Quality is a team habit, not a final check. These posts cover code review, warnings, tooling, and working with AI-generated code—practices that keep a codebase readable, safe, and maintainable.
My role as architect on a vibe-coded project with 4,000+ commits in under three months: an AI review bot, defence in depth and release reviews.
Read More: Three months, 4000 commits, one architect. What working with vibe coding looks like.
AI can write code, but review still decides whether it does the right thing. What changes when the author is a model, and why tests matter more.
Juniors, seniors and architects look for different things in a code review. Why that mix is a strength, and why review is a dialogue.
The start of my code review series: what review is for, why it matters more with AI-generated code, and how other organisations approach it.
Keep style out of code reviews. The tools I use for that: .editorconfig with dotnet format, Roslyn analyzers, ESLint, Spectral and SonarQube.
What I check in a pull request: does it belong, can I follow it, are comments respectful, and are tests, docs and config updated with it.
Warnings are signals. Why I recommend a zero-warnings policy, suppress only the specific instance with a reason, and start with new code.
Refactor your test setup to reduce duplication and make test intent obvious. Baseline + override keeps tests readable, maintainable, and developer-friendly.
Read More: Unit‑Test Code Is Still Code — Apply the Same Standards