要約

  • 最強のモデルを選ぶ
  • 単純なタスクの成功率が高くなっているので、複雑なタスクを単純なタスクに分解する
  • 複雑性管理のためのエンジニアリング能力はまだ人間が優位。高度なエンジニアリング能力は、AIの潜在能力を引き出すためにより正確に要件を記述できる
  • 高品質のドキュメントは高品質な出力に有利、特にプロジェクト自体のドキュメント

AI プログラマーを雇用して1年、複雑なプロジェクトにおいて、より高度に AI が人間のプログラマーを代替する方法を探し続けてきました。

これは2025年2月時点の観察進捗と最良の実践です。

最強のモデルを選ぶ

現在最強のコーディングモデルは依然として o1 pro です。理由は推論時間の延長と o1 自体の基礎の良さだと推測します。

o1 pro は遅いですが、欠点とは言えません。コードを書くのは元々ゆっくり考えて素早く書くものだからです。速度より正確さと合理性の方が重要です。

単純なタスクが最高

大規模言語モデルのプログラミング能力を示す際、よく完全な単純タスク(ToDoアプリやスネークゲームなど)を書かせます。

これらのタスクは境界が明確で、外部システムとの相互作用がほとんど不要で、ゼロショットではないため、非常に上手く完成させられます。

この利点を活かすには:1)利用可能な最強のモデルを使用し、2)要件記述時に厳密に境界を定め、単純タスクで複雑タスクを構成します。

2点目について、各モジュールをサードパーティのように扱います:内部ロジックをカプセル化し、インターフェースを通じて外部にサービスを提供し、依存する外部リソースは規定のプロトコルで取得します。これはソフトウェア工程の実践目標でもあるので、この原則に従えば工学的品質も向上します。

典型的な開発要件のプロンプトは以下のようになります:

implement a golang module, here are requirements:
- requirement 1...
- requirement 2...
- ...

here are interfaces:
- method 1...
- method 2...
- ...

here are dummy functions you may needs:
- function 1
- function 2
- ...

here are criteria:
- criterion 1
- criterion 2
- ...

このプロンプトを o1 pro に与えると、現在最良の結果が得られます。

エンジニアリング管理は人間が行う

現在、大規模言語モデルは最高レベルと最低レベルのエンジニアリングタスクで優れた性能を示しています。最低レベルは上述の「単純タスク」です。

最高レベルは全体アーキテクチャの抽象化で、コンサルティングを受けるアーキテクトの役割を果たし、質問に対して選択肢を提示し、参考として非常に有用です。

しかし、この二つを繋ぐ中間のエンジニアリングタスクについては、DevinやCursorのAgentを使用しても、現在の大規模言語モデルは複雑なエンジニアリングの中間部分を適切に処理できていません。

二つの問題があると理解しています:1)エンジニアリングに関する暗黙知がコードやドキュメントに反映されておらず、ソリューションやアーキテクチャの選択に最適解が存在せず、多くの泥臭い作業がある。2)モデルが受け取る内容が増えると、明確な境界が欠け、幻覚が深刻になる。

2つ目の問題は、エンジニアリング面でより多くの作業が必要かもしれません。例えば、静的解析の結果と組み合わせる(推測ですが、私は言語分析の専門家ではありません)などして、問題の規模を縮小することが目的です。

1つ目の問題は、本質的にコードとドキュメントは同じです。2つ目の問題が解決しにくい場合、知識を補足するだけでは不十分かもしれません。

IDEについては、vscode、cursor、windsurfに本質的な違いはないと考えています。結局のところ、モデルの能力には限界があり、IDEが最終的に誤った予測を出すなら、o1 proが一発で正解を出すほうが良いでしょう。

高品質なドキュメント

コードは自己説明的ですが、高品質なドキュメントがあればモデルのプロジェクト理解と認識が向上します。

この点ではモノレポが非常に有利です。ドキュメント自体がリポジトリ内にあり、IDEで1つのMarkdownファイルを指定するだけで十分だからです。

この理由から、私は徐々にプロジェクト単位でモノレポを組織し始めています。

人間のプログラマーを代替する実現可能性

Sahil Lavingiaの見解に同意します:

もはやジュニアレベルや中級レベルのソフトウェアエンジニアを雇用しない。

また、私もantiworkに似たことをしています。例えば、HelperのようなAIボットや、Iffyのような反スパム対策などです。

私の実践経験は以下の通りです:

  • 能力の高いエンジニアがAIを適切に活用すれば、5〜10倍の生産性向上は全く問題ありません。つまり、会社が技術力の産出で利益を得ているなら、50%〜80%の人員削減も可能です。
  • 複雑さを適切に分割し、優秀なエンジニアの監督下であれば、AIは中規模プロジェクトを継続的に反復できます(Quailyを例に挙げると、バックエンド部分の核心的なコードは約1Mトークン)。
  • 良いニュースは、AGIが来るかどうかに関わらず、LLMの能力の上限は多くのことを変える十分な力があることです。
    • 悪いニュースは、その下限が多くの人間の上限よりも高いことです。
      • さらに悪いニュースは、良いニュースを十分に理解できない人々は全て、悪いニュースの影響範囲内にいるということです。