- AIエージェントによる単純な反復作業の自動化、ビルド待ち時間の解消、並列ワークツリーシステムの構築など、開発インフラの改善を通じてコミット数が急増した6週間の経験を整理
/git-pr スキルでPR作成プロセスを自動化し、コンテキストスイッチのコストを解消。エージェントがより詳細なPR説明を直接作成- ビルドツールを SWC に切り替え、サーバー再起動を 1秒未満 に短縮。流れが途切れない開発環境を確保
- Claude Codeの プレビュー機能 により、エージェントが自らUIを検証できるようにし、開発者がすべての変更を直接確認するボトルネックを解消
- 各摩擦要因を順に取り除くと次のボトルネックが表れるという、制約理論(Theory of Constraints) のパターンがそのまま当てはまる
- いまは機能実装よりも、エージェントが効率よく働くためのインフラ構築とループ速度の向上に集中
単純な反復作業の自動化
- 当初は変更のステージング、コミットメッセージ作成、PR説明作成、プッシュ、GitHub PR作成まで、すべての工程を 手作業で実施
- この作業が単純な反復作業(grunt work)だと認識したことが最初の転換点であり、役割が 実装者からエージェントを管理するマネージャー へと変化
- 最初のClaude Codeスキルである
/git-pr を作成し、PR作成までの全工程を自動化
- エージェントがdiff全体を読み、変更内容を適切に要約するため、自分で書いていたときより PR説明がより詳細
- コードベースのCLAUDE.mdにはGraphiteの使用が明記されているが、個人的には plain git を好むため
/git-pr で運用
- 時間短縮そのもの以上に大きかったのは 精神的オーバーヘッドの除去。PR作成のたびに発生していた「コードについて考える → コードを説明することについて考える」という小さなコンテキストスイッチがなくなった
待ち時間の解消
- ローカルプレビューのため、作業中の内容から離れて devサーバーを停止し、新しいブランチで再起動 する工程が繰り返し発生
- サーバービルドに約 1分 かかり、集中を切らすには十分長く、別の作業をするには短すぎる時間だった
- ビルドを SWC に切り替え、サーバー再起動を 1秒未満 に短縮
- ファイル保存直後にはすでにサーバーが立ち上がっており、注意が散る隙がなくなった
- 「気まずい沈黙のある会話」と「自然に流れる会話」の違いになぞらえている
エージェント自身によるUI検証
- 従来はすべてのUI変更をローカルプレビューで自分で確認する必要があり、開発者があらゆる機能のボトルネック になっていた
- Chrome拡張機能が繰り返しクラッシュした後、Claude Codeの プレビュー機能 へ移行
- エージェントがプレビューを設定し、セッションデータを維持しながら UIが実際にどう見えるかを直接確認 できる
- これをワークフローに統合し、エージェントが UIを自分で検証して初めて「完了」 と扱うようにした
- 検証を委任できるため、最終レビューにだけ関与すればよく、エージェントがより長時間自律的に動ける
- エージェントが 自分でミスを見つけること が、想像以上に重要な効果だった
並列ワークツリーシステム
- 高速リビルドと自動化されたプレビューが整ったあとで見えてきた次の摩擦は、一度に1つの作業しか快適に進められない という点
- 別のエージェントやチームメンバーのPRをレビューするには、mainからPRブランチへチェックアウトしてリビルド・テストする必要があるが、未コミットの変更と衝突する
stash → checkout → rebuild → test → switch back → pop stash、あるいは手動でworktreeを作成してポート競合が発生
- アプリはフロントエンドとバックエンドでそれぞれ別ポートを必要とし、すべてのワークツリーが 同じ環境変数を共有 しているため、同じポートにバインドしようとしていた
- これを解決するため、ワークツリー作成時に各サーバーへ 固有のポート範囲を自動割り当て するシステムを構築
- 2本の並列ブランチでも圧倒されていた状態から、5つのワークツリーを同時運用 するレベルへ移行
- 複数のエージェントを別々のワークツリーで走らせ、それぞれ異なる機能をビルドさせ、UIの自己検証が終わるまで自律的に実行 させる
- 計画段階には深く関わったあと、コードレビューの時点まで介入しない 方式
- レビューもはるかにスムーズになった。設定作業、リビルド、ポート競合なしに、読んで、確認して、マージする 流れになった
核心はAIではなくインフラ
- 役割が変化。複雑な問題を自分で解き、完璧なUIを作ることに時間を使う代わりに、エージェントを効果的にするインフラを構築 するほうが面白くなった
- ソロ開発者ではなく、10人規模のチームのマネージャー になったのに近い
- 派手ではない配管(plumbing)作業だが、これが フロー状態にとどまれるか、環境と戦うことになるか を決める
- Tanoで最もレバレッジが高かった仕事は機能開発ではなく、コミットの流れを急流に変えたインフラ構築 だった
ループ: 制約理論の適用
- 各段階はそれぞれ異なる種類の摩擦を取り除く:
/git-pr: コード変更をPRにする フォーマットの摩擦 を除去- SWC: 変更後に結果を見るまでの 待機の摩擦 を除去
- プレビュー機能: 変更内容を確認する 検証の摩擦 を除去
- ワークツリーシステム: 複数の作業フロー間の コンテキストスイッチの摩擦 を除去
- 1つ取り除くたびに次のボトルネックがすぐ表れる、制約理論(Theory of Constraints) の典型的なパターン
- 作業の本質が変化した。「コードを書くためのツールを使うこと」ではなく、作業開始 → エージェントがコードを書く → プレビュー確認 → diffを読む → フィードバックまたはマージ → 次の作業、という タイトなフィードバックループ になった
- ループが十分に速ければ注意が逸れる隙がなくなり、速度向上そのものがゲーム になる
- 最終的に開発の目標は機能実装ではなく、ループ速度をどこまで高められるか へ移っていく
- 速度そのものがエンジニアリングの楽しさになる段階 に到達
2件のコメント
レビュアーとしては、機械が書いたPR Descriptionを見ると、あまり体験が良くないんですよね。プロンプトチューニングさえうまくやれば違うのかなとも思いますが……
Hacker Newsの意見
90年代の**「週間コード行数」**指標が戻ってきたように感じる
「PRをより多く出す」というのは、AIがうまく機能している証拠ではなく、単により多くマージしているという意味にすぎない
コード品質、バグ、保守負債を考慮せず、生産量だけで成果を判断するのは、昔の管理職が押し付けていた悪い指標と何も変わらない
結局のところ、私たちは悪い指標に反対していたのではなく、測定されること自体が嫌だったのかもしれない
コードがシンプルで、影響力のある結果を出すことが本当の目標だ
複数のエージェントを同時に走らせて異なる実装を試させ、その中の良いアイデアを組み合わせる形で実験している
また、文書と要件を集めてエージェントに質問を投げ、コードレビューのフィードバックを一般化してチェックリストにし、次のレビューに反映している
病むほど働くのは自慢ではなく、システムが間違っているというサインだ
たとえば COCOMOモデル は、法廷でもシステム価値の推定に使われるほど信頼されている
大半の開発者は自分自身を数値化されたくない
ただしAI擁護派は、改善を証明するには測定が必要だと考えている
LLMは認知負荷を減らす方向で使うべきだと思う
人間はマルチタスクが苦手で、LLMがそれを補ってくれるわけではない
私はClaudeに実装を丸投げするのではなく、自分で実装する過程を案内してもらう形で使っている
こうすると全体の流れを理解しながら、細部と大局を同時に見られる
反復的で機械的な部分だけClaudeに任せればよい
LLMに問題を理解させるための質問を投げ、核心部分のコードは自分で書いたうえで、残りの実装計画を立てさせる
LLMはコードの読解・説明・単純作業に強く、私は問題解決の方向を選ぶことに集中する
LLMが自分の代わりに決めた部分を追跡するため、「仮定の一覧を作れ」や「計画にない決定を列挙せよ」といったプロンプトを試している
Claudeの特性を理解すれば検証効率も上がり、経験が蓄積するほど品質管理もしやすくなる
複数のエージェントを動かして大きな機能を作ると、結局レビュー時間が非常に増える問題が生じる
他人（あるいはAI）のコードを読むほうが、自分で書くより難しいからだ
テスト自動化でカバーできるかもしれないが、完全に信頼するのは難しい
スコープ・テスト・文書化計画を明確にし、コードレビューボット（Sourcery, CodeRabbit, Codescene）と強力なリンティング規則を適用する
BDD、property testing、e2eテスト、コード監査、mutation/fuzzingテストまで活用する
エージェントコーディングの利点は、こうした品質管理に使う時間を確保してくれる点だ
100 PRs a day のようなアプローチで段階的デプロイを試している
作業を細分化し、テストを信頼すれば、AIコードレビューも軽くなる
テストケースをより丁寧に見て、コードレビューは素早く終える
複数のエージェントを並列では回していないが、AIのおかげで生産性は確実に上がった
PR作成工程が単純に自動化されると、自己検証の機会が失われる
私はPR説明を書く過程で、自分のコードのおかしさにしばしば気づいた
英語で説明するその瞬間が、最後の sanity check だった
worktreeシステムのおかげでコンテキストスイッチはしやすくなったが、同時に精神的疲労も大きくなった
小さな単位に分けてレビュー周期を短くすれば、品質管理はしやすい
自分の流れを崩さず、翌日に戻ってきても進捗している状態なのが良い
Claudeが高い完成度でコードを書くという前提には懐疑的だ
実際には何度ものフィードバックと修正が必要で、同時に複数作業を並列管理すると、むしろ非効率になる
Claude Codeは学習用ツールとしては革新的だが、コード生成品質にはばらつきがある
Flutter/Dartを学びながらClaudeに概念を尋ねる形で勉強したところ、本なしで1週間でアプリを作れた
まるで対話型百科事典のように感じられる
「この言語でXをするイディオマティックな方法は？」のような質問に、即座に有用な答えを返してくれる
ただし世界を変える存在というより、とても優れたツールにすぎない
しかし過剰なマーケティングが経済全体に悪影響を及ぼしている
AIが仕事を置き換えるという幻想のせいで、若い世代が職業を諦める現象も懸念される
「SWCにビルドを切り替えたらサーバー再起動が1秒未満に減った」という話があったが、
SWC はSpeedy Web Compilerで、型チェックなしに高速トランスパイルを行うツールだ
NestJSドキュメント でも同じことが説明されている
LLMを使っているからといって、生産性が爆発的に増えたと自慢するような話ではない
皆が同じツールを使えば、基準線が上がるだけだ
しかもAIが生成した大規模なコードが適切にレビューされなければ、長期的な品質は不確かだ
LLMが生産性を高めるのは確かだが、コミット数グラフで測るのは無意味だ
LOCで品質を判断するのと同じくらい愚かだ
自分でコードを書きながら理解し、Claudeは作業分解とレビューの相棒として大いに役立っている
複雑なコードを単純な抽象化に置き換える能力こそが、本当の生産性だ