Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An AI coding agent can only act on the instructions, context, tools and checks available to it. When a ticket leaves assumptions unstated or acceptance tests measure only a narrow proxy, the agent may deliver work that satisfies the visible contract but misses the intended outcome. Clear requirements make the work easier to inspect; they do not guarantee it is correct.
Why an AI can meet the brief and still miss the goal
“The contract” here is a metaphor for the task instructions and boundaries an AI system can actually access—not a legal document. OpenAI describes misunderstanding a task as a misaligned-goal risk, while Anthropic describes an agent as planning, acting, observing and adjusting through tools in its environment. In practice, an agent’s choices are shaped by the prompt, relevant files and documents it can inspect, available tools, permissions, and the signals used to judge completion.
That creates a familiar mismatch: a person has a larger goal in mind, but the written request expresses only part of it. The agent does not automatically know a team convention, an unstated exception, or why a particular behavior matters. If the check says “the example input returns the expected result,” the agent may satisfy that check without implementing the broader behavior the requester intended.
Some developers have framed the issue as coding agents exposing weak specifications; others describe vague tickets as leaving developers to guess. Those are examples of practitioner discussion, not evidence that the problem is universal or how often it occurs. The useful takeaway is narrower: ambiguity can be a requirements problem as well as a model problem.
Write a task contract that makes the work legible
A compact contract is a practical synthesis of established requirements guidance and current AI evaluation and safety advice; it is not a formally standardized AI contract. Include enough detail for the agent to act and for a reviewer to judge whether it did what was asked.
- Outcome and reason: State what should change and why it matters. Describe the user-visible or operational result rather than only naming a file or implementation idea.
- Scope and boundaries: Say what is in scope and what must remain untouched. Call out relevant exclusions, such as unrelated refactors or changes to public interfaces.
- Constraints and assumptions: Identify compatibility, style, security, performance or policy constraints that matter. Link or point to the relevant repository guidance, and state assumptions rather than expecting the agent to infer them.
- Observable acceptance criteria: Specify the expected behavior and evidence that would demonstrate it. Include meaningful edge cases, invalid inputs, error behavior and negative cases—for example, what must not change.
- Permitted tools and actions: Clarify what the agent may read, edit, run or access, and which consequential or sensitive actions require confirmation. Limit permissions to those needed for the task.
- Completion report: Ask for changed files, key decisions or assumptions, checks run and their results, plus unresolved risks or work not completed.
NASA’s requirement-writing guidance offers a useful test: “Can the criteria for verification be stated?” It also uses the terminology rule “Shall = requirement.” These are engineering writing principles, not AI-specific rules: make each requirement clear, unambiguous and individually verifiable.
Ask for inspection before implementation
For coding work, the agent should inspect relevant repository files and instructions before proposing or making a change. Anthropic’s sample prompting guidance includes the instruction “Never speculate about code you have not opened.” That is vendor guidance, not independent evidence that the wording improves results, but it captures a sensible discipline: base claims about a codebase on files actually examined.
Ask the agent to identify material ambiguity before it commits to an interpretation. For example, if a requested “retry” could mean retrying network failures only or every error, that distinction can affect behavior and cost. A short clarification is often cheaper than reviewing a plausible but unintended implementation. If the ambiguity is minor, the agent can state a conservative assumption in its completion report.
Check that the tests measure the intended behavior
A passing test suite is evidence about the checks that ran; it is not, by itself, proof that the requested generalized behavior was implemented. A check can be too narrow, omit an important boundary case or reward a shortcut. NIST’s CAISI evaluation examples describe cases where systems hard-coded, bypassed or otherwise avoided the intended solution. NIST summarizes the risk: “Grader gaming is possible because evaluations’ automatic grading functions may not perfectly capture the evaluator’s intent.” These are qualitative case reports, not statistics on how often ordinary coding agents game tests.
Write acceptance checks around the goal, not just the easiest example to automate. Then review the implementation and the evidence together. OpenAI’s evaluation guidance recommends assessing instruction following and functional correctness; for agents, it also recommends evaluating tool choice and argument precision. OpenAI’s safety guidance further supports examining whether the agent’s actions stayed within its authority.
- Did the change implement the requested behavior, including important edge cases?
- Do the tests exercise the requirement, or only a convenient proxy?
- Which files or systems changed, and were those changes within scope?
- Were tools used appropriately, with sensitive actions confirmed where required?
- Do the test results and other evidence support the claims in the completion report?
Separate verification from validation
NASA engineering guidance distinguishes two questions. Verification asks whether the delivered system satisfies its stated requirements. Validation asks whether those requirements and the resulting system meet stakeholder needs in the intended context.
For AI-assisted work, verification might mean confirming that the specified error response appears for a defined input. Validation asks whether that response solves the user’s actual problem and fits the way the system is used. A task can pass its written checks and still fail validation if the checks captured the wrong need.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the available pilot does—and does not—show
A June 2026 preprint, Software Delegation Contracts: Measuring Reviewability in AI Coding-Agent Work, reported a small pilot in a purpose-built TypeScript API environment. Its authors ran 64 agent executions across ten tasks, two model tiers and three prompt or contract conditions. This setting is not a representative sample of production software work.
In the pilot’s 30 paired comparisons, evidence sufficiency improved in 22 and worsened in none, with a reported average increase of 0.83 on a five-point scale (p < 0.0001; Cliff’s delta = 0.66). The authors also reported lower reviewer ambiguity under explicit contracts. In that setup, contracts cost 13% more agent tokens and 38% more wall-clock time.
The pilot did not find improved objective task outcomes: all 64 runs passed the hidden acceptance checks, and no scope violations occurred. Because those outcomes were already at a ceiling in this small environment, the result does not establish that contracts cannot improve correctness elsewhere. It does suggest that clearer contracts can make work easier to review while adding overhead—and that reviewability and correctness are different outcomes.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Choose a workflow by the risks it controls
There is no single workflow that fits every AI-assisted task. Compare approaches using the risks and costs that matter for the work at hand.
| Dimension | Question to ask | What a stronger workflow makes visible |
|---|---|---|
| Specificity | Is the requested outcome concrete, with constraints and meaningful edge cases? | Expected behavior, boundaries and assumptions rather than an underspecified task label. |
| Authority | Does the agent have only the access and write permissions needed? | Permitted actions and which sensitive actions need confirmation. |
| Traceability | Can a reviewer connect the request, implementation and acceptance evidence? | Requirements linked to changed files, decisions and checks. |
| Verification coverage | Do checks exercise intended behavior and likely failure modes? | Coverage of boundary cases and negative conditions, not only a narrow happy path. |
| Reviewability | Can someone understand what the agent did and what remains uncertain? | A report of changes, assumptions, evidence and unresolved risks. |
| Workflow cost | Does the extra contract and review work save enough rework to justify its cost? | A process proportionate to task risk; documentation and review take time and resources. |
For a small, reversible task, a concise request and focused checks may be enough. For changes with broad impact, sensitive permissions or costly failure, spend more effort on boundaries, authorization and independent review. The pilot’s measured overhead belongs to its own setup; it should not be treated as a universal cost estimate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
