# Mindtastic > AI strengthens what you already know about your work. Four specialist tracks for leaders, document professionals, developers, and governance — behavioral change, not tool training. Mindtastic provides AI training for senior developers and teams. We focus on accountability-first, production-focused AI integration — not demos or prototypes. Our methodology treats the developer as a conductor orchestrating AI tools, with human-in-the-loop responsibility for all output. Based in Stockholm, Sweden. ## Pages - [Home](https://mindtastic.se/): Marketing landing page with overview of AI training services - [Articles](https://mindtastic.se/articles): Published articles on AI development methodology, validation, security, and production workflows - [Audience](https://mindtastic.se/audience): Target audiences and personas for AI training - [About](https://mindtastic.se/about): About Tomas André and the Mindtastic approach - [Contact](https://mindtastic.se/contact): Get in touch for AI training inquiries - [Workshop](https://mindtastic.se/workshop): AI orchestration workshop — hands-on production-focused training ## Articles ### [The accountability test](https://mindtastic.se/articles/the-accountability-test) A computer cannot be held accountable, so it must not make a decision no one will answer for. That 1979 rule is the test leaders need now: for any decision you hand an AI, name who is accountable when it goes wrong. If the honest answer is no one, gate it to a human. # The accountability test In 1979, IBM put up a slide in an internal training session. Two typewritten lines: a computer can never be held accountable, therefore a computer must never make a management decision. We are going to take it at face value. The paper trail behind the photograph is thin, but the weight is not in who said it. It is in what it says, and what it says is a test every leader deploying AI can run this week. ## The slide was a syllogism, not a slogan Most people quote the sentence and stop. But the page behind it, read through the show-through, defines a management mandate in three parts: authority, responsibility, and the capacity to be held accountable. It then sets a value on each. On the third, applied to a computer, it prints one answer in capitals: none whatsoever. So the argument is not that computers are unreliable. It is that accountability is a precondition for holding a mandate at all. Something that cannot bear it cannot hold one, however good its judgment. That is not a claim about 1979 hardware. It is a claim about the nature of a decision. ## The test itself Here is the operational version, and it fits on one line. For any decision you are about to hand to an AI, ask: when this goes wrong, who is accountable? Name the person. If the honest answer is no one, you have not automated a decision. You have removed the person who answers for it, and left a gap where the accountability used to be. That gap is where AI deployments fail in production, not in the demo. The demo works. The gap only shows up the day something goes wrong and everyone looks around the room for who owns it. ## Capability is the wrong axis Leadership teams keep asking the same question: is the model good enough yet? It is the wrong question, because the answer weakens every quarter. Each new model is more capable, so a decision that felt too risky to automate last year feels safe this year, and the line keeps sliding. The accountability question does not slide. A model that becomes twice as capable does not become half as accountable. It becomes exactly as unaccountable as before. Capability tells you what an AI can do. Accountability tells you what it may decide. Those are different axes, and only one of them moves. ## Where the line actually falls This is the part we train. You do not draw the line once for "AI" in the abstract. You draw it decision by decision. - **Map the decisions the AI touches.** Not the tasks, the decisions. A task can be handed over freely. A decision has consequences that land on someone. - **Sort each one.** Reversible and low-consequence: let the AI run, sample-check the output, move on. Trust-bearing, meaning money, safety, or a promise to a customer: gate it to a named human before it takes effect. - **Make the gate a real person, senior enough to validate.** A gate that rubber-stamps is not a gate. You cannot sign off on what you do not understand, so the person at the gate has to be able to see when the answer is wrong, not just that an answer exists. - **Refuse the black box.** If an agent acts and no one owns what it did, that is not efficiency, it is an unclaimed liability. The pattern that works, the one serious operators land on, is simple: the human stays accountable for the agent, always, even when the agent does most of the work. None of this is a brake on AI. The checkpoint is not friction for its own sake. It is the moment the decision actually gets made, by the one who will answer for it. ## The travesties they already named The same 1979 page listed what it called travesties, confusions to avoid. Two of them read strangely well today: the computer as manager, the computer as god. They did not foresee a model architecture. They foresaw the confusion of swapping the one who bears a decision for the thing that computes it, and they named it a category error rather than an efficiency choice. That is the confusion the test is built to prevent. Draw the line before you deploy, not after the incident review. Name the human. Then the system has an owner, and the mandate stays where it belongs. *Companion piece (the personal take): [En dator kan aldrig ställas till svars](https://tomasandre.se/insights/en-dator-kan-aldrig-stallas-till-svars). Related: [The AI Validation Imperative](/articles/ai-validation-imperative-developer-accountability) and [Accountability levels](/articles/accountability-levels).* --- ### [The AI transformation that moves people, not tools](https://mindtastic.se/articles/ai-transformation-moves-people) Giving everyone a license isn't a transformation — it's a purchase. The real work moves people, not tools: map where each person actually is, move them through a stretch project in an adjacent domain, and build a portfolio instead of selling hours. # The AI transformation that moves people, not tools There's a sentence you hear constantly from leadership: "We've given everyone a license — we're driving the AI transformation." And then nothing happens. The licenses are bought, the tools are rolled out, and the way the organization works is exactly what it was. Same horse, slightly faster. The bottleneck is never the technology. It's the person at the end of it. Roughly half of a team will take to AI and roughly half won't — and the split isn't driven by the organization or the tooling, it's driven by mindset. The ones who resist are usually the ones who haven't really tried. They don't want to be replaced; they still want to be the one who writes the code. That's a human problem, and you don't solve a human problem by buying software. So a real transformation moves people, not tools. Here's a methodology that does. ## Map where each person actually is Start with an honest audit of the current state — not "do we have licenses" but "what is each person actually doing." Have they really used the tool, not just installed it? What does their last month of real usage look like? What domain are they in — embedded, web, data? You're not grading anyone. You're locating them, because where you move someone depends on where they're standing. ## Move them through a stretch project This is the part most programs skip. You don't move people with a slide deck; you move them through work they've never done. Take a team that knows, say, an aging desktop application on an old database, and have them rebuild a slice of it as a modern web app on a different stack — with AI alongside. The point isn't the app. The point is that **when you already know the domain, AI lets you learn the adjacent part fast.** They come out the other side having done something new, and saying "now I can do this." That confidence is the actual deliverable. Be deliberate about who goes first. Seniors who adopt the new way are world-class — their judgment is exactly what AI amplifies. Pick the few who will go in, drive the thing, and become the people others learn from. Peer-to-peer is how adoption actually spreads. ## Build a portfolio, not hours The last shift is the hardest, because it's commercial. "We're 20% more effective" is a dead end — a buyer can't validate it, and if you bill by the hour, working faster just means billing less. The model fights you. What doesn't fight you is a portfolio. "We built this ourselves, with these people, with this result." Something concrete you can point to. The consultancy that survives this stops selling hours and starts selling outcomes, and the portfolio is the proof that makes the outcome credible. Sales matters, but the portfolio is the foundation sales stands on. ## The honest part Moving people takes time — far longer than the technology does. Tech is fast; humans aren't, and some won't come at all. That's not a failure of the program; it's the shape of it. The leaders who get it right treat the whole thing as what it is: a human being moved, one stretch project at a time, with a portfolio to show for it at the end. You don't transform by buying licenses. You transform by moving people. --- *Related: [AI adoption is a change management problem](/articles/ai-adoption-is-a-change-management-problem) and [Measuring outcomes, not activity](/guides/leadership-measure-outcomes).* --- ### [Voice on legacy code: talking away tech debt](https://mindtastic.se/articles/voice-on-legacy-code-tech-debt) Most teams point AI at greenfield. The hardest tech debt sits in the legacy systems nobody touches — and there's a way to cut it without rewriting a line: have a developer talk through the code, then run the transcript against the codebase. # Voice on legacy code: talking away tech debt Most teams point AI at greenfield — new features, fresh repos, fast prototypes. The hardest debt sits in the other direction: in the legacy systems that actually run the business and that nobody wants to touch. They work, they bill, and the documentation is either stale or missing. Everyone treats them as a black box with a sign on it: don't touch. There's a way to use AI against those systems that almost nobody tries, and it's the least glamorous thing in the toolbox — have a developer talk through the code, out loud, while recording. ## The method Three steps, and none of them rewrite a line. **1. Record the walkthrough.** Sit the developer who knows the system in front of a recording and have them narrate it. What does this do? Where does it break? What do you always check before you change it? What's the assumption buried in this function that nobody remembers? Developers aren't used to talking about their code — they write it. After a minute, it loosens. **2. Run the transcript against the codebase.** This is where it gets useful. The transcript becomes structured text, and you put that next to the actual code. The model surfaces the *diffs* — where what the developer said the code does differs from what it actually does. It surfaces the documentation gaps, because now there's finally a description to compare against. It surfaces the spoken-in-passing assumptions the whole system rests on. **3. Produce the artifacts.** Documentation that didn't exist. A map of where the debt actually lives. A list of the places where the developer's mental model and the code have drifted apart — which is exactly where the next incident is hiding. You haven't refactored anything. But you've moved a real chunk of tech debt from nobody-knows to someone-knows — often around a fifth of it — using AI in the *old* process, not in a new build. ## Why voice, specifically The knowledge about a legacy system is rarely in the repo. It's in the head of whoever has lived with it: the 3 a.m. debugging, the times it broke, the quiet rules about what you don't touch. None of it is checked in anywhere. A language model can only work with what's in the context window. The one thing a legacy codebase is missing is exactly what the developer carries around. Voice is the only practical way to get it out — ten minutes of talking holds more of the real model of the system than anyone will write down in a week. ## The line you don't cross The developer stays the owner of what's true. The model structures what was said and points at where it scrapes against the code. The developer decides what actually holds. This is not automated documentation that nobody signed off on — if no human owns it, it isn't documentation, it's a liability. The model surfaces; the human validates. That discipline is non-negotiable on a system people depend on. ## It isn't new, and that's the point This worked with transcription years ago. The technology was never the barrier. The barrier was that someone has to think to point the voice pipeline *backward* — at the old system — instead of only forward at the new build. It's brown and boring and it doesn't demo well. That's probably why the debt is still sitting there. --- *Related: [Voice to structured meeting documentation](/articles/voice-to-structured-meeting-documentation) and [The production reality gap](/articles/production-reality-gap-part1).* --- ### [Governing AI cost at scale](https://mindtastic.se/articles/governing-ai-cost-at-scale) Buying licenses for everyone is not governance — it's a blown budget waiting to happen. How to get real visibility into AI cost and usage at scale, and why the gathering can be automated but the decision cannot. # Governing AI cost at scale There's a pattern that shows up in organization after organization. Leadership decides that everyone gets a license — that's the AI transformation. A budget is set, usually assuming a fraction of people will really use the tools and the rest won't touch them. Then, months in, the budget is blown and nobody can explain why. Ask what happened and it comes out. They don't know who uses what. They don't know whether it's used for work or privately. The vendors' pricing is moving. Someone wanted the $20 tier, someone else pushed for the $200 tier, and nobody governs it — it just happens. In an organization of thousands, there's no sane way to attribute the cost back to a budget. What actually happened is that they bought licenses and called it governance. You don't get one by buying the other. **You can't govern what you can't see.** ## Gather deterministically The first move is visibility, and it's mechanical, not magical. The things worth measuring are measurable: usage per person (commits and lines from the repositories), spend per person (against the API), and which license tier each person is on. Clone the repos, pull the numbers, track the spend. This layer is programmatic and deterministic. There's no judgment in collecting it, which is exactly why you can automate it without a second thought. ## Treat the metric honestly Then resist the temptation to trust the number too much. Commits and lines are a *rough* signal, nothing more. One of the most senior people on a team will write few lines of high complexity — a day of thinking, four lines, straight to production. Three hundred lines from someone else might mean they never really engaged. The number points; it doesn't conclude. Measure outcomes, and know the limits of the proxy you're using to do it. ## Keep the decision human Here's the line that matters most, and it's where most "AI governance" goes wrong. Gathering is one thing. Deciding is another. The moment someone asks for the *automated report* — the one where the model not only collects the data but draws the conclusion and recommends the action — you should push back. You can't act on a conclusion you can't validate, and the model can't tell you what a number means for this organization, this person, this month. That meaning is the decision, and the decision is the thing leadership is responsible for. Automate it and you've automated away the only part that was yours to own. So: automate the gathering, present the insight, and let a human take the decision. Deterministic visibility plus human judgment is governance an organization can actually live with. A dashboard that decides for you is not. ## The job is the judgment The report is the easy part. The hard part — reading it against what you know about the work, the people, and the moment, and then deciding — is the job. That's why it sits with a human and stays there. You don't buy governance. You build the visibility, and you own the decision. --- *Related: [Measuring outcomes, not activity](/guides/leadership-measure-outcomes) and [Skills as governance](/guides/skills-git-distribution).* --- ### [AI adoption is a change-management problem](https://mindtastic.se/articles/ai-adoption-is-a-change-management-problem) Most AI rollouts stall at about half the team, and leaders reach for a better tool. The blocker was never capability. It is behaviour, and behaviour change is a discipline some firms already own. That changes who is actually positioned to lead AI adoption. # AI adoption is a change-management problem There is a pattern you can set your watch by. An organisation decides to get serious about AI. It buys licences, runs an introduction, hands the tools out. A few weeks later, roughly half the team has woven the tools into how they work. The other half has quietly gone back to how they did things before. The standard response is to reach for a better tool. A new model dropped last night, surely that's the unlock. It rarely is. The half that stalled did not stall because the tool was too weak. They stalled because nothing told them why this was worth changing for. ## The blocker was never capability When you look closely at the half that adopted and the half that didn't, the dividing line is almost never technical skill. It's whether the person found a reason that was theirs. A developer who sees the tool close the gap between what they understand and what they have to ship adopts it. A developer who is simply told to use it, with no change to what success looks like for them, does not. That is not a technology gap. It is the oldest problem in organisational life: people change how they work when the change makes sense from where they sit, and not before. You cannot install that with a licence. You have to lead it. ## Which means it lands in a discipline that already exists Here is the part most of the AI conversation misses. If adoption is fundamentally about behaviour, reasons, and the quiet fears underneath them, then the work is change management. And change management is not new. There are firms, teams, and people who have done nothing else for decades. Reading where an organisation resists. Finding the individual why. Moving a group from compliance to ownership. Surfacing the things nobody says in the meeting, the fear about job security, the worry that faster means less to bill. Those firms tend to watch the AI wave from the sidelines, assuming it belongs to the technologists. It does not. The hardest part of AI adoption is the part they are already expert in. ## What they are missing is one layer, not the whole stack So why hasn't this already happened? Because the change-management discipline has a gap of its own, and it is exactly the inverse of the technologists' gap. A pure technology shop can run the tools but cannot move an organisation. A pure change shop can move an organisation but cannot credibly stand in front of a development team and show the work, in production, with their own name on it. Talking about AI is not the same as shipping with it. A team can tell the difference in the first ten minutes. What a change-management firm is missing is therefore narrow and specific: the AI-as-a-competence layer, and the production credibility to back it. Not a new identity. One layer added to a discipline they already own. ## The defensible position in 2026 Put the two together and you get something neither side has alone. The behaviour-change expertise that makes adoption actually stick, plus the hands-on, in-production credibility that earns the room's trust in the first place. That combination is hard to copy. A technology vendor can add slides about change but cannot fake decades of organisational practice. A traditional consultancy can add AI vocabulary but cannot fake having shipped. The firms that win the next few years of AI adoption will be the ones who already understood that this was a leadership and behaviour problem, and who added the one missing layer rather than starting from scratch. It was never a technology question. It was a question of who is positioned to answer it. --- ### [Three words, four definitions — why AI conversations keep failing](https://mindtastic.se/articles/three-words-four-definitions) Skill, agent, and automation sound like shared vocabulary. In most AI conversations, they aren't. Each word carries three or four incompatible definitions depending on the ecosystem — and false consensus around them costs real decisions. # Three words, four definitions The meeting seemed productive. Everyone agreed: the solution would use an agent with custom skills and automation to handle the repetitive parts. Great. Aligned. Moving forward. Six weeks later, nothing shipped. The developer built a Claude Code workflow with local skill files. The product lead expected something closer to an autonomous assistant running in the background. The operations manager assumed it meant a Make scenario triggered by a webhook. They had been talking about the same three words for six weeks. They were never talking about the same thing. This is not a communication failure. It is a vocabulary failure — and it is almost universal in AI conversations right now. The words **skill**, **agent**, and **automation** carry between three and four incompatible definitions each, depending on the ecosystem, the mental model, and the tool the speaker has been using. No one lies. No one oversimplifies deliberately. The words just mean different things. --- ## "Skill" — three separate concepts ### Concept 1: A local workflow file (Claude Code) In Claude Code — Anthropic's CLI environment — a skill is a folder on disk containing a markdown prompt file. It runs in a local session. It cannot be triggered externally. It is personal tooling, bound to one machine and one user's session. Powerful for the person who built it. Invisible to the rest of the organization. ### Concept 2: A self-generated workflow module (OpenClaw) OpenClaw, an open-source agent framework, uses the word skill differently. Here, a skill is auto-generated from a workflow the user builds — and it can be triggered externally via webhook. Another system sends a POST request; the agent wakes up and executes. This is meaningfully different from a filesystem-bound session script. ### Concept 3: An API-invokable capability (Claude API) In the Claude API, skills are uploaded capabilities with unique identifiers. External systems trigger them via `skill_id`. Designed for integration and automation at scale, completely decoupled from any local session. **Why this matters:** When someone says "we'll build a skill for that," they might mean any of the three. A developer who has been working with Claude Code thinks *local workflow, no external trigger*. A builder who has been working with OpenClaw thinks *webhook-invokable module*. A system architect thinks *API-registered capability*. All three agree to the plan. None of them are building the same thing. The practical test: *Which kind of skill, in which ecosystem?* That question ends the ambiguity immediately. --- ## "Agent" — four axes that slide into each other The word agent carries even more interpretive weight because it spans both technical architecture and organizational metaphor. **Product axis:** Scout (Microsoft), Hermes (Nous Research), OpenClaw — these are specific named products with distinct architectures. Scout runs under an Entra identity with audit trails, designed for M365 organizations. Hermes builds a closed learning loop after each task — depth over breadth. OpenClaw is gateway-first, built for breadth of integration. Using "agent" to mean any of these three products leads to meaningless comparisons. **Architecture axis:** Technically, an agent is an LLM in a loop with tools and memory. That is an architectural description, not a product. A Claude API conversation with tool use is architecturally agentic. So is a simple Python script that calls an LLM, checks output, and loops. Calling both "agents" obscures everything important about how they actually work. **Autonomy axis:** This is the one that confuses organizational discussions most. "Agent" can mean a scripted sequence of steps that looks autonomous (low autonomy, high predictability) or a genuinely self-directed process that decides its own next action based on intermediate results (high autonomy, lower predictability). The trust requirements for these two things are fundamentally different. **Metaphor axis:** "Digital employee." "Staff on a subscription." "Hired on retainer." These are sales metaphors that import human accountability structures onto software. The metaphor is powerful because it is legible to decision-makers who don't track the technical distinctions. It is also misleading because it suggests accountability transfer that does not actually happen. **Why this matters:** An organization that says "we want an agent to handle our onboarding flow" might mean any combination of these four axes. Before building anything, the conversation needs to answer: *What product or architecture? What autonomy level? Who remains accountable when it goes wrong?* --- ## "Automation" — different status in different mental models This one is subtler because the word carries different *category status* depending on who is speaking. **For a practitioner:** Automation is a first-class category. Make, Zapier, n8n — these are automation platforms. An automation is a defined pipeline with a trigger, steps, and an outcome. It is a stable, testable thing. The principle of *automation before agents* — build solid, machine-safe pipelines that an agent can *start* rather than building an agent that replaces the pipeline — treats automation as the dependable foundation layer. **For a process thinker:** Automation is not a meaningful category. There are just processes, divided into process steps. Some steps are human, some are programmatic. Calling the programmatic ones "automation" adds no useful information — it is just describing the substrate of execution. From this perspective, "we have zero automations" might mean "we have not set up any Make scenarios" or might mean "we do not think in terms of automation as a category at all." These are not incompatible worldviews. But they make conversations fail constantly. When a consultant says "you need to automate this," the practitioner hears *specific platform, defined trigger, testable pipeline*. The process thinker hears a vague recommendation to make things more programmatic. Both nod. Neither acts on the same thing. **The Mindtastic distinction:** The reason we separate automation from agents in the AI Orchestration framework is precisely because they have different trust profiles. An automation is a workflow you have reviewed, defined, and can validate. An agent operates within that workflow — or outside it, with higher autonomy and therefore higher accountability requirements. Conflating the two leads to either over-engineering (treating every Make scenario as an agent decision) or under-engineering (treating every agent decision as a simple automation with no accountability layer). --- ## The practical consequence False consensus costs real decisions. An organization that approves "an agent-based approach with skills and automation" has approved almost nothing. The words are compatible enough that everyone nods — and incompatible enough that three teams can build three different things with identical mandate and budget. The fix is not a glossary. Glossaries require people to check them, and they don't, especially under deadline. The fix is one question, asked early: *Which kind of X, in which ecosystem?* - Which kind of skill — local session, webhook-triggered, or API-registered? - Which kind of agent — which product, what autonomy level, who stays accountable? - Which kind of automation — a defined platform pipeline, or general programmatic processing? The question takes thirty seconds. The answer tells you whether the conversation was real alignment or apparent consensus waiting to collapse. In AI right now, apparent consensus is the norm. The technology moves fast enough that everyone is slightly behind, and no one wants to be the person who admits they are not tracking the distinctions. So people agree on words and diverge on reality. Asking *which kind* is not a sign of confusion. It is the most useful thing you can do in most AI conversations. --- *Related: [Accountability levels in AI development](/articles/accountability-levels) and [The work loop — six steps that make accountability concrete](/articles/ai-development-workflow-read-plan-flush-build-review)* --- ### [The two-thread pattern: Codex for spec, Claude for build](https://mindtastic.se/articles/two-thread-pattern-codex-spec-claude-build) The most polished AI workflows on dev teams converge on the same pattern. One model writes the specification. A different model builds from that specification in a different thread. Don't mix providers in the same conversation. # The two-thread pattern: Codex for spec, Claude for build Two senior developers on the same team, working independently on the same task, used exactly the same AI workflow. They had never discussed it. They had never seen it documented. They both arrived at it through their own iteration. The workflow: 1. Open a thread with one model (Codex/GPT). Ask it to write a product-style specification. 2. Refine the spec through dialogue until it captures the intent without specifying implementation. 3. Close that thread. Open a new thread with a different model (Claude with a developer skill). 4. Hand the spec over. Let the second model build from it. 5. Optionally: hand the result back to the first model for cross-review. They called it different things. The pattern is the same. I'm calling it the two-thread pattern. It's becoming the team's de facto default. ## Why two threads, not one The temptation when working with AI is to keep the whole conversation in one place. One thread, one model, one history. Everything in context. Everything connected. This fails for three reasons. **Context corruption.** Long threads accumulate drift. The model "remembers" things that didn't quite happen — earlier turns subtly bias later ones. By the end of a 200-message conversation, the model is operating on a partly-fictional version of the project. The conversation feels coherent because the model is good at appearing coherent. But the output quality has degraded measurably from where it was at message 20. **Model affordances.** Different models are good at different things. Codex/GPT has a strong product-thinking mode — it can write a specification that reads like it came from a product manager, which is useful precisely because product managers think about *what* and *why* before they think about *how*. Claude with a developer skill is exceptionally good at building from a well-formed spec, asking clarifying questions when the spec is ambiguous. The strengths are complementary in sequence, not in parallel. **Mixing providers breaks metadata.** This is the most underappreciated failure mode. If you switch from Codex to Claude (or to Gemini) inside the same thread, the context window includes content from a model with different metadata expectations. The receiving model can read the content, but it can't read the conversation structure cleanly. Edge cases fire. Citation expectations break. Tool-use patterns get confused. Two threads — separate, sequenced, with a deliberate handoff — avoids all three. ## What each thread does The spec thread, with Codex/GPT: - Starts with the customer brief, the team's guidelines, and relevant code samples - Produces a specification that's deliberately product-oriented, not implementation-oriented - "Don't provide architectural alternatives. Don't provide implementation tutorials. Specify what the audit log should do and what it shouldn't do." - Iterates until the spec captures intent without specifying mechanism - Optionally: produces a README, a definition-of-done, and operations notes - Saved to disk as a markdown file The build thread, with Claude (typically with a developer skill): - Starts fresh, with the spec from the previous thread loaded as input - Reads the spec, asks clarifying questions, asks for permission to begin - Builds incrementally with reviewable diffs - Tests as it goes - Handles ambiguity by surfacing it, not by guessing The work loop runs inside the build thread. The spec thread is upstream of the work loop. ## The cross-review variant One of the senior developers added a step the other hadn't: After Claude finished building, he opened a new thread with Codex and asked it to review what Claude had produced. Codex found three issues that the developer-skill self-review had missed. One was a retry-after-first-batch failure in the queue handling. One was an access-control gap. One was a configuration edge case. This works because models tend to catch each other's blind spots better than they catch their own. The retry logic was something Claude had written confidently because it followed Claude's training patterns; Codex evaluated it against different patterns and noticed the mismatch. This isn't ensemble voting. It's adversarial review. Cheap, effective, and the most novel workflow technique I've seen this year. ## Why this isn't ChatGPT 101 The two-thread pattern looks pedestrian. "Use one tool for one thing, another for another." That sounds like advice from 2023. What's different: **The threads have a designed handoff.** The spec produced in thread one is not a conversation snippet. It's a deliberate artifact: a markdown file on disk, structured like something a product manager would write. The handoff is to the file, not to the model. Either model could pick it up. The artifact survives the conversation. **The two-thread structure is upstream of model selection.** Once you have the pattern, you can pick different models per thread depending on the task. Codex isn't the only product-style spec model. Claude isn't the only good builder. The pattern survives changes in which specific models you're using. **It explicitly forbids mixing within a thread.** This is the part most developers haven't internalized yet. People still try to "just switch models" mid-conversation when something isn't working. That's not switching — that's silently breaking the context. If you want a different model, start a different thread. ## When the pattern doesn't apply - **Throwaway work.** A 20-line script doesn't need a spec phase. One thread is fine. - **Heavily exploratory work.** Sometimes you don't know what you want until you've tried to build it. The spec emerges from the build attempt. In that case, expect to throw away the build and write a spec from what you learned. - **Solo work in your own domain.** If you're deep in a codebase you know intimately, you can compress both phases mentally. The spec lives in your head; the build happens in one thread. - **When the project is too small to justify the overhead.** A spec phase costs ~30 minutes. Below a 4-hour task, it's usually not worth it. For real production work that spans more than a few hours, the two-thread pattern is paying for itself almost every time. ## How to start using it 1. **Pick your next non-trivial task.** Something with more than one architectural decision. 2. **Open a thread with Codex (or another model good at structured documents).** Give it the customer brief, the code context, the guidelines. Ask it to write a product-style specification. 3. **Iterate on the spec, not the code.** Push back when it specifies implementation. Ask for clarification when intent is unclear. 4. **Save the spec to disk.** Markdown file. Commit it. 5. **Close the thread.** Don't reuse it. 6. **Open a new thread with Claude (with a developer skill if you have one).** Load the spec as input. Let Claude build. 7. **When Claude finishes, optionally open a Codex thread and ask for a code review.** You'll feel the difference in two places. The build phase is faster because the spec gives the model the right context up front. And the review surfaces issues you'd have missed otherwise. The senior developers I see using this pattern are 4-5x as productive as the same developers were six months ago. Some of that is them. A lot of it is this. --- *The two-thread pattern was observed independently arrived at by two senior developers during a recent Mindtastic Sprint engagement, May 2026. The cross-review variant was added by one of them after reading research on cross-model evaluation. Customer identity withheld.* --- ### [Cross-model code review: ask one AI to grade another](https://mindtastic.se/articles/cross-model-code-review) Ask one AI to review what another AI wrote. The reviewer model finds issues the author model can't see — adversarial evaluation that costs almost nothing and catches what self-review misses. # Cross-model code review: ask one AI to grade another There's a quiet pattern emerging on senior dev teams that I haven't seen documented yet. It's worth naming because it's effective, cheap, and not obvious until someone shows you. A senior developer I was working with had just finished building a complex audit logging system. He'd used Claude with a developer skill — multi-thread, careful, structured. He ran Claude's built-in self-review twice. Both passes came back clean. By his own assessment he was 90% confident in the code. Then he opened a different thread, with Codex this time, and asked it to review what Claude had written. Codex found three real issues. One was a retry-logic bug — the implementation would fail silently after the first batch in certain queue configurations. One was an access-control gap that the original requirements had implicitly assumed but never made explicit. One was an edge case in idempotency where two events arriving in the same millisecond could produce duplicate records. All three were real. All three would have shipped. All three were missed by Claude reviewing Claude. The pattern has a name now: cross-model code review. ## Why it works The intuition is straightforward: models trained on different data with different fine-tuning objectives have different blind spots. When a model reviews its own output, it's checking against patterns it was trained to consider correct. It's looking in the places it knows to look. A model trained on different data looks in different places. The retry bug in the example above was something Claude had written confidently because the pattern matched something it had seen in training. Self-review didn't flag it because the pattern looked right by Claude's standards. Codex, evaluating it against different training patterns, noticed that this specific implementation deviated from the conventions it had absorbed for queue handling. Neither model is "better." They're differently calibrated. That difference is the leverage. ## How it's different from ensemble or voting This isn't ensemble voting where multiple models produce candidates and you pick the most-agreed-upon answer. It's also not the reflexion loop where a model criticizes its own output (though that has value too). Cross-model code review is **adversarial**: - The reviewing model is given the producing model's output as a fait accompli. - It's asked to find what's wrong, not to suggest improvements. - The reviewer doesn't try to rewrite — only to flag. - The developer makes the call on which flags are real. It's the same shape as a code review between two human engineers, except the engineers are two different AI systems with different training distributions. ## What the workflow looks like The senior developer's actual process: 1. **Build in one thread.** Claude with developer skill. Spec is loaded as input. Code is produced incrementally with reviewable diffs. 2. **Self-review in the same thread.** Run the developer skill's code-review prompt twice. Fix what surfaces. Get to a confident state. 3. **Open a new thread with a different model.** Codex in this case. New context. Fresh start. 4. **Hand over the code and ask for review.** Not "improve this code." Specifically: "find problems." 5. **Surface issues in a list.** Each issue should be specific: what's wrong, where, why. 6. **Developer triages.** Some flags are real. Some are stylistic differences between the models' training. Some are out-of-scope. The developer decides. 7. **Fix the real ones in the build thread, or open a new build thread to address them.** Cost: roughly 30 minutes of extra work per significant component. Hit rate: 2-4 real issues per review in the examples I've seen. ## When it adds the most value - **Code that's hard to test or review by running.** If you can't easily simulate the failure mode (race conditions, error handling, retry logic, integration code), cross-model review is one of the few practical ways to surface issues before production. - **Code at scope boundaries.** Anywhere a component meets the outside world — APIs, databases, queues, third-party services — the conventions differ between models' training. Cross-model review surfaces these mismatches. - **Security-relevant code.** Different models have different sensitivities about security patterns. Use this asymmetry deliberately. - **Long-context output.** When the producing model has built something across many turns, its self-review is operating on the same potentially-drifting context. A reviewer in a fresh thread sees the artifact, not the conversation. ## When it doesn't help - **Throwaway code.** If the code is going to be deleted in a week, don't review it. - **Code you can fully test by running.** Tests catch what cross-model review would have flagged, and you get test artifacts as a bonus. - **Code in a deeply familiar domain.** Sometimes the developer knows more than either model. Cross-model review can produce false positives where the developer's domain knowledge correctly overrides both models. - **Code that's already passed a thorough human review.** Two AI reviews on top of a human review usually doesn't add much. ## The deeper pattern Cross-model code review is part of a broader pattern I've been calling [the two-thread pattern](two-thread-pattern-codex-spec-claude-build.md). Different models have different strengths, sequenced in separate threads, with deliberate handoffs between them. In the two-thread pattern, the sequence is: spec model -> build model. Cross-model review extends it: spec model -> build model -> reviewer model. Three threads, three artifacts (spec, build, review notes), three models with complementary strengths. The cost is small. The value, on senior production code, is genuine and repeatable. ## How to start If you're working with Claude regularly, try this on your next non-trivial completion: 1. Finish what you'd normally consider done. 2. Open a Codex thread. Paste the relevant files. Ask: "Review this code. Find what's wrong. Be specific." 3. Read the response. Sort the flags into "real", "stylistic", and "out of scope." 4. Fix the real ones. If you're working with Codex regularly, do it in reverse: ask Claude to review. The first time you do it, expect to be surprised by what you find. The second time, expect to start designing your work around it. By the fifth time, it's a habit. --- *Based on observations from a recent Mindtastic Sprint engagement, May 2026. The pattern was developed independently by a senior developer who reported using it as standard practice for production code. Customer identity withheld.* --- ### [Where you start is where you'll stay](https://mindtastic.se/articles/where-you-start-is-where-youll-stay) The most informative thing about a team's workshop is where each person chose to begin. Each starting point encodes a bias about what the task is actually for. The first lever is noticing it. # Where you start is where you'll stay I ran a workshop with six developers recently. Same task: design an audit log component for a real customer codebase. Same brief, same materials, same week to work on it before we reconvened. When we met again, six radically different things had been built. One developer had a working RabbitMQ publisher/consumer with a polished UI. One had four parallel logging methods designed in detail but no code yet. One had a dual-store architecture with OpenSearch and a complete read interface. One had a full PRD, software requirements spec, and architecture document — and not a single line of code. One had a framework focused entirely on who would use the audit log and what indicators they'd need. One had not started. For a few minutes I thought the team had failed to converge. Then I realized the diversity *was* the data. ## The starting point encodes a bias Every developer chose where to begin. That choice — usually unconscious — determined everything that followed. The one with the working RabbitMQ system started by asking "what should it track?" That's a data-model question. A backend engineer's default. He built downstream from data. The one with four parallel methods started from "how should this integrate with the existing codebase?" That's an optionality bias. He designed multiple paths so the team could pick later. Methodical. Risk-averse. The one with the full OpenSearch implementation started from "what are my architectural options?" Research-driven. He'd recently read about dual-store designs and chose the differentiator deliberately. His starting move was to ask Codex for three alternatives before touching code. The one with the full spec and no code started from "what does the system actually need to be?" Specification bias. He was the CTO. He wrote the guidelines the team works from. His default is rigorous top-down design. The one focused on the user started from "who is this for, and what conclusions will they draw?" That's a product/end-user bias. He was the VD. The audit log to him was a decision-support tool, not a record. The one who didn't start at all — well, that's a different question. But his admission set the tone for the whole room. ## Where you start is where you'll always start Here's the thing nobody told these developers when they got the task: their starting point isn't a property of the task. It's a property of them. The same person will repeat the same starting move on the next task. And the one after that. Backend engineers will start from data even when the task is fundamentally about user flow. CTOs will start from spec even when the task is small enough to just write. Product-minded people will start from "who is this for" even when the audience is obvious. We don't pick starting points — we recognize them after the fact, or we don't recognize them at all. That's not a failure. The bias is usually correct *for the kind of work the person normally does*. The backend engineer's data-first instinct is what makes him good at backend. The CTO's spec-first instinct is what makes his guidelines coherent. The product person's user-first instinct is what makes him a useful product person. But when the task at hand isn't the task they're optimized for, the bias misfires. And because the bias is unconscious, the misfire is invisible. ## The first lever is noticing You can't change your default starting move by trying harder. You change it by noticing it. This is the single most useful exercise I've found for teams that work with AI: ask each person, after they've finished something, *where did you start?* Not what did you build. Not what model did you use. Where did you begin? The answers cluster. Backend engineers describe the data first. Frontend engineers describe the user interaction. Architects describe the contracts and boundaries. Operations people describe the deploy and the monitoring. PMs describe the user story. Make the starting points visible to the team. Suddenly everyone sees: ah, that's what we always do. *I* always start from there. The bias is in the room. > "Det första jag brukar göra med varje projekt är att läsa strukturen av loggfilerna." (The first thing I usually do with every project is read the structure of the log files.) That was one developer describing his approach. Not wrong. Not right. Just his default. Once he named it, he had a choice the next time. ## Why this matters more with AI In pre-AI software development, your starting bias mattered less. Code took long enough to write that you'd run into the bias's failure modes and correct mid-flight. The grind of typing protected you. With AI assistance, the grind is gone. You can produce a complete first draft of almost anything in 30 minutes. The bias now scales: whatever you started thinking about, you've now built. The wrong starting point doesn't slow you down — it just produces more wrong output faster. The result is that AI-assisted teams either: - Develop strong self-awareness about starting points and choose deliberately, or - Build six different things and discover after the fact that nobody was solving the same problem The first group has a workflow superpower. The second has expensive churn. ## What to do about it If you're a developer working with AI: 1. **Notice your default starting move.** Write it down. "When I get a new task, the first thing I reach for is ___." Be specific. 2. **Ask whether this task matches your default.** A data-modeling task fits a data-first developer. A user-flow task does not, even if it eventually has data in it. 3. **If there's a mismatch, deliberately start somewhere else.** Read the spec, then start from the user. Read the code, then start from the integration surface. Force a different first move. If you're leading a team: 1. **Make starting points a recurring question.** After every shipped feature, ask each contributor where they started. 2. **Map the team's defaults.** You'll find clusters and gaps. The gaps are where you have blind spots. 3. **Pair people with opposite defaults** on tasks where the work needs to span both biases. A backend engineer + a product-minded engineer often produces more than two backend engineers, even when the task is technically backend-heavy. If you're a facilitator running a workshop or training: 1. **Don't ask "what did you build?" Ask "where did you start?"** The first question produces self-congratulation. The second produces self-awareness. 2. **Surface the diversity of starting points as the lesson** — not as a coordination failure. The lesson is the spread. 3. **Let the team draw the conclusion themselves.** They'll see it. Don't lecture about it. ## The deeper claim The methodology pieces in Mindtastic — foundation pillars, the work loop, voice methodology, the three approaches — are all attempts to make implicit thinking explicit. Where-you-start is the most upstream of these. Everything else happens after. You can run the work loop perfectly and still end up with the wrong thing built, if you started from the wrong place. The work loop is downstream of the starting point. So is the prompt. So is the model selection. So is the review depth. Knowing where you start is the cheapest, most reliable productivity intervention I know of in AI-assisted development. It costs nothing. It takes thirty seconds. Most teams have never done it. Start there. --- *Based on observations from a recent Mindtastic Sprint engagement with a senior development team, May 2026. Six developers, one task, six legitimate starting points. Customer identity withheld.* --- ### [AI Development Accountability Levels — Solo, Engagement, Team Delivery](https://mindtastic.se/articles/accountability-levels) The Mindtastic accountability framework defines three levels of AI-assisted development based on where the consequences land. Solo (>10×), Engagement (5–10×), Team delivery (2–5×). Each level has a different discipline requirement. # AI Development Accountability Levels The most common mistake in AI-assisted development is not a technical one. It is applying the wrong discipline for the context you are in. The Mindtastic accountability framework starts from one question: **who bears the consequences if something goes wrong?** The answer determines which discipline is appropriate — and which shortcuts are rational versus dangerous. There are three levels. --- ## Level 1 — Solo (>10×) **Swedish:** Solo | **English:** Solo | **Performance ceiling:** >10× **Consequences land on:** You alone. You are building something for your own purpose. It may be a personal tool, an internal script, a learning project, or a production system — but only you are affected if it fails. At this level, rational flexibility is rational. You can choose how carefully to review AI-generated code because the cost of getting it wrong falls entirely on you. Vibe coding — accepting AI output without deep review — is a legitimate choice here, not a professional breach. **Natural drift:** Toward vibe coding. This is fine at solo level. **Minimum policy:** None required. The work loop is good practice, not an obligation. **What solo level looks like:** A developer building their own scheduling tool. A consultant automating their own invoice process. A team member running a personal experiment in a development branch. An engineer building internal analytics that only they use. **What solo level does not mean:** "experimental" or "not serious." Solo work can be fully production-ready. The defining characteristic is consequence destination — not code quality or deployment environment. --- ## Level 2 — Engagement (5–10×) **Swedish:** Uppdrag | **English:** Engagement | **Performance ceiling:** 5–10× **Consequences land on:** You and the client. You are delivering to someone else. Their system. Their data. Their business processes. Your name is on the contract — and on the code. At this level, the work loop stops being optional. You must be able to say "I understood every line I committed" — not because a process mandates it, but because you are professionally responsible for what you deliver. Solo habits ("it looks right") are a professional breach at engagement level. **Natural drift:** Solo habits creep in. Speed replaces review. **Minimum policy:** The work loop is non-negotiable. Every commit requires understanding. You cannot claim professional delivery without it. **What engagement level looks like:** A freelance developer delivering a feature to a client. A consultant building a workflow integration. A developer at an agency working on a client's production codebase. A contractor inside a client's infrastructure. --- ## Level 3 — Team Delivery (2–5×) **Swedish:** Bolagsleverans | **English:** Team delivery | **Performance ceiling:** 2–5× **Consequences land on:** The organisation and the client. A team is delivering to a client. The structural challenge is that team accountability can diffuse to nothing — "everyone reviewed the code" means no one reviewed the code. When no single person feels responsible for a specific outcome, accountability disappears without any individual making a bad decision. The 2–5× ceiling is not a failure. It reflects the governance overhead that is appropriate and necessary when consequences land outside the team. A team delivering at 3× under proper discipline is doing riskier work correctly. A team claiming 10× at team delivery level is almost certainly operating with solo habits — and the accountability is invisible until something breaks. **Natural drift:** Accountability diffusion. "We" replaces "I." **Minimum policy:** Named owner per commit. Team decisions on AI policy (what data goes to external models, recording consent, parallel context threads, automation boundaries, shared terminology). These decisions must be made before delivery begins — they surface as urgent problems mid-delivery if left unresolved. **What team delivery looks like:** A development team at a software company. An in-house engineering team building for internal stakeholders. A team at an agency delivering to enterprise clients. Any context where more than one person commits to a shared codebase with external consequences. **The most common failure pattern:** A team delivery team operating with solo habits — individual AI use without shared policy, no named commit owners, no team decisions about what is allowed. The output looks correct. The accountability is invisible. Until something breaks. --- ## The performance multipliers explained The multipliers (>10×, 5–10×, 2–5×) represent realistic performance ceilings per level — not promises. The base is the **knowledge multiplier**: a senior developer using AI systematically gains 4–5× productivity regardless of context (this is the individual knowledge amplification effect from consistent AI use). This is the floor. The level determines the **ceiling**. Governance overhead — review requirements, named ownership, team policy decisions — compresses the raw velocity gain. This overhead is not waste. It is the appropriate cost of working in contexts where consequences fall on others. | Level | Swedish | English | Ceiling | Why the ceiling drops | |-------|---------|---------|---------|----------------------| | 1 | Solo | Solo | >10× | No governance overhead — you set your own rules | | 2 | Uppdrag | Engagement | 5–10× | Work loop required. You must understand every commit. | | 3 | Bolagsleverans | Team delivery | 2–5× | Named ownership + shared policy decisions + coordination cost | --- ## The approach spectrum The three accountability levels are a separate dimension from the three approaches to AI-assisted development. Choosing the right approach for the wrong level is one of the most common mismatches. | Approach | What it is | Appropriate at | |----------|-----------|----------------| | **Vibe coding** | Accept AI output without deep review. Fast iteration, low validation. | Solo level. Minimal engagement tasks with low stakes. | | **Structured balance** | Systematic AI use with mandatory review at each step. The default for professional delivery. | Engagement and team delivery. | | **Hardcore planning** | Full specification before AI-assisted implementation. Maximum control, highest overhead. | Team delivery for critical paths. Complex systems with high failure cost. | The approach is a tool choice. The level is a fact about your context. Match the tool to the context. --- ## Key terms ### Arbetsloopen / The work loop A six-step method for AI-assisted development that makes accountability concrete at each stage: read the codebase, plan the change, flush context, build, review (confidence score), commit and document. The commit step is where accountability is made real — it requires a named person who understood every line they signed. ### Commit-ankaret / The commit anchor The commit is the only accountability mechanism that survives team scale. It has a name on it. One developer. That developer either understood every line at the moment of committing — or did not. There is no collective commit. This is why the commit step in the work loop is not administrative: it is the accountability step. ### Konfidenspoäng / Confidence score A self-assessed rating before committing AI-generated code. High: I understand every line and can explain it. Medium: I understand most of it but have uncertainty — review more before committing. Low: I do not understand why this works — stop. The confidence score makes accountability visible before it is too late to act on it. ### Kontexthantering / Context management Managing what the AI "sees" in a given session. Too much context creates confusion. Too little loses coherence. Parallel context threads on the same codebase create silent conflicts — a file changed in one thread is not updated in another's context window. At team delivery level, context management is a shared policy question, not an individual preference. ### Ansvarsdiffusion / Accountability diffusion The structural tendency for team-level accountability to distribute until no individual feels responsible for any specific outcome. "Everyone reviewed it" is the canonical diffusion statement. The work loop and named commit ownership are the structural counters to diffusion. --- ## Why this framework exists No other AI training program distinguishes between accountability levels before deciding what discipline to teach. Most treat all contexts as equivalent. The consequence: solo habits (rational for solo work) become the default at team delivery level, where they are dangerous. The failure is silent because the output looks correct. The accountability gap only becomes visible after something goes wrong. Mindtastic trains team delivery discipline by default — Solo and Engagement are covered because understanding the levels is necessary to understand why Team delivery requires what it requires. --- *For the complete framework this builds on: [The Foundation — Four Pillars and the Work Loop](/foundation)* *For the approach spectrum in detail: [Vibe Coding vs. AI Orchestration](/articles/vibe-coding-vs-ai-orchestration)* *For how accountability works at team scale: [Accountability in Teams — Commit as Anchor](/articles/accountability-in-teams-commit-as-anchor)* *For the governance layer: [Track 4 — Team Delivery Policy Workshop](/workshop)* --- ### [Why Accountability Disappears in Teams — and the One Thing That Prevents It](https://mindtastic.se/articles/accountability-in-teams-commit-as-anchor) Organisations implementing AI-assisted development often believe they have accountability because they have processes. They don't. They have the appearance of accountability. Here's the difference — and the only mechanism that makes it real. # Why Accountability Disappears in Teams — and the One Thing That Prevents It Organisations that implement AI-assisted development often believe they have accountability because they have processes. They don't. They have the appearance of accountability. This distinction matters more now than it did three years ago. AI tools accelerate the production of code that looks right, passes tests, and gets committed before anyone has genuinely understood it. The processes — code review, sprint reviews, QA sign-off — are still there. But the accountability has silently evacuated. ## How accountability disappears The pattern is consistent across organisations. It usually starts small. A developer uses an AI tool to build a feature. The output looks clean. The tests pass. The PR gets reviewed — but quickly, because the code looks fine. The reviewer trusts the developer. The developer half-trusted the AI. The result ships to production carrying nobody's actual understanding. Nobody decided to skip accountability. It just diffused across the chain until nobody held it. This is what accountability diffusion looks like in practice: every handoff in the process dilutes individual ownership slightly, until the question "who actually understands this line of code?" has no honest answer. **"Everyone reviewed it" means no one reviewed it.** The more people nominally responsible for something, the less any one of them actually owns it. ## Why AI makes this worse Manual code has a natural accountability checkpoint: the person who wrote it understands it. They might not have written it well, but they know what it does and why. AI-generated code breaks that link. A developer can commit fifty lines they didn't write and don't fully understand. The code might be functionally correct. It might pass every test in the suite. And it carries a hidden liability: nobody owns it. When that code breaks — in production, three months later, under conditions nobody anticipated — the question "who is responsible?" produces only pointing. Not because anyone acted in bad faith, but because accountability was never attached to the code in the first place. The AI acceleration that makes teams faster also makes accountability diffusion faster. More code, more commits, more surfaces where nobody's understanding was actually tested. ## Why personal accountability is the foundation, not a pillar The Mindtastic framework places personal accountability as the foundation beneath the four pillars — not as one principle among several. This is why. Accountability cannot be shared. The moment it belongs to multiple people equally, it belongs to none of them fully. This is not a cultural observation — it's a structural one. Distributed accountability is a contradiction in terms. What gets distributed is the *appearance* of accountability. Consider the alternative: if personal accountability were a pillar — one principle among four — it could in theory be traded off against the others. Strong context mastery might compensate for weak accountability. Sharper thinking might partially substitute. It cannot. Accountability is pre-conditional. Without it, the other pillars describe how to work efficiently without anyone responsible for whether the work is correct. That is a faster path to the same failure. ## Three levels, three different standards Not all development contexts carry the same accountability requirement. Understanding the difference is as important as understanding the principle. Each level has a name, a realistic performance ceiling, a natural drift pattern, and a minimum policy requirement. **Level 1 — Solo (>10×):** Your risk. Your consequences. If you choose not to review every AI-generated line of a personal project, that's a rational decision. Vibe coding is legitimate here — you feel the consequences immediately. The accountability mechanism is your own judgment, and nothing else is required. *Natural drift: toward vibe coding. Minimum policy: none.* **Level 2 — Engagement (5–10×):** The client's system. The client's data. Your name on the contract — and on the code. The work loop becomes a professional obligation, not a choice. You must be able to say "I understood every line I committed." Solo habits — "it looks right" instead of reading the diff — are a professional breach at this level. *Natural drift: solo habits. Minimum policy: work loop non-negotiable, every commit requires understanding.* **Level 3 — Team delivery (2–5×):** Everything from level 2, plus the structural risk that no named person ends up owning anything. This is where individual accountability must be made explicit and enforced by method, because diffusion is the path of least resistance. The 2–5× ceiling is not a failure — it reflects the governance overhead that is appropriate and necessary when consequences land outside the team. *Natural drift: accountability diffusion. Minimum policy: named owner per commit + shared team policy decisions (recording, data, code standards, parallel threads).* Mindtastic's training targets level 3. Not because levels 1 and 2 don't matter, but because level 3 is where accountability most commonly disappears — and where the consequences are carried by someone outside the team. **The pattern is always the same: solo behaviour in a team delivery context.** A real example: a team building a new scheduling module during an all-hands AI workshop shipped conflict detection, driver assignment, and an initial mobile app view — all into the production codebase, in a single afternoon, with no change requests, no documentation, and no named owner per commit. When asked "what does your internal policy say about this?" the answer was silence. Not because anyone acted in bad faith. Because the team had never had to decide. ## The commit as the only anchor that works There is one mechanism in software delivery that resists diffusion: the commit. A commit has a name on it. One developer. That developer, at the moment of committing, either understood every line they were signing — or they didn't. There is no collective commit. There is no "we committed this." There is a named person who made a decision. This is why step 6 of the work loop — commit and document — is not administrative. It is the accountability step. And it only works if step 5 actually happened: the developer reviewed every line, assessed their confidence, and stopped when they didn't understand something. **High confidence:** I understand every line. I can explain why it does what it does. → Commit. **Medium confidence:** It looks right but I'm unsure about parts. → Review more. Ask the model. Ask a colleague. **Low confidence:** I don't understand why this works. → STOP. Understand before proceeding. In a team, this standard must be applied by every developer to every commit. There is no collective bypass. A code reviewer can flag issues, but they cannot transfer ownership. The developer who commits owns it. ## What "the company is accountable" actually means Contracts and SLAs assign accountability to organisations. That's correct and necessary. But organisational accountability only has operational meaning if it traces back to individual accountability. When something fails in production, "the company is responsible" is a legal statement. The operational question — "who understood this code and signed off on it" — must have a human answer. If it doesn't, you don't have accountability. You have liability without the internal structure to learn from it, fix it systematically, or prevent it from happening again. This is the distinction that matters when organisations evaluate whether their AI-assisted development practice is responsible. Not whether they have a process. Whether they have a named human who owns every line that ships. The process can be lightweight or rigorous. The tools can be old or new. The team can be large or small. But someone has to own the code. And that someone has to have read it. --- *The framework this article applies: [The Foundation — Four Pillars and the Work Loop](/foundation) · [AI Development Accountability Levels](/articles/accountability-levels) · [The work loop — six steps](/articles/ai-development-workflow-read-plan-flush-build-review) · [The 90% AI-coded myth](/articles/90-percent-ai-coded-myth)* --- ### [The AI development workflow: read, plan, flush, build, review](https://mindtastic.se/articles/ai-development-workflow-read-plan-flush-build-review) The practical workflow that separates productive AI-assisted development from wasted tokens. Read the project. Plan on disk. Flush the context. Build from the plan. Review every line. This is not a suggestion — it is the process. # The AI development workflow: read, plan, flush, build, review Most developers using AI tools in 2026 have no process. They open a session, type a prompt, get output, iterate until it looks right, and commit. Sometimes it works. Often it doesn't. When it doesn't, they blame the tool. The tool is rarely the problem. The process is. After working with development teams across multiple organizations — watching what works and what fails in production, not in demos — one workflow pattern has emerged as consistently effective. It is not complicated. It has five steps. Most teams skip at least two of them. ## The loop ``` Read project → Plan to disk → Flush context → Build from plan → Review every line ``` Each step exists for a specific reason. Skipping any one of them degrades the result. Here is what each step does and why it matters. ## Step 1: Read the project Every session starts the same way. Before generating a single line of code, the LLM reads the project. Not "reads the file you're working on." Reads the project. The architecture. The recent git history. The guidelines and conventions. The existing patterns. The domain terminology. A model that understands your system produces code that belongs in your system. A model that doesn't will produce syntactically correct code that violates your architecture, uses wrong naming conventions, and introduces patterns that conflict with everything around it. That code compiles. It passes basic tests. And it creates technical debt the moment it merges. The investment is five minutes. The return is hours of avoided wrong-direction work. If your project has rule files — `CLAUDE.md`, `AGENTS.md`, `.kilocode/rules/`, `.cursorrules` — this step is where they earn their value. The model reads them and constrains itself before producing anything. Without rule files, Step 1 is best-effort guessing. With them, it is informed generation. ## Step 2: Plan to disk Before implementation, ask the model to produce a plan. Not in the conversation — on disk. A change request document. A design proposal. A specification. Whatever format fits your project. The point is that the plan becomes a file, committed or at least saved, that exists independently of the conversation. Why on disk? Because the plan needs to survive the next step. This maps to what experienced developers have always done: think before coding. The difference with AI tools is that the thinking can be externalized — written as a document that both you and the model can reference. A plan in the conversation is volatile. A plan on disk is durable. Review the plan before proceeding. This is the cheapest place to catch a wrong direction. Changing a plan costs minutes. Changing an implementation costs hours. ## Step 3: Flush the context This is the step nobody does. It is the one that changes everything. After the plan is written to disk, clear the conversation. Start a new session. Or, if the tool supports it, explicitly reset the context window. Why? Because the context window during planning is filled with exploration, questions, alternatives, dead ends, and decision-making artifacts. That context is valuable for planning. It is noise for implementation. When you start the implementation phase with a clean context and load only the plan document plus the relevant code, the model works from a clear specification — not from a muddled conversation history that includes every wrong turn from the planning phase. The plan document is the bridge between the two phases. It carries the decisions forward. The conversation noise stays behind. This is not a theoretical optimization. Teams that flush context between planning and implementation report fewer off-target implementations, less "the model went in a different direction than we discussed," and shorter review cycles. The plan on disk is unambiguous. The conversation in memory is not. ## Step 4: Build from the plan Load the plan. Load the relevant code. Implement. This phase is where most tutorials start — and why most tutorials produce mediocre results. Implementation without Steps 1-3 is generating code in a vacuum. Implementation after Steps 1-3 is building within understood constraints from a reviewed specification. The model should follow the approved plan. If something unexpected surfaces during implementation — a dependency that wasn't considered, an edge case that the plan missed — stop. Don't improvise. Update the plan first, then continue. The plan is the contract between you and the tool. Deviating from it without recording the deviation is how "the model did something weird" happens. ## Step 5: Review every line Read every diff. Every file. Every change. This is not a suggestion. This is where professional responsibility manifests. The moment you read a diff and decide "this is correct" is the moment accountability happens. Automate that away — auto-commits, auto-changelogs, automated test loops that approve without human review — and you automate away the only thing that makes your name on the code mean something. Update the changelog manually. Not because it takes long. Because the two minutes it takes to write what changed forces you to understand what changed. An auto-generated changelog is a summary of something nobody reviewed. It looks professional. It is meaningless. Run whatever verification makes sense: tests, type checks, linting. But verification is not review. Verification confirms that code runs. Review confirms that code should exist. ## Why this order matters The five steps are not interchangeable. They form a dependency chain: **Read** enables informed planning (without it, the plan ignores the existing system). **Plan** externalizes decisions (without it, decisions live only in conversation memory). **Flush** separates planning noise from implementation clarity (without it, the model hallucinates from stale context). **Build** executes within constraints (without the prior steps, it executes in a vacuum). **Review** closes the accountability loop (without it, the output is unowned). Skip Read and you get code that doesn't fit the system. Skip Plan and you get code that solves the wrong problem. Skip Flush and you get code that drifts from the plan. Skip Build-from-plan and you get improvised code. Skip Review and you get unowned code. Most teams skip Flush and Review. Those are the two steps that matter most. ## The voice input advantage One practical enhancement that compounds the workflow: use voice input for planning. When you speak a prompt instead of typing it, you express more context. Associations, nuances, conditions, edge cases — they flow naturally in speech but get compressed away in typing. A spoken description of what needs to change carries information density that a typed prompt rarely matches. This applies specifically to Steps 1 and 2 — the exploration and planning phases where breadth of context matters. For Step 4 (implementation), typed prompts with precise instructions are more effective. Match the input mode to the phase. ## What this workflow produces Teams that follow this loop consistently report: - Fewer "the model went in the wrong direction" incidents (the plan catches direction errors before implementation) - Shorter code review cycles (the implementation matches the specification because both are explicit) - Less technical debt from AI-generated code (the model works within loaded guidelines, not from generic patterns) - Higher confidence in AI-assisted output (every line is reviewed, every change is understood) None of these outcomes require a better model, a more expensive subscription, or a new tool. They require a process. Five steps. The same five steps, every time. The tool is capable. The question is whether you use it within a process that produces accountable output — or without one, hoping for the best. --- *This workflow is the practical implementation of principles covered in [Three ways to work with AI output](https://mindtastic.se/articles/vibe-coding-vs-ai-orchestration) and [Why developer accountability can't be automated](https://mindtastic.se/articles/ai-validation-imperative-developer-accountability). For the organizational layer — repo rules that constrain AI before it generates — see [From individual AI to organizational AI](https://mindtastic.se/articles/ai-rules-framework-organizational-governance).* --- ### [AI as a growth engine, not an efficiency tool](https://mindtastic.se/articles/ai-growth-engine-not-efficiency-tool) Most organizations measure AI success in hours saved. The ones gaining competitive advantage measure it in what they can now do that they couldn't before. The AI Sweden Leadership Report 2026 makes this distinction clearly — and it changes everything about how you should approach AI strategy. # AI as a growth engine, not an efficiency tool Most AI strategies start with the same question: *what can we automate?* It's a reasonable question. Automation is measurable, the ROI is calculable, and the organizational resistance is manageable — you're not changing what the organization does, just how efficiently it does it. But that framing also sets a ceiling on what you can achieve. If you start with "what can we automate," you will automate things. You will save some hours. And you will have spent significant organizational energy to deliver a fraction of what AI makes possible. The AI Sweden Leadership Report 2026, a synthesis of in-depth interviews with leading business executives in Sweden, makes this distinction explicitly: > *"AI's real value is not in doing the same things cheaper, but in doing new things altogether — reshaping products, decisions, and business models. Cost reduction is visible early; strategic advantage compounds over time."* This is the distinction that separates organizations gaining competitive advantage from those running efficiency programs. --- ## Two types of AI strategy **Efficiency-first strategy** starts with existing processes. It asks: where are we slow, where are we paying for manual work, where can a model replace a repetitive task? It delivers measurable short-term results. It is also, in most cases, a commodity play — because your competitors can run the same efficiency program. **Expansion-first strategy** starts with constraints and possibilities. It asks: what are we unable to do today that would matter if we could? What decisions are we making slowly that need to be made fast? What customer value is currently uneconomic to deliver? It delivers results that are harder to measure early — and harder for competitors to replicate. Peder Blomgren, VP Head of Data Office R&D at AstraZeneca, described it this way in the report: > *"As a leader, you do not invest in AI — you invest in achieving your objectives. We doubled our revenue between 2020 and 2025, with AI as a key enabler. Now AI is crucial to achieve our 2030 Ambition: 20 new medicines, doubled revenue, and a very ambitious sustainability agenda. AI is explicitly integrated, with clear and measurable targets."* Note what he did not say. He did not say "AI saved us X hours per year" or "AI reduced our processing costs by Y percent." He described AI as the enabler of a business objective: 20 new medicines, doubled revenue. That is a fundamentally different relationship to the technology. --- ## Why efficiency logic dominates anyway If expansion-first strategy delivers more value, why do most organizations default to efficiency-first? Three reasons: **It's easier to justify.** Traditional ROI calculations work for efficiency. The math is visible: process takes X hours, AI reduces it to Y, multiply by headcount. For expansion, the math is a bet — the upside is conditional on things that haven't happened yet. **It feels less risky.** Automating back-office processes doesn't change your business model. Expansion-first means committing to something new before you have proof it will work. **It's what technology vendors sell.** "Reduce costs by 30%" is a headline. "Expand into markets you couldn't reach" requires a business conversation the vendor usually isn't equipped to have. The report addresses this directly: > *"The first phase is almost impossible to get through because you won't have ROI or clear answers. It requires courage and leadership. At its core, this is about the intrinsic qualities of a leader — it's science and art."* > — Lotta Lyrå, CEO at Södra --- ## What this means for leadership The shift from efficiency to expansion changes the nature of the leadership question. Efficiency is a management problem: identify the process, select the tool, measure the output. It can be delegated to operations or IT. It doesn't require the CEO to understand AI — it requires someone to manage a tool deployment. Expansion is a leadership problem: it requires understanding what the organization is trying to become, which constraints are structural versus solvable, and where AI changes the economics of a decision. That cannot be delegated to IT. It requires the person responsible for the business outcome to be part of the question. This is why the report finds, consistently, that the executives who drive AI transformation are not AI enthusiasts — they are business leaders who saw AI as the means to a business objective they already had. > *"Our vision is to transform the entire business model — and AI is a key enabler in getting us there."* > — Pär Lärkeryd, CEO at Norra Skog The technology did not create the vision. The vision preceded the technology. AI became the instrument because the business objective demanded it. --- ## The question to ask before you start Before deciding which AI tools to evaluate, before building a business case, before selecting a vendor: what are you trying to achieve that you're not achieving today? Answer that concretely. Not "be more efficient" or "stay relevant" — but the specific business outcome that matters. Revenue that isn't there. Decisions that take too long. Customer value that's currently too expensive to deliver at scale. Then ask: is AI the right means to get there? Which parts of the chain need to change? What does success actually look like, and in what timeframe? That conversation is harder than selecting an AI tool. It is also the conversation that determines whether your AI investment produces efficiency gains or competitive advantage. --- ## For leaders considering Track 1 Mindtastic's Track 1 — Leadership & critical thinking — is designed for exactly this conversation. Not AI theory, not a vendor pitch, not a technical overview. A structured engagement for executives who need to make real decisions about AI in their organization: what to invest in, what to demand from their teams, what questions to ask — and what to be skeptical about. The goal is not to make executives into AI experts. It is to give them enough grounded understanding to lead the question rather than delegate it. If your organization is deciding now what AI should mean for your business, that's where to start. --- *Source: AI Sweden Leadership Report 2026 — [ai.se/sv/ai-sweden-leadership-report-2026](https://www.ai.se/sv/ai-sweden-leadership-report-2026)* *Related: [The leader who can't delegate](https://tomasandre.se/insights/ledaren-som-inte-kan-delegera) — tomasandre.se* --- ### [From individual AI to organizational AI: repo rules as the missing layer](https://mindtastic.se/articles/ai-rules-framework-organizational-governance) The tool your team uses will change. The rules in your repository won't. Organizations that encode their AI standards in repo-level rule files build lasting capability. Those that leave it to individual prompting build nothing that survives the next tool switch. # From individual AI to organizational AI: repo rules as the missing layer Every development team asks the same question in 2026: which AI coding tool should we use? It is the wrong question. ## The tool is ephemeral Roo Code — a popular VS Code extension forked from Cline, used by thousands of developers — shut down on May 15, 2026. Two weeks' notice. The team pivoted to a cloud-based product and abandoned the extension. Every developer using Roo Code had to migrate overnight. Their prompting habits, their muscle memory, their workflow — all tied to a tool that no longer exists. This is not an anomaly. It is the pattern. AI coding tools in 2026 are a fast-moving market where acquisitions, pivots, and shutdowns happen quarterly. Cursor may change its pricing model. GitHub Copilot will restructure its tiers. A new tool will emerge that makes today's favourite obsolete. If your AI capability lives inside the tool, it dies with the tool. ## What survives a tool switch One thing survived the Roo Code shutdown without modification: the rule files in the repository. Every serious AI coding tool in 2026 reads project-level configuration from files committed to git: | Tool | Rule file | Scope | |------|-----------|-------| | Claude Code | `CLAUDE.md` + `.claude/rules/` | Project + workspace + user | | Kilo Code | `.kilocode/rules/` | Project | | Cline | `.clinerules/` | Project | | Cursor | `.cursorrules` + `AGENTS.md` | Project | | Codex CLI | `AGENTS.md` | Project | | GitHub Copilot | `.github/copilot-instructions.md` | Org + repo | These files are plain text, version-controlled, and reviewed like code. They travel with the repository, not with the tool. When a developer switches from Roo Code to Kilo Code — or from Cursor to Claude Code — the rules stay. This is not a technical detail. It is the architectural insight that separates organizations with lasting AI capability from organizations with individuals who happen to use AI. ## What goes in the rules Rule files are not prompt libraries. They are not "tips for better AI output." They encode how your organization works: **Architecture standards.** "This project uses modular monolith architecture with five layers: presentation, service, repository, model, data. All new code must follow this structure." **Technology constraints.** "We use Laravel 11 with PHP 8.3. Do not suggest solutions in other frameworks. Do not introduce new dependencies without approval." **Quality requirements.** "All database queries must use the repository layer. No raw SQL in controllers. All public methods require PHPDoc." **Naming conventions.** "Database tables use snake_case plural. Models use PascalCase singular. API endpoints use kebab-case." **Domain terminology.** "A 'journey' is a scheduled route. A 'trip' is a single execution of a journey. Do not conflate these terms." These rules are not suggestions. They are constraints that prevent AI from generating code that compiles but violates your standards — the kind of code that creates technical debt invisibly. ## The evidence: 90% of the problems A CTO we work with reviewed every commit in his team's CI/CD pipeline for eight months. His finding: 90% of the problematic code was AI-generated. Not because the tools were bad. Because the developers used AI without shared standards. Each developer prompted in their own way, with their own assumptions, producing code that looked correct but violated architectural patterns, ignored layer separation, or introduced inconsistencies that only showed up at integration. The CTO had built comprehensive development guidelines — architecture standards, use case templates, layer definitions. He distributed them to the team. Almost nobody followed them. Not because the guidelines were wrong. Because there was no mechanism to enforce them at the point of code generation. The guidelines lived in a document. The code generation happened in a tool that had never read that document. Rule files solve this. When the architecture standard lives in `CLAUDE.md` or `.kilocode/rules/`, the AI reads it before generating a single line. The standard is not a document the developer should have read — it is a constraint the tool cannot ignore. ## AGENTS.md: the emerging cross-tool standard In 2026, a de facto standard is emerging: `AGENTS.md`. Multiple tools — Codex CLI, Cursor, and increasingly others — read this file for project-level instructions. The convergence makes sense. Developers switch tools. Teams use different tools for different tasks. A project might use Cursor for frontend work and Claude Code for backend refactoring. If the rules live in a tool-specific format, they must be duplicated and maintained separately. `AGENTS.md` is not yet universal, but the direction is clear: project rules will converge on a small number of formats that work across tools. Organizations that start encoding their standards now — in whatever format their current tool supports — are positioned to migrate those rules forward as the ecosystem matures. ## Individual AI vs organizational AI This is the distinction that matters: **Individual AI** is a developer using a tool with personal prompting habits. The output quality depends entirely on that person's skill, context awareness, and discipline. When they leave the team, their AI capability leaves with them. When the tool changes, their workflow breaks. **Organizational AI** is a team using tools constrained by shared rules committed to the repository. The output quality has a floor — no AI-generated code can violate the encoded standards, regardless of which developer prompted it. When someone leaves, the rules stay. When the tool changes, the rules migrate. The gap between these two states is not a training problem. It is a governance problem. And the solution is not more workshops on prompting — it is rule files in git. ## The documentation trap There is a version of this that fails. One team ran their first AI-managed project with strict documentation requirements and mandatory code reviews. Every pull request went back three or four times. Every architectural decision was formally recorded. On paper, it was the most disciplined project they had ever run. It didn't go faster. The quality was worse. Meanwhile, projects run by a different leader — verbal, goal-oriented, decisions made in conversation rather than documents — delivered on time. The difference was not documentation versus no documentation. It was what the documentation encoded. The strict process documented compliance: did you follow the steps, did you pass the gates, did the review approve? The verbal approach encoded understanding: what are we trying to achieve, what does the customer need, what does "done" look like? Rules that encode understanding create capability. Rules that enforce compliance create friction. The three files in the "Starting" section below are not about adding gates — they are about making the AI understand what your team already knows. Architecture standards, domain terminology, review criteria. Not sign-off checklists. If your repo rules read like a bureaucratic process, they will produce bureaucratic code. If they read like a senior developer explaining the system to a new colleague, they will produce code that belongs in the system. ## The governance layer nobody built Most organizations in 2026 have invested in AI tools. Licenses purchased. Accounts provisioned. Maybe a workshop or two. Some have measured adoption through token spend or usage dashboards. Almost none have built the governance layer: the rule files, reviewed and maintained like code, that encode how AI should behave in their specific context. This is the missing layer. Without it: - Every developer reinvents standards in every prompt - Architectural decisions are made by the model, not the team - Code reviews catch AI-generated violations after the fact instead of preventing them - Tool switches reset the team to zero - New hires have no encoded context to work with With it: - Standards are applied automatically at generation time - Architectural patterns are enforced before code review - Tool switches preserve organizational knowledge - New developers inherit the team's accumulated AI governance on day one - The CTO reviews rules instead of reviewing every commit ## Starting: three files, one week Building organizational AI governance does not require a transformation program. It requires three files and one week of attention: **Day 1-2: Write the architecture file.** Document your project structure, layer definitions, technology constraints, and naming conventions. Put it in whatever rule format your current tool reads. If you use Claude Code, write `CLAUDE.md`. If you use Kilo Code, create `.kilocode/rules/architecture.md`. If you use multiple tools, write `AGENTS.md`. **Day 3-4: Add domain terminology.** Define the terms that are specific to your business. AI models are trained on generic language — they will use "user" when you mean "passenger," "order" when you mean "booking," "message" when you mean "notification." A terminology file prevents this. **Day 5: Review the first week's output.** With rules in place, review the AI-generated code from the week. Where did the rules help? Where did they fail? What is missing? Update the files. This is not a one-time setup. Rule files are living documents — they evolve with every code review that reveals a gap. But the investment is small: a few hours of writing, committed to git, reviewed like any other code change. The return is organizational AI capability that persists across tool changes, team changes, and the relentless churn of the AI tooling market. ## The question to ask Stop asking "which AI tool should we use?" Every tool in 2026 is capable enough. The differences are in pricing, model access, and interface preferences — important, but not strategic. Start asking: "What rules does our repository contain?" If the answer is none, you do not have organizational AI capability. You have individuals who happen to use AI tools. The output is as inconsistent as the individuals, the knowledge as fragile as their tenure, and the capability as durable as the current tool's roadmap. The tool is the commodity. The rules are the asset. --- *Tomas Andre reflects on why the tool question is always wrong — [tomasandre.se/insights](https://tomasandre.se/insights).* --- ### [LLM, not AI: why the terminology matters for how you work](https://mindtastic.se/articles/llm-not-ai-terminology-matters) What you call the tool shapes how you use it. 'AI' implies a reasoning agent. 'LLM' tells you exactly what it is — and exactly how to get results from it. ## The word you use changes how you think Call it "AI" and you expect it to figure things out. You give it vague instructions and hope it reasons through to the right answer. You assume it catches things you missed. When it fails, you blame the prompt. Call it an LLM — a large language model — and you understand what is actually happening. You know what to put in. You know why it sometimes gives confident-sounding wrong answers. You stop treating it as a thinking partner and start treating it as an extraordinarily capable tool that does exactly what it is designed to do: predict the most probable continuation of what you gave it. That shift in understanding changes everything about how you work with it. --- ## What an LLM actually is A large language model is a text predictor. Given a sequence of tokens — words, code, data — it calculates the statistically most probable next token, then the next, then the next, until the output is complete. That is the entire mechanism. It is not reasoning in the way you reason. It is not searching a database of facts. It is not maintaining a world model that it updates as it learns. It is completing a pattern from what already exists in the context window — which is everything you gave it, plus everything it generated so far. The context window is the workspace. What is in it shapes every prediction that follows. An empty context window means the model predicts from general training data patterns alone. A context window filled with your codebase, your architecture decisions, your constraints, and your specific question means the model predicts from all of that. **This is why "context first, prompt second" is not a tip — it is the fundamental operating principle.** The model does not go and find information. It predicts from what is already there. You are responsible for making sure the right information is there. --- ## What "AI" implies that LLMs do not deliver When people say AI, they generally mean something like: a system with general intelligence that can reason about problems, update its beliefs with new information, recognize when it is wrong, and exercise judgment that transfers across domains. Large language models do not do this. They do not reason — they pattern-match at extraordinary scale and speed. They do not update — each context window is a fresh start with no memory of previous conversations. They do not recognize when they are wrong — they generate with the same syntactic confidence regardless of whether the content is accurate. Their judgment does not transfer in the way experience transfers; it is statistical correlation across training data, not understanding. This matters operationally. A system that "reasons" would know when your question is ambiguous and ask for clarification. An LLM generates a plausible-sounding answer to what it inferred your question might mean. A reasoning system would flag uncertainty. An LLM states uncertain things with the same fluency as certain things. **The single most common LLM failure mode — generating a confident, fluent, completely wrong answer — is only surprising if you expected a reasoning agent. It is entirely expected behavior from a text predictor.** --- ## Why it matters for accountability The terminology has a direct consequence for accountability. If you think you are working with "AI," it is easy to treat its output as something produced by an external intelligence — something to be delivered, evaluated, and passed on. The AI did the analysis. The AI built the feature. The AI wrote the report. If you know you are working with an LLM, you know that every output is a pattern completion based on what you put in. The quality of the output reflects the quality of the context you provided, the specificity of what you asked, and your judgment in evaluating the result. There is no external intelligence to credit or blame. There is a tool, and there is you. That is not a subtle distinction. It is the difference between "the AI got it wrong" and "I accepted output I should have reviewed more carefully." One of those is a sentence that prevents learning. The other is not. --- ## What changes when you use the right word In practice, calling it an LLM — and understanding what that means — produces three immediate changes: **You load context deliberately.** Instead of writing a detailed prompt and hoping the model figures out the rest, you ask: what does this model need in order to predict the right output? You load the relevant files, the relevant history, the relevant constraints. Then you ask. **You evaluate output as a prediction, not a decision.** The model generated the most probable continuation of what it was given. Is that probable continuation actually correct? That is your question to answer — and you can only answer it if you know enough about the subject matter to recognize a wrong answer. **You stop looking for a better prompt to fix things that context would fix.** Most "prompt engineering" problems are context problems. The model does not have what it needs to produce a useful output. Adding more information to the context window solves them. A cleverer prompt does not. --- ## The practical boundary None of this means LLMs are not remarkable. They are. The pattern completion happens at a scale and quality that was not possible five years ago, and the applications are genuine. A developer who understands what an LLM is — and uses it accordingly — can work at a multiplier that was not previously achievable. A developer who treats it as an autonomous AI agent, and ships its output without verification, gets a different result. The tool is the same. The understanding of what it is determines the outcome. --- ## Related - [The Foundation: five pillars of LLM-assisted development](/foundation) - [The context window myth: why 1 million tokens is mostly marketing](/articles/context-window-myth-exposed) - [The senior developer paradox: why experience compounds with LLM tools](/articles/senior-developer-paradox) --- ### [The production reality gap, part 1: the adoption crisis](https://mindtastic.se/articles/production-reality-gap-part1) description: Most people in organizations are not using AI effectively in their daily # The production reality gap, part 1: the adoption crisis *Part 1 of 3: Production Reality Gap Series* ## Series Overview This is Part 1 of a 3-part series exploring why most organizations struggle to move from AI experimentation to consistent, effective use. The examples are drawn from development teams — but the adoption pattern, the cultural barriers, and the competence dependency repeat identically across developers, analysts, document professionals, and leadership teams. The technology is available. The adoption gap is the same everywhere. - **Part 1: The Adoption Crisis** (this article) - Cultural and skill barriers to AI adoption - **Part 2: The Validation Problem** - Why expertise matters for AI development - **Part 3: Bridging the Gap** - Training and change management strategies ## Core Content Fragment ### The Reality Behind AI Adoption During a recent discussion about AI adoption in development teams, a striking pattern emerged. Despite AI development tools being available for over two years, most developers still aren't using them effectively in their daily work. This isn't a technology problem - it's an adoption crisis that reveals fundamental gaps in how we approach AI integration in development teams. #### The Great Divide The developer community has split into three distinct groups, each facing different challenges. There are the resistant seniors, the enthusiastic juniors, and a small group of successful adapters. The senior developers, many with years of experience, often view AI assistance with suspicion. *"De tycker att det är fusk"* (They think it's cheating), as one conversation revealed. These developers possess exactly the expertise needed to use AI effectively, but resist adoption due to psychological and cultural barriers. They see their professional identity tied to their ability to write code from scratch, and AI assistance feels like cheating against deeply held values about craftsmanship and professional worth. On the other end, junior developers embrace AI tools eagerly but lack the domain expertise to validate outputs effectively. This creates dangerous situations where incorrect code gets implemented. *"Vad gör vi med juniorerna? De är rökta. För de som inte har kunskapen att se att det här blir fel..."* (What do we do with the juniors? They're screwed. Because those who don't have the knowledge to see that this is wrong...) This harsh assessment reflects a real problem where enthusiasm without expertise leads to technical debt and security vulnerabilities. The most interesting group is the small percentage of successful adapters. *"Vi har två stycken i teamet som bedömer nu, som är juniora... Men det är för att de har en ambitionsnivå som är högre än snittet"* (We have two in the team who are evaluating now, who are junior... But it's because they have an ambition level that's higher than average.) This insight reveals that successful AI adoption isn't just about seniority—it's about learning mindset and ambition. These developers combine enthusiasm with appropriate caution, making them effective AI users regardless of their experience level. #### The Cultural Resistance The adoption crisis isn't technical—it's deeply cultural. Traditional development culture creates several barriers to AI adoption: **Effort-Based Value Systems:** Development culture historically rewards struggle, long debugging sessions, and solving problems through pure intellect. AI assistance feels like cheating against these deeply held values. **Craftsmanship Identity:** Many developers define their professional worth through their ability to write elegant, efficient code from scratch. AI-generated code threatens this core identity. **Knowledge Hoarding:** In traditional teams, being the "go-to" person for complex problems provides job security and status. AI democratizes some of this knowledge, threatening established hierarchies. **Fear of Obsolescence:** If AI can write code, what value do developers provide? This existential fear drives resistance more than any technical limitation. #### The Skill Gap Crisis The adoption statistics reveal a concerning skills gap that affects organizations at multiple levels: **Management Disconnect:** Leaders see impressive AI demos and expect immediate productivity gains, but don't understand the expertise required for effective AI adoption. **Training Inadequacy:** Most organizations provide basic AI tool introductions but skip the advanced prompt engineering and validation skills that determine success. **Process Integration:** Teams lack structured approaches for integrating AI into existing workflows, leading to ad-hoc adoption that fails under pressure. **Quality Control:** Without proper validation frameworks, AI-generated code introduces bugs and security vulnerabilities that erode trust in the technology. #### The Productivity Paradox Organizations face a frustrating paradox: the developers best equipped to use AI effectively are the least likely to adopt it, while those eager to adopt lack the skills to use it safely. **The Senior Paradox:** - Have domain expertise for validation - Understand architectural implications - Can craft sophisticated prompts - But resist adoption due to identity concerns **The Junior Trap:** - Enthusiastic about new technology - Comfortable with tool switching - Open to learning new approaches - But lack validation capabilities **The Organizational Cost:** - Productivity gains remain unrealized - Technical debt from poor AI adoption - Team fragmentation and conflict - Competitive disadvantage #### Real-World Adoption Failures The adoption crisis manifests in predictable patterns across organizations: **Pattern 1: The Prototype Plateau** Teams create impressive AI-assisted prototypes but struggle to reach production quality. The gap between demo and deployment reveals the validation expertise gap. **Pattern 2: The Quality Regression** Junior-heavy teams adopt AI enthusiastically but produce lower-quality code with security vulnerabilities and performance issues. **Pattern 3: The Resistance Stalemate** Senior-heavy teams maintain high quality but miss productivity opportunities, falling behind more agile competitors. **Pattern 4: The Tool Churn** Organizations cycle through AI tools looking for the "perfect" solution, when the real issue is adoption methodology and training. #### The Hidden Costs The adoption crisis creates significant hidden costs for organizations: **Opportunity Costs:** - Missed 4-5x productivity improvements - Delayed project delivery - Reduced competitive advantage - Lost innovation opportunities **Direct Costs:** - Failed AI tool investments - Extended development timelines - Increased technical debt - Higher recruitment costs **Cultural Costs:** - Team fragmentation and conflict - Reduced morale and engagement - Loss of top talent to AI-forward companies - Erosion of technical leadership #### The Geographic and Industry Divide The adoption crisis isn't uniform across all markets and industries: **Leading Regions:** - Silicon Valley startups: 40-50% adoption - Nordic tech companies: 35-40% adoption - European fintech: 30-35% adoption **Lagging Industries:** - Traditional enterprise: 10-15% adoption - Government/public sector: 5-10% adoption - Legacy financial services: 5-15% adoption **Cultural Factors:** - Risk tolerance affects adoption speed - Regulatory requirements slow implementation - Company age correlates with resistance #### The Competitive Implications The adoption crisis is creating a new form of competitive divide: **AI-Forward Companies:** - Faster development cycles - Lower development costs - Ability to experiment rapidly - Attraction of top talent **AI-Resistant Organizations:** - Maintaining traditional development speeds - Higher per-feature costs - Risk aversion limiting innovation - Talent flight to more progressive companies #### The Leadership Challenge Technology leaders face unprecedented challenges in managing this transition: **Strategic Decisions:** - How aggressively to push AI adoption - Whether to retrain existing teams or hire new talent - How to balance quality with speed - When to mandate vs. encourage adoption **Team Management:** - Addressing senior developer resistance - Preventing junior developer misuse - Building effective validation processes - Maintaining team cohesion during transition **Investment Allocation:** - Training vs. hiring decisions - Tool selection and standardization - Process development and documentation - Quality assurance infrastructure #### Early Warning Signs Organizations can identify adoption crisis symptoms through several indicators: **Cultural Indicators:** - Open resistance to AI tool evaluation - Dismissive attitudes toward AI capabilities - Fear-based discussions about job security - Generational conflicts within teams **Performance Indicators:** - Stagnant development productivity despite AI investment - Quality regressions after AI tool introduction - Increased debugging time and technical debt - Failed prototype-to-production transitions **Organizational Indicators:** - High turnover among AI-enthusiastic developers - Difficulty recruiting AI-experienced talent - Competitive disadvantage in delivery speed - Client complaints about development pace #### The Path Forward Addressing the adoption crisis requires acknowledging that this is fundamentally a people problem, not a technology problem. The solution lies in: 1. **Understanding the psychology** of developer resistance 2. **Building proper validation frameworks** for AI outputs 3. **Creating structured adoption programs** that address skills gaps 4. **Developing change management strategies** that honor existing expertise while embracing new capabilities The next parts of this series will explore the validation expertise gap and provide concrete strategies for bridging the adoption divide. #### Conclusion: The Urgency of Action The production reality gap isn't just about individual developer productivity - it's about organizational survival in an AI-transformed industry. Companies that successfully navigate the adoption crisis will gain sustainable competitive advantages, while those that ignore it risk obsolescence. *"Det finns ingen genväg"* (There are no shortcuts) - This applies especially to cultural change. Organizations must invest in proper training, change management, and validation frameworks to bridge the adoption gap. The crisis is real, but it's not insurmountable. The 25% who have successfully adopted AI prove that it's possible. The question is whether your organization will join them or be left behind. ## Development Notes - **Content Type**: Industry analysis / organizational challenge - **Target Audience**: Technology leaders, engineering managers, senior developers - **Key Message**: AI adoption crisis is cultural and skills-based, not technological - **Status**: Initial draft based on research insights - **Next Steps**: Add specific organizational examples from portfolio experiences ## Related Articles in Series - **Next**: Part 2 - The Validation Problem (why expertise matters for AI development) - **Also**: Part 3 - Bridging the Gap (training and change management strategies) ## Potential Portfolio Connections - **jsonflow**: Team AI adoption experiences and resistance patterns - **record-me**: Developer productivity comparisons before/after AI adoption - **tic**: Business intelligence team transformation and skill evolution - **sumtastic.app**: Content team adaptation to AI-assisted workflows - **grabb3r**: Competitive analysis of AI adoption across organizations ## Expansion Areas to Develop *When portfolio projects provide real examples:* - Specific organizational adoption case studies - Quantified productivity comparisons across teams - Change management strategies that worked/failed - Training program designs and outcomes - Cultural transformation methodologies --- *Fragment captured: 2025-08-13* *Development status: Part 1 of 3 - adoption crisis analysis established* --- ### [The strategy meeting that leaves no trace](https://mindtastic.se/articles/strategy-meeting-leaves-no-trace) Most organizations have a strategy day every year. The decisions made in that room govern the next twelve months. The documentation from that day is a deck nobody opens and notes nobody finds. That is a solvable problem. # The strategy meeting that leaves no trace Your organization has a strategy day every year. The right people are in the room — finally. Leadership, key managers, the people who actually know how things work. You talk for six hours about direction, priorities, what is working and what is not. Decisions get made. Alignment happens, or something that feels like alignment. Then everyone goes home. Three months later, someone asks what was decided at that meeting. The answers vary. Six months later, the same conversation starts again from scratch. Twelve months later, you hold another strategy day — and open by noting that last year's priorities somehow did not stick. The meeting was not the problem. The meeting was fine. The problem is that nothing from the meeting survived. --- ## The gap between conversation and decision Organizations are good at having important conversations. They are poor at capturing what was actually said in them. The notes from a strategy day are almost always the same: a few bullet points in someone's notebook, a slide deck with the themes that were discussed, and a set of action items that made sense in the room but lost their context by the time they reached an email. What disappears is not the conclusion. What disappears is the reasoning behind the conclusion — the tension that was surfaced, the trade-off that was made, the assumption everyone agreed on but nobody wrote down. That reasoning is what people need six months later when the situation has changed and they have to decide whether the original decision still holds. Meetings where important decisions get made are exactly the meetings least likely to have adequate documentation. --- ## What a strategy day actually contains A strategy day is a dense information event. In six to eight hours, a room of experienced people externalizes knowledge that has never been written down anywhere: - How work actually flows — not how the org chart says it should - Where decisions stall and why - Which processes depend on one person who happens to know something - What everyone privately thinks is broken but nobody has raised formally - What the real constraints are, as opposed to the stated ones That information exists nowhere else. It lives in the heads of the people in that room. A well-run strategy day is one of the few moments when it gets spoken aloud in the same place at the same time. It then disappears. --- ## The simplest intervention Recording the conversation and processing it systematically is not a new idea. What is new is the quality of the output that AI-assisted processing now makes possible — within hours, not weeks. A facilitated strategy day with structured AI-processing delivers the same day: - A process map of how work actually flows, based on what participants described - A systems diagnosis — where information lives, where it gets lost, where manual steps create errors - A responsibility map — who owns what, where gaps exist, where the organization depends on one person knowing something - Three to five prioritized next steps, each with a clear owner That is not a summary of what was said. That is a structured artifact built from what was said — specific to this organization, not a template with the company name inserted. The meeting still happens. The same people are still in the room. The difference is that the meeting leaves a trace. --- ## When it is the right intervention A strategy day with structured facilitation and documentation is the right format when: - **The right people are already assembled** — a leadership offsite, a quarterly planning session, a team day. The cost of bringing people together is paid regardless. The documentation is the add-on. - **Something is not working but nobody can name it precisely** — a facilitated day surfaces the actual problem, not the presented version of it. Most organizations are better at describing symptoms than diagnosing causes. - **A major decision is approaching** — an investment, a restructuring, a new direction. The reasoning that goes into the decision matters as much as the decision itself. Capturing it while it is being formed is significantly cheaper than reconstructing it later. - **The previous strategy day produced nothing durable** — the problem is not that the team cannot think strategically. The problem is that nothing was built to make the outcome last. --- ## What it is not It is not a consulting project. There is no follow-on work implied, no relationship that gets sold into, no dependency created. It is not a workshop in the training sense. Nobody is being taught anything. The value is not new knowledge brought in from outside — it is existing knowledge made visible and structured. It is not a survey or an assessment tool. Those generate data about averages and patterns. This generates analysis of one specific organization based on what the people in that room actually said. One day. One structured artifact. Delivered before everyone leaves. --- ## The lowest-risk entry point For organizations that are not sure where to start with AI-assisted work, a strategy day with facilitated documentation is the lowest-risk format available. It does not require an AI budget. It does not require anyone to learn a new tool. It does not require a defined problem — in fact, it works best when the problem has not been precisely defined yet. The organization gets a structured artifact from a conversation it was going to have anyway. The investment is a day and a facilitation fee. The output is clarity — about where things actually stand, what the real priorities are, and what needs to happen next. Whether that leads to a training program, an internal AI initiative, or simply better-documented meetings going forward — that is a decision for after the day, not before it. The only prerequisite is being willing to have the conversation on record. --- ## Related reading - [Voice to structured meeting documentation](/articles/voice-to-structured-meeting-documentation) — how recording a conversation becomes a structured artifact within hours - [Why your organization needs to learn to ramble](/articles/varfor-din-organisation-behover-lara-sig-svamla) — on the organizational knowledge that never gets captured in the first place - [Domain knowledge multiplies AI output](/articles/domain-knowledge-multiplies-ai-output) — why the expertise in that room is the actual multiplier --- *Genomlysning — Mindtastic's format for facilitated strategy sessions with same-day structured output. One day, 2–6 participants, NDA as standard. For organizations that know something needs to change but have not been able to name exactly what. [Contact us](/contact) to discuss whether it fits your situation.* --- ### [Why we don't call it AI training](https://mindtastic.se/articles/why-we-dont-call-it-ai-training) Calling it an AI course sets the wrong expectation from the start. The gap most organizations have is not access to tools — it is knowing how to work differently. Those are not the same problem, and they do not have the same solution. # Why we don't call it AI training When someone searches for AI training, they are looking for one of three things: how to use a specific tool, how to write better prompts, or a general overview of what AI can do. All three are legitimate. None of them are what we do. We work on how people work. How a team structures information, builds on each other's thinking, and produces results that hold up. AI is part of the method. It is not the product. The distinction matters because if you buy AI training expecting tool instruction, you will be disappointed by what we deliver — and you will not use what you learned. Getting the category right is not a marketing problem. It is a prerequisite for the training to work. --- ## What the tools actually cost you ChatGPT is free to try. Copilot is included in most Office licenses. Claude costs less than a coffee per day at personal usage volumes. If your team does not have access to capable AI tools, that is a purchasing decision you can make this afternoon. Access is not the problem. The problem is that having a tool and knowing how to work with it consistently are fundamentally different things. Your team has had access to search engines for twenty-five years. That did not automatically make everyone good at research. Tools do not change behavior. Structure does. Practice does. A shared way of working does. --- ## The three things we compete against Most organizations that approach us have already considered their options: **Hype workshops.** Two hours, certificates, enthusiasm. Everyone leaves having seen a demo. A week later, nothing has changed. These are easy to sell and cheap to run — and they produce the low expectations that make our job harder. **Tool training.** How to use Copilot. How to prompt Claude. How to connect APIs. Technically accurate, immediately applicable, and misses the point entirely. You learn the keystrokes. You do not learn how to think about your work differently. **Doing nothing.** The most common choice. Not a decision — an absence of one. People in the team are already experimenting with AI individually, producing inconsistent results, and nobody has made it a shared practice. The gap grows. We are none of these. What we do is closer to how a new operating procedure gets introduced in a high-stakes environment: with structure, with practice on real work, and with someone who will tell you when you are doing it wrong. --- ## What actually changes A participant who has been through a Mindtastic program works differently afterward. Not because they have a new tool — because they see their work process differently. They record meetings because they understand that conversations are data. They structure their output before they write it, because they know what AI needs to produce something useful. They validate what AI gives them, because they know where it generalizes instead of answers precisely. These are behavioral changes. They do not come from watching a demo. They come from doing the work, getting feedback, and building a habit. That is what we train. It is slower to sell than a two-hour workshop with a certificate at the end. It is also the only kind that produces a result you can point to three months later. --- ## Why the name matters If we called it AI training, we would attract the people looking for tool instruction. We would spend the first hour of every session correcting their expectations. We would be measured against the wrong benchmark. We do not call it AI training because AI is not what we are selling. We are selling the change in how your team works — with AI as the instrument that makes the change visible, immediate, and measurable. The tools are already there. The question is whether your organization is going to use them systematically or accidentally. That is a training problem. It just happens to involve AI. --- ### [Domain knowledge multiplies AI output — why the same tool gives dramatically different results](https://mindtastic.se/articles/domain-knowledge-multiplies-ai-output) Two groups. Same AI tool. Same data. One produced output with full compliance requirements met. One did not. The difference was what each group knew about their users — and whether they included that knowledge in their prompt. Domain expertise determines AI output quality more than any prompting technique. # Domain knowledge multiplies AI output — why the same tool gives dramatically different results ## The experiment that made this visible Seventeen developers, one task: visualize sick leave data from a CSV file using AI tools, your choice of stack, 90 minutes. Same data. Same tools available. Same general instructions. This observation was made with developers, but the pattern it reveals holds across every professional context where domain expertise meets AI tools — analysts, consultants, document professionals, anyone working with AI on problems that have real-world constraints. One group produced a visualization with full WCAG accessibility compliance — Wave and Lighthouse tested, zero errors. Another group produced a visualization with no accessibility consideration at all. Both groups used Python and Flask. Both got working output. The difference: the first group included accessibility and public sector compliance in their context. They mentioned, early in their first prompt, that their product is used in public sector environments where accessibility is a requirement. The second group described the data and the visualization goal, but did not mention accessibility. AI did not ask. AI cannot ask about requirements it does not know exist. The first group's domain expertise shaped their initial prompt. The second group's initial prompt described the task at face value. Same tool. Dramatically different output. Domain knowledge was the variable. --- ## The season pattern that appeared unbidden A separate group — design and UX background — started their session differently. Before writing any code, they had the AI analyze the CSV data to understand its structure. They described their context: their organization builds systems for occupational health and safety, their users track sick leave trends, their stakeholders care about organizational patterns. AI recommended visualizing seasonal patterns in the sick leave data. No other group received this recommendation. No other group asked for it. It was not in the task description. The group had described their business context — what the data means, who uses it, what decisions it informs. AI used that context to recommend a visualization approach that would be more valuable to the actual users of the system. Without the context, AI optimized for the task as stated: visualize the data. With the context, AI optimized for the goal behind the task: give users useful insight. This is not magic. This is the context window working correctly. The information you provide determines the optimization target. --- ## Why this is not about prompt engineering The framing of "domain knowledge matters" is often translated into "better prompts matter" — and then into "learn prompt engineering techniques." That framing misses the point. Prompt engineering techniques — chain of thought, few-shot examples, structured output formatting — are useful. But they are techniques for extracting better behavior from a model given a task. They do not change what task you are giving. The accessibility example is not about prompt structure. It is about knowing that accessibility is a requirement in the first place. A developer who does not know that public sector interfaces require WCAG compliance cannot prompt for it, no matter how sophisticated their prompting technique. They do not know the requirement exists. Domain knowledge is the information that shapes what you ask for. Prompting technique shapes how you ask for it. The first is more important than the second. --- ## The senior developer advantage, made concrete There is a common anxiety in development teams adopting AI tools: that junior developers with AI assistance will catch up to senior developers, erasing the value of accumulated experience. The accessibility and season-pattern observations point in a different direction. Senior developers carry domain knowledge that shapes every prompt they write — not because they explicitly reason about what to include, but because their mental model of the problem space naturally encompasses requirements, constraints, and edge cases that junior developers have not yet encountered. When a senior developer describes a task to an AI tool, they include this context implicitly. "Build a form that handles this workflow" from a senior developer includes assumptions about error handling, accessibility, edge cases in the data, compliance requirements — even when none of those words appear in the prompt. The same prompt from a junior developer is more likely to be a literal description of the visible task. The output will reflect what was asked, not what was needed. The AI does not fill in what is missing. It optimizes for what it was given. Domain expertise is the source of the specifications that shape that optimization. --- ## The 38-step rule One observation from the session: AI did not change the number of validation steps that a process requires. If your manual process has 38 validation steps — checking data quality, verifying edge cases, confirming outputs against known-good values — those 38 steps are still 38 steps with AI assistance. What changed: who writes the code that implements those steps. AI can write that code faster than a human. But knowing that 38 steps are required, knowing what those steps are, knowing which failures in each step indicate real problems versus acceptable variance — that knowledge has to come from somewhere. It comes from domain expertise. The process does not change. The coder changes. The domain expert who knows the process becomes more productive, not less necessary. A developer without domain expertise using AI tools will produce code that is missing steps they did not know were required. Discovery happens in production. This is the scenario that produces the "AI-generated code is unreliable" conclusion — and the conclusion is wrong. The process is unreliable. The domain knowledge was missing from the context. AI did what it was asked. --- ## Practical implication: treat context as investment, not overhead Before any significant AI-assisted work session, spend time building the context that shapes the output: **Domain requirements:** What constraints apply that are not visible in the task description? Compliance requirements, performance budgets, user population characteristics, integration constraints. **Business context:** What decision does this feature support? What does success look like for the user, not just for the output? What would make this more valuable than technically correct? **Historical context:** What has been tried before and why did it not work? What edge cases does the existing process handle in non-obvious ways? This is not overhead. This is the work that determines whether AI assistance produces good output or generic output. The time spent building context is almost always recovered in the first generation — because the output requires fewer revision cycles. The professionals who report the highest productivity gains from AI tools are, consistently, those who invest in context. The professionals who report frustration with AI output quality are, consistently, those who describe the task literally and expect AI to infer the requirements they did not state. --- ### [AI stops at the PR — and that's the rule](https://mindtastic.se/articles/ai-stops-at-the-pr) AI gives you freedom before the pull request. From the PR boundary onwards, your quality gates must be unchanged. One simple rule that resolves the autonomy debate. # AI stops at the PR — and that's the rule Teams arguing about how much to trust AI in their development process are usually asking the wrong question. The question isn't how much — it's until when. One boundary resolves most of the debate: the Pull Request (PR) — the point where your code moves from your machine into your team's shared review process. ## Two failure modes I keep seeing The first failure mode is excessive caution. Teams that distrust AI refuse to use it anywhere near their codebase. They miss the productivity gains that come from freely experimenting, drafting, and iterating before anything is committed. The tool sits unused or underused because nobody agreed on when it was acceptable. The second failure mode is excessive trust. Teams that over-rely on AI let it run through the entire pipeline — generating code, skipping review, pushing to staging, deploying to production — with humans acting as rubber stamps at best. This isn't AI-assisted development. It's abdication. Both failures come from the same source: no clear boundary. ## What the PR actually represents A Pull Request is the moment your code leaves your machine and enters your team's shared process. It's where individual work becomes collective responsibility. Code review, automated tests, staging environments, compliance checks — these are the gates your organization decided matter. They weren't built for AI. They were built because shipping broken code has consequences. That doesn't change when AI writes the code. If anything, it matters more. AI produces output confidently regardless of correctness. Your quality gates are the last line of verification that what gets merged is actually what was intended. ## Before the PR: full freedom Up to the moment you open the PR, use AI however you want. Generate first drafts. Explore three different implementations of the same function and pick the best one. Dictate your requirements out loud and let AI write the spec. Iterate on architecture decisions by asking AI to challenge your assumptions. Have it write boilerplate you'd otherwise spend an hour on. All of that is before the gate. None of it bypasses anything. The only condition is the one that always applied: you understand what you're committing. Not every token the AI produced — but the intent, the structure, the potential failure modes. That's not AI's job. It never was. ## After the PR: gates unchanged From the moment you open the PR, your existing process takes over. Unchanged. Code review happens because a colleague's eye catches things that automated tools miss and that you're too close to see. Automated tests run because regressions need to be caught before they reach users. Staging environments exist because production behavior is never perfectly simulated locally. Compliance checks exist because your organization is accountable for what it ships. AI doesn't get to skip any of that. Not because AI is untrustworthy — but because those gates aren't checkpoints for distrust. They're checkpoints for quality. The mistake is thinking that faster AI generation means the downstream process should speed up too. It doesn't. If AI helps you arrive at the PR with better code, faster — the PR is still the PR. ## Why this rule works in practice It's specific enough to follow. Teams can answer any "should we use AI here?" question by asking: are we before or after the PR boundary? If before — go ahead. If after — the existing process applies. It doesn't require a new policy document, a new tool, or a new governance layer. It uses the boundary your team already has. It scales. A solo developer working on a personal project has different gates than a team shipping regulated software. The rule is the same in both cases — it just maps to whatever process you actually have. And it creates the right accountability structure. Whoever opens the PR owns what's in it. They used AI, they reviewed it, they decided it was ready for the team's process. That's not different from writing the code themselves. The ownership is identical. ## The trap: using AI to shortcut the gate itself One pattern to watch for: using AI to generate the code review, write the test results, or draft the approval comment. That isn't AI-assisted development before the PR. That's using AI to simulate the gate rather than pass through it. The gates exist to catch things humans miss — including the person who wrote the code. Asking AI to perform the review on the code AI generated closes a loop that was deliberately kept open. The rule only works if the gate is real. --- The PR boundary isn't a constraint on AI use. It's a clear line that makes more AI use possible — because developers know exactly where their autonomy ends and their accountability begins. That's not a limitation. It's the design. --- ### [Why your organisation needs to learn to svamla](https://mindtastic.se/articles/varfor-din-organisation-behover-lara-sig-svamla) Most AI tools assume you already know what you want. Voice-first inverts this — and teaching organisations to calibrate between unstructured and precise input is the skill that changes outcomes. # Why your organisation needs to learn to svamla Most AI tools are built on a hidden assumption: that you already know what you want before you start. You type a prompt. You describe a task. You specify an outcome. The tool delivers. This assumption shapes everything — the interface, the workflow, the training. And it has made a particular kind of professional systematically worse at using AI: the expert who thinks in speech, not writing. Voice-first AI inverts the assumption. It starts with what you already do — describe, reflect, reason out loud — and lets the structure emerge from that. But inverting the assumption isn't enough on its own. The missing piece is teaching people to calibrate *which mode they're in* when they produce input. That calibration is a learnable skill. It's also, in our experience, the skill that separates organisations that get sustained value from AI from those that remain stuck in demos. ## Two input modes — not one There is a distinction that almost no AI training makes explicit, but that every effective AI practitioner develops intuitively. The first mode is what we call *kladdigt* — messy, unstructured, free. You have no strict goal. You describe what you're trying to understand, what you've seen, what confuses you. You let the AI interpret. You welcome semantic inference, contextual assumptions, follow-up questions. This is the mode for exploration, for capturing domain knowledge before you know how to formalise it, for working through a problem you don't fully understand yet. The second mode is *krispigt* or *knisprigt* — crisp, precise, targeted. You know exactly what you want. "Add this field." "Remove this section." "Split this view by team." No interpretation requested. The AI applies your instruction precisely, and any deviation is an error, not a feature. *Knisprigt* — a word coined mid-sentence by a practitioner trying to describe the moment when messy input suddenly has form — captures the transition between the two. It's not a final state. It's the moment when you shift gear. The problem most organisations have is not that they lack AI tools. It's that their people default to one mode and apply it everywhere. Professionals who are comfortable with structure give crisp instructions when they should be exploring — and get output that is precisely wrong. Professionals who prefer conversation give messy input when they need a specific change — and blame the tool for not understanding them. Teaching the calibration is the training intervention. Not prompting tips. Not tool tutorials. The actual skill of knowing which mode you're in and choosing deliberately. ## Why text-first is backwards Knowledge workers think in speech, not writing. The expert who has spent twenty years understanding a domain will, when asked to describe their problem, produce a spoken explanation that is richer, faster, and more contextually accurate than anything they would write in a prompt or requirements document. The gap between the spoken version and the written version is not trivial. In writing, professionals edit before they commit. They remove the detours, the hedges, the half-articulated nuances that represent the actual complexity of the situation. They produce something that looks clean but misses what was most relevant. Voice captures the original. The tangent that started as an aside and turned out to contain the real requirement. The phrase "it needs to be fast" said with stress on *fast* — which communicates a priority that the written phrase would flatten entirely. The pause before answering a question, which is itself information. A text-first workflow forces professionals to filter before the AI ever sees the input. Voice-first lets the AI work with raw material. The filtration happens after extraction, directed by a human who understands the domain. This is not a workflow preference. It's an accuracy difference. ## Semantic interpretation versus BI tools The standard argument against unstructured input is the data quality problem. BI tools require clean data. Before you can visualise anything, data must be washed, structured, and validated. That project can take months, and by the time it's complete the requirements have shifted. AI semantic interpretation removes this blocker. It doesn't require that data be structured to a predetermined schema. It interprets what exists. "This field seems to describe issue type, even though it's labelled differently across projects." "These three statuses all appear to mean 'waiting for someone else'." The interpretations are presented for validation — a domain expert confirms or corrects — and the context is built iteratively. The shift this enables is not just speed. It's a change in what questions you can ask. With BI tools, you can only visualise what your data structure was designed to expose. With semantic interpretation, you can ask questions about patterns that your data structure never anticipated — because the AI is reading for meaning, not for schema compliance. One practitioner described the traditional approach as "an eternal journey to clean data" — the infrastructure project before the infrastructure project. Semantic AI input eliminates the precondition. ## Human-in-the-loop is not a feature There is a version of the voice-first argument that ends with "and then AI does everything." That version is wrong, and organisations that believe it will produce confident errors at scale. Human-in-the-loop is not a feature you add when things go wrong. It is the professional standard for working with AI-generated output. Every semantic interpretation presented to a domain expert for validation, every summary reviewed before being forwarded, every output assessed before it drives a decision — this is not overhead. It is the work. AI does not make decisions. It produces output. The distinction is not semantic. When an AI analysis identifies that a particular status transition pattern correlates with project delays, it has found a pattern. Whether that pattern is causal, coincidental, or an artefact of data quality — that is a human judgement, informed by domain knowledge the AI does not have. Organisations that treat AI output as decisions will eventually produce expensive mistakes. Organisations that treat AI output as material for human judgement get compounding value: each iteration improves the analysis, each validation builds a more accurate semantic context, each decision is owned by someone who understands what they decided. The bottleneck is not AI capability. It is the quality of human judgement applied to AI output. That is a training problem. ## The honest section on confirmation bias Voice-first AI, if used uncritically, can confirm what you already believe more efficiently than any previous tool. When you describe a problem in kladdigt mode and AI returns a structured interpretation, that interpretation will tend to match the shape of your description. If your description was shaped by an existing belief about where the problem lies, the AI output will appear to validate that belief. It looks like insight. It may be projection. This is not a flaw in the approach. It is a structural risk in all analysis, which voice-first AI accelerates. The mitigation is not to stop using unstructured input — it is to build explicit validation steps and to cultivate the habit of asking: is this what the data shows, or is this what I was already expecting? A specific discipline that helps: when reviewing AI output, generate at least one alternative interpretation before accepting the first one. If the data shows that work gets stuck in review, ask whether it might instead show that certain types of work are misclassified as stuck when they are actually in a legitimate holding pattern. If you can't generate an alternative, you haven't looked hard enough. Confirmation bias doesn't disappear because the analysis was AI-assisted. It intensifies, because the output is presented with structural confidence. ## The organisational resistance signal There is a pattern we see in every organisation that attempts data-first AI work. Someone looks at an early analysis and says: "Det där datat stämmer inte." The data isn't right. It doesn't match what we know. This reaction is almost never about the data. It is about the gap between what the data shows and what was previously believed. The data may be entirely accurate. The belief may be wrong. Or the data may be revealing a pattern that is true but uncomfortable — a bottleneck where a senior person works, a delay that implicates a specific process, an insight that requires acknowledging a prior decision was mistaken. "Det där datat stämmer inte" is a signal to investigate, not to dismiss. The investigation — asking which specific records appear incorrect and what correct would look like — is often where the most valuable work happens. It is the moment where domain knowledge meets data analysis, and where the semantic interpretations of AI get refined by the people who understand what the numbers actually represent. Treating this resistance as obstruction misses what it contains. It contains the implicit model that people use to understand their work. Making that model explicit is the point of the whole exercise. ## Svamla and knisprigt as a learnable discipline Svamla — to ramble, to speak freely without a fixed destination — is not an absence of skill. It is a skill that most professional environments have systematically trained out of people. The knowledge worker who has spent a career in meetings knows that precision is valued and rambling is not. They have learned to front-load conclusions, compress reasoning, and omit the detours. These are useful skills in many contexts. In kladdigt AI input, they are liabilities. The compressed, pre-filtered version of a problem gives the AI less to work with, not more. Teaching people to svamla productively — to describe freely with the understanding that richness of input produces richness of output — is a retraining, not a tool tutorial. It requires permission to be imprecise, and confidence that imprecision at the input stage does not produce imprecision at the output stage. It produces the opposite. The paired skill — knisprigt precision when you know what you want — is equally important. Moving from free description to surgical instruction is the transition that makes iterations fast and changes targeted. Without it, every conversation with AI becomes exploratory, and nothing crystallises. The dual-mode discipline is what changes outcomes. Not the tools. Not the prompts. The calibrated choice, for each input, of which mode serves the moment. --- *Related: [Voice to structured meeting documentation](/articles/voice-to-structured-meeting-documentation) and [Voice reflection to structured goals](/articles/voice-reflection-to-structured-goals). See also: [Vibe coding vs AI orchestration](/articles/vibe-coding-vs-ai-orchestration) for the human-in-the-loop principle applied to code.* --- ### [The 90% AI-coded myth — what 'built with AI' actually means for production](https://mindtastic.se/articles/90-percent-ai-coded-myth) When companies proudly claim '90-95% AI-coded,' what does that actually mean for maintainability, security, and ownership? The gap between 'AI wrote it' and 'someone owns it' is where production systems live or die. # The 90% AI-coded myth — what 'built with AI' actually means for production A growing number of companies proudly announce that their products are "90-95% coded with AI." This is presented as a badge of honor — proof of innovation, efficiency, and forward thinking. Conference speakers cite these numbers to gasps of admiration. Investors hear them as signals of lean operations. But in production environments, this claim raises a different set of questions. Not "how impressive" but "how sustainable." Not "how fast" but "who owns this when it breaks." ## The claim sounds impressive The appeal is obvious. If AI wrote 90% of the code, development was faster. Fewer developers were needed. The product reached market sooner. For audiences unfamiliar with production software, these numbers suggest a revolution in efficiency. And for certain contexts — prototypes, proof-of-concepts, internal tools with limited lifespans — a high AI-generation ratio can be entirely appropriate. The problems emerge when the same numbers are celebrated for production systems that handle real users, real data, and real consequences. ## The questions nobody asks When someone claims 90-95% AI-generated code, the follow-up questions matter more than the headline: **Who reviewed it?** Every line of AI-generated code requires the same scrutiny as human-written code — often more, because AI-generated code can contain subtle errors that look syntactically correct but are logically wrong. **Who understands it?** Understanding code means being able to explain what it does, why it does it that way, and what happens when it fails. If the person who prompted the AI cannot answer these questions, the code is an orphan. **Who debugs it at 3am?** Production systems fail. When they do, someone must diagnose the problem under pressure, in an unfamiliar codebase, with users waiting. AI-generated code that nobody fully understands becomes exponentially harder to debug. **Who maintains it in six months?** Requirements change. Dependencies update. Security patches need applying. Maintenance requires understanding, and understanding requires someone who has read, reviewed, and internalized the code. *"Du äger varje rad output. Och du kan inte äga det du inte förstår."* ## The compound interest of ignorance The problem with high AI-generation ratios is not immediate. Week one looks fine. The code works. Features ship. Metrics look good. The damage compounds over time, following a predictable trajectory that organizations rarely anticipate. **Week 1-2: The honeymoon.** Features ship rapidly. Stakeholders are impressed. The team feels productive. Everything works because nothing has been tested by real-world conditions yet. **Week 4-6: The first cracks.** A production bug appears. The developer who prompted the AI cannot explain the affected module. Debugging takes three days instead of three hours because nobody understands the code's internal logic. The fix introduces a new bug because the developer modified code without understanding its dependencies. **Week 8-10: The cascade.** Multiple team members have generated code that interacts in ways nobody planned. Integration points fail. Error handling is inconsistent because each AI-generated module handled errors differently. The codebase has grown beyond anyone's comprehension. **Week 12+: The reckoning.** A critical failure occurs. The team cannot fix it without essentially rewriting the affected components. Management asks how this happened when the AI-generated code "worked perfectly" just weeks ago. The answer: it always had these problems, but nobody understood the code well enough to see them. This pattern is not theoretical. It plays out in organizations that treat AI code generation as a replacement for understanding rather than a complement to it. ## The ownership test A practical way to evaluate whether "90% AI-coded" is a strength or a liability: the code ownership audit. For any critical module in the system, find the developer responsible and ask: 1. **Can you explain the architecture of this module without looking at the code?** 2. **Can you identify the three most likely failure points?** 3. **Could you rewrite the core logic from memory if the code were deleted?** 4. **Can you explain every dependency and why it was chosen?** 5. **Could you onboard a new hire to this module in under an hour?** If the answer to most of these is no, the code is not owned — it is rented. And rented code has a way of evicting its tenants at the worst possible time. ## What "AI-assisted" should actually mean The problem is not with AI writing code. The problem is with the ratio being celebrated without context. A more honest framework acknowledges that AI assistance exists on a spectrum, and the appropriate level depends on what is being built. **Structured balance (50-70% AI-assisted):** The developer defines architecture, sets constraints, and reviews every significant output. AI handles implementation details within a framework the developer understands and controls. This is how most production work should operate — AI accelerates execution while the developer maintains ownership. **Vibe coding (high AI generation):** Valid for throwaway prototypes, internal experiments, and proof-of-concepts where the cost of failure is low and the code has a defined short lifespan. Not valid for production systems. **Hardcore planning (lower AI generation):** Complex systems, security-critical components, and unfamiliar territories where every line requires deliberate thought. AI assists with specific implementation tasks but the human drives the design. The teams that work effectively with AI don't celebrate high generation ratios. They celebrate understanding ratios — the percentage of their codebase that the team can explain, debug, and maintain without the AI that generated it. ## The organizational responsibility When organizations encourage or incentivize high AI-generation ratios without corresponding investment in review processes, they are building on a foundation that erodes over time. The short-term gains are real. The long-term costs are also real — and they compound. Production-first thinking demands a different metric than "how much did AI write." The relevant questions are: how much of the codebase does the team understand? How quickly can they respond to failures? How confidently can they make changes without introducing regressions? *"AI föreslår. Jag bestämmer. Jag pushar. Ordningen är oförhandlingsbar."* ## A practical framework: the code ownership audit For organizations that want to move beyond the vanity metric of AI-generation ratio, a quarterly code ownership audit provides a more honest assessment: 1. **Select critical modules** — identify the 20% of the codebase that handles 80% of the risk (authentication, payment processing, data handling, core business logic) 2. **Assign ownership** — each critical module has a named developer who is responsible for understanding it completely 3. **Test understanding** — the owner explains the module to a peer without referencing the code, including failure modes and dependencies 4. **Document gaps** — where understanding is insufficient, schedule dedicated review time — not more AI generation, but human comprehension 5. **Track over time** — monitor whether ownership is strengthening or degrading as the codebase evolves This audit does not slow development. It ensures that the development being done is sustainable. ## The bottom line "90% AI-coded" is not inherently good or bad. It is a ratio that requires context. For a weekend prototype, it might be fine. For a production system handling customer data, it is a question that demands follow-up: who owns this code? The companies that will thrive with AI are not those that maximize their generation ratios. They are the ones that maximize their understanding ratios — using AI to accelerate work they comprehend and control, not to produce output they cannot maintain. The real measure of AI maturity is not how much code AI wrote. It is how much of that code the team can stand behind. --- ### [The senior developer trap: When 'AI babysitting' reveals organizational failure](https://mindtastic.se/articles/senior-developer-trap-ai-babysitting) When senior developers spend their days cleaning up AI-generated chaos, the problem isn't the AI — it's the organization choosing the wrong paradigm. An analysis of what actually goes wrong when vibe coding enters production pipelines. # The senior developer trap: When 'AI babysitting' reveals organizational failure TechCrunch recently claimed "vibe coding has turned senior devs into AI babysitters, but they say it's worth it." This dangerous narrative fundamentally misunderstands AI development. When senior developers spend days fixing AI-generated messes, it's not because AI requires it - it's because organizations chose the wrong development paradigm. ## The symptom masquerading as solution Senior developers report spending most time checking faulty AI code, closing security gaps, and rebuilding AI-generated outputs. TechCrunch frames this as normal, even "worth it" for productivity gains. This misunderstands reality. When seniors become full-time fixers, organizations aren't implementing AI development - they're implementing broken processes. Andrej Karpathy coined "vibe coding" for accepting AI suggestions without review, explicitly for throwaway projects only. Yet organizations allow this in production pipelines, then wonder why seniors spend all time on cleanup. The problem isn't AI - it's absent methodology. ## Wrong context Senior developers trapped in babysitting roles are victims of organizational immaturity. They're janitors cleaning after uncontrolled AI experimentation, not orchestrators of AI-powered development. Junior developers or non-technical staff generate code without understanding, accept suggestions blindly, work around errors. Eventually the mess escalates to seniors who must reverse-engineer chaos, identify vulnerabilities, fix architecture, rebuild everything. This isn't AI-assisted development - it's bad process hidden behind buzzwords. ## The context window blindness The most damaging misunderstanding is how senior developers approach AI. They paste isolated code snippets into ChatGPT like it's Google, expecting magical solutions. When AI fails to understand their partial codebase context, they conclude "AI doesn't know" and dismiss the technology. This reveals a critical knowledge gap - not about programming, but about how LLMs fundamentally work. AI doesn't magically solve problems. It requires orchestration - the developer tells, the AI does. Success demands full alignment with the context window. When seniors paste a single function from a thousand-file codebase, they're guaranteeing failure. The AI lacks the surrounding context, dependencies, architectural decisions, and business logic that make that code meaningful. This isn't AI's limitation - it's the developer's failure to understand how to work with LLMs. The orchestration principle is vital: AI amplifies what you direct it to do, with the context you provide. Senior developers who understand this maintain full context window alignment, providing complete information about the system, dependencies, and objectives. Those who don't understand this treat AI like a search engine, get poor results, and blame the technology rather than their approach. ## What senior developers should actually be doing The proper role of senior developers in AI-assisted development looks nothing like cleanup babysitting - but it does require intense real-time oversight. There's a critical distinction between two types of "babysitting" that organizations must understand. The wrong kind involves cleaning up AI-generated messes after they've been created. The essential kind involves actively monitoring AI suggestions as they're being generated, understanding each line of code in real-time, staying aligned with the context window throughout the creation process. When using AI orchestration tools like Cline or RooCode, developers must "babysit" the screen during creation - not as passive observers but as active participants who understand every suggestion before it becomes part of the codebase. This real-time oversight is crucial because it maintains cognitive alignment between the developer and the AI's context window. Without this alignment, developers cannot take full responsibility for the output, and the code becomes a black box that nobody truly understands. In organizations that understand AI development paradigms, senior developers orchestrate AI tools to achieve complex objectives while maintaining production quality from the start. They design systems where AI agents handle routine tasks under proper supervision, establish validation frameworks that prevent bad code from entering the pipeline, and mentor teams on professional AI development practices. The key is that validation happens during creation, not after. In CLI-coding paradigms, senior developers define the patterns and standards that guide AI assistance. They review AI suggestions not as damage control but as part of a structured workflow where quality is maintained throughout. In AI-orchestrated paradigms, they design multi-agent systems where validation and quality assurance are built into the process, with developers staying mentally synchronized with the AI's operations. The difference is profound. Instead of spending 80% of their time fixing problems created by others, senior developers in properly structured organizations spend their time orchestrating AI while maintaining full awareness and control. They watch every suggestion, understand every change, and remain aligned with the context window throughout the development process. This real-time oversight isn't a burden - it's the essential practice that enables responsible AI-assisted development. ## Organizational maturity test How organizations handle AI reveals technical maturity. Mature organizations implement clear paradigms, validation processes, and accountability. Immature organizations grab AI tools without methodology, create chaos, wonder why seniors are overwhelmed. The "babysitting" pattern is a failure signal. Organizations skipped essential AI adoption steps - processes, standards, training. They confused experimentation with implementation. Senior developers cost hundreds per hour. Having them fix preventable problems wastes massive resources. Organizations pay premium prices for junior output with senior cleanup - the most inefficient pattern possible. ## Real costs Costs extend beyond wasted salaries. Senior developers burn out from repetitive cleanup instead of challenging problems. They leave for organizations using skills properly. Organizations lose productivity, institutional knowledge, technical leadership. Without seniors designing proper systems, juniors never learn correct AI practices. They continue generating messes, assuming "seniors will fix it." Organizations develop irresponsibility cultures where nobody owns quality. Competitive disadvantage compounds. While proper organizations accelerate through professional AI orchestration, babysitting organizations move slower despite same tools. They ship lower quality later, accumulate technical debt, face complete rewrites when chaos becomes unmanageable. ## Breaking free Organizations escape by recognizing senior cleanup isn't normal - it's process failure. Implement proper paradigms, not uncontrolled experimentation. Teams must understand vibe coding (unacceptable beyond experiments) versus professional AI development (required for production). They need validation training, accountability frameworks, quality standards. AI doesn't eliminate engineering discipline - it amplifies importance. Restructure AI integration. Instead of anyone generating code then passing to seniors, establish structured frameworks. Seniors define frameworks, not cleanup absence. Juniors learn validation as growth, not pass unchecked code upstream. ## Path forward The solution isn't accepting seniors as babysitters - it's eliminating need for babysitting. Professional AI development means everyone understands code quality responsibility. AI tools operate within defined paradigms, not uncontrolled experiments. Seniors return to proper roles as technical leaders, not cleanup crew. If seniors spend most time fixing AI-generated code, the organization failed at AI adoption. This isn't progress - it's emergency. Proper AI development delivers what babysitting promises but fails achieving. Teams move faster without cleanup. Quality improves when validation happens throughout, not as damage control. Seniors contribute more value designing systems than fixing messes. Organizations can waste senior talent on babysitting while calling it progress, or implement professional practices delivering value. First path: burnout, technical debt, competitive disadvantage. Second path: sustainable acceleration, quality improvement, innovation. The question is organizational maturity to recognize which path they're on. --- ### [AI-orchestrated project management: the same technique, a different domain](https://mindtastic.se/articles/ai-orchestrated-project-management) A year ago we were talking about AI orchestration for codebases. Everyone is talking about it now. The same technique — Socratic questions, raw text, context window — applies directly to project management. The organizations that realize this first will have the same head start developers had a year ago. # AI-orchestrated project management: the same technique, a different domain About a year ago, AI orchestration in software development was a fringe practice. A small number of teams were using it systematically. The results were significant enough — a development department transformed in roughly four months — that it was clear this was not a productivity trick but a structural shift in how technical work could be done. Now everyone is talking about it. The pattern is familiar. Early adoption, visible results, a lag of twelve to eighteen months before the mainstream catches up, then rapid convergence. The organizations that moved first have a structural advantage that compounds. Those that move when the conversation becomes mainstream are catching up rather than leading. The question worth asking now is not how to implement AI orchestration in software development. That answer exists. The question is: what comes next? And the answer is already visible to anyone who looks at the underlying technique rather than the specific domain. ## What made AI orchestration work in development The insight that unlocked AI orchestration for development teams was deceptively simple: a codebase is text. Not metaphorically. Literally. Source files, configuration, documentation, commit history — all of it is structured text that can be placed in a context window. Once you accept that framing, the mechanics follow directly. You put the relevant parts of the codebase in context. You ask Socratic questions — not "write me a function" but "given this architecture, what are the implications of changing this interface?" You work with the LLM as a reasoning partner that has the full context rather than as a code generator working from a description. The result was not faster typing. It was better decisions. Teams that understood the codebase deeply, found problems before they became incidents, made architectural choices with full awareness of the downstream effects. The LLM was not replacing the developer. It was giving the developer a collaborator who had read everything and could reason about all of it simultaneously. What made it work: the raw material was text, the context window was managed deliberately, and the questions were structured to elicit reasoning rather than output. ## The same raw material already exists in project management Steering documents are text. Meeting summaries are text. Decision logs are text. Email threads, Slack conversations, retrospectives, risk assessments, stakeholder updates — all text. The raw material for AI-orchestrated project management already exists in every organization. It has always existed. The difference is that until recently there was no practical way to reason over it at the scale and speed that changes how decisions get made. The technique that works for a codebase works for a project documentation corpus. You put the relevant documents in context — the steering document, the last three decision logs, the open risk items, the conversation thread from last week's planning session. You ask the same kind of Socratic questions: given these constraints, what is the implication of this timeline change? Which decisions made in the first phase are in tension with the approach being proposed in the third? What assumptions are embedded in this plan that have not been made explicit? The LLM does not manage the project. It gives the project lead a collaborator who has read all the documents and can reason about the relationships between them. The same structural shift that transformed development teams applies here. ## What this is not This is not the AI features being added to project management tools. Most of those extract summaries from existing fields, generate status updates from ticket data, or automate routine notifications. That is automation of administration. It is useful and it is not what we are describing. AI-orchestrated project management works with raw text outside of structured systems. The conversation that happened before the decision was logged. The steering document that was written six months ago and has not been formally updated but reflects assumptions that are now out of date. The retrospective notes that never made it into any system. The email thread that contains the actual reasoning behind a choice that looks arbitrary in the ticket. The unstructured, conversational, human record of how a project is actually being run — that is the input. A good LLM, given access to that material and asked the right questions, can surface what no dashboard will show you. ## The voice advantage: project work starts verbal There is one structural difference between a codebase and a project documentation corpus that actually strengthens the case rather than weakening it. A codebase is already text. A developer writes code, commits it, and the artifact is immediately machine-readable. Project work is largely verbal first. Decisions get made in meetings. Direction gets set in conversations. Context gets established in calls. The written record — if it exists at all — is a summary of what happened, not the raw material of the reasoning. This is not a problem. It is the point of entry. When you record and transcribe a meeting, you produce a raw text document that contains the actual language people used, the questions that were raised, the objections that were addressed, and the reasoning behind the outcome. That document is richer than any formal minutes. It captures what the decision log never will. Structured AI workflows for voice — recording, transcription, targeted extraction — are already understood and already deployed in organizations using AI seriously. The same pipeline that turns a sales call into structured customer intelligence turns a project steering meeting into a structured record of constraints, decisions, and open questions. The technique is identical. The domain is different. This means that project management AI orchestration has a raw material advantage that developers do not: the most important project conversations, once transcribed, are richer context than anything that ends up in a formal document. The informal, the verbal, the off-the-record — all of it becomes usable when you treat conversation as data. ## Context window management is the skill The same discipline that makes AI orchestration work in development makes it work in project management. The context window is finite. What you put in determines what the model can reason about. Putting everything in is not a strategy. The skill is selection: which documents are actually relevant to this decision? Which conversations contain the context that is missing from the formal record? Which earlier decisions are in active tension with the current proposal? This is not a technical skill. It is a knowledge work skill. The project lead who can make those selections well gets dramatically more leverage from the technique than the one who cannot. Which is exactly the pattern that emerged in development teams: the senior developers — the ones who already understood the codebase structurally — got the most leverage from AI orchestration. It amplified existing judgment rather than substituting for it. ## The choice that exists right now Organizations that started applying this technique in software development a year ago spent several months finding what worked, building the conventions, and accumulating the compounding returns of a team that has internalized a new way of working. By the time it became a mainstream conversation, they had a lead that takes time to close. The same window exists now for project management, knowledge work, and operational decision-making. The technique is understood. The tools are available. The raw material — text, conversations, documents — is already there. The question is the same one that faced development teams a year ago: do this now, when the advantage is available, or wait until it is a standard expectation and the advantage is gone. The technique does not change. The timing does. --- *Related: [The context window illusion](/articles/context-window-illusion) · [Voice to structured meeting documentation](/articles/voice-to-structured-meeting-documentation) · [Claude Cowork scheduled tasks](/articles/claude-cowork-scheduled-tasks) · [Track 2: Document Management](/workshop)* --- ### [Claude Cowork scheduled tasks: what actually enters the context window](https://mindtastic.se/articles/claude-cowork-scheduled-tasks) Claude's scheduled tasks run automatically — but Claude only knows what you explicitly give it. Before automating recurring work, you need to understand what actually enters the context window and who is accountable for reviewing the output. # Claude Cowork scheduled tasks: what actually enters the context window The coverage of Claude's scheduled tasks feature treats automation as the headline. Set up a task once, it runs on a schedule, work happens while you are away. That framing is technically accurate and practically incomplete. The question that determines whether scheduled tasks are useful or useless is simpler: when Claude runs your scheduled prompt, what does it actually know? ## What Claude reads when your scheduled task runs A scheduled task is a prompt that executes automatically. When it runs, Claude starts a new Cowork session with your instructions. It does not inherit memory from previous sessions. It does not automatically check your calendar, your inbox, your project management tool, or any other external system. What Claude knows at execution time is exactly what you give it — your prompt, plus whatever tool connections you have explicitly configured and Claude actively calls during that session. If your task is "generate a daily briefing summarizing what happened in the project today," Claude cannot do that without a live connection to where that information lives. Without configured MCP integrations pointing at your actual project data, Claude is running your prompt against its training data and general reasoning ability. The output will look like a briefing. It will not be based on your actual data. This is not a failure of the feature. It is what the feature is. The gap appears when the setup skips this step. ## The two categories of tasks that actually work Once you understand the data question, the distinction becomes clear. **Self-contained tasks** work well and require no integrations. If your scheduled task processes files that already exist in a folder Claude can access, analyzes a document you have explicitly pointed to, or runs against a dataset your prompt specifies directly — the task is self-contained. The input is defined. The output is reliable. **Data-dependent tasks** only work if the data pipeline is verified. A daily briefing works if Claude has working connections to your calendar, messages, or project tools via MCP — and if you have tested those connections produce the data you expect. A weekly report works if there is a defined source Claude reads, not a vague instruction to "summarize this week." The difference matters in practice: self-contained tasks can be set up and run. Data-dependent tasks require infrastructure verification before automation adds any value. ## The accountability problem automation creates Automating a task does not remove the accountability for its output. It shifts when and how that accountability is exercised. Before automation, you write the prompt, review the output, and act on it — or don't — in one continuous session. You are present when the work happens. After automation, the output exists in a folder. Whether it is reviewed, how carefully, and by whom is now an organizational question rather than a natural workflow step. The automation that was supposed to save time creates a new obligation: a committed review step that someone actually performs. Teams that treat scheduled output as background noise — letting it accumulate unread — have not gained productivity. They have created a system that produces authoritative-looking documents nobody is responsible for. The only scheduled tasks worth running are ones where the review step is as defined as the task itself. Who reviews it. How often. What action results from it. Without that, the automation is a false efficiency. ## What the "computer must be awake" limitation tells you Every article about this feature mentions that scheduled tasks require your computer to be awake and the Claude Desktop app to be open. This is framed as a temporary limitation. The more useful observation: this constraint is fine for the narrow category of tasks that scheduled automation is actually suited for. If you are generating a structured morning briefing at 8am, your computer is on at 8am. If you are running a weekly research summary on Monday, your computer is on Monday. The constraint only matters if you are trying to use scheduled tasks as always-on infrastructure — overnight log scanning, production monitoring, continuous processing. For that, you need cloud infrastructure. Scheduled tasks are not cloud infrastructure. Using them as a substitute creates gaps that are hard to detect and easy to miss. ## What makes a scheduled task worth setting up Before automating any recurring task, three things need to be true: The data source is explicit. Not "Claude will figure out what to read" — the task specifies exactly what input Claude processes, with working integrations verified before automation is turned on. The review step is defined. Someone reads the output on a defined cadence. If the output is wrong, degraded, or based on stale data, they will notice. The task is genuinely recurring. The same work, the same structure, the same questions, every time. If the task requires judgment about what to include or how to frame it, it is not ready for automation — it requires a human in the loop for each execution. Scheduled tasks are a legitimate tool for the narrow slice of recurring work that meets these criteria. For everything outside that slice, the manual prompt you write and review yourself is not a shortcut you have skipped — it is the accountability mechanism you have kept. --- *Scheduled tasks are available in Cowork on Claude Desktop for all paid plans (Pro, Max, Team, and Enterprise). MCP integrations require separate configuration.* --- ### [Agentic code review: AI hunts the bugs. You still own the merge.](https://mindtastic.se/articles/agentic-code-review-accountability) Claude's Code Review runs a fleet of agents against every pull request. 54% of PRs get findings. Less than 1% are false positives. The accountability still lands on the engineer who merges. # Agentic code review: AI hunts the bugs. You still own the merge. Anthropic's [Code Review](https://code.claude.com/docs/en/code-review) feature runs a fleet of agents against every pull request in parallel. Each agent targets a different class of bug. A verification step filters false positives before anything reaches the engineer. Findings post as inline comments on the exact lines where issues were found. The numbers from Anthropic's internal rollout: - 54% of PRs now get findings, up from 16% with previous methods - Large PRs average 7.5 real issues caught - Less than 1% of findings marked incorrect by engineers That's a meaningful signal-to-noise ratio for an automated system. Most automated review tools are abandoned because the false positive rate is too high to trust. Less than 1% incorrect is a different category of tool. ## What it actually does This is an agentic pattern in practice: parallel specialization, then consolidation. Each agent hunts one class of problem — security, logic errors, type safety, edge cases, whatever you configure. They run simultaneously. Results merge. A verification layer filters what survives before it surfaces to the engineer. One concrete case from Anthropic's rollout: a developer made a small code edit that would have silently broken authentication. The agents caught it before merge. Small change, serious consequence — exactly the category that slips through because it's too subtle to flag in a quick human skim. The review runs in about 20 minutes. Cost is $15–25 per PR, scaling with size. Currently available as a research preview. ## The REVIEW.md file You control what gets flagged through a REVIEW.md file in your repo. Define what to always check. What to skip. What conventions matter for this specific codebase. This is not a configuration detail. It is the structured handoff between human judgment and agent execution. Your accumulated knowledge of the codebase — what matters, what doesn't, what the team has already decided and why — becomes machine-readable instruction. The agents work within the frame you set. They do not invent standards. They apply yours. Without that file, you're delegating without a brief. With it, you're orchestrating. The REVIEW.md is where experience goes from tacit to explicit. Writing it well is a skill — the same skill that makes a good code review checklist, a good runbook, or a good architecture decision record. The quality of the agent output is bounded by the quality of the frame you give it. ## What doesn't change The agents find issues. Engineers decide what to do with them. That accountability doesn't transfer to the tool. This is the same principle that applies across AI-assisted development. More coverage doesn't mean less ownership. It means the bar for what you missed is higher — because the system already caught the things it was configured to catch. 54% of PRs get findings. Someone still has to read those findings, understand them in context, and decide whether they represent real risk. That requires domain knowledge. It requires the same judgment that made a good code reviewer before agents existed. The surface area of what you're accountable for changes. The accountability itself doesn't. ## The pattern worth understanding Regardless of whether you adopt this specific tool, the architecture is worth studying: - Parallel agents, each specialized to one task class - A verification step to filter noise before it reaches humans - Human-readable output at the exact decision point - A configuration file where human judgment is encoded upfront This is what agentic systems should look like when applied to workflows with real consequences. The agents amplify the review, not replace it. The REVIEW.md is the brief. The agents execute. The engineer signs off. The authentication bug would have shipped. It didn't. That is the point — and the limit. --- *Source: [Claude Code Review documentation](https://code.claude.com/docs/en/code-review)* --- ### [How to build AI systems that actually collaborate](https://mindtastic.se/articles/building-trustworthy-ai-confidence-scoring-systems) Transparency and confidence scoring transform AI from a black box into a reliable partner. Here is how you build AI systems that people actually trust. # How to build AI systems that actually collaborate You should have reasoning and you should have a confidence score. This simple requirement transforms AI collaboration. Instead of AI being a black box that spits out mysterious answers, it becomes a transparent partner that helps make smart decisions. ## The transparency that makes AI trustworthy Effective AI systems should never give just an answer. They should provide what they're proposing, why they think this is right, how confident they are (0-100%), what assumptions they're making, and what could go wrong. Without this transparency, you're flying blind. With it, informed decisions can be made about when to trust the AI and when to dig deeper. ## Confidence-based workflow Effective systems use confidence levels to guide decision-making: **90-100% confidence**: Quick review, usually good to go **70-89% confidence**: Detailed check, look for specific issues **50-69% confidence**: Major collaboration needed, significant changes likely **Below 50%**: Human-driven solution, use AI for research only This framework enables moving fast on solid recommendations while being careful with uncertain ones. ## The learning loop that improves everything Here's the pattern that works: 1. AI suggests with reasoning and confidence 2. Humans validate and give feedback on what was right/wrong 3. AI learns from corrections 4. Future suggestions get better This isn't just validation overhead - it's an investment. Every correction makes the AI more useful next time. AI systems get dramatically better over months of this feedback. ## Team roles that actually work Traditional development teams don't work well with AI. Effective AI implementations require: **AI Orchestrators**: Design the prompts and workflows **Validation Specialists**: Review AI outputs with domain expertise **Integration Engineers**: Connect AI and human processes smoothly **Quality Assurance**: Test the whole human-AI system Different skills than traditional roles, but essential for AI success. ## Industry patterns I've observed Successful AI implementations consistently follow similar patterns: **Healthcare**: AI suggests, doctors decide, everything has reasoning **Finance**: AI flags, humans investigate, multiple review layers **Development**: AI generates, humans validate, clear approval gates The common thread: AI provides analysis, humans make decisions, transparency enables trust. ## Workflow design that doesn't slow you down The key insight: good human-AI collaboration should speed you up, not slow you down. Effective approaches are simple. AI confidence scores help prioritize attention. High-confidence outputs get quick approval. Low-confidence outputs get focused review. Everything gets logged for learning. Quick rollback if something goes wrong. When done right, this catches problems early instead of in production. ## Quality control that actually works Three levels of control work effectively: **Process controls**: Regular reviews, peer validation, escalation procedures **Technical controls**: Version control, automated testing, monitoring **Organizational controls**: Clear roles, training, metrics that reward quality The goal isn't perfect oversight - it's reliable improvement over time. ## The real cost-benefit Yes, human-AI collaboration takes setup time. But the alternative is problematic. AI systems that nobody trusts. Outputs that look good but fail in practice. Teams that abandon AI because it's unreliable. Massive failures because nobody was checking. Proper collaboration pays for itself through prevented failures and improved capabilities. ## My practical framework Successful implementations consistently demonstrate these principles: 1. **Demand transparency from AI** - reasoning and confidence always 2. **Match oversight to confidence** - more uncertain = more checking 3. **Create feedback loops** - AI learns from human corrections 4. **Design for speed** - high-confidence outputs move fast 5. **Measure both speed and quality** - optimization for both The future isn't AI replacing humans. It's AI and humans getting really good at working together. Each correction makes the AI smarter. Each validation makes humans more effective. That's the learning partnership that actually delivers results. --- *Based on 6 months of building AI systems that humans actually trust* *Practical guidelines for AI-human collaboration* --- *Strategic AI insights for business leaders and technical decision makers* *Published: August 2025* --- ### [The senior developer paradox: why AI experts resist AI tools](https://mindtastic.se/articles/senior-developer-paradox) The developers best equipped to use AI tools effectively are often the ones who resist them hardest. A paradox that slows AI adoption across the industry. # The senior developer paradox: why AI experts resist AI tools ## Core Content Fragment ### The Expertise Contradiction One of the most surprising discoveries in AI adoption isn't technical - it's psychological. The developers who are best equipped to use AI tools effectively are often the ones who resist them most strongly. This creates a paradox that's slowing AI adoption across the industry. *"They think it's cheating"* - This sentiment from senior developers reveals a fundamental tension between professional identity and technological evolution. #### The Validation Capability Gap Senior developers possess the exact skills needed for AI-Orchestrated coding - the highest paradigm in our [framework](/research/reference_coding_paradigms_comparison.md). They understand the problem space deeply enough to provide full context window alignment and orchestrate AI effectively. They can validate AI-generated code for production readiness, the critical difference between CLI-Coding experiments and AI-Orchestrated systems. They have the expertise required for real-time validation, the key obstacle in AI-Orchestrated development. As one insight reveals: *"When you know the stuff... I couldn't use it to handle COBOL code. I don't know COBOL."* This highlights a crucial truth: AI amplifies existing expertise rather than replacing it. Without the foundational knowledge, even the most sophisticated AI tools become ineffective or dangerous. #### The Identity Crisis Senior developers often see their value in their ability to write elegant, efficient code. When AI can generate functional code quickly, it challenges their sense of professional worth. **Traditional Coding Identity:** - Manual code craftsmanship - Deep debugging cycles - Direct problem-solving - Being the technical authority **AI-Orchestrated Reality:** - Multi-agent orchestration - Real-time validation during generation - Full context window management - Maintaining production quality through AI This shift feels like a demotion to many seniors, even though it often requires higher-level thinking. #### The "Cheating" Mentality This perception of AI as cheating stems from several psychological factors: **Effort-Based Value System:** Traditional development culture values the struggle, the late nights debugging, the satisfaction of solving complex problems through pure intellect and persistence. **Craftsmanship Pride:** Senior developers take pride in their ability to write clean, efficient code from scratch. AI-generated code feels like taking credit for someone else's work. **Imposter Syndrome Amplification:** Using AI can make experienced developers feel like frauds, especially when junior colleagues or stakeholders don't understand the expertise required for effective AI orchestration. **Fear of Obsolescence:** If AI can write code, what value do senior developers provide? This existential fear drives resistance. #### The Junior Developer Contrast Ironically, junior developers often jump straight to Vibe-Coding approaches, embracing AI enthusiastically but lacking the expertise for proper validation: *"What do we do with the juniors? They're screwed. Because those who don't have the knowledge to see that this is wrong..."* **Junior Developer Pattern (Vibe-Coding):** - Accept all AI suggestions without review - Minimal understanding of generated code - Work around errors rather than solving them - Create impressive demos that fail in production **Senior Developer Capability (AI-Orchestrated):** - Real-time validation during generation - Full context window alignment - Production-grade quality assurance - Understanding every line as it's created The paradigm gap is enormous - juniors operate in Vibe-Coding while effective AI requires AI-Orchestrated expertise. #### The Exception: High-Ambition Learners *"We have two in the team who are evaluating now, who are junior... But it's because they have an ambition level that's higher than average."* This insight reveals that successful AI adoption isn't just about seniority—it's about learning mindset and ambition. Some junior developers succeed with AI because they: - Invest extra effort in understanding fundamentals - Actively seek feedback and validation - Combine AI enthusiasm with rigorous learning - Don't assume AI outputs are always correct #### The Resistance Patterns Senior developer resistance manifests in several ways: **Active Resistance:** - Refusing to try AI tools - Criticizing AI outputs without proper evaluation - Blocking team adoption initiatives - Insisting on traditional methods exclusively **Passive Resistance:** - Trying AI tools superficially and dismissing them - Using AI for trivial tasks only - Maintaining traditional workflows while others experiment - Expressing skepticism about AI capabilities **Intellectual Resistance:** - Focusing on AI limitations rather than capabilities - Demanding perfection from AI while accepting human errors - Overemphasizing edge cases and failure modes - Dismissing productivity gains as "not real development" #### The Cost of Resistance Organizations pay a high price for senior developer resistance: **Productivity Stagnation:** Teams without senior AI adoption miss out on 4-5x productivity improvements that proper AI orchestration can provide. **Cultural Division:** Resistance creates tension between AI-enthusiastic juniors and skeptical seniors, fragmenting team dynamics. **Competitive Disadvantage:** Companies with AI-resistant senior teams fall behind those that successfully bridge the expertise gap. **Innovation Paralysis:** Without senior validation, AI experiments remain at the prototype level, never reaching production quality. #### Breaking Through the Resistance Successful AI adoption requires addressing the psychological and cultural barriers: **Reframe the Role:** Position AI as a tool that elevates senior developers to higher-level architectural and validation work, rather than replacing their coding skills. **Emphasize Expertise Requirements:** Demonstrate that effective AI development requires more expertise, not less. The validation burden actually increases. **Show Real Value:** Focus on business outcomes and problem-solving capability rather than just code generation speed. **Address Identity Concerns:** Help seniors understand that their experience becomes more valuable in an AI world, not less valuable. #### The Evolution Path For senior developers willing to adapt, the transition follows predictable stages: **Stage 1: Traditional Coding (with AI attempts)** - Pasting code snippets into ChatGPT like Google - Getting frustrated when AI lacks context - Concluding "AI doesn't understand code" **Stage 2: CLI-Coding Adoption** - Learning proper prompt engineering - Providing better context in requests - Still experiencing "black hole" visibility issues **Stage 3: AI-Orchestrated Learning** - Understanding full context window alignment - Real-time validation during generation - Maintaining cognitive sync with AI **Stage 4: AI-Orchestrated Mastery** - Multi-agent system orchestration - Production-grade AI development - Teaching orchestration principles to others #### The Validation Advantage The paradox resolves when senior developers realize their expertise becomes more crucial, not less: *"The developer is personally responsible for everything that's output."* This responsibility requires: - Deep understanding of the problem domain - Ability to recognize correct vs incorrect solutions - Knowledge of security and performance implications - Experience with system integration challenges These are exactly the skills that senior developers have spent years developing. #### The Future of Senior Development The most successful senior developers will be those who: - Embrace AI as an amplifier of their expertise - Develop sophisticated prompt engineering skills - Build effective validation and quality processes - Mentor others on responsible AI development - Focus on architectural and system-level thinking #### Conclusion: From Resistance to Leadership The senior developer paradox isn't permanent. As the industry matures, we're seeing early adopters among senior developers becoming the most effective AI practitioners. Their domain expertise, combined with AI capability, creates unprecedented productivity and quality. The key insight: *"It's still you who builds"* - AI doesn't replace the developer's role; it transforms it. Senior developers who understand this become leaders in the AI era, not casualties of it. The future belongs to those who can combine deep expertise with AI orchestration skills. Senior developers have the expertise - they just need to overcome the psychological barriers to adding AI orchestration to their toolkit. ## Development Notes - **Content Type**: Psychology / professional development - **Target Audience**: Senior developers, technical leaders, engineering managers - **Key Message**: Senior developer resistance is psychological, not technical - expertise makes AI more powerful, not obsolete - **Status**: Initial draft based on research insights - **Next Steps**: Add specific examples from portfolio projects when available ## Potential Portfolio Connections - **jsonflow**: Senior developer AI adoption journey and validation processes - **record-me**: Audio processing expertise combined with AI transcription - **tic**: Business intelligence domain knowledge amplifying AI analysis - **sumtastic.app**: Content expertise guiding AI aggregation and summarization - **grabb3r**: Competitive analysis expertise directing AI data collection ## Expansion Areas to Develop *When portfolio projects provide real examples:* - Case studies of successful senior developer AI adoption - Before/after productivity comparisons - Specific examples of validation processes that work - Stories of overcoming resistance and identity challenges - Examples of seniors becoming AI orchestration leaders ## Key Concepts to Explore - **Expertise Amplification**: How domain knowledge makes AI more powerful - **Identity Evolution**: Professional identity transformation in AI era - **Validation Requirements**: Why senior expertise becomes more important - **Resistance Psychology**: Understanding and addressing adoption barriers - **Leadership Opportunity**: How seniors can lead AI transformation --- *Fragment captured: 2025-08-13* *Development status: Initial draft - psychological insights established* --- ### [How Claude Code actually works: the agentic loop, CLAUDE.md, and what engineers need to understand](https://mindtastic.se/articles/how-claude-code-works) Claude Code is not an autocomplete tool with a chat interface. It is an agentic loop that reads files, runs commands, edits code, and calls other agents — until the task is done. Understanding the architecture changes how you use it. # How Claude Code actually works: the agentic loop, CLAUDE.md, and what engineers need to understand Most engineers who pick up Claude Code use it the same way they used GitHub Copilot: type a prompt, get output, iterate. That works. It also leaves most of the tool's capability on the table. Claude Code is not a completion engine. It is an agentic loop — a system that reads, decides, acts, observes the result, and repeats. Understanding the loop changes what you ask of it, how you configure it, and where the accountability sits. ## The agentic loop Every Claude Code session runs the same core cycle: 1. Receive a task or message 2. Decide which tool to use 3. Execute the tool 4. Observe the output 5. Decide next step — and repeat until done The tools Claude Code can invoke: read files, write files, run bash commands, search the web, call external APIs via MCP connections, and spawn subagents to work in parallel. Each tool call is visible in the terminal as it happens. This is not a black box — it is a transparent sequence of decisions. The loop continues until Claude decides the task is complete, until context runs out, or until the user interrupts. On a large refactoring task, this might mean dozens of file reads, test runs, and edits before surfacing a result. The practical implication: vague prompts that worked for autocomplete tools do not work well here. The loop will execute on whatever interpretation it forms of an ambiguous instruction. Precision in the task description directly determines what the loop does. ## CLAUDE.md: where your judgment lives The most important configuration file in Claude Code is `CLAUDE.md`. Place it in a repository root and Claude reads it at the start of every session in that repo. It is not documentation — it is instruction. What to always do. What to never do. Which conventions matter in this codebase. How the team has decided to handle certain patterns. This is the same principle as [REVIEW.md in the Code Review feature](/articles/agentic-code-review-accountability) — human judgment encoded as machine-readable instruction. The quality of Claude Code's output in a specific codebase is bounded by how well CLAUDE.md captures that codebase's rules. Organizations that ship fast with Claude Code typically invest heavily in their CLAUDE.md files. Teams that get inconsistent results often have no CLAUDE.md, or one written once and never maintained. The file is not a one-time setup — it is a living document that grows with the codebase and the team's accumulated knowledge. What belongs in CLAUDE.md: - Testing conventions and which test runner to use - Code style rules that differ from language defaults - Which directories to avoid touching - How to handle migrations, secrets, environment variables - Architectural decisions that are already made Without CLAUDE.md, every session starts from zero. With it, the agent inherits the team's accumulated judgment. ## Skills and slash commands Claude Code supports Skills — specialized behaviors triggered by `/command` syntax. Skills are markdown files that expand into structured prompts when invoked, giving the agent a specific frame for a specific task type. A team can define a `/deploy` skill that includes the exact steps, checks, and approvals required. A `/review` skill that enforces the team's standard. A `/debug` skill that follows a specific investigation pattern. Skills encode process as executable instruction. They are the difference between asking "can you review this PR" and invoking a consistently structured review workflow that the whole team uses. ## Subagents and parallel execution Claude Code can spawn subagents — separate Claude instances that execute tasks in parallel and return results to the parent session. This is what enables complex workflows: a parent agent defines the overall task, breaks it into independent subtasks, and dispatches subagents to handle them simultaneously. Results merge back into the parent context. The Code Review feature is a concrete example of this pattern: a fleet of specialized agents runs against a pull request in parallel, each targeting one class of problem, with results consolidated and filtered before reaching the engineer. The same architecture is available in any Claude Code session. When a task has independent parallel workstreams — searching multiple sources, running multiple test suites, analyzing multiple files — subagents compress calendar time. ## MCP: extending what Claude can reach Model Context Protocol (MCP) is the integration layer. Claude Code connects to external tools and services via MCP servers — databases, APIs, internal systems, specialized search indexes. An MCP connection makes external data or capability available inside the agentic loop as a tool Claude can call, observe, and reason about. The agent does not know or care whether the data came from a local file or an internal API — it treats both as information it can act on. This is how Claude Code gets integrated into production workflows rather than living as a standalone coding assistant. ## Hooks: process control at the edges Hooks are shell commands that fire at specific moments in the Claude Code lifecycle: before a tool runs, after a tool completes, on session start or end. They are the mechanism for policy enforcement. A hook that blocks any file write outside specified directories. A hook that runs a linter before any commit. A hook that logs all bash executions to an audit trail. This is where organizational control lives. Hooks let engineering teams define hard boundaries on what Claude Code can do in their environment, independent of what any individual prompt requests. ## What this changes for engineering teams Most of the leverage in Claude Code is in configuration, not in prompting. A well-maintained CLAUDE.md means every session in that repo starts with the team's full context. Skills mean process knowledge is encoded and reusable rather than re-explained each session. Hooks mean policies are enforced at the tool level, not trusted to each engineer's prompting discipline. The agentic loop runs on what it is given. Teams that give it structured context, defined processes, and enforced boundaries get structured, reliable results. Teams that treat it as an intelligent autocomplete get autocomplete-level results from a much more capable system. The tool is not the bottleneck. The configuration is. --- *Sources: [How Claude Code works](https://code.claude.com/docs/en/how-claude-code-works) · [Features overview](https://code.claude.com/docs/en/features-overview)* --- ### [Vibe coding: the hidden danger of AI development](https://mindtastic.se/articles/vibe-coding-danger) "It works but I don't know why" is a ticking time bomb. Here is why vibe coding destroys codebases — and how you avoid the trap. # Vibe Coding: The Hidden Danger of AI Development **Target audience:** Development teams, tech leads, CTOs **Reading time:** 6 minutes **Key insight:** Why "it works but I don't know why" is a ticking time bomb ## Definition **Vibe coding** (n.): Creating code without understanding. Letting AI generate solutions you can't explain, debug, or maintain. Operating on vibes rather than comprehension. It's the development equivalent of driving blindfolded because the GPS is giving directions. ## The Seductive Trap AI makes vibe coding incredibly tempting: - **Instant gratification:** Complex features appear in seconds - **Imposter syndrome relief:** "Look what I built!" - **Velocity illusion:** Shipping faster than ever - **Complexity abstraction:** Don't need to understand the details One developer admitted: "I built an entire API integration in 10 minutes. It worked perfectly. I had no idea how." Six weeks later, it broke in production. Debug time: 3 days. ## Red Flags You're Vibe Coding - "It works but I don't know why" - Copy-pasting AI code without review - Skipping the planning phase - Can't explain the code to others - Afraid to modify AI-generated code - Debugging means regenerating - Code reviews become rubber stamps If you recognize these patterns, you're not alone. Every team using AI faces this challenge. ## The Compound Interest of Ignorance Vibe coding accumulates technical debt at an unprecedented rate: ### Week 1: The Honeymoon - Features ship quickly - Everyone's impressed - Productivity metrics soar ### Week 4: The Cracks - First production bug takes hours to fix - Team members can't modify each other's code - Documentation is meaningless ### Week 8: The Reckoning - Critical failure in production - No one understands the codebase - Refactoring means starting over - Trust in AI plummets ### Week 12: The Aftermath - Reverting to manual coding - "AI doesn't work for real projects" - Valuable tool abandoned due to misuse ## Why Vibe Coding Happens ### 1. Pressure to Deliver "We need this feature yesterday." AI seems like the shortcut. ### 2. Overconfidence in AI "If AI wrote it, it must be right." Famous last words. ### 3. Skill Gap Masking Junior developers can generate senior-level code... that they can't maintain. ### 4. Metrics Misalignment Measuring lines of code or features shipped rather than maintainability. ## The Security Nightmare Vibe coding's darkest secret: **security vulnerabilities you can't see**. Real example from a workshop participant: ```python # AI-generated authentication def verify_user(token): decoded = jwt.decode(token, options={"verify_signature": False}) return decoded['user_id'] ``` The developer didn't notice the `verify_signature: False`. The AI had prioritized "making it work" over security. This code shipped to production. ## The Alternative: Conscious AI Development ### Principle 1: Personal Responsibility "Du är personligt ansvarig för all kod" - You are personally responsible for all code you check in. ### Principle 2: Explanation Requirement If you can't explain it to a junior developer, you shouldn't ship it. ### Principle 3: Incremental Understanding Build complex features in understandable increments. ### Principle 4: Code Review Discipline AI-generated code needs MORE review, not less. ## Practical Prevention Strategies ### 1. The Rubber Duck Test Before committing AI-generated code, explain it to a rubber duck (or colleague). Can't explain it? Don't ship it. ### 2. The Debug Challenge Intentionally break the AI-generated code. If you can't fix it without regenerating, you don't understand it. ### 3. The Teaching Moment Have team members present AI-generated code in code reviews. Teaching forces understanding. ### 4. The Context Window Discipline Smaller, focused prompts lead to understandable code. Massive prompts create incomprehensible systems. ### 5. The Gradual Adoption Start with AI-assisted debugging and refactoring before generation. Build understanding gradually. ## Success Pattern: The Three-Layer Approach Teams successfully avoiding vibe coding use this pattern: 1. **Human designs** the architecture 2. **AI implements** the components 3. **Human validates** and understands This maintains human oversight while leveraging AI efficiency. ## Real-World Recovery Story A fintech startup discovered 40% of their codebase was vibe coded. Their recovery: 1. **Audit:** Identified incomprehensible sections 2. **Prioritize:** Critical paths first 3. **Rewrite:** With understanding, not just regeneration 4. **Document:** As they learned 5. **Process:** New AI guidelines established Time invested: 3 weeks Bugs prevented: Countless Team confidence: Restored ## The Cultural Shift Preventing vibe coding requires cultural change: ### From: "How fast can we ship?" ### To: "How well do we understand what we're shipping?" ### From: "AI will handle it" ### To: "We handle it, AI assists" ### From: "Trust the output" ### To: "Verify and understand the output" ## Your Anti-Vibe Coding Checklist Before committing ANY AI-generated code: - [ ] Can I explain every line? - [ ] Could I debug this without AI? - [ ] Would I write something similar manually? - [ ] Have I reviewed for security issues? - [ ] Can my team maintain this? - [ ] Is the approach documented? - [ ] Have I tested edge cases? ## The Sustainable Path AI is incredibly powerful for development, but only when used consciously. The choice is: **Vibe coding:** Fast today, disaster tomorrow **Conscious coding:** Thoughtful today, sustainable forever ## Call to Action 1. **Share this article** with your team 2. **Audit your codebase** for vibe-coded sections 3. **Establish AI guidelines** that prevent vibe coding 4. **Celebrate understanding** over velocity 5. **Remember:** You own all code you ship ## The Bottom Line Vibe coding is technical debt at 50% interest. It feels productive but destroys codebases. The antidote isn't avoiding AI - it's using AI consciously. As one workshop participant concluded: "I thought AI would let me code without thinking. I learned it actually requires thinking MORE, just differently." That's the paradox and the opportunity. --- *Based on patterns observed across multiple enterprise AI adoption workshops. For hands-on training in conscious AI development, visit mindtastic.se* **Related:** "The Context Window Trap" | "Testing AI-Generated Code" | "Personal Responsibility in AI Development" --- ### [Socratic questions: the 2,400-year-old AI development method](https://mindtastic.se/articles/socratic-questions-ai-development-method) The best AI developers don't give instructions — they ask questions. The Socratic method, 2,400 years old, turns out to be the most effective technique for both AI interaction and team development. Here's why inquiry beats instruction. # Socratic questions: the 2,400-year-old AI development method Most developers interact with AI the same way they'd write a ticket: "Do X. Build Y. Fix Z." It works. You get output. But you're leaving most of the value on the table. The developers I train who get the best results — the ones who hit 4-5x productivity — do something different. They ask questions. Not vague questions. Deliberate, open-ended questions that force the AI to bring context they wouldn't have thought to specify. The same technique, it turns out, that transforms how teams think about problems. It has a name. It's 2,400 years old. And it's the most underrated technique in AI-assisted development. ## What Socratic questioning actually is Socrates didn't teach by lecturing. He taught by asking. Open questions — not leading ones — designed to help the other person arrive at insight through their own reasoning. Not "don't you think X is better?" but "what would happen if we approached it this way?" Not giving answers, but creating the conditions for better thinking. The method has three characteristics that matter for AI development: **It's inquiry, not instruction.** You ask what the best approach is. You don't dictate it. **It forces reflection.** The person — or system — being questioned has to evaluate, connect, and reason. Not just execute. **It builds understanding, not dependency.** The insight belongs to the person who arrived at it, not the person who asked the question. > "Istället för att säga vad du ska göra — i planeringsfasen — ställer du sokratiska frågor." ## Applied to AI: questions beat instructions Here's what the difference looks like in practice. **Instruction mode:** "Write a Python function that validates email addresses using regex, handles edge cases, and returns a boolean." **Socratic mode:** "I need to validate email input from a web form. What are the main approaches, and what are the tradeoffs between strict regex validation versus a simpler check-then-verify flow?" The instruction produces exactly what you asked for — nothing more. The Socratic approach produces something you wouldn't have specified: context about tradeoffs, alternative approaches, edge cases you hadn't considered. The AI brings its full training to bear because you gave it room to reason, not just execute. This isn't about being polite to the AI. It's about input curation. What you put into the context window determines what comes out. And a well-formed question puts more useful context into play than a well-formed instruction. In the planning phase — before any code is written — this is where the real leverage is. Instead of "build me X," you ask: - "What's the best architecture for this given these constraints?" - "What are the failure modes I should worry about?" - "If you were reviewing this approach, what would you challenge?" Each question forces the AI to activate different parts of its training. You're not narrowing the output — you're expanding it. And then you select, validate, and decide. That's sharper thinking in practice. ## Applied to people: the same method, the same result Here's where it gets interesting. The exact same technique that makes AI interaction better also transforms how teams develop. I've seen organizations where developers execute tickets but never ask "what does the customer actually need?" The code works. The tests pass. But nobody has thought about whether the thing they built matters. Nobody has ont i magen — nobody feels the weight of the customer's problem in their gut. The root cause, in every case I've encountered, is an instruction-based culture. Specs are written. Tickets are filed. Developers execute. The system is efficient at producing output. It's terrible at producing ownership. The Socratic alternative is simple but uncomfortable: instead of telling someone what to build, you ask them what the system needs. Instead of writing the spec, you ask them to write it — and then ask questions about their choices. Instead of correcting their approach, you ask "what happens if a customer encounters this?" > "Genom att ställa sokratiska frågor så får hon reflektera och fundera. Det gör henne klokare än att jag bara säger till henne." This is slower. Significantly slower, at first. A developer who has spent fifteen years receiving instructions needs time to rebuild the muscle of independent reasoning. An education system that rewards memorization produces people who are brilliant at executing defined tasks and lost when asked to define the task themselves. But the investment compounds. A team that thinks in questions — "why are we building this?" "what does the user actually experience?" "how does this connect to the business?" — is a team that builds ownership. And ownership is the prerequisite for everything that follows. ## Why this connects to sharper thinking AI doesn't reduce cognitive load. It transforms it. You stop writing code and start defining what code should exist. You stop implementing and start validating. You stop building and start reviewing. Socratic questioning is the mechanism that makes this transformation work. When you ask the AI "what's the best approach?" instead of telling it what to do, you're forced to evaluate the response. You need to understand the tradeoffs. You need to decide. That's harder than writing the code yourself — it demands a different kind of thinking. The same applies to leading a team. When you tell someone what to build, the cognitive load is yours. When you ask them what should be built and why, the cognitive load transfers — and with it, the understanding and the ownership. This is why experienced developers get more out of AI than juniors. It's not that seniors write better prompts. It's that seniors ask better questions. They've spent decades building intuition about what matters, what breaks, what customers actually need. That intuition translates directly into better inquiry — both with AI and with people. > "Senior + AI = extraordinary results. Not because of better prompts. Because of better questions." ## The instruction trap There's a pattern I see in organizations struggling with AI adoption. The team treats AI exactly like they treat a junior developer: give precise instructions, expect precise execution, review the output. It works for simple tasks. It fails completely for anything complex. The failure isn't technical. The AI can handle complexity. The failure is that instruction-based interaction produces instruction-shaped output — narrow, literal, exactly what was asked and nothing more. The AI becomes a very fast typist instead of a thinking partner. The same pattern shows up in team dynamics. Organizations that run on instructions — detailed specs, rigid tickets, no room for interpretation — produce teams that execute but don't think. They deliver what was specified, even when what was specified is wrong. Nobody raises their hand because nobody was asked a question. Both failures have the same root: the culture of instruction kills the habit of inquiry. And without inquiry, there's no ownership, no reflection, no growth. ## The compound effect Socratic questioning creates a feedback loop that instruction never can: **With AI:** Better questions → richer responses → better understanding of the problem → even better questions. Each cycle deepens your grasp of the domain and improves the quality of what the AI produces. **With people:** Better questions → deeper reflection → growing ownership → independent thinking → people who ask their own questions. Each cycle builds capability that stays when you leave. **Between both:** The developer who learns to ask Socratic questions of AI starts asking them of themselves. "Why am I building this? What would the customer say? What am I missing?" That internal inquiry is the highest form of the practice — and it produces developers who don't need to be managed, because they manage themselves. This is what we mean when we say AI demands sharper thinking. Not that you need to be smarter. That you need to think differently — and the oldest method in philosophy turns out to be the most modern technique in AI development. ## In practice If you're working with AI today, try this for a week: Before any implementation task, ask the AI three questions instead of giving one instruction. "What approaches would you consider for this?" "What are the risks I should think about?" "If you were reviewing this solution, what would you challenge?" If you're leading a team, try the same: replace one instruction per day with one question. Not a leading question — a genuine one. "What do you think the customer needs here?" "How would you approach this if you had full ownership?" "What would you change about our current process?" The first few days will feel slower. The first few weeks will feel frustrating — people aren't used to being asked, and AI responses to questions are longer than responses to instructions. But by the end of the month, you'll notice something: the quality of thinking around you has changed. Not because you taught anyone anything. Because you asked the right questions. > "Ansvar kan inte delegeras. Men det kan odlas — genom rätt frågor." --- *Based on real experience from AI training workshops and organizational transformation. The Socratic method isn't a technique we invented — it's one we rediscovered when we stopped telling AI what to do and started asking it what to think.* --- ### [Three ways to work with AI output — and why your mix matters](https://mindtastic.se/articles/vibe-coding-vs-ai-orchestration) Most people default to one approach when working with AI output and never question it. There are three legitimate ways — accept, verify, direct — and the skill is knowing which fits the situation in the Software 3.0 era of agentic engineering. Applies equally to code, documents, and analysis. # Three ways to work with AI output — and why your mix matters Most people default to one approach when working with AI output and never question it. Some accept everything without review. Others refuse to trust anything the AI produces. Both extremes miss the point. This article uses code as the primary example — it's where the pattern is most visible and the stakes are clearest. But the same three approaches apply to any AI-assisted knowledge work: document drafts, meeting summaries, analysis, governance recommendations. The underlying principle is the same: your domain expertise determines whether you can tell the difference between good output and plausible-sounding nonsense. There are three legitimate ways to work with AI code — and experienced developers blend them deliberately. The question isn't which approach is correct. The question is whether you've made a conscious choice about your mix. ## Where the term started Andrej Karpathy, former Director of AI at Tesla and OpenAI researcher, introduced the term ["vibe coding"](https://twitter.com/karpathy/status/1757600733376995474) in February 2025: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects." The key phrase: "throwaway weekend projects." Karpathy was describing one valid mode of working — not a methodology for everything. The problem isn't vibe coding itself. The problem is teams applying one approach to every situation without thinking about it. ## Where the framing now lives In the year since Karpathy coined "vibe coding," the broader framing has filled in. Karpathy himself now talks about **Software 3.0** — the era where instructions, context, tools, and models together form a new substrate for building software. Simon Willison and others distinguish **agentic engineering** from vibe coding: vibe coding raises the floor (more people can build something), agentic engineering raises the ceiling (you build faster without dropping quality, security, or accountability). This is the same shift we have been teaching as **AI Orchestration**. The vocabulary is converging. The substance has not changed: you direct, validate, and own — the model produces; you decide whether what it produced ships. Vibe coding is the bottom mode in the three-approach spectrum below. Agentic engineering — what we operate as AI Orchestration — is what carries the structured balance and hardcore planning rows. Same map, public labels. ## Three legitimate approaches Every team that works seriously with AI-generated code ends up somewhere on a spectrum. In our workshops, we see three distinct approaches — all valid, each with its own place: ![Coding approaches compared: vibe coding, standard coding, AI orchestration](/static/images/concept-coding-paradigms.png) | Approach | When it fits | Typical proportion | Key characteristic | |----------|-------------|-------------------|-------------------| | **Vibe coding** | Simple, low-risk tasks; experienced developers who know the domain | 10-20% | Speed over review — you trust your ability to catch problems later | | **Structured balance** | Daily production work; the bulk of real development | 50-70% | Reasonable planning upfront, systematic review of output | | **Hardcore planning** | Complex systems, high-stakes changes, unfamiliar territory | 20-30% | Full documentation and specification before any code is generated | The proportions aren't rules — they're patterns we observe in teams that work effectively. Some weeks are 40% vibe coding because you're prototyping. Some weeks are 80% hardcore planning because you're rebuilding authentication. The point is that you choose deliberately. Ni kommer hitta er egen mix. ## The real shift: from builder to validator The deeper change isn't about which approach you pick. It's about what AI does to how you think. The promise everyone sells is "think less, do more." That's not what happens. What actually happens is that you stop writing and start defining. You stop implementing and start validating. You stop building details and start reviewing systems. None of those things are easier. They're harder. But they're harder in a different way — and that shift is invisible until you actually do it. A senior developer at a client tested AI-assisted development for three days. Same output as manual coding. Same functionality, same quality, roughly the same time. He wasn't faster. He wasn't slower. But he said one thing that stuck: "I had to think in a completely different way." The builder mentality is sequential — you take one step at a time and each step gives you clear feedback. The validator mentality requires holding the entire system in your head simultaneously. You need to understand not just what the code does but what it SHOULD do, and then compare the two. That's why experience matters more with AI, not less. The person who has built systems for twenty years has an advantage that can't be skipped. > "Om du inte tänker hårdare validerar du inte. Om du inte validerar vibe-codar du." ## Conscious friction — the control point IS the work There's a temptation to automate every step. Auto-commits. Auto-generated changelogs. Agents that push code without human review. It looks efficient. It's not. An auto-generated changelog looks professional. It has the right format, the right structure. It's also meaningless — a summary of something nobody reviewed. The moment you automate the documentation of what you did is the moment you stop understanding what you did. Every commit is a promise: I have read this. I understand this. I stand behind this. Remove that moment and you remove the promise. > "Jag vägrar auto-commits... Det ÄR friktion. Och friktionen är medveten." > "Automation tar bort steg. Medveten friktion gör att varje steg räknas." This isn't inefficiency. Conscious friction is slower per step — but every step holds. And the sum of steps that hold is faster than the sum of steps that need to be redone. No auto-commits. No auto-changelogs. No agents pushing unreviewed code. The control point isn't an obstacle on the way to delivery. The control point is the work. ## Experience as the multiplier AI is a catalyst. A catalyst accelerates a reaction — it doesn't create it. If there's nothing to react with, nothing happens, regardless of how effective the catalyst is. A person with decades of experience building systems, delivering to clients, living with the consequences of being wrong — AI makes that person extraordinarily productive. They know what the right answer looks like. They know what looks good but is wrong. They can review, challenge, and steer. A person without that foundation gets output — lots of output — but has no way to know if it's good or bad. And that's worse than having nothing at all, because you believe you have something. > "Du äger varje rad output. Och du kan inte äga det du inte förstår." The three preconditions for working at scale with AI: **Knowledge.** Years of building systems, delivering to clients, living with consequences. This is the foundation AI amplifies. Without it, there's nothing to scale. **Chain.** Voice to text, text to structure, structure to action. Preparation before the meeting, transcript after, project tracking, daily overview. Not one tool — a chain where each step builds on the previous one. **Accountability.** Every line of output passes through you before it leaves the system. This is non-negotiable. More volume without control isn't delivery — it's production of problems. > "AI föreslår. Jag bestämmer. Jag pushar. Ordningen är oförhandlingsbar." ## When each approach breaks down Every approach has failure modes. Knowing them is how you choose deliberately. | | Vibe coding | Structured balance | Hardcore planning | |---|---|---|---| | **Works when** | Simple tasks, known domains, experienced developers, throwaway prototypes | Daily production work, familiar tech stacks, reasonable complexity | Complex systems, unfamiliar territory, high-stakes changes, regulatory requirements | | **Breaks when** | Applied to production systems without review; used by developers who can't validate the output | Requirements are genuinely unknown and need exploration; or when rigidity prevents iteration | Speed matters more than perfection; scope is small; over-documentation becomes busywork | | **Risk** | Security vulnerabilities, technical debt, code nobody understands | False sense of control if reviews become rubber stamps | Paralysis by analysis; documentation that's outdated before code is written | | **Experience required** | High — you need to catch problems intuitively | Medium — systematic process compensates for gaps | Variable — the documentation itself builds shared understanding | ### Security and compliance Regardless of which approach you use, some things are non-negotiable. AI can generate vulnerabilities that aren't obvious during development. Systems handling personal data, payments, or regulatory compliance cannot rely on casual acceptance patterns. GDPR, PCI-DSS, and other compliance requirements demand that someone understands and validates every component. That's true whether you're vibe coding a prototype or executing a hardcore planning process. The question is always: can someone explain what this system does and why? ## The stilts metaphor Working with AI is like learning to walk on stilts. Initially uncomfortable. Unfamiliar. You wobble. It doesn't feel like progress — it feels like regression. But once you find your balance, you see things you couldn't see before. You reach things you couldn't reach. Not because the stilts do the work for you — but because they extend what you're already capable of. Each person finds their own balance. Some lean forward, some lean back. Support each other when someone wobbles. That's what a team does. This is capability building, not a magic shortcut. The stilts don't walk for you. But if you have the foundation — the knowledge, the chain, the accountability — they change what's possible. Varje person hittar sin egen balans. --- *Originally published August 2025. Revised February 2026 to reflect 18 months of production experience and an evolved understanding of the spectrum of approaches.* --- ### [Voice to structured meeting documentation: how core-claude-skills turns recordings into actionable data](https://mindtastic.se/articles/voice-to-structured-meeting-documentation) How the ops and transcript skills turn meeting recordings into actionable, structured data instead of worthless summaries. # Voice to structured meeting documentation: how core-claude-skills turns recordings into actionable data Your meeting summary is worthless. Not because the meeting was bad — because the summary captured structure instead of substance. As Tomas Andre writes in his insights series: > Du hade ett mote igår. Teams Copilot genererade en sammanfattning. Du skummade igenom den, kanske vidarebefordrade den, och tankte att motet var dokumenterat. Det ar det inte. Det du har ar en generisk lista med agendapunkter, namn pa folk som pratade, och ett par atgardsforslag som later rimliga men som missar allt som faktiskt avgjorde vad som hande i det rummet. > > — "Din motessammanfattning ar vardelos" (tomasandre.se) The problem isn't AI-generated summaries. The problem is that generic summaries lose the substance — the tone, the subtext, the pauses that actually determined what happened. You need the full transcription first, then human-directed extraction. ## The solution: full transcription + directed extraction The [core-claude-skills](https://github.com/tandregbg/core-claude-skills) repository provides two complementary skills for this: `/transcript` for personal calls and lightweight processing, and `/ops` — a unified, config-driven meeting processor that handles the full pipeline from transcription to task import. This isn't a summary tool. It's a processing pipeline that preserves everything and then lets you decide what matters. ## How it works ### Step 1: Create the structured summary Feed the transcription to `/ops` (for organizational meetings) or `/transcript` (for personal calls). The skill: - Detects the date from filename or content - Identifies participants and their speaking patterns - Extracts distinct topics as separate sections - Pulls out decisions with ownership - Lists action items with assignees - Preserves the original language (Swedish characters enforced: a, a, o — not anglicized approximations) The output isn't a paragraph of "key takeaways." It's structured markdown: ```markdown # Summary: 260225-samtal - Strategic review ## Topic 1: Q1 delivery status [Extracted content with context preserved] ## Topic 2: Partnership decision [The actual reasoning, not just the conclusion] --- ## Decisions - Decision: Proceed with pilot phase (Owner: Partner, Deadline: March 15) ## Next steps - [ ] Draft pilot scope document (You) - [ ] Schedule technical review (Partner) ``` ### Step 1.5: Link to preparation If you used `/preparation` before the meeting, `/ops` automatically links back to it. The meeting lifecycle is connected — what you prepared for, what actually happened, what comes next. ### Step 2: File organization `/ops` suggests where to save based on your project's routing rules. If your CLAUDE.md defines meeting routing (which folder for which participant or project), it follows those rules. You approve or override. ### Step 3: CHANGELOG update If the target folder has a CHANGELOG, `/ops` adds an entry: ``` - **260225: Transcript** - Strategic review of Q1 deliveries and pilot decision. *(strategy, pilot, Q1, partnership)* -> [260225-samtal.md] ``` One line, searchable keywords, direct link. Over time, this becomes a searchable history of every conversation. ### Step 4: Task import `/ops` detects action items assigned to you and offers to import them into your task tracker: ``` Found 3 action items for you: 1. Draft pilot scope document 2. Send partnership terms to legal 3. Book Q2 planning session Add to task tracker? [yes] no select ``` You choose: import all, skip, or select specific ones. Each task gets a priority, a source link back to the transcript, and enters your task management flow. ## The cascade: from recording to daily workflow This is where it gets powerful. A single meeting recording triggers a cascade: ``` Recording (voice) | v Transcription (text) | v /ops (structured summary + decisions + actions) | +---> CHANGELOG (searchable history) +---> Task tracker (actionable items) | | | v | /daily-dashboard (tomorrow's agenda includes these tasks) | +---> /preparation (next meeting with same person pulls from this transcript) ``` The `/preparation` skill for your next meeting with the same person will pull context from this transcript. The `/daily-dashboard` shows your action items. The CHANGELOG gives you searchable history. Nothing falls through the cracks because nothing stays trapped in a generic summary. For personal calls where you don't need the full pipeline, `/transcript` gives you a clean structured summary without the organizational overhead. ## What this actually costs The transcript processing itself costs cents. The real investment is the 2-3 minutes after each meeting to review the structured output and confirm the task import. That's it. Compare this to the alternative: spending 15-30 minutes writing meeting notes that nobody reads, or relying on an auto-generated summary that misses the substance. ## The deeper principle: voice as raw material > Allt jag sager hamnar i text. Det ar inte en feature. Det ar inte ett verktyg. Det ar ett satt att se pa rost som ramaterial. > > — "Allt jag sager hamnar i text" (tomasandre.se) Every meeting, every call, every walk-and-talk discussion — it's all raw material. The transcript skill is the processing step that turns that raw material into structured, searchable, actionable documentation. The skill doesn't replace your judgment about what matters. It preserves everything so your judgment has complete material to work with. You direct the extraction. You own the output. ## Config-driven behavior `/ops` uses layered configuration — organization configs define team participants, responsibility assignments, terminology, and workflow automation. This means the same skill adapts to different teams. For example, the structured extraction output: ```yaml extraction: date: 2026-02-25 duration: 45 language: sv participants: - name: Person A role: Strategy speaking_share: 60% content: decisions: - decision: Proceed with pilot owner: Person B deadline: 2026-03-15 action_items: - action: Draft scope document owner: Person A priority: P1 ``` This makes transcripts machine-readable. Other skills can process them further — aggregating decisions across meetings, tracking action completion rates, identifying patterns across conversations. ## Try it yourself Both `/ops` and `/transcript` are part of the [core-claude-skills](https://github.com/tandregbg/core-claude-skills) repository. Open source, designed for Claude Code, works with any transcription source — Teams, Zoom, Whisper, or manual transcription. Use `/ops` for organizational meetings (full pipeline with CHANGELOG, task import, dashboard refresh). Use `/transcript` for personal calls (lightweight structured summary). Use `/preparation` before meetings and `/daily-dashboard` for morning overviews. The pattern is simple: record everything, transcribe everything, then use human-directed extraction to pull out what actually matters. Stop trusting generic summaries. Start owning your meeting documentation. --- *Category: Methodology* *Published: 2026-02-26* --- ### [Voice reflection to structured goals: how the goals skill turns thinking into documents that compound](https://mindtastic.se/articles/voice-reflection-to-structured-goals) How the goals skill turns loose thinking into a structured document cascade — from voice reflections to five connected documents. # Voice reflection to structured goals: how the goals skill turns thinking into documents that compound People think about goals loosely. Intentions float around as mental notes, get discussed in passing, maybe written on a sticky note that disappears. Nothing is captured systematically, nothing compounds over time, and every January starts from scratch. The `/goals` skill from [goals-skills](https://github.com/tandregbg/goals-skills) solves this by turning voice reflections into a structured document cascade. You talk through your thinking. The skill processes it into five connected documents — and tells you what you missed. ## The problem: unstructured thinking doesn't accumulate Most goal-setting is a one-time event. You write down intentions at the start of the year, maybe check them quarterly, and by October you've forgotten what you wrote. There's no feedback loop, no structured check-in, and no way to see how your thinking evolves month over month. The deeper issue: the thinking itself is valuable, but it evaporates. A 30-minute reflection about where you are and where you want to go contains insights about priorities, conflicts, energy levels, and blind spots. Without capture and structure, all of that is lost. ## The solution: record, process, complete The monthly goals cycle works in three steps: **Step 1: Record a voice reflection** Using a structured template with 10 areas (emotional state, highlights, challenges, finances, health, relationships, personal growth, career, priorities, looking ahead), you record yourself talking through each area. No writing, no formatting — just honest spoken reflection. The template is designed for speaking aloud: ``` Hur skulle du sammanfatta manaden med tre ord? ... Vilken kansla har dominerat? Lugn, stress, energi, trotthet, hopp, frustration? ... Vad ar du mest nojd med denna manad? ``` You don't need to answer everything perfectly. You don't need to answer everything at all. That's what the next step handles. **Step 2: Process with `/goals process`** Transcribe the recording and run `/goals process`. The skill does two things: 1. Extracts structured data from your reflection into a monthly check-in document (manadsavstamning) — concrete numbers, status updates, progress indicators 2. Generates an ATT KOMPLETTERA section listing everything you didn't cover **Step 3: The ATT KOMPLETTERA pattern** This is the critical differentiator. After processing, the skill tells you exactly what's missing: ``` ATT KOMPLETTERA: - Ekonomi: Inga siffror namndes. Komplettera med skuld start/slut, budget - Halsa: Traning namndes men inga specifika siffror. Antal pass? Vikt? - Karriar: Inget namndes om Q2-planer. Komplettera med malsattning ``` You record a supplementary reflection addressing the gaps. Process again. The skill fills in what was missing. This iterative completion ensures the final documents are comprehensive without requiring you to remember everything in one take. ## Five document types from a single recording A single monthly voice reflection cascades into five connected documents: ### 1. Manadsavstamning (monthly check-in) Concrete data extracted from your reflection: financial numbers, health metrics, relationship status, career progress. Structured as a table with measurable values, not paragraphs of feelings. ```markdown ## Ekonomi | Aspekt | Varde | |--------|-------| | Skuld vid manadens start | 450 000 kr | | Skuld vid manadens slut | 425 000 kr | | Forandring | -25 000 kr | | Pa ratt spar mot malet? | [x] Ja | ## Halsa | Aspekt | Varde | |--------|-------| | Antal traningspass | 12 | | Langsta lopning | 8 km | ``` ### 2. Manadsreflektion (monthly reflection) The qualitative companion to the check-in. Captures the thinking, the emotional state, the insights that numbers can't express. This is where you notice patterns — "third month in a row where energy drops mid-month" or "career satisfaction consistently tied to autonomy, not title." ### 3. Manadsinspiration (monthly inspiration) Goals and aspirations extracted from the reflection, organized by life area. Not a to-do list — an articulation of what you're working toward next month and why. Updated monthly, it shows how your aspirations evolve. ### 4. Arsplan (yearly plan) The annual document that aggregates monthly reflections into a coherent year plan. Updated each month based on new check-in data. By month 6, your yearly plan reflects actual reality, not January's optimistic guesses. ### 5. Arlig reflektion (yearly reflection) An annual deep-dive guided review. Fed by 12 months of monthly data, this isn't starting from scratch — it's synthesizing a year of structured thinking into lessons and direction for the next year. ## The cascade flow ``` Voice recording (monthly, 20-40 min) | v Transcription | v /goals process | +---> Manadsavstamning (concrete data) +---> ATT KOMPLETTERA (gap detection) | | | v | Supplementary recording | | | v | Completed manadsavstamning | +---> Manadsreflektion (qualitative insights) +---> Manadsinspiration (next month focus) +---> Arsplan (updated yearly plan) | v After 12 months: Arlig reflektion (yearly synthesis) ``` Each month builds on the previous. The January check-in establishes baselines. February shows trajectories. By June, you have enough data to see real patterns. By December, the yearly reflection writes itself because the data is already structured and tracked. ## Why voice, not writing Writing about goals activates your editor brain. You self-censor, you polish, you write what sounds good rather than what's true. Speaking bypasses that filter. > Kod. Projektdokumentation. Offerter. Avtal. Sammanfattningar. Motesanteckningar. Det ar allt text. Och text ar data. Data kan processas. > > — "Text ar data" (tomasandre.se) Voice is the most natural form of reflection. Transcription turns it into text. Text is data. Data can be processed into structure. The goals skill is the processing step. You don't need to be articulate or organized when speaking. The skill handles organization. You just need to be honest. ## The compound effect Month 1: You have a check-in and a reflection. Useful but not transformative. Month 3: You start seeing patterns. "My energy correlates with exercise frequency" or "financial stress drops when I track weekly." Month 6: Your yearly plan is grounded in reality. Aspirations that aren't progressing get honest reassessment. Things that are working get more investment. Month 12: The deep yearly reflection has 12 months of structured data to synthesize. You're not guessing about the year — you're analyzing it. This compounding only works because the data is structured consistently. Free-form journal entries can't be compared month-over-month. Structured documents with consistent fields can. ## Practical: getting started The [goals-skills](https://github.com/tandregbg/goals-skills) repository includes: - The `/goals` skill for Claude Code (process, guide, and template modes) - Monthly reflection template (designed for voice recording) - Monthly check-in template (structured data extraction) - Monthly inspiration template (next month focus) - Yearly plan template - Yearly reflection template After saving any document, cascade updates automatically offer to create or update related files — progressing from monthly reflection through check-in, inspiration, and annual plan. The monthly cycle takes about 45 minutes total: 20-30 minutes recording, 5 minutes processing, 10 minutes reviewing and completing gaps. That's less time than most people spend thinking about goals without capturing anything. Start with one month. See what the structured output reveals about your own thinking. The ATT KOMPLETTERA section alone — seeing what you consistently avoid talking about — is worth the exercise. --- *Category: Methodology* *Published: 2026-02-26* --- ### [Beyond prototypes: why everyone demos but nobody ships](https://mindtastic.se/articles/beyond-prototypes-production-first-ai-development) AI makes the first 10% of any initiative effortless. The 90% that delivers real value requires existing expertise to even know what needs building. The demo trap isn't a developer problem — it's an organizational pattern. # Beyond prototypes: why everyone demos but nobody ships Why does everyone only talk about prototypes but no one goes to production? The pattern is consistent across development teams, consulting projects, and organizational AI initiatives: beautiful prototypes that wow stakeholders, then months of silence while teams struggle with the 90% of work that actually matters. AI makes it trivially easy to produce something impressive. It cannot substitute for the domain knowledge needed to make it real. ## The demo trap I keep seeing Here's what I keep running into: AI tools make prototypes ridiculously easy. A nice UI in 5 minutes, some AI magic, and suddenly everyone thinks they're done. But that pretty interface? It's maybe 10% of the real work. The missing 90% is everything that makes software actually usable. Security that doesn't leak data when real users touch it. Error handling for when things inevitably break. Authentication so the right people get in and the wrong people stay out. Monitoring so you actually know when it fails instead of finding out from angry users. Backup systems so you don't lose everything when something goes wrong. Teams can prototype anything but can't ship anything. They're stuck in demo mode while competitors actually deliver working solutions to real customers. ## What I learned building production AI Production-ready systems require a fundamentally different approach. The difference lies in starting with production requirements that go far beyond just backend code, combined with deep understanding of how infrastructure actually works. You can't build real infrastructure with fancy UI tools - you need to understand servers, databases, networking, deployment pipelines, and monitoring systems. AI helps implement what needs to be done, but someone has to know what needs building. Cloud infrastructure that scales automatically, but only because I understand load balancing and auto-scaling concepts. Real user authentication that works across devices, because I know how OAuth and session management actually function. Proper database design that handles actual load, because I understand indexing, normalization, and query optimization. Error logging and recovery systems, because I know what failure modes to watch for. My approach to AI-assisted development requires thinking complete production deployment based on real infrastructure knowledge. Not "how can I make this look cool" but "how will real users access this securely, and what needs to be in place for 24/7 reliability." The AI executes the implementation, but I have to know what needs to be built. ## The knowledge problem that breaks everything Here's what happens constantly: teams use AI tools that generate pretty interfaces, but they don't understand what they're actually building. They click buttons in fancy UI tools and think they're deploying to "production," but they have no idea how the underlying systems actually work. You can't direct what you don't understand. If you don't know how databases, servers, networking, and deployment actually function, then AI just becomes an expensive way to create sophisticated-looking failures. The fancy UI tools can't teach you what you need to know about load balancing, security models, or failure recovery. Working with AI for real development requires real knowledge. Complex infrastructure can only be implemented effectively when someone understands what needs to be implemented. This includes knowing what components are required, how they interact, what can go wrong, and how to fix it. The AI executes, but you have to bring the knowledge. And here's what AI can't do for you: it can't tell you what you don't know. If you lack the experience to recognize a bad architecture decision, AI will happily build that bad architecture for you, fast. ## The accountability principle that changes everything The developer is personally responsible for everything that's output. This cuts through all the hype. Every line of AI-generated code is YOUR responsibility. Every security hole, every failed integration, every broken workflow - that's on you, not the AI. Once you accept this responsibility, you stop treating AI like magic and start treating it like a powerful tool that amplifies your existing expertise. But if you don't have the expertise to begin with, AI just amplifies your ignorance faster. ## Production examples from my projects The difference between prototype and production thinking becomes clear in real systems: **Project management platform**: Prototype = pretty dashboard. Production = voice-to-database integration, user auth, audit trails, real-time sync. **Event registration**: Prototype = sign-up form. Production = payment processing, capacity management, refund handling, compliance features. The prototype gets the meeting, but the production system gets the business. ## My production-first rules These are the non-negotiable principles I follow: 1. **Start with production requirements** - Who are the real users? What happens when it breaks? 2. **Choose tools for shipping, not demos** - Can it handle security? Does it scale? Can you maintain it? 3. **Validate everything** - AI suggests, I verify, I take responsibility 4. **Plan for failure** - Monitoring, logging, recovery from day one 5. **Ship early, iterate based on real feedback** - Not theoretical requirements ## The competitive advantage While everyone else is stuck in prototype mode, production-first teams are shipping. They're getting real user feedback, building trust, solving actual problems. I've seen companies gain massive advantages simply by being the ones who actually deliver working software instead of impressive demos. ## Breaking the cycle The fix isn't complicated. Celebrate deployments, not demos. Measure success by actual users, not prototype features. Invest in production infrastructure instead of just demo tools. Reward teams for solving real problems, not creating impressive presentations. There are no shortcuts. You can't shortcut security, reliability, or user experience. But you can use AI to handle the implementation work while keeping production quality - if you know what you're doing. The question isn't whether you can build an impressive prototype with AI. The question is: can you ship it to production where it actually matters? --- *Based on 6 months of AI implementation work and real production deployments* *Published: August 2025* --- ### [The AI consistency illusion](https://mindtastic.se/articles/ai-consistency-problem) AI will never give you the same answer twice. Organizations that don't understand this build systems, workflows, and processes on a foundation that doesn't exist. The consistency assumption is the most expensive myth in AI adoption. # The AI consistency illusion One of the most dangerous myths about AI is that it behaves like traditional software. Business leaders, developers, analysts, document professionals — across every role I train — I see the same pattern: people assume that giving AI the same input will produce the same output. This assumption leads to costly failures regardless of where in the organization AI is being used. *"Is AI consistent - uh no! If I send in the same question 3 times - do I get the same answer - uh.. no!"* ## The consistency trap I see everywhere Here's what I keep running into across AI implementations: teams use AI to generate code, then treat it like magic. They deploy without understanding, debug without context, and blame the AI when things break. But AI doesn't take responsibility. AI doesn't get fired when systems fail. You do. The inconsistency isn't a bug that will be fixed in the next version. It's fundamental to how these systems work. Large language models are designed for creativity and variation, not deterministic precision. They use randomness to prevent robotic responses, which means the same prompt can produce different outputs depending on the model's internal state. And let me be clear about what this means: AI cannot give you repeatable results the way a database query or a calculation can. If you need deterministic output, AI is the wrong tool. Full stop. *"In the 1980s they said 'garbage in, garbage out' - is it different with AI? ... uh no!"* The garbage-in-garbage-out principle has evolved into something more dangerous. Traditional systems gave predictable errors that you could debug systematically. AI systems generate plausible but potentially incorrect answers that can fool even experienced professionals. I've seen it happen to smart people who should know better - including myself. ## What this means for production systems If you're building AI systems, you'll discover that consistency expectations don't scale. What works reliably for small, controlled experiments often falls apart when deployed across larger, more complex business processes. In automated customer service, identical inquiries may receive different quality responses. For content generation, the same brief can produce varying levels of accuracy. In data processing workflows, identical datasets may yield different insights. *"AI today still makes many mistakes and works best in small projects"* The validation crisis hits because traditional quality control assumes predictable behavior. When AI produces different outputs for identical inputs, standard testing approaches become inadequate. You need entirely new frameworks for ensuring reliability - and most teams don't have them yet. ## How I manage inconsistency I've learned to acknowledge inconsistency upfront and design systems to handle it. This means building in confidence scoring that helps prioritize human validation efforts, multiple validation layers with different expertise requirements, fallback mechanisms for when AI outputs are unreliable, and continuous monitoring to identify when performance degrades. The most effective approach I've found treats AI as a powerful but unreliable assistant rather than a replacement for human expertise. This means designing workflows where human oversight is efficient rather than burdensome, building systems that gracefully handle AI failures, and setting realistic expectations about what AI can actually deliver consistently. Expert validation becomes essential, not optional. You need domain knowledge to spot plausible but incorrect outputs, technical understanding to recognize when AI has misinterpreted requirements, and business context to evaluate whether recommendations make sense. ## The business reality Understanding AI inconsistency changes how you should approach AI adoption. Rather than expecting immediate productivity gains from replacing people, I recommend focusing on augmentation scenarios where human expertise guides and validates AI outputs. Yes, validation takes time. But the consequences without it are severe. Production failures that take days to fix. Data corruption that destroys user trust. Security breaches that cost millions. Projects abandoned because they're unreliable. The teams that succeed with AI are those that embrace its inconsistency as a design constraint rather than fighting against it. They build systems that harness AI's creative potential while maintaining the reliability their work requires. ## Breaking the consistency illusion *"There are no shortcuts there"* applies directly to consistency expectations. You cannot shortcut the work of understanding AI limitations, building appropriate validation systems, and maintaining human expertise for oversight. The teams that learn to work with AI's inconsistency productively will outperform those that waste time trying to eliminate it. This means building systems that work with AI's nature rather than against it, and finding the sweet spot where AI creativity enhances rather than undermines reliability. --- *Based on 6 months of AI consistency challenges and validation frameworks* *Published: August 2025* --- ### [The context window illusion](https://mindtastic.se/articles/context-window-illusion) AI marketing focuses on massive input capacity while hiding the real constraint: severely limited output capacity that breaks professional workflows. # The context window illusion AI marketing focuses on massive input capacity while hiding the real constraint that breaks professional workflows: severely limited output capacity. I've watched teams make adoption decisions based on impressive context window numbers only to discover they can't get the complete outputs their work requires. *"You can feed in as much as you want, but you don't get as much back out"* ## The marketing deception I keep seeing Every AI announcement emphasizes input capacity. Claude Sonnet 4.0 promotes 1 million token context windows. Gemini claims 1 million token processing. GPT-5 markets 400,000 token capacity. These numbers sound impressive and suggest AI can handle vast amounts of information to produce equally comprehensive outputs. But that's the deception. Large input capacity doesn't equal large output capacity. Teams assume they can provide comprehensive context and receive equally comprehensive responses. This assumption leads to disappointment when AI systems provide fragmented, incomplete outputs that require manual assembly. *"Marketing focuses on how much you can stuff in, not on how much you get out"* ## The fragmentation problem that breaks workflows Real professional work requires substantial, coherent outputs. Complete code modules need 3,000-8,000 tokens. Business reports require 5,000-15,000 tokens. Technical documentation needs 8,000-25,000 tokens to cover topics thoroughly. *"ChatGPT stops after 2,000-4,000 tokens with 'Continue generating'"* This output limitation transforms seamless content creation into fragmented assembly. You end up managing multiple continuation requests, each introducing inconsistencies in tone, style, or logic. Important details get lost between fragments. Cross-references break. Arguments lose coherence across continuations. Each continuation operates with reduced context awareness. The AI forgets earlier sections when generating later parts, leading to repetition, contradiction, or logical gaps. Professional documents require consistency that the continuation mechanism undermines. And here's what nobody tells you: AI can't warn you when it's losing coherence. It will confidently produce the fifth continuation as if it remembers everything from the first - even when it clearly doesn't. ## The hidden cost reality *"Costs jump 10-100x from UI testing to API production"* I typically see teams explore AI using free web interfaces that seem promising for simple tasks. When they attempt production workflows requiring substantial outputs, they discover web interfaces can't deliver complete responses. This forces expensive migration to API solutions. The cost shock occurs because API pricing scales with actual token usage rather than session-based web pricing. Workflows that seemed economical during testing become prohibitively expensive when implemented through APIs charging for full token volume. ## My output-first evaluation approach Understanding output limitations changes how I evaluate AI tools. Rather than being impressed by context window marketing, I test output capabilities under real conditions. *"Choose tools based on output capacity, not context window marketing"* Different systems show significant variation in practical output capacity. ChatGPT's web interface typically stops around 4,000 tokens. Claude can often reach 8,000-10,000 tokens in single responses. Gemini sometimes allows 30,000+ token outputs. GPT-5 promises up to 128,000 output tokens, though real-world performance remains to be tested. These practical limits matter more than theoretical specifications. I design workflows that account for output limitations rather than fighting them. This means breaking large tasks into appropriately sized segments that individual AI responses can handle completely. ## The real value framework AI excels at tasks where 2,000-8,000 tokens provide complete, actionable outputs. Code functions, brief analyses, summary reports, focused explanations. These tasks leverage AI's strengths without hitting output problems. AI struggles with tasks requiring extensive coherent outputs like comprehensive documentation, book-length content, or complex multi-part analyses. These tasks either require significant workflow adaptation or may not suit current AI capabilities at all. ## Breaking the illusion *"Next time you see AI marketing focused on massive context windows, ask: 'But how much can it actually write?'"* The context window illusion represents a fundamental mismatch between how AI is marketed and how it performs in professional workflows. If you base decisions on input capacity marketing rather than output reality, you're setting yourself up for disappointment and unexpected costs. Output capacity, not input capacity, determines real-world AI value. The sooner you accept that, the sooner you'll build workflows that actually work. --- *Based on 6 months of AI output limitations and workflow adaptations* *Published: August 2025* --- ### [Why developer accountability cannot be automated](https://mindtastic.se/articles/ai-validation-imperative-developer-accountability) Why some AI implementations succeed while others fail spectacularly — the difference is whether someone takes real responsibility for what comes out. # Why developer accountability cannot be automated Why do some AI implementations succeed while others fail spectacularly? The developer is personally responsible for everything that's output. I see this pattern consistently - beautiful AI-generated code that impresses stakeholders, then catastrophic failures when no one validates what actually got deployed. The difference isn't the AI. It's whether someone takes real responsibility for what comes out. ## The responsibility gap I see everywhere Here's the pattern I keep running into: teams use AI to generate code, then treat it like magic. They deploy without understanding, debug without context, and blame the AI when things break. But AI doesn't take responsibility. AI doesn't get fired when systems fail. AI doesn't answer to users when data gets corrupted. You do. ## My validation framework from real projects Real validation requires systematic approaches. Processing 34 database changes from a single meeting requires validating every single one before it touches the database. I use three validation layers that each catch different problems. The technical check asks whether the code actually works and is secure. The business check verifies it solves the right problem and fits constraints. The reality check determines whether real users will actually be able to use this thing. Each layer catches different problems. Skip any layer, and you're gambling with production. ## The confidence scoring that saves projects You should have reasoning and you should have a confidence score. This principle has transformed how I work with AI. Every AI output should tell you what it's proposing, why it thinks this is right, how confident it is (0-100%), what could go wrong, and what alternatives exist. My decision rules are straightforward. For 90-100% confidence, quick review is usually sufficient. For 70-89% confidence, detailed review is required. For 50-69% confidence, significant changes are needed. Below 50% confidence, I start over with my own thinking. ## The hallucination reality Hallucinations are usually bad prompting, not AI failure. Better prompting helps, but let me be honest: hallucinations still happen regardless. AI can generate code that looks perfect but has subtle bugs, database queries that run but return wrong results, and integration patterns that work in isolation but fail in production. The scary part? They all look convincing. Only domain expertise catches them. AI cannot tell you when it's wrong - that's fundamentally not how these models work. ## My risk-based oversight system Not everything needs the same level of checking. I match oversight to risk levels. Low risk tasks can be automated with monitoring and include data processing routines, standard reports, and simple calculations. Medium risk tasks require human approval and include database changes, security updates, and user-facing features. High risk tasks should be human-driven with AI help and include architecture decisions, business logic changes, and anything touching money or personal data. ## Workflow that doesn't slow you down The key insight I've found: validation should speed you up, not slow you down. My approach is straightforward. AI suggests, clearly marked with confidence. I decide with full context. Everything gets logged for learning. Quick rollback if something breaks. Metrics track both speed and quality. When done right, human oversight catches problems early instead of in production. That's faster, not slower. ## The real cost-benefit Yes, validation takes time. But the consequences without it are severe. Production failures that take days to fix. Data corruption that destroys user trust. Security breaches that cost millions. Projects abandoned because they're unreliable. Validation overhead pays for itself the first time it prevents a major failure. ## My practical rules These are the rules I follow in every project: 1. **Never deploy AI output without understanding it** 2. **Always have rollback plans** 3. **Log everything for learning** 4. **Match oversight to risk level** 5. **Design validation to speed up, not slow down** The principle is simple: AI suggests, I decide, I take responsibility. AI can be used for optimization, but human oversight matters because these tools make mistakes - confidently and convincingly. The future isn't AI replacing developers. It's developers getting smarter about using AI responsibly. --- *Based on 6 months of AI validation successes and failures* *Published: August 2025* --- ### [The context window myth: why 1 million tokens is mostly marketing](https://mindtastic.se/articles/context-window-myth-exposed) Why massive token counts are mostly marketing — and what actually matters for professional AI use. # The context window myth: why "1 million tokens" is mostly marketing ## I'm tired of the hype *"Jag är så trött på att höra om miljontals tokens."* (I'm so tired of hearing about millions of tokens.) Every AI announcement is the same: "Now with 1 MILLION token context window!" The numbers keep getting bigger. The marketing gets louder. And users keep experiencing the same frustration: "Why did my AI forget what I told it 5 minutes ago?" Let me explain what's actually happening - and why the big numbers are mostly irrelevant. --- ## The marketing trick nobody explains When Google announces Gemini's 1 million token context, or Claude promotes 200k tokens, they're technically telling the truth. You CAN input that much text. But here's what they conveniently omit: **Input capacity ≠ useful processing capacity** It's like a library that accepts a million books but can only read three at a time. The shelf space is real. The reading comprehension isn't. *"Du kan stoppa in hur mycket du vill, men du får inte ut lika mycket."* (You can stuff in as much as you want, but you don't get as much out.) --- ## The three lies of context window marketing ### Lie 1: "More tokens means better understanding" **Reality:** AI models don't "understand" your context linearly. Information in the middle of very long contexts often gets lost. Research shows that retrieval accuracy can drop by 30-50% for information buried in the middle of maximum-length contexts. The AI is optimized to pay attention to: - The very beginning - The very end - Whatever seems most recent Everything in between? It's there, technically. Used effectively? Often not. ### Lie 2: "You can work with entire codebases/document sets" **Reality:** You can INPUT entire codebases. The AI will produce outputs of 4,000-8,000 tokens regardless. That's about 3-6 A4 pages. So you feed it 750 pages of documentation. You get back 5 pages of response. Was it reading all 750 pages when generating that response? Mostly not - it was statistically sampling from patterns. ### Lie 3: "The free/cheap tier gives you a real AI experience" **Reality:** Free tiers have ~4k tokens. That's 3 A4 pages total - including your question AND the AI's answer. *"Gratis ger gratis resultat."* (Free gives free results.) People evaluate AI on free tiers and conclude "AI is overhyped." No - you're testing a race car in first gear with the parking brake on. --- ## What actually happens in your context window Let me be concrete about what "senildemens" (dementia) looks like in practice: **Tokens 1-1,000:** AI remembers everything. Sharp, coherent, follows instructions perfectly. **Tokens 1,000-5,000:** Still good. Minor inconsistencies might appear. **Tokens 5,000-20,000:** AI starts "drifting." Earlier instructions begin to fade. You notice it contradicting itself occasionally. **Tokens 20,000+:** Active degradation. The AI may directly contradict its earlier statements. Complex instructions from the beginning? Gone. This happens on EVERY tier. The only difference is how quickly you hit the cliff. | Tier | How fast you hit the wall | |------|---------------------------| | Free | 10-15 exchanges | | $20/month | 20-30 exchanges | | $200/month | 50-100 exchanges | | API max | 200+ exchanges (still happens) | --- ## The output capacity deception This is what makes me genuinely frustrated. Vendors brag about INPUT capacity while hiding OUTPUT limits. Every major model, regardless of context window size: - **ChatGPT:** ~4,000 tokens output max - **Claude:** ~8,000-10,000 tokens output max - **Gemini:** ~30,000 tokens output max (claims) You can't get a 100,000 token summary. You can't get a complete 500-page analysis. The output tap is limited regardless of how big the input bucket is. *"Marketing focuses on how much you can stuff in, not on how much you get out."* --- ## The 2-document precision loss that nobody talks about From my production work, here's what I consistently see: **On a free tier (~4k tokens):** - Upload 1 short document → Works okay - Upload 2 documents → **Immediate 25% precision loss** - Upload 3 documents → AI starts conflating them, mixing up facts **On a paid tier (~32k tokens):** - 1-2 documents → Good - 3-5 documents → Precision drops noticeably - 5+ documents → You need the expensive tier This isn't theoretical. I've measured this across dozens of client projects. The "2 documents = -25% precision" pattern is remarkably consistent. --- ## What vendors won't tell you **About context windows:** - Bigger isn't always better - attention degrades over length - The "middle" of long contexts often gets ignored - Performance benchmarks are run on optimal content, not your messy real-world data **About pricing:** - Free tier is designed for addiction, not evaluation - $20/month is a loss leader - they want you on $200/month - Enterprise pricing is often 50x the capability for 5x the price **About "unlimited" claims:** - There's no unlimited - there are just larger limits - "Fair use policies" kick in faster than you think - Heavy users get throttled without warning --- ## What you should actually do Stop chasing bigger context windows. Start designing for the reality. ### Accept the constraints - AI has memory limits. This won't change fundamentally. - More tokens don't solve the attention problem. - Output capacity is the real bottleneck. ### Design workflows accordingly 1. **Break tasks into focused chunks** - Don't try to do everything in one conversation 2. **Start fresh frequently** - New task = new conversation 3. **Summarize as you go** - Ask the AI to condense before continuing 4. **Front-load critical context** - Most important stuff goes at the START ### Budget honestly If you need professional results: - **Minimum:** ~220 kr/month per person - **Realistic:** ~2,200 kr/month per power user - **Production systems:** 500-5,000 kr/day API costs *"Det kostar detta mycket."* (It costs this much.) --- ## Your responsibility Here's what the vendors will never tell you: **You are responsible for understanding these limits.** When the AI "forgets" your instructions, that's not the AI failing. That's you exceeding the tool's capabilities. When quality degrades mid-conversation, that's not a bug. That's architecture. *"Du äger varje rad output. Du måste förstå verktygen."* (You own every line of output. You must understand the tools.) AI is not magic. Context windows are not unlimited memory. The million-token marketing is mostly irrelevant to your actual work. The sooner you accept this, the sooner you'll get real value from AI. --- ## The bottom line Next time you see a vendor announce a bigger context window, ask these questions: 1. What's the OUTPUT limit? 2. How does attention degrade over length? 3. What happens with realistic, messy content (not benchmark-optimized text)? 4. What's the real pricing at production scale? If they can't answer, they're selling you marketing, not capability. *Verktyg, inte magi.* (Tool, not magic.) --- *See also: [Context Window Economics](/resources/context-window-economics.md) for detailed tier comparisons and practical guidance.* --- *Based on 30 years of production development and 2+ years of intensive AI workflow development* *Published: December 2025* --- ### [The AI pricing lie: why free is a trap and $20/month isn't enough](https://mindtastic.se/articles/ai-pricing-lie-free-trap) Why free AI tools are a trap and consumer-tier subscriptions fall short for professional production work. # The AI pricing lie: why free is a trap and $20/month isn't enough ## Let me be brutally honest *"Alla vill ha gratis. Och sedan blir de besvikna."* (Everyone wants free. And then they get disappointed.) I've lost count of how many organizations I've seen follow the same path: 1. Try free ChatGPT 2. Get excited about the demos 3. Try to use it for real work 4. Get frustrated with limitations 5. Conclude "AI doesn't work" The problem isn't AI. The problem is the pricing model is designed to get you hooked on something you can't actually use. --- ## The free tier trap ### What free actually gives you - ~4,000 tokens of context (3 A4 pages) - Older, weaker model versions - Throttled during peak hours - Rate limits that kick in fast - Your data used for training ### What free is designed to do Make you think AI is magic so you upgrade. The demos work because they're simple. Ask ChatGPT to write a poem? Magic. Ask it to summarize your 50-page report? *"Sorry, I can't process files that large."* *"Gratis ger gratis resultat."* (Free gives free results.) --- ## The $20/month illusion "Just upgrade to Plus! Problem solved!" No. Here's what $20/month (~220 SEK) actually gets you: ### What you gain - Access to newer models (GPT-4, etc.) - Larger context window (~32k tokens) - Priority access during busy times - Some advanced features ### What you still don't get - Unlimited usage (fair use policy kicks in) - Professional-grade context (still limited) - API access for integration - Data training opt-out by default - Consistent performance for heavy use ### The hidden ceiling Most $20/month users hit the limit within their first serious project. Then they see: - "You've reached your usage limit. Please wait." - "Switching to a slower model due to high demand." - Context window still filling up after 20-30 exchanges **The $20/month tier exists to convert free users, not to support professional work.** --- ## The cost shock nobody warns you about Here's what I see constantly in organizations: ### The evaluation phase "We tested ChatGPT and it works great! Let's roll it out to the team." Cost during evaluation: 0-220 SEK/month per tester ### The reality phase "Wait, why can't it handle our documents? Why is it forgetting context? Why is the API bill so high?" **Actual cost for professional use:** | Use case | Free | $20/mo | What you actually need | Reality cost | |----------|------|--------|----------------------|--------------| | Individual research | OK | Better | Sufficient for light use | 220 SEK/mo | | Document analysis | Breaks | Struggles | $200/mo tier | 2,200 SEK/mo | | Team deployment | Impossible | Limited | API access | 5,000-50,000+ SEK/mo | | Production integration | Impossible | Impossible | API + infrastructure | 10,000-200,000+ SEK/mo | The jump from "testing" to "production" is 10-100x in cost. Nobody tells you this upfront. --- ## The enterprise pricing trap "Just get enterprise! It solves everything!" Let me explain enterprise AI pricing reality: ### The base cost - Platform fees: 5,000-50,000 SEK/month before usage - Per-user licensing: 200-500 SEK/month per seat - Setup and integration: 50,000-500,000 SEK one-time - Support/SLA: 10-20% of total cost annually ### The usage cost - Per-token pricing that scales with actual use - Context window costs that multiply with document size - API calls that add up faster than you expect ### What they don't tell you Enterprise gives you the same models that are available on API. You're paying 50x for: - A nicer admin console - Contract terms instead of click-through - Support SLAs - Compliance checkboxes Is that worth 50x the cost? For some organizations, yes. For most, API access with proper contracts would suffice at 10% of the cost. --- ## The real pricing math Let me show you what AI actually costs at different scales: ### Individual professional (consultant, analyst) **Minimum viable:** 220-440 SEK/month - Claude Pro or ChatGPT Plus - Works for 80% of individual tasks - Will hit limits on complex projects **Actually comfortable:** 2,200+ SEK/month - Claude Pro + API credits for heavy work - Or ChatGPT Pro ($200/month tier) - Handles professional document work ### Small team (5-10 people) **Budget version:** 1,100-2,200 SEK/month total - Shared API access - Careful usage management - Will frustrate heavy users **Working version:** 10,000-25,000 SEK/month - Individual accounts for heavy users - API pool for programmatic use - Buffer for usage spikes ### Organization (50+ users) **Don't even try** to do this on consumer subscriptions. **Realistic:** 50,000-200,000+ SEK/month - Mix of user licenses and API access - Proper enterprise agreements - Integration infrastructure - Usage monitoring and optimization --- ## What vendors hide in fine print ### "Unlimited" isn't Every "unlimited" AI plan has a fair use policy. Hit it and you get: - Slower models - Rate limiting - "Please try again later" messages - Silent quality degradation ### Output limits exist regardless of input You can pay for 1 million token context windows. Output is still capped at 4,000-30,000 tokens per response. Always. ### Pricing changes without warning API costs have changed multiple times. What cost X yesterday might cost 2X tomorrow. Budget accordingly. ### "Free" has a cost When the product is free, you are the product. Your data trains their models. Your usage patterns inform their pricing strategy. --- ## How to actually budget for AI ### Step 1: Define what you actually need Don't budget for "AI." Budget for specific outcomes: - Document analysis: X documents per month - Writing assistance: X hours saved per week - Code generation: X features per sprint - Customer support: X queries per day ### Step 2: Calculate realistic costs | Task type | Per-task cost | Monthly volume | Monthly cost | |-----------|--------------|----------------|--------------| | Simple Q&A | ~0.01 SEK | 1,000 | 10 SEK | | Document summary | ~0.50-2 SEK | 100 | 50-200 SEK | | Long analysis | ~2-10 SEK | 50 | 100-500 SEK | | Code generation | ~1-5 SEK | 200 | 200-1,000 SEK | Add 50% buffer for iteration and errors. ### Step 3: Plan for the real tier | Your need | Budget minimum | What to buy | |-----------|----------------|-------------| | Exploration | 0 | Free tiers (accept limits) | | Individual professional | 220 SEK/mo | Claude Pro or similar | | Heavy individual use | 2,200 SEK/mo | Pro tiers + API credits | | Team use | 10,000+ SEK/mo | API access + management | | Enterprise | 50,000+ SEK/mo | Proper enterprise agreement | --- ## The subscription vs API decision ### Subscriptions ($20-200/month per user) **Good for:** Individual exploration, light professional use **Bad for:** Heavy use, integration, team scaling ### API access (pay per token) **Good for:** Production use, integration, predictable scaling **Bad for:** Unpredictable usage, individual casual use ### The hybrid approach (what actually works) 1. Subscriptions for exploration and light users 2. API access for power users and production 3. Enterprise agreement for compliance requirements (if needed) Don't let vendors push you to enterprise when API + proper contracts would suffice. --- ## Your responsibility *"Det kostar detta mycket. Acceptera det eller gör något annat."* (It costs this much. Accept it or do something else.) AI isn't free. Professional results require professional investment. The vendors aren't lying - they're just not volunteering the full picture. **What you must accept:** - Free is for testing, not evaluation - $20/month is entry-level, not professional - Production use costs 10-100x what testing costs - Enterprise pricing is often 50x API pricing **What you must do:** - Budget based on outcomes, not marketing - Plan for the tier you'll actually need - Build in buffer for usage growth - Negotiate contracts, don't just click through AI is a tool. Tools cost money. *Verktyg, inte magi.* --- ## The bottom line Next time a vendor shows you a demo on their free tier, ask: 1. What tier do I need for this to work with my actual documents? 2. What's the monthly cost at 10x this usage? 3. What happens when I hit fair use limits? 4. What's in your Terms of Service about data usage? If they can't answer clearly, walk away and find a vendor who will. --- *See also: [Context Window Economics](/resources/context-window-economics.md) for understanding the technical constraints behind these pricing tiers.* --- *Based on 30 years of production development and watching organizations get burned by AI pricing surprises* *Published: December 2025* --- ### [The AI security paradox: what nobody warns you about multi-component architectures](https://mindtastic.se/articles/ai-security-architecture) What nobody warns you about the security consequences of multi-component AI architectures in production. # The AI security paradox: what nobody warns you about multi-component architectures ## Let me tell you what keeps me up at night *"Alla pratar om AI-möjligheter. Nästan ingen pratar om säkerhetskonsekvenserna."* (Everyone talks about AI opportunities. Almost no one talks about the security consequences.) I've watched organization after organization rush to deploy AI, connecting multiple services, sending data everywhere, and then being shocked - SHOCKED - when security problems emerge. Here's the uncomfortable truth: **The most effective AI implementations require the most complex security architectures.** And most organizations aren't remotely prepared for this. The paradox is real: building robust AI systems requires distributing trust across multiple vendors and platforms. Each connection is a potential security hole. Each vendor is a potential liability. *"En enskild modell räcker sällan. Det ger bättre effekt att koppla samman olika AI-lösningar för text, siffror och realtidsdata"* (A single model is rarely sufficient. It gives better effect to connect different AI solutions for text, numbers and real-time data) This architectural reality creates security challenges that go far beyond traditional software system protection. Organizations must now manage data security across multiple AI services, each with different privacy policies, storage locations, and compliance requirements. --- ## What AI security cannot guarantee Before we go further, let me be clear about what no amount of architecture can fix: - **AI cannot keep secrets** - If you send sensitive data to an AI service, it's been sent. Period. - **Vendors cannot un-train** - Data already used for training cannot be removed from models - **Compliance cannot be automated** - GDPR, AI Act, and sector regulations require human judgment - **Zero trust is still trust** - Every architecture assumes SOME level of trust somewhere - **Security costs money** - There's no free lunch. Secure AI costs more. *"Säkerhet är inte en produkt. Det är en process - och den tar aldrig slut."* (Security is not a product. It's a process - and it never ends.) --- ### The multi-component necessity Modern AI systems cannot deliver production-quality results using single models because different AI technologies excel at different tasks. Language models handle text understanding and generation effectively but struggle with numerical analysis and real-time data processing. Specialized analytics models excel at statistical processing but cannot generate human-readable explanations. Real-time models provide current information but lack deep reasoning capabilities. *"Skillnaden mellan språkmodeller, generiskt innehåll och dataanalys"* reflects the fundamental reality that *"en språkmodell i grunden är tränad för att tolka och producera språk – det vill säga text, konversationer och sammanhang"* (a language model is fundamentally trained to interpret and produce language - that is, text, conversations and context) This specialization forces organizations to build systems that combine multiple AI services, each introducing its own security considerations. A typical production AI system might use one service for text processing, another for numerical analysis, and a third for real-time data updates. Each service potentially stores and processes sensitive business data in different locations under different security frameworks. ### The geopolitical security reality AI security decisions have become geopolitical issues that affect business operations in ways that traditional software security never did. Organizations find themselves evaluating AI vendors not just on technical capabilities but on national origin and data sovereignty implications. *"När asiatiska, och särskilt kinesiska, aktörer kommer på tal uppstår ofta en större tveksamhet, trots att privacy- och säkerhetsfrågorna i själva verket borde bedömas utifrån faktiska avtal och teknisk implementering, snarare än enbart ägarnas nationalitet"* (When Asian, and especially Chinese, actors come up there is often greater hesitation, despite the fact that privacy and security issues should actually be assessed based on actual agreements and technical implementation, rather than just the owners' nationality) This geopolitical dimension creates operational complexities for multinational organizations. Different regions have different restrictions on AI vendor usage. European organizations face GDPR compliance challenges when using AI services that store data outside the EU. American organizations must navigate restrictions on certain foreign AI providers. Asian organizations may face limitations on Western AI services. The security evaluation process becomes more complex because organizations must assess not just technical security measures but also political stability, regulatory compliance across multiple jurisdictions, and potential future restrictions on vendor relationships. ### The European compliance challenge European organizations face particularly complex AI security challenges due to stringent data protection requirements that weren't designed with AI systems in mind. *"Juridiska risker med att använda AI-plattformar som lagrar data utanför EU"* (Legal risks with using AI platforms that store data outside the EU) GDPR compliance becomes exponentially more complex with multi-component AI architectures. Each AI service potentially processes personal data, requiring separate data processing agreements, privacy impact assessments, and compliance monitoring. Organizations must track how data flows between AI components, where it's stored at each stage, and how long it's retained by each service. The compliance challenge is compounded by the fact that AI services often use data for model improvement, which may not align with GDPR's purpose limitation principle. Organizations must negotiate specific clauses with each AI vendor to prevent unauthorized data usage while maintaining the functionality that makes multi-component AI systems effective. ### The data sovereignty imperative As AI systems become more critical to business operations, data sovereignty becomes a strategic concern rather than just a compliance issue. *"Var data hamnar och hur den lagras är minst lika viktigt som modellens prestanda"* (Where data ends up and how it's stored is at least as important as the model's performance) Organizations must balance AI capability with control over their data. This means evaluating not just where data is stored but how it's processed, who has access to it, and what happens to it after processing completes. Multi-component AI architectures complicate this evaluation because data may flow through multiple services in different jurisdictions. The sovereignty imperative requires organizations to develop data classification systems that determine which types of information can be processed by which AI services. Highly sensitive data might only use on-premises or private cloud AI services, while less sensitive data might use public AI APIs for better performance and cost efficiency. ### The security assessment evolution Traditional software security assessments focus on code review, penetration testing, and infrastructure security. AI security requires additional evaluation criteria that many organizations aren't prepared to handle. *"Granska leverantörers policy och ägarstruktur"* (Review suppliers' policies and ownership structure) AI security assessment must include evaluation of vendor data usage policies and commitments not to use customer data for model training. This requires understanding how AI vendors separate customer data from training data and what technical measures prevent unauthorized access. Organizations must also assess vendor stability and longevity because AI service dependencies are harder to replace than traditional software dependencies. Switching AI vendors often requires retraining users, updating prompts and workflows, and potentially rebuilding integrations. This lock-in effect makes vendor security and reliability assessment more critical than for traditional software purchases. ### The architecture security framework Successful AI security requires architectural approaches that assume multiple trust boundaries rather than relying on perimeter security models. *"Säkerställ dataflöden mellan komponenter"* (Ensure data flows between components) The framework must include data classification and routing rules that determine which types of information can be processed by which AI services. This requires technical implementation of data filtering, encryption in transit between AI services, monitoring and logging of all AI service interactions, and automated compliance checking for data handling policies. The architecture must also include fallback mechanisms that maintain security when AI services fail or become unavailable. This might involve local processing capabilities for sensitive operations or alternative AI services that meet higher security standards even if they provide lower performance. ### The cost-security trade-off Multi-component AI architectures force organizations to make explicit trade-offs between capability, cost, and security that aren't obvious from simple AI demonstrations. Higher security typically means higher costs through private cloud deployments, dedicated instances, or on-premises AI solutions. It may also mean lower performance through restricted AI services that meet security requirements but offer less capability than public alternatives. Organizations must develop frameworks for making these trade-offs systematically rather than defaulting to either maximum security or maximum capability. This requires understanding the business value of different types of AI capabilities and the actual risks associated with different security approaches. ### The integration security patterns Successful AI security implementation follows specific patterns that organizations can adapt to their specific requirements and risk tolerance. The zero-trust pattern treats each AI service as potentially compromised and implements validation at every integration point. This includes encrypting data between AI services, validating AI outputs before using them in business logic, monitoring all AI service interactions for anomalies, and implementing automated incident response for security violations. The layered security pattern implements different security levels for different types of data and operations. Highly sensitive operations use on-premises or private AI services with maximum security controls. Moderately sensitive operations use public AI services with enhanced monitoring and data handling agreements. Low-sensitivity operations use standard public AI services for maximum performance and cost efficiency. ### The monitoring and compliance reality AI security requires continuous monitoring that goes beyond traditional security metrics to include AI-specific indicators of compromise or compliance violations. This includes monitoring for data leakage through AI service interactions, tracking compliance with data handling agreements across multiple vendors, detecting unusual patterns in AI service usage that might indicate security incidents, and measuring AI service reliability and availability for business continuity planning. The monitoring framework must also include regular auditing of AI vendor compliance with security agreements and assessment of changing geopolitical restrictions that might affect AI service availability or compliance requirements. ### Conclusion: security as architectural foundation AI security cannot be an afterthought in multi-component architectures - it must be a foundational design principle that influences every architectural decision. *"Många av framtidens vinnare är de som lär sig kombinera olika AI- och ML-komponenter för att bygga flexibla och kraftfulla arbetsflöden"* (Many of the future winners are those who learn to combine different AI and ML components to build flexible and powerful workflows) The winners will be organizations that master the complexity of secure multi-component AI architectures rather than those that avoid AI due to security concerns or those that ignore security for the sake of AI capability. The key insight is that AI security requires the same systematic thinking and architectural discipline that organizations apply to other critical business systems. Security becomes more complex with AI, but it's manageable with proper framework and systematic implementation. --- ## Vendor security comparison matrix When evaluating AI vendors for multi-component architectures, organizations must assess multiple dimensions beyond technical capability: | Provider | Training data policy | EU hosting | GDPR-ready DPA | SOC 2 | Ownership | |----------|---------------------|------------|----------------|-------|-----------| | **OpenAI** | Opt-out (consumer), No (enterprise/API) | Via Azure only | Yes (enterprise) | Yes | US (Microsoft stake) | | **Anthropic (Claude)** | Never trains on user data | No (US only) | Yes | Yes | US | | **Google (Gemini)** | Opt-out (consumer), No (Workspace/Vertex) | Yes (Vertex AI) | Yes | Yes | US | | **Microsoft (Azure OpenAI)** | No | Yes | Yes | Yes | US | | **Mistral** | No (API) | Yes (EU-native) | Yes | Pending | France/EU | ### Vendor selection by use case **Maximum EU compliance:** 1. Microsoft Azure OpenAI (EU region) 2. Google Vertex AI (EU region) 3. Mistral (EU-native) **Best privacy policies:** 1. Anthropic Claude (never trains) 2. Azure OpenAI (enterprise controls) 3. Google Vertex AI (enterprise controls) **Swedish organization recommendations:** - Start with Microsoft if already using M365/Azure - Consider Google if using Workspace - Use Claude for highest-sensitivity analysis (accept US hosting) - Evaluate Mistral for EU-sovereign requirements --- ## Swedish and Nordic-specific considerations ### Regulatory landscape Swedish organizations face a specific regulatory context: **Offentlighetsprincipen (Public access principle):** - Public sector organizations must consider if AI interactions become public records - Document what data is sent to AI services - Implement logging for transparency requirements **Arbetsmiljölagen (Work Environment Act):** - AI implementation affects work conditions - Involve unions/safety representatives in AI deployment decisions - Document AI's role in decision-making processes **Branschspecifika krav (Industry-specific requirements):** - **Banking (Finansinspektionen):** Additional requirements for AI in financial decisions - **Healthcare (IVO):** Patient data cannot use standard AI services - **Defense (FMV):** Restricted AI vendor list ### Data residency options for Swedish organizations | Requirement level | Recommended approach | Trade-offs | |------------------|---------------------|------------| | **Standard business data** | Azure OpenAI (Sweden/EU) or Google Vertex (EU) | Full capability, standard compliance | | **Personal data (GDPR)** | Azure OpenAI with DPA, EU region only | Some latency, higher cost | | **Sensitive categories (Art. 9)** | On-premises solutions or no AI | Significant capability loss | | **Classified (Sekretess)** | Swedish sovereign solutions only | Very limited AI options | ### Praktiska rekommendationer för svenska organisationer 1. **Klassificera data först** - Innan AI-adoption, bestäm vilka datatyper som kan processas var 2. **Etablera DPA med varje leverantör** - Standardvillkor räcker inte för GDPR 3. **Dokumentera dataflöden** - Var går datan? Vem har access? Hur länge sparas den? 4. **Involvera juridik tidigt** - AI-säkerhet är en juridisk fråga, inte bara teknisk 5. **Planera för förändring** - Regulatoriska krav på AI kommer skärpas (AI Act 2025+) --- ## Implementation checklist ### Phase 1: Assessment - [ ] Classify data types by sensitivity - [ ] Map current and planned AI service usage - [ ] Identify regulatory requirements (industry, geography) - [ ] Document existing data flows and storage locations ### Phase 2: Architecture design - [ ] Define security tiers for different data types - [ ] Select vendors meeting each tier's requirements - [ ] Design data routing between components - [ ] Plan fallback mechanisms for security failures ### Phase 3: Implementation - [ ] Negotiate DPAs with all AI vendors - [ ] Implement technical controls (encryption, access control) - [ ] Deploy monitoring and logging - [ ] Train staff on security procedures ### Phase 4: Operations - [ ] Regular vendor compliance audits - [ ] Continuous monitoring for anomalies - [ ] Incident response procedures - [ ] Periodic architecture review --- --- ## Your responsibility *"Du är ansvarig för varje dataläcka, oavsett vad leverantören lovade."* (You are responsible for every data leak, regardless of what the vendor promised.) Let me be direct: vendors will not protect you. Terms of service are designed to limit THEIR liability, not protect YOU. **What you must accept:** - Security is your problem, not the vendor's - "Enterprise-grade" is marketing, not a guarantee - Compliance checkboxes don't mean actual security - The cheapest option is never the most secure **What you must do:** - Classify your data BEFORE choosing AI tools - Get legal sign-off for every vendor relationship - Monitor actual data flows, not just policies - Plan for breaches, not just prevention - Budget for security - it costs 20-50% more than insecure alternatives --- ## Conclusion: security is not optional Organizations that ignore AI security don't get to complain when breaches happen. Organizations that obsess over security without deploying don't get the benefits. The winners find the balance. *"Många av framtidens vinnare är de som lär sig kombinera olika AI- och ML-komponenter för att bygga flexibla och kraftfulla arbetsflöden"* (Many of the future winners are those who learn to combine different AI and ML components to build flexible and powerful workflows) But those winners will be the ones who did the security work FIRST, not as an afterthought. **The key insight:** AI security requires MORE systematic thinking than traditional software security, not less. If you're not prepared for that, you're not ready for AI in production. AI is a tool. Security is your responsibility. *Verktyg, inte magi.* --- *See also: [AI Training Data Policies](/resources/ai-training-data-policies.md) for detailed vendor data handling comparison.* --- *Based on 30 years of production development and watching security failures unfold in real organizations* *Published: December 2025* --- ### [Context Beats Prompts. Policy Beats Hype.](https://mindtastic.se/articles/context-beats-prompts-policy-beats-hype) After ten workshops with developer teams, the same eleven policy questions surface every time. Not because someone planned it — because practice forces decisions. # Context Beats Prompts. Policy Beats Hype. ## Every team lands on the same questions I have run over ten workshops with developer teams, sales organizations, and mixed-role groups in the past year. Every time the same thing happens: when a team sits down with real problems from their own backlog and actually uses the tools, policy questions surface. Not because someone planned it. Because practice forces decisions. Not identical questions. But the same decision domains. Every time. One group builds a module directly in production code. Five dollars in model cost. No documentation. No change request. Who owns that code now? Another group cannot get the external tool running. They download a local language model on a laptop and build natural language search in their route planning product. No external API. No help. They deliver. But what data went through the model? A third group plans and executes 60% of what their development lead calls "at least two weeks of full-time work" in a single day. A senior developer predicted edge cases that the model independently identified in the next query. Same prompt as everyone else. The difference? The context in the window. Not the prompt. Eleven policy questions surfaced during a single day. None of them planned. This is not unique to that team. It is a pattern. ## The questions that always surface After ten workshops I have seen the same decision domains emerge regardless of industry, team size, or technical maturity. Here are three that come up in every session. ### Ownership of AI-generated code Who owns the output? The person who wrote the prompt? The person who committed the code? The organization? The answer is simple: whoever commits the code is personally responsible. Regardless of whether it was AI-generated or handwritten. Most teams already have consensus on this. But they often lack a formal policy to lean on when a question is raised six months later. ### Data boundaries What may be sent to external models? Personal identifiers — never. Customer data — case by case. Internal code — usually permitted. Financial data and contracts — the gray zone. The real risk is not someone deliberately breaking rules. It is someone sending information to a free tier without thinking about data retention. Without policy, every individual decides for themselves. That is not a strategy. ### Knowledge sharing How does the team share AI experiences internally? Without a system, insights disappear with the individual. One CTO set up dedicated research sessions. First week, one person participated. The presentation was so good it triggered spontaneous participation. Culture first, structure second. --- These are three from a set of eleven recurring decision domains. Each one surfaces differently depending on team size, technical maturity, and the kind of work being done. The complete framework — all eleven questions mapped against three responsibility levels — is what we work through in Track 3 and Track 4 workshops. ## Policy lives where the work happens A policy that lives in a document is not a policy. It must live where the work happens. For teams using Claude Code or similar repo-aware tools, this means decisions go into a `CLAUDE.md` or `CONVENTIONS.md` at the repo root. Every session starts with the tool reading your guidelines. Policy is not something you need to remember. It is in the context window from the start. The concept of building organizational logic directly into a shared repo — a "Company OS" — is worth exploring for any team doing serious AI-assisted work. ## Seniority is the multiplier This is what I see in every workshop: seniority is the multiplier. Not prompt technique. The developer with 15 years of system experience beats the one who can write "better" prompts but does not understand the domain. Every time. The gap is widening. The prompt is the least interesting variable in the equation. What determines output is what the tool already knows when you ask. The context window. What is loaded before you type a single line. That is the whole thing. Policy amplifies this. It protects the organization from confident-sounding wrong answers shipping to production. It ensures that experience trumps speed. That the person who knows the most also gets the greatest leverage. ## Conclusion The industry spends disproportionate energy on prompts. It sells courses. It sells newsletters. But it builds nothing. What builds something: real problems, real tools, real decisions. Policy that grows from practice. Not from an inspiration talk. Every team I have worked with has landed on the same insight: it is not about formulating better questions. It is about loading the right context and taking responsibility for the result. Context beats prompts. Every time. ---