Alternative Approaches to Code Reviews

Last night, I was chatting in the hotel bar with a bunch of conference speakers at Goto-CPH about how evil PR-driven code reviews are (we were all in agreement), and Martin Fowler brought up an interesting point. The best time to review your code is when you use it. That is, continuous review is better than what amounts to a waterfall review phase. For one thing, the reviewer has a vested interest in assuring that the code they're about to use is high quality. Furthermore, you are reviewing the code in a real-world context, not in isolation, so you are better able to see if the code is suitable for its intended purpose. Continuous review, of course, also leads to a culture of continuous refactoring. You review everything you look at, and when you find issues, you fix them. My experience is that PR-driven reviews rarely find real bugs. They don't improve quality in ways that matter. They DO create bottlenecks, dependencies, and context-swap overhead, however, and all that pushes out delivery time and increases the cost of development with no balancing benefit. I will grant that two or more sets of eyes on the code leads to better code, but in my experience, the best time to do that is when the code is being written, not after the fact. Work in a pair, or better yet, a mob/ensemble. One of the teams at Hunter Industries, which mob/ensemble programs 100% of the time on 100% of the code, went a year and a half with no bugs reported against their code, with zero productivity hit. (Quite the contrary—they work very fast.) Bugs are so rare across all the teams, in fact, that they don't bother to track them. When a bug comes up, they fix it. Right then and there. If you're working in a regulatory environment, the Driver signs the code, and then any Navigator can sign off on the review, all as part of the commit/push process, so that's a non-issue. There's also a myth that it's best if the reviewer is not familiar with the code. I *really* don't buy that. An isolated reviewer doesn't understand the context. They don't know why design decisions were made. They have to waste a vast amount of time coming up to speed. They are also often not in a position to know whether the code will actually work. Consequently, they usually focus on trivia like formatting. That benefits nobody.

I'm BANNING code reviews for MVPs immediately. We spent 2 weeks reviewing code for features that got 0 user engagement. Here's the data that changed everything: WITH code reviews: -  Average MVP delivery: 14.3 weeks -  Average cost: $47,000 -  Time to first customer feedback: 16+ weeks WITHOUT code reviews: -  Average MVP delivery: 8.1 weeks -  Average cost: $20,000 -  Time to first customer feedback: 9 weeks The faster MVPs had HIGHER success rates. Not because the code was worse, but because speed gave founders something more valuable than perfect code Here's why: LEAD DEV: "But we need thorough code reviews for quality!" ME: "Quality for WHO? 96% of startups fail. Our clients need market validation, not perfect architecture." LEAD DEV: "What about scalability?" ME: "95% of MVPs die before they need to scale. We're optimizing for the wrong metric." LEAD DEV: "This goes against everything we learned in engineering school!" ME: "Engineering school doesn't teach you that speed to market beats perfect code for early-stage startups." Customers don't care about your code quality.  They care about solving their problem. MVPs aren't about building the perfect product.  They're about proving a hypothesis as fast as humanly possible. If something breaks? Fix it fast. Ship the patch in hours, not weeks. Our new "MVP Velocity Protocol": 1. ✅ Security reviews (non-negotiable) 2. ✅ Basic functionality testing 4. ❌ NO code reviews 5. ❌ NO refactoring for "best practices" 6. ❌ NO premature optimization The result? Our clients are validating ideas 6 weeks faster and with 44% less budget burn. One founder told me: "Your 'messy' MVP helped me realize my idea was wrong before I spent $50K. Now I'm building something that actually works." IMPORTANT:This applies ONLY to MVPs. Once you hit product-market fit and have real users, we implement full code review processes immediately. Founders: Would you rather have perfect code that launches in 4 months, or "good enough" code that validates your idea in 6 weeks?

Code reviews aren't about finding bugs. If that's all you're doing in reviews, you've already lost. I've seen teams spend hours debating variable names and missing the actual problem: the code works, but nobody else can maintain it. Here's what code reviews actually catch: The junior engineer who hard-coded a feature that should be configurable. Not a bug. But you just locked yourself into technical debt that'll take 6 months to fix. The senior engineer who built something clever. Too clever. It works perfectly but breaks the moment someone else touches it. The architect who designed a system only they understand. No tests. No docs. Just "trust me, it works." Then they go on vacation and the system breaks. These aren't bugs. They're decisions that will hurt you later. Good code reviews ask different questions: • Can someone else debug this at 2am? • Will this still make sense in 6 months? • What happens when we scale 10x? • Are we building the right thing? Most teams optimize code reviews for finding syntax errors. Your IDE already does that. The real value is catching the decisions that look fine today but become disasters tomorrow. If your code reviews only find bugs, you're using them wrong. What's the worst "it works but..." code you've caught in review? #SoftwareEngineering #CodeReview #EngineeringLeadership

I don’t think the main primary purpose of code reviews is to catch bugs. Most dev do. They’ll tell you reviews are about quality control. But I disagree. The most valuable part of a code review is knowledge transfer. Here's why: - Developers usually test their code before opening a PR - Most teams already use linters, static analysis, and CI to catch issues What teams do not do enough of is share why the code was written a certain way and capture architectural decisions so future engineers understand the tradeoffs On a fast moving distributed team it is impossible for everyone to be in every call or track every ticket. Code reviews become the last line of defense for distributing knowledge Here are 4 ways to make code reviews a knowledge sharing superpower: 1. Always explain the “why” behind your code, not just the “what" 2. Document architectural decisions either in the PR itself or by linking to an ADR 3. Summarize the PR in plain English so anyone can quickly understand what changed and why 4. If a decision was made in Slack or a meeting, record it in the PR so it is not lost

Whatever your sector calls it—ATO, accreditation, certification, audited—big-bang reviews create stale evidence. You pause the mission so paperwork can catch up, and risk quietly piles up in the gap. The alternative is simple and stubbornly practical: generate evidence as you change. Treat controls like code. Let your pipeline create the body of evidence automatically with each commit. Move security reviews into dev so risk decisions are documented where the work happens. Promote only what meets policy. Then sit down quarterly with real trendlines—lead time, change frequency, change failure rate, time-to-remediate—and talk about risk with data instead of theater. The payoff is calm and compounding: code freezes drop to zero, lead times fall, 2 a.m. heroics fade, and regulator conversations get boring in the best way. This pattern travels—from the battlefield to the VA clinic, because trust and uptime are non-negotiable anywhere. If you mapped one thing to an automated check tomorrow, which would it be and what would that unlock for your team?

3:47 AM on a Tuesday. My phone buzzes. PagerDuty alert. The system is down. I scramble to my laptop. Database connections maxed out. API timeouts everywhere. Users can't access the service. We get it back up. Block the offending caller. System stabilizes. The post-mortem hits differently. Two experienced engineers reviewed the PR. Tests passed. Code worked exactly as specified. But nobody asked one question: "How would someone abuse this?" That single question would have saved us. One line of code. Five minutes. Crisis prevented. Here's what I learned after years of causing (and fixing) production incidents: Code review isn't about what to check. It's about how you think. Most engineers do one of two things: • Rubber-stamp with "LGTM" • Spend hours arguing about formatting Both miss the real problems. I tried comprehensive checklists. Ran formal review sessions. Eventually everyone burned out. Then I found something that actually works. Three focused passes. Each with a different persona. Each asking different questions. Pass 1: Does it work and make sense? Pass 2: Can we live with this code in six months? Pass 3: How would I break this? I wrote the full breakdown of the three-pass system, including exactly what to look for in each pass and how AI can help. https://lnkd.in/ehSMw8ka

Unpopular opinion: Your senior engineers shouldn't review most PRs. AI tools generate code faster than ever. But code reviews still take 5 days on average. We've created a new bottleneck. And it's burning out your best people. Google's Addy Osmani called it out recently: "Code review is becoming the new bottleneck... we tend to have finite senior engineers." Human code review was never that effective anyway. The research is humbling: Formal inspections catch 55-65% of bugs (Capers Jones, 12,000 projects) Informal reviews catch less than 50% 75% of review comments aren't even about bugs. They're about maintainability. Meanwhile, AI code review tools hit 42-48% bug detection in 2025 benchmarks. That's approaching human-level on pattern-based issues. So what's the play? Let AI triage your PRs: Doc updates → auto-approve Simple refactors → AI review + merge New features → AI first pass + human sign-off Auth/security/architecture → always human One team cut first feedback time from 42 minutes to 11 minutes using this approach. The goal isn't replacing human judgment. It's stopping your senior engineers from being expensive spell-checkers. I'm experimenting with AI reviewing AI-generated code right now. Early results are promising. What's your code review bottleneck look like?

I changed how I do code reviews. Instead of starting with "what's wrong," I now start with: "Show me the part you're most proud of." Then: "What was the hardest decision you made here?" What I learned: When you lead with criticism, people get defensive. When you lead with curiosity, they open up about the tradeoffs they made. And THAT'S when you can actually help them get better. The bugs get caught either way. But this approach builds engineers who think critically, not engineers who wait to be told what's wrong. How do you approach code reviews? hashtag#EngineeringLeadership hashtag#CodeReview hashtag#TeamCulture hashtag#PriorityDriven hashtag#TechnicalLeadership

Does manual code review still matter the same way it used to or has AI changed the game? Traditionally, we’ve asked two things of code: 1. Deliver the required capability correctly. 2. Stay within cost constraints of time and money. Today, we can go further : One LLM can generate code from requirements, another can generate tests from the same inputs, and a third can perform the review. Running them adversarially and iteratively increases alignment with what was actually intended. But this shifts how we define quality : Beyond correctness, we now need documentation, security, reliability, performance, maintainability, compliance, and provenance. Add to that: Traceability: Why did the system choose this design? Observability: Can we detect regressions early and automatically? Which raises a deeper question: Do we still need human code reviews at all? Or should we shift left : putting the human in the loop at the beginning, to define requirements, constraints, risks, and context, and then let AI generate freely within those guardrails? Are we moving toward a world where AI-generated code becomes untouchable by humans? I’d love to hear how your teams are approaching this. Where do you keep the human in the loop? #AIinPDLC #CodeQuality #AIDrivenDevelopment #SoftwareDevelopment

Code reviews don’t make changes safe. At least not the way most teams do them. The paradox? The more code you change...the less time people actually spend reviewing it. Reviews become surface-level: - PR descriptions nobody reads - CI logs skimmed at best - Nitpicks on style instead of design That’s not catching risks. That’s just paperwork. Here’s how I flipped it: 1. Auto-generate PR summaries straight from git diff 2. Summarize CI failures in seconds 3. Get a risk-focused review draft before I dive in Now I can focus on what reviews should be about: architecture, risks, and trade-offs. Coding agents (Claude Code, Cursor, Augment Code) generate the code. CodeRabbit CLI reviews it, catching bugs, security issues, and AI hallucinations before they hit main. Fast code is easy. Safe code is rare. This setup gives me both.