"Continue" is a complete prompt
- ai
- agents
- autonomy
Subscribe
New essays and episodes, sent when there is something worth reading. No noise, unsubscribe anytime.
Subscribe
New essays and episodes, sent when there is something worth reading. No noise, unsubscribe anytime.
A post went past me on LinkedIn this week sorting people who work with GenAI tools into two camps. Camp one is spec driven, usually engineers: write the spec and the tests up front, then let the model execute. Camp two leads with intent, usually product people: describe the job to be done and the experience you want, let the tool plan and build, check afterwards that it did what you meant. People picked sides in the comments, and I couldn't pick one. I'd just been looking at my own chat history with the agent building my current product, and the prompts are most often the same word. Continue.
The two camps disagree about less than they think. Underneath both sits the same belief: an agent's reliability is fixed before it starts, by the quality of the document you hand it. The argument is only about which document. Spec people trust precision. Intent people trust purpose. And when an agent goes wrong, both camps reach for the same fix, which is a longer and more detailed version of their favourite document.
That fix kept disappointing me. When I read back through what my agents have actually got wrong, the misses don't cluster where the documents point. Specs get executed fine. The failures live between the requirements: whether a slow call should be cached, or which of two colliding requirements gives way. Building anything decomposes into dozens of small decisions that no document mentions, because no document could. You would be writing forever. The agent resolves each one anyway, and each resolution is defensible on its own. Defensible is not the same as aligned. Thirty defensible decisions made by something that doesn't know what the product is for is how a codebase drifts somewhere nobody chose.
So the documents I write first for a new build now decide nothing about implementation. I start with personas.md and problem.md, which say who this is for and what hurts, then vision.md, which says what should be true about the world if the build works. Then constraints.md: the architecture I'm committed to and the resource limits the build has to live inside. Only after that does the agent write the plan. It builds the feature roadmap from those files, then the technical specs from the roadmap, and both stay living documents that it revises as the build teaches us things. One standing rule sits over all of it: any time it presses up against a constraint, or makes a decision that conflicts with something written above it, it stops and tells me.
A tradeoff can't be decided from inside the task, because a tradeoff is a question about what you're willing to lose, and the task doesn't know. Purpose does. A spec can tell an agent what to do next. Only the layers above the spec can tell it what to want, and wanting is what a tradeoff runs on. Give the agent those layers and most of those small decisions stop being coin flips, because they become derivable: this user, this problem, so cache the report page and never the account balance. The agent still makes tradeoffs all day. They're just informed ones.
Armies got to this problem roughly two centuries before we did. From about 1807 the Prussian army built its doctrine around commanders who state the what and the why of an operation and leave the how to the officer on the ground, a philosophy Helmuth von Moltke pushed hard as chief of the general staff. His argument was that a favourable situation is lost by the officer who waits for orders. The idea survives today as mission command, doctrine across NATO: a subordinate learns what has to become true and why it matters, and owns the how. The point of transmitting the reason is that an officer cut off from orders can keep making decisions the general would recognise, even after the plan has stopped matching the terrain. The bet underneath the doctrine is that you can never write orders detailed enough to cover what the ground will actually serve up, so you transmit purpose instead of predictions.
A repo full of markdown files is a small, unglamorous version of the same bet, which is why I've started calling mine an intent stack. The vision sits at the top with the personas and the problem, constraints underneath, then the roadmap, then the specs. Each layer exists to answer why for the layer below it. The agent works at the bottom of the stack and reads upward, and a conflict between layers is never something it settles quietly on my behalf. It comes back to me.
There are two fair objections. The first is that this just sounds like more documentation, the chore everyone adopted agents to escape. What actually happened is that the writing moved rather than grew, and it moved up into the layers that barely change. It's the same trade I argued for in Nobody demos a text file, aimed this time at intent rather than instructions. Who the product is for and what problem it kills are the slowest-moving facts in the whole build. The specs churn constantly, and I no longer write those at all. The second objection is that a standing escalation rule means this isn't really autonomy. Mission command has carried the answer to that one for a long time: initiative is meant to be disciplined, exercised inside the intent, and an escalation is the system working rather than failing. What changed for me is what the conversations contain. They used to be the agent asking what to build next. Now they're the agent telling me that two things I wrote are in conflict. That's the cheapest review of my own thinking I've ever had.
A paragraph-long prompt is intent being smuggled in at the last second, because it lives nowhere else, and it dies with the chat window. Every word I used to type into the prompt box has a better home in some layer of the stack, where the next task inherits it without my involvement.
So spec first or requirements first is the wrong opening question. Either document can be excellent and the agent will still hit, within the hour, a decision that neither one imagined. What matters is what the agent can read when that happens. "Continue" is the shortest order a person can give, and it works for exactly as long as everything worth saying has already been said one level up.