Vibe codingとagentic engineeringの境界は、自分が望む以上に近づいている
(simonwillison.net)- vibe coding と agentic engineering はもともとコードレビューと説明責任の基準で区別されていたが、コーディングエージェントの信頼性が高まるにつれて、実際の本番作業ではその境界が曖昧になっている
- vibe coding はコードをほとんど見ず、望む結果が出れば受け入れるやり方なので、個人向けツールには有用かもしれないが、他人の情報や利用体験が関わるソフトウェアでは無責任な方法に見える
- Claude Code のようなエージェントが JSON API エンドポイント、SQL クエリ、テスト、ドキュメント化を繰り返しうまく処理することで、生成されたすべてのコード行をレビューしないことが起きており、これは人間のチームと違って評判や責任を持たない対象への信頼というリスクを生む
- いまではコミット 100 個、良い README、完全なテストを備えたリポジトリも 30 分で作れてしまうため、見た目だけで品質を判断するのが難しくなり、実際の基準は誰かがそのソフトウェアを継続的に 使ったか どうかになっている
- AI ツールはソフトウェアエンジニアの経験を置き換えるのではなく増幅し、コード生成速度が 1 日 200 行から 2,000 行に増えると、ボトルネックは設計、検証、運用、実利用へと移る
Vibe codingとagentic engineeringの境界
- Heavybit High Leverage ポッドキャスト Ep. #9で AI コーディングツールを扱う中で、vibe coding と agentic engineering が実務の中で互いにより近づいていると感じるようになった
- 以前は Not all AI-assisted programming is vibe coding (but vibe coding rocks) で vibe coding と責任ある AI 支援プログラミングを明確に区別しており、後者をその後 agentic engineering と呼ぶようになった
- vibe coding は、コードをほとんど見ず、プログラミングを知らない可能性のある利用者が欲しい成果物を依頼し、動けば受け入れ、動かなければもう一度依頼するやり方として区別される
- 個人向けツールのように、バグの被害が自分だけに及ぶ場合には vibe coding は有用かもしれないが、他人の情報や利用体験が関わるソフトウェアを作るときには無責任な方法に見える
- agentic engineering は、専門のソフトウェアエンジニアがセキュリティ、保守性、運用、性能といった制約を理解した上で、AI ツールを自分の能力を最大限に引き出す形で活用するやり方である
- 目標は、より低品質な成果物をより速く作ることではなく、より高品質な本番システム をより速く作ることにある
- 問題は、コーディングエージェントの信頼性が高まるにつれて、本番レベルの作業であっても、生成されたすべてのコード行をもはやレビューしなくなってきた点にある
コードレビューを省略させる信頼
- Claude Code に JSON API エンドポイントを作り、SQL クエリを実行して結果を JSON で出力するよう依頼すると、きちんと処理してくれるという確信が生まれる
- 自動テストやドキュメントの追加を任せても、成果物は問題ないだろうと期待するようになり、その過程で実際のコードを確認しないことが起きる
- コードをレビューしていないなら、それを本番で使うのは責任ある行為なのかという後ろめたさが残る
- 大きな組織でエンジニアリングマネージャーとして働いていたときに、他チームのソフトウェアを利用するやり方と似ていると考えられる
- 別のチームが画像リサイズサービスを提供していたとしても、通常そのチームが書いたすべてのコード行を読むことはない
- ドキュメントを見て画像をリサイズしてみた上で、自分の機能をリリースする
- バグや性能問題が見えたときに初めて Git リポジトリを確認することがある
- ほとんどの場合、そのサービスを 半分ブラックボックス のように扱う
- エージェントも次第に同じように扱うようになるが、人間のチームと違って Claude Code には職業上の評判や説明責任がない
- 人間のチームは、過去に良いソフトウェアを作ることで評判を築くことができ、ひどい成果物が自分たちの職業上の評判に影響するという圧力も受ける
- Claude Code はそうした評判を持てないが、単純作業を繰り返し正しく処理し、しかもこちらの好みに合ったスタイルでこなすことで信頼を積み上げている
- ここには 逸脱の正常化 の要素がある
- モデルが近くで監視しなくても正しいコードを書けるたびに、信頼は高まる
- 後になって、誤ったタイミングで過信し損害を受けるリスクも同時に高まる
ソフトウェア評価はより難しくなる
- 以前は、GitHub リポジトリにコミット 100 個、良い README、自動テストがあれば、そのプロジェクトにはかなりの手間と注意が注がれていると判断しやすかった
- いまでは、コミット 100 個、美しい README、すべてのコード行をカバーするテストを備えた Git リポジトリを 30 分で作れてしまう
- こうしたリポジトリは、長い時間をかけて手間と注意を注いだプロジェクトと見た目では同じに見えることがある
- 実際にそれだけ良い可能性もあるが、外見からは分かりづらく、自分のプロジェクトでも同じ問題が起きる
- テストやドキュメントの品質よりも重要だと考える基準は、誰かがそのソフトウェアを実際に 使ったか どうかである
- vibe coded な成果物であっても、作った人が過去 2 週間にわたって毎日使っていたなら、ほとんど実行もせずに吐き出した成果物よりはるかに価値があると考える
ボトルネックはコード作成から別の段階へ移る
- 1 日に 200 行のコードを書いていた状況から 2,000 行を書けるようになると、ソフトウェア開発ライフサイクルの他の部分が壊れ始める
- 従来のソフトウェア開発ライフサイクルは、1 日に数百行のコードを書く速度を前提に設計されていた
- ボトルネックの変化は下流工程だけでなく上流工程にも影響する
- Jenny Wen の講演 では、従来のデザインプロセスは「デザインを正しく固めなければならない」という前提を持っているとされる
- エンジニアに渡した後、間違ったものを 3 か月作り続けたら大惨事になるからである
- デザインが高コストな作業につながるため、広範なデザインプロセスが置かれている
- しかしビルドに 3 か月かからないのであれば、間違ったときのコストが大きく下がるため、デザインプロセスははるかに大きなリスクを取れるようになる
それでもソフトウェアエンジニアのキャリアが終わったとは思わない理由
- エージェントとの対話は、多くの人にとって理解しづらい “moon language” のように見える
- コンピュータが自分でコードを書けるようになったからといって、ソフトウェアエンジニアのキャリアが終わるとは思わない理由の 1 つは、こうしたツールが既存の経験を増幅するからである
- 自分が何をしているか分かっている人は、AI ツールと一緒にずっと速く動ける
- AI ツールを使えば使うほど、ソフトウェアを作ること自体が非常に難しいという事実が繰り返し確認される
- どれだけ AI ツールが与えられても、達成しようとしていることは依然として難しいと考える
- Matthew Yglesias は ツイート で「5 か月たって分かったのは、自分は vibecode をやりたくないということだ。専門的に運営されるソフトウェア企業が AI コーディング支援を使って、より多く、より良く、より安いソフトウェア製品を作り、それを自分に売ってくれる方がいい」と書いており、これに同意する
- 配管に関する YouTube 動画を十分見れば自分で家の配管を直せるかもしれないが、それでも配管工を雇う方を好む、という比喩でまとめられる
SaaSと内製のリスク
- 企業が SaaS を使わず独自ソリューションを作れるようになる脅威についても、実利用で検証されたソフトウェアを好むという基準はそのまま当てはまる
- 個人プロジェクトでは、少なくとも数週間にわたって作った本人が実際に使っていたツールを好む
- エンタープライズ版に置き換えるなら、少なくとも 2 社の別々の大企業が 6 か月間うまく使っていた CRM でなければ導入したくない、という基準になる
- リスクを取る前に、実際に機能することが証明されたソリューションを求める
1件のコメント
Hacker Newsの意見
バイブコーディングやLLMが、規律のないエンジニアリング組織やエンジニアを生み出したのではなく、既存の問題を露呈させ、加速させただけだということ
多くのエンジニアはコードを書く基準や実践が緩いか、そもそも存在せず、多くのチームもコードを本番環境にデプロイする基準が弱い
これは新しい現象ではなく、ソフトウェア開発ライフサイクルで基準を守ったことのない個人やチームが、はるかに多くのコードを書き、アイデアを具体化しやすくなったという意味にすぎない
コードを速く書けるようになったことで良いエンジニアになった同僚を見たことはない
私の知る最高のエンジニアたちは、経験と慎重な判断に基づいてチームに重要な洞察を共有し、システムの方向性を良く導いた人たちだった
「Claude、システムを1つ作って。しかもちゃんと良く作って。ありがとう！」
以前は、コードベースが機能開発に抵抗し始めたら当面のボトルネックを直し、次の抵抗点までは先送りにするというやり方だった
機能を作りながらある程度リファクタリングする方式だったが、フロンティアモデルは「問題になる瞬間」を後ろへ押しやってしまう
与えられたコードの山をある程度までは処理してくれるので、LLMがリグレッションを増やしたり要件をさらに見落としたりする形で現れるが、人間にとって作業がより難しくなった感覚は薄い
そしてある瞬間、壊れた部分が多すぎて直さなければならなくなるが、コードベース全体が自分の下していない決定のフラクタル状の層になっていて、ほどくのが難しい
自分でコードを編集しないため、「これをこういうやり方で追加すると緊張が大きい」という身体感覚が消え、リファクタリングの突破口を見つけるのも難しくなる
コードはいつでもリファクタリングできるし、エージェントに小さくモジュール化された断片やファイルを書かせるよう強制することもできる
エージェントが書いたものであれ人間が書いたものであれ、良いエンジニアリングは良いエンジニアリングだ
まだしばらくは、人間が少なくともアーキテクチャを理解して主導する必要があり、エージェントは偵察や提案で非常によく助けてくれる
この数週間の進歩を見逃していない限り、AIがより信頼できるようになったというより、エラーがより微妙になったように見える
コードがコンパイルできなければ見つけやすく、コンパイルは通るが動かなかったとしてもある程度は見つけやすい
しかし、コンパイルも通り動作もするのに一部の境界条件で誤っていたり、セキュリティ脆弱性があったり、技術的負債や疑わしいアーキテクチャ上の決定を持ち込んでいたりすると、見つけるのははるかに難しく、レビュー負荷はまったく減らない
むしろ、もっともらしいコードのほうが、明らかにひどいコードよりレビュー時の精神的負担は大きい
複数のテストを先に書かせ、コードがそれに合っているか確認し、エージェントがコードを正しく整理するよう指示すればよい
ただ今は、上から降ってくる熱気が大きすぎて、どこにでも広範囲に適用しろという雰囲気で、それに反対するとひどく気が滅入り、キャリア上の制約にもつながって精神がすり減る
明白な問題を指摘すればするほど多くの回避策が出てきて、その回避策にはすぐ別の問題が現れ、終わりなく新しい解決策を生む
ある瞬間、これらすべてが機械そのもののための作業のように感じられる
多くの会社では本当の目標がぼやけ、残っているのはLLMそのものだけのように思える
会社の未来を賭けてそのビジョンを実装する人たちは、結果から逃れられる穏やかな出口を保証されているのか、それとも合理性そのものが丸ごと捨てられているのか分からない
健全なエンジニアリング原則で問題を緩和することはできるだろうが、認知負荷・開発者の時間・金・有限資源の観点で、実際にどんな効率が生まれているのか疑問だ
「1日200行から2,000行を作れるようになったら何が壊れるのか」という文脈で、エンジニアリングのアウトプット尺度としてコード行数を使うのは恥ずかしいことだ
200行をレビューするのと2,000行をレビューするのでは、まったく異なる作業量になる
同じプログラムを自分の頭で作り直し、ChatGPTは検索とオートコンプリートのようにだけ使ったところ、1,500行で同じ結果が出た
努力の差も正直そこまで大きくはなかったが、手で書いたアプローチは、先にバイブコーディング版を作ったおかげで何を作りたいかをすでに考えられていたという利点があったかもしれない
ソフトウェアレビューの入力値としてコード行数を使うのは理にかなっている
文字どおり各行を読まなければならないからだ
ただし、開発者生産性の唯一の尺度としてはひどく、その用途で使おうとすると問題が起きる
それでも、複数の会社・チーム・言語・アプリケーションの文脈をまたいで、即座に直感的に理解でき比較可能なほぼ唯一の指標なので有用だ
同じチームが同じ製品で作業していても、1,000行の変更はすぐ終わることがあり、1行のバグ修正には何日もデバッグが必要なこともある
そのため、PR、機能、ストーリーポイントを文脈なしで比較するのは難しく、業界標準の開発者生産性指標が可能なら皆が使っていただろうが、本質的に難しいのだと思う
この種の比較では文脈が同じだと仮定すれば役に立つ
たとえば、ある会社のある製品を、ある技術スタックと品質プロセスで作っていたチームが、昨日はN1行、今日はAIでN2行を作ったなら、時間の経過とともにN1とN2の差が実際の影響を近似する
厳密なAI支援開発の生産性研究も、おおむね同じ集団を対象にAI利用前後のPRを比較するA/Bテスト的な測定を行ってきた
私にとっての違いは、パイプラインの品質と厳格さだ
バイブコーディングは、1回または数回試して、結果をざっと確認し、壊れるまで使うやり方だ
軽い概念実証や、リスクの低い個人・家族・小規模チーム向けアプリには向いている
エージェント型エンジニアリングは、機能的正確性、性能、インフラ、回復力/可用性、スケーラビリティ、保守性といったより広い関心事を気にする
作業フローを管理する多段階パイプラインがあり、プロジェクト受け付け・選定・仕様化・エピック分解・ストーリー分解・コーディング・ドキュメント化・デプロイといった段階がありうる
各段階には、テスト合格や性能基準のような決定的な品質ゲートと、事業価値・仕様の完全性・コードの優雅さ・ユビキタス言語の厳密さと単純さのような敵対的レビューが混ざる
これもスライダーだ
ときには、1つの機能をデプロイするためにインタビューをし、トークンを燃やし、3回の敵対的レビューと価値見積もり、詳細仕様までやりたくなくて、単にチケットをシステムに投げ込むこともある
Opus、GPT-5.5、より小さなモデルを毎日使っているが、作業全体を任せることはない
仕様を定義して磨き込むのにかなり力を入れても、人間のPRレビューなら通さないような愚かなことを、今でも数多くやる
出力を信じたり、大きなエージェントパイプラインを作って偽りの安定感を得たりしていたなら、コードベースにそのまま流し込ませてしまいがちだっただろう
10年後には良くなるかもしれないが、今のバイブコーディングとエージェント型エンジニアリングのパイプラインは、どちらもLLMに丸ごと委任するという同じ主題の変奏に見える
今朝も単一ファイルでOpus on Maxに変更を任せられそうだと思ったが、ほぼ毎ターンでミスや見落としがあり、修正しなければならなかった
提案されたコードはたいてい動いたはずだが、複雑すぎて、私がすでに手で単純化しておいた部分を再び退行させた
こうしたことが何千ものエージェントコミットに掛け合わされると、コードベースは急速に悪化する
開発チームは、設計・テスト・レビューという正しいプロセスなしに作ろうとすると苦しくなる
エージェントコーディング以前からそうだったが、今は特にそうであり、このプロセスでエージェントを活用する方法を理解したチームが最も成功するだろう
コーディングエージェントが最初の試行で解法にかなり近づくものの、最後の**10%や5%**を合わせ込むのに膨大な作業が必要だと感じたことはないだろうか
問題へのアプローチを変えれば、エージェントがそのギャップを埋められる
10年前なら、10〜15分ごとにコーディングを止めて、リファクタリング・テスト・分析を行い、完璧かどうかを確認していた
バグがその後のコード全体を汚染するからだ
コーディングエージェントはそうできず、バグや誤ったアーキテクチャを抱えたまま進み続ける
本能的にはエージェントを途中で止めたくなるが、さまざまな理由で不可能だ
その代わり、コストが非常に安いのだから、エージェントが最初に間違えた地点を探してプロンプトを直し、コードを修正する代わりに全部消して最初からやり直すべきだ
プロンプトが完璧なコードを出すまでこの反復を続ければよい
人間のやることが多いという反論が出るだろうが、まさにそれが核心だ
人間は依然として必要であり、このようにツールを使えばコード作成速度は10倍になる
「動く何か」はかなり早く作れるが、他の選択肢を評価し、磨き、テストして確信を積み上げるには時間がかかる
要点は正しいが、限界がどこにあるかは誰にも分からない
今後1年ほどは皆がそれを探る時期になるだろうし、だから「GitHubを再発明しなければならない」という話も多く聞くのだ
多くの場合、その最後の部分まで機械化するために投資するのは経済的に見合わない
LLMプロバイダーは最初から間違ったアプローチを取ったのだと思う
労働を代替することに集中するのではなく、労働を補完することに焦点を当てるべきで、高い授業料を払ってその教訓を得たようだ
最初からやり直したほうがよかったかもしれないが、始めた時点では望むアーキテクチャがどんなものか分かっていなかった
LLMが既存アーキテクチャに機能を合わせ込むのに苦労しているからといって、動いているコードベース全体を捨ててやり直すことはできない
聡明で謙虚で学び続ける人が書いた素晴らしい文章だ
気に入った一節は「コンピュータが自分のコードを書けるようになったからといって、ソフトウェアエンジニアとしてのキャリアが終わると恐れていない理由はたくさんある。部分的には、こうしたものが既存の経験の増幅器だからだ。自分が何をしているか分かっていれば、はるかに速く走れる」というところだ
また、「これらのツールを使うたび、私たちの仕事がどれほど難しいかを思い知らされる。ソフトウェアを作ることは猛烈に難しい。世のあらゆるAIツールを与えられても、私たちがここで成し遂げようとしていることは依然として本当に難しい」という部分も良かった
アップストリームの作業も一緒に変わるという指摘は的確だ
デザイン系ツールがとりわけ急速に進化していて、もはやFigma側にとどまる翻訳コストを払う価値はないように見える
怖いのは、コードベースにAI複雑性の層が積み重なり、人間がもはやコードを理解できず、最新モデルが解読して変更するのに大きなコストがかかるようになることだ
そう遠くないうちにコード再利用は消え去り、車輪を延々と再発明することに金を燃やすようになるかもしれない
初期のAndroidアプリを作るときはIDEが必須で、ボタンクリック後に「Hello World」の通知を出すだけでも、とんでもない量のボイラープレートコードを書かされ、魂が抜けるようだった
復唱してみよう。ほとんどのソフトウェアは寿命の大半を保守フェーズで過ごす
したがって、ソフトウェアが稼ぐ金の大半も保守フェーズで生まれる
業界はほぼ100年が過ぎても、いまだにこれを理解していない
Alan Kayがコンピュータ革命はまだ起きていないと言ったのは100%正しい
現在のあらゆる進歩にもかかわらず、ツールは概して石器時代レベルだ
私の大きな希望は、AIが既存のパラダイムを回復不能なくらい完全に壊す地点まで私たちを加速させ、ついに新しく、違っていて、より良い何かをできるようになることだ
だから今は、AIでソフトウェア開発ライフサイクルにジェットパックを付けて思い切りやってみよう
速く動き、本当に壊してみよう
タイムリーな観察で、私にも当てはまると感じる
比較的シンプルな一括ダウンロード → 変換 → APIエンドポイントを立てる必要があり、かなり詳細なプロンプトを書いたが、データソースのような実装の詳細は多く空けておいた
Opus 4.7は、私ならやるやり方の90%くらいで作り、便利メソッドや段階的な検証はずっと多く入れていた
とても良く、より難しい問題を考える余裕を与えてくれた
主にPython開発者だが、RustやGoのように、慣れてはいるが同じレベルではない別のバックエンド言語も継続的に使っている
1つの言語にかなり偏った約13年の経験と、他の言語に対する形式的な学習があるので、LLMを指揮するのはずっと容易だ
文法、基本構成要素、パッケージマネージャー、テストなどを学ぶ負担は、以前のプログラミング方法に比べれば大きくない
少し前に、Claude cowork/codeでレポーティング自動化をしていた非開発者の同僚を手伝った
その同僚はビジネスインテリジェンスの面はよく理解していたが、RDPを立ち上げ、ベンダーDB上のMS Access抽象化に値を埋める pyautogui ラッパーをバイブコーディングするための基本的な表現に苦労していた
開発者という職業は、この先5〜10年は大丈夫そうだ