In this article
Last updated September 18, 2026
4 min read
Passing tests are valuable.
They are also easy to ask to prove too much.
A green suite can show that the implementation satisfies the tests that ran in the environment recorded. It cannot, on
its own, show that the tests represent the user’s need, cover every important edge case, or protect the correct
invariant.
That gap becomes more important when the same AI system helps interpret the request, write the code, and generate the
tests.
How code and tests can agree on the wrong answer
A product request says, “Members can invite colleagues.”
The implementation allows any signed-in member to create an invitation.
The generated tests confirm that a signed-in member receives a successful response and an invitation is stored.
Everything is green.
The product may still have intended only administrators to invite. The tests are consistent with the code because both
share the same unapproved interpretation.
This is an illustrative example, not a claimed incident. It shows why internal consistency is weaker than independent
evidence.
Begin with observable behaviour
Before implementation, write what a user or system should observe.
For example:
- An administrator can invite a new member to an organisation.
- A non-administrator receives a forbidden response and no invitation is created.
- An expired invitation cannot be accepted.
- Removing the inviter does not silently transfer authority.
- Creating and accepting invitations produces the required audit events.
Each criterion should name a proof method:
- feature test;
- policy unit test;
- browser check;
- security review;
- audit-log assertion;
- human product decision.
The proof plan gives the test writer a source independent of the implementation.
Confirm invariants with a human
Some rules deserve stronger treatment because they must survive every code path.
Examples include:
- a user cannot approve their own elevated access;
- money cannot move without an immutable ledger entry;
- a deleted organisation cannot retain active invitations;
- personal data cannot appear in a public log.
An agent can help discover and phrase these rules. A named human should confirm them when they represent product,
security, legal, or architectural intent.
Then carry stable identifiers for the invariant into tests, review, and the final evidence receipt.
Map promises to evidence in both directions
Forward traceability asks:
Which code and test prove each acceptance criterion?
Reverse traceability asks:
Which acceptance criterion or decision required each changed behaviour?
Forward mapping finds missing proof.
Reverse mapping finds unrequested additions.
This is important because an AI-generated test can make an extra behaviour look intentional simply by preserving it.
Test the tests
Coverage counts execution. It does not necessarily show detection.
Mutation testing can help. A mutation tool introduces a small change, such as reversing a condition or changing a
boundary, and runs the suite again. If the tests remain green, the mutation survived and the team has a reason to
inspect whether the expected behaviour is protected.
Use mutation testing selectively. It has cost, and a surviving mutation is a signal rather than automatic proof of a
defect.
The useful question is:
Would this test fail if the product promise were broken?
Keep evidence categories honest
A final report should distinguish:
- Test execution passed.
- Acceptance criterion has a linked test.
- Reviewer judges that the test meaningfully proves the criterion.
- Human confirms the product rule.
These are different claims.
The first can be deterministic. The third requires judgement. The fourth requires authority.
When a workflow labels them separately, a reviewer can see what is proven and what remains a decision.
What paqad-ai adds
paqad-ai is designed to connect specification obligations to implementation and test evidence. Its workflow can freeze
the target for higher-risk work, keep acceptance criteria and invariants visible, run deterministic checks, use
separate review roles, and report gaps before a human verdict.
No framework can make a weak product decision correct.
It can make the missing decision and missing evidence visible before a green suite becomes false confidence.
Tests are part of proof.
The product promise is the thing they are supposed to protect.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- On the risk of coding before testing, July 2026 preprint that requires
replication. - OpenAI, Harness engineering, first-party account of mechanically
enforced invariants and repository structure. - Product workflow details are first-party claims from the current
paqad-ai repository.