Make Every Engineer a Staff Engineer

Here is the good news, and it is bigger than the fear that keeps crowding it out: the machine is coming for the worst part of your job first.

Greg Isenberg and Simon Høiberg on X, on how fast the default way of shipping software is changing
Screenshot: Greg Isenberg and Simon Høiberg, on X.

Not the part you are proud of. The part you never admit to. The boilerplate. The glue code. The tenth CRUD endpoint that looks exactly like the previous nine. And the one nobody says out loud: the babysitting. "Fix this." "Continue." "Try again." "No, the other one." I have burned whole afternoons carrying water to an agent, nudging it through work I could describe but couldn't be bothered to type. That is not engineering. That is fetching and carrying for the tool that was supposed to fetch and carry for me.

That is what goes first. And losing it does not diminish you. It elevates you.

In the next six to twelve months, most engineers will be doing staff engineer work. Not because a title changed. Because once the babysitting is gone, the only work left with your name on it is the work that was the point all along.

Great engineering was never the typing

The fear story makes one quiet mistake: it treats the typing as the job. It never was.

Great engineering was never about output volume. A staff engineer is not a senior engineer who types faster. The thing that ever mattered was leverage per decision: the interface that stops three teams from colliding, the architecture choice that deletes a class of bugs before anyone writes them, the "we shouldn't build this at all" that saves a quarter. One call in the right place that changes what a whole team builds. That was always the work, and that was always where the great outcomes came from.

The rest, the volume, was overhead we mistook for the job because it filled the hours. The middle is high volume, low judgment. Staff work is low volume, high judgment. The machine is excellent at the first and useless at the second, which is exactly why the first is the part it takes.

You can already see the line, drawn in the rules people write for their own loops. The work they hand the machine is the checkable kind: dependency bumps, lint passes, triaging a failing test. The work they insist a human keep is architecture, auth, payments, and anything where "done" is a judgment call. Read that second list again. The work people guard most carefully is the exact definition of staff work, and it was always the work worth guarding.

There is more of it now, not less

The reflex is to assume that if the machine writes the code, we need fewer engineers. That gets the economics backwards.

In 1865 the economist William Stanley Jevons noticed that when better engines made coal cheaper to burn, England didn't burn less coal. It burned far more. Make a resource cheaper to use and you don't shrink the demand for it, you explode it. Code is now the coal. When shipping a feature costs a fraction of what it used to, we don't build the same amount of software with fewer people and send everyone home. We build far more of it. And every one of those features still needs someone to decide it was worth building, shape the problem before the machine can touch it, and judge whether the result is right. Cheap code doesn't kill the demand for judgment. It multiplies it.

This is already happening. Anthropic's own engineers now merge close to eight times as much code per day as they did in 2024, and Anthropic is honest enough to call the raw number almost certainly an overstatement of the real gain. The exact multiple doesn't matter. The direction does. More gets built, and every increment of it needs more of the judgment only you supply.

Let me show you one

Abstract claims are cheap. Here is one real run, and watch where the human actually shows up.

Not an engineer chatting with a tool to spit out a function. A factory: a standing system that takes a trigger and a unit of work and turns it into a finished, reviewed feature through a durable spec. The engineer doesn't type the feature. The engineer builds and tunes the loop, and the loop produces the feature.

We had one to build: a comments system inside an internal tool called Control Tower. The intake was a UI prototype sitting on a branch. Nothing more. It went through the factory. Product spec, then technical spec, then a build under test gates, then two tiers of review, then a merge. Multiple pull requests, all reviewed, all merged into one feature branch. A shipped, working feature.

Here is the only number that matters. What did the human actually do?

A handful of product-level steers. "No edit or delete on comments." "Roll it out without feature flags, it's internal only." "Remember this is Control Tower, it faces inward." Plus the architecture calls at one brainstorm gate, where the factory laid out a few approaches with trade-offs and a human picked. That was the entire human contribution. Not line-by-line repair. Not babysitting. A few sentences of product judgment and a few architecture decisions, made up front, where steering is cheap.

The product spec came out needing almost no correction. And because the big decisions were locked at the start, the technical spec and the code came out clean. The lesson is one line: the build is only as good as what's documented in the spec. Front-load the judgment, and everything downstream is production, which is the machine's job.

Read that back. The human's whole role was judgment at two gates, and the feature shipped. That is not a diminished engineer. That is an engineer finally spending the whole day on the part that needed a human.

What the days become

So what fills the hours once the typing is gone? The best work you were always too busy to get to.

Your output stops being the lines you wrote and becomes the units of work your loop produces without you. You build engines, not widgets, and you are measured by the outcomes the machine ships while you sleep, not by what you personally typed. You spend your hours where the loop cannot go yet: on the first ugly, ambiguous version of a problem nobody has framed, shaping it well enough that it becomes a loop, then walking to the next frontier. You write the specs that govern the factory and the gates where a human has to sign off, because the spec that constrains a factory is higher leverage than any single feature that factory will ever ship. And you develop taste, because when generating ten solutions is free, the whole game becomes knowing which of the ten is right and why. Generation is cheap. Judgment is not.

Underneath all of it is the quiet one, and it's the biggest. The expensive part of software was never the keystrokes. It was agreeing on what to build and why. The factory pushes that fight forward, into the spec, before any code exists, where changing your mind costs a sentence instead of a sprint. You spend your hours arguing about intent, about outcomes, in a document. That is the most senior thing an engineer can do, and now it is most of the job.

The one fear worth naming

None of this means there's nothing to lose, and there is one loss worth taking seriously.

Juniors used to earn their judgment by grinding through exactly the grunt work the loop now eats: the hundredth endpoint, the boring ticket, the glue nobody wanted. That grind was the classroom. If the machine takes the bottom rung, how does anyone climb?

The honest answer is that the ladder changes, it doesn't vanish. You used to learn by hand-writing your hundredth endpoint. Now you learn by building and debugging loops, by reading spec diffs, by reviewing what the loop produced and working out why the good output was good, by watching a correction get promoted up into the shared rails so a mistake made once becomes a rule every future loop starts with. That is a faster teacher than the tenth endpoint ever was. But it is a different classroom, and there is a trap inside it. Building the loop teaches you when you do it with judgment, and rots you when you do it to skip thinking. Same action, opposite result. The junior who reads every diff the loop ships climbs faster than they used to. The junior who rubber-stamps the output learns nothing. The new ladder is real. It only holds if you keep reading.

That is the fear, in full, and it deserves one honest paragraph. It does not deserve to be mistaken for the whole story.

Great engineering was always about outcomes

Notice what this actually is, underneath the noise.

For years, most of the job was never engineering at all. Intake parsing. Boilerplate. Ticket triage. Rote handoffs. Nudging the tool through work you had already thought through. The part that looked like engineering but was really administration, eating the judgment hours without ever asking for judgment. It filled most of the week, and almost none of it was the work.

Great engineering was never about any of that. It was never about the typing, or the volume, or how many hours you fed the machine. It was about outcomes: the right thing built, the wrong thing killed, the decision that made a whole team faster. The machine takes the babysitting and hands you back the outcomes.

That is not a smaller job. It is the job, finally undistracted. Every engineer a staff engineer. Not a title someone grants you. The elevation the machine forces, by taking everything that was never the work.