Simon Willison published a piece this week, Coding After Coders: The End of Computer Programming as We Know It, that frames something most developers have been feeling but not quite naming. The argument is not that programmers disappear. It is that the activity we have called programming, the actual writing of code as the core daily labor, is in the process of being abstracted away, the same way assembly language was abstracted away and the same way manual memory management was.
What makes this moment different from previous abstraction waves is the target. Every prior shift raised the floor of what you had to specify to get work done. FORTRAN let you stop thinking about register allocation. C let you stop thinking about hardware instruction sets. Python let you stop thinking about memory layout. Frameworks let you stop re-implementing authentication and routing. Each layer removed a category of decisions from the programmer’s plate. But the programmer was still there, writing the logic, specifying the structure, expressing intent in a formal language.
LLMs are starting to absorb that last part.
What Has Already Changed
The transition is not hypothetical. Tools like Cursor, GitHub Copilot, and Claude Code have already shifted the ratio of written-by-human to written-by-tool code in production codebases at companies ranging from startups to enterprises. Anthropic’s own internal data on Claude Code usage shows that developers using agentic coding tools are completing certain categories of tasks, specifically well-specified feature additions and refactors with clear test coverage, at dramatically higher rates than before.
The Karpathy framing, which he called vibe coding, captured something real: for a certain class of problems, you no longer need to know how to write the code. You need to know what you want. That is a meaningful distinction. The cognitive load does not go to zero, but it relocates. It moves from syntax and structure to specification and verification.
This is not the same as saying code quality stopped mattering. It is saying that the person ensuring quality no longer needs to be the same person who generated the code. That separation, between generation and verification, is the structural shift Willison is pointing at.
The Historical Pattern
Every prior abstraction wave followed a roughly similar arc. A new layer appeared that automated some previously manual cognitive task. Early adopters gained productivity. The profession resisted briefly. Then the new layer became the baseline, and the old skill became either a specialty or obsolete.
Assembly programmers who moved to C did not stop being valuable. They became the people who understood what the compiler was doing, which made them better at writing C in performance-critical systems. Their knowledge persisted, but as background context rather than foreground labor. The same thing happened when managed languages replaced manual memory management. Systems programmers did not vanish; they became the people who understood the runtime well enough to debug what the garbage collector was doing.
What tends not to survive is the entry-level version of the old skill. When the automation is good enough to handle routine cases, the training pipeline for the next generation breaks. You cannot learn to program by writing boilerplate if no one writes boilerplate anymore. The junior developer path, which has historically meant writing straightforward code under supervision while building up pattern recognition and debugging intuition, stops being available at the same volume.
This is not speculation. Multiple large tech companies have publicly or quietly reduced junior engineering hiring since 2024. The work that justified those roles, initial implementations of well-specified features, is increasingly handled by LLM-assisted workflows where one senior developer does the specification and review work that previously required three or four people on a team.
What the Transition Actually Demands
There is a version of the optimistic take that goes: programmers do not disappear, they just move up the stack. They become better architects, better communicators, better at understanding systems at a higher level. This is partially true and partially wishful.
The uncomfortable part is that moving up the stack is not automatic or free. The skills required at higher abstraction levels, system design, problem decomposition, requirements elicitation, debugging emergent behavior in large codebases, are genuinely harder to develop without going through the lower-level work first. The reason senior developers are good at system design is that they spent years debugging gnarly code and learning, viscerally, where complexity hides. That knowledge is embodied. It comes from writing a thousand functions that seemed simple and turned out not to be.
If the lower-level work disappears before there is a clear path for building the equivalent intuition, you do not automatically get a generation of better architects. You potentially get a generation of people who are competent at prompt engineering for well-understood problems and poorly equipped to handle the problems that fall outside the distribution the LLM was trained on.
This is where Willison’s framing is most useful. The question is not whether AI changes programming. It does. The question is whether the profession builds sustainable training pathways for the skills that remain valuable, or whether it assumes the transition will sort itself out.
What Survives
Some things are structurally difficult for current LLMs to do well. Debugging novel failures in production systems, the kind that involve unexpected interactions between components the model has never seen together, still requires deep contextual understanding that current models handle inconsistently. Specifying requirements with enough precision that an LLM produces correct code still requires knowing enough about the domain to recognize when the output is wrong. Evaluating security properties of generated code, particularly subtle authorization logic and input validation, requires exactly the kind of adversarial thinking that comes from having written and broken security-sensitive code yourself.
Architecture decisions, the ones that are expensive to reverse, remain firmly in the domain where human judgment matters. An LLM will generate a plausible-looking schema, a plausible-looking API surface, a plausible-looking service boundary. It will do so with confidence regardless of whether the design will hold under real load patterns, real team structures, or real operational requirements. The people who can evaluate those outputs well are the ones who have watched plausible-looking designs fail in production.
None of this makes the transition painless. The skills that survive are the ones that are hardest to acquire without the lower-level work that is being automated away. That is the actual problem Willison is pointing at, and it is a real one.
The Shape of What Comes Next
Programming as a mass profession, as a job that a large percentage of the technical workforce does as their primary activity, is probably not going to look the same in ten years. The number of people whose job is primarily writing code is already declining relative to the amount of software being produced. That trend is not reversing.
What replaces it is not fully legible yet. Some of it is the higher-abstraction work described above: system design, requirements engineering, evaluation, debugging complex emergent behavior. Some of it is domain-specific expertise that happens to be expressed through code, where the domain knowledge is the scarce resource and the code is just the medium. Some of it is roles that do not exist yet, the way cloud infrastructure roles did not exist when C was invented.
The people who navigate this transition well are not necessarily the ones who resist the new tools. They are the ones who use the tools seriously enough to understand where they fail, who build the debugging intuition for AI-assisted systems the same way prior generations built intuition for the systems they worked with, and who treat the shift in abstraction as an opportunity to think at a level that was previously too expensive to think at.
Programming after coders is still programming. The job description changes. The underlying cognitive work of specifying intent, reasoning about correctness, and understanding failure modes does not. What changes is which of those tasks you spend most of your day on.