記事は、Andrej Karpathy によるソフトウェアの 3 段階の区分から始まる。記事はこれを、彼が Y Combinator の AI Startup School で行った講演に由来するものとしている。開発者がどのようにを記述する明示的なロジックを書く Software 1.0、データと学習によってニューラルネットワークの重みが生まれ、それがプログラムとなる Software 2.0、そして大規模言語モデルに何を望むかを自然言語で伝え、プロンプトがプログラムとなる Software 3.0 である。続いて記事は、実際にはモデル単体ではファイルを読むことも、API を呼び出すことも、データベースにアクセスすることもできず、モデルを役に立つものにしているのはハーネスだと論じる。著者の説明によれば、この名前は人が馬の力を利用できるようにする馬具に由来する。記事は、モデルの限界とそれぞれを補うハーネスの要素を表にまとめている。コンテキストウィンドウに対してはメモリ管理、ハルシネーションに対しては事実のグラウンディングと検索、ドメイン知識の不足に対してはナレッジベース、ステートレス性に対してはセッションとオーケストレーション、外部システムへのアクセスに対してはツールと MCP である（Software 3.0、エージェントハーネス）。
記事の中心的な主張は、Claude Code は本質的に Claude モデルのためのそうしたハーネスであり、その構成要素は開発者がすでに知っているレイヤードアーキテクチャに対応するというものである。そこから記事は、馴染みのあるアンチパターンや設計原則がエージェントの設計にも当てはまること、この類推が 1 つの重要な点で成り立たないこと（エージェントは立ち止まって質問できる）、そしてこの類推が実務上の限界も覆い隠していること（トークンはメモリのように振る舞う）を論じる。著者は、開発の重心はコードを書くことからコードを組み立て指揮することへと移りつつあり、その組み立ての原則は馴染みのあるものとそれほど変わらないとし、「考え方をリファクタリングすることから作り始めよう」と締めくくっている。
要点
- 記事は Claude Code の構成要素をレイヤードアーキテクチャに対応づけている。スラッシュコマンドはユーザーのリクエストの入口となるコントローラー（カスタムスラッシュコマンド）、サブエージェントはスキルを組み合わせてワークフローにするサービス層で、それぞれが独自のコンテキストを持ち、別スレッドのように独立して動作する。スキルは単一責任の原則に従うドメインコンポーネント（Agent Skills）、MCP は外部システムに接続するインフラ層またはアダプター層（Model Context Protocol）、そして CLAUDE.md は
package.jsonやpom.xmlに相当し、安定したプロジェクトの原則を保持する（CLAUDE.md）。 - 記事は、CLAUDE.md を頻繁に編集しているなら、編集している内容はおそらくそこに置くべきものではないと助言し、現在のイシューやその日の優先事項のように変化する情報は、会話の中で、あるいはサブエージェントのコンテキストを通じて渡すべきだとしている。
- レイヤードアーキテクチャのアンチパターンには、エージェントにおける対応物が与えられている。何千行にもわたってすべてを処理する「God Skill」、指示が構造なく混在した「Spaghetti CLAUDE.md」、MCP を経由せずに API 呼び出しをハードコードすることは密結合、MCP の内部実装を知っているサブエージェントは漏れのある抽象化、スキル間の循環呼び出しは循環依存である。フィーチャーエンヴィ、スキル間で重複したプロンプト、10 個のスキルを立て続けに呼び出すサブエージェントといったコードの臭いも、同じように持ち込まれる。
- この類推で説明できない違いは、従来のサービス層ではすべての分岐を事前に定義しなければならないのに対し、エージェントは質問ツールを通じて作業の途中でユーザーに判断を委ねられる点である。記事の言葉を借りれば、例外が質問になる（ヒューマン・イン・ザ・ループ）。著者は、全か無かの自動化と部分的な自動化を、そして誤りの後のロールバックと誤りの前の確認を対比している。
- 良いエージェントとは、いつ質問すべきかを知っているエージェントだと説明されている。削除、デプロイ、外部 API の呼び出しといった取り消しにくい操作の前、正解のない複数の選択肢がある場合、コストやリスクの高い判断については質問すべきであり、安全に繰り返せる作業、合意済みの規約でカバーされている作業、容易に元に戻せる作業は自分で進めるべきである。
- トークンはメモリとして扱われる。コンテキストウィンドウはワーキングメモリであり、トークンの使用はメモリの占有である。記事はおおよその数値を示している。よく整理された CLAUDE.md はプロジェクトごとに 500〜2,000 トークン、各スキルは読み込まれるたびに 300〜1,500 トークンである。そして、ワークフローを実行する前にどのファイルを読むかを Claude に尋ね、答えが予想より多ければ指示を絞り込むことを提案している。
- ブランチの命名規則のような決定論的なロジックはスクリプトに移すべきであり、そうすればモデルは毎回規則を解釈してトークンを費やすのではなく、スクリプトを実行することになる。
- Claude は起動時にすべてのスキルの名前と説明をシステムプロンプトに読み込むため、著者はクラス爆発に相当する「スキル爆発」に警鐘を鳴らし、デメテルの法則を適用することを推奨している。SKILL.md をファサードのような単一の入口とし、詳細な知識は必要なときにだけ読み込まれる
references/配下のファイルに委ねるというものである（段階的開示（Progressive Disclosure））。 - スラッシュコマンドについては、
npm initとnpm config setになぞらえたセットアップと設定のパターンが提案されている。リポジトリを分析して構造を生成し、選択が曖昧な箇所だけを質問する/setupコマンドと、後から調整するための/configコマンドである。
背景
この記事は、Software 1.0 で訓練を受けた開発者への助言という形をとっている。捨てるべきものは、あらゆるロジックを明示的に書こうとする強迫観念、あらゆる例外を事前に定義しようとする試み、そしてモデルを賢いオートコンプリートと見なす見方であり、残すべきものは、層の分離、単一責任、抽象化、依存関係の管理、インターフェース設計、テスト容易性、そしてコードレビューである。著者は後に同じブログで Software 3.0 時代、Harness による組織生産性の底上げ を書いており、この記事は著者の他の執筆物の中にそれを挙げている。記事は、掲載した画像はすべて生成 AI で作成したものだと述べている。
コメント欄はおおむねこの類推を評価している。あるコメント投稿者は、著者が実際にこうした方針に沿ってスキルやサブエージェントを設計・運用したことがあるのかを尋ね、アーキテクチャの原則を適用することと、エージェントを確実に振る舞わせることは、まったく別の問題だとわかったと述べている。別の投稿者は、Software 3.0 はそれ以前のパラダイムと大きく異なるため、1.0 流の対応づけは初期の理解には役立つかもしれないが、長期的には思考を制約しかねないと指摘している。