Navigate this article
‘Add report exports’ sounds straightforward. But which data, for whom, and in what format? Before asking an agent for code, turn those questions into verifiable decisions.
Write a small specification
Spec Driven Development, or SDD, uses a specification to guide implementation and validation. It does not need to predict the product's entire future. It needs to explain the outcome, boundaries, and how to recognize a correct delivery.
For the export example, define the user role, data scope, format, and failure behavior. State what this iteration will not deliver.
Goal: export orders for the authenticated company
Role: administrator with export permission
Format: CSV with approved fields
Out of scope: other companies' data and scheduling
Acceptance: correct file, denied unauthorized access,
handled errors without internal data disclosureProvide context that supports decisions
The agent needs the API contract, authorization rule, test examples, and project execution instructions. It does not need every conversation or an indiscriminate copy of the repository.
Context Engineering organizes that information. RAG can retrieve references as needed, but retrieval must respect the user's access. Finding a document does not make its content a trusted instruction.
- Task specification and acceptance criteria.
- Affected modules and boundaries to preserve.
- Actual build and test commands.
- Existing decisions and questions requiring a person.
Separate the work loop from the execution environment
Loop Engineering structures planning, execution, observation, and correction. The harness provides the environment: tools, permissions, context, limits, and records. They complement each other; neither requires a multi-agent architecture.
For an export, an agent can edit an approved module and run tests in an isolated environment. It does not need production credentials. When a step exceeds scope, the loop should stop for a decision, not invent authorization.
A prompt instruction describes a rule. System permissions constrain what the tool can actually do.
Validate behavior, not the amount of code
Require evidence for each criterion: export tests, access denial, and failure handling. Review the diff and run checks independently of the agent's account. ‘Done’ is a claim; tests and system state are evidence.
When the product uses AI in its operation, complement software tests with evals: representative cases comparing answers, tools, and effects between versions. Human review belongs at decisions involving risk or business judgment.
Try it on one project task
Choose a change small enough for one delivery. Write an objective, boundaries, and three acceptance criteria. Gather references, allow only the required tools, and run the implementation and review cycle.
Keep the specification, change, and test evidence together. If another person cannot understand why the result is correct, the delivery needs more context. If the process exceeds the task, reduce ceremony without removing essential controls.
Sources and further reading
Educational material. Validate examples in a test environment and adapt decisions to your project's context, risks, and responsibilities.
Share