Enterprises are investing huge sums in artificial intelligence, yet many have little to show for it. The usual explanations involve data readiness, model quality, or application integration. But another possibility deserves attention: AI is often being introduced by people who are too comfortable with the processes that AI is meant to replace.

AI will not eliminate the need for developers. Instead, it will change what is expected of them. As language models become more capable of generating code, questions about the junior developer’s role have become common. If AI can write code faster and cheaper, why hire developers who still need to learn how software is built? The answer may seem counterintuitive. The inexperience of junior developers might be exactly what the industry needs as it attempts to rewrite the rules of software development.

That idea was highlighted in a recent industry discussion about the habit of confusing age with authority. At a conference, a speaker tried to shame young audience members for not recognizing the older men who had shaped computing. The irony was that many of those older figures had done their most influential work when they were roughly the same age as the people in the audience. Bill Joy wrote vi at 22. John Carmack created Doom at 23. Linus Torvalds launched Linux at 22. Countless others made their biggest contributions before accumulating decades of experience.

This is not an argument that young developers are naturally smarter or more creative. Nor is it a suggestion that experienced technologists should be ignored. The point is about perspective. At the beginning of major technological shifts, experience can be a mixed blessing. It can help leaders spot risk, navigate complexity, and avoid costly mistakes. It can also make them overconfident in the methods and mental models that worked in the past. The most successful organizations will be those that pair the energy of younger developers with the guardrails supplied by more experienced engineers.

Why the factory won’t redesign itself

Economist Paul David’s 1990 paper, The Dynamo and the Computer, is a useful way to understand why many AI projects fall short. David’s argument was that electricity did not immediately transform factories. At first, factory owners simply replaced the central steam engine with an electric motor. They kept the same layout, the same workflow, and the same assumptions. Electricity was a new power source, but it was being used as if it were a cleaner steam engine.

The real productivity gains arrived only when factories were redesigned around the new technology. Once each machine had its own motor, a factory no longer had to organize itself around a single driveshaft. Work could be arranged around the flow of production. This is a useful metaphor for the current state of AI in the enterprise. Many companies are buying thousands of AI assistant seats, wiring agents into existing applications, and expecting large gains. The results are often uneven because the underlying process has not changed.

This is the equivalent of swapping a steam engine for an electric motor and declaring the 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, test, and ship software. The factory itself has to change.

Experience cuts both ways

There is an obvious danger in romanticizing youth. Unlimited confidence and limited context have produced plenty of bad software. Enterprises need software that works, and working software must comply with regulations, scale under load, and respect security boundaries.

That is why experienced developers matter. Engineering judgment becomes even more important in an era when AI can generate code on demand. With easier code generation comes easier technical debt generation. The limiting factor is no longer whether something can be built; it is whether the right thing is built in the right place with the right constraints.

Senior engineers often have better taste because they have lived through the consequences of architectural decisions. They know why a strange validation rule exists. They remember the customer who relied on undocumented behavior. They understand why a seemingly simple schema change can become a multiweek migration. That knowledge is essential.

But experience also has a shadow side. It can make the current process feel inevitable. A senior engineer may look at an AI assistant and see 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, might ask more interesting questions. Why is this ticket needed at all? Why is the spec not executable? Why can the AI agent not generate the test harness first?

More experienced developers are not incapable of asking such questions. They may simply have less time and energy to challenge the status quo after years of watching failed reorgs and abandoned initiatives.

The value of inexperience

The worst way to use junior developers in an AI-driven organization is to treat them as cheaper versions of senior developers. That was always a bad idea, and AI makes it even worse. If a junior developer is asked to take a ticket, generate code, and send it to a senior for review, the junior becomes a human wrapper around a coding tool. Nobody benefits. The junior developer does not learn much. The senior becomes buried in review. The organization ends up with more code, which is not necessarily a good thing.

A better approach is to give junior developers room to explore new workflows while providing oversight from experienced colleagues. That means giving newer developers genuinely challenging process questions:

• How would onboarding change if every internal API had an AI-readable contract and examples that actually worked?
• How would code review improve if every pull request included a change summary, test evidence, dependency risk, and rollback plan generated by an AI agent?
• How would feature development change if product requirements were written as executable acceptance tests instead of vague prose?
• How would toil be reduced if agents could safely handle routine migrations, dependency updates, and incident triage inside well-defined boundaries?

These are not toy assignments. They are not junior work. They are process redesign problems, and they are exactly the kind of work that enterprises often avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

Engineering leaders can start by rejecting the idea that AI adoption is an individual productivity contest. Measuring AI success in lines of code or tokens generated is a vanity metric. Some of the strongest voices in the industry have already dismissed that approach, noting that one day everyone will claim they were always against it. The more useful question is which parts of the software delivery process no longer make sense. AI’s biggest gains will come from changing how teams specify, test, review, and ship software.

Second, leaders should create mixed workflow teams. These should not be committees or PowerPoint-producing centers of excellence. The most effective teams will combine 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, senior engineers should spend less time saying no and more time defining guardrails. Paved roads matter when AI is being used by many developers. Senior engineers can set approved patterns, test requirements, observability standards, and review expectations. Once those boundaries are clear, junior developers and AI agents can move quickly inside them.

Fourth, reward deletion. AI adoption often fails when new automation is added without removing outdated processes. If a company keeps every legacy handoff, every outdated meeting, and every needless approval step, adding AI will simply make the old machine run faster. Deleting process steps is an essential part of modernization.

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 with procedures that seem arbitrary. They are less likely to treat the existing workflow as sacred. They are more willing to experiment with unfamiliar tools and to combine them in unexpected ways. Experienced developers bring judgment. They understand that software has users, auditors, attackers, budgets, latency, and history. They know that the right answer is often the boring answer, and that boring is sometimes the highest compliment.

Enterprises need both kinds of contributors. They need the developer who asks why the factory is still organized around the old driveshaft. They also need the developer who knows which machines can cause real damage if moved casually. Every development team needs people who understand why the old system exists, and people who do not carry that weight at all.

Source:InfoWorld News