A coding agent builds something every time you ask it to. Whether it builds what you intended is decided in the specification, and three levers raise those odds: functionality with verification criteria, quality standards, and architecture context. Each one closes a gap the agent would otherwise fill with a guess.
This piece expands the “Reflections On The Mission” section of our June 2026 On A Mission newsletter, From Tokenmaxxing to Outcomes. It adds a worked example and a short set of questions you can put to your own specifications.
Why a coding agent always builds something
A coding agent has no setting for “I am not sure what you mean”. Ask it for an app that sends an email or an SMS depending on each user's preferences and you will get one. The newsletter used exactly this example, and it is a good one because the delivered app really does work.
The trouble starts with everything around the app. You may also get a whole notification system written from scratch, because nobody told the agent that your organisation already runs one. An agent can only act on what sits in its context, so a service that exists elsewhere in your estate is invisible to it unless the specification points to it. That is our own reasoning from the newsletter's example, and it follows from how agents work with the context they are given.
The output can still look perfectly reasonable in a pull request. It compiles and it sends messages, yet it duplicates a service you already pay to run. So the useful question is how often the output matches your intent, and agentic engineering is the work of raising that probability. The specification is where most of that work happens, through the three levers below.
Lever one: functionality and verification criteria
The first lever is a clear description of the behaviour you want, with verification criteria attached to it. For the notification app, that means saying which channel a user gets when both are enabled, what happens when a user has set no preference, and how someone would check that the right message went to the right place.
The criteria carry as much weight as the description. Without them, “working” means whatever the agent decided it meant. A check that a person or a test suite can run gives the agent a definition of done that it did not have to invent.
Lever two: quality standards inside the specification
The second lever puts your coding standards and quality gates into the specification itself. An agent that has not been told your standards writes to its own, and those may differ from the ones your reviewers apply. Standards that live in a wiki the agent never opens are, for the agent, the same as standards that do not exist.
Quality gates belong here too, such as lint rules and test requirements. Writing them into the spec means the agent builds towards them from the first line. The alternative is to discover the gap at review, when the cheapest moment to fix it has passed.
Lever three: architecture context so the agent reuses what exists
The third lever gives the agent your architecture diagrams and service descriptions. This is the lever that addresses the duplicated notification system directly. If the specification includes a description of the notification service you already run, the agent can call it. If it does not, the agent builds another, and you pay for the same service twice.
Duplication is also a maintenance problem. Two notification systems mean two places to fix a bug and two sets of behaviour that can drift apart. The second one saves little, and the team inherits it.
Software 3.0 and why the specification is the program
Andrej Karpathy calls this shift Software 3.0. In his framing the LLM is a new kind of computer, and the contents of its context window are its programming language. The newsletter's conclusion follows directly: a detailed specification is the program.
Taken literally, that gives each lever a clear job. The first says what the program must do, and the other two say how it must be written and what it must connect to. A program that leaves any of these out gets completed by the machine running it, which is exactly the behaviour you saw in the email and SMS example.
Coding standards and architecture diagrams usually exist already, so none of this is exotic. The change is that a new kind of reader now needs them, and that reader cannot ask a colleague down the corridor what was meant.
How MISSION+ writes the three levers into the spec
At MISSION+ we write all three levers into the specification before an agent starts building. The agent still produces something every time. With the levers in place, it has the context to produce the right thing.
This sits alongside the wider framework we use for agentic engineering, ATOM, which we introduced in Introducing ATOM - the Agentic Engineering Target Operating Model. A specification also has to stay true after the first build. Our piece on spec drift covers what happens when a developer patches agent output by hand and leaves the spec behind.
Four questions to ask of your own specifications
You can test a specification against the levers in a few minutes. Take the last feature an agent built for your team and ask four things.
- Does every behaviour have a verification criterion that a person or a test could run?
- Are your coding standards and quality gates written into the specification, or only referred to?
- Can the agent see your architecture diagrams and service descriptions for the systems this feature touches?
- Does the specification still describe what is running in production?
A “no” to any of them points to the lever to fix first. Start with the one that would have prevented the last surprise your reviewers found.
If an agent has rebuilt a service you already run, treat that as a symptom of a wider gap in how your team does agentic engineering. If you are working out how your teams specify and check agent-built software, let's talk: https://www.mission.plus/contact-us
