分かっています。まるで世界が求めていたのが、また別のLLMsやAI技術に関するブログ記事だというかのようです。それでも、私の頭の中に積み重なっていて、他ではこのように書かれているのを見たことがないことがいくつかあるので、ここに書いていきます。

ちなみに、私は自分の記事を書くのにgenAIを使っていません。ここでも、他のどこでも。これらの散漫な言葉はすべて私自身によるものです。

The tower tilts

私は最近、The Tower Keeps Risingを読み、それが私の心に残りました。

この記事は観察であり、lobste.rs上のArminによると、現状を擁護するものではありません（ただし、Arminはvibecoding企業を運営しているため、この方向性を推し進める一員ではあります）：

文脈として：私は著者です。私はこれが良いことか悪いことか、あるいはこれが今後も機能し続けるかどうかの判断を意図的に行いませんでした。これは主に、エージェントを使えば、チーム内の人々が以前なら互いに話し合う必要があった状況でも、進捗を続けられるという観察です。

Arminの投稿の要約は、実質的にvibecodedシステムがコードの上にコードを積み重ね続けているが、多くのシステムでは物事が構築され続けているように見える一方で、抽象化が積み重なり、最終的に人間にはコードベースを理解できなくなるというものです。しかし、これは新しい運用方法であり、LLMsは人間には理解できないコードベースの一部を「説明」し、構築を継続できるのです。

仮にそのようなシステムが機能し続けられたとしても、私は2つのことを感じます：1) このような状況の支持者たちは、今やこれが自分たちのシステムの最終状態であることを認める方向に転換したこと、そして2) それを前進の道として受け入れているように見えることです。

最初の点について、これは転換であることを非常に重要だと考えます。Simon Willisonは、おそらくインターネット上で最も優れたgenAI支持派のライター（時には、より弱いライターたちに擁護を与えているようにも思えますが、それはSimonの責任でしょうか？）ですが、ある時点で「agentic engineering」という用語を作り出し、agentic engineeringとvibecodingの間に明確な線を引きました：

私たちはコードを読まなければなりません。AI支援プログラミングにおける私の黄金律は、リポジトリにコミットするコードについて、他人にそのコードが何をするのかを正確に説明できない場合はコミットしないということです。

LLMがあなたのためにコードを書いたとしても、それをレビューし、徹底的にテストし、他人にその仕組みを説明できるようにしたのであれば、それはvibe codingではなく、ソフトウェア開発です。その活動を支援するためにLLMを使用したかどうかは関係ありません。

信じられないほど短い期間、基本的に1年で、Simonはかなり率直な記事Vibe coding and agentic engineering are getting closer than I’d likeを公開しました：

問題は、コーディングエージェントがより信頼性が高くなるにつれて、私はプロダクションレベルの作業であっても、彼らが書くすべてのコード行をレビューしなくなったことです。

Claude CodeにSQLクエリを実行して結果をJSONとして出力するJSON APIエンドポイントを構築するよう依頼すれば、それが正しく行われることはよくわかっています。うまくいかないはずがありません。自動テストを追加させ、文書化させれば、それが良いものであることはわかっています。

しかし、私はそのコードをレビューしていません。そして今、私は罪悪感を抱いています：コードをレビューしていないのであれば、これを本番環境で使用するのは本当に責任あることなのでしょうか？

これは素晴らしい読み物であり、Simonの誠実さと、自己反省し、以前の発言に異議を唱える意欲に拍手を送りたいと思います。

しかし、前者と後者の記事の間の時間の隔たりは驚くほど短く、わずか1年余りです。

そしてSimonだけではありません。1年前、私は「agentic engineering」に似たものが人々がすべきこと、あるいはできることであるというのが、memeticな形であったと思います。そして、多くの人がそれを認めたがらないとは思いますが、Simon自身が引き込まれたように、これらのツールを使用しているほとんどの人はagentic engineeringではなくvibecodingの方に向かっていると思います。

この結果を見る前に、なぜこれが起こっているのかを見ておくべきだと思います。

The vibe bobsled

私の知る限り、「vibe bobsled」という用語を使っているのは私だけですし、それが特に広まる用語であるとは思いませんが、私にとっては個人的に役立つものです。

Bobsleigh（ボブスレー）をご存知でなければ、これは特に奇妙で興味深いスポーツです。とても楽しいですが、あまり主体性がありません。ボブスレーに座って、氷のコースを滑り下りるだけで、本当に行く道は一つしかありません。しかし、人々はそれに熟達することができ、互いのスキルを測り合うこともできます。オリンピック競技であり、私が子供の頃に父や叔父、叔母に連れられてボブスレーに初めて触れた時のことは今でも覚えていますが、それはジェットコースターのようにスリリングで、初めての出会いで魅了されました。

しかし結局のところ、行く場所は一つしかありません。

乗り物はLLM、あなたは乗客です。そして、人々が自分の旅に対して持っている主体性は、自分が感じているよりも大幅に減少していると思います。滑りやすい坂道というだけでなく、事前に作られた旅路なのです。

シュートの頂点で、人々はこれらのツールを一種の派手なオートコンプリートとして使うつもりだと自分に言い聞かせます。降下するにつれて、アイデアを探求するためにいくつかのエージェントを立ち上げるが、自分でコードを書くつもりだと言います。次に、エージェントがコードを生成するようになりますが、心配しないでください、すべての出力をレビューします。すぐに急降下し、もはや吐き出されるコードをあまりレビューしなくなりますが、エージェントを信頼します。もしかしたらエージェントの方が自分より優れたコーダーだと言うかもしれません。そして、そこからどこへ行くのでしょうか？「もうコードすら書かない」から「もうプロンプトすらしない」へ？

プロセスのすべての段階で、問題のコーダーはコードを生成するプロセスから自分を排除し、LLMが何をしているのかを理解し、うまくやっているという信仰に基づくコード生成の取り組みに身を委ねます。しかし、この氷のシュートにそりを引きずる重力の源は何でしょうか？

それは単純です。生成はコーディングの遅い部分ではありません。理論構築とレビューが遅いのです。そして、十分に説得力のあるものは、デバッグや理解するのが非常に困難です。しかし、機械は物事を生み出すのが非常に速いのです。もし彼らの仕事をレビューするつもりなら、彼らの最も強力な特性である速度を本当に活用しているわけではありません。しかし、理論構築とレビューはプログラマーの最も重要な役割でもあります。

妥当に見えるものに問題があることを検出・レビューすることがいかに難しいかを示すために、Ka-Ping Yeeの remarkable な論文Building Reliable Voting Machine Softwareを見てみましょう。これは素晴らしい読み物であり、非常に理解しやすいものです。

「ソフトウェアの検証を難しくするものは何か」というセクションで、Ka-Pingはソフトウェアの検証を難しくする主な理由として、コンポーネントの数、複雑な相互作用、広範囲に及ぶ影響、非線形性を挙げています。注目すべきは、これらの問題はすべてLLMsによるコード生成のパターンによって悪化するということです。とはいえ、それはさておき。

Ka-Pingはモデル投票機を構築し、それが正しく動作することを私たちが知っているかどうかを検証するのがどれだけ難しいかを確認することにしました。その探求を極限まで推し進めるために、Ka-Ping YeeとDavid Wagnerは興味深い実験を試みました：

David Wagnerと私は、Pvoteに3つのバグを挿入して、レビュアーがそれらを見つけるかどうかを確認することにしました。私たちは「簡単」なバグ、「中程度」のバグ、「難しい」バグを挿入するつもりで、それぞれのバグを、内部の人間がそのバグを悪用して選挙結果に影響を与えられる可能性があるように個別に選択しました。[...]

私たちはこれらのバグをすべて単一ファイルの100行の領域、Navigator.pyの11行目から109行目に挿入し、レビュアーにはこの領域を見るよう指示しました。これは、ナビゲーターがプログラムロジックにおいて最も興味深い部分であり、レビュアーの時間が限られていることを私たちが知っていたためです。私たちがレビュアーに渡した新しいバージョンのコードには3つのバグがすべて含まれていましたが、レビュアーにはバグがいくつあるかは伝えませんでした。

Yoshi Kohno、Mark Miller、Dan Sandlerがレビューの3日目にレビュアーとして参加しました。DanはPythonに非常に精通しており、「簡単」なバグと「中程度」のバグを約70分で素早く見つけました。Yoshi KohnoとMark Millerは約4時間のレビュー後に「簡単」なバグを見つけました。レビュアーの誰も「難しい」バグを見つけられませんでした。

Ian GoldbergとYoshi Kohnoがレビューの4日目にレビュアーとして参加しました。Ian Goldbergも約2時間以内に「簡単」なバグを見つけましたが、他のバグは4日目には見つかりませんでした。

レビュアーはこのNavigator.pyの100行のセクションのバグを見つける作業に、合計で約20レビュアー時間を費やしました。

Ka-Pingは、セキュリティの脅威に深く精通している、非常に経験を積んだレビュアーのグループから選びました。Mark S. Millerは私のキャリアを通じて個人的なメンターであり、私が最も多くを学び、その研究を最も深く研究したプログラマーの一人です。私はある時点で彼とその経験について話しました。彼は、簡単なバグを見つけるのにかなりの時間がかかり、中程度のバグを見つけるのに数時間かかり、誰も難しいバグを見つけられなかったと述べました...しかし、大きな観察（私に個人的に言われたもので、論文には記録されていません）は、「バグが指摘されると、私たちは皆、それが遡及的に明らかであり、見つけるべきだったと同意した！」ということでした。

世界最高のプログラマーの一部でさえ、そこにあるはずだとわかっているバグを100行のプログラムの中で見つけるのに苦労するなら、LLMsからの出力の量を人間がレビューする希望は全くありません。

したがって、唯一の方法は、気にしないことです。各段階で、自分を排除します。あなたはそうしないつもりだと言いますが、実際にはそうします。シュートとvibeトンネルの形に身を委ね、下へ下へと進んでいきます。

Vibe sickness and the colonial settlers of the uncanny valley

「AI psychosis」という用語は、genAIの使用による貧弱な行動や結果による誰かや何らかの状態を説明するために、最近よく使われています。しかし、「AI psychosis」の元の説明は、より臨床的なものに近く、チャットボットとの遭遇によって文字通り精神病を経験し、ユーザーのことをあまりにも肯定しすぎて、現実からの妄想的な乖離の領域に引きずり込まれる人々を説明するものでした。

しかし、この世界を襲っているような一般的な不健康感を説明する何かが必要であり、私が最初にGlyphの投稿で見た最良のフレーズはこれです：

#PyConUS 2026からの帰り道。今年は非常に激しい経験でした。甘く言うつもりはありませんが、どこにでもvibe-sicknessがあり、オープンソースは大規模な持続可能性の危機に苦しんでおり、slop security PRがすべての人を圧倒しています（などなど）。しかし、多くの希望、多くのエネルギー、相互理解に向けた多くの努力、そして（私にとっては驚くべきことに）多くの感謝がありました。私自身の執筆とコーディングの両方に対する感謝も含まれます。

私は「vibe sickness」というフレーズが好きで、文字通りの精神病について話しているのでなければ、これはより良いフレーズだと思います。

Vibe sicknessはどこにでもあります... もしかしたら、私たちはvibe epidemicの瀬戸際にいるか、あるいはすでに経験しているのかもしれません。誰もがslopについて不満を言っていますが、これらのツールを使っている人は、自分の出力をslopと自称したがりません。しかしslopはどこにでもあり、日常の経験に感染しているようです：地元のレストランの食べ物のポスターで、妥当だが理解不能なデザインのもの、崖から突き落としたくなるヘルプデスクのサポートチャットボット、年齢確認コード、そしてオープンソースプロジェクトのメンテナーであれば、slop issuesとpull requests。

問題は、これらのツールはあることには役立つが、「genAI」という用語は、それが最も苦手とするものを正確に指しているということです。問題を発見することについて話すなら、それは別の話です。しかし、成長し、揺れ動くタワーの品質の問題を脇に置いても、それがどのように構築され、構成され、維持されているのかを理解していないという問題が出てきます。

これらすべてで最悪なのは、あなたがオプトアウトできないということです。同僚やオープンソースの貢献者が、「寛大な貢献」として、絶対にslopで、提出した人には理解されていないものを送ってきます。あなたはそこに座って、これがLLM生成かどうかを尋ねるのが失礼かどうか、あるいは問題やPRに対応しようとすることで、間接的にエージェントとやり取りすることで、無意識のうちにvibecodingワークフローのユーザーになってしまうかどうかを解析することになります。

逃げられません。

Glyphの言葉を引用します：

LLMを含むソフトウェアの使用を拒否することでLLMに抗議することは、テトラエチル鉛をガソリンに混入させることに抗議するために、誰もが車に混入するのをやめるまで呼吸を拒否しようとするようなものです。だから私は、私がおそらくこれを受け入れるような個人的な道徳的線を引いています。

しかし、これを大量の気化した鉛を吸い込むことへの興奮と勘違いしないでください。

よく言ったものです。その間、uncanny valleyは私たちの世界を植民地化し、それを自分自身のものに変えています。

しかし、私たちの足元や壁の中に腐敗が広がっており、私たちの世界は誰も理解していないシステムに置き換えられています。そして、これから回復するのがどのようなものになるのか、私たちがまだ認識していない代償を支払うことになるのではないかと、私は恐れています。このため、現在のgenAIのことに関与しないことを選択するプロジェクトには、敬意を払う傾向があります。

しかし、おそらくあなたは問題を助けることからオプトアウトすることはできません。あなたの仕事はそれを許さず、あなたは何らかの状況に陥っています... 私は判断するつもりはありませんが、視点を述べて終わりたいと思います。

時々私は車の乗客として座り、道路を自転車で走っている人に腹を立てている車の運転手を見ます。それは気分が悪いものです。なぜなら、私も時々道路を自転車で走るし、十分なインフラがなければ、自転車に乗る人は道路の脇に駐車された車のドアにぶつかるリスクがあり、せっかちなドライバーに押し出されるからです。

私も運転します。運転していて、前方に自転車がいるとき、私は立ち止まって、世界が死にかけている中で、彼らの存在に感謝し、自転車に乗る人がより安全に参加できるように地形の形を変える方法について考える瞬間を持ちます（それは私もより簡単に運転できるようにするでしょうし、可能なら自転車を選べるようにもするでしょう）。

私たち自身を見捨てず、より良い世界を築くことに参加する能力への信頼を失わないようにしましょう。