Engineering Playbook
VERIFY
When execution becomes cheap, verification becomes valuable.
Verification protects customers, teams and reputation. It is where confidence is earned — and it is the stage that matters most once generating a change costs almost nothing.
What breaks without it
Without verification, "done" means merged, not correct. Customers and operators discover the truth first.
The deliverable
The Evidence Pack
No claim without evidence. An agent — or an engineer — should never simply report "done".
Industry research on AI adoption keeps arriving at the same shape: AI amplifies whatever engineering system it lands in. Organisations with strong verification convert AI into throughput. Organisations without it generate change faster than their control systems can safely absorb.
The counterweight is to make evidence, not assertion, the unit of completion. Every completed change should carry a record of what was claimed and what was demonstrated.
This is stronger than ordinary CI/CD because it travels with the change and is legible to a human reviewer who was not present for the work.
- Intent — which requirement this implements
- Change — what actually changed
- Tests — what ran, and what it proved
- Security — which checks ran and what they found
- Architecture — whether boundaries were preserved
- Static analysis — which quality gates passed
- Dependencies — what was added, removed or upgraded
- Risk — what residual risk remains and who accepted it
- Observability — how we will know this works in production
- Provenance — which human and which agent produced the change
- Agent trace — which tools and actions were executed
- Reviewer — who or what verified it
Evals
Verify the agent, not only the change
Agentic delivery adds a verification category that traditional testing does not cover: whether the engineering agent itself behaves correctly across a class of work. This is closer to evaluating a new engineer than to running a test suite.
- Does it select architecture consistent with our standards?
- Does it create tests at the right level of risk?
- Does it avoid prohibited libraries and patterns?
- Does it respect repository and ownership boundaries?
- Does it avoid unnecessary or opportunistic changes?
- Does it escalate for approval as risk increases?
- Does it behave the same way on the same class of ticket next month?
Practices
- Treat verification capacity as the real constraint on delivery speed
- Review evidence, not only the diff
- Run evals on the agent when you change its context, tools or model
- Make the secure and verified path the easiest path to take