- AIが生成した複雑なコードの大量生産が広がり、人間が読まないコードを作る現象が業界全体に拡散している
- 経営陣はAIによる人員削減を正当化し、開発者はAIが作ったコードの比率を満たすよう圧力を受けている
- このような「バイブコーディング」は、**ギャンブルの依存メカニズムに似た「ダークフロー（dark flow）」**状態を引き起こし、生産性の錯覚を生む
- 実際にAIコーディングツールの使用時には、生産性が20%向上したと感じる一方で、実際には19%遅くなるという研究結果がある
- AIは有用だが、人間の思考・創造性・ソフトウェアエンジニアリング能力は代替されず、それを手放すとかえって後退する危険がある
バイブコーディングの拡大と問題認識
- バイブコーディングはAIが生成した複雑なコードを大量生産する行為で、人間が読んだり保守したりしにくくする
- 一部企業は、AIが人間の仕事を代替できるとして解雇を正当化している
- 開発者は、AI生成コードの比率を満たせなければ人事評価で不利益を受けるという圧力にさらされている
- 学生も会社員も、「AIがまもなく自分の仕事を代替する」という不安の中で自己研鑽をためらう現象が起きている
- AIは実際に有用だが、バイブコーディングには注意が必要であり、使い方を誤ると否定的な結果を招く
「フロー」と「ダークフロー」の違い
- 心理学者Mihaly Csikszentmihalyiが定義した「フロー」は、挑戦と技能が均衡した没入状態
- 一方で、ギャンブルのように技能と無関係な活動でも没入感は生じうるが、これは**「偽のフロー」**に当たる
- スロットマシンのLoss Disguised as a Win (LDW)の事例のように、実際には損失でも勝ったかのような錯覚を誘発する
- 研究によれば、LDWは実際の勝利に似た生理反応を引き起こし、依存的な没入を強める
- このような現象は**「ダークフロー（dark flow）」または「ジャンクフロー（junk flow）」**と呼ばれ、成長を伴わない依存的な没入を意味する
バイブコーディングとギャンブルの類似性
- 開発者Armin Ronacherは、AIコーディングツールを使った後、大量のコードを作ったが実際にはほとんど使えなかったと述べている
- これはギャンブルにおける**「偽の勝利」**と似た錯覚の構造だ
- バイブコーディングは次の点でフローの条件に反している
- 成果に対する明確なフィードバックが欠如し、むしろ誤った達成感を与える
- 挑戦水準と技能水準の不均衡
- 統制の錯覚によって、利用者が結果を操作していると信じ込ませる
- AIが生成したコードの品質は、数週間後になって初めて問題が認識されることが多く、バグや保守不能な複雑さが後から露呈する
- LLMとスロットマシンはいずれも、利用者の心理反応を最大化するよう設計され、継続使用を促す
生産性の錯覚と「信頼できない語り手」
- METRの研究によれば、AIツールを使った開発者は20%速くなったと感じたが、実際には19%遅かった
- これは知覚された効率と実際の効率の間に40%の差があることを意味する
- AIで書かれた文章も、見た目は似ていても品質が低い場合がある
- あるAI研究者のブログ記事は、AIで書かれるようになった後、以前より読みにくい文体へと変化した
- 人は自分の生産性を客観的に評価しにくく、AI使用後に過大評価する傾向がある
外れ続ける予測とキャリア上のリスク
- AIがコーディングを完全に代替するという予測は繰り返し外れてきた
- Geoffrey Hintonは2021年までにAIが放射線科専門医を代替すると予測したが、実現しなかった
- GoogleのSundar PichaiとJeff Deanは2023年までにすべてのデータサイエンティストが自動ニューラルネットワーク設計ツールを使うと述べたが、実現しなかった
- AnthropicのDario Amodeiは2025年末までにAIが全コードの90%を書くと予測したが、根拠はない
- このような誇張された見通しに従って自分の技能開発を止めるのは危険だ
- AIの進歩速度は実際以上に継続的に過大評価されてきた
人間の思考と創造性の継続的な重要性
- AIコーディングエージェントは文法的に正しいコードを生成するが、
- 有用な抽象化、モジュール化、コード構造の改善は行えない
- つまり、コーディングは自動化されても、ソフトウェアエンジニアリングは自動化されていない
- AIが生成するテキストも文法的には自然だが、思考を精密に磨いたり核心を捉えたりはできない
- Jeremy Howardは「AIに思考を完全に委ねると、学習し成長する能力を失う」と警告する
- AIは道具として有用だが、人間の中核的な能力を代替するものではない
6件のコメント
人の業務能力を評価する際には、『態度』という要素があります。業務指針や上司の命令だけでなく、自分自身が仕事にどう向き合うかという姿勢が重要です。その態度は、業務に対する継続的な関心や洞察、責任感として表れます。中でも責任感が重要です。人工知能は他のことはまねできても、責任感はありません。人工知能は成果物を評価することはできても、プロセスにおける責任感を評価することはできません。
人工知能は『どのように（How）』はよく理解していますが、『なぜ』それをすべきかは分かっていません。仕事の根本的な目的を見極めようとし、試行錯誤をいとわず新しい道を探ろうとする探究心と、目的に向けた方向性を決めることは、人間にしかできません。責任感とは結果だけを追い求めることではなく、その過程で目的を見失わず、継続的に問い、探究する姿勢のことです。
マニュアルや指示以外の方法を創造的に見つけ出す能力も、責任ある姿勢から生まれます。
とても共感します。
Hacker Newsの意見
今は前者のほうがはるかに危険だと感じる。もっともらしいが間違ったバグ、行き止まりのアーキテクチャ、セキュリティ問題、コードへの当事者意識の低下、学習機会の喪失などがある
一方でAIをあまり使わないと生産性は落ちるが、コードベースへの深い理解と訓練が長期的にはより大きな資産になるかもしれない
個人的には、コードの中で自分でぶつかりながら得る創造的なアイデアが最も価値があると思う
AIに早い段階で任せすぎると、こうした機会を失うのが惜しい
反復作業が減るので頭が疲れにくく、難しい問題に集中できて、より良いアイデアが浮かぶ
核心は良いセンスと基準を維持することだ
事前に設計と文書を細かく準備しておくと成功率が高かった
コード生成そのものより、計画と設計の段階こそが本当に難しい部分だ
その一方で、LLMによるドキュメント化やボイラープレート作成は大きな時間節約になる
アプリを一気に完成させようとする人もいれば、単なる自動補完レベルでしか使わない人もいる
新しいやり方が次々に現れるので、開かれた心でさまざまな試みをしてみるのが最善だ
新しい技術は常に小さな単位で検証し、段階的に拡張するのが定石だ
AIの使用量は「検証済みの分だけ」が正解だ
こうした議論をパスカルの賭けのように持っていくのは悲しいことで、たいていは何かを売りたい人たちの論理だ
AIがうまくコードを書けたとしても、税計算の微妙な誤りのような見えない失敗モードが最も危険だ
実際の会計システムに誤った数値が静かに反映される可能性がある
だからAIは高度な自動補完ツールとしてしか使わない。アーキテクチャとドメインロジックは自分で設計し、反復コードやテストのスキャフォールディングにだけ使う
結局のところ問題は「AIが書いたコード」ではなく、自分が直接理解していないコードだ
LLMは関数を書くのは得意だが、どんな関数が必要かは決められない
実際のプロジェクトのアーキテクチャは、現実のボトルネックにぶつかりながら形作られてきたものだ
AIが助けてくれたのは実装速度だけで、構造的な判断は完全に人間の仕事だ
とくにドメインバグはLLMには絶対に見つけられない
結局、アーキテクチャとドメイン知識は人間が責任を負うべきだ
単に『コードを書け』とだけ言えば、それは目標ではないのだから、できなくて当然だ
私はこの1年間、ソフトウェア設計とVibeコーディングを同時に学んだ
DDD、Clean Architecture、Agileなどの本を学び、ずっと良いエンジニアになれた
AIを使っていても、コードへの責任は依然として自分のものだ
両方の領域を一緒に伸ばしていける
時間投資と練習は必要だが、学ぶ価値は大きく、他のスキルを置き換えるものでもない
LLMが苦手なのは高レベルの判断と構造設計だからだ
よく設計されたシステムはAIの効率を最大化する
また、新しいパラダイムの学習は、LLMが作ったコードをより良く判断し改善する助けになる
BDD、PBT、モデル検証のような手法は、AIコーディングをより安全にする道具だ
見た目には勝利のようでも、実際には敗北に偽装された勝利だった
これに対して、ある人は「その描写はまるで薬物の高揚と墜落のようだ」とたとえる
LLMをきちんと活用するには、この3つの役割すべての筋肉が必要だ
望むUI/UXを明確に描けるなら、現在のモデルでも十分に良い結果を得られる
逆に「ざっくり作って」といったプロンプトは危険だ
AIは高性能メカスーツのように扱うべきで、人間がループの中にいてこそ本当に速い
技術の進歩があまりにも速いため、昨年は難しかったことが今では些細になっている
社内で使っていたAIツールでさえ、オープンソースモデルに置き換わりつつある
今はまるで「AI版Don’t Look Up」のような時期だと感じる。誰もが手遅れになる前にAI時代に合わせて自分を再配置しなければならない
友人が3か月間Cursorで製品を作っていたが、機能ばかり多くて役に立たなかった
結局、コードを理解している人の不在が問題だった
基本的な**精神的な検証(sanity check)**すらしないのは理解しがたい
有用な抽象化、モジュール化、コード構造の改善はできていない
>> 共感します。