Enterprises are spending astonishing amounts of money on artificial intelligence and, in many cases, have remarkably little to show for it. The reason may have less to do with the models themselves than with the people chosen to lead the change.

The dominant question in boardrooms and engineering all-hands meetings has been whether junior developers are still needed now that large language models can generate code faster and more cheaply than a first-year hire. That framing misses something important. The relative inexperience of younger developers may be precisely what organizations need in order to rewrite the rules of software development rather than simply automate the old ones.

AI is unlikely to eliminate developers. It is far more likely to change what organizations need from them. The uncomfortable truth is that many of the assumptions baked into today's software delivery process were built for a world without capable code generation, and those assumptions are now load-bearing walls that nobody wants to move. Younger developers, who never helped pour those foundations, are often the least attached to them.

The Historical Case for Youth

Consider the track record of the industry's most celebrated figures. Bill Joy wrote vi at 22. John Carmack created Doom at 23. Linus Torvalds released the first version of Linux at 22. The pattern repeats across computing history: many of the people who reshaped the field did their most consequential work long before they had accumulated decades of scar tissue and institutional memory.

That does not mean young people are smarter. They are not. Nor does it mean experienced developers should be sidelined or ignored, which would be reckless. The point is subtler and more useful: at the beginning of a major shift, experience is a mixed blessing. It helps you spot risk, and it can also make you dangerously overconfident in old ways of working. The most successful enterprises find a way to balance youthful experimentation with experienced guardrails.

The Factory Doesn't Redesign Itself

A classic 1990 economics paper, "The Dynamo and the Computer," offers a useful way to understand why so many companies have "adopted" AI without much to show for it. Its argument, simplified, is that electrification did not immediately transform manufacturing. For decades, factories simply swapped out a central steam engine for a single large electric motor while keeping the same floor plan, the same workflows, and the same assumptions.

The historical details matter. In the steam era, a factory was organized around one enormous power source, with belts, shafts, and pulleys distributing mechanical energy to every workstation. The building's architecture followed the power source. When electricity arrived, early adopters ripped out the steam engine and bolted a big electric motor onto the same driveshaft. They had changed the fuel, not the factory. Electricity was new, but its potential was largely stifled by force-fitting it into an existing system built for something else.

The real productivity gains arrived later, when factories stopped treating electricity as a cleaner steam engine and started designing work around small motors distributed throughout the building. Once each machine could have its own motor, the factory no longer had to organize itself around a single driveshaft. Work could be reorganized around the flow of production instead of the flow of power. Output climbed accordingly.

That is a fair description of where many enterprises sit today with AI. They are buying copilot licenses by the thousands, wiring agents into existing applications, and then wondering why the results are so uneven. This is the equivalent of swapping the steam engine for an electric motor and declaring the modernization effort complete. It is not. Not even close.

The real payoff will not come from asking AI to write the same tickets a little faster. It will come from changing how teams define work and what developers build. The factory has to change. Which raises 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" is a demanding standard: it must comply with regulation, scale under load, respect security boundaries, survive audits, and remain maintainable years after the original author has moved on.

This is where experienced developers matter enormously. In the agent era, engineering judgment becomes more important than ever. AI makes it easier to generate code, but easier code generation can also mean easier technical debt generation. The limiting factor shifts from "Can we build something?" to "Can we build the right thing, in the right place, with the right constraints?" That requires taste, and taste is largely earned through experience.

Senior engineers are often better at seeing constraints because their experience has given them that taste. They know why a seemingly arbitrary validation rule exists. They remember the customer whose business depends on undocumented behavior. They understand why a simple schema change can turn into a multi-week migration with a rollback plan and a communications strategy. They have watched systems fail in ways nobody predicted and learned from it.

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

It is not that more experienced developers cannot conceive of these questions. They often can. It is that they may not have the energy to fight the organization to get them answered, especially when the existing process, however flawed, is still delivering.

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, and AI makes it worse. If the job is "take this ticket, generate some code, and hand it to a senior person for review," the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior learns little, the senior drowns in review work, and the enterprise ends up with more code, which is rarely the goal.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues to keep them grounded. That might mean handing newer developers genuinely 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 every pull request arrived with a change summary, test evidence, dependency risk assessment, and rollback plan?
• 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" in any meaningful sense. They are exactly the kind of process redesign that enterprises say they need but generally avoid, because everyone is too busy running on the existing hamster wheel to stop and rebuild it.

What Engineering Leaders Should Do

First, stop treating AI adoption as an individual productivity contest. The industry flirted with the idea that consuming more tokens equals being a better engineer, and the mere fact that this became a serious metric is damning. Measuring AI productivity in lines of code written is a vanity measurement that collapses under scrutiny. Far better to ask: What part of our software delivery process no longer makes sense? The biggest gains will come from changing how teams specify, test, review, and ship software, not from making individual developers type less.

Second, mix up your AI workflow teams. Not committees, and not centers of excellence that produce slide decks. Combine two or three newer developers who are already fluent in AI-native tooling with two or three senior engineers who understand production, security, architecture, and organizational constraints. Then give that group a real workflow to redesign, such as dependency upgrades or test creation, and hold them accountable for measurable improvement.

Third, redefine the senior engineer's role. The job should be less about saying no and more about defining the guardrails within which others can say yes. Golden paths matter enormously when agents are generating work: approved patterns, test requirements, observability standards, deployment contracts. Senior engineers should build those paved roads, then let junior developers and agents move quickly inside the boundaries.

Fourth, reward deletion. This may be the most important point of all. Returning to the factory metaphor, AI modernization will fail if organizations simply add AI on top of outdated processes without removing anything. Every new tool layered onto an obsolete approval chain, a redundant review step, or a documentation ritual nobody reads produces cost without compounding benefit. Someone has to be credited for turning things off.

Bringing Both to the Table

The future of software development will not belong exclusively to the young, nor to the old. It will belong to teams that combine the talents of both. Newer developers bring impatience, and impatience is underrated. They are less likely to accept the existing workflow as sacred. They are more likely to try strange tools, compose them in unexpected ways, and ask why enterprise software development so often feels like a ritualized exercise in waiting for permission.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is frequently boring, and that boring is good when it means predictable and maintainable. They remember the incidents nobody wants to repeat and the migrations that took six months longer than planned.

Enterprises need both. They need the developer who asks why the factory is still organized around the old driveshaft, and they need the developer who knows which machines will kill someone if they are moved casually. Every development team needs people who understand why the old system exists, alongside people who have no idea, and therefore no fear of asking whether it should.

Source:InfoWorld News