AI Helps You Build Faster. What If That's a Problem?

There’s a debate happening right now in software engineering that I find fascinating, not because either side is wrong, but because both sides are missing the same thing. Experienced engineers are pushing back on AI-assisted development, arguing it produces code that falls apart under real conditions. Meanwhile, other developers are shipping features at a pace that would have seemed absurd two years ago. The skeptics are right about the failure mode. The optimists are right about the capability. But both camps are focused on the code, when the real problem is upstream of the code entirely.

What AI Is Already Good At

AI-assisted development is genuinely impressive at working within the feedback loops it already has. Give an AI agent a well-structured project with a linter and a solid test suite, and it will do something remarkable. It will make a change, run the checks, see a failure, reason about what went wrong, and fix it. The first time I saw Claude doing this it was magic. It made me sit back and just marvel: this chatbot was actually fixing things using tests like I would.

This is a big part of why code is one of the most promising domains for AI. Unlike generating prose or images, code comes with built-in, objective feedback mechanisms. Compilers tell you if it’s valid. Linters tell you if it’s clean. Tests tell you if it works. That’s woefully incomplete, but it is at least concrete, and AI thrives on concrete feedback.

The Gap Between “It Works” and “It’s Right”

But concrete and incomplete is precisely the kind of surface area where bugs and vulnerabilities hide. This isn’t a new problem. It’s the oldest problem in software development. The gap between what the business asks for and what the engineering team builds is where most projects go sideways. AI doesn’t create that gap. However, it does widen it, because AI produces more code across more surface area, faster. More chances for things to drift from what the business actually needs, with less natural friction to catch it.

Without clarity and clear acceptance criteria on what to build, we can’t know if we’re really hitting the target or not.

Executable Specifications Close the Gap

This is where Behavior Driven Development becomes more relevant than it’s ever been, specifically the practice of writing executable specifications.

The core idea is straightforward: before you write code, define the expected behavior in straightforward examples and rules that both technical and non-technical people can understand. Then make those definitions executable. Turn them into tests that run automatically and tell you whether the software does what it’s supposed to do. Dan North originated BDD to solve exactly the communication gap between business intent and technical implementation.

With AI in the loop, executable specifications do two things. First, they give AI a richer set of signals to check against, not just “does this compile and pass unit tests” but “does this match the behavior the business actually defined.” The same self-correcting loop that already works so well with linters and unit tests now extends to business-level outcomes.

Second, and this is the part I think is underappreciated: the process of writing specifications forces the business to make decisions it hasn’t made yet.

Every system has rules that seem clear until you hit the edges. “Don’t let users withdraw more than their account balance.” Simple enough. But what happens when someone tries to withdraw the exact amount? Is that allowed? Does it trigger an account closure? Is there a minimum balance requirement nobody documented? Those are business decisions, not technical ones, and they’re the kind of thing that doesn’t surface until someone pushes on a concrete example.

BDD is built around exactly this: generating concrete examples, especially at the edges, that force clarity on decisions the business might think it’s already made. That discipline has always been valuable. It’s more valuable now because AI will happily implement whatever assumption seems most reasonable and move on. A human developer might notice the ambiguity, but AI simply can’t.

Traceability as a Byproduct

There’s a practical dimension here beyond better tests. In regulated environments (healthcare, financial services, any domain where you need to demonstrate that your software does what you say it does) traceability is a requirement.

We’ve done a lot of work in clinical trials, where you need trace matrices mapping every feature back to a specific requirement. Those are laborious to build by hand and even harder to maintain through a manual process. Requirements live in one system, code lives in another, and the mapping between them survives on human effort and good intentions.

When you drive development through executable specifications, that traceability becomes a byproduct of how you build rather than a separate documentation exercise. Every feature starts with examples, which become specifications, which become tests, which drive the code. Add a new feature, and you’ve already documented how it works and what examples drive it.

This matters even more when AI is accelerating the pace of changes. Updates become trivially fast, but knowing exactly what changed and whether those changes still map to documented requirements gets harder as velocity increases. Executable specifications aren’t just the guardrails. They’re the audit trail.

More Code Was Never the Answer

If there’s one lesson that software engineering keeps having to relearn, it’s this: more code production doesn’t solve the problem of not knowing what you’re building. We learned this with teams. Adding ten developers to a struggling project didn’t make it better, and plenty of us have lived through projects where it made things dramatically worse. The constraint was never typing speed. It was clarity.

AI gives us a massive leap in code production. That’s real and it’s valuable. But code production without clear goals, defined outcomes, and a way of knowing whether you’ve built the right thing was never a solid solution. It wasn’t a solution with ten more developers, and it’s not a solution with AI.

The teams that will get the most out of AI-assisted development aren’t the ones writing more code. They’re the ones writing better specifications, and letting the AI do what it’s actually good at: building against concrete, testable definitions of what “right” looks like.