Automate the known, invest people in the unknown
As principles go this one is hard to argue with. The routine and well-understood parts of building software get handed to agents. The people move onto the parts nobody has a procedure for.
In practice the known list is longer than most teams expect. Triage of incoming work. Bug autofix for the small, obvious, reproducible ones. Regression testing. Answering the product questions somebody asks every fortnight. Changelog and release notes. First-pass review for the mechanical things a linter nearly catches.
Linear have been unusually direct in public about where this goes. Their position is that issue tracking as practised is finished, that the product is really the shared context which humans and agents both coordinate around, and that when execution gets cheap the decision layer becomes the bottleneck. They report engineering agents installed on more than 75 per cent of their enterprise workspaces. Whatever you think of the framing, that is not a forecast, it is a deployment number.
So far this is the version everybody agrees with, and it is the version that fails.
Throughput and instability go up together
DORA has been measuring software delivery for over a decade and their recent work on AI is the least comfortable reading in the field.
Ninety per cent of technology professionals now use AI at work, and over 80 per cent believe it has made them more productive. Then the delivery metrics: higher AI adoption is associated with an increase in throughput and an increase in instability, at the same time. More code, moving faster, arriving at deployment pipelines and manual review gates that were sized for less code moving slower.
The mechanism DORA describe is the important part. AI reliably accelerates the start of a task and reduces the friction of beginning something. The time saved there is then substantially re-allocated to auditing and verification. It is not that the work disappears. It is that the work changes shape, and the new shape lands on a different person.
And that 80 per cent belief figure should be treated as sentiment rather than evidence. The one randomised controlled trial on this question, METR's, had experienced developers believing they were 20 per cent faster with AI while measuring 19 per cent slower. People are not good witnesses to their own throughput. Nobody is.
More code moving faster does not meet a pipeline built for less code moving slower.
You did not remove the work, you moved it
Automating the known does not delete effort. It relocates it, and it relocates it towards whichever human checkpoint is narrowest.
This is ordinary bottleneck behaviour and it is worth being blunt about, because it is the part that gets skipped in every enthusiastic write-up. Remove a constraint and you do not get a faster system. You get a different constraint, usually the next one along, and you find out where it is by watching queues form.
If authorship was your constraint, automating it helps enormously. If review was already your constraint, and in most teams of any size review was already your constraint, then automating authorship makes your actual problem worse. You have increased arrival rate at a queue that was already backed up, and you have done it while making each item in that queue slightly harder to check, because the reviewer no longer has the context that comes from having written the thing.
That is the whole of the DORA instability finding, expressed as a queue rather than a statistic.
What stays human is about consequence, not capability
Watch where teams actually draw the line and it is not where the marketing suggests. The steps that stay human are merge, production infrastructure, anything that moves money, and anything you cannot undo.
None of those are on the list because a person does them better. An agent can merge a branch perfectly well. They are on the list because the cost of getting them wrong is not proportional to the difficulty of getting them right.
That distinction matters because teams that draw the line by capability get it wrong in both directions at once. They keep people on work agents genuinely do well, like writing the fortieth regression test, and they hand over work where a quiet failure is unrecoverable, like a migration or a permissions change. Both feel reasonable in the moment. Only one of them shows up in the incident review.
The useful question is not "can an agent do this". It is "what does it cost me if this is wrong and nobody notices for a week". Sort your pipeline by that and the human checkpoints put themselves in sensible places.
The steps that stay human are not the hard parts. They are the expensive parts to get wrong.
Cheap verification, or the saving is imaginary
DORA's own prescription is unglamorous: automated testing, continuous integration, and working in small batches. I have never seen anyone get away with skipping it.
Read that in light of the mechanism above and it stops sounding like generic advice. If the time saved in creation gets re-spent on verification, then the price of verification determines whether you saved anything at all. Automating authorship on top of a slow, manual, high-ceremony review process does not give you a faster team. It gives you a more productive way to generate work in progress.
Small batches matter for the same reason and more than usual. A large agent-authored change is close to unreviewable: the reviewer did not write it, cannot hold it all, and will approve it on vibes after twenty minutes. Four small ones are four honest reviews. The batch size is doing the work that shared authorship context used to do.
Almost nobody does the second clause
Automate the known, invest people in the unknown. The first clause is a tooling project. It has a budget, an owner, a finish line and a demo. The second clause is a management problem with no natural end, no obvious artefact, and nothing to show at the end of the quarter.
So it does not happen. The routine work gets automated, the people who were doing it are moved onto the queue that the automation created, and the organisation books the efficiency. A year later everyone is busier, delivery is less stable, and nobody is working on anything nobody asked for.
There is a simple test for whether you implemented one clause or two. Take somebody whose routine work you automated six months ago, and ask what they spend the recovered time on. If the answer is reviewing, checking, verifying and unblocking, you automated the known and stopped. That is not a failure of the principle. It is the half of it that requires somebody to make a decision about headcount and then protect it.
Exploration does not survive as a residual. It survives when it is somebody's actual assignment, with time that other work is not permitted to eat.
Find the queue before you buy anything
Start by finding your real constraint, which is rarely the one you assume. Look for where work piles up and ages: pull requests open for days, a staging environment permanently occupied, one person whose approval everything waits on. Automating anything upstream of that constraint only makes the pile bigger.
Then price your verification. How long does it take, from a change being ready to a human being confident it is safe? If that number is large and manual, fix it before you increase the arrival rate. It is the highest-return item on this list and it is boring enough that it never gets prioritised.
Sort the rest of your pipeline by blast radius rather than by difficulty, and put the people where a silent failure is expensive instead of where the work is hard. Shrink your batches while you are at it, because an agent will happily hand you a thousand-line change and you should not accept it. The review is the product now.
Last, and this is the one that gets skipped: spend the saving deliberately. Name what the recovered time is for, and give it to somebody as an assignment rather than leaving it around as spare capacity. If you cannot say what that is, you have not finished the project. You have finished the easy part of it.
I spend more time on the second of those than on all the others put together. Most teams calling about agents do not have a tooling problem. They have a queue nobody has measured.