- AIコーディングツールを活用して、次第により大きな作業を任せるようになり驚きを感じたが、成果物には一貫性と構造的完成度が不足していることを確認した
- 詳細な仕様書を書いても、AIエージェントは長期的な文脈を維持したり設計を進化させたりできず、最終的にコードベース全体が不均質な断片の寄せ集めへと変わった
- コード片は個別には完全に見えても、全体としては構造的な雑さ（sloppy）と文脈の崩壊が発生した
- こうした経験の末、筆者はAIが作ったコードではユーザーの信頼やデータ保護を保証できないと判断し、自らコードを書くやり方へ回帰した
- AIコーディングは依然として有用だが、技術的負債と開発者の制御力喪失を招く可能性があり、慎重な活用が必要である
AIコーディングの初期の興奮と限界の認識
- ほとんどの利用者は簡単な作業からAIコーディングを始め、徐々に複雑な課題を任せるようになって性能に感嘆する
- しかし、ある時点を過ぎるとAIの誤りや一貫性のなさが露呈し、期待と現実のギャップが生じる
- 利用者は結果に満足できないと、自分のプロンプトの問題だと考えてさらに具体的な仕様を書こうとする
- Obsidianなどのツールを使って緻密な仕様書を作成しても、AIはそれを長期的に発展させられない
仕様ベースのアプローチの失敗
- 実際の開発では、設計文書は**発見と実装の過程で継続的に変化する「生きた文書」**である
- しかしAIエージェントは初期仕様に固定され、柔軟な修正や再解釈ができない
- 複雑な構造を扱うあいだ、エージェントは問題全体の文脈を失ったり、無理に作業を進めたりする傾向がある
- その結果、コードは見た目には完全でも、内部の一貫性と構造的な完全性を欠く
コード品質の崩壊と「vibecoding」の限界
- AIが書いたコードは部分的には素晴らしく見えても、全体としては意味のない組み合わせになる
- 筆者はコードベース全体を見直した後、その中に**「純粋な雑然さ（slop）」**が存在することを発見した
- AIはプロンプトと自己整合性には忠実だが、システム全体の調和や隣接パターンの一貫性は考慮しない
- これは、**小説の一部の段落は素晴らしくても、章全体はめちゃくちゃな「vibewriting」**に似た現象である
人間中心の開発への回帰
- 筆者はAIが生成したコードを製品として配布したり、ユーザーデータ保護に用いたりすることはできないと判断した
- 「このコードでユーザーに嘘はつかない」という決意とともに、自分でコーディングすることへ復帰した
- 自分で書くと、速度、正確性、創造性、生産性がむしろ向上すると実感した
- 単純なコード生成速度ではなく開発全体の効率を基準に評価すると、人間の優位が確認できた
AIコーディングの継続利用と警戒
- 筆者は現在も一部の作業では**LLMを限定的に活用（約40%）**している
- 反復作業や単純なコード生成には有用だが、技術的負債とコード理解の低下が蓄積する
- 長期的には、開発者がコードベースのメンタルモデルを失い、AIなしでは問題解決できなくなる危険がある
- 移動中（列車・飛行機など）には、AI依存のため生産性が0%になる状況も起こる
- 他の開発者たちは、「仕様さえうまく書けばよい」という発想はウォーターフォールモデルの再現であり、実際の開発では即興的な探索と相互作用が不可欠だと指摘する
結論
- AIコーディングは依然として強力なツールだが、システム全体の文脈と構造的一貫性を維持する能力は不足している
- 人間の開発者による直感的な判断と即興的な調整能力はいまなお中核であり、
AIは補助手段として慎重に制御された形で使うべきである
9件のコメント
バイブコーディングという概念が作られてからまだ丸1年も経ってないのに、何のSNS風の見栄なんだよマジでｗ
仕様を詰めることに力を入れる必要がありますね……。仕様を本当にソフトウェア工学で学んだFMどおりに作って磨き込み、その後はトレーサビリティを管理しながら更新して作業していくと良いです。
プロジェクトを進めながら、いつも仕様書テンプレートやプロンプトのバージョンを上げ続けているのですが、そろそろ本当にソフトウェア工学をもう少し深く勉強すべきなのかなと思うようになりました。
筆者は依然として一部の作業でLLMを限定的に活用している（約40%）
上記のように書かれているのを見ると、著者もAIを完全に捨てようという意見ではないようです。
うまく活用する方法を引き続き考えるべき段階だと思います。AIを捨てて開発するというのは、少しずつ遅れを取ることだと感じます。
この記事の筆者はすでにうまく活用する方法を実践していましたが、それでもなお、AIをさらにうまく活用する方向で悩むべきだと思います。
（まだ試行錯誤が多いだけで……）
仕様を更新してください
そうですね。フックをかけて実装が完了したら仕様を更新することもできますし、そうでなくても手動で仕様を更新するcommandやskillを追加すればいいんですが（笑）
ああ、年を取るのは嫌だ
Hacker Newsの意見
私は、AIが基礎的なことをあまりにもうまくこなす点こそ危険だと思う
学生は「AIが代わりにやってくれるから」と言って自分でコードを書かなくなり、その結果、中間段階や難しい概念を身体で学べなくなる
私はCSの教師として、学生たちに「機械ではなく、自分でコードを書かなければならない」と強調している
フォークリフトで重量を持ち上げるのは簡単だが、筋肉はつかない
学ぶ過程での苦痛こそが成長の核心だ
もちろん職場では成果物のほうが重要だが、それでも高次の思考ができる人は必要だ
応募者は理論知識は完璧だったが、自分が書いたコードの動作原理をまったく説明できなかった
結局「GenAIがほとんど書きました」と告白したが、『学んだこと』と『自分でやったこと』の乖離があまりに大きかった
コードを「どう書くか」よりも「コードがどう動くか」を教えることのほうが重要だ
昔はアセンブリ言語で直接書いていた時代もあったが、今はそれよりコンパイラの原理を理解するほうが価値がある
実際、ほとんどの人はコンパイラやOSを自作することはないが、その原理を知ることはプログラミング言語の限界を理解する助けになる
コンパイラが初めて登場した時にも同じ議論があり、結局私たちはより高い抽象化の段階へ進んだ
単なる実装だけでは思考は深まらない
AIに実装を任せると、結局は『目隠しした者どうしで道を探す』ことになる
自分でコードを扱いながら考える過程が不可欠だ
私は「AIは簡単な仕事はうまいが、大きな仕事はもっと得意だ」という話には共感できない
実際にはいつも期待外れの結果しか得られなかった
コードがまともに動かなかったり、何度も修正指示が必要だったりした
フィードバックループが難しいなら、結局自分自身が唯一のフィードバック源になり、そのときAIの限界を痛感することになる
たとえばTaskManagerの構造やメモリ所有権のルールなどを明確に説明すれば、テストまで通るコードをうまく作ってくれる
Ryan Dahlのように「もうコードを直接書かない」と言う人もいるが、それは反復的なフィードバックを通じて協業するように磨き上げているからだ
AIは子どもを教えるように扱うべきだ
入力・出力・想定エラーを明確に記述し、反復実験しながら修正する
Claudeが質問し、調査し、コードレビューまでしてくれる
まるで有能なジュニア開発者をメンタリングしているような感覚だ
私は「vibe coding」を最初はオープンな気持ちで試したが、次第に懐疑的になった
反復的で明確なコードには向いているが、ビジネスの中核ロジックには不向きだ
Claudeはしばしば仕様を無視したり、同じロジックを何度も繰り返したり、直すと言っておきながらそのままにすることが多い
モデルがだんだん鈍くなってきた感じもある
今では設計の議論やデバッグ用にしか使っていない
AIが埋めてくれる「退屈な部分」が多いということは、そもそもコード構造が間違っている可能性もある
この部分ではLLMは依然として役に立つ
多くの開発者はどうせすでに決まった設計案を受け取って実装するだけなので、AIが速度を上げてくれることはある
私は「AIは設計変更を反映できない」という主張には同意しない
むしろ「それこそが人間の役割」だ
たとえばAPI構造を変えろと言えば、AIは関連するすべての箇所を探して修正し、テストまで回せる
実装の詳細に執着したり、概念的な検証が抜けていたりする
それでも人間が書くテストも似たようなものなので、理解はできる
自分でコードを書かなければ、抽象化の粗く不均衡な部分を実感できず、それが結局は構造的品質の低下につながる
この違いがコードの完成度を左右する
だが重要なのは、どの作業が本当に手動介入を必要とするかを判断する能力だ
ただし、高額プラン（例: Claude Max 200ドル）を使ってはじめて効率が出る
AIツールの熟練度を客観的に評価する方法が必要だと指摘している
私は「2年前からvibe codingをしていた」という話に疑問を抱く
Karpathyがこの用語を作ったのは、ほんの1年前だからだ（出典）
GPTが自分で使うAPIを設計し、それに合わせて実装させたという点が興味深い
ただ、その後のモデルは自己修正・自己複製に関する会話をブロックし始めたという
完全なエージェント型ツールでなくても、ChatGPTやClaudeで十分可能だ
今ではリサーチ段階からAIと協業して良い結果を得ていると言う
私は学生たちに「スポーツをテレビで見ても運動にはならない」と話している
vibe codingも同じで、自分の手でコードを書くことでしか得られない達成感がある
AIが作ってくれる**『半分できあがったコード』**のおかげで再びやる気が出る
私は本物のエンジニアたちが「vibe coding」を盲目的にやっているのか疑問だ
むしろ私は対話で彫刻するようにコードを磨くやり方を使う
要件を提示し、AIと一緒に設計案を検討し、構造を段階的に完成させていく
この過程は遅いが、協業と思考の深さを維持できる
AIは大量のコード学習をもとに新しいアイデアを提示し、私は経験でそれを調整する
結局、**AIは私を拡張したバージョン（me++）**のように感じられる
まだ完全なエージェントに任せる準備はできていないが、このやり方が最も生産的だ
私は、AIが書いたコードは部分的には素晴らしいが、全体としてはめちゃくちゃな小説のようだと感じる
章ごとに見れば完璧でも、全体の文脈では混乱している
だとすれば、1万行のvibe-codedなコードベースがまともに動くと期待するのは無理がある
人間の思考や感情が反映されていなければ、ユーザー体験も一貫性を失い、認知的摩擦が生じる
設計が明確なときはLLMがボイラープレート作業を爆発的に加速してくれると言う
だが、デザインは依然として人間の仕事だ
彼のプロジェクトはGitHub公開版で見られる
私は、LLMが作ったコードは部分的には素晴らしいが、全体構造は弱いという点を認める
だが、コードベースを理解し、自分でレビューすれば十分に補える
vibe codingはプロトタイプ作成には優れている
素早く感触をつかみ、その後リファクタリングしながら拡張するやり方は効果的だ
つまり、成果物だけを見て判断するのが本当のvibe codingだという主張だ