Anand Naidu has witnessed the architectural shifts of software development from the granular, manual labor of the 1990s to the high-velocity, AI-augmented landscape of today. As an expert in both frontend and backend systems, he has navigated the recurring pitfalls of how engineering teams define and measure success. Today, he offers a candid look at the industry’s tendency to prioritize “productivity theater” over genuine problem-solving, urging a return to intentionality through spec-driven development and outcome-based results.
This conversation delves into the evolution of engineering metrics, exploring why traditional benchmarks like lines of code or story points often backfire. We examine the modern phenomenon of “tokenmaxxing” and how AI-driven activity can lead to bloated, unmaintainable systems if not managed with rigor. Finally, the discussion outlines a path forward where the craft of engineering moves upstream, focusing on defining clear requirements and delivering measurable value to the end user rather than simply maximizing computational output.
Engineering metrics like lines of code or story points often lead to bloated codebases or inflated estimates. Looking back at your experience since the 1990s, why do you think we keep falling into the trap of measuring quantity instead of quality?
It is a cycle that seems to repeat every decade because we naturally reach for things we can easily count, even if those things don’t actually move the needle for the business. Back in the 1990s, I saw companies that were literally paying developers by the line of code, which is probably the purest form of productivity theater I have ever witnessed. It created these massive, brittle codebases where developers were incentivized to write three pages of code for a problem that only required ten lines, leaving us with systems that were a nightmare to maintain and debug. When Agile and story points arrived in the 2000s, they were supposed to help us understand complexity and risk, but teams quickly learned how to game that system too. They would over-engineer a simple feature just to make it look like they were doing high-effort work, and once the metric becomes the goal, the actual value for the user gets buried under the weight of those inflated estimates. It is a fundamental human tendency to want a scoreboard, but in a discipline as creative as software engineering, a high score in activity rarely translates to a high-quality product.
We are currently seeing a new trend you describe as “tokenmaxxing,” where AI is used to flood systems with output. How is this behavior manifesting in modern development teams, and what are the hidden costs of this “activity-based” approach?
Today, we are seeing the same old “quantity over quality” mistake being rebranded for the AI era through behaviors like prompt flooding and the use of uncoordinated agent swarms. Prompt flooding is particularly concerning because it involves stuffing massive amounts of documentation and unnecessary context into every interaction, burning through tokens on context the model doesn’t actually need to solve the specific problem. I also see teams running background loops or multiple AI agents in parallel to maximize code output, often without a clear sense of who owns the resulting code or why it was generated in the first place. The hidden cost is a complete loss of control; you end up with a codebase that grows exponentially but lacks coherence, which eventually erodes team capability and business credibility. If we are just leaning on AI to perform productivity rather than deliver it, we are essentially spending massive human and computational resources on “activity” that doesn’t actually solve a user’s problem or close a workflow gap.
You have advocated for a shift toward “spec-driven development” to combat these issues. Can you walk us through how this methodology changes the way an engineer interacts with AI and where the “craft” of coding resides in this new model?
Spec-driven development is about moving the engineer’s intent further upstream, where the focus is on defining the “why” and the “what” before a single token is spent on the “how.” Instead of just throwing a vague prompt at an AI and hoping for a usable result, an engineer writes detailed, rigorous specifications that define the requirements and the intended system behavior. This is where the elegance of engineering lives now; the craft hasn’t disappeared, it has simply evolved into the orchestration of these systems with clear intent and meticulous detail. When you have a solid spec, you can use AI to generate code against it, but the engineer remains the primary architect who reviews that output to ensure it reduces friction for the user and improves reliability. It turns the developer into a high-level conductor rather than someone just trying to maximize the number of lines or tokens produced, ensuring that every piece of code serves a defined business purpose.
If we move away from counting tokens or tracking sprints, what are the specific, tangible outcomes that leadership should be looking at to determine if their engineering organization is actually succeeding?
The questions we should be asking are far more grounded in the reality of the user experience and the health of the business than they are in any dashboard of activity metrics. We need to look at whether we are resolving critical bugs more quickly or if we have significantly reduced the cycle time on features that provide high value to our customers. A truly successful engineering organization can point to a customer workflow that used to take hours and now takes only minutes, or they can show how a new deployment has directly improved the reliability of the platform for the end user. These are the outcomes that matter—things like improved product quality, faster delivery of meaningful features, and the closing of gaps in the user experience. Using the maximum amount of AI possible in a sprint isn’t impressive; what is impressive is using a well-crafted, intentional prompt to solve a specific, complex problem that makes the product better for the people using it.
What is your forecast for the future of software engineering as AI becomes even more integrated into the development lifecycle?
I believe we are heading toward a future where the most successful organizations will be those that prioritize rigor and intent over raw computational consumption. As AI continues to lower the barrier for generating code, the value of the “human in the loop” will shift almost entirely toward technical analysis, system design, and the ability to define complex challenges with precision. We will see a divide where some teams drown in AI-generated technical debt because they focused on activity, while others flourish by treating the specification as the most important piece of code they write. The integrity of our discipline depends on us not giving up the hard work of thinking and analyzing to the machines; if we use AI with the same rigor we expect from any other critical business decision, it will elevate the craft to new heights. Ultimately, the engineers who thrive will be the ones who never lose sight of why they are building in the first place and who use AI as a precise scalpel rather than a blunt instrument.
