- HashiCorpをイグジットし、Ghosttyを開発しているミッチェル・ハシモトが、AIツールを実際の業務に統合するまでの過程を整理
- 非効率 → 適応 → 生産性向上の3段階に分け、各段階での試行錯誤と学習プロセスを具体的に記録
- チャットボットベースのコーディングの限界を認識した後、エージェントベースのツールへ移行し、本格的に価値を見いだす
- 既存の手作業で完了したコミットをエージェントで再現する訓練を通じて、作業の分解、計画と実行の分離、自動検証が重要であることを体得
- 1日の業務の最後の30分を使って夜間の自動化作業を行い、再現可能な単純作業をエージェントに委任することで、実質的な生産性向上を実現
- 現在は常に1つのエージェントを動かすようにし、ミス防止のための**「ハーネスエンジニアリング」**も並行して行い、AIと人間の協業効率を最大化する段階にある
導入の背景とアプローチ
- 新しいツールを導入するたびに、非効率 → 適応 → 革新の3段階を経る必要がある
- 既存のワークフローに慣れているため初期導入は不便だが、長期的には生産性向上につながる
- AIツールに対する過度な期待や批判ではなく、実際の利用体験に基づいたバランスの取れた視点を提示している
Step 1: チャットボットから離れる
- ChatGPT、Geminiなどのチャットボットインターフェースによるコーディングは事前学習に依存しており、エラー修正も人間の反復的なフィードバックに頼るため非効率
- ZedのコマンドパレットのスクリーンショットをGeminiに貼り付けてSwiftUIで再現したことが最初の「驚きの瞬間」であり、GhosttyのmacOS向けコマンドパレットの土台になった
- しかし、ブラウンフィールドプロジェクト（既存のコードベース）の文脈ではチャットボットはしばしば質の悪い結果を生み、コードや出力をコピー＆ペーストする工程は自分で直接作業するより非効率だった
- 価値を得るには必ずエージェントを使う必要があり、ここでいうエージェントとは、LLMが外部アクションを繰り返し呼び出せるツールのことで、最低でもファイル読み取り、プログラム実行、HTTPリクエストの機能が必要
Step 2: 自分の作業をエージェントで再現する
- Claude Codeを初めて使ったとき、成果物に満足できず、修正作業に自分でやる以上の時間がかかった
- 諦める代わりに、手作業のコミットをエージェントで同じように再現する訓練を繰り返した
- 同じ作業を2回（手動 + エージェント）行う苦しいプロセスだったが、ツール導入時の摩擦は自然なもの
- この過程で自ら見いだした重要な原則は3つ:
- セッションを明確で実行可能な単位作業に分解すること
- 曖昧な依頼は計画セッションと実行セッションに分けること
- エージェントに作業を検証する手段を与えれば、自分でミスを修正し、リグレッションを防げる
- エージェントが苦手な領域を把握し、使わないべき場面を知ることも大きな効率向上要因
- この段階では純粋な効率向上はまだ感じなかったが、エージェントをツールとして十分に受け入れられるようになった
Step 3: 1日の終わりにエージェントを活用する
- 毎日最後の30分をエージェント作業の開始に充てるパターンを導入
- 自分が働いていない時間にエージェントが進捗を生めば効率が得られる、という仮説
- 効果的だった作業タイプは3つ:
- ディープリサーチセッション: 特定言語の特定ライセンスのライブラリを調査し、長所・短所・開発活動・コミュニティの反応などを複数ページの要約にまとめる
- 並列エージェントによる曖昧なアイデアの探索: リリース目的ではなく、翌日の作業時に未知の変数を見つけるために使う
- IssueおよびPRの分類・レビュー:
gh（GitHub CLI）を使って並列エージェントでIssueトリアージを行い、エージェントは直接返信せず、翌日に参照するレポートだけを作成する
- エージェントを一晩中繰り返し実行することはなく、多くは30分以内に完了した
- 1日の後半で疲れた時間帯をエージェント作業に切り替えることで、**翌朝の「ウォームスタート」**効果を得た
Step 4: 確実な作業委任
- エージェントがほぼ確実にうまくこなせる作業を把握した後、それらをバックグラウンドエージェントに委任し、自分は別の作業に集中
- 毎朝、前夜のトリアージ結果を手動でフィルタリングしてエージェント向きのIssueを選別し、1件ずつ実行
- この時間にはSNSや動画ではなく、従来のAI以前のやり方による深い思考を要する作業を自分で行う
- エージェントのデスクトップ通知をオフにすることが重要: コンテキストスイッチのコストが大きいため、エージェントが人間を割り込んで中断させるのではなく、自然な休憩時に確認する方が効率的
- Anthropicのスキル形成研究論文への向き合い方: エージェントに委任した作業に関するスキル形成は諦める一方、手作業を続ける仕事では自然にスキル形成が継続する
- この段階で**「もう以前には戻れない」レベル**に到達し、好きな仕事に集中できるようになったことが最大の利点
Step 5: ハーネスエンジニアリング
- エージェントは、最初の試行で正しい結果を出すか、最小限の修正だけで済むときに最も効率的
- エージェントがミスをするたびに、同じミスを二度としないよう解決策をエンジニアリングするというのが「ハーネスエンジニアリング」の考え方
- 形式は2つある:
- 暗黙的なプロンプト改善（AGENTS.md）: エージェントが誤ったコマンドを実行したり、誤ったAPIを探したりする場合、
AGENTS.mdファイルに記録して解決する — Ghosttyリポジトリに実例あり
- プログラムされたツール: スクリーンショット取得、フィルタ済みテストの実行などのスクリプトを書き、AGENTS.mdでそのツールの存在を知らせる
- 現在はこの段階にあり、エージェントの悪い挙動の防止と良い挙動の検証に積極的に投資している
Step 6: 常にエージェントを動かしておく
- Step 5と並行して、常に1つのエージェントがバックグラウンドで実行中の状態を目標にしている
- Ampのdeep mode（GPT-5.2-Codexベース）のように、30分以上かかるが高品質な結果を出す遅いモデルを好む
- 現在は複数エージェントの並列実行はしておらず、1つのエージェントと手作業のバランスが適切だと考えている
- 実際には勤務時間の10〜20%程度しかバックグラウンドエージェントは動いておらず、その比率の改善に取り組んでいる
- エージェントを動かすこと自体が目的ではなく、本当に役立つ作業があるときだけ実行すべきであり、委任可能な高品質の作業フローを作ることはAIの有無にかかわらず重要
現在の状況と考え方
- AIツールで成果を上げており、現実に根ざしたバランスの取れた視点で取り組んでいる
- AI企業に勤務したり、投資したり、助言したりする関係はなく、AIが存続するかどうかに関係なく、ソフトウェア職人として作ることを楽しむのが根本的な動機
- 基礎が弱いジュニア開発者のスキル形成の問題については深く懸念している
- モデル革新の速度が速いため、エージェントが不得意な領域についての判断は継続的に見直す必要がある
- AIを使うかどうかは個人の選択であり、本稿はツール探索と活用方法に関する個人的な事例共有を目的としている
1件のコメント
Hacker News の反応
セッションを明確で実行可能な作業単位に分けるのが重要
指示が細かすぎるとLLMを使う意味がなく、逆に「犬のためのFacebookアプリを作って」のように広すぎると役に立たないプロトタイプしか出てこない
結局、コード向けLLMをうまく活用するには、この適切なスコープを見つけることが鍵になる
どんな作業を任せれば良い結果が出るのか感覚をつかみ、それに合わせてスコープを調整していく過程は、プログラミングのモジュール化に近い楽しさがある
Lovableではオンボーディングの時点から失敗を誘発するような印象があったが、Claude Codeで小さく分割して進めるようにしたらずっと成功しやすくなった
for文の例を探す用途で使うだけでも、コンテキストスイッチを減らせて便利初期はこうした単純なコード作成補助としてよく使っていた
print(output)だけ追加するような反応をする自然言語とコードの間を行き来しながら作業すること自体が、むしろ心理的に楽だと感じる
2025年はAIコーディングツールが本当に実用段階に入った年だった
以前はGPT-3のような初期モデルが可能性だけを見せ、そのせいで過度なハイプと懐疑が生まれていた
だが今では、多くの開発者が実際のワークフローにAIを統合している
まだ懐疑的な開発者なら、Mitchellの記事を読んでClaude Codeを実際に試してみることを勧める
一時期は「データの限界」という話が多かったが、Claude Code、Sonnet 4.5、Opus 4.5が登場して空気が一変した
2つのモデルは似た感じだったが、Claudeは料金プランの利用上限をすぐ消費するという話があって、まだ試していない
経営陣が速度と量だけを重視して、保守不能なコードの山を量産するのではと怖い
「Don’t draw the owl」アプローチは自分の経験とも一致する
問題は、LLMが次第に現実の制約から離れてドリフトしていくことだった
そこでチャットは設計の議論用に、エージェントは狭くて検証可能なdiff作業だけを担当させるよう分けた
このループが安定すると、おもちゃではなく本物のレバーになり、実際のプロジェクト機能を何度もデプロイできた
最近はこうしたパターン化された文構造が人間のあいだでも増えていて興味深い
Opus 4.5についての議論が増えてきたので実際に使ってみたが、エージェントのパラダイムが確かに有用になってきたと感じる
まだ単純な作業が中心だが満足している
LLMは自分には合わない
人間の思考力と創造性こそが私たちを特徴づける要素であり、それを機械に渡すのは自分自身を弱めることだと感じる
Rails開発者としてZed、Claude Sonnet 4.x、Opusを使ってみたが、徐々にRSpecを書く力が落ちているのを実感した
結局、neovimに戻ってエージェントなしで作業している
利便性は結局、思考力の衰えを招きうる
LLMは人類が作った最高の利便ツールだが、私は自分の技術と考える力を維持する方を選ぶ
今回の記事は、ほかのフロントページ記事よりずっと実用的で誇張が少ない感じがする
「雰囲気コーディングでOSを作った」みたいな大げさな話ではなく、現実的なアプローチだ
みんなが似たようなAI活用の道のりをたどっているのが興味深い
複数のモデルを並行して使い、コードベースの別々の部分に適用し、モデル同士で相互検証させている
いまでもgit resetはよく使うが、だんだんそれを効率よく避ける方法を学んでいるところだ
まるで脳のオートコンプリート時代に生きているような気分だ
「エージェントはファイルの読み取り、プログラムの実行、HTTPリクエストが可能であるべきだ」という話があったが、
これはSimon Willisonの言う**『致命的三位一体』**とほぼ同じレベルだ
エージェントに改善点を繰り返し伝えなければならないのが面倒
毎回agent.mdを修正してフィードバックを書く必要があるが、自分で学習して改善してくれたらと思う
AGENTS.mdに数行追加する程度なら、それほど大した手間でもない
/fixコマンドを作って自動で修正と文書化をさせれば、かなり時間の節約になる自分がエンジニアリングの主導権を握っている感覚がある
特に新機能の調査と実装を素早く反復できるのが良い
実際にこうしたアプローチがどんなものか気になるなら、
OPの過去のブログ記事 “Non-trivial Vibing” と、
それに関する HNでの議論 も参考になる