Quality, debt and AI tools
As tech lead you own the health of the code, and you cannot review every line yourself. This lesson gives you three working systems for the Store app team: a code review culture that keeps work moving and teaches, a technical debt register that turns complaints into costed decisions, and written team rules for AI coding tools whose effect you actually measure.
By the end you can
- Set review rules that keep pull requests small, answered within a working day and clearly labelled
- Sort a piece of technical debt with Martin Fowler's quadrant and choose the right response
- Cost each debt item in hours lost, incidents and risk, and rank items by payback
- Agree a steady debt budget per sprint with your product manager
- Write team rules for AI coding tools and measure whether they help
The everyday picture
Think of a busy restaurant kitchen. Every plate stops at the pass, where the head chef looks at it for a few seconds before it goes out. She says "fix this now" about cold sauce and "next time, less salt" about small things, and the cooks learn from both. If plates waited ten minutes at the pass, the food would go cold, so the check has to be quick.
The kitchen also has an oven door that does not close properly. Every cook knows the trick: lean on it with a hip. It costs a minute here and there, and one Friday a tray of bread burns. Nobody decided to keep the broken door. It stays because nobody has put a number on what it costs. Then a new food processor arrives. It chops in seconds, but the cook who uses it still tastes the dish, and nobody feeds it the customers' booking list. A good head chef runs all three: a quick pass, a list of what is broken and what it costs, and rules for the new machine.
A review culture that keeps work moving
Code review has two jobs. It catches problems before they reach the scanners in 320 stores, and it spreads knowledge so that more than one person understands each part of the code. Both jobs fail when reviews are slow, because people respond to slow reviews by making bigger pull requests, and big pull requests get skimmed. You already know the mechanics from Pull requests and code review. As tech lead your job is the team's rules, written down in the team playbook (Your team's engineering playbook).
Four rules do most of the work.
- Small pull requests. Google's public engineering practices guide makes the case that small changes are reviewed faster and more thoroughly, and are easier to roll back. A team rule of thumb such as "under about 400 changed lines, one purpose per PR" is easy to check. Big features are split into a chain of small PRs behind a feature flag.
- An answer within one working day. The same guide says one business day is the maximum time to respond to a review request. The first answer can be a full review or "I will look this afternoon", but it is never silence. Reviewers pick up reviews between their own tasks, before starting something new.
- Labelled comments. Each comment says whether it blocks the merge. The Conventional Comments format gives you labels such as
issue,suggestion,questionandnitpick, with a decoration like(blocking)or(non-blocking). Google's guide uses a "Nit:" prefix for small points of polish the author may ignore. - Approve when the change makes the code better. Google's standard is that reviewers should favour approving a change once it definitely improves the overall code health, even if it is not perfect. Perfection is the wrong bar, because it makes every PR wait for the reviewer's personal taste.
Reviews also teach. A comment that says "this breaks if the count syncs twice; see how the GRN sync uses an idempotency key" teaches more than "wrong". Rotate reviewers so that knowledge spreads: Joel reviews Sam's code too, and learns by asking questions. And stop being the reviewer of everything. If every PR waits for the tech lead, you are the bottleneck, and the team never learns to judge quality without you. Review the risky areas yourself (sync, data migrations, anything touching stock numbers) and read a sample of the rest.
Quick check
Hugo leaves 14 comments on Mira's PR. They all look equally important, and Mira cannot tell which ones must be fixed before merging. What is the best change to the team's rules?
Labels tell the author what must change now and what is advice, and the advice is still shared, which helps Mira learn. A limit of five comments hides useful feedback. A second approval from the tech lead makes the wait longer and makes you the bottleneck. A weekly meeting slows every PR by days.