7月3日、okTurtlesが「The Short Leash AI Coding Method For Beating Fable」と題した記事を公開した。この記事では、セキュリティクリティカルなシステムでAIコーディングエージェントを安全に使いこなすための「ショートリーシュ」手法について詳しく紹介されている。なお、タイトル中の「Fable」はAIモデル名を指しており、ショートリーシュ手法が比較対象として参照するフロンティアモデルの一つとして記事中で取り上げられている。
「バイブコーディング」の何が問題なのか
AIコーディングエージェントを複数並列で走らせ、開発者自身はコーヒーを飲みながら待つ——いわゆる「バイブエンジニアリング」と呼ばれるアプローチがYouTube等で広まっている。okTurtlesはこのアプローチを明確に否定する。
問題の核心はコードベースへの理解が失われる点だ。AIは複数回「脱線（off the rails）」する。それに開発者が気づくのは、実際にソフトウェアを使おうとしたときだ。品質を問わないなら許容できるかもしれないが、セキュリティクリティカルなシステムではそれは致命的になる。
また、Fableのような最先端モデルが生成したコードであっても、動きはするが非効率で醜いコードになることがある——特に学習データの少ないニッチな領域では顕著だ。「モデルは学習データを超えた思考はできない」と記事は明言している。
ショートリーシュ手法：AIを"短い紐"でつなぐ
okTurtlesが1年以上の実践から導き出したのが「ショートリーシュ（短い紐）」メソッドだ。このメソッドは熟練した開発者が使うことを前提としており、AIを加速装置として使いつつも品質を犠牲にしない点が特徴である。
具体的な実践内容は以下の通りだ。
- 計画フェーズを必ず設ける。 タスクを細分化し、tasksスキルなどのツールで進捗を管理する。
- 「YOLOモード」（権限チェックをスキップする危険な設定）は絶対に使わない。
- AIが作業する間、開発者は離席しない。 AIがプレイ中にゲームを進めるような使い方はしない。
- パーミッションプロンプトで表示されるdiffを必ず確認する。 変更内容を自分の目で解析し、不要な変更にはその場で「DENY（拒否）」する。
- サブタスクの完了ごとにコミットする。 AIが過去の作業を誤って削除する事態（実際にClaudeのOpusモデルで発生したと報告されている）に備える。
- 最後にレビューを行う。
要するに、「常に開発者がループの中にいる」状態を維持することがこのメソッドの本質だ。
AIレビューの正しいやり方
コードレビューについても、okTurtlesは具体的な方針を示している。
人間だけのレビュー、またはAIだけのレビューよりも、両方を組み合わせたレビューの方がミスが少ない。 AIはlinter的な役割として一般的なミスを素早く検出し、人間は方向性の問題や高レベルの設計上の懸念を捉える。
実践上のポイントは以下だ。
- 全PRにAIレビューを適用する。
- AIには十分なコンテキスト（Issue、PR説明、コードベース、変更差分）を与える。
- PR説明に「AI Disclosure」という見出しを設け、使用したモデルを明記する。これはAIを使ったことを隠さない誠実さの表明であり、メンテナーが弱いモデルを使っていた場合に代替モデルを提案できるようにするための仕組みでもある。
- AI支援で作成したPRは、提出者自身が必ずレビューする。 AIが書いたコードであっても、提出者はそれを理解している責任を負う。自分のPRを他人のPRとみなして、1行ずつ確認することが求められる。
このメソッドが「誰でも使えない」理由
記事は「このメソッドは誰でも使えるわけではない」と明記している。前提となるのは、自分の専門領域においてフロンティアモデルを上回る知識を持つ熟練開発者であることだ。AIの出力が正しいかどうかを即座に判断できなければ、ショートリーシュは機能しない。
言い換えれば、AIは「手を動かす速度を上げるツール」であって、「判断を委譲するツール」ではない、というのがokTurtlesの立場だ。
okTurtlesの公式なAI利用ポリシーはCONTRIBUTING.mdのAI Usage Policyに公開されている。
詳細はThe Short Leash AI Coding Method For Beating Fableを参照していただきたい。
