Mitchell Hashimotoの新しいコード作成方法
Mitchell Hashimotoが常時エージェントを実行させる方法
Mitchell Hashimoto — HashiCorpの共同創設者、Terraformの開発者、現在Ghosttyを構築中 — は Pragmatic EngineerのGergely Oroszと対話し、AI補助開発のための深く考え抜かれた方法論を共有しています。これはハイプや浅い議論ではなく、20年の経験を持つ実践者が、AIエージェントを中心に日々のワークフローを根本的に再構成した方法を説明しています。
基本的な規律： “I endeavor to always have an agent doing something at all times. I want an agent if I’m coding, I want an agent planning. If they’re coding, I want to be reviewing. There should always be an agent doing something.” (常にエージェントに何かをさせようと努めている。コーディング中にもエージェントが欲しいし、エージェントが計画を立てるのが欲しい。もし彼らがコーディングしているなら、私がレビューしたい。常にエージェントが何かをしているべきだ。)
すべての遷移の前に — 家を出る前、どこかへ運転する前、一日の終わり前 — Mitchell は30分間を費やして「私のエージェントが次に行える遅い作業は何だろう？」と問います。彼はエージェントにリサーチタスク、ライブラリ評価、リアルタイムの注意を必要としないエッジケース分析を与えます。重要なことに、彼はすべてのエージェント通知をオフにします：「私はいつエージェントに割り込むかを選択します。エージェントが私に割り込むことはできません。」
AIが実際に何をもたらすかについて： “It’s really allowed me to choose what I want to actually think about. I always felt limited — I’m going to have to spend the next two hours doing this boilerplate. But now I don’t have to learn about it.” (本当に私が何を実際に考えたいのかを選択することを可能にしました。私はいつも制限を感じていました — 次の2時間をこのボイラープレートをやるのに費やすつもりです。でも今はそれを学ぶ必要がありません。)
これはより多くのコードを生産することではなく、認知エネルギーを重要な作業に転向させることです。
ハーネスエンジニアリング：複合的な品質戦略
Mitchell のAIコーディングの議論への最も独創的な貢献はハーネスエンジニアリング — エージェントが繰り返しの失敗を防ぐために呼び出すことができるツール作成のための彼の造語です。
パターン： エージェントが誤りを犯したとき、単にそれを修正するのではなく、テストハーネス、検証スクリプト、またはエージェントが自己チェックのために呼び出すことができるリントルールを構築します。ルールをあなたの CLAUDE.md または agents.md ファイルに追加します。エージェントはその特定の誤りを二度とすることはありません。
これは時間とともに複合します。 各セッションがハーネスを改善します。各ハーネス改善は後続のエージェントセッションをより信頼できるものにします。Mitchell はこれを彼の2026年の主要な目標の1つと呼び、AIエージェントを使用するチームにとって重要なインフラストラクチャ投資と見なしています。
拡張されたテスト要件： AIは「目標志向」です — 現在のタスク範囲外のものを壊して即座の目標を達成します。これは、テストカバレッジが人間のみの開発に十分だったよりもはるかに広い必要があることを意味します。すべてのAI誤りは、単なる修正ではなく、ハーネス改善につながるべきです。
コンテキスト依存の品質：ゼロレビューからすべての行まで
Mitchell はプロジェクトに応じて完全に異なる品質基準を適用します：
- Ghostty （オープンソースターミナル、長寿命）：AI生成コードのすべての行をレビューします。フレームごと9マイクロ秒のパフォーマンスが重要です。
- 使い捨てプロジェクト （家族の結婚式ウェブサイト）：コードレビューはゼロ。「3つのブラウザで正しくレンダリングされましたか？出荷してください。2か月間のみオンラインです。」
このプラグマティズムは競争的なエージェント実行に拡張されます。自信が低い難しいタスクでは、彼は2つのエージェントを並列で実行します — Claude Code vs. Codex — そして、より良い結果を選択します。彼は自分自身を「市長」と説明し、最大で2つのエージェントを管理しています。
Gitはエージェント時代を生き残れるか？
最も挑発的な予測：“This is the first time in like 12 to 15 years that anyone is even asking that question — will Git be around? — without laughing.” (これは12～15年で初めて誰かがその質問さえ尋ねる時代です — Gitは存在するでしょうか？ — 笑わずに。)
Mitchell は Git と GitHub forges が「今日ではエージェント型インフラストラクチャで機能しない」と主張しています。エージェントのチャーンが人間のチャーンの10～100倍の場合、マージキューは不可能になり、ディスク容量が爆発し、人間のレビュアーはペースに追いつくことができません。彼は具体的にこの問題に取り組んでいるステルス企業にアドバイスしています。
バージョン管理の将来への彼のビジョン：はるかに多くのブランチ、失敗した実験、履歴を保持する — 決して削除しない。これは「バージョン管理のためのGmailの瞬間」です。しかし、それは大規模なリポジトリ内の関連コンテキストを見つけるために根本的により良いツール作成を必要とします。
AI生成オープンソース貢献は信号を破壊している
Ghostty は毎日2～3件の低品質なAI生成PRを受け取ります。Mitchell はここで、関連する課題番号がない場合、読まずにそれらを閉じます。“AI makes it trivial to create plausible looking but incorrect and low-quality contributions. Open source has always been a system of trust. Before we had default trust. Now it’s default deny.” (AIはもっともらしく見えるが不正確で低品質の貢献を作成することを簡単にしました。オープンソースは常に信頼のシステムでした。前は。デフォルト信頼がありました。今はデフォルト拒否です。)
彼は、エージェント型ツールが「PRを開く一時停止を入れる」ことを望んでいます — 彼らが保守者に与える摩擦は、貢献者への利便性を上回ります。彼はClaudeの特徴さえ特定します：本文のないドラフトPRを開き、本文を編集し、それを再度開く — パターンは人間が従いません。
Mitchell Hashimotoのオブザーバーワークフローからの6つの原則
- 常にエージェントを実行させる — 遷移（運転、休憩、一日の終わり）を使用して、遅いエージェントタスクをキューイングします。エージェントは労働時間中にアイドル状態になるべきではありません
- 計画から実行を分離する — エージェントコーディング前の専用の計画ステップは、出力品質を劇的に向上させます
- 修正ではなくハーネスを構築する — すべてのAI誤りは、単なる修正ではなく、繰り返しを防ぐツール作成を生成するべきです
- 何を考えるかを選択する — AIの価値はより多くのコード/時間ではなく、認知を建築、デザイン、ユーザーニーズにリダイレクトすることです
- コンテキスト依存のレビュー厳密さ — 本番コードはすべての行レビューを得ます。使い捨てプロトタイプはゼロレビューを取得します。努力をステークスと一致させます
- 学習曲線への投資 — 「それは誰かがGitを1時間試して、それが生産的ではないと決めた場合のようなものです。熟練するには継続的な努力が必要です」
これがエンジニアリング組織に何を意味するか
Mitchell はAIの価値を生のプロダクティビティ利得ではなく、実験能力の拡大として考えています。1週間かかったプルーフオブコンセプトは、今では1日で行うことができます。しかし、彼は顕著に慎重です：“I hesitate to say more productive. There’s an expectation they could do more. You should be able to build a full demo, design, everything — you don’t need a team to do that anymore.” (より生産的と言うことをためらっています。彼らがより多くを行うことができるという期待があります。完全なデモ、デザイン、すべてを構築できるようになるはずです — チームはもうそれをする必要がありません。)
組織にとって、影響は具体的です：AI ツール能力を採用時に必須にする、エージェント構成ファイル（CLAUDE.md）をファーストクラスのインフラストラクチャとして扱う、ハーネスエンジニアリングに投資する、CI/CDパイプラインがAI生成コードが要求する拡張されたテストを処理するために根本的に再考する必要があることを受け入れます。エンジニアリングインフラストラクチャの機能 — エディター、forges、CI/CD、テスト、可視性、サンドボックス化 — はすべて一度に変更の対象です。Mitchell がそれを表現するように：「これは私の20年間のプロフェッショナルキャリアの中で、一度に非常に多くが変更の対象になる初めての時代です。」