AIによるコンテキストの外部化 – 個人開発の勢いを取り戻す
著者は、AIを使ってプロジェクトのコンテキストを外部化することで、長いインターバルがあっても個人開発の生産性を維持できるようになったと説明し、速度よりも遅延耐性の重要性を強調する。
2026年5月12日·4分読了·Patrick Schless
AIによるコンテキストの外部化
かつてサイドプロジェクトはセッションの合間に消えていた。しかし、私はコンテキストを頭の中に保持するのをやめた。
多くの開発者と同様、私も頭の中に有用なプロジェクトアイデアのバックログを抱えている。子供ができる前の若い頃は、週に20〜30時間を個人プロジェクトや面白いプログラミング言語、新しいフレームワークに費やすのが簡単だった。時間の制約が増えるにつれ、それは散発的な数時間に変わった。個人開発プロジェクトは勢いを維持するのが難しくなり、完全に放棄された。数年間、私はプロジェクトを開いては週末にちょっと手を付け、一か月放置して二度と戻ってこないということを繰り返した。理由は興味の欠如ではなく、数学の問題だった。
古い数学
幼い子供が二人いて、集中を要する本業がある場合、サイドプロジェクトには暗黙のハードルがあった。「今夜、興奮してこれを全部頭に詰め込んだとして、すぐにまたこのコードに戻ってくるだろうか？」通常、正直な答えはノーだった。例えばGoalChasrは、5ドルのiFit関連マグネットを販売する小さなVueJSプロジェクトだった。私は少数のリピーター顧客と、成長と定着のためのアイデアを持っていた。やる気はあったが、大きな変更を進めるのは難しかった。摩擦は「次に何をすべきか」ではなく、数日ぶりにプロジェクトを開くたびにメンタルモデルを再構築し、コードがどの状態だったかを再把握することだった。一行も書く前にセッションの半分が消費された。
そのため、私はほとんどのことを始めなかった。趣味はより離散的で完結したものへと移行した：ハイキング、遊び場、土曜日に収まるHome Assistantの自動化など。
変化
変化に気づいたのは一瞬ではなかった。徐々に浸透してきた。子供を寝かしつけた後の一時間の個人コーディングは、かつては30分のコンテキストロードと30分のフローだった。ある時点で、それは丸一時間の生産性になり、プロジェクトの状態がもはや頭の中に存在しなくなった。計画ファイルがそこにあり、「前回はここで止めた、次のステップはこれだ」と書いてある。再習得を完全にスキップできた。これは軽いバイブコーディングではなく、事前の合意と計画に基づいてコンテキストが提供される「本物の」キーボードを使った開発作業だった。
私にとって最も効果的な外部化の形は、長時間の事前計画会話で文書化された計画を作り、それに沿って小さな実装単位を進めることだ。その形の中の一つのワークフロー（唯一ではないが代表的）は、Matt Pocockの「grill-me」スキルで、Claudeが機能について私を問い詰めて設計を具体化し、その後ピンポンTDD（Claudeが失敗テストを書き、私が手動でパスさせる）を行う。グリル段階は全体のかなりの時間を要し、集中力が必要だ。そこでの実装上の多くの決定が実際に行われるからだ。その後、道筋が敷かれ、いずれも一晩で完了できる小さな断片に分割される。
勢いの回復
最近、私はPushForwardに取り組んでいる。それは楽しいが、特に斬新ではない：会話型のAIフィットネスコーチで、Hevy（ウェイトリフティング）とGoogle Health（歩数など）のデータを一つの継続的なスレッドに統合し、モデルが私のトレーニング履歴を把握できるようにする。2026年には数十のAIフィットネスコーチがあり、いくつかはすでにクロストラッカー合成を行っているので、このアイデアがユニークだとは主張しない。私がこれを作っているのは、自分がユーザーだからであり、実際に動作するエンドツーエンドのエージェントをリリースすることが、それについて読むことよりも優れているからだ。
最近、エージェントに新しいGoogle Health API統合を追加した。大きな事前計画セッションで、アーキテクチャ、OAuthフロー、新しいエージェントツール（get_step_count、get_weight_historyなど）、および既存のオーケストレーションへの組み込み方法をカバーした。それは個別の単位に分割され、それぞれが一晩か二晩で完成できる小さな計画を持っていた。大きな計画が方向性を維持し、小さな計画が一週間後に戻ってきたときに待っている次のステップを提供した。一年前なら、これを始めなかっただろう。作業が難しかったからではなく、セッション間の間隔がそれを殺していたからだ。
遅延耐性
私が読むAIコーディングに関する記事のほとんどは、時間あたりの出力、1日あたりのコード行数、「10倍の生産性」について述べている。これらは程度の差であって、種類の違いではない。私にとっての本当の変化は別のものだ：遅延耐性。セッションと次のセッションの間に許容できる間隔が、「数日、かもしれない」から「数週間、問題ない」に変わった。これこそが、この人生の段階で開発が再び趣味として可能になる理由であり、速度の枠組みに比べて過小評価されていると私は思う。小さな子供がいる開発者、要求の厳しい本業を持つ開発者、または注意が散漫になりがちな開発者は、速度の変化と同じくらいこの数学の変化を認識するだろう。