Reviewing code you did not write: what catches problems

The bottleneck moved. Writing code stopped being the slow part somewhere around 2025, and reading it never got any faster. A team that produces four times as much code produces four times as much reading, and human reading speed has not changed since the first pull request.

So the useful question is which checks find defects, and which ones only feel like diligence.

Line-by-line reading finds the wrong class of bug

Reading every line catches typos, obvious logic inversions, and style drift. Machines rarely make those mistakes now, and a linter catches them for free when they happen.

What machine-written code gets wrong is different. It calls an API that does not exist but is plausibly named. It handles the case it was told about and silently drops the one it was not. It writes a function that passes its own tests because the tests were written from the same misunderstanding. None of that shows up as a suspicious line. Every line looks reasonable.

Four checks that find things

Run it against the real system. Use the actual database, the queue, the third-party endpoint. A generated integration is confident about response shapes it has never seen. Ten minutes of running beats an hour of reading.

Read the tests before the implementation. If the tests only assert what the implementation happens to do, they prove nothing. Ask what a wrong version would fail, and check that a test covers it. Tests written alongside the code by the same process share its blind spots.

Check the boundaries, ignore the middle. Where does untrusted input enter, and what validates it? What happens on empty, on null, on the value one past the limit? Defects concentrate at edges, and generated code is fluent in the middle and vague at the edges.

Diff the behaviour. For a change to existing code, the question is what changes at runtime, whatever the number of lines moved. A refactor that keeps every test green while changing an error path is the failure mode nobody sees in a text diff.

The habit that catches nothing

Approving because the tests pass. Passing tests written by the same run that wrote the code only tells you the two agree with each other. It is the software equivalent of marking your own homework, and it is the single most common way a defect reaches production in an AI-assisted team.

What we build on top of this

StrucTime Code runs the checks a careful reviewer would run, and hands back what it found rather than a claim that everything is fine: the type check, the test run, the security analysis, and the trace of the software running. The mechanical part of reviewing should not cost an engineer an afternoon.

The judgement stays with you. Whether the feature is the right feature, whether the boundary is in the right place, whether this belongs in the codebase at all: no harness answers that, and none should pretend to.