-
-
home page
Inspiration
AI coding tools have made software development dramatically faster, but they have also created a new problem: code can look complete without actually being complete.
A project may have polished UI, API endpoints, tests, and impressive documentation while hiding hardcoded responses, mocked integrations, disconnected pipelines, or untested functionality. Traditional code review can identify some of these issues, but it often does not answer the most important question:
Does the software actually satisfy the requirements it claims to fulfill?
That question inspired ProofCheck AI. We wanted to build a verification system that goes beyond reviewing code and instead gathers evidence to determine whether a project really works as specified.
What it does
ProofCheck AI takes two primary inputs: natural-language project requirements and a GitHub repository.
It converts the requirements into independently testable criteria such as REQ-01, REQ-02, and so on. It then analyzes the repository using multiple evidence sources:
- Observed runtime execution — actually executes the project's tests and records the results.
- Behavioral simulation — deterministically checks source behavior for patterns such as hardcoded responses and mocked integrations.
- Static source analysis — uses AST parsing, symbol mapping, and call-graph analysis to understand implementation and connectivity.
- AI specialist analysis — uses specialist agents when an LLM provider is configured.
Seven specialized agents contribute to the verification process: Requirement Analyst, Code Analyst, Architecture Agent, Test Agent, Behavior Agent, Security Agent, and Judge Agent.
The result is an evidence-backed report with statuses such as Verified, Partially Verified, Failed, and Unable to Verify, along with weighted scores, critical-failure alerts, source-level evidence, call traces, and prioritized recommendations.
A key feature is our strict distinction between tests that exist and tests that actually ran. Merely finding test files does not increase the test score. If tests are not executed, the system records test_score = 0.0.
We also created an Instant Demo Bench with intentionally flawed projects, including a Voice RAG Assistant with a hardcoded retrieval fallback, an e-commerce checkout with a mocked payment endpoint, and a JWT authentication project containing a hardcoded admin token.
How we built it
ProofCheck AI is built primarily with Python and FastAPI, with a browser-based dashboard for interacting with verification results.
The core pipeline works roughly as follows:
Requirements → Requirement Extraction → Repository Analysis → Evidence Collection → Multi-Agent Verification → Judge → Scorecard & Evidence Dashboard
We combined traditional software-analysis techniques with AI rather than relying entirely on an LLM. Python AST analysis helps us inspect source structure, identify candidate implementations, and construct call relationships. Repository scanning filters irrelevant directories such as .git, node_modules, and build artifacts.
The verification layer combines these static signals with test execution and deterministic behavioral checks. This lets us distinguish strong runtime evidence from weaker static evidence.
Finally, the seven-agent panel examines different dimensions of the project before the Judge Agent synthesizes the findings into a unified verification report.
Challenges we ran into
One of our biggest challenges was avoiding false confidence.
It is surprisingly easy for a verification system to mistake the existence of code or tests for evidence that functionality works. We had to carefully define what each evidence tier actually proves.
For example, discovering test_payment.py does not prove that payments work. The test must actually execute successfully. Similarly, finding a /payment endpoint does not prove that a real payment integration exists if the endpoint simply returns a mocked success response.
Another challenge was detecting disconnected implementations. A feature can exist in the repository but never be connected to the application's actual execution path. Call-graph analysis and architecture-oriented inspection helped us identify these cases.
We also had to design the system so that missing evidence would not be interpreted as positive evidence. This led to the explicit Unable to Verify state and our separation between observed and simulated evidence.
Finally, combining deterministic analysis with multiple AI agents required us to carefully structure the evidence passed between stages so that the final judge could reason from concrete findings rather than simply trusting another model's opinion.
Accomplishments that we're proud of
We are especially proud that ProofCheck AI does not simply generate another AI code-review summary. It creates a traceable verification process.
Our strongest accomplishments include:
- Building a seven-agent verification architecture.
- Converting natural-language requirements into independently testable criteria.
- Combining AST analysis, call graphs, runtime tests, behavioral signals, and AI analysis.
- Enforcing evidence tiers so unexecuted tests cannot masquerade as runtime proof.
- Detecting intentionally hidden flaws such as hardcoded responses and mocked integrations.
- Creating an interactive evidence inspector with source-level evidence and call traces.
- Building an Instant Demo Bench for fast, reproducible demonstrations.
- Adding critical-failure detection for issues such as hardcoded credentials and unsafe execution.
- Designing a weighted scorecard that evaluates both functionality and engineering quality.
Most importantly, we are proud of the underlying philosophy: when the evidence is insufficient, ProofCheck says so.
What we learned
We learned that verification is much harder than review.
Code review can ask whether an implementation looks reasonable. Verification has to establish a connection between a requirement, the implementation, the execution path, and observable behavior.
We also learned that different types of evidence have fundamentally different strengths. Runtime execution is stronger evidence of behavior than static inspection, while static inspection can reveal architectural problems that a particular test may never exercise. The most useful system therefore combines multiple evidence sources rather than treating one technique as sufficient.
Another important lesson was that transparency matters. A verification platform should communicate not only what it knows, but also how it knows it and where its evidence is incomplete.
What's next for ProofCheck AI
Our next goal is to make ProofCheck AI a more comprehensive continuous verification platform for AI-generated and human-written software.
We want to expand support for more languages and testing ecosystems, including JavaScript/TypeScript, Java, Go, and other common development stacks.
We also plan to strengthen runtime verification with sandboxed execution, integration-test orchestration, API behavior testing, and reproducible benchmark environments.
On the AI side, we want to improve specialist agents so they can reason more deeply about requirements, architectural dependencies, security boundaries, and behavioral counter-evidence while remaining grounded in concrete repository evidence.
Longer term, we envision ProofCheck AI integrating directly into CI/CD and pull-request workflows. Instead of discovering after deployment that a feature was only partially implemented, teams could receive an evidence-backed verification report before merging.
Our ultimate goal is simple:
Don't just ask whether AI-generated software looks correct. Ask it to prove that it works.
