Generated isn’t done. Verified is.

Start with the requirement

A code review should ask whether a change solves the agreed problem. Clean-looking code can implement the wrong behavior perfectly. We compare the implementation with the acceptance criteria before getting lost in style.

For a customer portal, that means checking which customer can access which record, what happens when a session expires, and how a failed request appears to the user.

Test the boundaries

Happy-path tests are necessary, but they rarely cover the hardest failures. We check empty input, invalid state, missing permissions, duplicate requests and unavailable dependencies where those cases matter to the feature.

Generated tests can repeat the same misunderstanding as generated code. Useful tests assert behavior independently. A test for invoice access should try a different customer’s invoice, not just confirm that the database function returns a record.

Ask a second reviewer

Another model may spot a missing assumption or an unsafe change. It can be a useful additional review, but two models agreeing does not make a claim true. We still inspect documentation and execute the relevant checks.

Approve the release, not just the diff

The final question is whether the change is ready for its environment. Configuration, migrations, monitoring and rollback deserve attention alongside application code. A human owns the approval and the resulting production behavior.

See our quality process and how we structure the work.