Enterprises are pouring massive budgets into AI initiatives with surprisingly little to show for it. One reason may be that the wrong teams are leading the change. AI isn't going to eliminate developers, but it will redefine what we need from them. A recurring question is whether junior developers still matter when language models can generate code faster and cheaper. The overlooked truth is that those less experienced engineers may be exactly the people needed to rewrite the rules of software development.

The debate about age in technology surfaced recently when an industry speaker tried to shame younger audience members for not recognizing older computing pioneers. The irony: many of those pioneers did their most influential work in their twenties. Bill Joy wrote vi at 22, John Carmack shipped Doom at 23, and Linus Torvalds launched Linux at 22. Their achievements weren't grounded in decades of experience; they came from boldness, curiosity, and a willingness to ignore established assumptions.

None of this suggests that young people are inherently smarter, or that experienced developers should be ignored. Rather, it highlights a broader truth: at the beginning of big technological shifts, experience can be a mixed blessing. Experience helps you see risk, but it can also make you overconfident in old ways. The enterprises that succeed with AI will find a balance between youthful innovation and experienced guardrails.

The factory doesn't redesign itself

A classic 1990 paper, "The Dynamo and the Computer," explains why so many companies have adopted AI without much benefit. The argument, simplified, is that electricity didn't immediately transform factories. For a long time, factory owners simply swapped the central steam engine for an electric motor while keeping the same layout, the same workflows, and the same assumptions. Electricity was new, but its potential was stifled by being forced into old factory systems.

The big productivity gains came only when factories stopped treating electricity as a cleaner steam engine and started redesigning work around smaller motors distributed throughout the building. Once each machine had its own motor, the factory no longer had to organize around a single driveshaft. Work could be reorganized around the flow of production.

That's a decent description of where many enterprises stand with AI today. They buy copilot licenses by the thousands, wire agents into existing applications, and then wonder why the results are so uneven. This is the equivalent of swapping a steam engine for an electric motor and declaring the modernization work done. It's not. Not even close.

The real payoff won't come from asking AI to write the same tickets a bit faster. It will come from changing how teams define work, and how and what developers build. The factory has to change. So here is the uncomfortable question: Who is most likely to build the new factory?

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, yes, but "works" also means it complies, scales, respects security boundaries, and more. This is where experienced developers matter. A lot.

The agent era makes engineering judgment more important than ever. AI makes it easier to generate code, but easier code generation can become easier technical debt generation. The limiting factor becomes less "Can we create something?" and more "Can we create the right thing, in the right place, with the right constraints?" Taste is required.

Senior engineers are often better at seeing constraints because their experience gives them taste. They know why the weird validation rule exists, and they remember the customer who depended on undocumented behavior. They understand why a simple schema change can turn into a multi-week migration. That perspective is invaluable.

But experience also has a shadow side. It can make the current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that's 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? It's not that senior developers don't know these questions. It's that they may not have the energy to rage against 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, but 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 doesn't learn much, the senior 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're not "junior work." They're exactly the sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. The industry has been moving away from the idea that "lots of tokens" equals "great engineer," but the fact that it even flirted with that notion is damning. Measuring AI productivity by lines of code written is a stupid mistake. One day, everyone will claim they were always against it. Instead, ask questions like: 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.

Second, mix up your AI workflow teams. Not committees or PowerPoint-producing centers of excellence. Combine 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, 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 so on. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Back to the factory electricity metaphor: we'll fail with AI modernization if we simply add AI without removing outdated processes.

Bring everyone to the table

The future of software development won't belong to the young. It won't belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They're less likely to accept the existing workflow as sacred. They're 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 driveshaft, 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 those who don't.

Source: InfoWorld News