ジュニア開発者の逆襲
(sourcegraph.com)Part 1: 6つのAIコーディングの波
- Vibeコーディングは、LLMにコード作成を依頼し、結果にフィードバックしながら反復する対話型コーディング手法に付けられた軽妙な呼び名である
- 従来のコーディングや自動補完中心のコーディングとは大きく異なる概念で、当初は明確な定義なしに使われていたが、Andrej Karpathyがこれを "vibe coding" と名付けたことで急速に広まった
- 現在、vibeコーディングは次の3つの状態を同時に持っている:
- 業界の80%はVibeコーディングの存在すら知らない。"コーディングエージェント" という言葉すら初めて聞く人も多い
- メディアやSNSを中心に爆発的に拡散中で、論争や賛否の中でも多くの開発者が未来の技術として認識している
- 従来のChatベースのコーディングはすでに旧世代技術として扱われており、より速い新しい方式に熱狂する一部の開発者はもはやchatに関心を持っていない
- 本稿では、AIベースのコーディングの発展段階を全6つの波として説明する:
- 伝統的なコーディング (2022)
- 自動補完ベースのコーディング (2023)
- 対話型コーディング (2024)
- コーディングエージェント (2025年前半)
- エージェントクラスター (2025年後半)
- エージェントフリート (2026)
- このうち伝統的コーディングと自動補完ベースのコーディングは徐々に衰退しており、その後に登場する方式はそれぞれさらに速いペースで普及する
- vibe codingはこれらの波とは別に点線として表される
- vibe codingは上記のすべての方式の上で共存し、特定の方式ではなく、AIが大半のコードを書く状況全体を包摂する概念である
- まもなく登場する "エージェントクラスター" は複数のエージェントを並列管理する概念であり、"エージェントフリート" はAIマネージャーが下位エージェントを監督する構造へと拡張される
- FY26の組織図はこれを描いたもので、1人の開発者が複数のエージェントグループを運用し、それぞれのグループがバグ修正、新機能開発、アーキテクチャのリファクタリングなど多様な役割を担う
- 現在はエージェントが止まったり誤った方向へ進んだりしたときに人間が直接介入しなければならないが、まもなくスーパーバイザーエージェントがその役割を代替するようになる
- 最終的には数十以上のエージェントを同時に扱えるようになり、膨大なレガシーコードを処理する自動化システムになるだろう
- このようなエージェントフリートは 2026年初頭までには確実に登場する見通し であり、並列作業を効率的に構成する技術はすでに整っている
Part 2: あなたは今どこにいるのか?
- いまだにAIをコード自動補完ツールとしてしか使っていない、あるいは Completion Acceptance Rate(CAR) を重視しているなら、Figure 1における 伝統的プログラミング曲線 に当たる
- この曲線は2027年ごろには完全に消えると予想される
- 自動補完は1年前までは人気だったが、今ではもはや中核技術ではない
- より先進的な立場なら、Copilot、Cursor、Sourcegraph、Windsurfなどの IDE内チャットベースのコーディングツール を活用しているかもしれない
- この場合は悪くない位置におり、コード自動補完よりはるかに生産的な方法を導入している状態だ
- チャットベースのコーディングは依然として利用者は多いが、最新技術の基準ではない
- 最近登場した コーディングエージェント(Aider.chat、Claude Codeなど) は、これらすべての方式を圧倒する可能性を示している
- IDEに自然に統合されるようになり、従来の対話ベース方式よりはるかに速く効率的である
- エージェントを一度使えば、以前のやり方には戻りにくくなる
- エージェントベースのコーディングもまたvibe codingの一種である
- vibe codingは "AIがコードを書くあらゆる方式" を意味し、特定の技術方式(modality)ではない
- 違いは、エージェントは 頻繁に対話しなくても 自律的に作業を進める点にある
- 各コーディング方式の変化は、次のような 生産性倍率 のパターンを示す:
- Chatベースのコーディングは手作業の約5倍生産的である
- エージェントベースはchatよりさらに5倍生産的でありうる
- 各波は時間が経てば10倍の生産性も可能だが、新技術がより速く登場することで曲線は平坦化する
- 現在、私たちは巨大なAIの海のただ中におり、ますます強力になる波(新技術)に乗って進まなければならない状況にある
- すべての企業はFigure 1にある導入曲線のいずれか、あるいは複数の上に位置している
- 自分がどの曲線上にいるのかを自問する必要がある
- vibe codingは特定の技術方式ではなく、新しい開発の哲学であり現実である
- もはや自分で直接コードを書かないことが核心である
- コード作成はAIに任せ、人間は結果のレビューと調整だけを行う構造へ移行中だ
- 次のパートでは、この技術変化が 財務的にどのような影響を持つか を見る
- コーディングエージェントは魔法ではなく、コストを燃やすほど賢くなる構造 である
- まだ試していないなら、今すぐ使ってみるか、使っている人を観察することが重要だ
Part 3: 新しいラクダの取扱説明書
- 最新のコーディングエージェントは ほんの数週間前に登場したばかりの非常に新しい技術 であり、多くは ターミナルベース で動作する
- たとえるなら、一生歩いていたところにラクダを与えられたようなもので、便利だが扱いにくく、金もかかる
- "1頭" いるだけでも歩くよりはるかに速いが、つばを吐いたり噛んだり逃げたりもする
- 多くの開発者はいまだにAIコーディングに懐疑的で、依然として 自分でコードを書きたがっている
- 中には "私はコードを書く人間だ!" と明言する人もいる
- しかし、こうした考えはもはや現実に遅れている
- 懐疑的な人ほど、今すぐ 最新のコーディングエージェント(3月1日以降に公開されたもの) をダウンロードして使ってみることを勧める
- 数週間前、筆者自身も驚くほど進化した姿を直接確認した
- エージェントはvibe codingと原理は同じだが、人が直接プロンプトをやり取りする必要がない
- 複雑な作業を自力で実行し、完了したり問題が発生したりしたときにだけ再びユーザーに連絡する
- 作業全体の90〜99%を自動で実行するため、人間はボトルネックから解放される
- chatベース方式との違い:
- エージェントは より大きな作業単位 を一度に処理できる
- その間、開発者は自由に別の作業ができる(例: おやつを食べる、Hacker Newsを見る)
- 例: "このJIRAチケットを解決して" とだけ言えば、
- JIRA CLIを探し、必要ならインストールを要求し
- チケットのフィールドを読むための一時的なプログラムを書き
- コード分析 → バグ発見 → 修正提案 → テスト作成と実行 → ループ反復
- 結果としてエージェントは まばゆい速度で働く人間開発者のような存在 だが、少し方向感覚に欠ける
- 欠点:
- 現時点では 小さな単位の作業しか安定して処理できない
- 過度な期待は失敗を招き、タスク分解(task decomposition) の能力が必須である
- 大きすぎる作業はうまく遂行できず、道に迷ってしまう
- したがって現在は 繊細な問題選定と監督が必要 であり、エージェントは頑固な動物のように扱わなければならない
- しかし、この状況もまもなく変わる見込みだ:
- エージェントは近いうちにIDEへ自然に統合され、より扱いやすく親しみやすいツール へ進化する
- ラクダから鞍付きの馬へ、そして遠からず 戦車(chariot) へと進化する予定だ
- 結論: 今はエージェントと共に働く方法を学ぶのに 最適なタイミング であり、
- まもなくより多くの機能、より良いインターフェース、より大きな生産性向上が続くだろう
Part 4: 数学はないと言ったのに
- このセクションは CIOおよび財務担当者 向けの内容である
- FY26予算をちょうど仕上げた今、開発者1人あたりの LLM利用コスト をいくら計上しただろうか?
- 1日あたり$25はかなり大胆に見えるが、実際には適切な水準に近い
- 現実はさらに深刻だ:
- コーディングエージェントは 非常に高価 で、1時間あたり$10〜12相当のトークンを消費する
- 従来のコーディングアシスタントのライセンスが月$30程度だとすれば、これは 数十倍以上のコスト差 を意味する
- しかし計算上、コーディングエージェントは1日8〜10時間使うと ジュニア開発者1人を雇ったのと同程度の生産性 を持つ
- 1時間あたり$10なら非常に安く、開発者は2体のエージェントを同時に回せる
- 1日あたり$100程度をLLMに支出すれば、開発者の生産性が2倍以上 に上がる可能性がある
- しかし本当の変化は、まもなく登場する エージェントクラスター(2025年Q3予定) である
- 1人の開発者が 複数のエージェントを並列運用 できる
- 各エージェントはバグ修正、新機能開発、ドキュメント作成など多様な作業を独立して実行する
- その結果、1人の開発者がまるで 多数の開発者の役割 を果たすようになる
- もちろん熟練者であるほどその効果は大きい
- エージェントクラスターの登場は ソフトウェア開発環境をクラウドへ移行 させる契機となる
- 数十〜数百のエージェントをローカルデスクトップで扱うのは不可能だ
- クラウドベースの開発環境が事実上の標準となる
- したがって、クラウド予算も追加で確保しなければならない
- たとえば、開発者1人が5体のエージェントを回すと:
- 1時間あたり$50 → 年間約$100,000規模のコストが発生する(クラウド費用は除く)
- これはもはや「安い投資」ではなく、相当な支出である
- しかし 生産性は5倍以上に向上しうる ため、長期的には高いROIが期待できる
- 問題は、多くの企業が 2026年運用予算にこうしたLLMコストを含めていない可能性が高い ことだ
- これにより企業間格差が広がる。予算のある企業は技術的優位を確保し、ない企業は淘汰されるリスクがある
- 結論:
- ソフトウェア開発は今や pay-to-playの超高速列車 である
- チケット(予算)がなければ、集団から脱落する危険が大きい
Part 5: エージェントフリートが来る
- ここからは少し不都合な真実を扱う
- 心の準備ができていないなら、少し休んでから読み進めることを勧める
- エージェントクラスターの次の段階 は "エージェントフリート(fleet)" であり、これは開発者が 100体以上のエージェントを同時運用 する環境を意味する
- このとき上位で制御する スーパーバイザーエージェント が登場し、下位エージェント群を管理し、問題が起きたときだけ人間が介入する
- 未来の開発者の役割 はもはやコードを書く人ではなく、
- エージェントとAIマネージャーが表示された ダッシュボードを運用・監督する役割 へと変わる
- これを皮肉って "AIの子守り" と表現する人もいるかもしれないが、これがまもなく 新しいソフトウェア開発 の姿になる
- CIOの立場から見ると、エージェントフリート時代には 開発者1人あたり1日数千ドルのLLMコスト がかかる可能性がある
- 推論コストが下がっても、ジェボンズのパラドックス により 利用量の増加がコスト削減を相殺する
- 例: あなたのバグバックログが終わりなく積み上がっていることを思い出してほしい
- しかし、これは浪費ではなく 莫大な価値への投資 である
- ついにエンジニアリング組織が経営陣の望む速度で動けるようになる
- まるでスタートアップのような俊敏さで顧客を驚かせ、喜ばせられる時代に入る
- 欠点は 非常に大きな予算が必要だということ である
- 一部の大企業はすでにLLM実験予算をスラッシュファンドのような形で確保しているが、
- 多くの企業は今回の予算編成でこれを まったく考慮していなかった可能性 が高い
- 一部の大企業はすでにLLM実験予算をスラッシュファンドのような形で確保しているが、
- 年末までに 開発者1人あたり$50,000の追加予算 を確保できなければ、構造調整以外の選択肢がなくなるかもしれない
- この変化はむしろ機動力のある スタートアップに有利 に働く可能性がある
- 技術格差よりも 予算の有無が企業競争力を決める時代 が到来する
- そして、もし予算を用意できないなら、削減可能な唯一の部門がどこかは明らかだ
- その答えは読者の判断に委ねる
- 幸い、この予測はやや誇張されている可能性もある
- Claude(LLM) と議論した結果、約 6か月ほど予測を後ろ倒しにしたほうが現実的 かもしれない
- 良いニュースは、ここからが始まりだということだ
- 悪いニュースはもう終わった。残るのはただ一つ、甘美な復讐 だけである
Part 6: ジュニア開発者の復讐
- 未来は暗くない。むしろ ソフトウェア業界には依然として多くの仕事がある
- ただし、手作業でコードを書く伝統的な開発者の役割は消える だろう
- この1年で観察したパターンの1つは、ジュニア開発者のほうがシニアよりもAI導入に積極的 だという点である
- 一部はAIに仕事を奪われるのではと心配しているが、多くは変化に素早く適応している
- O’Reillyの AI Engineering を学び、chat codingやコーディングエージェントを巧みに使っている
- 一方、シニア開発者は ほとんどLLMに触れたことがないか、間接的にしか経験していないことが多い
- AI技術に対する 露骨な拒否感 を示す例もある
- 例: ある有名企業の開発者が「AIを捨てて伝統的コーディングに戻ろう」というスライドPDFを提出した
- こうした反応は 新技術への不安 と 既存知識への投資損失 に起因する
- 新しい言語やツールを学ぶことは本質的に 「また最初からやり直さなければならない」という恐怖 を伴う
- しかし現実は明白だ:
- AIを無視した人たちはすでにゲームから押し出されている
- ジュニア開発者はより安価で、より適応力が高く、より速く学ぶ
- 企業が開発者人員を調整しなければならないとき、どの開発者を選ぶかは明らかだ
"AIがあなたより優れていることを証明する必要はない。あなたがAIをよりうまく扱えるようにならなければならない。"
- つまり、ジュニア開発者は今や 丘の上で光の剣を掲げる立場 にあり、
- シニア開発者に変化へ適応しろと叫んでいる
- この状況全体から得られる教訓:
- あなたが誰であれ、会社であれ、個人であれ — ジュニアのように振る舞え
- 今こそ AI技術を受け入れ、適応するとき である
- Sourcegraphはこの技術進化の流れを日々分析しており、
- コーディングエージェントを エンタープライズのコード資産に接続すること が次世代の中核戦略である
- 全体として見れば、AI導入が進むにつれて ソフトウェア関連の雇用もむしろ増える だろう
- 採用が停滞している現在は、企業がまだどう対応すべきかわからず慎重になっているだけだ
- 歴史的に、技術転換期ごとに生産性は急増し、GDPもまた上昇してきた
- したがって今やるべきこと:
- コーディングエージェントについて学び、習熟すること
- PMや他の技術職も例外ではない
- LLMベースの開発は単なるプロンプト作成ではない。検証、テスト、調整 など実際の開発実務を変えていく
- 警告:
- コーディングエージェントは強力だが トンネル掘削機のようなツール である
- 高価で、停止することがあり、方向を見失うこともある
- 継続的な誘導と現実的な期待値設定 が必要だ
- vibe codingはその名の通り 楽しく働ける方式 である
- コードを直接書かなくてよいという点は、意外なほど大きな解放感がある
- 「6か月後にはもっと良くなるから今は待とう」という考え方は危険だ
- 結局、出発は遅れ、到着はもっとも遅くなる
- エージェントはやって来ている。しかもコーディングエージェントだけではなく、
- 全社業務全体にわたって数百のタスクエージェントがすでに導入されつつある
- 結論としての行動指針:
- chatへ移行する
- 自動補完は捨てる
- 直接コーディングは減らす
- 検証/レビュー/実行をAIベース環境に合わせて学ぶ
- 最新の技術トレンドに合わせて 継続的に実験し、適用すること
- 今は難しく不完全に見えるコーディングエージェントも まもなく一般化する
- 人間に比べてはるかに安価な生産性マシンであり、企業の選択は明白である
- 2025年末には「ソフトウェアエンジニア」という職務は、ほとんど直接コーディングをしなくなる
- その代わり エージェント運用、調整、検証管理 が中心業務になる
- 最後に、今何をすべきかわからないなら、ジュニア開発者に助けを求めること
2年前に『Cheating is all you need』を書いてから、もう2年が経ち、その間にすべてが変わった
今こそ変化のただ中にあり、この流れに乗るべき時だ
23件のコメント
これが本当にもどかしいんですが
従来: 思考 => コード（遅い） => デバッグ
AI: 思考 => 精緻なプロンプト作成 => コード（瞬時） => デバッグ
でも普通は、自分の考えをプロンプトにするよりコードで書くほうが速いんですよね？ すでによく知られていることをやるときを除けば……。信頼性が重要な部分では、どうせ書いたあとに目でロジックを把握しなければならないので、任せることもできないし、任せた瞬間に職業意識がなくなるわけで
もはや開発をしていない開発者出身のマネージャーですが、最近はまたジュニアに戻ったような気分で、あれこれ自分で試しています。チームメンバーに任せていたことを今は自分でやってみるようになり、速度がとても速くなって少し戸惑っています。小規模チームでももっと多くのことができそうだという気もします。良いツールと説明をありがとうございます！
今、趣味で vibe coding を使ってウェブゲームのクライアント、サーバー、管理画面を開発しているのですが（自分では直接修正もしません。修正が必要な部分をコピペして修正依頼し、出てきたコードをそのまま反映しています）、今のところだいたい2万行くらいですね。たまにイラッとすることはありますが、キレながら質問すると今のところはそれなりにいい感じのコードを出してくれています。
私はこの記事に90パーセント以上共感します。
今は、開発の力量とパラダイムが変わる瞬間が訪れているのは確かなように思います。
これからは、監督する能力という側面において、より多くのデザインパターンや、汎用的なアプリケーションの構築方式、問題解決のための方法論などに気を配るべきだと思います。
すでにアルゴリズム開発は人間の限界を超えて久しく、人間には理解できないアルゴリズム最適化をAIが行っているように、これからの開発者はより広く、より多くのトレンドに集中すべき時代です。
AIを学ぶことは重要ですが、新しい技術が出るたびに過剰に反応する必要はないと思います。変わらない中核概念により多くの時間を投資するほうが効果的であり、AIは比較的学びやすいぶん、ゆっくり身につけてもよいと考えています。毎回追いかけるよりも、本質的な能力を育てることが重要だと思います。
今でもたいていの人よりはうまくやれています。オープンソースのグルたちのコードを学習しているので、うまく質問すれば品質の高い結果が出るんですよね（笑）
AI技術の本質がどの水準まで発展するかは分からないでしょう。
今のレベルではまったく話になりません
習得する知識や経験の価値が下がるという側面から見ると、シニアとジュニアの境界自体が曖昧になっていく気がします。
そして、少数独占の市場になる気がします。今後は開発者採用が、投入する努力や経歴の有無よりも、生まれ持った思考力や推論能力に優れたAIパイロットを選ぶ方向になっていく気がします。
監督エージェントか…。
開発段階がざっくり4つあるとして（開発、デバッグ、QAおよびデバッグ、リファクタリング）、4つのレイヤーで起こるハルシネーションを全部捕まえられるのか…。
今でもプロンプトにデバッグやテストの要求をかなり細かく書いておいても、何が問題なのか分からないというたわごとがたまに出てくるんですよね（Sonnet 3.7）。
トランスフォーマーアーキテクチャ自体が変わるなら別ですが。
vibe codingに賛同しにくい理由は、依然としてコードベースで仕事をしなければならないという状況を、AIエージェントが解決できていないからです。エージェントが自律的に動作する環境なら、機械にとって理解しづらいコードがなぜ必要なのでしょうか。私は、AIエージェントが本当にソフトウェア開発の姿を変える瞬間とは、それを指揮するユーザーにとって、コードというレイヤーが完全に抽象化された瞬間だと思っています。まだのところ、単にコード片を素早く生成するレベルにすぎないと考えています（もちろん、それもすごいことですが）。
AIエージェントが私たちをコードから解放してくれる瞬間が来るまでは、変化が驚くべきものであることは認めるとしても、それがソフトウェア業界の仕事の進め方を劇的に変えるという主張には賛同しにくいですね。
現代自動車のメガファクトリー導入と似ていると考えています。
従来の労働者はセットアップおよびメンテナンスへと移行していくのでしょう。（この部分はもう少し理解できます。）
ただ、抽象の領域を扱う部分までもがそうなるのかは？
個人的には可能だと考えています。
まだ少し複雑なパターングループのペアを文字のアルファベット順で書くときに、たまに混乱しています..（お願い！！）キーボードを打つのが嫌なんだけど
最後のジュニアに関する部分さえなければ、ある程度は同感ですね。
AIを受け入れられないシニアや既存企業は世代交代していく、というくらいのほうがより正確な気がします。
会社の重要な開発成果物は、ほぼ100パーセントインターネット上では非公開です。現在のAIの水準では、その程度の品質は作れない。でたらめだ。
知識や実力が似ているなら、適切な環境では似たような結果が出るでしょう。
開発というのは、比較的多くの資料が公開されているWebアプリケーションだけがあるわけではなく、グラフィックエンジンから組み込み、低レベルのチップ設計まで非常に多様ですよね。ゼロ、あるいはゼロに近い状態から始まる分野も多いです。私の分野についても、GitHubであれ文書であれ、インターネット上にまともに参照できるものがありません。もちろん、GrokでもClaudeでもまともな結果は出せませんし。コード全体をモデルに提供するとか、ファインチューニングは論外です。
おそらく、こうした専門性が必要な開発をしていないか、社内で公開禁止の資産をお持ちでないのだと思いますが、ご自身が状況を正確に把握していると確信しすぎないほうがいいです。
インターネット上になければAIが侵食できないという論旨は、少しおかしくありませんか？ 学習方法に関する研究が進み続けるほど、インハウスAIがインハウス開発者の居場所を代替するようになると思っていました。
インターネットが問題なのではなく、AIモデルを作るために学習させられるデータがないという意味ですよね……。なのに、なぜ学習方法に関する研究の話が出てくるのでしょう？ 私はいま、実体的な現実の話をしているんです。2025年末までにすべての開発者を代替するAIなんて、絶対に作れません。そもそも性能の問題ではありません。
私の言葉を誤解されているようですが、会社内のコードでAIを学習させ、それを社内でのコード生成に使う状況を想定したものです。
監督だって、何かを分かっていないといけないんじゃないか……遊んでいるのか、仕事をしているのか、無駄なことをしているのか、ちゃんとやれているのか……監督って電気を消したりつけたりする人だと思っているのか……
電気を消したりつけたりするのが監督の仕事だというなら……その監督こそ、まさにAIに置き換えられるのにうってつけの人だ。
個人的にはあまり同意できません。AIを使って働くジュニアに押し負けるシニアは、そもそもシニアではないと思います。
主張を裏付ける根拠が不足しているようで、残念です。
Neo の名前が変わったのですか？
名前が変わったわけではなく、GN+ と neo の表示が重複しているようだったので、1つに整理しました。クリックすると neo に移動します。