あなたがバイブコーディングしているときがわかる

2025年7月31日原文(alexkondov.com)

概要

コードの生成方法 には関心がないが、 マージされるコードの質 が重要
LLM生成コード はプロジェクトの慣習を無視しがち
スピード重視 の風潮がソフトウェア品質を損なう懸念
品質・一貫性・長期的な保守性 への配慮の重要性
既存の原則 を守り、LLM活用時も適切な指示が必要

LLM生成コードとプロジェクト慣習

コードの生成手法 （手書き、コピペ、LLM利用等）自体は本質的な問題ではない
マージされるコード が正しい成果を生み、将来の理解・変更が容易であることが重要
LLM生成コード は、プロジェクトの既存ルールや慣習を無視した実装が多い傾向
- 例：既存のデータ取得ライブラリがあるのに独自HTTP実装
- 例：既存のユーティリティ関数を再実装
- 例：グローバル設定の不適切な変更
- 例：関数型アプローチの中で突然クラスを定義
人間らしさの欠如 が、プロジェクトの一貫性を損なう要因

ソフトウェア開発の本質と課題

ソフトウェア開発の本質 は、長期的に保守可能なものを作ること
動くコード を早く書くだけでは不十分
品質・一貫性・保守性 を無視した“スピード重視”の開発は、後の改修コスト増大につながる
過去の知見やパターン を活かし、安定した開発基盤を維持することが重要

スピードと品質のバランス

スピードのみを追求 する開発は、短期的な成果を優先しがち
良質な成果物 の提供には、適切な手順と配慮が不可欠
例え話 ：カフェで新米バリスタが焦ってコーヒーを作る様子に例えることで、品質より速度を優先する危うさを説明

LLM活用時の注意点と提言

LLMは技術的偉業 だが、プロトタイプを本番化するだけでは不十分
プロンプトや指示 を工夫し、プロジェクトの慣習や既存ライブラリの利用を明示することが重要
- 具体的なライブラリ指定
- 実例提示
- 小さなファイル単位での指示
新しい原則は不要、既存の開発原則を遵守する姿勢が求められる
コードベースの保守性 をモデル任せにしない開発意識

結論：開発者としての姿勢

コードの生成方法 ではなく、 成果物の質 にこだわる姿勢
品質・一貫性・長期的な視点 を持った開発姿勢の重要性
LLMの活用 も、既存原則の上に成り立つべきであることの再認識

Hackerたちの意見

それは全部本当だね。今のLLMを扱う最適な方法は、アセンブリ言語よりもコンパイル言語が提供する抽象の一歩上にある感じ。普通の英語で何かを説明して、その明確な要件や入力、出力を示せば、LLMは指定したロジックの翻訳としてコードを書いてくれる。LLMを使うときは、彼らが対処しなきゃいけないエントロピーを最小限に抑えるのがベストだよ。トランスフォーマーは基本的に翻訳エンジンだから、生成器としてじゃなくて翻訳者として使うべきだね。とはいえ、数ヶ月ごとに新しいモデルが出てきて、典型的なLLMの欠点から少し解放されて、ちょっと「直感的」に賢くなって、手取り足取りのサポートがあまり必要なくなって、信頼性も増してる気がする。これは単なる進化の自然な過程だと思う。LLMにお金が投入されるほど、彼らは良くなっていく。基本的に彼らは巨大な連想マシンだから、その連想がより大きな抽象を生み出して、世界を理解するための道具の使い方がより堅牢な概念に繋がるんだよね。時間が経つにつれて、LLMに与えたタスクを人間のプログラマーよりも上手にこなせるようになるのは避けられないと思うし、人間がやることのほとんども同じことになるだろうね。

└

いや、LLMはコンパイラみたいな「抽象」じゃないよ。これはクソみたいな話だ。LLMは確率的なトークン生成器に過ぎない。現実で、LLMを使って作ったものでゴミ箱に捨てないものを作った人に会ったことなんて一度もないし、LLMのレシピで焼いたクッキーを食べたことがあるけど、それは本当に不快だった。いや、LLMは良くならないよ。シンギュラリティのクソみたいな話は2010年代から続いてる。LLMはインターネット全体を消費して、まだ役に立たない。残りのデータはどこから来るんだ？高品質なデータを求める人たちからのメールは詐欺ばっかり。人々は、質が高いのは高いから、簡単に盗めるゴミでこれらを訓練したがってるだけなんだよ。ちょっと考えればわかることだ。この楽観的なクソみたいな宣伝は恥ずかしい。

└

これは間違ったアナロジーだね。LLMは、コンパイラやインタプリタが高水準プログラミング言語を機械命令に実装するのと同じように、自然言語を高水準コードに「コンパイル」するわけじゃない。プログラミング言語や機械言語は、正確であいまいさのない意味論を目指しているから、意味論が実際に正確かどうかや、コンパイラが仕様を実装できていないバグがあるかどうかを話すのが意味を持つんだ。自然言語は、既存のスタックの上にある単なる高いレベルの抽象じゃない。新しいモデルが出たり、既存のモデルを新しいシードで実行したりすると、異なるコードが出てきて、動作も異なることがある。これがコンパイラの動作じゃないんだよ。

コードを生成するためにLLMを使うときは、リンターやフォーマッターを設定して、厳密な型チェックをたくさん行うのがめっちゃ役立つよ。これは、スタイルルールを知らない人や同意しない人からの貢献を受け始めたときにも同じだね。テストも重要だし。基本的に、自動化されたもので、コードのスタイルや動作を確保するのに役立つものは、コーディングエージェントと一緒に使うとすごく便利になる。彼らは、問題をチェックしたり、可能なら修正したりするために、指示したコマンドをそのまま実行できるからね。

└

これらのツールが大いに役立つのはわかるけど、記事に挙げられている例（「バイブコーディングの匂い」の下）を防ぐことはできないと思うよ。

└

これじゃ問題を隠すだけだよね。

LLMは、現在のコードベースの状態だけでなく、歴史的なコミットをコンテキストとして使う必要があるね。私が関わったほとんどのコードベースは、レガシーパターンAから新しくて良いパターンBに移行していく過程を経るんだ。これらの移行は一度で完了することはめったにないから、古いコードが再訪される間、両方のパターンがしばらく残ることが多い。HTTPの例のように、たとえLLMが従うべきパターンを拾ったとしても（実際にはそうならないことが多いけど）、正しいものを選ぶかどうかは運次第だよ。

└

それは、コミットメッセージが正しく実装されていると仮定しているけど、「このファイルを更新しました」や「バグ修正」みたいなものじゃないってことだね。

└

具体的にどうやってこれやあれをやるのか、いくつかの例を交えて教えた方がいいね。

└

これね… 以前、20年の間に何度も買収や名前変更、合併を経た大規模なコードベースに関わったことがあるんだ。辞める頃には、ついにフォーチュン500のグローバル企業の手に渡ってた。必要なAPIコールに合致するコードが見つかることもあったけど、それが2000年代中頃に最後に更新されたもので、実際にはそのタスクの最新のコードじゃない可能性が高かった。でも、特定のクライアントが使うために必要だったから残ってたんだよね。ドキュメントがない似たようなAPIコールもあって、欲しいデータフィールドを返すやつを選ばなきゃいけなかった。

└

ちゃんとしたCLAUDE.mdを作って、「この部分みたいにコードを書いて、あのレガシー部分みたいなコードは避けて」って書くことができるよ。

└

でも、その意識が「雰囲気コーダー」に欠けてることが多いんだよね。多くの人は以前はあまりコードを書いてなかったから。

Hacker Newsで議論の続きを見る

ハクソク