Technical Risk
Technical risk is shaped by the cost of being wrong and the difficulty of recovery. These field notes connect code review, software quality, technical debt, and refactoring to the same operating concern: whether a team can change a system with enough evidence, understanding, and reversibility to trust the outcome.
Not every change deserves the same control. Review depth should follow consequence. Debt is useful when its cost and repayment path are understood. Tests and evals should prove the behavior that matters, not merely produce a green check.
Technical Risk Field Notes#
Code Review Is Risk Management
Code review should not treat every pull request equally. Review depth should follow the cost of being wrong, and the reviewer still owns that decision.
Evals Are the New Tests
In April 2025 OpenAI shipped a model update whose offline evals and A/B tests all looked good. It was sycophantic enough to roll back within days. A practical guide to building the measurement layer that would have caught it - with a working eval spec and grading rubric.
Code Was Never the Bottleneck
Your engineers are producing more code and your delivery cadence has barely moved. The waiting did not disappear - it moved downstream to review and absorption, and that is where the constraint always was. Includes a review-capacity audit.
Technical Debt Is a Tool
Technical debt isn't the main problem-loss of trust is; continuous, small refactors keep teams confident and fast.
Refactoring Is How You Keep Moving Fast
How continuous refactoring prevents engineering slowdowns and keeps the cost of change flat over time. Refactoring isn't a cleanup phase—it's the mechanism that preserves feature velocity.