Share this post
Probably today. Probably more than once. You typed in a prompt, the agent went off and worked, and it came back with a wall of text. It thought of everything — every decision, every file, every function, all baked in, ready to go. And our job? Scroll. Then choose Yes, and auto-accept edits.
So how often do you actually read that obfuscated novel — really read it, push back on it, discuss it? Or do you just let it rip? "Ready to code?" Sure. Yes, and auto-accept edits.
I'm not accusing. I do it too. Often.
This is the written companion to my latest video, where I walk through the live demo. Here I give you the full argument and the receipts behind it.
Watch the full demo on YouTube →
Why this happens
So why does this happen? I'm not accusing — let me sum up where we actually are.
In this Claude Code era, you're pushed to deliver more. Way more. Fifteen, thirty, fifty PRs a day. The marketing assistant is sending you suggestions on how to fix the code. The designer is opening PRs. It's a PR explosion, and engineering is drowning in it. Meanwhile the agents keep getting better, which only turns up the volume — more output, faster, from more directions.
So how are you supposed to keep up with all of it?
Engineers are expected to deliver more and more. And the plan you're handed is basically meta-code design — something that would make perfect sense to another LLM, but not to a human. So you trust it, and you let it code. Or you push back, and get another wall of text that's impossible to follow. This is the reality of coding in 2026.
Less model prompts, more loops
Two people worth listening to here keep making the same point. Boris Cherny, the creator of Claude Code, and Peter Steinberger, the creator of OpenClaw, are both saying the same thing: stop prompting, start building loops. Steinberger put it in a line that cleared two million views — you shouldn't be prompting coding agents anymore, you should be designing loops that prompt your agents. Cherny says it about his own work: he doesn't really prompt Claude anymore, he writes the loops, and the loops do the prompting. This is the direction the whole field is moving.
And as agentic coding moves toward loops, long-running executions, and autonomous agent work, the importance of planning amplifies and compounds. Everything the agent does for the next twelve hours is built on top of the plan you approved in the first thirty seconds.
Because the work itself is moving. Programming is dead. Software programming as a job is being eliminated, and we have to accept that and adapt. The value of engineering is shifting up to orchestration: getting the model to understand your intent, getting it to validate its own work against real acceptance criteria — the good old discipline, back under a new name — and getting all of that to actually fit your infrastructure, your codebase, and your standards, consistently. That's where engineering value lives now. Not in typing the implementation. In nailing the intent, the validation, and the fit.
And that's exactly what a wall of text you scroll past and auto-approve makes impossible. The one surface where you're supposed to lock in intent and validation is the one surface built to be agreed with, not engaged with.
The plan is the surface that matters now
So the value of the plan is becoming enormous — and the gap between a good one and a bad one is everything. I won't say the plan is the single most important thing, because a bad plan and a good plan are worlds apart; that gap is the point. What I've seen, again and again, is that the tighter the plan, the smaller the variance in what the model actually does. A loose plan gives you wildly different runs and a pile of lines to fix afterward. A tight plan collapses that variance — the executions converge, and the amount you have to correct shrinks toward nothing. The plan is the lever that turns an unpredictable agent into a far more predictable one.
And the format we're stuck with is failing exactly that. Markdown files are not efficient for human consumption. They're fine for an agent; they're a poor way to hand information to a person — which means the surface where plan quality is decided is the surface we're least able to actually read.
This isn't just my opinion. The people building these tools are openly wrestling with it — different formats, verification, and HTML as a far better way to condense information into something visual and easy to consume. The HTML idea isn't even mine — it's something Anthropic themselves have pointed to. And you can see it landing in the tools. Claude Code now ships /goal and /loop: /goal sets a persistent target — what "done" actually looks like — and /loop runs the agent across turns until that condition is met, with a fast model grading the work along the way. Together they're a self-directing, self-terminating loop, the native version of exactly what Cherny and Steinberger are describing. These two commands are worth really understanding, because they're where intent and validation become first-class.
And that's the whole game. Everything forward rests on one thing: can the agent extract the right intent from you, and extrapolate it against your infrastructure, your codebase, your best practices, and how you actually want to ship production-grade code? To get there you need the right surfaces. Your CLAUDE.md matters. The right tools and connectors — MCP, how it reads and understands the codebase first — matter. /goal and /loop matter. But the part I keep coming back to — the part I've researched before — is the plan. It's where intent and validation get set before the loop ever runs.
So I built an HTML plan
So I built one. An HTML plan that lets you plan interactively instead of approving a scroll. It surfaces things toward you in a way a human can actually consume — the goal, the intent, the architecture as a flow — and it lets you understand each part, discuss each part, and debate each part. Nothing is a wall you skim. Everything is a piece you can engage with.
I go into the full demo in the video. Here's what it actually does.
What the HTML plan actually does
I'm going to describe what it does rather than walk you through every button, because it's a work in progress — I'm updating it constantly, and the exact layout will have moved by the time you read this. What won't change is the shape of it.
It floats the important things up front. The goal, in plain language. The intent — what the agent understood you to be asking for — right at the top, before any detail. You know what you're approving before you scroll an inch.
It helps you define your intent. Not "here are the 20 files and 30 functions I'll be touching" — that's the least valuable thing it could tell me. It helps you figure out what you actually need built. I've seen skills like /grillme and /interviewme doing a version of this: the real work isn't listing what the agent will change, it's extracting what the user needs. That's so much more valuable than a manifest of files. The plan pulls that out of you, and helps you understand it yourself.
It shows you the direction it would take — mocks, back-end flows, the shape of the thing. I'm visual; reading the architecture out of a list of file paths is painful, and seeing it as a flow or a mock is instant. So you get to react to the direction, early, while changing it is still cheap.
It gives you control and boundaries. Real guardrails on what we're building — and just as importantly, what not to do. As you hand an agent more autonomy, fencing it off from the things it shouldn't touch matters as much as pointing it at the things it should. What not to build is a first-class part of the plan.
And it supports your loops. You set clear acceptance criteria and validations up front: how will the agent confirm that what it built actually works? That's the stop condition the loop needs, defined before the loop runs.
Most of all, it lets you engage with all of this in small, bite-size pieces — not as one monolithic wall. You can discuss every goal, every intent, every step, every verification output on its own. Ask for an explanation when you don't follow what the agent is saying. Challenge it. Reorder it. Iterate on one piece without swallowing the whole thing at once. It acts as a bridge between you and the model.
Put those together — intent, direction, boundaries, validation — and that's the actual job now. Orchestration and steering: aligning with the model on what's needed and what outcome we're after. This is where engineering is going, and the plan is where it happens.
A quick word for the engineers, since you'll ask: it all runs locally. It's wired up as a skill plus a small local service — easy to install, easy to run. There's even a tunnel baked in, so if you're away from your machine you can pull the plan up and review it from your phone. I'll spare you the internals because they'll change, but that's the shape: local, yours, no tokens spent to look at your own plan.
The Finalize button is still right there. You can always click it — the dreaded auto-approve, yes, and go. The difference is that now it's a real decision you're choosing to make, not the path of least resistance you fall into because reading the alternative was too much work.
I walk through a live version in the video. And to be clear, this is an experiment, not a finished product — I'll keep iterating on it.
Take it and make it your own
So here's where I've landed. The agent's research is great. The thinking is great. What was broken was the last ten feet — the surface where all that work got handed to me as a wall of text and a button. So I changed the surface.
Stop auto-approving plans you didn't read. The plan is your last cheap moment to steer the agent, and in a world of loops it's the lever the whole run pivots on. Understand it. Align with the model on it. Then pull the trigger on purpose.
It's a skill, and it's an experiment — I'll keep iterating on it. Take it, fork it, or just take the idea and build your own. The point isn't my tool. The point is that the last ten feet between you and the model deserve more than a scroll and a yes.
Key Takeaways
- Stop auto-approving plans. A wall of text you scroll past isn't a review, no matter how good the underlying plan is.
- HTML makes plans far easier to consume. Markdown is built for the agent; a visual, interactive surface is built for you.
- The plan is your last cheap moment to steer the agent. Catching a wrong assumption costs seconds here, and hours after the loop runs.
- Understand the plan, align with the agent. Intent and validation are the real work now — that's orchestration, and it's where engineering is going.
- Use my skill — take it, make it your own. It's an experiment; fork it, or steal the idea.
Stop wasting time on AI. I run practical experiments — real lessons you can use tomorrow, biweekly.
