Enterprises are investing heavily in AI, but many are seeing few meaningful returns. Part of the problem may be that the wrong people are leading the transformation. AI is unlikely to replace developers, but it is changing what we need from them. The popular question is whether junior developers are still useful when large language models can write code faster and cheaper. What this misses is that younger developers, with their limited experience, may be exactly who we need to rethink how software is built.

This thought echoes a point made about age and authority in the tech industry. During a conference talk, a speaker tried to shame a young audience for not recognizing older figures who had shaped computing. As one observer noted, many of those famous older figures did their world-changing work when they were younger than the people being scolded. Bill Joy wrote vi at 22; John Carmack created Doom at 23; Linus Torvalds launched Linux at 22. Many computing titans made their biggest contributions before they had decades of experience.

The point is not that young developers are smarter. It is not that experienced developers should be ignored. Rather, at the beginning of big technology shifts, experience can work both ways. It helps people spot risk, but it can also make them overly attached to old ways. The most successful enterprises will find ways to balance youthful innovation with experienced guardrails.

The factory does not redesign itself

One useful way to understand why AI adoption is underperforming comes from Paul David's classic 1990 paper, The Dynamo and the Computer. The simplified version of his argument is that electricity did not immediately transform factories. For a long time, factories simply replaced the central steam engine with an electric motor while keeping the same layout, the same workflows, and the same assumptions. Electricity was new, but its potential was suppressed by forcing it into old factory systems.

Real productivity gains came 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 itself around a single driveshaft. Work could be reorganized around the flow of production. That is a good description of where many enterprises are with AI today.

Companies are buying copilot licenses by the thousands and wiring agents into existing applications, then wondering why the results are uneven. That is the equivalent of swapping the steam engine for an electric motor and declaring the AI modernization complete. 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 how developers build. The factory itself has to change.

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, but working software also means it complies with regulations, scales under load, respects security boundaries, and handles edge cases. This is where experienced developers matter enormously.

The agent era makes engineering judgment more important than ever. AI makes it easier to generate code, but easier code generation can lead to easier technical debt. The limiting factor becomes less about whether we can create something and more about whether we can create the right thing in the right place with the right constraints. Taste is required. Senior engineers are often better at seeing those constraints because their experience gives them taste. They know why a strange validation rule exists. They remember the customer who depended on undocumented behavior. They understand why a simple schema change can become a multi-week migration.

But experience also has a shadow side. It can make the current process feel inevitable. A senior engineer may view an AI assistant as 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 is the spec not executable? Why cannot the agent generate the test harness first? It is not that senior developers do not know these questions. They may simply lack the energy to challenge the machine.

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 to take a ticket, generate some code, and send it to a senior 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. More code 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 kind of process redesign that enterprises need but usually avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

What should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. The idea that lots of tokens equals great engineer should have been rejected long ago. Measuring AI productivity by number of lines written is a stupid mistake. Instead, leaders should ask what part of the software delivery process no longer makes sense. The biggest gains will come when teams change how they specify, test, review, and ship software.

Second, mix up AI workflow teams. This does not mean committees or PowerPoint-producing centers of excellence. It means combining two or three newer developers who are 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 constraints. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electricity metaphor, teams will fail with AI modernization if they simply add AI without removing outdated processes. Deleting unnecessary steps, redundant handoffs, and legacy assumptions is where the real transformation happens.

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 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. 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.

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 people who do not. Only then can AI investment lead to real change.

Source: InfoWorld News