"After the first couple of PRs, we knew that we didn't want to remove cubic."
— Bu, CTO and co-founder at Resend

We recently caught up with Bu, CTO and co-founder of Resend, to talk about how they handle code review at scale.

For context, Resend is the email API that developers actually like. They process billions of emails for companies like Supabase, Mistral, and Raycast. The team ships code every single day across their dashboard, API, SDKs, and open source projects. 

That pace of shipping is intentional. It's also what makes their approach to code review so interesting.

The scaling challenge every team hits

"Reviewing PRs is hard, and it gets harder as the company grows."

"Reviewing PRs is hard, and it gets harder as the company grows," Bu tells us. "You don't always have the context you need."

It's a familiar story. When Resend was smaller, everyone touched every part of the codebase regularly. Review was straightforward because everyone had context on the whole codebase. But as they've grown, engineers are increasingly reviewing code in areas they haven't worked on recently.

"Every day we have a bunch of PRs going out," Bu says. "We don't really do code freezes, we're always shipping."

With PRs flowing constantly across multiple repos, the review burden compounds. Engineers have to review code outside their immediate area. The kind of friction that gradually slows teams down.

"That's how regressions happen," Bu notes.

Resend's pragmatic approach to AI tools

"We use AI as part of the process, not the process."

Before we dive into how cubic fits in, it's worth understanding Resend's philosophy on AI tools.

"We're not super AI heavy in terms of product," Bu explains. "But we're not afraid to try new tools."

When engineering candidates ask if they can use AI for take-home exercises, Resend's answer captures their stance perfectly: "Use AI as part of the process, not the process."

They try things. They keep what delivers real value. They drop what doesn't. No dogma, just results.

The cubic experiment that stuck

"It was free to try, so we gave it a shot, and it surprised us."

Bu describes their first experience with cubic casually, almost surprised by how quickly it proved valuable.

"It was free to try, so we gave it a shot, and it surprised us," he says. Then the key moment: "After the first couple of PRs, we knew that we didn't want to remove cubic."

What actually changed in their workflow

"We'll often wait for cubic to finish reviewing. It gives us extra confidence before shipping."

The initial wins were subtle but meaningful. cubic generates PR summaries and descriptions that give reviewers immediate context.

"Even something small, like the PR summary, gives reviewers a lot more context," Bu says.

For a team pushing multiple PRs daily, that context saves real time. But the more interesting change was behavioral.

"We don't block PRs on cubic, at least not yet," Bu tells us. "But we'll often wait for cubic to finish reviewing. It gives us extra confidence before shipping."

That's voluntary adoption. The team chooses to wait because the signal is worth it. No policy required.

Beyond bug catching: encoding team patterns

"Rules help us reinforce patterns in the codebase. Even when it's not a bug, rules help us stay consistent."

We asked Bu about cubic's rules feature, which lets teams encode their specific patterns and conventions.

"Rules help us reinforce patterns in the codebase," he explains. "Even when it's not a bug, rules help us stay consistent with how we write code."

This resonated with Resend's growth phase. As you add engineers, maintaining consistency becomes harder. The same feedback appears on PR after PR. Different reviewers explain the same patterns differently.

Now those patterns are captured once and applied consistently. It's how you scale engineering culture without endless repetition.

What Bu wants next

"We'd love a way to run cubic across the whole codebase, not just new diffs."

When we asked about improvements, Bu's wishlist was specific and practical.

"Performance on CI, getting the checks faster, would be a big improvement," he says. For a team shipping this frequently, every minute in the feedback loop matters.

He also wants broader coverage: "We'd love a way to run cubic across the whole codebase, not just new diffs. Trigger it across the entire repo and scan the whole codebase for issues."

That's the natural evolution. Once you trust a tool on new code, you want that same review on your existing codebase.

The bottom line for fast-shipping teams

Resend processes billions of emails for thousands of developers. They ship constantly because that's how they stay ahead. But that pace only works if you can maintain quality.

Bu and his team didn't adopt cubic to slow down and catch every possible issue. They adopted it to maintain confidence while moving at their natural speed.

"After the first couple of PRs, we knew that we didn't want to remove cubic," Bu reflects.

For teams that ship like Resend ships, that extra confidence before merging isn't a nice-to-have. It's how you keep quality high when stopping isn't an option.