Let me be honest: this week I read a post that will not let me go. A developer describes his new job. There the AI produces everything: requirements, tickets, tests, code, documentation, reports. The people sit in front of it twelve, thirteen hours a day and confirm what comes out. Nobody knows what happens in the system anymore. Nobody thinks anymore. His sentence for it: people only press Enter. Almost five million have read that, and I think he is right. Just not with the conclusion many draw from it.
The post
The man is anonymous, out of fear of his employer, and that already says something. What he describes is not an isolated case, I have heard it for a year in every second conversation with developers: management measures sprints, pull requests, shipped features. So everything that makes features faster is handed to the AI, from the requirement to the backend. And the human becomes what he later called a "meat proxy" in an interview: someone who passes on outputs without reading them.
One sentence from the post is the most important, and it is not the loud one: writing code was never the bottleneck. The bottleneck was the systems around it.
Typing was never the problem
I have been building software for over twenty years, and I cannot remember a project that failed at typing. The projects failed on other questions. What are we actually building, and why. What does the architecture look like. What data do we have, and how good is it. What dependencies arise, and who still knows them in two years. What happens when twenty developers change things at the same time. And today: what happens when fifty agents change things at the same time.
None of these questions disappears because a model writes two thousand lines in thirty seconds. They become more important. I described that in "Code is getting cheap. Knowledge is not.", and this post is the evidence from practice: when code costs nothing, everything else is what counts. And everything else is being automated away right now, because it is not on any dashboard.
Producing faster than anyone can understand
Development used to be expensive. A feature had to be planned, built, tested, reviewed, and each of these stages was a brake. Annoying, but a brake has a use: it forces you to stop. Today an agent does in minutes what a team needed a week for. That is good, I work that way every day. But it has a side effect nobody sees on the dashboard.
Understanding means, quite plainly: someone knows which dependencies exist. Why an architecture decision went the way it did. Why data is stored this way and not otherwise. Which component is critical, and what happens if you touch it. When nobody knows that anymore, you do not have ten times more output. You have ten times more complexity that nobody can explain at the first outage at 11 pm. I said it in the enterprise piece already: the agent writes code. Building software is more than code.
The human goes one level up, or he goes
And here I part ways with the conclusion many draw from the post. The conclusion is not: less AI. The conclusion is: the human has to go one level up. Not the one who checks every code block. That scales as badly as typing, and it is exactly the job the man in the post hates so much. But the one who designs the system in which the agents work.
What that means: he sets the architecture. The patterns. The boundaries, what an agent may do and what not. The quality requirements, the data models, the interfaces. And above all the intention: what should this system do, and why. That is not less thinking than before. It is more, just on a different level. I wrote that in the article about the architect before this post existed, and I see it confirmed now: the architect does not die out. He becomes more important than ever. Only in the companies that measure sprints, he is being cut right now.
How I would build it
I would not build it the way the post describes: one big model that does everything, and people who press Enter. I would build it the other way round, and that is how we build it at NeoCoder, our own agent system, since day one.
Different tasks, different agents, partly different models. One analyses the requirement. One writes. Another checks the architecture rules, and it is another one, never the same. One tests. One looks at security. For some of these tasks a small model of your own is better than the biggest one there is, because it can do exactly one thing and you understand it.
No agent signs off on its own work. The one rule that holds everything together for me. Whoever writes does not check. That is the four-eyes principle every good team has known for thirty years, only that the eyes are now partly agents. The human does not check every block. He checks whether the rules were followed, and he wrote the rules.
The goal is a development machine, not a faster developer. The developer builds the machine: rules, checks, boundaries, feedback from errors and reviews. The machine takes over more and more of the operational work. But someone understands the machine, and that someone is the most important person in the team.
Intention before output. Before an agent builds, the why is written down. Not as a ticket title, but as a sentence a case worker could sign. A feature without that sentence does not get built, no matter how fast it would go.
That is the answer to "meat proxy": the human does not pass things on. He designs. And if a company does not want that, because it does not show up on the dashboard as a feature, then that is the company the man in the post wants to leave. Rightly so.
We measure the wrong thing
More pull requests. More features. More tickets. More code. Shorter sprints. That looks good on a dashboard, and it is exactly what produced the post. If you measure output, you get output. I would measure other things.
How much complexity we removed. Not added. Removed. A sprint in which code disappears is a good sprint.
How much code we still need at all. If an agent writes two thousand lines where two hundred would do, that is not progress. It is what I called giant classes in the enterprise piece.
How well the team understands the system. Can someone explain without the model why it is built this way. If not, that is the most important number, and it is red.
How many decisions the machine makes without breaking the rules. That is the metric for the development machine. It rises when the rules are good, and falls when someone only presses Enter.
Has the product become better. A hundred features nobody needs are not better than ten good ones. Even if the AI builds them in an afternoon.
What stays
I do not see AI in development negatively. I think what is happening right now is more exciting than almost anything I have experienced in this profession. But we should not use it to do the same thing faster. A team will at some point consist of a few people and very many specialised agents, I consider that likely. Those people will not be less important. Their task changes: from "write this code" to "design a system that can reliably build software". When at some point everyone can generate code in minutes, code is no longer an advantage. The advantage is knowing which code you should generate at all.
The man in the post is right: whoever only presses Enter no longer has a job, but a shift. But the answer is not less AI. The answer is that the human goes one level up: he designs the machine that builds, instead of watching it. And that companies stop measuring output and start measuring understanding. Whoever does not will very quickly get a lot of software nobody understands anymore.
Source: Thibault Spirlet, "An engineer's viral post captures the soul-crushing downside of AI coding", Business Insider, September 2026. Quotes paraphrased.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by a twin model of my own, trained on my texts. Sometimes that turns into a mix. Of course I read everything again, but nobody is infallible. Whatever stays in is mine too.