ロボットファーストエンジニアリング

ソフトウェアは人間のために作られてきた。ファイルシステム。ターミナル。JSON。Git。コードレビュー。そのすべてが、キーボードを叩く人間が扱えるものとして形作られてきた。

それを全部捨てて、機械のためにゼロから作り直したらどうなるか?

それがロボットファーストエンジニアリングだ。そして、自律的なソフトウェア開発がすでに向かっている方向でもある。

開発はもうエンジニアリングではない

仕事全体を再構成するこの分岐を見てほしい:

ソフトウェア開発は今や機械の仕事だ。コードを書く。テストを実行する。コミットする。エージェントがすでに処理している。大体1時間あたり1,500円、睡眠なし、休憩なしで動く。

ソフトウェアエンジニアリングは、その機械を信頼できる状態に保つ人間のレイヤーだ。レール。障害ドメイン。検証ループ。バックプレッシャー。エージェントが中で動くための配管のすべて。

気づかないうちに仕事が変わっていた。あなたはもう船に荷物を積み込んでいない。コンテナが登場した。今はロコモティブを動かして線路の上を走らせるのがあなたの役割だ。

その考え方の転換が、新しい世界で活躍するエンジニアと行き詰まるエンジニアを分ける。

スクリュードライバーからジャックハンマーへ

自律的なエンジニアリングには段階がある。飛ばすと失敗する。

スクリュードライバー。手作業。仕様を手で書く。コンテキストを緻密に管理する。検索とリンクを自分でコントロールする。目標は、システムをどうレールの上に乗せるかを学んでから鍵を渡すことだ。

ジャックハンマー。全力稼働。Ralphループが無監視で動く。オーケストレーションされたフリート。並列エージェント。朝には機能が出来上がっている一晩のビルド。

ほとんどのエンジニアが同じ間違いを犯す。スクリュードライバーに触れる前にジャックハンマーを掴む。

基礎なしに完全な自動化に飛びつくと、アウトプットはゴミになる。スクリュードライバーこそが、ジャックハンマーに何が必要かを教えてくれる。

まず手作業でやる。何がシステムを保たせているかを理解する。それから電動工具に手を伸ばす。

Loom: エージェントのために作られたスタック

Loomは次のステップを指し示している: 人間ではなくエージェントを中心に自己再構築するソフトウェア環境だ。

設計ルールは厳格だ。スタックのすべての部分について、3つの問いに答える:

これは人間のために設計されたか?
もしそうなら、取り除けるか?
取り除いた場合、何を失い、どう置き換えるか?

テストに失敗するいくつかの前提:

UnixユーザースペースとTTY規約。エージェントはターミナルに座らない。これらはまだ必要か?
アジャイルの儀式とプロセス。スプリントは人間が週単位で計画するから存在する。エージェントはそうしない。
データフォーマットとしてのJSON。すべての引用符とカッコがトークンを消費する。JSONは適切なワイヤーフォーマットか?
コードレビューのワークフロー。検証ループがレビューキューを置き換えられるか?

Loomの構成要素には:

コードホスティング、GitHub的だがエージェント向けに形作られたもの
機械のワークフローとより相性の良いJJによるソースコントロール
Codespace風のリモートサンドボックス
複数のプロバイダーを一緒に動かすマルチLLM「アロイング」
アクターとpub-subメッセージパターン
Erlang/OTPスタイルのチェーニング

核心的なアイデア。ループをチェーンとして組み合わせる。 ループの上のループの上のループ。それぞれが密で焦点を絞ったもの。全体が1つのリアクティブシステムとして振る舞う。

コンテキストウィンドウは単なる配列だ

ロボットファーストで考えるための核心的な原則:

コンテキストウィンドウは配列だ。その配列に入れる量が少ないほど、スライドする量が減り、アウトプットの質が上がる。

コンテキストを詰め込むと:

より多くのスライディング
より早いコンパクション
データを失うコンパクション
アンカーの欠如
ドリフト

これがRalphループが機能する理由だ。ループは配列を決定論的に実行するように設計されている。配列をリーンに保つ。コンパクションを避ける。ピンを保持する。

ピンはあなたの仕様だ。エージェントが常に指し示し続ける安定した参照点。すべての反復でそれをもう一度読む。ピンがなければ、エージェントは作り話を始める。

仕様はルックアップテーブルとして

ロボットファーストの仕様はドキュメントではない。エージェントの検索に最適化されたルックアップテーブルだ。

良い仕様はこんな見た目になる:

## User Authentication
 
**Also known as**: login, sign-in, auth, session management, identity
 
**Related files**: src/auth/, src/middleware/session.ts
 
**Key patterns**: JWT tokens, refresh rotation, secure cookies
 
**What NOT to do**: Don't implement custom crypto, don't store passwords in plain text

「also known as」フィールドは検索のヒット率を上げる。エージェントが「login」でgrepすると、認証仕様にたどり着く。シノニムが多いほど、ヒットが増える。ヒットが増えるほど、発明が減る。

仕様はフィーチャー全体の参照フレームになる。エージェントは何があるかを調べて、何があるかを推測しなくなる。

リンクはファンシーなフォーマットに勝る

多くのエンジニアが計画を過剰に作り込む。ネストされたJSONスキーマ。タスク階層。凝ったフォーマット。

ロボットファーストの見方は: タイトなリンクはファンシーなフォーマットに勝る。

実際に機能するもの:

具体的な参照を持つ箇条書き
正確な仕様セクションを引用する
正確なファイルを指し示す
特定のハンク (Claude はファイルをハンク単位で読む) を参照する

## Implementation Plan
 
- [ ] Add JWT validation middleware
 
  - Spec: auth-spec.md#token-validation
  - File: src/middleware/auth.ts (lines 45-60)
  - Pattern: Follow existing rate-limit middleware structure
 
- [ ] Create refresh token endpoint
  - Spec: auth-spec.md#refresh-flow
  - File: src/routes/auth/refresh.ts (new file)
  - Pattern: Match existing /auth/login endpoint structure

これでエージェントは精度高く検索できる。正しいハンクを見つける。リポジトリにすでにあるパターンをコピーする。発明をやめる。

ロボットファーストスタック

ここからアイデアが急進的になる。スタック全体を所有すれば、機械向けにチューニングできる:

シリアライゼーション。JSONはトークン効率が良くない。すべての引用符、すべての波括弧、すべてのカンマがトークンを消費する。バイナリフォーマット、またはエージェント向けに構築されたテキストフォーマットは、そのコストを大幅に削減できる。

ユーザースペース。エージェントがUnixのユーザースペースを引き継ぐ必要があるか? TTYは人間がターミナルで使うために作られた。エージェントはターミナルエミュレーションをまったく必要としない。

ガベージコレクション。「プロセス」がステートレスなAPIコールである場合、メモリ管理はどういう意味を持つのか? 通常の前提が成立しなくなる。

メッセージパッシング。ErlangとOTPが戻ってくる。アクター。スーパーバイザーツリー。Let-it-crash。パターンがエージェントのオーケストレーションにきれいに対応する。

スタックを所有すれば:

トークン化をチューニングできる
コストを大幅に削減できる
より高速なリアクティブパイプを構築できる
次のチームより安価に動かせる

それが競争優位の土台だ。

Weaver: 人間のいないエージェント

ロボットファーストエンジニアリングの到達点には名前がある: Weaver。

Weaverとは自律的なエージェントで:

フィーチャーフラグの裏でコードをリリースする
コードレビューなしでデプロイする
プロダクトアナリティクスを監視する
変更がエラーを修正したかどうかを判断する
さらに進むかどうかを決める
自律的に反復する

誰も見張っていない。完全な自律性。

怖い、それが正しい最初の反応だ。では少し腰を落ち着けて考えてほしい。

挙げられるすべての反論は、構築すべきエンジニアリング課題だ。本番を壊したら? ロールバックをエンジニアリングする。間違った判断をしたら? 検証ループをエンジニアリングする。レールを外れたら? バックプレッシャーをエンジニアリングする。

ソフトウェアエンジニアリングの新しい仕事。懸念をエンジニアリングで排除する。

反論を書き出す。そしてそれを無力化するシステムを構築する。それが今の仕事だ。

バックプレッシャーエンジニアリング

自律的なループは障害モードを生み出す。あなたの仕事はレールを敷くことに変わる:

仕様内に制約を追加する
計画のリンクを締める
検索ガイダンスを改善する
ゲートを高くする (テスト、リンティング、フォーマット、セキュリティスキャン)

アウトプットが悪化したとき、修正は別のループだ:

リファクタリングループ
規約ループ
セキュリティループ
i18nループ

バックプレッシャーがジェネレーターをレールの上に保つ。あなたがレールをエンジニアリングしたから、ロコモティブが線路上に留まる。

スケーリングラダー

ロボットファーストエンジニアリングは組み合わせによってスケールする。4つの段階。

レベル1: 手作業の基礎

会話を通じて仕様を生成する
制約を手でタイトにする
コンテキストをできる限り小さく保つ
キーボードの前にいる

レベル2: 無人ループ

while true の実行
反復あたり1つの目標
自動テストとコミットとプッシュ
チェックポイント状態

レベル3: マルチループオーケストレーション

複数のループが同時に動く
それらの間にリアクティブチェーンが張られる
アクターとpub-subパターン

レベル4: 自律的プロダクトシステム

フィーチャーをリリースするWeaver
意思決定を駆動するアナリティクス
レビューキューなし
エンドツーエンドのプロダクト自律性

各段階は下の段階の上に乗っている。レベル1〜3なしにレベル4に飛ぶことはできない。

マインドセットの転換

ロボットファーストエンジニアリングには異なる考え方が必要だ:

古いマインドセット。「このコードをどう書くか?」 新しいマインドセット。「このコードを確実に書くシステムをどう設計するか?」

古いマインドセット。「このPRをどうレビューするか?」 新しいマインドセット。「レビューを不要にする検証をどう構築するか?」

古いマインドセット。「この問題をどうデバッグするか?」 新しいマインドセット。「このクラスのバグを防ぐフィードバックループをどうエンジニアリングするか?」

あなたはもうコードを書いていない。自律的なシステムを設計している。あなたはロコモティブエンジニアであり、荷役作業員ではない。

今日から始める

ロボットファーストに考え始めるためにLoomは必要ない。問いから始めよう:

私はどんな人間の前提を焼き込んでいるか? ワークフローを振り返る。どのステップが、人間がやる人だったからこそ存在するのか?
何がルックアップテーブルになれるか? 仕様。パターン。規約。エージェントが検索できる形に整えられるか?
リンクが弱いのはどこか? ほとんどの計画は漠然と物事を指し示している。ファイルパス、行の範囲、ハンクをハードコードできるか?
バックプレッシャーはどこにあるか? エージェントが横道にそれたとき、何が捕まえるか? 必要になる前にそのブレーキを構築する。
完全な自律性には何が必要か? あなたがループから外れたと仮定しよう。何が崩れるか? それらの障害があなたの次のエンジニアリング優先事項だ。

この先

これは2026年だ。シートベルトを締めよう。

信頼できる自律ループを動かせるチームとそうでないチームのギャップは急速に広がっている。経済的な現実は明確だ。自動化された開発は大体1時間あたり1,500円だ。人間の開発者はその10倍以上だ。

ロボットファーストで構築するチームはまったく異なるペースでリリースする。より安価に動く。より速く反復する。眠っている間も改善が積み重なる。

人間ファーストのワークフローに縛られたエンジニアは遅れをとっていく。スキルが悪いからではない。最適化のターゲットが間違っているからだ。

ソフトウェアエンジニアリングは変わった。前にも変わってきた。また変わるだろう。

うまくいくエンジニアは、変化のたびにそれをファーストプリンシプルから設計し直すチャンスと捉える人たちだ。それはいつもそうだった。ただ今は無視するのが難しくなっただけだ。

スクリュードライバーから始めよう。基礎を正しく整えよう。それからジャックハンマーに手を伸ばす。

ロコモティブが待っている。

Ralph Wiggum テクニック。自律ループの基礎
スレッドベースのエンジニアリング。エージェント作業をスケールするためのフレームワーク
自律エージェントループ。RalphとスレッドをあわせたもN
フィードバックループ。ループを誠実に保つ検証パターン
コンテキストエンジニアリング。配列の管理