Fableを打ち負かす「短いリード」のAIコーディング手法
(blog.okturtles.org)- セキュリティ重視のソフトウェアでAIコーディングエージェントを使うには、自律実行に任せるよりも、開発者が変更を継続的に統制する Short Leash方式 が必要
- 複数のエージェントが並列でコードを作成・レビューする「vibe」式アプローチは、コードベース理解を弱め、AIが off the rails 状態になった後になって初めて問題に気づかせる可能性がある
- 中核となる手順は、計画立案、段階分解、権限プロンプトの diffレビュー、頻繁な拒否と介入、サブタスクごとのコミット、最後のレビューへと続く
- PRレビューではAIと人間を併用することでミスを減らせる可能性があり、AIはよくある誤りを素早く見つけ、人間はより高次の問題や方向性を判断する
- AIが作成に関与したPRは、提出者が1行ずつ直接レビューし、PR説明に使用モデルを AI Disclosure として明記してこそ信頼を得られる
AIコーディングエージェントを使うための前提
- この方法は、セキュリティ重視システム で高品質なソフトウェアを作るためにAIエージェントを使ってきた経験に基づく
- 対象は、AIを学習の敵とみなすべき初心者開発者ではなく、自分の専門領域で「frontier AI models」より優れた 専門開発者
- 目標は、AIを性能向上ツールとして使いつつ、ソフトウェア 品質を犠牲にしないこと
- 経験の範囲には、AIエージェントの限界探索、自前のAIレビューツールの作成、AIコーディングエージェントCrushの カスタムフォーク 維持が含まれる
「vibe」式アプローチが揺らぐ地点
- AIエージェントを使うセッションでは、2つの問題がよく起こりうる
- 最初のアイデアが悪く、より良いアプローチがあることに後から気づく
- エージェントが望まない方向へ off the rails 状態になる
- 複数の並列エージェントとオーケストレーターが同時に作業し、開発者がコーディング過程から外れると、コードベース理解を自力で積み上げにくくなる
- 品質を気にしない状況ならこの方式でも問題ないかもしれないが、品質が重要な場合 には別のアプローチが必要
- Fable 5が書いたりレビューしたりしたコードは、動作しても非効率で見栄えが悪いことがある
- モデルが依存できる学習データが少ない ニッチ領域 では、この問題がより頻繁に起こりうる
- 一部CEOのマーケティングとは異なり、この見方ではモデルは学習データの先まで思考できない
Short Leash方式の動作
- Short Leash方式は誰にでも使える方法ではなく、専門ソフトウェア開発者 向け
- frontier modelを使わなくてもFableを打ち負かす結果を出せる点が利点
- 作業前には計画段階で課題を調査し、計画を立てる
- 大きな作業は tasks skill のようなツールで進捗を追跡し、段階に分ける
- この部分は複数の「vibe engineering」方式と共通している
- その後の核心は、AIを継続的に 短いリード につないでおくこと
- 「YOLO」モードや「dangerously skip permissions」は使わない
- ユーザーがゲームをしている間、AIを単独で作業させない
- 適用予定の変更の diff を権限プロンプトで表示するコーディングエージェントを使う
- 開発者がAIの提案変更を実際に分析する
- 権限プロンプトのdiffでコードベース理解を最新に保ち、AIを統制する
- AIが望まない作業をしようとしたら権限を拒否する
- 必要なときは頻繁に介入し、AIが方向を見失わないようにする
- サブタスクが終わるたびにコミットを作成し、AIが以前の作業を壊したり削除したりする事態を防ぐ
- こうしたことは実際に起こりうり、Opusで見た事例がある
- 最後の段階ではレビューを行う
AIレビューは人間レビューを代替しない
- 人間だけでレビューしたPRやAIだけでレビューしたPRより、人間とAIが一緒にレビューしたPR のほうがミスを減らせる可能性がある
- AIはリンターのように扱える
- よくあるミスを素早く見つける
- 人間はより高次の問題や方向転換の必要性を判断する
- すべてのPRはAIレビューを通すことが推奨される
- AIレビューには十分な 文脈 が必要
- Issue
- PR説明
- コードベース
- 変更内容
- レビューには利用可能な最新モデルを使うことが推奨される
AI Disclosureと提出者責任
- PR作成にAIが使われたなら、PR説明の AI Disclosure セクションで使用した正確なモデルを公開しなければならない
- この公開には複数の目的がある
- メンテナーにAI使用の事実を伝える
- 弱いモデルを使っていた場合、より良いモデルを提案できるようにする
- AIをこっそり持ち込もうとしているわけではないというシグナルを与える
- AIを使ったPRは必ずPRの「作成者」が自分でレビューしなければならない
- AI補助PRは、実際には人間の助けを得たAIのPRに近いため、提出者は自分が提出する内容を理解している必要がある
- 提出者は自分のPRを他人のPRのように見て、line-by-line で直接レビューしなければならない
- セルフレビューが終わった後、自分の承認を確認し、メンテナーにレビューを依頼できる
- この過程は、提出者がコードベースを理解していることを形にし、示す役割を果たす
okTurtlesの適用方法
- okTurtlesはこの方式でAIを活用している
- 公式ポリシーは AI Usage Policy に整理されている
- この記事自体は人間が執筆し、公開前にAIスタイルの スペルチェック のみを行ったというAI Disclosureが含まれている
1件のコメント
Hacker Newsの意見
この「短いリード」方式は補助ツールというより松葉杖のように見え、そもそもAIに問題を十分説明していなかったか、出力をレビューして反復していなかったというサインのように思える
Fableのような強力なモデルを実装段階で手取り足取り引っ張っていくのは時間の無駄であり、Fableの無駄遣いでもある。強力なモデルほど、より微妙な設計議論ができ、以前よりはるかに良いコードを書く。設計と実装を議論し、おかしく見える部分を質問し、AIの回答を実際に読むというプロセス自体が、より良い解決策を見つける助けになる
以前、貪欲アルゴリズムの解法を作ろうとしていたとき、Opusと議論する中で、既存のMILPライブラリで問題を正確に解けると提案された。MILPについて聞いたことすらなかったが、最終的な実装は自分一人でやった場合より良く、単純になった
ところが動作せず、その第一原理推論の手順を説明してみてくれと言うと、実際にはただでっち上げただけだと答えた。なので、モデルとの微妙な議論という話は信じがたい
計画段階に十分投資していて、プロジェクトの既存アーキテクチャや慣例がしっかりしているなら、ここで言われているほど実装段階で多くの監督は必要ないかもしれない
「初期アイデアが愚かで、より良い方法があると気づける」というのは、たいてい計画とアーキテクチャの段階で高レベルに発見される
エージェントが望まない方向へ「脱線」する問題も以前ほど悪くなく、影響のある変更には最低限のテストカバレッジがあるべきだ。そのテストが単に実装済みの挙動を「固定」する程度でもよい。最後のレビュー議論は、レビューや敵対的レビューエージェントが見つけたもの以上を確認する良い機会になる
MILPの例はこのアプローチが妨げるようなものではなく、計画段階で明らかになっていたはずだ
結局は細部が重要で、作業開始時のプロンプトをどう与えるかが影響する。それでも、出力を確認し、モデルがやっていることに関与し、なぜそう作ろうとしているのかを問い詰めるプロセスは必須だ
しかし、その社員のアイデアはテーブルに上がらず、長期的にチーム全体のためになり得る貢献も失われる
生成されるものをすべて理解し、コードベースに関する作業知識を維持し続けられるようにしてくれる。方向転換も簡単にさせられる
サイドプロジェクトで2週間こうやってみたが、結局コードベースに対するメンタルモデルがない状態になった
自分で作らない限り、そのモデルを作る方法はないのだと、より確信するようになった
忘却曲線のせいで、自分のメンタルモデルは最初に作っていた期間ほど長くは持続しない。どうやって再構築するかは、まだ分かっていない
ただし、自分で書いたときのように「自分で作れる能力」はあまり蓄積されないという点には同意する
例えば、ある効果を得るにはどんな変更をすべきか分かっていて、実際に変更すると期待した結果になるので、自分のメンタルモデルが機能していることは分かる。だが、似たものをゼロから自分で作れと言われたらできない気がする。アプローチが自分の手の届かないところにある感じなのだが、説明しにくい
実際にコーディングできる人は、重要なことにAIを使うときはみんなこう使っているのだと思っていた
自分が間違っているのか？ 最近はみんな単にYOLOモードで回しているのか？
funemploymentの楽しみだ。再び仕事を始めたら、かなり興味深い変化になりそうだ
今は走らせておき、ビールを飲みながら1時間ほど大きな方向性の批評と自己点検／クローズドループのフィードバックを新しく設定してから、また好きに走らせる、という単純なやり方だ
Claudeをbypass-permissions以外の方法でどう使うのか気になる。Claudeが使えるツール一覧を長く管理してみたが、結局戻ってくると、あるツールの出力を別のツールへパイプしようとして、明示的に許可されていないと言って止まっていることが繰り返された。単なる
grepのようなことだったのに止まるので腹が立ったbypass-permissionsでは「そのまま動く」。もちろん既存コードの分析と変更提案にだけ使っていて、何か壊れても、それはバージョン管理がある理由だと思っている
概ね筆者に同意する。何よりも、LLMがすることや言うことは何一つ信じるなと付け加えたい
今日Claudeに3つのコンポーネントの挙動を統一するよう頼み、5回もやらせた。毎回最後にはまだ合っていない部分があり、Claudeはそれを正当化する方法を見つけた
尋ねると「私の責任です」や「意図的な選択だと思っていました」と答えたが、先に何をすべきか質問したり、問題を述べたりしたことは一度もなかった。だから短いリードを握り、思考過程を見て、無駄なことをすぐ正さなければならない。これは今日のSonnet 5基準であり、明日は良くなるかもしれないし悪くなるかもしれない。今日Claudeに通じる言い方が、明日は別の結果をもたらすかもしれない
「AIでXする方法」系の記事の問題は、状況ごとにすべてが異なることです。たとえば Symfony プロジェクトを 3.1 から 8.1 に上げる作業は、道筋が明確です。
メジャーバージョンごとに書かれた移行ガイドに従い、すべてのルートや認証フローなどをテストすればよいのです。このテストも自分で選別でき、あるものは 200、あるものは 302 を返すかもしれません。
必要なら先にセーフティネットを書いて手動テストを減らし、たとえば PHPStan のベースライン などを置くこともできます。
ルートがエンドツーエンドで機能的に意図どおり動けば、それで終わりです。ここではスナップショットテストも使えます。
こういう場合、AI を見張っている必要はありません。最後にコードをレビューすることはできますが、途中でいちいち手動承認する必要はないので、安全機能はオフにします。
たいていは一つの観点から書かれますが、実際の観点は広く、ある状況で通用することが別の状況では通用しません。ソフトウェアエンジニアリング全体が結局、何をどこで、いつ適用するかを見極め、それ以外は無視しようとする営みに近いのです。
多くの企業ブログ記事は、あらゆる場合に通用する銀の弾丸があるかのように信じさせますが、普通は事実ではありません。
結局いつものソフトウェアエンジニアリングで扱ってきたように、「あるものは、ある状況で通用する」という話に近く、正誤というより状況ごとの実際の適用が違うだけで、それは普通のことです。
AI はジュニアから中級エンジニア程度です。そう扱えば、こうした偏執的な対応なしに、バイブコーディングと厳格なエンジニアリングの両方の利点を得られます。
最初から隔離された VM で Claude を YOLO モードで動かしていました。エンジニアに自分のノートパソコンを渡すのと同じです。Claude が機能を PR できるところまで作り、私はほかのエンジニアの場合と同じように diff をレビューしてから、適切な形に整えて次へ進みます。
未熟なエンジニアも同じミスをします。
rm -rfも見たことがあります。ルートでやったわけではありませんが。すべての権限を拒否したまま誰かをマイクロマネジメントしていたら、気が狂っていたと思います。ジュニア/中級エンジニアのたとえにも同意しますが、大きな但し書きがあります。AI は学び方を知らないジュニアエンジニアのようなものです。
『メメント』の主人公と一緒に働いているような感じです。毎日 LLM が出社すると、これまでの作業から何も学んでおらず、毎日が初日です。
もちろん『メメント』の主人公のように、作業スペースのあちこちに付箋やリマインダーをばらまいて助けることはできます。努力すれば「学習」と呼べるものに近づけることはできますが、これはチームのすべてのソフトウェア開発者にとって文字どおり最も重要な特性です。
しかし簡単ではなく、ツールもまだ不十分です。自分が試した中で最善だったのは、Obsidian のようなツールで使う「第二の脳」に近いものでした。残念ながら、第二の脳は第一の脳の代替にはならないと思います。正直、AI エージェントのように学び成長できないエンジニアなら、私が働いてきたどの会社でも最初の1カ月後に解雇されていたでしょう。
それでも、主要な AI プロバイダーか誰かが今後この部分を改善してくれるだろうと、かなり楽観しています。優れたメモリと、文脈に合わせて記憶をよりうまく注入するよく設計された思考システムが組み合わさり、監督なしに実際の学習を捉えられるなら、不可能な課題には見えません。
こういう問題をすでに誰かが解決していて、自分が遅れて気づくだけで済む状況であってほしいと思いながら、こうした記事を読んでいますが、今のところはエージェントを設計する能力が最初より少し良くなった程度です。
私の経験則は、AI のために作る特殊なプロセスは人間にも妥当であるべきで、そうでなければ価値がない、というものです。良いコマンドラインツール、長いコマンド出力の自動要約、Markdown 文書とワークフローは、人間にとっても有用です。
ミスや悪用を防ぐには、マイクロマネジメントではなく、サンドボックスとスコープを限定した権限を使うべきです。
知りたいのは、AI エージェントとの良いペアプログラミングのワークフローです。高性能モデルに大きな作業を任せることはでき、それはうまくいきます。低レベルモデルを IDE の補助として使うこともでき、それもうまくいきます。しかし両者は別々のワークフローです。
本当に有用なのは、高性能モデルとキーボードを受け渡ししながら一緒に作る方式です。ただし、自分のマシンで完全な YOLO モードで動かすべきではありません。ここが人間と LLM の違いです。速すぎるので、脱線したときにキーボードを奪い返すのが難しいのです。
AI が何なのかは正確には誰にも分かりませんが、ジュニアでも中級エンジニアでもありません。ドメインの文脈がなく、5時間ごとに記憶なしで目覚める、掘っ立て小屋に住む原子力スタッフエンジニアに近いです。
LLMはいまだに次トークン予測器である。より曖昧な指示を出しても正しい手順を見つけられるからといって、知能があるという意味ではない。あなたがモデルの訓練に使われたハーネスと同じ言語を話しているという意味である。
そしてそこには限界がある。概念実証レベルや単純なアプリにとどまっているなら、現在のモデルがいまだにどれほど制限されているか分からないかもしれない。そういう場面では作業を分割すべきで、もっともらしい手順を並べるトークン予測器を信じてはいけない。
どこかには必ず人間のループが必要である。権限のスキップを始めると、最良の場合は大当たりだが、より可能性が高いのは次善の解法とトークンの浪費である。本当に怖いのは、モデルが指示を無視して愚かなことをし、一日を台無しにする場合である。
これはCNC機械のように鋭い。有用でないわけではないが、危険になり得る。縦列駐車ができないなら、怪物のような機械で木を削ろうとしたり、狭い住宅街にFerrariを停めようとしたりしない方がいい。
LLMが「トークン予測器」だから何かができる、あるいはできないと言うのはカテゴリーエラーである。インターフェイスは堅い限界ではない。
LLMには知能がないとあらかじめ決めておく公理を使わずに、言語モデルは除外し、人間は含める定義がどう可能なのか気になる。
たいていこの言い方で意図されるのは「訓練データ、つまりインターネットの次のトークンを予測しているだけ」という意味だが、素のモデルについてなら事実かもしれない。しかしモデルは事後学習を経るので、この説明すらもはや正しくない。
「知能ではない」という言葉は有用でもないし、私の考えでは間違っている。あなたの知能の定義に合うかどうかを誰が気にするのか。依然として印象的なことをやってのけており、あなたが示唆するよりはるかにすごいこともしている。
元記事はまだ2025年にとどまっている感じがする。
「AIが何度も脱線し、実際にソフトウェアを使ってみて初めて気づくだろう」と言うが、今やそのAIが自分でソフトウェアを使ってバグを見つけて修正でき、新機能も進められる。
エージェントが望まないことを始めることはあるが、以前よりずっと減っており、完全自律エージェント側の論拠は弱まるどころか強まっている。
「人がコードベースを理解するのは人間的に不可能だ」という言葉も古く見える。今や人間がコードベースを理解する必要がなくなり、AIが主導していく方向に進んでいると思う。
多くの人がこれに乗っているが、私は愚かな流行だと思う。
だがセキュリティリスクの大きいシステムには絶対に当てはまらない。銀行、航空、防衛のような分野ではAIは確かに貢献するだろうが、人間のエンジニアリング理解とは独立して動くことはできない。
短いリード方式は、訓練データの外で作業するときに良い結果を保証する方法である。平均より少し上のプログラマーであっても、LLMで高速かつ高品質な開発を保証する唯一の方法はこの方式だと思う。
人間がもうコードベースを理解する必要はないという発言は、AIがまだ悲惨なほど不得手なプログラミングの世界を知らないことから出ているように見える。手動メモリ管理のある言語で、メモリ処理を頻繁に壊すのを継続的に見てきた。Valgrindのループに入れておけば済むほど単純ではない。
API定義、リクエスト/レスポンスモデル、データベーススキーマ、全体フローを何度も反復して練り直し、矛盾の除去とドキュメント修正をかなり自分で行った。Opusはずっと脱線し、最終ドキュメントは500行を超えた。
API統合テストでも行き来が必要だった。AIがドキュメントから直接テストを作れなかったため、まずGiven-When-Thenコメント付きのプレースホルダーを作り、手でレビュー・修正した後、2回目の反復でテストを実装した。レビュー後に修正したミスが多かった。
実装段階では、APIドキュメント、動作するテスト、修正ブロックフック、6個以上の「ベストプラクティス」スキル、「ラバーダック」と「コード単純化」エージェント、テスト・リンター・コンパイルエラー確認用スクリプトを提供した。計画、実行、レビューと複数回の修正を経て機能は実装され、テストもすべて通った。
コードレビューでは、平均してコード20行あたり1つの問題を見つけた。コードスタイルを除いても、Kubernetesサービスでのインメモリセマフォの使用、単一リクエスト中に同じレコードを更新しようとしてDB呼び出しを8回行うこと、1回に1カラムずつ更新すること、トランザクションなしの読み取り・修正・保存、ビジネスロジック・復旧・認可のミスがあった。
結果は、ほぼ1週間分の業務時間、100ドル超のトークン費用、そして「この努力に価値はあったのか？」という思いだけだった。2人の開発者チームを抱えているが、たった今1人のPRをレビューしたところ、80%がスロップだった。
似たようなアプローチを試したが、私にはうまく合わなかった。速度向上はほとんど、あるいはまったくなかった。生産性を得るには、サンドボックス内である程度のYOLOモードが必要だと思う。
目標は、モデルに可能な限り多くの作業を外注しつつ、その結果を理解してレビューするために必要な労力を最小化することのはずだ。
例えば、モデルにバグ原因の特定、Xの概念実証の作成、何かを段階的に最適化すること、ガイド付きで明確に定義されたリファクタリングなどを任せる、という具合である。
人々がループを作ると言っているのも非常に似ている。モデルが行うことを最大化し、それを制御するために自分がしなければならないことを最小化するということだ。
記事には大した内容がなかった
昨年は「AIは確率的オウムにすぎない」だった
今年は「AIはコードを書けるが、人間が依然としてレビューしなければならない！」だ。もちろん、そのレビューにもAIを使う
あと1年もすれば、語られる筋書きは「コードレビューはAIにしかできず、AIのレビューをレビューできるのもAIだけだ。人間は意味のある監督を維持するために、AIの最終見解だけを読めばよい」になるだろう
ゴールポストは動き続けるが、確信は決して動かない