Topic · Intent

AI generates our specs and our code. Who verifies the intent is right?

A human still signs the shall. Proof then fails the merge when the files have no witness. A spec written from the code is a restatement, not a check.

proof audit --fail-level warn

The model can write the YAML. It cannot sign it. Jama still authors the programme.

01 · Spec from code

If the YAML came from the same window as the function, every analysis is green and you learned nothing.

A requirement that describes what the code already does will pass realizability, consistency, and vacuity. Zero bugs found is the expected result. The shall never asked a question the code could fail.

Verifying one patch is the developer loop. The buyer question when the code is model-written is who audits AI-generated code. This page is the next turn: the model also wrote the spec. There is no independent bar left unless a person signs one.

We ran this in public on a 400-line policy merge. Phase 1 wrote 38 requirements from the code. Every analysis was green. Zero bugs. Phase 3 rewrote the shalls from what the merge is supposed to do, declared an extra input, and gap analysis flagged unconstrained outputs. The test for that case crashed. The bug was always there. The restatement never asked.

proof audit --fail-level warn
proof audit --check acceptance_criteria_witnessed

A green unit test the model also wrote does not clear acceptance_criteria_witnessed. A // Verifies: marker that arrived in the same commit as the test is co_authored: the trace restates the code. That classification is in git history, not a prompt.

02 · The exhibit

Same component. Two specs. One of them can fail.

Shall from the code: when apply is requested, tags are merged. Shall from intent: tags are merged only when the store is available. Click the tabs.

Model-written YAML

  • Source the function, restated
  • Store down not an input
All analyses green

The missing case

store_available = false is not in the spec. Gap analysis has nothing to flag.

Unasked

The restatement

Still green. It never mentioned the store.

Zero bugs

Proof

  • Shall owner-signed, store is an input
  • Gap outputs unconstrained when store is down
Test crashed

Same merge. Two bars. Click the tabs.

What ran Green? What it looked at
YAML generated from the code Yes A restatement. Realizability of a mirror is not a finding.
Tests from the same window Yes Agreement. co_authored traces do not count as an oracle.
LLM eval of the spec Often Whether the YAML reads well. Not whether a case is missing.
proof audit on an owner-signed shall No, here Gap analysis on the extra input. The crash was the unconstrained case.

If the job is “make the YAML look like a spec,” keep the model. If the job is “did we ask the question the code can fail,” a person still has to sign that question. Proof does not invent it. It fails the merge when the signed shall has no witness, or when gap analysis says an input was never constrained.

03 · The honest loss

Proof does not know what you meant. A person still has to say it.

A green audit means the checks we selected passed on the approved shalls. It does not mean those shalls are the promises a customer heard.

We have not run Proof and an LLM-eval, or Proof and a requirements bot, on the same frozen corpus. FRETish is 288 templates, not arbitrary English. Jama still wins at programme authoring. The model can draft. The owner still approves every clause before any line is judged.

The developer loop stays on verify AI agent code. The buyer question that does not also blame the spec stays on who audits AI-generated code. Machine-checkable authoring stays on FRETish. The commercial shape of the install is on the audit page.

04 · Nearby questions

What people type next.

The AI wrote the function and the test that agrees with it. How do I know either is right? Same circular proof, code side. Verify AI agent code.

Who audits AI-generated code for correctness? The buyer URL when the code is model-written and the shall is already signed. Who audits.

How do I write machine-checkable requirements? That is authoring, not the circular-spec problem. FRETish.

How do I catch when an agent silently breaks an existing requirement? Reverse suspect, after a shall already exists. Silent break.