LLM時代のエンジニアリング
(x.com/yairwein)- LLM時代にプロダクトと開発組織をどう作るべきかについて、Reindeerでの1年半の試行錯誤をまとめた文章で、ヒューマンコンテキスト（human context）が最も希少な資源だという認識から、あらゆる洞察が出発している
- コンテンツ生産量は爆発的に増えたが、人間の消費速度は変わらず、そのギャップが新たなボトルネックになっている — slopがslopを食わせる（slop feeds slop） 悪循環を断ち切る必要がある
- モデリングやAPI設計のような 構造的な決定 は依然として人間の領域であり、LLMが生み出す成果物に対して「no」と言える人が必要
- コードレビューだけではLLMに勝てないため、リンター・LLMジャッジ（LLM judges）・小さなPR のような自動化・規律ベースの防御層を構築する必要がある
- 開発者の中核的な能力は深い技術知識ではなく、コンテキストスイッチングと自分のコンテキストウィンドウの大きさ にあり、適応した開発者は超高生産的になる一方、適応できない開発者はチームにとって マイナス（net negative） になる
ヒューマンコンテキストは希少資源
- この25年間、業界で変わらない事実 — 最も高価な資源は ヒューマンコンテキスト であり、人間もLLMのように限られたコンテキストウィンドウとアテンションマスクを持つ
- 今起きている変化は、四方八方からLLM slopが流れ込んでくること — 生産速度と人間の消費速度の 比率 が新しいボトルネックになっている
- 問題は slopがslopを食わせる こと
- LLMによって水増しされたコードコメント、冗長なPR説明、結果ではなく履歴ばかりを並べるドキュメント生成
- 次のLLMがそれを読み、コンテキストがノイズで埋まったまま同じやり方を引き継いでしまう
- 組織内のテキストコンテンツは 圧縮的 であるべきで、コードとその挙動だけでは明確でないことだけを含めるべき
人間を置き換えられない領域
- モデリングは人間の仕事
- CUJ（Critical User Journey）をAPIフローへ落とし込み、コンポーネントが何か、それぞれの関心事と境界がどこにあるかを決める作業
- LLMはコードを素早く吐き出せるため、悪いモデリングも高速で拡散 し、後から直せない歪んだ依存関係を作ってしまう
- 実装コストが安くなるほど、最終的な価値における 構造に対する人間の決定 の比重は大きくなる
- モデリングは実際の組織の真実であり、どこか一か所でアクセス可能な形で生きていなければならない
- API定義には厳格な人間の規律 が必要
- LLMは特定タスクに都合のいいフィールドを次々と足しがちで、そのフィールド一つひとつがAPIを恒久的に汚していく
- APIは 公開契約（public contract）であってスクラッチパッドではない — 「no」と言う人間が必要
Slopに対する大規模防御
- 人間のコードレビューではLLMに勝てない — スケールせず、結局は みんな目をつぶって承認する 状態に行き着く
- Reindeerは 自動強制レイヤー へと収束した
- リンター（Linters）: サービス間の禁止依存、アーキテクチャ境界のような絶対的な論理ルール
- LLMジャッジ（LLM judges）: コード化は難しいがモデルが検査できるもの。例: 暗黙の契約
- ただし、APIに触れたりモデリング変更が起きたりする場合は 実際の人間によるレビュー が必須
- 日常レベルのルールは「互いにslopを投げつけないこと」
- 小さなPR、必要ならスタックド（stacked）PR
- 2,000行のslop PRを投げたくなる誘惑と、レビュアーが目をつぶって承認してしまう可能性に抗わなければならない
- PRは 注意（attention）の基本単位 であり、人間のコンテキストウィンドウを超えると承認はされても読まれない
Padded rooms — LLMを解き放てる領域
- 上記の構造を整えると、LLMが自由に走り回れる領域、「padded rooms」（緩衝室） を特定できる
- モデリングに影響せず、長期的な依存関係もない領域
- slopが発生しても簡単に置き換えられ、コードベース全体へ広がらない
- 会社のコードの大半がここに入る可能性はあるが、荷重を支える（load bearing） 部分ではない
- 顧客ごとのカスタマイズの答え もここにある
- カスタマイズは100% padded roomsの中で生きるべき
- コアへ漏れ出した瞬間、コアは裂け、顧客が1社増えるごとにリスクが発生する
- padded roomsは、アーキテクチャ上の代償を払うことなく、顧客に素早く「yes」と言えるようにするインフラ
技術的負債の経済的逆転
- 荷重領域とpadded領域の分離は、技術的負債との関係 も変える
- 過去: 開発中にモデリングの問題を見つけても未来の自分に先送りし、書き直しコストが高いため大きな作業の途中では負債を飲み込んでいた
- 現在: 書き直しコストはほぼ0に収束 している
- 本当の投資先はタイピングではなく モデリング にあった
- 捨てて、モデリングを直して、書き直すことは安い
- 先送りすると非常に高くつく — 間違ったコードを通過するすべてのLLMがそれを採用し、slopがslopを食わせる 状態になり、すぐに直さなかったモデリングのミスは短時間で何倍も複雑な負債になる
この時代のPM
- PMの役割は変化し、モデリング担当者と密接に協業 して、CUJがAPIやコンポーネントへ落とし込まれる過程で壊れないよう保証することが求められる
- PMとモデラーが同期していないと、
- 技術的には動くがCUJを満たさないプロダクト、あるいは
- CUJはきれいでも現実的に作れない成果物
- ReindeerではPMが 別リポジトリで直接MVPを構築 する
- このコードが本番環境に触れることは決してないという前提
- LLMとともに素早く動き、顧客に見せられる自由を確保する
- 成功したもの、あるいは顧客と向き合う必要があるものだけが正式なモデリング・開発プロセスを通る
- コアに投資する前に素早くデモを立ち上げて顧客検証できる — アイデア検証の速度 と プロダクトに入るものに対する外科手術のような厳格さ のバランス
ループから解放してくれるインフラ
- エージェントを手取り足取り導くことと、複数のタスクを並列に回して寝に行けることの違いは 良い報酬関数（reward function） にある
- それがなければLLMは帰ってこられない旅に出る
- あれば、自分がいつ近く、いつ遠いのかを自ら判断できる
- 開発における良い報酬関数は 良いテスト へと翻訳される
- プラットフォームに対する E2Eテスト を含む
- 何もテストしない mock依存の悪い習慣 からLLMを引き離す
- LLMベースの出力に対する Evals
- クリーンなコンテキストのLLMジャッジ が自動レビューのループを実行する — コードを書いたエージェントと同じ幻覚にジャッジまで陥らないようにするため
- 組織レベルでは、このインフラは 共有 される必要がある
- Reindeerにはカテゴリ別に整理された 中央 skill marketplace リポジトリ があり、社内スキルをすべて含んでいる
- Claude Code、Codex のすべてのハーネスで自動サポートされ、本人のようにかなりunhingedな人向けには pi.dev もサポートされている
- 新しい開発者は、組織のすべてのスキルを即座に受け取れる（オンボーディングやセットアップを実行するスキルも含む）
未来の開発者
- この時代の開発者にとって決定的な能力は、深い知識ではなくコンテキストスイッチングと自分自身のコンテキストウィンドウ／アテンションマスクの大きさ である
- 大きなコンテキストを維持し、集中を失わずにタスク間を移動し、複数のエージェントを並列管理できる人が勝つ
- 鋭い技術的深さはLLMが埋めてくれるため、重要性は下がる
- 追加で必要な能力は モデリング力、システムアーキテクチャへの良い理解、設計段階で何を警戒すべきかという感覚
- 新しい世界が開発者を二分する理由
- 適応した人は 超高生産的（super-productive） になる
- 適応できない人は中立ではなく、チームにとって 純粋なマイナス（net negative） になる
- LLMは 乗数（multiplier） であり、扱える人には生産性を、扱えない人には高速な損傷をもたらす
- 報酬の面では、後者タイプの開発者の給与は0になる — 仕事がなくなるからだ
- はるかに少ない人数ではるかに多くのことができる一方で、採用拡大は非常に難しく、きわめて選別的でなければならない
トークンコストについて
- 繰り返し出る質問: トークンコストが5〜10倍に跳ね上がったらどうなるのか
- 時間が経てば、この懸念は現実的ではない
- AIには 加速したムーアの法則 があり、1ドルあたりの品質は上がり続ける
- 十分な数の オープンモデル が存在するため、カルテルは形成できない
- トークンが安い理由 — Claudexが突然不合理に高くなれば、誰もがどこかのneocloud上のQwenへ移るからだ
まだコメントはありません。