- 人がコードを読まず書かない無人（lights-off）ソフトウェアファクトリーは生成速度を高めるが、長期的な保守性を判断する人間まで排除してしまうため、複雑な本番コードベースでは機能しにくい
- コーディングモデルの強化学習は、テスト合格のような速く明確な報酬を最適化し、数カ月後に表面化する悪い設計のコストにはペナルティを与えられない
- SWE-bench系はバグ修正と既存テストの維持を評価するが、無差別なtry/catch、型キャスト、shotgun surgeryのようにコード品質を徐々に悪化させる変更はふるい落とせない
- 現時点では、人間がコードレビューを担い、プロダクト要件・システムアーキテクチャ・プログラム設計・垂直スライスを実装前にレビューしてこそ、手戻りと大規模なAI生成コードレビューを減らせる
- モデルの制約を認めれば、無理な10〜100倍の自動化ではなく、人間レベルに近い品質を保ちながら2〜3倍速く開発できる。核心的な判断とコードを読む作業は、まだ外部委託できない
ループ中心のソフトウェアファクトリーの約束と現実
- AIコーディングの本番導入競争では、ハーネスとエージェントループを増やせばよいという認識が広がっている
- StrongDMの無人ソフトウェアファクトリーは、人間がコードを読んだり書いたりしない方式を掲げている
- OpenAIのSymphonyも、ハーネスエンジニアリングに基づくソフトウェアファクトリーの事例である
- このアプローチは、人間がボトルネックであり、モデルは十分に優秀で、コード生成コストは実質的に低いため、より多くリリースすればよいという前提に立っている
- 目標は、10〜100倍の速度、高い品質、人間によるコードレビューの排除を同時に達成することにある
- リンターをさらに設定し、PRレビューボットに敵対的な検討を指示すれば、ソフトウェアを自律的に安全にできると考えている
- 実際の現場では、コーディングエージェントのミスによって障害が発生し、コードベースが急速に崩れる事例が出ている
- Faros AIのレポートは、AIコーディングツール導入後に次の変化を観察した
- レビューコメントの数と長さは増えたが、レビューなしでマージされるPRも増えた
- インシデントと開発者1人あたりのバグが増えた
- ただし、検証済みの因果関係ではなく、相関関係のシグナルに近い
- StrongDMの成果を示す確定的なデータは見つけにくく、2月から6月の間に公開されたアップデートも少ない
複雑なコードベースはバイブコーディングとは別の問題
- 少数だけが使うサイドプロジェクトと、10年もののエンタープライズシステムを保守するチームでは、共有する制約がほとんどない
- 議論の対象はバイブコーディングそのものではなく、複雑なコードベースの難問と本番保守である
- かつてbrownfieldは古いJavaシステムなどを意味していたが、エージェントが作ったコードベースも、開発速度が速いため約3〜6カ月後から変更しにくくなる可能性がある
- 結果が悪いと、トークンや技術が足りないせいだという助言が多いが、核心的な問題はハーネスよりもモデルの訓練方法にある
ソフトウェアファクトリーの進化
-
1968年からAI導入以前まで
- 「ソフトウェアファクトリー」という用語は、「ソフトウェアエンジニアリング」という表現が登場した1968年のNATO会議までさかのぼる
- 2022年頃の典型的なファクトリーは、次の循環構造を持っていた
- 人間が何を作るかを決め、LinearやJiraのようなトラッカーに登録する
- 担当者が実装とテストを行う
- 自動チェックと人間によるコードレビューを経て、問題があれば実装段階に戻る
- 本番デプロイ後に監視し、障害とユーザーフィードバックを再びトラッカーに入れる
- 実装とレビューにそれぞれ数時間または数日かかるため、チームは計画、アーキテクチャ提案、スプリント計画を前段に置き、先に合意を作る
- 実装前の合意は手戻りを減らし、決まった方向に近い完成度の高いPRは、すべての行を読んでも素早くレビューできる
-
エージェント型ファクトリー
- Ramp、Stripe、WorkOS、Brexなどは、エージェントファクトリーがコードの約**75%**を出荷していると紹介している
- 既存ファクトリーで人間が実装していた段階をエージェントに置き換え、オーケストレーション、ハーネス、サンドボックス、モデル、コンピューター使用を組み合わせる
- 実装時間は数時間・数日から数分・数時間に短縮されるが、人間がコードを読みテストする作業はそのままなので、レビューがボトルネックになる
- このボトルネックを減らすために、複数のループを追加する
- スタイル、バグ、セキュリティを検査するエージェントコードレビュー
- ブラウザとコンピューター使用で外部動作を確認する回帰テスト
- 障害を自動的にPRへ紐づけ、担当者が修正候補を受け取る流れ
- ユーザーフィードバックを作業キューへ直接つなぐ流れ
- 結局、運用上の問題は、作業キューにどれだけ多く入れられるか、結果をどれだけ速くレビューしテストできるかに絞られる
-
無人ファクトリー
- Dan Shapiroが名付けた無人ファクトリーは、人間がすべての変更を読む段階を取り除く
- コードレビューの代わりに、次の領域へ投資する
- エージェントの自己テスト
- サンドボックスとオーケストレーション
- 自動レビューとモニタリング
- 段階的リリースとユーザーフィードバックシグナルの収集
- 人間の判断を取り除くと、エージェントにどれだけ多くの作業を依頼できるかだけが残るが、この方式は複雑な本番コードベースでは機能しない
実際に適用した無人方式の失敗
- 2025年7月から、仕様とチケットだけを読んで小・中規模の作業をバックグラウンドエージェントに任せる完全な無人方式を適用した
- 数カ月が過ぎると、高度なプロンプトとワークフローでも解けない複雑な問題が発生した
- 必要なコンテキストを収集してモデルに提供した
- エージェントが約10通りの方法で問題の再現を試みた
- 最終的に人間が、3カ月間読んでいなかったコードベースに直接入り、原因を探さなければならなかった
- その間、サイトは停止し、ユーザーは不便を被り、人間は蓄積された低品質なコードを読まなければならなかった
- 最初の失敗では、速度のためにリスクを取る価値があると判断したが、約3回目の問題が発生した11月には、最初から書き直すほうが簡単だった
- 共同創業者がVS Codeで2週間かけてパターンを直接再実装した
モデルがコードベース品質を下げる理由
- 現在のモデルは、相当な人間の方向付けなしには、コードベース品質を長期的に維持し改善できない
- ここでいう保守性とは、ある部分を変えると別の部分が壊れ、同じ変更を複数箇所に適用しなければならないshotgun surgeryの状態を避ける能力である
- モデルは単発の問題解決や新しいマーケティングサイト生成では大きく進歩したが、時間の経過とともにコード品質を改善する能力が明確に向上したとは言いにくい
- 保守能力を測る良いベンチマークがないため、この差を証明したり反証したりすることも難しい
- GPT-5.5 xhighのようなモデルが優れたリファクタリングを行うとしても、人間がコードベースを理解し、必要な作業を具体的に指示しなければならないなら、無人ファクトリーの問題は解決されない
Claude Codeとハーネス内部の強化学習
- Claude Code以前にも、aider、cline、codebuffのようなCLIエージェントが、読み取り、書き込み、編集、検索、シェルツール、コンテキストエンジニアリングを提供していた
- 既存のエージェントは、同じ編集を繰り返して失敗するなど、ツール使用の安定性が不足することがあった
- SWE-Agent論文は、ReadFileの結果に行番号を入れる、Editを検索/置換から行範囲編集に変えるといった小さなツール設計の違いも性能に影響すると分析している
- Claude Codeが急速に成長した核心的な理由として、Anthropicが実際にリリースするハーネスの中でモデルを強化学習した点が挙げられる
- モデルが正確なツールセットをエージェントループ内で呼び出すように重みを調整した
- 外部開発者がツール定義と評価をモデルの好みに合わせるのとは異なり、モデル所有者はモデル自体をツールに合わせて変更できる
- ハーネスとモデル重みの両方を持つチームは、ハーネスだけを作り重みを調整できないチームより有利である
コーディングエージェント強化学習の報酬の限界
- コーディングモデルの強化学習は、おおむね次の手順を何百万回も繰り返す
- テスト修正のような問題を解かせるため、エージェント実行トレースを生成する
- 検証器で実行トレースを評価する
- 良い実行トレースの確率を高め、悪い実行トレースの確率を下げるようにモデル重みを更新する
- 問題は、評価スコアが過度に一次元的になり得る点である
-
SWE-bench Multilingualの事例
- SWE-bench Multilingualは、Redis、jq、Djangoのようなオープンソースリポジトリから取った約15分規模の作業を使う
- 報酬は0または1で、2つの条件を検査する
FAIL_TO_PASS: 要求された問題を修正したかPASS_TO_PASS: 既存の動作を壊していないか
fastlane__fastlane-19304タスクは、任意のinclude、excludeパラメータがないときにnilへ.empty?を呼び出して失敗するバグである- 実際の人間による修正は、nilを空配列にデフォルト設定する2行の変更だった
- モデルは修正直前のベースコミットとバグレポートだけを受け取り、正解パッチと採点用テストパッチは見ない
- 評価は次の順序で進む
- モデルが作ったパッチを保存する
- モデルがテストファイルに加えた変更は取り除く
- ベンチマークの非公開テストパッチを適用する
- 既存テストと新しいテストを一緒に実行する
- テスト変更を捨てる理由は、モデルが失敗テストをコメントアウトしたり、意味のないmockを入れたりして合格させる場合があるためである
- ベンチマークと強化学習の検証器は同一ではなく、互いに分離されるべきだが、どちらもコーディング実行トレースの品質を判断する構造的限界を示している
-
設計悪化にはペナルティがない
- テストさえ通れば、解法に至った過程と構造的品質はスコアに反映されない
- あらゆる場所をtry/catchで囲むことや、型システムの利点を崩す緩い型キャストも正解になり得る
- 保守性の毀損は、既存テストと新規テストが通る限りペナルティを受けない
テスト合格より難しい品質検証
- テストは数秒以内に明確な成功・失敗を提供するため、強化学習を何百万回も反復できる
- 悪いアーキテクチャのコストは、数週間、数カ月、数年後に、小さな変更を複数箇所へ適用しなければならないときに表面化する
- 現在のベンチマークは、こうした長期的な設計コストを評価できない
- 強化学習とベンチマークは同じものではないが、保守性が強化学習で解決されているなら、ベンチマーク設計にもその能力が現れる可能性がある
- したがって、既存ベンチマークスコアの向上を、モデルがコードベースを汚さなくなった根拠とは見なせない
保守性を評価しようとする新しい試み
- モデル品質の最前線は改善しているが、技術的規律よりも期待と宣伝が先行している
- 保守性により近い評価を試みる事例は次のとおり
- SWE-Marathon: Excelの全機能再現のような約400時間規模の作業と、単一の成功・失敗ではない複合的な報酬チャネルを使う
- DeepSWE: 現実では実際に実装されていない大規模オープンソース作業を使い、訓練データ汚染を減らすが、品質問題そのものは解決しない
- Frontier Code: 複数のPRにまたがる作業を評価し、パッチ前のコードでも失敗しないテストを書くとペナルティを与える
- ミューテーションテストに似た方式で、テストの有効性を決定論的に検査する
- コード品質ルールに従ってdiffを検査する判定モデルも実行する
- 判定モデルが品質を安定して区別できるなら、最初から良いコードを生成できたはずだという限界がある
- 強化学習には高速で信頼できるオラクルが必要だが、保守性にはそのようなオラクルがない
- レビューエージェントと追加トークンは明白なミスを捕まえ、最低品質を引き上げることはできるが、強化学習でモデルに教えた水準を超えて最高品質を引き上げることはできない
- SWE-Marathon、DeepSWE、Frontier Codeは成功・失敗判定を超えて保守性を評価しようとする初期の試みだが、まだコードベース全体を任せられる水準ではない
人間を再びループに入れる4段階
- 現在信頼できる品質判定者は人間なので、コードレビューを復元しなければならない
- AI以前から使っていた事前計画を適用し、長いレビューと手戻りの可能性を減らす
- AIのレバレッジは、プロダクト要件、システムアーキテクチャ、プログラム設計、垂直スライスの4段階で活用する
-
1. プロダクトレビュー
- 短い文章や長い音声メモを半構造化された文書に変え、何をなぜ作るのかを固定する
- まずユーザーの言葉で解決すべき問題を定義し、リリース後に成功可否を判断する基準を定める
- ワークフロー実行時間の短縮
- オンボーディングのマイルストーン早期達成
- エラー率やレイテンシの改善
- 特定のサポートチケットの減少
- 技術的詳細よりもユーザー体験に集中し、技術判断がプロダクト判断を妨げる場合は現在の文書を保存したうえで、アーキテクチャレビューや妥当性プロトタイプへ移る
- 画面の挙動は、長い説明よりも粗いHTMLモックで確認するほうが合意に効果的である
- 文言修正、単発スクリプト、再現方法が明確なバグにはこの手順を適用せず、エージェントに直接任せる
- エージェントが意図を誤解したときのコストが大きい変更だけをプロダクトレビューの対象にする
- PRレビュアーにもプロダクト・技術仕様を事前にレビューさせ、非同期の文書コメントやGitHub、Notionなどを使える
-
2. システムアーキテクチャ
- サービス、エンドポイント、スキーマ、キュー、ストレージ間の通信方式に合意する。ただしプログラム内部の実装までは踏み込まない
- 人間とエージェントのコミュニケーション帯域を高めるため、次の表現を使う
- UI、API、サービス、ストレージ間のシーケンス図
- リクエスト・レスポンスを示すAPI契約
- 新しいテーブルとクエリの形を表すデータモデル
- Mermaidは有用だが、使いすぎると実際に合意ができたという誤った確信を与えかねない
- アーキテクチャレビューはモデルの悪い癖を早期に防ぐうえで効果的だが、高品質なコードを保証するには不十分である
-
3. プログラム設計
- 実装前に、アーキテクチャより一段下のコードの形を決める
- 型
- メソッドシグネチャ
- プログラム配置
- コールスタック
- 複雑なMermaidよりも、軽量な擬似コードの可視化のほうが読みやすい
- オーケストレーションや制御フローの変更にはコールスタックツリーを使い、変わる部分が重要ならdiff構文を適用する
- ファイルツリーdiffで、新規ファイルと修正ファイルの位置と役割を確認する
- 中核関数の型とメソッドシグネチャを事前に決め、エージェントが内部設計を誤って選ぶ可能性を減らす
- モデルが草案を作り、人間が調整できる。コードレビュー中に暗黙的に下す判断を、より安い時点へ前倒しする作業である
- 実装前に、アーキテクチャより一段下のコードの形を決める
-
4. 垂直スライス
- モデルはデータベースマイグレーション→サービス層→API→フロントエンドの順に積み上げる水平計画を好む
- 水平計画では、作業中にブラウザやcurlで実際の解決策を触って検証しにくい
- AI以前の開発者は、500行や2,000行を一度に書くより、中間から外側へ広げながら継続的に確認していた
- API契約とmockデータを作り、curlで検査する
- フロントエンドでmockデータを消費し、ブラウザで整える
- APIをサービス層につなぐ
- データベースマイグレーションとストレージ接続を追加する
- ビジネスロジックを追加する
- エラー処理を追加する
- 垂直スライスまたはtracer bulletsは、各段階で実際の動作をテストし改善できるようにする
- 品質が特に重要な領域では、段階ごとに100〜200行をレビューして方向を修正するほうが、2,000行以上を後から直すより安い
- 最新モデルでも、人間の方向付けなしにこうした計画を立てるのは難しく、コードベースや作業ごとの汎化も難しいため、人間はループに残る必要がある
作業サイズに応じた適用方法
- 30分の事前計画で、実装後に数時間かかるレビューを減らせる
- 人間レベルに近い品質を保つには、プロダクト設計、システムアーキテクチャ、プログラム設計、垂直スライスに人間が関与しなければならない
- すべての作業に全手順を適用するわけではない
- 約**40%**は一度に生成するか、1〜2回の軽いフィードバックで終える
- 中規模の作業は、プロダクト設計とシステム設計を1つの計画文書にまとめ、実装段階は分割しない
- 大きな作業は4段階すべてを経るが、大規模リファクタリングのようにプロダクトレビューが合わない場合はその段階を省く
- 通常、モデルには一度に1〜3個のスライスを任せ、進行中のコードをレビューする
- 早い段階で内部構造や機能を修正するほうが、大量生成後に何が間違っているかを探すより簡単である
ボトルネックはPR数ではなくPR品質
- PRが多すぎるのではなく、悪いPRが多すぎることがボトルネックである
- 決まった設計とチームの慣例に従うきれいなPRは、すべてのファイルを読んでも素早くレビューできる
- PRの20%を手戻りさせるだけでも、提出者とレビュアーの双方に知的負担と感情的負担が生じる
- AIが一度に生成したPRは、手戻り率が50%に近い場合が多い
- 提出者がAIであっても、誰かが作業を開始し、結果を整えたり責任を負ったりしなければならないため、手戻りコストは消えない
制約を受け入れた開発速度
- 現在の核心的な制約は、モデルが得意なことと不得意なことが明確であり、当面は人間がコードを読まなければならない点である
- コード品質は重要ではないと仮定して10〜100倍の速度を追うより、制約の中でシステムを最適化すれば、安全に2〜3倍の速度を得られる
- 実務上の原則は4つである
- モデルと十分に作業し、制約に対する直感を養う
- その制約の中で開発システムを最適化する
- 高いレバレッジがある地点を見つける
- 実際のコードを読む
- ハーネスとループは明白なエラーを減らす道具だが、保守性の判断と設計思考を代替するものではない
1件のコメント
Hacker Newsの意見
これを意図・実装・品質の問題と呼ぶ
ソフトウェア工場は、1行の要求だけでアプリ、機能、バグ修正、設計変更、リファクタリングまで実装できるが、その要求の背後にある人間の意図や製品の進化の方向性まで正確に作り出せるかは別問題である
実装方法は組み合わせ的に爆発し、システムと整合し、拡張可能で、理解しやすく、何百万人ものユーザーを安全に支える「正しい」方法は、人や課題によって主観的である。テストや作業の証拠で品質の一部は高められても、この主観的な品質を検証して修正するフィードバックループはない
コードをまったく見ず、要求が成功したかどうかだけをフィードバックにするバランスも可能だが、それ以外のソフトウェアでは、意図と主観的品質の問題はまだ解決されていない
記事には良い内容もあるが、2025年7月の無人運用実験を現在のエージェントの限界として一般化するのは難しい
モデルの有用性は2025年秋か2026年春ごろに大きく跳ね上がり、私もその後からエージェントに機能全体を任せられるようになった。記事はモデル改善に触れつつも実質的に無視しており、自分の実感とは合わない
Opus 4.6以降のモデルは、70万〜90万トークンでも知能低下を体感しにくいほど安定しており、コスト効率は非常に悪いが動作はする
現在のモデルの能力をよく理解しているはずなので、今なら無人ソフトウェア工場が可能だと判断していたなら、再挑戦しているはずだ
最新のフロンティアモデルでも、文脈からの逸脱やショットガン・サージェリーをうまく扱えるようにはなっていないと思う。反論するなら、ただ無視するのではなく、具体的な根拠と異なる利用経験を示すべきだ
4.5はより速く、単純なプロンプトや暗黙の意図をうまく読み取り、新規ユーザーを素早く引き込むのに有利だった
私は自分のソフトウェア工場を8か月間構築・運用しており、作業の自動収集やPR提出はまだないものの、要求を決めた後は大半を自動でデプロイまで進める。システム評価を経て、この4か月はコードレビューもやめている
1行プロンプトの代わりに、インタビュー工程で未解決の質問や曖昧さを先に解消し、計画レビュー、ブラウザベースの品質保証、敵対的レビュー、単体テスト、リンター、型チェッカー、コミット後フック、形式手法のトレースを安全装置として使っている
反復的なミスが現れると、コードを見なくても汚れてきた領域を検知できる。要求が増えて状態変数が重なってきた場合は、1つの合併型にリファクタリングし、複雑ならQuintで形式モデルとトレースを作って単体テストとして実行する
コードベースは1年以上経ったフロントエンドとバックエンドで構成されている。エージェントは既存パターンをそのまま複製するため、明確な原則が重要であり、新しいシステム境界を分けるときはSonnet級モデルはしばしば判断を誤り、Opusの方が良かった
品質低下はだいたい検知できたし、コードを開いて問題を見つけた後、エージェントで整理できなかったことはまだない。平均的なエンジニアでもコードベースの汚染を元に戻せない状況は見たことがない
コードベースの動作を理解する必要があるか、理解する必要がないかのどちらかである
Claudeはコードを代わりに書けても、代わりに理解してはくれず、その過程は依然として人間の速度で進む。すべてを理解する必要がない場合はあるが、もっと繊細な区別が必要で、Claudeが完璧なコードを書いてもこの事実は変わらない
LLM以前でも巨大なコードベース全体を知る人はいなかったが、少なくとも自分が作ったPRや担当領域は概ね理解していた
自分の経験とあまりにも似ていて安心した。最近よく話題になる 好みと判断力 を思い出した。
アーキテクチャの品質には、ファッションのように客観的な正解がないのかもしれず、機械に理性と合理性を委ねた後、人間は美学を学ぶべきなのかもしれない。
実装プロセスが与えてくれていた休息なしに、ほぼ同等な選択肢のあいだでの折衷を延々と判断し続けなければならないので疲れるし、Fable や GPT-5.6 級のモデルでもコードレビューは依然として必要だ。小さな欠陥は覚えておいて、似た問題が十分たまったらまとめて直す。
エージェントについても、少数の優秀な人材と緊密に協業するのか、大規模な下位エージェント群を回して自動で玉石混交を見極めるのかを選ばなければならない。自分の好みは 少数の高度に調整されたチーム だが、それが正解かどうかは時間が教えてくれるだろう。
好みとは、ソフトウェアを作る中で自分で踏み抜いてきたあらゆるアンチパターンや地雷から得た 苦労の末の直感 なのだ。
https://www.youtube.com/watch?v=eIoohUmYpGI
この人は過去にも根拠のない内容を作って広め、被害を与えたと認めた前歴があるのに、今回の考えが良いという 証拠もまったくない。再び信頼すべき理由が必要だ。
今の状況で最も目立つ問題は PR レビューのユーザー体験 だ。
GitHub の PR 画面が以前からずっと嫌いで、ブランチを落として
$EDITORで差分を確認していたが、もうここまで不便である理由はない。コードレビュー企業ですらない Linear が、小さなモデルで変更ファイルをトピックごとにまとめ、説明と重要度の順序を付けて、GitHub より良い基本機能を提供している。レビュアーと依頼者に追加作業をさせずに認知負荷を大きく下げられるし、可視化のような後続機能も十分可能だ。このアプローチが間違っているのか、広く使われている代替案があるのか気になる。
https://linear.app/docs/diffs#guides
強力なロールバック手順まで備わっていれば、PR の関門は有用な問題を捕まえられない不要なプロセスになり、チームメンバー同士でそのままマージできる。
実際に動くソフトウェアをレビューすべきであり、変更案を即座にデモできるシステムが必要だ。コードと仕様の比重は下がり、未来のソフトウェア生産は GitHub より Replit に近づく だろう。
Tree-sitter ベースのアプローチである https://github.com/0x007BA7/codebook を試して気に入った。まだ本番環境で使える水準ではないが、似た方式を製品化する余地はある。
ソフトウェア工場には両義的な感覚がある。
中核製品は規模が大きく、あらゆる変更に人間の入力が必要だが、軽いリファクタリング・テスト作成・UI 変更の自動化はうまく機能する。一方で小さな実験では、できあがったコード自体は特別でなくても、今後拡張されていく可能性が見えたし、最初からエージェントが書くことを前提に 新しい戦略とアーキテクチャ を設計できると思う。
方向性にまったく介入しない公開実験は https://relentless.works/ に記録してある。取引エージェントも介入なしで観察しているが、約 3% の損失ではあるものの全額を失ったわけではなく、最近は新しいポジションも開いた。
ソフトウェア工場は可能に見えるが、新しい概念と思考様式の変化、そして AI を待つ忍耐が必要だ。
ソフトウェアを作るとは何か、という点からして根本的な問題がある。
GitHub のチケットを AI エージェントに割り当てて休んでいるだけだと、抽象化と間接レイヤー が積み上がり続ける可能性が高い。コーディング中には「ここで Redis を使えば？」「API はすでに必要なデータを返しているのでは？」「過去 1 年間アクティビティのない顧客はレポートから外そう」といった視点が生まれ、どこかの時点で人間がそれを判断しなければならない。
https://gwern.net/doc/cs/algorithm/1985-naur.pdf
Claude Code の計画モード、
mattpocock/skills、obra/superpowers、調査→計画→実装の流れなどがそれに当たる。モデルの記憶は、人間が眠りながら重みに刻み込むように統合されるのではなく、昨日を覚えていない人にメモを渡すのに近い。エントロピーの高いシステム が時間とともにプロジェクトへエントロピーを加えていっても驚くことではない。
バイブコーディングのプロジェクトにはこうした無駄があふれているが、プロンプトを書いた人はそれに気づかないかもしれない。ツールが毎日時間を節約してくれるのは良いが、過剰実装 は深刻だ。
無人工場としてのソフトウェアを語りながら、生産性をPRやコミット数で測るのは滑稽だ。その方向で行くなら、コードの単位はすでに
bos（bunch of shit）と呼ぶべきレベルだhttps://en.wikipedia.org/wiki/The_Goal_(novel)
極端なスタートアップのように資本を節約する代わりに、人生の数年を投入する交換に近い