Before an AI coding agent builds a feature, give it the intent behind the work, not just the task — the objective, the evidence that motivated it, the outcome to preserve, the edge cases that matter, what must not regress, and how it's verified. Pathmode authors that intent from real evidence and hands it to the agent at build time — so it builds toward the decision you made.
A builder gave Cursor a one-line ask: "let users filter the dashboard by date." The agent shipped a clean date-range picker. But the real need, buried in a month of support tickets, was a saved "last 7 days" default that survived page reloads. The agent built what the sentence said. The sentence had thrown away everything that made the request worth doing.
Why a one-line ask isn't enough
The ask an agent receives is a compression of a decision — and the reasoning got squeezed out. The agent can't recover what isn't in front of it, so it optimizes the literal instruction and ships something technically correct and beside the point. The fix isn't a longer sentence. It's handing over the judgment the sentence was standing in for.
What to give the agent — the checklist
- The objective. One line on what this feature is supposed to change for the user — the goal the code is in service of, not the mechanism.
- The customer evidence behind it. The tickets, quotes, and observations that motivated the work, so the agent builds toward the real pattern, not a paraphrase of it.
- The outcome to preserve. What success looks like for the user, stated plainly, so the agent has something to protect when the instruction and the goal pull apart.
- The edge cases that matter. The specific conditions where naive implementations break — empty states, concurrency, the user who already has data — named up front, not discovered in review.
- What must NOT regress. The behavior, performance, or guarantee that's allowed to stay exactly as it is, so a locally correct change can't quietly break the larger goal.
- How it's verified. The concrete check that proves the outcome held — a test, a manual path, an observable signal in production — so "done" means "right," not "merged."
Give it the outcome to preserve, not just the file to edit.
The tradeoff vs a detailed prompt
A detailed prompt can carry a lot of this — and for throwaway work, a script, a spike you'll delete, it's the right tool. The break comes when the instruction and the outcome conflict. A prompt is still judgment compressed into instructions, and when the agent has to choose between following the wording and protecting the goal, a prompt gives it no way to know which one wins. Intent makes the outcome and the non-negotiables explicit, so the right call is already in the agent's hands.
Frequently asked questions
- Isn't a well-written prompt enough?
- For disposable work, yes — a prompt is fast and good enough when the output won't be maintained. It breaks when the instruction and the real outcome conflict, because a prompt only encodes what to do, not which goal to protect. That's exactly the moment agents ship correct-but-wrong code.
- What's the single most important thing to include?
- The outcome to preserve. The objective and the task tell the agent what to build; the outcome tells it what success means, which is what it needs when an implementation choice could satisfy the instruction while missing the point. Everything else on the checklist exists to keep that outcome intact.
- Where does the evidence come from?
- From inputs you already have — support tickets, user interviews, observed friction, usage metrics. Pathmode assembles that into an IntentSpec the agent can read at build time, so the "why" travels into the build instead of staying in someone's head.
- Do I have to write all six parts every time?
- No. Small, reversible changes need less; anything users depend on needs the full set, especially "what must not regress" and "how it's verified." The point isn't ceremony — it's making sure the judgment behind the work reaches the agent before it starts writing code.