Home / OrangIT Blog / Requirement Specification is the New Black
Requirement Specification is the New Black
Written by Tea Kauppinen, Team Lead at OrangIT
AI assistants like Claude and GitHub Copilot are incredibly powerful, but they’re also dangerously eager. To me, they feel like fresh-out-of-school junior developers: enthusiastic, fast-moving, and brimming with potential, but sometimes breaking more than they fix.
The problem isn’t the AI itself. It’s us. Most of us are simply not very good at telling machines exactly what we want. We toss in vague prompts, assume the AI “knows what we mean,” and then feel disappointed when the results don’t line up with our expectations. If this sounds familiar, it’s because we’ve been here before.
Back in the waterfall era, requirement specifications were the backbone of successful projects. They weren’t glamorous, but they were essential. The better the specification, the better the outcome. That lesson hasn’t aged a bit; in fact, with AI, it’s more relevant than ever.
Why Structure Matters for AI
AI thrives on structure. It doesn’t do well with half-formed intentions or fuzzy goals. The clearer the boundaries and expectations, the sharper and more useful the results. That’s why I believe we’re witnessing a quiet comeback of something that once felt old-fashioned: requirement specifications, design documents, and detailed contracts. These aren’t relics of a bygone era. They’re the foundations of a new way of working with AI.
Some people call this contract-based prompting : treating prompts less like casual suggestions and more like agreements that spell out exactly what the AI should deliver. And it’s not as bureaucratic as it sounds. In fact, I’ve found it liberating. By forcing myself to clarify what I want, I save myself from endless rounds of rework.
This actually isn’t too different from something developers have known for a long time: test-driven development. The discipline of writing tests before code forces us to articulate what “done” looks like before we begin building. It’s a little slower at the start, but the payoff is enormous: less confusion, fewer surprises, and more reliable outcomes.
From Prompts to Agreements
What if we applied the same mindset to working with AI? Imagine telling your assistant, “Don’t just give me an answer. Ask me questions until you’re at least 90% confident you know what I want. Then generate your output and check it against the criteria we agreed on.” Suddenly, the AI isn’t just guessing at my intentions, it’s helping me clarify them. It becomes a collaborator in the process of specification, not just a generator of outputs.
I’ve experimented with this in practice. I’ll start by drafting requirements with the AI, letting it interrogate my assumptions and poke at the edges of my idea. Then I’ll ask it to help define “acceptance tests” — conditions that any solution should satisfy. Once we have that shared understanding, I let the AI generate a draft. More often than not, the result is dramatically closer to what I actually need. It feels a lot less like gambling, and a lot more like building.
When I stumbled upon Nate B. Jones’ video on contract-based prompting, the light bulb really went on. I realized that what I’d been fumbling toward in practice already had a name, and a community of people thinking about it. Nate articulated the idea in such a clear way that it helped me frame what I had been doing all along: not just writing prompts, but writing agreements.
The Quiet Comeback of Specifications
The big takeaway? Requirement specifications were never outdated. They were simply waiting for their renaissance. In the age of AI, they’re not just helpful — they’re the difference between chaos and clarity.
So I’ll leave you with a question: how do you work with AI today? Do you take the time to clarify, specify, and test what you want, or do you still throw in a few loose instructions and hope for the best?
Originally published at https://www.linkedin.com.