This is not a forecast about headcount or an attempt to rank models. It is a record of a change I can feel in recent projects. Software still matters, but writing code is no longer the unquestioned center of the work.
New models and agents arrive every day. The feed mixes real wins with inflated demos and nonsense. That noise will be around for a while, but the place that people and code occupy in the development process is changing in a way that is harder to ignore.
I have been building software for a long time, and I have not felt a shift this directly before. Lately, the amount of code I write by hand feels roughly half of what it used to be. Even code I do write goes back to an agent for review, alternatives, tests, or a second pass. It is now harder to find a step in the development loop that AI does not touch.
The uncomfortable change is not only about speed. I am less willing to sit with painful code for hours. I ask an agent to map the structure, point out risk, and propose a patch before I trace every branch myself. One question is hard to avoid: do I still need to understand every line in the old way?
When code stops being the center
For decades, software engineering put people at the center of the loop. A person interpreted the request, designed the logic, wrote the implementation, and fixed the failure. That order can now reverse. A person may set a goal and its limits; an agent may do much of the implementation and execution; the person may mostly inspect the result.
The unit of work is changing with it. It used to be a function, a commit, or a carefully reviewed pull request. More often now, it is a result: a feature working in a running system, with evidence that it can be trusted. The code is still there, but it no longer proves by itself that the work is done.
That also changes what a product may look like. Some services will increasingly be built for agents to call, negotiate with, and operate. People may spend more time approving, interrupting, or investigating what happened through a dashboard. I cannot prove that outcome from a few projects, but it is a plausible direction.
Domain knowledge is not a permanent moat
It is tempting to say that domain experts will be safe. I am less certain. Project rules, recurring questions, edge cases, and internal vocabulary can move into an agent’s usable context faster than expected. When everyone asks an agent before asking a teammate, knowledge that used to live in one person’s head becomes a shared working surface.
That does not make people useless. It changes where the value sits. The useful person may not be the one who remembers the most rules. It may be the one who notices conflicts between them, knows what a customer will not forgive, and can judge which trade-off the organization is willing to own.
AI does not yet run the whole show because it has not earned that level of trust. If a system mishandles customer data, spends too much money, or fails in production, someone still has to decide where it stops and who answers for the damage. Good examples and long operating records may lower that barrier. A generated patch that passes today is not the same thing as trust earned in operation.
I saw this while finishing the Luthn Team onboarding flow. The default workspace is prepared automatically, but connecting the team’s Hub and connecting an Agent remain separate steps. Combining them would have been convenient, but it could also change an Agent’s settings before the user intended it. That is where we stopped the automation.
The important work was not getting an Agent to write more code. It was deciding what may change automatically and what must be preserved when it does not work.
The work that remains
I do not think developers survive by trying to type faster than an agent. That contest is already losing its meaning. The work moves outward: defining what should be built, saying what must not be built, separating what an agent may see from what it may execute, and deciding what counts as proof.
The questions matter more than the prompt. What can this agent access? What is it allowed to change? Who decided that this result is correct? Can the system be stopped and rolled back? Who carries the cost if it is wrong?
Without answers, a polished demo is still a lucky demo. It is not a product someone can responsibly operate.
This is why I do not think the developer’s future is simply code generation with better autocomplete. The role moves closer to intent, authority, verification, and consequence. You may no longer write every line, but you still need to question the system, inspect the evidence, and refuse the task that should not be delegated.
Software is not ending. We may build far more of it, far more quickly. What may be ending is the era in which code was the central artifact and developers were its exclusive readers. The harder question is no longer whether developers can survive. It is who decides how far an AI may act, and who stands behind the answer.
Scope note: this is a personal project retrospective, not a benchmark. The estimate that I write about half as much code by hand is my own working impression, not a measured industry claim.
