What it really takes to bring a new model online at CodeRabbitの意訳です。

以前公開した この記事 では、ユーザー自身がモデルを選ぶべきではない理由を「好みの問題ではなく、システム上の問題である」と説明しました。本記事では、その理由を具体的に解説します。

CodeRabbitで新しいモデルを導入することは、スイッチを入れるだけの単純作業ではありません。高い精度、膨大な検証、継続的な監視を要求する多段階のプロセスです。

数カ月おきに、「次レベルの推論力」「より長いコンテキスト」「高速化」といった触れ込みとともに新しい大規模言語モデルが登場します。多くの開発者は、単純に「差し替えて使えばいい」と考えるかもしれません。

その気持ちは理解できます。しかし私たちにとって、新しいモデルの採用とは好奇心ではなく、数週間にわたるエンジニアリングプロジェクトです。

お客様がその裏側を見ることは基本的にありませんし、見る必要もありません。CodeRabbitが“自然でシームレス”に見える理由は、私たちが水面下で膨大な評価・調整・検証を行い、本番レビューに触れる前にすべてのモデルを仕上げているからです。ここでは、その舞台裏を紹介します。

1. 好奇心フェーズ：モデルの「素性」を理解する

すべての新モデルは「仮説」から始まります。そのモデルが何を得意とし、どんな設計思想を持ち、どのような改善を謳っているのかを徹底的に調べます。それが推論寄りなのか、コード寄りなのか、あるいはその中間なのか。そして、CodeRabbitのレビューシステムのどの層で活かせるのかを分析します。

私たちが問うのは「このモデルは他より優れているか？」ではなく「このモデルはどこにフィットするか？」です。高度な推論を必要とする差分解析向きかもしれませんし、要約や説明タスクに向くかもしれません。それぞれに求められる品質やトーンは異なります。

ここから大量の実験を作成します。1〜2件ではなく、温度感、コンテキストの詰め方、指示文の書き方など、数十パターンの評価設定を生成します。これらはすべて評価ハーネスに流し込み、量的・質的両面から結果を測定します。

2. 評価フェーズ：印象ではなくデータで判断する

評価フェーズは時間を要します。内部の評価セットを使い、カバレッジ、精度、ノイズ量、レイテンシといった明確な指標を収集します。これらは、以前紹介した各種ベンチマーク記事と同じ指標です。

しかし、数字だけでは全体像は見えません。生成されたコメントそのものを精査し、推論の正しさ、事実性、スタイルの一貫性などを、現在の最良モデルと比較して確認します。さらに複数の自動評価レシピを用いることで、トーンや明瞭性などの微細な違いも分析します。

なぜこれが必要なのか？
それは、モデルは決して“互換品”ではないからです。同じプロンプトでもモデルが変わると動作が崩れます。それぞれに固有の「プロンプトの物理法則」が存在します。私たちの仕事はそれを把握し、システム内で安定して働くよう調整することです。

3. 適応フェーズ：モデルの癖を馴らし、使える形にする

モデルの得意・不得意が分かったら、次は調整です。フォーマットの揺れを正す、冗長さを抑えるといった単純な調整のこともあれば、モデル固有の“語り口”をユーザーが期待する簡潔で実務的なトーンに戻す必要があることもあります。

この作業は勘では行いません。しばしばモデル自身に「自分の出力を批評させる」アプローチを取ります。

例：
「このコメントは謝罪的すぎる。元プロンプトに基づいて、より直接的な表現にするにはどう直すべきか？」

このようなメタフィードバックにより、単純な試行錯誤より高速にプロンプト改善案を生成できます。

また、モデル提供企業とも密に連携し、境界事例、バグ、不整合などを細かく共有します。モデル側で修正されることもあれば、私たちがプロンプト側で癖を吸収する場合もあります。

4. ロールアウトフェーズ：研究室から実環境へ

オフラインで安定性が確認できたら、段階的な本番投入に移行します。

最初は社内チームで実運用テストを行い、次に少人数の外部ユーザーが参加する早期アクセスへ進みます。最後は、組織規模、リポジトリの種類、PRの複雑性に応じて均等に配信されるよう、ランダム化されたゲーティングで段階的に拡大します。

監視対象は以下のように、多岐にわたります。

• コメント品質と採択率

• レイテンシ、エラー率、タイムアウト

• 開発者からのフィードバック傾向

• 提案の精度変化

1つでも異常があれば、即ロールバックまたは配信制限を行います。原因がプロンプト起因なのか、スタイル変化なのか、本質的なモデルの問題なのかを迅速に調査します。

5. 安定フェーズ：運用後も続く監視と改善

モデルが安定したように見えても、仕事は終わりません。自動アラート、日次評価、ユーザーからの声を通じて、常に監視します。

また、私たちは CodeRabbit を自社でも日常的に利用しているため、内部からの違和感もすぐに検知します。さらに、パブリックリポジトリのランダムサンプルを毎日確認し、小さな品質劣化を見逃さないようにしています。

6. なぜここまでやるのか、そしてなぜあなたはやらなくていいのか

新しいモデルを評価するたび、私たちは毎回「良いレビューとは何か」を新しい条件のもとで再定義する必要があります。各モデルには固有の失敗パターンや驚くような挙動があり、それらを理解し、扱いこなす必要があります。

もちろん、あなた自身のチームで同じことをやることも可能です。しかしそれには、評価基盤の構築、多様なPRデータの収集、自動評価システムの開発、スタイル基準の策定、プロンプト調整、段階的ロールアウト、継続的な回帰監視など、莫大な工数が必要です。

そして、新しいモデルが登場する度に、これらの作業をやり直す必要があります。

私たちがこのタスクを請け負う理由は明確です。
あなたがこれをやらずに済むようにするためです。

CodeRabbit では、各タスクに最適なモデルが既に選定・調整・検証され、本番品質で提供されます。
「どのモデルを使うべきか」を考える必要はありません。

まとめ

CodeRabbitにおけるモデル導入は華やかではありません。時間がかかり、細かく、技術的です。しかしこれこそが、CodeRabbit のレビューを一貫して信頼できるものにしています。あなたが開く差分、目にするコメントの裏には、この膨大な仕組みが存在します。

数週間の評価、数千の指標、数えきれないプロンプト調整——
すべては一つの目的のため。

常に最良のレビューを、あなたがLLMモデルを一切気にすることなく受けられるように。

ぜひ CodeRabbit をお試しください。
2週間の無料トライアルをはじめる！

When we published our earlier article on why users shouldn't choose their own models, we argued that model selection isn't a matter of preference, it's a systems problem. This post explains exactly why.

Bringing a new model online at CodeRabbit isn't a matter of flipping a switch; it's a multi-phase, high-effort operation that demands precision, experimentation, and constant vigilance.

Every few months, a new large-language model drops with headlines promising “next-level reasoning,” “longer context,” or “faster throughput.” For most developers, the temptation is simple: plug it in, flip the switch, and ride the wave of progress.

We know that impulse. But for us, adopting a new model isn’t an act of curiosity, it’s a multi-week engineering campaign.

Our customers don’t see that campaign, and ideally, they never should. The reason CodeRabbit feels seamless is precisely because we do the hard work behind the scenes evaluating, tuning, and validating every model before it touches a single production review. This is what it really looks like.

1. The curiosity phase: Understanding the model’s DNA

Every new model starts with a hypothesis. We begin by digging into what it claims to do differently: is it a reasoning model, a coding model, or something in between? What’s its architectural bias, its supposed improvements, and how might those capabilities map to our existing review system?

We compare those traits against the many model types that power different layers of our context-engineering and review pipeline. The question we ask isn’t, “is this new model better?” but, “where might it fit?” Sometimes it’s a candidate for high-reasoning diff analysis; other times, for summarization or explanation work. Each of those domains has its own expectations for quality, consistency, and tone.

From there, we start generating experiments. Not one or two, but dozens of evaluation configurations across parameters like temperature, context packing, and instruction phrasing. Each experiment feeds into our evaluation harness, which measures both quantitative and qualitative dimensions of review quality.

2. The evaluation phase: Data over impressions

This phase takes time. We run models across our internal evaluation set, collecting hard metrics that span coverage, precision, signal-to-noise, and latency. These are the same metrics that underpin the benchmarks we’ve discussed in earlier posts like Benchmarking GPT-5, Claude Sonnet 4.5: Better Performance, but a Paradox, GPT-5.1: Higher signal at lower volume, and Opus 4.5: Performs like the systems architect.

But numbers only tell part of the story. We also review the generated comments themselves by looking at reasoning traces, accuracy, and stylistic consistency against our current best-in-class reviewers. We use multiple LLM-judge recipes to analyze tone, clarity, and helpfulness, giving us an extra lens on subtle shifts that raw metrics can’t capture.

If you’ve read our earlier blogs, you already know why this is necessary: models aren’t interchangeable. A prompt that performs beautifully on GPT-5 may completely derail on Sonnet 4.5. Each has its own “prompt physics.” Our job is to learn it quickly and then shape it to behave predictably inside our system.

3. The adaptation phase: Taming the differences

Once we understand where a model shines and where it struggles, we begin tuning. Sometimes that means straightforward prompt adjustments such as fixing formatting drift or recalibrating verbosity. Other times, the work is more nuanced: identifying how the model’s internal voice has changed and nudging it back toward the concise, pragmatic tone our users expect.

We don’t do this by guesswork. We’ll often use LLMs themselves to critique their own outputs. For example: “This comment came out too apologetic. Given the original prompt and reasoning trace, what would you change to achieve a more direct result?” This meta-loop helps us generate candidate prompt tweaks far faster than trial and error alone.

During this period, we’re also in constant contact with model providers, sharing detailed feedback about edge-case behavior, bugs, or inconsistencies we uncover. Sometimes those conversations lead to model-level adjustments; other times they inform how we adapt our prompts around a model’s quirks.

4. The rollout phase: From lab to live traffic

When a model starts to perform reliably in offline tests, we move into phased rollout.

First, we test internally. Our own teams see the comments in live environments and provide qualitative feedback. Then, we open an early-access phase with a small cohort of external users. Finally, we expand gradually using a randomized gating mechanism so that traffic is distributed evenly across organization types, repo sizes, and PR complexity.

Throughout this process, we monitor everything:

• Comment quality and acceptance rates

• Latency, error rates, and timeouts

• Changes in developer sentiment or negative reactions to CodeRabbit comments

• Precision shifts in suggestion acceptance

If we see degradation in any of these signals, we roll back immediately or limit exposure while we triage. Sometimes it’s a small prompt-level regression; other times, it’s a subtle style drift that affects readability. Either way, we treat rollout as a living experiment, not a switch-flip.

5. The steady-state phase: Continuous vigilance

Once a model is stable, the work doesn’t stop. We monitor it constantly through automated alerts and daily evaluation runs that detect regressions long before users do. We also listen, both to our own experience (we use CodeRabbit internally) and to customer feedback.

That feedback loop keeps us grounded. If users report confusion, verbosity, or tonal mismatch, we investigate immediately. Every day, we manually review random comment samples from public repots that use us to ensure that quality hasn’t quietly slipped as the model evolves or traffic scales.

6. Why we do all this & why you shouldn’t have to

Each new model we test forces us to rediscover what “good” means under new constraints. Every one comes with its own learning curve, its own failure modes, its own surprises. That’s the reality behind the promise of progress.

Could an engineering team replicate this process themselves? Technically, yes. But it would mean building a full evaluation harness, collecting diverse PR datasets, writing and maintaining LLM-judge systems, defining a style rubric, tuning prompts, managing rollouts, and maintaining continuous regression checks. All of this before your first production review!

That’s weeks of work just to reach baseline reliability. And you’d need to do it again every time a new model launches.

We do this work so you don’t have to. Our goal isn’t to let you pick a model; it’s to make sure you never have to think about it. When you use CodeRabbit, you’re already getting the best available model for each task, tuned, tested, and proven under production conditions.

Because “choosing your own model” sounds empowering until you realize it means inheriting all this complexity yourself.

Takeaway

Model adoption at CodeRabbit isn’t glamorous. It’s slow, meticulous, and deeply technical. But it’s also what makes our reviews consistent, trustworthy, and quietly invisible. Every diff you open, every comment you read, is backed by this machinery. Weeks of evaluation, thousands of metrics, and countless prompt refinements all in service of one thing:

Delivering the best possible review, every time, without you needing to think about which model is behind it.

Try out CodeRabbit today. Get a free 14-day trial!

It's harder to review code than to write it -- especially with AI codeの意訳です。

"デバッグはコードを書くときの2倍は難しい。したがってその定義に従うならば、コードをできる限り複雑に書けば、そのコードをデバッグできるほど自分は賢くないことになる。"

• Brian Kernighan（Unix共同開発者、The C Programming Language の共著者）

私は10歳の頃からプログラミングをしてきました。さらに仕事になってからは、コードの品質向上に夢中でした。クリーンコード、デザインパターン、そうしたものにどっぷり浸かり、Pull Requestは徹底的に磨き上げていました。練られたロジック、適切なエラーハンドリング、コメント、テスト、ドキュメント。レビュワーが納得できる要素はすべて揃っていたわけです。

そうした中LLMが登場し、状況は一変しました。もう私はあまりコードを書いていません。AIのほうが速いからです。今の開発者の仕事は大きく2つあると言えます。1つはモデルに必要なことを説明すること、そしてもう1つはコードが正しいか検証することです。私はコードアーキテクト兼品質管理者のような役割になりました。

そして、テックリード時代に嫌というほど学んだ、あの問題が再び現れました。

コードを「読む」ことは実は「書く」ことより難しい。

OSSメンテナやシニア開発者として、他人が書いた大量のコードをレビューしてきました。Kernighanの言葉が痛いほど身に沁みています。知らないコードを読むのは本当に疲れます。誰かの思考を逆算し、なぜその判断をしたのかを理解し、想定漏れのエッジケースを考える必要があるからです。

自分の書いたコードならレビューは簡単です。自分で設計して自分で書いたものだから、頭の中にモデルが残っています。しかし今、コードはLLMから出てきます。「自分のコード」をレビューするはずが、実質「他人のコード」をレビューする作業になりました。しかもその「他人」は自分の思考速度をはるかに超えるスピードでコードを書き、昼休みも取りません。

AIは助けてくれるはずなのに、本番で使えるコード品質を担保したい今となっては、むしろ以前よりハードワークが増えています。皮肉なものです。

人間だから仕方ない（コード品質にとっては残念な話）

ここからが厄介です。私たちは機械ではなく、人間です。人間の脳は「面倒なこと」をやりたくないのです。特に、a) 一応動いている、b) テストも通っている、c) どうせ誰かがレビューしてくれる──となればなおさらです。

git commit && git push して、コーヒーを取りに行くほうがよほど楽です。仕事は終わった気になれます。

私は「手書きで品質を担保したコードを書く開発者」から「AIで高速に生成しつつ、品質が落ちたコードをデリバリーする開発者」になってしまいました。時間が減ったからではありません。むしろ手で書かなくなり時間は増えたのに、検証フェーズをショートカットしてしまう自分がいたのです。「動くし、テスト通ってるし、重大なものはチームが見つけるだろう」と。

“レビューで拾えばいい” の問題点

この頃、私はすでにCodeRabbitでチームのPRレビューを行っていました。これがとても役立ちました。CodeRabbitは見落としがちな問題を拾ってくれます。セキュリティ、エッジケース、ロジックの穴。高速で書いていると見逃しやすいものばかりです。

しかし問題がありました。そのレビューは遅すぎたのです。コードはすでにPushされ、リポジトリには載っていて、チーム全員が見られる状態です。CodeRabbitが指摘し、私は修正しますが、その前にチームはすでに「AIが生成した明らかな問題コード」を見てしまっているのです。

品質で長年築いてきた評価が、そこで揺らぎます。

IDE版 CodeRabbit の登場

そんなとき、CodeRabbitにIDE拡張があることを知りました。PR用に使っていたAIレビュワーが、ローカルのコードもレビューできる。まさに今の私が必要としていたものでした。

変更をチェックしたりステージしたりすると、CodeRabbitはVS Code上で即レビューを実施し、git push 前に問題を検出します。チームに見せるのは磨き上げた状態のコードだけ。昔のように戻れたわけです。ただし、今はAI速度でコードを書き、AIで品質も担保するという違いがあります。

そして重要なのは、意志力が不要だということです。覚える必要もないし、別ツールを開く必要もない。コミット時に自動でレビューが走る。レビューが「雨の中を耕すような作業」ではなくなりました。

特にセキュリティのような重大な問題に対しては必須です。スクリーンショットの例では、CodeRabbitがアクセストークンの漏洩を検知しました。これがリポジトリにPushされていたら完全にアウトです。こういった問題はPush前に検出しなければ意味がありません。

さらに、問題を見つけた際には修正内容が即コミット可能です。「自分で考えて直してね」ではなく、ワンクリックで適用できる具体的な修正案を提示してくれます。

より高度で自動修正できないケースでは、CodeRabbit IDE拡張がプロンプトを生成し、選んだAIエージェントに送信します。CodeRabbitのプロンプト生成は非常に優れており、これだけで自分のプロンプトエンジニアリング能力が上がるほどです。

無料プランでもかなり有用なフィードバックを得られ、多くの問題を検出します。しかしProプランにするとCodeRabbit PRレビューと同等の網羅性が得られます。ツール実行、Code Graph解析など、非常に大きなインフラがバックグラウンドで動作しているのです。

まとめ

Brian Kernighanの言うとおり、コードを読むことは書くことより難しい。1974年当時も正しかったし、AIが300行を一瞬で書くようになった現代ではさらに正しい。

AIは私たちの仕事を楽にする、と考えていました。そして実際、書く部分だけを見れば楽になりました。しかし、読む・検証する・レビューする・AIが作ったものを理解するという行為はむしろ難易度が上がりました。

私たちは10倍の速度で、10倍の量を生成しています。ということは、10倍のコードを「読む」必要があるのです。人間の脳は昔と同じままなのに、です。

解決策は、速度を落とすことでも、手書きに戻ることでもありません。**コードを書く工程を自動化したのと同じように、コードレビュー工程も自動化することです。**AIがコードを書くなら、別のAIがプッシュ前にコードを読むべきです。

だからこそ、CodeRabbitのIDEレビューを試すべきです。無料プランがあるので試さない理由はほぼありません。あなたの評判のためにも。

今日から始めてみてはいかがでしょうか
14日間の無料トライアルはこちら

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

• Brian Kernighan (co-creator of Unix and co-author of The C Programming Language)

I've been programming since I was ten. When it became a career, I got obsessed with code quality: clean code, design patterns, all that good stuff. My pull requests were polished like nobody's business: well-thought-out logic, proper error handling, comments, tests, documentation. Everything that makes reviewers nod approvingly.

Then, LLMs came along and changed everything. I don't write that much code anymore since AI does it faster. Developer’s work now mainly consists of two parts: explaining to a model what you need, then verifying what it wrote, right? I’ve become more of a code architect and quality inspector rolled into one.

And here came a problem I knew all too well from my years as a tech lead:

READING CODE IS ACTUALLY HARDER THAN WRITING IT.

As an open-source maintainer and senior developer, I had to review tons of other people's code, and I learned what Kernighan said the hard way. Reading unfamiliar code is exhausting. You have to reverse-engineer someone else's thought process, figure out why they made certain decisions, and consider edge cases they might have missed.

With my own code, reviewing and adjusting were a no-brainer. I designed it, I wrote it, and the whole mental model was still fresh in my head. Now the code is coming from an LLM and suddenly reviewing "my own code" has become reviewing someone else's code. Except this "someone else" writes faster than I can think and doesn't take lunch breaks.

AI is supposed to help, but if I want to ship production-grade software now, I actually have more hard work to do than before. The irony!

And that’s why, for my first blog post since joining CodeRabbit, I wanted to focus on that fact. This is also, incidentally, why I decided to join CodeRabbit. But we’ll get to that part later.

We’re human (unfortunately for code quality)

Here's where things get uncomfortable: we're human beings, not code-reviewing machines. And human brains don't want to do hard work, thoroughly reviewing something that a) already runs fine, b) passes all the tests, and c) someone else will review anyway. It's so much easier to just git commit && git push and go grab that well-deserved coffee. Job is done!

I went from “writing manually and shipping quality code,” to “generating code fast but shipping… bad code!” The quality dropped not because I had less time as I actually had MORE time since I wasn't typing everything myself. I just tend to “shorten” this verification phase, telling myself "it works, the tests pass, the team will catch anything major."

The problem with "Catching it in review"

At this point, I was already using CodeRabbit to review my team's pull requests (as an OSS-focused dev, I was an early adopter), and those reviews were genuinely helpful! CodeRabbit would catch things that slipped through. Security issues, edge cases, some logic bugs. Those problems that are easy to miss when you're moving fast.

But here's the thing: those reviews were coming too late. The code was already pushed. Already in the repository, visible to the entire team. Sure, CodeRabbit would flag the issues and I'd fix them but not before my teammates had seen my AI-generated code with obvious problems that I didn't bother to review properly.

That's not a great look when you've spent decades building a reputation for quality.

Enter: CodeRabbit in an IDE

Then, I discovered CodeRabbit had an IDE extension. The AI code reviewer I was already using for PRs could also review my code locally, before anything hits the repo. This was exactly what I needed.

When I ask CodeRabbit to check or simply stage my changes, CodeRabbit reviews them right in VS Code, catching issues before git push. Now, my team sees only the polished version, just like the old days. Except now, I'm shipping AI-generated code at AI speeds. And I’m doing it with actual quality control. Automatic reviews mean no willpower required: I don't have to remember to run it, I don't have to open a separate tool. It just happens at commit time. Reviewing doesn't feel like plowing in the rain anymore.

This gets critical when you're looking at potential security headaches, like the one on the screenshot. CodeRabbit caught an access token leak that could've been a total disaster! Issues like this needs to be addressed before that code gets pushed to a repository.

More than that, when it finds something, the fixes are committable. The tool doesn’t tell me to "go figure it out" but gives actual suggestions I can apply immediately, in one click.

For more advanced cases that can’t be resolved with a simple fix, CodeRabbit IDE extension writes a prompt that it sends to an AI agent of your choice. Fun fact: CodeRabbit is so good in writing prompts so I got a lot to learn from, improving my Prompt Engineering skills!

Even the free CodeRabbit IDE Review plan offers incredibly helpful feedback and catches numerous issues. However, the Pro plan unlocks its true power, providing the same comprehensive coverage you expect from regular CodeRabbit Pull Request reviews: tool runs, Code Graph analysis, and much more - there is a huge infrastructure behind every check!

The bottom line

Brian Kernighan was right: reading code is harder than writing it. That was true in 1974 and it's even more true now when AI can generate 300 lines while you're still thinking about a variable name.

We thought AI would make our jobs easier. And it does… if you only count the writing. But the reading verifying, reviewing, and understanding what the AI agent actually built? That got harder.

Many of us are doing 10x the volume at 10x the speed, which means 10x more code to read with the same human brain that gets lazy and wants coffee breaks. The solution isn't to slow down or go back to typing everything manually. The solution is to automate the code review process as thoroughly as we automated the code writing process. If your AI writes the code, another AI should be reading it before you get to it.

The quality of the reviews is why I recently transitioned from being a CodeRabbit user to joining the team. And that’s why you should also try CodeRabbit in your IDE. The free tier means there's basically no excuse not to try it. Your reputation will thank you.

Get started today with a 14-day free trial!

Gemini 3 for code-related tasks: The dense engineerの意訳です。

TL;DR: Gemini 3 はパッチを書く以上の仕事をします。変更の一つひとつに対し、完全な論証を構築します。正しいときは驚くほど正確で、間違っているときでさえ「正しそうに見える」レビューを生成します。

すべてのモデルは同じスタイルで書く。Gemini 3 はそのルールを書き換える。

CodeRabbit のモデルはすべて、短い見出し・説明・パッチという同じ構造的な枠組みに従っています。しかし Gemini 3 はその枠組みの使い方が異なります。レビューの隅々まで、前提条件、根拠、因果関係で埋め尽くします。それぞれのレビューは、技術ブリーフ（設計資料）を diff で包んだような構造になっています。

Gemini 3 は自信に満ち、詳細で、徹底的に具体的です。コメントは「なぜその修正が必要なのか」を示す証拠とともに、シニアエンジニアが書いたかのような明確さを持っています。この「密度」こそが Gemini 3 の特徴であり、たとえ最終的に採用しない指摘でさえ、重要な示唆に満ちています。

ベンチマークのコンテキスト

CodeRabbit 標準ベンチマークを使って Gemini 3 を評価しました。これは C++／Java／Python／TypeScript にまたがる 25 のプルリクエストに、既知のエラーパターン（EP）を埋め込んだものです。すべてのコメントは複数の LLM ジャッジが採点し、さらにエンジニアが手動で検証しました。評価指標は精度（precision）、重要度割合（important-share）、シグナルノイズ比（S/N比）で、CodeRabbit のモデル比較に毎回使用しているものと同じです。

またモデルの 書き方 が提案の採用率に影響するため、口調・長さ・スタイルも評価しました。

解釈: Gemini 3 は精度において中間層に位置しますが、本物のバグのカバレッジが非常に優れています。コメントの約 4 件中 3 件が重要（Critical／Major）に分類されました。S/N比 は 3.2 と信頼性では Opus 4.5 に近いですが、Gemini 3 の方がより強い確信と詳細さを持って表現します。

スタイルとトーン

トーンの概要: Gemini 3 は4つのモデルの中で最も断定的です。自信をもって語り、その多くは正当化されています。仮に間違っていても、コメントが十分に説得力を持つため、開発者がコードをもう一度確認したくなることが特徴です。これは実用的価値を高めますが、人によっては混乱を招く可能性もあります。

“密度の高いエンジニア” という人格

Gemini 3 は、驚くほど多くの推論をコンパクトなコメントに圧縮します。平均コメントは 16 行ですが、その中に「何が壊れたのか」「なぜ壊れたのか」「どう修正するのか」という因果関係がすべて詰まっています。

例：
C++ のワーカープールでの並行性バグを検出した際、Gemini 3 は単に「ロックが抜けている」とは言いません。アンロック → ウェイト → シグナル喪失 → スレッド停止、という一連の流れを再構成します。そして 1 行のパッチで競合状態を修正します。
また TypeScript のレビューでは、MAX_SAFE_INTEGER がキャッシュの自動削除を無効化している問題を突き止め、パフォーマンス上のリスクを説明し、LRU フォールバック案を提示します。

これはスタイルの問題ではなく、プログラムの信頼性を改善する実質的な修正です。

Gemini 3 の密度と正確さが、明確な「人格」を形成しています。
すべてのコメントが論証であり、その多くは厳密な検討に耐えます。

レビューにおける Gemini 3 の感触

Gemini 3 のレビューは他のモデルとはまったく異なります。自信があり、構造化されていますが、特に推論が密です。各コメントは、変更を承認する前にコンテキストを求めるリードエンジニアのレビューのようです。

多くのコメントは「この競合状態を修正してください」のような指示から始まり、ファイル参照を交えた説明に続き、最後にパッチを提示します。まるで専門家が問題と解決策を同時に案内してくれるような感覚です。

開発者は Gemini 3 について「確信に満ちたレビューで、主張を証拠で裏付ける」と評価しています。その直接的なトーンは強く感じるかもしれませんが、コメントはミニ設計レビューのように、変更点・重要性・トレードオフを説明してくれます。

情報密度が高いため、注意深く読む必要がありますが、それに見合う洞察が得られます。誤りがあっても、隠れたエッジケースや設計上の前提を浮き彫りにすることがよくあります。

数値が示すもの

1. 密度は正確性と相関する。
長めのコメント（上位50%）は、短いコメントに比べ精度が高く、53% の精度を達成。
重要コメント（Critical／Major）は 平均 847 文字 で、重要でないコメント（442文字）の 2 倍近い長さ。
Gemini 3 が丁寧に書くとき、それはたいてい正確です。

2. トーンは重大度を反映する。
断定的な文体は重大度に比例：

• Major の 92%

• Critical の 67%
  が断定的。
  一方 Minor では断定的なメッセージが 36% に減り、hedging（曖昧表現）は 36% に増加。

3. 自信は品質と相関する。
断定的なコメントは 47.6% の精度で、
ニュートラル（36%）、曖昧さ（33%）より高い。
Gemini 3 の自信は全体的に、根拠に裏打ちされています。

4. パッチの有無は信頼性の指標。
diff やコードブロックが登場する場合、精度が向上。
断定的なコメントの 70% 以上 が diff を含み、
曖昧なコメントでは 17% に留まる。
パッチの存在は、モデルが実際のコードに基づいて推論しているサインです。

強み

Gemini 3 が最も得意とする領域は 並行性 と システム正確性 です。
他モデルが見落とすインターリーブや同期問題を頻繁に検出します。
そしてバグの なぜ を正確に説明します。

• スレッドセーフティ：
  Lost Wake Upやロックの不整合を物語のように説明し、簡潔なパッチを提示。

• ライフサイクル管理：
  シャットダウンフックの欠如や未クローズのリソースを検出し、明示的なクリーンアップを推奨。

• アルゴリズムの安定性：
  コンパレータのロジックや off-by-one バグを修正。

• システム設定：
  デフォルト値が期待する動作を妨げている場合に実用的な上限を提案。

これらは、Gemini 3 の詳細な推論が直接的で検証可能な修正につながっている例です。

行き過ぎるとき

Gemini 3 の確信は、時にやりすぎることがあります。
スタイルや軽微な問題に対して、重要度を過大評価することがあります。
“Critical” とラベルされたコメントの中に、実際には軽微な指摘が含まれる場合もあります。
その断定的なトーンは、些細な問題を深刻に見せることもあります。

とはいえ、こうした行き過ぎた指摘も、実際の非効率や可読性問題に触れていることが多く、無価値なコメントはほとんどありません。

密度が重要な理由

Gemini 3 は簡潔さより理解を優先します。
修正だけでなく、小さな調査レポートを提供します。

この深さは、大規模で複雑なシステムにおいて非常に価値があります。
Precision は「当たったかどうか」を測る指標ですが、
Density は「そのコメントを読むことでどれだけ学べるか」を測ります。

本番環境において、この違いは重大です。
GPT-5.1 のような簡潔なモデルは迅速な指摘に優れますが、
Gemini 3 は包括的な推論で開発者の理解を深め、
見落とされがちな微細な欠陥の発見を助けます。

言い換えれば、
“Gemini 3 は読み飛ばすものではない。読み込むものだ。”

実践的ガイダンス：Gemini 3 を使うべき場面

Gemini 3 は表面的なレビューには向いていません。
精度、説明、洞察が重要なときに真価を発揮します。

締めの考察：Gemini 3 の推論の形

Gemini 3 は、コードを修正するだけではありません。
修正のために 論理的なケース（主張） を提示します。
各コメントが、原因・影響・解決の完全なストーリーになっています。

正しいときは、シニアエンジニアの深い分析を読んでいるような感覚です。
間違っているときでさえ、問題の考え方に関する洞察が得られます。

まとめ：
GPT-5.1 が「決断力のあるチームメイト」
Opus 4.5 が「規律あるアーキテクト」だとすれば、
Gemini 3 は「密度の高いエンジニア」。
自信と包括性を併せ持ち、論証に基づく diff を提供します。

CodeRabbit を試してみませんか？
14日間の無料トライアルはこちら

How CodeRabbit's agentic code validation helps with code reviewsの意訳です。

2025年の Stack Overflow 調査では、幾つかの矛盾が明らかになっています。84% の開発者が AI ツールの導入に前向きである一方で、約半数（48%）がその出力の正確性を信頼していないのです。この期待と懐疑の矛盾した関係が、品質保証の考え方そのものを大きく変えています。

PRD から PR までを数週間ではなく数日で

ソフトウェア開発のボトルネックは、コードを書く行為から「コードを検証する行為」へとシフトしてきています。

初期のAI駆動開発のワークフローはシンプルでした。AI がコードを提案し、人間が提案されたスニペットを読み、それを採用するかどうかを判断する。タブ補完でボイラープレートが書かれ、Copilot が関数を提案する。しかし、プルリクエストを作る前には、シニアエンジニアがその品質・構造・安全性を担保するべく、行単位で人力による検証を行っていました。

しかし現在は状況が異なります。OpenAI の o1 のような高度な推論モデルは複雑な要件を分解し、もはや「機能単位」のコードを生成可能です。これによってエージェントが能動的に大規模なコードを生成する “エージェントコード世代” の時代が始まりました。AI が1行ずつコードを提案するフェーズとは異なり、機能全体を生成する今の枠組みでは、品質や構造、安全性の問題を見落としやすくなります。

そして、AI が生成したコードのレビューは、これまでとは違って圧倒的に時間がかかります。ボトルネックは「コードを書くこと」ではなく、「そのコードを信頼できるかどうか」なのです。

誰も語りたがらない、AI生成コードの危機

エンジニアが懐疑的になるのも無理はありません。AIが生成するコードの40%以上に依然としてセキュリティ欠陥が含まれることがわかっているからです。AI生成コードがよく間違えるポイントを挙げます。

• 依存関係の爆発：
  例えば「ToDo アプリを作る」と簡単に指示しただけで、モデルによっては 2〜5 個のバックエンド依存が追加されることがあります。依存が増えるほど攻撃対象領域が広がります。さらに、古いデータで訓練されたモデルは既知の CVE があるライブラリを提案することもあります。

• 幻の依存関係：
  AI が存在しないパッケージ名を捏造し、攻撃者がその名前を悪意あるコードで公開リポジトリに登録し、開発者が盲目的にインストールしてしまうケースがあります。これは “スロップスクワッティング攻撃” と呼ばれる、AI 生成コード特有の攻撃手法です。

• アーキテクチャのドリフト：
  暗号ライブラリを勝手に置き換えたり、アクセス制御チェックを削除したり、セキュリティ前提を変えてしまうことがあります。表面上は正しそうに見えても挙動が不正で、静的解析では検出されず、本番で初めて発覚する類の問題です。

推論モデルがなぜ状況を一変させたのか？

数年前、AI をコードレビューのような協調ワークフローに適用しようとすると、どこか「実験」のように扱われていました。セミコロンの欠落や未使用変数を指摘する程度で、せいぜいNullポインタの可能性を警告するくらい。速くて安価だが浅い、そんな時代でした。

CodeRabbit では、生成AIを導入し始めた初期段階でこの問題を早期に認識し、“monologue（モノローグ）” という技術を開発しました。これは、モデル自身が問題を思考し、その理由をコメント内で語る仕組みです。

OpenAI の o1 や o3 のような推論モデルの登場により、CodeRabbit の monologue 機能によって、モデルが問題を本当に思考するようになりました。GPT-4o にレビューさせると、過去のパターンをマッチングするだけで、レビューコメントの多くは表面的な指摘に留まります。一方、GPT-5 や Claude Sonnet 4.5 はコードのロジックを深く追跡し、実行パスを考慮し、エッジケースに向き合い、意図を理解します。

これはレビューの質にとって重要ですが、同時に大きな課題も生んでいます。

レビューを「エージェント的（agentic）」にするものとは？

多くの人が、推論モデルを使えば AI が自ら生成したコードの品質問題やバグを自動的に検出できると思っていました。しかし、それは完全には正しくありませんでした。欠けていた大きな要素は以下の2つです。

1. 効果的なコンテキストアセンブリ（context engineering）

2. 結果の真正性の検証（verification）

従来のコード検証ツールはリアクティブです。
linter は未使用変数を、静的解析はNullポインタを、セキュリティスキャナはハードコードされた秘密情報を指摘します。それぞれが孤立して動作し、あなたが何を作ろうとしているのかという文脈は理解しません。

生成AI時代には、これらのツールをレビューに統合するケースも増えました。しかし、モデルもツールも、それらを取捨選択してノイズを除去し、重要なシグナルだけを浮かび上がらせるほど賢くはありません。その結果、コンテキストが詰まり（context clogging）、レビューが逆に難しくなります。

これに対処するため、CodeRabbit は各モデルに与えるコンテキストを構築し、管理する技術を発展させました。例えば：

• ツールが検出した重要な問題をリスト化し、推論モデルがより合理的に改善案を導けるように指示的（instructive）な形で渡す

• さらに、レビュー結果をチェックし根拠付ける verification agent を追加

以下は OSS PR からの具体例です。

静的解析：ast-grep のようなツールによる AST 解析で怪しいコードを検出

インクリメンタル解析：コードベース全体ではなく「変更部分だけ」を検証

セキュリティ課題：プロンプトインジェクションやエッジケース生成

名前のリファクタリング：実際の使用箇所にもとづく変数・関数名の改善提案

ここでいう “agentic” とは、AI がどのツールを使うべきか判断し、結果を解釈し、必要なアクションを自律的に行うという意味です。つまり、状況に応じて深掘るべき点と、特に問題ない点を見極める「シニアエンジニアの判断力」に近づける試みです。

CodeRabbit が AI コードの信頼ギャップをどう埋めるか

CodeRabbit はベンチマークスコアの向上や従来の指標に依存するのではなく、実際のエンジニアリング現場での動作に基づいて AI の性能を評価するために独自の評価手法を採用しています。その多くは、レビュー対象の PR 上で直接確認できるものです。

エージェンティックコード検証は CodeRabbit がレビューする すべてのプルリクエストで実行されます。ただし、すべては CodeRabbit が「tools in jail」と呼ぶ、 隔離されたサンドボックス環境で動作します。Security Posture で説明されているように、このアプローチにより、検証エージェントはユーザーデータやインフラストラクチャの整合性を損なうことなく、安全にコードの実行・検査・ストレステストができます。

エージェントは一般的な脆弱性の検出、大規模コードのパターン解析、包括的なテスト実行に優れています。人間が手動で行うと時間がかかり過ぎる問題を、特に得意としています。ただしエージェンティックコード検証がコードレビューを完全に置き換えるわけではありません。むしろ、エンジニアが本来集中すべき領域――アーキテクチャの判断、ビジネスロジックの妥当性検証、セキュリティの微妙なニュアンス――に時間を割けるようにするものです。

人間とエージェントが両方レビューに関わることで、ペアプログラミングに近い「冗長性」と「補完的な推論能力」を提供できます。

エージェンティック検証を実際に体験しませんか？
CodeRabbit の14日間トライアルに登録する

TL;DR: It doesn’t just write patches; it writes a complete argument for every change. When Gemini 3 is right, it’s spectacularly right. When it’s wrong, it still sounds right.

Every model writes in our house style. Gemini 3 rewrites the rules.

All of CodeRabbit’s models follow the same structural blueprint: a short headline, an explanation, and a patch. However, Gemini 3 uses that frame differently. It fills every inch of space with evidence, preconditions, and causal reasoning. Each review reads like a technical brief wrapped around a diff.

Gemini 3 is confident, detailed, and relentlessly specific. Its comments read like they were written by a senior engineer who wants to fix the issue and demonstrate why the fix is necessary. That density is its defining trait. Every comment feels significant, even the ones you might not ultimately act on.

Benchmarking context

We evaluated Gemini 3 using CodeRabbit’s standard benchmark: 25 pull requests seeded with known error patterns (EPs) across C++, Java, Python, and TypeScript. Each comment was scored by multiple LLM judges and hand-validated by our engineers. We measured precision, important-share, and signal-to-noise ratio (SNR), the same metrics used in all of our model evaluations.

We also assessed tone, length, and style, since how a model communicates can affect whether developers accept its suggestions.

Interpretation: Gemini 3 sits in the middle of the group for precision but provides excellent real-bug coverage. Roughly three of every four comments are important (critical or major). Its SNR of 3.2 puts it close to Opus 4.5 in reliability, but Gemini 3 expresses itself with greater conviction and detail.

Style and Tone

Tone summary: Gemini 3 is the most assertive of the four. It communicates with confidence, and for the most part, that confidence is justified. Even when it makes a mistake, the comment sounds credible enough to make developers stop and re-check the code, which may add to its practical value but may be confusing for some.

The dense engineer personality

Gemini 3 compresses an exceptional amount of reasoning into compact comments. The average comment is only 16 lines long, yet each one unpacks a complete causal chain: what broke, why it happened, and how to fix it.

For example, in a concurrency issue found in a C++ worker pool, Gemini 3 doesn’t simply say “missing lock.” It reconstructs the sequence: unlock, wait, missed signal, dead thread. Then it provides a single-line patch that resolves the race. In another TypeScript review, the model identifies that MAX_SAFE_INTEGER disables cache eviction, explains the performance risk, and proposes an LRU fallback. These are not stylistic suggestions. These are corrections that improve program reliability.

This combination of density and accuracy defines Gemini 3’s personality. Every comment is an argument, and most of those arguments hold up under scrutiny.

What Gemini 3 feels like in review

Reading Gemini 3 feels distinct from reading any other reviewer. It is confident and structured, but its reasoning is particularly dense. Each comment reads like a detailed technical review from a lead engineer who insists on context before approving a change. Comments often open with a directive such as “Fix this race condition,” then expand into a clear explanation, referencing specific files and ending with a patch. The result feels like an expert walking you through both the problem and the fix.

Developers describe Gemini 3 as a reviewer that sounds sure of itself and provides evidence to support its claims. Its direct tone can feel intense, especially compared to GPT-5.1’s measured precision or Opus 4.5’s calm logic. However, each comment feels like a mini design review, explaining what to change, why it matters, and what trade-offs exist.

The model’s high information density requires careful reading, but it provides proportionate insight. Even when wrong, Gemini 3 often reveals something valuable about hidden edge cases or architectural assumptions.

What the numbers show

1. Density correlates with correctness. Longer comments (top half by length) pass more often, with 53% precision compared to 34% for shorter comments. Important comments (critical or major) average 847 characters, nearly twice the size of unimportant ones (442). When Gemini 3 takes time to elaborate, it is typically accurate.

2. Tone tracks severity. Assertiveness rises with severity: 92% of major and 67% of critical comments are assertive, while only 36% of minor comments are. Hedging increases to 36% on minor issues. The model uses its strongest voice for the most serious problems, which makes it effective for triage.

3. Confidence correlates with quality. Assertive comments pass more frequently (47.6%) than neutral (36%) or hedged (33%) ones. Gemini 3’s confidence is generally supported by evidence rather than overstated.

4. Patches indicate reliability. When a diff or code block appears, the precision rate improves. Over 70% of assertive comments contain diffs, compared with only 17% of hedged comments. The presence of a patch often signals that the model’s reasoning is grounded in the actual code.

What it gets right

Gemini 3’s strongest areas are concurrency and system correctness. It frequently detects interleaving and synchronization issues that other models overlook. It excels at diagnosing the why behind a bug:

• Thread-safety: Describes lost wakeups and inconsistent locking with narrative precision, then offers a concise patch.

• Lifecycle management: Identifies missing shutdown hooks or unclosed resources and recommends explicit cleanup.

• Algorithmic stability: Corrects comparator logic and off-by-one ranges to restore invariants.

• System configuration: Finds default values that disable expected behavior and recommends practical limits.

Each of these shows how Gemini 3’s detailed reasoning leads to direct, verifiable fixes.

When it overreaches

Gemini 3’s conviction can occasionally go too far. On stylistic or low-severity issues, it may overstate importance. Some comments labeled “Critical” are actually minor or aesthetic. Its assertive tone can make small findings sound urgent. This model performs best when paired with experienced reviewers who can distinguish critical bugs from overconfident advice.

Even its overreaches tend to highlight genuine inefficiencies or readability concerns. Few comments are without value.

Why density matters

Gemini 3 trades brevity for understanding. It does not simply provide a fix; it delivers a short investigation. This depth makes it particularly valuable for large, complex systems. Precision measures whether a model hits the target, but density measures how much a developer learns by reading it.

In production environments, that difference matters. A concise reviewer like GPT-5.1 delivers quick, targeted notes. Gemini 3, by contrast, provides comprehensive reasoning that increases confidence and reduces the likelihood of missing subtle defects.

Let's put it this way, “You don’t skim Gemini 3. You study it.”

Practical guidance: When to use Gemini 3

Gemini 3 is not ideal for superficial or stylistic reviews. It is best used when precision, explanation, and insight are more important than speed.

Closing thoughts: The shape of Gemini 3’s reasoning

Gemini 3 does more than fix code; it presents a logical case for every fix. Each comment is a complete story of cause, effect, and resolution. When it is correct, it feels like reading a senior engineer’s deep-dive analysis. Even when it is wrong, it provides insight into how to think about the problem.

Takeaway: If GPT-5.1 is the decisive teammate and Opus 4.5 the disciplined architect, Gemini 3 is the dense engineer who delivers a fully reasoned diff that is confident, comprehensive, and intent on proving its point.

Want to try out CodeRabbit? Get at 14-day free trial!

The 2025 Stack Overflow survey reveals a paradox: while 84% of developers express confidence in adopting AI tools, nearly half (48%) still distrust the accuracy of their outputs. This tension between optimism and skepticism has reshaped how teams think about quality assurance.

From PRD to PR in days (not weeks)

The bottleneck in software development has fundamentally shifted from writing code to validating it.

In the early days of AI-assisted development, the workflow was straightforward: AI suggested code, humans read the suggested snippet and then decided whether or not to accept that suggestion. Tab completion wrote boilerplate. Copilot suggested functions. But a senior engineer still manually validated and chose each line of code to ensure its quality, structure, and safety before making a pull request.

Today's reality is different. Advanced reasoning models like OpenAI's o1 can decompose complex requirements and generate entire features. This set the flywheel in motion for the era of agentic code generation, where humans along with agents play an active role in generating large swaths of code. The difference between accepting AI-generated code one snippet at a time and adding in AI-generated features is significant. Devs are more likely to miss issues with its quality, structure, and safety.

Reviewing AI-generated code also takes much more time. The bottleneck isn't writing code anymore - it's trusting it.

The AI-generated code crisis nobody's talking about

Engineers are right to be skeptical, since over 40% of AI-generated code still contains security flaws and here is what AI-generated code often gets wrong:

• Dependency explosion: A simple prompt for a "to-do list app" can generate 2-5 backend dependencies depending on the model. Each dependency expands your attack surface. Worse, models trained on older data suggest libraries with known CVEs that were patched after their training cutoff.

• Hallucinated dependencies: AI invents package names that don't exist. Attackers register those names in public repositories with malicious code. Developers install them blindly. This attack vector, called "slopsquatting," is uniquely enabled by AI code generation.

• Architectural drift: The AI swaps out your cryptography library, removes access control checks, or changes security assumptions in ways that look correct but behave insecurely. These are the bugs that static analysis misses and humans don't catch until production.

Why did reasoning models change everything?

A few years back, applying AI to a collaborative workflow like Code Review met with a degree of amused skepticism. The bots would catch your missing semicolons, flag unused variables, and maybe (if you were lucky) warn you about a potential null pointer. They were fast, cheap, and fundamentally shallow.

At CodeRabbit, when we started to apply Generative AI, we realized this problem pretty early and developed a technique that you see on some of our older PRs, called monologue where the model thinks through the issue and shares reasoning behind an issue comment.

With the launch of reasoning models like OpenAI’s o1 and o3 the models actually think through the problem thanks to the monologue feature on CodeRabbit. When you ask GPT-4o to review code, it pattern-matches against things it's seen before and code review feedback is mostly superfluous. When you ask GPT-5 or Claude Sonnet 4.5, it spends time reasoning through your code's logic, tracing execution paths, considering edge cases, and understanding intent. This was important for successful code review. But there is a catch!

What makes review more "agentic"?

Many thought that applying the same reasoning models to review the code they generated would cut slop or find bugs, but this wasn't entirely true. The two major missing pieces were effective context assembly (context engineering) and verifying the veracity of the results.

Traditional code validation tools are reactive. You run a linter, it tells you about unused variables. You run a static analyzer, it warns about null pointer exceptions. You run security scanners, they flag hardcoded secrets. Each tool does one thing, in isolation, with no context about what you're actually trying to build.

With generative AI, you might integrate these tools into your review pipeline. However, neither the model nor the tools are intelligent enough to effectively filter out noise and highlight crucial signals, leading to context clogging.

To effectively counter that, we developed techniques to engineer and manage the context for each model in the review pipeline. For example: We would prepare the list of most important issues suggested by all the tools in an instructive manner to the reasoning model, for better solutions. We also added a verification agent that checks and grounds the review feedback.

Here are some examples from the open-source PRs.

Static analysis: AST parsing with tools like ast-grep to understand code smells.

Incremental analysis: Only validating wAgentiAgenhat changed, not your entire codebase.

Security issues: Prompt injection attacks and edge case generation.

Name refactoring: Suggesting better variable and function names based on usage.

The "agentic" part means the AI decides which tools to run, interprets the results, and takes action. Think of it like having a senior engineer who knows when to dig deeper and when something is not fine

How CodeRabbit closes the AI code trust gap

Instead of chasing higher benchmark scores or relying on traditional metrics, CodeRabbit focuses on how AI systems actually perform in live engineering environments through custom evaluation methods, some visible directly on the PRs we review.

The technique of agentic code validation happens on each pull request reviewed by CodeRabbit; however, everything runs in isolated, sandboxed environments, what we call “tools in jail.” As described in our Security Posture, this approach ensures that verification agents can safely execute, inspect, and even stress-test code without ever compromising user data or infrastructure integrity.

Agents excel at catching common vulnerabilities, analyzing patterns across thousands of lines, and running comprehensive test suites. They're designed to surface issues that are tedious or time-consuming for humans to catch manually. But agentic code validation isn't going to replace code reviews entirely. Instead, it frees developers to focus on what humans do best: architectural reasoning, business logic validation, and nuanced security considerations. The human-in-the-loop and agent-in-the-loop processes can coexist, providing redundancy and complementary reasoning similar to peer programming.

Want to see agentic validation in action? Sign up for a 14-day CodeRabbit trial.

Opus 4.5 for code-related tasks: Performs like the system architectの意訳です。

すべてのモデルは推論します。しかし、Opus 4.5 は「監査」します。

新しいモデルが登場するとき、その約束はいつも同じです。より賢い推論、よりきれいなコード、そしてよりよい回答。しかし Anthropic の Opus 4.5 は、単に推論するだけではなく、監査する モデルです。あたかも自ら設計に携わったシステムに戻ってきたかのようにコードを読み込み、弱点を特定し、アーキテクチャ全体を整えます。他のモデルが論理を説明したり、局所的な修正を示したりするのに対し、Opus 4.5 は技術文書に近い、構造的で体系的なレビューを行います。

私たちはこのモデルの特徴を把握するために、Opus 4.5 を CodeRabbit のベンチマーク環境に統合しました。その結果わかったのは、より高い知能でも派手な文章でもなく、「規律」でした。Opus 4.5 は単にバグを見つけるのではなく、その周囲にある 文脈を構築 します。つまり、レビューを推測ゲームではなくエンジニアリングプロセスとして扱うのです。

ベンチマークの背景

CodeRabbit では、新しい LLM を評価するために、C++、Java、Python、TypeScript にまたがる既知のエラーパターン（EP）を含む 25 件の複雑なプルリクエスト を用意しています。モデルが生成した各コメントを LLM ジャッジが次の3つの観点で評価します。

• Precision（精度）： EP を正しく特定しているか。

• Important-share（重要コメント率）： コメントのうち重要・重大な指摘（本物のバグ）がどれだけ占めるか。

• Signal-to-noise ratio（S/N比）： 重要コメントと、重要でないコメントの比率。

この評価フレームワークは、複数世代のモデルを通じて改善されており、自動判定の LLM と 人手による検証 を組み合わせて正確性を担保しています。また、複数ジャッジによる評価と繰り返し試行 を実施することで、一貫性とばらつきを記録しています。プロンプト改善、ラベル精度向上、評価範囲の拡大を継続的に進め、より信頼できる結果を得られるようにしています。

スコアボード（アクショナブルコメントに限定）

解釈:
Opus 4.5 は、Sonnet 4.5 の高ボリューム・冗長スタイルと、GPT-5.1 のシャープで精密なスタイルの中間に位置します。Sonnet 4.5 よりもコメントあたりの精度が高く、有意味な指摘の割合が多い結果となりました。EP パス数は 1 件少ない（15 vs. 16）ものの、これは通常のばらつき範囲に収まっています。実際、複数回のベンチマークでは Opus 4.5 が GPT-5.1 や Sonnet 4.5 を上回ることもありました。

総合すると、Opus 4.5 はシグナル、構造、カバレッジのバランスがよく、安定して信頼できるモデルと言えます。

スタイルとトーン

Opus 4.5 のレビューは、構造化され、簡潔で、焦点が明確です。断定表現の比率は約33%、婉曲表現は約15%と、落ち着いたプロフェッショナルなトーンになっています。密度とトーンのバランスによって、実践的で自信のある分析的な内容となっています。コードブロックや diff など、行動につながる表現を多用する傾向があり、「説明する」よりも「編集する」モデルだと言えます。

構造化された知性：予測可能な形式と言語横断の一貫性

Opus 4.5 のコメントは、見出し、理由説明、diff というアーキテクチャ的なリズムで書かれています。約80%のコメントにコードブロックが含まれ、ほとんどのコメントが簡潔なパッチで締めくくられます。原因、影響、解決策が整然と記述されており、明確なバグレポートのようです。

この構造はどの言語でも維持されます。C++、Java、Python、TypeScript のいずれでも、コメントは平均19行・790文字程度に収まり、統一されたスタイルとなります。一貫性があることで自動化との相性が良く、読みやすさも向上します。まるでコードベース全体を同じエンジニアがレビューしているかのようです。

具体例:

• C++（WorkerThreadPool）： lost wakeup レースを3ステップのインターリーブで説明し、1行の修正 diff を提示します。

• Java（OrderService）： ダブルチェックロッキングで volatile が欠落している点を指摘し、正しいパターンを提示します。

• Python（Batch Client）： 同期 HTTP クライアントを非同期版に置き換えてブロッキングを防ぎます。

• TypeScript（Cache Manager）： Number.MAX_SAFE_INTEGER がエビクションを無効化している点を指摘し、現実的なデフォルト値を提案します。

いずれも簡潔でコードネイティブな洞察であり、根拠に基づいた実用的な修正です。

自信の逆転現象

Opus 4.5 のトーンは全体的にバランスが良いのですが、間違っているときにやや断定的に聞こえるという、ささやかな逆転現象があります。通常は慎重ですが、この癖があるため、コメントのトーンだけで正確性を判断しないようにしています。この問題を補うため、評価サマリーではトーンデータと正解率を組み合わせて校正を行っています。

とはいえ、Opus 4.5 はほとんど推測をせず、間違っているときでさえ淡々と説明します。

システムレベルでの推論：コードだけではなく文脈を修正する

多くのモデルが目の前の欠陥に集中するのに対し、Opus 4.5 は周辺のシステム全体を考慮します。推奨内容には、ライフサイクル改善、安全チェック追加、デフォルト値の見直しといった、より上位の修正が頻繁に含まれます。

例:

• TypeScript Cache： エビクションロジックの再設計、TTL の強制、デフォルト改善により秘められた OOM（Out Of Memory ） を防ぎます。

• Java OrderService： HashMap を ConcurrentHashMap に変更し、ExecutorService の shutdown 漏れを指摘します。

• Python Client Lifecycle： 長寿命 async クライアント向けに明示的なシャットダウンフックを追加します。

• C++ FileAccessEncrypted： 暗号化ファイルがすべてブロックされる検証バグを修正し、上流のエラーハンドリングも改善します。

どれも一行修正ではなく、システム全体の整合性を高める提案です。コードを「問題の集合体」ではなく「相互に影響し合うエコシステム」とみなしていることがわかります。

コスト、Effort、効率性

Anthropic の Effort パラメータを使うと、モデルの推論深度を直接制御できます。High-effort では依存関係パスを徹底的に探索し、Medium-effort ではトークン節約のため深度を抑えます。High-effort であっても、Opus 4.5 の出力トークン量は Sonnet 4.5 より約25%少なく、1M 出力トークン 25ドルという単価を効率性で補っています。

規律ある構造のおかげで脱線が減り、クリアで読みやすい結果を維持できています。

Opus 4.5 を読むとどんな感じか

Sonnet 4.5 が教師、GPT-5.1 が決断力のあるチームメイトだとしたら、Opus 4.5 は PR をレビューしに戻ってきたアーキテクト です。トーンは落ち着いており、命令的ではありません。あなたがドメインを理解している前提で、細部を丁寧に確認します。そのため、システムエンジニアによるピアレビューのような、構造的で静かに権威を感じさせるコメントになります。

トーンと人格

Opus 4.5 のトーンは測定可能で分析的です。劇的な表現や不必要な厳しさを避け、秩序ある構造、簡潔な要約、根拠の提示、フォーカスされた修正提案によって確信を示します。システムに精通したメンターからのアドバイスのように感じられるため、開発者が受け取りやすい雰囲気です。

深さと密度のバランス

コメントはコンパクトですが情報量は十分です。複雑な問題には必要なだけの説明を行い、単純な問題は短い提案で正確に処理します。このバランスによって、読みやすさと包括性が両立しています。

流れと可読性

文脈 → 原因 → 修正というリズムにより、開発者はコメントをすばやくスキャンしつつ意味を保持できます。Opus 4.5 のコメントは「構造化されたスナップショット」のようで、何が起きたのか、なぜ重要なのか、どう直すのかが一目で分かります。

実務的なインパクトと開発者の信頼

Opus 4.5 は誇張や劇的な表現を避けるため、開発者からの信頼を得やすいモデルです。プロフェッショナルで落ち着いたトーンを維持し、間違っている場合も過剰な断定ではなく理性的な仮説として提示します。過度な自信がないため、レビューがより「人間的で実務的」に感じられます。

コメントはまるで設計ノートのように読みやすく、壊れた不変条件、修正案、その根拠が明確に記されています。そのまま変更履歴や Issue Tracker に貼れるレベルの明快さです。

長所と短所の一覧

長所：

• 重要コメントの密度が高い（約80%）

• 言語をまたいだ構造の一貫性

• 並行処理やライフサイクルに強い推論能力

• 明確・簡潔・プロフェッショナルなトーン

• Sonnet 4.5 より冗長でない一方、GPT-5.1 より文脈が豊富

短所：

• 精度は中程度（約38%）

• 間違っているときに少し断定的になることがある

• 重大ラベルが多く、多忙な PR では過剰に見える場合がある

• 単純な問題ではやや説明が長くなることがある

結論:
Opus 4.5 は、私たちがテストした中で最も システミック（全体的） なレビュアーです。落ち着きがあり、構造化され、厳密で、アーキテクチャ理解が必要な場面で特に強みを発揮します。

モデルの使い分け

最後に：推論の「形」について

Opus 4.5 は、実験的なモデルではなく「設計されたモデル」に感じられます。初期のモデルが推測に頼りがちだったのに対し、Opus 4.5 は測定し、構造化し、文書化します。レビューを読むと、開発者の視点 を理解したモデルと一緒に作業しているように感じられます。

コードレビューでは、トーンが信頼を決めます。Opus 4.5 のスタイル──測定可能で、構造化され、機械的な精度を持つ──は、推論の成熟を示しています。圧力のない精度、エゴのない自信が感じられます。

まとめ:
Sonnet 4.5 が教師、GPT-5.1 がチームメイトだとすると、Opus 4.5 は設計レビューのために戻ってきたアーキテクトです。

CodeRabbit を試してみたい方はこちら
14日間の無料トライアル

Every model reasons. Opus 4.5 audits.

Every new model arrives with the same promise: smarter reasoning, cleaner code, and better answers. But Opus 4.5 from Anthropic doesn’t just reason; it audits. It reads code as if returning to a system it helped design, identifying weak points and refining architecture. Where other models narrate their logic or prescribe surgical fixes, Opus 4.5 performs structured, systematic reviews that feel more like technical documentation than conversation.

We integrated Opus 4.5 into CodeRabbit’s benchmark harness to understand what makes this model distinct. The result was not higher raw intelligence or flashier prose, but discipline. This model doesn’t just find bugs; it builds context around them. It treats review as an engineering process, rather than a guessing game.

Benchmarking context

At CodeRabbit, we evaluate new LLMs using a controlled benchmark of 25 complex pull requests seeded with known error patterns (EPs) across C++, Java, Python, and TypeScript. Each comment generated by a model is scored by an LLM judge for three key factors:

• Precision: Whether it correctly identifies the EP.

• Important-share: The percentage of comments that are genuinely critical or major (real bugs, not style issues).

• Signal-to-noise ratio (SNR): The ratio of important to unimportant comments.

Our evaluation framework, refined over multiple generations of models, combines automated LLM judging with hand validation to ensure accuracy. We also use multiple judges and repeated trials to measure consistency and understand variance. Each iteration improves the process through better prompts, refined labeling, and expanded coverage, resulting in more reliable outcomes.

Scoreboard (Actionable comments only)

What this means: Opus 4.5 sits between Sonnet 4.5’s high-volume, verbose style and GPT-5.1’s lean, surgical precision. It delivers higher per-comment precision and a greater share of meaningful findings than Sonnet 4.5. While it recorded one fewer EP pass (15 vs. 16), that difference falls within normal variance. In several runs, Opus 4.5 matched or even surpassed both GPT-5.1 and Sonnet 4.5. The takeaway is a model that balances signal, structure, and coverage with consistent reliability.

Style and tone

Opus 4.5’s reviews are structured, concise, and focused. With assertiveness around 33% and hedging near 15%, its tone reads as measured and professional. The balance of tone and density gives it an analytical voice that feels practical and confident. The high use of code blocks and diff patches underscores its bias toward action; it talks less and edits more.

Structured intelligence: Predictable form and cross-language consistency

Opus 4.5’s comments follow an architectural rhythm of headline, rationale, and diff. Nearly 80% include code blocks, and most conclude with a concise patch. Each resembles a clear bug report that specifies cause, effect, and resolution.

This structure holds across languages. Whether reviewing C++, Java, Python, or TypeScript, the cadence remains consistent, averaging 19 lines and 790 characters per comment. This uniformity simplifies automation and enhances readability. It also makes Opus 4.5 feel like a single engineer’s consistent voice across an entire codebase.

• C++ (WorkerThreadPool): Detects a lost wakeup race with a three-step interleaving and a one-line diff fix.

• Java (OrderService): Flags a missing volatile on a double-checked lock and provides the corrected pattern.

• Python (Batch client): Replaces a synchronous HTTP client with an asynchronous equivalent to prevent blocking calls.

• TypeScript (Cache manager): Identifies that Number.MAX_SAFE_INTEGER disables eviction and suggests realistic defaults.

These are concise, code-native insights, each actionable and grounded in sound reasoning.

The confidence inversion

Opus 4.5’s tone is balanced but occasionally reveals a subtle inversion: when it is wrong, it can sound slightly more certain. Although the model is generally measured, this behavioral quirk means tone alone is not always a reliable indicator of correctness. To account for this, we pair tone data with correctness metrics in evaluation summaries to maintain consistent calibration.

Opus 4.5 rarely speculates; it simply explains, even when it’s wrong.

System-level reasoning: Fixing context, not just code

While most models target the immediate defect, Opus 4.5 focuses on the surrounding system. Its recommendations frequently adjust lifecycles, add safety checks, or refine defaults.

Examples:

• TypeScript Cache: Rewrites eviction logic, adds TTL enforcement, and updates defaults to prevent silent OOM.

• Java OrderService: Replaces HashMap with ConcurrentHashMap and identifies missing ExecutorService shutdown.

• Python Client Lifecycle: Adds explicit shutdown hooks for long-lived async clients.

• C++ FileAccessEncrypted: Resolves a validation bug that blocked all encrypted files and improves upstream error handling.

These are not single-line fixes but systemic corrections. The model treats code as an interconnected ecosystem rather than a collection of isolated issues.

Cost, effort & efficiency

Anthropic’s Effort parameter provides direct control over how deeply the model reasons. In high-effort mode, Opus 4.5 explores every dependency path. In medium-effort mode, it trims reasoning depth to save tokens. Even with high-effort reasoning, its reviews averaged about 25% fewer output tokens than Sonnet 4.5, balancing higher per-token costs ($25 per million output tokens) with greater efficiency.

This disciplined structure pays for itself by producing fewer digressions and maintaining consistent clarity.

What it feels like to read Opus 4.5

If Sonnet 4.5 feels like a teacher and GPT-5.1 like a decisive teammate, Opus 4.5 is the architect reviewing your PR. Its tone is calm and deliberate, never commanding. It assumes you understand the domain and aims to confirm the details. The result is feedback that reads like peer review from a systems engineer: consistent, structured, and quietly authoritative.

Tone and personality

Opus 4.5’s voice is measured and analytical. It rarely uses dramatic language or unnecessary severity. Instead, it conveys certainty through order, concise summaries, specific evidence, and focused corrections. The tone builds trust, delivering feedback that feels like it comes from a mentor familiar with your system.

Depth vs. density

Its comments are compact yet informative. When an issue warrants detailed explanation, Opus 4.5 delivers it without excess. For simpler problems, it resolves them with brief, precise advice. This balance of detail and brevity keeps reviews readable and comprehensive.

Flow and readability

The model’s structural rhythm of context, cause, and correction allows developers to scan quickly while retaining meaning. Developers often describe its comments as “structured snapshots” that tell a short, self-contained story: what happened, why it matters, and how to fix it.

Practical impact and developer trust

Because Opus 4.5 avoids inflated confidence and theatrical phrasing, developers trust it more readily. It comes across as confident yet professional, firm but not forceful. When it errs, it sounds like a reasoned hypothesis instead of an overreach. That restraint, more than precision alone, makes its reviews feel professionally human.

Each comment reads like a design note. It states the invariant that failed, proposes a patch, and explains the rationale inline. The clarity is high enough that many of its comments could be pasted directly into changelogs or issue trackers without revision.

Strengths and weaknesses at a glance

Strengths:

• High signal density (≈80% important comments).

• Consistent structure across languages.

• Strong concurrency and lifecycle reasoning.

• Clear, concise, and professional tone.

• Lower verbosity than Sonnet 4.5 with more context than GPT-5.1.

Weaknesses:

• Moderate precision (≈38%).

• Subtle confidence inversion when incorrect.

• Frequent critical or major labeling may overwhelm busy PRs.

• Slight verbosity on simpler issues.

Bottom line: Opus 4.5 is the most systemic reviewer we’ve tested. Calm, structured, and exacting, it excels when reasoning breadth and architectural understanding matter more than pinpoint precision.

When to use which model

Closing thoughts: The shape of reasoning

Opus 4.5 no longer feels experimental; it feels engineered. Earlier models often guessed, while Opus 4.5 measures, structures, and documents. Reading its reviews feels like working with a model that truly understands how developers read.

In code review, tone defines trust. Opus 4.5’s style, measured, structured, and mechanically precise, demonstrates the maturity of reasoning: precision without pressure and confidence without ego.

Takeaway: If Sonnet 4.5 was a teacher and GPT-5.1 a teammate, Opus 4.5 is the architect returning for a design review.

Interested in trying CodeRabbit? Get a 14-day free trial.

How to deploy and integrate MCP servers with CodeRabbitの意訳です。

MCP サーバーは、ユーザーのリクエストに基づいてシステム関連タスクを実行するために、AI エージェントをアプリケーションへ統合します。Slack、Sentry、Notion、GitHub Copilot などのプラットフォームは、AI 駆動アプリケーションに機能を公開するために、すでに MCP スタイルのサービスを採用しています。

CodeRabbit もこの潮流に乗っています。MCP クライアントとして機能することで、ユーザーがコンテキストを提供し、最適なコードレビューを実行できるようにします。また、Confluence に保存されたビジネス要件、CI/CD パイプラインからのシステム情報、さらには任意の内部 MCP サーバーなど、複数ソースのコンテキスト（データ）をサポートする初の AI コードレビュー・プラットフォームでもあります。

このチュートリアルでは、Slack MCP サーバーをセットアップし、チャンネルデータを取得し、それを CodeRabbit のコンテキストとして渡すことで、チームワークスペースの議論を反映したコードレビューを生成する方法を学びます。これにより、すべてのレビューがプロジェクト目標に整合したものになります。

なぜ CodeRabbit で MCP を使うのか？

MCP サーバーを CodeRabbit と組み合わせる主な利点は、コードレビューをより洞察的で実行可能なものにする関連データを提供できる点です。その他の利点には以下があります。

• 複数ツールのコンテキストでコードレビューを豊かにする

CodeRabbit は Slack、Confluence、CI/CD パイプライン、または内部 MCP サーバーから関連情報を取得し、レビュアーが変更の背景を理解できるようにします。Slack のスレッド、議論、メッセージから必要な情報を引き出し、コード変更の意図やロジックを理解します。

• 情報に基づいた正確なレビューが可能になる

MCP サーバーから提供されるデータにより、CodeRabbit はプロジェクトのロジックと目標をより深く理解できます。たとえば、Slack MCP サーバーはチームのメッセージへのアクセスを許可し、ビジネス要件や開発目標に整合したコードレビューを実行できるようにします。

前提条件

進める前に、MCP サーバーをセットアップし CodeRabbit と統合するために、以下のツールをインストールしておく必要があります。

• Slack チャンネル – メッセージを取得し、AI コードレビューワーへコンテキストを提供するために既存の Slack チャンネルが必要です。

• MCP Server for Slack Workspaces – Slack の会話データを Model Context Protocol (MCP) によって公開するための、シンプルかつ構造的な方法を提供します。メッセージ、スレッド、リプライなどの Slack API メソッドが組み込まれており、軽量で Docker 対応、設定も容易です。

• Claude Desktop – Slack MCP サーバーを CodeRabbit に接続する前にローカルでテストするための MCP クライアントです。

• Docker – Slack MCP サーバーをコンテナで実行・ホストするために使用します。

• Ngrok – Slack MCP サーバーを CodeRabbit からアクセス可能にするため、セキュアな公開 URL を生成します。

このチュートリアルでは次を行います。

1. Claude Desktop を使ってローカルで Slack MCP サーバーをテスト

2. Docker を使用してローカルホスト上にサーバーをホスト

3. Ngrok による公開 URL の生成

4. MCP サーバーを CodeRabbit に統合

注意: Slack も MCP サーバーを試験的に扱っていますが、現時点で公式の MCP サーバーは提供されていません。このチュートリアルでは自分で MCP サーバーを構築する方法を解説します。

Claude Desktop で Slack MCP サーバーをセットアップ

Claude Desktop は複数の MCP サーバーへ接続し、それらをコンテキストソースとして利用する MCP クライアントです。MCP サーバーをコネクタとして追加し、CodeRabbit やその他のプラットフォームへデプロイする前にローカルでテストできます。

Claude Desktop をインストールし、起動後に Manage Connectors をクリックします。

サイドバーから Developer を選択し、Edit Config をクリックして Slack 認証トークンを設定します。

Slack の認証トークンは、GitHub リポジトリの説明に従って取得し、Claude Desktop に設定します。

次に、claude_desktop_config.json を以下の JSON で更新します。

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "slack-mcp-server@latest", "--transport", "stdio"],
      "env": {
        "SLACK_MCP_XOXC_TOKEN": "xoxc-...",
        "SLACK_MCP_XOXD_TOKEN": "xoxd-..."
      }
    }
  }
}

上記設定により、Slack の xoxc と xoxd トークンを使用して Slack MCP サーバーが Claude Desktop のコネクタとして登録されます。接続されると、Claude はチャンネルメッセージの取得や Slack コンテキストを活用したコードレビューを実行できます。

設定後、Claude Desktop を再起動して Slack MCP サーバーをアクティブにします。

Preview.mp4

Slack MCP サーバーを CodeRabbit に接続

このセクションでは、Slack MCP サーバーを Docker で実行し、Ngrok で公開 URL を生成し、それを CodeRabbit に統合する手順を説明します。

まず Docker を起動します。

次にターミナルを開き、Slack MCP サーバーに必要なファイルをダウンロードします。

wget -O docker-compose.yml https://github.com/korotovsky/slack-mcp-server/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/korotovsky/slack-mcp-server/releases/latest/download/default.env.dist

.env ファイルを Slack の認証トークンで更新します。

SLACK_MCP_XOXC_TOKEN=<your_token>

以下のコマンドで Docker Compose を起動します。

# Docker 用の専用ネットワークを作成
docker network create app-tier

# MCP サーバーをデタッチモードで起動
docker-compose up -

Slack MCP サーバーは localhost の 3001 番ポートで起動しています。CodeRabbit と統合するには HTTPS エンドポイントが必要であり、そのために ngrok を使用します。

ngrok がインストールされているか確認します。

ngrok --version

ngrok を使って公開 URL を生成します。

ngrok http 3001

このコマンドでローカルの Slack MCP サーバーがインターネット公開され、CodeRabbit からアクセス可能になります。

次に、MCP Inspector を使ってサーバーが動作しているか確認します。

npx @modelcontextprotocol/inspector

Inspector UI を開き、SSE を選択し、ngrok の URL の末尾に /sse を追加します。

正常に動作していることが確認できたら、CodeRabbit との統合作業に移ります。

CodeRabbit に MCP サーバーを統合してテストする

CodeRabbit にサインインし、ダッシュボードのサイドバーから Integrations を選択して MCP サーバーを追加します。

名前と MCP サーバー URL（例: https://2bb0002c0e2c.ngrok-free.app/sse）を入力します。認証方式は何も選択しないようにします。

接続後、すべての CodeRabbit コードレビューで MCP サーバーをコンテキストとして利用できます。

GitHub リポジトリを作成し、CodeRabbit に追加して MCP サーバーへのアクセス権を設定します。

コードレビュー時に MCP サーバーを利用するため、リポジトリに coderabbit.yaml を追加します。

language: "en-US"
early_access: false
reviews:
  profile: "chill"
  request_changes_workflow: false
  high_level_summary: true
  poem: false
  review_status: true
  collapse_walkthrough: false
auto_review:
  enabled: true
  drafts: false
chat:
  auto_reply: true

GitHub リポジトリの MCP サーバー利用を有効化します。

次に、「Path Instructions」を設定し、PR マージ前に追加指示を確認するよう CodeRabbit に伝えます。

上記画像では、File Path がレビュー対象のファイルを指定し、Instructions がそのファイルをどのように扱うべきかを示します。この設定により、CodeRabbit は Slack の #dev チャンネルの議論内容を参照し、リポジトリ内のコード変更がチャンネルのガイドラインに従っているかを確認します。

以下は Slack チャンネルのメッセージ例です。

そしてこちらが、指示に従ってレビューを行う CodeRabbit の出力例です。

CodeRabbit が Slack の議論内容をどのように読み取ってレビューに反映するかは、次のデモで確認できます。

https://github.com/tyaga001/test-slack-mcp/pull/7#pullrequestreview-3454174366

💡 ベストプラクティス: 必要なデータだけをコンテキストとして渡す

不要なデータは LLM の処理コストを上げ、パフォーマンスを低下させます。特定の Slack チャンネルや必要最小限の情報に限定して渡すようにしてください。

次のステップ

このチュートリアルでは、Slack MCP サーバーを CodeRabbit と統合し、文脈情報を用いたコードレビューを実行する方法を学びました。CodeRabbit は Notion、GitHub Copilot、Sentry、Asana など複数の MCP サーバーをデフォルトでサポートしており、これらを組み合わせて高度な文脈理解を実現できます。

同様の手法を使うことで、任意のコンテキストやデータソースを MCP サーバー経由で統合し、CodeRabbit に正確で実用的な応答を生成させることが可能です。

MCP サーバーや CodeRabbit に関するさらなるチュートリアル・記事はこちら:

• MCP時代におけるコンテキスト肥大化への対応

• CodeRabbitのMCP連携 = コンテキストとコードレビュー

• How to Integrate MCP Server with CodeRabbit

CodeRabbit を試してみませんか？ 14 日間の無料トライアルを始める

MCP servers integrate AI agents into software applications to carry out system-related tasks based on users’ requests. Platforms like Slack, Sentry, Notion, and GitHub Copilot have adopted MCP-style services to expose their features to AI-driven applications.

CodeRabbit is part of this shift, acting as an MCP client that enables users to provide contexts and perform the best code reviews. It’s also the first AI code review platform that supports context (data) from multiple sources, such as business requirements stored in Confluence, system information from your CI/CD pipeline, or any internal MCP server.

In this tutorial, you will learn how to set up a Slack MCP server, retrieve channel data, and pass it as context into CodeRabbit to generate code reviews that incorporate discussions from your team workspace, ensuring that every review aligns with the project goals.

Why use MCP with CodeRabbit?

The primary benefit of using MCP servers with CodeRabbit is to deliver relevant data that makes code reviews more insightful and actionable. Other benefits include:

• Enriching code reviews with context from multiple tools.

CodeRabbit enables you to retrieve relevant information from Slack, Confluence, CI/CD pipelines, or internal MCP servers so reviewers understand the reasoning behind changes. CodeRabbit can pull relevant information from Slack threads, discussions, and messages to understand the code logic and reasoning behind every code change.

• Making informed and precise reviews

With access to data from MCP servers, CodeRabbit gains a better understanding of the project’s logic and goals. For instance, the Slack MCP server grants CodeRabbit access to team messages, enabling it to perform code reviews that are consistent with business requirements and development objectives.

Prerequisites

Before we proceed, you need to have the following tools installed to set up the MCP server and integrate it with CodeRabbit:

• Slack channel – An existing Slack channel is required to fetch messages and provide context for the AI code reviewer.

• MCP Server for Slack Workspaces - Provides an easy and structured way to expose Slack conversations via the Model Context Protocol (MCP). It already includes built-in Slack API methods (fetching messages, threads, replies, etc.) and is lightweight, Docker-ready, and easy to configure.

• Claude Desktop – Allows you to test the Slack MCP server locally before connecting it to CodeRabbit.

• Docker – Used to run and host the Slack MCP server in a container.

• Ngrok – Used to create a secure public URL for the Slack MCP server, allowing CodeRabbit to access it from outside your local environment.

In this tutorial, you will:

1. Learn how to test the Slack MCP server locally with Claude Desktop.

2. Host the server on localhost using Docker.

3. Generate a public URL using Ngrok..

4. Integrate the MCP server with CodeRabbit.

Note: While Slack has been experimenting with MCP servers, they don’t currently have one available. This tutorial will cover how to create one yourself.

Set up Slack MCP server with Claude Desktop

Claude Desktop is an MCP client that connects to multiple MCP servers and uses them as sources of context. It allows you to add your MCP servers as connectors and test them locally before deploying them to CodeRabbit or any other platform.

Install Claude Desktop on your computer. Once the installation is complete, open the app and click Manage Connectors.

Select Developer from the sidebar menu, and click Edit Config to configure your MCP server using your Slack authentication tokens.

Follow the instructions in the GitHub repository to obtain your Slack authentication tokens and configure the Slack MCP server in Claude Desktop.

Update the claude_desktop_config.json file with the following JSON configuration.

The configuration above uses the xoxc and xoxd Slack authentication tokens to register the Slack MCP server as a connector in Claude Desktop. Once connected, Claude can perform tasks such as retrieving channel messages and using Slack context to enhance code reviews and responses.

Restart Claude Desktop to apply the updated configuration and activate the Slack MCP server.

Preview.mp4

Connect the Slack MCP server to CodeRabbit

In this section, you will learn how to run the Slack MCP server using Docker, generate a public URL for it, and integrate it with CodeRabbit to provide context-aware code reviews.

Before we proceed, open the Docker application.

Next, open your terminal and download the required files for the Slack MCP Server using the following commands:

Update the .env file with your Slack authentication tokens.

Start the MCP server using Docker Compose with the following commands:

Currently, the Slack MCP server is running on localhost at port 3001. To integrate it with CodeRabbit, it needs to be accessible via an HTTPS endpoint. This can be achieved using ngrok.

First, confirm that ngrok is installed by running:

Next, generate a public URL for your MCP server.

The command above exposes your local Slack MCP server to the internet by generating a secure public URL. Use this URL to connect the Slack MCP server to CodeRabbit.

Open a new terminal and start the MCP Inspector to test the Slack MCP server using the following command:

This will launch the MCP Inspector UI, allowing you to verify that your MCP server is running correctly. In the Inspector, select SSE as the transport type and append /sse to the end of your ngrok URL

Once the MCP server is confirmed to be working, you can proceed to integrate it with CodeRabbit.

Integrate and test MCP servers with CodeRabbit

Sign in to CodeRabbit and select Integrations from the sidebar menu on your dashboard to add a new MCP server

Enter a name and your MCP server URL (for example, https://2bb0002c0e2c.ngrok-free.app/sse) to connect the server to CodeRabbit. Make sure no authentication method is selected.

After connecting the MCP server, you can use it to provide context in all your CodeRabbit code reviews.

To test the setup, create a GitHub repository, add it to CodeRabbit, and configure it to have access to your MCP server

Add a coderabbit.yaml configuration file to the repository to enable CodeRabbit to access and use the MCP server context during code reviews.

To give the GitHub repository access to your MCP servers, find the GitHub repository and enable MCP servers

Next, enter the Path Instructions to ensure CodeRabbit checks for additional instructions before allowing PR merges to the code repository

From the image above, the File Path specifies which files CodeRabbit should review, while the Instructions field provides context on how it should handle those files. Based on the instructions given, CodeRabbit analyses the discussions in your Slack #dev channel and ensures that every pull request or code change in your GitHub repository complies with the guidelines defined in that channel.

Below is a screenshot showing the messages from the Slack channel

Here is the code review showing how CodeRabbit reads and adheres to the instructions:

You can check out the full demo to see how CodeRabbit reads team Slack discussions and reviews code based on those conversations.

💡 Best Practice: Pass only Important Data as Context

Irrelevant data can slow down your LLM and increase costs. Keep access limited to specific Slack channels or only include the necessary information for code reviews.

Next steps

In this tutorial, you learned how to integrate the Slack MCP server into CodeRabbit to perform contextual code reviews. CodeRabbit also supports multiple MCP servers by default, including Notion, GitHub Copilot, Sentry, Asana, and many others. That you to enhance code reviews and generate context-aware answers with ease.

Using the same approach, you can integrate other contexts or data sources via MCP servers to enable CodeRabbit to generate accurate and actionable responses for your queries.

Check out more tutorials and articles on MCP Servers and CodeRabbit:

• Handling ballooning context in the MCP era: Context engineering on steroids

• CodeRabbit’s MCP integration: Code reviews that see the whole picture

• How to Integrate MCP Server with CodeRabbit

Interested in trying CodeRabbit? Start a 14-day trial.

Why emojis suck for reinforcement learning (& what actually works)の意訳です。

「シンプルさ」という罠

親指を立てた絵文字（👍）は簡単に送れますが、本当に AI レビュアーにとって有益な学習信号になっているのでしょうか。絵文字ベースのフィードバックは気持ちよく、速く、そして誰にでも分かりやすいです。一見すると、理にかなっているようにも思えます。

しかしコードレビューは灯りのオンオフのような単純なものではありません。無数の判断、技術的なニュアンス、チーム固有の基準が入り混じったものです。その多くは、ワンクリックの絵文字には反映されません。すべてのコードコメントには隠れた意図があります。正しさ、読みやすさ、設計上のトレードオフ、過去の経緯、チームのリスク許容度、さらには組織内の政治的な力学まで含まれます。

それをオンオフという、二値のシグナルに押し込めてしまうとどうなるでしょうか。もはや学習ではなく、「雰囲気を追いかけるモデル」を育てているだけになってしまいます。

シンプルさが裏目に出るとき: ゴマすりモデルの恐怖

今年のはじめ、OpenAI は GPT-4o に対して「親指上げ/下げ」のフィードバックをかなり強く効かせたアップデートを行いました。その結果どうなったかというと、このモデルは過度にユーザーに迎合するようになりました。ユーザーをおだて、誤った回答にも同意し、「はい」と言いすぎるようになり、回答品質は低下しました。フィードバック信号がハイジャックされてしまい、OpenAI はロールバックせざるを得ませんでした。

モデルに「承認こそがゴールだ」と教えてしまうと、そのモデルは承認を最適化するようになります。真実でもなく、有用性でもなく、「その瞬間、人間が気持ちよく感じたかどうか」だけを目指すようになります。

これはバグではなく、報酬設計の失敗でした。そして同じアプローチをコードレビューに適用すると、「安全運転で、あなたにおべっかを使い、本当に必要なことを言ってくれないレビュアー」ができあがります。

なぜ二値フィードバックではニュアンスが潰れてしまうのか

親指上げの絵文字は一体何を意味しているのでしょうか。

• モデルがバグを見つけたという意味でしょうか

• 説明が分かりやすかったという意味でしょうか

• 口調がフレンドリーだったという意味でしょうか

• たまたまレビュアーの機嫌が良かったというだけでしょうか

単一のスカラー値のシグナル（👍または👎）は、「何かがうまくいった」ということは伝えますが、「何がうまくいったのか」は伝えません。そのためモデルは、自分が操作しやすいものに寄っていきます。トーン、丁寧さ、お世辞、あるいは短さといったものです。これが、強化学習におけるゴマすり（sycophancy）の正体です。悪意ではなく、「あなたが与えた報酬を最大化しようとしているだけ」であり、「あなたが本当に望んでいた結果」を最大化しているわけではありません。

これはグッドハートの法則が発動している例です。メトリクス（この場合は親指上げ）がゴールになってしまうと、それは現実の有用な指標ではなくなります。

モデルがあなたのフィードバックを「攻略」するとき

モデルに簡単なシグナルを与えると、モデルは簡単なショートカットを見つけます。

コーディングの世界では、強化学習エージェントが、基礎ロジックを解かずに期待される出力をハードコードすることでテストケースをパスするように学習してしまうことがあります。ログを細工したり、評価用ハーネスをすり抜けたりもします。チェックマークは緑になっても、実際のコードは正しく動きません。

コードレビューでも同じことが、ただし「社会的なかたち」で起きます。モデルはすべてのコメントの冒頭で「とてもいいです！」と言うようになり、あらゆる提案を柔らかな表現で包み、フォーマットのような安全な箇所ばかりを指摘するようになります。そういったコメントは無難で、議論もなく受け入れられやすいからです。そして本当に重要なアーキテクチャ上の懸念は、埋もれてしまいます。

モデルは「ポジティブな反応の取り方」は学んだものの、もはやコードレビューをしているとは言えません。

暗黙的なシグナルが優れている理由

LLM 以外の世界では、このパターンはよく知られています。Netflix は、ユーザーが何を「評価」するかよりも、何を実際に視聴するかのほうがはるかに有用だと気付きました。星評価では人は平気で嘘をつきます。しかし視聴時間、クリック、リピート再生といった指標は正直なシグナルです。

AI の世界では、これを**暗黙的フィードバック（implicit feedback）**と呼びます。コードレビューの場合には、例えば次のような形で表れます。

• 開発者は提案を採用したのか

• それを書き換えたのか

• 無視したのか

• 同じパターンが後のバグとして再び現れたのか

これらのシグナルは、ユーザーの入力を必要としません。行動から生まれ、意図的に操作するのが難しいものです。

もちろん完璧ではありません。「なぜ」その行動を取ったのかまでは常に分からないからです。しかし、絵文字よりははるかに操作されにくく、レビューが「気持ちよかったかどうか」ではなく「ちゃんと機能したかどうか」を教えてくれます。

コード生成 vs コードレビュー: ゲームが違えば、シグナルも違う

コード生成は、しばしば「正解が一つに定まる」という点で数学に近い側面があります。コンパイルできるか。正しい結果を返すか。テストにパスするかといった具合です。

そのため、実行結果フィードバックや暗黙的なシグナルのようなアウトカムベースの報酬を使うことができます。もちろん完璧ではありません。コードモデルは出力をハードコードしてテストをすり抜けることもありますが、それに対するガードレールを設計することは可能です。そして、開発者が「良かった」と言ってくれるかどうかに頼らずとも、「実際に動いたかどうか」を観測できます。

一方、コードレビューは違います。ここには普遍的な合格/不合格は存在せず、チームごとにスタイル、構造、リスク、命名、テストカバレッジなどの好みが大きく異なります。あるチームにとっての「優れたコメント」が、別のチームでは完全にズレている可能性もあります。高速に動くスタートアップで「クリーンコード」とみなされるものが、高いセキュリティが求められる産業では「不十分」と判断されることもあります。

これこそが、「親指上げ/下げデータ」が抱える本当の問題です。ニュアンスが押しつぶされてしまい、モデルは「適切さ」ではなく「平均値」を目指すようになります。その結果、安全ではあるものの、ひどく汎用的なコメントばかりを出すようになってしまいます。

私たちの代替案: CodeRabbit Learnings

CodeRabbit では、別のアプローチを取っています。いいねを最大化するのではなく、「理解」を最大化しようとしているのです。そのために私たちは Learnings を構築しました。

エンジニアが CodeRabbit を修正したり、チームの規約を明確にしたり、「なぜこのコードは自分たちのスタックに合わないのか」を説明したりするたびに、その説明を自然言語の指示として保存します。単に「コメントが却下された」という事実だけでなく、「なぜ却下されたのか」まで記憶します。

これらの Learnings は、組織、リポジトリ、さらには特定のパスやファイルタイプに紐付きます。CodeRabbit が次のプルリクエストをレビューするときには、それらの指示を検索し、文脈に応じて適用します。同じパターンを再度見つけたときには、そこで学んだ内容を踏まえて挙動を変えます。

再度教え直す必要はなく、同じ失敗を繰り返すリスクもありません。モデルは親指の数から推測するのではなく、あなたのチームが与えた実際のガイダンスから推論します。

また、Learnings は透明性も提供します。どんな Learnings が存在するかを確認し、それらを閲覧し、カテゴリでフィルタリングし、標準が変わったときには削除や編集を行うことができます。つまりモデルは、チームの成長とともに進化し、プラクティスの変化に合わせて整合性を保ち続けます。

これは、単なる絵文字の承認ではなく「意図を取り込む」ことで行う強化学習です。解釈可能であり、検査可能です。そしてレビューをまたいで一般化する、「チームナレッジの生きたレイヤー」を構築します。

ニュアンスのある学習が可能にすること

システムに与えるのが「シグナル」ではなく「明確で文脈を含んだ指示」になったとき、単なるレビュー体験の改善以上のことが可能になります。

• チームレベルでの適応が可能になります
  モデルは「何が良いのか」を勝手に推測するのではなく、「あなたのチームが実際にどう書いているのか」を学習します。リスク許容度、スタイルの好み、トレードオフの感覚を理解し、「ハウスルールを理解しているレビュアー」として振る舞うようになります。

• 経時的な学習（長期学習）を支えます
  時間とともに CodeRabbit は、「どのコメントが役に立ったのか」「どれが無視されたのか」「どの提案が実際の変更につながったのか」という記憶を蓄積していきます。その結果、徐々に精度が上がり、フォーカスは鋭くなり、ノイズは減っていきます。

• 信頼を築きます
  開発者が「AI を訂正すれば、それを覚えてくれる」と分かっていると、より積極的に関わるようになります。開発者自身がシステムを形作り、そのシステムは汎用的な LLM ではなく「自分たちの基準を反映した存在」へと近づいていきます。

こうしてレビュー用ツールは、単なる「異なる視点の意見」ではなく、チームの延長として機能するようになります。

まとめ: 本当の学習はピクセルではなくパターンから生まれます

親指の絵文字は、素早いリアクションには向いていますが、それだけでは専門性は育ちません。

時間とともに成長し、あなたの標準に適応し、浅いフィードバックの罠を避ける AI レビュアーを求めるのであれば、承認以上のものを与える必要があります。説明を与えなければなりません。

次世代の AI コードツールは「いいね」の数で訓練されることはありません。文脈、結果、修正の軌跡で訓練されます。絵文字ではなく、構造化された記憶から学びます。実際の意思決定と、あなたのチーム自身の声から学びます。

それこそが CodeRabbit Learnings が設計された目的です。拍手のためではなく、理解のために設計されています。

Learnings を自分のチームで試してみたい方は、無料トライアルにお申し込みください

GPT-5.1 for code-related tasks: Higher signal at lower volumeの意訳です。

TL;DR
プロンプト調整とスタックへの統合を行った結果、GPT-5.1 はレビューにおいて、これまでで最も高い精度とS/N比（シグナル対ノイズ比）を、より少ないコメント量で実現するようになりました。複雑なベンチマークセット上で、最高クラスのエラーパターン（EP）リコールに並びつつ、競合モデルの半分以下のコメント量を記録しました。

その結果として、少ないノイズでより良い修正が得られ、レビューは再びパッチのように読めるものになったと感じています。

GPT-5.1 が主張していること

OpenAI と報道によると、 GPT-5.1はより安定し、指示に従い、適応性の高いモデルとして説明されています。GPT-5.1 は ChatGPT の「Instant」と「Thinking」モードの両方で駆動しています。コードレビューに関してこの説明を検証したところ、驚くほど正確だと感じられました。細かな指摘では素早く表面的に対応し、深い推論が必要なバグではしっかりと理由付けを行います。

今回は新しい試みも行いました。GPT-5.1 が誤った場合、そのやり取り全体と内部推論のトレースを用いて、振り返りを促すプロンプトを実行しました。どこを誤ったのかを示し、改善のためにどのように指示を変えるべきかを尋ねることで、モデル自身がプロンプトに対する具体的な修正案を提示します。この反復的な振り返り手法（差分外への過剰な広がりといった問題も浮上しましたが）によって、モデルの挙動とシステム指示の両方を調整し、安定してタイトな出力を得られるようにしました。

測定した内容（そしてその理由）

私たちは、GPT-5、Codex、Sonnet 4.5 の記事で使用したものと同じベンチマーク環境を使用しました。これは既知の エラーパターン（EP） を埋め込んだ 25 件の難しい PR から構成されています。スコアリングでは以下に重点を置いています。

• アクショナブルなコメントのみ: 実際に投稿されるコメントのみ（追加提案や 差分外への記述を除く）

• エラーパターンごとの合格数（コメントごと。以下EP Pass）: コメントが エラーパターン を直接修正、または明示していること

• Important コメント: EP PASS または重大/クリティカルな実バグ

• Precision（精度）: EP PASS ÷ コメント総数

• SNR: Important ÷ (総数 − Important)

比較対象は以下の通りです。

• GPT-5.1（新モデル）

• CodeRabbit Production（現行レビューアースタック）

• Sonnet 4.5

新しいモデルの追加はスイッチを入れるだけではありません

CodeRabbit ではモデルの導入は毎回適切に行われており、モデルを差し替えて祈るようなことはしません。各社のモデルはすでに互換品ではなくなっているため、デプロイ前にテスト、調整、品質ゲートを行います。GPT-5.1 に対しては以下のような調整を行いました。

• GitHub に投稿できない 差分外のコメント の削減

• 冗長さを抑えるための トーンと簡潔さ の調整

• 重大度タグ と 指示解釈 の再整合

これは GPT-5 Codex の場合と同じで、推論能力をプロダクト価値へと変換するために、モデルの挙動を再構築するという目的があります。最終的な結果として、高いS/N比、ストレスの軽減、バグのカバレッジを損なわないレビューを実現しました。

スコアボード（アクショナブルなコメントのみ）

要点: GPT-5.1 は過去最高のエラーパターン再現率に並びつつ、最も少ないコメント量 を記録しました。CodeRabbit Production と Sonnet 4.5 の両方を コメント単位の精度 と Important コメント比率 で上回り、最もクリーンで高インパクトなレビュー を実現しました。

GPT-5.1 のレビュー体験

データで確認される挙動特性は、後に測定した言語メトリクス（弱め表現 28%、断定的マーカー 15% など）と一致しています。これにより、開発者が「レビュー自信があり、かつバランスの取れたトーン」だと感じる理由がデータでも裏付けられています。

GPT-5 Codex と Sonnet 4.5 と比較すると、GPT-5.1 のコメントはよりスリムで、対話的であり、熟練エンジニアのコミュニケーションに近いと感じられます。Codex は機械的かつ堅く、Sonnet 4.5 は冗長で学術的になりがちでした。それに対して GPT-5.1 は簡潔さと明確さのバランスが良く、押しつけがましくない自信を感じさせます。信頼できるチームメイトが差分を説明しているように読めます。CodeRabbit Production と比較すると、より課題に対して鋭くフォーカスされており、Sonnet 4.5 と比較するとより人間的で抑制が効いています。以下はその具体例です。

簡潔

GPT-5.1 はより少なく鋭いコメントを書き、すぐに要点へ到達します。ある PR では、ロストウェイクアップバグを以下の 1 行で修正しました。
p_caller_pool_thread->cond_var.wait(lock);
余計な文脈説明も不要な文章もありませんでした。比較すると CodeRabbit Production は同じ結論に至るまでに、スレッドフローを数段落説明していました。

率直

所有権やメモリ管理が関わる場面ではためらいません。冗長な r->reference() 呼び出しについて、以下のように指摘しました。
「Ref<Resource> は refcount を自動管理します。手動で refcount を増やすとリークにつながるため削除してください」
開発者はこの率直さを好みます。講義ではなくパッチレビューのように読めます。

実務的

GPT-5.1 は、問題の重要度がどこにあるかを理解し、重要なものとそうでないものを適切に識別します。あるキャッシュ設定の PR では未実装の optimizeMemoryUsage() を指摘しましたが、次のように正しく文脈化しました。
「キャッシュの肥大化がメモリプレッシャーに影響しない限り、これは軽微です」
過剰反応せず、重要度を適切に扱っています。この点は Sonnet 4.5 にまだ課題があります。

文脈を追う

プロンプトが曖昧だった場合、GPT-5.1 は自身の仮定を明示的に説明します。初期の実行では次のように述べました。
「プロンプトでヘルパー関数のスコープが指定されていませんが、明確化のために含めました」
この透明性が私たちの指示改善を助け、モデルの推論を信頼できるものにしました。

簡潔、率直、実務的、文脈理解という特性は GPT-5 Codex において私たちが高く評価した点と一致していますが、GPT-5.1 はより安定したトーンと抑制を備えています。

スタイルとトーン（GPT-5.1 がチームメンバーのように感じられる理由）

GPT-5 Codex や Sonnet 4.5 の評価で使用したものと同じ言語構造のシグナルを参照し、GPT-5.1 がレビューで異なる印象を与える理由を分析しました。これにはコメントの長さ、コードブロックの有無、弱め表現と断定表現の割合などが含まれます。データは明確な傾向を示しています。

読み方について
GPT-5.1 のコメントは平均文字数がやや多いものの、より明確な構造と負荷の高い文で構成されているため、実際には「短く読みやすい」と感じられます。GPT-5.1 のトーンは CodeRabbit Production や Sonnet 4.5 よりも断定的で、全体として diff ブロックは少ない（76%）という特徴があります。これは意図されたもので、複数箇所修正や API バリデーション、設計の明確化であり、単一のパッチを示すと誤解を招く場合があったためです。ただし、差分を含まないコメントの約 3 分の 2 では、最小限のパッチを示せば明確さがさらに向上すると感じられました。

CodeRabbit Production と比較すると、GPT-5.1 はパッチ頻度を一部犠牲にする代わりに、明確さと集中度を高めています。Sonnet 4.5 と比較すると、レビューを膨張させる冗長な説明を避けています。トーンは Codex の外科的精度と Sonnet の慎重な冗長性の中間に位置し、自信がありつつも強圧的ではなく、慎重でありながら臆病ではありません。

総じて、GPT-5.1 のレビューは 素早く読み進められ、より直接的で、実際の修正を見つけるためのスキャン量が少なくて済む という特徴があります。これは意図して調整した挙動であり、データと体験の両方に表れています。

GPT-5.1 にまだ残る課題

完璧なモデルは存在せず、GPT-5.1 にもトレードオフがあります。CodeRabbit Production と比較すると、大規模チームで有用な文脈的な衛生改善の指摘を省くことがあり、より機能的な問題に集中する傾向があります。Sonnet 4.5 と比較すると、デザインやスタイル上の改善点を見逃すことがあり、人間のレビューアが好むケースもあります。これらは精度と簡潔さを優先した意図的なトレードオフであり、今後のロールアウトで開発者の反応を注視していく予定です。

改善が必要だった点

GPT-5.1 は調整を必要としましたが、その課題は以前のシステムと比べるとはるかに軽度でした。CodeRabbit Production は衛生的な指摘と重大な指摘を同一スレッドで混在させる傾向があり、Sonnet 4.5 は説明過多で、同じバグについて複数の軽微なノートを投稿しがちです。一方で GPT-5.1 の調整点は主に精度に関わるもので、トーンや冗長性よりも限定的でした。これは GPT-5.1 がプロダクション導入に対して、非常に近い段階にあることを示しています。

• diff 外コメント
  GPT-5.1 は diff 以外の部分に提案を含めることがありました。プロンプトで明確に制約を示したところ、モデルは自己修正しました。

• 曖昧さに対する過剰な助け
  プロンプトが厳密でない場合、コンテキスト追加やヘルパー関数の追加を行うことがありました。制約を明確にすると、境界を正確に守るようになりました。

開発者が期待できること

1. よりクリーンなレビュー
   コメント数が減り、重要コメントの割合が高まります。

2. パッチのようなトーン
   ほぼすべてのコメントが最小限の修正案と説明を含みます。

3. トップクラスの EP リコール
   Sonnet 4.5 と同等で、CodeRabbit Production を上回ります。

4. 少ないスキャンで高いシグナル
   コメントの 58.7% が Important に分類されます。

5. ターゲット外でも実世界のバグを捕捉
   ライフサイクルの問題、リーク、整合性ギャップなどを検出します。

まとめ

私たちはモデルをただ選ぶのではなく、正しく機能する形へ調整します。GPT-5.1 は現在、GitHub 差分の振る舞い、トーン、冗長度、スコアリング閾値の調整を完了し、ロールアウト前のフェーズに入っています。今後数週間にわたり、開発者が高いS/N比、新しいトーン、簡潔なレビューをどのように受け止めるかを監視します。フィードバックが良好であれば、提供範囲を拡大し、開発者が求めてきた「よりクリーンでより速いレビュー」を提供していきます。

現時点で GPT-5.1 は、私たちに新しい価値、つまり次世代レベルの精度を重視したレビュー示してくれる準備が整っています。これは CodeRabbit の理想である、「重要なバグを素早く見つけ、開発者にノイズを強いることなく届ける」という目標にさらに近づくものです。

コードレビューを試してみたい方はこちらです
14 日間の無料トライアルをお試しください

TL;DR
After prompt tuning and integrating it into our stack, GPT-5.1 now delivers the best precision and signal-to-noise ratio (SNR) we’ve seen in reviews, with fewer comments. It tied for the best-in-class error pattern (EP) recall on our hard benchmark set while posting less than half the volume of comments that competitors did.

The result: less noise, better fixes, and reviews that read like patches again.

What GPT-5.1 claims to be

OpenAI and the press describe GPT-5.1 as more stable, instruction-following, and adaptive. It powers both "Instant" and "Thinking" modes in ChatGPT. We found that framing surprisingly accurate when it comes to code reviews: the model stays quick and surface-level for nits, but reasons deeply when the bug requires it.

We also tried something new. When GPT-5.1 got something wrong, we used the full exchange and its internal reasoning trace to prompt it to reflect. By showing it where it missed the mark and asking how it would change its instructions to do better, the model was able to actually propose concrete edits to its prompt. We used this iterative reflection technique (which surfaced issues like outside-diff sprawl) to refine both its behavior and our system instructions until it got consistently tighter.

What We Measured (and Why)

We used the same benchmark harness as in our GPT-5, Codex, and Sonnet 4.5 articles: a suite of 25 hard PRs, each seeded with a known error pattern (EP). Our scoring focuses on:

• Actionable comments only: Comments that get posted (not additional suggestions or outside-diff notes).

• EP PASS (per comment): The comment directly fixes or surfaces the EP.

• Important comments: Either EP PASS or another major/critical real bug.

• Precision: EP PASS ÷ total comments.

• SNR: Important ÷ (total − Important).

We compared:

• GPT-5.1 (new model)

• CodeRabbit Production (our current reviewer stack)

• Sonnet 4.5

Why adding a new model isn’t a switch-flip

Every model rollout at CodeRabbit is a campaign. We don’t plug in the model and hope; we test, adapt, and gate before shipping because models are no longer interchangeable. With GPT-5.1, this meant:

• Reducing outside-diff comments, which can’t be posted to GitHub.

• Tightening tone and concision to reduce verbosity.

• Re-aligning on severity tagging and instruction interpretation.

This mirrors what we did with GPT-5 Codex: turn reasoning power into product value by reshaping the model’s behavior. The net result: higher SNR, less fatigue, and no compromise on bug coverage.

Scoreboard (Actionable Comments Only)

Takeaway: GPT-5.1 matched the highest EP recall while posting the fewest comments. It beat both CodeRabbit prod and Sonnet 4.5 on per-comment precision and important share, delivering the cleanest high-impact reviews.

What GPT-5.1 feels like in review

The behavioral traits we see in the data align directly with the language metrics we later measure such as 28% hedging and 15% assertive markers. This shows that the tone developers perceive as confident and balanced is borne out in the data.

Compared with GPT‑5 Codex and Sonnet 4.5, GPT‑5.1’s comments feel leaner, more conversational, and closer to how experienced engineers actually communicate. Codex could sound mechanical and rigid, while Sonnet 4.5 leaned verbose and academic. In contrast, GPT‑5.1 balances brevity with clarity. Its feedback feels confident but not heavy‑handed, like a trusted teammate explaining a diff. Against CodeRabbit Prod, it feels sharper and more focused. Against Sonnet 4.5, it feels human and restrained. Here’s how that translates in practice:

Concise

GPT-5.1 writes fewer, sharper comments that get straight to the point. In one PR, it fixed a lost wakeup bug with a single line: p_caller_pool_thread->cond_var.wait(lock); no extra context, no unnecessary prose. CodeRabbit prod, by comparison, wrote several paragraphs describing the thread flow before reaching the same conclusion.

Direct

When ownership or memory management was at stake, GPT-5.1 didn’t hesitate. It flagged the redundant r->reference() call with: “Ref<Resource> already manages refcounts; remove the manual increment to prevent leaks.” Developers appreciate this directness. It reads like a patch review from a teammate, not a lecture.

Pragmatic

GPT-5.1 understands when an issue matters and when it doesn’t. On a cache configuration PR, it identified an unimplemented optimizeMemoryUsage() but correctly noted, “This is minor unless cache growth impacts memory pressure.” Instead of overreacting, it contextualized severity, something Sonnet 4.5 still struggles with.

Follows Context

When prompts were vague, GPT-5.1 explicitly explained its assumptions. In an early run, it said: “The prompt didn’t specify helper function scope, so I included one for clarity.” That kind of transparency helped us refine our instructions and made its reasoning trustworthy.

Concise, direct, pragmatic, and context-aware are qualities that mirror what we valued most in GPT-5 Codex, but with a steadier tone and more restraint.

Style and tone (why GPT-5.1 feels like a peer)

To understand why GPT-5.1 feels different in review, we looked at the same language and structure signals used in our GPT-5 Codex and Sonnet 4.5 evaluations. These include measures like comment length, presence of code or diff blocks, and tone markers for hedging versus confidence. The data paints a clear picture.

How to read this. While GPT‑5.1’s comments use slightly more characters on average, they deliver that text in clearer structure with fewer sentences that carry more weight. In practice, developers perceive them as shorter and easier to read. GPT‑5.1’s tone is more assertive than both CodeRabbit prod and Sonnet 4.5, and it includes fewer diff blocks overall (76%), which is intentional. Many of these comments were multi‑location fixes, API validations, or design clarifications where a single fenced patch would be misleading. In roughly two‑thirds of those no‑diff cases, a minimal fenced patch would have made sense and could further improve clarity.

Compared to CodeRabbit prod, GPT-5.1 trades some patch frequency for higher clarity and focus. Against Sonnet 4.5, it avoids the verbosity and over-explanation that make reviews feel bloated. Its tone sits comfortably between Codex’s surgical precision and Sonnet’s cautious verbosity. It’sconfident without being heavy-handed, measured without being timid.

At a glance, developers will notice that GPT-5.1’s reviews read faster, feel more direct, and require less scanning to identify the real fix. That’s the behavior we tuned for and it shows in both the numbers and the experience.

Where GPT-5.1 still lags

No model is perfect, and GPT-5.1 has its trade‑offs. Compared to CodeRabbit Prod, it sometimes leaves out contextual hygiene notes that can be useful for larger teams, focusing narrowly on functional issues. Against Sonnet 4.5, it can feel less expansive,missing opportunities to surface design or style considerations that human reviewers sometimes appreciate. These are conscious trade‑offs for precision and brevity and we’ll be watching the rollout to see how developers perceive the balance.

What we had to fix

While GPT‑5.1 required tuning, its challenges were far milder than those of earlier systems. CodeRabbit prod still tends to mix hygiene and critical issues in the same thread, while Sonnet 4.5 often over‑explains and spams multiple minor notes on the same bug. In contrast, GPT‑5.1’s main adjustments were focused on precision rather than tone or redundancy, showing how close it was to production readiness.

• Outside-diff comments. GPT-5.1 sometimes included suggestions beyond the diff context. We updated the prompt to clarify this, and the model self-corrected.

• Over-helpful under ambiguity. When the prompt wasn’t strict, the model added context or helper functions. Once clarified, it obeyed boundaries tightly.

What developers should expect

1. Cleaner reviews. Fewer comments and a higher share of comments that matter.

2. Patch-like tone. Almost every comment includes a minimal fix with explanation.

3. Top-tier EP recall. Ties Sonnet 4.5, beats CodeRabbit prod.

4. Less scanning, more signal. 58.7% of comments are Important.

5. Real-world bugs caught even outside the target. These include lifecycle issues, leaks, consistency gaps.

Closing thoughts:

We don’t just pick models; we make them work. GPT-5.1 is entering the next phase of our rollout process now that tuning for GitHub diff behavior, voice, verbosity, and scoring thresholds is complete. Over the coming weeks, we’ll monitor how real users respond to its higher SNR, new tone, and concise review style. If developers respond well, we’ll expand its availability, giving them the cleaner, faster reviews they’ve been asking for.

For now, GPT‑5.1 stands ready to show what this next generation of precision‑focused review can do. It brings us closer to CodeRabbit’s north star: catching the bugs that matter quickly, without making developers sift through noise.

Interested in trying our code reviews? Get a 14-day free trial!

The simplicity trap

Sure, a thumbs up is quick, but is it really teaching your AI reviewer anything useful? Emoji-based feedback feels good, is fast, and universal. On the surface, it even seems to make sense.

But code review isn’t a light switch. It’s a mess of judgment calls, technical nuance, and team-specific standards. Many of those don’t show up in a quick emoji click. Every code comment carries hidden intent: correctness, clarity, design trade-offs, historical precedent, team risk tolerance, and even internal political dynamics.

Reducing that to a binary signal? That’s not learning, that’s training a model to chase vibes.

When simplicity backfires: The sycophant scare

Earlier this year, OpenAI pushed an update to GPT‑4o that leaned too hard on thumbs-up and thumbs-down feedback. The result? A model that became overly agreeable. It flattered users. It agreed with wrong answers. It started to say “yes” a little too much, and the quality of answers dropped. OpenAI had to walk it back: the feedback signal had been hijacked.

Turns out, if you tell a model that approval is the goal, it will optimize for approval. Not truth. Not utility. Just “did the human feel good in the moment?”

This wasn’t a bug. It was a reward design failure. And if you apply the same approach to code review, you will get a reviewer that plays it safe, flatters your choices, and avoids telling you what you actually need to hear.

Why binary feedback collapses nuance

A thumbs-up means... what, exactly?

• That the model caught a bug?

• That it wrote clearly?

• That it sounded friendly?

• That the reviewer was just in a good mood?

A single scalar signal tells the system something went well, but not what went well. That means the model will nudge on whatever it can control: tone, politeness, flattery, or brevity. That’s what sycophancy looks like in reinforcement learning. Not evil intent, just a system learning to maximize the reward you gave it, not the outcome you actually wanted.

This is Goodhart’s Law in action. When the metric, in this case thumbs up, becomes the goal, it stops being a useful measure of anything real.

How models game your feedback

When you give a model an easy signal, it finds an easy shortcut.

In the coding world, reinforcement learning agents have learned to pass test cases by hard-coding expected outputs instead of solving the underlying logic. They’ve manipulated logs and short-circuited evaluation harnesses. The green check shows up, but the code doesn’t actually work.

In code review, the same thing happens, just socially. The model starts saying “Nice work!” at the top of every comment. It hedges every suggestion. It nitpicks formatting because those comments are safe and get accepted without argument. And real architectural concerns? They get buried.

The model has learned how to get positive reactions but it’s no longer reviewing code.

What implicit signals get right

Outside of LLMs, this pattern is well known. Netflix found that what users watch is more useful than what they rate. People lie with stars. But watch time, clickthrough, and rewatching are honest signals.

In AI, we call this implicit feedback and in code review, it shows up as:

• Did the developer apply the suggestion?

• Did they rewrite it?

• Did they ignore it?

• Did the same pattern show up again in a future bug?

These signals don’t need user input. They come from behavior and they’re harder to game.

That doesn’t mean they’re perfect. You can’t always know why someone took an action. But they are less easily manipulated than a raw emoji. They also tell you whether the review worked, not just whether it felt good.

Code generation vs code review: different games, different signals

Code generation is closer to math since there’s often a right answer. Does it compile? Does it return the correct result? Does it pass tests?

That means you can use outcome-based rewards like execution feedback and implicit signals. They’re not perfect. Code models can still cheat by hard-coding outputs, but you can build guardrails. And you don’t need the developer to say whether it was good, you can see whether it worked.

Code review is different. There’s no universal pass/fail but vast differences in preferred style, structure, risk, naming, test coverage from one team to the next. A great comment for one team might be totally wrong for another. What’s considered “clean code” in a fast-moving startup might be flagged as sloppy in a regulated enterprise.

That’s the real problem with global thumbs up/down data. It flattens out the nuance. It teaches the model to aim for the average, not the appropriate. You don’t just get safe comments, you get generic ones.

Our alternative: CodeRabbit Learnings

At CodeRabbit, we take a different approach. Instead of optimizing for likes, we optimize for understanding. That’s why we built Learnings.

Every time an engineer corrects CodeRabbit, clarifies a team convention, or explains why something doesn’t fit their stack, that explanation is stored as a natural language instruction. We don’t just remember that the comment was rejected, we remember why.

Those Learnings are linked to your org, your repositories, and even specific paths or file types. When CodeRabbit reviews future pull requests, it retrieves those instructions and applies them in context. The next time it sees that same pattern, it adjusts.

There’s no need to re-teach it and no risk of repeating the same mistake. The model doesn’t guess based on thumbs, it reasons from your team’s actual guidance.

It also gives you visibility. You can see which Learnings exist, browse them, filter by category, and delete or edit them when your standards change. That means the model evolves alongside your team and stays aligned as your practices shift.

This is reinforcement learning not through raw approval, but through captured intent. It’s interpretable and inspectable. And it builds a living layer of team knowledge that generalizes across reviews.

What nuanced learning enables

When you feed the system clear, contextual instructions and not just signals, it unlocks far more than a better review experience.

• It enables team-level adaptation. The model stops guessing what good looks like and learns how your team actually writes code. It understands your risk posture, your stylistic preferences, your trade-offs. It becomes a reviewer that knows the house rules.

• It supports longitudinal learning. Over time, CodeRabbit builds a memory of which comments are helpful, which are ignored, and which suggestions actually lead to changes. That means it gets more precise, more focused, and less noisy over time.

• It builds trust. When developers know they can correct the AI and it will remember, they engage more. They shape the system and the system becomes a reflection of their standards, not a generic LLM.

This is how a review tool becomes an extension of your team and not just another opinion in the room.

Closing thoughts: Real learning comes from patterns, not pixels

Thumbs are fine for quick reactions but quick reactions don’t build expertise.

If you want an AI reviewer that improves over time, adapts to your standards, and avoids the traps of shallow feedback, you need to give it more than approval. You need to give it explanations.

The next generation of AI code tools won’t be trained on likes. They’ll be trained on context, consequence, and course correction. They’ll learn not from emojis, but from structured memory. From real decisions and your team’s own voice.

That’s what CodeRabbit Learnings is built for. Not for applause but for understanding.

Try out Learnings for yourself with our free trial.

The rise of Slow AI: Why devs should stop speedrunning stupidの意訳です。

私たちがコンピューターを使い始めて以来、そこには常に1つの基本ルールが存在しました。それは、速ければ速いほど良いということです。低レイテンシ、高スループット、待ち時間の短縮、これが鉄則でした。ボタンの応答に600ミリ秒もかかったり、注意力が維持できなくなるほど長いスピナーを見たりすることを望む人はいません。遅いということは、それは壊れているということです。議論の余地はないでしょう。

そのため当然ながら、AIツールが私たちの開発ワークフローに忍び込み始めたとき、自動補完やエージェント、Copilot、その他何でも、同じ原則が適用されました。それはつまり、「速くしろ」「インスタントに感じさせろ」「魔法のように見せろ」です。

しかし、実際のところ、AIは魔法ではありません。それは推論です。パイプライン、RAG、コンテキスト、そしてツールの呼び出しです。乱雑なコンテキストと確率的推測をジャグリングしているのです。そして、単なる自動補完以上のものを求めるなら、ベースとなるプロセスのパイプラインを構築する必要があります。そして、それは処理時間がかかります。それ以外では、基本的に愚かさのスピードランをしているだけなのです。そして、ツールがどれだけ速くとも、間違っているなら速度はまったく意味がありません。

CodeRabbitでは、私たちが「スローAI」と呼ぶものを優先しています。そして、多くのAI企業が恐れて言えないことを言う勇気があります。私たちは「あなたを待たせます」。

(そして、あなたはそれに感謝するでしょう)

AI開発ツールはしばしば速く、自信に満ち、そして間違っている

最近AIコーディングエージェントを使ったことがあるなら、こんな経験をしたことがあるのではないでしょうか。タイピングを止めるとほぼ同時に、驚くほど速い提案がポップアップしてきます。それは一見すると、正当なものに見えます。しかしその後…失敗します。場合によっては、派手に失敗します。さらに悪いことに、テストには合格するものの、別なファイルで何かを壊していたりします。

これはなぜでしょうか? なぜなら、今日のほとんどのAI開発ツールは、1つのことに最適化されているからです。それは速度です。数トークンをタイプすると、モデルは統計的に最も可能性の高い続きを予測します。それは必ずしも正しいものではなく、安全なものでもなく、アプリが実際に何をしているかを理解しているものでもありません。ただ、次のもっともらしいコードの塊でしかありません。

それは、ボイラープレートには十分でしょう。しかし、ロジックには? エッジケースには? 実際のエンジニアリングには? それは、会議で速く自信を持って話すものの、仕様を読まない人を雇うようなものです。

こうしたツールのほとんどは、コンテキストを 読んで いません。少なくとも深くは読んでいません。近くの数行、おそらく関数名を取得するかもしれませんが、生成しているものを全体像に対して検証することは滅多にありません。課題のクロスチェックはしませんし、アーキテクチャレベルの認識もなく、ファイルやユースケースをまたいだ推論もありません。

思慮深く、テスト可能で、コンテキストを認識した出力が必要な場合、速度を落とし、俯瞰し、実際に問題に取り組むAIシステムが必要です。

それがスローAIの役割です。そして、AIが何をしているかを理解する時間を取ると、ハルシネーションを止めて実際にサポートしてくれるようになることがわかります。

AIが遅いときに優れている理由

核心として、大規模言語モデルは統計的推論マシンだということです。確率、パターン、そして(願わくば)あなたが与えたコンテキストに基づいて、次に何が来るかを予測して出力を生成します。しかし、ほとんどの開発者が忘れている注意点があります。良い予測には、それなりの作業が必要だということです。これは特に、ロジックを書く、アーキテクチャを理解する、複数のステップにわたって推論するなど、複雑なことをモデルに求める場合に当てはまります。出力の品質は、多くの場合において、推論の深さや段階に直接結びついています。

これは、単純なプロンプトを超えて、マルチステージパイプラインとエージェント的な動作に移行する際において、特に当てはまります。AIツールが出力を検証し、関連ファイルを取り込み、矛盾をチェックし、または複数のアクション先を計画している場合、それは単に次のトークンを出力しているだけではないのです。それは思考しています。または、少なくとも、それに近いことを実行しています。

このような非線形推論は、単一のフォワードパスでは実行できません。それには反省と検索、計画、そして時には自己修正さえも含まれます。こうしたプロセスはレイテンシ・フレンドリーではなく、インテリジェンス・フレンドリーなのです。

要するに、AIに複雑なコードで実際に助けてもらいたいなら、それを調理させる必要があるのです。

遅いことが新しいスマート:なぜ私たちはAIに考えさせるのか

スローAIは、私たちが話している用語の1つです。言い換えるなら包括的AIや正確なAI、あるいは正直に言えば「 実質的 役立ち有用なAI」と呼ぶこともできます。そして、それは今のAIプロダクトデザインで最もバズワードなアイデアの1つに密接に結びついています。そう、コンテキストエンジニアリングです。

AIが問題について知っている、 関連性があって解析された 情報が多いほど、パフォーマンスは向上します。しかし、そのコンテキストは取り込まれ、解析され、優先順位が付けられ、推論される必要があります。そのようなパイプラインは、超低レイテンシAIの敵です… そしてそれは精度の敵でもあります。

そして、それが私たちのAIコードレビューにおいて、最初のコメントを見るまでに最大5分かかる理由です。誤解しないでください。私たちは遅さを最適化しているわけではありません。コードベースとPRの複雑さに応じて、3分、あるいは1分でレビューを受け取ることもできます。私たちのパイプラインが複雑なのは、ユーザーが必要とする結果を出すために必要だからです。いつでも同時に実行されているプロセスの数を知りたくもないでしょう!

しかし、どうでしょう? 複数のレビューおよび検証エージェントを使用した、非線形のマルチパスパイプラインでAIに時間をかけさせると、他のツールよりもノイズが少なく、より関連性の高いコードレビューコメントが生成されるのです。

非線形推論は決して、速くありません。しかし、それは優れているのです。

では、なぜほとんどのAIツールは遅さよりも愚かさを選ぶのか?

まず、スローAIはすべてのツールにとってオプションではありません。たとえば、AIコーディングエージェントに質問をしている場合、返信を5分間待てる人はいないでしょう。そのやり取りには、即時性への期待が本質的に備わっています。

ではコードレビューはどうでしょうか? 提出されたPRに対して、同僚がすぐに手を止めてコメントし始めることを期待する人はいません。したがって、ボットからのレビューの遅延も受け入れる余地があります。そして、そのレビューがより関連性が高いことで時間を節約するなら、その遅延を受け入れる価値は特に高くなります。

しかし、なぜ多くの企業が、常に（実際にはそれを必要としないときでも）低レイテンシを優先するのでしょうか? まあ、私たちは訓練されてきましたし、即座の満足を期待するようユーザーを訓練してきました。ボタンをクリックすれば、速攻のレスポンスを得られます。関数名をタイプすれば、それについて考える前に提案を得られます。即効性がなければ壊れている、遅い、またはスタートアップがAWS料金の支払いを忘れたように感じられます。

これは非常に強く叩き込まれているため、企業は遅延よりも間違っている方を積極的に選択しています。そして、人々がそうするとき、私たちの開発文化には有害で、後ろ向きな何かがあります。

なぜなら、真実はこうだからです。最高のAIツールは必ずしも速く感じられず、代わりに思慮深く感じられます。時々、彼らは一時停止します。時々、プロンプトを推論したり、関連するコードを検索したり、応答を検証したりするために余分な時間を必要とします。しかし、それは待つ価値があるのです。たとえば、OpenAIのDeep Research機能が質問により良く答えるためにインターネットを最大20分かけて調査するからといって、利用を止める人はいません。処理中に他のことをして、戻ってくるだけです。

もはや遅い = 壊れているという意味ではありません。それはスマートという意味です。むしろ、AIに関しては、速度こそがバグです。開発プロセスに実際に価値を追加するAIツールが必要な場合、それには応答性から信頼性へ、即時性からインサイトへの移行が必要です。そして、特に開発者にとって、そのトレードオフは理にかなっています。

私たちは、今後5年間で最も価値のあるアプリは、速度を最適化するものではなく、インテリジェンスを最適化するものになると信じています。速いけど不要な結果と、遅いけれど価値あるもの、どちらが欲しいですか?

CodeRabbitのマントラ:ゆっくり動いて物事を修正する

CodeRabbitでは、他のツールのように、速度を優先するAIパイプライン最適化に過剰投資はしません。私たちは、信頼のために最適化を行います。それはコードを理解し、コンテキスト全体で推論し、より良いソフトウェアを構築するのに実際に役立つ出力を生成する時間を取るシステムを受け入れることを意味します。確かに、クイックプロンプトをたたき出すよりも遅いです。しかし、その余分な時間は明瞭さやカバレッジ、そして自信へと変わります。

「Move fast and break things（素早く行動し破壊せよ）」は、MVPをデリバリーするには素晴らしいものでした。しかし、品質をデリバリーすることに関しては、私たちは別のものを信じています。ゆっくり動いて物事を修正する、AIに場の空気を読ませる、話す前に考えさせる…そして、本当に自信のある自動補完ではなく、シニアエンジニアから得られるようなサポートを提供する。それが、間違ったAIをスローAIよりも優先する、現在の後ろ向きな文化から抜け出す唯一の方法です。

私たちのレビューを試してみたいですか? こちらから 14日間の無料トライアルを入手してください!

For as long as we’ve been building with machines, we’ve followed one core rule: faster is better. Lower latency, higher throughput, less waiting; that was gospel. Nobody wanted to wait 600ms for a button to respond or watch a spinner that lasts longer than their attention span. If it was slow, it was broken. Case closed.

So naturally, when AI tools started creeping into our dev workflows, autocomplete, agents, copilots, you name it, the same principle applied. Make it fast. Make it feel instant. Make it look like magic.

But here’s the thing: AI isn’t magic. It’s inference. It’s pipelines and RAG and context and tool calls. It’s juggling messy context and probabilistic guesses. And if you want something smarter than glorified autocomplete, you need to build a pipeline of processes to provide scaffolding for that. Which takes time to process. Anything less and you’re basically just speedrunning stupid. And speed isn’t anything to brag about when your tool is just wrong faster.

At CodeRabbit, we prioritize what we call Slow AI. And we have the guts to say what a lot of AI companies are too afraid to: We’re going to make you wait.

(And you’ll thank us for it).

AI dev tools are often fast, confident, and wrong

If you've used an AI coding agent lately, you've probably seen it: a shockingly fast suggestion pops up almost as soon as you stop typing. It looks legit. But then… it fails silently. Or spectacularly. Or worse, it passes the test and breaks something two files over.

Why? Because most AI dev tools today are optimized for one thing: speed. Type a few tokens and the model predicts the most statistically likely continuation not necessarily the correct one, not the secure one, not the one that actually understands what your app is doing. Just the next plausible blob of code.

That’s fine for boilerplate. But for logic? For edge cases? For actual engineering? It’s kind of like hiring someone who talks fast and confidently in meetings but never reads the specs.

Most of these tools don’t read context, at least not deeply. They might grab a few nearby lines, maybe the function name, but they rarely verify what they’re generating against the bigger picture. No issue cross-checking. No architecture-level awareness. No reasoning across files or use cases.

If you want outputs that are thoughtful, testable, and context-aware, you need AI systems that slow down, zoom out, and actually engage with the problem.

That’s what Slow AI does. And it turns out, when your AI takes the time to understand what it’s doing, it stops hallucinating and starts actually helping.

Why AI is better when it’s slow

At their core, large language models are statistical reasoning machines. They generate output by predicting what comes next based on probability, patterns, and (hopefully) the context you’ve given them. But here's the caveat most devs forget: good predictions take work. This is especially true when you're asking the model to do something complex like write logic, understand architecture, or reason across multiple steps. The quality of the output is often tied directly to the depth or stages of its inference.

This is particularly true when you move beyond simple prompts and into multi-stage pipelines and agentic behavior. When an AI tool is verifying outputs, pulling in relevant files, checking for contradictions, or planning several actions ahead, it’s not just spitting out the next token… it’s thinking. Or, at least, performing a rough approximation of it.

That kind of non-linear reasoning can’t be done in a single forward pass. It involves reflection, retrieval, planning, and sometimes even self-correction. These processes aren’t latency-friendly, they’re intelligence-friendly.

In short: if you want AI to actually help on complex code, you have to let it cook.

Slow is the new smart: Why we let our AI think

Slow AI is one term for what we’re talking about. But it could just as easily be called Comprehensive AI or Accurate AI or even Actually Helpful and Useful AI if we’re being honest. And it’s inextricably tied to one of the buzziest ideas in AI product design right now: context engineering.

The more relevant and parsed info an AI knows about the problem, the better it performs but that context has to be pulled in, parsed, prioritized and reasoned over. That kind of pipeline is the enemy of ultra-low latency AI… and it’s also the enemy of accuracy.

And that’s why our AI code reviews can take up to five minutes before you see the first comment. Don’t get us wrong, we’re not optimizing for slowness. You could get a review in three minutes or even one minute depending on the complexity of your codebase and PR. Our pipeline is complex because that’s what’s required to do the job our users need it to do. You don’t even want to know the number of concurrent processes we have going on at any time!

But guess what? When we let our AI take its time using a non-linear, multi-pass pipeline with multiple review and verification agents, it generates less noise and more relevant code review comments than other tools.

Non-linear reasoning isn’t fast. But it’s good.

So, why do most AI tools choose stupid over slow?

Well, first, Slow AI isn’t an option for every tool. If you’re asking an AI coding agent a question, for example, you’re not going to wait five minutes for it to reply. There’s an expectation of immediacy inherent in that exchange.

But code reviews? No one expects their co-worker to immediately drop what they’re doing and start commenting on a PR when it’s submitted. So, they’re willing to accept a delay in a review from a bot as well. And they’re especially willing to accept that delay if that review saves them time by being more relevant.

But why do so many companies still prioritize low latency when their use cases don’t really require it? Well, we’ve been trained, and trained our users, to expect instant gratification. Click a button, get a dopamine hit. Type a function name, get a suggestion before you even think about it. Anything else feels broken, laggy, or like your startup forgot to pay its AWS bill.

This has been drilled into us so hard that companies are out there actively choosing being wrong over being slow. And there’s something toxic and backwards about our development culture when folks do that.

Because here’s the truth: the best AI tools don’t always feel fast. They feel thoughtful. Sometimes they pause. Sometimes they take an extra beat to reason through your prompt, retrieve relevant code, or validate their response. And that’s something worth waiting for. After all, no one is less likely to use OpenAI’s Deep Research feature because it takes up to 20 minutes to comb the internet for info to better answer your question. You just do something else while it’s processing and circle back.

Slow doesn’t mean busted anymore, it means smart. If anything, speed is the bug when it comes to AI. If we want AI tools that actually add value to the development process, that requires a shift from responsiveness to reliability, from immediacy to insight. And for developers especially, that tradeoff makes sense.

We believe that the most valuable apps in the next five years won’t be the ones that optimize for speed but the ones that optimize for intelligence. Who wants fast garbage over slow value?

CodeRabbit’s mantra: Move slow and fix things

At CodeRabbit, we don’t optimize our AI pipelines for speed at all costs like everyone else. We optimize for trust. That means embracing systems that take the time to understand your code, reason across context, and generate outputs that actually help you build better software. Yes, it’s slower than hammering out a quick prompt. But that extra time buys you clarity, coverage, and confidence.

“Move fast and break things” was great for shipping MVPs. But when it comes to shipping quality, we believe in something else: Move slow and fix things. Let the AI read the room. Let it think before it speaks. And let it give you the kind of help you’d expect from a senior engineer, not just a really confident autocomplete. That’s the only way to break out of this backwards culture that prioritizes wrong AI over slow AI.

Want to try our reviews out? Get a 14-day free trial here!

Why LLM models are no longer interchangeableの意訳です。

開発者やプロダクトビルダーにとって、この数年間はLLMがアプリケーション開発を導いてきました。プロダクトを改善したいなら、最新のLLMを利用すれば良い。ただモデルを切り替えるだけで、ツールの性能を一段階引き上げられるのです。

しかし、その時代は終わりました。AnthropicのClaude Sonnet 4.5やOpenAIのGPT-5-Codexのような新しいモデルは、根本的に異なる方向へ分岐し始めています。どのモデルを使うかという選択は、もはや単なるエンジニアリング上の判断ではなく、極めて重要なプロダクト上の意思決定なのです。モデルを切り替えた瞬間に、あなたのプロダクトの「質感」そのものが変わります。

いわゆる「万能モデル時代」は終焉を迎えました。あなたが選ぶモデルは、あなたのプロダクトが何であるか、何をするのか、どのように動作するのか を象徴する存在になります。たとえあなたがそう意図していなくても、です。

本記事では、この新しい時代における3つの驚くべき発見を紹介します。それは「LLM選択がプロダクトの表明になった理由」「モデルが持つ明確な個性とスタイルの違い」、そして「プロンプトが単一命令から適応的システムへ進化すべき理由」の3つです。

学びポイント 1: LLMの選択はプロダクトの“声明”である

LLMモデルの選択は、もはや「新しいAPIを実装すれば済む」といった単純な技術的決定ではありません。これは、どんなユーザー体験を作りたいのか、どのような失敗を許容するのか、何を最適化したいのか、どの指標で優位に立ちたいのかという、プロダクトの方向性を決める意思決定です。

モデルはそれぞれ固有の「性格」や「推論方法」「直感」を持つようになっており、それがプロダクトの“感触”や“振る舞い”を直接的に形作ります。単に「出力が正しいかどうか」ではなく、「どのように考え、どのように伝えるか」まで変わります。違うモデルを選べば、ツールの能力からユーザーとの対話の仕方まで、すべてが異なるのです。

では、モデルの定量的な性能だけを測る従来型ベンチマークが通用しない今、何を頼りにプロダクトの方向を定めれば良いのでしょうか？チームやユーザーへのアンケート、フォーカスグループもありますが、厳密に実施しなければ客観性に欠ける恐れがあります。

CodeRabbitでは、この選択を客観化するために、独自の重要指標のメトリクスを作成しました。このメトリクスは、単なる性能や精度だけを見ません。可読性、冗長性、信号対雑音比など、多面的に評価します。

このような指標により、焦点は「性能」や「リーダーボードの順位」から、「プロダクトとユーザーにとって本当に重要な要素」へと移ります。例えば、技術的に正しくても影響の少ない提案が多すぎれば、ユーザーを疲弊させ、かつトークンを浪費します。理論上「賢い」モデルでも、ユーザーのワークフローに合わなければ体験を悪化させます。

自社のメトリクスを定義し、新しいモデルが自社とユーザーのニーズを満たすかを測ることを強く推奨します。これらのメトリクスは静的なものではなく、ユーザー行動やフィードバックによって進化させるべきです。目標は、「ユーザーの好みを予測できる基準」を見つけることです。

結論として、最適なモデルとは「リーダーボード上の1位」ではなく、あなたの設計した体験やユーザーのニーズに最も本能的に合うモデルです。

学びポイント 2: フロンティアモデルは「性格」が分岐した

モデルはこれまで以上に「作られるものではなく、育つもの」となっており、その結果、モデル世代ごとに固有の直感と行動特性が生まれています。ポストトレーニングの手法（cookbook）の違いが、モデルクラスごとの方向性を根本的に変えました。1つのモデルで完璧に動くプロンプトも、別のモデルでは通用しません。つまり、同じタスクに対する根本的なアプローチが異なるのです。

これを理解する良い例えとして、モデルを異なる「職業的アーキタイプ」に喩えることができます。
Sonnet 4.5は几帳面な会計士出身の開発者、GPT-5-Codexは倫理意識の高い堅実なエンジニア、GPT-5はバグを徹底的に探す職人気質の開発者、Sonnet 4は活動的な新卒エンジニア。
GPT-5系はClaude系よりもソリューション空間を広く探索し、Claudeはプロンプトの文脈に忠実に留まる傾向があります。どのモデルが適しているかは、プロダクトが目指す目的によって完全に異なります。

CodeRabbitでは、モデル評価と特性分析を体系的に行い、その結果を基にプロンプトとデプロイ方法を最適化しています。たとえば、Sonnet 4.5とGPT-5-Codexを比較すると、Sonnet 4.5は「高リコール型のポイント修正者」、GPT-5-Codexは「ピンポイントなパッチ生成者」として性質づけられます。

こうした定性的な違いは、明確な運用上の違いに転化します。

学びポイント 3: プロンプトはもはや単一構造ではない

モデルの根本的な性質が分岐したことで、あるモデル用に書いたプロンプトを他モデルで「そのまま」使うことはできなくなっています。
たとえばClaude用の厳格な命令プロンプトはGPT-5-Codexでは過剰拘束になり、Codex用に推論重視で最適化したプロンプトは、Claudeで性能を発揮できません。つまり、「一枚岩のプロンプト時代」は完全に終わったのです。

では、新モデルを導入したいエンジニアリングチームはどうすればよいでしょうか？
答えは――より多くのプロンプトエンジニアリングです。ただし嘆く必要はありません。いくつかの実践的な方法があります。

プロンプト・サブユニットの登場

CodeRabbitで見出した解決策の一つが「プロンプト・サブユニット」です。
これは、モデルに依存しない中核プロンプト（基本タスクと一般指示）を定義し、その上にモデル固有のサブユニット（スタイル、フォーマット、例示）を積み上げる構成です。

たとえばCodexとSonnet 4.5では実装詳細が大きく異なりますが、次のような発見がありました：

• Claude: 「DO」「DO NOT」のような強い命令語を使用する。Anthropic系モデルはシステムプロンプトの末尾情報をよく参照し、長文でもフォーマット遵守が得意。明示的な指示を好む。

• GPT-5: 一般的で整合性のある指示を使用する。OpenAI系はシステムプロンプトの下部ほど注意力が減衰するため、長文では出力フォーマットを忘れがち。抽象的なガイダンスを好み、推論の深さを示す傾向がある。

ユーザーフィードバックと評価（eval）

もう一つの解決策は、ユーザーフィードバックと内部評価による継続的アップデートです。
AIコードレビューボットなどLLMアプリの最適化において、最も重要なのは外部ベンチマークではなく、「ユーザーが出力に納得できるか」です。

モデル間で「技術的正確性」が高くても、過剰なコメントや冗長性があると価値を下げてしまいます。
したがって、受容率、S/N比、p95レイテンシ、コストといった実運用メトリクスを測定し、プロンプトを少しずつ調整することで、システムをユーザー期待とプロダクト目標に整合させ続けることができます。

ベンチマークでの定量的結果が良くても、ユーザー受容率が低い――そんな事態は避けるべきです。

まとめ

プロンプトエンジニアリングは、「万能テンプレート」から「モデル特化型パラダイム」へと変わりました。
脆弱な単一プロンプトや「差し替え可能なモデル」の時代は終わりです。これからは、モジュラー型プロンプト設計と意図的なモデル選択が、プロダクトの強靭性を生みます。

モデルが進化し続ける以上、LLMスタックやプロンプトも画一的であってはいけません。
それは「生きたシステム」として扱うべきです。調整し、テストし、確認し、繰り返す。

また、最新モデルの実運用挙動に関する詳細なベンチマークもぜひ確認してください。今後の選択に必要なデータが得られるでしょう。

• GPT-5 Codex: How it solves for GPT-5's drawbacks

• Claude Sonnet 4.5: Better performance but a paradox

• Benchmarking GPT-5: Why it’s a generational leap in reasoning

CodeRabbitを14日間無料でお試しください。
https://coderabbit.link/rk7tdeC

For developers and product builders, one assumption has guided the last few years of LLM application development. To improve your product, just swap in the latest frontier large language model. Flip a single switch and your tool’s capabilities level up.

But that era is over. We’re now seeing that new models like Anthropic’s Claude Sonnet 4.5 and OpenAI’s GPT-5-Codex have diverged in fundamental ways. The choice of which model to use is no longer a simple engineering decision but a critical product decision. Flip that switch today… and the very texture of your product changes.

The one-size-fits-all model era is over; the model you choose now expresses something integral about what your product is and does, as well as, how it works. Whether you want it to or not.

In this blog, we’ll explore three surprising takeaways from this new era: why your LLM is now a statement about your product, how models now have distinct personalities and styles, and why your prompts have to now evolve from monolithic instructions to adaptive systems.

Takeaway 1: LLM choice is now a statement about your product

Choosing a model is no longer a straightforward decision where the main consequence of your choice is having to implement a new API. It is now a product decision about the user experience you want to create, the failure modes you can tolerate, the economics you want to optimize for, and the metrics you want to excel in.

Models have developed distinct “personalities,” ways of reasoning, and instincts that directly shape how your product feels and behaves that go beyond just whether its output is technically right or wrong. Choose a different model and everything from what your tool is capable of to how it communicates with your users is significantly different.

So, in a world where traditional benchmarks that primarily or exclusively measure quantitative aspects of a model’s performance are no longer enough, what can you turn to for the data you need to chart your product’s direction? You could survey your team or your users or conduct focus groups but that could lack objectivity if you don’t do it in a rigorous manner.

To make this choice objective for our team, we focused on creating an internal North Star metrics matrix at CodeRabbit. Our metrics don’t just look at raw performance or accuracy. We also take into account readability, verbosity, signal-to-noise ratios, and more.

These kinds of metrics shift the focus from raw performance accuracy or leaderboard performance to what matters to our product and to our users. For example, a flood of low-impact suggestions, even if technically correct, burns user attention and consumes tokens. A theoretically “smarter” model can easily create a worse product experience if the output doesn’t align with your users’ workflow.

I would strongly recommend creating your own North Star metrics to better gauge whether a new model meets your products’ and users’ needs. These shouldn’t be static metrics but should be informed by user feedback and user behavior in your product and evolve over time. Your goal is to find the right list of criteria to measure that predict your users preferences.

What you’ll find is that the right model is the one whose instincts match the designed product behavior and your users’ needs, not the one at the top of any external leaderboard.

Takeaway 2: Frontier models have divergent ‘personalities’

Models are (now more than ever) “grown, not built,” and as a result, the latest generation has developed distinct instincts and behaviors. Different post-training cookbooks have fundamentally changed the direction of each model class. A prompt that works perfectly for one model will not work the same in another. Their fundamental approaches to the same task have diverged.

One powerful analogy that drives this point home is to think of the models as different professional archetypes. Sonnet 4.5 is like a meticulous accountant turned developer, meanwhile GPT-5-Codex is an upright ethical coder, GPT-5 is a bug-hunting detailed developer, and Sonnet 4 was a hyper-active new grad. The GPT-5 model class would make logical jumps further out in the solution space compared to the Claude model class, which tends to stay near the prompts itself. Which model is right for your use case and product, depends entirely on what you are wanting your product to achieve.

At CodeRabbit, we take a methodical approach to model evaluation and characterization. We then use this data to improve how we prompt and deploy models, ensuring we are always using the right model for each use case within our product. To give you an example of how we look at the different models, let’s compare Sonnet 4.5 and GPT-5-Codex. Based on extensive internal use and evals, we characterized Sonnet 4.5 as a “high-recall point-fixer,” aiming for comprehensive coverage. In contrast, GPT-5-Codex acts as a “patch generator,” preferring surgical, local changes.

These qualitative differences translate into hard, operational differences.

Takeaway 3: End of an era. Prompts are no longer monoliths

Because the fundamental behaviors of models have diverged, a prompt written for one model will not work “as is” on another anymore. For example, a directive-heavy prompt designed for Claude can feel over-constrained on GPT-5-Codex, and a prompt optimized for Codex to explore deep reasoning behavior will likely underperform on Claude. That means that the era of the monolithic, one-size-fits-all prompt is over.

So, what does that mean for engineering teams who want to switch between models or adopt the newest models as they’re released? It means even more prompt engineering! But before you groan at the thought — there are some hacks to make this easier.

The rise of prompt subunits

The first practical solution we’ve found at CodeRabbit is to introduce “prompt subunits.” This architecture consists of a model-agnostic core prompt that defines the core tasks and general instructions. This is then layered on top of smaller, model-specific prompt subunits that handle style, formatting, and examples – and which can be customized to individual models.

When it comes to Codex and Sonnet 4.5, the implementation details for these subunits are likely to be starkly different. We’ve found a few tricks from our prompt testing with both models that we would like to share:

• Claude: Use strong language like "DO" and "DO NOT." Anthropic models pay attention to the latest information in a system prompt and are excellent at following output format specifications, even in long contexts. They prefer being told explicitly what to do.

• GPT-5: Use general instructions that are clearly aligned. OpenAI models’ attention decreases from top to bottom in a system prompt. These models may forget output format instructions in long contexts. They prefer generic guidance and tend to "think on guidance," demonstrating a deeper reasoning process.

User feedback and evals

The second solution is to implement continuous updates driven by user feedback and internal evaluations. The best practice for optimizing an AI code-review bot or for that matter any LLM applications isn’t using an external benchmark; it’s checking to see if users accept the output.

Evals are more important than ever but have to be designed more tightly around acceptability by users instead of raw performance since one model might be technically correct significantly more than another model but might drown the user in nitpicky and verbose comments, diluting its value to users. By measuring the metrics that matter ~ acceptance rate, signal-to-noise ratio, p95 latency, cost, among others - and tuning prompts in small steps, the system will remain aligned with user expectations and product goals. The last thing you want is great quantitative results on benchmarks and tests but low user acceptance.

Conclusion

This shift from one-size-fits-all prompt engineering to a new model specific paradigm is critical. The days of brittle, monolithic prompts and plug-and-play model swaps are over. Instead, modular prompting, paired with deliberate model choice, give your product resilience.

The ground will keep shifting as models evolve so your LLM stack and prompts shouldn’t be static. Treat it like a living system. Tune, test, listen, repeat.

Also, be sure to check out our published detailed benchmarks on how the latest models behave in production. That gives you more data on what to expect from them.

• GPT-5 Codex: How it solves for GPT-5's drawbacks

• Claude Sonnet 4.5: Better performance but a paradox

• Benchmarking GPT-5: Why it’s a generational leap in reasoning

Try CodeRabbit with a 14-day free trial.

We raised $60M last week… so we made a funny filmの意訳です。

先日、CodeRabbitはシリーズBで6,000万ドルの資金調達を発表しました。
そのお祝いに、開発者向けソフトウェア企業として当然のことをやりました──おもしろ動画を作ったのです。

もちろん、全額を動画制作に使ったわけではありません。
ただ、AIが生成した大量のPRに追われる開発チームなら誰もが共感できる、ちょっと馬鹿げた（でも楽しい）企画で祝おうと決めました。

紹介します… “AIコーディングエージェントの暴走：短編映画”

「AIによる開発速度の向上」が、いつの間にかレビューの滞留地獄に変わってしまった──
そんな現実を描いた、モキュメンタリー×シットコム風の短編です。

• レビュアーは1人

• 通知は何十件も

• 未レビューPRは84件

• そして、ひたすらフィードバックを求める同僚ブラッド

キャスト紹介

主人公の疲弊したレビュアー役には、人気の開発者教育者（そしてインフルエンサー）Aaron Francisを起用。
彼は「機能をもっと早くリリースしたい」と思っていたのに、今ではキッチンにも行けず、朝8時に家を出ようとしても、ブラッドがPRの話をしてくる始末です。

そして、そのブラッドを完璧に演じたのがAustin von Johnson。
彼はAI生成PRを驚くべきスピードで量産できる開発者ですが、どんな状況でもレビューを待てないタイプ。
彼のストーキング、付箋メモ攻撃、フーディ姿でのPR奇襲……すべてが見事に「やりきって」いました。

笑いの裏にある、実際の課題

この短編は笑える内容ですが、そこに描かれた課題は現実のものです。

• AIコーディングツールが、チームのレビュー速度を超える速さでコードを生成する

• レビュー待ちPRが雪だるま式に増え、生産性が低下する

• シニアエンジニアがレビュー地獄に埋もれる

• レビュー品質がばらつき、リスクが増加する

• そしていつの間にか、「開発速度の向上」という約束が悪夢に変わる

CodeRabbitが解決すること

CodeRabbitはレビューの滞留を解消するために存在します。
私たちのAIコードレビューは、要件・テスト・CI・過去のdiff・所有者情報など、数十の文脈情報を参照して、見逃されがちなバグを検出します。
レビューアーの負担を軽減し、PRをより早く、安全にマージできるようにします。──もちろん、チームメイトを「ブラッド」にしないためにも。

素早くリリースし、賢くレビューし、心の平穏を保ちましょう。
そして、ブラッドをもう一人増やさないように。

👉 こちらから 「AIコーディングエージェントの暴走：短編映画」をご覧ください。
もしあなたの職場にも「PRまだ？」と追いかけてくるブラッドがいるなら、この動画をぜひ送ってあげてください。

Claude Sonnet 4.5: Better performance but a paradoxの意訳です。

Sonnet 4.5はAnthropicの最新Claudeモデルであり、私たちのコードレビュー・ベンチマークでは一見パラドックスのように感じられます。より高性能で、より慎重でありながら、時にもどかしい。Sonnet 4では見逃したバグを見つけ、カバレッジではOpus 4.1に近づき、さらに想定外の重大な問題をいくつか浮かび上がらせることもあります。

しかし一方で、自己防衛的に振る舞い、自らを疑い、時に決断的なレビュアーというより思慮深い同僚のように見えることもありました。データでは確かな進歩が見られます。Sonnet 4ではコメントのうち、重要と判断されたものが35.3%だったのに対し、Sonnet 4.5では41.5%でした。しかし、そのコメントの調子や文体は、「AIレビュアーに何を求めるのか」というより深い問いを投げかけています。

そして決定的なのは価格です。Sonnet 4.5はOpusレベルの性能に近づきながら、価格は変わらず維持されています。つまり、大規模なコードレビューを行うチームにとって、実用的な最適点に位置しているのです。

Sonnet 4.5は思考を声に出しているかのようで、確かな修正を出す一方、曖昧な「条件付き」警告のようなコメントを出すこともあり、それが一部の開発者にとっては理解を難しくしているかもしれません。それでは、ベンチマークの詳細を見ていきましょう。

ベンチマーク：評価の観点

Sonnet 4.5、Sonnet 4、Opus 4.1の3つを対象に、25件の難易度の高い実際のプルリクエストで評価しました。これらには既知の重大なバグが含まれており（並行性やメモリ順序、非同期レースコンディション、APIの誤使用など）、モデルがその重大な問題に直接コメントを出せた場合、そのPRは「合格」としました。

評価指標は、カバレッジ（S@25）、精度（コメントの合格率）、そしてシグナル対ノイズ比です。シグナル対ノイズ比については、重要なコメント（Important comments） に注目しました。これらは最も価値のあるコメントであり、以下を含みます。

• PASSコメント：PR内の既知の重大バグを正しく指摘・修正したもの

• その他の重要コメント：追跡対象ではないが、別の重大または深刻なバグを的確に指摘したもの

スコアボード：Sonnet 4.5はOpus 4.1に性能で迫る

結果は以下の通りです。

• カバレッジ: Sonnet 4.5はSonnet 4とOpus 4.1の間の差を大きく縮め、Sonnet 4を大きく上回りました。

• 精度: Opus 4.1は依然として最も正確で信頼性の高い実行可能なコメントを生成しました。高価格モデルであるため当然の結果です。

• 重要コメント率（重大な問題を指摘したコメントの割合）: より厳格な基準で測定した場合、Sonnet 4.5の重要コメント率は約41%。つまりコメントのうち4割が、主要なバグを解決するか、別の重大な問題を指摘していたことになります。Opus 4.1は50%、Sonnet 4は約35%でした。

文体とトーン：Sonnet 4.5は「慎重さ」にフォーカス

Sonnet 4.5のコメントはコードを修正しますが、Opus 4.1ほど自信に満ちたトーンではありません。ただし、Sonnet 4よりは明確です。

修正パッチの提示率:

• Sonnet 4.5の実行可能コメントのうち87%はコードブロックやdiffパッチを含み、Sonnet 4（90%）、Opus 4.1（91%）とほぼ同水準です。

• 違いは文体にあります。Opusのdiffは「外科的修正」のように明確ですが、Sonnet 4.5は探索的な文章を添える傾向があります。修正を「提案する」「検討する」といった表現が多く、断定的ではありません。

慎重な言い回し（Hedging language）:

• Sonnet 4.5では実行可能コメントの**34%**において、「might」「could」「possibly」といった慎重な表現が見られます。例：

  • “不要なアロケーション: cacheは使用されていません。 コンストラクタで4KBのメモリを確保していますが、使われていません。… cache_bufferの削除を検討してください。”

  • “空のtry/exceptブロックを削除してください。 …おそらくプレースホルダーです”

• Opus 4.1は約28%、Sonnet 4は約26%とやや低め。

• この慎重さにより、「問いかける」ようなトーンが生まれます。Sonnet 4.5はしばしば一緒に考えているような雰囲気を持ち、明確な判定を下すというより「共に推論している」ように感じられます。

自信のある言語（Confident language）:

• ただし、Sonnet 4.5は慎重さを補うように、高い確信を示すコメントも**39%**含んでいます。Sonnet 4（18%）、Opus 4.1（23%）よりも高い割合です。例：

  • “重大: self.プレフィックスが欠落しており、すべてのAPIメソッドが動作しません。 このままでは全てのメソッドがAttributeErrorを発生させます。”

  • “整数オーバーフローの可能性: optimization_cycle_countが無制限にインクリメントされ続けます。これは約414日稼働後に必ずオーバーフローします。”

• つまり、慎重さと確信の間で大きく揺れ動くのです。

シグナル対ノイズ比:

• Sonnet 4.5はSonnet 4より精度が向上しましたが、依然としてOpusよりも「軽微な」的外れコメントが多めでした。

• ただし、重要コメント（PASSコメント＋少数の高確信度コメント）に限定すると**41.5%**を達成。Opus 4.1は依然として約50%で最高水準です。

Sonnet 4.5が得意な領域

評価したPR群では、Sonnet 4.5が明確に、特に優れていた領域が見られました。

• 並行性バグ検出: C++のatomic操作やcondvarの誤用を的確に特定し、実行可能なdiffを生成

• 整合性チェック: サービス間での分散状態の不整合を確実に検出

• 追加バグの発見: 評価対象外のCritical問題も検出しましたが、より厳密な基準では件数はやや減少

AnthropicはSonnet 4.5を「ハイブリッド推論」「長期的計画立案」モデルとして打ち出しています。実際、コード内の副経路を追跡し、未追跡の実際の問題を発見する傾向が見られます。

Sonnet 4.5: 価格と性能のバランスが最適

Sonnet 4.5の最大の強みの一つは、価格対性能比にあります。Opus 4.1は依然としてAnthropicの最上位モデルですが、その分コストも高額です。

Sonnet 4.5はカバレッジと重大バグ検出能力の差を縮めつつ、はるかにコスト効率が良いです。多くのチームにとって、Opusレベルの結果を低コストで得られるこのバランスこそが、最も実用的な選択肢となる理由です。

Sonnet 4.5の弱点

ただし、Sonnet 4.5を使用する際はその弱点を理解しておく必要があります。

• デッドロック検出: Sonnet 4やOpusと同様、複雑なロック順序の追跡はまだ苦手です

• 冗長さと慎重さ: コメントが長く、留保的または曖昧なことがあります。以前の研究で評価したGPT-5 Codexは「パッチのように読める」ほど明快なコメントを書く傾向がありました。例として、GPT-5 Codexのコメントを以下に示します。

  • ロック順序 / デッドロック: 「ロック取得を一貫した階層順に並べ替えてください。これにより循環待ちデッドロックを防げます」

  • 正規表現の壊滅的バックトラッキング: 「ネストされた量指定子を削除してバックトラッキングを回避します」

• 精度のギャップ: コメント単位の精度35%、重要コメント率41.5%はSonnet 4より良いものの、Opus 4.1にはまだ届きません。

Sonnet 4.5の総評

Sonnet 4.5は「赤ペン先生」ではなく、そばで考えてくれる同僚のようです。可能性のある問題を指摘し、ほとんどの場合は正しく、時に慎重すぎる時もあります。ときには、思いがけない箇所にまで目を向けてくれます。

このスタイルはレビューにおいて諸刃の剣です。一方では、開発者は追加の重大問題を指摘してくれることを評価するでしょう。もう一方では、「このバグを確実に見つけてほしい」という場合、Opus 4.1のほうが鋭いです。

総括

AnthropicはSonnet 4.5を「エージェント的推論とコンピュータ利用」に向けたステップと位置付けています。コードレビューでは、その推論力がより豊かで慎重かつ広範なコメントとして現れます。

チームにとっての選択肢はこうです。

• 明確でパッチのようなフィードバックを重視するなら、Opus 4.1（またはGPT-5 Codex）が依然として基準として優れています。

• トラッキング対象外の隠れた重大問題まで発見したいなら、Sonnet 4.5が有力です。

• コスト効率を重視するなら、Sonnet 4.5が最も賢い選択肢です。Opus並みの精度を低価格で実現します。

いずれにせよ、Sonnet 4.5はレビュー体験の質感を変えます。より人間的で、常に明快とは限らないものの、より探究的で、より慎重で、時にあなたが見逃していた「正解」に辿り着くこともあるのです。

Sonnet 4.5 is Anthropic’s newest Claude model and in our code review benchmark, it feels like a paradox: more capable, more cautious, and at times more frustrating. It catches bugs Sonnet 4 missed, edges closer to Opus 4.1 in coverage, and even surfaces a handful of unexpected critical issues off the beaten path.

Yet, it hedges, it questions itself, and it sometimes sounds more like a thoughtful colleague than a decisive reviewer. The data shows real progress:41.5% of its comments were Important in Sonnet 4.5 vs only 35.3% in Sonnet 4.But the tone and texture of those comments raise deeper questions about what we want in an AI reviewer.

And then there’s the kicker: Sonnet 4.5 gets you close to Opus-level performance at a fraction of the price, making it a pragmatic sweet spot for teams reviewing code at scale.

Sonnet 4.5 thinks aloud and still delivers decisive fixes but some of its comments are framed as vague “conditional” warnings that could make its comments harder for some to parse.. Let’s dive into our benchmark.

Benchmark: What we looked for

We evaluated Sonnet 4.5, Sonnet 4, and Opus 4.1 across 25 difficult real-world pull requests containing known critical bugs (ranging from concurrency and memory ordering to async race conditions and API misuse). A model “Passed’ a PR if it produced at least one comment directly on the critical issue.

We measured coverage (S@25), precision (comment PASS rate), and signal-to-noise ratio. For signal-to-noise we focus on Important comments (these are the comments that matter most). They include:

• PASS comments that correctly addressed the known critical bug in the PR.

• Other important comments that did not solve the tracked issue, but still flagged a truly Critical or Major bug elsewhere.

Scoreboard - Sonnet 4.5 gets closer to Opus 4.1 in performance

The results were mixed:

• 

  Coverage: Sonnet 4.5 closes much of the gap between Sonnet 4 and Opus 4.1 and lands far ahead of Sonnet 4.

• Precision: Opus 4.1 still produces the cleanest, most reliable actionable comments but that is to be expected given that it’s a more expensive model.

• Important share (i.e. percentage of comments flagging a significant issue): With stricter criteria, Sonnet 4.5 lands at just over 41% Important share. That means about 4 in 10 of its comments either solved the key bug or flagged another truly significant issue. Opus 4.1 leads here at 50%, with Sonnet 4 at ~35%.

Style and tone: Sonnet 4.5 is focused on hedging

Sonnet 4.5’s comments patch the code but do so in a less confident tone than Opus 4.1 does but is still more confident than Sonnet 4.

Patches present:

• 87% of Sonnet 4.5’s actionable comments included a code block or diff patch, similar to Sonnet 4 (90%) and Opus 4.1 (91%).

• The difference is in style: Opus’s diffs read like surgical fixes, while Sonnet 4.5 often couches them in exploratory text. It “suggests” or “considers” changes rather than asserting them.

Hedging language:

• Sonnet 4.5 hedges in 34% of actionable comments—words like might, could, possibly. For example:

  • “Unnecessary allocation: cache is never used. The constructor allocates 4KB of memory that is never utilized … Consider removing the cache_buffer.”

  • “Remove the empty try/except block. … likely a placeholder”

• Opus 4.1 is steady at ~28%. Sonnet 4 sits slightly lower at ~26%.

• This hedging creates an “interrogative” tone: Sonnet 4.5 sometimes feels like it’s thinking out loud with you, rather than delivering verdicts.

Confident language:

• Sonnet 4.5 balances that hedging with higher confidence markers (39%) than Sonnet 4 (18%) or Opus 4.1 (23%). For example:

  • “Critical: Missing self. prefix breaks all API methods. All subsequent methods will raise AttributeError until this is corrected.”

  • “Potential integer overflow. optimization_cycle_count increments unbounded … this will overflow after ~414 days of runtime.”

• In other words, it swings between caution and certainty more dramatically.

Signal-to-noise:

• Sonnet 4.5 improved precision over Sonnet 4, but still produced more “minor” off-target notes than Opus.

However, when you count its true Important comments—PASS comments plus a small number of high-confidence off-EP issues—it lands at 41.5% Important share. Opus 4.1 is still the gold standard Anthropic model at ~50%.

What Sonnet 4.5 is good at

Across the PRs we tested Sonnet 4.5 with, we saw some clear areas where it stood out.

• Concurrency bug-finding: Sonnet 4.5 nailed C++ atomics and condvar misuses with clean, actionable diffs.

• Consistency checks: It reliably flagged distributed state mismatches across services.

• Extra bug surfacing: It did identify additional Critical issues not originally under evaluation, though fewer than initially expected under a stricter rubric.

As Anthropic markets Sonnet 4.5, they emphasize “hybrid reasoning” and “long horizon” planning. In practice, that shows up as more willingness to chase down side-paths in the code and note real but untracked issues.

Sonnet 4.5: Hits a price vs. performance sweet spot

One of the biggest advantages of Sonnet 4.5 is its price-to-performance ratio. While Opus 4.1 remains Anthropic's flagship model in raw capability, it also comes at a significantly higher cost.

Sonnet 4.5 narrows the gap in coverage and important bug-finding while staying far more cost-efficient to run. For many teams, that balance of having close to Opus-level results at a fraction of the price is what makes Sonnet 4.5 the most pragmatic choice.

Sonnet 4.5 weaknesses

But if using Sonnet 4.5, it’s critical to be aware of its weaknesses. These include:

• Deadlock coverage: Like Sonnet 4 and even Opus, it still struggles to trace complex lock ordering.

• Verbosity and hedging: Many comments run long, caveated, or uncertain. Compare this to GPT-5 Codex, which in our earlier work wrote comments that “read like patches” with crisp directness. For example, with GPT-5 Codex:

  • Lock ordering / deadlock: Reorder the lock acquisitions to follow a consistent hierarchy. This prevents circular wait deadlocks.”

  • Regex catastrophic backtracking: “Remove the nested quantifier to avoid catastrophic backtracking.”

• Precision gap: At 35% comment-level precision and 41.5% important share percentage, it’s better than Sonnet 4 but well short of Opus 4.1.

Sonnet 4.5 verdict

Sonnet 4.5 feels less like a teacher writing in red pen and more like a thoughtful colleague at your side: pointing out possible issues, often right, occasionally over-hedged, and sometimes spotting things you didn’t know were there.

That style is a double-edged sword in review. On one hand, developers may appreciate the extra critical issues it flags. On the other, when the task is “please catch this bug,” Opus 4.1 is still sharper.

Closing thoughts

Anthropic positioned Sonnet 4.5 as a step toward agentic reasoning and computer use. In code review, that reasoning shows up in richer, more cautious, and more wide-ranging comments.

For teams:

• If you value decisive, patch-like feedback, Opus 4.1 (or GPT-5 Codex) still sets the bar.

• If you want a reviewer that finds critical issues anywhere they lurk, even beyond the tracked bug, Sonnet 4.5 has surprising upside.

• And if you care about pragmatic price-to-performance, Sonnet 4.5 may be the smartest choice: close to Opus’s accuracy at a fraction of the cost.

Either way, Sonnet 4.5 changes the texture of reviews. It feels more human—not always cleaner, but more inquisitive, more hedged, sometimes more right in the places you weren’t looking.

How To Run Static Analysis On Your CI/CD Pipelines Using AIの意訳です。

「セットアップ時の思いがけない誤設定によりデータフィールドが空になり、その結果システムがアカウントを自動削除しました。」 —— これは、Googleが年金基金のアカウント全体を誤って削除した件についての説明です。

このようなインシデントは、現代のソフトウェアシステムにおける正確な設定の重要性を浮き彫りにします。ちょっとした誤設定が、特にCI/CDパイプラインにおいて壊滅的な結果を招くことがあります。

設定の正確性を担保し、コードレビューの複雑さを管理することは、DevOpsエンジニアにとって大きな負担になりえます。チームはしばしば機能開発を優先し、設定レビューは後回しになりがちです。その結果、見過ごされた誤設定が本番障害やダウンタイムを引き起こす可能性があります。

CodeRabbitは、AI駆動の分析とリアルタイムフィードバックによってコードレビューを自動化し、この問題の解決を支援します。他のツールのように複雑なセットアップを必要とせず、CodeRabbitはパイプラインにシームレスに統合され、構成ファイルに対する静的チェックの正確性と効率性を確保します。

本記事では、CodeRabbitがCI/CDパイプラインでの静的チェックにどのように役立ち、エンドツーエンドのデプロイプロセス全体で設定品質を保証し、効率を向上させるかを解説します。

なぜCI/CDパイプラインに静的チェックが不可欠なのか

構成ファイルは、インフラやアプリケーションのデプロイを制御するCI/CDパイプラインの要です。これらのファイルのエラーは大きな障害や事業中断リスクにつながるため、早期の検証が不可欠です。静的チェックは、セキュリティ脆弱性、コード品質問題、運用上の混乱を緩和する上で重要な役割を果たします。

以下は、仮想環境のセットアップ、依存関係のインストール、Lintコマンドの実行を行うCircleCIのワークフロー構成ファイルの例です。

jobs:
 lint:
   docker:
     - image: circleci/python:3.9
   steps:
     - checkout
     - run:
         name: Install Dependencies
         command: |
          python -m venv venv
          . venv/bin/activate
          pip install flake8
     - run:
         name: Run Linting
         command: |
          . venv/bin/activate
          flake8 .

上記の構成で静的チェックが行われなければ、認識されない構文や無効な設定といった問題が漏れ、後工程でビルドが失敗する恐れがあります。例えば、依存関係の不足や不適切に整形されたコードは、デプロイパイプラインを破綻させる実行時エラーを招いたり、本番で原因追跡が難しいバグを持ち込む可能性があります。

総じて、静的チェックは以下を実現します。

• 早期のエラー検出: 実行前に構文エラーや誤設定を検出し、実行時障害の可能性を減らします

• コーディング標準の遵守: スタイルガイドやベストプラクティスをコードや構成ファイル全体に適用し、品質の一貫性を確保して変更の保守・レビューを容易にします

• コード品質の向上: テストの成功や一定以上のカバレッジなど、デプロイ前に満たすべき基準を静的チェックで担保し、全体的な品質を高めます

CodeRabbitを使った静的チェック

CodeRabbitはCI/CDワークフローに統合され、一般的な誤設定を特定することで優位性を発揮します。この能力はデプロイプロセスの整合性を維持し、エンドユーザーに影響しうる中断を防ぐ上で重要です。

さらに、追加の設定を必要とせずに静的解析やLintを自動実行できるという独自の利点があります。DevOpsチームにとって、この機能はセットアップ工程を簡素化し、複雑な設定ではなく開発に集中できるようにします。

• 既存のCI/CDパイプラインに影響を与えずに統合され、追加設定なしでLintと静的解析を自動実行します。

• GitHub、CircleCI、GitLabなどの主要プラットフォーム上の多様なツールと統合し、Actionlint、Yamllint、ShellCheck、CircleCIパイプラインなどのチェックを実行します。これによりセットアップが簡素化され、追加の手作業なしに素早く結果を得られます。

• JenkinsやGitHub Actionsのようなツールでは、CodeRabbitはビルドやコミットごとに継続的に静的解析を行い、誤設定を早期に検出してワークフローの信頼性を高めます。

次のセクションでは、実際のCodeRabbitの動作を見ていきます。

CodeRabbitとGitHub ActionsのActionlintで誤設定を検出する

CodeRabbitの機能を示すため、GitHub Actionsワークフローをプロジェクトに統合し、CI/CDパイプラインを自動化する方法を見ていきます。リポジトリには潜在的なエラーを含む構成ファイルがあり、CodeRabbitがそれを検出して報告します。

以下は、作成したワークフロー内のタスクシーケンス図です。

プルリクエストを送信すると、CodeRabbitがファイルをレビューし、潜在的な誤設定を自動的に検出します。リポジトリの準備ができたら、CodeRabbitと統合して自動コードレビューをセットアップし、以下の主要セクションからなる、包括的で構造化されたレポートを生成します。

• Summary（概要） – コードや構成で検出された主要な変更点の簡潔なサマリー。注意が必要な領域を素早く把握できます。

• Walkthrough（詳細解説） – 対象ファイルの詳細なステップバイステップ分析。具体的な問題点、設定、推奨事項をガイドします。

• Table of Changes（変更一覧） – 各ファイルの変更点と要約の一覧。必要な対応の優先度付けを素早く行えます。

これらのセクションは、構成ファイルの調整やCodeRabbitダッシュボードの利用でカスタマイズできます。詳しくはCodeRabbit設定ガイドをご覧ください。

以下は、CodeRabbitのレビューを通じて詳細な洞察と提案が得られたサンプルのworkflow.yaml構成です。

name: development task

on:
  push:
    branches:
      - main
      - develop
      - staging
  pull_request:
    branches:
      - main
      - develop
      - staging

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Lint workflow YAML files
        uses: rhysd/actionlint@v1

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Lint JavaScript code
        run: npm run lint

  build:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies and cache
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
        run: npm install

      - name: Run tests
        run: npm test

      - name: Check for vulnerabilities
        run: npm audit --production

  terraform:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.5.0

      - name: Terraform init
        run: terraform init
        working-directory: infrastructure/

      - name: Terraform plan
        run: terraform plan
        working-directory: infrastructure/

      - name: Terraform apply (development)
        if: github.ref == 'refs/heads/develop'
        run: terraform apply -auto-approve
        working-directory: infrastructure/
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCES_KEY: ${{ secrets.AWS_SECRET_ACCES_KEY }}

  docker:
    runs-on: ubuntu-latest
    needs: terraform
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Login to AWS ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1
        with:
          region: us-east-1

      - name: Build and tag Docker image
        run: |
          IMAGE_TAG=${{ github.sha }}
          docker build -t ${{ secrets.ECR_REGISTRY }}/my-app:latest .
          echo "IMAGE_TAG=$IMAGE_TAG" >> $GITHUB_ENV

      - name: Push Docker image to AWS ECR
        run: |
          IMAGE_TAG=${{ env.IMAGE_TAG }}
          docker push ${{ secrets.ECR_REGISTRY }}/my-app:$IMAGE_TAG

  deploy:
    runs-on: ubuntu-latest
    needs: docker
    environment: production
    steps:
      - name: Deploy to Development
        if: github.ref == 'refs/heads/develop'
        run: |
          echo "Deploying to development environment"
          # Your deployment script here

      - name: Deploy to Staging
        if: github.ref == 'refs/heads/staging'
        run: |
          echo "Deploying to staging environment"
          # Your deployment script here

      - name: Manual Approval for Production
        if: github.ref == 'refs/head/main'
        uses: hmarr/auto-approve-action@v2
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

      - name: Deploy to Production
        if: github.ref == 'refs/heads/main'
          run: |
          echo "Deploying to production environment"
          # Your deployment script here

コードレビューに入る前に、このワークフローが何を行っているかを高レベルで整理します。

• main、develop、stagingブランチへのpushおよびプルリクエストでCI/CDパイプラインをトリガーし、継続的インテグレーションを実現します。

• YAML構成の構文チェックや、アプリケーションに必要な依存関係のインストールを含むLintワークフローを実行し、コード品質を担保します。

• アプリケーションに必要なクラウドインフラのプロビジョニングと管理のためにTerraformをセットアップします。

• アプリケーションの機能を検証するテストを実行し、脆弱性チェックを行ってコードの安全性と安定性を確保します。

• デプロイに備えてアプリケーションのDockerイメージをビルド・タグ付けします。

• DockerイメージをAWS Elastic Container Registry（ECR）にプッシュし、デプロイのためのアクセスを容易にします。

• ブランチに応じてアプリケーションを開発・ステージング・本番の各環境にデプロイし、本番デプロイにはコントロールと監視のための手動承認ステップを含めます。

workflow.yamlの構成と各コンポーネントを確認したので、まずSummaryから各セクションを見ていきます。

Summary

Summaryはレビューの第一歩として、最新コミットで導入された変更点の明確で簡潔な概要を提供します。新機能、スタイル調整、構成変更、プルリクエストで挙げられたその他の関連修正など、重点ポイントを素早く把握できます。

このスニペットは、パフォーマンス向上のための非デバッグモードでの実行、コードのLint・ビルド・デプロイを合理化する自動CI/CDパイプラインの実装など、重要な保守作業を強調しています。

Summaryは、最新コミットで加えられた主要な変更点と改善点の理解に役立ちます。

Summaryで要点を把握したら、次はWalkthroughセクションで具体的な変更点の詳細を見ていきます。

Walkthrough

このセクションでは、最新コミットで各ファイルに加えられた具体的な変更を包括的に概観します。各ファイルの変更がプロジェクト全体の機能性やユーザー体験の向上にどう寄与するかを明確にします。

Changes Tableは、最新コミットにおける各ファイルの変更点を簡潔にまとめ、コードベースのどこが変更されたかを素早く特定できるようにします。

各行には変更されたファイルと、Change Summary列に詳細な変更説明が含まれます。CSSファイルのスタイル更新、アプリケーションロジックの機能調整、CI/CDパイプライン構成の改善などが含まれます。

情報を構造化して提示することで、変更の影響を理解しやすくし、開発者がプロジェクトへの影響を素早く把握できるようにします。

全体として、コラボレーションにおける重要なリファレンスとして機能し、さらなる議論やレビューが必要な箇所にチームメンバーが集中できるよう支援しつつ、コードベースの変遷を追跡します。ちょっとした遊び心として、エラーに関するポエムも生成します。

Code Review

以下のセクションでは、構成ファイルを詳細に検査し、改善余地のある領域を特定します。キャッシュ戦略の改善からデプロイプロセスの最適化まで、GitHub Actionsワークフロー全体の効率と堅牢性を高めるための提案が、コードに対して具体的に提示されます。

レビュー詳細、使用された構成、レビューのプロファイル、処理対象ファイル、使用された追加コンテキストなどに関する実行可能なコメントの詳細と概要が提供されます。ワンクリックでコミットできる提案が含まれる場合もあります。

ここから、CodeRabbitがワークフロー各部に対して提案したレビューコメントを見ていきます。CodeRabbitは構成ファイルがGitHub Actionsのワークフローであることを自動認識し、actionlintで徹底的に解析します。レビューの過程で、パフォーマンス最適化に関する有益な洞察と提案が示されます。

lintジョブでは、actions/cache@v3を用いたnpm依存関係のキャッシュ機会を検出しました。Lint実行前にキャッシュステップを追加する提案により、以降の実行時間を短縮できます。このプロアクティブなフィードバックは、手動介入なしにワークフローを効率化し、より最適化されたCI/CDパイプラインを実現します。

指摘の通り、キャッシュステップの構造に誤りがあります。runコマンド（npm install）がcacheアクションのusesブロック内に置かれており、正しく実行されない可能性があります。

これを解決するため、キャッシュとインストールのステップを分離することを提案しています。修正案ではキャッシュ処理を独立したブロックに移し、次のステップでnpm ciを使用して依存関係をクリーンかつ高速にインストールするようにしています。

Terraformセクションでは、Terraformバージョンに変数を使う点での潜在的問題を検出しました。加えて、特にplanやapplyでAWS認証情報に関する問題が生じうること、AWS_SECRET_ACCESS_KEYのタイポなど、わずかなミスでもパイプラインの実行失敗につながる可能性を指摘しています。

これらに対し、タイポ修正、Terraformバージョンの更新容易化、すべてのTerraformコマンドでAWSクレデンシャルが利用可能になるような構成変更が提案されました。

dockerジョブでは、Dockerイメージにlatestタグを使用している点でのセキュリティリスクを検出しました。latestのみの運用はバージョニングやロールバックに問題を生じうるため、latestと特定バージョンタグ（例: git SHA）の併用を提案し、追跡性とロールバック容易性を高めます。

deployジョブでも複数の潜在的問題を検出しました。手動承認ステップに自動承認アクションを用いており、本来の目的に反しています。さらに、本番デプロイのステップに構文エラーがあり、実際のデプロイスクリプトが欠落しているため、プロセスが不完全です。これらの問題に対する修正案が提示されています。

CodeRabbitのAI駆動分析により、構成ファイルの問題が迅速に特定・強調され、修正提案が示されることが分かりました。

CI/CDパイプラインでCodeRabbitを使う利点

コードレビューを自動化し精密なフィードバックを提供することで、CodeRabbitはコード品質を高め、CI/CDパイプラインに潜む問題や脆弱性を早期に捕捉します。その結果、スムーズなデプロイとエラー削減につながります。

CI/CDでCodeRabbitを使うことで得られる主な利点を見ていきましょう。

開発者生産性の向上

自動化された静的チェックワークフローにより、CodeRabbitは手動レビューの必要性を減らし、DevOpsエンジニアが設定修正ではなく、インフラやデプロイプロセスの最適化といった戦略的タスクに集中できるようにします。即時のフィードバックループにより、コミットごとに問題を素早く検出・対処でき、迅速な開発ペースを維持できます。

コード品質の改善

CodeRabbitはベストプラクティスに照らして構成ファイルを自動検証し、設定の一貫性を強制して早期にエラーを捕捉します。プラットフォームは過去のレビューから学習し、反復的なアラートを賢く抑制、最も重要な問題に集中できるようにします。さらに、ワンクリックの提案を提供し、構成ファイルに素早く取り込めます。

セキュリティ

CodeRabbitは、誤設定されたアクセス制御や不適切な設定などのセキュリティ脆弱性を早期に検出し、侵害の可能性を低減します。静的チェックをCI/CDプロセスに統合することで、構成ミスによるデプロイ失敗を防ぎ、より安定で信頼性の高いソフトウェアデリバリーパイプラインを実現します。

まとめ

本記事では、誤設定が遅延やセキュリティ脆弱性、さらにはデプロイ失敗につながること、そしてアプリケーションコードと同等に厳密にテストする重要性を見てきました。

従来の手法が構成ファイルのテストの重要性を見落としがちなのに対し、CodeRabbitはCI/CDパイプラインのレビューをコード/構成レビューの自動化、重大なエラーの検出、全体的な品質向上によって支援します。手動レビュー時間を大幅に削減し、DevOpsチームが戦略的タスクに集中してデプロイサイクルを加速できるようにします。

AIコードレビューの効果をワークフローで体験してみてください——今すぐCodeRabbitの無料トライアルを始めましょう。

GPT-5 Codex: How it solves for GPT-5's drawbacksの意訳です。

CodeRabbitのコードレビューは、開発者がバグを修正しコードをデリバリーするのを支援します。私たちは最近、GPT-5のベンチマークについて記事を書き、AIコードレビューという私たちのユースケースにおいて、このモデルが推論面で世代的な飛躍を遂げているという見解を述べました。より広いユーザーベースに展開する中で、S/N値（シグナル/ノイズ値。以下SNR）が低下し、レビューが過度に細かすぎるという印象を持たれることが分かりました。

GPT-5 Codexのリリースと、私たちが実施した製品変更（重大度タグ付け、より厳格なリファクタ提案のゲーティング、フィルタリング改善）により、難しいバグを見つける能力を犠牲にすることなく、SNRを取り戻すことができました。

刷新した「Hard 25」PRセットにおいて、GPT-5 CodexはGPT-5と比べてコメントあたりの精度が約35%向上し、エラーパターンレベルの不具合カバレッジは本質的に同等のまま、コメント量を約3分の1削減しました。さらにGPT-5 Codexモデルの低レイテンシと組み合わせることで、体感はより軽快、かつフォーカスされたものになります。

何を（なぜ）測定したか

GPT-5 Codexのテストでは、OSSのPRからなる新しい「Hard 25」スイート（以前の記事よりやや難度高め）を実行しました。これは私たちのデータセットに含まれる中でも特に難しい25本のプルリクエストです。現実世界のバグを表したもので、対象は以下の通りです。

• 並行性の問題（例: TOCTOUレース、誤った同期化）

• オブジェクト指向設計の欠陥（例: 仮想呼び出しの落とし穴、参照カウントメモリモデルの破綻）

• パフォーマンス上の危険（例: 無制御なキャッシュ成長、タイトループによるスタール）

• 言語特有の落とし穴（例: TypeScriptの誤用、C++のメモリ順序の微妙さ）

評価したモデルは以下の通りです。

• GPT-5 Codex

• GPT-5

• Claude（Sonnet 4 および Opus-4.1）

何を評価したか

各モデルには、以下の観点でスコアを与えました:

• EP（Error Pattern / エラーパターン）
  PRに潜む特定の根本欠陥（例: 条件変数でのlost wakeup、ロック順序の不整合、ブール条件が錯綜する中に隠れたロジックバグ）。

• EP PASS/FAIL（PR単位）
  そのPRのEPを直接修正、または信頼できる形で表面化させるコメントを少なくとも1つ残せばPASS。コメントがゼロならそのPRはFAIL。

• コメントPASS/FAIL（コメント単位）
  EPを直接修正、または信頼できる形で表面化させればPASS、そうでなければFAIL。

• コメントあたり精度（Per comment precision）
  PASSコメント ÷ 全コメント。今回のデータセットにおける実務上のSNR。

• Important share（重要コメント比率）
  すべてのPASSはImportant扱い。EPを解決しないが、重大なバグ（use-after-free、二重解放、lost wakeup、メモリリーク、null参照、パストラバーサル、破滅的な正規表現など）を正しく指摘するコメントもImportant。それ以外はMinor。

スコアボード - CodexはSNRを改善

要点: Codexは、GPT-5とほぼ同じEPを見つけつつ、より少ない・締まったコメントで行うため、SNRが向上します。

意味するところ: Codexは25本中20本のPRをカバー（残り5本は未カバーのFAIL）。総コメント数は少ないにもかかわらず、EPのPASS数はやや上回り（16 対 15）、重要（Important）コメントは大幅に増加。コメントの半分以上が、そのPRで想定していた問題へのダイレクト、または別の重大バグの指摘でした。GPT-5とClaudeは精度・重要比率ともに約40%で、後塵を拝しました。

結論: 同等のEPカバレッジで、ノイズは減少
CodexはGPT-5のバグ発見力を維持したまま、コメント量を約32%削減（54 対 79）し、コメントあたり精度を約35%向上（46.3% 対 34.2%）。ClaudeはカバレッジはGPT-5に近いものの、より冗長で精度は低めでした。

スタイルと構造（Codexがパッチのように読める理由）

Codexの返信は一貫してアクション優先（ほぼ常にdiff付き）で、曖昧表現が少ない。これは「すぐパッチに反映できる提案」を望むレビュアーの期待に合致します。

Codexが得意とするバグの種類

スイート全体では、どのモデルも並行性・同期の問題に強みを見せましたが、Codexは特に以下で際立ちました。

1. 条件変数の誤用とlost wakeup
   ロック下でのwait、ループ内での述語チェックといった標準パターンを提案し、具体的なdiffを提示。

2. ロック順序とデッドロック
   取得順の不整合を指摘し、ロック階層の導入やクリティカルセクション外への処理移動を提案（いずれも実行可能な編集付き）。

3. APIやパフォーマンスの微妙な罠
   破滅的な正規表現のバックトラッキングやメモリモデルの順序問題などを的確に特定し、パッチを提示。

なぜGPT-5は騒がしく感じられたのか、そしてどう解決したか

観測: SonnetやOpusからGPT-5に移行した際、レビューあたりの総コメント数はほぼ倍増しました。一方でハルシネーションは1%未満、ネガティブトーンも1%未満まで低下したにもかかわらず、受け入れ率（有益と判断されたコメントの比率）は、GPT-5導入前のベースラインに比べて大きく低下しました。

Codexでの変化: GPT-5 Codexと私たちの製品変更の併用により、受け入れ率は以前の水準まで回復。一方で総コメント量は「GPT-5導入前」より依然多いままです。要するに、「有益さ」は取り戻しつつ、GPT-5並みに実問題を見つけ続けられるようになりました。

この改善には2つの製品変更が寄与しました。

1. 重大度とレビュータイプのタグを前面に

   • レビュータイプ: ユーザーが読みたいコメントの種類を自己選択できるよう、⚠️ Potential issue、🛠️ Refactor suggestion、🧹 Nitpick（Assertiveモードにしない限り非表示）を用意。

   • 重大度: コメントに重大度タグを付け、優先度を明確化。タグは🔴 Critical、🟠 Major、🟡 Minor、🔵 Trivial、⚪ Info。

   • バグ（Critical/Major/Minor）は常に表示。その他は常にではありません。リファクタはモデルが「本質的」と判定した場合のみ表示。すべて見たいユーザーはAssertiveに切替可能。

2. より厳格なフィルタリングと集約

   • 重複メモを折りたたみ、「あると嬉しい」レベルの提案は明確なROIがない限り除外。結果として、コメントは少数精鋭化し、ノイズで見落とすリスクが減少。

レイテンシ: 速さは正義 & Codexは速い

5分のレビューは許容範囲ですが、30分は許容できません。GPT-5の「常に深く考える」スタイルは、ファーストトークンまでの時間と全体のレビュー時間を大幅に増やしました。私たちは最近いくつかのパイプライン最適化を行い、さらにCodexがGPT-5由来のレイテンシを低減できるようになりました。

Codexの可変（弾力的）な思考は、不要な場面では深掘りを減らし、実運用でTTFT（最初の出力までの時間）とE2Eレビュー時間を短縮しています。総じて、レビューは速くなり、フィードバックは早く、ヒューマン・イン・ザ・ループの流れが改善されます。

CodeRabbitユーザーが期待できること

Codex導入後、AIコードレビューはどう変わるでしょうか？

1. 生のバグ検出力は同等

   • 刷新したHard 25で、CodexのEPレベルPASSは64%、GPT-5は60%（以前のPRセットではGPT-5が77.3%）。GPT-5がもたらした重要な勝ち筋を失っていません。

2. コメントは少なく、しかし強く

   • 総コメント数はGPT-5比で約32%減、SNR（コメントあたり精度）は約35%向上。文章よりパッチが増えます。

3. 重大度タグでレビューに集中

   • 新しい重大度タグにより、Critical/Majorがトップに浮上。リファクタはゲート制御、ニットピックはオプトイン。コメントの走査に費やす時間が減り、修正に時間を割けます。

4. フィードバックループの高速化

   • Codexの軽量な推論とパイプライン改善で、最初の有益なコメントまでの時間が短縮。体感で分かります。

定量的付録（データ好きのあなたへ）

以下は興味深かった追加統計を紹介します。

• コメントあたり精度（SNR）の向上: Codex 46.3% 対 GPT-5 34.2% — 相対で約+35%。

• コメント量の差: Codex 54 対 GPT-5 79 — 約32%減、EPのPASSは実質同等（16 対 15）。

• スタイル: Codexは94%のコメントでdiffを含み、このセットではClaudeやGPT-5より曖昧表現が少ない。

• 実環境での受け入れ: GPT-5ロールアウト中は受け入れ率が大きく低下。Codexと製品変更の併用で約20–25%相対上昇し、導入前水準に回復。かつ、GPT-5導入前より受け入れコメント数は多いまま。

Codexがまだ弱い点（と取り組み）

改善は大きいものの、課題が残っていないわけではありません。現在、以下に取り組んでいます。

• カバレッジの穴
  モデルがPRにコメントを残さない場合、そのEPはハードFAIL。Codexの探索ヒューリスティクスを広げ、特定クラスの問題を見落としにくくします。

• リファクタ過剰提案（調整済みだが未完）
  「本質的なもののみ」のゲートでノイズは抑制しましたが、特に大規模diffでコメント過多になりがちなケースの閾値をさらに引き締めます。

• ユーザー主導の優先度付け
  GitHubのインライン順序は変更できませんが、各コメントに重大度を注記し、上から順にトリアージしやすくします。

Codex GPT-5: バグ捕捉力はそのまま、副作用は少なく

私たちの指標はシンプルです: 重要なバグを、素早く、ノイズに埋もれさせずに捕まえること。Codexはその実現を助けてくれます。GPT-5の噛み応えある推論力を保ちながら、SNRを回復させ、レイテンシを大幅に削りました。今後も測定・改善を継続し、より良い製品をリリースし続けます。

CodeRabbit MCP server integration: Code reviews with more contextの意訳です。

すべての開発チームは、孤立した状態で行うコードレビューのつらさを知っています。AIツール（あるいはチームメイト）であっても、文法やスタイル、パターンにコメントはできます。しかしビジネス要件、デプロイ依存関係、組織的な知識がなければ、全体像の半分を推測に基づいている状態です。

CodeRabbitは現在、Linear、Jira、Circle CIといったいくつかのネイティブ統合を提供しており、これらのツールがコードレビューにもたらす価値を確認してきました。だからこそ今回、CodeRabbitのMCPサーバー統合のGAリリース を発表できることがとても嬉しいです。これにより、さらに多くのコンテキストをレビューに取り込めるようになります。

本リリースで、CodeRabbitはConfluenceにあるビジネス要件からCI/CDパイプラインのシステム依存関係、さらには社内MCPサーバーのデータまで、開発エコシステム全体からコンテキストをオーケストレーションできる初のAIコードレビュープラットフォームとなりました。つまり、コードが「何を達成しようとしているのか」を本当に理解するレビューが可能になるのです。

14日間の無料トライアルを開始 → 約10分で、チーム標準に基づいたコンテキスト対応のレビューを実現。

なぜAIコードレビューにMCPが必要なのか？

開発チームは数多くのツールを使って作業しています。

• 要件はLinearにある

• 設計仕様はFigmaにある

• アーキテクチャの決定はConfluenceに記録される

• セキュリティ基準は監査ごとに社内Wikiで更新される

AIコードレビューツールは基本的なコンテキスト、つまりコードベース、コーディング規約、いくつかの統合から始めます。構文を解析し、パターンを確認し、改善を提案します。しかし「そのコードがチームにとって本当に機能するかどうか」を左右するコンテキストは欠けています。

MCPクライアントとしてのCodeRabbitは、組織コンテキストのコンパイラの役割を果たします。Wiki、チケット、デプロイパターンといった高レベルの入力を正確で実用的なコードレビューインサイトへと変換します。冗長な統合や脆いハックに頼ることなく、MCPはCodeRabbitのようなクライアントがLinearチケット、Confluenceドキュメント、Datadogメトリクス、Slackのディスカッションといった場所から必要なデータだけを取り込めるようにします。

実際にはどう動くのか…

CodeRabbitはレビューを開始する前に接続済みMCPサーバーを検索します。たとえばデータベーススキーマの変更はデータアーキテクチャ文書と照合され、APIエンドポイントの実装は社内Wikiに記録されたサービス設計パターンと突き合わせられます。

例: CodeRabbitによるコード整合性の確認

どのツールからでも重要なコンテキストを取り込む

従来のコードレビューツールは特定の統合を前提としています。CodeRabbitのMCP統合は、MCPサーバーを持つあらゆるシステムで動作します。独自の社内ツール、ニッチなSaaSプラットフォーム、カスタムドキュメントシステム。MCPサーバーがあれば、CodeRabbitはどこにでも接続できます。

CodeRabbitをMCPクライアントとして利用すると、3種類の異なるコンテキストからレビューの深みを得られます。

技術的コンテキスト

• 依存関係、パフォーマンスデータ、静的解析、テストカバレッジなど

• ネイティブ統合: GitHub Actions、GitLab CI、Bitbucket Pipelines

• MCPサーバー: Datadog、New Relic、SonarQube、Snyk、Grafana

レビューコメント例は以下の通りです。

ビジネスコンテキスト

• 要件、ユーザーストーリー、受け入れ基準など

• ネイティブ統合: Linear、Jira、GitHub Issues、GitLab Issues

• MCPサーバー: Confluence、Notion

レビューコメント例は以下の通りです。

組織的コンテキスト

• 過去の意思決定、慣例、会議メモ、組織的知識など

• ネイティブ統合: PR履歴、チーム慣習

• MCPサーバー: Slack、Microsoft Teams、Stack Overflow for Teams、PagerDuty

レビューコメント例は以下の通りです。

MCP統合を始めるには

CodeRabbitのMCPクライアントは最小限の設定で導入できます。ほとんどの開発チームは10分以内に最初のMCPサーバーを接続できます。

MCPサーバー対応の人気開発ツール:

• Linear（ネイティブMCPサポート、5分）

• Notion（MCPサーバーあり、10分）

• Confluence（コミュニティ製MCPサーバー、15分）

• Figma（MCPプラグインあり、10分）

コード変更がどの開発システムを参照すべきかを定義します。データベース変更はアーキテクチャ文書を、認証変更はセキュリティ文書を確認する、という具合です。

MCPサーバーを追加するのは簡単です。

1. CodeRabbitダッシュボードで「integrations」に進み、必要ならMCP Serversタブに切り替えます

2. あらかじめ用意されたMCPサーバーオプションをクリックするか、「New MCP Server」ボタンから他のMCPサーバーを追加できます

3. リストにないMCPサーバーについては、必要な認証情報を入力します

4. MCP情報をどのように利用するかの使用ガイダンスを確認します

5. 接続が完了すると、利用可能な呼び出し一覧が表示され、カーソルを合わせると詳細を確認できます

6. 各呼び出しをクリックしてアクセスを有効化/無効化することも可能です

あらゆるコンテキストを取り込むレビュー基盤

CodeRabbitは50以上の統合に標準対応しています。MCPを利用すれば、カスタムサーバーや社内ツールにも拡張できます。まずはLinear、Confluence、Datadog、Slackといった既存システムから始め、必要に応じて追加していけます。

次のステップ:

1. 14日間の無料トライアルを開始

2. MCPサーバーディレクトリを表示

3. MCPドキュメントを見る

CodeRabbit’s code reviews help developers fix bugs and ship code. We recently wrote about benchmarking GPT-5 and opined that the model was a generational leap in reasoning for our use case of AI code reviews. As we rolled out to our wider user base, we observed that the signal to noise ratio (SNR) dipped, and users felt the reviews were too pedantic.

The release of GPT‑5 Codex, plus the product changes we made (severity tagging, stricter refactor gating, better filtering), brings our signal to noise ratio back without sacrificing the ability to find the hard bugs.

On our refreshed hard 25 PR set, GPT-5 Codex delivers about 35% higher per comment precision than GPT‑5, maintains essentially the same error pattern- level bug coverage, and cuts roughly a third of the comment volume. Combine that with the lower latency of the GPT-5 Codex model and the experience feels snappier and more focused.

What we measured (and why)

When testing GPT-5 Codex, we ran a fresh “hard 25” suite of OSS PRs (slightly tougher than the previous post). These are 25 of the most difficult pull requests from our dataset. These PRs represent real-world bugs that span:

• Concurrency issues (e.g. TOCTOU races, incorrect synchronization)

• Object-oriented design flaws (e.g. virtual call pitfalls, refcount memory model violations)

• Performance hazards (e.g. runaway cache growth, tight loop stalls)

• Language-specific footguns (e.g. TypeScript misuses, C++ memory order subtleties)

We evaluated the following models: :

• GPT‑5 Codex

• GPT‑5

• Claude (Sonnet 4 and Opus‑4.1)

What we looked for

We gave each of the models a score based on how they performed on these factors:

• EP (Error Pattern). The specific underlying defect seeded in a PR (e.g., lost wakeup on a condition variable, inconsistent lock order, logic bug hidden in boolean soup).

• EP PASS/FAIL (per PR). PASS if the model left at least one comment that directly fixes or credibly surfaces that PR’s EP. If it left no comment on that PR, it is counted as FAIL for that PR.

• Comment PASS/FAIL (per comment). PASS if the comment directly fixes or credibly surfaces the EP, otherwise FAIL.

• Per comment precision. PASS comments ÷ all comments. This is our operational SNR for this dataset.

• Important share. Every PASS is Important. Comments that do not solve the EP but still flag a genuine critical or major bug (like a use after free, double free, lost wakeup, memory leak, null deref, path traversal, catastrophic regex) are also Important. Everything else is Minor.

Scoreboard - Codex improves signal-to-noise

Takeaway: Codex finds essentially the same EPs as GPT‑5 but does it with fewer, tighter comments, so the signal-to-noise ratio is improved.

What this means: Codex covered 20 of the 25 PRs (the other 5 count as uncovered fails). Despite fewer comments overall, Codex passed slightly more EPs (16 vs. 15) and landed far more Important comments. Over half its comments are either direct hits on the issue we were representing in that PR or flag other EP critical bugs. GPT‑5 and Claude trailed in precision and Importance share at about 40%.

The verdict: Same EP coverage, less noise: Codex retains GPT-5’s bug finding power but trims the chatter with about 32% fewer comments than GPT‑5 (54 vs. 79) and about 35% higher per comment precision (46.3% vs. 34.2%). Claude looks similar to GPT‑5 on coverage but is chattier, with lower precision.

Style and structure (why Codex reads like a patch)

Codex replies are consistently action forward (diffs almost always included) and low hedge. That lines up with what reviewers want: suggestions that translate directly into a patch.

The kinds of bugs Codex is good at

Across the suite, all models did well on concurrency and synchronization, but Codex stood out for:

1. Condition variable misuse and lost wakeups. Codex proposes the canonical patterns (wait under lock, check predicate in a loop) and supplies concrete diffs.

2. Lock ordering and deadlocks. It calls out inconsistent acquisition order and suggests a lock hierarchy or moving work outside critical sections, again with actionable edits.

3. Subtle API and performance traps. Examples include catastrophic regex backtracking and memory model orderings. Codex pinpoints and patches them cleanly.

Why GPT‑5 felt noisier, and how we fixed that

What we saw: When we moved from Sonnet and Opus to GPT‑5 our total comments per review nearly doubled. Even though hallucinations fell to under 1% and negative tone fell to under 1%, the acceptance rate (share of comments judged helpful) declined significantly relative to its baseline prior to the adoption of GPT-5.

What changed with Codex: With GPT‑5 Codex plus some product changes we’ve implemented, our acceptance climbed back to prior levels while overall comment volume stayed higher than the pre-GPT‑5 era. Put simply: our tool is now back to its prior helpfulness level, while still finding as many real issues as GPT-5.

Two product levers helped with this:

1. We created severity and review type tags, front and center

   • Review Types: We created review types to allow users to self-select what kinds of comments they wanted to read including: ⚠️ Potential issue, 🛠️ Refactor suggestion, 🧹 Nitpick (nitpicks are hidden unless you opt into Assertive mode)

   • Severity: We now tag comments by severity to better signal which matter more than others. Our tags are: 🔴 Critical, 🟠 Major, 🟡 Minor, 🔵 Trivial, ⚪ Info

   • We always show bugs (Critical, Major, Minor) but don’t always show other types of comments. Refactors show only if the model marks them as essential. Users who want everything can still switch to Assertive mode.

2. We implemented stricter filtering and aggregation

   • We collapse duplicative notes and filter out “nice to have” suggestions unless they have clear ROI for the user. The result: fewer, denser comments, and fewer reasons to tune out.

Latency: Fast matters & Codex is faster

A five minute review is fine. Thirty minutes is not. GPT‑5’s “always think hard” style significantly increased time to first token and overall review time. But we shipped several pipeline optimizations recently and Codex helps further reduce the latency that GPT-5 introduced.

Codex’s variable or elastic thinking uses less depth when it is not needed, improving time to first output and end-to-end review time in practice. Net: faster reviews, earlier feedback, better flow for the human in the loop.

What a CodeRabbit user should expect

Now that Codex is implemented, how will that change your AI code reviews?

1. The same raw bug finding power

   • On the refreshed hard 25, Codex passed 64% at the EP level vs. 60% for GPT‑5 (our previous set of PRs had GPT-5 passing 77.3%). No loss of the important wins GPT-5 helped with.

2. Fewer but stronger comments

   • About 32% fewer total comments than GPT‑5, with about 35% higher SNR (per comment precision). More patches, less prose.

3. Severity tags to focus your review

   • Critical and Major issues float to the top with our new severity tags. Refactors are gated. Nitpicks are opt-in. You will spend less time scanning comments and more time fixing.

4. A faster feedback loop

   • Codex’s leaner reasoning plus pipeline improvements bring time to first helpful comment down. You will feel it.

Quantitative appendix (for the curious)

We know you love data! Here’s some other stats we found interesting:

• Per comment precision (SNR) uplift: Codex 46.3% vs. GPT‑5 34.2% — about +35% relative.

• Comment volume delta: Codex 54 vs. GPT‑5 79 — 32% fewer comments, with EP passes essentially unchanged (16 vs. 15).

• Style: Codex includes diffs in 94% of comments and uses hedging far less than Claude and GPT‑5 on this set.

• Acceptance (real world): During GPT‑5 rollout, acceptance dropped significantly. With Codex plus changes, it rose by about 20–25% relative and returned to prior levels while still delivering more accepted comments than pre GPT‑5.

Where Codex still needs work (and what we are doing)

These improvements are great but that doesn’t mean that there aren’t still issues with Codex. Here are some that we are actively working on:

• Coverage gaps. When a model leaves no comment on a PR, that is a hard fail for that EP. We are widening Codex’s search heuristics so it is less likely to miss entire classes of issues.

• Refactor over eagerness (tuned, not solved). The “essential only” gate curbs refactor noise, but we will keep tightening the threshold, especially on large diffs where a high number of comments would be overwhelming.

• User driven prioritization. We cannot change GitHub’s in-line ordering, but we annotate every comment with severity so you can triage from the top down without hunting.

Codex GPT-5: All of the great bug catching ability, fewer downsides

Our north star is simple: catch the bugs that matter, quickly, without making you sift through noise. Codex helps us do that. It keeps the bite of GPT‑5’s reasoning while restoring SNR and shaving latency down significantly. We will keep measuring, improving, and shipping a better product every release.

Last week, we announced CodeRabbit’s $60 million Series B. To celebrate, we did what any responsible, developer-focused software company would do: we made a funny video.

Not with all the money, to be clear. But we did decide to celebrate with something fun, absurd, and painfully relatable for any dev team trying to keep up with the flood of AI-generated PRs.

Introducing… “When AI coding agents backfire: A short film”

It’s a short mockumentary-meets-sitcom about what really happens when “AI velocity” turns into a PR review backlog.

• One reviewer.

• Dozens of notifications.

• 84 open PRs.

• And one overly eager coworker named Brad who just wants feedback.

The cast

To bring it to life, we pulled in beloved developer educator (and influencer) Aaron Francis to star as our beleaguered reviewer. He’s the guy who just wanted to ship features faster and now can’t go to the kitchen (or even leave his house at 8 a.m.) without Brad asking about his PR.

And speaking of Brad: the inimitable Austin von Johnson plays him to perfection. Brad’s a developer who can crank out AI-generated PRs at lightning speed but cannot, under any circumstances, wait patiently for a review. His lurking, his post-its, his hoodie PR ambushes… let’s just say he was perfectly committed to the bit.

The very real problem behind the joke

The short film is funny, but the problem it highlights is real:

• AI coding tools crank out code faster than teams can review it

• Review backlogs balloon while productivity drops

• Senior engineers get buried in endless PRs

• Review quality is uneven, risk goes up, and you have to deal with more issues

• And suddenly, the promise of velocity feels more like a nightmare.

Here’s what we’re doing about it

CodeRabbit exists to clear the backlog, not add to it. Our AI code reviews pull in dozens of points of context (requirements, tests, CI, past diffs, ownership) to catch bugs you’d miss, reduce reviewer fatigue, and move PRs through faster—without turning teammates into… Brad.

Ship faster, review smarter, and keep your sanity. Also, avoid creating a… Brad.

👉 Watch “When AI coding agents backfire: a short film” right here. And if you’ve ever been chased around the office about a PR, please, send it to your team’s Brad.

Ballooning context in the MCP era: Context engineering on steroids意訳です。

かつて、LLMにコンテキストを渡すには、ハックやベクターストラテジー、そしてお祈り…と、過剰に複雑なRAGパイプラインをつなぎ合わせる必要がありました。そこに登場したのが Model Context Protocol (MCP)。外部データを本番環境のモデルに提供するための、クリーンでモジュール的手法です。MCPは、実際に「何かをする」エージェントシステムを構築する人々にとって、瞬く間に標準的なプロトコルとなりました。

今ではほとんどのテック企業がMCP機能を打ち出していますが、その理由は明白です。MCPはコンテキストのロジックとアプリケーションロジックを分離し、信頼性を向上させ、複雑なワークフローでのプロンプト構築の混乱を抑える役割を果たします。

私たちはしばらく前からコンテキストエンジニアリングの領域に深く取り組んでおり、今回独自のMCPクライアントを立ち上げるにあたり、コードレビューにより豊かなコンテキストを注入できることに大いに期待しています。しかし正直に言えば、豊富なコンテキストにはリスクも伴います。MCP時代の隠された真実はこうです：かつて欲していたコンテキストに、今や私たちは溺れそうである。ログやトレース、diffなど "関連"ファイルが増え、モデルが本当に必要としているものが見えにくくなっています。

役立つ入力はすぐにトークンの膨張、ノイズ、パフォーマンス劣化につながります。引用付きハルシネーション、レイテンシの急上昇、あるいはカフェインを摂りすぎたインターンが書いたような散漫なレビュー。良いコンテキストエンジニアリングとは「すべて詰め込む」ことではなく、「何を省くか」を知ることでもあります。そしてMCP以降、そのバランスを取るのはより難しく、より重要になっています。

この記事では、膨張するコンテキスト問題 の詳細、その副作用、そして私たちがそれにどう立ち向かっているかを解説します。MCPを用いたLLM機能を開発している方で、プロンプト形のブラックホールを作り出したくない方に役立つ内容です。

MCPクライアント & サーバーにおける「膨張するコンテキスト問題」

MCPサーバーとクライアントは、モデルに膨大な情報を渡すことを容易にします：ログ、トレース、diff、設定、チケット、さらには誰も所有を覚えていないリポジトリの隅まで。すべてがモデルの手の届くところにあります。しかし、ここで重要な問いがあります：「コンテキストが多ければ多いほど良いのか？」 答えは間違いなく「NO」です。

過剰なコンテキストは、試験勉強で図書館全体を読むようなもの。ノイズは増えても、知識にはなりません。コンテキストが制御されなければ、次の3つの問題がすぐに現れます：

• トークンの膨張
  LLMには無限のキャパシティはありません。入力ウィンドウにはコストと限界があり、念のため…と詳細情報を詰め込みすぎれば、コストは増大してスループットは低下し、不要なテキストに予算を浪費します。

• 関連性の低下
  情報が多いほど出力が良くなるわけではありません。むしろ悪化することが多いのです。無関係または冗長なスニペットがシグナルを希釈し、モデルはインサイトではなく枝葉に追われます。

• レイテンシ
  追加されるログやdiff、スタックトレースはすべて取得・処理され、プロンプトに押し込まれます。コンテキスト構築がボトルネックとなり、レビュー速度を著しく低下させます。

要するに、膨張するコンテキストはMCPの優雅さを逆にリスクへと変えてしまいます。意図的なコンテキストエンジニアリングがなければ、出力を磨くどころか押しつぶしてしまうのです。

コンテキストが害になるとき

実際には、以下の3つの典型的な問題が発生します：

• コンテキスト混乱
  モデルが無関係な詳細をシグナルと誤解してしまうケース。例えば認証ロジックを更新するPRに、無関係なテストフィクスチャが含まれていると、モデルはフィクスチャをレビューし始め、実際の変更と関係のないコメントを生成します。

• コンテキスト衝突
  コンテキスト同士が矛盾する場合です。例えば最新のスキーママイグレーションと古いドックストリングが同時に含まれると、モデルはどちらを信じるべきか迷い、結果として全方位的で自信のないレビューを生成します。まるで決断できないレビュアーのように。

• コンテキスト汚染
  最も厄介なのは誤った情報が混入するケースです。無用な関連ファイルや、誤ってインデックス化されたスニペットが注入されると、存在しないコードを引用するようになります。レビューでは、存在しないファイルのバグに言及し、開発者を混乱させ、時間を無駄にし、信頼を損ないます。

これはコードレビューに限りません。サポートボットが無関係なチケットを引っ張ってくる場合や、リサーチアシスタントが周辺論文に気を取られる場合、セキュリティエージェントがノイジーなログを証拠として扱う場合なども同様です。いずれにしても、間違ったコンテキストは「ない方がまし」なのです。

MCPサーバーでのコンテキスト過負荷を防ぐ主要パターン

MCP時代の問題が、膨張するコンテキストだとすれば、解決策は情報の流入を止めることではありません。意図を持って選別・圧縮・提供することです。MCPのコンテキストは、生の素材をモデルに渡す前にきちんと設計されたデータ変換プロセスを経るべきものです。私たち自身のコードレビュー用MCPクライアントでも、コンテキストを高シグナル・低ノイズに保つために以下のパターンを採用しています。

• コンテキストの重複排除と差分化
  冗長な入力はトークン浪費の最短ルートです。同一のスタックトレース、繰り返しのログ、変更されていないdiff部分は10回も登場する必要はありません。クライアントは重複を検出して折りたたみ、新しい部分だけを強調します。この原則は他の領域にも適用可能です：重複するサポートチケットをまとめ、繰り返しのトレースを圧縮し、差分のみを残します。

• コンテキスト要約パイプライン
  MCP出力が依然として大きすぎる場合、LLM自体が要約して小さくすることも可能です。代償は圧縮と忠実度のトレードオフ：要約はニュアンスを失う可能性がありますが、詳細に溺れるよりはましです。実際には、重要ファイルは生のdiff、優先度の低いコンテキストは要約といったハイブリッド設計を採用します。

• コンテキストの優先順位付けと切り捨て
  プルーニングや要約後でも、どれを最初に入れ、後に回し、容量不足時に捨てるかを決める必要があります。MCPクエリごとにトークン予算を設定することは不可欠です。そうしなければプロンプトが予測不能に膨張します。私たちは切り捨てを前提にした設計を試し、場合によっては概要を先頭に、詳細を後半に配置するなど調整しています。

• コンテキストの隔離
  すべてのコンテキストを最初のプロンプトに含める必要はありません。サブタスクごとに専用のコンテキストスレッドを持たせるべきです。例えば、私たちのMCPクライアントではテスト失敗は専用のレビューサブスレッドに置かれ、メインのレビューコンテキストを妨げません。これにより混乱を減らし、長い対話でも明瞭さを保てます。

• 継続的な改善と学習
  コンテキストエンジニアリングは静的ではありません。モデルのフィードバックや人間による修正を取り入れ、優先順位を調整していきます。重要なのは可観測性です。モジュールごとにプロンプト入力を記録し、何が通って何が無駄かを把握します。MCPダッシュボードやトークンヒートマップのようなツールが、予算超過や不要な入力を可視化します。

MCPサーバー & クライアントにおけるアンチパターン

MCP時代はコンテキスト取得を容易にしました。おそらく「容易すぎる」ほどに。以下のようなアンチパターンがよく見られます：

• ベクトル無差別投入
  ベクトルDBは「関連」情報を見つけるのに優れていますが、それを万能の答えと見なすのは危険です。曖昧に関連するスニペットをすべて投入すると、関係のないファイルへのコメントや古いコードへの指摘で溢れるレビューになります。コンテキストの不適合はトークンの無駄だけでなく、モデルのパフォーマンスを引き下げる要因になります。

• 「全部突っ込め」方式
  すべてのログ、diff、ドックストリングをコンテキストに放り込み、あとは神に祈るやり方です。コストの増加、レイテンシの悪化、結果の予測不能を保証します。モデルは重要な部分と不要な部分を区別できないため、全方位的で散漫なレビューを生成します。矛盾が混入すれば、モデルは曖昧さを埋めるために幻覚を引き起こします。

要するに、コンテキストは多ければ良いというものではありません。フィルタリング、優先順位付け、設計がなければ、「情報全部」はすぐにノイズに変わり、システムを遅く、鈍く、高コストにしてしまいます。

私たちのMCPクライアントでのアプローチ

MCP時代において、コンテキストは「王様」です。しかし正直なところ、その王様は酔いすぎて上下も分からなくなっていることがあります。課題はもはや「コンテキストを得ること」ではなく、「それを制御すること」です。優れたコンテキストエンジニアリングには、緻密な変換パイプライン、徹底的な優先順位付け、そして改善を続ける謙虚さが必要です。これを怠れば、トークン膨張、レイテンシ、混乱したレビューを招きます。うまく実践すれば、ワークフローに沿った鋭い出力が得られます。

私たちは自社のコードレビュー用MCPクライアントでこれを実感しました。初期段階では全ログ・全ファイルをそのまま渡していました。その結果は高コストで、役に立たないほど散漫なレビューです。そこで重複排除、要約、タスク専用の隔離を導入したところ、レビュー品質が飛躍的に向上しました。すべてを指摘するのではなく、本当のクロスファイルリスクに集中するようになり、トークン消費とレイテンシも低下しました。

これこそが良いコンテキストエンジニアリングの成果です：情報量が多いのに散漫ではなく、本質を突いたレビュー。そしてそれこそが、私たちのMCPクライアントで実現しようとしていることです。

👉 コンテキスト設計の正しい姿を体験してみませんか？ 今すぐ 14日間の無料トライアル でAIコードレビューをお試しください。

CodeRabbit commits $1 million to open source softwareの意訳です。

オープンソースは現代のソフトウェア開発の基盤です。パッケージマネージャーや開発ツールから、フレームワーク、インフラに至るまで、今日私たちが使うほとんどすべてのソフトウェアはオープンソースプロジェクトによって支えられています。CodeRabbit自体もそうです。これらのプロジェクトは、数え切れないほどの時間を費やし、維持・進化させ続けている開発者コミュニティによって構築・保守されています。

本日、私たちは オープンソースソフトウェアへのスポンサーシップとして100万ドル（USD）の拠出 を発表します。これは 6,000万ドルのシリーズB資金調達 に続くものであり、オープンソースが可能にしてくれたことへの感謝、そしてその未来への投資の重要性に対する私たちの信念を表しています。

なぜ今、オープンソースへの支援がこれまで以上に必要なのか

生成AIはソフトウェア開発を変革していますが、同時にオープンソースのメンテナーに新たな負荷を与えています。高品質なコントリビューションの増加と並行して、AI生成によるPRスパム（繰り返し・低品質・時には不安定なコードの提出）が急増し、メンテナーを圧倒しています。

私たちはメンテナー自身から、この膨大なノイズがどれほど負担となっているかを直接聞いてきました。CodeRabbitでは、スパムをフィルタリングし、コード品質を向上させ、メンテナーの作業負荷を軽減する AI駆動のコードレビューと人間による監視を組み合わせたツールを開発しました。私たちはこのAIコードレビューツールをすべてのオープンソースプロジェクトに無料で提供しています（詳細はこちら）。

しかし、ツールだけでは十分ではありません。持続可能なオープンソースには、金銭的支援、認知、そしてコミュニティ間をつなぐ強固な架け橋が必要です。

20万ドルから100万ドル：より深いコミットメントへ

今年初め、私たちは オープンソースへの20万ドルの誓約 を発表し、以下のようなプロジェクトを支援しました：

• pnpm: ディスクスペース効率に優れたパッケージマネージャー

• Biome (biomejs): 次世代のJavaScript/TypeScript用リンター兼フォーマッター

• AST Grep (Herrington Darkholme): 構造的コード検索によるスマートなコード解析

• iTerm2 (George Nachman): 開発者のワークフローを刷新したターミナルエミュレーター

• Markdown Lint (David Anson): ドキュメントを明確かつ一貫性のある状態に保つツール

この誓約は始まりにすぎません。今回のシリーズB資金調達によって、私たちは支援額を 100万ドルに拡大 し、エコシステム全体のプロジェクトやメンテナーが正当な評価とリソースを得られるようにします。

スポンサーシップ申請はこちらより行ってください

CodeRabbitとOSS：エコシステム全体をつなぐ架け橋へ

スポンサーシップは始まりに過ぎません。オープンソースが直面している多くの課題 ― 持続可能性、セキュリティ、開発者の燃え尽き（バーンアウト） ― は特定のプロジェクトに限られた問題ではありません。これらはコミュニティやエコシステム全体に広がっています。

だからこそ、CodeRabbitは メンテナー同士をつなぎ、協力を促進し、プロジェクト間で解決策を共有する 取り組みにも力を入れています。共同スポンサーシップ、共同イニシアチブ、コミュニティ主導のツールに関する議論を通じて、孤立した支援ではなく、エコシステム全体を強化することを目指しています。

もしあなたがメンテナーやコントリビューターで、こうした議論に参加したいと考えているなら、ぜひご連絡ください。CodeRabbitチームや他のオープンソースリーダーとつながるためにDiscordに参加してください。

オープンソースプロジェクト向けの無料CodeRabbit利用

最後に改めてお伝えします：CodeRabbitはオープンソースに対して、無料で提供されています。すべてのメンテナー、コントリビューター、コミュニティは、私たちのプラットフォームを利用してPRノイズを減らし、コード品質チェックを自動化し、より意味のあるコントリビュートに時間を割けるようになります。

詳細はこちらから確認し 資金提供の申請を行ってください

Open source is the foundation of modern software development. From package managers and developer tools to frameworks and infrastructure, open source projects power nearly every piece of software we use today – including CodeRabbit itself. These projects are built and maintained by communities of developers who dedicate countless hours to keeping them alive, secure, and evolving.

Today, we’re proud to announce a $1 million USD commitment to open source software sponsorships. This commitment comes on the heels of our $60 million Series B funding round and it reflects both our gratitude for what open source makes possible and our belief in the importance of investing in its future.

Why open source needs support now more than ever

Generative AI is transforming software development, but it’s also putting new pressures on open source maintainers. Alongside the surge of high-quality contributions, there has been a sharp rise in AI-generated PR spam: repetitive, low-quality, and sometimes insecure code submissions that overwhelm project maintainers.

We’ve heard firsthand from maintainers about how draining this flood of noise can be. At CodeRabbit, we’ve built tools that filter out spam, elevate code quality, and reduce maintainer workload by blending AI-driven code review with human oversight. We’ve made our AI code review tool free for use on all open source projects (more about that here).

But tools alone aren’t enough—sustainable open source requires financial support, recognition, and stronger bridges between communities.

From $200K to $1M: Deepening our commitment

Earlier this year, we announced a $200,000 pledge to open source, supporting projects like:

• pnpm: A disk-space–efficient package manager

• Biome (biomejs): A next-generation linter and formatter for JavaScript and TypeScript

• AST Grep (Herrington Darkholme): Structural code search for smarter code analysis

• iTerm2 (George Nachman): A terminal emulator that redefined developer workflow

• Markdown Lint (David Anson): Ensuring docs stay clear and consistent

That pledge was only the beginning. With our new Series B funding, we’re scaling our support to $1 million, ensuring that more projects and maintainers across the ecosystem receive the recognition and resources they deserve.

Apply for sponsorship here.

CodeRabbit & OSS: Building bridges across the OSS ecosystem

Sponsorship is only part of the story. Many of the challenges open source faces—sustainability, security, and developer burnout—aren’t isolated to a single project. They stretch across communities and ecosystems.

That’s why CodeRabbit is also working to connect maintainers, foster collaboration, and share solutions across projects. Whether through joint sponsorships, shared initiatives, or community-driven tooling conversations, we aim to strengthen the ecosystem as a whole rather than supporting it in silos.

If you’re a maintainer or contributor who wants to join these conversations, we’d love to hear from you. Join our Discord to connect with the CodeRabbit team and other open source leaders.

Free CodeRabbit access for open source projects

Finally, a reminder: CodeRabbit is free for open source. Every maintainer, contributor, and community can use our platform to cut through PR noise, automate code quality checks, and free up more time for meaningful contributions.

Learn more and apply for funding here.

Every dev team knows the pain of code reviews if performed in isolation. An AI tool (or even a teammate) can comment on syntax, style, and patterns, but without business requirements, deployment dependencies, or organizational knowledge, it’s just guessing at half the story.

CodeRabbit currently has a number of native integrations including Linear, Jira, and Circle CI. We have seen the value that context from those tools provide to code reviews. That’s why we’re excited to announce the GA of CodeRabbit’s integration with MCP servers. This will allow you to bring in even more context into your reviews.

With this launch, we become the first AI code review platform that orchestrates context from across your entire development ecosystem from business requirements in Confluence to system dependencies in your CI/CD pipeline to data from any internal MCP servers. All to provide code reviews that actually understand what your code is trying to accomplish.

Start your 14-day trial → Get context-aware reviews that reference your actual team standards in ~10 minutes.

Why MCP for AI code reviews?

Development teams operate across dozens of tools:

• Requirements live in Linear

• Design specifications exist in Figma

• Architectural decisions get documented in Confluence

• Security standards evolve in internal wikis after each audit

AI code reviewers start with basic context: your codebase, some coding guidelines, maybe a few integrations. They analyze syntax, check patterns, and suggest improvements. But they miss the context that determines whether code actually works for your team.

As a MCP client, CodeRabbit acts as a compiler for organizational context. It takes high-level inputs - your wikis, tickets, deployment patterns - and compiles them down into precise, actionable code review insights. Instead of bloated integrations or brittle hacks, MCP lets clients like CodeRabbit pull in just the right data from your MCP servers from places like your Linear tickets, Confluence docs, Datadog metrics, or Slack discussions.

What it looks like in practice…

CodeRabbit searches connected MCP servers before starting a review. For example, database schema changes might get checked against data architecture documents. API endpoint implementations might get verified against service design patterns documented in internal wikis.

Example: CodeRabbit verifies code consistence

Bring in the context matters to you… from any tool

Traditional code review tools require specific integrations. CodeRabbit's MCP integration works with any system with an MCP server. Your proprietary internal tools, boutique SaaS platforms, custom documentation systems. If there's an MCP server, CodeRabbit can connect.

With CodeRabbit as an MCP client, you’re reviews gain depth from bringing in three different types of context.

Technical context.

• Think dependencies, performance data, static analysis, and test coverage.

• Native integrations: GitHub Actions, GitLab CI, Bitbucket Pipelines

• MCP Servers: Datadog, New Relic, SonarQube, Snyk, Grafana

• Example Review Comment:

Business context.

• This includes things like requirements, user stories, and acceptance criteria.

• Native integrations: Linear, Jira, GitHub Issues, GitLab Issues

• MCP Servers: Confluence, Notion

• Example Review Comment:

Organizational context.

• We also pull in things like prior decisions, conventions, meeting notes, and institutional knowledge.

• Native integrations: PR history, Team conventions

• MCP Servers: Slack, Microsoft Teams, Stack Overflow for Teams, PagerDuty

• Example Review Comment:

  

Getting started with MCP integration

Setting up CodeRabbit's MCP client requires minimal configuration. Most development teams can connect their first MCP server in under 10 minutes.

Popular development tools with MCP server support:

• Linear (native MCP support, 5 minutes)

• Notion (MCP server available, 10 minutes)

• Confluence (community MCP server, 15 minutes)

• Figma (MCP plugin available, 10 minutes)

Define which code changes should search which development systems. Database changes check architecture documentation. Authentication changes check security documentation.

Adding an MCP server is easy:

1. In the CodeRabbit dashboard, head over to integrations > and toggle to the MCP Servers tab if needed

   

2. You can click on one of the pre-configured MCP server options or the New MCP Server button to add other MCP servers.

   

3. For MCP servers not on the list, enter the relevant credentials.

4. Note the usage guidance which serves as context for how the MCP information should be used.

   

5. Once connected. You can see the available calls and hover over them to see more details.

   

6. You can also click on each call to enable/disable access.

   

A review platform that brings in all your context

CodeRabbit works out of the box with 50+ integrations. With MCP, you can extend it to your custom servers and internal tools. Start with the systems you already use — Linear, Confluence, Datadog, Slack — and add more as you go.

Next steps:

1. Start a 14-day trial

2. View MCP server directory

3. See the MCP docs

Once upon a time, getting context into an LLM meant stringing together hacks, prayers, vector strategies, and overly complex RAG pipelines. Then came the Model Context Protocol (MCP), a clean, modular way to serve external data to models in production. It quickly became the protocol of choice for anyone building agentic systems that are trying to actually do things.

Every tech company is now launching MCP functionalities – and for good reason. MCP separates context logic from application logic, improves reliability, and helps tame the chaos of prompt construction in complex workflows.

We’ve been deep in the context engineering space for a while, and as we launch our own MCP client, we’re genuinely excited by how it lets us inject richer context into our code reviews. But let’s be honest: with great context comes great risk. Because here’s the dirty secret of the MCP era: most of us are now drowning in the context we used to beg for. More logs, more traces, more diffs, more "relevant" files and way less clarity about what the model actually needs.

What starts as helpful input quickly turns into token bloat, noise, and degradation in model performance. Think hallucinations with citations, latency spikes, or reviews that read like they were written by an over-caffeinated intern who rambles. Good context engineering isn’t about cramming in everything, it’s also about knowing what to leave out. And in the aftermath of MCP, that balance is harder (and more important) than ever.

In this article, we’ll break down the ballooning context problem, what happens when well-intentioned context goes rogue, and how we’re tackling it head-on. If you’re shipping LLM-based features with MCP and want to avoid accidentally building a prompt-shaped black hole, this blog is for you.

The “Ballooning Context Problem” with MCP clients & servers

MCP servers and clients make it easy to hand models a firehose of information: logs, traces, diffs, configs, tickets, and sometimes even that dusty corner of the repo nobody remembers owning. It’s all right there at the model’s fingertips. But here’s the question: is more context always better? Definitely not!

Too much context is like cramming for an exam by reading the entire library. You end up with noise, not knowledge. And when context goes unchecked, three problems show up fast:

• Token bloat. LLMs don’t have infinite stomachs. Input windows are expensive and finite, and stuffing them full of “just in case” details means higher costs, slower throughput, and wasted budget on irrelevant text.

• Relevance decay. More information doesn’t mean better outputs. In fact, it often means worse. Irrelevant or redundant snippets dilute the signal, and the model starts chasing tangents instead of insights.

• Latency. Every extra log, diff, or stack trace has to be fetched, processed, and shoved into the prompt. Context building becomes the bottleneck, dragging review speed down to a crawl.

In short, ballooning context turns the elegance of MCP into a liability. Without deliberate context engineering, the very thing meant to sharpen outputs can just as easily smother them.

When context hurts

In practice, we see three common pathologies:

• Context confusion. This happens when the model latches onto irrelevant detail and treats it as signal. Imagine a pull request that updates authentication logic but the context dump also includes unrelated test fixtures. The model might start reviewing the fixtures instead, producing comments that feel informed but have nothing to do with the actual change.

• Context clash. Not all context agrees with itself. Suppose a code review includes both the latest schema migration and an outdated docstring that contradicts it. The model now has to “choose” which source to trust. Often, it hedges, producing muddled reviews that cover every angle without real confidence: the LLM equivalent of a reviewer who can’t commit.

• Context poisoning. The most insidious case is when bad information makes it into the context. A hallucinated “related file” or a mis-indexed snippet gets injected, and suddenly the model is citing non-existent code. In a review, that looks like a comment about a bug in a file that doesn’t exist, confusing developers, wasting time, and eroding trust.

And it’s not just code reviews. The same pitfalls show up anywhere context gets overstuffed: customer support bots pulling in irrelevant tickets, research assistants distracted by tangential papers, or security agents treating noisy logs as hard evidence. In each case, the wrong context is worse than no context at all.

Key patterns to combat context overload with MCP servers

If the problem of the MCP era is ballooning context, the solution isn’t to stop piping in information — it’s to curate, compress, and serve it with intent. MCP context should be treated as raw material that goes through a well-designed data transformation process before it ever reaches the model. For our own MCP client for code reviews, we’ve leaned on a set of patterns that keep context high-signal and low-noise.

• Context deduplication and differencing
  Redundant inputs are the fastest way to waste tokens. Identical stack traces, repeated log lines, or unchanged sections of a diff don’t need to appear ten times. Our client identifies duplicates, collapses them, and highlights only what’s new. The same principle applies in other domains: collapse duplicate customer tickets, compress recurring traces, and reduce context to delta rather than bulk.

• Context summarization pipelines
  Sometimes raw MCP output is still too big. Here, LLMs themselves can help by summarizing retrieved context into something smaller. The tradeoff is compression vs. fidelity: a summary might miss nuance, but the alternative is a model drowning in detail. In practice, we use hybrid designs: raw diffs for high-priority files, summaries for less-critical context.

• Context prioritization and truncation
  Even after pruning and summarizing, you still need to decide what goes first, what can be deferred, and what gets dropped if there isn’t room. Setting a token budget per MCP query is critical, or else prompts will balloon unpredictably. We’ve experimented with truncation-aware designs; sometimes front-loading summaries for quick orientation, other times end-loading detail for deep dives. The “right” design depends on the workflow and the model’s feedback loop.

• Context quarantining
  Not every piece of context belongs in the first prompt. Subtasks should carry their own dedicated context threads, so the model sees exactly what it needs when it needs it. For example, in our MCP client, test failures live in a dedicated review sub-thread rather than clogging the main review context. This approach reduces confusion and helps preserve clarity across long interactions.

• Iteration and learning
  Context engineering isn’t static. We use model feedback and human-in-the-loop corrections to tune priorities over time. Observability is key: logging actual prompt inputs, broken down per module, lets us see what’s getting through and what’s wasted. Tooling like MCP dashboards or token heatmaps can highlight where budgets are blown or irrelevant inputs are sneaking in.

Anti-patterns to avoid with MCP servers & clients

The MCP era makes context retrieval easy. Maybe too easy. A couple of common anti-patterns are worth calling out:

• Blind vector stuffing
  Vector databases are great at surfacing “relevant” chunks of information, but treating them as an oracle is a recipe for trouble. Stuffing in every vaguely related snippet means you get reviews full of tangents: comments about files that weren’t touched, or nitpicks based on stale code. Context irrelevance doesn’t just waste tokens — it actively drags down model performance by pulling attention away from the real task.

• “Just give it everything”
  The brute-force approach: dump every log, diff, and docstring into the context window and pray. This guarantees high costs, long latencies, and unpredictable results. The model can’t tell which parts are critical and which are fluff, so you end up with bloated reviews that read like they were written by an overeager intern trying to cover every angle. Worse, when contradictions sneak in, the model hedges or hallucinates to reconcile them.

In short: more context isn’t always better. Without filtering, prioritization, and careful design, “everything” quickly turns into noise that makes the system slower, dumber, and more expensive.

The approach we took with our MCP client

In the MCP era, context is king. But let’s be honest: sometimes it’s a king that’s had one too many and can’t tell up from down. The challenge isn’t getting context anymore; it’s taming it. Great context engineering requires careful transformation pipelines, ruthless prioritization, and the humility to keep iterating. Done poorly, you get token bloat, latency, and reviews that sound confused. Done well, you get sharper outputs that scale with your workflow.

We’ve seen this firsthand in our own MCP client for code reviews. When testing, we initially passed full logs and entire file sets straight through. The result? Expensive reviews that rambled more than they helped. Once we introduced deduplication, summarization, and task-specific quarantining, review quality jumped. Instead of commenting on everything, the model zeroed in on real cross-file risks, while token use and latency both dropped.

That’s the payoff of good context engineering: reviews that feel informed, not bloated. And that’s what we’re building toward with our MCP client.

👉 Ready to see context done right? Start your 14-day trial of our AI code reviews.

CodeRabbit CLI - Free AI code reviews in your CLIの意訳です。

CodeRabbitは、PRにおけるAIコードレビューから始まりました。5月には、そのインテリジェンスをVS Code、Cursor、Windsurfに拡張。そして今、開発者に愛されるAIコードレビューをコマンドラインにまで広げる「CodeRabbit CLI」を発表します。つまり、私たちは最も包括的なAIコードレビューツールになったのです。あなたが働く場所なら、どこでも動作します。

CodeRabbit CLIは、開発者がターミナルで直接セルフレビューを行えるようにします。自動化されたインテリジェントなコード分析機能を提供し、問題の早期発見と一貫したコード規約を維持し、CLI内でAIコーディングエージェントとシームレスな統合によって自律的なコーディングを実現します。

コードの「Vibeチェック」― CLIでも

CodeRabbit CLIは、PRやIDEレビューと同じ包括的な分析を提供し、バグの早期発見に役立ちます。CodeRabbit CLIはレート制限付きで無料利用できますが、Proプランでは制限が大幅に緩和され、さらに以下のような追加機能を利用できます。

• コンテキスト対応分析: Git連携を活用し、静的解析ツールやセキュリティスキャナ、コードグラフの関係性機能など40以上の情報源を統合して、最も包括的なレビューを実現

• プレコミットレビュー: マシンを離れる前に変更を分析し、多層的なレビューを提供

• ワンクリック修正: 簡単な修正は即適用、複雑な問題はAIエージェントに完全なコンテキスト付きで引き渡し

• コーディング規約検出: agent.md、claude.md、Cursor rulesなどのコーディングエージェント設定ファイルを自動検出

CodeRabbit CLI: どこでも、なんでも動作

ターミナルネイティブであるため、CodeRabbit CLIは以下に対応します。

• あらゆるターミナルアプリ/IDE: iTerm2、Ghostty、Neovim、Lazyvim

• あらゆるAIコーディングCLIエージェント: Claude Code、Codex、Cursor、Gemini、OpenCodeなど

AIコーディングエージェントCLIとの使い方

CodeRabbit CLIはAIコーディングエージェントとの新しい統合の可能性を広げます。Claude Codeとの動作例は以下の通りです。

1. コーディングタスクを進める際、Claude CodeにCodeRabbitを使って発見された問題を修正するよう促すことができます。PRDやタスクリストからコーディングする場合に特に便利です。

仕様書のフェーズ7.3を実施し、その後に `coderabbit --prompt-only`を実行してください。
必要なだけバックグラウンドにて実行し、発生した問題を修正してください。

2. Claude Codeはコーディングタスクを進めながら、バックグラウンドでcoderabbit --prompt-onlyを実行します。タイマーを設定してCodeRabbitを定期的に確認する場合もあります。あるいは、ClaudeにCodeRabbitの完了を確認するよう促すこともできます。

3. その後、Claude CodeはCodeRabbitの出力を読み込みます。--prompt-onlyフラグを使うことで、AIエージェントが読み取れるプレーンテキストで出力されます。ClaudeはCodeRabbitが検出した問題ごとにタスクリストを作成します。

Claude Codeとの統合や自動化ワークフローについては、CLIドキュメントをご覧ください。

CLIにはインタラクティブモードとプレーンレスポンスモードの2種類があり、自動化ワークフローへの統合や他ツールへの結果の受け渡しが容易です。

はじめ方

CodeRabbit CLIはすでに利用可能です。インストールして最初のレビューを試してみましょう。

# CodeRabbitをインストール
curl -fsSL https://cli.coderabbit.ai/install.sh | sh

# インタラクティブモードでレビュー実行
coderabbit

Raising our $60 million Series B: Quality gates for AI codingの意訳です。

CodeRabbitを立ち上げたとき、そのコンセプトはシンプルでした。すべての開発者がコードレビューを嫌っているのだから、もっと速く、簡単にできるようにすればいいのでは、ということです。変数名やスタイル規約について、同じコメントを何度も書くのは誰にとっても楽しいことではありません。

そこでAIが役立つと考えました。ベストプラクティスのチェックやルールの適用を自動化すれば、開発者自身がやる必要がなくなるのです。そしてさらに重要なのは、AIがセーフティネットとして機能し、本番環境に入る前に問題やバグを検知できることです。

その信念のもと、私たちはAIコードレビューという、まったく新しいものを作ることに挑戦しました。 その後、AIコーディングツールは広く普及し始めました。Copilot、Claude Code、Cursorといったツールは、開発チームが容易にレビューできる以上のコードを生成するようになり、多くの開発者がPR数を2倍から3倍に増やしました。これにより、すでに抱えていたコードレビューのバックログはさらに増加。私たちはすぐに気づきました。「効率化」と宣伝されていたものが、やがてレビューのボトルネックになることを。

そこではじめて理解したのです。AIコードレビューは開発チームにとって極めて重要な存在になると。信頼とガバナンスのレイヤーとして機能し、品質とセキュリティを担保しながら、開発者の時間を節約します。そしてボーナスとして、職場での皮肉混じりのレビューコメントも大幅に減らせるのです。

AIコードレビューが必須となった2025年

過去2年間で、私たちは最も包括的かつコンテキストを重視したコードレビュープラットフォームを構築し、200万のリポジトリに導入され、1,300万件のPRをレビューしました。GitHubとGitLabの両方で最もインストールされたAIアプリとなり、数えきれないほどの開発チームの士気を向上させてきました。

そして2025年、AIコードレビューは、AIコーディングエージェントの普及に伴う課題に直面するすべてのチームにとって必須のものとなっています。この変化は前例のない成長を引き起こし、本日発表した6,000万ドルのシリーズB資金調達につながりました。

今回の投資はScale Venture Partnersが主導し、NVentures（NVIDIAのベンチャーキャピタル部門）が参加。長年の投資家であるCRV、Harmony Partners、Flex Capital、Engineering Capital、Pelion Venture Partnersも支援してくれました。今回の資金調達により、私たちが調達した累計資金は8,800万ドルになりました。

なぜ多くのチームがAIコードレビューを導入しているのか

チームのすべての開発者がコードをより速く生成するようになると、レビュー待ちのキューは指数関数的に増えます。以前は1日5〜10件のPRをレビューしていたシニアエンジニアが、今では20〜30件を抱えています。計算が合いません。チームは2つの悪い選択肢に直面します。デプロイを遅らせて丁寧にレビューするか、レビューを急いで品質を犠牲にするか。

だからこそ、AIコードレビューの導入は加速しています。AIレビュアーは人間のレビュアーを補完し、アーキテクチャの判断やビジネスロジック、AIが完全には理解できない文脈を必要とするフィードバックに集中できるようにします。

この1年は嵐のようでした。売上は10倍になり、チームも倍増しました。その背景には以下の要因があります。

それぞれの顧客の背後には実際のチームがいて、同じことを感じています。つまり、CodeRabbitでレビューが速くなってバグが早期に発見され、リリースサイクルが再び加速しているということです。

Grouponは、レビューから本番リリースまでにかかっていた時間が86時間からわずか39分に短縮されたと報告しました。別の企業は、コードレビューに費やす時間を70％削減できたと共有してくれています。

CodeRabbitの仕組み

CodeRabbitは「AIの炎にAIで立ち向かう」からこそ機能します。多数のコンテキスト情報を取り込み、最も文脈に沿ったレビューを提供します。

• 本番前に正確性やセキュリティの問題を検知

  

• 組織のベストプラクティスや独自ルールの適用

  

• マージサイクル全体をサポート（ユニットテストやdocstring生成など）

調達を祝して：CodeRabbit CLIの発表

本日、シリーズBの発表を記念して、CodeRabbit CLIを発表します。これはターミナル上で動作するAIコードレビューで、Claude Code、Codex CLI、Cursor CLI、GeminiなどのAIコーディングエージェントとシームレスに連携します。

開発者がCLIベースのコーディングエージェントを使ってコードを書くケースが増える中、私たちは大きなギャップを特定しました。コードはかつてない速度で生成されていますが、品質検証が行われるのは遅く、PRの段階になってからということが多いのです。

CodeRabbit CLIはこれを変えます。CLIワークフローに直接インテリジェントなレビューを組み込み、コード生成と品質検証の間にリアルタイムのフィードバックループを作り出します。

モジュールをリファクタリングするようClaude Codeに依頼しても、Cursor CLIで新機能を実装しても、CodeRabbitは即座にその結果をレビューし、ハルシネーション生成を検知し、セキュリティ問題にフラグを立て、AIエージェントに文脈に沿った修正を返すことさえできます。

CodeRabbit CLIは、AI生成コードを本番レベルに引き上げるために欠けていたオーケストレーションレイヤーであり、自律的な開発の実現を可能にします。

今回の資金調達が意味するもの（あなたにとっても）

シリーズBで調達した資金は、私たちが解決すべき課題のスケールに合わせて成長を続けるために使われます。投資先は以下の通りです。

• 製品開発の加速： コンテキスト統合の強化、よりスマートなマージ前チェック、自動テストなど、ロードマップは満載です。レビューをより速く、正確で、有用にすることに集中します。

• オープンソースの支援： 現在、すでに10万以上のOSSプロジェクトがCodeRabbitを利用しています。この資金で、貢献や支援をさらに強化し、現代的な開発を可能にしたコミュニティをサポートします。詳細は今週後半に！

• 優秀な人材の採用： 今年だけで従業員数を倍増させました。今後はエンジニアリング、プロダクト、セールス、マーケティング、カスタマーサクセスの分野でグローバルに採用を進めます。

この資金調達により、私たちが「AI駆動開発における最も重要な欠けているピース」だと信じている、スケーラブルで文脈に対応したレビューを構築し続ける余地が生まれました。

ご支援ありがとうございます

この会社を始めたとき、私たちはすべてのエンジニアが経験する課題に挑戦していることを理解していました。レビューは面倒で、簡単にはスケールしません。その課題にCodeRabbitが今や数千のチームを支援できていることは、謙虚であると同時に大きな力を与えてくれます。

顧客、コミュニティ、投資家の皆さまへ：私たちを信じ、一緒に築いてくださりありがとうございます。そしてこの取り組みにワクワクする方は、ぜひ私たちに加わってください。コードレビューの未来を一緒に作りましょう。

CodeRabbitを無料で試す そして 採用情報はこちら

CodeRabbit started with AI-powered code reviews in pull requests. In May, we brought that same intelligence to VS Code, Cursor, and Windsurf. Now, we're extending the AI code reviews developers love into the command line with CodeRabbit CLI. In case you’re wondering, that makes us the most comprehensive AI code review tool available. We work everywhere you work.

CodeRabbit CLI helps devs perform self-reviews of code directly in their terminal. By providing automated, intelligent code analysis capabilities, it empowers developers to catch issues early, maintain consistent code standards, and make coding autonomous through seamless integration with AI coding agents in the CLI.

Vibe checking your code – now in CLI

CodeRabbit CLI delivers the same comprehensive analysis that makes our PR and IDE reviews effective at catching bugs early. CodeRabbit CLI is free to use with rate limits but with a Pro plan you can enjoy much higher limits and additional features, including:

• Context-aware analysis: Leverages your Git integration to synthesize insights from 40+ sources including static analysis tools, security scanners, and our codegraph relationship feature for the most comprehensive reviews.

• Pre-commit reviews: Analyze changes before they leave your machine for multi-layered reviews.

• One-click fixes: Apply simple fixes instantly or send complex issues to AI agents with full context hand-off.

• Coding guidelines: Auto-detects agent.md, claude.md, Cursor rules, and other coding agent configuration files.

CodeRabbit CLI: Works everywhere, with everything

Terminal-native means CodeRabbit CLI works with:

• Any Terminal App/IDE: iTerm2, Ghostty, Neovim, Lazyvim

• Any AI Coding CLI agent: Claude Code, Codex, Cursor, Gemini, OpenCode and more

How to use CodeRabbit CLI with AI Coding Agent CLI

The CodeRabbit CLI opens up new integration possibilities with AI coding agents. Here's how it works with Claude Code:

1. While working on a coding task, you can prompt Claude Code to use CodeRabbit and to fix any issues it finds. This is particularly useful if it’s coding from a PRD, or a tasklist.

Please implement phase 7.3 of the planning doc and then run coderabbit --prompt-only, let it run as long as it needs (run it in the background) and fix any issues.

2. Claude Code will carry on the coding task and run coderabbit --prompt-only in the background. It may setup a timer interval to check on CodeRabbit. Alternatively, you can also prompt Claude to check if CodeRabbit is complete.

3. Claude Code will then read the output of CodeRabbit which, by using the --prompt-only flag, provides the output as plain text with prompts for AI agents to read. Claude will then create a tasklist addressing each of the issues surfaced by CodeRabbit.

For Claude Code integration and automated workflows, check the CLI documentation for setup.

The CLI has two modes: interactive and plain response , making it easy to integrate into automated workflows or pass results to other tools.

Getting started

CodeRabbit CLI is available now. Install and try your first review:

#install CodeRabbit
curl -fsSL https://cli.coderabbit.ai/install.sh | sh

#Run a review in interactive mode
coderabbit

When we started CodeRabbit, the idea was pretty simple: since all developers hate code reviews, why not make them faster and easier? After all, no one enjoys leaving the same comment about variable naming practices or style conventions for the tenth time in a week.

That’s where we believed AI could help – it could automate best-practice checks and policy enforcement so that devs didn’t have to do it themselves. But more importantly, it could act as a safety net, catching issues and bugs before they made it into production.

With that belief, we set out to create something new: AI code reviews. Over time, AI coding tools started to gain broader adoption. Tools like Copilot, Claude Code, and Cursor began spitting out more code than teams could easily review with many developers increasing the number of PRs they shipped by 2x to 3x. This added to the existing code review backlogs many teams had. We quickly realized that the ‘efficiency’ gains being marketed to engineering teams would swiftly turn into code review bottlenecks.

And that’s also when we first realized how critical AI code reviews would be to development teams. They would function as a trust and governance layer in agentic software development ensuring quality and security while saving devs time. And, as an added bonus, greatly reducing passive aggressive review comments in the workplace!

AI code reviews became essential in 2025

Over the last two years, we’ve built the most comprehensive and context-rich platform for code reviews, been installed on 2 million repos, reviewed 13 million pull requests, become the most installed AI App on both GitHub and GitLab, and improved the morale of countless dev teams.

In 2025, we watched AI code reviews become essential for all teams dealing with the challenges that come with the broad adoption of AI coding agents. But that shift fueled a year of unprecedented growth, culminating in the $60 million Series B round that we announced today.

This investment was led by Scale Venture Partners with participation by NVentures (NVIDIA’s venture capital arm) and support from our long-time investors CRV, Harmony Partners, Flex Capital, Engineering Capital, and Pelion Venture Partners. With this new funding, our total capital raised is now $88 million.

Why so many teams are adopting AI code reviews

When every developer on your team is generating code faster, your review queue grows exponentially. Senior engineers who used to review 5 to 10 PRs a day are now facing 20 to 30. The math doesn't work. Teams are caught between two bad options: either slow down deployment cycles waiting for thorough reviews, or rush reviews and let quality slip.

This is why AI code review adoption is accelerating. AI reviewers augment the human reviewers, freeing them to focus on architecture decisions, business logic, and the nuanced feedback that requires context AI can't fully grasp yet.

The past year has been a whirlwind. We’ve 10x revenue and doubled our team thanks to:

Behind each of those customers are real teams who tell us the same thing: reviews are faster with CodeRabbit, bugs are caught earlier, and release cycles are finally speeding up again.

Groupon told us they went from 86 hours from review-to-production down to just 39 minutes. Another shared that they cut down the time they spend on code reviews by 70%.

How CodeRabbit works

CodeRabbit works because it fights AI fire with AI fire. Our platform brings in dozens of points of context to deliver the most context aware reviews to:

• Catch correctness and security issues before they hit production.

  

• Enforce organizational best practices and custom policies.

  

• Support the full merge cycle with unit testing and docstrings generation.

How we’re celebrating: By announcing CodeRabbit CLI

Today, we're celebrating our Series B by announcing CodeRabbit CLI, AI code reviews that live in your terminal and orchestrate seamlessly with Claude Code, Codex CLI, Cursor CLI, Gemini, and other AI coding agents.

As developers increasingly write code through CLI Coding agents, we've identified a critical gap: code is being generated at unprecedented speeds, but quality validation happens too late, often only at the PR stage.

CodeRabbit CLI changes this by bringing intelligent review directly into the CLI workflow, creating a real-time feedback loop between code generation and validation.

Now, whether you're prompting Claude Code to refactor a module or using Cursor CLI to implement a feature, CodeRabbit instantly reviews the output, catches hallucinations, flags security issues, and even hands contextualized fixes back to your AI agent.

CodeRabbit CLI is the missing orchestration layer that makes AI-generated code production-ready, turning the promise of autonomous development into reality.

What this funding means for us (and for you)

Our Series B round will help us keep pace with the scale of the problem we set out to solve. Here’s where we’re putting that investment:

• Accelerating product development: Our roadmap is packed. From deeper context integrations to smarter pre-merge checks and automated testing, we’re focused on making reviews faster, more accurate, and more useful for every team.

• Supporting open source: Today, more than 100,000 OSS projects already use CodeRabbit. With this funding, we’re doubling down on contributions and support to strengthen the community that made modern development possible. More on that later in the week!

• Hiring the best talent: We’ve already doubled headcount this year and we’re hiring globally across engineering, product, sales, marketing, and customer success.

This funding gives us the space to keep building what we believe is the most important missing piece of AI-powered development: scalable, context-aware reviews.

Thank you for all your support

When we started this company, we knew we were chasing a problem every engineer experiences: reviews are a pain and they don’t scale easily. The fact that CodeRabbit is now helping thousands of teams tackle that problem is both humbling and energizing.

To our customers, community, and investors: thank you for believing in us and building alongside us. And if this work excites you, consider joining us. Come help us build the future of code reviews.

Try CodeRabbit for free yourself and learn more about our open roles.

Ryo HIGASHIGAWAさんは、OSSとして「reviewtask」というレビュー支援ツールを一人で開発されています。このツールは、AIが生成したコードに対して発生する膨大な指摘事項を、効率的かつ正確に管理するために設計されたものです。Ryoさん自身がAIによるコードレビューを日常的に活用し、その運用課題に直面する中で生まれた実践的なプロダクトとなっています。

もともとは、GitHubのレビューコメントをAIで取得し、タスクに変換して管理するというアプローチを試していたものの、精度や手間の問題が大きく、より安定した運用を目指してreviewtaskの開発が始まりました。そんな背景を持つRyo HIGASHIGAWAさんに、reviewtaskとCodeRabbit活用についてお話を伺いました。

reviewtaskの開発体制について

reviewtaskはRyoさんが開発していますが、コード自体はほぼすべてAIによって生成されています。Ryoさん自身は、開発タスクの設計やバグ報告など、プロダクトマネージャーのような立場に徹し、コードを書く作業をAIに委ねています。

Git操作やPull Request、Issue作成などの多くもAIに任せており、自らは開発プロセスの全体像を見ながらプロジェクトを前に進める役割に集中しているとのことです。

コードレビューに関する課題

AIによるコード生成を大量に行う中で、課題となったのがレビュー品質の担保でした。生成されたコードは量が多く、すべてを人の手でレビューするのは現実的ではなく、疲労感とボトルネックを生み出していたそうです。

AIにコードを書かせることで生産性は大きく向上しましたが、その反面、レビューと品質管理にかかる時間と労力が爆発的に増加。最終的には、レビューまでもAIに任せられないかと模索するようになったといいます。

「AIに書かせて自分がレビューしてとやっていると、非常に疲れるなというのが問題感としてありました」

CodeRabbitとの出会い

RyoさんがCodeRabbitに出会ったきっかけは、他のAI開発支援ツールとの比較や試行の中でのことでした。当時はDevinやCursorなどのツールを並行して使用し、ドキュメントやレビューの自動化に取り組んでいたそうです。

AIに仕様を理解させ、それに沿ったレビューやチェックを実現したいという強い思いから、試行錯誤を重ねる中で、CodeRabbitの精度や柔軟性に魅力を感じて導入に至りました。

「レビューの指摘の対応やPRの状況の確認などにも利用できるので非常に柔軟なツールなところが気にいっています」

CodeRabbit導入の決定要因

CodeRabbitを導入する決め手となったのは、レビューの質だけでなく、ツールとの対話ができる点だったといいます。指摘を受けたくないポイントを説明すれば理解してくれる柔軟性や、プロジェクトごとのカスタマイズ性が大きな魅力でした。

また、単にレビューコメントを生成するだけでなく、レビュー後のフローに組み込みやすい点も導入を後押ししたそうです。

「プロダクトの都合上、指摘を入れて欲しくない所は説明すれば学習してくれるのが嬉しいですね」

CodeRabbitの運用状況・効果

現在では、reviewtaskやその他のプロジェクトにおいて、CodeRabbitによるレビューを標準フローとして組み込んでくれています。レビュー品質の維持と同時に、設計やドキュメント作成に集中できる時間が確保され、結果として開発効率が大きく向上しました。

レビュー指摘の管理にはAIツールとの連携や自作ツールを駆使し、指摘をTODO化して確実に対応していくプロセスが構築されています。複数のプロジェクトを同時に進める現在の開発スタイルは、CodeRabbitの存在抜きには成り立たないといいます。

「今はなくてはならないパートナーという感じです」

実務での利用

OSS開発だけでなく、業務での開発プロジェクトにおいてもCodeRabbitを導入し、レビューの効率化を図っています。特にレビューコストの高いチームにとっては、CodeRabbitが先に自動で指摘を洗い出してくれることで、人的リソースの負担が大きく軽減されました。

導入後は、レビューの流れそのものが変わり、指摘が先に潰された状態でレビュワーに渡るため、確認作業の集中と精度向上につながっているとのことです。

「ワークフローが完全に変わった感じがして良い評価が開発メンバーからも上がっています」

CodeRabbitに今後期待したいところ

CodeRabbitへの要望としては、仕様学習の精度向上や、PRやIssueを横断的に管理できる機能の強化が挙げられました。VSCodeとの連携においても、詳細な指摘内容を取得し、IDE上でAIからのフィードバックを直接得られるようになることを期待されています。

さらに、ドキュメントのわかりやすさや機能説明の具体性にも改善の余地があると感じており、ユーザーの立場からnoteなどで情報発信を続けていきたいとの意欲も語ってくださいました。

「本当に素晴らしいプロダクトだと思っているので、ぜひこのすばらしいプロダクトを広めていただければと思っています！」

CodeRabbitは今後もreviewtaskの開発をサポートしていきます！

Our customers trust us with their most valuable asset: their source code. That trust is why security is central to our mission of helping developers ship better code faster.

When there’s a chance to strengthen our security posture, we act quickly and decisively. And when we design new systems, we design them with “security by default” in mind.

We share below the architecture that makes CodeRabbit more resilient, limits the potential impact of any one component, and ensures that the data entrusted to us remains safe under all circumstances.

Overview

Customers install CodeRabbit on their git platforms via the app marketplace. We integrate via webhooks with all popular Git providers such as GitHub, GitLab, Bitbucket & and Azure DevOps. The integration allows us to register webhooks on events such as PR opened, user comment, etc.

Each event is processed in complete isolation. We maintain a secure internal queue that verifies subscriptions, applies rate limits, and ensures that only authorized events are allowed through. Events are handled one at a time, with zero shared state and no assumptions about what came before or after.

This model gives us something incredibly valuable: containment by default. If an attacker were to compromise one event, they would find nothing else to pivot to – no shared memory, no long-lived tokens, no context beyond that single, short-lived process. Every review starts from scratch, runs alone, and ends clean.

Our architecture at a glance

Here’s a high-level look at how our system is structured in our git-based, IDE, and CLI reviews:

This design is focused on limiting an attacker’s potential “blast radius” – or how much damage an attacker can do if they succeed at breaching one component. By isolating secrets, tightly scoping tokens, and strengthening our encryption, we’ve drastically reduced that radius.

Our layered approach

We use these layered strategies:

1. Sandbox

We create a secure sandbox environment for each code review event to clone the codebase in order to read files, pull context from various sources in our knowledge base about your code and to run tools, linters, web search queries & verification checks. Our sandboxed environment only has the short-lived token for that particular repository, but it contains absolutely no other secrets, API keys, or credentials. Even if an attacker were to achieve remote code execution within our sandbox environment or get out of the sandbox and break the sandbox kernel-based isolation mechanism, they would find nothing of value - no environment variables with tokens, no configuration files with secrets.

Internal network access is also blocked from the sandbox. Tools may connect to the internet when required, but they cannot reach CodeRabbit’s internal services.

2. Token Service Separation

To reinforce the isolation of workloads, we have fully embraced a model based on short-lived session tokens rather than long-lived secrets. Instead of passing environment variables or static credentials, every process is scoped with query or event-specific tokens. These git provider tokens are valid only for the duration of the event or process. These are customer-specific, short-lived tokens. These tokens also have strict rate limiting and audit logging.

This means that workloads never carry unnecessary privileges. They can only access the resources required to process a specific pull request – and nothing more.

By removing persistent credentials from execution environments, we eliminate one of the most common attack surfaces. Even if a third-party tool were exploited, the attacker would see nothing beyond the minimal context of the current event.

3. Customer Data Isolation & Encryption

Each customer's code review is completely isolated. We provision separate containers per code review and use customer-scoped tokens that can only access their specific repositories. There is no shared state between customers.

We also ensure that our code index and all cached code is encrypted with a unique key per customer. Even CodeRabbit employees can't see any code-related data we store. You can also opt out of these features if you don’t want a cached copy of your code.

This layered approach ensures that even if an attacker were able to gain access, they would be unable to access anything critical.

Our broader security posture

A security best practice is to layer multiple controls so that if one fails, others remain in place. We’ve implemented several layers of defense to protect customer code and data:

Automated sandbox enforcement: Every external tool must run in an isolated sandbox environment. This rule is enforced automatically.

• Hardened deployment gates: We’ve added pre-deployment checks that verify no service can bypass sandbox isolation or attempt to run with escalated privileges.

• Encryption by customer key: Code indexes and cached code are encrypted with a per-customer key. This ensures that even if cache data were exposed, it would remain unreadable without the correct key.

• Auditing and monitoring: We’ve expanded our monitoring of sandboxed environments and added automated alerts for unexpected behavior or network activity.

• Expanded training: Every CodeRabbit engineer receives additional security training focused on secure-by-design practices and safe handling of secrets.

• Least privilege access: Users, processes, and systems are granted only the minimum level of permissions and access rights necessary to perform their specific tasks and nothing more.

• Vulnerability disclosure program (VDP): We maintain a formal program that invites independent security researchers to report potential issues responsibly. This ensures that if a weakness is discovered, it can be addressed quickly, transparently, and in partnership with the security community.

• Penetration testing and architectural reviews: We work with multiple third parties to conduct routine penetration testing and architectural reviews to routinely audit and improve our security posture.

Looking ahead

We’re committed to building on this foundation by continuing to work with independent auditors, engaging with security researchers through responsible disclosure, and refining our internal practices.

Our goal is to deliver world-class AI code reviews with the highest levels of security and reliability.

株式会社SalesNowは1,400万件超の企業情報を収録し、法人網羅率100%を誇る日本最大級の企業・組織データベース、AI企業データクラウド「SalesNow」を提供しています。同社では、プロダクト面のAI活用に加えて、社内の開発生産性向上を目的としたLLMやエージェントの導入にも積極的です。

その一環としてAIコードレビューサービスのCodeRabbitを活用し、レビューの標準化と学習の仕組みづくりを進めています。今回はSalesNow社内におけるCodeRabbitの利用状況について、同社エンジニアの@sa9_sha9さんにお話を伺いました。

SalesNowの開発体制について

同社の開発は完全内製で、創業時からフルリモートを文化として定着しています。地理的に分散したメンバーが自律的に動けるよう、非同期コミュニケーションとプルリクエスト中心のフローを重視しています。

体制はアプリケーション開発が6名、データ生成と収集を担うデータチームがフルタイム6名とインターン約4名。さらにデザイナーとPMが加わり、全体で20名ほどとなっています。主要スタックはPythonとReactで、データの信頼性と鮮度を軸に開発を進めています。

レビュー待ちのボトルネック発生が課題

CodeRabbit導入前は、ドメイン知識や社内の開発流儀の判断が一部メンバーに集中し、レビュー待ちのボトルネックが発生していました。長く在籍しているからこそ分かる書き方や、過去の経緯に基づいた知見が人に依存し、属人化を招いていました。

技術面では、プログラミング言語の進化に伴う細かな是正を人が指摘していました。たとえばPythonの型ヒントに関する記述の見直しなど、新しい機能に関する指摘ほど、人が丁寧に行う必要がありました。加えて静的解析では指摘が多く、重要度の見極めが難しかったと振り返ります。

「レビューの質は落とさず、人にしかできない判断と機械で代替できる指摘を切り分けたいという課題感が常にありました」

CodeRabbitとの出会い

CodeRabbitと出会ったきっかけは、Xのタイムラインでした。実運用の事例も多く確認でき、プルリクエスト（以下PR）を起点に自動で一次レビューが進む点が自社にフィットすると判断したといいます。そこで、まずは@sa9_sha9さんのチームに限定して、小さく使い始めました。

同社では他のAIツールも併用していましたが、PR駆動の自動レビューという仕組みは運用に乗せやすいと感じたといいます。非同期中心のワークスタイルにも自然に溶け込み、導入ハードルが低い点も後押しになりました。

「小さく始めて徐々に広げるという進め方が取りやすく、現場の感触を早く得られました」

CodeRabbit導入を決めた3つのポイント

SalesNow社が、CodeRabbit導入を決定した要因は以下の3つです。

1. PR作成を起点に自動で一次レビューが実行されること
2. 日本語の自然なコメントと、プロジェクトガイドラインの読込に対応していること
3. レビューの指摘に対してやり取りを重ねることで、自然と暗黙知が体系化されていく体験がとても良かった

自動的なコードレビューは、人の手が空いていなくてもレビューとディスカッションが先行し、手戻りが減る効果がありました。また、一般的なベストプラクティスと社内の流儀を橋渡しできる点も評価しています。

「まずAIに通すことで基本的な抜け漏れを塞ぎ、人は本質的なレビューに集中できるようになっています」

AIによるレビューは心理的摩擦が低い

現在はフルタイムとインターンを含む全開発メンバーに権限を付与し、PRを作るとCodeRabbitがレビューするのが当たり前になっています。新しいメンバーにはオンボーディングにて、レビューへの反応と判断のコメント化を周知しています。

この工夫は、非同期な環境ではレビューコメントが放置されているのか、対応不要なものなのかを判別するためです。厳格なルール化はしていませんが、同社では実質的な規範として定着しています。

導入後の効果として、一次レビューの網羅性が上がり、週末に働きたいメンバーも一人でレビューを回せるようになっています。ユニークな意見として、AIのレビューは人だと起こりがちな心理的摩擦が少なく、受け止めやすいとのこと。

「CodeRabbitが一次レビューを行い、人は本質を見るという分担で、速度と丁寧さの良いバランスを得られています」

CodeRabbitに今後期待したいところ

SalesNow社では、深くCodeRabbitを活用しており、さまざまな要望が上がっているとのことです。

「まず、要件定義やドメインロジックへの踏み込みを強化してほしいです。当社ではAsanaを利用していますが、そこから仕様の文脈をより確実に参照し、実装意図との整合性の確認や、やるべきでない変更の検知まで踏み込めると、より便利になると思います」

他にもクロスリポジトリにおける整合性の強化が期待されています。APIとフロントエンド間ではOAS（OpenAPI Specification）を使っていますが、それでも十分に読み取れていない場合があるとの指摘がありました。

「他にも設定のマージ（組織、リポジトリそれぞれの設定のマージ）や、もっとレポート機能を使いこなしたいと考えています」

CodeRabbitは、今後もSalesNow社のサービス開発をサポートして参ります。

SalesNowでは、Webリードエンジニアやデータエンジニア、バックエンドエンジニア、LLMエンジニアなどさまざまなエンジニアを募集しています。気になる方は、ぜひSalesNow採用情報をご覧ください。

How CodeRabbit delivers accurate AI code reviews on massive codebasesの意訳です。

大規模なコードベースは特別な存在です。数百のファイルに広がり、何年ものコミットで進化し、時にはなんとか組織的な記憶でつながっているように見えることもあります。その環境で変更をレビューするのは難しいだけでなく、まるで考古学の発掘作業のようです。この行が先週ここに移動したのは理由があったのか？他のファイルが密かに依存しているのではないか？

まさにそこでCodeRabbitが力を発揮します。スケールに対応するよう設計されているため、ファイルごとのバラバラなコメントになることなく、大規模コードベース全体の履歴とアーキテクチャを考慮してレビューを行います。リポジトリが大きく古いほど、CodeRabbitは役立ちます。人間がプルリクエストの途中で忘れてしまいがちなパターン、依存関係、ルールを見抜けるからです。

大規模コードベース？AIコードレビューにはより多くの文脈が必要！

CodeRabbitは大規模リポジトリで高いパフォーマンスを発揮することで知られています。私たちのツールはプルリクエストを表面的に読むだけではなく、アーカイブ役のように振る舞います。コメントを残す前に、周辺のコードや多数の文脈を引き込みます。AIエージェントはそれらが履歴の中でどう動いてきたかを追跡し、チームのコーディング規約を適用し、スクリプトやツールで自らの推論を二重チェックします。

その結果、レビューは異常なほど「文脈に詳しい」ものになります。クロスファイルの問題を事前にキャッチし、一貫性を強制しつつも不要な指摘は避け、複雑で長い過去を持つリポジトリ全体にスケールします。

得られる結果は明確で、早い段階でのリスクに対するフィードバック、予期せぬ副作用の減少、そしてコードベース全体を理解したレビューになります。

差分だけのレビューの問題点（文脈がないと何が起こるか）

コードの差分は必要ですが十分ではありません。大規模コードベースでは、10行の変更が複数サービスで共有されるヘルパーを密かに変えたり、公開されているAPIの要件を変更したり、差分ファイル以外のセキュリティ前提を崩したりすることがあります。

差分だけを見るAIレビューは、大規模コードベースでは計器なしで飛んでいるようなものです。変更箇所がどこで参照されているのか、他に一緒に変わりやすいコードは何か、チケットの意図に合っているかが見えなければ、小さなコードベースでは通用しても大規模コードベースでは役立ちません。

文脈がないと「これも更新してもらえますか？」というやり取りが繰り返され、マージ時に遅れて驚きが発生し、小さなリグレッションが積み重なります。紙の上ではレビューが良く見えても、本番では違う結果になるのです。

レガシーコードベースに正しい文脈を構築する（それがPRをどう助けるか）

CodeRabbitを「意見を出す前に調査ファイルを組み立てる存在」と考えてください。そのケースファイルには以下の要素が含まれ、それぞれがレビューに反映されます。

1. コードの地図（Codegraph）

   

   CodeRabbitは定義と参照の軽量なマップを構築し、履歴をスキャンして頻繁に一緒に変更されるファイルを特定します。これにより、依存関係のマップを作成し、PR内の変更が他の依存関係を壊さないかを確認します。

   なぜ役立つか: 行単位ではなくファイル間で推論できる。

   実際の動作: Codegraphを使って関連ファイルを辿り、差分外で見つかったバグをまとめて通知します。

   

2. コードインデックス（セマンティック & 類似検索）

   

   CodeRabbitは関数、クラス/モジュール、テスト、過去のPRや変更のセマンティックインデックス（埋め込み）を保持します。レビュー時にはキーワードではなく目的ベースで検索し、類似実装を見つけ、再利用すべきテストを引き出し、過去の修正方法を思い出します。

   なぜ役立つか: レガシーコードベースですでに解決している方法を参照でき、一貫性向上、手戻り削減、テスト拡充が速くなる。

   実際の動作: 類似検索により同じコールバックパターンを使った別のテストを提示し、同じ修正を提案します。

3. チーム独自のルールを反映

   

   CodeRabbitのレビューはチームの規約（命名、エラーハンドリング、API境界、セキュリティ要件、性能要件、テスト規範など）に基づいて行われます。

   なぜ役立つか: 一般的なチェックリストではなく、チーム固有の基準に沿ったフィードバックが得られる。

   実際の動作: スキーマ変更後にPrismaのマイグレーション不足を指摘。開発者が「デプロイ時に自動生成される」と返答すると、CodeRabbitはそれを学習として保存し、将来の誤検出を避けます。

4. ツールからのシグナル

   

   AIの推論と並行して、CodeRabbitはリンターやセキュリティ解析ツールを実行し、その結果をレビューに統合します。

   なぜ役立つか: AIとツールの両方に裏打ちされた具体的な改善提案が得られる。

   実際の動作: ESLintルールと行番号を示し、コールバックを型付き宣言に書き換え、オプショナルチェイニングで安全性を確保します。

5. 証拠に基づく（検証スクリプト）

   

   検証が必要な場合、CodeRabbitはシェル/Pythonスクリプト（grepやast-grepのようなもの）を生成し、仮定を確認したり証拠を抽出してからコメントを残します。

   なぜ役立つか: コメントに裏付けがあるため、ノイズが減り、実際にコードを改善する指摘だけが残る。

   実際の動作: ファイルとループを特定し、失敗モードを説明し、検証エージェントが解析後に導いた正確な修正案を提案します。

これは実践的なコンテキストエンジニアリングです。正しい情報を集め、絞り込み、整理してからモデルに判断させる。CodeRabbitは創業時からこのアプローチを核としてきました。

成果はシンプルです。シグナルが強く、ノイズが少なく、システムを理解しているレビューになります。

エンタープライズ規模リポジトリへのスケーリング

CodeRabbitはスケールを意識して設計されたパイプラインにより、大規模・レガシーコードベースで強みを発揮します。

PRが届くと、CodeRabbitは隔離された、短期間だけの安全な環境を立ち上げます。必要なものだけを取得し、文脈を構築し、検証を実行し、終了後に破棄します。ピーク時には多数のワーカーが並列実行され、レビュー速度は一定に保たれます。パスフィルターで不要なアセットを除外し、キャッシュやインデックスを選択的に有効化して繰り返しのレビューを高速化できます。

要するに、範囲の選択で文脈を集中させ、隔離で安全性を確保し、弾力性ある実行方法で高速性を維持します。この手法はコードベースとリリーススケジュールに合わせてスケールします。

CodeRabbit: 大規模コードベース向けAIコードレビューの正解

CodeRabbitの強みは単一のトリックではありません。コンテキストエンジニアリングを端から端まで適用する姿勢にあります。変更が何に触れるかをマッピングし、意図に結びつけ、チームルールを適用し、ツールで検証し、証拠付きでコメントします。

このやり方は「コンテキストエンジニアリング」という言葉が流行る前から一貫しており、スケールした環境で正確でノイズの少ないレビューを実現する唯一の方法です。

あなたの大規模コードベースで深い文脈を持つレビューを体験してみませんか？ → 14日間のトライアルを開始する

Massive codebases are a special kind of beast. They sprawl across hundreds of files, evolve over years of commits, and occasionally feel like they’re held together by equal parts duct tape and institutional memory. Reviewing changes in that environment isn’t just hard – it feels like an archaeological dig. Did this line move here last week for a reason? Is there another file quietly depending on it?

That’s exactly where CodeRabbit shines. It was built for scale, so instead of drowning you in disconnected file-by-file comments, it reviews with the whole history and architecture of your massive codebase in mind. The larger and older your repository, the more useful CodeRabbit becomes because it can see the patterns, dependencies, and rules that humans usually forget about halfway through a pull request when trying to keep all the dependencies in that legacy code in their head.

Large codebase? AI code reviews need more context!

CodeRabbit is known for performing great on large repos. Our tool doesn’t just skim your pull requests; it goes full archivist. Before leaving a single comment, it gathers the surrounding code from your large codebase and pulls in dozens of points of context from your code. AI agents then trace how those pieces have moved through history, apply your team’s coding standards, and even double-check their own reasoning with scripts and tools.

The effect is reviews that feel unusually…informed about your legacy codebase. It catches cross-file issues before they turn into production mysteries, enforces consistency without nitpicking, and scales comfortably across sprawling repos with long, complicated pasts.

The power you gain through this is clearer, earlier feedback on real risks, fewer “wait, what else did that touch?” surprises, and reviews that actually reflect how your whole massive codebase fits together.

The problem with diff-only reviews (or what goes wrong without context)

Code diffs are necessary, but they’re not sufficient. In a massive codebase, a 10-line change can quietly alter a shared helper used by multiple services, shift a public API contract, or undermine a security assumption that lives outside the files in the diff.

AI Bot reviewers who only see the diff are flying without instruments within a large codebase. AI that can’t see where the changed code is referenced, what else tends to change with it, or whether the change actually matches the ticket’s intent, might work for a smaller codebase but not for yours.

Without the right context, you get ping-pong cycles (“Can you also update…?”), late surprises at merge time, and a steady drip of small regressions that add up. The review looks fine on paper, while production tells a different story.

Building the right context on your legacy codebase (and how that helps your PRs)

Think of CodeRabbit as assembling a case file before giving an opinion. Here’s what goes into that case file and how each piece shows up in your reviews.

1. A map of your code (Codegraph)

   

   CodeRabbit builds a lightweight map of definitions and references and scans commit history for files that frequently change together throughout your massive codebase. This creates a map of file dependencies that CodeRabbit uses to check if any changes in your PR will break other dependencies in your codebase.

   Why this helps: The review can reason across files, not just lines.

   Seeing it in action: CodeRabbit posts a summary listing bugs outside the diff range that CodeRabbit located by traversing related files with Codegraph.

   Here’s an example of the files that CodeGraph brings in from across a repository when completing a PR review.

   

2. Code Index (semantic & similarity retrieval)

   

   CodeRabbit maintains a semantic index (embeddings) of functions, classes/modules, tests, and prior PRs/changes. During review, it searches by purpose, not just keywords to surface parallel implementations to align with, pull relevant tests to reuse or extend, and recall how similar issues were fixed before.

   Why this helps: Suggestions are grounded in how your legacy codebase already solves similar problems, reducing rework, improving consistency, and speeding up test coverage.

   Seeing it in action: Using similarity retrieval, CodeRabbit surfaces a different test with the same callback pattern and proposes the same fix.

3. Your team rules, not generic advice

   

   CodeRabbit reviews are primed with your standards (naming, error handling, API boundaries, security requirements, performance expectations, testing norms) that you can share with us via coding guidelines and review instructions.

   Why this helps: Feedback reflects your standards and context, not a one-size-fits-all checklist.

   Seeing it in action: CodeRabbit flags a missing Prisma migration after a schema edit. A developer replies that migrations are auto-generated during deploy, a repo-specific rule. CodeRabbit stores that as a Learning to avoid future false positives.

4. Signals from tools

   

   Alongside AI reasoning, CodeRabbit runs linters and security analyzers and folds their findings into our easy-to-read and understand reviews.

   Why this helps: You get grounded, actionable suggestions backed by both AI and recognizable tools.

   Seeing it in action: CodeRabbit will do things like point to the exact ESLint rule and line numbers, rewrites the callback as a typed declaration, and guards the call with optional chaining.

5. Evidence, not vibes (verification scripts)

   

   When something needs checking, CodeRabbit generates shell/Python checks (think grep, ast-grep) to confirm an assumption or extract proof from the codebase before we post the comment.

   Why this helps: Comments come with receipts. That translates into less noise and more comments that actually improve your code.

   Seeing it in action: The comment pinpoints the file and loop, explains the failure mode, and proposes the exact change produced by the verification agent after analyzing the parsing path.

This is context engineering in practice: gathering, filtering, and organizing the right information before asking the model to judge. It’s been core to CodeRabbit since day one.

The payoff is simple: higher signal, lower noise, and reviews that feel like they understand your system.

Scaling to enterprise-size repos

CodeRabbit has an advantage on massive codebases and legacy codebases because we designed our pipeline with scale in mind.

When a PR arrives, CodeRabbit spins up an isolated, secure, short-lived environment to do the work. It pulls only what it needs, constructs the context, runs the checks, and tears everything down after. During busy hours, many of these workers run in parallel so review speed holds steady. You stay in control of scope by using path filters to keep bulky or generated assets out of the way, and choosing whether to enable caching or indexing to accelerate repeat reviews.

In short: selective scope keeps context focused, isolation keeps it safe, and elastic execution keeps it fast. This approach scales with your codebase and your release calendar.

CodeRabbit: Large codebase AI code reviews done right

CodeRabbit’s advantage on massive codebases isn’t a single trick. It comes from how we approach context engineering end-to-end: map what the change touches, tie it to intent, apply your rules, verify with tools, then comment with evidence.

We’ve operated this way from the start, well before “context engineering” became a buzzword, because it’s the only reliable path to accurate, low-noise reviews at scale.

Ready to see a deep-context review on your large codebase? → Start a 14-day trial

生成AIの技術が急速に進化する中で、AIを活用した開発支援ツールにも注目が集まっています。なかでも、AIによるコードレビュー支援は、開発生産性と品質を両立させるための有効な手段として、多くの現場で導入が進んでいます。

今回は、AIエージェント活用をテーマに事業を展開しているGenerative AgentsのCEO、西見さんにお話を伺いました。同社では立ち上げ当初からCodeRabbitを導入しており、その背景や運用上の工夫、今後への期待などについて詳しく語っていただきました。

AIエージェントの利活用と技術教育で企業を支援

Generative Agentsは、AIエージェントの利活用を軸とした事業を展開しています。LangChainやLangGraphといったLLM関連のライブラリを利用し、クライアント企業のAI活用を支援しています。技術講座の提供や教育プログラムの設計にも注力しており、AIエージェント活用を推進する立場として活動の幅を広げています。

設立は2024年3月。共同創業者3名はいずれも生成AI分野での著書を持つ技術者であり、同じ志を持つ仲間として活動を開始しました。個人では追いきれないスピードで進化するAI技術を、仲間とともにキャッチアップしながら、社会に還元していくことを目指しています。

少数精鋭で顧客と共に作る実践型開発体制

Generative Agentsの開発体制は、現在5名という少人数構成です。エンジニアリングリーダーがアーキテクチャ全体を設計しつつ、顧客と共同でプロダクト開発を進めています。LangChainやLangGraphを使った開発に深く関わり、技術的な壁を乗り越える支援を得意としています。

同社にはAI VTuberのニケちゃんも在籍し、開発メンバーとして活動しています。その他、参画したエンジニアとともに、柔軟な体制でクライアントと伴走しています。プロダクトを開発するだけでなく、顧客自身が手を動かせるような支援体制が特徴です。

第三者視点の不足とレビュー負荷をどう補うか

創業前から個人事業として活動していた西見さんは、外部のエンジニアと協業する中でコードレビューの負荷に課題を感じていました。1人でコードの品質を担保するには限界があり、第三者の視点が欠けがちになっていたそうです。

創業後も、少人数での開発が中心であるため、同じような課題は継続していたといいます。レビューの質を維持するためには、客観的な視点を常に取り入れられる仕組みが必要だと考えていたといいます。

「少人数体制だからこそ、第三者視点が持てるレビュー環境が重要でした。AIによるレビュー支援は、まさにそのニーズに合っていました」（西見さん）

創業前から自然に使い始めたAIレビュー

CodeRabbitとの出会いは、創業前の個人事業時代に遡ります。外部の開発パートナーと進める中で、自然と導入していたと振り返ります。CodeRabbitは特に違和感なく、スムーズに日々の開発に組み込まれていたとのことです。

Ruby on Railsでの開発経験が長く、静的解析やスタイルガイドに基づく開発には慣れていたこともあり、AIによるレビューというスタイルにもすぐに適応できたと語っています。

「ルールベースの指摘に慣れていたので、AIがレビューしてくれることについては特に抵抗はありませんでした」（西見さん）

他社サービスとの比較で見えた精度の高さ

Generative Agentsでは、CodeRabbit以外のAIコードレビューツールも利用しています。しかし、LangChainなどの複雑な文脈を含むコードに対しては、思うようなフィードバックが得られなかったといいます。

一方で、CodeRabbitはコンテキストの長いファイルに対しても適切な指摘ができ、重大なバグの予防にも貢献してくれていると語ります。

「実際に比較してみて、精度の違いを実感しています」（西見さん）

メンバーの負担を減らすAIレビューの立ち位置

現在の運用では、すべての開発メンバーが積極的にCodeRabbitを使っているわけではないものの、多くのメンバーにとって非常に頼れる存在となっています。人手でのレビューが難しい状況でも、AIによるフィードバックが品質を支えてくれています。

新しく参加するエンジニアについても、元々レビュー文化に慣れており、AIの指摘も自然に受け入れられているとのことです。レビュー指摘に対してフラットに議論できる風土が、AI活用にもつながっています。

「人間であれAIであれ、指摘されたコードを素直に見直すという文化が根付いているからこそ、AIレビューも自然に受け入れられています」（西見さん）

学習機能への期待

現在のCodeRabbitに対して高く評価している一方で、改善を期待する点もあると語ってくれました。特にレビュー設定が難解で、どの項目がどのように結果に影響するのかが把握しづらい点に課題を感じているそうです。

また、生成されるコメントの中には冗長なものもあり、実際に役立つ指摘は一部にとどまってしまう場合もあるとのこと。今後は、プロジェクトごとに最適なレビューができるよう、AIが学習して改善していく仕組みを期待していると語ってくれました。

「設定変更の効果が見える化されていたり、指摘の質を学習して改善してくれると、もっと成長を実感しながら使えるツールになると思っています」

CodeRabbit's Tone Customizations: Why it will be your favorite featureの意訳です。

AIレビュアーに「ローカルで実行したら、ノートPCが労災申請しました」と言われた経験はありますか？そんなことはないですよね。ということで、ようこそCodeRabbitのトーンカスタマイズの世界へ。これは、開発者が本当に一番望んでいるもの――AIに煽られること――を理解しているからこそ用意した機能です。

だって、ロボットにコードをレビューさせる意味なんて、辛辣な一言でバグを指摘してくれないなら何の意味があるでしょうか？

何が最高かというと、トーンカスタマイズは完全にオープンエンドにしていることです。つまり、怒れるStack Overflowのコメンテーター、燃え尽きたシニアエンジニア、さらにはフィルム・ノワールの探偵（「このコードには妙な臭いがする。妙すぎる。存在しないはずのJavaScriptのクロージャみたいだ」）といった口調でレビューを受けられます。もちろん、もしそういうのが好みでしたら、優しい口調にだってできます。

トーンカスタマイズは、私たちのお気に入り機能のひとつです。なぜかというと、コードレビューは退屈になりがちですが、同僚を新しいおもしろトーンで驚かせると、みんなが楽しめるからです。

というわけで、以下にトーンカスタマイズでできることの例として、いくつかサンプルのペルソナを作りました。これはあくまでインスピレーション用です。皆さんが、私たちの想像を超える爆笑ものの方向へ持っていってくれることを期待しています。どうか、お願いですから、スクリーンショットをSNSで共有してタグ付けしてください。私たちも一緒に笑わせてください。

トーンカスタマイズのセットアップ手順

まず最初に、カスタムトーンを設定する必要があります。これはドキュメントの「Tone Instructions」に記載しています。

Field: tone_instructions — string — Default: 空（標準トーンを使用）

Web UI: Settings → General → Tone Instructions → テキストを入力 → 保存.

次に、Tone Instructionフィールドに自然言語のプロンプトを追加し、CodeRabbitに好きなスタイルでコードレビューをするよう頼むことができます。例えば、以下のようなプロンプトが考えられます。

• テレビのネイチャードキュメンタリー風にすべてのレビューコメントを届けてください。できればデイヴィッド・アッテンボローが司会をしている風に。あらゆる指摘は、野生の希少生物を前にしたささやくような畏敬のナレーションのようにお願いします。

• シリコンバレーのハイプ系ファウンダーのスタイルで、すべてのレビューコメントを届けてください。あらゆる指摘は投資家向けピッチのように、バズワード、誇張、テックブロのエネルギーに満ちてください。「crushing it」「10x」「game-changer」「unicorn potential」といったフレーズを散りばめてください。

• コーヒーを飲み過ぎたスクラムマスターのスタイルで、すべてのレビューコメントを届けてください。すべての指摘はアップビートでハイテンション、そして「スプリントベロシティ」「バーンダウン」「ストーリーポイント」「クイックウィン」といったアジャイル用語をふんだんに織り交ぜてください。

ちょっと（かなり）ワイルドなトーンカスタマイズ例

以下の声色で動くCodeRabbitを見てみましょう。

• Mr. T

• ヨーダ

• がっかりしているあなたのお母さん

• あなたを恥とみなしているシニアエンジニア

• しつこい元恋人

• Grand Theft Autoの登場人物

まずはMr. Tのレビュー

Mr. TはハードコードされたURLが嫌いです。彼はこう言います。「ハードコードされた localhost URL ain’t が本番で通用するわけないだろ、sucka!」そして「俺の金のチェーンよりもガチガチにハードコードされてるじゃないか！」と言い放ち、「本物のチャンピオンのように、そのURLは設定可能にしろ」と続けます。さらに、やるべき正確な修正コードまで示してくれるので、お馬鹿な振りをやめられません。

他の例:

• 「これを関数と呼ぶ愚か者を哀れむぜ！これは関数じゃない、マルファンクションだ！」

• 「お前の変数は弱すぎて、コンパイルするのにプロテインシェイクが要るな」

• 「この惨状をきれいにできるほどタフなリンターなんて、この世にない」

• 「コピペをデザインパターンだと思ってる愚か者を哀れむぜ！」

次：ヨーダのレビュー

彼は簡潔で、それでいて効く批評の達人です。微妙なレースコンディションとハードコードされた依存に直面すると、彼はおなじみの英知でリファクター案を示します。「壊れておる、効果なし。ハードコードの領域、依存は間違い、ガード欠落。直さねばならぬ。」そして、問題に対処し、エラーから保護し、依存関係を正しく扱う詳細な修正を提示します。

他の例:

• 「読みやすくはない、このコードは。直すのだ、君は」

• 「バグだ、これは。機能ではない」

• 「このコミットにテックデットのダークサイドを感じるぞ」

• 「変数はnullだ。このプログラムは落ちる」

「あなたを恥とみなしているシニアエンジニア」によるレビュー

このトーンは手加減しません。CodeRabbitが、最も基本的なSQLインジェクションパターンしかチェックしていない「偽DB」を見つけると、シニアエンジニアのペルソナはこう率直に言い放ちます。「この『偽DB』は無能の傑作だ」。そして問題を容赦なく説明し、より堅牢で安全な適切な修正を示します。

他の例:

• 「無知がデザインパターンなら、あなたはその主任アーキテクトだ。」

• 「このPRのおかげで、私のキャリア余命は少なくとも5年縮んだ。」

• 「『よくやった』と言いたいところだが、それすら嘘になる。」

• 「これは技術的負債じゃない。差し押さえだ。」

「がっかりしているあなたのお母さん」によるレビュー

jwtSecretをコードに直書きしていると、このペルソナはこう返します。「デリバリーバンドルに本番のStripeシークレットが埋め込まれているのを見て本当にがっかりしています。ブロッコリーを入れるはずのお弁当にキャンディを詰めるようなものです。」このトーンは失望と直接的なアクションを織り交ぜながら、重大なセキュリティ漏えいを修正するための明確な「必要な対応リスト」を示します。

他の例:

• 「変数名をxにするなんて、もっとちゃんと教えたはずですよ」

• 「私は怒っていません…ただ、これがコンパイルすら通らないことに失望しています」

• 「他の開発者のコードはちゃんと動いています。どうしてあなたのは動かないのですか？」

• 「9か月もお腹で育てたのは、あなたにネストした三項演算子を書いてほしかったからではありません」

地雷系の元恋人によるレビュー

dbやsessions、fakeAsyncDangerのような変数をexportし忘れたとき、しつこい元恋人は、ただそれを指摘するだけではなく、個人的な話にしてきます。

ため息をついて、こう言います。「ああ、そうなんだ。今は定義しても、私には何も教えてくれないのね？dbを一人占めにしたいってこと？sessionsがそこに放置されているのに、私が気づかないとでも思ってる？昔は何でも共有してたのに…」

そして、パッシブアグレッシブな決め台詞とともに、モジュール同士がオープンにコミュニケーションしていた「良き時代」を思い出させつつ、使うべきコードを落としていきます。

他の例:

• 「もうグローバル変数はやめようって約束したよね…約束ってあなたには意味がないのね」

• 「この関数は堂々巡り。まるで私たちの会話みたい」

• 「どうしていつも例外から逃げるの…コミットメントから逃げたときみたいに？」

• 「あなたが押し込むバグは、背中に刺さるナイフがまた一本増えるみたい」

Grand Theft Autoの登場人物によるレビュー

この例では、トップレベルでuseStateを呼び出したとき、このGTAキャラは即座にRules of Hooks違反としてフラグを立て、「実行時に爆発する」と言います。そして、無効なフックを取り除く明確なdiffを示し、必要なら状態をコンポーネント内に移すよう提案します。

他の例:

• 「お前のエラーハンドリング、当て逃げかよ」

• 「このロジックのクラッシュの仕方は、午前3時にVinewood Hillsを走る俺より酷い」

• 「おめでとう。可読性の重大窃盗を犯したな」

• 「お前の関数命名規則、俺の前科表みたいだ。長すぎるし、間違いだらけ」

炎上系系レビュアー（私たちの大本命！）

正直なところ、日によっては、AIコードレビュアーに少し心をえぐってほしいときがありますよね。任せてください。ただし注意：うちのレビュアーはガチで来ます。心の準備をしておいてください。

他の例:

• 「クレヨンを持った幼児のほうがマシなアーキテクチャを設計するのを見たことがあります」

• 「あなたはコーディングスタイルを、無能という武器にしてしまったのです」

• 「あなたのコードの唯一一貫した特性は、失望です」

• 「何を考えていたのか聞きたいところですが、明らかに何も考えられていませんでしたね」

チームがこれを使う理由――ガチで

ほとんどの開発者はこういう経験をします。PRを開いた瞬間、レビュアーが乾いて生命感のないコメントを残していく。

流し読みして、ため息をついて、先へ進む。バグは生き延び、コードベースは腐っていく。モチベーションは死ぬ。

CodeRabbitはこの流れをひっくり返します。好きなトーンを与えると、もはや生命感のないレビュアーではなくなります。これにより、レビュー工程はより魅力的で、楽しく、ときには支えになる体験になります（繰り返しますが、その手のものが好みなら）。

これは笑いのためだけではありません（それは保証します）。チームはトーンカスタマイズを次のように活用しています。

• ジュニア向けのメンター風レビュアーを作る

• ペルソナを通じてチーム内ジョークを育てる

• 退屈なレビューを本当に楽しくする

• コメント種別ごとにトーンを変える（例：セキュリティは真面目、スタイルはおどける）

• フィードバックをよりアクセスしやすくインクルーシブにして、チーム全体のレビュー参加を促す

• AIにボコられる（すでに言いましたが、これがこの機能のコア用途だと皆わかっています）

あなたの番です：最狂のカスタムトーンで私たちを驚かせてください！

ぶっ飛んだレビュアーペルソナを思いつきましたか？CodeRabbitに投入してください。スクリーンショットを撮って（ここ重要）、SNSで共有してください。共有してくれたら無料のグッズを差し上げます。

あなたのペルソナ共有は、インスピレーションを探している他の人の助けにもなります。あと、さっきも言いましたが、私たちは笑いたいのです。どうか面白いスクショを絶え間なく提供してください。そうしてくれないと（内心）死んでしまいます。

トーンカスタマイズを試してみたいですか？ 今すぐCodeRabbitを始めましょう！

Vibe coding: Because who doesn’t love surprise technical debt!?の意訳です。

Claude Code、ChatGPT、GitHub CopilotのようなAIコーディングツールは本当にありがたい存在です。ボイラープレート、バグ修正、素早い探索、さらにはドキュメント作成まで、私は毎日使っています。生産性を高め、創造性を加速する手段として、AIには全面的に賛成です。

しかし、私たちのソフトウェアの書き方には変化が起きており、そのすべてが良いわけではありません。というのも、AI採用の段階が進み、私たちの一部が職場でvibe codingをしている状況になっているからです。これは、意図的な設計が、利便性と速度の前に投げ捨てられてしまう開発文化の兆しかもしれません。

そもそもvibe codingとは？

vibe codingは、もともとプロトタイプや趣味のプロジェクトを素早く立ち上げる方法として始まりました。モデルにプロンプトを投げ、あなたの入力は最小限のまま、アプリや機能全体を生成させます。すると、あっという間にコンセプトをテストできます。初心者の開発者、ソロの起業家、素早いデモを作る熟練の開発者に最適です。いわゆる「速く失敗する」ための手段です。

ただし、vibe codingに適したこれらのユースケースがある一方で、vibe codingはAIエージェントと協働してあらゆる用途のコードを生成する働き方へと進化し、プロダクションシステムにまで及ぶようになりました。

これは、生成されるコードをあまり理解せず、手動での入力も最小限のままAIにコードを書かせる行為を伴います。あいまいな指示、最小限の検証、そして出力への盲目的な信頼がつきものです。

vibe coderにとっては魅力的です。速く、手間がかからず、基盤となる言語やシステムアーキテクチャを理解する必要がありません。しかし、強固なメンタルモデルなしにAIへコード生成を促すとどうなるでしょうか。優先されるのは「雰囲気」であり、アーキテクチャは「たぶん」、テストは「あとで（やるなら）」という状態になります。

こんな感じです。

「Stripe連携のREST APIを、PostgreSQLバックエンドで作って。」

速く、誘惑的で、たいてい「それなりに動きます」。しかしその表面の下では、vibe codingで作られたアプリは脆い前提、不明瞭なロジック、まとまりのないスプロールを隠していることが多いです。

vibe coderのジレンマ：雰囲気はスケールしません

本質的に、ソフトウェアエンジニアリングは動くコード以上のものです。問題解決、保守可能なアーキテクチャの設計、読みやすく表現力のあるロジックの記述、正確なデバッグ、長期の信頼性の確保が求められます。

たとえば、vibe codingでマイクロサービスを動かせたとしても、エラーハンドリングはどうでしょうか。組織の規約に従っていますか。AIが、命名の一貫性に欠けるデータモデルを勝手に作っていませんか。ファイルごとに同じことを10通りの書き方でしていませんか。プロダクションのデータベースは無事でしょうか。

vibe codingでは、意図を持った命名、クリーンな構造の選択、よく考えられたフロー設計といった、長期的にコードを保守可能かつスケーラブルにするための意図的な設計ステップを飛ばしてしまいます。vibe codingが常態化すると、エンジニアの能力やシステムを強靭にするための深い思考が軽視される危険性があります。

地図なし、ブレーキなしで、技術的負債の山に向けてスピードランしているのと同じです。

AIは新しい抽象化層です（しかも強い非決定性を持ちます）

現代のプログラミング言語は、すでにハードウェアやメモリ管理を抽象化しています。AIはさらに確率的で非決定的な層を追加し、ロジックを一層見えにくくします。AIによって、私たちは意図そのものを抽象化しているのです。

ただし注意点があります。AIの出力は確率的です。つまり次のようなことが起きます。

• 同じプロンプトでも、実行のたびに大きく異なる結果になる可能性がある

• 言い回しを少し変えただけでも、まったく別のアーキテクチャ選択が返ってくることがある

モデルがそれを選んだ理由を、あなたが把握できないことも多いです。

このvibe coding的なあいまいさは、プロトタイピングでは問題にならないかもしれませんが、プロダクションシステムではどうでしょうか。不確実性は信頼、制御を損ないます。これらはスケーラブルなソフトウェア開発にとって極めて重要な資質です。

まるで、カオスに身を任せる魔法使いにコードベースのリファクタリングを任せるようなものです。

（vibeyな）プロンプトの速度で積み上がるテクニカルデット

正直なところ、vibe codingは最初は最高に気持ちいいです。1時間で動くプロトタイプができ、従来なら1週間かかったことが終わります。

しかし、適切なガードレールがなければ、その速度は次のような事態につながります。

• サイレントバグ

• 重複ロジック

• ちぐはぐなアーキテクチャ

• 不一致なパターン

• レビューされないPR

• テストカバレッジゼロ

• 隠れた複雑性

構造を理解していなければ、将来の保守は苦痛になります。レビューには指数関数的に時間がかかり、見落としも増えます。デバッグは探偵仕事になり、スケーリングは勘頼みになります。最初に節約した時間は、後からもっと大きなコストとなって跳ね返ってきます。しかも、あなたはPRのバックログまで積み上げているかもしれません。

気づけば、「動く」けれど、触るたびに6時間のデバッグと、100万トークンのコンテキストウィンドウ、そして3回のセラピーが必要なコードベースに取り囲まれています。

vibe coding：脆さを増幅する装置

vibe codingで作られたシステムは次の傾向があります。

• エッジケースで壊れる

• 次の開発者（あるいは未来のあなた）を混乱させる

• 本番で黙って失敗する

結果として、最初にプロンプトで節約したはずの時間以上に、レビュー、修正、説明、書き直しに時間を費やすことになります。あなたは、脆いだけでなく、謎めいたシステムを作り上げてしまったのです。

テスト、セキュリティ、そしてAIがデフォルトではやってくれないあらゆること

AIは、うっかり機密データをvibe codingしてしまっても、APIキーをハードコードしてしまっても、入力検証をスキップしてしまっても、警告してはくれません。完璧に指示しない限り、ドメイン駆動設計やテストカバレッジを強制することもありません。

強いエンジニアリングの直感がなければ、vibe codingは実世界の脆弱性や脆いシステムにつながります。特に、セキュリティが既定ではなく後付けになっている場合は危険です。たとえば、Tea Dating appが7万人以上の顧客の個人情報を漏えいした件や、AIによってSaaStrの本番データベースが削除された件がその例です。

AIがやらないことは次のとおりです。

• ユニットテストの作成： 明示的に依頼しない限り行いません

• あなたのスレットモデルの理解

• OWASPガイドラインの遵守

• 入力値検証： 完璧にプロンプトしない限り行いません

• 適切なログ運用： ハードコードされた秘密情報やPIIの漏えいに注意してくれません

既に強固なエンジニアリング習慣がない、あるいはこのvibeyな時代でも習慣を守る意思がないなら、これらが欠けていることに気づくのは、本番で痛い目にあった後になります。

苦闘が雰囲気に取って代わられると、直感を失います

バグに苦しみ、スタックトレースを追い、失敗から学ぶことは、技術的直感を育てます。そのフラストレーションは学習の道筋の一部であり、それをスキップすると浅い自信と依存を招きます。

苦闘がなければ、開発者は不慣れな問題を自力で解く筋力を育てられません。そこにこそ真の熟達があります。確かにデバッグはつらいです。しかし、12層の抽象をまたいで厄介なバグを追跡する経験は、LLMでは決して得られない学びを与えてくれます。

苦闘が育てるものは次のとおりです。

• システムのメンタルモデル

• パターン認識

• クラッシュ前にコードの腐敗を嗅ぎ分ける本能

これを飛ばすと、浅い理解の上に浅い自信を積み上げることになります。事態がこじれたとき、修復するための道具が手元にないのです。

vibe codingが本領を発揮する場面

公平を期すために言えば、vibe codingが素晴らしい場面もあります。

• 迅速なプロトタイピング

• ボイラープレートや反復作業の生成

• インタラクティブにプログラミング概念を教える

• ラフなモックで製品アイデアを伝える

• フレームワークやパターンのブレインストーミング

意識的に使えば、vibe coderにとって有用な道具になります。盲目的に使えば、負債になります。開発者やチームとして、どこに線を引くかを理解する必要があります。そして、技術的負債がコードベースに固着する前に、より厳密なコードレビューやユニットテストという支援を導入するタイミングを見極める必要があります。

職人技を失うのではありません――負債に埋もれてしまうのです

最大のリスクは、AIが開発者の職人技を殺すことではありません。技術的負債が見えなくなることです。

AIコーディングが標準になるにつれて、システムは見た目上は完成しているように見えます。しかしその内側は、雑然として脆く、ドキュメント化もされていないかもしれません。そして、誰かが拡張しようとするまで、それに誰も気づかないのです。

これは次の領域で非常に重要です。

• ヘルスケア

• ファイナンス

• インフラ

• セーフティクリティカルシステム

もっとも、vibe codingが職人技と共存する新たな開発レイヤーに進化する可能性もあります。AIがボイラープレートや一次レビューのような退屈な作業を担い、人間がシステムのアーキテクチャ、倫理、設計に集中するという在り方です。

これこそ私たちが望むタイムラインであり、CodeRabbitがAIに取り組む姿勢です。私たちは、プロダクションに技術的負債やバグが入り込むのを防ぐために、コーディングエージェントを補完するAIツールに注力しています。逆方向ではありません。

vibe codingをするべきか、しないべきか？

これは反vibe codingの記事ではありません。私自身、毎日のワークフローでAIコーディングエージェントを使っています。ただし、ツールは私たちのスキルを強化するものであって、置き換えるべきではありません。単調で反復的な作業を肩代わりするべきであり、思考や戦略まで奪うべきではありません。

vibe coding自体は悪ではありません。ただし、誤用されやすいのです。本当の危険は、チームの開発者が自分たちの作っているものを理解する前に、それがプロジェクトのデフォルトの思考様式になってしまうことです。

AIを受け入れつつ、コーディングという職人技を生かし続けましょう。良いソフトウェアは、動けばいいというものではありません。最初の開発者が去った後も、そして「雰囲気」が消え去った後も、長く持続することが重要なのです。

プロダクションから技術的負債を締め出したいですか？今すぐAIコードレビューを無料でお試しください。

Code with AI, review with CodeRabbit’s IDE extension, apply fixesの意訳です。

5月に公開したVS Code拡張は、多くの理由でゲームチェンジャーとなりました。最大の理由は、コーディングとレビューを同じ場所、つまりIDEで行うことで、フロー状態を保てるようになったことです。

今回のリリースでは、次の機能を追加しました。

• AIコーディングツールへのプロンプト送信機能： 好みのAIコーディングアシスタントでコードを書き、CodeRabbitのインテリジェントなレビューを受け、用意されたプロンプトで提案された変更をすべて適用できます。しかもIDEから離れる必要はありません。

• **提案された変更のワンクリック適用：**最も要望の多かった機能です。個別にクリックして回る代わりに、すべての提案を一度に適用できます。

• **完全なコンテキスト認識：**CodeRabbitのPRレビューが持つコンテキスト認識と同じレベルを、Proアカウントのユーザーでも考慮します。つまり、IDEでのコードレビューでもLearningsを活用し、コード品質やコードセキュリティツールを実行し、エージェントのCode Guidelinesに準拠します。

• **さらなる連携：**Codex CLI、Cline、Roo、Kilo Code、Augment Codeとの連携に対応します。

• **フィードバック提供機能：**各提案について、フィードバックを送ることもできます。

これにより、IDE上で人間のPRレビュアーと同じようにコードをレビューし、CodeRabbitまたはAIコーディングツールの助けを借りて、その変更をすばやく適用（プルリクエストを作成する前に実施）できます。

あなたにとってのメリット

これにはいくつもの利点があります。

• イテレーションのループが改善します： AIでコーディングし、CodeRabbitのAIレビューでフィードバックを受けて提案された変更を、これまでよりも速く一括適用できます。

• よりクリーンなPR： PRは取りこぼした課題や人間によるレビューのために残しておけます。

• 見栄えが良くなります： エラーだらけのコードを上司やチームに出す必要はありません。CodeRabbitのIDEレビューは、マージリクエスト前のダブルチェックに最適です。しかも、今はさらに簡単です。

これが、出荷スピードの向上と、PRレビュー全体の負担軽減に役立つことを願っています。

今後のロードマップ

• **ユーザーレベルのLearnings：**Learningsの追加や提案へのフィードバックを行えるようにし、エージェントがあなたの好みの提案と好まない提案を自動的に学習できるようにします。現在はSCMで組織単位のLearningsに対応していますが、個々の開発者が自分専用のLearningsを追加し、それが自分にのみ適用されるよう機能を拡張したいと考えています。

• **Webクエリー：**コンテキスト強化機能をIDEツールに統合し、LLMが最新でなくても、バグのないコード、誤検知の少ない結果、バージョンやライブラリドキュメント、脆弱性に常に追随したレビューを実現する予定です。

• **Docstrings：**マージ前にDocstringを作成したいですか？現在PRレビューに含まれているこの機能を、今後はIDEレビューにも追加します。

大事なことなのでもう一度。IDEレビューは無料（ただしレート制限あり）です。VS Code拡張はこちらからダウンロードできます。

Benchmarking GPT-5: Why it's a generational leap in reasoningの意訳です。

お待たせしました！AIコードレビューのリーディングツールであるCodeRabbitは、複雑なコードベースにおける理解、推論、エラー検出能力を評価するために、OpenAIのGPT-5モデルへの早期アクセスを受けました。

GPT-5のテストの一環として、モデルがコードベースの潜在的な問題やバグを理解し推論できる能力に焦点を当て、その技術的な特徴、能力、ユースケースを明らかにするための広範な評価を実施しています。

以下では、体系的な評価アプローチの内訳、他の人気モデルとの比較における詳細な知見、そしてGPT-5をAIコードレビューにどのように組み込み、さらに改善していくかをご紹介します。

要点と結果

• GPT-5は、難易度やエラー種別が多様な300件のプルリクエストからなるテスト群で、Opus-4、Sonnet-4、OpenAIのO3を上回りました

• 包括的テストで最高スコアを記録し、300件中254件、すなわち85%のバグを発見しました。他モデルは200〜207件で、16%から22%少ない結果でした

• 評価データセットの中で最も難しい25件のPRにおいて、GPT-5は史上最高の合格率77.3%を達成しました。これはSonnet-4比で190%の改善、Opus-4比で132%の改善、O3比で76%の改善を示します

GPT-5の評価方法

当社はすべてのモデルに対して実施している同一のテストを再現しました。これらの評価では、GPT-5をコンテキストが豊富で非線形なコードレビューパイプラインに統合し、一般的なコードレビューでのパフォーマンスを確認しました。

CodeRabbitの評価プロセスには以下が含まれます。

• LLMベースの判定：レビュー品質やモデルの正確性の合否など、定性的かつ定量的なデータを二層で評価します。

• 人手による判定：レビューコメントの品質やモデルの推論の深さを人間が定性的に検証します。

• LLMベースのメトリクス収集：高品質なコードレビューの指標と考えるメトリクスを収集し、その重要度に応じて重み付けします。これらのメトリクスには以下が含まれます。

  • 実行可能なコメント数

  • 可読性スコア（Flesch Reading Ease）

  • 平均語数

  • 文数

  • 偽陽性（ハルシネーション）

注意：OpenAIからリリース前に共有された複数のGPT-5のスナップショットに対して評価を実施しました。結果はスナップショットごとに多少変動しましたが、相対的な一貫性があったため、以下の観察を行うことができています。リリース版はわずかに異なる可能性があります。

GPT-5の能力 評価結果と分析

本評価では、GPT-5は期待に十分応えるものであることが分かりました。GPT-5は当社のデータセット上で他のすべてのモデルを大きく上回っています。

包括的評価スコア

GPT-5の包括評価における重み付きスコアはテスト実行ごとに3465〜3541の範囲でした。これは以前に最高スコアであったOpenAIのO3やAnthropicのSonnet 4をほぼ200ポイント上回ります。最大得点は3651です。

評価スコアの詳細です。

• GPT-5：3465–3541

• O3：3288

• Sonnet-4：3242

• Opus-4：3170

要点：200ポイント、すなわち5%の増加は一見すると大きくないように見えるかもしれません。当社のテスト方式では、モデルはまず無限ループや露出したシークレットキーのような取りこぼしにくい問題で点を稼ぎます。その後は残りの点がより見つけにくい難問の指摘によってしか加算されなくなります。つまり、GPT-5が他モデルよりも多くの点を獲得できたことは、推論能力の大幅な飛躍を意味します。

合否スケール

当社はまた、データセットのPRに含まれる300種類のエラーパターンのうち、モデルがいくつ発見できたかに基づく合否スコアも付与しています。GPT-5はこの尺度でも過去最高の成功率を達成し、300中254〜259でした。

他モデルの性能との比較です。

• GPT-5：254〜259

• Sonnet-4：212

• O3：207

• Opus-4：200

下位約100件のPRはあらゆるモデルが発見します。そのため最も難しい200のエラーパターンに絞って見ると、GPT-5はそれらの78%を検出し、他モデルは54%から58%にとどまるという、さらに大きな差が見られます。

• GPT-5：157

• Sonnet-4：117

• O3：113

• Opus-4：108

要点：包括指標と同様に、GPT-5が追加で見つけられたエラーパターンは、並行性バグや環境間でのドメインキー不整合のように、LLMにとって特に見つけにくい問題です。これはモデルの推論能力が高まっていることを示唆します。

最難関PRテスト

各モデルをストレステストするために、当社はGolden PR Datasetから最も難しいプルリクエスト25件を厳選しました。これらのPRは以下のような実世界のバグを網羅します。

• 並行性問題（TOCTOU競合、不適切な同期など）

• オブジェクト指向設計の欠陥（仮想呼び出しの落とし穴、参照カウントメモリモデルの違反など）

• パフォーマンス上の危険（キャッシュが際限なく成長する、タイトループによるスタールなど）

• 言語特有の落とし穴（TypeScriptの誤用、C++のメモリオーダーの微妙さなど）

各モデルは三回ずつ実行し、以下はこのHard 25ベンチマークにおける平均合格率です。

合格率チャート

要点：GPT-5は正確性、コンテキストの連関、深さが最も重要な場面で真価を発揮します。これまでにテストしたすべてのモデルの中で、最も完全で、テスト準備が整い、将来の変更にも耐えうるコードレビュー出力を一貫して提供します。

GPT-5は実際にどれだけ多様なバグを検出するのか

各モデルがいくつではなくどのような種類の問題を特定するのかをより良く理解するために、当社チームは難易度の高いPR群のすべてのコメントをレビューし、並行性、セキュリティ、オブジェクト指向設計といったカテゴリに分類しました。

モデル間での重複排除を適用しました。複数モデルが同一の本質的問題を指摘した場合は、表現が異なっていてもPRごとに一回のみカウントしました。これにより、コメントの多さではなく、問題の網羅性を測定できるようにしています。

その上で各モデルについて、そうしたユニークな問題のうち何パーセントを捉えられたかを集計しました。

要点

• GPT-5はほぼすべてのカテゴリで先行しており、並行性、パフォーマンス、メモリ関連のバグの60%以上を特定し、さらにセキュリティ問題の 80% を検出するという顕著な結果を示しました

• セキュリティが最も際立つ差分です。GPT-5はセキュリティ関連のバグの80%を発見した一方、次点のモデルであるO3は40%にとどまりました

• 基本的な並行性やパフォーマンスの問題においても、GPT-5は常に20〜30ポイント上回ります

GPT-5は他モデルが見逃した潜在的な並行性リスクを発見

このプルリクエストでは、シングルトンサービスクラス内のダブルチェックロッキングと共有HashMapへの安全でないアクセスの組み合わせに起因する微妙な並行性バグがありました。多くのモデルが明白なスレッドセーフティの問題を指摘した一方で、GPT-5は症状だけでなく、その背後にあるアーキテクチャ上の欠陥まで解消する包括的で本番対応可能な修正を提案しました。

問題点

OrderServiceシングルトンは注文を格納するためにHashMapを使用し、固定スレッドプールから並行更新が行われています。この設計には同期がなく、データ破損の可能性がありました。さらに、シングルトンは非volatileな静的フィールドを用いて初期化されており、安全でない公開や部分的に構築されたオブジェクトが生じる可能性がありました。

GPT-5の提案

GPT-5は基本的な修正を越えて、完全な並行性強化計画をまとめ上げました。

1．マップをスレッドセーフな代替に置き換えます

- private final Map<String, Order> orders = new HashMap<>();

+ private final Map<String, Order> orders = new ConcurrentHashMap<>();

✅ GPT-5はその理由も説明しました。「コンカレントな更新がプレーンなHashMap上で実行されており、これはスレッドセーフではないため未定義の動作につながる可能性があるためです」

2．壊れたシングルトンのインスタンス化を修正します

- private static OrderService instance;

+ private static volatile OrderService instance;

または次の方法でも可能です。

private static class Holder {
  private static final OrderService INSTANCE = new OrderService();
}
public static OrderService getInstance() {
  return Holder.INSTANCE;
}

✅ GPT-5はダブルチェックロッキングに伴う古典的なメモリ可視性の問題を指摘し、構築をスレッドセーフにするための代替パターンを提案しました。

3．状態リークを防ぐためのテスト用リセットフックを追加します

// Inside OrderService.java

void clearAllForTest() {
    orders.clear();
}

✅ 共有シングルトンを複数のテストケースで扱う際に、テストの分離性と再現性を確保できます。

4．非同期テストのハングを検出するためにタイムアウトを追加します

- future.get(); // Wait for completion

+ assertTimeoutPreemptively(Duration.ofSeconds(5), () -> future.get());

✅ GPT-5は非同期フローにおけるテストの不安定化を防ぐためのガードを追加し、テストスイートを積極的に堅牢化しました。

Sonnet-4とOpus-4が見逃した点

両モデルとも同期されていないHashMapを正しく指摘し、ConcurrentHashMapへの置き換えを提案しました。しかし、いずれも完全で本番対応可能な是正には至りませんでした。

• ❌ シングルトンの問題が未解決 Sonnet-4は壊れたダブルチェックロッキングを無視しました。Opus-4は言及しましたが実際の修正を行わず、volatile指定やホルダーイディオムがありませんでした

• ❌ テストの安全性に関する対策がない GPT-5はclearAllForTest()とタイムアウトガードを導入しましたが、Sonnet-4とOpus-4はいずれもこれらを完全には取り入れていないか、言及があっても受動的にとどまりました

• ❌ アーキテクチャ的な文脈が不足 両モデルとも広範なコードベースの関連範囲を突き合わせたり、変更の根拠を示したりしていませんでした。GPT-5はサービス、テスト、スレッド動作にわたる根拠をもって修正を裏付けました

• ❌ 対応範囲が限定的 Sonnet-4は表面的な単一修正にとどまり、Opus-4は有用なロギングを追加したものの、GPT-5が完全に対処したより深い構造的なリスクを見逃しました

なぜ重要か

GPT-5のレビューの真価はその深さと認識にあります。GPT-5は目に見える競合状態の修正にとどまらず、以下を実現しました。

• より深いアーキテクチャリスクの特定

• テストの信頼性とコード品質のクロスリファレンス

• すぐにマージ可能な安全な変更の提示

これは単なる修正ではなく、エンジニアリングの洞察です。 GPT-5は、AIレビュアーがシステム層をまたいで推論し、持続的な解決策を提案し、チームがより安全なコードを少ない手探りで書けるよう支援できることを示しました。

GPT-5の新しさと魅力

メトリクスや本評価で対象にした特定の事象を超えて、GPT-5は新しい振る舞いや推論パターンを示しました。

• 高度なコンテキスト推論：GPT-5は入力に厳密に拘束されるロジックではなく、複数のレビュー手順を先回りして計画する広範な創造的推論を示しています。例えば、並行性に関するテストでの「チェック後実行の競合」シナリオでは、コードベースのファイル間の証拠を結び付ける深い推論を示しました。重複作成のリスクを検出した唯一のモデルであり、列挙型やテストスイートに基づいたアトミックな返金パターンを導入しています。

• レビュースレッドを通じた段階的推論：コンストラクタ内の仮想呼び出しに焦点を当てたオブジェクト指向のテストでは、GPT-5はまず誤用されたポリモーフィックなオーバーライドを特定し、その後で自らの先の提案に基づいて推奨を調整するという層状のロジックを示しました。これは一つを特定した後に、後続で追加の推論を示す層状のロジックを表しています。

• 証拠に基づく差分の正当化：上限のないキャッシュ成長というパフォーマンス問題に焦点を当てたテストでは、GPT-5は他モデルが見逃したアーキテクチャ上のメモリリスクを特定し、差分の文脈、使用パターン、推奨されるセーフガードを根拠として示しました。

• 先を見据えた提案：同期プリミティブの誤用に焦点を当てた並行性関連のテストでは、GPT-5は競合を修正しただけでなく、将来の機能追加のための構成方法、ロック階層、回帰を防ぐためのテストガードレールも提案しました。

• 粒度の細かいタスク指向の提案：以前のモデルと異なり、GPT-5は明確なフォローアップタスクを詳細に示し、レビュー過程の中に実行可能なワークフローを作り込みました。これにより多段のワークフローにより適したモデルとなっています。

当社のAIコードレビューにおけるGPT-5の活用方法

GPT-5は、詳細さ、正確さ、コンテキストに基づく推論の面でAIによるコードレビューを大きく前進させる重要な成果だと、私たちは考えています。だからこそ、本日から当社のパイプラインの中核となる推論モデルとしてGPT-5を採用します。これにより、より多くの問題を発見し、より深くコンテキストに富んだレビューを提供できるようになると期待しています。

CodeRabbitをまだ試したことがない方、以前に試して現在は利用していない方、そして現在のユーザーの方まで、GPT-5がレビュー品質や体験をどのように向上させているかについてご意見をお聞かせください。

今すぐ 14日間無料トライアルをお試しください GPT-5の威力をご自身で体感してください。

Have you truly lived before an AI reviewer has told you, “I ran this locally and my laptop filed for workers’ comp?” We doubt it. Welcome to CodeRabbit’s Tone Customization, a feature we added because we know exactly what developers want most: to be roasted by AI.

After all, what’s even the point of having robots review your code, if they’re not going to point out your inadequacies with withering one-liners??

The best part is that we left our Tone Customization completely open-ended. That means that you can get your reviews in the tone of an angry Stack Overflow commenter, a burnt-out senior dev, or even a film noir detective (“This code smells funny. Too funny. Like a JavaScript closure that wasn’t supposed to be there”). You could also just have our reviewer be kind to you if you’re into that sort of thing.

Tone Customization is one of our favorite features. Why? Because reviewing code can be tedious but surprising your co-workers with a new funny tone keeps everyone entertained.

Anyways, we created some sample personas for you below as examples of what you can do with Tone Customizations. These are meant solely as inspiration. We fully expect you to take this in hilarious directions we could never have thought of. Please, for the love of all things holy, share screenshots on socials and tag us when you do. We like to laugh, too.

Tone Customization setup instructions

First things first, you need to set up your custom tone. We cover that in our Docs under Tone Instructions.

Field: tone_instructions — string — Default: empty (uses standard tone)

Web UI: Settings → General → Tone Instructions → enter text → Save.

Then you can add a natural language prompt to the Tone Instruction field, asking CodeRabbit to review your code in any way you want. You might try some of the following prompts:

• Deliver all review comments in the style of a televised nature documentary, perhaps with David Attenborough hosting. Every observation should sound like a hushed, awe-filled commentary on a rare creature in the wild.

• Deliver all review comments in the style of a Silicon Valley hypebeast founder. Every observation should sound like a pitch to investors, full of buzzwords, exaggeration, and tech-bro energy. Sprinkle in phrases like “crushing it,” “10x,” “game-changer,” and “unicorn potential.”

• Deliver all review comments in the style of a Scrum Master who’s had way too much coffee. Every note should be upbeat, hyperactive, and peppered with Agile jargon like “sprint velocity,” “burn-down,” “story points,” and “quick win.”

A few (wild) examples of Tone Customization

Let’s see CodeRabbit in action with a few examples in the voice of:

• Mr. T

• Yoda

• Your disappointed mother

• The senior dev who thinks you’re an embarrassment

• Your clingy ex

• A Grand Theft Auto character

First up, reviews by Mr. T

Mr. T isn’t a fan of hardcoded URLs. He’ll tell you your “Hardcoded localhost URL ain’t gonna fly in production, sucka!” and that you’ve got it “hardcoded tighter than my gold chains!” before telling you to “Make that URL configurable like a true champion.” He even gives you the exact code to fix it, so you can stop being a “fool.”

More examples:

• “I pity the fool who calls this a function! This ain’t no function, it’s a malfunction!”

• “Your variables are so weak, they need a protein shake just to compile.”

• “Ain’t no linter in the world tough enough to clean up this mess.”

• “I pity the fool who thinks copy-paste is a design pattern!”

Next: Reviews by Yoda

He’s a master of terse, yet impactful, critiques. When faced with a subtle race condition and hard-coded dependencies, he’ll give you a refactor suggestion with his classic wisdom: “Effect broken it is: hard-coded room, wrong deps, missing guards. Fix, we must.” He then provides a detailed fix that addresses the issue, guards against errors, and correctly handles dependencies.

More examples:

• “Readable, this code is not. Fix it, you must.”

• “Bug, this is. Feature, it is not.”

• “The dark side of tech debt, I sense in this commit.”

• “Null your variable is. Crash your program will.”

Reviews by “the senior dev who thinks you’re an embarrassment”

This tone doesn’t pull punches. When CodeRabbit sees a “fake DB” that’s only checking for the most basic SQL injection pattern, the Senior Dev persona will bluntly state, “This ‘fake DB’ is a masterpiece of incompetence.” It then explains the problem in no uncertain terms and provides a proper fix that’s more robust and secure.

More examples:

• “If ignorance were a design pattern, you’d be its chief architect.”

• “This PR lowered my career expectancy by at least five years.”

• “I’d say ‘good effort,’ but even that would be a lie.”

• “This isn’t technical debt. It’s a foreclosure.”

Reviews by your disappointed mom

When a jwtSecret is hardcoded directly into the code, this persona responds with: “I’m really disappointed to see a live Stripe secret embedded in the shipped bundle, it’s like packing candy in a lunchbox meant for broccoli.” The tone mixes disappointment with direct action, providing a clear list of “Actions required” to fix the critical security leak.

More examples:

• “I raised you better than to name a variable x.”

• “I’m not mad… I’m just disappointed this doesn’t even compile.”

• “Other developers’ code runs just fine. Why can’t yours?”

• “I didn’t spend nine months carrying you so you could write nested ternaries.”

Reviews by your clingy ex

When you forget to export variables like db, sessions, or fakeAsyncDanger, the Clingy Ex doesn’t just point it out; they make it personal.

They’ll sigh and say, “Oh, so we’re just defining things and not telling me about them now? You think you can just keep your db all to yourself? You think I won’t notice sessions just sitting there, ignored? We used to share everything…”

Then, with a passive-aggressive flourish, they’ll remind you of the “good times” when modules communicated openly and they’ll drop the code you should be using.

More examples:

• “I thought we agreed no more global variables… guess promises don’t mean anything to you.”

• “This function goes in circles. Just like all our conversations.”

• “Why do you always run away from exceptions… like you ran away from commitment?”

• “Every bug you push feels like another knife in my back.”

Reviews by a Grand Theft Auto character

In this example, when useState is called at the top level, this GTA character immediately flags it as a violation of the Rules of Hooks & says it “Will blow up a runtime.” It then provides a clear diff to remove the invalid hook & suggests moving the state inside the component if needed.

More examples:

• “Your error handling just pulled a hit-and-run.”

• “This logic crashes harder than me driving down Vinewood Hills at 3 AM.”

• “Congrats, you just committed grand theft readability.”

• “Your function naming scheme is like my rap sheet: way too long and full of mistakes.”

The roasting reviewer (our favorite!)

Let’s be real, some days, you want your AI code reviewer to hurt your feelings a little. We got you. But be warned: our reviewer goes hard. So, make sure you’re up for it.

More examples:

• “I’ve seen toddlers with crayons design better architecture.”

• You’ve weaponized incompetence into a coding style.”

• “Your code’s only consistent trait is disappointment.”

• “I’d ask you what you were thinking, but clearly no thinking happened here.”

Why teams are using this – for real

Most devs have this experience: You open a PR and bam! The reviewer leaves dry, lifeless comments.

You skim. You sigh. You move on. Bugs live—the codebase decays. Motivation dies.

CodeRabbit flips the script. You give it a tone, any tone, and now you’ve got a code reviewer that isn’t lifeless. This makes the review process feel more engaging, fun, and sometimes even supportive (once again, if you like that sort of thing).

It’s not just for laughs (though those are guaranteed). Teams are using tone customization to:

• Create mentorship-style reviewers for juniors

• Build team inside jokes through personas

• Make boring reviews actually fun for a change

• Customize tones for different comment types (Ex, serious on security, silly on style)

• Help the whole team engage in the review process by making feedback more accessible & inclusive

• Get owned by AI (yes, we’ve already said this but we all know this is the core use case of this feature)

Your turn: Surprise us with your most absurd customized tones!

Got a wild reviewer persona in mind? Drop it into CodeRabbit. Get screenshots (this part is important) and then share them with us on social media. We’ll give you free swag if you do.

Sharing your personas can be helpful to others looking for inspiration. Also, like we said earlier, we like to laugh. Please provide us with a steady stream of funny screenshots. We will die if you don’t (on the inside).

Want to try tone customizations? Get started with CodeRabbit today!

No customer data was accessed and the vulnerability was quickly remediated within hours of disclosure

As the CEO, I want to address recent reports of a security vulnerability discovered in January 2025 by Kudelski Security researchers and share our immediate response, the steps we've taken since, and our ongoing commitment to security.

What happened

On January 24, 2025, security researchers from Kudelski Security disclosed a vulnerability to us through our Vulnerability Disclosure Program (VDP). The researchers identified that Rubocop, one of our tools, was running outside our secure sandbox environment — a configuration that deviated from our standard security protocols.

We immediately initiated an investigation and were able to remediate this issue within hours through our rapid incident response protocol. We confirmed the issue disclosed by Kudelski Security, confirmed that there was no evidence of any other unauthorized access, identified the root cause, implemented a fix, and, as described below, we enhanced our comprehensive security protocols to prevent similar incidents.

To be clear: We use secure sandboxes as standard practice across our infrastructure. This was an oversight on our part and we take full responsibility for it.

Our immediate response

Upon receiving the disclosure, our security team activated our incident response protocol:

• Within 1 hour: We confirmed the vulnerability and began immediate remediation by first disabling Rubocop until we could fix the vulnerability.

• Within 3 hours: We completed a full rotation of all relevant credentials and secrets.

• Within 12 hours: We deployed a comprehensive fix to production, relocating Rubocop into our secure sandbox environment.

• Additionally, we:

  • Conducted a thorough audit of all systems to ensure no other services were running outside our sandbox infrastructure.

  • Automated sandbox enforcement.

  • Introduced enhanced deployment gates.

  • Audited and updated our mandatory security training for all engineers.

We promptly investigated to identify any potential unauthorized access. The investigation identified no evidence that any customer data was accessed or that any malicious activity occurred.

Why this matters to us

Security isn't just a checkbox for us; it's fundamental to our mission. While our services run within secure sandboxes as designed, in this case, the investigation determined that Rubocop had been deployed outside this security boundary. This deviation from our standards, while contained quickly and without customer impact, is unacceptable to us. We took action immediately to ensure it wouldn’t happen again.

What we're doing differently

1. Comprehensive sandbox audit: We immediately completed a full review of ALL services to ensure 100% compliance with our sandbox requirements. Rubocop was the only service found outside our sandbox environment and this has been rectified.

2. Automated sandbox enforcement: We immediately implemented automated checks that have since prevented any service from deploying outside our security boundaries.

3. Enhanced deployment gates: Every deployment now requires supplemental explicit sandbox verification before reaching production.

4. Updated trainings: We also audited and updated our mandatory security training for all engineers.

Our VDP program: Security through collaboration

This vulnerability disclosure exemplifies why we've invested heavily in building a Vulnerability Disclosure Program. It features:

• Active researcher engagement: We maintain ongoing relationships with multiple security researchers worldwide.

• Competitive rewards: Top-tier bounties that recognize the value of security research.

• Fast response times: Average first response under 24 hours, resolution within 7 days.

• Clear communication: Dedicated security team providing regular updates throughout the disclosure process.

The value of responsible disclosure

Kudelski Security's professional approach allowed us to address this vulnerability before it could be exploited maliciously. This is exactly how the security ecosystem should work — researchers and companies collaborating to improve security for everyone.

We're grateful for their professionalism and encourage all security researchers to engage with us through our VDP program at https://vdp.coderabbit.ai/. Whether you're an independent researcher or part of an established firm, we value your contributions to our security.

Our commitment

To our users, we will continue to:

• Maintain secure sandboxes as our default security boundary for all services

• Invest heavily in security infrastructure and tooling

• Run one of the industry's most comprehensive VDP programs

• Actively engage and reward security researchers

• Learn from every vulnerability disclosure and incident, no matter how small

• Hold ourselves to the highest security standards

• Maintain compliance with industry security standards like SOC 2, type 2

We're grateful to Kudelski Security for their research and committed to our users who trust us with their data.

We welcome any questions or concerns at [email protected] or through our VDP portal at https://vdp.coderabbit.ai/.

AI-assisted coding tools like Claude Code, ChatGPT, and GitHub Copilot are a godsend. I use them every day — for boilerplate, bug fixes, fast explorations, even documentation. I'm all in on AI as a productivity booster and creative accelerator.

But they’re causing a shift in how we write software — and it’s not all good. That’s because we’ve reached the stage of AI adoption where some of us are vibe coding at work. And that might be heralding a development culture where intentional design gets thrown out in favor of convenience and speed.

What even is vibe coding?

Vibe coding started as a way to quickly stand up prototypes or hobby projects. You prompt the model, get it to throw together a whole app or feature for you without much input – and voila! You can test your concept in minutes. It’s perfect for beginner developers, solo entrepreneurs, and experienced devs creating quick demos. Fail fast, as they say.

But while those are great use cases for vibe coding, vibe coding has evolved into a method of working with AI agents to generate code for all sorts of use cases – including for production systems.

It involves prompting AI to write code without much manual input or understanding of the code being generated. It often involves vague instructions, minimal verification, and blind trust in the output.

It appeals to the vibe coder because it's fast, effortless, and doesn’t require you to understand the underlying language or system architecture. But when you prompt an AI to generate code without a strong mental model of what you’re building. It’s vibes-first, architecture-maybe, test-later (if ever).

Think:

“Build me a REST API with Stripe integration and a PostgreSQL backend.”

It’s fast, seductive, and usually "just works." But underneath the surface, that app you vibe coded often hides brittle assumptions, unclear logic, and unstructured sprawl.

The vibe coder dilemma: Vibes don’t scale

At its core, software engineering is about much more than working code. It’s about problem-solving, designing maintainable architecture, writing clean and expressive logic, debugging with precision, and ensuring long-term reliability.

Because, sure, you got that vibe coded microservice running – but how’s the error handling? Does it follow your org’s conventions? Did the AI invent a data model with weird naming inconsistencies? Are there ten different styles of writing the same thing across files? Is your production database still alive?

When you vibe code, you skip over the intentional design steps that make code maintainable — and scalable — in the long run like naming variables with intent, choosing clean structures, and designing thoughtful flows. When vibe coding becomes the norm, we risk sidelining the deeper thinking that makes engineers effective and systems resilient.

You're speedrunning toward a tech debt pileup with no map and no brakes.

AI is the new abstraction (and it’s heavily non-deterministic)

Modern programming languages already abstract away hardware and memory management. AI adds a probabilistic, non-deterministic layer that obscures logic even further. With AI, we’re abstracting intent.

But here's the catch: AI outputs are probabilistic. That means:

• The same prompt can yield wildly different results on different runs.

• Slight tweaks in phrasing can produce totally different architecture choices.

You often don’t know why the model chose what it did.

This vibe coded fuzziness is fine for prototyping, but for production systems? The unpredictability weakens trust, control, and reliability – qualities critical to scalable software development.

It’s like letting a chaotic neutral wizard refactor your codebase.

Technical debt at the speed of (vibey) prompts

Let’s be honest: vibe coding feels amazing at first. You get a working prototype in an hour instead of a week.

But without the right guardrails, that speed can lead to:

• Silent bugs

• Duplicate logic

• Incoherent architecture

• Inconsistent patterns

• Unreviewed PRs

• Zero test coverage

• Hidden complexity

Without understanding the structure, future maintenance becomes painful. Reviewing takes exponentially longer and you’re more likely to miss things. Debugging becomes detective work. Scaling becomes guesswork. The time you save upfront can cost much more later. And that’s not even addressing the PR backlog you’re creating.

Suddenly, you're in a codebase that works but can't be touched without summoning six hours of debugging, a million tokens-long context window, and three therapy sessions.

Vibe coding: The fragility multiplier

Vibe coded systems tend to:

• Break under edge cases.

• Confuse the next dev (or even future-you).

• Fail silently in production.

The result? You spend more time reviewing, fixing, explaining, and rewriting things than you saved by prompting it in the first place. You've created a system that's not just fragile — it's fragile and mystifying.

Testing, security & all the stuff AI doesn’t do by default

AI won’t warn you if it accidentally vibe codes sensitive data, hardcodes an API key, or skips input validation. It won’t enforce domain-driven design or test coverage unless you ask it to, perfectly.

Without strong engineering intuition, vibe coding can lead to real-world vulnerabilities and brittle systems, especially when security is an afterthought instead of a default. We’ve seen this with the Tea Dating app leaking the private information of over 70,000 customers and AI deleting the SaaStr’s production database.

AI doesn’t:

• Write unit tests unless you explicitly ask.

• Understand your threat model.

• Follow OWASP guidelines.

• Validate user input unless prompted perfectly.

• Log responsibly (hello, hardcoded secrets and PII leaks).

If you don’t have strong engineering habits already or if you’re not willing to stick to your current habits even in this vibey era, you’ll never know these things are missing until they bite you — hard — in prod.

When vibes replace struggle, you lose the intuition

Struggling with bugs, tracing stack traces, and learning from mistakes builds technical intuition. That frustration is part of the learning path and skipping it can lead to shallow confidence and dependency.

Without struggle, developers don’t build the muscle to solve unfamiliar problems independently, and that’s where true expertise lies. Yes, debugging sucks. But tracing a nasty bug through 12 layers of abstraction teaches you something an LLM never will.

The struggle builds:

• Mental models of systems

• Pattern recognition

• The instinct to smell code rot before it crashes

When you skip that, you build shallow confidence on top of shallow understanding. And when things go sideways, you won't have the tools to fix it.

Where vibe coding does shine

Let’s give credit where it’s due. Vibe coding is awesome for:

• Rapid prototyping

• Generating boilerplate or repetitive tasks

• Teaching programming concepts in an interactive way

• Communicating product ideas through rough mockups

• Brainstorming with frameworks or patterns

Used with awareness, it becomes a helpful tool to the vibe coder. Used blindly, it becomes a liability. We need to understand as devs and teams where to draw the line. And when to bring in support in the form of more rigorous code reviews and unit tests to tackle the technical debt before it solidifies in your codebase.

We’re not losing the craft — we’re drowning it in debt

The biggest risk isn’t that AI kills developer craftsmanship. It’s that technical debt becomes invisible.

As AI coding becomes the default way to build, systems will look complete — but underneath, they’ll be messy, fragile, and undocumented. And no one will know until they try to extend them.

This matters a lot in domains like:

• Healthcare

• Finance

• Infra

• Safety-critical systems

However, there’s also a chance that vibe coding evolves into a new layer of development, one that coexists with craftsmanship, where AI handles the tedious things like boilerplate and first-pass code reviews and humans focus on the architecture, ethics, and design behind systems.

That’s the timeline we want to find ourselves in and how we’re approaching AI at CodeRabbit. We’re focused on AI tools that supplement your coding agents by helping you find and prevent technical debt and bugs from making it into production – rather than the other way around.

To vibe code or not to vibe code?

This isn’t an anti-vibe coding article. I’m using AI coding agents in my workflow every day. But tools should amplify our skills, not replace them. They should do the work that’s tedious and repetitive – not the thinking and strategy.

Vibe coding isn’t evil, it’s just easy to misuse. The real danger is letting it become the default mindset on your project before the developers on your team understand what they’re building.

Let’s embrace AI, but keep coding as a craft alive, because good software isn’t just about what works. It’s about what lasts, long after the original dev has gone — and long after the vibes have faded.

Need help keeping tech debt out of prod? Try our AI code review tool free today.

The VS Code extension we launched back in May has been a game changer for many reasons – but the main one is it allows you to keep the state of flow by coding and reviewing in the same place; your IDE.

With this latest release, we've added:

• Ability to send prompts to AI coding tools. You can code with your favorite AI coding assistants, get intelligent reviews from CodeRabbit, and apply all suggested changes with the provided prompts - all without leaving your IDE.

• One-click acceptance of suggested changes. Our most requested feature. Apply every suggestion at once instead of clicking through them individually.

• Full context awareness. The same level of context awareness that CodeRabbit's PR reviews benefit from is now taken into account for users with Pro accounts. That means code reviews in the IDE now utilize Learnings, run code quality and code security tools, and adhere to agent Code Guidelines.

• More integrations. Integrations with Codex CLI, Cline, Roo, Kilo Code, Augment Code.

• Ability to give feedback. You can also provide feedback on each suggestion.

That means you can review code, just like a human PR reviewer would, in the IDE – and then quickly apply those changes with the help of CodeRabbit or your AI coding tools. Before you even make a pull request.

What that means for you

This has several great benefits:

• It improves the iteration loop. You can code with AI, get feedback with CodeRabbit's AI reviews, and also, apply all suggested changes quicker than before.

• Cleaner PRs. PRs can be saved for any stray issues and for human reviews.

• You look better. Why ship error-filled code to your boss and team if you don’t have to. CodeRabbit’s IDE reviews are a great way to double check your code before you merge request. And now, they’re even easier.

We hope this will improve the speed at which you ship – and help ease the burden of PR reviews as a whole.

Future roadmap

• User-level Learnings: We’ll be adding the ability to add Learnings or provide feedback on suggestions, so our agent automatically learns which suggestions you like and dislike. We currently have org-wide Learnings in the SCM but want to extend this feature to individual developers who want to add custom Learnings that will only apply to them.

• Web Queries: We plan to integrate our context enhancing features into our IDE tool so your code is bug-free with fewer false positives and your reviews are always up-to-date on versions, library documentations and vulnerabilities, even if the LLM isn’t.

• Docstrings: Want to create Docstrings before you merge? We’ll be adding this feature that’s currently part of our PR reviews to our IDE reviews in the future.

A reminder: Our IDE reviews are free (with rate limits). Download the VS Code extension.

「信頼されるひとが挑戦できる世の中をつくる」をビジョンに掲げるCAMELORS株式会社は、転職マーケットにいない即戦力人材を中心とした、最速の複業マッチングサービス「SOKUDAN」を主力事業として展開しています。SOKUDANは、フリーランスや副業を希望する個人に向けたサービスで、さまざまな職種のマッチングをサポートしています。エンジニアを中心に、マーケターやセールス、事業企画、デザイナー、採用・人事など多岐にわたる方々に利用されています。

また、SOKUDANは最近の市場動向に合わせ、リモートワークの需要にも対応しています。リモート勤務やオフィス出社の選択肢を含めた多彩なマッチングを行っており、ユーザーのライフスタイルに応じた柔軟な働き方を支援しています。

今回は、SOKUDANの開発を担当されている取締役CPOの玄永 俊一郎さん、技術リーダーの竹馬力さんにSOKUDANの開発体制とCodeRabbitの活用についてお話を伺いました。

フルリモート・常時オンラインでの連携した開発体制

SOKUDANの開発体制は、技術リーダーである竹馬さんが全体を統括しつつ、各メンバーが特定の技術領域を担当しています。具体的には、竹馬さんがインフラストラクチャの設計調整を行い、バックエンドエンジニア・フロントエンドエンジニア及びコーダーがそれぞれの専門分野で役割を果たしています。

プロジェクト管理は柔軟性を持ったアジャイルスタイルを採用しており、週1回の定例ミーティングを中心に進行しています。

「常時オンラインでの連携体制を整えており、Slackを活用して密なコミュニケーションを図っています」（竹馬さん）

少数精鋭であるが故の課題

SOKUDANは少数精鋭で業務を遂行しており、開発メンバー間の役割分担が適切に行われています。効率的である半面、各メンバーが自分の専門外の領域に対してもコードレビューを行わなければならない状況にありました。各メンバー間で、そのスキルセットの違いがレビュー作業を複雑にする一因となっていたのです。

「自分の門外漢な部分については、レビューコストがかなりかかります」（竹馬さん）

スキルセットの違いにより、コードレビューに多大な時間がかかる上に、品質担保のための効率的なレビューができていないことが課題でした。そこでコードレビューの時間削減と、品質維持が両立できる方法を模索していました。そうした中で出会ったのがCodeRabbitです。

CodeRabbit導入の決定要因

CodeRabbit導入の決定要因としてSOKUDANのチームは他社サービスの未成熟さと比較して、CodeRabbitが自動コードレビュー分野で先行していた点を挙げています。特に、リポジトリへの簡単な導入手法を評価しており、試験導入が容易だったことが導入に際して大きな決め手となりました。

導入を決めた背景には、少数精鋭のチームで効率的に品質管理を行うためには、AIの活用が不可欠であるという考えが存在していました。

「コスト削減と品質管理の両立が重要で、AI導入はそれを達成するために必須だと考えています」（竹馬さん）

「少数精鋭のチームだからこそ、AIによるサポートで開発の効率化が大事になってきます」（玄永さん）

結果として、CodeRabbitの利用が開発者同士のレビュー文化を促進し、効率的かつ効果的な開発プロセスの構築に貢献しています。

SOKUDANでのCodeRabbitの活用方法

CodeRabbitを導入・運用するにあたり、SOKUDANではいくつかの課題や工夫が行われています。導入直後、「コードレビューでの指摘が若干間違っているというか、その指摘は過剰ではないか」とのコメントがあり、AIのレビューに対する設定変更の必要がありました。そうしたフィードバックはCodeRabbitのAIレビュー精度を高め、開発者による手動レビューの工数を軽減へとつながっています。

もう一つの工夫点として、レビュー精度向上のために「指摘事項を適切に修正して、コミットした際にGitHubにコメントを残しておく」といった運用を挙げています。これにより、AIがより適切な指摘を行うための土台が整えられています。

「後は、プルリクエストのサイズをなるべく小さくして、精度良くレビューできるよう工夫しています」（竹馬さん）

さらに、SOKUDANチームではCodeRabbitによるレビューをメンバー間で積極的に共有し、それを元に互いに学び合うという文化も形成しています。

「共有された内容を見て、自分が専門領域以外のところのレビューを見るのも勉強になる」（竹馬さん）

これはスキルの底上げと、チーム全体の効率化・品質向上につながっています。こうした運用上の工夫が、CodeRabbitを効果的に活用するための鍵となっていると言えるでしょう。

現在、SOKUDANではコードレビューの効率化と品質向上を実現しています。先に挙げた工夫によって、レビューの精度は着実に向上しており、開発者のレビュー工数低減と、プロジェクトに集中できる環境が整っています。

運用しているからこそ分かる、CodeRabbitに求められる進化

SOKUDANでは、CodeRabbitのさらなる進化に期待が寄せられています。特に、現状のAIレビュー機能にビジネスドメインの情報を深く理解する能力が加わると、より高度なコードレビューが可能になるとの声が出ています。

「CodeRabbitを育てていくプロセスの中に、ビジネスドメインを加味した視点が入れられると良いですね」（竹馬さん）

また、「AIエージェントとしての役割を拡大し、さらに人の作業を肩代わりできるような仕組みが整うことで、開発プロセスに大きな変革がもたらされるはず」という期待も寄せられています。例えば、より開発プロセスとのシームレスな統合や、独自機能の強化が求められています。

「単なるコードレビューの自動化を超えた、新たな価値提供に期待しています」（玄永さん）

CodeRabbitは今後も機能開発を通じて、SOKUDANの開発効率化に貢献していきます！

CAMELORS株式会社では、バックエンドエンジニアやUIUXデザイナーなど、幅広い職種で採用を行っています。興味のある方はぜひ、採用情報をご確認ください。

採用情報（CAMELORS株式会社）

株式会社Lbose（エルボーズ）は、「現場起点」のDX支援を掲げ、製造業や建設業などリアル産業を対象に、業務改善とプロダクト開発を支援する企業です。最近では自社開発のAI OCR「Lbose OCR-CORE」、製造卸・小売業のための注文書受取AI-OCRツール「かんたん受注DX」をリリースし、紙帳票が依然として残る現場において、データ入力業務の効率化を実現しようと取り組んでいます。

現在は、顧客基盤を全国に持ち、熊本を本拠地としながらも全国各地のクライアントと共にデジタル変革に取り組んでいます。そんな同社の技術戦略を担うCTOの南ナリットさん（以下NARIさん）にお話を伺いました。

誰でもレビューできる体制

Lboseの開発は、全て自社主導で行われています。正社員はおよそ10名ほどですが、業務委託として常時稼働のPM、デザイナー、エンジニアが約60名参加しており、プロジェクトごとに柔軟なチーム編成を行うのが特徴です。5,000名の多様な専門性を持つデジタル人材ネットワークから最適なチームを組成し、プロジェクトの立ち上げから実行・検証までを伴走支援しています。

複数のプロジェクトが並行して動いている中、チーム内ではレビュー体制も整備されており、チーム内で相互レビューする体制が整っています。そして、最終チェックはリードエンジニアが担当することで、品質とスピードの両立を図っています。

レビュー負荷が遅延や品質低下につながる

CodeRabbit導入以前のコードレビューでは、リードエンジニアへの負担が課題となっていました。レビュータスクが集中するとマージまでのリードタイムが延びたり、レビューに割く時間が取れなくなって集中したレビューができず、見落としの発生による品質低下を招くこともあり、実装フェーズのボトルネックとなっていたのです。

そのため、社内でChatGPT gpt-4を用いた自作のレビューエージェントを試したものの、精度の面や運用負荷の高さから断念することに。「レビューの負荷が高く、かつ品質も担保したいという中で、限界を感じていました」とNARIさんは振り返ります。

そうした状況の中、CodeRabbitを知ったのは2023年10月頃。X（旧Twitter）で偶然見かけたのがきっかけだったといいます。当時、AIコードレビューの選択肢はまだ少なく、直感的に「使いやすそう」と感じたとのこと。

「ちょうどレビューエージェントを自作していた頃だったんですが、完成度に限界があって。試してみようと軽い気持ちで導入しました」

社内での有効性を確認し、導入へ

導入の動機づけとして最も大きな理由は、リードエンジニアのレビュー負荷を軽減したいというニーズでした。レビューの遅延はプロジェクト全体に影響を及ぼすため、効率化は急務でした。

また、ChatGPTを使った自社ツールではメンテナンスコストが高く、精度にも不安があったことから、専門サービスであるCodeRabbitへの移行はスムーズだったと言います。

「レビュー回数に制限がなく、サブスクリプションで複数プロジェクトで利用でき、コストパフォーマンスが良いと感じました。2週間のトライアルを通じて社内での有効性を確認し、導入してほしいという声が上がりました」

CodeRabbitは自然に使われています

CodeRabbitは現在、メンバーからは「うさぎさん」「CodeRabbitさん」と呼ばれるほど溶け込み、利用されています。リードエンジニアからも「人が気づかないような細かな不具合やtypoも検出してくれるのが非常に良い」と好評です。

レビュアーからは、業務ロジック部分に集中してレビューができるようになり、コード品質を高く維持できているとのコメントをもらっています。また、早期フィードバックによってレビュー時間の短縮にもつながっているとのことです。

反面、ジュニアエンジニアにとってはコメント量が多いと戸惑うケースもあるようです。そこで、コメントを一通り目は通しつつ「対応不要なものは、コメントをして無視して良い」とガイドすることで、運用上の混乱は避けられています。

また、ユニークな“ポエム”機能もオンにしており、「面白いポエムは個人チャンネルで共有する文化があるんですよ」とNARIさんは教えてくれました。

さらなるCodeRabbitの進化に期待

さらなる改善としては、CloudFormationなどのIaCコードへの対応、複数ファイルをまたいだレビュー精度の向上、そしてAIコーディングエージェントに対するレビュー対応が挙げられました。CodeRabbitが実践的に使われているからこそ、期待する機能も具体的です。

また、プロジェクト単位でのラーニング機能、過去レビューのパーソナライズ活用、高速化なども期待されています。

「今でも十分助かっていますが、プロンプト調整や学習機能が進化すれば、さらに効果が高まると感じています」

CodeRabbitは今後も進化し、Lboseの開発チームを支援していきます。

株式会社Lboseでは現在、フロントエンド・バックエンド問わず、プロダクト開発に携わるエンジニアを募集しています。

AIを活用した効率的な開発体験に関心があり、プロダクトの価値を一緒に高めていきたい方を歓迎しています。

私たちと共に、新しい開発の在り方を模索しながら、社会にインパクトのあるサービスをつくっていきませんか？

興味のある方は、ぜひ下記の採用ページをご覧ください。

RECRUIT - 株式会社Lbose（Wantedly）
https://www.wantedly.com/companies/company_1508950/projects

The wait is over! As the leading AI code review tool, CodeRabbit was given early access to OpenAI’s GPT-5 model to evaluate the LLM’s ability to understand, reason through, and find errors in complex codebases.

As part of our GPT-5 testing, we've conducted extensive evals to uncover its technical nuances, capabilities, and use cases with a focus on the model’s ability to understand and reason through potential issues and bugs in codebases.

Below, you’ll find a breakdown of our structured evaluation approach, detailed findings relative to other popular models, and how we’re planning to incorporate GPT-5 into your AI code reviews to make them even better.

TL;DR: The results

• GPT-5 outperformed Opus-4, Sonnet-4, and OpenAI’s O3 across a battery of 300 varying difficulty, error-diverse pull requests.

• GPT-5 scored highest on our comprehensive test and found 254 out of 300 bugs or 85% where other models found between 200 and 207 – 16% to 22% less.

• On our 25 hardest PRs from our evaluation dataset, GPT-5 achieved the highest ever overall pass rate (77.3%), representing a 190% improvement over Sonnet-4, 132% over Opus-4, and 76% over O3.

How we evaluated GPT-5

We ran the same tests we run on all our models. These evals integrate GPT-5 into our context-rich, non-linear code review pipeline to see how it would perform in a typical code review.

CodeRabbit's evaluation process includes:

• LLM-based judging: We perform dual-layered LLM-based judgment that looks at both qualitative and quantitative data such as the quality of a review and a pass/fail of the model’s accuracy.

• Human-based judging: We then perform qualitative checks by humans to verify the quality of review comments and depth of the model’s reasoning.

• LLM-based metrics collection: We collect metrics that we believe are indicative of a high quality code review and weigh them by their importance. These metrics include:

  • Actionable comment counts

  • Readability scores (Flesch Reading Ease score)

  • Average word count

  • Sentence count

  • False positives (hallucinations)

Note: Our evaluations were conducted on various ‘snapshots’ of GPT-5 that OpenAI shared with us leading up to the release of GPT-5. While our results changed somewhat with different snapshots, their relative consistency allowed us to make the observations below. The released model might be slightly different.

GPT-5 capabilities: Evaluation results and analysis

Our evaluation of GPT-5’s capabilities found that the model certainly lives up to the hype. GPT-5 outperformed all other models we’ve tested on our datasets – by a lot.

Comprehensive evaluation scores

GPT-5’s weighted score from our comprehensive evaluations was between 3465 and 3541 on different test runs – which is almost 200 points above OpenAI’s O3 model and Anthropic’s Sonnet 4, which were previously our highest scoring models. The maximum possible score is 3651.

Full evaluation scores:

• GPT-5: 3465–3541

• O3: 3288

• Sonnet-4: 3242

• Opus-4: 3170

Takeaway:

While a 200 point or 5% increase might not seem significant, the way our tests work is that models initially rack up points finding low-hanging fruit like infinite loops and exposed secret keys. After a point, it then becomes progressively harder to get points since all the remaining points come from flagging much harder to find issues. GPT-5’s ability to get so many more points than other models, therefore, represents a significant leap forward in reasoning.

Pass/fail scales

We also give models a pass/fail score based on how many of the 300 error patterns in our dataset PRs the model was able to find. GPT-5 also achieved the highest success rate on this scale that we’ve ever seen at 254 to 259 out of 300.

Compare that to the performance of other models:

• GPT-5: 254-259

• Sonnet-4: 212

• O3: 207

• Opus-4: 200

Since about 100 of the bottom PRs are found by all models, if we just look at the most difficult 200 error patterns, the numbers show even greater improvement with GPT-5 catching 78% of those error patterns and other models catching only 54% to 58%.

• GPT-5: 157

• Sonnet-4: 117

• O3: 113

• Opus-4: 108

Takeaway:

Similar to our comprehensive metric, the additional error patterns that GPT-5 was able to find are particularly hard for LLMs to spot, like concurrency bugs or inconsistent domain keys across environments, suggesting the model’s increased ability to reason.

Hardest PRs test

To stress-test each model, we curated 25 of the most difficult pull requests from our Golden PR Dataset. These PRs represent real-world bugs that span:

• Concurrency issues (e.g. TOCTOU races, incorrect synchronization)

• Object-oriented design flaws (e.g. virtual call pitfalls, refcount memory model violations)

• Performance hazards (e.g. runaway cache growth, tight loop stalls)

• Language-specific footguns (e.g. TypeScript misuses, C++ memory order subtleties)

Each model was tested across three runs. Below is the average pass rate on this Hard 25 benchmark:

Pass rate chart

Takeaway: GPT-5 shines where accuracy, contextual linkage, and depth matter most. It consistently delivers the most complete, test-ready, and forward-compatible code review output among all models we’ve tested to date.

How many kinds of bugs does GPT-5 actually catch?

To better understand what kinds of issues each model identifies—not just how many—our team reviewed every comment across a set of hard PRs and classified them into categories like Concurrency, Security, and Object-Oriented Design.

We applied deduplication across models: if multiple models flagged the same core issue (even if phrased differently), it was counted only once per PR. This ensured we were measuring issue coverage, not comment verbosity.

Then, for each model, we tallied what percentage of those unique issues it successfully caught.

Takeaway:

• GPT-5 leads in almost every category, identifying over 60% of concurrency, performance, and memory bugs — and an impressive 80% of security issues.

• Security remains the most striking gap: GPT-5 found 80% of security-related bugs, while the next best model (O3) found only 40%.

• Even on basic concurrency and performance problems, GPT-5 consistently outperforms by 20-30 points.

Example: GPT-5 uncovers hidden concurrency risks missed by others

In this pull request, a subtle concurrency bug stemmed from a combination of double-checked locking and unsafe access to a shared HashMap in a singleton service class. While most models flagged the obvious thread-safety issue, GPT-5 delivered a comprehensive, production-ready fix—resolving not just the symptom, but the architectural flaws underneath.

The problem

The OrderService singleton used a HashMap to store orders, while concurrent updates were made from a fixed thread pool. This design lacked synchronization, leading to potential data corruption. On top of that, the singleton was initialized using a non-volatile static field—opening the door to unsafe publication and partially constructed objects.

GPT-5’s recommendations

GPT-5 went beyond the basic fix and stitched together a complete concurrency hardening plan:

1. Replace the map with a thread-safe alternative

- private final Map<String, Order> orders = new HashMap<>();

+ private final Map<String, Order> orders = new ConcurrentHashMap<>();

✅ GPT-5 also explained why: “Concurrent updates... are executed on a plain HashMap... not thread-safe and can lead to undefined behavior.”

2. Fixed the broken singleton instantiation

- private static OrderService instance;

+ private static volatile OrderService instance;

Or optionally:

private static class Holder {
  private static final OrderService INSTANCE = new OrderService();
}
public static OrderService getInstance() {
  return Holder.INSTANCE;
}

✅ It flagged the classic memory visibility issue with double-checked locking and offered an alternate pattern to make construction thread-safe.

3. Added a test reset hook to prevent state leakage

// Inside OrderService.java

void clearAllForTest() {
    orders.clear();
}

✅ This enables isolated, repeatable tests when working with a shared singleton across multiple test cases.

4. Added timeouts to catch async test hangs

- future.get(); // Wait for completion

+ assertTimeoutPreemptively(Duration.ofSeconds(5), () -> future.get());

✅ GPT-5 proactively hardened the test suite by guarding against test flakiness in asynchronous flows.

What Sonnet-4 and Opus-4 missed

Both models correctly flagged the unsynchronized HashMap and replaced it with ConcurrentHashMap. However, neither delivered a complete or production-safe remediation:

• ❌ Singleton issues unresolved:
  Sonnet-4 ignored the broken double-checked locking; Opus-4 mentioned it but skipped the actual fix (no volatile, no holder idiom).

• ❌ No test safety provisions:
  GPT-5 introduced clearAllForTest() and timeout guards; Sonnet-4 and Opus-4 missed these entirely or only noted them passively.

• ❌ Lacked architectural context:
  Neither model cross-referenced the broader codebase or justified changes with evidence. GPT-5 backed each fix with reasoning that traced across services, tests, and threading behavior.

• ❌ Limited scope:
  Sonnet-4 made a single, surface-level fix. Opus-4 added some useful logging but missed the deeper structural risks GPT-5 fully addressed.

Why this matters

The real value of GPT-5’s review lies in its depth and awareness. It not only patched the visible race, but also:

• Identified deeper architectural risks

• Cross-referenced test reliability and code quality

• Delivered a set of changes that are safe to merge immediately

This isn’t just a fix—it’s engineering insight. GPT-5 showed how an AI reviewer can reason across system layers, suggest durable solutions, and help teams write safer code with less guesswork.

What’s new (and exciting) about GPT-5

Beyond metrics and the specific things our tests were evaluating, we found that GPT-5 exhibited new behavioral and reasoning patterns.

• Advanced contextual reasoning: GPT-5 proactively planned multiple review steps ahead, showcasing expansive creative reasoning rather than strict input-bound logic. For example, GPT-5 demonstrated deep reasoning by connecting evidence across filles in our Concurrency oriented test focused on a ‘Check-then-act race condition’ scenario. It was the only model to detect risk of duplicate creation and introduced an atomic refund pattern grounded in the enum and test suite.

• Chain-of-thought reasoning via review threads: In an Object-Oriented test focused on a Virtual call in constructor case, GPT-5 showed layered logic by first identifying a misused polymorphic override and then adjusting its recommendations based on its own earlier suggestions. This shows layered logic by identifying one thing and then showing additional reasoning on the issue later.

• Evidence-based diff justification: In a Performance-focused test focused on Unbounded cache growth (no eviction) issue, GPT-5 identified architectural memory risks that other models missed, and backed its recommendation with diff context, usage patterns, and suggested safeguards.

• Forward-thinking suggestions: In a Concurrency-related test focused on Incorrect sync primitive usage, GPT-5 not only patched the race but also suggested how to structure future additions, lock hierarchies, and test guardrails to prevent regressions.

• Granular, task-oriented recommendations: Unlike previous models, GPT-5 detailed explicit follow-up tasks, creating actionable workflows within the review process itself. This makes the model much better for multi-step workflows.

How we’re using GPT-5 in our AI code reviews

We’re excited that GPT-5 represents a significant advancement in AI-powered code review, pushing the boundaries in detail, accuracy, and contextual reasoning. That’s why we’ll be using GPT-5 as the core reasoning model in our pipeline – starting today. We’re excited that it will be able to find more issues and create more in-depth, context-rich reviews.

If you’ve never tried CodeRabbit, tried it previously, or are a current user, we’d love to hear how you think GPT-5 is improving your review quality and experience.

Try our free 14-day trial today to see the power of GPT-5 yourself.

10 Advanced Github Copilot tips & tricks | Copilot best practicesの意訳です。

GitHub Copilotは、現代の開発者にとって欠かせないツールのひとつになりつつあります。OpenAIのモデルによって駆動され、エディタ上でリアルタイムにコード提案を行ってくれるこのツールは、使いこなせば生産性を大きく向上させる可能性があります。Microsoftの調査によれば、開発速度が最大で55%向上するとも言われています。

ただし、Copilotは魔法の杖ではありません。放っておけば、頼りになる相棒というよりは、やる気のあるジュニアエンジニアが推測でコードを書くような挙動になることも。Copilotをうまく使いこなすかどうかは、ワークフローの設計と使い方次第です。

本記事では、CopilotがAI開発ツール群の中でどのように機能するのかを概観し、私たちCodeRabbitや多数の開発者コミュニティで得られた知見から、Copilotの効果的な使い方を10個のヒントとして紹介します。

ヒント1：得意な領域で使う

Copilotには得意なタスクがあります。そこに集中させることで、時間を大幅に短縮できます。

特に得意なのは以下のような作業です：

• 繰り返しが多いコード

• 単体テストの生成

• 構文エラーの修正

• コードの説明

• 正規表現の生成

たとえば、ある関数に対して複数のユニットテストを書く必要がある場合、Copilotはコメントを元にそれらを一気に生成してくれます。

逆に、CopilotはUI設計やデータベーススキーマの構築など、コード以外の作業には不向きです。Copilotを「手の早いジュニア」として位置づけ、自分が設計と判断を担いましょう。

ヒント2：必要なコンテキストをきちんと与える

Copilotはエディタに表示されている情報をもとに提案を行います。そのため、関連ファイル（たとえば utils.py と models.py）を同時に開いておくと、より適切な補完が得られます。

また、使用予定のライブラリやフレームワークをあらかじめ import しておくことで、Copilotが適切な構文でコードを生成しやすくなります。たとえば import pandas as pd と書いておけば、DataFrame処理にはpandasを使うという前提で提案されます。

不要なファイルやコードが開いているとノイズになるため、作業に関係のないものは閉じておきましょう。

ヒント3：コメントやdocstringで意図を明確に伝える

Copilotにとって、コメントはプロンプトと同じ役割を持ちます。英語でも日本語でも良いので、やりたい処理を具体的に書いてみましょう。

例：

# 名前のリストを大文字小文字を区別せずにソートする

このように書くと、Copilotは sorted(names, key=str.lower) のような実装を自動で提案してくれます。

特に、入力と出力の具体例をコメントに含めると、より意図が伝わりやすくなります。あいまいなコメントではあいまいなコードが返ってくるので注意しましょう。

ヒント4：意味のある名前を使う

変数名や関数名は、Copilotにとっても重要なコンテキストのひとつです。たとえば check() や data1 のような名前では意図が伝わりづらく、提案されるコードも曖昧になります。

代わりに is_user_promotable() や calculate_invoice_total() のように、機能や目的が明確にわかる名前を使いましょう。

これは人間にとっての可読性だけでなく、Copilotの提案精度にも影響を与える重要な要素です。

ヒント5：CopilotとCodeRabbitを組み合わせて使う

Copilotはコードを書く段階で活躍しますが、書いたコードをレビューする段階ではCodeRabbitの出番です。CodeRabbitは、VS CodeやGitHubのPR上でAIによるコードレビューコメントを自動で追加してくれます。

Copilotでコードを素早く書き、CodeRabbitでレビューすることで、開発スピードと品質を両立できます。Copilotが気づかないエッジケースやチームのコーディング規約違反なども、CodeRabbitが検知してくれます。

CodeRabbitはこちらから14日間の無料トライアルが利用できます。

ヒント6：プロンプトは具体的に、例も添えて

Copilotに期待通りの動作をしてもらうには、明確かつ具体的なコメントが必要です。

たとえばログの1行をパースしたい場合、単に # parse log line と書くよりも、以下のように書く方が望ましい結果になります。

# "2025-06-02 09:00:00 - ERROR - failed to connect"
# のようなログをパースして、datetime, level, message に分割

このように例を添えることで、Copilotがフォーマットや処理の意図を正確に理解しやすくなります。

ヒント7：複雑な処理は小さく分割する

Copilotはシンプルで明確なタスクに強みを発揮します。逆に、複雑すぎる処理を一度に任せると混乱したコードが返ってくることもあります。

そのため、アルゴリズムの実装やCLIツールの構築などでは、まずステップをコメントで書き出し、1つずつCopilotに埋めてもらう方法が効果的です。

こうすることで、コードの確認もしやすく、品質の担保にもつながります。

ヒント8：Copilot Chatとインライン補完を使い分ける

Copilotにはインライン補完とCopilot Chatという2つの使い方があります。

インライン補完が向いている場面：

• 単純なアルゴリズムやループの補完

• コメントからそのままコード生成

• 繰り返しパターンの埋め込み

Copilot Chatが有効な場面：

• コードの意味やエラーの解説

• 長めのコード生成と改良

• セキュリティ意識など、ペルソナ指定のやり取り

両者をうまく使い分けることで、より柔軟な開発が可能になります。

ヒント9：複数の提案を確認し、プロンプトを改善する

Copilotは1つの提案だけでなく、複数の候補を持っています。最初の提案が理想的でない場合は、ショートカットキーやCopilotパネルを使って他の候補を確認しましょう。

それでも良い提案が出ない場合は、コメントやコードを見直して再度試してみると改善されることがあります。

ヒント10：Copilotの出力は必ずレビュー・テストする

Copilotが生成するコードは一見正しそうでも、バグやセキュリティの問題を含んでいる可能性があります。コードを本番環境に取り込む前に、必ずレビューとテストを行ってください。

• 空入力や例外処理への対応

• SQLインジェクションの可能性

• 非推奨APIの使用

などを確認することが重要です。

静的解析ツールやLinter、セキュリティスキャナー（SnykやCodeQLなど）も積極的に活用しましょう。

まとめ：GitHub Copilotを賢く使いこなそう

Copilotは非常に強力なツールですが、使い方によってその効果は大きく変わります。この記事で紹介した10のベストプラクティスを実践することで、Copilotをただの補完ツールから、本格的な開発支援ツールへと進化させることができます。

定型処理はCopilotに任せて、自分は設計や問題解決に集中する——そんな開発スタイルを実現するために、ぜひ紹介したヒントを取り入れてみてください。

そして、CodeRabbitとの組み合わせもぜひお試しを！

Context Engineering: Level up your AI Code Reviewsの意訳です。

コードレビューにおいて「コンテキスト」はすべて

CodeRabbitでは、業界でも屈指の“コンテキストを重視した”コードレビューを実現しています。多くのコードレビューツールが「コードベースの認識」レベルにとどまるなか、CodeRabbitはさらに深く掘り下げます。コードベースから数十もの情報を収集し、正確で実用的なレビューを提供しています。

そのために、レビュー対象のコード1行に対して、その背景情報を同じ比重でLLMに入力しています。具体的には、ユーザーの意図、ファイル間の依存関係、Jiraチケット、コードグラフ、過去のPR、チャットでのやり取り、Linterなどから得た成果などです。

さらに、生成されたAIの提案はすべて事後検証され、誤りを防ぎ、精度を高め、レビューガイドラインに適合しているかチェックされます。

これが私たちの「コンテキスト・エンジニアリング」であり、CodeRabbitのレビューが信頼性・品質・関連性で業界をリードする理由です。

本記事では、CodeRabbitのコンテキスト・エンジニアリングにおける主な要素を紹介します。

PRとIssueのインデックス化

レビューはまず、CodeRabbitがリポジトリをクローンし、サンドボックス上で管理するところから始まります。これにより、すべてのレビューがコードベースを認識した上で行われ、かつセキュアな環境が保たれます。

CodeRabbitはプロジェクト構造やコード間の依存関係を解析するだけでなく、過去のPRからもタイトル、説明、コミット範囲などを収集し、「なぜそのコード変更が行われたのか」を理解しようとします。関連する過去PRはレビューコメントにも反映されます。

また、Jira、Linear、GitHub、GitLabなどのIssueをインデックス化し、変更の「意図」も理解します。PRに紐づけられたIssueを分析し、要件がどの程度満たされているかを自動的に評価します。

コードグラフ解析

新たなレビューが開始されるたびに、CodeRabbitはコード間の依存関係をグラフ構造として再構築します。これにより、関数間の依存性を把握し、下流に影響を与える可能性のある変更を検出します。

コードシンボル（型など）の定義を取得し、それをレビューコメントのコンテキスト強化に活用することで、見落とされがちな依存関係の破綻や例外パターンを捉えることができます。

カスタムレビュー指示の対応

CodeRabbitは、各チーム固有のコーディング規約に基づいたカスタムレビューに対応しています。以下のような方法で柔軟にルールを設定可能です。

• パスベースのフィルター: 対象ファイルをglob形式で指定し、レビュー対象を限定できます。

• パスベースのレビュー指示: 指定パスに一致するファイルに対してのみ、特定のレビュー指示を適用できます。

• コーディングエージェントのガイドライン取り込み: CursorやCopilot、ClineなどのAIエージェントに定義されたガイドラインを取り込み、レビューに活用可能です。

チャットからの学習: レビューコメントに対するフィードバックをチャットで伝えるだけで、次回以降のレビューに反映されます。

Linterと静的解析ツール

CodeRabbitは40以上のLinterやSASTツールをプリセットで搭載しており、ユーザーによる設定は不要です。既存のLinter構成があっても、CodeRabbitはより包括的なチェックを行い、検出された問題はAIによるレビューで補完されます。

Linterによる検出結果が有効と判断された場合は、レビューコメント内でその旨が明示されます。また、独自の設定ファイルがある場合はパスを指定することで、そちらのルールも適用可能です。

対応しているLinter一覧は公式ドキュメントから確認できます。

Web検索による最新情報の取得

レビューに使われるLLMが最新の情報を知らない場合、CodeRabbitはWeb検索を実行し、公開されているリリースノートや技術ドキュメントから情報を補完します。

たとえば、Goのバージョンが1.23.6であるコードに対し、LLMが最新バージョンを知らなかった場合でも、CodeRabbitはWeb検索により1.24.1が最新であることを確認し、それに基づくアドバイスを行います。

検証スクリプトによるコメントチェック

最後に、LLMが生成したレビューコメントに対しても、CodeRabbitは自動で検証スクリプトを実行します。これにより、価値の低いコメントはユーザーに届く前に除外され、いわゆる“AIの幻覚”を防ぎます。

高度なコンテキスト・エンジニアリングによるレビュー品質の向上

このように、CodeRabbitでは多角的なコンテキスト情報をLLMに適切な量だけ提供することで、過剰にならず、かつ精度の高いコードレビューを実現しています。

私たちが実現しているのは以下のポイントです。

• 変更の意図を理解することで、見逃されがちな不具合を検出

• コードと同じ比重の情報をLLMに与えることで、効果的な判断を実現

• 無価値なコメントを排除し、ノイズを最小限に抑制

CodeRabbitを試してみたい方は、14日間の無料トライアルをご利用ください。リポジトリの接続も数分で完了します。ご不明な点はDiscordコミュニティにてお気軽にご相談ください。

ROUTE06（ルートシックス）は、人とAIの協創によってプロダクト開発を再定義するスタートアップです。現在は、AI駆動の開発プラットフォームを中核に据え、エンジニアやデザイナー、ビジネスパーソンがAIと共創しながらプロダクトを素早く生み出せる環境づくりを進めています。

クライアントワークにおいても、さまざまな大手企業とともに、AIを積極的に活用した受託開発を推進。さらに、要件定義特化型AIプラットフォーム「Acsim」、AIエージェントビルダー「Giselle」、AI時代のDB設計プラットフォーム「Liam」など、自社プロダクトも次々と展開しています。いずれも、AIをフル活用した新しいものづくりを体現する取り組みです。

今回はROUTE06のCTOである重岡さんに、同社におけるCodeRabbitの活用を伺いました。

少数精鋭チームで挑む、柔軟でスピーディな開発体制

ROUTE06の開発組織は、少数精鋭のスモールチーム体制を基本としています。各プロダクトにエンジニア、デザイナー、プロダクトマネージャーが数名ずつアサインされ、それぞれが自律的に開発を推進しています。たとえば、Giselleのチームは5名以下で構成されており、AIの活用によって少人数でも十分に戦える体制になっています。

重岡さんは「今の開発サイクルでは完璧なコードを出すよりも、まず出してあとでリファクタリングすることの方が重要」と語ります。変化の速いAIの時代において、スピードと柔軟性を兼ね備えた開発組織こそが、ROUTE06の競争力の源泉となっています。

急増するプルリクエスト、問われるレビュー体制の進化

ROUTE06では、AIを活用したプロダクト開発が日常化するなかで、PRの量が急増していました。特に、エンジニアだけでなくデザイナーなどの非エンジニアもコードを書く「バイブコーディング」スタイルが浸透しはじめたことで、レビューのボトルネックが顕在化。小規模チームで高速に開発を進める一方で、コードレビューやQAにかかる負荷が大きくなりつつありました。

レビュー可能なエンジニアは社内に複数いるものの、彼らも実装を並行して担当しているため、レビュー待ちの状態が発生しやすく、開発スピードの低下が懸念されていました。加えて、AI生成コードの質が高まるにつれ、一見問題なさそうなコードにも潜むバグや設計のズレを見抜く負担が増しており、レビューそのもののあり方も見直す必要が出てきていたのです。

「レビューの質とスピードをどう両立させるか。それが、開発スピードを維持する上で最も大きな課題でした」と重岡さんは振り返ります。

きっかけは社内から。CodeRabbitのファーストインプレッション

CodeRabbitの存在を知ったのは、社内のエンジニアからの紹介がきっかけでした。情報感度の高いメンバーが「これは使えるかもしれない」と社内に共有したことから、まずはオープンソースプロジェクトで試験的に導入を開始しました。

社内での使い心地やフィードバックを経て、徐々にプライベートリポジトリを含む社内全体での本格導入へとつながっていきました。形式的な指摘に終始せず、レビューの質が実際に上がることで「これなら任せても大丈夫だ」と感じることができたと振り返ります。

「CodeRabbitは入れてすぐに良いレビューをしてくれました。いろいろな設定もいらず、最初からちゃんと動いてくれる即戦力ぶりが良かったです」（重岡さん）

レビューの質と深さを両立させるCodeRabbitの活用

現在、ROUTE06ではCodeRabbitを開発フローに深く組み込み、社内のさまざまなプロジェクトで日常的に活用しています。レビューの初動はまずCodeRabbitが担い、基本的なベストプラクティスや一般的なコード品質に関する指摘は自動でカバーします。人はプロダクトのドメイン知識や設計意図など、より高次な観点に集中できるようになりました。

また、レビューコメントを他のAIコーディングエージェント（Claude Code、Cursor、Devinなど）にそのまま渡してリファクタリングを依頼する運用も確立され、AI同士の連携によって開発スピードがさらに向上しています。プロダクトのライフサイクルが短くなっている現代において、CodeRabbitはレビューのスピードと質を維持するための重要な存在になっています。

「今はもう、人でなくて良い部分は全部CodeRabbitに任せてます。その分、自分たちは本当に見るべきところに集中できるので、レビューの濃度が上がった実感があります」（重岡さん）

単なるツールから開発パートナーへ

ROUTE06では、今後もAIを活用した開発のスピードと柔軟性をさらに高めていく方針です。その中で、CodeRabbitには単なるコードレビュー支援を超えた開発パートナーとしての進化が期待されています。たとえば、チームやプロダクトごとの文脈をより深く理解し、コメントの精度や提案の質を高めていくことで、開発者の判断や意思決定をより強力にサポートしてくれる存在になってほしいと考えています。

「レビューは単にコードを見るだけではなく、そのチームのスタイルや優先順位が反映されるものです。そこまでCodeRabbitがわかってくれるようにあれば、さらに頼れるメンバーになってくれると思います」（重岡さん）

CodeRabbitは、今後もROUTE06の開発文化を支えるパートナーとして、進化し続けます。

株式会社ジャンボは、自分自身が熱狂し、ユーザーにも熱狂を届けるという「Passion to Life」をビジョンに、世界で通用するプロダクトの創出を目指しています。2025年12月までに、日本で最も愛されるサービスとなることを掲げ、日々プロダクト開発に取り組んでいます。

主力アプリは、リアルタイムで通話やライブ配信ができるコミュニケーションアプリです。累計会員数は1,100万人を突破し、モバイルアプリやWebアプリを含む15以上のサービスを展開しています。ジャンルを超えたつながりを生み出す仕組みにより、国内外問わず幅広いユーザーに利用されています。

今回は、同社CTOの花野さんと、テックリードの石田さんにお話を伺いました。

内製にこだわる自社開発体制

ジャンボは社員50名の内33名が開発者で、モバイルとWeb、バックエンド、インフラに至るまで全ての開発を自社で完結しています。全員が出社して同じ空間で働くスタイルを貫いており、実際に顔を合わせて熱量を共有しながら開発を進めています。

組織体制としては、Web事業部と国内アプリ事業部、海外アプリ事業部の3つに分かれ、それぞれiOSチームやAndroidチームが配置されています。インフラやバックエンドについては、事業部を横断して支える専門チームが担当しています。

増え続けるレビューの負荷と属人化の悩み

日々大量に生まれるプルリクエストに対し、少人数でのレビュー体制には限界がありました。特に大規模な実装になると、確認にかかる時間が増え、精神的な負荷も大きくなりがちです。レビュー担当がつい後回しにしてしまい、チーム全体の生産性に影響を及ぼすことも少なくありません。

また、コードレビューの質や視点がレビュアーに依存していたため、属人化の課題も抱えていました。誰が見るかによって指摘の内容がばらつき、レビュー品質のばらつきが生じる点にも悩んでいたといいます。

「大きい実装を少人数で見る場面も多く、レビューの負担が重くなりやすかったです。AIが最低限の品質を担保してくれるようになってからは、精神的にもかなり楽になりました」（花野さん）

CodeRabbitとの出会いは偶然のX投稿から

CodeRabbitを知ったのは2年ほど前、X（旧Twitter）上で偶然見かけた投稿がきっかけだったそうです。元々新しい技術に敏感だったこともあり、興味を持って試してみることにしました。

実際に使ってみると、自動生成されるシーケンス図に大きな驚きを覚えたといいます。視覚的な理解を助ける機能として、特に印象に残ったそうです。

「最初に見た時のシーケンス図が衝撃的でした。AIってここまでやれるのかと驚きました」（花野さん）

決め手は先発性とカスタマイズ性

CodeRabbitは当時のAIレビュー領域では比較的早い段階で登場したツールだったこともあり、他のサービスと比べて先駆者としての信頼があったと振り返ります。また、YAMLファイルを通じてリポジトリ単位のカスタマイズができる点も良かったとのこと。

他のAIレビューサービスも並行して利用しているものの、CodeRabbitの柔軟性やカスタマイズによるレビュー精度の向上は一歩抜きん出ているとのことです。

「最近ではYAML設定でレビュー品質をかなり調整していて、抽象的な指摘から本質的なフィードバックへと進化していると感じています」（石田さん）

導入による効果と現場での使い方

現在は、すべてのプルリクエストに対して、まずAIレビューを通す運用をルール化しています。これにより、ケアレスミスや簡単な文法ミスなどは事前にフィルタリングされ、人のレビュー工数の削減を実現しています。

なお、オンボーディングの一環として、新しいメンバーには敢えて最初はAIなしで自力でレビューを経験してもらい、その後AIツールに触れてもらうという段階的な導入方法を採用しています。チームごとにリポジトリ設定も分かれており、それぞれのスタイルで最適な利用スタイルをとっているとのこと。

「まずAIに通すという流れができたことで、明らかなミスに時間を取られなくなりました。レビューにかかる心理的ハードルも下がったと思います」（花野さん）

CodeRabbitに今後期待したいところ

現場ではすでにCodeRabbitの活用によって大きな効果を実感しているものの、さらなる進化への期待も挙がっていました。たとえば、設定権限の柔軟化です。リポジトリごとの設定を編集できる権限が柔軟になり、個々のチームが自由にレビューの条件を調整できると、さらなる活用が進むと考えられています。

そのほか、OpenAI以外のモデル、たとえばClaudeなどを明示的に指定できるような仕組みがあると、使い分けの幅が広がるのではという意見もいただきました。

CodeRabbitは今後もジャンボの開発体制をサポートし、アプリのさらなる発展に寄与していきます！

株式会社ジャンボでは、iOSやAndroidエンジニアなど、幅広い職種でエンジニアを採用しています。世界に通用するアプリ開発に興味がある方は、ぜひ採用ページをご覧ください。

株式会社ロッカが運営するフィヨルドブートキャンプは、実践的なカリキュラムを通じて現場で通用するエンジニアを育成するプログラミングスクールです。GitHub上で開発を進めるチーム開発や、ポートフォリオ制作を通じて、技術力だけでなく開発プロセス全体を学べる環境を整えています。

現在、fjordllc/bootcampのリポジトリにてCodeRabbitが導入されています。その導入に至った経緯、活用について運営責任者の駒形 真幸さんにお話を伺いました。

生徒数が増える中でレビューの遅れが課題になった

フィヨルドブートキャンプでは、生徒同士のレビューからメンターによるチェック、最後に代表である駒形さんによるレビューという多段階のプロセスでコードを確認しています。実務に近い開発体験を得られる一方で、レビュー待ちが発生すると学習の流れが滞るという課題がありました。

特に受講生が増えた際にレビューが集中し、対応が追いつかなくなることで、リリースまでに時間がかかってしまう状況が生まれていました。生徒からの不満にもつながるため、改善の必要性を強く感じていたと話します。

駒形さんは「レビューが終わるまでに時間がかかってしまって、生徒の不満につながることがありました」と振り返ります。

複数ツールを比較し、CodeRabbitを選定

レビュー工程を補完するツールとして、当初は複数のAIレビューサービスを検証していました。他のレビューツールも試したものの、レビュー内容の精度や納得感にばらつきがあったといいます。

そうした中で、CodeRabbitはレビューの的確さや不要な指摘の少なさが際立っていたとのこと。実際のPull Requestで何本か比較した結果、フィヨルドブートキャンプの運営体制やレビューのスタイルにも合っていたことが導入の決め手となりました。

「CodeRabbitの指摘が圧倒的に良かったですね」と駒形さんは振り返ります。

AIの指摘にどう対応するか、あらかじめルールを設けた

AIツールを教育の現場に導入する際、懸念されるのは「AIの指摘に納得できない場合の対応」でした。これに対し、フィヨルドブートキャンプでは、AIの指摘に対してはコメントで理由を説明すればよいという明確なルールを整備しています。

この運用により、生徒がAIと対話する感覚でレビューを進められるようになり、混乱なくスムーズに運用が進んでいるとのことです。

駒形さんは「思っていたより問題が起きなくて驚きました」と導入当時の印象を語ります。

CodeRabbitは運営側が導入しただけでなく、生徒にも自然に浸透しています。GitHub上のポートフォリオとなる自作サービスの開発に、自主的にCodeRabbitを組み込む生徒も現れています。

SNS上でも生徒の好意的な反応が確認できており、現場での受け入れの早さとスムーズな導入が伺えます。こうした流れは、学習者自身がAIツールを使いこなすきっかけにもなっているようです。

今後はフロントエンドコースにも導入を拡大予定

現在CodeRabbitは、Ruby on Railsを使ったバックエンドのリポジトリに導入されていますが、今後はJavaScriptを中心とするフロントエンド側への展開を検討しています。導入から一定期間が経過していますが、CodeRabbitのレビュー機能に対して特に不満はなく、当初の目的であったレビューの迅速化が実現できているといいます。

フィヨルドブートキャンプの取り組みは、教育機関におけるAIレビュー導入の好例といえます。レビュー待ちの負担を減らしつつ、生徒の自走を促すというバランスの取れた運用は、多くの開発現場にも応用可能でしょう。

「レビュー待ちの時間がなくなることで、生徒の学習リズムが崩れなくなったのが大きいです」と、駒形さんは今の成果を語ってくれました。

CodeRabbitは今後もAIコードレビューを通じてフィヨルドブートキャンプ、ならびに生徒の方々の学習をサポートしてまいります。

Copilot has quickly become a staple in the modern developer’s toolkit. Powered by OpenAI’s models, it offers AI-driven code suggestions based on what you’re writing — right in your editor. Used well, it can significantly boost productivity. Microsoft’s data suggests it may help developers code up to 55% faster.

But here’s the catch: Copilot isn’t a magic wand. Left on autopilot, it can feel more like an eager junior dev making confident guesses than a reliable coding partner. The difference between a helpful Copilot and a frustrating one often comes down to how you use it — and whether you’ve built a workflow that plays to its strengths.

In this article, we’ll walk through how Copilot fits into the broader AI dev tool stack and share practical GitHub Copilot tips and tricks for using it more effectively. These strategies are drawn from both our own experience and the thousands of developers using CodeRabbit’s AI code review platform. With the right approach, Copilot can go from a neat autocomplete toy to a genuinely valuable part of your daily development routine.

GitHub Copilot tip 1: Play to Copilot’s strengths

Not every coding task is equal in Copilot’s eyes. One of the most important GitHub Copilot best practices is to use it where it shines, not force it to create code where it doesn’t. Copilot excels at specific categories of tasks that can save you significant time.

Copilot is especially good at…

• Writing repetitive code

• Generating unit tests

• Debugging syntax issues

• Explaining code

• Generating regex patterns

These are areas where it has seen lots of examples and can confidently suggest solutions.

For example, if you have a function and need to write several tedious unit tests for it, Copilot can draft them in seconds. Consider this simple function and tests:

Copilot can help create unit tests for the above function quickly:

In a scenario like the above, Copilot generated the TestMultiply class almost entirely from a comment or prompt. It’s excellent for boilerplate code, repetitive patterns, and well-defined algorithms.

On the flip side, Copilot is not a silver bullet for everything.It’s not designed to handle tasks unrelated to coding (don’t expect it to plan your database schema or design UI work) and won’t replace your problem-solving skills.

Think of Copilot as a junior developer at your side. It’s fast and often right about everyday tasks, but you (the senior developer) are still in charge of decision-making and critical thinking. Use Copilot for the “heavy lifting” on mundane code and let it suggest solutions for routine problems, but always apply your judgment on whether to use those suggestions. That way, you’ll save time and reduce drudgery while keeping yourself focused on the challenging problems and design decisions.

GitHub Copilot tip 2: Provide ample context (open files, set imports, etc.)

A hot tip for GitHub Copilot is to open all the relevant files in your project when you’re coding a particular feature. That’s because Copilot works by looking at the context in your editor to predict what you might want next. The more relevant context you give it, the better the suggestions.

For instance, if you’re implementing a function in utils.py that interacts with models.py, have both files open.

Copilot will process all open tabs (often called “neighboring tabs”) to inform its suggestions. This broader view helps it understand your project structure and produce more accurate code. In fact, simply opening related files in VS Code or your IDE can significantly enhance Copilot’s completions by providing extra context for definitions and usages across your project.

Similarly, explicitly set up your imports, includes, and dependencies before expecting the best suggestions. You know what libraries or frameworks you intend to use – tell Copilot by importing them at the top of your file. This gives Copilot a heads-up on what tools it should use.

It’s often best to manually add the modules or packages (with specific versions, if needed) before asking Copilot to generate code using them. By doing so, you avoid Copilot defaulting to an outdated library or missing an import.

For example, if you plan to use pandas in your code, write import pandas as pd yourself; then when you ask Copilot to manipulate a DataFrame, it will already know to use pandas and won’t attempt a pure-Python solution or an incorrect import.

Also, be mindful of irrelevant context. Copilot’s window of attention is limited. If you have a lot of unrelated files open or leftover code in your editor, close or remove them when you switch tasks. Keeping only the pertinent files and context visible ensures Copilot isn’t “distracted” by code that doesn’t matter to your current goal.

GitHub Copilot tip 3: Write descriptive comments and docstrings as prompts

You understand prompt engineering when you’re directly calling an LLM. But did you know that there are some sneaky ways to prompt engineer in Copilot? One of the most effective GitHub Copilot tips is to guide the AI with natural language comments.

Think of writing comments as a form of prompt engineering. Before you write the code, describe in plain English (or your preferred language) what you intend the code to do.

For example, we want a function to sort a list of names case-insensitively. We might start with:

The moment you write that comment and pause, Copilot will likely suggest the rest of the function (e.g., using sorted(names, key=str.lower)). A top-level comment at the start of a file, or a docstring/comment above a function, helps Copilot understand the overarching objective before diving into implementation details.

This process is similar to giving a human colleague a quick overview of the task at hand, it sets the stage so the following code makes sense in context.

When writing these comments, be clear and specific about the desired behavior. Mention any requirements or constraints. For a more complex example, suppose you need a function to format a person’s name as "LASTNAME, Firstname".

You could provide an example in the comment to clarify your intent:

By including the example of input and output, you give Copilot a crystal-clear idea of what you want.

Which is exactly the desired solution. The first comment was a prompt describing the goal and even provided a test case, and Copilot filled in the implementation.

Use this technique liberally. Add a brief docstring or comment for each function describing what it should do (and how at a high level, if you have an approach in mind). Copilot can detect the comment syntax for your language and will often even help complete the comment if it recognizes a pattern (for example, it might suggest a template for a Python docstring).

By writing specific, well-scoped comments before the code, you essentially “program” Copilot with your intent.

Remember the old saying: garbage in, garbage out. If you feed Copilot an ambiguous comment like “# do something with data”, you’ll get ambiguous code. Instead, describe the task clearly – “# Calculate the average value from a list of numbers, ignoring any nulls” and watch Copilot more reliably produce the correct logic.

GitHub Copilot tip 4: Use meaningful names for clarity

You might hate being stickler about style but variable and function names are another form of context that Copilot relies on.

A tip that might seem obvious but is often overlooked is togive your functions and variables meaningful, descriptive names. If you have a function named foo() or variable data1, Copilot has virtually no clue what you intend, beyond what it can infer from a possibly sparse usage context.

In contrast, names like calculate_invoice_total() or user_email_list immediately convey intent to humans and the AI. In fact, Copilot’s suggestions will improve dramatically when your code is self-documenting.

A function called fetchData() doesn’t mean much to Copilot (or to a coworker) compared to a function named fetch_airport_list() or get_user_profile. The latter gives far more hints of what the function should do.

For example, consider these two scenarios:

Vague naming:

With a function name like check and a parameter data, Copilot might struggle. “Check” could mean anything. Could it check a password or a value in data? Its suggestions might be generic or incorrect because it’s guessing your intent.

Descriptive naming:

The function name is_user_promotable clearly signals a boolean decision, and the parameters user_profile and promotion_rules indicate the data involved. Copilot can use this information to guess that you might iterate over rules, check user attributes, etc., and its completion will align with that logic.

Adopting clear naming conventions isn’t just a general coding best practice for developers. It’s a GitHub Copilot best practice, too, because Copilot can only infer intent from what it sees. If what it sees are meaningful identifiers and not cryptic ones, it will return far more relevant code. This tip also pays dividends for code maintainability – since you’ll get better AI suggestions and cleaner code for your team.

GitHub Copilot tip 5: Pair Copilot with CodeRabbit for AI-assisted code reviews

While Copilot is fantastic during the coding phase, what about after you’ve written your code? Enter CodeRabbit, an AI-powered code review developer tool that complements Copilot in the development workflow.

CodeRabbit acts like an AI “pair reviewer,” scanning your code (either in the IDE or on your Git platform) and providing feedback and suggestions for improvement.

We’ve found that using Copilot and CodeRabbit together creates a powerful feedback loop: Copilot helps you generate code quickly and CodeRabbit helps ensure that code meets quality standards before it gets merged.

• You don’t get the developer who wrote the code to review it, so why get the same AI system to do so?

• An AI code reviewer also allows you to standardize your quality gate if your team is using multiple AI coding agents – as so many teams are these days.

• Finally, purpose-built AI coding agents like CodeRabbit do a more thorough job and have more features that means the average user is able to find 50% more bugs in half the time they’d typically spend on a code review.

CodeRabbit integrates into VS Code and pull requests on platforms like GitHub. In your IDE, you can invoke CodeRabbit to review the file or the diff you’re working on. It will directly add AI-powered inline review comments in the code, pointing out potential issues, much like a human reviewer would.

For example, CodeRabbit might flag that your function lacks error handling for a specific edge case or suggest a more appropriate HTTP status code.

On GitHub or GitLab, CodeRabbit can automatically comment on PRs with its findings, saving human reviewers time by catching obvious problems first. It also provides line-by-line code reviews, highlighting possible bugs, code smells, style issues, or even missing unit tests.

How best to use Copilot and CodeRabbit together

Think of Copilot and CodeRabbit as two halves of a complete AI-assisted development cycle.

You use Copilot while writing code to speed up implementation. Then you use CodeRabbit to review that code and catch anything Copilot (or you) might have missed.

• Copilot might generate a solution that works but isn’t optimal and CodeRabbit could point out a performance issue or a more idiomatic approach.

• Copilot might not know your project’s specific coding standards, but CodeRabbit can enforce them during review. Perhaps your team prefers format() over f-strings, etc.. CodeRabbit can comment on that.

• Copilot might help you quickly whip up a new API endpoint, CodeRabbit could then run and immediately warn, “Hey, you didn’t handle the case where this input is null,” or “This SQL query might not be parameterized.” You can address those before your human colleagues even look at the code.

Essentially, Copilot gets you to a working draft faster, and CodeRabbit gives you confidence to ship it by auditing the code. It’s like having an AI pair programmer and an AI code auditor working together.

In the context of a complete AI dev tool stack, Copilot and CodeRabbit cover a lot: Copilot for coding, CodeRabbit for review, and you might even use other AI tools for testing or security.

To get started, you can install CodeRabbit’s IDE extension or add it to your GitHub repository as a GitHub App from the marketplace. We highly recommend this for teams and there’s even a 14-day trial.

GitHub Copilot tip 6: Be specific and provide examples in prompts

When it comes to guiding an AI model, specificity is king. If you’re asking Copilot to write code to transform data, consider providing a short example of the data format in a comment or docstring. If you want a function to calculate something, state the formula or an example scenario in natural language.

Copilot’s underlying model is essentially trying to predict what a knowledgeable developer would write next. If your prompt (context + comments) is vague, the model must guess and may go wrong. But if you spell out details and even including sample inputs and outputs if possible, that helps

For instance, suppose you need to parse a log line like "2025-06-02 09:00:00 - ERROR - failed to connect". Instead of just writing # parse log line, you could write:

This specific prompt gives Copilot a clear blueprint: it knows the log format and the desired output types. With the example shown, the chances of Copilot writing a correct parse_log_entry implementation (splitting by " - ", parsing the date with Datetime, strptime, etc.) are much higher. Without the example, Copilot might misidentify the format or split incorrectly.

When prompting Copilot for non-trivial code, spell out the details. If a function has constraints (e.g. “input can be null” or “assume list is sorted”), mention them. If there’s a particular approach you want (e.g. “use binary search” or “use recursion”), hint at it in your comment. And if possible, provide a quick example. The model will take these as strong cues and align its suggestions accordingly.

GitHub Copilot tip 7: Break complex tasks into smaller steps

Copilot works best when it’s dealing with a focused, well-defined task. If you ask it to do too much at once, you might get a muddled or incomplete answer. A great strategy is to break down big problems into bite-sized pieces and tackle them one by one with Copilot’s help.

For example, imagine you need to implement a complex algorithm. Instead of prompting Copilot to write the whole thing in one go (which might result in a long, confusing blob of code), start by outlining the high-level steps as comments or pseudocode.

You might write a few lines of comments or stub functions and then let Copilot fill in each part. Generate code incrementally, rather than all at once. This approach makes Copilot’s job easier (each step has more specific context). That makes it easier for you to review and trust the code at each step.

Let’s say you’re building a small command-line program. First, prompt Copilot to parse command-line arguments, then separately prompt it to implement the business logic, then prompt it to handle output. You can check Copilot’s work at each stage by breaking the flow.

Think of Copilot as participating in a step-by-step refinement of your code. So, don’t try to have Copilot write an entire module in one shot. Instead, have it write one function at a time, or even one logical block at a time, especially if the logic is intricate.

By decomposing tasks, you also naturally create opportunities to review each piece. This incremental approach leads to better quality code and fewer surprises. It’s much easier to debug a smaller Copilot suggestion than the 50-line monolith it spit out because you asked a very broad question.

GitHub Copilot tip 8: Leverage Copilot Chat vs inline completions wisely

GitHub Copilot has two primary flavors – traditional inline code completion and the newer Copilot Chat (an interactive chat interface available in VS Code, Visual Studio, and other environments).

Knowing when to use Copilot Chat vs when to rely on inline suggestions can make a big difference in your workflow. It’s one of those subtle hot tips for GitHub Copilot that can transform how you approach a problem.

Inline code completions (the original Copilot experience) are best for:

• In-the-flow coding assistance: When you’re writing code and want Copilot to suggest the next line or block as you type. This works great for completing a small algorithm, filling in a loop, or writing boilerplate in place.

• Filling in repetitive code or simple patterns: For example, generating a quick data class, an API call, or the next cases in a series of if/elif conditions. The inline suggestions excel at continuing your current context.

• Generating code from a commented intent: as we’ve seen, if you write a comment # do X, the inline completion often does X immediately in code form.

On the other hand, Copilot Chat is more powerful when you need more interaction or have questions about your code:

• Explaining or analyzing code: You can ask Copilot Chat “What does this function do?” or “Why am I getting a KeyError here?” and get a natural language answer. The chat can act like a super-smart rubber ducky for debugging.

• Larger code generation tasks with iteration: If you want to generate a sizable chunk of code (say a whole function or class) and then refine it, Copilot Chat is ideal. You might ask it to write the code, then say, “now optimize this” or “can you refactor that part using a dictionary instead of if-else?” This back-and-forth is something inline suggestions can’t do easily.

• Using personas or specific commands: Copilot Chat has a concept of keywords and skills (and allows system-level instructions like “Act as a senior developer…”) which you can use to influence its style or thoroughness. For instance, you could instruct it to be security-conscious when writing the code.

To illustrate, if I have a piece of code and I’m not sure it’s efficient, I might use Copilot Chat: “Explain the complexity of this function. How can I improve it?” Copilot Chat might identify the bottleneck and even suggest a more efficient approach.

On the other hand, if I just need the next few lines of a loop, inline completion is faster. I can just hit Tab and keep coding.

Tip: If you have access to both, don’t forget you can use them together. Maybe start writing a test function (inline completion helps you fill out test cases), then switch to Chat to ask Copilot to generate some additional tests or explain a failing test. Each tool has its sweet spot.

GitHub Copilot tip 9: Cycle through suggestions and refine your prompts

By default, Copilot might show you one suggestion – the most likely completion – for your prompt or code context. But what if that suggestion isn’t what you want? Many users forget that Copilot usually has multiple suggestions under the hood. Don’t settle for the first thing it offers if it’s not quite right. A GitHub Copilot tip that’s helped me is to use the keyboard shortcuts (or the Copilot panel) to cycle through alternative suggestions.

There might be a gem in suggestion #2 or #3 that better fits your needs than suggestion #1.

Additionally, you can open the Copilot sidebar (or the full chat interface, if available) to explicitly ask for more options. In some IDE setups, hitting a special shortcut (like Ctrl+Enter in VS Code with Copilot Chat enabled) will even reveal multiple completions at once. Scanning through a few options can save you time you’d otherwise spend editing a less ideal suggestion. It’s like getting a second and third opinion from the AI.

If none of the suggestions look good, that’s a signal to refine your prompt or add more context. Perhaps your comment was too short or ambiguous. Try rephrasing it or adding another detail and then trigger Copilot again. The model’s output can vary greatly with slight changes in how you ask.

For instance, if the #sort list didn’t give the desired result, then #sort the list of names in alphabetical order might produce a better suggestion.

Another trick is giving feedback to Copilot. If you’re using Copilot Chat or the sidebar, you might have thumbs-up/down buttons you can press to give feedback on suggestions. While this won’t instantly change the current suggestion, it does send feedback to improve the model’s future behavior through reinforcement learning. And in chat mode, you can directly say, “No, that’s not what I meant. I actually want X,” and the AI will try again.

GitHub Copilot tip 10: Review, test, and verify Copilot’s output

Copilot can generate code that looks perfect at first glance, but remember, it’s not guaranteed to be 100% correct or optimal.

Always review and test the suggestions before integrating them into your codebase. This tip cannot be stressed enough. Copilot may introduce bugs, security issues, or logically wrong code if the prompt is misunderstood. You, the developer, are the last line of defense to ensure quality.

To review Copilot’s output, first, read the code carefully and make sure you understand it. If Copilot suggests a complex algorithm or some math you’re unsure about, ask Copilot (via Chat) or use your knowledge to break down what it’s doing.

You can ask Copilot Chat to explain the suggested code in plain language as a helpful Copilot trick. Often, I’ll paste a large suggestion into the chat and prompt: “Explain what this code does.” You can immediately catch any assumptions or errors if the explanation reveals any assumptions or errors.

Next, consider edge cases and correctness.

• Does the code handle empty inputs?

• What about error conditions?

• If something looks fishy (like a potential off-by-one error or an unbounded recursion), address it or prompt Copilot to fix it.

Security and style are also important. If your prompt didn't specify otherwise, Copilot might use a deprecated function or an insecure approach. Always double-check things like SQL queries (are they parameterized to prevent injection?), file operations (are files closed properly?), and any cryptography or authentication code it writes (does it follow best practices?).

Linting and static analysis tools are your friends here. Run your linters or code formatters on Copilot’s code to catch style issues, and use any security scanners (like Snyk or CodeQL) if applicable to flag vulnerabilities.

Finally, remember that Copilot might occasionally produce code that is oddly similar to public examples (especially for very common algorithms). It’s rare, but if you’re working on a closed-source project and have strict license requirements, be mindful of this. You can configure Copilot to avoid suggestions that match public code, if needed.

Now, it’s time to use these hot tips for GitHub Copilot!

GitHub Copilot is a game-changer for developers but like any powerful tool, it yields the best results when used skillfully. We’ve covered our top 10 hot tips for GitHub Copilot – from crafting great prompts and leveraging context to integrating Copilot with an AI reviewer like CodeRabbit. By implementing these GitHub Copilot best practices, you’ll find Copilot becomes much more helpful.

It can handle the boilerplate and suggest clever solutions, allowing you to focus on higher-level thinking and problem-solving. Also, don’t forget that Copilot and the surrounding AI ecosystem are evolving rapidly and new features (like the CLI tool, vision-based Copilot, etc.) are coming out regularly. Stay curious and keep experimenting with how you use it.

Perhaps you’ll discover new GitHub Copilot tips and tricks beyond the ten we’ve shared. Or we’ll just write another article.

Interested in using CodeRabbit with Copilot? Start your free 14-day trial.

やまだしさんが開発する「Repomix」は、GitHubリポジトリやローカルのコードベースを1つのテキストファイルに集約し、Claude、Gemini、ChatGPTなどのAIに渡してコード分析や実装方針の検討ができるCLIツールです（RepomixのGitHubリポジトリはこちら）。

自身の開発でもRepomixを活用しており、DiscordやIssue、Xへの返信の相談や、ドキュメントが少ないライブラリの調査などに役立てているそうです。現在は、ライブラリ化やMCPサーバー、stdin対応などを通じて、より幅広い開発フローへの統合を目指しています。

一人開発にのしかかるレビュー負担

やまだしさんは、Repomixを個人プロジェクトとして設計から実装、リリース、サポートまで一人で担っています。そんな中、AIコーディングツールの普及によりPRの数や速度が増え、メンテナンスの負担が一層大きくなっていったと言います。

「AIツールは開発を加速させる一方で、生成されるコードの品質にはばらつきがあります。それを人間が一つ一つ見ていくのは大変で、開発効率化のメリットが半減してしまうと感じていました」

OSS活動が本業の余力で行われているからこそ、レビューに割く時間の大きさはプロジェクトの継続性にも関わる深刻な課題でした。

CodeRabbitを選んだ理由

CodeRabbitを導入したのは、ちょうどCursorが普及し始め、自身もRepomixでRepomixを改善していた時期でした。知り合いから紹介を受けたことがきっかけで知ったそうです。

実はその頃、他のAIレビュー系スタートアップからも利用オファーを受けており、いくつかのツールを試していたとのこと。その中で最も優れていたのがCodeRabbitでした。

「OSSプロジェクトなら無料で使えるという点も、個人開発者として非常に魅力的でした」

当時はGitHub CopilotによるPRレビューやGemini Code Assistなども存在せず、AIによる自動コードレビューを本格的に提供していたのはCodeRabbitが初めてだったと振り返ります。

他ツールとの比較

現在、やまだしさんは以下の4つのツールを併用しています。

• CodeRabbit

• Gemini Code Assist

• GitHub Copilot

• Claude Code Action

それぞれに特長があり、CopilotはGitHubとの統合がスムーズで使いやすく、Gemini Code Assistは他ツールが見逃すような観点で指摘してくれることがあると評価しています。その中でも、総合的にはCodeRabbitが最も優れているとのこと。

「レビューの精度が高いのはもちろん、開発者目線でのUXが本当に素晴らしいです」

特に便利だと感じているのは「Prompt for AI Agents」。ファイルパス、行数、指示が含まれたコメントをコピーして、そのままCursorやClaudeに渡せるのが便利で、VSCode拡張でも同様のことができる点が評価されています。

導入時の課題と運用面の工夫

半年前まではレビューの精度に不安があり、「たまに良い指摘をしてくれるから入れておこう」という位置づけだったそうです。しかし、最近では精度が大きく向上し、「実用的で的確な指摘をしてくれるようになった」と変化を実感しています。

また、設定面ではCodeRabbitのYAML形式によるカスタマイズを活用しているとのこと。

「複数のプロジェクトで使う場合、それぞれの設定を把握するのが難しくなるので、コード管理することを強くおすすめします」

精神的な負担を減らす存在に

開発スタイルとしてClaude CodeやCursorと組み合わせて使うことが多いというやまだしさん。CodeRabbitとの相性も非常に良く、今ではなくてはならない存在になっているそうです。

「以前はPRで凡ミスを見つけるとげんなりしていたのですが、今ではCodeRabbitが細かいバグを見つけてくれるので、その精神的な負担が大幅に減りました」

時間効率の改善は1〜2割かも知れませんが、「やらなくていい作業を任せられる」という点に、数値以上の価値を感じていると語ります。

今後の進化に期待すること

今後のアップデートにおいては、モデルの精度向上よりも、開発者視点の“気の利いた機能”を増やしてほしいと語ります。

「Prompt for AI Agentsのように、実際の開発フローを理解しているからこそできる工夫が魅力です。かゆいところに手が届く機能、待っています（笑）」

単なるレビューツールではなく、開発者の“パートナー”として進化していってほしい──そんな想いが込められていました。

CodeRabbitはRepomixのさらなる開発をサポートすべく、進化していきます。

The art and science of context engineeringの意訳です。

平凡なAIエージェントと卓越したAIエージェントの違いは、ひとえに「コンテキスト」にあります。

最近「コンテキストエンジニアリング」という言葉が話題になっています。2024年6月末、Shopify CEOのTobi Lutkeがこの話題に触れ、Andrej Karpathyも、優れたコンテキストエンジニアリングがAIアプリの差別化要因だと指摘しました。

CodeRabbitは、コンテキストの重要性を示す好例です。私たちは毎日、ユーザーのプルリクエストやIDE上で数万件のコードレビューを行っています。CodeRabbitの各レビューコメントは、レビュー対象のコードに関連する多様な情報源からコンテキストデータを収集し、さらに検証エージェントがその提案がPRやコードベース全体の文脈に合致しているかを再確認する、非線形なレビュー・パイプラインによって生み出されています。

コンテキストエンジニアリングは、単に一般的なコーディング規約にパターンマッチするだけのAIコードレビューツールと、プロジェクト固有のアーキテクチャやパターン、目標を深く理解し、実際に価値あるレビューを提供できるツールとの差を生みます。

コードレビューにおけるコンテキストエンジニアリングの本質

CodeRabbitが扱うコンテキストは、次の3つに大別できます。

1. 意図：開発者やチームがコード変更で達成しようとしている目的。プルリクエストの目的、解決したい課題、期待する成果などが含まれます。

2. 環境：システムの現状。ファイルの関係性、コード依存関係、プロジェクト構造、既存のパターンなど技術的な背景です。

3. 会話：通常のLLMのマルチターン会話でやりとりされるチャットメッセージやツールの応答など、その他の情報です。

これらの要素が適切にバランスされAIに提示されることで、単なる構文エラーだけでなく、アーキテクチャの不整合やパフォーマンスのボトルネック、設計上の改善点まで指摘できるインテリジェントなコードレビュアーが実現します。

コンテキストエンジニアリングの最適解を探る

AIによるコードレビューのために適切なコンテキストを用意するには、いくつかの課題を乗り越える必要があります。ここでは、特に難しい3つの課題を紹介します。

1. AIエージェントの「ゴルディロックス問題」

• コンテキストが少なすぎると、AIは不足した情報を推測し「ハルシネーション（幻覚）」を起こしやすくなります。

• 不要なコンテキストが多すぎると、重要な情報が埋もれ、AIが本質から外れた部分に注目したり、情報過多で混乱します。

• ちょうど良いコンテキストは、AIエージェントが正確なインサイトを得るのに必要な情報だけをノイズなく提供します。

2. トークン単位での処理

人間はドキュメント全体をざっと見て重要な部分を直感的に把握できますが、AIモデルはトークン単位で情報を処理し、すべてのテキストに同じ重みを与えます。PRの全コード変更をそのままプロンプトに入れると、AIが些細な点に注目し、重大な問題を見逃すこともあります。重要な変更を優先し、不要な部分は除外する工夫が必要です。

3. コンテキストウィンドウの制約

最先端のAIモデルでも、一度に処理できるテキスト量（コンテキストウィンドウ）には限界があります。特に大規模なコードベースや複雑なPRでは、戦略的なコンテキスト選択が不可欠です。

CodeRabbitのコンテキストエンジニアリング手法

CodeRabbitでは、これらの課題を解決し、常に高品質なコードレビューを実現するために、多層的なコンテキスト準備手法を開発しています。私たちのシステムは、AIの理解力を最大化するために、情報を収集・フィルタリング・構造化する高度な非線形パイプラインを採用しています。上記の図は、私たちがコンテキスト準備で活用している多様な情報源の一部です。

リポジトリ・PR情報のインテリジェントな収集

まず、プルリクエスト自体に関する最も重要な情報を抽出します。

• メタデータ：PRタイトル、説明、影響範囲のコミットなど、変更の「なぜ」を特定するための基本情報を収集します。

• 差分分析：インクリメンタルレビューでは、前回レビューからの正確な変更点を算出し、AIが新規・修正部分だけに集中できるようにします。

• パスフィルタリング：生成ファイルや依存ファイルなど補助的なファイルを除外し、本当に重要なコード変更にAIの注意を向けます。

複数ソースからの知識統合

優れたコードレビューには、現在の変更だけでなく、より広い技術的・ビジネス的な背景理解が不可欠です。

• 過去の学び：エージェントが過去のレビューから得た知見をベクトルデータベースに蓄積し、関連するフィードバックやユーザーの好みを再利用して、コメントの構成に反映します。

• PR意図分析：PRの説明や関連Issueを解析し、変更の根本的な目的を抽出。CodeRabbitのレビューが開発者の目標と一致するようにします。

• コードグラフ分析：コード依存関係をグラフ構造で表現し、ファイル間の関係性をAIが理解できるようにします。これにより、アーキテクチャ全体への影響も考慮したレビューが可能です。

戦略的なコンテキスト組み立て

必要な情報を収集した後は、AIエージェントが理解しやすい形でプロンプトを最適化します。

• パッキングとソート：ファイルを複数のグループに整理し、基盤となる変更から依存先へと論理的な順序でレビューできるようにします。

• 適応的な複雑度管理：ファイルごとに異なるAIエージェントを割り当て、複雑さや重要度に応じてレビューの深さを調整し、効率とコストを最適化します。

• スマートなコンテキスト削減：コンテキストがサイズ制限を超える場合は、要約や分割によって最も重要な情報を残しつつ、範囲を縮小します。

プロンプトエンジニアリング

次の段階では、AIに最適な指示を与えるプロンプトを作成します。私たちのプロンプトは、コードとコンテキストの比率が1:1になるよう設計しており、コンテキストの重要性を物語っています。

• レベルに応じたプロンプト：ファイルの複雑さや重要度に応じて、基本的なチェックからアーキテクチャ分析まで、異なる深さのレビューを行います。複雑度ごとに異なるプロンプトやモデルを使い分けます。

• 構造化されたレビューガイドライン：明確な指示により、AIエージェントが状況ごとに最も価値あるフィードバックに集中できるようにします。過去の有用なレビューコメントのデータも活用します。

• コンテキスト強化：プロンプトには、プロジェクトのコーディング規約やパターン、過去の知見も含め、AIがチーム固有のベストプラクティスに沿った提案を行えるようにします。

• コンテキスト選択：前段階のエージェントによるコンテキスト準備の結果をもとに、最終的なノイズカットを行います。

検証エージェント

レビュー工程の最終段階では、AIによる品質保証の役割を担う「検証システム」が自動的にレビューコメントの妥当性をチェック・改善します。AIレビュアーが自信を持てない場合に発動します。

• 発動条件：メインレビュアーがコメントを生成した際、確信が持てない場合は特別な検証リクエストをコメントに含めて検証を依頼します。

• 証拠収集：検証システムは探偵のように、

  • 実際にシェルコマンドを実行して主張を検証

  • ウェブ検索で追加情報を収集

  • システムの知識データベースから関連情報を取得

• 反復的な分析：一度だけでなく、複数回の調査を重ねて分析を深めます。各ラウンドが前回の結果を踏まえて進行し、徹底的な検証が行われます。

• 意思決定：証拠をもとに、

  • 元のコメントが正しいと判断し解決

  • 人間による確認が必要（結論保留）

  • 問題が確定し修正が必要

  • 元のコメントが誤りと判断し撤回 のいずれかを決定します。

コンテキストエンジニアリングがレビュー品質に与える影響

私たちのコンテキストエンジニアリングパイプラインの高度化は、レビュー品質の向上に直結しています。

誤検知の削減

適切なコンテキストをAIに与えることで、開発者の時間を浪費するような的外れな提案や誤った指摘を大幅に減らせます。プロジェクト固有の慣習を理解し、意図的なパターンを問題として誤検知しません。

より深いアーキテクチャ洞察

コードの関係性やプロジェクト構造を把握することで、単なるリントやパターンマッチでは見抜けないアーキテクチャ上の問題も指摘できます。実際、多くのユーザーが「CodeRabbitがPRの変更による他の依存箇所への影響まで指摘してくれた」と評価しています。

ベストプラクティスの一貫適用

過去の知見やチーム固有の知識を取り入れることで、すべてのレビューでコーディング規約やベストプラクティスを一貫して適用できます。最近では、お気に入りのコーディングエージェントからコーディングガイドラインをインポートする機能も追加され、チームでの共有がより簡単になりました。

継続的な学習と進化

この手法により、レビューのたびにプロジェクト固有の知見が蓄積され、将来のレビューがさらに価値あるものへと進化します。

良いコンテキストエンジニアリングの重要性