The bottleneck moved

Typing stopped being the expensive part of building software. This is the lifecycle that replaces the one built around it, and what it costs you to run.

Every version of the SDLC, from waterfall through agile through whatever your company calls its process now, is built on one load-bearing assumption: that turning a decision into working code is slow and expensive. Estimation exists because implementation is costly. Sprints exist because you can only fit so much implementation into two weeks. Prioritisation is brutal because every yes is a month of someone's hands.

That assumption broke quietly, and most process did not notice.

When an agent can take a well-specified change and produce a working, tested diff in twenty minutes, the cost of implementation stops being the thing you plan around. It does not go to zero. It goes somewhere else. The useful question is not whether AI writes code well enough. It is: once implementation is cheap, what becomes expensive?

Five things get expensive instead

FIG. 1 Where the effort sits, and which way it travelled. Hollow markers are the old lifecycle, filled markers the new one. Producing the diff is the only line running the other way, and everything the rest of this page argues follows from that one reversal. The positions are a shape drawn from the argument, illustrative, and no measurement is claimed.

Direction

An agent will build precisely what you asked for, including the parts you did not mean. The skill that used to be split between deciding and typing is now entirely deciding. A vague ticket used to cost you a conversation. Now it costs you a merged pull request that solves the wrong problem convincingly.

Specification stops being paperwork you write for someone else and becomes the actual work.

Context

This is the one nobody planned for. Every agent starts from nothing. It reads the code, infers intent from what it can see, and gets to work. It does not know that you tried the obvious approach in March and it deadlocked. It does not know that the weird indirection in the auth layer exists because of a compliance requirement. It does not know that another agent, running right now in the next pane, has already decided how this is going to work.

So it rediscovers. Every time. And you pay for the rediscovery in tokens, in wall-clock time, and worst of all in decisions quietly relitigated by something that was not in the room the first time.

With one agent this is an annoyance. With six it is the dominant cost. Scaling agents without scaling shared context does not multiply your output; it multiplies your contradictions.

FIG. 2 The rediscovery tax. Four agents inferring intent from the same code arrive at four readings of it and quietly relitigate each other. The dashed line on the right is the step no SDLC has: the agent writes back what it learned, so the fifth agent starts where the fourth finished.

Review

If implementation is twenty minutes and review is two hours, review is the process. Everything upstream of it is now fast enough to be irrelevant to your throughput, and everything downstream waits on it.

This is genuinely uncomfortable, because review is the part of the job that scales worst with people and worst with attention. Reading a diff you did not write, deciding whether it is right, and being accountable for that judgment is slow by nature and does not get faster because the diff arrived sooner.

Guardrails

Which is why the way out of the review bottleneck is not reviewing faster. It is making most of what you would have caught in review impossible to produce in the first place.

That means taking your standards out of your head, and out of the review comment where they currently live, and putting them somewhere the agent reads before it writes anything, and not in a style guide nobody opens. Constraints with teeth: this is how errors are handled here, this module is owned and you do not restructure it, this approach was tried in March and it deadlocked, every query goes through the repository layer, nothing talks to the payment provider directly.

Written in a document, those are suggestions. Written into a graph the agent must read, they are a funnel. Every agent, before it does anything, is walked through the accumulated intent of everyone who worked on this codebase before it, and comes out the other end shaped by it. You are not asking it to be careful. You are narrowing the space of things it can plausibly build until the wrong answer is not reachable from where it starts.

FIG. 3 Guardrails as geometry. Every band is something somebody already knew, written where the agent has to pass through it. Nothing here asks the agent to be careful. The wrong answers are simply out of reach by the time it starts typing.

Authoring that funnel is real work, and it is the expensive part. It is also the most valuable afternoon a senior engineer can spend right now, because a constraint you write once is applied by every agent, on every task, indefinitely, without you in the room. A review comment is applied once, to one diff, by one person who has to be awake.

Follow that far enough and you arrive somewhere most people will not say out loud: when the funnel is good enough, you stop reading the code.

You keep caring about it. What stops is reading it line by line as the primary way you convince yourself the work is correct. You get that conviction instead from the constraints you wrote, the decisions on the record, the tests that ran, and the behaviour of the thing in front of you. Reading every diff is how you check work when you do not trust the process that produced it. The whole direction of travel is toward trusting the process instead, and the graph is where that process has to live, because it is the only part of the system that both persists and gets read by every agent before it acts.

That is the change happening right now, and it is bigger than any of the others on this list. Everything else here makes agents more useful. This one changes what your job is.

Trust

Every agent you run at full permissions is a process with your credentials, your SSH keys, and your whole disk. Most people solve this by approving each action, which destroys the speed that made agents worth using. The alternative is to make the blast radius small enough that full permissions stop being frightening. That is an infrastructure problem, and it is now part of the development lifecycle whether or not your process has a box for it.

What the lifecycle looks like instead

Take those five together and the loop reshapes itself. Call it the AIDLC if it needs a name, the AI development lifecycle, the thing that stands where the SDLC used to:

Direct. State intent precisely enough that an agent cannot satisfy it the wrong way. This is where your judgment goes now.
Constrain. Encode the principles and the ways of working an agent has to abide by, so the wrong answer is already out of reach when the agent starts.
Ground. Give the agent what has already been decided, what was already tried and failed, and who owns which file. The actual accumulated state of the project's thinking.
Fan out. Run the work in parallel, isolated, with each agent on its own branch, because the cost of an extra agent is now roughly the cost of an extra terminal.
Converge. Review, judge, and land. This is your bottleneck, so it is the part worth investing in.
Record. Write back what was learned, so the next agent and the next person do not pay for it again.

FIG. 4 The AIDLC. Six steps around one shared record. The dashed spokes are the whole argument: every step reads the graph before it acts and leaves something in it afterwards, which is what closes step six back onto step one.

The record step is the one that does not exist in any SDLC, because in the old lifecycle the record lived in the heads of the people who did the work, and those people came back tomorrow. Agents do not come back tomorrow. Every session is a new employee with no memory of the last one. If the lessons do not live outside the agent, they do not live.

The ceremony is dead

Every ritual in the modern process exists to solve a scarcity. Take the scarcity away and the ritual does not become lighter or more agile. It becomes theatre performed by people who have forgotten what it was for.

RITUAL	THE SCARCITY IT ANSWERED	WHAT STANDS THERE NOW
Estimation	Human hours were the unit of everything	How precisely the work was specified
Sprint planning	A fixed number of engineer-weeks to allocate	Continuous steering, closer to flying than to budgeting
The standup	People could not see each other's work	A pane per agent that says what it is doing
The ticket queue	More things to do than hands to do them	Intent, constraints and decisions, in the graph
Line-by-line review	The only way to check work you did not trust	Guardrails the agent passes through before it writes

FIG. 5 The ledger. Each ritual was a good answer to a real constraint, and each constraint has moved. The middle column is why these were worth doing. The right column is where the work went.

Estimation

Pointing a ticket is a prediction about human hours. That is the entire content of the exercise. When the work is done by a process that starts in seconds and finishes in twenty minutes, and the actual variance lives in how precisely you specified it, the number you argued about for eleven minutes on Tuesday is measuring something that no longer exists.

Sprint planning

A sprint is a capacity allocation. You have so many engineer-weeks, here is how we spend them, see you in a fortnight. It is a good answer to a genuine constraint, and the constraint is gone. Capacity is not what limits you now. Your ability to say precisely what you want is what limits you, and that does not batch into two-week increments. It is a continuous activity, more like steering than like budgeting.

The standup

The daily standup exists because people cannot see each other's work. You gather, you each say what you did, and the point of the ritual is shared awareness bought with fifteen minutes of everyone's morning.

When your colleagues are agents, awareness is not bought with a meeting. It is a property of the interface. You can see what every agent is doing because every agent is a pane and every pane says what it is working on. The standup becomes you, coffee in hand, walking the rows.

The ticket system

This is the one people will defend hardest, so it deserves the real argument.

A durable queue of work items exists because work waits. It waits because there are more things to do than hands to do them, so you need somewhere to put the things that are not being done, with enough structure that you can find them later and enough ceremony that they do not get lost. Jira is a very good answer to that problem.

When the queue drains as fast as you can specify it, most of that structure is overhead on work that no longer sits still. What is genuinely left is not a backlog. It is intent, constraints, and decisions: what we are trying to do, how work is done here, what we already tried. Those are the three things your agents need most.

The decisive problem is simpler than any of that. Your agents cannot read Jira.

They cannot read Linear either. They cannot read the Slack thread where the decision was actually made while the ticket still said In Progress. Every hour you spend grooming a backlog, dragging a card, or writing an update in a channel is an hour spent producing a record for the humans while the things doing the work stay ignorant of all of it.

Jira, Linear and Slack are not neutral bystanders here. They are three separate stores of intent, none of them legible to your agents, all of them disagreeing with each other by Thursday. A ticket says one thing, the thread says another, the code says a third, and the agent, which can only see the code, confidently builds the wrong thing and is not at fault. The state has to live where the agents pass through it: next to the code, in the graph, in the same place the constraints live.

What actually survives

Not everything here is theatre, and pretending otherwise would be the same overclaim in the other direction. Deciding what matters most gets harder when you can build ten things a week. Telling people outside engineering what is happening is real. Regulated industries have audit requirements that do not care about your opinion on ceremony.

But notice that all three of those are about communication and judgment. None of them are about coordinating scarce implementation capacity, which is what the machinery was actually built for, and which is the part that died.

The problem that does not solve itself

Awareness between people. Two developers each running six agents against the same codebase is a coordination problem that neither the old standup nor any single-player agent tool addresses. You do not need to hear what your colleague did yesterday. You need to see what their agent is doing right now, and you need both your formations reading the same decisions and bound by the same constraints.

What this asks of tools

Very little of the current tooling is built for this, because most of it was built for the previous assumption: one developer, one agent, one conversation, forgotten at the end.

An honest list of what the AIDLC actually needs:

Many agents visible at once, with a live answer to "what is each one doing", not a wall of identical tabs.
Isolation per agent, so parallel work on one repo does not become a merge disaster.
A shared, persistent record of decisions and dead ends that agents read before they write and update when they finish.
Constraints with teeth. A place to write down how work is done here that an agent has to pass through on its way to the work.
A sandbox tight enough that running at full permissions is a reasonable default.
Review treated as the main event, with an interface built for it.
More than one human in the room.
All of it on one surface.

That last one sounds like a preference and is not. If the work is visible in one place, the ticket queue and the status meeting were solving a problem you no longer have. If it is scattered across six terminal windows, a GitHub tab for pull requests, a Linear board somebody updates by hand, and the Slack channel where the decisions actually get made, then you have not removed the coordination overhead. You have hidden it, and you will pay it back in a meeting.

Fragmentation is also what kills the graph. A decision made in a pull request comment, a Slack thread and a Linear description is three decisions, none of which your agents can read, and the reconciling gets done by whoever happens to remember. One surface is the precondition for the work being legible to the things doing it.

FIG. 6 Why one surface is a requirement here. Scatter the intent across a board, a thread and the repository and two thirds of it sits on the far side of a wall your agents cannot climb. They build from the only store they can read, and they are not at fault.

What we are not sure about

Three things, honestly.

The first is how much of the direction work stays human. Right now, precisely specifying intent is the irreducible part. It is not obvious that it stays that way, and anyone telling you confidently either direction is guessing.

The second is whether shared memory between agents scales the way we think it does. It works well for decisions, dead ends, and ownership, which are small, high-value, and slow-changing. Whether it holds up when a graph has ten thousand nodes and four teams writing to it is a real open question and we will find out in public.

The third is when you stop reading the code, and for which code. We think the direction is settled. The pace is not. Nobody stops reading the payment path on a Tuesday afternoon because their constraints file got good, and the honest version of this argument admits there is a floor somewhere. What we do not accept is that the floor is where it is today, which is every line of every diff, read by a tired person, as the only thing standing between a codebase and the agents working on it.

Why we care

We build Clarence, a Mac cockpit for running coding agents in formation, so the argument above is not disinterested. It is the argument the product is built on: agents in parallel, a shared knowledge graph they read before they write, constraints the agents pass through before they act, a Docker cage so full permissions are safe, pull requests from opened to merged without leaving the window, and a second chair for the person you work with.

All of it on one surface, which is the part we are most stubborn about. Not because a single app is tidier, but because the moment the work is split across a terminal, a browser, a board, and a chat channel, you have rebuilt the coordination problem the ceremony existed to solve, and you will end up holding a standup about it.

You do not need our tool to take the argument seriously. But if you have felt the rediscovery tax, or watched two agents undo each other, or realised that your review queue is now the whole process, that is the AIDLC arriving whether or not anyone named it.

Download Clarence for Mac. Free tier, no card.