この記事は用語の空白から出発する。著者は、バイブコーディング が、AI を使って速く、いい加減に、無責任にソフトウェアを作るやり方（完全にプロンプト主導で、コードがどう動くかに注意を払わない）の名前としてすでに定着していると捉え、スペクトルの反対側、つまり熟練したプロが LLM で仕事を加速させつつ、自分が生み出すソフトウェアに誇りと自信を持って責任を負い続ける側を何と呼ぶべきかを問う。著者は「半分だけ冗談で」、バイブエンジニアリング という名前を提案している。
記事の大部分は、この反対側が難しく、既存の専門性に報いるものだと論じている。著者はコーディングエージェントの台頭を指摘する。Claude Code、OpenAI の Codex CLI、Gemini CLI のように、指定された目標に達するまでコードをテストし修正しながら反復するツールである。また、経験豊富なエンジニアが複数のエージェントを並列で動かしていることにも触れ、著者自身も今ではそうしていると述べている（並列コーディングエージェントのライフスタイルを受け入れる を参照）。著者は、エージェントとともに反復して自分が保守できる本番品質のコードを目指すことを、単純で失敗しても影響の小さいタスクを外部に任せ、動いているように見えれば結果を受け入れる古典的なバイブコーディングと対比している。
2026 年 2 月 23 日付の記事の追記では、この考え方については「エージェント型エンジニアリング」という用語が優勢になりつつあるようだと述べられている（エージェント型エンジニアリング を参照）。
要点
- バイブコーディングと、ソフトウェアのための LLM の責任ある職業的な利用との間には用語の空白があり、著者はそれを埋めるために「バイブエンジニアリング」を提案している。
- おもちゃではないプロジェクトで LLM と生産的に働くことは難しいと説明される。ツールには奥深さがあり、避けるべき落とし穴があり、ツールが動くコードを生み出す速さによって、人間が貢献すべきことの水準が引き上げられる。
- 著者によれば、LLM は既存の一流のソフトウェアエンジニアリング実践に積極的に報いる。自動テスト（ループで反復するエージェントにはテストファースト開発が特に効果的）、事前の計画、包括的なドキュメント、良いバージョン管理の習慣、CI、フォーマット、リント、プレビューデプロイといった効果的な自動化、そしてコードレビューの文化である。
- 著者は必要だと考えるスキルも挙げている。人間の協力者を管理するのに似た、エージェントの「非常に奇妙な形のマネジメント」、優れた手動 QA、調査スキル、プレビュー環境へ出荷できる能力、何を AI に任せられるかの勘、そして更新された見積もり感覚である。
- エンジニアの役割は、アプローチの調査、アーキテクチャの決定、仕様の記述、成功基準の定義、エージェント的ループの設計、QA の計画、そしてコードレビューにはるかに多くの時間を費やすことへと広がる。
- 記事の結論は、AI ツールは既存の専門性を増幅するというものである。エンジニアのスキルと経験が多いほど、LLM やコーディングエージェントでの成果はより速く、より良くなる。
- 名前は意図的に選ばれている。著者はこれを生意気で物議を醸しそうだと述べ、「バイブ」をより建設的なもののために取り戻したいと語り、「バイブ」と「エンジニアリング」の自己矛盾こそが定着の鍵になるかもしれないと評価している。
これらの点は著者自身の経験に基づく見解であり、記事は計測結果を示していない。
背景
著者は、自分が挙げた実践のほとんどすべてがすでにシニアソフトウェアエンジニアの特徴であると指摘し、「コーダー」と「エンジニア」の区別は門番的な線引きとして嫌ってきたが、ここでは「少しの門番こそがまさに必要なもの」だと述べている。また、以前にも AI 支援型プログラミング のような用語を定着させようとして、ほぼまったく成功しなかったことも記している。