In today’s safety critical industries, engineering teams write code then hand it over to a verification and validation team to check the implementation meets the requirements. The separation of responsibilities is implemented to ensure the verification is not biased towards the implementation; it has to strictly meet the requirements. This means that in some cases a deviation from the requirements is only caught after the code is merged to the codebase. If a deviation is identified, a new task is created for the engineering team to address it in the next sprint. This results in wasted cycles waiting for feedback from verification teams regarding deviant behaviour.

———

Similarly, many engineering teams are skeptical about using coding agents to write safety critical code due to the potential for hallucination when unit tests are written to confirm behaviour. This prevents these teams from reaping the rewards of faster development that coding agents can provide. The natural question we asked ourselves is how can we allow such teams to move fast without losing confidence in the generated code. What if we can shift verification earlier in the development process so feedback is quick and there is less waiting time to fix deviant behaviour? What if we can maintain a live traceability matrix (requirement → test → code) on every pull request? The engineering team doesn’t want to wait for feedback a sprint later, they want to get it immediately when a pull request is up so it’s fixed before a merge.

The problem

Coding agents cannot be trusted to write safety critical code.

Anyone who used coding agents today knows they can generate code bloat and superfluous tests. An engineering team writing safety critical code cannot use coding agents due to the work load it would generate in the verification step. In safety critical code, diligence is indispensable. Every source line needs to be traced back to a requirement and to the tests that verify it. That process is expensive because it is careful and precise. Coding agents made writing code fast and nearly free but did nothing for the expensive part — every line an agent writes is still a line to be traced, reviewed, justified and documented, and today’s agents generate far more of them than need to be there.

Coding agents accelerate code generation but create a verification overload.

If a coding agent generates the code and the test, the verification evidence becomes less trustable. The evidence that code meets a requirement is typically done independently of the development of the code. A verification team uses the requirements to generate tests that check that the code behaves as expected. Much of the confidence in verification is derived from the test suite: the requirement is met because the tests that exercise it pass, and the suite is an independent verification of that. A model optimises toward generating tests that pass. That can come at the cost of actually verifying the correct behaviour. A green CI correlates less and less with correct behaviour as the share of agent-authored tests rises.

When the suite becomes the thing being optimised, it stops being evidence.

So the constraint moves. A team can now generate far more code than it can verify, and what governs how fast safe software ships is no longer authorship — it is the rate at which you can produce trustworthy evidence that the code satisfies its requirements. A programme that adopts agents without changing how it verifies does not go faster. It accumulates unverified output, and the verification load quietly becomes the thing that is holding shipping back.

Our Solution

Verify at the scope of a system, across repositories — instantly.

If evidence is the constraint, the tooling has to produce it where the requirement lives and most verification tooling do not. A static analyser sees a file while a build sees a repository. Neither sees the scope a requirement is actually about: system level behaviour across the several components and downstream consumers that together satisfy it. The scope of the tool and the scope of the requirement do not match, and the gap between them is exactly where system level requirement drifts hide.

Code Sa maintains that whole graph, specifications, tests, source and consumers, and evaluates every change against it, before the change merges. Three things become visible that a file- or repo-scoped tool cannot see.

Specification drift is not just a property of a file; it is a mismatch between what a requirement says and what the code now does as part of the system, and both halves of that comparison usually live somewhere other than the pull request. Held at the right scope, that relationship is re-checked on every pull request, and drift stops being something discovered during a verification cycle. The developer gets immediate feedback on whether their pull request breaks a requirement or lacks sufficient testing. A change to an SDK or a library is judged against the consumers that call it, not only the repository it lives in, so the blast radius is visible while the change is still a pull request.

A generated unit test isolates a function behind stubs and mocks; that verifies the function, but not the requirement, which is usually satisfied by several components acting together. Because Code Sa holds the dependency chain, it generates tests that exercise a requirement end to end, from real call patterns rather than invented edge cases.

How Code Sa enables safe usage of coding agents

Four questions, answered on every pull request.

1 — Does the code still match the specification?

Live status per requirement across every approved statement, traced to the source text it came from, with a path straight through to the exact tests that verify it and the lines that implement it. When a change breaks that relationship, you see it while it is still a pull request — the traceability every one of these standards asks for, maintained continuously rather than reconstructed after a merge.

A requirement traced to the tests that verify it and the source that implements it — with verified, partial and no-coverage states across the set.

2 — Do your tests prove anything?

Every test decomposed into the functions it calls, its assertions and its size; overlapping tests surfaced as covered by another, so the suite can be trimmed without losing coverage; and the gaps that remain closed with tests generated from how the API is actually used not from the implementation that was just produced. The point is to break the loop where the code and the test that checks it share an author.

3 — Does it meet the standard?

Code quality rules are checked — ISO 26262-6 and MISRA C, for example — with a running count of findings mapped to the clause each rule enforces, in whichever standard and coding guideline your programme works to. Violations arrive with proposed patches for a human to accept or reject, and the whole codebase is re-verifiable against the guideline in a single action. The rule list itself is an artefact these standards require a project to produce, and here it stays current instead of being written once.

Rules drawn from a programme’s own coding guideline — here ISO 26262-6 — with clause references, finding counts and pass / violated state — the coding-guideline artefact, kept current on every change.

4 — Does the documentation describe what shipped?

Every interface with its documentation status scored for coverage alongside how widely it is used, so the undocumented functions that actually matter are fixed first, and regenerated from the current code so the description matches the actual implementation. Documentation stops being the thing that is always one release out of date.

The cadence

Verification has to move at the speed of the code.

The thread through all four is cadence. Evidence produced once, at the end, was a reasonable model when code changed slowly and a competent author sat behind every change. Neither holds now. The only cadence that works is the one the code changes at: every pull request. Findings arrive with proposed patches, the traceability updates and the correct documentation. The verification moves at the same speed as the code being generated.

The line we hold

Adopt the agents; keep the evidence chain.

Code Sa speeds up the part of the process that was always expensive, so a team can put coding agents to work and still hand over a clean, current evidence chain rather than a larger backlog of unverified output. Everything runs in your own cloud tenancy; your source, your requirements and your test data are never used to train models — ours or anyone else’s.