Santiago Valdarrama(@svpino)がLinkedInにこんな一言を投稿しました。「I'm writing less code and spending more time managing agents.」この一文が開発者コミュニティに波紋を広げました。コードを書く量が減る — 開発者が?
これは何?
2026年3月現在、開発者の日常が静かに変わりつつあります。NYTマガジンが70名以上の開発者にインタビューした記事によると、サンフランシスコのスタートアップ創業者Manu Ebertは、Claude Codeエージェントを複数台動かしながら一日中やり取りしているそうです。一つは新機能を実装し、もう一つはテストし、三つ目が全体を監督する。以前なら一日かかっていた機能の実装が、今では30分で終わります。
大事なのは、単に「AIがコードを書いてくれる」ということではありません。開発者がコードをタイピングする時間が減り、エージェントに要望を伝えて結果を検証する時間が増えたということです。「どう実装するか」から「何を実現したいか」へ、問いかけ自体が変わっています。
これは一部のアーリーアダプターだけの話ではありません。Microsoftはプロダクションコードの30%がAI生成だと明かしており、開発者の73%がAIツールを週単位で使っています。 GitHubのCEOは、自分の次の肩書きが「コード・クリエイティブ・ディレクター」になるだろうと語るほどです。
Santiagoが言及したTonkotsuというツールが、この変化を象徴的に表しています。元Facebookエンジニアたちが作ったこのデスクトップアプリは、開発者を「コーディングエージェントチームのマネージャー」にします。タスクを計画し(Plan)、複数のエージェントに同時に委任し(Delegate)、成果物のdiffをレビューする(Verify)ループを、一つのインターフェースで提供します。
この変化の本質
IDEやターミナルでコードを「書いていた」開発者が、複数のAIエージェントにタスクを「割り当て」、結果を「レビューする」役割へと移行しています。ツールが変わったのではなく、「開発」という行為の定義そのものが変わりつつあるのです。
何が変わるのか?
2026年のAIコーディングエージェント(AI coding agent)は、すでに三つのアーキタイプに収束しています。CLIエージェント(Claude Code、Codex CLI)、IDEネイティブエージェント(Cursor、Windsurf)、クラウドエンジニアリングエージェント(Devin、GitHub Coding Agents)。インターフェースは違っても、メモリファイル・ツール使用・長期実行・サブエージェントのオーケストレーション(orchestration)という共通アーキテクチャを持っています。
| 従来の開発スタイル | エージェント管理スタイル | |
|---|---|---|
| 中心的な活動 | コードを直接書く | エージェントに意図を伝える + 結果を検証する |
| 並列性 | 開発者1人 = 作業1件 | 開発者1人 = エージェントN台を同時運用 |
| 重要スキル | プログラミング言語の習熟度 | コンテキスト設計 + アーキテクチャの判断力 |
| 生産性の指標 | 書いたコードの行数 | 検証済みのマージPR数 |
| チーム構造 | シニア1 + ジュニア5のピラミッド型 | オーケストレーター1 + エージェントNのハブ・アンド・スポーク型 |
TossのJeong Sehun開発者は、この変化を「抽象化」という言葉で説明しています。AIに業務を委任するのは、結局のところ業務を抽象化する行為です。「この部分はもう自分で気にしない」という宣言でもあります。ただし、間違った抽象化は抽象化がないよりも悪い結果を招きます。エージェントに「うまくやっておいて」と丸投げすれば、必ず失敗します。
HackerEarthの2025年採用データが、この変化を数字で示しています。企業が開発者を評価する際、プログラミング能力(+54倍)、問題解決能力(+39倍)、データ可視化(+35倍)の比重を大幅に引き上げました。「この文法を知っているか」ではなく、「この問題を解けるか」を問う時代になっています。
一方、Googleで同じ質問をすると、答えが少し変わります。Sundar Pichaiが公表した数字はエンジニアリング速度10%向上です。スタートアップの「10〜100倍速くなった」と比べると、温度差があります。何十億行もの既存コードを抱える大企業では、新しいコードを誤って導入すると数百万人のサービスが止まりかねないからです。
始め方のポイント
- 「何を実現したいか」を先に明確にする
エージェントに「この機能を作って」と伝えるのではなく、要件・制約条件・期待する結果を整理して伝えましょう。CLAUDE.mdやAGENTS.mdにプロジェクトのコンテキストをまとめておけば、毎回説明し直す手間がなくなります。 - 検証ループを先に作る
エージェントが書いたコードを一行ずつ目で追うのはやめましょう。テストを自動で実行し、CIを通過しないとPRが開けない仕組みにしてください。「エージェントが自分で結果を検証するシステム」が肝心です。 - 委任の範囲を少しずつ広げる
TossのJeong Sehun開発者が提案するアプローチです。作業が終わるたびに「これをAIにどう任せられるか?」と自問してみてください。次に似たような作業が出てきたら、多少非効率でもエージェントに委任してみる実験をしましょう。 - エージェントの並列運用を試す
Tonkotsuのようなツールで複数のエージェントを同時に動かしてみましょう。一つは新機能、一つはテスト、一つはドキュメント作成。開発者一人がチームリードとして複数の作業ラインを同時に管理する感覚を体験することが大切です。 - コードベースをAIが読みやすい状態に整理する
デッドコード、途中で止まったマイグレーション、競合するパターンを整理しましょう。エージェントは確率的に動作するため、コードベースに矛盾するシグナルがあると、おかしなコードを生成してしまいます。
それでも変わらないもの
シニア開発者の価値は、むしろ上がっています。AIが生成したコードの30%にセキュリティ上の脆弱性が含まれるという研究結果があり、コードのチャーン率(Churn)はAI登場前の2倍に増えています。 エージェントが素早く作ったコードが「本当に正しいのか」を判断できる人、抽象化が崩れたときにシステムと正面から向き合える人の価値は、これからさらに高まります。
