More Code Isn't Better Code

Note: AI helped put these thoughts into words; the experiences and perspectives are my own.

More Code Isn’t Better Code

Why We Need to Slow Down.

The Inescapable Trap of Vanity Metrics

The software engineering industry never truly moved past these vanity metrics. While tech-forward companies built cultures around system reliability and impact, the broader corporate world—non-technical firms, traditional clothing retailers, or car rental companies with newly minted software departments—often imported superficial standards from legacy management frameworks. Now, driven by automated tooling, those exact metrics are creeping back even into tech-heavy firms. Teams and management are sliding into measuring productivity through superficial telemetry once again: raw lines of code, pull request counts, and velocity metrics inflated by automation.

The Trap of Speed and Stunted Growth

Engineers, particularly those new to the field, have eagerly embraced the startup ethos of “move fast and break things” or simply “just ship.” But relying entirely on AI models without deep engagement stunts professional development. When an engineer outsources every block of logic, they never build the mental models required to understand system internals.

This gap becomes painfully clear during an on-call incident at 3:00 AM. If you didn’t build the mental framework of how a service fails, you cannot effectively debug it under pressure.

The illusion of competence that AI provides hides critical design gaps. AI agents can easily generate the happy path of a feature, but they rarely challenge the core architectural trade-offs.

Consider a real-world platform component—like the metering service used to bill customers for cloud infrastructure. Building a basic client loop is trivial, but designing a resilient system requires deep intent:

How do you handle failures when reporting usage metrics to prevent revenue loss?
Do you queue usage facts and retry with exponential backoff?
Do you aggregate usage points into a single data point during an outage, accepting a loss of granularity once the system restores?
Most importantly, how do you guarantee that your retry logic doesn’t result in double-billing customers?

An AI agent will write the implementation code instantly, but it won’t organically question whether your retry mechanism is idempotent.

Code Reviews in the Age of Slop

We have built sophisticated tools to accelerate code creation, but we haven’t evolved our code review processes to match. Attention spans are shortening, and review fatigue is setting in. As peers approve massive AI-generated pull requests they don’t fully understand, more subtle bugs slip into production.

This lack of deep codebase familiarity combined with automated generation creates real-world risks. When complexity outpaces human comprehension, security posture is the first thing to degrade.

The Personal Project Reality Check

This tension isn’t just theoretical; I ran headfirst into it while building a personal project utilizing backend AI features.

While generating a feature, the model decided it was entirely appropriate to embed my private AI model provider API key directly into the frontend store and invoke the API straight from the client’s browser. If deployed blindly, any user could easily extract the key from their browser developer tools and use it for their own personal queries at my direct financial expense. The model optimized for a working UI demo, completely bypassing the fundamental security boundary of protecting server-side secrets.

This kind of oversight mirrors how small security lapses compound into major production failures across the industry. For a stark example of how third-party AI integrations can compromise security posture, look at the attack chain behind the Vercel April 2026 Security Incident. In that case, an attacker leveraged a compromised OAuth token from a third-party AI tool (Context.ai) used by an employee to gain a foothold into corporate systems and access exposed environment variables. Whether it is an AI agent leaking an API key into a frontend bundle or an over-permissioned OAuth integration, when complexity outpaces human comprehension and intentional oversight, security is always the first thing to degrade.

The MVP Paradox

To be fair, speed has its proper place. There is immense value in building fast, prototyping, and validating MVPs to get early user feedback—especially for startups where time-to-market is existential.

The tension lies in knowing when you are in “discovery mode” versus “production mode.” The danger is when prototype-grade code, generated carelessly under pressure, quietly transitions into core infrastructure without a deliberate rewrite.

Conclusion: Intentional Engineering

We do not need developers to become casual prompt operators acting like pseudo-product managers—throwing loose instructions at a model and hoping for the best.

Instead, we need engineers to use these tools intentionally:

Be explicit in your architecture: Outline module organization, system expectations, and data flow constraints in your prompts.
Delegate execution, retain control: Let the model handle the tedious translation into syntax, while you retain absolute ownership of the design, security boundaries, and failure modes.
Balance speed with maturity: As founders, pioneers, and business owners, we must embrace rapid prototyping to validate ideas. But we must equally recognize the precise moment to pull back, manually refactor the codebase, secure our systems, and build for long-term resilience.