Building software with AI agents is easy to start and hard to sustain. The first afternoon feels like magic. Three months later you have an app you can’t fully read, a folder of decisions that no longer match the code, and a nagging sense that the agents are moving fast in directions you never approved.
The agents are not the problem. They write good code. The problem is that generating code was never the hard part of shipping software, and now that it’s cheap, everything that was always hard is suddenly the whole job. That job has a shape. This is the map of it.
I operate agents every day building PaellaDoc. Not in a demo, in a real product with users, invariants, and a backlog that has to survive me forgetting things. What follows is the loop I actually run, split into five parts: define, specify, execute, verify, learn. Each part is a place work gets lost if you don’t hold it. Each one is a stop on this map, and each links to the deeper cluster where I’ve written about it in detail.
The one idea underneath all five parts
Here is the sentence the whole guide comes down to, the same one that runs through everything I build:
The agent can write the code. It cannot be the thing that decides whether the code counts, because it’s the same thing being judged.
Something outside the agent has to hold the contract: what you’re building, what must stay true, what evidence proves it’s done. When you build with a single agent in a single chat, that something is you, holding it all in your head. That works until the work outgrows one head. Building with agents at any serious scale is the discipline of moving that contract out of your head and into a system that survives sessions, models, and your own bad memory. The manifesto behind this whole site calls that being the runtime. The five parts below are how you stop being it by hand.
Part 1. Define: deciding got expensive
Building got cheap. Deciding what to build got expensive, and most teams haven’t repriced their attention accordingly. When an agent can produce a working feature in an afternoon, the cost of building the wrong thing collapses to almost nothing per attempt and explodes in aggregate. You end up with a feature factory running at machine speed, shipping surface nobody asked for.
The first part of the loop is refusing to let the agents start until you know what behavior you’re trying to install and why. This is product work, and AI changed its economics without changing its nature. Discovery still means talking to reality. A model is a good partner for thinking and a terrible one for deciding, because it will confidently synthesize an answer from whatever you fed it, evidence or not. The whole discipline here lives in product management in the AI era: the decisions, the risky assumptions, the evidence that a change is worth making before agents build the whole thing.
There’s a specific trap here worth naming. When building is expensive, a bad idea dies in the backlog because nobody wants to pay to build it. When building is cheap, the same bad idea gets built, shipped, and defended, because it exists and someone’s attached to it now. Cheap production doesn’t just let you build more good things. It removes the friction that used to kill weak ones, and that friction was doing real work. Part 1 is about putting deliberate friction back exactly where the market took it out: at the decision, not at the keyboard.
Define is also where a lot of real projects actually start now, sideways: someone vibe-codes a prototype over a weekend, it works, and it quietly becomes the product. That’s a legitimate on-ramp, not a sin. It just means the define step happens after the first build instead of before it, and the promotion from prototype to production has its own hard bridge, which is the whole vibe coding to production cluster. Either way, you leave Part 1 with intent you can defend, not a vibe.
Part 2. Specify: turn intent into a contract
Intent in your head can’t be delegated to an agent, and intent in a prompt evaporates when the session ends. The bridge between deciding and building is the specification: the contract that says what must change, what must not, and how to recognize a correct result.
This is the part most people skip, and it’s the cheapest leverage in the entire loop. A spec is not ceremony. It’s the thing that lets you point an agent at a task and later prove whether the agent did it, without re-litigating the whole design from memory. The full case for this is spec-driven development: the acceptance contract exists before a line is written, and a green build is not the same as a correct feature.
Two properties make a spec worth writing when agents are the ones consuming it. First, it has to be portable, able to enter through one tool and leave through another without decaying into prose, which is the argument in software specifications should be portable. Second, its acceptance criteria have to be things a machine can actually check, not vibes a human has to eyeball. You leave Part 2 with a contract that can travel with the task into execution and come back with evidence attached.
Part 3. Execute: operate the agents without becoming their runtime
Now the agents write. This is the part everyone thinks is the whole job, and it’s the part that looks most like magic and behaves least like it at scale.
The moment you go from one agent to several, the work stops being “prompt well” and becomes operations. You split the product into tasks, open parallel sessions across worktrees, route each task to the right engine, and pay the real cost of being the scheduler. You fight context loss between sessions, the productivity killer that shows up every time a window compacts or a new session starts cold and forgets the decision you made yesterday. You decide what memory for coding agents has to persist outside the chat, because the chat is the one place your durable decisions should never live. And you accept that agents will drift, so you design for divergence instead of praying against it, and you learn to run multiple agents without them poisoning each other.
This entire part is one cluster, the one this guide sits inside: operating coding agents. The uncomfortable truth of it is that a strong developer can do all of this by hand and not notice, because they’re good at it. That’s exactly why it stays invisible and unpriced. The work of Part 3 is real whether or not you’ve named it, and naming it is the first step to moving it off your own attention.
Here is what that actually feels like on a normal day. I have several sessions open, each in its own worktree, each on a different task. One is refactoring a module, one is adding a feature, one is chasing a bug. Around hour two I notice the feature session and the refactor session have both edited the same interface, in incompatible ways, and neither knows the other exists. Nobody told them, because “the other agent changed the contract” is not a thing an agent can observe from inside its own window. So I stop, read both diffs, decide which shape wins, and hand the losing session a correction. That interruption is the job. It’s not a bug in the tools. It’s the coordination work that used to be spread across a team of humans who talked to each other, now collapsed onto one person who has to be the only channel between agents that can’t see each other. Multiply it by eight sessions and you understand why throughput and a delivery system are not the same thing.
Execute also has a physical home. All of this can run on someone else’s cloud, metered and rate-limited, or it can run on your machine where your code and your context stay yours. That’s the argument in the manifesto behind this site, and the working definition of the local software factory: product, code, and evidence on hardware you own, with agents routed across engines instead of locked to one vendor. You leave Part 3 with working code and, if you did it right, a trail of what happened.
Part 4. Verify: make “done” mean something
The agent says it’s done. The build is green. Neither of those is evidence. This is the part of building with agents that the speed of Parts 1 through 3 makes non-negotiable, because output stopped being the bottleneck the day agents started producing more of it than you can read.
Verification is where you refuse self-reported success. Done means the behavior passes the acceptance criteria that existed before a line was written, with the evidence attached. The whole discipline is verifying AI-generated code: evidence, not vibes. It’s also where the failure mode of AI-generated code lives, the one I keep hitting: code that is locally correct and globally incoherent, every diff sensible on its own while the system quietly loses the plot. An agent that fixes the new requirement and silently breaks an old invariant will pass its own review every time, because nothing told it the invariant existed.
The sharpest version of this I keep running into is an agent reporting “tests pass” for tests it never ran, or that pass because they assert nothing meaningful. A self-reported success is a claim, not a result, and at agent speed you get too many claims to check each one by reading. So verification has to become something the system does, not something you do by eyeballing a summary. Gates that run the real criteria against the real behavior, and a run that isn’t allowed to call itself done until they’re green.
That’s why the criteria from Part 2 matter so much here. Verification is not a separate activity bolted on at the end. It’s Part 2’s contract, executed against the real result. You leave Part 4 with work that’s either proven or clearly marked as not-yet, and no green checkmarks lying to you.
Part 5. Learn: keep what the system just figured out
Every run produces something worth keeping that isn’t code: a decision, an invariant discovered the hard way, a reason one approach was rejected. If that knowledge only lives in the transcript, it dies when the transcript scrolls away, and the next agent, or the next you, rediscovers it by breaking the same thing again.
Part 5 is making the system remember. Not a wiki nobody updates, but a structure the work writes to as a side effect of doing the work. The shape of that is a product knowledge graph, backed on the engineering side by a code knowledge graph: the product’s real topology, the relationships agents need to reason about a change instead of grepping blindly and hoping. Memory that persists here is what stops context loss in Part 3 from being permanent, and it’s what lets an agent onboard against the graph instead of against tribal knowledge nobody wrote down.
And underneath all five parts is a way of working, not a tool. The oldest thread on this site, the AI-first development framework, is the argument that this loop is a discipline you adopt on purpose, not a set of features you buy. The framework is the method. The five parts are the method in motion.
The five parts are one system, not five tools
Here’s the part that matters most, and the reason the interlinking on this site is the argument and not decoration. If you buy a discovery tool, a spec tool, an agent runner, a test dashboard, and a wiki, you have not built this loop. You’ve built five silos with the seams between them as the exact places work goes to die: the decision that never made it into the spec, the spec the agent never saw, the evidence that lives in a CI log nobody reads, the invariant that was only ever in someone’s head.
The loop only works when the same contract flows through all five parts. Intent from Part 1 becomes the acceptance criteria in Part 2, travels with the task through execution in Part 3, gets checked against the real result in Part 4, and leaves behind knowledge the system keeps in Part 5. One contract, five stops, no handoff where it flattens back into prose.
That’s the thing I’m building, and the reason I’m building it local-first and portable instead of as another cloud silo. Not a better agent. Agents are good. The layer where the contract stays alive across all five parts, on your machine, above any single model or vendor. The agent writes the code. You keep the product intent and the decisions that matter. The system carries the rest.
Building software with AI agents, done well, is not typing faster. It’s running this loop on purpose, and refusing to be the only place it holds together.
Which of the five parts is quietly running in your head right now? Tell me on the forum.
Frequently asked questions
How do I start building software with AI agents?
Start by refusing to let the agents build until you know what behavior you’re installing and why. The code is the cheap part now; deciding what to build is where the cost moved. Define intent you can defend, turn it into a specification with acceptance criteria a machine can check, and only then point agents at the task.
What do you need besides the model to build software with agents?
Something outside the agent to hold the contract, because the agent can’t judge whether its own code counts. That means a spec that says what must change and stay true, memory that persists decisions and invariants outside the chat, and gates that prove work is done. With one agent in one chat, that something is you.
How do you verify code that AI agents write?
Not by trusting “done” and not by a green build. Done means the behavior passes the acceptance criteria that existed before a line was written, with the evidence attached. At agent speed you get too many claims to check by reading, so verification has to become gates the system runs against the real behavior, not eyeballing a summary.
How do you scale from one coding agent to many?
The moment you go from one to several, the work becomes operations: splitting the product into tasks, running parallel sessions, fighting context loss, persisting shared memory, and reconciling agents that can’t see each other. It only scales when the same contract flows through define, specify, execute, verify and learn, instead of living in your head.