Ten more ways to narrow the intent gap
Say it without prose, draw it out by interaction, check the reading before you pay. And how to get an assistant to interview you properly.
Acceptance criteria are one tool in a larger kit. The compact way to see the kit: the intent gap can be narrowed on three fronts. Say the intent with something other than prose. Draw it out of your head by interaction. Check how it was understood before you pay for the code. Criteria belong to the first front; each front has several more.
Say it with something other than prose
1. Examples instead of descriptions. A concrete input and its output, a mockup, a screenshot with “make it like this”, a golden file that has been approved. Each transmits intent more exactly than three paragraphs, and most exactly for user interfaces and data formats, which prose describes worst.
2. Existing code as the standard. “Like the payment module, except for X” is a dense specification: a whole set of conventions, structure and error handling passed through one pointer. This is why a clean codebase is itself an intent-gap tool. Agents imitate what they see, so what they see had better be what you want more of.
3. Types, schemas and constraints the machine checks. An API description, a protobuf definition, a strict type system, a database constraint, an invariant. Each is a piece of intent enforced by the machine instead of remembered by a person. Intent that fits in a type is never guessed wrong.
4. Tests first. Executable criteria pushed to the limit: you write the failing test, the agent makes it pass. For a bug fix this is close to a gold standard. The test that reproduces the bug is the specification of the fix.
Draw intent out by interaction
5. The reverse interview. Instead of trying to write everything, ask the agent to interview you before it starts. The reason it works is that the agent does not share your assumptions, so it asks what you would not think to ask; its naivety is the silence detector. The reason it usually fails is that most people’s first experience of it is bad questions: irrelevant ones, “what scale, which regions, what availability target” for an internal tool with fifty users, or opaque ones that make you do the agent’s job. That is the homework problem in the form of questions. Without something concrete to ask about, the model recites an elicitation template.
Three causes, in order of frequency. It has nothing specific to interview you about: give it a draft, a codebase, a brief first, then ask about that. You have not said which questions are legitimate: a good question is one you cannot answer with “your call”; if you could, the agent must decide and record its assumption instead of asking. And open questions instead of decision-forcing ones: not “how do you picture the architecture” but “does customer data have to stay in-country? If yes I drop the managed service and design for self-hosting, at roughly this operating cost; if no, option A stands.” That question takes five seconds to answer and every answer bends the design in a known direction.
The purpose of the interview, to be exact about it, is to move the information that cannot be regenerated from your head into the artifact: the real constraints (budget, the infrastructure the customer already runs, the deadline, who will maintain it), the priority when goals conflict, the history (we tried X and it failed because Y), the appetite for risk, and the real numbers rather than “millions of users”. The agent can draft everything that can be derived. Those five it has to guess unless asked, and each guess is a gap. A prompt that encodes the rules:
Prompt · the reverse interview
Here is the draft and the context. Interview me to complete the design. Rules: ask only what cannot be derived from what I gave you and what you cannot decide yourself; if you can decide, decide and record the assumption. Each question must say how the answer changes the design, as options with consequences. At most five questions, ordered by impact, one at a time. Prefer real constraints, priorities under trade-off, history and reasons, and real numbers.
Train it inside the session. When an irrelevant question arrives, say so: “this is one you can decide; do not ask this kind again.” The questions improve within the same conversation, and if you put the rules in the conventions file they persist across conversations, which is the harness idea again: good agent behaviour is designed, not hoped for. One measurement is worth keeping. After the interview, count how many of your answers changed the draft. Below half, the interview was theatre; go back to the three causes.
6. Generate and select. Because generation is cheap and you do not know what you want until you see what you do not, have the agent produce two or three variants of the ambiguous part, especially interface, flow and wording. Choose one and say why. The why is intent that was just excavated; write it into the spec or the conventions before it evaporates.
7. An early vertical slice. A thin working path through the whole stack, demonstrated, instead of a finished system reviewed at the end. Validation by exposure on the shortest cycle: the wrong direction shows up on day two instead of in week three.
Check the reading before you pay
8. Plan review. The agent’s plan is its translation of your intent, exposed before it becomes code. Fixing one line in a plan is cheaper than fixing a pull request several times. A later piece in this series is about the plan gate on its own.
9. Echo-back. The cheapest of all: “Before you start, summarise your understanding of this task in five lines and list the assumptions you are using.” Twenty seconds to read, and a drift in direction is caught at the root. The assumptions are the important half: that list is exactly the places the agent is guessing.
10. A glossary. Many intent gaps are word gaps. “Order” in the customer’s head means something different from the orders table. Twenty lines defining the business nouns, placed in the agent’s context, block a whole class of misunderstanding that no criterion can catch, because the criteria are written in the same words.
How they fit together
Conventions and a glossary as the shared base. Short criteria for what is specific to the feature. Examples and tests where prose fails. The reverse interview and echo-back for vague tasks. Plan review as the last check before code. With a second language in the loop, when the person who wants the feature and the person building it do not share one, examples and glossaries and echo-back cross the barrier better than prose does: a table of inputs needs no translation, and a vague sentence that has been translated once can come out twice as vague.
In Rindo the glossary and the conventions are pages in the project, read over MCP by any assistant that joins it, and the Guidance page is the one every assistant is pointed at before it acts.