A question recently surfaced in my LinkedIn feed that I haven’t been able to shake: How will the next generation of software developers gain experience when AI takes over the writing?

The analogy offered was that of a conductor — someone who doesn’t need to play the violin to judge whether the orchestra is in harmony. It’s a compelling metaphor. But I think it lets us off the hook too easily.

The Conductor Knows the Score

Here’s what the analogy gets right: a great conductor doesn’t micromanage each musician. They set direction, maintain coherence, and hear the ensemble as a whole.

But here’s what it glosses over: a conductor can only do this because they have spent years deeply understanding what each instrument is capable of. They know when the second violin is slightly flat. They feel when the tempo is drifting before the audience does. That sensitivity wasn’t born — it was forged through thousands of hours of intimate contact with the music.

Software engineering is no different. The intuitive understanding of a system — when something feels wrong before the tests tell you so, when a refactor is going to create more problems than it solves — doesn’t emerge from reading documentation. It comes from having been burned. From having debugged a race condition at 2am. From having inherited a codebase that made sense to no one, including the person who wrote it.

What AI Changes (and What It Doesn’t)

Let me be clear about what I observe in practice: AI is genuinely transformative. Tasks that used to consume hours — boilerplate generation, test scaffolding, documentation drafts — now take minutes. The feedback loop is tighter. The floor for getting something working has dropped dramatically.

But the ceiling — the difference between working and good, between functional and maintainable — that gap has not closed. If anything, it has widened.

Here’s why: AI is extraordinarily good at pattern completion. Given a clear, well-defined problem, it will produce a plausible solution faster than any human. But software problems are rarely well-defined at the start. The real work is figuring out what the right question even is.

Consider a classic scenario: a firmware component starts behaving unpredictably under real operating conditions — but only after several hours of runtime, and never in the lab. The symptoms are ambiguous. The timing traces are noisy. The failure doesn’t reproduce on the bench. An AI can help you analyze the trace logs, suggest hypotheses, and narrow down the search space. But recognizing that the root cause is a subtle interaction between an interrupt handler running slightly too long and a watchdog timer with an overly tight tolerance — that requires a mental model of the hardware-software boundary that no prompt can substitute for.

The New Shape of Seniority

This is where I think the conversation needs to move. The question isn’t whether AI will replace developers — it won’t, not at the level that matters. The more interesting question is: what does senior expertise look like in an AI-assisted world?

I see three shifts happening:

Validation becomes the new coding. The primary skill is no longer writing correct code — it’s recognizing incorrect code quickly. This requires knowing what correct looks like, which requires having written a lot of incorrect code yourself first.

System design moves to the foreground. When implementation is cheap, architecture becomes expensive. Decisions about how components communicate, where state lives, how the system degrades gracefully — these decisions are now proportionally more important because they’re harder to reverse and AI is less reliable at making them well.

Pattern recognition across time. Experienced developers don’t just understand the current state of a system — they understand its history. They know which parts of the codebase are fragile because they’ve seen them break. They know which team dynamics produce which kinds of technical debt. AI has no access to that institutional memory.

The Apprenticeship Problem Is Real

I want to return to the original question, because I don’t think we should dismiss it.

If junior developers spend most of their time reviewing AI-generated code rather than writing their own, some important things may not happen. The muscle memory of debugging. The frustration of a design that seemed elegant until you tried to extend it. The satisfaction — and the lesson — of refactoring something messy into something clean with your own hands.

These experiences aren’t just character-building. They are how the pattern recognition that defines senior judgment gets built. If we automate them away entirely, we may be optimizing the present at the cost of the future.

The answer isn’t to artificially restrict AI use among junior developers. It’s to be intentional about what experiences we ensure still happen. Code review as teaching, not gatekeeping. Deliberate time in complex, legacy systems. Pair programming where the human leads and the AI assists, not the other way around.

A Team Sport, For Now

My pragmatic take: for the foreseeable future, the most effective engineering teams will be those that treat AI as a fast, capable, but unsupervised collaborator — and senior humans as the ones responsible for the quality of what ships.

An incredibly fast apprentice, without supervision, is still an unsupervised apprentice.

The competitive advantage right now isn’t AI fluency alone. It’s the combination of deep human expertise and AI speed. Teams that have one without the other will find the gap showing up eventually — either in velocity, or in the quiet accumulation of decisions that seemed fine at the time.

This post is part of an ongoing series exploring the intersection of engineering practice and the changing landscape of AI tooling.