The ADLC in five years, and what stays human
The generation of code is nearly solved. Taste, judgement about what is worth building, and the person who answers when an agent is wrong are not, and will not be.
A reviewer I know rejected a pull request last spring that had nothing wrong with it. Every test passed. The acceptance criteria were satisfied line by line. The implementation was cleaner than what the team would have written by hand, with better error handling and a migration that was genuinely thoughtful about backfill order. The agent had done excellent work.
She rejected it anyway, with a two-sentence comment: We should not build this. It makes the permissions model harder to explain, and we are about to rewrite the permissions model.
That comment could not have come from anywhere in the system. Not from the criteria, which were correct. Not from the tests, which were green. Not from the codebase, which contained no record of a rewrite that had not started. It came from a person who had been in a meeting, had a view about where the product should go, and was willing to spend social capital saying no to work that was already finished.
Five years from now, the code in that pull request will be produced faster and better than it was last spring. The comment will still have to come from a human being.
This is the last piece in this library, and it is about the division of labour that survives. Not a defence of human relevance, which is a genre that mostly consists of anxious people reassuring each other. Something more specific: which parts of building software are structurally resistant to delegation, why, and what the job looks like once the delegable parts are gone.
The boring version of five years out
Start with the unglamorous forecast, because the exciting versions are almost always wrong in the same direction.
In five years, most changes to most codebases will be drafted by agents. That is close to true already in the teams furthest along, and the Foundations piece on who actually writes your code now suggests the honest audit surprises people in both directions. Specification will be a written activity that occupies a large share of an engineer’s day. Verification will be sampled and statistical for routine work and deep for risky work, the split the review piece describes. The record of what is happening will be derived from the repository rather than maintained by hand, because maintaining it by hand will have become visibly absurd.
None of this is exotic. It is the current direction of travel with the friction removed.
Look at the shape of that. The two stages in the middle, turning a specification into working code and checking that the code does what it says, are exactly the stages where the work is bounded, the inputs are legible, and success is checkable. Those are the conditions under which delegation works. They compress.
The two stages on the outside have none of those properties. Deciding what is worth building has no bounded input set, because the relevant information includes things nobody has written down and some things nobody has said out loud. Answering for consequences is not a task at all, it is a relationship between a person and the people affected by their decision.
The interesting question is not whether the middle compresses. It is what happens to the outside when the middle gets very fast.
Taste, which is not a soft word
Taste has a bad reputation in engineering conversations because it sounds like a preference, and preferences are arbitrary, and arbitrary things do not belong in technical decisions. That reading is wrong, and it will get more wrong as generation gets cheaper.
Taste is compressed judgement about consequences you have seen play out. When an experienced engineer says an abstraction feels wrong, they are usually not expressing an aesthetic. They are pattern-matching against the six times they watched a similar abstraction calcify and become the thing nobody could change. The feeling arrives faster than the reasoning, which is why it reads as intuition, but there is a real model underneath it built from real outcomes.
Here is why that matters more, not less, in an agentic life cycle. When producing an option was expensive, you got three designs and picked one. When producing an option is nearly free, you can have thirty, and every one of them will compile, pass tests and look reasonable. The scarce resource is no longer the ability to produce a good option. It is the ability to look at thirty adequate options and know which one you will still be glad about in two years.
Gets cheaper and faster
- Producing an implementation
- Producing an alternative implementation
- Writing the tests for either
- Documenting what the code does
- Reconciling the record with reality
Stays exactly as expensive
- Knowing which option you will regret
- Deciding what should not be built
- Saying no to finished work
- Holding intent nobody wrote down
- Answering for a bad outcome
There is a second-order effect that worries us more than the first-order one. Taste is built from consequences, and consequences are learned by making mistakes at a scale small enough to survive and slow enough to notice. If juniors never write the abstraction that calcifies, they never learn the feeling that warns them about it. The apprenticeship model for engineering judgement ran on people doing work that machines can now do better, which means the training path for the skill we most need is the path being automated away.
We do not have a good answer to that. Nobody does yet. The best we have seen in practice is deliberate: teams that make juniors write and defend specifications rather than implementations, and make them sit in the review of what came back. That builds the judgement muscle directly rather than as a byproduct of typing. Whether it works as well as the old apprenticeship is genuinely unknown, and anyone telling you confidently that it does is guessing.
Judgement about what is worth building
The permissions-model rejection at the top of this piece is a small example of a large category: decisions where the correct answer depends on information that exists only in the intersection of several human heads.
Should we support this workflow, given that two customers asked and one of them is about to churn for unrelated reasons? Is this technical debt worth paying down now, given the reorganisation nobody has announced? Does this feature make the product harder to explain, and does that matter more than the revenue it unlocks? Is the right response to this bug a fix, or an admission that the model underneath is wrong?
These are not hard because they require reasoning that machines cannot do. Machines reason well. They are hard because the inputs are not available. The relevant facts are unrecorded, partially private, sometimes politically sensitive, and frequently not yet decided by the people who will decide them. The Open Knowledge series spends ten pieces on getting more of this written down, and that effort is worth making, but it has a floor. Some of what determines whether a thing is worth building has not happened yet.
This is where we should be careful about a comfortable story. The comfortable story says humans provide the strategy and machines provide the execution, everyone keeps their dignity, and the org chart barely changes. It is too neat. In reality the boundary is ragged, moves constantly, and a great deal of what currently feels like judgement is actually pattern-matching that will be absorbed. Estimating effort. Triaging bug severity. Deciding which of four similar refactors to do first. Those feel like judgement calls today, and a system with enough history to read will make most of them at least as well as a distracted human on a Thursday afternoon.
The residue that does not get absorbed is smaller than engineers would like to believe and much larger than zero. It is concentrated in exactly two places: decisions that depend on information nobody has recorded, and decisions where someone has to be willing to be blamed.
Someone has to be wrong on the record
An agent cannot be accountable. This is not a philosophical claim about consciousness or intent, it is a practical one about what accountability is for.
Accountability is a mechanism for making future decisions better. It works because a person who will have to explain a bad outcome makes different choices beforehand: they think harder about the edge case, they push back on the deadline, they insist on the extra check. The threat of having to answer is what produces the care. You can log everything an agent did, and you should, but you cannot make an agent care about explaining itself next quarter, because there is no next quarter for it to care about.
So the accountability has to attach to a person, and the interesting design question in the ADLC is which person, and for what.
The old answer was simple and is now broken. The author was accountable, because the author held the intent and did the work. When an agent writes the change, “author” splits into at least four roles, and if you do not assign them explicitly they resolve into the worst possible default, which is that everyone assumes someone else has it.
Notice that none of these can be discharged by pointing at the agent. “The model generated it” is not an answer to any of the four questions, in the same way that “the compiler emitted it” was never an answer. The tool changed. The chain of responsibility did not, and the organisations that get this right will be the ones that write the chain down before an incident forces them to.
There is a version of this that goes badly, and it is worth naming because it is the likely failure rather than the exotic one. Accountability without capability is just blame. If you make a reviewer accountable for merges while giving them four hundred changes a week and no way to tell which forty matter, you have not created responsibility, you have created a person who will be fired for something they could not have prevented. The Failure modes series is largely a catalogue of this pattern in different costumes. The obligation to answer has to come with the means to have done otherwise, or it corrodes rather than protects.
Neither the utopia nor the collapse
Two stories are told about this future, and both are wrong in ways that are easy to demonstrate.
The utopia says software gets so cheap to produce that everything worth building gets built, engineers become architects of intent, and the tedious parts vanish. It is wrong because it assumes the constraint on good software was ever the typing. It was not. The constraint was, and remains, knowing what to build and being able to tell whether you built it. Removing the typing exposes that constraint rather than relieving it, which is why so many teams have found that going faster made things worse before it made them better. The piece on speed without a definition of done is about precisely this disappointment.
The collapse says the craft is over, the profession hollows out, and what is left is supervising a machine that does the interesting part. It is wrong for a subtler reason. It assumes the interesting part was the implementation, which is a strange thing for anyone who has actually built systems to believe. The implementation was the part you did after the hard thinking. What is disappearing is the transcription, and the reason it feels like a loss is that transcription is pleasant, absorbing, and produces a satisfying sense of progress that specification work does not.
That last point is worth sitting with, because it is the honest source of the dread. The new job is harder than the old one in a specific way: it is thinking-dense and feedback-sparse. Writing a good specification is more cognitively demanding than writing the code it describes, and it feels like less. You spend a morning on four paragraphs and have nothing to run at the end of it. That is a real cost and a real adjustment, and dismissing it as resistance to change is both wrong and rude.
Where this breaks down
Several places, and some of them are load-bearing.
The clean split assumes the middle actually gets reliable. Everything above is premised on execution and verification becoming trustworthy enough to delegate. If they do not, if agent output stays good enough to be tempting and unreliable enough to require full human reading, then the job does not move to specification and judgement. It becomes proofreading, at volume, forever. That is a worse outcome than either story above, and it is not obviously off the table. The teams in that state today are miserable, and the thing that gets them out is not a better model, it is the criteria discipline the Definition of done series argues for.
Accountability may not survive contact with scale. We have written confidently that a person must answer for each of the four roles. In an organisation shipping thousands of agent-authored changes a week, that may simply not be tractable, and the honest resolution might be that accountability moves up a level: nobody answers for individual changes, some designated person answers for the failure rate of the system as a whole, the way a factory manager answers for defect rates rather than for individual defects. That is a coherent model and it is not the one we described. If it wins, the four-role split above becomes an artefact of an awkward transitional period rather than a durable structure.
We may be overrating taste because we have it. Everyone writing about this subject is an experienced practitioner, and experienced practitioners have a well-documented tendency to conclude that the thing they are good at is the thing that cannot be automated. We should apply the discount to ourselves. It is entirely possible that a large fraction of what we call taste is pattern-matching over outcomes, that outcomes are increasingly recorded, and that a system reading ten years of a codebase’s incident history develops something functionally indistinguishable from the feeling that an abstraction is wrong. We think the unrecorded residue matters. We would say that.
And the apprenticeship problem might be worse than a training gap. If the path to judgement runs through consequences, and juniors no longer experience the consequences of their own implementation choices, the pipeline of people capable of the surviving work may thin out over a decade in a way that is invisible year to year. That is a slow failure, the kind organisations are worst at detecting, and nothing in the current tooling conversation addresses it.
Closing the library
A hundred pieces is a strange thing to write, and it is worth saying plainly what the whole thing was for.
The argument was never that agents change software development. Everyone knows that. The argument was that they broke two specific assumptions the life cycle was quietly built on, that a human writes the change and a human maintains the plan, and that most of the disorientation teams feel is that break rather than any particular tool being bad. The Foundations series makes that case. SDLC versus ADLC works through what it does to each ceremony. Failure modes catalogues what goes wrong when you accelerate the first half of the loop and not the second. Definition of done and Open Knowledge are about the two things you have to write down for any of it to work. Metrics is about how you would know. The Transition playbook is about doing it on a Monday without breaking the team.
If you take one thing from all of it, take this. The response to work becoming machine-generated is not more ceremony and not blind automation. It is to make your definition of done checkable, to derive your record of reality from the repository rather than from someone’s memory, and to keep a named human at both ends of the pipe: one deciding what is worth building, one answering for what shipped.
That last part is not a consolation prize for humans in an automated world. It is the load-bearing element. Everything in between can be delegated, and probably will be. The decision about what deserves to exist, and the willingness to be wrong about it in public, cannot be, because there is nobody else to be wrong.
The reviewer who rejected a perfectly good pull request was doing the job. In five years, that will be most of the job. It is a smaller job in hours and a much larger one in weight, and the teams that understand the difference will be the ones still worth working for.
Everything between the intent and the consequence can be delegated. The intent and the consequence cannot, because delegation requires someone to delegate to, and at the ends of the chain there is only you.