AI Large Scale Code Verification

What is AI large scale code verification?

AI large scale code verification includes using AI to help verify existing software and systematically checking AI-generated changes across many files or repositories. The goal is reproducible evidence that code meets specified requirements, fits existing interfaces and avoids known classes of defects.

Anthropic's October 22, 2026 research offers a concrete example of formal verification at scale. Anthropic and Theorem used Claude to write Rocq proofs checked by the Rocq kernel at the compiled RISC-V assembly level. They report no-crash proofs for 239 entry points across 123 OSS-Fuzz libraries after patching bugs.

That result has a defined scope: inputs smaller than 64 MB, single-threaded static binaries, a fixed memory budget and modeled Linux and RISC-V assumptions. It establishes the specified no-crash property within that scope, rather than freedom from every software bug or support for every architecture.

For an everyday codebase, begin with acceptance criteria and repeatable checks. Record the commit, configuration and results so another reviewer can reproduce the decision. A convincing explanation is not execution evidence.

Build a layered verification workflow

Run inexpensive checks first to shorten feedback loops. Add deeper checks according to the change: a parser catches syntax errors, while an integration test can expose a broken boundary between services. Neither replaces the other.

• Define acceptance criteria before reviewing the implementation. Include expected outputs, failure behavior and compatibility constraints.
• Check syntax, lint rules and types using the repository's committed configuration. Investigate warnings rather than silently disabling rules.
• Run unit and integration tests. Add regression cases for the reported defect and boundary cases that could contradict the implementation.
• Run security analysis appropriate to the language and threat model. Review findings in context and document justified exceptions.
• Have a reviewer inspect the diff, evidence and remaining uncertainty. Require accountable approval for consequential changes.

Choose tools by the evidence you need

Choose tools for your language and existing pipeline. Each supplies a different kind of evidence. Pin versions and commit configurations so local and CI results are comparable.

A small Python CI starting point

The example assumes an existing Python repository with src and tests directories, an activated environment, pinned project dependencies and committed Ruff and mypy settings. Install those dependencies through your repository's normal setup before running it. Adapt paths to your project.

The shell stops at the first failing command. Preserve its logs and exit status in CI. Compile checks cover syntax; Ruff, mypy and pytest then supply separate evidence. This starting point does not add security scanning, deployment checks or complete test coverage.

set -eu

python -m compileall -q src tests
python -m ruff check src tests
python -m mypy src
python -m pytest tests

Scale checks across repositories

Start each change with the modified modules and their dependency impact. A shared interface change may require downstream tests even when those files were untouched. Use targeted checks for fast feedback, followed by the required full checks before release.

Make each result traceable to the repository, commit, environment and tool versions. A green result from an earlier revision should not approve a later change. Retain the logs and artifacts needed to diagnose failures without rerunning an entire fleet.

• Key caches by relevant inputs, including dependency lockfiles, runtime versions and analysis configuration. Invalidate them when those inputs change.
• Separate existing findings from newly introduced findings. Give baseline exceptions an owner and a reason; do not automatically absorb new failures into the baseline.
• Track repeated failures and flaky tests. Assign ownership so retries do not become the default way to obtain a passing status.

Where formal verification helps

Tests exercise selected executions. Formal verification can establish properties of an annotated program under stated specifications and assumptions. Dafny, for example, uses preconditions, postconditions and invariants to express obligations the verifier checks.

Use this approach when a narrow property merits precise modeling, such as an algorithm invariant. The specification still needs review: proving the wrong contract does not establish the intended behavior. External services, runtime integration and assumptions outside the model need their own checks. An AI-generated explanation or a passing test suite is not a formal proof.

Ask AI for review evidence

Give the reviewer the diff, relevant interfaces, acceptance criteria and actual check results. Ask for falsifiable findings that a human can inspect. Keep the reviewer focused on the change; a second model repeating the first model's explanation adds little evidence.

Review this change against the acceptance criteria below.
Do not edit files or run commands.

Inputs:
- Acceptance criteria: [requirements and failure behavior]
- Diff: [patch]
- Relevant interfaces and tests: [context]
- Check results: [actual logs, or 'not run']

For each actionable finding:
1. Cite the file and line in the supplied revision.
2. Explain the failure with a concrete input or execution path.
3. State the evidence and any uncertainty.
4. Suggest a test that could confirm or refute the finding.

Do not claim that tests ran or passed without supplied evidence.
If context is missing, identify it. If no supported finding exists,
say so and list the checks or assumptions still unresolved.

Budget the review context

For large repositories, send the changed code, relevant contracts and focused test evidence first. Split unrelated changes into separate reviews while preserving dependencies. Count the assembled prompt before submission, then reserve capacity for the response and any provider-specific request overhead.

Tiktokenizer helps measure that text budget. Choose the model's supported counting method and read its accuracy label. A smaller prompt is useful only if it retains the context needed to review the change; token counts say nothing about whether the code is correct.

Official documentation

Use the tool documentation to configure checks for your repository.

• Anthropic: LLMs are making formal software verification feasible at a much larger scale
• GitHub: About code scanning
• Semgrep: Code overview
• Ruff: Python linter and formatter
• mypy: Getting started
• pytest: How to invoke pytest
• Hypothesis: Quick start
• Dafny: Verification tutorial