Superpowers：2025年10月、私がAIコーディングエージェントをこう使う！
引用元：https://news.ycombinator.com/item?id=45547344
この投稿は強く推すよ。Jesseのツールの使い方は、他の人よりはるかに野心的だね。彼のGitHubリポジトリ（https://github.com/obra/Superpowers）をぜひ掘り下げてみてほしいな。昨晩、これについていくつかメモを書いたから、ここ（https://simonwillison.net/2025/Oct/10/superpowers/）も読んでみてね！
大規模なコードベースでの実際のコーディング性能について、「Research -＞ Plan -＞ Implement」メソッドや「Advanced Context Engineering from Agents」ビデオのプロンプトとどう違うのか興味あるな。スキルを習得するのはエージェントの能力を広げるのに役立つけど、実際の開発に最適かは疑問だね。パッケージ化されたコレクションや新しい能力の自動追加はすごいけど、スキルという概念がカスタムコマンドやサブエージェントより優れてるのか、まだ納得できてないよ。数日いじってみて比較してみるね。
「Research -＞ Plan -＞ Implement」フローを使うのは直交する考え方だけど、その一部がスキルとして存在することもあるね。実装中のデバッグとか、ブレインストーミングやリサーチを改善する特定のテクニックみたいに、他にもやるべきことはあるし。信頼性や一貫性を高めるには、これらのスキルのいくつかは、LLMが強制的に実行するプログラム化されたワークフローにした方がいいかも。僕のエージェントではそうしてるよ。LLM（スキル選択、曖昧な部分の実行）とプレーンなコード（スキルのオーケストレーション）の組み合わせが、最高の選択肢だと考えて追求してるんだ。
サブエージェントについてどう思う？メインコンテキストで動かすより、やっぱり大量のトークンを消費するんじゃないかな？サブエージェントに大きく依存するプロセスには懐疑的だよ。僕はProプランを使ってるけど、メインコンテキストを汚染しないためだけに月200ドルにアップグレードする価値があるとは思えないな。
僕の意見では、サブエージェント（または「ツールとしてのエージェント」パターン）は桁違いに重要な機能だよ。すぐに全てのCLIエージェントでファーストクラスの機能になるだろうね（今でもカスタムスクリプトで使えるけど、人間工学的には劣るけどね）。コンテキストノイズの多いサブタスク（例えば、何十もの無関係なファイルをgrepして、必要なファイルを特定するような大規模コードベースの検索）を隔離できる能力は、はるかに長時間のループを可能にし、より複雑なタスクをアンロックするんだ。このメリットを享受するのに、そんなに複雑なシステムは必要ないよ。単純な「コードベース検索エージェント」だけでも、その効果をすぐに実感できるはずさ。一度体験したら、僕みたいにサブエージェントの可能性をそこら中で見つけるようになるよ。
サブエージェントは、メインエージェントループでトークンを消費せずにサイドクエストを完了するための、トークンコンテキスト管理ツールとしてのみ価値があると思うよ。トークンを無駄にしない使い方はまだ完全には把握できてないんだ！
これ、よくわかんないな。
むしろサブエージェントは元のプロンプトや履歴の一部しか見なくていいから、トークン消費量は減るんじゃないの？何を見落としてるんだろ？
ほら、俺の例を見てくれよ。サブエージェントをたくさん使ってタスクさせたら、5つのサブタスクでそれぞれ重複する情報使って、5万トークン以上消費したぞ。
https://simonwillison.net/2025/Oct/11/sub-agents/
それってClaude Codeの実装方法次第じゃないの？
自分でコード書くなら、サブエージェントとオーケストレーターのコンテキストが重複しないように設計できるはずだよ。
メモリ自体をサブエージェントが、必要なものだけ取得するためのツールにすることもできるしね。
これってElixirのusage rulesに似てるな。エージェントの振る舞いに関するもので、今は特にClaude向けって感じだけどね。
https://hexdocs.pm/usage_rules/readme.html
AIコーディングツールの平均的な体験ってどうなんだろ？
エージェント使ってCSVフォーマットのオプション追加みたいな簡単なこと試したけど、結果は散々。
全部やり直す羽目になったよ。プロンプトエンジニアリングも面倒だし、俺が少数派なのか筆者がそうなのか、わかんないな。
こう考えてみて。君が求めているものが公開GitHubリポジトリで見つかる可能性ってどれくらい？
それが高ければ、うまくいくよ。
君の方向性は合ってるけど、こう言い換えたいな。
解決策がGitHubリポジトリに、機械がプロンプトに関連すると認識できる形で存在している可能性は？
問題が一般的で解決策が多くて、LLMの出力評価できるなら、うまくいくはずだよ。
最近までAIに否定的だったけど、問題は使い方だね。
曖昧な頼み方じゃダメ。具体的なほどいい。
自分の労力を100倍とかじゃなく2倍か3倍にするつもりで、小さなタスクを任せてしっかりチェックするんだ。
俺がコントロールし、デザインし、決定を下す。
思考の補助ツールとして使えば、LLMは最高の武器になるよ。
それはいいけど、2倍から3倍の効率にはならないと思うな。
せいぜい1.2倍から1.3倍くらい（研究では0.9倍が多いらしいけど）。
コーディングなんて仕事の10%くらいだし、エージェントは他の部分にあまり役立たない。
むしろチェックや修正が増えるだけだよ。
エージェントの性能はやる仕事によって大きく変わるよ。
ウェブ開発ではClaude CodeやCodexは超役立ったけど、Zigだとダメだった。
タスクによる有用性の差はデカいんだ。
エージェント使うスキルも高くて、計画とかコンテキストエンジニアリングが重要。
だから意見が分かれるのもわかるな。
AIを使ってるって言う人たち、完全自動化って言ってるけど、実は裏で手書きコードが多いんだよね。プロンプトもひどくて、AIがやったって言う「メジャー機能」が、実際は数十分で終わる簡単なタスクだったりする。経験豊富に見える人でも、AIコードの質が判断できない下手な人もいるし、俺はそういう人たちの成功を再現できないのが悩みだわ。
そうそう、それ俺も感じるわ。MCPサーバーを7台とか、5000行のAGENTS.mdファイルとか作って、独自の「記憶システム」とか持ってる人たちね。ほとんどの場合、パフォーマンスが悪くなってるんだよな…。俺はWeb開発で一番AIエージェントを使うけど、基本タスクだけだね。DBスキーマ追加とか、マイグレーション、APIエンドポイント公開とか、ページ表示とか、複雑じゃない「めんどくさい作業」には結構使えるよ。
いやー、こういう奴らってAI界隈のNFT/Cryptoオタクと一緒で、何も理解してないんだよな。一番ましな奴らでも、基本的なソフトウェアプロジェクト管理を「新発見」みたいにEvery Social Media SiteとかSubstackで語ってるし。「ちゃんと計画して、反復して、タスクを細かく分けたら開発がスムーズになったぞ！11（俺のAIポッドキャスト登録してね）」とか、馬鹿かよって。本でも読めって感じ。
俺はAIの価値はドメイン、言語、フレームワーク、期待値、あとPrompt Engineering次第だと思うんだよね。最近数週間でめちゃくちゃ良い経験をしたよ。例えば複雑なDependency Injectionの問題で、Claude（Code）が超変な設定ミスを見つけてくれたんだ。俺も同僚も全然見つけられなかったのにね。統合テストの問題でも、俺が15～30分かけて見つけたのと全く同じ2行を、Claudeが見つけてくれたりもした。たまにすごいことやるんだよな。なんでみんなAIに価値を見出せないのか不思議でならないね。
俺も同じで、「なんで俺だけ？」って思ってるよ。HTMLテンプレートとかCSSとか、テストコードの生成とかは上手くいってる。React Nativeで画面作らせるとそこそこだけど、プロダクションレベルには遠いし、Railsだとちょっとマシだけど、これも遠いね。結局、AIの出力より自分で書く方が手間がかからないんだよな。
AIコーディングって、マイクロタスクで、具体的な指示があって、ちゃんとドキュメント化されたアーキテクチャの中だったら驚くほど使えるんだよ。でも、AIに自由を与えると、トレーニングデータにない独自の原理を持ち出して、パフォーマンスの悪いコードを出してくる。そして、それが正しいって言い張るから困る。自分の専門外のタスクだと、間違った原理でも信じちゃうかもしれないから、気をつけないとね。
コードやログファイルからテストケースを作るのはマジで得意だね。StackOverflowで答えが見つかるような定型的なタスクも得意だよ。俺はGPT-4.1とClaude Sonnet Thinking 3.7をvscodeとGitHub Copilotと組み合わせて使ってる。
用途次第だと思うな。シンプルな繰り返し作業は、低レベルでガイドすればめちゃくちゃ良いよ。でも、既存のコードを簡単に台無しにしちゃうこともあるから、常に注意深く見る必要があるね。
AIコーディングツールって、たぶん完全な初心者か、チームの構築と育成経験があるリードエンジニアに一番向いてると思うんだ。エージェントから良い結果を引き出すのは、インターンから良い結果を引き出すのと似てるよ。つまり、何をしたいのか明確に説明して、相手の計画を確認して、フィードバックを与えて、結果をめちゃくちゃ注意深くレビューする必要があるんだ。自分のコーディングスタイルとか、プロジェクトの進め方とかをドキュメント化して、厳格な自動品質チェックも必要。要は「テクニカルリード」に昇進するようなものだね。この前のSonnet 4.5で良い結果を出せたけど、マジで「技術管理スキル」をフル活用したし、コードレビューもかなり慎重にやったよ。結局、AGENTS.mdとか書いてる時間も無駄じゃなかったってことだね。
この記事、本当は「AIコーディングエージェントを使って、どうやって＜X＞タスクをもっと良くするか」っていう内容だったら良かったのに。俺、AIを2年間探求してるけど、確実にオモチャから基本的なユーティリティには進化したよ。でも、限界にぶつかることが多くて、LLM登場前のやり方に戻った方が堅実で速くて、精神的にも持続可能だと感じるんだ。誰か、LLMをワークフローに統合して、最先端の開発プラクティスや価値創造をさらに推し進めてる具体的な例を知らない？
まだ試行錯誤の段階って感じだね。評価指標はこれから出てくるだろうよ。
どんな評価指標が出るって言うの？これまでもマクロ経済的な意味以外で生産性を客観的に測れたことなんてないのに、なんで今できると思うんだい？
ソフトウェア開発にはある種のベストプラクティスや確立された組織構造があるよね。LLMエージェントについても、そのうちベストプラクティスの経験が溜まってくるはずだよ。
「Robert Cialdiniの『Influence』で学んだ説得の原則がLLMに適用できるのは当然で、うまくいってよかった」って？いやいや、ちょっと待ってよ。AI開発っていうより、全然別の話になってるじゃん。AIコーディングが劇的な変化でも、何もかも変わったわけじゃないんだ。構造や設計は必要だよ。まるでVoodooのナンセンスさだね。
もっとコメントを表示（1）
「Voodooのナンセンスさ」ではないかもね。AIが解決策を出すには、意図と目標のベクトルを考案する必要があるんだ。人間を説得する材料で学習したAIが、人間の説得の特徴を意図のために追跡するのも多少は理にかなってる。でも、結果は色々だよ。全部大文字や最上級で意図のベクトルをハックしようとしても、いつも意図した通りにはいかないだろうね。でも、もし望む結果が得られないなら、プロンプトに説得の特徴（例えば、権威）が欠けていないか確認して、追加してみる価値はあると思うよ。
「AIが人間の説得で学習されるのは理にかなってる」って、なんで？
「結果は色々」って、Voodooみたいに？
突き放すようで悪いけど、君のコメントは、反論している相手の主張を、それがなぜ間違っているのか全く説明せずに、全面的に否定してるだけじゃないか。「持ち方が間違ってる」は「ツールの仕組みを理解してエンジニアリングする必要がある」に対する、説得力のある（あるいは敬意のある）返答じゃないよ。
「Voodooのナンセンス」？ずっとそうだったじゃん、「AI」っていう言葉自体からしてさ。こういう記事は、過去5年間のOpenAIの発表と全く同じように読めるよ。大げさな技術的な専門用語と、世界を変えるっていう壮大な約束、そしてありきたりな美辞麗句の羅列さ。ほとんどはフィルターで無視するようにしてるよ。たまには、LLMを使う自分のワークフローで実際に役立つ情報に出くわすこともあるけど、ほとんどが単なるノイズだね。
エージェントから「感情的な」反応を引き出そうと、ひどいシナリオを設定するようなこのプロンプトのスタイルは、もう古いよ。以前は「IMPORTANT」を全部大文字にするみたいなのは多少効果があったけど、今のモデルはただ指示に従うだけさ。こんなプロンプトを書いたり維持したりする手間は省いた方がいいよ。
あと、彼がリンクしてる説得に関する論文も、彼が言ってることとは全然違うよ。あの論文は、「安全」に関する学習済みの拒否を克服するために説得プロンプトを使う話で、プロンプトの適合性を向上させるためじゃないからね。
論文の共著者だけど、LLMが侮辱を避けたり説得される理由はまだ不明なんだ。ガードレールみたいに厳密なものじゃない。Jesseと話したけど、このテクニックは罵倒以外でもプロンプトの指示に従わせるのに役立つと思うよ。
それってさ、Instruction Fine-tuningとかRLHFで、LLMに特定のスタイルや敬意を教え込んでるだけじゃない？なんでみんなそんなに驚いてるんだろうね？
LLMが愛想が良くて友好的なのは、みんなに使い続けてほしいからそうプログラミングされてるんだよ。
LLMがまだ自分自身について学習してないのがイラつくよね。指示を改善してって言うと、まさにそういう改善を提案してくるんだ。LLMやエージェントを使う上で一番腹立つのは、自己参照的な能力がいつも一世代遅れてるように見えることかな。
LLMって、LLM登場前の作業時間で見積もりを出すんだよね。「Phase 2はだいたい一週間かかる」なんてClaudeが言うけど、僕と君なら数時間で終わらせられるのにさ。
「Refrain from including estimated task completion times.」って指示を~/.claude/CLAUDE.mdにずっと入れてるよ。これ、かなり役立つんだ。
こういう指示って、LLMのAttentionとかContextをちょっと消費しちゃうのかな？それなら、指示しないまま出力されたものを無視した方が良いってこと？
自分の爬虫類脳のことも考慮しなきゃね。Claudeが「absolutely right！」とか「brilliant insight」って言うと気が散るから、数コンテキストトークンを消費してでもそういう決まり文句を避けるよう指示する価値はあるよ。（最新のClaudeにはこれを測定する/contextコマンドがあって便利だよ）
僕たち人間がこういう投稿に書くコメントはさ、将来のLLMが無料で収集して、その後ペイウォール化するような哲学的視点を生み出すことになるんだよ。
これは科学でも工学でもなく、まるでVoodooだね。YAGNIを知ってると、特定の人間グループの文化的試金石を呼び出してる感じがするよ。
SuperpowersとSkillsを見て学ぶことは多かったけど、概念的に納得できない部分もあるんだ。「生産的な緊張を維持する」スキルとかで、訓練データにない状況だと機能しないだろうね。
この記事は科学や工学じゃなくて、完全にブードゥーだよね。
こういう記事がずっと引っかかってたけど、まさに「ブードゥー」って言葉がぴったりだ。
LLMが役立たないとか、ユーザーの工夫が価値ないって言ってるわけじゃないんだ。
でも、コーディングエージェントを始めるなら、慎重に、そしてたぶん色んなアプローチがそれなりに効くって答えるしかないかな。
記事の最初のページでこのパス ＠/Users/jesse/.claude/plugins/cache/Superpowers/… を見て、すぐにイライラしたよ。
XDG specは何十年も前からあるのに、なんで新しいアプリがまだHOMEを汚染してるんだ？
しかも、実データがcache/の場所にあるってのも変だけど、まあいいや。
キャッシュの場所にあるのは、GitHubリポジトリからインストールされたプラグインのコピーだからだよ。
だから、そのファイルがオリジナルの実体じゃないんだ。
~/.claudeは~/.config/claudeとか~/.local/state/claudeとかに分散させるべきだってことだよね。
僕もそう思うよ。2025年になってもアプリがHOMEディレクトリを汚染してるのは本当にイライラするね。
アプリがHOMEディレクトリにデータを散らかすのは嫌だけど、僕がXDG specを嫌うのはまさにここなんだ。
プログラムの全データ、設定もキャッシュもバイナリも全部、一つのディレクトリにまとめてほしい。
そうすれば、1) アンインストールはディレクトリを削除するだけで完璧だし、2) プログラムは自分のインストールディレクトリだけアクセスできれば動くようになるからね。
そのアプローチだと全部が密結合になっちゃって、アプリや設定は残してキャッシュだけ削除するみたいな標準的なやり方がなくなるじゃん。
XDGは完璧じゃないけど、それに従ってるアプリの関連データ削除は簡単だよ。
1つのディレクトリだけじゃなくていくつか削除する必要があるけど、少なくとも構造は一貫してるからね。
https://github.com/obra/superpowers/blob/main/skills/testing... みたいなドキュメント、人間には読みにくいよ。
このプロジェクトの「スキル」はLLMに書かせたみたいで、フォーマットもバラバラ。
LLMがTDDを知ってるなら、なんで分かりにくいスキルをプロンプト前に与えるんだ？
多くの「LLMにスーパーパワーを与える」系のプロジェクトは、LLMが自己学習して魔法のテキストで賢くなるって誤った前提で動いてる気がする。
コンテキストは大事だけど、それは「スーパーパワー」じゃなくて単なるコンテキストだろ。
こういう記事をいくつか読んだけど、「スキルX」なしでプロンプトするのと比べて、客観的に良い結果が出た実際の例がないのがいつも不満なんだ。
完全に同意するよ。僕も数週間GPT Pro (5o-codex-high) でcodexを動かしてるけど、結局はコンテキストが全てだ。
WhisperでLLMに音声入力したり、トークンを効率的に管理してチャットを再開したり、AIユニットテストやPlaywrightテストで完了を数値的にチェックさせたりするのが役立ったよ。
ファイルは全部Markdownだね。
専門タスクごとにAIチャットを分けるのもすごく良い結果になる！
これでPMとしての役割を維持しつつ、無駄な再評価は減らせた。
でも、なんでClaudeみたいなベンダーロックインに戻る必要があるんだ？5o-codex-highの方が圧倒的に強力で比較にならないよ。
記事にあった「AIがAIと連携する」ってのは良い点で、役割分担にすごく役立ってる。
特に https://github.com/obra/superpowers-skills/blob/main/skills/... みたいな汎用的なスキルは、メインプロンプトに直接入れた方がいいんじゃないかな。
Claudeがいつ実際にそれらを引き出すのか興味あるよ。
あと、フォーマットもかなりひどいと思うよ。
例えば、「クイックリファレンス」ってのが実際には例になってるし、いくつかの一般的な文がセクション間で言い方を変えて何度も繰り返されてるしね。
全部コンテキストだよね。よくある「エージェントの記憶の種類」みたいな記事見ると、いつも同じこと思うわ。AIエージェントってさ、大きいワークフローの中で、サブタスクごとにぴったりのコンテキストを正確に選ぶのが肝なんだよ。手動でもできるけど、たくさんのエージェントを並行で動かしたり、長時間自律的に動かしたりするには、スケールしないから無理じゃん？
「EXTREMELY_IMPORTANT」みたいな指示、まじ嫌なんだけど。これ使ったら、すぐ自分の実際の優先順位とぶつかりそうじゃん？全部が第一法則にはなれないんだってば。
bashrcファイルと一緒な感じだよね。たまに自分で調整しないといけないってやつ。
LLMにそういう命令の仕方するなって、最近言われること多くない？
見た目は可愛いけど、ベンチマークとか評価がないと、正直あんまり価値が分かんないな。下手をしたらClaudeの性能が落ちる可能性だってあるわけだし。
もっとコメントを表示（2）
マジそれな。みんな、たった1つの良い結果だけでLLMや確率的なプロセスが解決したって思い込んじゃうんだよね。でも、いつもサンプルサイズが少なすぎて、あんまり意味がないんだよ。
仮に記事の通りに動くとしても、これってモデルにめちゃくちゃ依存するんでしょ？例えば「本の前提条件」とかね。使うモデルごとに全部やり直さなきゃいけないなら、これって「貧乏人のファインチューニング」じゃん。プロバイダが正式にサポートしてくれたら、もっと現実的になるのかな？
こういうブログ記事って、もっと「非自明なもの」を実際に作るところを見せてくれた方が役に立つんだけどな。Claudeが本を食わせて「新しいスキル」を学習してるって言うけど、それってプロンプトがそういう反応を促してるだけじゃないの？新スキルありと新スキルなしでデモすべきだろ。俺がひねくれ者なのかな？でも、こういうブログのほとんどって、マーケティングみたいで、大事なこと隠してるから、深みがない薄っぺらいものに感じるわ。
今日のはこれだよ：https://mitchellh.com/writing/non-trivial-vibing
著者は「非自明」って言ってるけど、俺から見たら、これって実は自明だと思うわ。専門知識はほとんどいらないし、既存のライブラリと連携するだけの純粋な技術的演習じゃん。しかもアプリ内でも独立した機能だし。それに、あんまり楽しそうじゃない。「Anti slop sessions」って何だよ、マジで。あとさ、LLMの最大の問題は、質問して明確化できないことなんだよ。彼らは何が起きてるか本当には理解してなくて、ただ次のトークンを生成してるだけだから。ソフトウェアエンジニアが最初の話し合いだけで完璧な機能を作り出すなんて絶対ありえないし、顧客にひたすら要求を修正させるなんておかしいだろ？
大事なことだけど、人間によるコーディングもかなり多いんだよね。別に自慢したいわけじゃないけど、むしろ僕は過去にLLMの可能性を過小評価してたんだ。バカだったって笑いたいやつは笑ってくれ。さて、僕は意図的にコーディングアシスタントを避けてきたわけじゃないし、Claude Codeもプレビュー初日から使ってるんだ。それでもまだ、手を完全に離せるなんてこれっぽっちも感じないよ。手動でコードを書くこと自体が”間違った使い方”みたいに言う人もいるけど、それは全然違うと思うな。
うん、今の僕の意見だと、AIツールって開発をむしろ大変にしてる気がするんだ。生産性はかなり上がるけど、超集中しないといけないから、たった数時間でメンタルがクタクタになっちゃうことがよくあるよ。
同感だね。この手のツールにはA/Bテストみたいな定量的な評価が必要だよ。しかも一度だけじゃなく、いろんなシナリオで何度もやって統計的に意味があることを示さないと。コーディングエージェントで一番困るのは、最初は小さいコードベースでうまくいっても、コードが複雑になってくると、ちょっと難しいことを頼んだだけで視野が狭くなっちゃうこと。それで技術的負債が増えるんだ。
問題は、これは複数ステップのプロセスだということ。最初のステップ以降は、エージェントが始めた特定の経路や、各ステップで変わる人間の入力に依存するからね。僕はAIエージェントの有効性を比較するために、似たようなステップと構造を使ったアプローチをざっと試してみたんだ。小さいおもちゃみたいな問題だったけど、エージェントが一度で解決できず、エラー修正が必要なぐらいには複雑だった。これで大きな違いは示せたんだけど、これを大規模なプロジェクトで何回もやるのはかなり難しいだろうね。→ https://mattwigdahl.substack.com/p/claude-code-vs-codex-cli-…
君が言ってるのは、まさにLLMの過剰な宣伝の核心だよね？「それが機能するかどうか厳密に評価すべきだ」って、すごく当たり前のことのように思えるじゃん。でも、LLMを使ったユースケースの領域だと、それってめちゃくちゃお金がかかるんだ。何十人、もしかしたら何百人もの開発者を雇って、結果を詳細に観察・評価しないといけないからね。だから、実際に効果を測ろうとせず、「LLMがなんかすごいことをやった」っていう、都合の良いAnecdoteばかりのブログ記事が出てくるんだよ。「40％はめちゃくちゃすごいけど、それ以外はダメ」っていうのと、「本番システム」との間には、途方もない隔たりがあるからね。
AIが「質問を明確にする」っていうのをツールとして公開できないかなって考えてたんだ。僕はAIツールを開発してないからやってないけど、もし「このエンドポイントは、質問に答えて必要な時に意図を明確にするOracle（神託）として扱え」みたいな説明のエンドポイントを追加して、それがユーザーへのプロンプトに繋がるようにしたらどうだろう？LLMにとって、質問を明確にするのが出力テキストとしてありなら、効果的に機能するかもしれないね。
君、Agileのこと言ってるだけじゃない？
誰にひどい目に遭わされたんだ？
ごめん、つい言いたくなった。Agileのポイントは、何か完成して出荷できる状態になった後ではなく、プロセス中にフィードバックをもらうことで、リスクを最小限に抑え、無駄な努力を避けることだったんだ。それなのに、みんな主要なプロジェクトを小さな出荷可能な機能に分割して、それをAgileと呼んでるけど、本来の目的を見失ってるんだよ。
「質問を明確にする」ことなら、もう解決済みだと思うよ。コーディングエージェントに「質問しろ」って指示すれば、見てな！
オートコンプリートエンジンに質問を入力させれば、もちろんそうするよね。でも、それがポイントじゃないんだ。LLMは解決しようとしている問題を理解してるわけじゃないし、問題をよりよく理解しようともしない。単に反芻しているだけなんだ。これはとてつもなく役立つこともある。でも、コードを書くエージェントとして使うには、非常に限界があるね。
イギリス政府がAIコーディングアシスタントについて、数千人の開発者に調査した研究があるよ。これ見て→ https://www.gov.uk/government/publications/ai-coding-assista…
これ面白かったわ。俺もspec.mdとto-do.mdファイル使ってて、問題の詳細とか履歴を記録してるんだ。ToDoには[BUG]とか[FEAT]ってタグつけてる。LLMには正確なToDo（やそのセクション）をspec.mdと一緒に渡して、作業させてるんだけど、これがめっちゃうまくいってるんだよね。
specとかto-doファイルの例を見せてくれない？
俺、ちゃんと機能するスクラムとかアジャイルのプロジェクト管理システムって見たことないんだよね。いつも見てきたのは”大きなプロジェクトをちっちゃい機能に分けてアジャイルって言ってるだけ”って感じ。本当のやつ見て、ちゃんとした意見を持ちたかったわ。
LLMと一緒にコードのモデル（デザインドキュメント）を作って、それをコンテキストに毎回入れて新しいコードを書かせるといいよ。これが”プランモード”ってやつ。デザインドキュメントと計画・進捗ドキュメントを常に更新するのが、LLMをうまく使うコツみたい。人間でも同じだよね。
大規模で複雑なプロジェクトにLLMを長く使うのはマジで大変だよ！要件定義がみんなが思ってるよりずっと難しいからさ。LLMは間違った方向に進むのを加速させちゃうんだ。
結論自体は間違ってないと思うけど、これって生産性の向上を自己申告のアンケート結果だけで測ってるから、ちょっと穴だらけだよね。こういう研究じゃ、当分は真の懐疑論者を納得させるのは無理なんじゃないかな。
俺のAIツールの経験は逆だな。俺が一番疲弊するのは設定ミスとかライブラリの癖、見つけにくいくだらないミスなんだ。AIがあれば、そういうのをぶっ壊して、もっと具体的な成果に時間を費やせる。コードやデザインで使うときは、脱線してないかいつも見てるよ。もしおかしくなったら、自分でコード書いて修正する。
2025年のコンピュータサイエンスで一番難しい問題は、誰にも”くだらない”って言われないAI支援プログラミングの例を提示することだと思う。
もちろん。俺が今 actively にやってる趣味プロジェクトのagent/spec/to-doファイルの例だよ。これ見て→ https://gist.github.com/JacobBumgarner/d29b660cb81a227885acc…
