I built a proof layer for AI-coded projects because green tests can lie
I kept running into the same frustrating moment: an AI coding tool said the task was done, the test suite was green, and the issue only appeared when someone used the product for real.
So I built the next Code Factory release around a simpler question:
Can this test actually reject the broken outcome it claims to cover?
First Proof deliberately challenges a declared test with an intentional failure. If the broken path still passes, Code Factory shows the proof gap instead of treating the run as evidence. For a solo builder, that is the whole first use case: one local check before you trust a green result.
Graph Ops then makes the review path visible:
source → approved obligation → forbidden behavior → gate → test → evidence → decision
That makes it easier to see what was actually verified, what is missing, and what still needs a human decision.
For teams using AI agents, the Agent Proof Bridge can inspect a supplied handoff from Junie, Copilot, CodeRabbit, Devin, Eve, Grok Build, or another client. It records local facts behind the work—scope, artifacts, tool/checkpoint hashes, and continuity. It does not run the agent, change code, merge a PR, or release software. The point is a better handoff into human review.
AppForge is the iOS lane: it organizes user design input, storyboard coverage, iPhone/iPad media, accessibility checks, and submission evidence. It cannot promise Apple approval, but it can surface avoidable gaps before the queue—helping reduce repeat-review rework that can otherwise add days.
The boundary matters: Code Factory prepares evidence and makes uncertainty visible. It does not take final approval, publishing, deployment, or credential authority away from the team.
I built this after wasting time on code that looked finished until real use exposed what the green result had missed. I’m releasing v0.9.0 today. If you build with AI, I’d value your bluntest feedback: what would make you trust an AI-assisted change enough to ship it?
Measurement boundary between confidence and reality. Green tests measure "did the code path execute" not "does the code work". The proof challenge injects intentional failure - that's not noise, that's measurement infrastructure. When a test passes the proof failure, it's measuring something real (the broken outcome is actually caught). When it doesn't catch the break, you've made invisible what was hiding. The review path visibility (source → obligation → forbidden behavior → gate → test → evidence) is mapping the measurement system itself so humans can see which layer actually validated the change. That's the precision problem: not "is this good enough to ship" but "which measurements did we actually verify."
The “green tests can lie” problem is real.
What’s the minimum proof you’ve found that makes a solo builder comfortable shipping an AI-coded change?
I have thoroughly tested and can verify from my personal results that Code-Factory has saved a lot of frustration, caught a lot that GPT 5.6 missed, and the prestige design module truly helps review and improve UI design. It's free so try it yourself and your feedback or a star is appreciated.