Google DeepMind Says AI Formally Verified Signal’s Protocol Code and Flagged Only 1% for a Human Look. Where Should Human Review Go?

Google DeepMind says its AI agents formally verified Signal’s protocol code, with about 1% of the codebase flagged for a human look, using a research framework called AlphaProof Code announced on 10 Nov 2026. The result lands on the problem every team merging agent-written code shares, which is checking it. Reviewing and validating AI-generated code is the main delivery constraint for 25.8% of developers and 26.0% of engineering leaders, according to a 2026 Qodo survey.

The proof covers the properties in a specification that human experts reviewed, for one narrow, high-stakes codebase. Everyday pull requests (PRs) from coding agents have no such specification and still need review against the team’s own rules. Formal proof and PR review work at different layers of the same delivery process, and Qodo works at the PR layer, next to formal verification.

TL;DR

• Checking agent-written code is the open problem. DeepMind’s paper says software assurance today “primarily comes from testing, bug finding, and code review,” and review of AI-generated code is the main delivery constraint for about a quarter of developers in a 2026 Qodo survey.
• DeepMind says its agents proved that Signal’s protocol code meets a written security specification. AlphaProof Code generated over six million lines of Lean proof in four weeks, according to DeepMind, and agents flagged about 1% of the codebase for a second human look.
• A proof covers only the properties written into its specification. Human experts reviewed every specification, DeepMind says, and most everyday agent PRs have no formal specification, so they still need review against team rules.
• Qodo works at that everyday PR layer, alongside formal verification. Qodo reviews every PR against the team’s REVIEW.md and the linked ticket and lets teams route the high-severity findings to the people who decide, so teams merge agent-generated code sooner with fewer rollbacks.

Agents Write the Code. Checking It Is the Open Problem

Agents write the change, and people still carry the checking. In the same 2026 survey of 500 US developers and 300 US engineering leaders, 36.4% of developers say AI-generated code takes the same review time with more mental effort, according to Qodo’s AI code review guide.

Software assurance today “primarily comes from testing, bug finding, and code review,” DeepMind’s paper says. Formal verification proves with math that code meets a stated property for every input, instead of testing a sample of inputs. The paper says formal verification has been “historically too expensive for most software,” and verifying the seL4 microkernel took twenty person-years. DeepMind’s paper aims to show that AI agents can cut that cost, using one critical codebase.

What Google DeepMind Says AlphaProof Code Did With Signal

Signal’s protocol protects messages in the Signal app, Google Messages and other apps. Real bugs often sit in the gap between a protocol design and the code that runs on phones, as DeepMind’s announcement puts it.

AlphaProof Code is an agentic framework for formal verification that “combines human expertise with AI agents,” Google DeepMind researchers Pushmeet Kohli and Swarat Chaudhuri write.

DeepMind’s team first worked with several models to turn Signal’s security goals into formal specifications, “with human experts reviewing every one.” Agents powered by Gemini then wrote the proofs in Lean, a language whose checker accepts a proof only when every step holds. Agents next audited the proofs and flagged areas for a person. DeepMind’s technical paper says “none of the authors wrote any proof code.”

DeepMind did the Signal analysis free of charge as a research project, WIRED reported, and is open-sourcing the specifications and proofs. The result sits at the far end of the checking problem, on one critical codebase and against properties people chose in advance.

Why the Proof Still Depends on People: Someone Has to Write Down What Correct Means

Proofs got cheap, by DeepMind’s account. DeepMind reports four weeks for Signal, with Lean rejecting any proof with a broken step. The hard part moved to the specification. “Once proofs become cheap, the hard question is what to prove,” the paper says. “The majority of our effort went not into proofs but into specifications.”

A specification states what the code must guarantee, and the paper warns that it “cannot be automatically checked.” A specification with assumptions that are too narrow can hold even for buggy code, the paper notes. “So now the question is what are we verifying? … That process is fundamentally human-in-the-loop,” Chaudhuri told The Register. The team didn’t want “this sort of vibe world where AI is generating the goals and AI is generating the proofs and basically taking tests that are self-written,” he told WIRED.

The scope is narrow on purpose. The proofs cover selected security properties of Signal’s protocol library, assume perfect cryptography and leave the full Signal app unverified, according to DeepMind’s paper, The Register and WIRED. Most teams don’t write formal specifications for a payments service or a settings page, so most of the code they merge sits outside any proof.

What Formal Verification Covers, and What Still Needs Review

Formal verification and PR review work at different layers of the same delivery process. The table compares the two in DeepMind’s Signal project and in everyday PR review with Qodo.

A proof answers whether one codebase meets a written property for every input. A PR review answers whether today’s change follows the team’s rules and does what its ticket asked. The two layers are complementary, and neither replaces the other.

Senior engineers can’t scale the way agents do, so judgment a team repeats belongs in written standards, and a person steps in for new trade-offs, unclear constraints and thin evidence. Everyday review has no proof checker, so the cost of a vague standard or a missed requirement shows up in four places.

What Breaks When Everyday Review Has No Specification

1. Standards live in people’s heads. Standards already exist in wikis, rules files and senior engineers’ heads, but an agent never sees most of them, and review can’t check what nobody wrote down. AlphaProof Code started with specifications people approved before any proof began, and most repositories have nothing comparable for review.
2. Intent sits outside the diff. The intent behind a change usually sits in tickets, specifications and architecture documents, not in the code or in an agent’s instruction files. Understanding whether code matches its intent is the greatest AI code review challenge for 13.2% of developers in the same 2026 survey. A review that reads only the diff can’t tell whether the change does what the ticket asked.
3. Human attention spreads across everything. DeepMind’s experts focused on about 1% of the codebase, according to DeepMind, because the agents and Lean handled the rest. On a PR with many comments of equal weight, a reviewer reads everything or skims everything, and the high-severity finding gets the same glance as a style note.
4. The agent’s own “done” becomes the record. “We therefore never rely on an agent’s own report that a goal is done,” DeepMind’s paper says of its gatekeeper. An agent that writes the code and then reports success is grading its own work, and without an independent record, nobody can show which issues were raised, fixed or dismissed across repositories.

Where Human Review Goes Now

Human review moves up, to deciding what matters and writing the rules, the way DeepMind’s experts approved every specification, and out, to the code no proof covers, which on most teams means every PR. In DeepMind’s words, AI assistance “can reduce the cost of specification writing and assurance but not completely replace human judgment and review.” Everyday review needs four parts, one for each break.

1. Written review rules per repository and across the organization, so review has a standard to check against.
2. The ticket in the review, so each change is checked against what it was meant to do.
3. Findings ranked by severity and routed so people read the high-severity ones first.
4. A record kept outside the coding agent, showing which findings were resolved, dismissed or left open.

Neither a proof checker nor an AI reviewer decides what the rules should say. People do, and the four parts describe the everyday review layer where Qodo works.

How Qodo Covers the Everyday Review Layer

Qodo, the AI Code Review Platform, is the quality and governance layer for teams moving toward a more autonomous SDLC (software development lifecycle). Qodo works at the PR layer, alongside formal verification, checking every PR from any coding agent against rules the team wrote. Qodo answers the four breaks in order, with written review rules, ticket-aware review, severity routing and a record of what happened to each finding.

REVIEW.md and Custom Instructions Write Down What Correct Means

REVIEW.md is a file at the root of a repository that tells Qodo’s review agents what to flag and how to prioritize findings on every PR. Teams write the properties a change must keep in plain Markdown, such as “every decrypt path verifies the message authentication code before using the plaintext.” Qodo uses REVIEW.md only for its code review agents, and the next PR review reflects any update to the file.

As of 5 Nov 2026, REVIEW.md instructions are on by default for Qodo SaaS workspaces, and single-tenant and on-premises teams turn them on in the Qodo portal under Configurations > Context. Custom instructions in the Qodo portal add the same guidance for the Issue finding agent across the organization. Enterprise engineering teams get one written standard across many repositories and coding agents.

Ticket Context Checks Each Change Against Its Intent

Qodo reads the ticket linked to a PR and checks how well the changes match the stated intent. According to Qodo’s ticket context documentation, the feedback appears as findings and may include “Missing or incomplete requirements,” “Changes that do not clearly support the intended goal,” and notes that an implementation “looks correct but may require additional manual validation.”

Requirement-aware feedback is on by default. Qodo finds the ticket through a link in the PR description or a ticket key in the branch name, and works with Jira, Azure DevOps and other ticketing tools.

Severity Routing Puts High-Severity Findings in Front of People

Qodo labels every finding High, Medium or Low. High covers issues “that should be addressed before merging, such as security or compliance violations, sensitive data exposure, or critical correctness issues,” according to Qodo’s guide to the anatomy of a review. By default, every severity appears both inline and in the summary, and comment routing in the Qodo portal lets admins send each severity to inline comments, the summary or both.

Routing High findings inline and Medium and Low findings to the summary gives reviewers a short list on the code and keeps the rest one click away. PR review stays low-noise because people read every comment. High-velocity teams keep the coding agents they already use and get every PR checked, with setup in about 5 minutes on GitHub or Bitbucket Cloud and no new process.

Resolved Findings, Review Resolver and Analytics Keep the Record

Each time Qodo reviews a new commit, it re-checks every open finding against all changes since the finding was raised, and marks each one Resolved, Dismissed or Outdated. The record comes from Qodo’s review instead of the coding agent’s own report.

Review Resolver, an Agentic Toolbox skill, lets a coding agent retrieve Qodo’s findings from an open PR and resolve the ones a developer picks, with an explicit outcome for each. Qodo’s code review analytics shows admins how teams respond to findings across PRs, repositories and PR authors, and which high-severity findings remain unaddressed. A written standard tells an agent what to do. Review outside the agent checks whether the standard held, and reports how often.

2 Examples: Everyday Agent PRs Checked Against Team Rules and Tickets

Example 1: an agent’s retry fix skipped a message check

A messaging team’s REVIEW.md states three properties in plain words, including “every decrypt path verifies the message authentication code before using the plaintext,” and asks Qodo to treat violations as high severity. A coding agent fixed a flaky retry by adding a fast path that reused a cached session and skipped the check on the second attempt. The tests covered only the first attempt, so they passed.

With comment routing configured to send Medium and Low to the summary, Qodo raised a High finding under the REVIEW.md instruction as an inline comment, and five Medium and Low findings went to the summary. The developer asked the agent to resolve the finding through Review Resolver, and Qodo marked it resolved when it reviewed the next commit.

Example 2: an export story’s privacy criterion went missing

A Jira story for a data export listed four acceptance criteria, one of them “exports include only records the requesting user owns.” The agent’s PR built the export, the file format and the download link, and filtered records by workspace instead of by owner.

Qodo reviewed the PR against the linked story and raised a finding for the missing requirement, plus a note that the download screen looked correct but needed manual validation. The product engineer checked the screen by hand, the developer fixed the filter, and the platform lead filtered analytics by High severity to check other repositories for unaddressed findings.

Hands-On: Give Qodo a Specification to Review Against

The steps follow Qodo’s docs as of 10 Nov 2026. The instruction text is an example, not a Qodo default.

1. Install Qodo on your Git provider. Installation takes about 5 minutes on GitHub and on Bitbucket Cloud, and around 5 to 10 minutes on GitLab and Azure DevOps. Reviews then run automatically when a PR is opened, reopened or marked ready for review.
2. Write the properties your code must keep in REVIEW.md at the repository root. Plain Markdown works, with no required schema.

# REVIEW.md

## Properties every change must keep

- Every decrypt path verifies the message authentication code before using the plaintext.
- Session keys and tokens never reach logs, error messages or analytics events.
- Exports and search results include only records the requesting user can access.

Treat a violation of these properties as high severity.

3. Add organization-wide guidance. In the Qodo portal, go to Configurations, then Custom instructions, add the properties every repository shares for the Issue finding agent, and click Save.
4. Connect your ticketing tool. For Jira Cloud, go to the Qodo Integrations page, click Connect Jira Cloud and click Accept, as Qodo’s Jira guide describes, and add jira_base_url under [jira] in the configuration file so branch names and short ticket IDs resolve. Link each ticket in the PR description, or put the key at the start of the branch name or right after a slash, such as feature/PROJ-123-export-filter.
5. Route findings by severity. In the Qodo portal, go to Configurations > Display > Comment routing, send High to Inline & Summary and Medium and Low to Summary, and click Save changes, or pick the Balanced display mode, which applies the same routing along with its other display settings.
6. Resolve findings from the coding agent. Install Qodo’s Claude Code plugin, then ask the agent to resolve the findings you choose through Review Resolver.

Resolve the high-severity findings from my pull request.

7. Read the record. As an admin, open Analytics in the Qodo portal, choose Last 30 days, filter by Severity: High and break the data down by repository or PR author.

Summary

Checking agent-written code is the open problem for most teams. For one critical codebase, Google DeepMind says AlphaProof Code proved that Signal’s compiled protocol code meets a written security specification, with over six million lines of Lean in four weeks and about 1% of the codebase flagged for a second human look. The proof covers the properties in that specification, and human experts reviewed every specification, DeepMind says.

Most code has no formal specification, so human review moves to deciding the rules and to the PRs no proof covers. Qodo works at that everyday layer. Qodo reviews every PR against REVIEW.md and organization-wide instructions, checks each change against its linked ticket, lets teams route the high-severity findings to the people who decide and keeps a record of what was resolved, outside the coding agent. Formal verification and PR review are complementary layers, and neither replaces the other.

Teams merge agent-generated code sooner with fewer rollbacks. Enterprise engineering teams get one written standard across many repositories and coding agents. High-velocity teams keep their coding agents, get every PR checked and finish setup in about 5 to 10 minutes on cloud Git providers. Qodo’s code review best practices, its AI code review guide and its look at where code rules should live cover the wider picture.

FAQs

What is AlphaProof Code?

AlphaProof Code is a Google DeepMind framework for formal verification, announced on 10 Nov 2026, in which people and AI agents write a formal specification of real code and agents then prove in Lean that the code meets it. DeepMind used AlphaProof Code to verify key security properties of Signal’s protocol code, in work WIRED described as a research project.

What did Google DeepMind verify in Signal?

Google DeepMind verified key security properties of libsignal, Signal’s reference implementation, at the machine-code level, including forward secrecy, authentication, post-compromise security and handshake secrecy, according to DeepMind’s paper. WIRED reported that the work found no new vulnerabilities in the parts of the protocol it checked and did not cover the full Signal app.

Does formal verification replace code review?

No, by DeepMind’s own account. DeepMind’s paper says AI assistance “can reduce the cost of specification writing and assurance but not completely replace human judgment and review.” Formal verification proves that specific code meets a written specification, only for the properties stated, and most code changes have no formal specification. The two are complementary layers. Qodo reviews every PR against the team’s rules and linked ticket, as the everyday layer alongside formal verification.

What is a specification in formal verification?

A specification in formal verification is a precise statement of what code must guarantee, such as “earlier messages stay secret even if a key is later compromised,” written so a proof checker can test a proof against it. Everyday teams write a looser version in tickets and review instructions, and Qodo checks each PR against a repository’s REVIEW.md and the linked ticket.

How much of AlphaProof Code’s work did humans review?

Agents flagged about 1% of the codebase for a second human look in AlphaProof Code’s Signal project, according to DeepMind, and human experts reviewed every specification. Qodo lets teams apply the same idea of putting human attention where it counts to everyday PRs, by routing high-severity findings inline and the rest to the summary.