Enterprises are pouring enormous sums into artificial intelligence with surprisingly little to show for it. A common explanation for these disappointing results is technological immaturity or poor data quality, but another possibility deserves more attention: the wrong people are leading AI transformation. While executives focus on model selection and token consumption, the deeper structural issue is who gets to redesign software delivery around AI, and whether organizations are giving the right mix of people permission to do so.

AI is not likely to eliminate developers, despite persistent fears to the contrary. Rather, it will reshape what organizations need from developers at every level. A recurring question in the industry is whether junior developers still matter when large language models can generate code faster and cheaper than a human newcomer. This question misses the point. The habits, doubts, and even the impatience of younger developers may be exactly what the industry needs to rewrite the rulebook for software development in an AI-native world.

Consider an observation from the technology commentator James Governor, riffing on a piece by Ben Griffiths about the industry’s tendency to confuse age with authority. Griffiths described attending a conference talk in which a speaker scolded younger members of the audience for failing to recognize some of the older men who had shaped computing. The irony, Griffiths noted, was that many of those older luminaries did their world-changing work when they were younger than the audience members being lectured. Bill Joy wrote vi at age 22. John Carmack created Doom at 23. Linus Torvalds launched Linux at 22. The pattern repeats across decades: many of the industry’s defining achievements came from people who had not yet accumulated decades of experience.

This is not an argument that young people are naturally smarter, or that experienced developers should be ignored. That would be absurd. The more useful insight is that at the beginning of a major platform shift, experience can be a mixed blessing. Experience helps people see risks, but it can also create overconfidence in established ways of working. The enterprises that thrive in the AI era will be those that find a deliberate balance between youthful innovation and experienced guardrails.

The factory doesn’t redesign itself

A useful historical analogy comes from Paul David’s classic 1990 paper, “The Dynamo and the Computer.” David argued that electricity did not immediately transform factories. For a long time, factory owners simply replaced a central steam engine with an electric motor while keeping the same factory layout, the same workflows, and the same underlying assumptions about how work should be organized. Electricity was new and powerful, but its potential was largely stifled by being forced into old factory systems.

The big 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. When each machine could have its own motor, the factory no longer had to organize itself around a single drive shaft. Work could be reorganized around the natural flow of production, leading to entirely new factory designs and massive gains in efficiency.

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

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

So here is the uncomfortable question that every engineering leader should be asking: Who is most likely to build the new factory? The answer is not simply the most senior people in the room, and not simply the youngest either. It is a deliberately mixed team.

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. Enterprise software must comply with regulations, scale under load, respect security boundaries, and satisfy customers who depend on subtle behaviors that have evolved over years. None of that is obvious to a newcomer, and pretending otherwise is reckless.

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 is no longer “can we create something?” but “can we create the right thing, in the right place, with the right constraints?” Taste is required, in other words.

Senior engineers are often better at seeing 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, and why a seemingly harmless refactor can break an obscure integration. This kind of institutional knowledge is invaluable, and it cannot be captured entirely in documentation or training data.

But experience also has a shadow side. The same experience that gives senior engineers judgment 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? These questions can feel naive, but they are often the questions that unlock real transformation.

It is not that experienced developers don’t know these questions. Rather, they may simply lack the energy to rage against the machine after years of fighting for incremental improvements. The status quo becomes a comfortable weight, and the burden of questioning it falls to those who have not yet learned to accept it.

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 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 developer does not learn much, the senior developer 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 sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel. Junior developers, precisely because they have less to unlearn, can approach these questions with fresh eyes. They can experiment with AI-native workflows without feeling that they are betraying the way things have always been done.

Finding the balance

So what should engineering leaders do differently? First, stop treating AI adoption as an individual productivity contest. The industry seems to be moving away from the idea that “lots of tokens” equals “great engineer,” but the fact that this idea was ever taken seriously is telling. Measuring AI productivity by the number of lines written is a foolish metric, and one day everyone will claim to have always been against it. The better question is: What part of our software delivery process no longer makes sense? AI’s biggest gains will come when organizations change how they specify, test, review, and ship software.

Second, mix up AI workflow teams. This does not mean forming committees or standing up PowerPoint-producing centers of excellence. It means combining 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 that blended team a real workflow to redesign, such as dependency upgrades, test creation, or incident response. Let the junior developers propose the future, and let the senior engineers make sure it is safe.

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 security guardrails. Then let junior developers and AI agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electrification metaphor, AI modernization will fail if organizations simply add AI without removing outdated processes. The entire point of the factory redesign was not to add electric motors to the old layout; it was to eliminate the drive shaft, the centralized power distribution, and the workflow constraints that came with them. Likewise, enterprises need to reward teams that delete unnecessary processes, not just teams that add new AI features.

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, and that are intentional about how they do so.

Newer developers bring impatience. They are less likely to accept the existing workflow as sacred. They are more likely to try unconventional 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 to be minimized but a resource to be deployed.

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 that boring is usually good. They know which machines will break if moved carelessly, and they know why some rules exist even when those rules are not written down.

Enterprises need both kinds of developers. 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 cause damage if moved casually. Every development team needs people who know why the old system exists, as well as people who do not. The most successful AI transformations will be led by those teams.

Source: InfoWorld News