Which engineering goals can you state well enough to hand to an agent run, and which can you not?
answer
- Does the criterion exist yet?
- Acceptance apart from the implementation
- Contested, undiscovered, or only recognisable
- Pay to make intent statable
basics
~20 sA goal is statable when its acceptance exists apart from the implementation. Where acceptance is what the work discovers, or two teams disagree what done means, no wording fixes it — settle it first, or run to learn and discard.
solid answer
~50 sThe retry work is statable: I can say what must be observably true about a rejected payload without having written a line of it. Three shapes resist statement. One, the acceptance is the output — "work out how this receiver behaves when it is struggling" — where any criterion I write presupposes the answer. Two, the definition is contested: my team and the receiver's team mean different things by delivered, and a request cannot settle a disagreement between owners. Three, the criterion is recognition rather than description, where I will only know what I wanted when I see it. The lead's call is not agent or no agent. It is whether to pay for making intent statable — write the acceptance, settle the definition — or do the unstatable part myself, or spend a run I am willing to throw away precisely to learn what the acceptance should say.
go deeper
Notice when you cannot say what finished looks like. That is a signal to go and find out — ask the team that owns the other side, or read the contract — rather than to write a longer request and hope.
Distinguish a criterion that is missing from one that is unknown to you. A bound you can look up is statable once someone asks; a definition two teams disagree about is not, however carefully you word it.
Show that you can recognise an unstatable goal before spending a run on it, and that your response is to produce the criterion — an investigation, a conversation — rather than to iterate on wording.
Own the cost comparison: what you pay to make intent statable, what you pay to do the unstatable part yourself, and when a run you intend to discard is the cheapest way to learn what the acceptance should say.
## Statable means the acceptance exists apart from the implementation A goal is statable when you can say what must be observably true when it is finished **without having written it**. Adding a retry policy to the parcel-tracking service's outbound webhook sender qualifies: a delivery the receiver rejected as malformed is never retried, a delivery that got no answer is retried to a bound, an exhausted event is recorded where an operator will find it. Every one of those was true as an intention before any code existed. That is the property, and it is worth naming because it is the thing an unstatable goal lacks. Not size, not difficulty, not novelty — plenty of large, hard, novel work has perfectly crisp acceptance. What makes a goal unstatable is that **the criterion is not available to you yet**. ## Three shapes that resist statement 1. **The acceptance is the output.** *Work out how this receiver behaves when it is struggling, and design around it.* Any acceptance you write presupposes the answer you are trying to find. The deliverable is a decision, and a decision cannot be its own criterion. 2. **The definition is contested between owners.** Your team counts a delivery as delivered when it is handed off; the receiving team counts it when it is processed. A request cannot settle that, and whichever meaning you write down produces work the other team will reject. The obstacle is organisational, and no amount of wording moves it. 3. **The criterion is recognition, not description.** Some goals — the shape of an interface, how an operator's view should read — you can only judge on sight. You are not withholding the criterion; you do not have one in a transmissible form. A fourth case looks like these and is not: a goal whose non-negotiables exist but live outside your knowledge, in a downstream contract nobody wrote down. That is statable as soon as someone goes and asks. **The test is whether the criterion exists and needs fetching, or does not exist yet.** | the goal | is acceptance available before the work? | what that implies | |---|---|---| | add a retry policy with named failure classes | yes | state it; the run is measured against it | | find out how the receiver behaves under load | no — the finding is the deliverable | do it yourself, or run to learn and discard | | make delivery mean the same thing to both teams | no — it is contested, not unknown | settle it between owners first | | design how the operator's view should read | no — you will judge it on sight | expect to iterate on shape, not to specify it | | match the bound to the downstream contract | yes, once someone asks | fetch the fact, then state it | ## The choice a lead is actually making The interesting part is not "hand it over or don't". It is **what you are willing to pay to make intent statable.** Writing acceptance criteria, or getting two teams to agree what delivered means, is real work — and it is work whose value does not depend on who writes the code afterwards. That is why the answer is rarely *keep this away from the agent*: you were going to need the criterion for the reviewer, the test, and the on-call engineer regardless. So the honest framing is a comparison of costs: - **making intent statable** costs a conversation and a document, and pays back everywhere it is used afterwards; - **doing the unstatable part yourself** costs your time, and produces the criterion as a by-product; - **handing over an unstatable goal** costs you a plausible result you cannot grade — the worst of the three, because it looks like progress. ## The run you are willing to discard There is one more option, and it is a deliberate choice rather than a failure: **spend a run you intend to throw away**, to find out what the acceptance should say. This is a reasonable choice when stating intent is expensive and an attempt is cheap, and it has one hard condition — you decide *in advance* that the output is information rather than a change. A run begun as an experiment and kept because it looked fine is how an ungraded result gets merged. ## How you would know you called it wrong The signal is in what the corrections are about. If round after round of correction is about **how** the work was done, the goal was statable and your request was simply thin. If the corrections keep being about **what done means** — you keep discovering the criterion by looking at output — the goal was not statable and no rewording was ever going to fix it. That is the moment to stop editing the request and go settle the decision.
- Is an unstatable goal an argument against using an agent at all?Rarely. It is an argument for doing the part that produces the criterion first — the investigation, or the conversation between two teams — because you need that criterion for the reviewer and the on-call engineer whoever writes the code. What follows it is usually statable.
- How do you keep a run you meant to discard from being merged because it looks fine?Decide before starting that the output is information, and say so where others can see it. A plausible result you cannot grade against a criterion is exactly what the exercise was meant to produce, and it is not made gradable by looking reasonable.
- Two teams disagree on what delivered means. Why can the request not simply pick one?It can, and the work will then be rejected by whichever team was not consulted. The disagreement is about ownership rather than wording, so a request that settles it unilaterally hides a decision that needed both signatures.
saying these in an interview costs you the question
- Any goal can be stated clearly enough with sufficient effort
- If the wording keeps failing, write a longer request
- An exploratory goal just needs a more open-ended request
- Acceptance criteria are for the reviewer, not for the run
- A result that looks reasonable can be kept whatever the run was for