NISHIO Hirokazu[Translate]
Shipping with Codex

>hillbig OpenAIのエンジニアたちが、実際にCodexを使ってどうやって開発しているかを紹介した動画がある(スレッドに)。
>
> やっていることはTDD(テスト駆動開発)に近く、最初に設計してテストを書き、そのテストが通るまでコードを直していくという流れだ。設計もAIを使って詳細化いくとともに、作業工程はマスタードキュメントに集め、それが作業のたびに更新されていって、開発の進み方を一連で見ることができる。
>
> さらに、作ったコードを実際に導入する段階でも、ちゃんと問題がないかをAIエージェントが確認し、バグがないかを、様々な仮説を立て検討しながら実際にコードを動かし検証する。そして変更点が大きくなりすぎないように、主要な変更点を1〜2個に絞ってPR(Pull Request)を作る、というサイクルを繰り返している。
>
> その結果、1時間あたり約4000行もの変更を含むPRを作ることができ従来の開発とは次元の違う生産性を実現している。どんなに優れたプログラマーでも、このような生産性はでないし、この作業スループットは今後も指数的に増えていくだろう。
>
> こうしたAIエージェントが登場すると、開発者の役割は「AIが正しい方向に進んでいるか」「意図どおりに開発できているか」を確認する立場に変わってくる。
> 人は全体を高いレベルでチェックすることはできても、すべてのコードを目で追うのはもはや不可能である。
> 動画の中でも「もう全部は見きれないね」と話し、結果を了承するコマンドを打っている。だからこそ、設計書(Design Doc)やテスト、検収条件といった“ドキュメント”の重要性がますます増している。これは、外部に開発を発注するのと同じような構造だといえる。
>
> ===
> こうした、AIによるプログラム開発支援で起きていることは、これから他の分野にAIエージェントが広がっていくときの先例になると思う。
>
> 「AIツールを使うとちょっと楽になる」というレベルではなく、かなりまとまった仕事をAIに任せて、生産性を数十%から数倍にまで引き上げる変化が他の分野でも起きてくるだろう。そのときに大事になるのは、「人がどうやって全体の品質を担保するか」「AIにどう指示を出し、どうフィードバックを受け取って協調していくか」という全体設計だ。
>
> これは、今の企業やチームの分業・協力の仕組みと本質的には同じだ。人と人が知識を共有し、設計書やテスト、細かいレポートやフィードバックといったつながりのもとで仕事を進めるように、AIとも同じようなやり取りが必要になる。
>
> ソフトウェア開発は、人間が作るものの中でも特に複雑な領域であり、そこがAIによってどう変わっていくかを見ることは、きっと他の分野にとっても大きなヒントになると思われる



"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]