Artificial intelligence has become a priority for enterprises, but many are spending heavily and seeing disappointing results. One reason may be that the wrong people are leading the transformation. Success with AI is not just about tools, models, or token counts. It depends on who is involved in reshaping the work itself.
AI is not likely to eliminate developers so much as change what organizations need from them. A common question is whether junior developers are still needed when large language models can write code faster and cheaper. That question misses an important truth: younger developers and their relative inexperience may be exactly what the industry needs to rewrite the rules of software development.
Why AI projects stall
Enterprises are buying copilot licenses by the thousands. They are wiring agents into existing applications and automating routine tasks. Yet the results are often uneven. The reason is familiar: new technology is being forced into old workflows. The way teams define work, write specifications, test code, and review changes has not kept pace with what AI can do.
This pattern is not new. In 1990, economist Paul David published a famous paper called “The Dynamo and the Computer.” He explained that electricity did not immediately transform factories. At first, factory owners simply replaced a central steam engine with an electric motor. They kept the same layout, the same workflow, and the same assumptions. Electricity was new, but its potential was limited by an old design.
The big productivity gains did not arrive until factories redesigned work around smaller motors distributed throughout the building. Once every machine had its own motor, the factory no longer had to be organized around a single driveshaft. Work could be reorganized around the flow of production. That is the lesson many enterprises still need to learn with AI.
Today, companies are essentially swapping the steam engine for an electric motor. They ask AI to write the same tickets a little faster, generate similar code, and summarize the same meetings. Then they wonder why the return on investment is poor. The real payoff will come only when teams change how they specify, test, review, and ship software. The factory itself has to change.
The case for young developers
At the beginning of a major shift, experience can be a mixed blessing. It helps people see risk, but it can also make them overconfident in old ways. Many of computing’s most celebrated figures did their world-changing work at a young age. Bill Joy wrote the vi editor when he was 22. John Carmack created Doom at 23. Linus Torvalds launched Linux at 22. These innovators did not have decades of experience when they disrupted the industry. They had fresh perspectives, impatience with unnecessary limitations, and a willingness to question assumptions.
The point is not that young people are smarter. They are not. The point is that people with less invested in the present system are more likely to see its flaws. A junior developer may not know all the reasons why a process exists, and that can be valuable. They might look at a ticket and ask why it exists at all. They might wonder why specifications are not written as executable tests. They might question why a code review process still works the way it did before AI.
Senior engineers often have the same questions, but they may not have the energy to challenge the machine. They have seen many failed transformations. They know that changing a process brings risk. They may prefer to quietly work around the system rather than try to redesign it.
Why experience still matters
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. “Works” means more than simply running without crashing. It means complying with regulations, scaling under load, respecting security boundaries, and surviving the messy realities of production.
This is where experienced developers matter a great deal. The agent era makes engineering judgment more important than ever. AI makes it easier to generate code, but easier code generation also makes it easier to generate technical debt. The limiting factor is no longer “Can we create something?” It is “Can we create the right thing, in the right place, with the right constraints?” Taste is required.
Senior engineers often have that taste because they have seen the consequences of small decisions. 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. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. The right answer is often boring, and boring is good.
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 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. The enterprise ends up with more code, which is rarely a good thing in itself.
Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. They should be asked interesting questions. 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 a 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 usually avoid because everyone is too busy running on the existing hamster wheel.
Mixing people and process
Engineering leaders should stop treating AI adoption as an individual productivity contest. Measuring AI productivity by the number of lines written is a stupid mistake. The number of tokens generated says nothing about whether the software is valuable, maintainable, or secure. Leaders should instead 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.
Leaders should also mix up AI workflow teams. This does not mean creating committees or 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. Then give them a real workflow to redesign. Dependency upgrades are a good starting point. So is test creation. So is onboarding documentation. These are practical areas where new tools can be tested and old assumptions can be challenged.
Senior engineers should spend less time saying no and more time defining the guardrails within which others can say yes. Golden paths are essential to using AI effectively. Senior engineers should define the paved roads: approved patterns, test requirements, observability standards, and security boundaries. Then let junior developers and agents move quickly inside those boundaries.
Reward deletion. This may be the most important point. Enterprises will fail with AI modernization if they simply add AI without removing outdated processes. Every step in the software delivery pipeline should be examined. If a process exists only because of a tool limitation, remove the process. If a meeting exists only to share status updates, remove the meeting. If a code review step is redundant because the agent already generated a detailed summary and tests, remove the step. The goal is not to make the old factory slightly faster. The goal is to build a new factory.
The future of software development does not belong exclusively to the young, and it does not belong exclusively to the old. It belongs to teams that combine the strengths 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 the history. They know the risks. They know that every decision has a downstream consequence.
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 break if moved carelessly. Every development team needs people who know why the old system exists, as well as people who do not.
Source: InfoWorld News