Enterprises are pouring vast sums into artificial intelligence, yet many are seeing disappointing returns. One possible reason is that organizations are placing the wrong people in charge of the transformation. As previously argued, AI is not likely to eliminate developers but will instead change what is expected of them. For instance, there is ongoing debate about whether junior developers remain necessary in a world where large language models can write code faster and more cheaply. However, this overlooks the reality that younger, less experienced developers might be exactly what is needed to rewrite the rules of software development.

This idea crystallized after reading a reflection by James Governor on a piece by Ben Griffiths about the industry habit of confusing age with authority. Griffiths recalled a conference talk where the speaker shamed young audience members for not recognizing older pioneers of computing. The irony, as noted, is that many of those pioneers did their most transformative work at very young ages. Bill Joy wrote vi at 22, John Carmack created Doom at 23, and Linus Torvalds launched Linux at 22. These titans made their biggest contributions before accumulating decades of experience.

The point is not that young people are inherently smarter, nor that experienced developers should be ignored. Rather, it is that at the beginning of major shifts, experience can be a double-edged sword. It helps identify risks but can also breed overconfidence in outdated methods. The most successful enterprises will find ways to balance youthful innovation with the guardrails provided by seasoned professionals.

The factory doesn't redesign itself

Zara Zhang recently referenced Paul David's classic 1990 paper, The Dynamo and the Computer, to explain why many companies adopt AI without significant results. David argued that electricity did not immediately transform factories. Initially, factories simply replaced the central steam engine with an electric motor while keeping the same layout and workflow. The new technology was forced into old systems, stifling its potential. Real productivity gains came only when factories abandoned the steam-engine mindset and redesigned work around distributed motors, allowing each machine its own power source and enabling reorganization around production flow.

This mirrors the current state of AI adoption in many enterprises. Companies are purchasing thousands of copilot licenses and wiring agents into existing applications, then wondering why results are uneven. This is equivalent to swapping a steam engine for an electric one and declaring modernization complete. The real payoff will not come from using AI to write tickets slightly faster. It will come from fundamentally changing how teams define work, how software is specified, tested, reviewed, and shipped. The factory itself must change.

Experience cuts both ways

There is a clear danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence but limited context. Software needs to work, which means it must comply with regulations, scale, respect security boundaries, and more. This is where experienced developers prove invaluable. The agent era makes engineering judgment more important than ever. AI makes it easier to generate code, but easier generation can lead to easier accumulation of technical debt. The limiting factor is not whether something can be created, but whether it is the right thing created in the right place with the right constraints. Taste is required.

Senior engineers often excel at recognizing these constraints because their experience gives them taste. They understand why a seemingly odd validation rule exists and recall customers who depended on undocumented behavior. They know why a simple schema change can become a multi-week migration. However, experience also has a shadow: it can make existing processes feel inevitable. A senior engineer might view an AI assistant as a faster autocomplete, fitting it into an existing mental model. In contrast, a junior developer, less invested in the old workflow, may ask more fundamental questions: Why does this ticket exist at all? Why is the spec not executable? Why can the agent not generate the test harness first? It is not that senior engineers are unaware of these questions—they may simply lack the energy to challenge the status quo.

The value of inexperience

The worst way to use junior developers in the AI era is as cheaper versions of senior developers. That was always a poor strategy, but AI makes it worse. If the job is to take a ticket, generate code, and send it for review, the junior developer becomes a human wrapper around a coding assistant. This benefits no one: the junior learns little, the senior is buried in reviews, and the organization ends up with more code—which is rarely beneficial. Instead, junior developers should be given room to explore new workflows with appropriate oversight. They should tackle questions such as: How would we redesign onboarding if every API had an AI-readable contract with working examples? How would code review change if agents provided change summaries, test evidence, dependency risk, and rollback plans? How would features be built if product requirements were executable acceptance tests instead of vague prose? How could agents perform routine migrations or incident triage within clear boundaries? These are not toy problems but exactly the kind of process redesign that enterprises need but often avoid because everyone is too busy maintaining the current hamster wheel.

Finding the balance

Engineering leaders should stop treating AI adoption as an individual productivity contest. The idea that more tokens equals a better engineer is a damaging vanity metric as criticized by Santiago Valdarrama. Instead, ask which parts of the software delivery process no longer make sense. The biggest gains will come from changing how software is specified, tested, reviewed, and shipped. Second, mix up AI workflow teams. Combine two or three junior developers 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 updates or test creation. Third, shift the senior engineer's role from saying no to defining guardrails within which others can say yes. Golden paths are key: approved patterns, test requirements, and observability standards that allow junior developers and agents to move quickly within safe boundaries. Fourth, reward deletion. Many organizations will fail with AI if they only add AI without removing outdated processes. The factory metaphor suggests that deleting the old drive shaft is as important as installing new electric motors.

Bring everyone to the table

The future of software development will not belong exclusively to the young or the old. It will belong to teams that combine the talents of both. Newer developers bring impatience and a willingness to question sacred workflows. Experienced developers bring judgment, understanding of users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and that boring is good. Enterprises 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 break if moved carelessly. Every team needs people who understand why the old system exists, as well as those who do not care.

Source: InfoWorld News