Experience + Opinion + Fact (50% experience · 35% opinion · 15% fact) — Written in collaboration with AI — I discuss, I do not outsource.

Chapter 1. Hired to Hold the Quality Gate

A Fortune 500 hardware company. An external vendor doing all the firmware and embedded software. A clear mandate. My job: sit between the two. Review every pull request. Catch every defect before it reached the production line. The vendor engineers were competent professionals. Experienced. Working hard under real deadline pressure.

First principle: When you are hired to enforce quality, the first move always looks obvious: review more, catch more. That is not wrong — it is just incomplete.

Chapter 2. The Obvious Solution: Review Everything

The first few months: a grind of pull requests, inline comments, and back-and-forth threads. A missing null check that could corrupt a state machine on edge input. Caught it. Written up. Fixed. An implicit assumption in a sensor driver — the kind that works fine in the lab and surfaces at 2 a.m. on the factory floor. Caught it. Written up. Fixed.

I added structure: review guidelines, a shared doc cataloguing common patterns. Checklist items. A growing reference for the vendor team. For a while, the rate of defects in review slowed. The gate felt like it was holding.

First principle: More thorough review catches more defects. That is true. But it is not sufficient.

Chapter 3. Same Class. Different Module. Every Sprint.

It was never the same bug. It was always the same class of bug — appearing in a new module, written by a different engineer, in a different subsystem, every sprint. A null check missing here. An ownership boundary left implicit there. A state machine embedded in code that was never designed to hold state.

I wrote longer guidelines. I added more detail to the review checklist. The cycle slowed a little. Then it resumed. Each module was a fresh canvas. Each sprint was a fresh opportunity for the same structural hole to reappear in a new location.

First principle: A recurring class of defect is a structural signal. It is the architecture telling you something — not the engineer.

Chapter 4. Review Is a Lagging Indicator

At some point I stopped asking how do I catch this faster and started asking why does this keep appearing.

REVIEW-GATE MODEL (lagging):
Code written → Bug introduced → PR submitted → Reviewer catches it → Fix applied → Repeat next sprint.

ARCHITECTURE-ENFORCED MODEL (leading):
Structure defined → Wrong pattern constrained → Violation surfaces at compile/boot/CI

By the time a bug arrives at a reviewer, the architectural decision that allowed that bug was already made. The module boundary was drawn loosely — that happened weeks earlier, when the design was sketched. Review sees the result. Review cannot see the moment of cause. That moment is in the architecture.

First principle: Review is a lagging indicator — by the time the bug is visible, the structural decision that made it possible is already locked in.

Chapter 5. Quality Has to Be Designed In

In a review-gate model, quality is a person. It lives in the reviewer's judgment, applied after the fact. In an architecture-enforced model, quality is a property of the structure. Typed interfaces between modules. Ownership rules encoded in the build system. State machines that live in files that can only hold state machines. The correct pattern is not just described — it is the only path available.

First principle: Structure enforces what guidelines only describe. The right architecture makes the correct pattern the easy path and the incorrect pattern structurally difficult.

Chapter 6. If You Are Outsourcing Firmware Today

This pattern is not rare. A hardware company hands firmware development to a vendor. The vendor delivers code. The company reviews. Bugs appear. The review process gets heavier. Bugs keep appearing in new modules. The root cause is rarely vendor skill. The root cause is the absence of a structural framework before the first line of code was written.

The point of intervention is earlier than the first line of vendor code. Define the structure before the code begins. Make the architecture explicit. Enforce it in ways that do not depend on a reviewer catching it after the fact.

First principle: The architecture you hand a vendor is the quality floor you will get back. No review process substitutes for a defined structural framework given before the first commit.

Chapter 7. What I Do About This at Ritzy Lab

That year of reviewing pull requests, watching the same class of defect appear in a new module every sprint — that is what changed how I work. At Ritzy Lab, this is the lens we bring to every firmware engagement. Before code gets written, there is an architecture. Before the architecture is handed off, it has been reviewed not for correctness but for structural enforceability — does it make the right pattern the easy pattern?

Next: the specific architecture patterns that make violations visible before runtime — and what it looks like to embed them into a real firmware project from the start.

First principle: The commitment is to put quality in the architecture, not in the review queue. When the structure enforces correctness, review becomes confirmation — not salvation.