AIでコーディングは速くなったのに、なぜ出荷は速くならないのか

これはブルックスがすでに『人月の神話』で考察していたことだ：

「改装したガレージで二人のプログラマーが、大規模チームの最善の努力を凌ぐ重要なプログラムを構築したという新聞記事を時々読む。そしてすべてのプログラマーはそのような話を信じる準備ができている。なぜなら、産業界のチームで報告されている年間1000ステートメントよりもはるかに速くどんなプログラムでも構築できると知っているからだ。ではなぜ、すべての産業プログラミングチームが専任のガレージデュオに置き換えられていないのか？何が生産されているかを見なければならない。」

ブルックスは、ガレージで行われたコーディングは最終製品に必要なもののほんの一部に過ぎないと論じている：

「それは9倍のコストがかかる。しかし、それは真に有用なオブジェクトであり、ほとんどのシステムプログラミング努力の意図された製品である。」

今私たちが見ているものもそれほど変わらないように感じる。最初のドラフト、グリーンフィールドプロジェクト、実験、あるいは少なくともその初期イテレーションを大幅に加速できる。稼働中の本番システムや広く使われているライブラリを変更するのは全く別の話だ。

はるかに多くを出荷しているが、顧客が必ずしもそれを認識するかどうかはわからない。範囲の都合で先送りされていた完全な書き直しが必要なものが、今は完了している。セキュリティ問題はパッチが当てられている。サポートチケットのオープンから解決までの時間は短縮されている。つまり、機能だけに焦点を当てるのではなく、はるかに優れたプロジェクトを作るために、はるかに速く出荷しているのだ。

AIコーディングがもたらした力学の一つは、機能が最初の開発イテレーションの後、AI以前のコーディングと比べてより「完全」または「複雑」に成長することだ。例として、最近会社の内部ドキュメントサイト用のウェブクローラーを構築した。スクレイピング、パース、ベクトル化、インデックス作成のデータの設計は、AIを使わなかった場合よりもはるかに複雑で完全なものになった。これは主に、この分野に関する私の知識不足とプロジェクトの一般的な時間的制約によるものだ。

その複雑さの増大は、以前よりコストが低いとはいえ、設計が「より愚か」であったならば存在しなかったであろう認知的負荷とテストの面で、プロジェクトに時間とコストを追加した。この設計の複雑さの増大という概念は、利用可能な時間を埋めるように設計の複雑さが増大するという、一種のパーキンソンの法則と考えることができる。

AIは確かにコードを書くのを速くしているが、コードを書くことが安くなった今、実際にどれだけの時間が解放されているのだろうか？私たちはしばしば、その解放された時間を他の何かで埋めているだけのように感じる。設計の複雑さの増大はその一つだ。

チケットはより多く、より大きくなり、以前は3つのチームと調整して4週間かかった完全な移行が、今では1日で単一のPRとして完了する。

edit: PRが遅くなっていると感じているなら、それはおそらくあなたの10倍のエンジニア10人が、勤務中に8つのスタートアップのために、横でcodexの3〜4以上のアカウントでコードを投げているからだろう。

LLMへの興奮は、プロジェクトの品質ではなく、エンジニアの生産性にまつわるものだった。伝統的に、新しい作業にはレビューとQAの段階でボトルネックがあり、多くの組織はそれらのボトルネックを修正せずに新しいコードのホースを全開にしている。

高速で走りたいなら、まず高速道路を建設する必要がある。

ソフトウェア開発におけるAIの影響を疑問視する人々が多くて、自分がおかしくなった気がする。

ほんの数年前のソフトウェア開発がどれほど長く困難だったかを、人々はもう忘れてしまったと思う。

今の最大のボトルネックは、エンジニアリングに関するCI/CD/実験と、ビジネスに関するプロダクトの整合性だ。

しているよ。1ヶ月の仕事が1日になった。