なぜ90%と100%で10倍の差が出るのか
エンジニアの90%がAIを使う組織と100%が使う組織では、結果がまったく違います。たとえ10%でも旧来のやり方で働くと、組織全体がその10%に合わせて後退せざるを得ないからです。
誰もコードエディタに手で打ち込まなくなって初めて開けることがあります。複数の機能やバグを並行して処理し、コードが安くなるぶん、リスクのあるアイデアもまず試作して実験回数を増やす。わずか10%の例外が、こうした可能性をすべて閉ざしてしまいます。
15人で4つのプロダクトを運営するとは
米国のEveryは15人で4つのソフトウェア製品を運営しています。コードの99%をAIエージェントが書き、アプリ1本を開発者1人が担当します。有料購読者は7000人超、累計調達はわずか約100万ドルです。
おもちゃのようなアプリではなく、複雑な本番プロダクトを一人が作り、維持します。この構造は数年前、いや1年前でも成立しませんでした。作業をエージェントに委ね、並行して進める働き方がそれを可能にしました。
コンパウンディング・エンジニアリングとは何か
従来の開発では、機能を一つ足すたびに次の機能が作りにくくなります。コンパウンディング・エンジニアリングの狙いはその逆で、どの機能も次の機能をより作りやすくするよう設計することです。
やり方は計画・委任・評価・体系化という四段階のループです。要は最後の体系化です。計画し、委任し、評価する中で得た暗黙知をプロンプトとして明文化し、組織全体で共有します。積み上がったプロンプト群が、次の作業の出発点を引き上げます。
この方式は組織にどんな二次効果を生むか
暗黙知を明文化すると、見えにくい二次効果が伴います。隣の開発者のリポジトリを指し示すだけで、AIがその実装過程を読み取り、別の技術スタックへ移し替えます。新入社員は初日から、環境構築も良いPRの書き方も整った状態で生産的に働けます。
プロダクト間でバグ修正のPRをやり取りし、スタックを一つに標準化しなくても、AIが言語やフレームワークの間を翻訳します。管理者やCEOさえコードをコミットします。3〜4時間のまとまった集中時間がなくても、会議の合間に調査を委任し、戻ってPRを出せるからです。