Quoting James Shore

The Catalyst: An Overlooked Alarm While the industry celebrates the "productivity boost" from AI coding tools like GitHub Copilot and Cursor, veteran software engineer James Shore, in an article cited by Simon Willison, presents a sobering, almost brutal mathematical model. He points out that we are collectively falling into a cognitive trap: equating "speed of writing code" with "efficiency of software development." This reveals a deeper trend—the value assessment system for AI in software engineering might be fundamentally flawed from the start. Deconstruction: The Unsettling "Maintenance Cost" Math Shore's core argument can be understood simply: software development is not a "one-off sale" but an ongoing "maintenance process." Writing code is just the beginning; the subsequent debugging, modification, extension, and comprehension (i.e., maintenance) constitute the bulk of the cost. He presents a simple yet powerful calculation: - If AI doubles your coding speed (output x2), but also doubles the cost to maintain that code (cost x2), your total maintenance cost becomes four times the original (2x2=4). - Even if AI magically keeps maintenance costs steady (cost x1), the total cost doubles (2x1=2). Only if AI can increase coding speed while proportionally decreasing maintenance costs (e.g., output x2, maintenance cost x0.5) can the total cost break even (2x0.5=1). This requires AI tools not just to generate code, but to generate cleaner, more maintainable, less buggy, better-documented code, and even help understand and refactor old code. Most current tools clearly focus more on the former. Trend Insight: From "Coding Accelerator" to "Debt Manufacturing Machine" This statement punctures the "productivity bubble" of current AI-assisted programming. It reveals a deeper trend: the competitive dimension for AI tools is shifting from "generation speed" and "code completion accuracy" to their impact on the total lifecycle cost of software. If AI merely allows us to pile up a harder-to-maintain "legacy code mountain" faster, it brings not liberation, but a heavier shackle—what Shore calls "permanent indenture." This forces the entire industry to question: Are we using 20th-century "lines of code" thinking to evaluate 21st-century AI tools? Practical Value: How Should Developers and Teams Respond? For frontline developers and team leads, this provides a new evaluation framework: 1. Shift Evaluation Criteria: Don't just ask, "How much faster does it make me write code?" Ask more, "Does it make understanding, modifying, and debugging this AI-generated code easier or harder?" 2. Focus on Code Quality: Prioritize AI tools that generate code with clear comments, reasonable abstractions, and adherence to team best practices. Configure tools to favor generating "maintainable code" over "code that just runs." 3. Invest in "AI-Assisted Maintenance": Look for or develop AI applications that help understand complex codebases, automatically supplement documentation, and identify potential technical debt. This is the true area of untapped value. 4. Renegotiate ROI: When introducing AI tools to a team, the Return on Investment (ROI) calculation must include estimated maintenance costs over the coming years, not just the immediate development speed boost. Counter-Intuitive Insights and Surprises The most counter-intuitive point is that AI might make poor software engineering practices unprecedentedly efficient. It can generate large volumes of hard-to-understand, tightly coupled, low-cohesion code at incredible speed, thereby exponentially amplifying a team's existing technical debt problems. For teams with rigorous engineering practices, AI is a force multiplier; for teams already in a mess, AI could be pouring oil on the fire. This unexpectedly points to the intensification of the "Matthew Effect" in the AI era of software engineering—the strong get stronger, and the weak become more vulnerable.