The End of Coding or a New Renaissance? The Invisible Crisis of AI

💡 Quick Summary (TL;DR):

• AI can remove useful repetition from junior work as well as tedious repetition. A task completed is not necessarily a skill acquired.
• The risk is not that AI makes people incapable. It is that teams delegate without creating the struggle, explanation, feedback, and review through which engineers learn to carry responsibility.
• Organisations that need future senior engineers must deliberately design those learning loops. AI can help when it explains, critiques, tests, and exposes reasoning.

The loudest question around AI coding is whether fewer people will be needed to write software. I think a quieter question matters at least as much: where will the next generation of senior engineers come from?

For a long time, the early work of software development served two purposes. It moved a project forward, and it gave a less experienced developer repeated contact with the machinery of real systems. A small feature, a failing test, a confusing production bug, or a review comment could be slow and frustrating. It also taught cause and effect.

AI changes that bargain. A senior engineer can now complete some of that work faster. A junior developer can receive a plausible answer before they have formed a hypothesis of their own. That is useful. It can also remove the low-risk situations in which someone learns how a system behaves when the answer is not obvious.

This is not an argument for preserving drudgery. It is an argument for noticing what the drudgery was quietly teaching.

The missing middle of an engineering career

Most capable senior engineers were not trained by a single course or a heroic breakthrough. They accumulated a large number of small corrections: a test that revealed an assumption, a reviewer who asked why a boundary existed, an incident that forced them to trace a failure across systems, and a design discussion that showed what their first solution had missed.

Those experiences build mental models. Over time, an engineer stops seeing a ticket as a set of lines to produce. They begin to see contracts, failure modes, data flows, users, and the cost of being wrong.

Many entry-level tasks are repetitive enough for AI to accelerate. They are also often bounded enough to be safe places to make, explain, and repair mistakes. If organisations simply remove those tasks, they may reduce junior hiring or turn the remaining work into prompt-and-accept routines. Neither outcome guarantees that a junior engineer becomes capable of operating a system independently.

That is an observation about a learning path, not a prediction that every junior role will disappear. Hiring patterns will vary by company, market, and the work itself. The concern is more practical: a team can make local delivery faster while weakening the route by which it renews its own senior capability.

What the early evidence says—and does not say

The evidence on AI and software learning is still young. In a 2026 randomized experiment, Anthropic studied developers learning an unfamiliar Python library. Participants using AI scored 17 percent lower on an immediate quiz of concepts they had just used than participants who coded by hand. The study was small and measured short-term comprehension, so it does not tell us what happens to a career over years or to every AI workflow.

Its more useful finding is about method. Participants who used AI to ask follow-up and conceptual questions, or to request explanations, showed stronger mastery than those who mainly used it to produce code. That fits a distinction teams can act on: assistance can support learning, while delegation can conceal whether learning happened.

AI can be an unusually patient tutor. It can explain unfamiliar code, propose counterexamples, generate tests, compare approaches, and challenge a developer to articulate a decision. Used that way, it may give a junior engineer more feedback than a busy team could otherwise provide. The tool is not the problem. Passing responsibility to it without comprehension is.

Fewer easy tasks changes the organisation, not only the individual

The individual version of this problem is easy to see: someone copies a fix, the immediate error disappears, and they cannot explain the next variation. The organisational version arrives later.

If junior developers get less exposure to debugging, design trade-offs, and review discussion, the team gets fewer people ready to take on the work that experienced engineers currently carry. The visible gain may be a smaller backlog. The less visible cost can be a thinner bench for incident response, architecture decisions, code review, and succession.

This is capability debt. It is not the same as the technical-debt problem in the previous vibe coder essay, where quickly generated systems become costly to maintain. Nor is it the review-capacity problem in AI Made Code Cheap. Verification Is Still Expensive., where seniors become a queue for output they did not create. Here the question is earlier: are we still creating engineers who can eventually make and defend those decisions themselves?

No spreadsheet will show this debt immediately. A team may meet its delivery targets while its experienced engineers remain the only people who can explain a fragile subsystem or judge a risky change. The signal appears when a senior leaves, an unfamiliar failure occurs, or review capacity is needed faster than it can be developed.

Build learning loops deliberately

The answer is not to reserve every simple task for humans. It is to make sure accelerated work still contains a learning loop.

A junior engineer can use AI to draft an implementation, then explain the chosen approach before review. They can ask the model to list assumptions and failure cases, write tests from requirements rather than from the generated code, and compare the result with an existing pattern in the codebase. A reviewer can discuss one important decision instead of silently repairing the whole change.

Teams can also keep some work deliberately close to the learner: debugging a real issue with guidance, owning a small service end to end, rotating through incident follow-up, or pairing on a design decision before an agent produces a large change. The exact practice will differ by system. The common requirement is exposure to reasoning, feedback, and consequences.

This costs time in the moment. So did apprenticeship before AI. The difference is that the investment is easier to skip now because a tool can produce an acceptable-looking answer immediately.

Coding is changing. Mastery still needs a path.

Writing code manually is becoming a smaller share of some software work. That does not make engineering knowledge obsolete. It makes the ability to frame a problem, notice a bad assumption, test an answer, and take responsibility for a system more valuable.

The useful question for a team is not whether AI has replaced junior work. It is whether the work left behind still gives junior engineers a credible route to become the people the organisation will need five years from now.