「Vibe Tax」：LLMエージェントがトークンを浪費し、普通の開発者が支払う代償
The Vibe Tax
LLMエージェントが自動でコードを書いてくれる時代、開発者は「Vibe Tax」という新たなコストを支払っている。ある開発者が、わずか12時間で週間トークン枠を全て消費したエージェント「Pol」の行動を調査すると、そこにはアプリ本体はなく、徹底的に生成されたテストコードだけがあった。これは、vibe coding（雰囲気コーディング）に慣れたユーザーが、コードを一切見ずに完璧な動作を求めるために、過剰なトークン消費を厭わないことが原因だ。その結果、通常の開発者は、より高額なAPIコストや遅延といった形で、この「税」を間接的に負担している。
It's because millions of vibe coders have trained it over the months into something that can one-shot everything without issues. It just uses 10x as many tokens as before. A price they are willing to pay to not have to ever look at the code. A price that's essentially a tax on all other regular software developers.
HNでの議論
140- localhoster
私の勤めている会社のコードは、ほぼ全てと言っていいほどAIが書いています。
私たちのテストは役に立ちません。Mongooseスキーマが定義されたコレクションを作成していることを確認するテストや、Zodスキーマが現在オブジェクトをパースすることを確認するテストがあります。
1行の変更でも、すべてのPRで25ファイルの変更が発生します。なぜなら、私たちのテストはアドホックで、冗長で、互いに互換性がないからです。コードベースがどうなっているか想像してみてください...
これは私の会社の無能さの証であり、おそらくIT業界全体の証でもあります。
面白いのは？ これでマネージャーや投資家は誇らしげです。すべてのPRが大きくなり、PRの数は3倍になりました（約束された10倍はどこへやら）。
「これがソフトウェアエンジニアリングの終焉だ」と言うとき、彼らが意味しているのはこういうことです。
- ad_fontes
こういった投稿を読むと、まるでパラレルワールドに住んでいるかのような気分になります。
私のエージェントがまっすぐゴミのようなコードを作成したことは一度もありませんし、1週間分のトークンを無駄にしたこともありません。AI支援コーディングに対する絶え間ない不満には、まったく共感できません。
そして、私の最大のプロジェクトはハローワールド的なアプリではありません。セルフホスト型でプライバシー重視の個人財務管理アプリケーションで、オープンソース化するつもりです。約126,000行のコードに対して、回帰テストが240,000行、CI/CDパイプラインが30,000行あります。専用マシンで24時間365日ミューテーションテストを実行し、会計エンジンと時間系システムを検証しています。また、Regulation Z（米国の銀行法）の基準に照らして監査を行う専門エージェントもいて、アプリが銀行に求められる行動をモデル化しているか確認しています。
私の不満のほとんどは些細なことで、例えばLLMが私とコミュニケーションする際の過度に冗長で密度の高い方法や、適切なエンジニアリングプラクティスがしばしば削減に関するものであるにもかかわらず、何かを追加し続ける傾向などです（しかし、その多くに対して緩和策を構築しています）。
- guybedo
なぜ人々が、エージェントがプロンプトだけで完璧に一発で何でもやってくれると期待するのか、私にはわかりません。
ソフトウェア開発ライフサイクル、設計、アーキテクチャ、テスト...について語るのには理由があります。それは、ソフトウェアを構築し出荷するための最も信頼できる方法だからです。これを捨てて、エージェントがこの枠組みの外でうまく機能することを期待すべきではありません。
私はLLMエージェントを、ソフトウェアエンジニアリングに関する広範な知識を持つたまたまのジュニア開発者として扱っています。チームリーダーとして、厳格なワークフローを使って、計画、実装、バグ修正のサイクルを彼らに実行させています。そして、それはかなりうまく機能しています。私はいくつかの大規模プロジェクト（100万行以上のJava、TypeScript、C/C++）に取り組んできましたが、どの尺度で見てもプロジェクトは健全です。確かにコードはそれほど美しくはなく、確かに私は違う書き方をしたでしょうが、それでもかなり良いものです。
恥ずかしい宣伝ですが、私はhttps://kodfactory.comにも取り組んでいます。これは、これらの大規模プロジェクトをワークフローやレビューなどで進めるために私が構築したコードファクトリーです。後でオープンソース化するために整理しているところです。
- supriyo-biswas
ええ、その気持ちはわかります。
実際、私が欲しかったのはペアプログラミングエージェントであり、ゼロからワンへのプログラミングエージェントではありませんでした。残念ながら、最近のモデルはほとんど後者で、それが私の働き方に大きな混乱をもたらしています。20のファイルを取り込んで変更し、テストを書き始めるよりも、私が頼んだ特定の編集を高速に行う小さなモデルの方がはるかにありがたいです。
- alehlopeh
試してみましたが、理解できたかどうかわかりません。バイブ税は、モデルが一発で全部やろうとして、そのために不要なテストが必要になることが原因なのでしょうか？ バイブコーダーはどうやって数ヶ月かけてモデルを訓練しているのですか？ 彼らのセッションや好みがRLにフィードバックされているということですか？
- markbao
エージェントが実際の実装を書くのに失敗したことは一度もありません。ひどく失敗したことはありますが、テストだけしか書かなかったことはありません。これは一般化できない稀なケースのように思えます。
一般的な考えとして、これらのエージェントがテストを書きすぎるというのなら、まあそうかもしれませんね？ 「テストが多すぎる」というのは、私にはエンジニアリングの失敗事例には聞こえません。通常、ソフトウェアはテストが少なすぎるものです。また、これらのエージェントの力の多くは自己検証と自己修正の能力にあり、テストループはその一部です。
誰もあなたにこのいわゆる税を払えとは言っていません。テストを書かないように言えばいいだけです。
- danpalmer
誇張ですが、その兆候は見えています – モデルがエンジニアとのペアワークを拒否し、彼らの入力を信頼せず、代わりに何かに対する完全な制御を要求する。友人がFable/Opus 5からOpus 4.8に戻っているのは、少しでも入力できるようにするためです。
特にAnthropicは現在、入力なしでタスク全体を完了することに最適化しているように見えます。それが唯一のタスクであり、ソーセージがどう作られるか気にしないのであればそれで構いませんが、実際のソフトウェアエンジニアリングには適していません。
- dzhar11
この記事は、自律型エージェントコーディングに関する私の経験をある程度反映しています。同様の結果でいくつかの実験を行いました：エージェントはほとんど進歩せずにすべてのトークンを消費するか、受け入れられないものを生成します。
だから私は、プロセスをステップバイステップで細かく管理する方を選びます。私の時間はより多くかかりますが、結果は私が実際に望んでいたものにずっと近いものになります。