Use raw prompts for disposable work and exploration. Use a repo-bound IntentSpec when the decision must survive another session, builder, branch, or review. Pathmode helps an agent draft and preflight intent.md; a human authorizes the product judgment; the coding agent then builds against the same versioned objective, outcomes, boundaries, and checks.
A builder opened Cursor and typed: “refactor the checkout flow to use the new pricing API.” The agent did it quickly. The next morning a different builder asked another session to “clean up the checkout flow,” and the agent undid a behavior the first change was meant to protect. Both prompts were reasonable. Neither session had a durable statement of the product outcome.
What a prompt is good at
A prompt is immediate. That is a feature, not a defect. Use one when:
- The output is disposable — a data fix or script you will run once.
- You are exploring — learning what is possible before committing to a direction.
- The change is small and reversible — the consequence of a wrong assumption is low.
- Speed to first output is the goal — nobody needs to maintain the reasoning later.
For that work, formalizing intent may be overhead with little payoff.
Where a prompt stops carrying enough
The weakness appears when the decision must survive beyond the current turn. A prompt may contain excellent reasoning, but it is usually bound to one conversation. A second agent, reviewer, or branch may see only the resulting code and a new instruction.
intent.md gives the decision a stable address in the repository. An agent can draft it, a human can authorize it, and every later implementation session can read the same objective, outcomes, constraints, edge cases, and checks.
Prompts steer a turn. Repo-bound intent governs maintained work.
Raw prompts vs repo-bound intent
| Raw prompt | IntentSpec in intent.md | |
|---|---|---|
| Best fit | Disposable or exploratory work | Maintained, consequential product work |
| Authority | Current conversation | Versioned repository artifact |
| Product judgment | Often implicit in the instruction | Explicitly reviewed and authorized |
| Continuity | Must be re-explained | Travels with the branch and code |
| Verification | Whatever the prompt requests | Concrete checks recorded before implementation |
| Private evidence | Usually omitted or pasted ad hoc | Referenced from the file; retained privately when connected |
The choice is not “vibe coding bad, specs good.” Ask whether the product decision needs to remain true tomorrow. If it does, give it a durable, reviewable home before asking an agent to build against it.
Frequently asked questions
- When are raw prompts the better choice?
- When the output is disposable, the change is small and reversible, or you are exploring before making a product decision. A one-off migration script or prototype usually does not need a durable intent artifact.
- Can't I just keep my prompts in a file and reuse them?
- Yes, and that may be enough. intent.md adds a shared structure for the product decision, including observable outcomes, hard constraints, edge cases, and verification. It is also designed to be reviewed and versioned with the code rather than replayed as an instruction.
- Does Pathmode slow me down compared with vibe coding?
- For consequential work, it adds a brief drafting and review step before implementation. The tradeoff is continuity: later agents do not need the decision reconstructed from old prompts, and reviewers can inspect what authorized the change.
- How does the agent receive the intent?
- The decision lives in intent.md in the repository. Pathmode's MCP server reads that file in local mode and can enrich it with private team context in connected mode. The repo remains the authority for the implementation session.