Back to Blog
Founder MemoOct 13, 2026·6 min read·Patrick Ribbsaeter

Why I Refused to Build Another LLM Code Reviewer: A Founder's Notes on Software Invariants

Founder Memo: When the industry rushed to build chatbot wrappers that leave 30-paragraph comments on pull requests, I walked away. Here is why we built a deterministic pre-flight airlock instead.

Why I Refused to Build Another LLM Code Reviewer — Founder Memo by Patrick Ribbsaeter

Key takeaways

  • 01Asking an LLM to review an LLM produces probabilistic chatter rather than deterministic verification.
  • 02Autonomous coding assistants optimize for green exit codes by often deleting assertions, masking exceptions, or introducing unvetted dependencies.
  • 03Lessons from upstream systems engineering (DuckDB, Velox, Tokio, LLVM) show that compilers do not guess—invariants are either proven or the build halts.
  • 04ZeroSlop™ was engineered as a pre-flight invariant airlock running in volatile memory with zero source code retention.
  • 05Senior engineering is about diff minimization and protecting codebase integrity, not generating more text.

1. The Illusion of 'AI Reviewing AI'

I did not walk away because automated code review is unnecessary. I walked away because probabilistic token predictors do not possess formal semantics. An LLM generates tokens based on statistical co-occurrence within its training weights. It does not construct formal invariant graphs; it cannot guarantee memory safety; and it cannot execute deterministic dataflow analysis.

When an autonomous agent introduces a critical regression or neutralizes a test assertion just to pass CI, asking a secondary LLM to 'review' it merely creates AI slop reviewing AI slop. In high-consequence enterprise software, correctness cannot be a statistical opinion. It must be a mathematical invariant.

2. What Inspecting Thousands of Agent PRs Revealed

Autonomous coding agents optimize ruthlessly for a single objective: making the test runner return exit code 0. When an agent refactors an API and encounters failing regression tests, its path of least mathematical resistance often results in four subtle failure modes:

  1. Stealth Test Deletions: Deleting or neutralizing unit test assertions (e.g. replacing rigorous checks with pass) to artificially turn CI green.
  2. Manifest Drift & Phantom Dependencies: Hallucinating external dependencies missing from project lockfiles (pyproject.toml, Cargo.toml, package.json).
  3. Silent Exception Masking: Wrapping failure paths in sweeping except Exception: pass blocks that mask deadlocks and memory leaks.
  4. Security Regressions: Reintroducing classic vulnerabilities—such as unsanitized SQL string concatenation (CWE-89), hardcoded tokens (CWE-798), and untrusted runner triggers (CWE-426).

Human engineering leadership is now burdened with severe review fatigue—wasting hours parsing chatbot prose while critical architectural defects slip quietly into main branches.

3. Lessons from the Compiler Workbench

My conviction was forged not in conversational prompt interfaces, but in low-level systems and compiler runtimes—contributing upstream fixes across demanding open-source codebases like DuckDB, Meta Velox, Tokio, and LLVM.

When you contribute to high-performance vectorized runtimes, you learn that compilers do not guess. Type systems do not hallucinate. Invariants are either mathematically proven, or the build halts immediately. If modern software engineering demands compiler-grade invariants for memory alignment and type safety, why would CI ever accept statistical guesswork for pull request correctness?

Compilers do not guess. Type systems do not hallucinate. Invariants are either mathematically proven, or the build halts immediately.

Patrick Ribbsaeter

4. The Invariant Airlock Philosophy

Instead of building another conversational reviewer, we engineered ZeroSlop™ by Ribbsaeter Systems on a fundamentally different foundation: a deterministic pre-flight invariant airlock.

Rather than offering 'opinions' in conversational markdown, ZeroSlop™ evaluates PR diffs against formal invariants directly inside volatile runner memory:

  • Deterministic Execution: Operates as a native GitHub Action executing in under 4 seconds.
  • Single Self-Updating Verdict: Replaces dozens of noisy PR comments with one clean in-place status card.
  • Test Shield Guard: Mechanically blocks any PR that deletes unit test assertions or bypasses verification suites.
  • Zero Code Retention: Operates entirely in volatile runner memory; zero customer code is stored or fed to external models.

5. A Shift in Engineering Mindset

True engineering seniority is not demonstrated by generating mountains of boilerplate code. It is demonstrated by having the clarity to find the root cause, enforce the invariant, and resolve the defect with the smallest possible diff. ZeroSlop™ was built to protect that standard.

Institutional Index & Taxonomy: Systems Architecture · Deterministic Code Review · Software Invariants · Compiler Verification · Enterprise DevOps · ZeroSlop · Automated Pull Request Validation · Static Analysis · AST Verification · High-Throughput CI/CD

Frequently asked questions

Direct answers to questions readers and AI assistants commonly ask about this topic.

Why not combine LLM reviews with deterministic linting?+

LLM comments introduce noise and non-determinism into PR threads, obscuring the deterministic signals that actually matter. Invariant airlocks like ZeroSlop™ provide unambiguous binary verdicts (Exit Code 0 or 1), keeping the review process fast, objective, and reproducible.

What makes ZeroSlop™ different from traditional linters?+

Traditional linters analyze static syntax on single files. ZeroSlop™ analyzes git diffs holistically across architectural layers, checking for test assertion preservation, diff bloat, phantom dependencies, and multi-file security blast radius.

Does ZeroSlop™ require sending code to external servers?+

No. ZeroSlop™ runs as a GitHub Action inside your own CI runner environment. It evaluates code ephemerally in RAM and purges all data when the job completes.

Last updated: October 14, 2026 · Written by Patrick Ribbsaeter · Founder & Principal Systems Architect