Deep dive
AI-assisted engineering through spec-driven development
How AI fits into disciplined engineering: design intent made explicit in specifications, the tool used to challenge and accelerate the work, and verification and accountability kept with the engineer.
Premise
AI became part of my daily engineering workflow, but the useful shift was not faster code generation. It was moving more design intent into explicit specifications that could be challenged, implemented, reviewed, and verified systematically.
When AI-assisted work goes wrong, it usually starts before any code exists: the requirement was vague, and the tool filled the gaps with plausible guesses. Engineers under time pressure do the same. Writing the intent down closes those gaps for both.
The practice
01Start from a specification
Before implementation, a vague requirement becomes an explicit engineering artifact. A useful specification captures:
- Intended behavior
- Constraints and assumptions
- Interfaces
- Edge cases and failure scenarios
- Acceptance criteria
It doesn’t need to be long. It needs to be specific enough that two implementations built from it would behave the same way, and that someone could tell whether the result is correct.
02Use AI as a reasoning partner
The tool is at least as useful around implementation as in it: challenging the assumptions in a spec, finding edge cases I missed, laying out implementation options, investigating a failure, reviewing a change, tightening documentation, or checking whether I really understand a piece of code.
Used that way, it’s a fast second opinion. It is still an opinion.
03Implementation is not architecture
AI can accelerate implementation. It shouldn’t own the architecture, have the final say on design, or settle the tradeoffs. Those depend on context the tool doesn’t have: the organization’s constraints, the system’s history, what it will cost to operate, and what the team can support.
Faster implementation only helps when the shape of the system was decided deliberately first.
04Verification remains mandatory
Generated code is untrusted until it’s verified, and it earns some extra scrutiny: it reads as confident whether or not it’s correct. It’s verified the usual ways — tests, review, static analysis, runtime behavior — and checked for architectural fit and security implications before it goes anywhere near production.
Whoever merges a change owns it, regardless of who — or what — wrote the first draft.
05Keep durable sources of truth
Decisions made in a conversation with a tool disappear with the conversation. The source of truth stays in the specification, the code, the tests, and the documentation, where the next engineer — or the same one six months later — can find it, question it, and change it.
If a session produces a decision that matters, it gets written into the spec or the docs, not left in the chat history.
The principle
The tool can accelerate the work. Architecture, verification, tradeoffs, and production accountability still belong to the engineer.