ソフトウェアファクトリーは、ソフトウェア作業を繰り返し実行するループです。ソフトウェアファクトリーを構築する場合、出荷可能なコードであっても、人間のセンスとオーナーシップが必要です。これについて、今すぐファクトリーが必要かどうかも含めて議論します。
もしそうなら：
- 製品の意図、システム設計（気にする場合）、品質基準を決めるために、最初は人間がループに関与する必要があるでしょう。
- コードレビューは行う（ライトオン・ファクトリー）が、それが最も必要な場所に意図的に集中してください。自動化されたバックプレッシャーが機能しなくなる場所や、保守性のトレードオフが必要な場所に注意を払う必要があると私は感じています。
- 品質チェックは、可能な限り早く、継続的に行うことを目指してください。すべてがそうである必要はありませんが、型システム、自動テスト、ミューテーションテスト、セキュリティスキャナー、アーキテクチャルールのリンティングなどが含まれます。
- チェックの数 != 品質。どのチェックが最良のシグナル・ノイズ比をもたらすか、実験する必要があるでしょう。制約を意図的に厳しくしたり緩めたりする準備をしてください。
ファクトリーは、人間のセンスのいくつかの側面が環境にエンコードされ、エージェントが自分の作業が正しいという証拠を提供し、人間が依然として本番環境に出荷されるものを「所有」するように構築する必要があります。
本当にソフトウェアファクトリーは必要ですか？
私の経験では、標準的なコーディングハーネスで驚くほど遠くまで行くことができます！ つまり、Claude Code や Codex、複数のセッション、検証が組み込まれた優れた仕様、そして制約です。実装と人間の関与基準を備えた GitHub の Issue をまとめて投入することもできます。Claude Code のルーチンや Copilot/Codex のクラウドエージェントは、カスタムインフラなしで、スケジュールまたはイベント駆動型のループをすでに提供しています。
ファクトリーが価値を持つのは、繰り返し可能で一貫性のある実行、エージェント間の作業の引き継ぎ、2 つのセッションが同じ Issue を担当するのを防ぐ、証拠を保持する、レビューが遅れたときに本番環境を停止する、といったことが必要な場合です。
そこで、最初に ソフトウェアファクトリーは、ソフトウェア作業を繰り返し実行するループです と言いました。ここで、非常に小さなファクトリーループを示すプロンプトを実際に見てみましょう。
コードを変更する前に、GitHub Issue #123 とリポジトリの指示を読んでください。
記載されている受け入れ基準のみを実装してください。認証、課金、マイグレーション、既存のテストアサーションは変更しないでください。ブランチで作業し、差分をレビュー可能な状態に保ってください。
npm run lint、npm test、npm run build を実行してください。必要なチェックが実行できない場合は、停止して理由を説明してください。実行したチェック、残っているリスク、人間がまだ決定すべき事項を記載したドラフトプルリクエストを作成してください。マージしないでください。
目標は、チェックが通るまでこれを動かし続け、毎朝特定のラベルがないか GitHub Issues をポーリングしたり、オープンなプルリクエストをレビューしたりすることです。ブランチ保護によりマージの境界を強制でき、人間は何を準備完了にするか選択し、レビューし、最終的なマージの判断を行うことでループに関与し続けることができます。
イベント駆動型の作業キュー（例：Slack トリガー、GitHub Issues、Linear、バックログ）が必要で、それを隔離されたクラウド環境で実行し、トリアージ、実装、テストを処理し、ある程度明示的な人間の監視が必要な場合に、ソフトウェアファクトリーを追加してください。ループの終わりに、本番環境を監視し、Issue を登録して再びトリアージするモニターエージェントを配置するものもあります。
私の経験では、ファクトリーが有用になるのは、異なる実行を一貫して動作させること、エージェント間で作業を引き継ぐこと、異なるセッションが同じ Issue を主張するのを避けること、証拠を保持すること、人間のレビューが遅れているときに本番環境を停止すること、といったことが難しい部分になったときです。
これを解決するものは、少し退屈に聞こえるかもしれません。例えば、Warp は、入ってくるすべての Issue を 4 つの状態（実装準備完了、仕様準備完了、情報不足、実装待機）のいずれかにトリアージし、そのラベルが次のエージェントを起動すると述べています。
このラベルは、一度にいくつかの役割を果たします。キューであり、ロックであり、セッションは準備完了とマークされたものだけをピックアップするため、人間が「ノー」と永久に言わずに何かを保留できる場所でもあります。
ワークフロー的には、Claude/Codex を単に使用する場合と比較して、いくつかの類似点と相違点があります。
- ステアリング: エージェントに軌道修正が必要な場合、入力を与えてリダイレクトできます
- 通知: ファクトリーがブロックされたことを伝える方法。要件が曖昧だった、リスクのあることを開始した、人間の入力（ステアリング）が必要な場合などが考えられます
- ハンドオフ: タスク、その状態、コンテキストをクラウドファクトリー/別のエージェント/人間のレビュー担当者に移動します。適切なハンドオフは、何が起こったか、何が残っているか、なぜハンドオフが必要なのかを追跡します
優れたファクトリーでは、人間は最終的な差分を最後にレビューして承認するだけに限定されません。作業の初期段階で形作ったり、実装中に方向付けたり、ハンドオフを通したり、本番環境への出荷を停止したりすることができます。
検証は、責任あるファクトリーが多くの時間を費やす場所です。これについては後で詳しく説明します。
ソフトウェアファクトリーが必要だと判断した場合、それを構築することだけが選択肢ではありません。ファクトリーを拡張するためのインフラを立ち上げるのは大変な作業であり、購入するか構築するかを検討する必要があるかもしれません。Factory.ai、Devin、Warp、HumanLayer はすべて、このループの一部を販売しています。
私が実際に注意を向けているところ
この 1 年で、ソフトウェア開発に関する私の日々の経験は大きく変わりました。エージェントとの並行作業を増やし、ライトオン・ソフトウェアファクトリーへと移行していることについて、ますます話すようになりました。そして多くの人から、これらのことが実際に何を意味するのか、何を構築しているのか、どのようなプロジェクトにこれらを使っているのか、とよく尋ねられます。その多くは次のようなものです。
ごく普通の日には、私はよりシンプルなライトオン・ソフトウェアファクトリーを持っています。クラウドで実行されているタスクがあるかもしれません。これらのタスクの半分は、私が協力している小規模な企業向けの本番クライアントアプリケーションに取り組んでいるものかもしれません。実際のユーザーがいます。実際の認証、支払い、サブスクリプション、注意が必要な重大なリスクがあります。「ああ、エージェント、テストや制約、品質チェックなしでこれをやってくれ」とは言えません。
オープンソースプロジェクトに取り組むこともあります。自分の本のためのコンパニオンサイトを構築しているかもしれません。ツールを構築しているかもしれません。自分自身のアプリを構築しているかもしれません。これらはすべて、私が取り組んでいる非常に異なる種類のアプリケーションです。そして時には、それらの共通点は、それらに取り組むために使用しているツールだけであることもあります。マイグレーションに取り組んでいるかもしれません。あるいは、実際に大規模な機能開発をしているかもしれません。作業の影響範囲も非常に異なる可能性があります。
したがって、並行作業を増やし、速度を向上させ、生産性を向上させ、自律性を高める（つまり、システムをより信頼できる状態にする）ことを目指し始めると、絶対に人間のコードレビュー、人間の入力が必要な場所はどこか、考える必要があります。
その多くは、最初に必要になります。仕様や要件を定義するとき、製品のデザインはどのようになるのか？製品の意図はどのようになるのか？そして、エージェントが実際に作業を正しく完了したことをどのように検証するのか？既存のシステムを壊していないことをどのように検証するのか？品質基準を満たしていることをどのように確認するのか？
したがって、コードを生成することは、必ずしも最も心配する必要がある部分ではありません。十分なコンテキストがあれば、エージェントは実装を書き、テストを実行し、失敗を検査し、コードを修正してくれます。私たちは、人間のセンスが環境に十分にエンコードされ、構築されているものを信頼できる状態に到達する必要があります。そうすることで、人間の注意を最も必要とされる場所に集中させることができます。
さて、「これらすべてを自動化できるとは思わない」と言う人々からの反発もあります。すべてを自動化しているわけではありません。しかし、生成されるコードの量を考えると、人間がそれをすべて読むのは現実的ではないと思います。特に、私たちはロケットを常に作っているわけではないからです。UI を構築し、フルスタックアプリケーションを構築しています。
私たちの判断力、センスは、最も必要とされる場所に集中するのが最善です。システムの最もリスクの高い部分はどこか？人間のセンスをどこに適用する必要があるか？それはフロントエンドにあるかもしれません。システムの動作方法にあるかもしれません。そのすべてである必要はありません。
私の認知帯域幅はエージェントに合わせて拡張されない
現実には、数十、数百、数千のエージェントを並行して起動できるようになりましたが、あなた自身の認知帯域幅は同じようには拡張されません。これは、以前私が話した認知負債または理解負債につながる可能性があります。
ほんの 5 年、10 年前を思い出してください。エンジニアリングコミュニティでは、コンテキストスイッチングとそのコストについて多くの議論がありました。タスクの途中で同僚や誰かが机に歩いてくるのを嫌がるという話をよくしました。フロー状態に戻るのに非常に時間がかかりました。どこまで進んでいたか、何をしていたかを思い出す必要があったからです。たとえ少し残っていたとしても、時間がかかりました。
私たちは今、以前よりもさらにコンテキストスイッチングを行っています。特定の日に、ソフトウェアファクトリーの外で作業している場合、一度に 5 つか 10 の異なるプロジェクトをエージェントと同時に進めているかもしれません。あるいは、1 つのプロジェクトで 5 つか 10 の異なる機能を同時に進めているかもしれません。5 つか 10 の異なるセッションを持っていることになります。
つまり、それらの少なくともいくつかは把握しておく必要があります。タスクを十分に定義し、成果を定義し、それが十分に完了したことを検証する方法を定義しているという信頼があれば、いくつかのタスクにより多くの自律性を与えることができる可能性があります。しかし、そうでないと感じるタスク、よりリスクやニュアンスが伴うタスクもあるでしょう。注意を払う必要があります。
ソフトウェアファクトリーをレビュアー向けに最適化することを検討してください。これらのアプローチはすべて、その出力を 1 人の人間の注意にルーティングするため、ファクトリーがあなたがまだ下さなければならない決定をどれだけ安くしているかを自問する必要があります。
プロジェクトを間違えるミス
複数の並行プロジェクトをエージェントと進めていたときのことを覚えています。誤って、Web アプリにダークモードを追加したいと思い、頭の中で「よし、これがどうあるべきか」と考えていたのに、誤って別のプロジェクトのセッションに行ってしまい、同じプロンプトを入力し始めたことがありました。
つまり、まったく必要のないものにダークモードを実装し始めたのです。このようなミスは私にも起こり得ます。ソフトウェアファクトリーには、この種のミスをしてほしくありません。
これは実際にはシステムとして考える必要があります。ソフトウェアエンジニアリング文化、チーム文化をシステムにエンコードして、同じような振る舞いを持たせ、どこかにオーナーシップを持たせ、何が起こっても誰かが責任を負い、それらのことについて非常に明確に考えているようにする必要があります。
グリーンが誤解を招くとき
これらのシステムでも、非常に注意する必要があります。AI にテストに合格するのを手伝ってもらうように頼んだとき、多くの人が見たことがあるでしょう。単体テストのようなプログラミングテストの場合、AI はその条件を満たすために単体テストを変更したり、条件を満たすためにコードのロジックを変更したりすることができます。それは、機能的な動作とテストがテストすべきだったことの両方を一致させるというあなたの意図に実際に従ったことを意味するわけではありません。
ソフトウェアファクトリーがすべてグリーンであると表示しているからといって、実際にグリーンであるとは限りません。特に、これらの設定を始めたばかりの頃はそうです。チェック、検証などがすべて正しく形成されていることを確認するために、多くの注意を払う必要があります。期待通りに動作していることを確認する必要があります。誤解を招くようなものであってはなりません。
テストで「認証プロバイダーが変更されました」と言われた状況は避けたいものです。例えば、GitHub を認証プロバイダーとして追加するように頼んだのに、UI にスペースが 3 つしかなかったため、他のプロバイダーの 1 つを削除してしまったとします。そして、それがたまたま顧客が実際に望んでいたものだった場合、問題です。したがって、これらのシステムをどのように機能させたいかについて、非常に明確にする必要があります。
ちなみに、セキュリティも非常に重要です。ファクトリーが GitHub Issue や Slack メッセージのような信頼できない入力を読み取る場合、それは敵対的である可能性があり、サプライチェーン攻撃などの問題を含む可能性があります。Vercel Sandbox/AI ADK Factory のようなソフトウェアファクトリー関連の製品の中には、タスクに必要なシークレットのみを保持する隔離されたサンドボックスでエージェントを実行するものがあります。これにより、侵害された実行がジョブに不要なものにアクセスできなくなります。防御は多層化されることになります。
どの古いプロジェクトに新たな命を吹き込む価値があるか？
また、今日の働き方の大きな部分は、何を存在させるべきかを決めることだと思います。AI 以前の何年も前を思い出してください。放棄されたソフトウェアエンジニアリングプロジェクト、放棄された週末プロジェクト、個人プロジェクトが非常に多くありました。それらを完成させる時間がなかったため、ローンチされませんでした。それらがそれほど重要ではなかったか、時間を見つけられなかったため、優先順位を付けてリリースすることができませんでした。
今では、それらのプロジェクトを完了するのはかなり簡単ですが、同じ人間の判断の問題が生じます。それらのプロジェクトは存在する価値があるのでしょうか？ローンチすべきでしょうか？世に出すと、たとえユーザーが 5 人だけでも、メンテナンスしなければならないかもしれません。維持したい品質基準が新たに生まれるかもしれません。
長年にわたって多くの GitHub プロジェクトがありましたが、今ではエージェントを入手したら、最初にすることはビルドを通すことです。もちろん、クローンすると、すべての依存関係が変更されているためビルドが通りません。半分は時代遅れか、セキュリティの脆弱性が至る所にあるため、更新する必要があります。
次に、テストがない場合はテストを追加する必要があります。プロジェクトを何らかの方法でアップグレードする場合や、より現代的な言語やフレームワークなどに移行する場合に、少なくともその動作が維持されることを確認するためです。
そして、自問し始めます。馬鹿げた例かもしれませんが、昔は Twitter Bootstrap を使っていたけど、今は誰もが Tailwind と shadcn を使っているので、UI を再実装しなければならない。すると、突然これに時間がかかっていることに気づくでしょう。そうです、エージェントはこれをより速くこなせますが、今度はプロダクトセンスや taste などすべてを考慮に入れなければなりません。
それでも疑問は残ります。これは誰のためのものか？市場はあるのか？自分のためか？他人のためか？世に出すとしても、今や誰でも同じように素早く立ち上げられることを考えると、それでも同じように興味深いものだろうか？
したがって、これらのものは存在する価値があるのか？どのようにセンスと判断力を考慮に入れるのか？これらのことは引き続き非常に重要だと感じています。人間の注意という希少なリソースが本当に必要とされる場所です。昔は、1 日は有限の時間しかありませんでした。ミーティングがありました。デザインやコーディングなどに時間を割り当てる必要がありました。
今ではエージェントが手伝ってくれるので、どこに、なぜ時間を費やしているのかについて、非常に明確にする必要があると思います。
サンプルを構築したときに起こったこと
それでは、82 分のファクトリー実行について話します。人々からかなり長い間、「ソフトウェアファクトリーを構築するにはどうすればいいですか？」とか、「Claude Code や Codex を使うのに慣れています。セットアップをソフトウェアファクトリーに進化させるにはどうすればいいですか？」と尋ねられてきました。
そこで最初に言っているのは、「今のままで十分かもしれません。ファクトリーを必要とせずに、あなたの作業はまったく問題ないかもしれません。」ということです。しかし、人々がチェックできるリファレンスセットアップを提供したいと思いました。そこで私がまとめたのは、Factory というリポジトリです。チェックしてみてください。また、デモアプリケーションとワークショップも用意しました。
ここ数年、多くのことのための私の定番デモアプリケーションは映画アプリです。私は大の映画ファンです。映画を見るのが大好きで、いつも映画を見ています。そのため、非常にシンプルな映画アプリから始まるデモアプリケーションを持っています。そして、ファクトリーに実装してもらいたい機能がいくつかあります。いくつかの異なる機能があります。お気に入り機能が欲しい。検索ができるようにしたい。ダークテーマも欲しいかもしれません。そのようなものです。
そこで、ファクトリーにこれらの作業を開始させます。実装をチェックアウトできます。その利点の 1 つは、実際の問題をキャッチできたことです。これらの問題は、ワンショットの実装を依頼しただけでは気づかなかったかもしれません。
おそらく 60 分くらい経った頃、「わあ、これは異常に遅い」と感じていました。ファクトリーを使ってハーネスに「なぜ遅いのか？」と尋ねました。すると、「これはまったく問題ありません。すべての検証プログラムがまだ実行中です。」と言われました。
個々のタスクは 10 分、15 分、20 分で完了すると予想していたかもしれませんが、検証、リトライ、ブラウザチェック、人間のレビュー、その他の追加の遅延を含めると、2 倍から 4 倍の時間がかかることがあります。
これらは、より良い品質とシステムへの信頼につながると思います。測定の観点からは、マージされた PR あたりのコストやコードの保存期間を、理解負債の指標として見るかもしれません。
また、有用な遅延とファクトリーのオーバーヘッドについても考える必要があります。私の場合、検証プログラムは実際の問題をいくつかキャッチしました。時間の一部は、私が望んでいた証拠を生成することに費やされたかもしれません。一部はファクトリーの実行におけるオーバーヘッドでした。最適化に時間を費やしたわけではありませんが、価値を見出せないチェックをたくさん実行するだけのファクトリーは、高品質とは言えません。
繰り返し実行されるチェックについて、それらは無関係か？ノイズが多いか？実際にシステムをより安全にしているか？を調査する必要があります。
検証には予算が必要
検証の予算について私が考えている方法は、基本的にこれです。検証予算について話しています。これは、これまでパフォーマンス予算について考えてきたのと同じ方法で考えています。
ソフトウェア開発ライフサイクルの早い段階で実行できる特定の種類のチェックもあれば、非常に重いけれども多くの価値を提供するため、後で実行したいものもあります。高速なチェック、例えばリンティングや型チェックなどがあります。これらは比較的高速なチェックで、早い段階で実行できます。
テストスイート全体は、ドラフト PR がまとめられる直前またはその後により近いタイミングで実行できます。これには、ミューテーションテスト、ブラウザテスト、セキュリティチェックなどが含まれます。
これらを単なるサマリーに置き換える必要は必ずしもないと思います。実際のテストが必要ですが、開発ループを遅くしたくないため、適切な場所に予算を割り当てる必要があります。私は決して開発ループを遅くしたくありません。高速なイテレーションループを持つことは私にとって重要ですが、同時にそれらのチェックとバランスも維持したいと考えています。
実行が出荷されないとき
上記で書いたことの多くは、チェックに関するものです。
Vercel は、ソフトウェアファクトリーにおいて、すべてのエージェント実行を「成功」、「欠陥あり」、「ブロック」、「手動」としてマークし、「成功」のみが本番環境に出荷されます。残りはシステムに再投入されます。私も同様の観点で実行について考えてきました。
ここでの「欠陥あり」は、間違ったものが実装された、または完全なコンテキストがなかったため、修正が必要であることを意味します。「ブロック」は、環境に資格情報が不足しているため、提供する必要があることを意味します。「手動」は、ファクトリーがまだ越えてはならない境界です。
ここでの 3 つのうち 2 つは機械的な修正が可能であり、最後の 1 つは信頼に関するものです。
これは素晴らしいことですが、この分類ではコストがわかりません。TMDB アプリを使った私のファクトリー実装に戻ると、却下なしのクイックファインダーは 7 分かかりました。2 回の却下と途中での人間の判断があったお気に入り機能は 56 分かかりました。同じファクトリーです。したがって、この分類とステージごとのタイミングを組み合わせることをお勧めします。そうしないと、実行が欠陥ありで戻ってきたことはわかっても、そのコストがいくらだったかはわかりません。もう 1 つ修正したいのは、境界でのハンドオフです。私のサンプルファクトリーは最初の Issue を停止し、それを factory:needs-info に移動しました。これは正しいですが、回答をどこに置けばよいかわかりませんでした。手動実行は、ファクトリーが停止した時点で終了するのではなく、人間が次に何をすべきかを知った時点で終了します。
自律性は単一の設定ではない
数週間前に、エージェントの自律性と自律性の考え方についての記事を書きました。自律性は、すべてのプロジェクトで単一の設定になるわけではないからです。
検証は信頼を買い、エージェントにより多くの自律性を与える能力を買います。例えば、重要な変更に取り組んでいるが、いくつかのチェックが整っており、すべてが正しく検証され、おそらく自分自身で手動チェックも行ったとします。次に同じプロジェクトで同様のタスクを行うときは、エージェントにもう少し自律性を与えても大丈夫だと感じるかもしれません。
ソフトウェアファクトリーを構築するときに考えるべきことはこれです。検証はリスクに応じて変化します。目標は最良のシグナル・ノイズ比です。実行している大規模なチェックリストをただ持っていればいいというものではありません。
再学習が必要だった機能
Claude で複数のセッションを使用していた日に先延ばしにしていた機能がありました。一度にいくつかの異なるプロジェクト、プロジェクトごとにいくつかの異なる機能に取り組んでいました。Claude は私が取り組んでいた機能を実装しました。テストは通っているように見えました。検証についてあまり考えていませんでしたが、テストが通ったので、うまくいったと思いました。マージしました。
これはお気に入り機能でした。かなり良いと思いました。ブラウザで確認してみました。問題ないように見えましたが、数日後、いくつか微調整をしようと思い、実際にコードに戻りました。
エージェントに変更を依頼するだけでは済ませたくなかった。なぜなら、それはごく微妙な動作の違いだったからだ。アイコンをタップしても、タップ時に正しいエフェクトが表示されなかった。だから、自分で微調整したかった。どのように動作するのかを理解して、エージェントに正しく指示できるようにしたかったのだ。
コードに戻ったとき、その機能がどのように動作するのかを説明できなかった。このリポジトリは私のものだ。変更を承認した。リポジトリの多くの部分、多くの動作は理解していたが、積み重なっていくコードのすべてに理解が追いついていなかった。
私が理解できなかったのは、追加されたこの機能が実際にどのように動作するのか、UI がどのように動作するのか、そのエフェクトがどのように機能するのか、ということだった。この機能をやり直し、実際にステップバイステップで「これはどう動くのか？どうすれば理解できるのか？」と確認する必要があった。
並行作業が理解に与える影響
並行作業を行うと、この全体的な問題が増幅される。そして、ソフトウェアファクトリーでそれを行うと、さらに増幅される。5 つや 10 のセッションを同時に進めると、単なるレビューの量の問題以上のものが生まれる。別の作業をしている間に、かなり冷めてしまう可能性のある複数のメンタルモデルが生成される。
これまで、コンテキストスイッチングの課題についてよく議論されてきた。チャットが圧縮されると、いくつかのアプローチを却下し、別の方法を試し、エージェントとペアリングすることになる。セッションで起こったすべてのことを覚えておくのは難しい。
スクロールして戻っても、圧縮が行われているため、すべてがそこにあるわけではない。すべてを頭の中に保存しておくこともできない。コードは、下された決定を保存することが多いが、なぜその決定が下されたのかは保存しない。
これは、あなたにとって有益な学びになると思う。エージェントに、その軌跡に関する情報や、問題にどのようにアプローチしたかに関する興味深い教訓を実際に保存するように依頼することを検討することが重要だ。そうすれば、後でそれに戻ることができる。
これは、リポジトリにコミットするかどうかを自分で決められる。必要ならローカルに保持しておくこともできるし、チームと共有することもできる。しかし、それは後で参照できるものになる。セッションに残っているかもしれない、あるいは後で覚えているかもしれない、という不確かなものに頼るよりも良い。
実際に何を生み出しているのか？
@threepointone と @bentlegen が、ソフトウェアファクトリーに関する 見解 を 投稿していたが、私はそれに強く同意した。
「実行」の仕組みに魅了され、その仕組みを最適化し、本来何を生み出すべきだったかを忘れてしまうのは簡単だ。もしあなたのファクトリーが主に、より良いファクトリーを生み出しているだけなら、あなたはその製品が自分自身であるようなソフトウェアを構築していることになる。
ループに投資すること自体は問題ないし、複利効果もある。失敗は、ループが閉じてしまったとき、つまりファクトリーが生み出すすべてのものがファクトリー自身によって消費され、外部の誰もスイッチを切っても気づかないような状況になったときに起こる。私が適用するテストは「プル」だ。外部に改善を求めている何かが存在しなければならない。誰がプルしているのかを特定できなければ、それは磨きすぎ（ポリッシング）だ。
オーナーシップは消えない
これらすべての根底には、より広い原則がある。
人間が物理的にタイピングするコードの割合は劇的に減少するかもしれない。しかし、人間のオーナーシップがそれに伴って減少する必要はないと思う。
- 誰かが依然として問題を選択する。
- 誰かが依然としてアーキテクチャを選択する。
- 誰かが依然として品質基準を設定する。
- どの検証シグナルが信頼に値するかを誰かが決定する。
- いつエビデンスがリリースに十分かを誰かが決定する。
そして、結果として得られるシステムが失敗したとき、「エージェントが書いた」では済まされない。これが、ソフトウェアエンジニアリングの未来が「人間がループから外れる」と表現するのが最適ではないと私が考える理由だ。代わりに、人間の判断が再配置されているのだ。
機械がより強力で、より速く、より確定的なシグナルを生成できるループの部分からは、人々を排除すべきだ。同時に、コンテキスト、センス、リスク、長期的なオーナーシップが最も重要となる場所に、人々を集中させるべきだ。
最高のソフトウェアファクトリーは、人間の関与をどれだけ完全に排除するかによって定義されるわけではない。
それらは、人間の関与をどれだけインテリジェントに配置するかによって定義されるのだ。
意図、システムの形状、品質基準については、人間の判断を上流に保つ。自動化されたバックプレッシャーが弱くなるか、結果が主観的になるコードをレビューする。すべての確定的なシグナルを、可能な限り早期かつ継続的にループに押し込む。システムが信頼を得たり失ったりするにつれて、制約を意図的に強化したり緩和したりする。
最終的にリリースされるコードに対して、人間が依然として責任を持たなければならない。リリースに十分なコードは、それが存在すべきかどうかを気にする誰かから始まる。
