「広く作って、狭く出荷する」——AI時代の新たな開発フロー
Build Wide, Ship Narrow
従来の開発では、設計段階でPRの分割を決めていたが、AI支援により、まず全体を一気に作り、後から自然な境界でPRに分割する「Build Wide, Ship Narrow」という手法が有効になっている。著者は、仕様を先に確定し、広く実装してからデモで検証し、最後にコードレビュー用にPRを分割するという流れを実践。分割はAIエージェントが行い、削除は最後のPRにまとめる。この手法により、レビューが容易になり、誤った方向性を早期に発見できる。ただし、本番環境での順序が重要なマイグレーションには不向き。
構造上の決定は消えない。ただ、コードが目の前にある状態で行えば、そのコストは劇的に下がる。
HNでの議論
32- smashed
それは理解しにくかった。私の理解が正しければ、アイデアは制約なしに反復すること、つまり速く動いて物を壊すこと（広く作る）だ。デモをして、どんどん変更を加え続ける。変更の量を気にせず、きれいなコミットも気にしない。自由に探索して、必要なだけ変更を生み出してよい。
それからAIエージェントを使って履歴をきれいにし、従来の方法で出荷できるきれいな変更セット、つまり小さくてきれいなコミットを作る。
それは面白いアイデアだと思う。AIエージェントは大量のコードを生成するだけでなく、git履歴をきれいにするのにも使える。
でも、ヘビーなLLMユーザーはきれいなgit履歴や変更セットをあまり気にしないと思う。もしプロジェクトや既存のワークフローがそれを要求するなら、余分な手順を踏むかもしれないが、実際にはあまりやられていないと思う。
本当にこれらの小さな変更をレビューするつもりなのか？今のところ、エージェントの例はひどいものばかりだ。関係のない変更があちこちに散らばっている。ほとんど無害かOKな変更だが、焦点が定まっていない。
- moezd
最近、パスカルの言及が増えている気がする。「短くする時間がなかったので、長くしました」みたいな。
コードベースに大量の変更を加えることは、これまで一度も印象的だったことはない。LoC（行数）は常に進捗の悪い指標だった。それなのに、現代のフレームワークや人気のツール、場当たり的なビジネスロジックは、できるだけ多くのLoCを吐き出すことをほとんど強制している。ソフトウェアエンジニアリングはこんなに冗長であるべきではなかった。
- bluegatty
少し困惑するが、この仕事の小さなバリエーション：マージしない実験的なブランチを大量に作る。
AIが壁にぶつかったブランチから学べるのは驚くべきことだ。
実際の製品で無茶な反復をする必要はないと思う。スクラッチスペースでやって、「コードではなく教訓をマージする」だけでいい。
この「事前設計」というアプローチは、悪い前提を多く組み込んでしまうので、うまく機能したためしがない。
実験的な取り組みは、それらを解決するのに役立つ。
それを乗り越えたら、脇に置いて、スクラッチの作業に基づいてAIに計画させればいい。
絡み合ったものはスクラッチスペースにある。それがスクラッチスペースの目的だ。
そして重要なのは、ほとんどコストがかからないことだ。
AIの力は「細かいバグ」ではなく、PRやレビューを気にせずに解き放てるスクラッチブランチの洪水だ。
すべてが解決されたら、解決への道筋は実際には比較的明確で、「計画を立てて」実行するだけでいい。
- freditup
なぜ企業がAIが書いたような記事をブログに載せるのか、そしてなぜ著者がそれを自分のものとして載せることを許可するのか、私には理解できない。
著者へ：もし実際に深く考えた内容があって、最終的な執筆をAIに任せたら、最終的な製品の価値を大きく損なう。この著者には良い内容があると思うが、AIが生成した散文はそれを台無しにしている。
企業へ：もしブログが採用目的（よくある大きな動機の一つ）なら、AIが書いた駄文は優秀な人材にとって大きなマイナスになるだろう。
- forgotTheLast
私は複数のサービスを保守する小さなチームで働いているが、これは私たちのアプローチと非常に似ている。ただし、私は一般的に、バックエンド/フロントエンドでPRを分割しない方がレビューが簡単だと思う。追加のコンテキストが役立ち、インターフェースが一致することを確認するために2つのファイル/変更セットを行ったり来たりする必要がない。相互に依存する複数の破壊的変更がある場合、昔ながらのフィーチャーブランチも役立つ。
追伸：ブルーノ、次回はLLMの飾り立ては省略してくれ。読みにくくなる。