I’ve spent the last 15 years building web and application software. The tools change, the platforms change, the “best practices” change. But one thing stays constant: the projects that go well are the ones where we are clear about what we are building, why we are building it, and what “done” actually means.

Generative AI doesn’t change that. It puts it under a spotlight.

Why I’m Betting on Specifications

I’m not talking about hundred-page documents that no one reads and everyone resents. I’m talking about a software requirements specification in the original sense: a durable, reviewable description of what the system must do and the boundaries it must operate within. If you want a baseline definition, start with the Software Requirements Specification (SRS) concept .

In my experience specs have often been treated as “process overhead” once a team was moving fast. Now we have a tool that can generate thousands of lines of code in minutes. The bottleneck isn’t typing. The bottleneck is correctness. And correctness starts with intent.

We’ve Been Here Before: Shipping What We Don’t Fully Understand

Jake Nations at Netflix said it well “I shipped code I don’t understand and I bet you have too.”

That’s not an indictment of engineers. It’s reality. Systems are complex. Deadlines are real. We work in layers of abstractions. Sometimes you ship because you have enough confidence, not perfect understanding.

Generative AI increases the odds that you ship code you didn’t author and don’t fully comprehend. That’s fine if your verification and constraints are strong. It’s a problem if your workflow is “looks good, ship it.”

Specifications Enable “Slow Thinking” Without Slowing Delivery

A lot of software failure isn’t technical—it’s interpretive. People thought they agreed on what they were building, then reality proved they didn’t. Specs are how you force the hard conversations to happen while it’s still cheap to have them.

The value of a good specification has always been:

The Human Role Doesn’t Disappear, It Moves Upstream

The human in the chain provides abstract reasoning: business context, risk tolerance, security posture, product judgment, ethical boundaries, and the “this matters because…” layer that models can’t reliably infer.

Then we record those insights into a specification. That spec becomes the context, and the instruction set the model uses to generate the implementation.

Evaluating Model Performance: One Specification, Multiple Models 

To effectively compare and select the optimal large language model (LLM) for code generation, a consistent input artifact—the software specification—is paramount. This approach enables a systematic evaluation process, addressing the challenge of reproducible assessment in model output. By documenting requirements throughout the development lifecycle, the same comprehensive specification can be leveraged across various LLMs or different iterations of a single model. This facilitates a direct comparison of their respective outputs, providing clear insights into performance and reliability.

A Pragmatic Evaluation Framework: 

1. Specification Versioning: Treat the specification as a first-class artifact, versioning it alongside the codebase to ensure traceability and consistency.
2. Initial Implementation Generation: Generate a primary code implementation from the established specification using Model A.
3. Comparative Implementation Generation: Produce a secondary code implementation from the identical specification, employing Model B or an alternative prompting strategy.
4. Rigorous Evaluation: Subject both generated implementations to the same predefined acceptance criteria and a comprehensive test suite, all derived directly from the specification.
5. Selection and Refinement: Identify and retain the implementation that best satisfies the evaluation criteria. Continuously refine the specification upon discovering any ambiguities, thereby enhancing future model outputs and ensuring the selection of the most performant model.

Bottom Line: Specifications are the *Authoritative* Human Input for Generative Models

I’m not interested in hype cycles. I’m interested in what holds up under production pressure.

Generative AI will reduce code production time. It will not reduce the cost of being wrong. If anything, it makes being wrong easier to do at scale.

That’s why I believe specifications will become the authoritative human-produced input artifact for generative models—because they encode intent, constraints, and verification in a way that can survive model changes, team changes, and time.