📋 Overview
In this concise talk, Brainqub3 tackles a problem every engineer, founder, and vibe coder faces: how do you ship a codebase you can't possibly read in full? Drawing on a real client audit of a 100,000-line vibe-coded prototype, he argues that chasing line-by-line understanding is not just impractical — it's mathematically impossible (Rice's theorem, 1953). Instead, he presents a disciplined four-principle architectural review approach and introduces his open-source architecture-as-is Claude Code skill that automates this process: mapping surfaces, tracing real flows, qualifying test evidence, and separating observation from inference. The result is a grounded picture of what the system actually does, plus the risks that block production.
1 The 100K-Line Problem
The setup: you've been handed a codebase — or your agent generated one — that's too large to review manually. It works on someone's machine. Now someone's asking whether it's safe to ship to real users.
On a recent client engagement, Brainqub3 faced exactly this scenario. A client had vibe-coded a prototype and wanted to take it to MVP. The repo contained:
- 100,000+ lines of code
- A serverless database back end
- A front end running locally
- Duplicated logic in multiple places
- Entire sheets of dead code nothing called
And it worked. On the developer's machine, it ran exactly as expected.
The core tension: you need an understanding of the codebase, but you can't possibly read every line. And even if you could, you probably wouldn't understand it. This is where dropping a fundamental assumption changes everything.
2 Rice's Theorem — Complete Proof Is Impossible
In 1953, mathematician Henry Rice published a proof that there is no general procedure that can look at an arbitrary program and decide whether it does what you want. That's Rice's theorem.
This is the foundational insight that took the pressure off. You're not failing at your job when you can't verify every line — no one can. Not because they lack resources, but because mathematics says it's impossible. The goal was never complete proof. The goal is coverage of behaviors that matter.
3 Dijkstra, NIST & The Limits of Testing
If you can't prove correctness by reading code, can testing rescue you? Not fully.
Brainqub3 invokes two authoritative sources:
- Edsger Dijkstra (1970) — "Program testing can be used to show the presence of bugs, but never to show their absence."
- NIST (US standards body) — states plainly that exhaustive testing is nearly always impossible
This reframes the entire audit mindset. You're not pursuing certainty — you're building layered confidence in the parts that matter most for production.
4 How Amazon Verifies at Scale
You might think this is just a resource problem — that with enough money and engineers, you could verify the whole thing properly. So look at the people with the deepest pockets of all.
In 2015, Amazon's engineers published how they verify systems like S3 and DynamoDB. Their approach:
- Design reviews
- Static analysis
- Fault injection testing
- Formal methods on top of everything else
And they still find subtle bugs hiding, because the number of reachable states is astronomical. Even then, they don't prove the whole service correct — they model the parts that matter and check those.
The lesson from Dijkstra, Rice, and AWS combined: stop chasing perfect line-by-line understanding. Focus on the bits that matter most in production. Accept that bugs will exist, and accept that you can't verify every behavior — but you can understand the system at the level that counts.
5 Four Principles for Codebase Audit
Back to the real audit. Brainqub3 didn't set out to read every line or prove the code correct. He needed a picture of what the system actually does. Here are the four principles he worked to:
1. Start from the Repository, Not Documentation
Documentation often doesn't exist for vibe-coded apps. Map what's really there — entry points, custom CLIs, any surface that lets you interact with the system. The surfaces tell you what the system is for and what it can do (its capabilities) before you read a single line of how it works. You learn the shape of the edges.
2. Trace How the System Actually Behaves
Build the true dependency graph, then follow two or three representative flows end to end. You see the real coupling, not the diagram someone intended. A handful of real flows show you how the whole thing ties together without reading every part. This is where reading line by line earns its keep — on a few flows that actually matter, not the 100,000 lines that might or might not.
3. Treat Tests as Evidence, Not Truth
Existing tests are evidence, but you don't take them on trust. Read them as documentation of intended behavior. Run the checks the project already has. Qualify what you find. The tests hand you the behavior the team meant to build, so you learn what it's supposed to do without reading the implementation.
4. Separate Observation from Inference
Separate what you observe from what you're inferring from what you don't know. Surface the implications, not the redesign. Labeling your confidence gives you an honest, actionable picture — you know what you actually understand and where you still need to dig, instead of pretending you've read it all.
6 The Architecture-As-Is Skill
Doing all four principles by hand is a lot of work. So Brainqub3 built an open-source Claude Code skill called architecture-as-is that automates the process.
The skill combines:
- Static analysis of the codebase
- Reading and qualifying existing tests
- The agent's own code reading
- Running the repo's sanity checks — type checks, builds, tests
- Booting the app and watching what actually happens at runtime
The runtime evidence is what promotes an inference to a verified fact. The skill produces an HTML file that makes it easy to review the architecture — locate it in the repo and open in your browser.
Warning: Because this runs live code, you should be running it with appropriate guardrails in place (sandboxes, containers, etc.).
The skill is stack agnostic, with some optional tooling that leans towards JavaScript/TypeScript. If that's not your stack, you can ask the agent to adapt it.
7 Prevention Beats Cure
One honest limitation: the architecture-as-is skill can risk a codebase you inherited, but cleaning it up after the fact is the hard route. Prevention beats cure.
Bake the disciplines in from the start:
- Branch protection and CI — nothing lands until it passes checks
- Test first — the agent builds to a spec
- Architecture skill as a living check — not just a one-off rescue
Lead with that, and one engineer can hold a standard as they vibe code to production.
The Team Problem
The harder problem is holding that line across a team. Put a team of engineers on Claude Code, and standards will drift — everyone settling on their own bar. Brainqub3's answer is his Claude Skills Playbook — a framework for holding teams to one standard when rolling out Claude Code at scale (free download linked from his site).
🎯 Key Takeaways
🔑 Key Takeaways
- You don't need to understand every line — shipping code safely means understanding what matters, not reading everything. Drop the belief that line-by-line comprehension is required.
- Complete proof is mathematically impossible — Rice's theorem (1953) proves there's no general procedure to verify an arbitrary program does what you want. This isn't a resource problem; it's a fundamental limit.
- Testing builds confidence, not certainty — Dijkstra and NIST both confirm that exhaustive testing is nearly always impossible. Work toward coverage of behaviors that matter, not proof.
- Even Amazon doesn't prove whole systems correct — they layer checks (design reviews, static analysis, formal methods, fault injection) and aim them at the parts that matter most.
- Map surfaces before reading code — start from entry points, CLIs, and interaction surfaces to understand what the system does before diving into how.
- Trace real flows, not all flows — two or three representative end-to-end flows show you real coupling. This is where line-by-line reading earns its keep.
- Tests are evidence of intent, not truth — read them as documentation of what the team meant to build. Qualify and verify, don't trust blindly.
- Label your confidence explicitly — separate observation, inference, and unknowns. An honest picture beats a comprehensive fiction.
- Static + runtime agreement = verified — a claim only earns high confidence when the code reading and the live run agree. The architecture-as-is skill automates this dual verification.
- Prevention beats cure — branch protection, CI, test-first, and architecture as a living check from day one. One engineer can hold the standard while vibe coding to production.
🔗 Resources & Links
- architecture-as-is — open-source Claude Code skill for automated architectural review
- architecture-as-is on skills.sh — skill listing and documentation
- Rice's Theorem (1953) — H. G. Rice, "Classes of Recursively Enumerable Sets and Their Decision Problems"
- Dijkstra on Testing (1970) — "Notes on Structured Programming" (EWD249)
- NIST on Exhaustive Testing — Automated Combinatorial Testing for Software
- How AWS Uses Formal Methods (2015) — Newcombe et al., Communications of the ACM