Blog
-
Opus 5 feels worse because it stopped asking. Give it somewhere to ask.
A widely shared post says Opus 5 feels like a downgrade: better execution, higher benchmarks — and bold assumptions where earlier models paused to ask, so drift happens more. The fix isn't a different model; it's a workflow where asking costs nothing. Anchored to a plan, the bold model is the best one yet.
-
The 70–90% token saving your chat window won't let you have
The viral checklist quoting Karpathy says most AI-coding spend is waste — and its tip #9 (batch ten small questions, save 70–90%) is the one a linear chat can't follow. Anchored comments make batching structural.
-
Plan drift: why the model that planned it isn't the model that builds it
Plan with your best model, build with a faster one — and the build comes back subtly wrong. The planner's implicit reasoning didn't survive the handoff. The fix isn't a better model; it's a plan explicit enough to cross it.
-
Engineer the graph, not just the loop
After loop engineering comes graph engineering: wiring specialized agents into a topology of nodes, edges, and human checkpoints. Tools like ORCA make it hands-on. But a graph has to be a graph of something — the nodes, dependencies, and checkpoints you draw are a plan.
-
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.
-
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.
-
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.
-
Claude Opus 5 is a big jump — and it makes the plan matter more
Opus 5's biggest agentic-coding gains land on the hardest tasks, "with far less variance run to run." That's the case for planning, not against it: the model cuts execution variance, but only a plan cuts intent variance. Point its stronger loop at a decided target.
-
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.
-
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.
-
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.
-
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.
-
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.