Enterprises are investing heavily in artificial intelligence, yet many are struggling to show meaningful returns. That may be because the wrong people are leading the transformation. AI is not likely to eliminate developers, but it is changing what we need from them. The question of whether junior developers are still necessary in an era of large language models misses something important: their relative inexperience might be exactly what the industry needs to rewrite the rules of software development.

This idea becomes clearer when we look at how the industry has historically confused age with authority. During a conference talk, a speaker once tried to shame young attendees for not recognizing older figures who shaped computing. The irony is that many of those older figures did their most influential work when they were just about the same age as the people being lectured. Bill Joy wrote vi at 22, John Carmack created Doom at 23, and Linus Torvalds launched Linux at 22. Countless industry titans made their biggest contributions before accumulating decades of experience.

The point is not that young people are inherently smarter. They are not. Nor is the point that experienced developers should be ignored. That would be foolish. Rather, the larger lesson is that at the beginning of major shifts, experience can be a mixed blessing. Experience helps you see risk, but it can also make you overconfident in established ways. Successful enterprises will find ways to balance youthful innovation with experienced guardrails.

The factory doesn’t redesign itself

Zara Zhang recently highlighted Paul David’s classic 1990 paper, “The Dynamo and the Computer,” to explain why so many companies have adopted AI without much to show for it. David’s argument, simplified, is that electricity did not immediately transform factories. For a long time, factories simply replaced the central steam engine with an electric motor while preserving the same layout, the same workflows, and the same assumptions about how work should flow. The new technology was there, but its potential was stifled because it was forced into old systems.

The real productivity gains arrived only when factories stopped treating electricity as a cleaner steam engine and began redesigning work around smaller motors distributed throughout the building. Once every machine could have its own motor, the factory no longer needed to organize around a single driveshaft. Production could be reorganized around the natural flow of work.

That description fits many enterprises today. They buy copilot licenses by the thousands, wire agents into existing applications, and then wonder why results are so uneven. This is the equivalent of replacing a steam engine with an electric one and declaring the modernization complete. It is not complete. It is not even close.

The real payoff will not come from asking AI to write the same tickets a bit faster. It will come from changing how teams define work and how, and what, developers build. The factory itself has to change.

So here is the uncomfortable question: who is most likely to build the new factory?

Experience cuts both ways

There is an obvious danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, and “works” also means it complies, scales, respects security boundaries, and satisfies non-negotiable business requirements.

This is where experienced developers matter enormously. In the agent era, engineering judgment is more important than ever. AI makes it easier to generate code, but easier code generation can also become easier technical debt generation. The limiting factor is no longer “Can we create something?” but rather “Can we create the right thing, in the right place, with the right constraints?” Taste is required.

Senior engineers are often better at seeing these constraints because their experience gives them taste. They know why a weird validation rule exists. They remember the customer who depended on undocumented behavior. They understand why a simple schema change can turn into a multi-week migration.

But experience has a shadow side. It can make the current process feel inevitable. A senior engineer may view an AI assistant as a faster autocomplete because that is the easiest way to fit AI into an existing mental model. A junior developer, less invested in the old workflow, may ask more interesting questions: Why are we doing this ticket at all? Why isn’t the spec executable? Why can’t the agent generate the test harness first?

It is not that experienced developers do not know these questions. They may simply lack the energy to fight against the system. They have seen attempts at change fail before, and they know the institutional reasons why things are the way they are.

The value of inexperience

The worst way to use junior developers in the AI era is to treat them as cheaper versions of senior developers. That was always a bad idea, but AI makes it worse. If the job is “take this ticket, generate some code, and send it to a senior person for review,” the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior does not learn much, the senior gets buried in review, and the enterprise ends up with more code, which is hardly a good thing.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. That might mean giving newer developers interesting questions to answer, such as:

• How would we redesign onboarding if every internal API had an AI-readable contract and examples that actually worked?
• How would we change code review if the agent produced a change summary, test evidence, dependency risk, and rollback plan with every pull request?
• How would we build features if product requirements were written as executable acceptance tests rather than vague prose?
• How would we reduce toil if agents could safely perform routine migrations, dependency updates, or incident triage within clearly defined boundaries?

These are not toy problems. They are not “junior work.” They are exactly the process redesign challenges that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. The idea that “lots of tokens” equals “great engineer” is a vanity metric. Measuring AI productivity by lines of code written is a well-known mistake, and eventually everyone will claim they were always against it. Instead, ask questions like “What part of our software delivery process no longer makes sense?” The biggest gains from AI will come when we change how software is specified, tested, reviewed, and shipped.

Second, mix up AI workflow teams. Not committees or PowerPoint-producing centers of excellence. Combine two or three newer developers who are already fluent in AI-native tools with two or three senior engineers who understand production, security, architecture, and organizational constraints. Give them a real workflow to redesign, such as dependency upgrades or test creation.

Third, make the senior engineer’s job less about saying no and more about defining the guardrails within which others can say yes. Golden paths are key to using AI effectively. Good senior engineers should define the paved roads: approved patterns, test requirements, observability standards, and other guardrails. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Returning to the factory electricity metaphor, AI modernization will fail if we simply add AI without removing outdated processes. Every new AI capability should be accompanied by the removal of an old process that no longer serves a purpose. Deleting code, deleting processes, and deleting assumptions should be celebrated as much as creating new things.

Bring everyone to the table

The future of software development will not belong to the young. It will not belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They are less likely to accept the existing workflow as sacred. They are more likely to try weird tools, compose them in unexpected ways, and wonder why enterprise software development feels like a ritualized exercise in waiting for permission. Their inexperience is not a weakness; it is a source of fresh questions and unconventional solutions.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and boring is good. They can keep younger colleagues from breaking things while also opening doors that the younger developers did not know existed.

Enterprises need both. They need the developer who asks why the factory is still organized around the old drive shaft, and they need the developer who knows which machines will kill someone if moved casually. Every development team needs people who know why the old system exists, as well as those who do not know and are brave enough to ask why it still exists.

Source: InfoWorld News