AIに丸投げで本体の2倍近いテストコードが必要に 海外で「バイブ税」論争
姉妹サイトの新着
AIに「こんなアプリを作って」と指示するだけでコードが出てくる、いわゆるバイブコーディング。海外のブログ記事「The Vibe Tax」は、実際には本体コードをはるかに上回るテストやCI/CDが必要になり、その分の"税金"を払わされているのが実情だと指摘した。Hacker Newsでは、この"税金"は仕様書を先に書けば防げるのか、それともAIエージェントの宣伝文句自体に問題があるのかを巡って意見が割れた。
バイブ税
出典: insufferable.dev / 元記事はこちら
読んでみたけど正直よく分からない。『バイブ税』ってつまり、モデルが一発で全部やろうとするせいで余計なテストが必要になるってこと？ あと『バイブコーダーが何ヶ月もモデルを鍛えている』ってどういう意味？ セッションの好みがRL（強化学習）にフィードバックされてるとか、そういう話？
これって両立しない目標だと思う。・開発者は自然言語でアプリを説明して、あとはAIに任せて寝ていたい・でもその同じAIには、もっとテストを控えめに書いてほしいこの人にとって『バイブコーダー』って結局何なんだろう？
情報が足りない。話の筋はいいんだけど、結局そこで言いたい全体的な傾向が何なのか、読んでいてよく分からなかった。
仕様書を作って、それを賢くないモデルに実行させればいい。それで解決。
>>16
まずAIにいくつかの簡単な要件から詳細な仕様書を作らせる。それを自分でレビューして直したい部分を修正する。それからAIにその仕様書を実装させる。新しい要望が出るたびに、仕様書もAIに更新させればいい。
まずAIにいくつかの簡単な要件から詳細な仕様書を作らせる。それを自分でレビューして直したい部分を修正する。それからAIにその仕様書を実装させる。新しい要望が出るたびに、仕様書もAIに更新させればいい。
>>16
でも賢くないモデルは、良い仕様書があってももっとミスするんじゃない？ 自己検証する能力（内省する力）が無くて、推論よりパターンマッチに頼っちゃうし。
でも賢くないモデルは、良い仕様書があってももっとミスするんじゃない？ 自己検証する能力（内省する力）が無くて、推論よりパターンマッチに頼っちゃうし。
2025年10月より前ならそうかもね。でも今は？ 全く同意できない。この投稿には何の洞察もない。
>>17
この投稿は今日公開されたばかりで、書き手は明らかに最先端モデルを皮肉ってる（『Pol』はGPT-5.6 Solのもじり）。
この投稿は今日公開されたばかりで、書き手は明らかに最先端モデルを皮肉ってる（『Pol』はGPT-5.6 Solのもじり）。
>>2
エージェントに『この問題に対する完璧なアーキテクチャを考えて仕様書に書き出せ』と明示的に頼んで、それを開発担当のエージェントに守らせれば、ちゃんとやってくれる。ただ、コーディングとアーキテクチャ設計を同時に考えるのが、コーディングエージェントには苦手なだけ。
エージェントに『この問題に対する完璧なアーキテクチャを考えて仕様書に書き出せ』と明示的に頼んで、それを開発担当のエージェントに守らせれば、ちゃんとやってくれる。ただ、コーディングとアーキテクチャ設計を同時に考えるのが、コーディングエージェントには苦手なだけ。
>>2
＞なぜみんなプロンプト一発でエージェントに完璧に仕上げてほしいと期待するのか分からないそれが最終目標だからでは？ 単純で小規模なものなら、もう到達してるし。
＞なぜみんなプロンプト一発でエージェントに完璧に仕上げてほしいと期待するのか分からないそれが最終目標だからでは？ 単純で小規模なものなら、もう到達してるし。
>>2
＞なぜみんなプロンプト一発でエージェントに完璧に仕上げてほしいと期待するのか分からないそういう売り文句で宣伝されてるからだよ。
＞なぜみんなプロンプト一発でエージェントに完璧に仕上げてほしいと期待するのか分からないそういう売り文句で宣伝されてるからだよ。
>>20
モデル提供元がそんな宣伝をしてるのは見たことないな。具体的にどんな例があった？
モデル提供元がそんな宣伝をしてるのは見たことないな。具体的にどんな例があった？
>>39
『週末の一晩でアプリのアイデアを形にできます』と宣伝しておいて、一般の人が頭の中で『……ただし経験豊富な開発者に監督してもらうこと』と勝手に補ってくれると想定してるとは思えない。
『週末の一晩でアプリのアイデアを形にできます』と宣伝しておいて、一般の人が頭の中で『……ただし経験豊富な開発者に監督してもらうこと』と勝手に補ってくれると想定してるとは思えない。
>>4
それって、初期のCursorがやろうとしてたことじゃなかった？
それって、初期のCursorがやろうとしてたことじゃなかった？
>>4
だからこそ、もっと優れたZetaモデルが出てくれたら本当に嬉しい。
だからこそ、もっと優れたZetaモデルが出てくれたら本当に嬉しい。
>>4
小さく明確に定義したチケットを書いて、それをClaudeにやらせるやり方が、このタイプの作業だとうまくいくと感じてる。
小さく明確に定義したチケットを書いて、それをClaudeにやらせるやり方が、このタイプの作業だとうまくいくと感じてる。
>>27
そうそう。Matt Pocockの『skills』って仕組みがまさにそのプロセスを型にしてる……（やりすぎな面もあるけど）。
そうそう。Matt Pocockの『skills』って仕組みがまさにそのプロセスを型にしてる……（やりすぎな面もあるけど）。
>>27
それ、しんどそうなんだけど。普段のワークフローやエディタの中で具体的なタスクを渡すだけじゃダメなの？ ただでさえ嫌なチケット作成作業を、なんでわざわざ増やしたいんだろう。
それ、しんどそうなんだけど。普段のワークフローやエディタの中で具体的なタスクを渡すだけじゃダメなの？ ただでさえ嫌なチケット作成作業を、なんでわざわざ増やしたいんだろう。
>>5
家計簿アプリか。2026年版のTODOアプリだな。
家計簿アプリか。2026年版のTODOアプリだな。
>>5
＞個人向け資産管理アプリ＞本体126,000行に対して、リグレッションテスト240,000行、CI/CDパイプライン30,000行いや……それはもう、AI支援コーディングへの不満に気づけない理由として、これ以上ないくらい説明になってると思う。
＞個人向け資産管理アプリ＞本体126,000行に対して、リグレッションテスト240,000行、CI/CDパイプライン30,000行いや……それはもう、AI支援コーディングへの不満に気づけない理由として、これ以上ないくらい説明になってると思う。
>>5
CI/CDだけでどうやったら3万行も必要になるんだ……？
CI/CDだけでどうやったら3万行も必要になるんだ……？
>>31
モデルによっては、簡潔に書けと強く指示しない限り、そのうち2万8千行くらいはコメントだったりする！
モデルによっては、簡潔に書けと強く指示しない限り、そのうち2万8千行くらいはコメントだったりする！
>>20
だったら批判的思考を働かせるべきだよね。このサイトの大勢の人は、エージェントを全知全能だと期待しておいて、心を読んでくれないと『やっぱりインチキだ』って言い出す。
だったら批判的思考を働かせるべきだよね。このサイトの大勢の人は、エージェントを全知全能だと期待しておいて、心を読んでくれないと『やっぱりインチキだ』って言い出す。
>>32
それ、人間でも同じだよ！ 自分の先輩社員たちも、確認の頻度はずっと少ないのに、その分ずっとコストが高い！
それ、人間でも同じだよ！ 自分の先輩社員たちも、確認の頻度はずっと少ないのに、その分ずっとコストが高い！
他サイトの新着
>>35
それ、コードを自分で書くよりずっと面倒で回りくどいと思う。
それ、コードを自分で書くよりずっと面倒で回りくどいと思う。
>>48
だったら自分でコード書けばいいじゃん！ この投稿の人はLLMを使うことを自分で選んでるんだから。自分が幸せになる方を選べばいいんだよ！
だったら自分でコード書けばいいじゃん！ この投稿の人はLLMを使うことを自分で選んでるんだから。自分が幸せになる方を選べばいいんだよ！
>>48
面倒じゃないよ、AIが動いてる間は自分は別のことをやってるから。
面倒じゃないよ、AIが動いてる間は自分は別のことをやってるから。
>>36
いや、うまくいくよ。仕事をこなせる程度に賢くしておいて、最後に賢いモデルにレビューさせればいい。
いや、うまくいくよ。仕事をこなせる程度に賢くしておいて、最後に賢いモデルにレビューさせればいい。
>>40
それ、少なくともある程度はタスク次第だと思う。極端な話、一回動いて役に立つ結果さえ出れば、『動いてるっぽい』以上のことは気にしなくていい場面もある。
それ、少なくともある程度はタスク次第だと思う。極端な話、一回動いて役に立つ結果さえ出れば、『動いてるっぽい』以上のことは気にしなくていい場面もある。
>>40
cのやり方だけが持続可能だと思う。bみたいに、ソフトが動いているのに誰も仕組みを理解していない状態は、ビジネスの土台としてはまずいんじゃないかな。
cのやり方だけが持続可能だと思う。bみたいに、ソフトが動いているのに誰も仕組みを理解していない状態は、ビジネスの土台としてはまずいんじゃないかな。
>>42
開発者にとってチケットは悪魔の道具だが、マネージャーにとってチケットは目的達成のための単純な手段だからさ。――某ダメ上司より
開発者にとってチケットは悪魔の道具だが、マネージャーにとってチケットは目的達成のための単純な手段だからさ。――某ダメ上司より
>>50
これは『モット・アンド・ベイリー』の詭弁に見える。『うちのモデルは優秀だ』という守りやすい主張（モット）を掲げておいて、それを根拠に『だからプロンプト一発で何でも完璧にこなせるはず』という過激な主張（ベイリー）を通そうとしている。それに、誰かがそう主張しているからといって、批判的思考を全部放棄していい理由にはならない。もっとも、実際には言われているような主張はしていないのが明らかだけど。
これは『モット・アンド・ベイリー』の詭弁に見える。『うちのモデルは優秀だ』という守りやすい主張（モット）を掲げておいて、それを根拠に『だからプロンプト一発で何でも完璧にこなせるはず』という過激な主張（ベイリー）を通そうとしている。それに、誰かがそう主張しているからといって、批判的思考を全部放棄していい理由にはならない。もっとも、実際には言われているような主張はしていないのが明らかだけど。
>>58
それは論点がずれてる。問われていたのは『なぜ人々がそう思い込むのか』であって、答えは『そう宣伝されているから』。念のため言っておくと、これは自分の意見じゃない。実際、Fable 5だって条件次第では笑えるくらいひどい結果を出すし、Sonnet 5だって条件次第では素晴らしい結果を出す。
それは論点がずれてる。問われていたのは『なぜ人々がそう思い込むのか』であって、答えは『そう宣伝されているから』。念のため言っておくと、これは自分の意見じゃない。実際、Fable 5だって条件次第では笑えるくらいひどい結果を出すし、Sonnet 5だって条件次第では素晴らしい結果を出す。
この話題の背景と論点
「バイブコーディング」は自然言語の指示だけでAIにコードを生成させる開発スタイルで、今回話題になった記事は個人向け資産管理アプリの事例として、本体コード12.6万行に対し回帰テスト24万行、CI/CDパイプライン3万行という数字を示し、検証にかかる負担の重さを「税金」に見立てて表現した。
スレで意見が割れたのは、この負担が仕様書を先に書いてからAIに実装させる手順を踏めば回避できる技術的な問題なのか、それとも「一晩でアプリが作れる」といったAIエージェント側の宣伝文句そのものが期待値を過大に釣り上げていることが根本原因なのか、という点。仕様書先行を勧める声がある一方、それは結局コードを自分で書くのと大差ないという反論や、モデルの性能次第で結果の質が大きく変わるため一概には論じられないという指摘も出ていた。
読者が見落としやすいのは、挙げられている行数の数字が特定の個人開発アプリ一件の事例に基づくものであり、AI支援開発全般に当てはまる普遍的な比率として示されたわけではない点だ。
※本記事は5ch(Hacker News)スレッド「The Vibe Tax」より抜粋・要約して構成しています。
この記事のリアクション
まだコメントはありません。