Skip to content

頑固な開発者の死

Steve Yegge御大のCHOPエッセイ【和訳】

2024年12月10日 Steve Yegge

私は5月に「ジュニア開発者の死」というブログ記事を書いた。それが多くの人を怒らせた。その後、多くの大企業によって私の主張が裏付けられ、さらにこれはソフトウェア業界だけでなく、他の業界でも起こっている現実の問題であることが明らかになった。

この記事の主な前提はシンプルで、ソフトウェア開発における2種類のタスクの違いを示すものだ。

1. 葉ノードのタスク(小さな独立したタスク) - 例:「認証ライブラリを書く」「ユニットテストを最新化する」など - 小規模で自己完結的なため、ジュニア開発者に割り当てられることが多い

2. 内部ノードのタスク(複数のタスクを組み合わせる高次のタスク) - 例:「複数の機能を統合してプロジェクト全体を完成させる」 - 計画と調整が必要であり、通常はシニア開発者が担当する

しかし、2024年5月時点で、大規模言語モデル(LLM)が葉ノードのタスクだけでなく、一部の内部ノードのタスクまで実行できるようになった。 つまり、人間が担当するのは計画と調整のタスクばかり になった。そして、それらは通常、ジュニア開発者には割り当てられない。

では、ジュニア開発者は今後何をして成長すればいいのか? 答えは「チャット指向プログラミング(Chat-Oriented Programming, CHOP)を学ぶしかない」。

これはジュニア開発者だけの問題ではない

「ジュニア」という言葉が適切ではなかったことに気づいた。実際に取り残されているのは、単に「経験の少ない開発者」ではなく、新しい技術に適応できない開発者 だ。

実際に私は、以下のような極端な例を見てきた。

  • ジュニア開発者がCHOPを学んで適応し、シニア開発者が「くだらない」と拒否している会社
  • シニア開発者がCHOPを取り入れているが、ジュニア開発者が「仕事を奪われる」と恐れて学ばない会社

どちらも極端だが、共通しているのは、「CHOPを拒否する人」が取り残される ということ。

チャット指向プログラミング(CHOP)とは何か?

なぜ「チャット指向プログラミング」が重要なのか? それは、LLMがコードの「葉ノード」を3Dプリントするような存在になったからだ。つまり、ソフトウェア開発の中心は「コードを書くこと」ではなく「チャットで指示を出すこと」になっている

LLMはまだ完璧ではないが、それでもエンジニアの生産性を30%以上向上させる という研究結果が出ている。 今後、LLMの進化によってこの数値は 10倍、20倍以上 になる可能性がある。

つまり、CHOPを使わない開発者は、圧倒的に不利な立場になる。

「CHOPの時代は短命」という意見もある

一方で、「CHOPは一時的なものに過ぎず、すぐに完全自律型エージェントが登場する」という意見もある。 その根拠は以下の通り。

1. CHOPは難しい

  • 速くタイプし、速く読むスキル
  • LLMの出力を適切に理解し、修正するスキル
  • 文脈を適切に提供するスキル

といった、開発者としての「ハッカー気質」が求められる。 これは「スキルの高い人」にとっては便利かもしれないが、「一般的な開発者」にとっては難しすぎるのではないか?という懸念がある。

2. 完全自律型エージェントが近い将来に登場する可能性

  • 開発者が「短いプロンプト(指示)」を入力するだけで、AIがすべてを処理する
  • 人間は「結果を確認し、問題があれば修正するだけ」で済む

この意見を支持する人々は「開発者の仕事は、ただ短いプロンプトを書くことになる」と主張する。 つまり、CHOPのように「開発者が細かく指示を出す必要がない」未来が来るという予想だ。 特に、「企業の経営者が開発者を雇わずにアプリを作れる時代になるかもしれない」 という極端な主張をする人もいる。

だが、私はこの考えに懐疑的だ。

現時点で、汎用的な自律エージェントが実用化された例はない。 例えば、2024年3月に「Devin」というエージェントが発表されたが、以降の8カ月間、ほぼ音沙汰なしだった。

現実的には、CHOPの時代が少なくとも3~10年は続く可能性が高い

アップデート:Devinがついに正式リリースされた

この記事を公開した翌日、Devinが正式リリースされた。しかも、驚くべきことに 「開発作業のすべてを自動化する」 という当初の主張から大幅に後退していた。

彼らが提供する機能は、主に次の3つ:

  • フロントエンドの修正
  • バックエンドの変更プランを生成(ただし、LLMはすでにできる)
  • バッチリファクタリング(大量のコード変更)

要するに、「完全自律型エージェント」ではなく、単なる「特定用途向けのバッチ処理ツール」に落ち着いた というわけだ。

これは、私の主張を裏付ける結果になっている。 少なくとも、現時点では「汎用的な自律エージェント」は幻想に過ぎない。

CHOPの課題と今後の展望

CHOPには学習方法や評価基準が確立されていない という問題がある。

例えば: - 企業がCHOPの効果を測定する方法がない - CHOPを学ぶための公式な教材が存在しない

しかし、これらの問題を解決しようという動きもある。 例えば、CI/CDの指標「DORAメトリクス」を開発したGene Kim氏が、CHOPの評価指標を作るプロジェクトを進めている

この評価基準が確立されれば、企業がCHOPの導入を合理的に進められるようになる

結論:コードを書くのをやめる時が来た

開発者の仕事は「コードを書くこと」ではなく「LLMに正しく指示を出すこと」になる。 もしあなたがCHOPを使わずに、従来の方法でコードを書いているなら、取り残される可能性が高い

歴史を振り返ると、 - 1990年代にアセンブリ言語に固執したエンジニアは取り残された - 2000年代にクラウドに移行しなかったエンジニアは取り残された

そして今、CHOPを使わないエンジニアが取り残される番だ。

「自律型エージェントがすぐに登場するからCHOPは不要」という考えは、単なる希望的観測に過ぎない。 少なくとも今後数年間は、CHOPを習得することがキャリアの生存戦略になる。

「コードを書くのをやめる準備はできているか?」 あなたのチームは思い切って、コードを書くのをやめようとし始める時だ。そのためにLLMがある。

エージェント型のプログラミングAIの得意な分野と課題

得意な分野

  1. 外部参照やコンテキストを必要としないタスク

    • LLMが与えたコンテキストデータ内で完結できる処理
    • 例:「アルゴリズムの最適化」「標準的なAPI設計」「基本的なフレームワーク設定」
  2. 技術的なドメインに閉じているタスク

    • 業務やプロダクトごとの独自要件ではなく、特定の技術(例:Python、React)の範囲内で完結する作業
    • 例:「特定のライブラリを使った機能追加」「フレームワークの定型コード生成」
  3. モックデータを作りやすいタスク

    • 実データとの統合が不要で、ダミーデータを用いた開発やテストが可能
    • 例:「サンプルデータを使ったテストケース作成」「仮データでのUIプロトタイプ構築」
  4. 既存の実装が豊富なタスク

    • すでに確立されたプラクティスがあり、AIが過去のコード例をもとに生成できる
    • 例:「基本的なCRUD機能の作成」「OAuth認証の設定」

まとめ

  • 「葉ノードのタスク」の自動化による効率化は疑念の余地が無い。
  • 「内部ノードのタスク」(計画・統合・戦略的決定)には、まだ人間のエンジニアが不可欠である。
  • CHOPの発展とともに、エージェント型AIがどこまで自律的にタスクを処理できるかが、今後の重要な課題となるが、少なくとも10年くらいは大丈夫ではないか。という予想。
  • たとえば分散並行処理、アルゴリズムのボイラープレート以外のコード、新しいUXなどは当分無理ではないか。