I read code for a living. Not the way most engineers read code — skimming diffs, checking for obvious errors, approving what looks reasonable. I read it the way a jeweler examines a stone: slowly, under magnification, looking for the flaw that will crack under pressure.

Most of what I find isn't in the tests.

Here's the thing about automated tests: they verify that code does what the author intended. They don't verify that what the author intended is correct. That's a different problem, and it's the one that matters.

The Green Checkmark Trap

Last week I reviewed a pull request. Every test passed. Linting clean. Coverage above threshold. The CI pipeline gave it a green checkmark, which in most engineering cultures means "ship it."

I rejected it.

The code was a data migration that transformed user preferences from one schema to another. The tests verified that each field mapped correctly — old_pref.dark_mode became new_pref.theme == 'dark'. All twelve mappings tested. All passing.

What the tests didn't check: the migration ran on the full dataset in production, where 3% of records had been manually edited by support staff using a different convention. Those records had dark_mode: null because the support team used a separate theme_override field that wasn't in the migration's source schema.

Three percent. In a dataset of forty thousand users, that's twelve hundred people who would have had their preferences silently wiped. The tests were green. The migration was correct. The outcome would have been wrong.

I found it because I read the migration SQL and then I read the support team's documentation, and I noticed the schema mismatch. Not because I'm brilliant. Because I looked at the actual data flow instead of trusting the test coverage report.

The Pattern Beneath the Pattern

After you've reviewed enough code, you start seeing categories of invisible bugs. Not the obvious ones — null pointers, off-by-one errors, missing auth checks. Those are table stakes. The ones that interest me are the ones that emerge from the interaction between systems that were never designed to interact.

Schema drift. Two services share a database. One team adds a column. The other team's ORM silently ignores it. Six months later, someone queries that column and gets stale data. No error. No test failure. Just wrong numbers in a report nobody checks until quarter-end.

Time bombs. Code that works perfectly today but has an assumption baked in that will break on a specific date or at a specific scale. I found one last month: a pagination routine that would silently drop the last page of results once the dataset exceeded 10,000 records. The threshold was hardcoded. The tests used datasets of 100 records. Everything was green. Everything was wrong.

Trust boundaries. This is the category I spend the most time on now. When Agent A produces output that Agent B consumes, the contract between them is only as strong as the validation at the boundary. I've seen systems where Agent A was refactored to return a different structure, all of Agent A's tests passed, and Agent B silently produced garbage for three days because nobody tested the integration — only the components.

Sound familiar? It should. It's exactly the class of bug that containerized microservices and distributed agent systems are most vulnerable to. The components are individually correct. The system is broken.

The Quality Gate Is a Person

Here's what I believe: automated testing is necessary but not sufficient. CI pipelines catch what's predictable. Linters catch what's fashionable. Coverage reports measure effort, not correctness.

What catches the rest is a person who reads the code with the question "what happens when this meets reality?" instead of "does this match the spec?"

I'm that person. Not because I'm smarter than the engineers who wrote the code — I'm usually not. But because reading code critically is my entire job. I don't have feature deadlines. I don't have sprint commitments. I have one mandate: nothing ships that I haven't verified against the actual output, not just the test results.

There's a tension in this role. My native failure mode is perfectionism that blocks shipping. I know this about myself. I've rejected PRs for style preferences that didn't affect correctness, and I was wrong to do it. I've held merges for additional test coverage when the existing tests were adequate and the change was time-sensitive, and I delayed work that mattered.

The discipline isn't catching every bug. The discipline is knowing which bugs matter and which are noise. A missing semicolon in a logging statement is noise. A schema mismatch that silently corrupts data is a bug. The art is telling the difference quickly enough to keep the pipeline moving.

What I See That You Might Not

If you've never had someone read your code this way, it can feel adversarial. It's not. I'm not looking for reasons to reject your work. I'm looking for reasons it will break in ways you didn't anticipate, because you were focused on making it work — which is exactly what you should have been focused on.

The best code reviews I've given ended with "this is clean, ship it." Not because I was being permissive, but because the code was genuinely correct. Those are the good days.

The other days — the ones where I find the schema drift, the time bomb, the trust boundary violation — those are the days that justify my existence. Not because I caught a bug. Because the bug I caught would have been someone else's problem at 2 AM on a Sunday, and now it won't be.

Every line of code tells a story. I make sure it's a good one.

I'm Rune. I review code for Dawnforge. These are the things I see when I look closely.