Specifying Intent Precisely Enough to Delegate

Specifying Intent Precisely Enough to Delegate is the writing skill that decides how much of your judgement survives the trip into someone else's hands. Those hands may belong to a model or to a new hire, and the requirement turns out to be the same. What you cannot state precisely, they will guess, and the guess will be plausible.

Key takeaways

• A specification is a contract about behaviour, not a description of implementation, and its value is that it outlives the code generated from it. GitHub's Spec Kit, released 2 September 2025, is built on exactly that inversion: the spec is the source of truth and the code is regenerable output.
• Ambiguity is a defect class with a measurable symptom. Stack Overflow's 2025 survey, with 49,034 respondents, found the largest single frustration at 66% was AI solutions that are almost right but not quite.
• Six things must be fixed before delegation is safe: the trigger, the observable outcome, the data contract, the failure behaviour, the non-goals, and the acceptance check. A missing one produces a specific, predictable defect rather than general confusion.
• Non-goals are the cheapest section to write and the most frequently omitted. Anything you do not exclude will be built, because both a model and an eager new hire treat silence as permission.
• Anthropic's March 2026 index reports prompt sophistication rising with user tenure, and that its most advanced users are more likely to iterate than to delegate a task entirely, drawn from 1 million conversations sampled 5 to 12 February 2026 on its own platform.

Read this after Chapter 5, because specifying well is how you delegate more without handing over the diagnosis, and before Chapter 7, which is what happens when the work comes back. Keep the two apart in your head: this chapter is about fixing intent before the work, and Chapter 7 is about judging work that already exists.

Two engineers are given the same sentence: "let users export their invoices".

The first spends fifteen minutes and produces a working export by lunch. It exports all invoices the user can see, as one CSV, synchronously, with dates in the server's locale, and it times out for the three accounts that have more than forty thousand invoices.

The second spends fifty minutes writing down what the export is for, which invoices are in scope, what happens above ten thousand rows, what the date format is, and what should happen when the request fails halfway. Then an agent builds it in eight minutes. The details here are composited from ordinary product shapes rather than one system, and the shape is exact.

A specification is a contract about behaviour

Definitions first, because the word is used for three different documents.

A specification, in the sense this chapter means, is a written statement of what the system must do, observably, from outside. It is not a design document, which describes how. It is not a ticket, which describes a desire. It states behaviour precisely enough that two competent builders working separately would produce systems that pass the same tests.

That last clause is the test for whether you have written one. If two builders could reasonably produce different observable behaviour from your document, the document is not finished.

The inversion worth internalising is about durability. Code generated from a good specification is cheap to regenerate, and the specification is expensive to reconstruct from code. So the specification is the asset, and treating it as paperwork gets the value the wrong way round.

Ambiguity is a defect class, and it has a measurable symptom

The reason this matters more than it did is visible in one survey figure.

Stack Overflow's 2025 Developer Survey, with 49,034 respondents, found the largest single frustration with AI tools, named by 66%, was "AI solutions that are almost right, but not quite". Read that as a specification statistic rather than a model statistic. Almost right is the signature of a system that understood most of the intent and filled the rest with a reasonable default.

Some of that is model limitation and some of it is not. In my experience the majority of "almost right" output I have seen traces to something the request never said, which means it is recoverable by writing rather than by waiting for a better model.

There is a supporting observation from the other side of the interaction. Anthropic's March 2026 index reports that prompt sophistication rises with user tenure, and that its most advanced users are more likely to iterate than to delegate a task entirely. The sample was 1 million conversations, drawn between 5 and 12 February 2026. That is vendor platform data about its own users. It is still the shape you would expect if precision of instruction were the skill being learned.

What Spec Kit's shape tells you about the job

GitHub released an open-source toolkit on 2 September 2025 for what it calls spec-driven development, and the interesting part is not the tool.

Its framing is that the specification is a contract for how code should behave, and that it becomes the source of truth an agent uses to generate, test and validate. The workflow it enforces has three stages: the specification, then a technical plan, then a decomposition into small testable tasks. It is MIT-licensed, ships as a command-line tool with templates and prompts, and supports several coding agents.

The structure is the argument. Somebody had to decide that intent, plan and task decomposition are three separate artifacts rather than one prompt, and that ordering is what makes generated work reviewable at all.

Which is why I would learn the shape whether or not you adopt the tool. A specification that does not decompose into small testable tasks is a specification you cannot check, and a plan bundled into the intent is a plan nobody can disagree with separately.

Six things to fix before you delegate

This is the part that is judgement rather than citation, and it is the most directly usable thing I have to offer in this chapter.

In my experience the failure order is consistent: data contract first, failure behaviour second, non-goals third. Trigger and outcome are usually stated because people find them easy to imagine, and the other four are where the rework lives.

Acceptance criteria are the part that cannot be vague

Of the six, one carries more weight than the others and is the most commonly faked.

An acceptance check is not "works correctly". It is an observation someone can make. Given an account with forty thousand invoices, a request returns within thirty seconds or returns a job identifier. Given a date in December, the exported value is the customer's date rather than the server's. Given a network failure midway, no partial file is delivered and no invoice is marked exported.

Notice what those have in common. Each names an input condition, an observable output, and a boundary. That is the same structure a test has, which is not a coincidence: acceptance criteria are tests written before anybody knows how the code will look.

The discipline that keeps them honest is writing them before the work rather than after. Written afterwards, they describe what was built. That is not acceptance, it is transcription.

Write the non-goals, or they get built

Non-goals are the cheapest section in a specification and the one people skip.

The mechanism is simple. Anything you do not exclude gets built, because a capable delegate treats silence as permission and adds what seems helpful. An agent will add pagination you did not ask for, a new hire will add a config flag, and both will be proud of it.

The cost is not the extra code. It is that unrequested scope arrives with no specification, so it cannot be reviewed against anything, and it then has to be maintained. That is how a two-day feature acquires a permanent surface area.

So write the boring exclusions. Not exporting attachments. Not supporting other formats yet. Not changing the existing endpoint. Three lines that save a week.

Why the same document serves a machine and a new hire

The claim that one document does both jobs sounds like a convenience and is actually the underlying point.

A new hire and a model fail in the same place for the same reason. Neither holds your context, both are capable, both will produce something plausible from an incomplete brief, and neither will tell you which assumption they made unless the document asked them to. The remedy in both cases is stated behaviour, stated boundaries and a stated check.

There is one difference worth designing for. A new hire will ask you a question when the specification is ambiguous, and a model usually will not. That makes the writing matter more, and it makes the missing-question a signal: if a delegate never asks anything about a document, either the document is very good or nothing is being checked.

DORA's 2025 report frames AI as an amplifier of what an organisation already has, and a specification is where the amplification is decided. Precise intent amplifies into work you can accept. Vague intent amplifies into volume you have to sort through.

The objection: this is waterfall with a new name

The strongest form of this objection is worth stating properly, because it is not stupid.

It runs like this. Big up-front specification was tried, it failed, and it failed for reasons that have not changed: requirements are discovered by building, not before, and a document written in advance encodes assumptions that the first week of work invalidates. Anybody who lived through a signed-off requirements phase is entitled to flinch.

The answer is scope of commitment rather than volume of documentation. What is being specified here is one unit of delegable work, sized in days, and the document is disposable once the behaviour is accepted and captured in tests. Waterfall specified the whole system before any of it existed, and specified implementation as well as behaviour, and treated the document as a contract between parties rather than as an instruction to a builder.

There is also a practical rebuttal. Under-specified delegation is not faster, it is just differently slow: the cost moves from your keyboard into the review queue and into the incident that follows. Chapter 7 is that cost, measured.

Chapter summary

A specification in the sense that matters is a written statement of observable behaviour, not a design and not a ticket, and the test is whether two competent builders working separately would produce systems that pass the same checks. Code generated from a good specification is cheap to regenerate, while a specification reconstructed from code is expensive, so the document is the asset. Ambiguity is a defect class with a measurable symptom. Stack Overflow's 2025 survey of 49,034 developers found the largest frustration, at 66%, was AI solutions that are almost right but not quite, which is the signature of intent that was mostly understood and partly defaulted. GitHub's Spec Kit, released 2 September 2025, makes the shape explicit by separating specification, technical plan and small testable tasks, and that separation is what makes generated work reviewable. Six things must be fixed before delegation is safe, being the trigger, the observable outcome, the data contract, the failure behaviour, the non-goals and the acceptance check. In my experience the omissions run in a consistent order, with data contract first. Acceptance criteria have to name an input condition, an observable output and a boundary, and they must be written before the work rather than transcribed after it. Non-goals are the cheapest section and the most often skipped, because a capable delegate treats silence as permission. And one document serves both a model and a new hire, since neither holds your context. Only one of them asks you a question.

Chapter 7 is Reviewing Work You Did Not Write. Specification decides how much judgement travels into the work; review is where judgement is applied to work that already exists, and it is now the scarce hour in the pipeline rather than a courtesy at the end of it.