Enterprises are pouring billions into AI initiatives with surprisingly little to show for it. The problem may not be the technology; it may be the structure of the teams trying to deploy it. AI is not about to eliminate developers, but it will change what we need from them. If companies keep applying new tools to old workflows, they will keep getting modest improvements and call it transformation. Real gains will come from rebuilding the software factory itself.
The most interesting signal comes from our own industry history. A conference speaker once tried to shame young attendees for not recognizing some of the older men who shaped computing. The irony is that many of those men did their world-changing work while they were younger than the audience members being scolded. Bill Joy wrote vi at 22, John Carmack created Doom at 23, Linus Torvalds launched Linux at 22. The lesson is not that young developers are smarter. The lesson is that at the beginning of a big shift, experience can be a mixed blessing. It helps with risk, but it can also make old ways feel inevitable. The most successful enterprises will pair the impatience of youth with the judgment of experience.
The factory doesn't redesign itself
A classic academic paper from 1990, The Dynamo and the Computer, explains why many companies have adopted AI without much to show for it. When electricity replaced steam, factories did not change overnight. They swapped the central steam engine for an electric motor, but kept the same layout, workflows, and assumptions. The potential of electricity was stifled by force-fitting it into an old system. Productivity gains arrived only when factories redesigned around smaller motors distributed throughout the building, allowing work to flow according to production needs.
This is exactly where many enterprises are with AI. They buy copilot licenses in the thousands and wire agents into existing applications, then wonder why the results are uneven. That is the equivalent of replacing the steam engine and announcing the modernization is complete. It is not. The payoff will not come from asking AI to write the same tickets slightly faster. It will come from changing how teams define work, how they specify requirements, how they test code, and how they decide what to build. The factory has to change.
Experience cuts both ways
There is obviously a danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, which means it must comply with regulations, scale under load, respect security boundaries, and survive the messy realities of production systems. This is why experienced developers matter. They provide taste. They know why a weird validation rule exists. They remember a customer who depended on undocumented behavior. They understand that a schema change is never just a schema change.
But experience has a shadow side. It can make current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that is the least disruptive 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? Experienced developers are capable of asking those questions, but they may not have the energy to fight the machine. A team composed only of veterans can become a well-oiled machine for building the wrong thing. A team composed only of newcomers can build something ambitious that collapses in production. The answer is not choosing between them.
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. If the job is to take a ticket, generate some code, and send it upstream for review, the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior does not learn, the senior gets buried in review, and the enterprise ends up with more code. In an environment where AI makes code generation easier, technical debt generation also becomes easier. More code is not a good outcome.
Instead, junior developers should be given room to explore new workflows under light supervision. They should be asked interesting questions:
- How would we redesign onboarding if every internal API had an AI-readable contract and working examples?
- How would we change code review if an 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 inside clearly defined boundaries?
These are not toy problems. They are exactly the kind of process redesign enterprises need but avoid because everyone is too busy running the existing hamster wheel. Junior developers can ask the questions that seniors have stopped asking. Their inexperience is a feature, not a bug.
Finding the balance
Engineering leaders should stop treating AI adoption as an individual productivity contest. The industry flirted with measuring AI productivity in lines of code, and that vanity metric is already being mocked. One day everyone will say they were always against it. The better question is: what part of our software delivery process no longer makes sense? AI's biggest gains will come when we change how we specify, test, review, and ship software.
Leaders should also mix workflow teams. Not committees or centers of excellence, but small teams composed of two or three newer developers who are fluent in AI-native tools and 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. Let the junior developers move quickly. Let the senior engineers define the guardrails.
The senior engineer's job should be less about saying no and more about defining the paved road. They should set approved patterns, test requirements, observability standards, and operational boundaries. Then allow junior developers and agents to move faster within those boundaries. This is how golden paths work in AI-native development.
Reward deletion. This may be the most important point. If enterprises add AI without removing outdated processes, they will fail. The electric factory only became productive when it abandoned the central driveshaft. The same principle applies to software delivery. Remove the rituals, handoffs, and approvals that exist only because they were needed in a pre-AI world. Deletion is hard because it feels like losing capacity. But every process that remains after a technology shift is a tax on the future. In the AI era, the fastest way to create real value may be to stop doing things that no longer matter.
Bring everyone to the table
The future of software development does not belong to the young or the old. It belongs to teams that combine 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 ask 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 usually good.
Enterprises need both. 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 will cause damage if moved casually. Every development team needs people who understand why the old system exists, and people who do not. That combination, not any single generation, is what will make AI productive.
Source: InfoWorld News