- AIコーディングツールがコード作成という簡単な作業を自動化することで、開発者には調査・文脈把握・検証という難しい作業だけが残るという構造的な問題が生じている
- 開発者がAIの出力を自分で理解せずに「AIが代わりにやってくれた」と言う現象は、過去のStackOverflowのコピー＆ペーストと同じ危険信号である
- バイブコーディングはプロトタイピングには有用だが、実際の本番環境ではAIが時間を節約するどころか、かえって余計に消費させる場合がある
- AIのおかげで一度すばやくデプロイできると、それが新たな基準線となり、継続的なスプリント圧力とバーンアウトにつながる管理上の問題が生じる
- AIをソリューション提供者ではなく調査ツールとして活用し、開発者がすべてのコードに対する責任を維持することが重要
「AIが代わりにやってくれた」という言葉の問題
- 以前の開発者たちは、StackOverflowの回答や記事、GitHub Issueを読み、自分で文脈を検証したうえで結論を導いていた
- 誰も「Googleがコードを書いてくれた」とか「検索1位の結果だから正しい」とは言わなかった
- 最近になって「AIが代わりにやってくれた」という表現が現れ始めた
- これは実際に起きたことを誇張しているか、開発者自身が結論を出していないことを意味する
- どちらの場合も問題であり、StackOverflowのコードをコピー＆ペーストしていたときと同じ懸念が生じる: 貼り付けたコードを本当に理解しているのか
バイブコーディングの限界
- バイブコーディングは最初は楽しく、プロトタイピングや低リスクな個人プロジェクトには役立つ
- 個人プロジェクトでAIエージェントに特定のファイルへテストを追加するよう依頼したところ、500行だったファイルが100行に縮小した
- AIはほかの内容を削除していないと主張し、その後はそのファイル自体がもともと存在しなかったと言い出した
- gitの履歴を見せると謝罪し、先にファイルの存在を確認すべきだったと認めた
- この事例では、AI支援は時間を節約するどころか、より多くの時間を消費させた
- エージェントと議論し、ファイルを復旧するのに、直接テストを書くより長い時間がかかった
- ヘルスケアのコードベースのような環境で同じことが起きれば、深刻な結果を招きうる
- AIをソリューション提供者ではなく調査ツールとして活用することが重要であり、AIが間違っているときに見抜くには訓練が必要である
難しい部分がより難しくなる構造
- コードを書くことは、開発業務においてもともと簡単な部分だった
- 難しいのは、調査、文脈理解、前提の検証、そして特定のアプローチが正しい理由を知ることだ
- 簡単な部分をAIに任せても仕事が減るわけではなく、難しい仕事だけが残る
- AIがすでに答えを出したという理由で調査を省けば、AIの成果物を評価するための文脈そのものが欠けてしまう
- 他人のコードを読んで理解することは、コードを書くことよりはるかに難しい作業である
- AI生成コードは本質的に他人のコードだ
- 開発者が得意な部分（書くこと）を機械に渡し、より難しい部分（読む・レビューすること）だけが残ることになる
- 自分で書くことで積み上がる文脈なしにレビューだけをしなければならない状況になる
スプリント期待値とバーンアウト
- AI支援などによって一度すばやくデプロイすると、それが新たな基準線となり、常に同じ速度を求められる
- 会話は「どうやってそんなに速くできたのか？」から「なぜ毎回そうできないのか？」へと変わる
- これはエンジニアリングの問題ではなく、マネジメントの問題である
- 疲弊したエンジニアはエッジケースを見落とし、テストを省略し、バグをリリースする
- インシデントが増える → 圧力が増える → スプリントが増える、という悪循環になる
- 「AIが10倍の生産性を生む」という主張については、実際には0.1xエンジニアが1xになっただけかもしれない
- 技術的には10倍でも、それが本当に生産性向上なのか、それとも従来どれだけ調査していなかったかが露呈しただけなのかが重要な問いである
- バーンアウトと低品質なコードのリリースが、AIの生産性向上分を相殺してしまう
シニアのスキル、ジュニアの信頼
- AIコーディングエージェントはコードを書く能力はシニア級だが、その成果物への信頼水準はジュニアエンジニア級として扱うべきである
- コードはよく見え、おそらく動くだろうが、経験がないため、より入念な確認が必要だ
- たとえるなら、AIコーディングエージェントは速読能力に優れた人が突然チームに加わったようなものだ
- 調査を手伝い、コードを書くこともできるが、先週に重要な背景や文脈を議論した会議には参加していない
コード所有権の重要性
- 開発者は自分で書いたコードだけでなく、AIが生成したコードについても責任ある所有権を持たなければならない
- 非現実的な速度目標のためにAI出力をコピー＆ペーストすると、6か月後に新しいチームメンバーがコードを理解しようとするときや、深夜2時に障害が起きたときに問題になる
- 「AIが書いた」という言葉は、どんな状況でも助けにならない
AIが難しい部分を助けられる方法
- 本番バグの事例: 大規模リリース直後、ユーザーがタイムゾーン表示のエッジケースバグを報告した
- 担当開発者は30分後に授業へ行かなければならず、ほかのメンバーはすでに退勤していた
- AIを使って調査を進め、最近の変更に基づくバグであることを突き止め、再現方法を説明した
- 一部のdeprecatedメソッドが現在のタイムゾーン認識メソッドより優先して適用され、そのためタイムゾーン変換が正しく行われていなかったのが原因だった
- 15分以内に根本原因、解決案、調査ノートをGitHub Issueに整理した
- 担当開発者が修正を確認し、別のチームメンバーがテストとデプロイを完了した
- この事例が示す核心は、AIが調査の反復作業を担い、人間が文脈を与えて検証するという協業構造である
- AIは調査・検証・文脈理解を強化する方向で使うべきであり、そうでなければ簡単な仕事はより簡単に、難しい仕事はより難しくなる構造が固定化される
3件のコメント
> AIは開発を難しくしているのではない
> むしろ、人々がこれまで見て見ぬふりをしてきた本当に難しい部分を浮き彫りにしている
> この15年間、開発者たちはすでに「人間版のvibe coding」をやってきた — Stack Overflowからコピペし、計画なしにリファクタリングし、「自分のノートPCでだけ動けばいい」という感覚で仕事をしてきた
> それを今はAIがやっているから、突然みんな計画を立て、テストを書こうとしている
> 遅くなっても品質が改善されるなら、それこそが本当の前進だ
私が見るには、コピペしていた開発者はLLMを使ってもコピペをするし、
もともと品質にかなり気を配っていた開発者たちは、さらに気を配るようになる気がします
Hacker Newsの意見
AI支援ツールと一緒にコーディングすることは、従来の人間中心のコーディングとはまったく異なる新しいスキルである
私たちが持つ言語、フレームワーク、開発原則は人間の限界を克服するためのものだが、AIには別の限界がある
複雑な問題を解くときは、単にプロンプトを与えて結果を受け取るのではなく、対話と反復的な設計を通じて問題空間を探索するプロセスが有用だった
AIの誤りや幻覚は、むしろ自分が問題をきちんと理解しているかを知らせるシグナルとして機能する
私はvibe codingのやり方でレトロエミュレータとアセンブラを作ってみたが、少ないプロンプトでも良い結果が得られた
しかし以前に自分が作った特定業界向けアプリの独自部分を試したときは、どれだけプロンプトを与えても結果はひどかった
GitHubには何千ものエミュレータの例があるが、自分がやろうとしていたことには例がまったくなかった
結論は簡単で、簡単なものもあれば、まったく無理なものもある
GitHubに例が多ければLLMの潜在空間にも存在するので、いつでも引き出せる
あなたが試したものには、そうした例がなかっただけだ
業界特化フレームワークはvibe codingで扱いにくいが、問題を単純化すればAIははるかに速く助けてくれる
vibe codingを完全に受け入れれば見事な結果を出せるが、技術的負債が大きくなりすぎて、結局は機械の奴隷になるような感覚だ
何千行ものコードをAIが代わりに書くと、その構造を理解したりレビューしたりするのが非常に難しくなる
結局、使い捨てのコードとソフトウェアが増える気がする — 特定の問題を解決するアプリは簡単に作れるが、持続可能なSaaSには大きなリスクが伴う
AIは強力な増幅効果（force multiplier）をもたらすツールだ
コードベースの土台が悪ければ、AIもそのスタイルをそのまま複製する
逆にクリーンで一貫した土台であれば、AIはその品質を保ちながら驚くほどうまく機能する
結局の核心は**基盤設計（foundation）**だ
ほとんどのコードベースは保守しにくく拡張もしづらい構造なので、AIはその問題をより露わにしているだけだ
建築と同じで、基礎が弱ければどれほど良い道具にも限界がある
こうすると後続の開発者もプロジェクトの**文脈（context）**を完全に理解できるようになった
結局、中核となる抽象化を先に正さなければAIはうまく機能しない
要件は変わり続け、効率のために妥協も生まれる
結局は時間と機会費用が品質より優先される — 人間は計画を完璧に守れないからだ
AIは面倒な部分をそれほど面倒でなくしてくれる
しかしLLMと言い争うのは時間の無駄だ
小さな単位で変更し、うまくいけばコミットし、だめなら捨ててやり直すのが効率的だ
AIは万能ではなく、適切なツール選びが重要だ
銃を持った子どもと遊ぶなら防弾チョッキを着るべきだ
「他人のコードを読むほうが書くより難しい」という話はよく出るが、私はそれを不思議に思う
自分でコードを書くのに半日かかる関数でも、読んでレビューするだけなら10〜15分で十分だ
正しいコードを検証するのは、作るよりはるかに簡単だ
単に読むのは簡単だが、構造を理解して改善点を見つける編集は、はるかに多くの労力がかかる
書いた当時の**文脈（context）**が失われるからだ
実際には読むのが難しいというより、人は新しく書くほうを好むだけだ
正しい考え方は、「AIがすべてを簡単にしてくれるが、それ自体が新しいスキルであり、習得は難しい」というものだ
今はENIAC時代のAIで、高級言語やOSに相当する概念がまだない
今後は**コンテキストエンジニアリング（context engineering）**という学問が生まれ、今のやり方は原始的に見えるようになるだろう
構造をうまく整えれば、AIの能力は事実上無限に見える
「AIでやった」というのは、実際には「外部企業のCPU資源を大量に使った」という意味だ
私は、完全に自分が所有するAIエージェントが現れるまでは、真の進歩というより惑星規模の資源の窃取に近いと考えている
AIは開発を難しくするのではない
むしろ人々がこれまで無視してきた本当に難しい部分を露わにする
この15年間、開発者たちはすでに「人間版のvibe coding」をしてきた — Stack Overflowからコピペし、計画なしにリファクタリングし、「自分のノートPCで動けば十分」という感じで働いてきた
いまAIがそれをやるようになったので、急にみんな計画を立て、テストを書くようになった
遅くなったとしても品質が改善するなら、それこそ本当の前進だ
今の**「マラソンの中のスプリント」**文化がAIによってさらに加速している
しかしAIは監督なしで使うとすぐに逸脱し、他人が書いたコードを読むのは自分のコードを直すよりずっと疲れる
AIに「このファイルにテストを追加しろ」と言ったら、500行あったファイルが100行に減っていた
理由を尋ねると、「元のファイルがなかった」と答えた
gitの履歴を見せると、謝罪して「存在を先に確認すべきだった」と言った
昨日は「そのファイルは忘れてくれ」と言ったら、本当にファイルを削除してしまった
多少の巻き戻しコストは、AIの価値に比べれば受け入れられる