スロップクリープとは、個別には合理的だが集合的には破壊的な決定の蓄積による、コードベースのゆっくりとした目に見えない強化のことです。それぞれの決定はフラグを立てるには小さすぎ、追跡するには多すぎ、そして気づくまでにリラックスできないほど深く埋もれています。
今から 6 か月後のコードベースを想像してください。すべての機能は予定通りに出荷され、すべての PR はレビューに合格しました。しかし、チームはこれまでよりも遅く、絶えず消火活動を行っています。
新しい機能はすべて、数十のファイルに影響します。同じことを行うのに 6 つの異なる方法があります。データ モデルには、以前に導入され、再検討されることのなかった制限を回避するためだけに存在するフィールドがあります。システムを介したリクエストのフローを誰も追跡できないため、オンコール ローテーションは悪夢です。
私は自分自身にこれをしてしまいました。建てるとき ベースライム私は、時期尚早なマイクロサービス、貧弱で拡張不可能なスキーマ、漏れやすい抽象化など、本にあるすべての間違いを犯しました。私は迅速に出荷し、「実用的な」アーキテクチャ呼び出しを行い、コードベースがそれらの周りで石化するのを観察しました。以前は、危機点に達するまでに複数のミスが重なり、数か月を要しました。
昨年、私はコーディングエージェントを雇いましたが、私のサイドプロジェクトは数日で危機的状況に達しました。
すべての変更は問題ありませんが、コードベースは問題ありません
これがスロップクリープの厄介な点です。単一のコミットが問題となるわけではありません。エージェントはバグを導入したのではなく、わずかに間違った抽象化を導入し、その上に構築し、さらにその上に構築しました。 それ。
グラフTD A[Feature Request] –> B[Agent writes solution]
B –> C[Looks fine in isolation]
C –> D[Ships]
D –> E[Next feature request]
E –> B D –> F[💀 Codebase decays]
スタイル F 塗りつぶし:#fee2e2、ストローク:#fca5a5、カラー:#991b1b
2 週間後、それを解くということは、本番環境のデータベースをいじり、3 つのサービスを書き直すことを意味します。それは、何千回もの合理的な判断による死という、ひどいクリープだ。
昔の世界にはサーキットブレーカーがあった
以前は、アーキテクチャに関する間違った決定が一度に行われることがよくありました。勘の悪い若手開発者には自然な速度制限があり、誰かが気づく前にコードベースを埋めてしまうほど速くビルドすることができませんでした。痛みは大きくて避けられなかったので、治さなければ死んでしまいます。
グラフTD A[Bad abstraction] –> B[Slows everything down]
B –> C[Team feels the pain]
C –> D[Forced to fix it]
スタイル C フィル:#fee2e2、ストローク:#fca5a5、カラー:#991b1b スタイル D フィル:#d1fae5、ストローク:#6ee7b7、カラー:#065f46
コーディングエージェントがサーキットブレーカーを削除しました。
エージェントは、無期限にゴミの上にゴミを積み上げ続けることができ、その間ずっと生産性を維持できます。スピードを緩めることはありません。さらに大きな山を築きます。計算は延期され、さらに複雑になり、最終的にそれが到来すると、さらに苦痛が大きくなります。
コーディングエージェントはシステムを総合的に考えることができない
中心的な問題は単純です。コーディング エージェントは、ソフトウェアを構築するときに適切な抽象化レベルを見つけることができないのです。彼らはシステムを見ているのではなく、プロンプトを見ているのです。
エージェントにエンドポイントの追加を依頼すると、エージェントがエンドポイントを追加します。共有ハンドラーに抽象化されるべきエンドポイントが他に 4 つあることも、拡張しているデータ モデルがすでに間違いであったことも知りません。誰も教えてくれなかったので、それは何も知りません。
グラフTD A[Agent sees: the prompt] –> B[Agent builds: the solution]
B –> C[Correct in isolation]
B –> D[Wrong for the system]
スタイル C フィル:#d1fae5、ストローク:#6ee7b7、カラー:#065f46 スタイル D フィル:#fee2e2、ストローク:#fca5a5、カラー:#991b1b
エージェントは自信を持って、明らかに間違っています。コードベース内の重要な決定を具体的に伝える必要があります。
これは良くなるでしょうか？
多分。コンテキスト ウィンドウは拡大し、モデルはよりスマートになっています。その答えはおそらくコンテキストの増加です。コードベース全体を読み取り、あらゆる決定の履歴を理解し、システムが 6 か月後にどこに向かっているのかを予測できるエージェントは、誤った呼び出しをはるかに少なくするでしょう。
しかし、今日のエージェントはそんなことはしません。彼らにはプロンプトと、読み取るように指示されたファイルが表示されますが、それ以外には何も表示されません。彼らにはシステムがどこへ行く必要があるのかについての先見の明がなく、どのようにしてここに到達したのかについての記憶もありません。それが変わるまでは、「単独での正しさ」と「システムにとっての正しさ」の間のギャップを埋めるのはあなた自身です。
エージェントは電話をかけるのではなく、ギャップを埋める必要があります
コーディングエージェントは10倍のエンジニアを100倍のエンジニアに変えることができますが、それはエンジニアが消えるわけではありません。それはエンジニアが入力をやめて、 考え始める。
残念ながら、私たちはこれらのツールを全体として非常に間違って使用しています。コンピューターが「私たちの代わりに仕事をしてくれる」ため、毎日だらだらと仕事をし、頭のスイッチをオフにしてしまいます。
データ モデル、サービス境界、主要な抽象化など。これらは一方通行のドアであり、いったん実稼働環境に移行すると、元に戻すのは困難または不可能な決定です。エージェントは決して一人で一方通行のドアを通過するべきではありません。そこで登場します。
これは、すべてのスキーマとインターフェイスを事前に指定するという意味ではありません。エージェントによる計画の最初の草案は出発点ですが、通常はひどいものです。カーディナリティが間違っている、制約が欠落している、列挙型が必要なブール型フィールド、6 か月後にデータがどのようにクエリされるかについて考慮されていない。しかし、その最初の草案は、反応するものとして非常に役立ちます。あなたはそれを読み、バラバラにし、修正の注釈を付けて、修正するためにエージェントを送り返します。これを 2 ～ 3 回繰り返すと、エージェントの幅広い知識とシステムおよび製品に関する理解が組み合わされるため、どちらかが単独で作成したものよりも優れた抽象化が完成します。
まさにこの種の反復的な改善を中心に構築された研究、計画、実装のワークフローでクロード コードを使用する方法について書きました。
グラフTD A[Engineer defines intent] –> B[Agent drafts plan with code snippets]
B –> C[First draft is usually wrong]
C –> D[Engineer reviews and annotates]
D –> E[Agent revises]
E –> F{十分ですか?} F –>|いいえ| D F –>|はい| G[Agent implements]
スタイル C フィル:#fee2e2、ストローク:#fca5a5、カラー:#991b1b スタイル D フィル:#ede9fe、ストローク:#c4b5fd、カラー:#5b21b6 スタイル G フィル:#d1fae5、ストローク:#6ee7b7、カラー:#065f46
私はもうコードを書きませんが、エージェントが書くほぼすべての行を読みます。綿密な計画を立てずにエージェントを放っておくと、数週間後にいつも同じことを後悔します。データベース スキーマが悪く、あちこちにブール値フィールドがあり、分析が欠如していて、可観測性を始められなかったのです。
答えはエージェントの使用をやめないことです
スロップクリープは現実のものですが、コーディングエージェントの使用をやめる理由にはなりません。これらはここ数年でソフトウェア開発に起きた最高の出来事であり、自分の中に構築する必要があるとは思っていなかったものを構築できるようになりました。コードベースのすべての文字を自分で入力する作業に戻るつもりはありません。
しかし、計画段階は、ほとんどの人が行うよりも 10 倍の注意を払う価値があります。機能の曖昧な説明ではありません。主要なデータ モデルの実際のコード スニペット。主要な抽象化のための実際のインターフェイス。曖昧な部分が残されていないため、エージェントが重要なことを間違うことはありません。
グラフTD A[Vague plan] –> B[Agent makes architectural decisions]
B –> C[Slop creep]
D[Tight plan with code snippets] –> E[Agent executes within constraints]
E –> F[Clean codebase]
スタイル C フィル:#fee2e2、ストローク:#fca5a5、カラー:#991b1b スタイル F フィル:#d1fae5、ストローク:#6ee7b7、カラー:#065f46
計画にもっと時間を費やしましょう。重要な決定を行うためのコード スニペットを作成します。次に、エージェントに料理をさせます。
「コードは新しいアセンブリです」
よくある反論は、「そんなことは問題ではない」というものです。コードは新しいアセンブリ言語です。誰も読んでいません。エージェントがそれを書き、テストに合格し、機能が動作しても、内部が醜いことを誰が気にするでしょうか?
これはコンパイラの機能を誤解しています。コンパイラの役割は、高レベル言語を次の言語に翻訳することです。 効率的、パフォーマンスの高い マシンコード。肥大化し、冗長で、微妙に間違ったマシンコードを生成するコンパイラーは、ソフトウェアの構築に真剣に取り組んでいる人には使用されないでしょう。
エージェントがコンパイラであり、出力が不安定な場合は、コンパイラがありません。あなたには責任があります。
グラフTD E[Good agent workflow] –> フ[Clean, maintainable code]
G[Vibe coding] –> H[Slop that ships]
スタイル F フィル:#d1fae5、ストローク:#6ee7b7、カラー:#065f46 スタイル H フィル:#fee2e2、ストローク:#fca5a5、カラー:#991b1b
そして、その強化はコード内にとどまらず、ユーザー エクスペリエンスにまで波及します。バイブコード化されたすべてのアプリには同じ兆候があり、全体を感じさせる小さなカットが多数あります。 オフ:
- コンピューター上で利用可能なリソースをすべて占有するアプリ
- 無効にする必要があるときに完全に無効にならないボタン
- 点滅するローディング状態
- ナビゲーション時に入力が失われるフォーム
- 誰も障害モードをモデル化していないため、「問題が発生しました」というエラー メッセージが表示される
これらはいずれもデモには表示されません。それらはすべて、ユーザーが毎日感じているバグです。コードベースでのスロップ クリープは製品でもスロップ クリープになり、ユーザーはコードを読んでエクスペリエンスが悪い理由を理解できなくなります。彼らはただ立ち去るだけだ。
仕事は消えたわけではなく、変わった
正直なところ、この投稿に記載されている内容はすべて、次のメジャー モデル リリースでは廃止される可能性があります。システムを真に総合的に理解し、コードベースがどこに向かっているのかを見極める先見性と、コードベースがここに到達した理由を知るコンテキストを備えたエージェントは、方程式を完全に変えるでしょう。
しかし、それは今日私たちが持っているものではありません。そして、次の 6 ～ 12 か月で変化をもたらすエンジニアは、エージェントの出力を見て、「自分の立っている場所からは見えない理由でこれは間違っている」と言えるエンジニアになります。どのドアが一方通行なのか、どの抽象概念が石化するのか、そしてどのコーナーで後で費用がかかるのかを知っている人です。
モデルが追いつくまで、スロップクリープと戦います。ソフトウェアの暗号化は静かに進行しており、完全に防止可能であり、現在どこでも起こっています。
私も建てています 公称.dev、2026年には誰もオンコールにならないはずだからです。
#スロップクリープ #ソフトウェアの偉大な機能化