10月2日、cymerys.comが「Why Agentic Engineering Is Slower on Older Codebases」と題した記事を公開した。この記事では、レガシーコードベース上でAIエージェントを使った開発が期待通りに速くならない理由と、その改善アプローチについて詳しく紹介されている。
「週末に3つのMVPを作れた」「もうコードを書く必要はない」——そういう声がLinkedInやXに溢れる一方、実際の現場に戻ると話が違う。AIを使ってはいるが、速度はそこまで変わっていない。
この違和感の正体は何か。記事の著者は、Upsideのクライアント向けにエージェント型エンジニアリング（AIエージェントが自律的にコードを生成・修正する開発スタイル。コーパイロット的な補完にとどまらず、タスク単位で自律実行する点が特徴）の実装を進めてきた経験をもとに、既存コードベースに潜む6つの構造的な障害を整理している。エージェント型エンジニアリングの概念的な背景については、Andreessen HorowitzやSequoiaが発表したAI-native開発に関するレポート群も参照されたい。
テストがなければ、エージェントは迷子になる
最も重要な問題として挙げられているのが、自動テストの欠如だ。
AIエージェントによる反復速度は、変更を検証できる速度に上限を引っ張られる。「動いているか」「既存の挙動を壊していないか」——この2点を確認する手段がなければ、エージェントは修正とリグレッションの無限ループに陥る。
多くのレガシーシステムは、テストスイートが薄い。かつてはテストの構築・維持コストが高く、「早く動いて、壊れたらサポートで対応」という文化が通用していた業界も多かった。しかしAIコーディングでは、その方程式が根本から変わる。
記事では「まずテストから着手すべき」と明言している。テストがなければ、エージェントの変更を信頼できない。これが出発点だ。
ドキュメントが人の頭の中にある問題
AIエージェントはコードから実装の詳細をある程度読み取れるが、コードベースが大きくなるほど、細部の文脈を拾い損ねる。これは新人開発者がキャッチアップに時間を要するのと同じ構造だ。
問題は、多くの既存プロジェクトで「なぜこの機能がこう動くのか」という知識が、プロダクトマネージャーやシニア開発者、あるいはCEOの頭の中にしか存在しないことだ。Confluenceにあっても、古い情報と現行の情報が混在している。
解決策として記事が示すのは、ドキュメントをリポジトリかMCP（Model Context Protocol）対応ツールに配置し、エージェントがアクセス・更新できる状態にすることだ。MCPはAnthropicが策定したオープン標準で、AIモデルが外部ツールやデータソースと構造化された形でやり取りするためのプロトコルである。技術的な実装は難しくないが、内容を正確に埋めるには人間によるレビューが不可欠になる。
コードの一貫性がない問題
10年選手のRailsコードベースを例に、著者はこう描写する。
- 2016年当時に流行した関数型パラダイムをオブジェクト指向言語に無理やり持ち込んだコントローラ群
- マイクロサービス化を目指して導入されたが中途半端なままのApache Kafka連携
- 「Railsフロントエンドの未来」として2022年に採用されたHotwireとReactが混在するビュー層
こうした「時代の地層」がAIエージェントの判断を混乱させる。コードベースが標準化されているほど、エージェントの検索精度が上がり、アーキテクチャ上の判断に費やすイテレーションが減る。ShopifyがAI活用に向けてコードベースとインフラの標準化に注力したことを2025年に報告しているのも、この文脈から理解できる。
デッドコード、肥大化したモノリス、自動化の欠如
残る3点を簡潔にまとめる。
デッドコードは、エージェントに「実際には起きないエッジケース」を実装させる原因になる。ハーネス（AIエージェントを動かすための実行基盤）を使って定期的に除去することが推奨されているが、AIが生成したコードにも残骸が生まれるため、継続的なクリーンアップがプロセスに組み込まれる必要がある。
モノリスの肥大化については、著者は「ツーピザルール」（Amazonが提唱した、チームを2枚のピザで養える人数——おおよそ6〜8人以下——に保つという原則）の閾値が変わったと指摘する。1人の開発者が複数エージェントを並列で動かせる今、5人チームでもすでに限界を超えうる。モジュールやサービスへの分割が、以前より早いタイミングで必要になる。
コードベース周辺の自動化については、「IDEでAIにコードを書かせる」だけでは不十分だと述べる。テレメトリのエラーログをトリガーにしてエージェントが自動でプルリクエストを作る、といったコード生成を取り巻くパイプライン全体の自動化が本質的な改善になる。ただしこの領域はまだ業界標準が存在せず、最も実験的な段階にある。
優先順位の付け方
記事の末尾では、現実的な着手順が示されている。単なるリストではなく、各ステップに著者なりの根拠がある点が重要だ。
- テスト（これなしには何も信頼できない。エージェントの出力を検証する手段がなければ、以降のステップはすべて砂上の楼閣になる）
- デッドコードの除去と初期自動化（投資対効果が最も高く、リターンが早い。コードベースの「ノイズ」を減らすことでエージェントの判断精度が即座に向上する）
- 暗黙知のドキュメント化（時間はかかるが、エージェントが文脈を正しく理解するための基盤となる。MCP対応ツールへの配置と合わせて進めることで効果が高まる）
- アーキテクチャの標準化・モノリスの分割（最も時間を要するが、エージェントが並列で複数タスクをこなせる構造を作るうえで避けられない。段階的に進めることが現実的だ）
「一度にすべてやる必要はない」というのが著者のスタンスだ。ただし、これらの障害を放置したままでは、AIエージェントは「コードの一部を書いてくれるアシスタント」以上にはなれない、と明確に述べている。
詳細はWhy Agentic Engineering Is Slower on Older Codebasesを参照していただきたい。
