July 07, 2026 • INSIGHTS • Behind the Platform

A Second Set of Eyes on Every Line of Code

How PRISMA tested CodeRabbit, an AI code review tool, across engineering teams, and what the survey data revealed about real impact vs. the promise.

A Second Set of Eyes on Every Line of Code

Even a solid code review process has limits. Time is finite, and no reviewer can foresee how a change in one part of a system might affect something unrelated elsewhere.Marvin Stickel, Engineering Manager at PRISMA, spent a while sitting with that problem before he found a way to address it.We talked to him about how CodeRabbit ended up in our workflow.

PRISMA: You were the one who wanted to test an AI tool within PRISMA's review process. How come?

MMarvin Stickel portrait namearvin: It had been growing in my head for a while. Looking at the code we produce and the kind of bugs that still slip through our review process, I kept asking myself: is there really nothing we can do to catch more of this, without just committing more people or more time to it?

Throwing more reviewers at the problem doesn't hold up in the real world; time is always limited, and no one can fully foresee how a change in one place might affect something completely unrelated elsewhere. Forcing everyone to check everything more thoroughly just creates fear and slows projects down. It's ongoing progress in AI tooling that finally opened a door here: a way to review our code more thoroughly without spending more of our limited resources on it.

PRISMA: Why CodeRabbit specifically?

Marvin: CodeRabbit kept coming up: used in projects I was following, mentioned frequently, and heading in a direction that matched what I had in mind. One thing that especially stood out was a feature I hadn't even considered myself: using our Jira tickets and their acceptance criteria to check whether an implementation actually meets them.

PRISMA: So you proposed a demo run, open to anyone who wanted to try it. How did that go?

Marvin: I raised it in our Community of Practice. The level of interest was genuinely surprising. We ended up enabling CodeRabbit across frontend, backend, and DevOps repositories: essentially our whole tech stack, old code and new. Rather than reviewing only after code is finished and tested, CodeRabbit steps in early, giving feedback as soon as changes are pushed. The human review still happens afterward, just with some issues already resolved or flagged for discussion.

PRISMA: Did anything surprise you?

Marvin: Positively, yes. CodeRabbit could instantly reveal issues a human reviewer would likely never have anticipated: findings based on related code that hadn't even been changed, but could still be affected. The most astounding one: a bug in one of our oldest services that had been sitting undiscovered in the codebase for years. On the other side, it clearly struggled more with our legacy projects, where code quality isn't up to today's standards and some business logic has quirks we've long since accepted as safe to leave alone. It generally does better the more common the technology is, and it comes with a self-learning knowledge base, so we expect it to keep improving.

PRISMA: Did it actually save time?

Marvin: I sent a survey to all participants, so we can say: no, not really. For most of us, the time spent on human code review hasn't decreased, and I think that's fine. It comes down to what you expect from the tool. If the goal is better code quality, it can't also mean less time spent producing it. It depends on the person: some want higher quality, others want to free up time elsewhere while still making sure reviews happen before something ships. CodeRabbit can support either approach, and I like that it doesn't force one or the other.

 

 


 

 


The Numbers Behind the Demo

37 people were invited, 17 responded (a 46% response rate).
58 written comments on top of the ratings.

 

  Score (0-100)
How well suggestions fit our tech stack 88
Overall usefulness 59
Caught issues before manual review 53
Acted on its suggestions 47
Relevance of its comments 41
Reduced manual review effort 29

 

The lowest score was effort reduction: most people didn't see their workload shrink.
The strongest result by far was technical fit.

 

PRISMA: So what convinced you to keep it?

Marvin: The recurring theme across the comments in the survey wasn't "remove it" but "tune it": reduce the noise, teach it PRISMA's conventions, make its output easier to scan. But the most convincing response I got was simply: "When can we have it back?" People actually missed it once it was gone. I had a positive view of the demo myself, but hearing that from others is what confirmed it's a genuinely beneficial addition.

PRISMA: How is the team using it now?

Marvin: On a voluntary basis. Anyone who benefits from it in their workflow can add it. We haven't made it automatic or mandatory. Our teams and individuals work differently, and this is a significant change. We want continuous improvement, not mindless rollout, so we're monitoring how it performs and whether it makes sense to bring into new projects as it keeps proving its value. At the end of the day, it raises the bar for what we ship, and gives us an extra reviewer that catches things earlier, without asking anyone to read code faster than a human can.


Interested in how AI tools like CodeRabbit are shaping the way we build software at PRISMA? This is one story in a series. More to come.

 

 

 

 

 

 

RELATED INSIGHTS

NEWS

Explore PRISMA's activities

Do you want to learn even more about PRISMA? Dive into the PRISMA's News, where we share customer project success stories, exciting events, and a glimpse into our company culture.