ソフトウェア工場が失敗する理由：ハーネス工学だけでは不十分である

人間によるコードレビューを排除するソフトウェア工場は、モデルがコードベースの品質を維持できないため失敗する

コードを誰も読んだり書いたりしない「ライトオフ」ソフトウェア工場は実際には機能しない。2025年7月に完全なライトオフアプローチを試みた作者のチームは、障害、怒ったユーザー、そしてエージェントが導入した品質の低いコードを掘り下げる羽目になった。より多くのループ、より良いハーネス、より多くのトークンがあればスピードと品質の両方が得られるという約束は、根本的な制約を無視している：現在のモデルは、タスクがテストを通過するかどうかだけを訓練および評価の基準としており、結果として得られたコードが長期間にわたり保守可能かどうかは評価対象外である。

現在の訓練とベンチマークはタスク完了を奨励し、保守性は無視される

モデルの訓練では、単純なパス/フェイル検証器（例：SWE‑bench Multilingual）によってスコア付けされたトレース上で強化学習が行われる。悪い設計に対するペナルティは存在しないため、モデルはどこにでもtry‑catchブロックを追加したり、型システムを損なう遅延型キャストを使ったりするよう学習する。悪いアーキテクチャのコストは数週間、数ヶ月、あるいは数年後に現れるため、強化学習中に保守性を報酬するための迅速なオラクルは存在しない。その結果、最先端ベンチマークで優れた成績を収めるモデルでも、コードベースの品質を時間とともに低下させ、単純な変更が多くの場所で編集を必要とし、隠れたバグのリスクを高める。

新たなベンチマークは保守性を評価しようとしているが、依然として限界がある

SWE‑Marathon（長時間で複合報酬タスク）、DeepSWE（訓練データにない大規模OSSタスク）、Frontier Code（マルチPRタスク、変異テストおよびジャッジモデル付き）といった取り組みは、パス/フェイルを超える品質をスコアリングしようとしている。しかし、良いコードと悪いコードを信頼性高く区別できるモデルは、そもそも良いバージョンを最初から書く能力を持っているはずであり、保守性に対する迅速かつ信頼できるオラクルはまだ存在しない。これらのベンチマークは有望ではあるが、長期的なコードの健康状態を示す信頼できるシグナルを提供しているわけではない。

人間のレビューを前倒しで導入することで成果が向上する

ライトを再び点灯させること——人間のレビューをプロセスに組み込むこと——と前倒しの整合性を組み合わせることで、再作業が減り、レビューが速くなる。推奨されるプロセスは4段階からなる：製品レビュー（問題と成功基準を定義する短いドキュメント）、システムアーキテクチャ（サービス、エンドポイント、スキーマ、キュー、ストアの可視化）、プログラム設計（型、メソッドシグネチャ、コールスタックツリー、擬似コードでのファイルツリー差分の定義）、垂直スライス（早期にエンドツーエンドのトレーサブルを構築し、反復的に進める）。この計画に約30分を割くことで、作者の経験ではレビュー時間は数時間から数分に短縮された。

コミュニティの知見は人間の判断、ガバナンス、モジュール設計の必要性を強調している

コメント者たちはいくつかの実践的な点を指摘した：

モデルのスキルよりもガバナンスと文化が重要である；人間が関与する、セキュリティと規律を備えた丁寧なハーネスがあれば、成功するダークファクトリーが実現できる。
プルリクエストのユーザーエクスペリエンスは悪い；LinearのPRレビュー機能のように、変更をテーマごとにグループ化し、コメントを追加するツールは認知負荷を軽減する。
AIファクトリーは意図を生み出せない；人間がビジョンと制御枠組みを提供しなければならない。
最初にモジュールアーキテクチャを構築することで、エージェントが独立したモジュールで作業でき、保守性の懸念が低くなる。
トークン補助が、モデルの品質よりも特定のハーネスの早期採用を促進した可能性がある。
フロンティアモデルのブレークスルーを待たずに、代表的なリポジトリレベルのデータセットを使ってエージェントの品質を評価するなど、ハーネス自体の最適化が効果を高める。
エージェントはコードベースに見られるパターンを模倣しがちなので、明確で一貫したパターンを確立することで、有用なコードの生成を助ける。
複雑なコードベースでは、エージェントが状態変数を繰り返し重ねがちである；それらを和型にリファクタリングするか、形式モデル（例：Quint）を使うことで、明確さを回復できる。
1年以上経過したバックエンドとフロントエンドを備えたコードベースでも、明示的な人間の指導が必要である；モデルだけでは人間のコードを理解できない。

モデルの制約内で最適化する：理解と品質のためには人間をプロセスに残す

根本的な制約は、モデルが孤立したタスクのコード生成には強いが、コードベースの構造を長期間にわたり維持または改善することは弱いことである。より大きなトークン数を追い求めるのではなく、チームはこの制約を受け入れ、より良い計画と段階的なレビューによって効果を発揮し、人間が意図の理解、アーキテクチャ的影響の評価、保守性の確保を担うべきである。このアプローチにより、安定した品質を維持しつつ2〜3倍のスピードアップが現実的に得られ、ライトオフ工場が引き起こす障害や技術的負債を回避できる。