Kiro's steering files solve a real problem — a constitution kept short enough to stay in context can't cover every situational rule a codebase needs. Steering files are where that detail goes.

A hands-on walkthrough of GitHub's open-source Spec-Kit — the constitution, and the specify → plan → tasks → implement workflow that turns a coding agent into a disciplined collaborator.

A blank page is the biggest friction point in getting engineers to actually write specs. Four templates covering the change types that come up most, ready to copy.

"Are we actually doing spec-driven development, or just saying we are" needs a measurable answer, not a vibe check at a retro.

A byproduct of spec-driven development that doesn't get enough credit — specs written as durable, checkable artifacts are also a genuinely good onboarding resource, if you use them that way deliberately.

A spec stored in a wiki or a separate docs tool decouples from the code it describes, and that decoupling is exactly what makes drift invisible. Specs belong in the same repo, same commits.

Letting an agent draft the spec from a rough description is faster than writing it by hand. It also risks the agent filling ambiguous gaps with its own assumptions instead of flagging them.

Every spec-driven development example assumes you're building something new. Migrating an existing system needs a spec that documents current behavior before it can specify the target one.

Vibe coding is genuinely great for prototypes and genuinely dangerous for production. Here's why agentic coding agents specifically need a persistent spec, and what changes when you give them one.

If the spec already states acceptance criteria as checkable conditions, most of the test suite should be mechanically derivable from it — not written separately, after the fact, by memory.