How AI Saved Me From a Cross-Service Code Review Blind Spot

Whenever the topic of "Artificial Intelligence in software engineering" comes up, the conversation usually swings to one of two extremes: either AI is going to replace developers tomorrow, or it's just an overhyped code generator that produces bugs.

I don't really identify with either side.

I'm still exploring where these tools genuinely add value. Lately, I've been trying to use them in places where I actually feel pain as a backend engineer—not to generate code from scratch, but to help me during Code Reviews.

And one recent experience made me realize that AI can be surprisingly useful in distributed systems. Not because it writes better code, but because it helps recover something we often lose: context.

A Small Change Can Have a Massive Impact

One thing I've noticed while reviewing Pull Requests (PRs) is that we naturally focus on what's right in front of us.

We open the diff, review the implementation, check naming, architecture, tests, and validate if the new logic makes sense. That's exactly what we should do.

But in systems composed of dozens of microservices, the change we're reviewing is rarely isolated. A small modification can affect a neighboring service, a shared database table, an event contract, or an internal convention that lives in another repository entirely.

Keeping all of that fresh in your head at the same time simply isn't realistic.

A Real (and Silent) Catch

Recently, I decided to experiment with AI as part of my review workflow.

I configured my editor with a few tools, spent some time refining prompts focused on our project's architecture, and started asking the model to reason about the broader system instead of just the modified files.

During one review, the change looked perfectly reasonable.

A service was persisting a failed operation into a shared database table using the following status:

{
  "status": "Rejected",
  "reason": "timeout"
}

Nothing looked wrong. The implementation was clean, the logic made sense, and the PR probably would have been approved without much discussion.

Then, the AI raised a simple observation:

"Another service that reads and writes from this shared table has historically used the value Rejected Exception for this same scenario."

That was enough to make me stop.

The issue wasn't whether Rejected was a better name than Rejected Exception. The real issue was that we were about to introduce a silent inconsistency into a shared contract.

Maybe nothing would break immediately. But weeks or months later, someone might build a report, add a filter, create a dashboard, or write a new integration assuming those values were standardized.

Those are exactly the kinds of inconsistencies that are easy to introduce and surprisingly expensive to trace and fix later on.

The AI Didn't Make the Decision

This experience reinforced something I've been thinking about for a while.

As I always say around here: Clean code is not about beauty — it's about predictability.

The AI didn't redesign the architecture. It didn't tell me which naming convention was correct. It didn't decide whether we should keep the existing value or refactor all services to a new standard.

That decision—the architectural trade-off—still belonged to the engineering team.

What the AI did was expand my peripheral vision. Instead of reviewing a single Pull Request in isolation, it connected information across services and surfaced a detail I probably wouldn't have remembered during a normal, fast-paced review.

Where I See the Real Value

I've also had the opposite experience.

Sometimes, the AI suggests changes that don't make sense. Sometimes, it completely misunderstands the business rules. Sometimes, it just creates noise that I have to ignore.

That's why I don't believe AI should ever replace engineering judgment. But I do believe it can be an excellent assistant when the challenge isn't writing code, but understanding how different pieces of a complex system relate to one another.

For me, that has been one of the most practical applications of AI so far.

Not replacing developers. Just helping to reduce the massive amount of context that inevitably gets lost when we work across multiple microservices.

Key Takeaways

• Connecting Context: AI shines in Code Reviews by cross-referencing contexts from different repositories, services, and shared contracts in seconds.

• Inconsistencies Become Debt: Small standardization drifts in distributed systems usually turn into technical debt long before they become visible bugs.

• Judgment is Human: Engineering and architectural decisions still belong to engineers. AI should provide hidden context, not replace critical thinking.

• Better Questions: The best AI experiences I've had weren't about writing code faster, but about how the tool helped me ask better questions during the review process.

---

📣 What about your team?

How are you approaching this? Have you experimented with AI during your code reviews? Has it helped you catch issues you might otherwise have missed, or has it mostly generated noise?

I'm genuinely curious to hear different experiences in the comments!

👉 Follow my articles on the official blog at byRodovalho.com and let's keep this conversation going here on LinkedIn.

🔖 Found this insight useful? Share it with that teammate who reviews microservice PRs with you!