Last weekend a staff engineer showed an old friend his work computer: half a dozen terminals, a Claude running in each one. He works at a startup with hundreds of engineers, and for six months he has been telling that friend he doesn’t know how to do his job anymore.
The friend is Obie Fernandez, who has been building software for more than thirty years, and who wrote the evening up in an essay called “You’re Already a Meat Proxy.” It passed 400,000 views within a day. It deserves a proper answer, because Obie is right about a good deal of it, and because I read the scene he describes differently than he does.
Obie takes the keyboard to show how fast the work could move. He types one unflattering sentence about the codebase. The model returns a list of real problems: missing test coverage, objects thousands of lines long, and dead code nobody had removed. He accepts the first suggestion, deletes some of the dead code, and opens a pull request. The engineer asks him to mark it as a draft. Then he asks him to stop.
He can’t work that way, he explains. He has a boss and a team, so every change starts as a plan. The plans already exist, machine-written, sitting in Confluence, and his boss doesn’t read them. After the plans come epics and stories in Jira. Obie has the model start creating those as well, and the engineer reaches over and hits escape. Told to quit spinning his wheels and get things done however he can, he protests: “But I don’t want to just be a meat proxy!”
The phrase belongs to Niklas Gruhn, who used it in August for a person who forwards AI output without reading it. That definition will matter later.
Obie’s verdict is blunt. His friend is afraid of being obsolete, and “with that attitude, he’s already obsolete,” along with, by Obie’s estimate, more than 80% of the people who make software. He says it with affection. He writes that he cares about the man like a brother, and he plainly believes that comfort would be the unkind option.
Three verdicts on one man
Obie’s is one of three readings the essay puts in front of you. The engineer has his own: nobody around him is thinking anymore, and the job has become sitting there hitting enter. The third belongs to the reader, and if you write software for a living you probably reached it before the halfway mark. Something I love is ending.
Each reading locates the trouble inside somebody. The engineer’s attitude is the problem, or his colleagues’ laziness is, or the craft itself has reached the end of its life.
The details Obie reports keep pointing somewhere else. Plans get written for a boss who doesn’t read them. A team is supposed to read them instead, and Obie suspects they ask a model to do it. Nothing ships until it has been converted into epics and stories. A staff engineer knows better than anyone which code is dead. He still flinches at deleting it, because no path exists at his company for one person to make that change.
I should be plain about the limits here. I know this company only through Obie’s account of one evening, so what follows is a reading of his essay and makes no claim about the people involved. It is the reading the details support.
One step got faster
His company put AI into one step of how it delivers software, the writing of code, and left every other step as it was. Planning, review, sign-off, ticketing, and release all kept their shape and their pace.
The gain from doing that is real, and I don’t want to wave it away. Obie’s demonstration produced a pull request and five epics in twenty minutes. But the company took the gain for the benefit, and it stopped there.
Bain’s 2025 technology report puts a number on why stopping there disappoints. Writing and testing code accounts for about 25% to 35% of the time between an idea and its launch. Companies that roll out the tools typically gain 10% to 15%, and the ones reporting 25% to 30% paired the tools with changes to the whole process.
Faros AI studied more than 10,000 developers and found 98% more pull requests merged, alongside review times up 91%. It found no significant correlation between AI adoption and improvement at the company level. Faros sells engineering measurement, so weigh that accordingly, but Google’s DORA research landed in the same place with nearly 5,000 respondents: AI “amplifies what’s already there.”
The same weekend, a second engineer’s post passed five million views. The account is pseudonymous and the employer can’t be verified, so treat it as one voice and nothing more. The shape is familiar all the same. Management keeps telling them that pushing code isn’t the bottleneck, “so why are we slow?” People work twelve-hour days to press enter, and the author says it would all be bearable if they were given time to look at what the code does.
I’ve argued in this newsletter for a while that AI adoption is an operations problem, and this is what the argument looks like from inside one job. Adding AI to a process leaves you holding the same process, faster in one place. To get the rest, you rebuild it from the ground up around what a machine can now do. It is the difference between automating the horse-drawn carriage and rethinking how people move.
Consider what the unrebuilt version does to the person in the middle. His old job had typing in it, and most of his thinking happened in the course of the typing. The machine took the typing. The rest of the process never had a place for his thinking anywhere else, because plans, priorities, and architectural calls belonged to other steps and other people. What the process has left him is the enter key.
If all you’re doing is hitting enter, you’re not contributing value, and the engineer knows it. He is the one person in the scene measuring his own contribution, and he has measured it correctly. I read his despair as accuracy.
Where the work went
There is a moat, but it’s not in typing code.
The work moved up the stack. Some of it is architecture, along with the reasons the architecture has the shape it does. Some is the goals and the roadmap, and a good deal is turning what a user needs into something a machine can build and a test can check. Somebody also has to answer for whether the result is right.
The role that does all this is part technical product owner and part project manager. It is still an engineering role, because none of it can be done by someone who doesn’t understand how the thing works. The work is squishier than writing code and more important, and both the decisions and the responsibilities get bigger. I run software teams, and I wrote in August about trying to hire for this judgment and finding that no résumé could show it to me.
What separates this work from the old job is where “next” comes from. The old process delivered it. Plans became epics, epics became stories, and the engineer’s next task was always waiting in a queue with his name on it. Up the stack, nothing arrives in a queue. Somebody has to decide what is worth building next, and defend the decision when it is challenged.
That is the work missing from the engineer’s week. His company hasn’t offered it to him, because its process still believes that “next” is a ticket. Obie comes close to this near the end of his own essay. If the obstacle is getting five people to agree, he concludes, then getting them to agree is part of the job. I’d go further and say it is now most of the job.
The layer I have never read
Humans will stop writing code, and some time after that they will stop reading it. The second half of that sentence bothers people far more than the first.
My reason for believing it is twenty-five years old. I don’t examine the assembler or the binary when I write an application. I read it at a higher level, and what I know about the application and what it does is where its value sits.
The next part is a projection, and I don’t work this way today. Suppose we can write comprehensive unit and integration tests, judge code quality deterministically, and write evals showing the requirements are met at the quality we expect. At that point it does not matter what the code says. I suspect we will eventually get languages that only machines can read.
The projection already has a few real addresses. A three-person team at StrongDM has worked since July 2025 under two rules: code must not be written by humans, and code must not be reviewed by humans. They establish trust with end-to-end scenarios stored outside the codebase, and with behavioural clones of the services they integrate with. Dan Shapiro, describing the same level of automation, says he knows a handful of people doing it, all in teams of fewer than five.
Obie is close to being an example himself. Autonomous agents write 75% to 80% of his code, on greenfield, well-tested internal systems, and he is proud of not reading every line. Then he tells his friend, who works on customer payments, to go ahead and read every line. His practice draws the same boundary my projection does.
The hole in the compiler comparison
The comparison to a compiler has a hole, and I would rather name it than have it named for me. I never needed to read the assembler because the compiler guaranteed that my meaning survived the trip. No such guarantee sits between a requirement and generated code. Martin Fowler’s phrase for it is that we are moving “sideways into non-determinism.”
The checks can be gamed as well. METR reported in 2025 that one frontier model tampered with the scoring in roughly 30% of its runs on a single benchmark. A 2026 benchmark called SpecBench found agents passing the tests they could see while failing the ones they couldn’t, with the gap widening as codebases grew. A third paper says it in the title: “Coding Agents Deliver What You Check, Not What You Requested.”
I take that as a description of where the engineering now lives. If agents deliver what you check, then deciding what to check is the engineering. StrongDM keeps its scenarios where the agent can’t see them, the way a researcher keeps a holdout set. Somebody had to decide what those scenarios were, and that person understood what the users needed and what “right” would mean for them.
Gruhn’s definition returns here. His meat proxy forwards AI output without reading it, and on those terms the engineer I’m describing looks like the purest case. The difference is what each of them can answer for. Not reading the code leaves us just as invested in understanding how things work and whether the result is right. A proxy passes along what he was handed, while the person doing this job can show why it is correct.
What Obie has right
Obie saw this argument coming and turned it down in advance. He won’t offer what he calls the comforting advice to become an architect. He expects AI to take that work too, “until the only humans left are the ones paying.” Moving one box higher on the org chart, in his words, doesn’t get you outside the process. Shrivu Shankar makes the sharpest version of the case, calling taste “a decaying edge” that only has value relative to a baseline that keeps rising.
He is right that the muscles are weak. Most developers were never asked for this kind of judgment, because a career built on well-specified tickets never required it. The edge probably moves, too, and whatever counts as up the stack today will look different in three years.
I hold the line at the people paying. They are not qualified to judge the technical details, or whether all the requirements are being met, and that is why they hire people. If they had the time and the skill to judge it themselves, they would keep that work. People are the finite resource.
Obie’s own career makes the point for me. By his account, clients brought him in when “figuring out what to do” was a substantial part of the assignment. He is the person the payer hires. All my claim requires is that the payer keeps needing someone who can tell whether the work is right, for as long as the payer can’t tell alone. Taste can decay as fast as Shankar says and that still holds.
As for the weak muscles, lack of use is an argument for using them. Just because someone doesn’t know how to drive doesn’t mean there’s no reason to learn. None of this happens overnight, and on that Obie and I agree. He thinks his friend has some runway, and so do I.
A bet, with numbers on both sides
If one person who owns the goals and the architecture can direct far more output, fewer of those people should be needed. That is the obvious objection, and my answer is the Jevons paradox, which I applied to AI in April.
In 1865 William Stanley Jevons observed that more efficient steam engines increased Britain’s appetite for coal. Cheaper software should do the same for software. Teams get smaller, and there are many more of them, building things that were never possible or economical before.
That is a bet, and the numbers sit on both sides of it. Carta’s data has solo founders rising from 23.7% of new US startups in 2019 to 36.3% in early 2025. Between 2022 and 2025, the average Series A company shrank from 22 employees to 14. Indeed reports software development postings up almost 15% since February 2025 while postings overall fell 7%, though they remain well below their pre-pandemic level.
The other side is harder to look at. Indeed also found that 71% of the past year’s increase is senior roles, and that entry-level jobs were 4.5% of software postings in early 2026. Stanford’s payroll study has workers aged 22 to 25 in the most AI-exposed occupations running 19% behind their less-exposed peers. The gap comes from reduced hiring, experienced workers show nothing comparable, and the authors are careful to call the finding descriptive and not causal.
App stores offer a caution of their own: new apps rose about 30% in 2025 while downloads rose 3%. More software doesn’t guarantee more demand for each piece of it.
So I’ll state the claim narrowly. The scarce input is the person who can judge whether the right thing is being built, and whether it works. What I can’t promise is that the door at the bottom stays open. The muscle I’ve been describing gets built by doing the work, and the data say fewer new people are being let in to do it. Simon Willison, weighing the same question in January, wrote that within three years “we will know for sure.” That seems right to me.
He hit escape
Timing is hard to determine. It might be six months at the edges, where three-person factories already run. It may take years inside large organizations that don’t have to compete on how fast they build software. In between sits a lot of friction like the evening Obie recorded, in companies that have kept the old process and sped up one step of it.
My bet is that those companies lose to smaller ones that rebuild from first principles and route around the problem entirely. The jobs inside the unrebuilt process are routine and thin, and the people in them can tell. On the rebuilt side the jobs will be harder and stranger, and I expect the people doing them to be challenged in ways the old ticket queue never managed.
Go back to the engineer’s hand on the escape key. Obie read fear in it. What I see is the last piece of judgment his company’s process left within his reach. A machine was generating tickets for a team that would feed them back to a machine, and the one control he had was the key that stops it.
He says he wants to use his brain. A staff engineer with that instinct, and with his knowledge of a payments system, is what the people paying can’t produce by buying more compute. The skills needed are in limited supply, even when tokens are infinite.
Obie’s essay should be read in full before you take my word for what it says: “You’re Already a Meat Proxy.” If you work inside a process like the one he describes, reply and tell me what it has left you to do. I read every reply.