The staff engineer in an agent-heavy codebase
When generating code stops being the constraint, the highest-leverage engineer in the building stops being the one who writes the most of it. What replaces that is less glamorous and considerably more important.
There is a particular kind of engineer that most organisations have exactly two or three of. They have been in the codebase for years. They know why the payments module has that strange retry loop, and they know it because they were in the incident that caused it. When something breaks in a way nobody understands, someone eventually says their name in a channel, and forty minutes later there is an explanation.
That person’s leverage has historically come from a combination of two things: judgement about the system, and the ability to act on that judgement quickly by writing the code themselves. The second half of that combination is what changes.
I want to be precise about the claim, because there is a lazy version of it circulating. The lazy version says senior engineers become “architects” who stop writing code and start reviewing agent output. That is both wrong and a good description of how to destroy a staff engineer’s value in about six months. The real change is narrower and stranger: the scarce thing they produce shifts from implementation to constraint, and constraint is a much harder artefact to produce well.
The bottleneck moves, and it moves onto their desk
Start with the mechanical picture. In a team where agents write a meaningful share of changes, the rate at which candidate changes arrive goes up by a large multiple. The rate at which the organisation can absorb changes does not move at all on its own. Absorption is review capacity, environment capacity, deploy windows, and the willingness of whoever owns a risky subsystem to say yes.
The queue lands on the staff engineer. Predictably, because they are the person the organisation trusts to look at a change to the auth path and say whether it is sane. Ten times the changes means ten times the requests for that judgement, applied to a person whose capacity is fixed and who was already the constraint on three other things.
The naive response is to ask them to review faster. This fails in a specific and instructive way: review quality degrades non-linearly under volume. A person reviewing eight changes a day reads them. A person reviewing sixty skims for patterns they recognise, which means they catch the failure modes they have seen before and miss the ones they have not, which are exactly the failure modes an agent is most likely to produce.
So the useful question is not how to make this person review faster. It is how to make most changes not require them at all, while still not letting through the ones that should have.
From reviewing instances to encoding rules
The shift, stated plainly: a staff engineer’s job moves from judging particular changes to making their judgement executable.
Every time this person rejects a change, there is a rule in their head. Sometimes it is a rule they could state in a sentence. Sometimes it is a rule they have never articulated and could only recognise on sight. The work is to drag those rules out into a form that runs without them.
Some of that is old technology used with new seriousness. Types that make an invalid state unrepresentable are a staff engineer’s judgement compiled into the language. Lint rules and architecture tests are the same. A schema that rejects a malformed event at the boundary is one fewer thing anyone has to notice in review. None of that is new; what is new is the return on it. When a rule catches one bad change a month, encoding it is a hobby. When it catches thirty, encoding it is the highest-value thing in the sprint.
Some of it is genuinely new. Acceptance criteria that a machine can evaluate are, in effect, a per-ticket rule: this is what “done” means here, checked without me. The interesting design work is deciding which parts of correctness live in the type system, which in tests, which in criteria attached to the ticket, and which genuinely cannot be encoded and must stay with a human.
That last rung matters. The goal is not to encode everything, and a staff engineer who believes it is will spend a quarter building an unmaintainable rules engine. The goal is to be honest about which decisions are irreducibly human, keep those, and stop spending human attention on the rest.
The codebase became a prompt
Here is a consequence that surprised me, and that I now think is one of the more important second-order effects of the whole shift.
Agents imitate. Given a task in a codebase, they read the surrounding code and produce something shaped like it. This is usually described as a limitation. It is better understood as a control surface, and it is one that a staff engineer already knows how to operate.
If there are three ways to do database access in your repository and one of them is the good one, an agent will produce all three in roughly the proportion they appear. If you delete the two bad ones, output quality rises without a single instruction being written. The old argument for consistency was human cognitive load, which was real but always slightly abstract, and always lost to “we do not have time to refactor that.” The new argument is direct and measurable: inconsistency in the codebase becomes inconsistency in everything generated from it, at volume, forever.
This reframes a class of work that was historically hard to justify. Deleting the dead abstraction, collapsing the two competing HTTP clients, making the one canonical example of a well-built module actually canonical: this was tidying. It is now closer to configuration. Tell your finance-minded director that consolidating three patterns into one improves the quality of every future generated change and you have an argument you did not have two years ago.
What actually gets harder
I would distrust this essay if it only described a promotion. Three things get materially worse.
The volume of context they are asked to hold goes up. More changes land per week across more of the system. The staff engineer who used to have a reliable mental model of the codebase now has a model of a codebase that is being modified faster than they can read. Some of them cope by narrowing to a domain, which is sensible and also a real loss, because their value came partly from being one of the few people who could see across domains.
Debugging gets harder in a specific way. When you debug code a colleague wrote, you can reconstruct their intent, because humans make human mistakes: off-by-one, a misunderstood requirement, a copied block they forgot to edit. Generated code fails differently. It is frequently plausible, locally coherent, and wrong in a way that has no story behind it. The question “why would anyone write this” has no answer, and a lot of debugging skill is built on that question having an answer.
They become responsible for a system they did not build and cannot fully inspect. The pipeline that generates, checks and merges changes is now load-bearing infrastructure. When it produces something bad, the staff engineer is expected to explain it. Their ability to do so depends entirely on whether the system kept a record of what happened, which is a decision someone made months earlier, probably without consulting them.
Failure mode: the bottleneck who reviews faster
- Review load rises with generation volume
- Quality degrades quietly under skimming
- Encoded rules never get written, no time
- The person burns out and the org calls it capacity
Working mode: the bottleneck who removes themselves
- Every repeated rejection becomes a rule
- Review reserved for the genuinely novel
- Codebase consolidated because output imitates it
- Human judgement kept for what cannot be encoded
The thing nobody schedules
The conversion work above has an awkward property: it always loses to the queue. There is a review waiting right now, and encoding a rule pays off next quarter. Under any normal prioritisation the review wins, every day, until the person leaves.
The only fix I have seen work is structural rather than motivational. Someone senior has to protect a fraction of that person’s week for rule-writing, explicitly, and defend it when a deadline arrives. Not as a perk, and not as innovation time. As capacity planning, on the grounds that it is the only investment that changes the slope rather than the intercept.
The test of whether an organisation has understood any of this is simple. Ask what happens to a staff engineer’s week when generation volume doubles. If the answer is “they review more,” nothing has been understood.
Where this breaks down
Some judgement genuinely does not compress. “This is technically correct but it is going to make the next three features harder to build” is a real and valuable objection, it is frequently right, and I have never seen it encoded in anything. Organisations that push encoding too hard start treating unencodable objections as illegitimate, which is how you get a codebase that passes every check and is miserable to work in.
Rules rot, and rotten rules are worse than none. An encoded rule outlives the reasoning behind it. Two years on, a team is contorting changes to satisfy a constraint that was correct for an architecture that no longer exists. Anything encoded needs a recorded reason and a review date, and almost nobody does this.
Not every staff engineer wants this job. A significant number of people reached that level because they are exceptional at building things, and the role described here involves substantially less building. That is a legitimate preference and not a deficiency. Organisations that assume the transition is automatic will lose people who would have been happy in a different shape of senior role, and will lose them without ever understanding why.
The premise assumes the agents are good enough. Everything here follows from generation being cheap and roughly competent. In a domain where output needs heavy rewriting, the staff engineer is not a constraint designer, they are a rewriter, and the correct move is to use agents less rather than to restructure the role around them.
The takeaway
The staff engineer’s value never came from typing. It came from knowing which changes were safe and which were not, and that has not changed at all. What changed is that the volume of changes now exceeds any single person’s ability to look at them, which means the judgement has to leave their head and go somewhere it can run without them.
Types, tests, architecture rules, machine-checkable criteria, and a codebase clean enough to be worth imitating: these are not tidiness. They are how one person’s judgement gets applied ten thousand times a week instead of forty.
If you take one thing into next week, take this question: what did you reject this month, and why is that rejection still living only in your head?
The next piece stays on the same fault line and looks at review itself, which is the ritual most obviously broken by volume and the one most organisations have not yet admitted is broken.