Speed vs. Scale: Why Senior Developers are the Editors of the AI Era

The tension between developers and business leaders arises from a conflict between the need for market speed and the necessity of system stability. AI exacerbates this by increasing output while decreasing code understandability and reliability. By decoupling development into 'Speed' and 'Scale' versions, senior developers can facilitate rapid growth while maintaining responsible control over the core system.

Key Points

• Business stakeholders prioritize speed to reduce market uncertainty, whereas senior developers prioritize simplicity to manage system complexity.
• Communication fails because developers talk about complexity management while the business is focused on uncertainty reduction.
• AI agents accelerate the ability to ship code but threaten the understandability and stability of the system, for which senior developers are ultimately responsible.
• The primary value of a senior developer is taking responsibility for the system's long-term health and ability to be fixed or extended.
• A proposed solution is to decouple software into a 'Speed' version for rapid prototyping and a 'Scale' version for stable, high-quality production.

Sentiment

The community largely agrees with the article's core thesis that senior developer expertise is rooted in deep, hard-to-transfer mental models. However, there is significant pushback on the oversimplified framing of senior developers as purely 'avoiders' and the engineer-centric perspective. Many commenters see the article as validating their own frustrations but note that the proposed solutions (Speed vs Scale separation) are aspirational rather than practically achievable in most organizations.

In Agreement

• Expertise is inseparable from internal 'world models' built through years of practice — it cannot be fully communicated through documentation or words alone
• Senior developers serve as crucial gatekeepers who understand system complexity and prevent unnecessary changes that could destabilize production systems
• AI tools accelerate code production speed but risk creating unmanageable complexity when developers lack deep understanding of the systems they're building
• The 'two loops' framing (speed vs. stability) resonates with the lived experience of tension between business stakeholders wanting rapid delivery and engineers managing long-term system health
• Proof-of-concepts routinely go into production without being properly rewritten, validating the need for the 'Speed vs Scale' separation the article proposes
• Peter Naur's 'Programming as Theory Building' paper supports the article's core thesis — losing the humans who hold the theory of a system is deeply costly

Opposed

• The article's characterization of senior developers as 'avoiders and reducers' is overly simplistic — good seniors know when to innovate and when to hold back, depending on context
• The framing is too engineer-centric — product designers and product managers also build essential world models of customers and business domains that are equally hard to transfer
• Some senior developers use 'untransferable expertise' as gatekeeping or job protection rather than genuinely struggling to communicate — they should just write things down
• The decline of mentorship isn't necessarily youth arrogance — the internet genuinely provides access to world-class experts, raising the bar for what local expertise offers
• If a prototype is working in production with no incidents, the business case for rewriting it is weak regardless of developer aesthetics — incident count matters more than code purity
• The article's advice essentially amounts to the decades-old 'plan to throw one away' from The Mythical Man-Month, which has never been easy to convince decision-makers to follow