The bottleneck moved

Coding 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?

There is an old joke about software being ninety percent done for ninety percent of the schedule, and it has arrived somewhere new. An agent will take you most of the way in an afternoon. What is left over is judgement, taste, and the scars of having shipped something like this before, and that remainder is now the entire job.

FIG. 1 The inversion this page is about. The work moved to the agents and the risk stayed with you, concentrated into a sliver that no longer looks like engineering hours at all. Those two questions are what the human contribution has narrowed to, and every tool being rebuilt right now is being rebuilt to serve them. The proportions are the familiar shape of a last mile and are not a measurement.

Five things get expensive instead

FIG. 2 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 coding 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. 3 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. 4 Guardrails as geometry. Each coloured band is something somebody already knew, written where the agent has to pass through it, and each one catches a different class of wrong answer. Nothing here asks the agent to be careful. By the time it writes a line, the wrong answers are out of reach.

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. 5 The AIDLC, and the colour key for these plates. Six steps around one shared record, coloured by who actually does them. Two steps are yours, one is the guardrails, one is the agents, and two are the graph. The dashed blue spokes are the argument in one image: 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
THE SCARCITY IS GONE
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 implement them	A queue of decisions waiting on a human, held 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
STILL REAL WORK
Deciding what matters	Every yes cost a month of someone's hands	Harder now, because you can build ten things a week
Telling the business	Engineering was opaque from the outside	Unchanged, and it was never about capacity anyway
Audit and compliance	Regulators need a record they can inspect	Unchanged, and indifferent to your view on ceremony
Awareness between people	Two developers could not see each other's work	Harder now, because each of them runs six agents

FIG. 6 The ledger. Each ritual was a good answer to a real constraint, and the middle column is that constraint. Where it has gone, the ceremony goes with it. The four in blue are the ones that survive, because they were about communication and judgment and never about rationing scarce implementation capacity.

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. Under the old assumption it waited on hands: more things to do than people to do them, so you needed somewhere to put what was not being done, with enough structure to find it later and enough ceremony that it did not get lost. Jira is a very good answer to that problem.

Implementation stopped being what holds the queue up. What holds it up now is a person. Every item in that list is waiting on someone to decide what it actually means, to settle which of two agents was right, or to look at a finished diff and accept it. The backlog quietly stopped measuring capacity and started measuring how much of your intent you have managed to state precisely, which is a different quantity with a different bottleneck sitting behind it.

Once the queue is a queue of human decisions, the thing worth optimising becomes obvious: how fast one person can state intent, settle a question and accept a result, across as many agents as they care to run at once. That is an orchestration problem, and a board was never built to be one.

The obvious objection is that an agent can read the board now. That is true. Jira ships an MCP server, so does Linear, so does Slack, and an agent pointed at any of them will read the ticket perfectly well.

Then look at what it read. A title written for a human, a status somebody last dragged on Tuesday, a comment thread that stopped being true the moment the real decision moved into a channel, and a description the code has since contradicted. Reading it was never the hard part. Trusting it is, and an agent with access to all three stores gets three answers and no way to tell which one is current.

So the state has to live somewhere with different properties: written to be read by the thing doing the work, updated by the work itself as it happens, and sitting next to the code in the same place the constraints live. What is genuinely left of a backlog once you do that 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, and the three things a board holds worst.

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 that disagree, and the reconciling gets done by whoever happens to remember. Your agents can now reach all three and are worse off for it, because three contradictory accounts of the same choice are harder to act on than one. One surface is the precondition for the work being legible to the things doing it.

FIG. 7 What one person can hold. Both panels run the same seven agents. On the left you are wired to each one separately, so the dashed agent costs you a seventh connection to maintain. On the right you state the intent once, every agent reads it on the way past, and the work comes back through a single review, so the dashed agent changes nothing on your side of the picture. The agents multiply and your job stays the same size, and the two connections it consists of are the two questions this page opened with.

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 flock, 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 flock for Mac. Free tier, no card.