Blog
-
Spec Kit, Kiro, inplan: three shapes of spec-driven development
GitHub's Spec Kit, AWS's Kiro, and inplan all start from the same premise — the spec is the source of truth — but optimize different parts of the loop: artifact scaffolding, an integrated IDE, and the human⇄agent conversation that resolves the plan. An honest map, so you can pick the right one or combine them.
-
Claude Code's plan mode is great. Then what?
Plan mode is the best habit in agentic coding — a plan before code. But then the plan is a text blob you approve: no comment on a line, no threaded answer from the agent, no teammate review, and it evaporates after the session. The plan is a conversation, not a keystroke.
-
Spec-driven development needs a plan you can argue with
Spec-driven development makes the spec the source of truth — but most tooling optimizes generating the spec and leaves the harder half thin: the human⇄agent conversation that decides what it should say. A spec is a pile of decisions; inplan is where you resolve them together.
-
The human in the loop is tired of reviewing
The human-in-the-loop exhaustion is real — the satisfying part of coding got automated, leaving unbounded review of mostly-correct output. But the tiredness has a location: it's downstream. Move the judgment upstream — resolve the decisions once in the plan — and the review shrinks to the part worth staying awake for.
-
The same plan, the same result
LLMs are non-deterministic — the same prompt run twice gives you two different programs. A concrete, detailed plan collapses the space the model samples over, so the agent reproduces nearly the same result every run: easier to debug, consistent quality, far less dependent on who's driving.
-
Your plan is a harness
Harness engineering — the scaffolding around a model that makes its output reliable — turns out to be the same work as thorough, collaborative planning. A resolved plan supplies the constraints, acceptance, and context a harness does. It is one.
-
Engineer the loop, not the prompt
Loop engineering says the unit you optimize is the loop, not the prompt. But Andrew Ng's developer feedback loop — where judgment becomes specs and evaluation criteria — is exactly what a plan is: the loop's memory, validation, and exit conditions, kept alive against drift.
-
A one-liner builds the minimum. A plan builds the app.
We re-ran all four of the build-off's apps — calculator, Conway's Life, Rubik's cube, raycaster — same model, one-liner vs a plan that spells out the real feature set, with the plan and the rubric written double-blind. The one-liner delivered 11–67% of the app; the plan delivered 63–91%.
-
A plan for the page
Planning-first isn't only for code. A novelist, an investigative reporter, and a game's narrative designer use the same shared document — an AI drafts and raises open questions in parallel threads, and they decide in place before committing to the page.
-
One document, three jobs
A developer, a product manager, and an architect work the same planning document three different ways — settling the implementation, product, and structural questions before a coding agent writes a line. Three concrete stories.
-
All you need is more thorough planning
Coding agents write fast and guess wrong — quietly. We put it to the test on a checkout pricing engine: same prompt, same agent, first-pass correctness went from 4/8 to 8/8. Why planning first is how you ship it right, and about 30% faster overall.
-
Your coding agent doesn't need a better model. It needs a better plan.
Agentic coding's real bottleneck isn't the model — it's shared understanding. Why planning is the highest-leverage thing you can do with a coding agent, and what "planning" actually means in this era.