AI coding agents are getting good at writing code. Too good, in some ways. Hand one a vague prompt and it'll build you something - probably the wrong something, but it'll do it fast and with confidence.
The problem isn't the code. The problem is what happens before the code gets written. Agents guess. You say "build me a login system" and the agent picks password rules, session lengths, error handling approaches. It makes fifty tiny decisions you didn't know needed making. Then you test it and realise half those guesses were wrong.
A new tool called spec-writer attacks this differently. Instead of letting agents dive straight into code, it forces you to write a specification first. Proper structured requirements. The kind of thing humans skip because it's tedious.
Here's what makes it interesting. The tool doesn't just ask for a spec - it flags every decision point inline. Password length? Flagged. Session timeout? Flagged. What happens when someone forgets their password? Flagged. You can't move forward until you've made those calls explicit.
Why This Matters Now
The better AI agents get at coding, the more dangerous implicit requirements become. A human developer will ask clarifying questions. An agent will just... decide. And because the code works (technically), you won't notice the problem until it's deep in production.
This isn't theoretical. Developers using AI agents report the same pattern: fast first draft, slow rewrite cycle. The agent built the wrong thing confidently, and now you're unpicking assumptions baked into the architecture.
Spec-writer tries to surface those assumptions before they become code. It's procedural - almost annoying in how thorough it is. But that's the point. The tedium is the feature.
What It Actually Does
The tool generates a structured specification document before any code gets written. Think of it as a checklist that won't let you skip questions. For a login system, it'll ask about password complexity rules, session management, multi-factor auth, account recovery flows, rate limiting on failed attempts.
Each decision gets documented. Not in prose - in structured data that an agent can read. When you hand that spec to a coding agent, it's not guessing anymore. It's implementing explicit requirements.
The win isn't just fewer rewrites. It's surfacing the cost of decisions early. When you see all the edge cases written out, you might realise your "simple login system" has thirty decision points. Maybe you don't need all of them. Maybe you adopt a standard (OAuth, Passkeys) instead of building custom. The spec makes that conversation possible before the code exists.
The Larger Pattern
This connects to something broader. As AI gets better at execution, the value shifts to specification. Knowing what to build matters more than knowing how to build it. We've heard that before, but spec-writer makes it concrete.
For developers, this is a workflow shift. You don't start with code anymore. You start with questions. The annoying, tedious, clarifying questions that used to feel like overhead. Now they're the actual work.
For businesses, it's a forcing function. Who decides the password rules? Not the developer, not the agent - someone with context about user needs, security posture, regulatory requirements. Spec-writer makes it obvious when those conversations haven't happened yet.
There's a deeper implication here about AI tools in general. The sharper the tool, the more damage a vague input can do. A blunt tool forces you to be careful. A sharp tool will confidently execute your half-formed idea and give you exactly what you asked for - which is rarely what you needed.
What This Means for Builders
If you're using AI agents to write code, this is worth trying. Not because the tool itself is significant, but because it makes explicit a problem most people haven't named yet. Agents don't ask questions. They fill in blanks.
The more you rely on agents, the more you need something like this. A structured way to surface assumptions before they become technical debt. A forcing function that makes you think through decisions while they're still cheap to change.
It's not glamorous. It's procedural, methodical, slightly tedious. But that tedium is what stops you rebuilding the same feature three times because the requirements were vague and the agent was confident.
The future of AI-assisted development probably looks more like this - less "write me an app" and more "here's a 47-point specification, implement section 3". That's not a worse future. It's just a different skill. Learning to specify well is learning to work with sharp tools safely.