バイブ・エンジニアリング

• "Vibe Engineering" は、AIコーディングツールを活用した専門的な開発手法の新しい呼び名であり、速いが無責任な「バイブコーディング」とは異なり、熟練したエンジニアがLLMを活用しつつ、コード品質と説明責任を維持するアプローチを意味する
• Claude Code、OpenAI Codex CLI、Gemini CLI のような コーディングエージェントの登場により、実務プロジェクトでの LLM 活用が急増しており、一部のエンジニアは複数のエージェントを 同時実行して並列作業を行っている
• LLM を効果的に活用するには、自動化テスト、事前計画、包括的なドキュメント化、バージョン管理、コードレビュー文化など、すでに確立された最高水準のソフトウェアエンジニアリング実践が必要
• AI ツールは 既存の専門性を増幅する性質を持ち、シニアエンジニアが持つスキルと経験が多いほど、LLM 活用時により速く、より良い結果を得られる
• この用語は、「バイブコーディング」との明確な区別を通じて、プロダクションソフトウェア開発のための、より難しく洗練された AI 活用手法であることを強調しており、エンジニアリングとバイブという矛盾した組み合わせが、むしろ覚えやすい利点をもたらしている（AI ツールの進化に伴う開発プロセスの変化と、専門性の重要さを浮き彫りにする）

---

バイブコーディングとバイブ・エンジニアリングの区別

• バイブコーディングとは、AI を使った高速で緩く無責任なソフトウェア開発手法であり、完全にプロンプト主導で、コードがどのように動作するかに注意を払わないアプローチである
• その対極には、熟練した専門家が LLM によって作業を加速しながらも、自分が生み出すソフトウェアに誇りを持ち、自信を持って責任を負うやり方があり、これを バイブ・エンジニアリングと呼ぶ
• おもちゃのようなプロジェクトではなく、実際のプロジェクトでソフトウェアエンジニアとして LLM と生産的に働くことは、難しいというあまり知られていない真実があり、ツールの使い方を理解するには深い知識が必要で、避けるべき落とし穴も多い

コーディングエージェントの登場と影響

• 2025年2月にリリースされた Claude Code、4月にリリースされた OpenAI の Codex CLI、6月にリリースされた Gemini CLI のような コーディングエージェントツールの登場により、実際のコーディング課題に対する LLM の有用性が劇的に高まった
  • これらのツールは、指定された目標を達成するまでコードを反復的に修正し、積極的にテストしながら作業する
• 経験豊富で信頼できるソフトウェアエンジニアたちは、複数のエージェントを同時に実行して、複数の問題を並列に処理し、作業範囲を広げている
  • 筆者は当初懐疑的だったが、自ら並列コーディングエージェントを実行してみた結果、精神的には疲れるが驚くほど効果的であることを確認した
• tools.simonwillison.net コレクションの大半は古典的なバイブコーディング方式で構築されたが、コーディングエージェントと反復的に作業して 将来的に保守可能なプロダクション品質のコードを生み出すことは、まったく別のプロセスのように感じられる

LLM が強化する既存のソフトウェアエンジニアリング実践

• 自動化テスト: 強力で包括的かつ安定したテストスイートがあれば、エージェント型コーディングツールは高速に動作できる。一方でテストがなければ、エージェントは実際にはテストしていないのに動作すると主張したり、新しい変更が無関係な機能を壊したりする可能性がある
  • テストファースト開発は、ループ内で反復できるエージェントにとって特に効果的
• 事前計画: 何かを一緒にハックし始めるときに高レベルの計画から始めると、はるかにうまく進む。エージェントと作業するときは、これがさらに重要になる
  • まず計画を反復的に詰めてから、それをエージェントに渡してコードを書かせることができる
• 包括的なドキュメント化: 人間のプログラマーと同様に、LLM も一度にコードベースの一部しかコンテキストに保持できない。関連ドキュメントを与えれば、コードを先に読まなくても別の領域の API を使える
  • 良いドキュメントを先に書いておけば、モデルはその入力だけで一致する実装を構築できる
• 良いバージョン管理習慣: コーディングエージェントが変更を加えている可能性がある場合、ミスを取り消し、何がいつどのように変わったのかを理解することがいっそう重要になる
  • LLM は Git に非常に強く、バグの起点を追跡するために履歴を自力で探索でき、多くの開発者よりも git bisect をうまく使う
• 効果的な自動化: 継続的インテグレーション、自動フォーマットと lint、プレビュー環境への継続的デプロイなどは、エージェント型コーディングツールにも役立つ
  • LLM は素早い自動化スクリプトの作成を容易にし、次回以降その作業を正確かつ一貫して繰り返せるように支援する
• コードレビュー文化: コードレビューを素早く生産的に行えるなら、LLM と作業するときの体験はずっと良くなる
  • 自分でコードを書く方が好きで、他人（あるいは何か）が書いた同等のものをレビューするのが苦手なら、これは難しいだろう
• 非常に奇妙な形のマネジメント手法: コーディングエージェントから良い結果を引き出すことは、人間の協力者から良い結果を引き出すことと、不快なほど似ている
  • 明確な指示を与え、必要なコンテキストを保証し、成果物に対して実行可能なフィードバックを返さなければならない
  • 実際の人間と働くよりもはるかに簡単なのは、相手を侮辱したり落胆させたりする心配がないからだが、既存のマネジメント経験は驚くほど役に立つ
• 本当に優れた手動 QA（品質保証）: 自動化テストに加え、エッジケースを予測して掘り下げることも含めて、ソフトウェアを手動でテストする能力に非常に長けている必要がある
• 強力な調査スキル: あるコーディング問題の解決法は数十通りあり、最良の選択肢を見極めてアプローチを裏づけることは、これまでも常に重要であり、エージェントを解き放って実際のコードを書かせるうえでも依然として障壁である
• プレビュー環境へデプロイする能力: エージェントが機能を構築したとき、それを安全に事前確認できる手段があれば（本番に直接デプロイせずに）、レビューははるかに生産的になり、壊れたものを出荷するリスクも大きく減る
• AI にアウトソースできることと手作業で扱うべきことに関する勘: モデルとツールがより効果的になるにつれて、これは今後も進化し続ける
  • LLM と効果的に働くうえで大きな部分を占めるのは、それがいつ最も適切に適用できるかについて強い直感を保つことである
• 更新された見積もり感覚: プロジェクトにどれくらい時間がかかるかを見積もることは、常にシニアエンジニアであるうえで最も難しく、かつ最も重要な仕事の一つだった。特に予算や戦略の決定がその見積もりに基づく組織ではなおさらである
  • AI 支援コーディングはこれをさらに難しくする。以前は長くかかっていたことがはるかに速くなる一方で、見積もりは今や私たち全員がまだ把握しようとしている新しい要素に依存している

バイブ・エンジニアリングの本質と意義

• こうした新しいツールの能力を本当に活用するには、ゲームの最高レベルで機能する必要があり、
  • 単にコードを書くことだけに責任を持つのではなく
  • アプローチの調査
  • 高レベルのアーキテクチャ判断
  • 仕様の作成
  • 成功基準の定義
  • エージェントループの設計
  • QA 計画
  • 隙があればごまかそうとする奇妙なデジタルインターンたちの、増え続ける部隊の管理
  • そしてコードレビューに多くの時間を費やすことまで含まれる
• このほとんどすべてが、すでにシニアソフトウェアエンジニアの特性である
• AI ツールは 既存の専門性を増幅し、ソフトウェアエンジニアとしてより多くのスキルと経験を持つほど、LLM やコーディングエージェントと協働して、より速く、より良い結果を得られる

「Vibe engineering」、本当に？ : 用語選択についての考察

• **「バイブ・エンジニアリング」**という名前はばかげているのか、という問いに対しては、おそらくそうだろう。AI における「バイブ」という概念は、この時点ではやや使い古されて見え、「バイブコーディング」自体も多くの開発者に軽蔑的な意味合いで使われている
  • しかし筆者は、より建設的な何かのためにバイブを取り戻す準備ができている
• 筆者は「コーダー」と「エンジニア」の間にある人工的な区別を好んだことはなく、それはいつも少し参入障壁のように感じられていたが、この場合は 少しの参入障壁こそがまさに必要なもの
  • バイブ・エンジニアリングはバイブコーディングとの明確な区別を確立し、これが プロダクションソフトウェアを構築するために AI ツールと協働する別の、より難しく、より洗練された方法であることを示す
• これが生意気で物議を醸す可能性がある点を筆者は気に入っており、この領域全体はいまだにさまざまな意味で不条理である
  • こうした新しいツールを最も生産的に適用する方法を模索するあいだ、自分たちをあまり深刻に受け止めすぎるべきではない
• 過去には AI 支援プログラミングのような用語を定着させようと試みたが、成功はほぼゼロに近く、今回はバイブをこすってみて何が起こるかを見るのも悪くない
• 筆者は「バイブ」と「エンジニアリング」の間にある明確な不一致をとても気に入っており、この結合語を 遊び心があり、（願わくば）覚えやすい形で自己矛盾的なものにしている

[m00nlygreat]

少し前にも「何とかコーディング？」のような名前を付けて失敗したと記憶していますが、AIペアプログラミングがいちばん適切な表現な気がします。

「その名前は自分が作った」と主張するためのネーミング

[m00nlygreat]

誰かがこれを増強コーディング(Augmented Coding)だと主張していましたが、すぐに消えましたね

[GN⁺]

Hacker Newsの意見

• 最近こういう話題を読むと、なんだか憂うつになる。以前は、身につけるのが難しくて需要も高く待遇も良いプログラミングスキルを持っていて、言語やフレームワークが素早く変わっても賢さで追いつけると感じていた。ところが Simon Willison のような人たちが、こうした新しいエージェントベースのコーディング方式や同時並行の作業フローこそが未来だと言っているのを見ると、ものすごい努力が必要そうでつらい気持ちになる。コーディングエージェントも使ってみたが、むしろ待ち時間が増え、複数の作業を管理するのも流れをつかみにくくて楽しくない。だから、営業のようなまったく別の分野に移りたいとさえ思ってしまう
  • その気持ちには本当に共感する。実際、私の目標の一つは「プログラミング技術は無価値になり、誰でも LLM でコードを書ける」という考えに反論することだった。実際には、既存の開発経験がある人のほうが、コーディングエージェントや LLM と組み合わせたときにはるかに価値が高まると信じている。これまで学んできたことを活かして、新しいツールでより大きなインパクトを出せる。投稿でも触れられていた通り、AI ツールは既存の専門家の力を増幅する役割だ。初心者でも ChatGPT で見栄えのいい UI は作れるかもしれないが、アーキテクチャ設計から自動テストや CI/CD、Kubernetes デプロイ、複数エージェントの同時運用まではできない。だから、経験のあるエンジニアの役割はむしろさらに重要になる
  • 私も「複数の大規模並列エージェントを管理すること」は負担に感じる。見た目にはとても強力そうなので、多くの開発者が関心を持つのもわかるが、実際には強いストレスと管理業務に思える。自分が開発に最初に夢中になった頃は、コーディングそのものが楽しくて、一日中コードを書きながらたくさん学んでいた。ところが 10 年以上の経験を積んだ今では、「そもそもなぜコードを書くのか？」というビジネス寄りの考え方に変わった。会議で各部署が「これはできますか？」と聞いてくると、答えはいつも「YES」だ。技術的にはほとんど何でも可能だ。でも本当に重要な問いは「どれだけ難しいのか」あるいは「なぜこれをやるのか」だと思う。今でも重要なのは反復やいろいろなものを出荷する能力ではなく、本質を見ることだと考えている
  • まさに私の気持ちを代弁してくれている。私も AI を見張って管理する仕事は本当に好きではない。しかも、この AI ベースのコーディングが、検証もされていない正体不明の大企業アカウントなしでは仕事ができないという現実を当然のものにしてしまう点も怖い
  • 心配する必要はない。私もチームの新人エンジニアをメンタリングしているが、この子はコード改善がとても苦手だ。なぜなら、とりあえず動くのでそれで満足してしまうからだ。構造も良くないし、小さな問題やセキュリティ上の懸念があちこちに潜んでいる。Python ファイルがたった 3 つでもそういうことが起きる。私たちのチームには 10 人の開発者がいるが、LLM を一緒に使うようになると、経験の差に応じてコード品質の差はさらに大きくなる。正式に LLM を使うようになる前の 6 か月で感じたこととしては、実際にジュニアとシニア、経験者の差はむしろ広がる傾向がある。Simon の意見に近い
  • 本質的には、知識のある人ほどツールによってより大きな力を得るのであって、その逆ではない、ということを覚えておけばよい
• GPT-4 の発売前後だった 2023 年初頭、翻訳業界にも似たような変化があった。英日翻訳（私が仕事をしてきた分野）では、機械翻訳が初めて人間レベルに近づいた。そのとき多くのプロ翻訳者とさまざまな議論をしたが、ここでの話と同じように、苦労して身につけた翻訳技術の価値がなくなるのではと落胆を訴える人が多かった。LLM を補助として使うと、今や作業過程そのものの挑戦的な面白さまで失われる、という反応も多かった。私が会った翻訳者の大半はフリーランスで、一文ずつ慎重に訳すタイプだった。大規模翻訳プロジェクトの管理者になることにはあまり気が進まないと言っていたし、高度な文化的・状況的コミュニケーション能力を活かせるとしても、動機づけは弱かった。今の私は翻訳の仕事をそれほど多くはしていないが、AI の進歩は継続的に追っており、ときどき翻訳作業でモデル比較のテストもしている。最近は複数の LLM を重ねて動かす、つまり互いの翻訳を相互チェックして改善するマルチ LLM ベースの翻訳システムを試している。文書によっては、本当に最高水準の人間翻訳にほとんど見分けがつかない結果が出る。API 利用料は安くはなかったが、重要な翻訳には十分投資する価値があった。そういう「vibe translation」システムを設計するとき、私の翻訳者としての経験は明らかに役立った。これは Simon の言う vibe engineering に似ている。今の私の年齢（68 歳）ならこれは悪くないが、もし LLM などが私のキャリア初期、つまり 5〜10 年目の頃に登場していたら、翻訳者を諦めていたかもしれないと思う
  • 翻訳の話は LLM 議論にとても良い題材だ。経験の共有に感謝する。一方で、多くの人は翻訳者そのものには深い価値を置いていない。たとえば、誰が本を翻訳したかをほとんど覚えていない。最近は本を以前ほど読む人も少ないので、なおさらかもしれない。また、こうした理由から、伝統的に翻訳は常に単語数や行数ベースで契約・支払いされる傾向があった。ソフトウェアセキュリティのように最終チェック扱いだ。本当に将来競争力を持ちうる翻訳分野は、法律分野（人が訴訟や責任を負う必要があるので）か、あるいは同時通訳・現場通訳（直接対面して実際のやりとりが必要だから）くらいだと思う
• 最近の技術コミュニティでは、「コーディングが速くなって生産性が上がる」という主張が過剰に押し出されているようで少しあきれている。ひたすら速い結果だけを重視する空気だ。実際、私の経験では LLM は冗長で散らかったコードを出してくることが多かった。もちろん私より速いことはあるだろうが、むしろ自分がゆっくり書いたコードのほうがずっと良いと感じる。最近は何でもすぐチャットしてすぐ結果を出し、すぐ本番投入しなければならないという雰囲気だが、それこそが昔の雑な Web 製品乱発の原因だった。vibe coding や vibe engineering のような気の利いた言葉遊びではなく、なぜ多少低品質でも速さがそこまで必要なのか、そしてなぜ自動化やプロセスそのものをもっと改善できないのかを真剣に議論すべきだ。たとえばユニットテストはものすごく速く作れるが、そもそもなぜこんなに多くのユニットテストが必要なのかを問うべきだと思う。必要なのは確かだが、抽象化、つまり上位の視点は進歩している一方で、下位ツール、つまり細部の道具の進歩は遅い気がする
  • ソフトウェアエンジニアリング論争の本質的な問題は、ツールや言語は同じように見えても、実際には許容度、セキュリティ、コンプライアンス、保守基準にとてつもない差があることだ。ある人は単純なプロトタイプを素早く作り、ある人は 10 年単位の長期ロードマップや機微データを扱う。この二つの視点が混ざることで、速く作れることが能力だという見方と、このままではひどい結果になるという懸念が同時に生まれる。どちらも間違ってはいないが、実際の業務文脈やリスクは毎回無視されたまま議論されているように思う
  • 現実的に見て、LLM が開発速度にものすごく役立つのは事実だ。私は 5 年生の頃から 20 年以上コードを書いてきたし、周囲からも速いと言われてきたが、LLM 導入後は自分のスケールが大幅に広がった。もうゲームは変わっていて、今は適応するかできないかの問題だ。未来の不確実性には私も不満が多いが、同じ立場のエンジニアなら十分共感できる
  • ソフトウェア開発において、なぜ速度がそこまで重要なのかという理屈を説明してみたい。自分の主張が必ず正しいとか、実データがあるというわけではないし、用語の定義も曖昧かもしれない。まず「些末な（trivial）ソフトウェア」とは、誰もがその価値と解法を明確に理解していて、自動検証が可能であるか、あるいは実装方法が一つしかないものだと考えられる。だが現実のソフトウェアの大半は非自明だ。そこでは常にバグ、抜け漏れた要件、漏れる抽象化、役に立たない機能、統合の問題、性能問題、セキュリティ問題、複雑さ、保守の悩みなどが発生する。どれほど優秀な開発者が書いても、どれほどコードをきれいに書いても、こうした問題は避けられない。こうした問題は、繰り返されるフィードバック、実運用、保守、数多くの実験の中でしか現れず、少しずつ改善される。つまり、コードを一度で完璧に作ることはできず、何度もの反復を通じて品質が上がっていく。ソフトウェア全体の品質は、この「フィードバックループ」の量に支配される。1 つのループを回すのにかかる時間だけ、全体の反復回数も制限される。結局、生産速度が高いほど、より多くのフィードバックループを経験でき、そのぶんより良いソフトウェアへ発展すると考えている。遅いが高品質なコードでも 1 回しか反復できなければ限界があり、むしろ質が低くても反復回数が無限に多ければ、より良い結果に到達できるかもしれない
  • 5 年後には、世界最高のサンクコスト錯誤の事例になっていそうだ
• 「vibe coding」よりも「agentic coding」あるいは「agentic software engineering」といった名称のほうが適切だと思う。私の開発フローは Claude のコードプランから始まり、最初の段階で必ず明確な仕様を作る。TDD を活用し、自分で決めた隠れたコード品質ルールも自動化ツールで強制している。たとえばデザインシステムに反するとコードをコミットできないし、HTTP ハンドラが必ずサービスレイヤーを通るようにレイヤー分離チェックも自動化している。モデルには TDD をきちんと守るよう定期的に念押ししているが、Claude 4.5 は 4.1 よりはるかによく覚えている。TDD ベースなので PR のコードレビューも非常に簡単だ。PR と仕様を Gemini に渡して不一致、欠落、誤りなどを自動指摘する簡単なツールも作った。良いバックアップツールだ。しかし最終的に重要なのは、自分が何を望んでいるのか、そしてエージェントがどこで逸脱しているのかを自分で判断できる能力だ。結局のところ「質の低い入力には質の低い出力、質の高い入力には質の高い出力」だ
  • モデルに TDD を念押ししているとのことだが、vibe coding では実際にエージェントが TDD のレッド・グリーン・リファクタループを繰り返しているのか？ それとも結果を一度にまとめて出しているのか気になる
  • vibe based という名称より「slop-coding」のほうがふさわしいと思う
• 「vibe engineering」という名称が本当に正しいのか疑問だ。実際には、エージェントに自動テスト、事前計画、詳細なドキュメント化、コードフォーマット／lint、手動 QA など、あらゆる制約を課すやり方だ。私も Karpathy の文章を読んで vibe coding を始めてみて、コードが止まっても何度も再実行しながら全体プロセスを信頼する流れを経験した。だが経験を積むうちに、結局はモデルを制御しなければならないと気づいた。エージェント運用はカートレースに似ていて、コース脇のタイヤのように多くの制約条件を置く必要がある。制約ハーネス（Constraint Harness）が中核であり、コードそのものは生成も再生成もしやすくなる。今後重要なのは、AI の成果物に対するテストと制約条件をうまく積み上げることだ
  • 「vibe engineering」という名前は軽すぎて真面目に聞こえない。より中立的で実際の機能を表す「LLM-assisted programming」のような用語のほうがよいのではないか。もちろんインパクトは弱いが
• 「事前計画」は spec-driven development とも呼べるかもしれない。実際、すべての開発は突き詰めれば事前の仕様に基づいていたとも言える。しかし本当の肝は「非常に奇妙な形のマネジメント」、つまり明確な指示、十分なコンテキスト、実行可能なフィードバックを与えることだ。文字だけで見ると、agile より waterfall に近い
• 今や vibe-coding という言葉は、AI ベースのコーディング全体を指す意味へと広がってしまったようだ。実際、私も AI と一緒に作業しているとペアプログラミングに近い感覚があり、「これは本当に vibe-ing だな」と感じる。ただし、「Take the wheel, LLama of God」のような、本来の丸投げ型 vibe-coding も依然としてよく使われる現象なので、別の新しい言葉が必要だと思う。「Yolo-Coding」を提案したい。no-code、low-code、yolo-code の流れにもよく合う
  • 私は、vibe coder という言葉が no-code に近い否定的なイメージを保つほうがよいと思う。vibe engineer という言い方は好きではないが、いずれにせよ今後はエンジニア／開発者という呼び名自体がエージェント利用を前提とし、「手作業」の開発者のほうがむしろ例外になるかもしれない
  • $enterprise では、「responsible vibing」と「YOLO vibe coding」を区別する新しい呼び名を探した末に、結局「agent assisted coding」という用語にたどり着いた。3 文字の略語がどうしても必要だからだ
  • 「vibe coding」の本来の意味は、Ilya Sutskever が Twitter で投稿していたように、単にプロンプトを入力して、その結果をレビューもせずコピペして実行する、というものだ。分析も検証もしない
  • AI-assisted coding は、個人的にはオートコンプリートや不親切なドキュメントを読む支援くらいのレベルだと思う。vibe coding は
  • LLM が書いたコードを開発者がまったく理解していない
  • コードレビューなしで即座に技術的負債が発生する
  • 法的には著作権保護の問題で EU/US では完全に脆弱 と考えている。vibe coding の最大の致命点は、LLM が生成したコードは本質的に保護も著作権登録もできないことだ。英国など一部の例外はあるが、大半の国では厳しいと思う
  • 私も claude に /yolo のようなスラッシュコマンドを作って、特にガイドもなくそのまま実行させることがある
• ハトがランダムに餌を出す装置と相互作用すると、自分の行動が報酬につながったと思い込み、さまざまな面白い踊りや動作を繰り返すようになる実験がある
  • その面白い踊りというのが、まさに「テストを書く」とか「計画を立てる」に似ているのかもしれない
  • 根拠となる論文のようなものはあるだろうか？ 「ハト 芸」で検索しても SNS の動画ばかり出てきて見つけにくい
• 「Augmented Engineering」（AE）という名前のほうがよい。AI の力で能力を拡張し、最高の結果を出せるのだから「拡張エンジニアリング」だ。AE は「Advanced Engineering」とも解釈できる。AI によって即座に最新の技術知識へアクセスできるのだから、当然より進んだエンジニアリングでもある。vibe はいまひとつだ
  • 用語をそこまで気にする必要はなく、別の名前を付けるとかえって AI コーディングが一部の開発者だけのもののように感じられるかもしれない。今後は従来型のコーディングのほうが例外的になり、今の vibe という言葉もすぐ消えるだろう
  • 最後の文には反論がある。AI は単に最新のエンジニアリング知識を理解させてくれるだけではなく、ここ 1〜10 年で繰り返されてきた失敗、誤り、誤解、設計欠陥なども「即座に」吸収させてしまう危険がある。つまり、AI が提供する情報を絶対に無批判に信じてはいけないし、出典も必ず確認すべきで、その出典ですら AI 生成でないか確かめる必要がある。データセットは汚染され続けているのだから、なおさら注意が必要だ
  • 「Augmented Engineering」をわざわざ別名にする必要があるのかと聞きたい。実際には単に「エンジニアリング」だろう。参考書を見ながらやることを「book assisted engineering」とは呼ばないのと同じで、vibe も同様だ。わざわざ「Yolo engineering」や「Machine Outsourced Irresponsible LMAO Engineering」と呼んでもよいくらいだし、最後の「Advanced Engineering」も大げさに聞こえる
• Simon はいつも本当に要点を正確に突く。だが本当の問題は「coding」よりも「vibe」という言葉のほうだ。vibe engineering に変えてもなお、「何をしているのかもわからないまま突き進む」というニュアンスが残る。まだ「AI-assisted software engineering」のように両端を明確に区別できる言葉のほうがましだと思う

[kimjoin2]

意味のない名称作り;