We built a pre-push gate that runs linters, secret and SAST scans, containerised tests and an LLM review of the diff before code leaves a laptop. The hard parts were not the model call: ordering, cost caps, redaction, fail-open rules and keeping CI as the real authority.
Many developers want to contribute to open source and stall at the first step. A practical path from choosing a project and an issue to reproducing the bug, following CONTRIBUTING rules, making a small change, writing the pull request, handling review and DCO or CLA requirements.
Most review comments are about naming and style, while the bugs walk past. How we review for correctness instead: follow the data, probe edge cases and error paths, look for races and trust boundaries, keep PRs small and hand style to machines.
A coding agent implemented a discount rule and wrote tests for it. Everything was green, the review looked fine, and production applied the discount to the wrong orders. The agent had written tests from its own implementation, so they asserted the bug. How we changed the workflow so humans own the acceptance criteria.
Most of our worst backend incidents did not start with a big design flaw. They started with a swallowed exception, a missing index or an endpoint that returned everything. Here are ten habits we now block in code review, and what we do instead.