最近、Rampが自社で開発したInspectというバックグラウンドのコーディングエージェントについての記事を読みました。よい記事です。AIコーディングエージェントの生産性向上をチーム全体にどう広げるか考えているCartesiaのエンジニアにとって、まさにタイムリーでした。
Cartesiaでは、コーディングエージェントを積極的に使っています。チームではClaude Code、Cursor、Codex、Copilot、Zed、Conductorなどを利用しています。モノレポではClaude Code、Cursor BugBot、Vercel Agent、Codexからレビューが来ます。指摘は多様で、補い合うことも、矛盾することもあります。それでも、出荷するコードの品質は実際に改善しています。今のところ、最も人気があるのはBugBotです。
これは上からコーディングエージェントの導入を命じられた結果ではありません。よりよい仕事を速く進め、退屈な作業をできるだけ自動化したいという自然な関心と、実験に必要な費用を惜しまない姿勢から生まれました。
幅広く試すことで、エージェント同士を比較し、最先端の進歩を体験しやすくなりました。数か月ごとに、やり方が書き換わっています。
でも、何かが足りないと感じていました。
コードを書くことは解決したように感じる。でも、エンジニアリングはまだ
最先端のモデルは、複雑なリファクタリングを行い、大量のトラフィックがあるエンドポイントにもコードを組み込めます。先の問題まで見えているように感じることもあります。コードをモノレポにまとめるような簡単な変更だけでも、大きな効果があるとわかりました。エージェントがシステムの構成要素をまたいで考え、微妙なバグを避けられるからです。レビューエージェントも、コーディングの抜けを補います。コードを書くこと自体は、もうボトルネックではありません。
しかし、コーディングとエンジニアリングは別です。優れたエンジニアは、モノレポにコードを組み込むだけではありません。成果を考えます。機能が役立っているかを判断し、実際の反応をもとに改善し、会社の目標を達成するまで続けます。
エージェントが苦手なのは、ここです。私たちはOpus 4.5を使って、1万行以上の機能を安全に削除できました。
それでも、本番環境で機能が使われているかを理解して改善することや、APIレイテンシの急増をコードの特定の行に結びつけることは、まだ頼めません。
本当のボトルネックは、途切れたフィードバックループ
エージェントが失敗するのは、コードを書けないからではありません。実務上の境界で止まるからです。Opus 4.5はA/Bテストのコードを書けても、PostHogで実験の成否を確認できなければ、そこで止まります。UIの修正をデプロイしても、Vercelのプレビューにアクセスできず、見た目を確かめられません。SQLクエリを最適化しても、本番の指標を見られず、改善を確認できません。
私たちは、エージェントが最初から最後まで改善を繰り返せるインフラを、安全に提供することに効果があると考えています。リポジトリ、CI、プレビュー、社内ダッシュボード、PostHogのデータ。人のエンジニアと同じように成功と失敗を判断するために必要なものです。
よい点は、人にも具体的な利益があることです。CIを速くしたり、システム全体を起動しやすくしたりすれば、人のエンジニアも早く仕事を始められ、生産性を保ちやすくなります。
コーディングエージェントの効果を広げる仕事は、戦略的な役割
エンジニアは目の前の問題に集中し、開発体験全体を考える余裕を持ちにくいものです。最新の進歩を追い、新しいツールを試し、学んだことを社内で使える形にするには、専任の仕事が必要です。
機会は開発部門だけではありません。エージェントの生産性を高めるAI向けインフラの考え方は、会社全体の業務も変えられると考えています。GTM、事業、営業のチームには繰り返し作業が多く、適切に自動化すれば大きな効果があります。
エージェントの能力とインフラの差は、自然には埋まりません。人とAIの両方に向けて、開発体験を積極的に設計する人が必要です。
この問題を解くために、AI & Developer Accelerationエンジニアを募集しています。AIと開発者の両方の仕事を速くするエンジニアです。 入社した方には、エンジニアもそうでない人も、最小限の人の介入で問題から解決まで進めるためのやり方をつくっていただきます。その取り組みを外に向けて発信することもできます。ぜひご連絡ください。