Essay
The cost of unproven code
Green CI is evidence for the checks it ran. Accepting a change needs more.
evidence · acceptance · audit
Originally published
Article history
No released revision history is available for this article. The original publication date is preserved; no revision events are implied. Any editorial clarification in the article is separate from admitted revision history.
A coding agent proposes a change to your repo. The proposal is identical in both worlds. What differs is what stands between the proposal and your main branch.
Without Apex
You ship trust.
Nothing checked the change against what it was allowed to touch, and nothing on the record can be replayed.
With Apex
You ship proof.
The signed projection records acceptance PASS. It does not name a person.
The right-hand column illustrates the intended acceptance workflow. The public calibration summary does not demonstrate this entire flow. Inspect the evidence →
Every engineering organization now lives an incident away from a sentence it does not want to read in an audit finding or a postmortem: the AI wrote it, and CI passed. Producing software has become cheap. Knowing what you accepted has not - and in a regulated environment, the gap between those prices is where the risk sits.
Green CI was never proof
Continuous integration answers a narrow question: did the tests the author chose to run, against the code the author chose to test, pass? When the author was a person, that answer came with an unpriced warranty - a human being who understood the change, staked their name on it, and could be asked about it afterwards. The whole change-management apparatus in banking, insurance, and critical infrastructure assumes that person exists.
A coding agent removes the person and keeps the ceremony. The diff looks reasonable. The description is well written. The tests are green. And nobody, anywhere, can tell you what the change was allowed to touch before it ran, which evidence was gathered and which was quietly lost, or why this change was accepted rather than merely merged. The historical Packaging calibration account reports tests executing against an installed package instead of the source tree under evaluation - green tests, wrong software. That is what green CI is worth on its own.What this does not proveA source-binding defect found in calibration is not evidence of a customer deployment or a general incident rate.Public trailImport-origin binding / proof file ↗
What unproven code costs
Trust is cheap on merge day. The invoice arrives later, in several currencies.
An incident is the obvious form. Something regresses and the review meeting asks the only question that matters: why was this change accepted? If the honest answer is “the agent's tests passed,” the incident now includes a process failure, and the remediation includes rebuilding a record that does not exist.
An audit is another. Supervised industries are being asked to show change control over machine-authored code with the same rigor as human-authored code. “CI passed” is evidence for the checks actually run. On its own it does not establish the authority, scope or independent evidence needed to accept the change. Firms are discovering that the cheapest time to build the record was before the run, and the most expensive is after the finding.
Compounding is the quiet form. Every unproven acceptance becomes the baseline the next change builds on. Unproven code does not just add risk - it quietly raises the floor under future risk, because nothing distinguishes what was verified from what was waved through.
Your numbers / illustrative scenario
What does your current review exposure look like?
Enter your own assumptions. This estimates review effort and the cost of a hypothetical bad merge, not savings from Apex or the probability of an incident.
Formula: PRs/week × review hours/PR × loaded hourly cost; add the bad-merge cost only in the stated scenario. This is not an expected loss, risk probability, ROI, or Apex benefit estimate. No values are sent or saved.
What proof looks like
Proof is not a better model or a longer prompt. It is machinery that costs something to fake, and it has several moving parts. The change is bounded before it runs. The floors - what may not regress - are fixed in advance. The verdict comes from the target's own tests rather than the candidate's own success message. The proof file describes implemented checks for source binding and incomplete evidence; those component claims are not a public reproduction of a full run. The signed projection records acceptance PASS and does not name a person. Its target-native test result is distinct from native Apex Review ACCEPT.What this does not proveThe merged mechanism is code provenance, not a run receipt. Its stronger file-binding claim was withdrawn.Public trailProtected verdict / proof file ↗
How a change earns acceptance
A step costs something to fake.
The intended compounding model makes an accepted improvement a requirement for later changes. The public record reports bounded development calibration on a private mirror of pypa/packaging. A private same-engine fresh-clone re-evaluation is reported separately; visitors cannot reproduce that evaluation from the published summary. The proof file also describes historical Astronomy Shop feasibility, not a current customer deployment or independently public replay.What this does not proveThe signed summary lists 11 protected dimensions. The reported same-engine replay and primary receipts remain private.Public trailSigned summary / evidence record ↗
drop a signed projection or the Cycle 2 run receipt here, or click to choose a file
nothing leaves this tab
None of this claims autonomous, self-certifying software. Apex is at calibration stage: the machinery is real, and the receipts are development-only. That is precisely the point - proof is what makes the work inspectable while the system earns the right to be trusted further.
The question to put to any agent pipeline, yours or a vendor's, is short: show me the record for the last change it accepted. If the answer is a green checkmark, you are shipping trust. The cost of unproven code is not what it breaks today. It is what you cannot prove tomorrow.