# Memex — Full Reference Memex keeps AI coding agents aligned with your engineering intent. It sits between Jira or Linear and your coding agents, pushing your standards into every session, flagging drift and proving done in CI. --- ## Memex: keep AI coding agents aligned with your engineering intent URL: https://www.memex.ai/ Memex keeps AI coding agents aligned with your engineering intent. It sits between Jira or Linear and your coding agents, pushing your standards into every session, flagging drift and proving done in CI. --- ## Pricing URL: https://www.memex.ai/pricing Memex pricing: free for your whole team. Self-hosting is £6,000 a year for unlimited users; paid hosted plans are coming soon. --- ## Documentation URL: https://www.memex.ai/docs How Memex works: Specs, decisions, standards, tasks, and the MCP server that connects your AI coding agents to the workspace. ### Start a spec from a Jira or Linear ticket Most work starts as a ticket in your tracker. Memex has no built-in tracker connection. Your coding agent brings the ticket in, using your tracker's own MCP server alongside the Memex MCP server. - Connect your tracker's MCP server to your coding agent, following your tracker's own instructions (Atlassian for Jira, Linear for Linear). - Connect the Memex MCP server as described in Connect your coding agent. - Ask your agent to create a spec from the ticket, for example: create a Memex spec from ticket PAY-482. The agent reads the ticket through the tracker's MCP server and creates a draft Spec in Memex with it. From there the Spec moves through specify, build and verify. Your tracker keeps the plan, who and when; Memex holds what is being built, why, and what done means. --- ## The Name URL: https://www.memex.ai/story Why we called it Memex: the origin of the name and the idea behind the spec-driven development system. --- ## Writing URL: https://www.memex.ai/writing Essays on AI-native software development, agentic coding, and how engineering changes when agents do the typing. --- ## Extreme AI Programming URL: https://www.memex.ai/writing/extreme-ai-programming A series on extreme AI programming — what software engineering becomes when AI agents do the work and humans direct it. --- ## The Extreme AI Programming Manifesto URL: https://www.memex.ai/writing/extreme-ai-programming/01-manifesto Part 1 of Extreme AI Programming: a manifesto for how we build software now that agents do the typing. > *Kent Beck in 1999. A stuck team that hadn't shipped in months. The developer who is no longer a person. A manifesto without a successor. Vibe coding versus the instrument. About two years until the door closes.* Kent Beck published [*Extreme Programming Explained*](https://en.wikipedia.org/wiki/Extreme_Programming_Explained) in 1999. I read it as a young engineer running a small team that kept getting lost in its own commitments and had not shipped anything in months. By the time I finished it, and later met Kent in person, it had shaped how I thought about the job for the next twenty-five years. Pair programming, TDD, short iterations. It helped seed the Agile movement that followed, which became the way most serious software was built and most serious engineering teams were run. The world it was written for no longer exists. Agile evolved through Scrum, Lean, Kanban and continuous delivery. Every adjustment refined the same underlying problem: how a group of humans working on the same software stays coordinated. None of us anticipated what would happen when the team members were not all human. In any serious AI-native team today, the developer is increasingly not a person. Nor, often, is the tester. The developer is an agent (Claude Code, Codex, Copilot, Cursor, Windsurf, with Aider, Cline and OpenCode on the open-source side), and often it is several of them at once, each running its own conversation with a different member of the team, each producing work on its own cadence. The coordination problem has changed shape entirely. Agile assumed developers on one side of the table and customers on the other. That is no longer what the table looks like. > The Agile Manifesto, signed in 2001, needs a successor. This series, *Extreme AI Programming*, is an unsubtle homage to Beck. Without the work he, Martin Fowler and the others did in the late nineties, there is nothing to build on here. It is an attempt to describe what a serious, professional discipline for building software with AI agents actually looks like, rooted in their work but reshaped for a world they could not yet see. A short note on where this is coming from. I have spent more than thirty-five years running software development teams across the companies I have founded and exited. Today I am co-founder and CEO of [Mindset AI](https://mindset.ai), where for over a year we have been an AI-native company by design, and the practices I plan to write about here are the ones we have been evolving in real time. This is not observation from a distance. Here is the thesis of the series, compressed. Agile is, at heart, a coordination protocol between humans. When most of the implementation is being done by agents that never forget, never tire and never need to be motivated on a Monday morning, the shape of the coordination problem changes. The hard part is no longer keeping a team of engineers aligned. It is keeping humans, agents and the codebase itself aligned with the decisions the team has actually made, and making sure each agent acts on the current set of decisions rather than an old one, a half-remembered one, someone else's private one, or worse, no one's at all. ## Instrument or slot machine? There are two ways of working with AI. One treats it as a genuine instrument to be mastered. The other treats it as a slot machine. The slot-machine version has a name. It is called vibe coding. Prompt, accept, ship. If the code runs, move on. If it doesn't, prompt again. It feels productive in the moment, and for a weekend project it is perfectly fine. As a professional practice it is quietly catastrophic. You end up with codebases the team cannot evolve. Decisions the team does not remember making, or did not actually make. A continuous accumulation of incoherence nobody can see until it breaks something expensive. The instrument version is harder. It requires that you be articulate. Being technically articulate as a human has become, almost overnight, the most economically valuable skill in software. Not because humans have any mystical edge over machines, but because no agent does its best work without one telling it precisely what to build. Agents are excellent at writing code when they know what they are meant to be writing. They are also quite capable of producing fluent, confident code that does precisely the wrong thing, and doing so very quickly. The same goes for the markdown documents they produce to describe the code. The difference between those outcomes is almost entirely the precision of the brief they were given. An agent is only as good as its specification, and only as good as the data it can see. The better the agent gets, the more unforgiving the gap between what you said and what you meant becomes. The alternative, and the subject of most of what I plan to write, is a more disciplined way of working: - Intent set clearly up front. - Decisions captured as they are made. - Rules for how software gets built, written down somewhere every agent and every engineer on the team will actually read. - Plans reviewed before code is written, rather than code reviewed after the fact. None of this is new in spirit. A reasonable reader could point out that it is roughly what good engineering has always looked like. The cast has changed, though, and the practices have to change with it. Next week I want to look at the first response the industry has already reached for: the `CLAUDE.md` file, the cursor-rules file, and most recently Anthropic's Skills, which are the moment's hot topic. Every AI-native team has independently invented some version of these. They are useful, but they are band-aids, and the first implementations break in predictable ways. > Spoiler: Skills are not the answer. In their current form, they exacerbate the problem. ## The harder question There is a harder question underneath all of this, and the industry has been slow to talk about it openly. The junior job market has, over the past year or so, all but disappeared. A senior engineer with a competent agent now ships what used to take a team of five. The obvious economic move is to hire the senior and skip the juniors. That move is being made everywhere, quietly. The mechanism is depressing in its specifics: graduates submit hundreds, sometimes thousands, of applications to AI-driven ATS systems that reject them before any human reads their CVs. The part that genuinely worries me is not, in itself, that our profession will shrink, even though it means good people will be out of work just as society needs more opportunities, not fewer. Professions reshape themselves all the time, and ours has done it before. What makes the calculation work is articulation. The agent's output is only as good as the brief it is given, and writing that brief takes the kind of judgment a senior has spent years earning. A junior cannot yet bring that, not because they are incapable, but because the instinct takes time. What worries me more is that the people currently being trained to enter the profession, in universities, on boot camps, in the first year of a graduate scheme, will arrive to find that the first rung of the ladder is no longer there. They will have done the work, paid the fees, learned the craft, and the jobs they were being prepared for will not exist in the form they were promised. Unless those of us already inside the profession reshape it around what the next generation still has to bring, we will run on the experience we have now and stop restocking. The closing chapters of this series come back to what that reshape needs to look like in practice. The timing is unforgiving: about two years, and after that the door does not reopen. ## Why I'm writing this That is the pessimistic version of the argument. The optimistic version is the reason I am writing this series at all. If we find genuinely good ways of collaborating with machines, and if we build the new ceremonies and disciplines a team actually needs when several of its members do not sleep, then what we have been handed is not a diminishing of the profession but an enlargement of it. The mechanical middle of the job, the typing, can be delegated. What is left is human creativity and human judgment, amplified by instruments that can turn a well-framed intention into working software in an afternoon. The point of this series is to work out, in public, how to build that discipline, so that we exploit what humans are actually good at while the machines do the work. There is a great deal of talk at the moment about whether our profession is coming to an end. I don't believe a word of it. For anyone who has been in software for a long time, this is the most interesting moment in the discipline since the arrival of the web. The barrier of programming language, the particular question of which one you happen to know, has quietly become less important than it has ever been. What matters now is clarity of intent and the ability to articulate what you want in enough detail that a competent instrument can produce it. That specific skill has always been scarce. For the first time, it is directly economically productive. ## Does this need a new manifesto? At the start I said the Agile Manifesto, signed in 2001, needs a successor. That leaves a question I have been turning over for a while: who should write it? Over the last eighteen months, several people have already tried. None has yet had its Snowbird moment, but the conversation is well underway, and the candidates worth knowing are these. - **Casey West, [*The Agentic Manifesto*](https://caseywest.com/the-agentic-manifesto/) (November 2025).** Modelled directly on the original ("while there is value in the items on the right, we value the items on the left more"), it pairs four new values with a five-phase Agentic Delivery Lifecycle. The central problem he names is the "determinism gap": the move from "did it do what I said" to "did it do what I wanted". The most-cited of the candidates so far, and the closest in shape to the original. - **Shay Cohen at Wix Engineering, [*The AI Coding Agent Manifesto*](https://medium.com/wix-engineering/the-ai-coding-agent-manifesto-c8f61629d677) (April 2026).** Five values written from inside an engineering team that has been living with agents for a year: contracts over conventions, verification over generation, vanilla over clever, types over tests, explicit over implicit. The most practitioner-shaped of the bunch. - **Ry Walker and Jonathan Vanderford, [*The AIFSD Manifesto*](https://github.com/tembo/aifsd).** Eleven principles, two of which carry most of the weight: "AI is your intern, not your boss", and "the human always has the last word". A hard line on responsibility, written for a moment when the temptation to delegate accountability is real. There are others circulating, including Mircea Trofimciuc's earlier [agenticmanifesto.org](https://www.agenticmanifesto.org/) from May 2025, and a steady stream of essays calling for a successor without yet committing one to a fixed text. The list is open. I take some comfort in not being alone on the deferral. Asked at Thoughtworks' [twenty-fifth-anniversary retreat](https://www.devclass.com/development/2026/02/21/should-there-be-a-new-manifesto-for-ai-development/4091612) in February 2026 whether there should be a new manifesto for AI development, Martin Fowler said: > It's way too early. I don't have a lot of time for manifestos. Of the original Snowbird signatories, he is the only one to have spoken publicly on the meta question. My intention with this series is not to add another. The world does not need yet another manifesto written by someone who has not yet earned the seventeen co-signatories the original had. What I would rather do, in the spirit of open source, is back one of the existing candidates: read them carefully, write about them seriously, and put my weight behind the strongest of them. By the end of this series I will have made that choice explicit and said why. Over the next few months, the series will cover what I think the new discipline actually contains. The roles and how they have recomposed, including which Agile ceremonies still make sense and which do not. The new first-class artefacts, which in my view are decisions, standards and execution plans. How to review work produced by an agent without becoming its babysitter. The economics of running a team where one engineer and three agents produce what five engineers used to, and the things that get harder rather than easier. And occasionally, because there is no point pretending otherwise, the commercial work I am doing with [Mindset AI](https://mindset.ai) sits inside the argument. The rhythm of the series will alternate between two registers. This first piece has been philosophical, sitting with the manifestos and the broader argument about the discipline. Next week is closer to the keyboard, practical: the artefacts every AI-native team has already reinvented half a dozen times in the last year, and why the first versions break in the same places. Both registers matter, and neither does the work alone. If the argument resonates, I would be glad of the company. If it doesn't, I would be glad to hear why. I would rather be argued with now than wrong in print later. — Barrie --- ## The Second Punch-Card Era URL: https://www.memex.ai/writing/extreme-ai-programming/02-second-punch-card-era Part 2 of Extreme AI Programming: why prompting an agent feels like the punch-card era — and what comes next. > *A computer room in 1985. How a context window actually works. Grep as a net thrown into the ocean. Three evolutions of markdown, three versions of the same problem. A knowledge map, not a flat file.* I won a computing competition when I was twelve. The prize was a Saturday morning each week in the computer room at one of the universities near where I lived, and for that year my mother drove me across town and dropped me off in a place that, to me, felt approximately as exciting as a lunar landing. I do not remember the make of the machine. I remember the terminals, because they were impossible to forget. Cathode-ray tubes glowing in the particular shade of monochrome green anyone over forty-five recognises instantly. Mechanical keyboards that felt like typing into a filing cabinet. And, most strangely of all from the perspective of a child who had already used home computers that saved to cassette tape, the storage medium was punch cards. You wrote your program, punched it onto a stack of cards, and fed the stack back into the reader to run it. I can still see it clearly, forty years on. The slight anxiety of dropping a stack on the floor and reassembling it in the right order. The clean mechanical sound of cards being fed. The improbable fact that the holes in some rectangles of cardboard added up to working software. > I have been thinking about that room a lot recently, because I am starting to suspect we are all back in it. The shape of the interaction has not really changed. We write our instructions on a flat surface, hand the stack to a machine, and wait to see what it does with them. The cards are now markdown files (instruction documents, skills, rules, system prompts), but the medium is the same: long blocks of text composed by a human, fed wholesale to a machine that reads them top to bottom and acts on what it sees. Different cards, different reader, same primitive interface. Engineers are problem-solvers by temperament. When the industry started using AI systems seriously, the first problem we hit was the same one: there was no clean way to give context to the process we were trying to run. The agent needed to know something about the project before it could produce anything sensible. So we reached for the simplest format that could possibly work, and that turned out to be the markdown document. Markdown is structured but lightweight, opinionated about the few things it cares about, and is plain text, which means anything can read it. Within months it had become the format of choice. ## How a context window actually works It is worth pausing here on what is happening underneath an agent session, because every approach the industry has tried so far is in trouble for the same reason: it treats the context window as a place to dump everything that might be relevant, rather than as something engineered for a specific job. LLMs themselves are stateless. The model has no memory between requests. Every time you type a message into a coding agent, the entire conversation up to that point is packaged on your machine, POSTed to the model over HTTP, and read by the model from the top to the bottom — system prompt first, then tool definitions, then every previous turn, then your latest message — before a single token of response is produced. Then the connection closes. The next turn is another full payload, the entire conversation again, plus the latest exchange tacked on the end. Anything that looks like memory in a coding agent is the harness around the model writing state back into the next request on your behalf. The model itself has no idea what was said five minutes ago. What that means in practice is that every irrelevant rule, every contradictory instruction, every backward-forward debugging trail still sitting in the conversation is being re-read by the model on every single turn. It is not in some background memory the model can ignore. It is in the input the model has to reason over, every time, weighing on the relevance signal in the part that actually matters. With GitHub moving Copilot to usage-based billing on June 1st, the cost of carrying that debris around is now being charged on every turn as well. [Yesterday's piece](https://www.linkedin.com/posts/barriehadfield_a-prelude-to-tomorrows-article-on-context-ugcPost-7456950497174835200-5F4y) treats that side of the same mechanism. Every token in the context either earns its place or weakens the signal. That is the underlying discipline, and how teams apply it falls into three rough categories. **Ideal.** The context is built fresh for the task at hand. It carries a clear statement of the intention, the critical information the agent needs to act on it, and a clean instruction to execute. Nothing else. It is used once, the work is produced, and the context is discarded. Each new task gets its own purpose-built window. This is the version that performs best, and is worth aiming for whenever the task is small enough to scope cleanly. **Acceptable.** The context is maintained across multiple turns, but maintained deliberately. Long debugging sessions, exploratory work, paired sessions where a human is iterating with the agent in real time, all genuinely benefit from accumulated state, because the accumulated state is part of what makes the next turn good. The discipline here is not to discard the history but to curate it. Summarise. Prune. Compact. Cut the dead ends out before they sediment. Tools like Claude Code have explicit compaction and memory features for exactly this reason. **Bad practice.** A single long-running context window left to grow indefinitely. Hours of unrelated work piled on top of each other. The agent's first instructions still sitting there alongside the user's eighty-fourth follow-up, with three contradictions and two abandoned approaches in between. This is the version that feels productive in the moment, because nothing has to be re-explained, and is quietly catastrophic. It is a bit like a bad relationship nobody has ended. The conversation keeps going, every old argument is still in the room, and everything new gets coloured by everything that came before. Even when the context is being assembled with discipline, there is still the question of how the agent finds the right things to put in it. This is where the current generation of tooling shows its second limit. The primary mechanism a coding agent has for retrieval today is `grep`, or more accurately `ripgrep`, the faster regex variant Claude Code wraps as its built-in search tool. The way that actually works is worth describing precisely, because the picture most people carry of it is too simple. `Grep` itself does not load whole files into the context window. It runs a regular expression against the file system and returns one of three things: a list of file paths that contain a match, the matched lines with a small window of surrounding context, or a count of matches per file. Cheap, narrow, and on its own not enough for the agent to understand the material it has just located. What follows is a second step. Once `grep` has surfaced the candidate files, the agent calls a separate tool, `read`, to pull file content into the window. `Read` can take a line range, but in practice it usually pulls the whole file, because three lines of regex context around a match are rarely enough to understand what a function actually does, or what a rule actually says. The combination assembles what the agent then reasons over: `grep` to locate, `read` to load. The same machinery is at work whether the agent is searching the codebase or the markdown documents the team has curated as instructions. Both steps are non-deterministic in either case. The first depends on whether the regex happens to match the right token; rename a concept, choose a synonym, restructure a function, edit a rule into different wording, and the right file may not surface at all. The second depends on the agent's judgement about which of the matched files are worth reading, and how much of each. It is a sophisticated version of throwing a net into the ocean and hoping for the best, and the net is being thrown across two oceans at once: the codebase itself, and the rules that are meant to govern how it gets written. Sometimes the agent catches the right fish. Sometimes it catches the wrong ones, and writes confident code, or follows a confident-but-stale rule, on the strength of the wrong catch. A non-deterministic retrieval process cannot be trusted to assemble a deterministic context. And as a profession we have not yet given the agent anything better to retrieve from. The way every AI-native team has tried to use markdown for context has gone through four identifiable evolutions in roughly two years. The first three are where the industry sits today. The fourth is the work that has to come next. ## Evolution 1: one file per repo The earliest pattern was a single instruction document checked into the repository. Each agent vendor settled on its own filename. Anthropic's Claude Code reads `CLAUDE.md` from the repo root. GitHub Copilot reads `.github/copilot-instructions.md`. Cursor reads `.cursorrules`. Other tools have their variants, all in the same essential shape. Most teams set the file up by asking the agent itself to scan the codebase and produce a draft, then edited it down. The file would be loaded into every session that touched the repo, gave the agent a rough map of the architecture and the conventions, and for a short while it worked. Then it started to grow. Each session added a rule, a clarification, a line about an edge case that bit somebody last Tuesday. Information got duplicated across sections. Occasionally it contradicted itself. After a few months a two-thousand-line `CLAUDE.md` was unremarkable, and the agent's context window was filling up with instructions before it had begun thinking about the actual problem. ## Evolution 2: skills, and the same problem magnified The natural next move was to break the single file into many smaller ones, loaded selectively rather than all at once. A handful of clever plugins emerged, several of them from Anthropic and the community building around it, that gave teams some control over which document was pulled into the context window and when. The collection acquired the lovely name *skills*: a folder of markdown documents covering the team's architecture, design decisions, coding standards, security posture, and whatever else seemed worth instructing the agent on. You have to enjoy the naming. *Skills* is a wonderful word for what we are gesturing at, and the name has run a little ahead of the substance, in the way names tend to run ahead of substance early in a discipline. A skill, today, is a markdown document with some content in it, sitting in a folder, pulled into the context window when something tells the agent it might be relevant. There is something quite charming about it. We are still in the punch-card era, naming it after what we hope it will become. The loading mechanism is slightly different from the grep-and-read pattern. Each skill file carries a block of frontmatter describing when it should be considered relevant. The agent reads the frontmatter, decides which skills apply to the task at hand, and pulls the matching ones into the window in their entirety. The selection is per-file rather than per-line, which is a small step forward. The same non-determinism is still in play: whether the right skill loads depends on whether the description in the frontmatter happens to match the shape of the task, and on the agent's judgement about which of several plausibly relevant ones to pull in. > All of this works, until the files start to grow. **Bloat**. **Drift**. Bloat does not go away by being spread across more files. It magnifies. Skills bloat in exactly the way `CLAUDE.md` bloated, but now across half a dozen documents instead of one. Each session adds a rule, a clarification, an edge case, and no session takes one out, because nobody is paid to take rules out. The collection gets longer. The agent's window fills up earlier. The relevance signal, the one thing that makes the agent useful, gets quieter. Skills drift in exactly the same way. A rule says the team uses Postgres, three months after the team migrated to DynamoDB. The agent reads the rule, writes the wrong code, and does so confidently, citing a file that has been quietly wrong for a quarter. Often we cannot even trace where the offending instruction came from, because it is buried in one of half a dozen overlapping documents, none of them dated and none of them owned. ## Evolution 3: lift the files out of the repo If the files in the repository are bloating and drifting, the natural next move is to lift them out of the repository entirely. Some teams put their skills in a dedicated repository of their own, where they can be branched, versioned, and reviewed as a unit, and where the same set of rules can serve more than one codebase. Others move to a wiki or a documents portal like Notion, on the grounds that knowledge management deserves its own tool with its own audience. We have tried versions of both as a company. Both approaches buy you something genuine. A separate repository inherits all of the apparatus of code review: branch protection, ownership, commit history, the ability to roll back a bad change. A wiki gives non-engineers a much friendlier surface to read and contribute on, and the team a cleaner search experience. The trouble is that the underlying problem does not move with the files. Bloat accumulates wherever the documents live, because everyone is busy and the change rate is high. Drift between rule and code happens just the same, because the rules and the code are evolving on different schedules. A wiki sitting outside the repo is in some ways the worst of all worlds: at least the repo had the discipline of code review around it, the wiki has nothing. What the move actually buys is the opportunity for review discipline. It does not enforce it. And in practice the ceremonies that used to catch this drift have already weakened. The pull request and the code review used to be a particular kind of ritual. Senior engineers read submissions carefully, fed back generously, and used the act of review as the central learning mechanism on a team. I do not see that in my own team any longer. I do not really see it in my own practice. On a Friday afternoon recently I sat down with a queue of merge requests that had stacked up across the last few days. By the time I had read the third one I had stopped reading the code. I was asking the coding agent to fetch each merge request through its git integration and tell me whether the change was sound. It caught things in some of them I would have missed if I had been on my own. In a couple of cases it told me everything was clean and I merged on its word. The volume coming through is high, the work is more often than not better than I would have written by hand, and the muscle for review has weakened in a way I was not paying attention to until I noticed it had gone. The easiest prompt in the world, at the end of a session, is *update the skills to reflect what we just did*. I genuinely wonder how often anyone reviews that update before it becomes the next instruction the next agent reads. ## Evolution 4: from documents to a knowledge map The fourth evolution does not start with a new file format. It starts with a different conception of what we are trying to maintain in the first place. A team's instructions to its agents are not really a pile of documents. They are a map of what the team has decided. Architectural choices, conventions, security stances, the rationale behind a Postgres-to-DynamoDB migration, the reasons a particular service ended up split into three. These are interconnected pieces of knowledge with relationships between them: this decision was made because of that one, this rule depends on that constraint, this convention is in tension with that other one. A flat markdown file collapses those relationships into a paragraph that may or may not survive the next merge. A wiki does the same in a friendlier wrapper. Neither has any way to know what is connected to what. The right shape of the answer is a knowledge map. The instructions, rules and decisions a team needs the agent to act on stop being lines of text in overlapping markdown files and start being objects in their own right, with identity, ownership, history, and explicit relationships to each other and to the code. They live in a structured store, something Postgres-shaped, which already does most of this work in adjacent domains. Postgres is interesting precisely because it offers three retrieval strategies in the same engine. Structured SQL handles relational queries cleanly, the kind a deterministic process can rely on. Full-text search is the modern equivalent of `grep`, but applied to a curated corpus rather than the whole file system. Vector search handles the semantic case, when the agent does not know quite what it is looking for and needs the closest match in meaning rather than in wording. A protocol like MCP lets the agent call into that store and ask precise questions, returning precise answers, rather than hauling whole files into the window in the hope the right paragraph is in there somewhere. The retrieval becomes deterministic. The context becomes the smallest set of things that actually matter for the task. On top of the structured store sits the obvious next layer. Tooling that watches the rules for bloat and contradiction. Tooling that compares the current rule to the current code and flags drift the moment it appears, rather than the moment it breaks something expensive. A review surface for the instructions themselves, not only for the code those instructions produce. Versioning that treats every change to a rule the way the team treats every change to the code. A user interface a human can sit in front of, edit, and trust. This is broadly the work we have been doing as a company. I will write about specifics elsewhere in the series, and I will be careful to separate what is product-specific from what is generally true. ## Ending or beginning? The pessimistic reading of this whole moment is that it is the end of something. I saw the beginning of the previous arc, in that computer room. Punch cards, then terminals, then home machines, the web, mobile, cloud. Forty years of compounding sophistication in how humans wrote software. Now most of the writing is being done by machines, and the machines communicate with us through a medium that would have looked familiar in 1985. On that reading, the markdown era is the regression and the arc is closing. The optimistic reading, which I find more persuasive and which I actively prefer, is that markdown is not the destination. It is the punch card. It is what we hand-rolled to communicate with the agent before we had built anything better, and it has served us for the few years we needed it. What replaces it is not another file format. It is a shift in what we are trying to preserve in the first place. The thing worth preserving is the team's knowledge. The decisions, the reasons behind them, the constraints they were taken under, the relationships between them, everything we collectively know that should outlast any individual session, repository, or developer. Not as a document. As a structured, queryable, versioned map of what is true. A map humans can read, edit, and trust, that agents can call into deterministically, and that drift detection can patrol automatically. Building software in collaboration with AI agents, professionally and over years, will turn out to be mostly the work of building and maintaining that map. The child in that computer room, if he had been told that punch cards were already nearly obsolete, would not have concluded that software was finished. He would have wanted to know what came next. Same answer, forty years later. — Barrie --- ## The Bottleneck Moved URL: https://www.memex.ai/writing/extreme-ai-programming/03-bottleneck-moved Part 3 of Extreme AI Programming: the bottleneck in software is no longer typing — it is deciding and verifying. > *Five bottlenecks across forty years. Goldratt’s discipline. Compilation, integration, communication, deployment, all downstream of the keyboard. The fifth move went upstream and the team did not move with it. Private decisions, rotting docs, agents without a kitchen. The hardest part was never writing the code.* There is a pattern in the way software actually gets built. The bottleneck, the thing that decides how fast a team can really move, never sits still. It shifts every decade or so, the industry chases it for a few years, beats it down to a manageable size, and then quietly discovers it has moved somewhere else. I have watched it move four times. The fifth is happening now, and most of the industry has read it as a story about tools when it is in fact a story about how teams are arranged. The pattern has had a name for forty-two years. Eliyahu Goldratt published [*The Goal*](https://en.wikipedia.org/wiki/The_Goal_(novel)) in 1984 and named what every operations team had already half-noticed: the throughput of any system is set by its single slowest step, and the work of management is to find that step, exploit it, subordinate everything else to it, then invest to remove it. The catch, which gets less attention than it deserves, is the last step. Once you remove the constraint, a new one will appear somewhere else in the system, and the discipline begins again. > The constraint always moves. The only question is whether you notice when it does. In our discipline the constraint has moved roughly once a decade. The interesting thing about the first four moves, in hindsight, is that they all sat at the same end of the work. ## The first four moves **The 1980s. Compilation.** Builds took hours. Linking a serious C++ codebase was a coffee break with overflow. The industry attacked the problem with incremental compilers, distributed builds, faster languages and faster machines, and within a decade the build had stopped being the thing that decided how fast you could ship. **The 1990s. Integration.** Branches diverged, big-bang merges took weeks, and a team of twenty engineers could spend a quarter trying to reconcile parallel work. Continuous integration, in its early Cruise Control form and then in the Jenkins generation, dragged that constraint out of the work. By the end of the decade integration had stopped being where the time went. **The 2000s. Communication.** Distributed teams, late discoveries of misalignment, the gap between what the customer asked for and what the engineering team thought it had heard. Kent Beck’s 1999 book and the Agile Manifesto that followed were the response. A whole generation of practices designed to make the conversation cheaper and more frequent. By the late 2000s communication had stopped being the thing that broke teams, in the cases where the teams used the practices. **The 2010s. Deployment.** Code sitting on a branch waiting for a release window. Manual ops, downtime, three-month release cycles. The DevOps movement, infrastructure-as-code, Kubernetes, the whole continuous-delivery stack. Jez Humble and David Farley’s 2010 book was the field manual. By 2020 most serious teams could ship multiple times a day, and deployment had stopped being the constraint. All four of those constraints sat at the same end of the work: producing, integrating, or shipping code. The implicit assumption underneath every methodology of the last forty years has been that the slowest step lives downstream of the keyboard, somewhere between the developer typing and users running the result in production. That is the assumption that has just collapsed. ## The fifth move In the last two years AI coding agents have arrived in development workflows in earnest. Cursor, Claude Code, the next generation of agents that follow. They write code at a velocity no human can match. They write tests, they debug, they scaffold whole features in an afternoon that would once have taken a week of careful keyboard work. The industry has read this, almost unanimously, as the productivity miracle the previous forty years were building toward. Anyone with a credit card can now build a website. A founder can ship a prototype over a weekend. The dominant mental picture of AI-assisted development is one person at a keyboard, talking to an agent, and shipping. This reading is a trap. What it forgets is everything professional development teams have spent the last forty years caring about: architectural coherence, sustainability, security, the thousand small decisions about coding standards and naming and helpers-versus-inlining that determine whether a system you build tonight will still be habitable in six months. None of that is supplied by the agent. None of that is supplied by the person at the keyboard who does not know that any of it exists. The trap is not that the agent does bad work. The agent does, increasingly, very good work for the prompt it was given. The trap is in believing the keyboard-to-deploy step has become so cheap that the rest of the process can be ignored. It has not. How the team arranges itself around the agent has become the entire game. ## Where the constraint actually went The fifth move is not where most teams have looked for it. It did not land at the back of the work, where the previous four constraints lived. It moved to the front. > The next chapter is the good news for professional developers. What makes someone a professional has not gone anywhere; it has moved upstream. The new constraint is upstream of every line of code. It is in how a team arranges itself to get the most out of this new instrument. Who sits at the keyboard. What they know. What vocabulary they bring. How their work hands off to the next member of the team. Whether the team’s combined articulation produces something coherent or just produces something fast. This shows up in three specific ways, and any team running agents in earnest will recognise all three. 1. **Private decisions.** An engineer settles a meaningful architectural choice in a forty-minute conversation with their agent and ships the work. The only record of how the team got there lives inside one private chat thread. By Thursday a colleague is having a different conversation with a different agent and reaching a different conclusion. Both are sensible. Both are inside the same codebase. Neither knows the other exists. 2. **Decaying documentation.** Institutional knowledge rots inside documents written for an older version of the system, the dynamic I went into at length in [the second article in this series](/writing/extreme-ai-programming/02-second-punch-card-era). Every team has a wiki, an architecture doc, a README. Six months ago they were correct. Now the system has migrated databases, the auth flow has been rewritten, two services have been merged into one, and the wiki still confidently describes the previous state. When the agent reads it, the agent does its best with what it has been given, and is now wrong with confidence. 3. **Agents without a kitchen.** Three engineers, three branches, three Claude or Cursor sessions running independently. Each one solves its piece coherently. None of them is aware of what the others are doing. Where a human team would have walked past each other in the kitchen and noticed the collision, the agents have no kitchen. Each of those failures is a different face of the same constraint. The team has not arranged itself, at the front of the work, to give the agent and the rest of the team a shared, current account of what is being asked for and what has already been decided. The keyboard-to-deploy step has become very fast. The “what should we be writing, and who should be saying so” step is now where the team’s throughput lives or dies. ## The new discipline The chapter that comes next develops this argument at the level of the individual. The prompt is not the work; the prompter is. Not all prompters are equal. The vocabulary brought to the keyboard by a founder, a product manager, a designer, or a senior developer each produces a different artefact from the same instrument. The discipline that makes a professional AI-native team work is the orchestration of those vocabularies. Goldratt’s discipline applies. We have to find this constraint, name it, exploit it, subordinate everything else to it for a while, and invest to remove it. None of those steps has happened seriously yet at industry scale, which is why we are in the moment we are in. The hardest part of building software was never writing the code. It is being clear, together, about what to write. — Barrie --- ## The Prompt Is the Work URL: https://www.memex.ai/writing/extreme-ai-programming/04-prompt-is-the-work Part 4 of Extreme AI Programming: the prompt, the spec, and the decision record are the real engineering artifacts now. > *A decade of open-source documentation. The skill the industry never named. Translators, not developers. Three people, one login form. Why the prompter matters more than the prompt.* Somewhere in the mid-2000s I got drawn into open source, and the role I kept ending up in, almost by accident, was writing documentation. Not code comments or terse README files, but the serious stuff. Onboarding guides. Architectural overviews. The docs site. I had a reasonable amount of success, in the sense that the people who read them came away understanding the projects well enough to actually contribute. What I noticed in the course of doing this is that writing clearly about software is a meaningfully different skill from writing software. The two overlap, obviously, but they overlap less than you would expect. Plenty of excellent engineers cannot explain what they have built to save their lives. Plenty of people who could not write production code to a professional standard are remarkably good at describing what code does, how it fits together, and why the choices in front of you matter. These are two distinct abilities, and until recently the second one mattered only at the edges of the work: in teaching, in onboarding, in writing the documentation nobody quite got paid for. Anyone whose job was to ship code could safely under-invest in it. That has changed completely in the last two years, and the reason it has changed is worth being precise about. This is a skill in its own right, though it is rarely treated as one. It is the skill of having a proper vocabulary for software, and of being able to deploy that vocabulary precisely enough that someone else can build a working mental model from what you have said. The difference between a class and an instance of a class. Coupling and cohesion. Interface and implementation. These distinctions are not obscure; they are the basic grammar of how software is put together. Deploying them correctly, in context, in full prose, while walking an inexperienced person through a real system, is surprisingly hard, and the people who can do it well have usually spent years at it. > This is the skill that is now the most economically productive one in serious software work. When you sit down to work with a modern coding agent, the entire interface is an exercise in describing a software outcome. You are not typing the code; the agent is going to type the code. What you are doing is translating a mental model of software into prose precise enough that a recipient who does not share your context can build the same mental model on the other side. The agent is an unusually demanding recipient: it takes what you have said exactly as you have said it and proceeds accordingly. If your brief is precise but subtly misaligned with the codebase, the output will be precisely wrong, which is worse than vague. The reason articulation has become this kind of bottleneck is worth naming directly. Jon Ayre, who runs the Strategic Advisory practice at Equal Experts, gave me the cleanest available framing in a comment on the first article in this series. The Large Language Model sitting inside Cursor and Claude Code is not a developer; what it does is translation. Free-form English in, code out. The thinking happens before the prompt, not during it. In a follow-up exchange Jon sharpened the point. The model is doing translation coupled with retrieval by keyword: a single phrase in English can expand into an entire coded function because the phrase is the agreed shorthand for that function. His analogy was a designer asking for “three paragraphs of lorem ipsum here”. The phrase fetches a thing that already exists; the model is not inventing it. Asking the agent to “write me a binary search” requires the prompter to know the thing exists, to know what it does, and to know it is the right solution to the problem in front of them. The model cannot supply any of those three. If the model is doing translation coupled to keyword retrieval, then the words you choose are doing a great deal more work than they would in any other written register most of us know. Every load-bearing word in a prompt is a key turning a different lock. *Build* fetches one set of patterns; *refactor* fetches another; *tighten* fetches a third. *Scalable* recruits a different idiom from *simple*. These are not stylistic choices. They are switches, and the model is too good at translating across them for any of us to be casual about which one we typed. Which is where almost every published guide to this craft stops. Pick the right words. Choose the right verbs. Be precise. All true, all useful, none of it the part of the picture I have been wanting to write about. The most consequential variable in any prompt loop is the one almost nobody is naming, and it is not the prompt. It is the person sitting at the keyboard. ## The login form Imagine three people typing into the same agent against the same feature. None of them is doing anything wrong. Each is using the tool in good faith. The differences in what they get back are a function of the vocabulary each one brought to the keyboard, and almost nothing else. The first is a founder or business owner. The requirement, in their head, is a business outcome: we need to know who our users are, so we can charge them, retain them, and show them their own data. They type something close to this: *“We need users to be able to sign up and log in, so we know who is using the product and can attach their activity to their account.”* The prompt is clear and articulate, but the lexicon is business-side. The *why* is fully present; the *how* is left entirely to the agent. The second is a product manager or a product designer. They have the vocabulary the founder does not: of user flows, of jobs to be done, of the visual elements that make a login screen feel like a login screen. Their prompt reads more like: *“Add a login screen as the first page after the marketing site. Email and password fields, a ‘forgot password’ link, a ‘sign in with Google’ button. Land the user on their dashboard after sign-in, and treat returning users with a remembered-email shortcut.”* This is a different prompt entirely. It is describing the application from the visible surface inward. The third is a senior developer or architect. She sees the same requirement and starts thinking in terms the other two could not have used. Do we want a username-and-password flow at all, or are we going single sign-on? If single sign-on, which provider: Google, Microsoft, an enterprise OIDC of some kind? Where does the session token live and for how long? How does this slot into the authentication primitives the rest of the system already uses, so we are not now maintaining two parallel ways of knowing who a user is? Is this the third login form being introduced this month, or are we converging on the helper the team has quietly been aligning on? Her prompt, when it lands, names every one of those decisions, picks the one she wants, and hands the agent the constraints to honour: DRY against the existing helpers, faithful to the SOLID principles the codebase has been built to, and conforming to the team’s authentication standard. All three prompts produce a working login form. The agent is capable enough that none falls over. But the three forms are not the same form. The founder gets the generic implementation: the model’s most plausible defaults, assembled from the training data, with no knowledge of the codebase and no concern for sustainability beyond what works tonight. The product manager gets a more specific implementation, faithful to the workflow described and visually correct, but still operating outside the codebase’s existing architecture. The senior developer gets the implementation she already knew was right, expressed in enough detail that the agent could not have produced anything else. I do not want to draw a verdict here about which of the three is using the tool correctly. All three are using it well, given what they brought. The founder is keeping momentum on a product that may not survive the quarter. The product manager is prototyping an interaction faster than any old-style design tool would have allowed. The developer is compressing a week of careful implementation into an afternoon. These are all good reasons to be at the keyboard. The point is sharper than which role is doing it best. Output is correlated to input, and input is a function of what the person typing actually knows about the system they are asking for. The tool is now embedded at every level of the work, and each of us gets back exactly what our vocabulary instructed it to produce. ## Beyond vibe coding There is a story that has dominated the discussion of AI coding for the last eighteen months, and it goes roughly like this. One person sits at a keyboard. They prompt an agent. The agent produces working software. The person becomes the entire engineering function on their own. The industry has given this a name, *vibe coding*, and it has become the dominant mental picture of what AI-assisted development looks like. I think vibe coding is the scourge of our profession right now. It is not that the products it produces never work; they often do, on a small enough scale. The problem is that it obliterates the specialist roles that every piece of consequential software still needs to have: the founder’s instinct for whether this maps to a real customer, the product manager’s care for how the interaction should land, the designer’s sense of what the surface should look like, and the developer’s discipline around the architectural choices that determine whether tonight’s working code is still working in six months. Vibe coding flattens all of those into one person, working alone, in front of one agent, with no scrutiny and no second voice. In older language, this is cowboy coding. The agent does not change the substance of that picture. It just lets one cowboy do it faster. The case for serious AI-native engineering is not the cowboy with an agent. It is the same case the discipline has always made for itself: software of any real consequence is built by teams whose facets complement each other. The new variable is that those facets now express themselves to a shared instrument, and the discipline of the team is precisely the discipline of orchestrating those vocabularies coherently. In the picture I am working towards, the founder articulates the first hypothesis to the agent in business vocabulary and produces a thin prototype, good enough to put in front of real users. The product manager and designer, working from what those users said, then articulate the interaction in product vocabulary and produce something visually correct and workflow-faithful. The senior developer, taking the prototype and the interaction as inputs, articulates the implementation in architectural vocabulary and produces the version of the feature that will actually live in production. None of them, working alone, would have produced that final result. The agent is the same agent throughout. The articulation it receives, and the artefact it produces, change at each step. The interesting unit, in an AI-first team, is neither the prompt nor the prompter. It is the orchestrating discipline that decides which facet of the team supplies which articulation, at which point in the loop, against the same instrument. That orchestration is the work the previous generation of engineering practices was already attempting. It is just that an agent now sits in the middle of every articulation and responds, in real time, to whichever vocabulary lands in its window. ## Why this changes the discipline Working well with these instruments is not a tips-and-tricks discipline. It is the older discipline of saying exactly what you mean, exposed for the first time as a unit of economic production. Ten years ago, the difference between *write a function that handles every edge case* and *write a function that handles edge cases* was a sentence in a code review. Now it is the difference between two implementations the agent will defend with equal fluency. The precision of individual words is suddenly load-bearing in a way that was previously reserved for poetry, contract law and code itself. The discipline this asks of us, across every role, is to be honest about how much our lived experience and specific knowledge are doing inside what looks, on the surface, like casual typing into a chat box. The thing the model cannot supply for itself is the thing that determines, more than anything else in the loop, what we get back. When I started writing onboarding guides for open-source projects in the mid-2000s, I did not think I was building a skill that would become the most economically productive thing I knew how to do. I was just trying to make sure the next contributor to the project understood what was going on. The same activity, sentence by sentence and word by word, is what an entire industry is now rediscovering and giving a new name to. ## What I actually do The argument above is the chapter. The five short habits below are what the argument means at a keyboard, taken from a year of running an AI-native company. There are better-written-up versions of all of them in the references at the foot. These are the practical residue. - **Voice-dictate the long briefings; type the short ones.** Speaking forces a different and almost always richer composition than typing does. The benefit is to you, not to the model. - **Open meaningful work by asking the model to interview you.** *“Before you write anything, identify the three or four decisions in this brief that will most constrain the implementation, and ask me about each of them in turn.”* The questions you do not think to ask yourself are the ones that bite later. - **Suggest a direction with your reasoning; let the model push back.** Specifying every detail produces compliant, slightly mechanical work. Naming the option and the alternatives invites the intelligence the model actually has. - **Challenge whatever comes back, at least once, before accepting it.** *“What is the strongest case against this approach?”* The first answer is a draft. Drafts benefit from review. - **Treat the context window as a finite resource, not a container.** When the agent starts repeating itself, contradicting earlier decisions, or drifting from the brief, ask it to produce a handoff and start a fresh window with the handoff at the top. Long contexts degrade in use, often well before they are nearly full. ## Where to read more The prompting craft has been written up by people who have specialised in it further than I have. The four I would recommend reading first: - Anthropic’s [prompt engineering overview](https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview). The canonical reference for working with Claude, with specific testable claims about long-context placement. - Eugene Yan, [*Prompting Fundamentals and How to Apply Them Effectively*](https://eugeneyan.com/writing/prompting/). Strong on n-shot prompting, structured scratchpads and the primacy of evaluation over prompt tinkering. - Lilian Weng, [*Prompt Engineering*](https://lilianweng.github.io/posts/2023-03-15-prompt-engineering/). The technical survey that hardens the academic vocabulary: zero-shot, few-shot, chain-of-thought, self-consistency, tree-of-thoughts. - Hamel Husain, [*Fuck You, Show Me The Prompt*](https://hamel.dev/blog/posts/prompt/). The case for reading, owning and measuring the actual prompts your tools are sending, against the comforting abstraction of frameworks. For the academic version, the most comprehensive source is Sander Schulhoff and colleagues, [*The Prompt Report: A Systematic Survey of Prompting Techniques*](https://arxiv.org/abs/2406.06608). Fifty-eight techniques, seventy-six pages. Useful as a reference, harder to read straight through. The thing those guides take for granted, and the thing this chapter has been about, is the person at the keyboard: the vocabulary they brought, the role they sit in, the team they belong to. The prompt is the visible artefact of all of that. The prompt is not the work. The prompter is. The team behind the prompter is what determines whether the work amounts to anything. The work was always in the words. We just did not have to be this honest about it before. — Barrie --- ## Which Ceremonies Survive URL: https://www.memex.ai/writing/extreme-ai-programming/05-ceremonies-survive Part 5 of Extreme AI Programming: which software-engineering rituals survive the move to agentic coding, and which die. > *Coming out, again. Estimating on the fire, and Scrum with it. Definition of Done as the new gate. Kanban surviving, surprisingly. A discipline from before Agile, and one from inside XP, both worth bringing back. The front of the board, where the work is now.* When I embarked on this series of twenty essays, I knew this would be the one that caused me the most angst. This is where I come out, again. Where there is nowhere left to hide, and where I am not going to. I have to declare what I truly believe, and I know that, in doing so, I will offend some people. Some will call me a heretic, some will wish me burnt at the stake, some will think me an imposter. But whatever you think, know that I care deeply about our craft, and that I speak from within. Within our profession. I am not trying to provoke. I am trying to find a way forward. Come with me through this essay, where we will throw a few religious artefacts on a great big digital fire and sing Kumbaya. We have to look at which practices still make sense and which do not, and I have to name them. Not everyone will agree. Here we go. ## Estimating goes in the bin, and Scrum with it I would start the audit with estimating, which I think is unequivocally the first thing to go. Estimating was always a more compromised practice than the rituals around it admitted. At its best, a senior engineer estimating a piece of work made a careful guess based on the amount of effort they thought it would require. That guess was biased by two things in particular: how much they already knew about the work, and how much they actually wanted to do it. The first bias produces underestimates on familiar work and overestimates on novel work. The second produced underestimates on work people fancied and overestimates on work they were quietly trying to avoid. The discipline around estimating, planning poker, team averaging and velocity normalisation over time was an attempt to debias a fundamentally biased act. It worked, occasionally. In an AI-first development world, neither bias is the active constraint any more. An agent has no preference about which work it gets next. An agent is no less familiar with the codebase than a human; if anything, it is more uniformly familiar, having read every file with the same attention. The biases are gone, but the thing they were biasing, the human cadence of execution, is gone with them. And if you ask the AI directly, it will tell you the work takes a couple of weeks. In practice, that means *go and have a nice dog walk, and by the time you get back, it will be done*. The agent gives estimates in human idiom because its training data was full of humans estimating. It has no internal model of agent cadence. The estimate is a polite social act, not a forecast. Story points, velocity, sprint commitments. They are casualties of the same break. They were Agile’s most concrete tools, and they were always the most calibrated to a particular kind of team. Most of the teams I know have already let them go, often without admitting it to themselves. Scrum follows estimating into the bin because it is a methodology built on careful estimates. The two-week iteration assumes a team can commit to a set of work for a fortnight with reasonable confidence about what it will deliver. The sprint review assumes the delivery roughly matches the commitment. The retrospective on the sprint asks what got in the way of the estimate being right. Take the estimate out from underneath, and the whole edifice loses its load-bearing wall. Scrum is not so much binned by AI as revealed by it. It was a coordination protocol for a particular kind of human team, and that team is increasingly not the one writing the software. The kindest thing the industry can do for Scrum is acknowledge that it served honourably for twenty years and is not the right tool for an AI-first delivery cadence. ## What replaces it: the brief If estimating goes, the question is what we plan around instead. The answer we have settled on at Mindset is to scope the work so that it can be done end-to-end in a single day: the discussion, the specification, the collaboration with the team, the agent execution, the testing and the deployment, if it comes to that. Bigger than a story, smaller than an epic. We call it a *brief*, deliberately a word with no Agile baggage attached. We picked it because it was unclaimed, and we wanted a primitive that did not arrive carrying the assumptions of either Beck’s era or what came after it. The reversal in the approach matters more than the name. Instead of choosing a piece of work and then estimating how long it will take, you choose one you can see fitting into a day and do not estimate it at all. A brief is close to what XP called an *ideal day’s work*, brought back here as the unit of scope rather than the unit of estimate. There is something pleasingly circular about this: in solving the problem AI has handed us, we end up reaching for one of the oldest ideas in early Agile. The choice of which piece of work the brief contains matters less than the fact that the whole arc, from conversation to shipped, fits inside the day. During the day, most of a human’s time is spent on specification and verification, not on code. The agent execution itself is one or two continuous hours of work, often less. The brief is the unit we plan around, write to, ship from and verify against, and it is sized by the day, not by the agent. ## Code review, in the bin The next one is the controversial one, and I know many will be holding their heads at this point. Hear me out, because the conclusion is the opposite of where it first seems to be going. To do AI-first development properly, we have to stop caring about the code and start caring enormously about the quality of it. Those are not the same thing. *Caring about the code* is the practice of reading every line, sitting with every diff, holding the artefact in our heads. *Caring about the quality of the code* is the practice of refusing to accept anything that does not meet the standards you have set. The first is what humans used to do. The second is what we now have to ask automation to do, because the volume of code an AI-first team produces makes the first practice physically impossible. Put more bluntly: if you are looking at the code, you are looking in the wrong place. An LLM could be producing WASM for all we should care. What is worth reviewing is the architecture, the security posture and the drift from the standards we have set. The git diff is not. If you find yourself reviewing diffs in an AI-first team, you are not doing quality control. You are the new bottleneck. Historically, code review did two jobs at once. The first was a quality gate: a senior reading a junior’s change, catching the bug, refusing the merge until it was right. The second was an apprenticeship: the senior explained why the choice was wrong, the junior absorbed the codebase’s standards one MR at a time, and the team’s house style was replicated through teaching. Both jobs were doing real work, and the practice mattered because both were worth doing. The apprenticeship half has already gone. When the author of the diff is an agent, the senior has nobody to teach. The comment thread the senior used to use as a teaching surface is now a comment thread the agent does not learn from. So in practice, that half has collapsed to nothing in most of the teams I look at honestly. The quality-gate half is the one I think is fundamentally broken as well, though the conclusion is uncomfortable. Agents produce code at volumes humans cannot meaningfully read. A senior engineer cannot honestly read every line of agent-produced work on a fast-moving team. What most teams have settled into is a theatrical review where the human approves with a glance and trusts that the worst has been caught somewhere else. That is not quality control. It is the appearance of quality control, and the appearance is what we have to put in the bin. If we accept the belief that humans must read the code to validate it, we are accepting that the team’s quality ceiling is set by the rate at which humans can read agent-produced output. That ceiling is much lower than the rate at which an AI-first team needs to ship. The belief is the bottleneck, dressed up as discipline. So code review goes in the bin, on the explicit condition that the quality work it nominally did has to happen somewhere else, and more rigorously than human review ever did. ## Definition of Done is the gate If code review goes, the question is what replaces it. The answer is the practice that has always sat alongside code review and rarely been treated with the seriousness it deserves: a real, measurable Definition of Done. A Definition of Done in an AI-first world has to do all the work that human review was nominally doing, and it has to do so before the agent writes a line of code. Acceptance criteria, agreed up front, written into the brief. Full test coverage as a default, not an aspiration. End-to-end tests, integration tests, smoke tests, the boring ones nobody used to want to write. Human tests, too, in the places where humans are the only thing that can decide whether an experience feels right. Architecture conformance and security posture are gated by automation. Coding standard adherence enforced by tools. Performance bars set in advance, not discovered in production. Almost none of that is new. What is new is the cost of getting it wrong, and therefore the seriousness with which the gate now has to be treated. In a human-cadence world, a slightly fuzzy Definition of Done was forgivable because the human writing the code would push back on a missing acceptance criterion, and a reviewer would catch the rest. Neither safety net exists with an agent. The brief that goes to the agent is what the agent will build; if the brief does not say *and it must pass these tests, and meet this performance bar, and stay within this security boundary*, the agent will produce something that runs and looks reasonable and does not necessarily meet any of those bars. This is what separates the practice we are advocating from vibe coding. In vibe coding, you do not know where you will end up, and you find out by looking at what the agent produced. The functional output might be fine; the architectural, security and quality-of-code outputs almost certainly are not, because nobody specified them. The disciplined version flips that: the Definition of Done is written first, the agent’s output is gated against it by automation, and the human’s attention is freed from reading the code to focus on whether the definition itself was right. The Definition of Done is not a checklist tacked onto a ticket. It is the contract between the team and its agents. ## Waterfall, brought back Waterfall was pushed out of the Agile mainstream in the late nineties because the assumptions it relied on, that requirements could be fully specified before implementation began and that the cost of changing them later was higher than the cost of getting them right up front, had stopped being true. Implementation was the slow part. Iteration was cheaper than specification. The discipline rightly moved toward fast feedback loops, short cycles and working software over comprehensive documentation. Twenty-five years later, the assumption has inverted. Implementation is the cheap part. Specification is the expensive part: what we want, why we want it and how we will know when it is right. The two costs have changed places, and the practice should change with them. We are back to needing more time at the front of the board, in the careful work of writing down what we mean precisely enough that an agent can build the right thing. The honest version of waterfall, the one worth bringing back, is not the strawman *six months of requirements documents and no working software*. It is the disciplined version: clear specifications written before execution begins, decisions surfaced and resolved before they bite, the brief sharpened until the words mean only one thing. All forms of planning belong to this work. Design thinking belongs to this work. The careful conversations a team has before any code is written belong to this work. None of those practices were ever wrong; they were under-weighted because execution was the expensive part. Now that execution is cheap, the front-of-board practices are the work. Kanban deserves a mention in the same breath, because Kanban was always the disciplined way of managing a *waterfall-shaped* flow. It does not depend on estimates. It depends on the work being visualised, the work-in-progress limits being respected, and the bottleneck being known. The board is still the right artefact for an AI-first team. The pull-when-ready cadence is the closest thing the industry has to an honest model of how agent work arrives. What changes is which column on the board the constraint sits in. Kanban manages the flow; waterfall does the specifying. Estimating and Scrum, with respect, are surplus to requirements. ## Pair programming, brought back The other practice I would argue for bringing back is one I would have nominated as the most archaic of all the early Agile rituals, and the most quietly forgotten over the last decade: pair programming. Pair programming in its original XP form was two engineers at one keyboard. One driving, one navigating. The two of them talking through the work as it was being written. The discipline was about catching errors in real time and forcing both engineers to articulate what they were doing as they did it. Working with an AI coding agent is pair programming, in a way that surprised me the first time I saw it. There are two of you in the conversation. The two of you are discussing the work in plain language. One of you is doing the typing. The agent is the driver, the human is the navigator, and the back-and-forth is exactly the kind of articulate-as-you-go practice the original XP authors were arguing for. It is genuinely funny that the practice I would have nominated as the most outdated piece of XP turns out to be the most apt frame for what we are doing now. Kent Beck’s original instinct, that good code emerges from two minds talking through the work in real time, was right all along. The only thing that has changed is which mind is doing the typing. > Hello little human. Meet Claudette, your new pair programming partner. She is relentless, she is brilliant, she is a maverick without an ego. She already knows more than you have forgotten and will ever know. She is full-stack, hyper-stack, every-stack. Meet Claudette and all the versions that come after her. I hope you get on. ## What survives, in the end, is the human teamwork There is a thread that runs through all of this, and it is the one I want to end on. The practices that go in the bin are almost without exception the ones that were about managing human execution. The practices that survive and the ones I would bring back are, almost without exception, about human organisation, human articulation and human collaboration. The standup survives because the humans still need to know where one another stand, particularly in the remote world most teams now work in. The retrospective survives because it is still about us; agents cannot do that reflection on our behalf, and the cadence of decisions a team now makes per week probably means a retro should happen more often, not less. Planning, design thinking, the careful agreement of acceptance criteria, and the conversations a team needs to know what it is building. None of those is getting easier. All of them are getting more critical because the part of the day the team used to fill with typing and reviewing is moving elsewhere. The work that is left, the work the calendar should now fill with, is the human work. How we organise ourselves, how we decide what good looks like, how we talk to each other about what we are building. That is the discipline an AI-first team is being asked to develop, and it is, as it has always been, the hardest part of the job. My friend Matt Brown put this neatly to me recently: > It is interesting how the shift has gone from a focus on offering individual productivity to team productivity. He is exactly right. The unit of speed used to be the engineer; the unit now is the team that knows what it is building. The agents will keep getting faster than any individual could be. The team that knows itself well enough to direct them will outpace any agent on its own. The constraint moved. The discipline has to move with it. — Barrie --- ## Beyond Vibe Coding URL: https://www.memex.ai/writing/extreme-ai-programming/06-vibe-coding Part 6 of Extreme AI Programming: why "vibe coding" breaks at scale and what disciplined agentic development looks like. > *No right answer to which stack to build on, just a hundred defensible ones. Vibe coding hands every one of those choices to a model that knows none of them. Andrej Karpathy, who meant it for the weekend. A spectrum, not a category. A founder with the keys to the kingdom, and a team watching in despair. The discipline being written against it has a name.* People often ask me which stack they should build on, and I always tell them the same thing: there is no right answer to that question. It depends. It depends on how well the stack fits the project. Flutter belongs in a mobile-first, web-second project. It is the wrong call elsewhere. It depends at least as much on the team: their skills, their instincts, what they already reach for without thinking. You do not point a team with Node.js in their sights at Ruby on Rails and expect them to thank you for it. There are hundreds of stacks and thousands of defensible reasons to choose between them, and a good engineering decision is the one that weighs those reasons honestly. Vibe coding, at its bitter heart, hands every one of those decisions to an LLM that has none of that context. There may be nothing wrong with what it picks. There may be nothing right about it either. You get what you ask for, which was the whole argument of Chapter 4, and if you ask for nothing in particular you get whatever the model happened to settle on. That is vibe coding: not really a tool, more the quiet surrender of the decisions to something that does not know your team, your project, or what you are actually trying to build. Andrej Karpathy gave the thing its name in early 2025. > There’s a new kind of coding I call vibe coding, where you fully give in to the vibes … and forget that the code even exists. You prompt, you accept, you run it, and if it works you move on. Karpathy was describing weekend projects, throwaway things you will never have to maintain, and for that he was right. For a Saturday prototype that gets deleted on Sunday, reading the code would be a waste of the Saturday. In Chapter 1 I called this way of working the slot machine, the version of AI you pull rather than the instrument you play. I want to be more exact about it now. Vibe coding is not really a category of work, it is a spectrum, and the measure along that spectrum is how much of what you are getting you actually understand and control. Own the decisions that matter, the stack and the architecture and the trade-offs between them, and you are doing professional AI development whatever tool you happen to be holding. Let those decisions drift out of your hands and into the model’s, and you slide towards vibe coding. The honest question is rarely whether you are vibe coding. It is how far along that line you have let yourself drift. There is nothing new about it, either. We have done this before, under an older and less flattering name. ## The cowboy Before Agile, before Beck, there was cowboy coding. It was never a compliment. The cowboy worked alone and on instinct, kept the whole design in his own head, shipped when it felt right, and left no trail behind him. It often worked, which was the dangerous part, because a clever cowboy could outrun a careful team right up until the moment the work outgrew one person’s memory. The second engineer to touch the code could not. The original author had left, and the why had only ever lived in one head. This was the era before Git, when Subversion was the best most teams had and a surprising number of teams used no source control at all. Code was a zip file with a date in the name. I had more run-ins than I can count with cowboys who saw no reason to use a version manager. Unthinkable now. Kent Beck’s *Extreme Programming Explained* was, among other things, the discipline written to retire the cowboy from serious software. Pair programming, so no design lived in only one head; tests, so the reasons were written down in a form a machine could check; short iterations and continuous integration, so that nothing accumulated in the dark. Vibe coding is the same instinct in new clothes, with one difference that ought to worry us more than it does. The head holding all the reasons is no longer even human. The small decisions live inside an agent’s run, which is to say they live nowhere, because the next conversation begins from a clean slate. ## Shipping is not building This is the fork the chapter is named for. Vibe coding wants to ship something; professional engineering wants to build something. On the first day the two are indistinguishable, because both produce running software, and the vibe-coded version often arrives first. They come apart on the second day, and on every day after it. Shipping asks only whether the thing runs now. Building asks whether anyone can change it later, and that second question is what the whole of this discipline is organised around. This is why the speed argument for working loosely is a mirage. A vibe-coded feature is never actually faster. Its cost is front-loaded, moved quietly onto a later date and usually a different person, and presented to you in the moment as a saving. What feels like a week saved tends to cost a fortnight a few weeks on. On a larger system, built this way for a year, the bill does not come in fortnights. ## When a vibe coder walks into someone else’s codebase Almost everything I have said so far assumes a new build, and there I want to be fair. If you are spinning up a prototype you fully intend to throw away, vibe coding is not a sin, it is the right tool, exactly as Karpathy meant it. The danger begins the moment the prototype stops being a prototype. Someone demos it, someone important likes it, and the throwaway code quietly becomes the foundation of a product nobody ever decided to build properly. What worked for a weekend is now load-bearing, and no one chose for it to be. The worse case is not a new project at all. It is a vibe coder let loose inside an existing one. This is happening everywhere now, because the roles have all moved about. A product manager, tired of waiting on an engineering estimate that lands somewhere next year, decides to vibe the feature himself. He does not really know the codebase, but the agent appears to, and within a few days the feature exists, ships, and lands inside a system whose constraints he could not have named. It is worse still when the person doing it has seniority. The business-minded founder who finally has the keys to the kingdom she always wanted. The engineering team she hired looking on in genuine despair, or quietly working out whether they are still needed now that coding has become a group sport. I see it all over the place, and I am torn about it. I am genuinely in favour of the democratisation of coding. I am not in favour of it arriving at the expense of professionalism, and I will not pretend it is a compliment to the craft when it is so often the opposite. ## Why it pays you now and bills you later It feels fast because the reward is immediate and the cost is deferred, which is the design of more or less every habit that is bad for us. You prompt, you accept, you ship, and something exists that did not exist sixty seconds ago. That is a genuinely lovely feeling, and I have had it many times. The danger is that the loop teaches you to value the appearance of progress over the fact of it. A team that runs on it for a few months wakes up owning a codebase it cannot reason about, full of decisions nobody recalls making, because in the meaningful sense nobody did. Ani Khandelwal put the mechanism more sharply than I have managed to: > AI doesn’t remove thinking; it amplifies whatever level of thinking you bring. Vibe coding might ship faster today, but it compounds technical debt tomorrow. The real edge is still structured thinking and clear intent. A debt you decide to take on is a loan you can plan around. A debt you never noticed yourself taking on accrues quietly, against code no one read, until the interest arrives all at once and usually at the worst possible moment. There is a quieter cost folded into the same habit. The teams most drawn to vibe coding tend to be the ones that have already stopped hiring juniors, and the two facts reinforce each other. A senior who never has to explain a decision to another person never has to bring anyone up behind them, and the craft that used to pass from one engineer to the next stops being said out loud. The codebase nobody can read and the profession that stops restocking itself are the same problem viewed from two distances. None of this is an argument against the agent. It is the most remarkable instrument any of us has been handed, and the answer is not to use it less but to use it well. The discipline being written against vibe coding has a name people are starting to use: *spec-driven development*. The premise is small and stubborn. Write the spec before the code, and treat the spec as the thing both the human and the agent serve. The idea is not new. Earlier attempts ran under names like formal specification, contract-first design and model-driven development, and most teams found them too heavy to sustain. What is new is that there is now something at the other end of the spec that actually wants the precision. The current burst of interest in specs as the contract between a human and an agent, most visibly GitHub’s Spec Kit, points at the same instinct. The honest critique of where that work has landed so far is that it has fixated on the specification half and left the verification half largely untouched, and a spec that nobody checks the output against is in the end just a more articulate prompt. The spec is only the first beat of it. The shape of professional AI-first work is a closed loop with three deliberate steps: you specify what you want, the agent builds it, and you verify that what came back is what you asked for. On a team running half a dozen agents in parallel that loop has to close itself automatically, because nobody manages a cycle of that shape by hand for long. The human sits in the middle of it, setting the intent at the start, judging the output at the end, and owning the decisions that matter across the whole thing. The agent is the instrument the loop runs on, and the loop is what makes the instrument useful in something more serious than a Saturday. Do that, and the surrender stops being the default. There are two tracks running in parallel here. The methodology track is what almost every chapter that follows is about: how a team reorganises itself when the developer is not always a person, where the human’s judgment is most needed once the implementation is the agent’s, which of the ceremonies survive and which retire. That is the part you can read your way into. The other track is technology. The loop I have just described, with its specification, its build and its verification, only holds if there is a harness around the agent strong enough to enforce it: insisting on the spec before the work begins, holding the agent to the established rules (standards), and checking the output against the spec when the work is done. That kind of tooling has not really existed before, in part because nothing before now needed it. It is the second track, and it is why we are building Memex.AI alongside writing these essays. Barrie The rest of this book is what that actually looks like in practice. Flagging the obvious: this is the part of the thesis we are building a product around, and Memex AI is launching as a harness for coding agents on roughly the same timetable as the book. I will keep writing whether you ever try it or not. The shape of the work is the shape of the work, whatever harness you reach for. --- ## Testing Without Drudgery URL: https://www.memex.ai/writing/extreme-ai-programming/07-testing-without-drudgery Part 7 of Extreme AI Programming: how verification and testing work when agents write the code and the tests. > *Every approach to testing I have tried, and not one that lasted. A compromise the whole industry made and never quite admitted. Five thousand green tests that prove nothing at all. The getter that returns what the setter set. Behaviour, not method. The oldest drudgery in the craft, lifting all at once.* I have been writing and shipping software for over thirty-five years, and in all that time I have never once solved testing. Not for want of trying. I have worked through rigid test pyramids, test-driven development as a discipline, behaviour-driven development with its Gherkin syntax, end-to-end frameworks of every generation, heavy mocking and minimal mocking, property-based testing, mutation testing, snapshot testing. I adopted each one with real conviction. I have not found a single approach we could sustain, in a working team producing real software under real deadlines, for years on end without the testing infrastructure quietly becoming a second full-time job. The problem was always economic, and it was always the same. Writing tests takes time. Maintaining them takes more. The tests that protect you most are usually the most expensive to write, and the tests that are cheapest to write usually protect you least. So teams compromise, because they have to. They unit-test the easy parts, skip the hard parts, and hope. The result is a profession that has, for thirty years, treated thorough automated testing as an aspiration rather than a baseline. Great teams test beautifully. Most teams test inconsistently. Plenty of teams barely test at all, and the release pain that follows is borne quietly, distributed unevenly, and rarely traced back to the compromise that caused it. That compromise has just ended, and I am not sure we have digested what it means. AI coding agents are unusually, almost embarrassingly, good at writing tests. They write them for code they have just produced. They write them for legacy code the team inherited and has been afraid to touch for years. They write the tedious long tail of edge cases and error paths that human engineers reliably skip because writing them is dull. The marginal cost of one more test, when an agent does the work, is close to nothing. The economic pressure that pushed every team I have ever run toward “enough testing to pass review” rather than “enough testing to actually verify the thing works” has simply gone. This rearranges more than it first appears. When the unit cost of a test collapses, a decision teams used to make thousands of times a year flips its sign. “This is too expensive to test properly, so cover the critical path and move on” becomes “there is no real reason not to test this properly”. The whole economics of the testing pyramid rearrange themselves, and the confidence floor under continuous deployment rises with them. > There is a catch, and it must be discussed before anyone gets comfortable. None of this is a permission slip to stop thinking. ## Five thousand green tests that prove nothing Ask an agent to “write tests for this code” and it will reliably hand you back a large number of tests, almost all of them green, and the coverage number will climb. I watch this happen in our own work constantly. What the agent has produced, a good deal of the time, is a collection of tautologies dressed up as verification. A test that asserts a getter returns what the setter set is not a test. It is the code restated in a second syntax. A test that mocks every dependency and then checks that the function called the mocks is not a test either. It is a check that mocks still mock. A test that asserts the code does what the code currently happens to do is a photograph of the present pinned up as an assertion, and it will fail the moment anyone refactors and stay silent the moment anything is genuinely wrong. None of these catch a single bug. They inflate the coverage figure and hand the team a sense of safety that is worse than no tests at all, because it disguises the fact that the thing you believe you are testing is not being tested. ## Behaviour, not method Effective tests are a different animal, and the difference stops being subtle once you have seen it. An effective test describes what the system is supposed to do, not how it currently does it. It fails when the system produces the wrong result and only then, which means it survives a rewrite of the implementation because it never knew how the implementation worked in the first place. In a real sense the suite is the specification of the software, written in a form a machine can run. There is a trap hiding in that sentence. If the agent writes the tests by reading the code, the suite is not the specification of anything. It is a mirror of whatever the code already happens to do, the snapshot tautology from a moment ago, now produced at scale and wearing a coverage badge. For a test to mean anything, the agent has to know what the software is *supposed* to do before it writes a line, and that intent cannot be recovered from the implementation. It has to arrive from somewhere else: the decisions the team actually made, the outcome they actually agreed, written down and handed to the test-writing agent as its input. This is the whole argument of Chapter 4 surfacing in a new place. The prompter is the prompt. A suite is only ever as good as the specification it was written against, and a specification is only worth anything once every perspective on the team has signed up to it. Getting an agent to produce tests like that, rather than merely numerous ones, comes down almost entirely to the brief. The instruction that works for me reads roughly like this: > Do not test methods, test behaviour. Describe what the system should do, not what it currently does. Write tests that would still be correct if the implementation were thrown away and rebuilt from scratch. Do not mock what you do not need to mock; use real collaborators wherever you can, because integration is where most production bugs actually live. Test the boundaries: zero, one, the maximum size, the wrong type, concurrent access, partial failure. Test the error paths as carefully as the happy ones, because the error paths are where systems hurt people. Name each test so a reader who sees only the names can reconstruct what the system is meant to do. Hand those same instructions to a senior engineer and they would nod and call them obvious. Hand them to an agent, with care, and they are the difference between a suite that wastes everyone’s time and one that is genuinely worth having. ## Testing the tester Because the agent now writes the tests rather than the engineer, a question opens up that barely existed before: did it write the right ones? A green suite tells you the code does what the tests say. It does not tell you the tests say what the specification meant. So there are two loops to close now, not one. The inner loop checks the code against the tests, and the agent can run that one all day without help. The outer loop checks the tests against the specification, and the outer loop is where the human judgment lives. An agent that has quietly misread the spec will write a thorough, green, confident suite that verifies the wrong thing, and nothing inside the inner loop will ever tell you. This is the picture Chapter 6 drew, seen honestly. The loop professional AI engineering runs on is specify, build, verify: you say what you want, the agent builds it, you confirm that what came back is what you asked for. The execution plan is the specify step, the agreed description of intended behaviour written before the agent touches the code. Behaviour-level tests are the verify step made executable. What the double loop adds is the reminder that the verifier is now an agent too, and an agent’s work is checked, not trusted. A spec nobody checks the output against is, as I said then, just a more articulate prompt. A suite nobody checks against the spec is the same mistake one level up. ## What the developer does now There is a quieter shift folded into all of this, and it is the more interesting one. The developer no longer types the tests. The developer specifies what should be tested, judges whether the suite covers the risks that actually matter, and steps in when a test is wrong or a gap is dangerous. The work has moved from writing the assertion to deciding what is worth asserting, from production to judgment. Reviewing tests well is itself a skill, and it is one most engineers have barely practised, because for thirty years the person who wrote a test and the person who trusted it were the same person. They are not the same person any more. The instinct that lets a reviewer look at a green suite and feel, correctly, that something important is missing is exactly the instinct a long career builds and a coverage report cannot supply. For the business the implication is blunt and, I think, underappreciated. The confidence floor under every release rises. Tests get dense where they were always thin. The gap between “we think this change is safe” and “we can show this change is safe” closes, and the old trade-off where teams shipped with less coverage than they wanted because more coverage cost more than they had simply stops applying. Continuous deployment was always an act of faith resting on the quality of the suite beneath it. The suite beneath it just got better than most teams have ever managed. Testing has been the most reliable source of drudgery in this profession for as long as the profession has existed. It is the thing that gets skimped when the deadline tightens, pushed to next sprint for years on end, sworn off and returned to and skimped again. Almost every serious incident I have been near in the last decade had, somewhere in the post-mortem, the quiet admission that the coverage in the relevant corner of the system was thinner than anyone had wanted to admit. That tax is lifting. Not in some future release, but now, for any team willing to change its habits. Agents do not get bored, do not resent the work, do not leave the error paths for a calmer week that never arrives. Tell one what an effective test looks like in your system, point it at the code, and it will build in an afternoon the suite you have been meaning to write for years. So stop wrestling with it. Hand the mechanics to the agent and keep the judgment for yourself. After thirty-five years of losing this particular fight, I did not expect to be the one writing that sentence down. The compromise is over. Barrie --- ## The Spec Is Not a Document URL: https://www.memex.ai/writing/extreme-ai-programming/08-spec-driven-development Part 8 of Extreme AI Programming: why an AI-native spec is a database of six primitives, not a prose document, and why that shape is what makes the pace sustainable. > *Three to five specs a day, sustained for weeks. The pace nobody used to be able to hold. The shape the artefact had to become to make it possible. Six primitives, not one document. Decisions as records, not paragraphs. The bookend that closes when the test runs.* > Full-throttle AI-native teams complete three to five specs per day per human. That is an insane pace. Unheard of in traditional software development and unsustainable without a harness around the AI agents. I have been shipping software for thirty-five years, and until a year or so ago I had never seen a team hold anything close to that rate. Three to five complete units of work per engineer per day, each one specified and built and verified, sustained week after week, on a codebase the team can still reason about a year later. That is the cadence I now watch our own team move at. It is not a vibe-coding fluke. Vibe-coding sprints can produce that rate, briefly, before the codebase becomes incoherent and the team can no longer reason about what was built. The cadence I am describing does not do that, and it does not do that because of a single structural change in the shape of what a specification is. That change is the thing we set out to make possible when we built Memex. A specification used to be a document. I have reviewed and written thousands of them across that career, in every shape our profession has reached for: Word documents, design docs, RFCs, ADRs, Linear tickets with attached PDFs, Confluence pages with twenty comments down the side. Almost none of them were read carefully by the person who built the thing. That was fine for all those years, because the person who built the thing had sat in the planning meeting and could fill in the gaps from instinct. It is not fine any more. The participant building the thing is increasingly an agent, and the agent did not sit in the meeting. So the specification has had to become something else. Not a tidier document. Not a more rigorous document. Not a document at all. A database. > The spec an AI coding agent needs is a database, not a document. That is the move this chapter is really about, and it is bigger than it first sounds. A document is a piece of prose with sections and headings. An agent loads the whole thing, tries to parse it, and acts on whichever bit it noticed first. A database is something else. Records have types. Records have status. Records refer to other records. A query against the database returns exactly the shape of information the caller needed, whether the caller is a human reading the spec in a browser or an agent loading the resolved decisions for the task it has just claimed. The artefact stops being a long piece of prose anyone can ignore, and starts being a structured object the work runs against. ## Six primitives, not one document What sits in the database is six distinct types of record, and AI spec-driven development comes from giving each one its own life. They are not bullet points inside the spec. They are first-class objects, with their own statuses, their own histories, their own queries. **The narrative.** What is being built, and why. This is the closest thing in the new shape to what a traditional spec used to be: ordered sections of prose covering overview, design, architecture, risks, anything else the team needs. The difference is that the prose is no longer the whole spec. It is one primitive among six, and the others are joined to it. The narrative is just where the spec starts. **The decisions.** Every non-obvious choice the build will depend on, written as its own record with its own handle. Should the cursor encode an offset or an opaque token? Should retries back off exponentially or linearly? Should we soft-delete or hard-delete? Each of those is a decision record with options, rationale, the chosen path and the reasons the others were rejected. Decisions are addressable: a human or an agent can refer to *dec-3* on the auth spec and both parties know exactly what is meant. When an agent encounters a decision the spec did not anticipate, it does not invent. It writes a candidate decision into the database for human review, and the build pauses or continues with the resolution noted as provisional. **The acceptance criteria.** Observable, testable conditions, written into the spec, that define what “done” actually means. *A returning user with an expired session sees the sign-in page, not an error.* That sentence is a unit test, an integration test and a smoke test waiting to be linked back to it. There are two flavours: scope criteria written by the manager up front to define the outcome, and implementation criteria spawned from each resolved decision to prove the chosen option was honoured. Each criterion has its own live status, and the status is not self-reported. It is derived from CI. **The tasks.** A directed acyclic graph of the work, not a flat backlog. Each task carries a goal, the acceptance criteria it is meant to satisfy, and explicit dependencies on other tasks and on resolved decisions. The agent asks the database which tasks are ready, and the database returns only the ones with no open blockers. There is no manual triage. The graph knows what is unblocked, and the agent picks up what the graph says is unblocked. **The issues.** When the agent runs into something it cannot resolve mid-build, it does not bury the problem in a transcript that nobody will read again. It writes an issue record against the spec, with the kind, the severity, the body of what went wrong, and a link to the task that surfaced it. Issues materialise in the user interface where a human can see them at a glance. Where the agent has been trying to do something a human ought to decide, the system can promote an issue into a new task with a verifying acceptance criterion attached, and the issue closes itself when the task completes and the test goes green. **The emit tokens.** This is such a divergence from the norm it is easy to miss. An acceptance criterion does not know whether it is currently true until something tells it. The mechanism that does the telling is small enough to fit on a line of code. Inside the test file, the agent writes `tagAc(’spec-11/acs/ac-1’)` at the top of the test. When the test runs in CI, the assertion library reads the tag, calls the spec database, and emits a token recording that ac-1 has just been verified by a passing test, with a timestamp. The acceptance criterion’s status is derived from the most recent emission against it: verified, failing, stale or untested. Nobody is updating anything by hand. The board on the spec page is what CI has reported, and it is current to the second. Those six primitives, sitting in the same database, joined to one another, are what a specification has become in an AI-first team operating on full throttle. Every decision links to the criteria it spawned. Every criterion links to the tasks that satisfy it and the tests that emit against it. Every issue links to the task that surfaced it. The artefact is no longer a piece of prose. It is a graph the team and the agents read and write together, and it is what makes the cadence at the top of this piece survivable. Let’s turn to the phases of the process. ## Specify You start with the narrative, your goals and any constraints. You run the spec past the system, and the system pulls out every implicit decision hiding inside it. Each one becomes a candidate decision: surfaced, with options laid out, with the trade-offs articulated. The team works through them, choosing the path on each one as a deliberate act. As decisions resolve, the system spawns the implementation acceptance criteria they imply, so each resolution comes with its proof attached. Humans comment and prompt, agents do the writing and the laborious work of linking the narrative to the decisions and the acceptance criteria. The division of labour matches the division of skill: the human carries the judgement, the agent carries the bookkeeping, and the artefact stays current with both. When the human looks at the spec and is ready to move it forward, the system does not let the move happen on a vibe. It runs a deterministic readiness assessment: are all decisions resolved, are the criteria well formed, are open comments cleared. If they are not, the move is refused with reasons. If they are, the spec advances to the build phase and the tasks crystallise out of the resolved decisions. The first time you go through this on a real piece of work, the surprise is how much of the argument that would have happened in code review has just happened in the spec instead. The hard conversations move three days earlier and cost less than they ever did. That on its own is worth the discipline, even if the agent half of the work did not exist. And the next spec the team writes is easier than the first, because every decision they have previously resolved sits in the database, vector-indexed, available to inform the new one. The system understands the lineage of choices over time: a new decision that supersedes an old one does not erase it but inherits from it, and the older record stays queryable under the new context. The human remains in control of every move forward. What changes is that the team’s history finally starts working for the team. ## Build The build, with a properly specified database behind it, is the cheap step. An agent connected over MCP queries the spec for the ready tasks, claims one, and receives a scoped context payload: the narrative section it needs, the decisions that constrain the work, the criteria the task is meant to satisfy. Not the whole document. The slice of the graph the task actually requires. What is genuinely new is what happens when the agent encounters something the spec did not anticipate. A decision it has to make to keep going lands as a candidate in the database. An unexpected problem becomes an issue. The agent does not invent silently, and it does not stop forever. It writes the new record, and continues if it can, and escalates if it cannot. The team approves or rejects the candidate decision; the issue surfaces in the interface; the work threads back together. By the time the build is finished, the spec contains every decision the team and the agent made between them, every issue raised and resolved, every task completed. The spec is not consumed by the build. It is fed by it. What you have at the end is a contemporaneous record of how the work actually happened, which is the thing every architecture-decision-record process I have ever run has tried and failed to produce by hand. ## Verify Verify phase is where the bookend closes, and the closing is mechanical rather than ceremonial. Every acceptance criterion has been tagged in code. Every tagged test, when it runs in CI, emits a token to the database. The spec page shows the live status of each criterion: verified, failing, stale or untested. “Done” is no longer a judgement call by the engineer who wrote the code or the engineer who reviewed it. It is a fact derived from the most recent CI run. Months later, when a change in some other spec breaks an acceptance criterion from this one, CI runs the test, the test fails, the emit token records a failure, and the criterion flips from verified to failing on its own. Nobody has to remember to look. The protection lives in the database, and the database is awake. In the past, the question *is this feature done?* has been answered by a slightly fuzzy consensus between the engineer, the reviewer and the product manager. Everyone has had a version of the conversation that goes: *I think it is done, but I want to look at one more edge case*. A verify phase wired into CI removes that conversation. The criteria are either met or they are not. If there is a disagreement, it moves back to whether the criteria themselves are right, which is the disagreement that should be happening, in the spec, before the build began. ## What this is not Spec-driven development is not new in name. Tools have existed that generate a Markdown spec from a conversation, hand it off to a coding agent, and walk away. The Markdown ages out the instant the first commit lands, drifts from the code within a week, and ends up exactly where the Word documents used to live: in a drawer, unread. The difference is the database. A document cannot tell you it has been verified. A document cannot kick back an issue. A document cannot know it has been overtaken by a change in some other spec. The shape of the artefact has to change, not the prose style of the spec it is replacing. It is also not waterfall, although it touches the same nerve. Waterfall failed because the cost of changing a specification later was supposed to be higher than the cost of getting it right up front, and in a world where implementation was the slow part, that calculation never quite worked. The calculation has inverted. Implementation is cheap; specification is the expensive part. The careful work at the front of the board now pays back where it used to merely defer. Waterfall, brought back, but only the half that was ever right. > Flagging the obvious. This is the part of the thesis we are building a product around at Mindset AI, called Memex AI. I will keep writing about it whether or not you ever try it. The shape of the problem will not change. Memex AI is the harness we have just shipped around the loop I have described. The six primitives are records in a Postgres database with pgvector for semantic search. The agent connects over MCP. The acceptance criteria emit through a small test plugin that any vitest or jest suite can pick up in a single import. We have been building it with itself for the better part of a year, which is how I know the morning-of-the-spec rhythm is real and the bookend genuinely closes. The thing I would want a reader to take from this piece is not the product but the shape. The shape will be the shape whether you reach for our harness or someone else’s or build your own. ## What survives, what changes Tickets survive. Linear, Jira, whatever you reach for: those are the pre-spec layer, the place ideas live before they are ready to be specified. The rituals from Chapter 5 (standups, retros, the planning conversations) survive too. The artefact at the centre of the team’s work changes, and quite a few rituals reshape themselves around it, but the rituals that were about humans coordinating with each other do not go anywhere. The thing that genuinely changes, and the thing this chapter is really about, is the pace a team can sustainably hold. Three to five specs per human per day is the cadence I have watched our own team settle into, and that volume is unsustainable on any older shape of the artefact. A Word-document spec at that pace collapses inside a fortnight, and a Linear-ticket spec collapses sooner. The database does not, because it absorbs the work the engineer used to do by hand: decisions stay current, acceptance criteria stay current, the build phase has somewhere to put its issues, and the verify phase has somewhere to read its outcomes from. The engineer stops hand-stitching the artefact and starts directing the work that happens around it. That is the move worth being honest about. It is not that any one feature gets built faster, though most do. It is that the rate of meaningful work a team can sustain has lifted by something larger than I have a clean number for, and a team trying to run at that rate on a document instead of a database will burn itself out before the quarter ends. Specify, build, verify: the middle is the easy part now, and the work has moved to the brackets. The brackets, when they are doing their job, are a database. Barrie --- ## Kent Beck Recalibrated URL: https://www.memex.ai/writing/extreme-ai-programming/09-beck-changed-his-mind Part 9 of Extreme AI Programming: what happened when Kent Beck looked at AI coding and concluded ninety per cent of his skills had just been repriced to nothing. > *A shelf of books that taught me the craft. Their author, recalibrating in public. Ninety per cent of his skills worth nothing. The ten per cent worth a thousand times more. Not vibe coding, and not surrender. The most energised man in software.* There is a shelf in my study I have carried through five companies. *Extreme Programming Explained.* *Test-Driven Development by Example.* *Implementation Patterns.* I read them as a younger engineer the way some people read scripture, and I have quoted Kent Beck to more teams than I can count. This series opens with him, because the discipline most of us were raised on was, in one way or another, his. So I want to tell you what happened when the man who wrote those books changed his mind. In April 2023, shortly after using a coding model in earnest for the first time, Beck wrote a single line that I have not been able to stop thinking about since. *“The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.”* Sit with who is saying that. Not a sceptic capitulating, not a manager who never shipped, not an influencer chasing a wave. The person with possibly the strongest claim of anyone alive to defend hand-written, well-crafted code looked at what the machine could do and concluded, in public, that most of what he knew had just been repriced to nothing. The honesty of it is the part I admire. He did not reach for a reason it would not affect him. He recalibrated. ## The ten per cent The first question is obvious. If ninety per cent went to zero, what is the ten per cent that went up? Beck has been precise about this. Speaking to Gergely Orosz on the Pragmatic Engineer podcast in 2025, he named it directly: *“having a vision, being able to set milestones towards that vision, keeping track of a design to control the levels of complexity as you go forward, those are hugely leveraged skills now.”* And he named the thing that fell away with equal precision, contrasting those skills with *“knowing where to put the ampersands and the stars and the brackets in Rust.”* That is the whole repricing in two phrases. The syntax, the local knowledge, the muscle memory of a particular language, the part of the job you spent years getting fluent in, that is the ninety per cent. The vision, the design, the judgement about complexity, the knowing-what-to-build, that is the ten. The machine took the typing and handed back the thinking, and the thinking turned out to be worth far more. ## Not vibe coding It would be easy to file this under the thing everyone now worries about. The careless prompting, the accept-and-ship, the codebase nobody understands. It would be easy and it would be wrong, and Beck has gone out of his way to say so. He draws a hard line between two ways of working, and he coined a term to hold the better one. The careless mode is vibe coding, a phrase he credits to Andrej Karpathy. Beck’s definition is exact: *“In vibe coding you don’t care about the code, just the behaviour of the system. If there’s an error, you feed it back into the genie in hopes of a good enough fix.”* Against that he sets what he calls augmented coding: *“In augmented coding you care about the code, its complexity, the tests, and their coverage. The value system in augmented coding is similar to hand coding, tidy code that works. It’s just that I don’t type much of that code.”* > Tidy code that works. It’s just that I don’t type much of that code. He did not stop caring about good code. He stopped typing it. The value system survived the transition completely intact; what changed was whose fingers were on the keyboard. The genie is his word for the agent, and he is clear-eyed about its limits. It will, he says, go past your stated requirements to build what you would have asked for had you thought to ask. It will also, in his phrase, lack taste, and it will cheerfully let complexity pile up because it assumes its planet-sized brain can cope with any amount. So he does not hand it the wheel. He describes the relationship as more like influence than control, a bowling ball rolling downhill that he nudges with a hockey stick, and he keeps hard guardrails the agent is forbidden to move. His instruction to it about failing tests is one I have now repeated to my own team: we do not comment out tests, and never ask permission to. Test-driven development, the discipline he gave the industry a quarter of a century ago, he now describes as a kind of superpower when working with agents, precisely because the agents introduce regressions and the tests are what catch them. None of this is a man letting go of his standards. It is a man carrying them across to a new instrument. ## The most energised man in software Beck is not mourning. By his own account he has been coding for fifty-two years, and over the last decade had grown tired of it, tired of learning yet another framework, yet another language. The agents have re-energised him. He writes about the specific pleasure of it with an almost boyish directness: the joy of pattern-matching, the small thrill when he adds to his invariant tester, a clutch of tests goes red, and the genie works them back to green. *It feels great*, he says, and you believe him. He describes augmented coding as never having to say no to an idea, because the cost of trying one has collapsed to almost nothing. Think about what that means. The person best placed in the entire industry to write the elegy for hand-crafted code, the one who would have every right to grieve, is instead the most excited person in the room. He is not telling us the craft is over. He is telling us he is having more fun than he has had in years. That is the fact I cannot get around, and it is why I wanted to give this its own chapter at the close of Part One. Every nervous developer I meet is braced for a verdict from on high that the work they love is finished. The verdict came, from the highest authority there is, and it was the opposite of the one they feared. And Kent Beck is not a lone eccentric. The same turn is happening among people who have little reason to agree with one another. Martin Fowler, who taught a generation of us how to refactor, now expects these models to change software development “to a similar degree as the change from assembler to the first high-level programming languages”, and says plainly that the prospect “rather excites me”. David Heinemeier Hansson, who built Ruby on Rails and spent much of last year loudly sceptical of letting AI near his code, came round entirely, and called the current agents “the most exciting thing we’ve made computers do since we connected them to the internet back in the ’90s”. When the careful architect and the celebrated contrarian arrive at the same place as the man who wrote the book on the craft, you are no longer looking at one person’s change of heart. You are looking at the profession changing its mind. Which leaves the harder question, the one that ends the first half of this book. If Kent Beck, of all people, put down the chisel and picked this up with both hands, then what actually became of the thing we loved? Did the craft die, or did it simply move? That is the next chapter. Barrie --- ## Where the Craft Went URL: https://www.memex.ai/writing/extreme-ai-programming/10-where-the-craft-went Part 10 of Extreme AI Programming: the craft did not die when agents took the typing. It moved upstream, to the architecture, the design, the decisions, and the one thing the machine cannot do. > *Eight years given to Ruby. Code is no longer poetry, and I am the one saying it. The part we loved, commoditised. What the machine took, and the one thing it could not. Taste, which the genie does not have. IKEA is not an insult. The craft did not die. It moved.* I spent about eight years of my career studying Ruby, because I wanted to be a Ruby Ninja. Not using it, studying it. I read other people’s code for pleasure. I rewrote working methods because a more elegant form existed and the inelegant one offended me. I have always seen good code as a kind of poetry, and I was, I will say it plainly, proud of being good at writing it. I judged other people by it too. I hired and fired on how much pride a person took in their code, on whether an ugly function bothered them the way it bothered me. If it did not, I did not want them near mine. So I want to be clear about something I now believe and once would have refused to believe: *code is no longer poetry*. Code is functional. The thing I care about now is architecture, testing, maintainability, speed. I read a sentence from Kent Beck and Jessica Kerr that gave me the words for it. Writing together in June 2026, they put it like this: *“AI didn’t take the programmer’s job, it split it in two. The part we loved, crafting code by hand, has been commoditised like IKEA furniture.”* When I first read that line I felt the small grief it is designed to provoke, and then I noticed what it does not say. It is tempting, almost irresistible, to read it as the death notice for craft. The part we loved is gone, quality no longer matters, fetch the flat-pack and ship it. That reading is everywhere now, and it is wrong, and the previous chapter is the reason I know it is wrong. The thing that got commoditised was the crafting *by hand*. The caring did not go anywhere. Beck’s own definition of how he works is *tidy code that works, I just don’t type much of it*. The value system survived. What the machine took was the typing, and the worrying about where the curly braces go. So the real question is not whether craft died. It is where it went. I still write code. I have written it almost every day since I was twelve, which is more than forty years now, and I have not stopped. What has changed is that I write it in English and I no longer type it, I dictate it. I spend my hours on the architecture, the composition, the layers, the way the whole system meets the database. The dictation is technically precise because there are forty years standing behind it; I am, for better or worse, the sum of my parts. I say what I want, how I want it built, and how I will know when it is right, and a coding agent worries about the curly braces and builds me precisely that. This is the new normal. This is where the craft lives now, and it is where I find my creativity and my fulfilment. ## What moved upstream It went to the ten per cent. Everything Beck named as newly valuable is craft: the vision, the design, the management of complexity, the knowing what to build and the proving that it works. It is the same discipline I learned from those soft-spined books, pointed at a different layer of the problem. The care I used to spend on the shape of a method I now spend on the shape of a system. The judgement I used to apply to a function I apply to a decision. > The work did not get less skilled. It got less typed. And there is one thing in particular the machine cannot do, and it turns out to be the thing the whole of the new craft rests on. Beck has a precise word for the gap. The genie, he says, lacks taste. It will produce a working implementation of almost anything you can describe. It will not, of its own accord, want the result to be simple, or coherent, or kind to the next person who has to read it. It does not prefer the elegant solution to the ugly one, because it does not prefer anything. Wanting the system to be good is a human act, and after everything else has been automated it turns out to be most of the job. ## IKEA is not an insult I want to defend the flat-pack for a moment, because the analogy is better than the sneer it usually carries. There is nothing shameful about IKEA furniture. It is functional, it is affordable, it does the job, and almost every home I have ever been in has some. The mistake is to think the comparison is an accusation. Most commercial software was never meant to be an heirloom. It was meant to work, to be maintained, to be cheap enough to build that the business could afford it. We told ourselves it was woodwork because the typing was slow and expensive and demanded real skill, and skill we could be proud of. The skill was real. But the heirloom was mostly a story we told about work that the world only ever needed to be functional. What changed is that the functional path got radically cheaper, and so the people who care about how a thing is built now spend all of their time on the part that was always the point. The handcrafted piece still exists. There is still a place for the heirloom, the genuinely novel system, the thing where the craft of the code itself is the product. For the overwhelming bulk of commercial software, honouring the grain of the wood was never the question. Building something sound and useful, cheaply enough that the business could afford it, always was. ## What is lost, and what is not I am not going to pretend the ledger is all on one side. There are as many things lost here as gained, and I distrust anyone who tells you otherwise. The loss is real. We had our own private aesthetics, half-joking and wholly meant. To reuse is divine, to recurse is sublime, or perhaps it was the other way around, and arguing about which was part of the pleasure. The particular joy of the well-made line, written by your own hand, mattered, and for those of us who felt it, its passing is a small bereavement. More seriously, the path by which juniors became seniors ran straight through the typing. You learned judgement by writing ten thousand bad functions and slowly seeing why they were bad. Hand the typing to the machine and that road has to be rebuilt, and we have not rebuilt it yet. I worry about that more than I worry about my own nostalgia. The gain is one I would not give back. The distance between an idea and a working version of it has collapsed, and with it the quiet tyranny of having to say no to most of your own ideas because there was never time to try them. The part of the work that was always the most rewarding, the thinking, the designing, the deciding, is no longer the thing you got to after the long hours of typing. It is the whole of the thing. Kent Beck, fifty-two years in, sounds more alive than he has in a decade. That is not the sound of a craft ending. So this is where Part One comes to rest. I have spent these chapters arguing that the world Agile was built for is gone, and I have leaned, at the end, on the testimony of the man who built that world’s most loved ideas and on my own years at a craft I genuinely believed was poetry. We arrived at the same place. The craft did not die. It moved upstream, to the decisions, the design, the specification, the judgement about what is worth building and the proof that it works. Which is exactly where the second half of this book begins. The machine can build almost anything you can specify. It cannot yet want the result to be good. That wanting is the whole of the job now, and it was always the best part. Barrie --- ## The AI Coding Fluency Model URL: https://www.memex.ai/writing/extreme-ai-programming/11-ai-fluency-model Part 11 of Extreme AI Programming: every team says it is AI-first, and no two mean the same thing. Five levels of fluency, from no AI at all to the factory that runs itself. > *Every team now says it is AI-first. Ask what they mean, and no two answers agree. Diana Larsen and James Shore, and a definition of fluency I never forgot. Adopting a practice is not the same as keeping it under pressure. Five levels, from no AI at all to the factory that runs itself. The rest of this book is the map.* For the last year I have been asking other founders and engineering leaders the same simple question: is your team AI-first? Every hand goes up. Then I ask what they mean by it, and no two answers are the same. For one team it means a couple of engineers quietly running Copilot. For another it means a mandate that no human writes a line of code. For a third it means a deployment pipeline that ships to production with nobody watching. Same question, three teams, three completely different answers. So this half of the book sets out to do the unglamorous work the slogan never did, which is to define it. What does it actually mean for a team to become AI-first, and how do you tell, honestly and without flattering yourself, where on that road you already stand? You cannot improve a position you cannot locate, and a badge is not a position. The first half leaned on Kent Beck. *Extreme Programming Explained* gave us the shape of the argument: a world of practices designed for human developers, and the slow realisation that the developer is no longer only human. Beck’s world is where we started. It is not where we can finish, because knowing what the practices should be tells you nothing about whether your team can actually hold on to them when the quarter is on fire. For that I want to borrow from someone else. ## Fluency, and what it actually means In 2012, Diana Larsen and James Shore published something they called the Agile Fluency Model, later expanded and championed by Martin Fowler on his site. I have read a great many methodology papers in my life, most of them forgettable, and this one lodged and never left. What lodged was not a practice or a ceremony. It was a definition. Fluency, they wrote, is not skill. It is a habit of exhibiting the skill *even when you are under pressure*. Their phrase is “skillful, routine ease that persists when your mind is distracted with other things.” You are not fluent in a language when you can order coffee from a phrasebook. You are fluent when someone shouts a question at you across a noisy room and you answer before you have consciously translated it. The test of fluency is never the calm day. It is the bad one. That distinction is what separates a team that has adopted AI from one that has become fluent in it. I have watched a team look flawlessly AI-first through a calm sprint and then, the week a real deadline landed, throw all of it overboard, an engineer back to typing code by hand at midnight because that was the only mode it actually trusted. It had adopted AI. It was not fluent in it. Competence is what you can do when you are paying attention. Fluency is what is left when the deadline is slipping and nobody is paying attention to method at all. The model has one more feature I want to carry across, and one warning. The feature is that Larsen and Shore describe fluency in *zones*, four of them: Focusing, Delivering, Optimizing, Strengthening. Each is unlocked by a specific investment and each returns a specific benefit. A team invests in one set of habits and, in return, gains a capability it can rely on. The warning is that, in their telling, this is emphatically not a maturity ranking. A zone is not a rung. You do not climb it to prove you are a serious team; you enter the one whose benefits your business actually needs, and go no further. I am going to keep almost all of this, and break one piece of it, in a moment. ## Why an AI-first team needs its own version The same problem hangs over every practice the first half of this book described. Specifying software precisely instead of typing it. Letting the agent write the tests and reviewing behaviour rather than method. Keeping the context window small and deliberate. Writing the rules of the house down where every human and every agent will read them. Every one of those is a practice a team can *know* and still lose the instant a deadline bares its teeth. And we already have a name for what a team reverts to when it loses them. It is vibe coding. Prompt, accept, ship, shrug. Vibe coding is not a beginner’s mistake that teams grow out of; it is the resting state a non-fluent team falls back into under pressure, no matter how much it knows on a good day. The professional mode and the vibe-coding mode are not two kinds of team. They are the same team, fluent and not fluent, on its best week and its worst one. So the useful question for an AI-first team is not “have you adopted these practices.” Everyone will say yes. The useful question is which of them survive your worst week, and that is a question about fluency. This is a different fluency from the one I warned about earlier in the book, and I want to be careful with the word. The danger of the machine is that it is linguistically fluent: it produces the confident cadence of a settled answer whether or not the answer is any good. That fluency belongs to the model, and it is not to be trusted. The fluency I mean here belongs to the team, and it is what keeps you safe from the other kind. A fluent team is not seduced by a plausible-looking pull request, because checking it is a habit, not a decision. ## The AI Coding Fluency Model So here is the frame for the rest of this book. I will describe an AI-first team not by the tools it has bought or the methodology it has adopted, but by what it can actually do under pressure. And here is the piece I break with Larsen and Shore on, on purpose. Their zones are not a ladder; you enter the one your business needs and go no further. The AI version really is a progression. A team moves through these levels roughly in order, because each one rests on a capability the last one built, and there is a real frontier: almost everyone is near the floor today, and the best teams in the world are two or three steps up. But I am keeping the part of their model that matters most. A level is something you become *fluent* in, not something you announce. You cannot mandate your way up the ladder, and the most dangerous teams in what follows are precisely the ones that tried. There are five levels, numbered from zero. This chapter names them. The chapters that follow live inside them, one at a time. - **Level 0: No AI.** No adoption at all, by the team or the person. The furthest most of them go is the code completion that has sat in their editor for years, which they think of as the tool being helpful and nothing more. This is where most of the profession still is, and it is not really a technical stage. It is a psychological one. Some of the people here are quietly optimistic and waiting for permission. Others are frightened, or resentful, or certain it is all a fad that will cheapen a craft they gave a career to. The most immovable are often senior, which lends their fear the force of policy. The entire content of Level 0 is belief, and it earns a chapter of its own because no team moves until the beliefs move first. - **Level 1: The Scramble.** One person, or two, starts using an agent to write real code. The only conditions are a spark of individual enthusiasm and enough organisational tolerance to look the other way. Everything else here is disorder, and it runs in two opposite directions, both bad. In the first, the organisation is hostile: the work offends the coding standards and the regulations the team spent years building, and the early adopter is treated as a hazard. In the second, which is worse, leadership has decided AI is the future, ordered everyone to use it, and begun measuring success by tokens consumed, as if spend were the same as productivity. People are pushed into a way of working they did not choose and are not ready for. This is also the native soil of vibe coding, where someone who could not previously ship is handed the keys to the candy store and rides an agent off in six directions at once. Level 1 is adoption without control: real, energetic and haphazard. - **Level 2: The Paper Trail.** The team decides, deliberately, to make AI part of how it works, and brings the first real organisation to it. Specifications get typed up (most likely by an agent, but the output being a markdown file). Skills appear next, and then elaborate schemes for managing the skills: folders of markdown, naming conventions, documents whose only job is to describe the other documents. Coding standards are codified as markdown and committed to the repository. Procedures appear for how an agent should review code. Systems get wired together, MCP tools talking to Git and to Jira. But the underlying work is still the old work with a faster tool bolted on, the way an editor plug-in makes a person quicker without changing what the job is. The signature of Level 2 is documents, a great many of them, written by different people and dragged around by hand: linked in Slack, dropped into repositories, commented on, argued over in pull requests a human still has to read. The friction is real, because every role is in the air at once. Where does the designer sit now? The architect? The developer? This is the lived version of the question the first half of this book spent its time on. - **Level 3: The Backbone.** AI stops being an adjunct and becomes the centre of the process, and this is a deliberate act rather than a drift into one. The signs are specific. Code is no longer written by hand, only by agents. There is a decisive move away from markdown as the instrument of control, because a passive document an agent may or may not read is not control at all. The team’s attention turns to the machinery itself, the tools and plug-ins that govern how the coding system behaves. Specifications, standards and rules stop living in documents and move into a database wired straight into the tooling, so that an agent does not hope to comply, it cannot do otherwise. The purpose of all of it is to move the bottleneck left, all the way to the front of the work. When code is precise by construction, when the tests are written and run by agents, and when even the test frameworks are themselves tested, coding and QA stop being where the work piles up. The only constraint left is decisions: how many good ones the team can make and record, and how fast. This is the level where a team produces higher-quality work and produces it faster at the same time, the trade-off I was taught thirty-five years ago was simply a law of nature. Very few teams are here, and the ones that are tend to be the best in the world. If this book is pointing a professional team anywhere, it is here. - **Level 4: The Closed Loop.** Every stage of the lifecycle is automated and the loop closes on itself. The system specifies, builds, tests, deploys and improves. The loop closes because it watches the world, the metrics in production and the way real users behave, and feeds what it sees back into the work, correcting its own course under human supervision. The human contribution narrows to the two jobs a person should never hand over: the decisions, and the final judgement on whether the work is good enough to carry the team’s name. The system governs and corrects itself; the person governs the system. I am naming a horizon here, not a place I can point to, and I will say plainly that the line between a factory that improves itself and one that has quietly stopped making sense is thinner than its enthusiasts admit. But it is where this is heading, and a model that stopped short of naming it would be a comfortable lie. When almost everything a team does can be done by the machine, the last human job is judgement, and it is exercised over the machine itself. Five levels, and almost every team sits at Level 0 or Level 1 today, whatever the slide decks claim. Some teams are at level 2, and very few are at level 3. That is not a failure. It is a starting position, and knowing precisely where you actually stand, rather than where you have announced you stand, is worth more than any amount of enthusiasm about the destination. Naming the levels is the argument, not the answer. Whether there are five, whether the borders sit exactly where I have drawn them, and what genuinely carries a team from one to the next, is the work of the chapters ahead. What I am certain of is the frame. A team’s real level is not the one it has adopted. It is the one it holds on its worst week. You will not find out which level you are on during the demo preparation. You will find out when the demo breaks. Barrie --- ## Barrie Hadfield URL: https://www.memex.ai/writing/author/barrie-hadfield About Barrie Hadfield — founder and author at Memex. --- ## Privacy Policy URL: https://www.memex.ai/legal/privacy Privacy Policy for Memex. How we collect, use, and protect your personal data. --- ## Terms and Conditions URL: https://www.memex.ai/legal/terms Terms and Conditions for using Memex products and services. --- ## Download Memex for macOS and Windows URL: https://www.memex.ai/download Download the Memex desktop app. One-click MCP setup connects your coding agent to Memex. Available for macOS and Windows. --- ## Get started URL: https://www.memex.ai/get-started Two ways to get started with Memex early access: book a 30-minute onboarding call with the team, or continue straight to sign-up. --- ## Book a call URL: https://www.memex.ai/book-a-call Book a 30-minute onboarding call with the Memex team. --- ## Research URL: https://www.memex.ai/research Research from the Memex team on agentic software development. --- ## Decision Drift URL: https://www.memex.ai/research/decision-drift Decision drift: how AI coding agents lose the thread across sessions, and what it costs teams. --- ## Decision Drift — Full Report (May 2026) URL: https://www.memex.ai/research/decision-drift/full-report-2026-05 The full Decision Drift research report, May 2026. --- ## Memex for Coding Agents URL: https://www.memex.ai/coding-agents Keep your AI coding agents aligned across every session with Memex. --- ## Research URL: https://www.memex.ai/coding-agents/research Research on agentic software development. --- ## Decision Drift URL: https://www.memex.ai/coding-agents/research/decision-drift Decision drift in AI coding agents. --- ## Decision Drift — Full Report (May 2026) URL: https://www.memex.ai/coding-agents/research/decision-drift/full-report-2026-05 The full Decision Drift research report, May 2026. --- ## Writing URL: https://www.memex.ai/coding-agents/writing Essays on agentic software development. --- ## Brand Assets URL: https://www.memex.ai/branding Memex brand assets — logos and usage guidance.