Let me tell you about the most expensive bug we never shipped.

It wasn’t a bug in the code. It was a bug in how we worked.

The team was building features fast. Designs were done. Code was written. But nothing was reaching production on time. We’d plan for a week, it would take two. Every single time.

For months, we blamed the usual suspects — bad estimates, scope creep, “it’s more complex than we thought.” You know how it goes.

Then we actually looked at where time was disappearing.

It was code reviews.

The thing nobody tells you about code reviews

They’re probably the most disliked part of being a developer. Nobody wakes up excited to review someone else’s pull request.

You’re deep in your own work, finally in the zone, and then — ping. “Can you review my PR?”

So you switch context. Open the PR. And what do you find?

“You missed a semicolon.” “This if condition is wrong.” “There’s a typo in the variable name.”

Important? Sure. But pointing out the same five things for the fifth time this week, while the mental cost of the context switch sits firmly in the senior engineer’s bucket? Soul-crushing.

The marinating PR

On our team, every PR just sat. Marinating.

A developer would finish their work, open a PR, and move on to the next task. The reviewer was busy with their own stuff. By the time they got to it, days had passed. The original author had completely moved on mentally — now they were re-reading their own code trying to remember what they were even thinking.

Project management was losing patience. “Why isn’t this shipped?” “What’s blocking us?” “Can we speed this up?”

But the developers weren’t slow. They were stuck — waiting on each other.

That’s when it landed for us. The easy thing would have been to push people harder. PMs were already doing that. It wasn’t working.

We wanted to fix the actual problem.

The problem was this: senior engineers were spending hours doing something a machine could do. Catching missing null checks. Spotting wrong conditions. Finding typos. All on autopilot.

Their brains could be solving real problems. Instead, they were playing spot-the-semicolon.

That’s not a people problem. That’s a systems problem. And systems problems need systems solutions.

So we built one.

The first-pass reviewer

The idea was simple. What if AI did the first pass on every PR?

Not to replace human reviewers. The point isn’t to fire anyone.

Just to catch the obvious stuff before a human even opens the PR.

We called the tool SherlockQA. It hooks into GitHub, reads the diff when a PR is opened, and:

  • Drops comments on the lines that need fixing.
  • Catches the boring stuff — missing semicolons, wrong conditions, security issues, the edge cases that break at 2 AM.
  • Suggests what QA should test manually.
  • Flags whether unit tests are missing.
  • Gives a clear verdict — ship it / fix this stuff / don’t merge.

What changed

Before SherlockQA, our flow looked like this:

Developer opens PR → waits two days → reviewer finds eight issues → “you missed a semicolon” → developer switches back → forgot what they were thinking → another day of back-and-forth → PM asks for status → everyone’s frustrated.

After SherlockQA:

Developer opens PR → gets feedback in two minutes → fixes the silly stuff before anyone sees → tags a reviewer → reviewer only looks at architecture and logic → ships fast.

Developers started cleaning up small mistakes before requesting human review. No more public “you forgot a semicolon” comments in front of the whole team. They could fix things privately.

When a senior engineer finally opened a PR, they could skip the tedious stuff and focus on what actually needs a human brain — architecture, business logic, the edge cases that need real thinking.

We added a whole new layer to how the team worked. And it scaled without hiring anyone. Every developer who joined got the first-pass review automatically. Quality stays consistent as the team grows.

The unexpected part

We added different personalities to the reviews. Just for fun, at first.

  • Professional — formal, straight to the point.
  • Bro — casual, like a teammate on Slack.
  • Desi — Hinglish mode, “arre yaar yeh kya hai”.
  • Detective — dramatic, Sherlock-style observations.
  • Enthusiastic — your hype-man who loves everything.

Something weird happened. People started actually reading the feedback more carefully.

Tone matters. A comment that sounds like a friend hits differently than one that sounds like an angry linter.

The real lesson

This whole thing changed how we think about engineering speed.

A team’s speed isn’t about how fast they write code. It’s about how fast code moves through the system. Writing is the easy part. Review, approval, merge — that’s where everything slows down.

The answer wasn’t pushing harder. It was removing friction. Give feedback faster. Let people fix mistakes quietly. Free up senior engineers to do what they’re actually good at.

That’s the entire pitch for AI in engineering work, in our experience: not “replace the developers.” It’s replace the stuff the developers secretly hate doing, and let the human brain go back to the parts that actually need it.

SherlockQA is open source — MIT-licensed, on GitHub Marketplace as a GitHub Action. Five-minute setup, your own API key, no per-seat pricing.

→ github.com/mayurrawte/SherlockQA