→ Problem
At Bradesco Seguros, a pull request used to sit in the review queue for close to an hour before anyone even looked at it. Reviewers are busy, so a PR would wait, and once someone finally opened it, a good chunk of what they wrote back was the same handful of comments they'd already made on a dozen other PRs that week.
An off-the-shelf AI review bot doesn't fix that: it reviews against generic best practices, not this project's own conventions, so it either misses what actually matters here or flags things the team does on purpose. What was missing wasn't more review, it was a reviewer that already knew these codebases.
→ Discover
Before writing a single review rule, I had the agent map every repository we had, not just one: a whole constellation of Micro Frontends and Micro Services. The folder structure, the architecture, how logic and API calls are actually written, the types, the config files, the CI/CD setup, how errors are actually handled, which libs get used and how, per repo. Not a style guide someone wrote once and let go stale, the patterns each codebase actually follows most consistently, today.
The other half came from the team's own history: I went through previous pull requests, across those same repos, and pulled out the issues reviewers asked for most often, the recurring feedback that never got written down anywhere, just repeated PR after PR. Between the two, the agent's actual rulebook wasn't something I guessed at, it was learned from these specific projects and this specific team.
Folder structure, architecture, API call patterns, types, config, CI/CD, error handling, libs usage, per repo
The issues reviewers asked for most often
→ Solution & results
That's what runs today: a custom review agent built on the Claude API and AWS Kiro, paired with an MCP server that pulls only the PR's diff, never the whole repository behind it, so the context window never overflows, whichever of the many Micro Frontend or Micro Service repos the PR happens to be in. The same MCP layer also reads the build status from Bamboo and the static-analysis report from SonarQube, so the agent isn't reviewing code in isolation.
Keeps the context window from overflowing, across many repos
- SonarQube report
- Bamboo build status
- Code pattern files
Checks the diff against the discovered patterns, the build status, and the static-analysis report
Posted on the Bitbucket pull request
Checked against the patterns and the recurring issues from the discovery step, it posts both inline comments on the specific lines and a general comment summarizing the review, directly on the Bitbucket pull request.
The result: review time dropped from close to an hour to under ten minutes, a ~90% cut. It wasn't a side experiment that stayed on my machine, either, the whole engineering team adopted it as part of the actual review process, and it's been submitted for a talk at AWS Summit São Paulo 2026.