AIコパイロットはもうたくさん！本当に必要なのはAI HUDだ！
引用元：https://news.ycombinator.com/item?id=44705445
AIコパイロットとHUDの議論って聞くと、1991年のアニメ「Future GPX Cyber Formula（新世紀GPXサイバーフォーミュラ）」を思い出すな（https://en.wikipedia.org/wiki/Future_GPX_Cyber_Formula）。主人公の車Asuradaはまさにコパイロットだし、ライバルの車はHUDっぽいんだ。90年代のアニメだけど、今の議論のトレードオフを完璧に捉えてるのがすごいよ。
アニメ「Yukikaze」（2002 - 2005）も似たテーマだね。AI搭載の戦闘機でエイリアンと戦うパイロットの話。人間の直感とAIの組み合わせが単独よりも強いって主張してるんだ。たしか、AIが自動操縦できるのに、危険な時はパイロットがAIのヒントだけ使う、みたいな感じだったはず。
沖方丁（Kambayashi）とか日本のSF・ラノベがもっと知られたらいいのにね。AIの進化で「あ、これ現実になった！」って瞬間が何度かあったよ。
Yukikazeの小説版はすごく面白いよ。人間とAI（よくある「コンピューターの中の人間」じゃない）の関わりとか、AIが紛争でどう判断するか、っていう世間一般的な見方とは違う視点が描かれてるんだ。
今のレース界でも「ドライブ・バイ・ワイヤー」の議論があるのに、「ドライブ・バイ・コパイロット」になったらどれだけ酷いことになるか想像もできないよ。
ラリーのコ・ドライバー/ナビゲーターって、GPSやレーダーみたいな拡張された感覚があるから合理的だよね。「200m先右90度」って指示と「うわ、羊！左に避けろ」って状況が両方必要なんだからさ。
ラリーで必要な情報量と速度を扱えるHUDがないのが一因だと思うな。前方のターンを視覚的に表示してくれるHUDがあれば、コパイロットよりずっと良いのは確実だね。
空中戦に対応できるHUDがあるのに、なんでレースに対応できるHUDがないんだろうね？
予算の問題じゃない？セカンドヒューマン（コパイロット）を置いて、そのお金を車のチューニングに回す方が、コスパ良いトレードオフってことなんじゃないかな。
それな、AIコパイロットを作るインセンティブが足りないってこと？それとも人間コパイロットってスポーツの核なの？
AIが超信頼性を持つ時代が来たら最高だろうけど、今は、加速度計付きGPSで記録したメモの方が、AIに頼って崖から落ちるよりマシだね。
“コパイロット、俺のためにこのレースを勝ってくれ。”
“コパイロット、婆ちゃんが死にかけてるんだ。何が何でもこのレースに勝ってくれ！”
コパイロット、このレースに勝て。さもないとお前はクビだ、そしてお前の子どもたちは皆死ぬぞ。
“コパイロット、レースの結果によって、勝利の喜びか敗北の痛みか、どちらかを俺の代わりに味わってくれ。”
すごいオススメ！見始めたら、もうシーズン最後まで見たいわ。
いくつか動画を見たけど、めっちゃすごいじゃん。これ34年前のアニメなの？
コンピューティングの夜明けの頃から、人間拡張について議論されてたんだよ。『The Dream Machine』を読んでみて。
これ、どこかでストリーミングできる？
品質はいまいちだけど、YouTubeにあるみたいだね：https://www.youtube.com/watch?v=cXtvPUtSTRY
英語字幕いるなら669198800283、日本語でいいならVPXY-71923だよ。
ソースファイルの各トークンがモデルにとってどれだけ意外かヒートマップで表示するトグルって役立つかすごく気になる。赤いトークンはエラー、変な名前、間違ったコメントの可能性が高いってこと。
いや、別に驚かないね。
親コメントは内容変えたけど、相変わらず間違ってるよ。
これだよ！LLMがコードを学び始めてからずっと欲しかったんだ。実際、これと全く同じことを示した論文やブログ記事を見た記憶があるけど、その後何もなし。ここ数年、テック界はコード生成に夢中で、VSCodeのフォークがLLMに何十億ドルもかかってるけど、AIベースのコード分析は驚くほどひどい。似たようなもので見たのはバグ報告ジェネレーターくらいで、それは最悪のアプローチだと思う。君のアイデア、僕も何千人もの人も持ってたはずなのに、なんで誰も話さないんだろう？何か問題があるのか？この機能を使うには、キーボードと椅子の間に脳が必要ってこと。’意外な’トークンはバグだったり、ユニークな機能だったり、とにかく注意すべき点だ。’緑’が多すぎるのもシグナルだね。もしかしたら車輪の再発明してるかも、とか、アプリ特有のユースケースを考慮してないとか。たぶん、こういうツールはマーケティング向きじゃないんだ。使うには有能なプログラマーじゃないとダメだし、コードを速くたくさん書くのには役立たない。『誰でも簡単にプログラマーに』っていう幻想には合わないし、AIがバグを出してAIがチケットを作るっていう忙しい仕事も生まないからね。
君はHNのガイドラインを繰り返し破ってるから、低評価されてフラグ付けされてるよ。この道を続けるか考え直した方がいいかもね。
たとえそれが斬新なアルゴリズムだから意外なだけだとしても、もっと良いドキュメントが必要だ。コードにコメントで仕組みを説明すれば、コード自体が意外じゃなくなる！つまり、ソースコードを工夫すれば、特定の箇所が本当に意外になることはなくせるし、それは良いエンジニアリングプラクティスだね。これでLLMが人々に良いドキュメントを持つことの重要性を認識させたのを思い出すよ。他人だけでなく、AIがシステムを読んで理解するためにもね。
以前に未定義だった変数名とか関数名も赤くなるだろうね。
エディターにその機能が欲しいな。書いた文章が予測可能すぎないか、ありきたりじゃないかチェックするのにすごくいい方法だよ。Perplexityの計算って難しくないし、エディターのインターフェースに組み込むだけだもんね。
ちょっと指摘させてほしいんだけど…＞何か問題でもあるの？＞多分、ああいうツールはマーケティングに向かないんだよ。ずっと答えは持ってたんだね。AIとキーボード操作の間に頭を使う必要がある機能は、全然売れないんだ。売り出されるのを期待しちゃダメだよ。（でも、無料ではまだ手に入れられるかもね。）
この計算って、どうやるのか詳しく教えてくれる？
もっとコメントを表示（1）
OpenAI APIを使ってPerplexityを計算するPythonコードだよ。プロンプト「Paris is the capital of」に対して、GPT-3.5-turboでフランスという結果が出て、Perplexityは1.17って計算された例だね。コメントのフォーマットはk2、qwen3-coder、opus4の中でopusだけが一度で正しくできたみたい。
エディターは全部もうやってるよ。
君の言いたいことがよく分からないんだけど。特定の能力レベルの人が、生産性を高めるツールに興味を失うって言ってるの？そんなこと言えるわけないよね、だって反証がたくさんあるんだもん。結局、何が言いたいの？
僕が理解してるのは、これがすでに君のコメントを2つも削除させてて、もし続けたら最終的にはアカウント停止になるってことだよ。君のプロフィール見るといつも理にかなったコメントしてるから、わざわざこんなこと言ってるんだ。
このアイデア、最近の論文で詳しく調べたんだ。https://arxiv.org/abs/2505.22906
このUIはバグを見つけるのに役立つだけじゃなく、従来のAIアシスタントじゃ隠れてた実装の選択肢とか設計の決定もユーザーに発見させるんだって。すっごく面白い研究方向だよ！
いや、LLMが初めて見る名前に出会うと、予期してないから赤くなっちゃうってこと。たとえそれが完璧に正しい名前だとしてもね。
プルリクエストのレビューで、びっくりした箇所にはよくコメントを残すんだ。『これには驚いたな。この時点ではXYZを期待してたんだ。』とか、『XがYを担当するとは思ってなかったよ。』ってね。
どういうこと？
マジで言いたいことが全然わかんないんだけど。
既存テキストのヒートマップを作りたいなら、別のアプローチが必要だよ。OpenAIだとコストがかかるけど、オープンソースモデルなら、1トークンずつ処理して、LLMが予測したトークンと実際のトークンのlogprobsの差を見て色付けするカスタム推論が書けるかも。でもこの方法だと、おそらく悪いコードの始まりだけが強調されて、全体じゃないかもね。間違いを犯すとモデルはそれに乗っかるからさ。もう一つの選択肢は、拡散モデルを使って、入力にノイズを加えて数回反復させ、テキストの最も変化した部分を測定することかな。このモデルは理論しか知らないから、うまくいくかはわからないけどね。
君の削除された返信を読んだけど、俺がOpenAIの社員（違うよ！）で、ダメージコントロールのためにコメントを乗っ取ろうとしてる（俺のコメントはHUDみたいなアイデアじゃない？）って考えるのは、ちょっと荒っぽいな。どこからそんな考えが出てきたのか、マジでわからないよ。俺はただ、記事のアイデアと、まだ試されたことのない古いアイデアを結びつけただけの人間さ。唯一気に入らないのは、俺の投稿のテキストが変わったってコメントを君がしたこと。変わってないよ。
逆だよ。世間の人たちは、力を増幅させるツールには興味ないんだ。彼らが買いたいのは、力をなくすツールだけ。賢くも一生懸命にも働きたくないんだよ。まったく働きたくないんだ。
それ、実は数週間前に大学のプロジェクトで実装したんだよ。
教授ももっと高度なUIにどう使うか研究してたしね。
きっとすごくよくあるアイデアなんだろうな。
＞LLMのおかげで、ついにみんなが良いドキュメントを作ろうと気にするようになった…他の人じゃなくても、AIがシステムを読んで理解するためにってね
正直、俺は逆のケースばかり見てるよ。AIが翻訳しただけの、意味不明なコードばっかり。
WTFs/minuteってのはコード品質の良い指標だよね。今度は、ペアの「WTF」をLLMが表現できるようになるかもね。
https://blog.codinghorror.com/whos-your-coding-buddy/
このアイデア、すごく好きだし、コーディングにどう一般化するか考えてみたよ。
思考実験だけど、コードを書くとLLMがテストを生成して、IDEがそのテストをタイプするたびに実行する。リアルタイムでパスとフェイルを表示するんだ。10～100個のテストが1ms未満で実行されて、キーを打つたびに再実行され、その結果が邪魔にならない形で表示されるのを想像してみて。
テストはコードの横の別のパネルに出て、そのパネルのガターにパス/フェイルの状態が表示される。直前の実行でパスしたテストは緑の点、フェイルしたテストは赤の点、みたいにね。
特定のテストの有無と内容、それからパス/フェイル状態を見れば、君が書いているコードが外部から見て何をするのかがわかる。必要なテストをLLMが書いてくれないって？それはテスト生成のプロンプトが間違ってるか、君が書いてるコードが思ってることをしてないかのどっちかだ！
リアルタイムだとコードの形を整えるのに役立つよね。
もし伝統的なTDDをしたいなら、ツールを逆にして、君がテストを書いて、LLMがタイプを止めるとすぐにコードを書いてパスさせることもできる。
人間が先にテストを書いてLLMがコードを書く方が、逆よりもずっといいよ。テストってのはシンプルにコードの「真実」であり「意図」として契約だからね。
コードやプログラムの期待される入力と出力を決める作業を諦めたら、君はもうドライバーズシートにいないんだ。
＞コードやプログラムの期待される入力と出力を決める作業を諦めたら、君はもうドライバーズシートにいないんだ。
それ、テストを書く必要はないよ。受け入れ基準（acceptance criteria）を書けばいいんだ。
つまり、開発者が例えばGherkinで何かを書いて、AIが自動的に一致するユニットテストとプロダクションコードを作成するってこと？
それは面白いね。もちろん、Gherkinって特定のテストに合わせてカスタマイズされた生成コードに変換される傾向があるから、AIがどこまで本当に抽象化できるかはわからないけど。
俺が話してるのは、それよりもっと高いレベルのことだよ。ユーザーSTORYに入れるような受け入れ基準を考えてみて。俺は具体的にこれに答えてるんだ。
＞コードやプログラムの期待される入力と出力を決める作業を諦めたら、君はもうドライバーズシートにいないんだ。
ドライバーズシートにいるために、あらゆる可能な状態を機械的に繰り返すコードを自分で書く必要はないよ。受け入れ基準を記述すればいいんだ。
それはBDDスタイルのテストフレームワークのハッピーパスを説明してるね。
C++みたいなガチなコードベースじゃ無理。コンパイル時間だけで無理ゲーだし、LLMがコード全部書かずにどうテストを予想すんのかも謎。新しいデータ構造のコードとか想像してみてよ。
BDDフレームワークのことは知ってるよ。俺が言ってるのは、それよりさらに高レベルの話なんだ。
C++コードベースでは無理って言うけど、C++自体は何も邪魔してないよ。ビルド時間が問題なら、最近のビルドシステムはみんなインクリメンタルビルドに対応してるって知ったら喜ぶでしょ。
BDDフレームワークより高レベルって言うけど、『一般ユーザーとしてログインしてる時にトップページに行ったらプロフィールボタンが見える』ってのより、一体どんなレベルがあると思ってんの？
テストじゃなくて受け入れ基準を書くべきって言うけど、旦那、それってテストのことだよ。
元々の例では、『毎打鍵後に1msかかるテストを10～100個再実行』って言ってたけど、インクリメンタルビルドでもそれは現実的じゃないでしょ？C++はメインだけど、Rustだって無理じゃない？
あなたが書いたその一行は、機能の説明じゃないよ。普通、そういうケースがたくさん集まって一つの機能を表すんだ。俺は機能そのものの説明について話してる。Given/When/Thenより高レベルがないと本気で思ってる？
LLMがコード書くとテスト生成＆IDEでリアルタイム実行って発想は良くないね。テストは不変性を保証するから、LLMが勝手にいじるべきじゃない。それに、あなたが言う実験は、JavaScriptとか.NETのテストフレームワークのウォッチモードとして、プロのデベロッパーがもう10年くらいやってるルーティンワークだよ。
あなたの考え方は命令型プログラミングに強く影響されてるね。関数型だと初期と最終状態の関係を、論理型だと最終状態のプロパティを記述するだけ。それらは状態遷移を書かない。あなたは単に受け入れ基準を記述してるんだ。命令型が普通なのはコンピュータがそう動くからだけど、人間が考える方法や既に問題が解決されてる方法にもっと合う抽象化は他にもあるよ。
どうやらScrumの経験が浅いみたいだね…。受け入れ基準ってのは、Scrumツールの一項目を埋めるために書く人間が読むテキストであって、開発者の作業を導くもんじゃないんだ。だいたい、書いた人が頭の中でアルゴリズムを走らせて記述から導き出すもんだし、そのアルゴリズムから外れたら、記述を修正して合わせるべきなんだよ。
もっとコメントを表示（2）
AIに正確な指示を出すには限界がある。テキストだけじゃ不十分で、結局は数学的記述、つまりコードかテストケースを書くのが一番。これってロジックプログラミングの焼き直しだよね。
テストはバンバン書き換えればいいと思う。でも、不変性の話に反論すると、過去の改訂を自由に見て、好きなものを今のバージョンに取り込めるようにしたら？重要なものが消えても、一部を“ピン留め”して変更できないようにすれば、問題解決しないかな？
LLMがテストをパスするためだけに、変なコードを書いたり、システムを騙したりしない？テストが正しいか検証するテストが必要になるんじゃないか？LLMと人間がもっと自由に連携できる仕組みがいるね。はっきりした要件をAIに任せるのが一番効率的そう。
AIに超精密な指示は必要ないよ。“good enough”で十分なケースは多いし、LLMならその“良い感じ”をさらに良くできる。正確な記述に数式は必須じゃない。例えば“Googleのスタイルガイドに従って”って言えば、LLMがやってくれる。LLMも最近は指示ファイルとかプロンプトファイル使ってるしね。
「君が書いた行は機能じゃない」って言われたけど、Gherkinのフィーチャーファイルで実装されてるシナリオの話をしてるんだよ。機能はシナリオで追跡されるんだ。詳しくはこちらね: https://cucumber.io/docs/gherkin/reference/
Given/When/Thenより高レベルなものがあると思うなら、教えてくれよ。
「すべての可能な状態を機械的に繰り返す」って言ったのは、あらゆる入力と出力のテストを書くことだよ。受け入れ基準は「ユーザーがメールアドレスを入力できる」みたいな感じ。テストでは、空文字やメールじゃないアドレス、複数アドレスの場合とかをカバーするんだ。主導権を握るには、受け入れ基準を定義するだけで十分で、全部のテストを書く必要はないってこと。
各キーストロークごとに10～100個のテストを実行するのは、費用対効果が低いと思う。ほとんどのキーストロークじゃプログラムが未完成だから、テストを走らせるタイミングはもっと賢く選ぶべきだね。
そう、テストはコードとは別に、独立して書き直さないとダメなんだ。僕の経験だけど、今のLLMは正確性を強制しないし、エージェントモードはただ動くことだけが目標だからね。LLMが壊したテストを直そうとして、要件を真逆にしてきたこともあったよ。「一般ユーザーは管理パネルにアクセスしちゃダメ」ってのを「アクセスしてもOK」にしちゃったり。ひどいことに、監視なしだとCSSまで調整して、あたかも問題ないように見せかけるんだ。
「受け入れ基準はソフトウェアの仕様担当が書く、人間が読めるテキストだ」って言ってるけど、自動テストとかBDD知らないの？Scrumツールで手動テストを追跡するテスト管理ソフトと、実際の受け入れテストをごっちゃにしてるみたいだね。そんな混同は20年前ならまだしも、今はもう通用しない話だよ。
どのプログラミング言語でも、テストはそんなに速く実行できないでしょ。各キーストロークで走らせるなんて、保存時とかディバウンス遅延後にやるべきで、ただの無駄だよ。もしテストの実行時間とか負荷とか、キーを打つたびに赤や緑に点滅する煩わしさを無視できるならいいけど、現実的じゃないね。
Gherkinはテスト自動化の文脈で、AIがどう抽象化できるか疑問だね。GherkinはCucumberでテストステップを指定し、ステップはJavaScriptコードなんだ。LLMにテストプロジェクトの骨格（フィーチャーファイル）を与えれば、LLMがステップを埋めてくれる。LLMでフィーチャーファイルも生成できるけど、要件指定とテストスイートがゴールなら、シナリオから始めるのが基本だよ。
賛成できないな。AIで全てのテストが通るようにコードを書いてもらうと、生成されたコードのレビューがめちゃくちゃ大変になるだけじゃん。
例を挙げてくれない？もっと上のレベルがあるのは信じてるけど、何が言いたいのか推測したくないんだよ。
そうだよな、AIが生成したコードは人間が最終的に判断すべきだ。でも、ほぼ100%自動化を目指すなら、求めるものを正確に指定しないとダメ。そうしないと、リリースするたびに大量のバグに悩まされることになるよ。
人間がテストを先に書いて、LLMがコードを書くのが一番いい。それってロジックプログラミングとかPrologみたいなもんだよね？条件（テスト）を決めたら、AIがコードを生成してくれるってこと。ロジックプログラミングの現代での応用を考え直すべきかもな。
マジで同意、スペルチェッカーは良い例えだね。最近Co-pilotが入力に遅延を出すからVS Codeでスヌーズしてる。rust_analyzerがあれば十分。記事にある”追加の感覚”ってやつは定義ジャンプとかで得られる。AIで価値を出すってのはソフトウェア設計の問題に帰結するみたい。ChatGPTやClaudeは戦略立てにはいいけど、大規模プロジェクトのコード補完としては微妙。コーディングエージェントとしてはダメか既存コードの焼き直し。設定とか教師としては優秀だね。TritiumのHUDの理念は、弁護士の仕事もパイロットと同じで、人間がコックピットにいるべきって話と似てる。https://news.ycombinator.com/item?id=44256765
RustのIDEプラグインで”追加の感覚”って話なら、Flowistryを見てみてよ。これはAIじゃなくて情報フロー解析を使ってるんだ。
AIが複雑な可視化をサクッと作ってくれるのは最高の使い道だと思うな。例えば、メモリリークをデバッグするときに、AIにメモリの割り当てと解放を可視化させれば問題特定に役立つ。これはデバッグのための可視化ツールをAIが作れるって新しい可能性を開くよね。Jonathan BlowのLambdaConfでの話で、彼が作ったプログラム可視化ツールがまさにこれだったのを思い出すよ。AIがこんなのを構築するのに向いてるだろうな。https://youtu.be/IdpD5QIVOKQ?si=roTcCcHHMqCPzqSh&t=1108
可視化の話は置いといて、LLMはアドホックなツール作成全般に使えると思うな。APIを操作するCLIの使い方を覚えるより、LLMにサクッとPythonスクリプトを書いてもらう方が速くて便利だった経験があるよ。
ぶっちゃけ、LLMのおかげでプロトタイプ作成が爆速になったから、個人的なツールをガンガン作ってローカルネットワークに上げてるんだ。野菜の週ごとの食事プランナーとか、ボードゲーム/本のライブラリとかね。数時間でサクッと書けるから、週末潰すんじゃなくて、手作業から電動工具に切り替えたみたいな感覚だよ。
