この記事はポッドキャスト出演のハイライトをまとめたもので、その中心にある告白は、ツールについてではなく著者自身の実践についてのものである。著者はかつて、バイブコーディング（コードをまったく見ないこと）と、エージェント型エンジニアリング（セキュリティ、保守性、運用、パフォーマンスを理解したプロのソフトウェアエンジニアが、これらのツールを自分の能力の限りを尽くして使うこと）との間に明確な線を引いていた。その線が曖昧になりつつあると著者は報告している。コーディングエージェントの信頼性が高まるにつれ、本番用の作業も含めて、エージェントが書くすべての行をレビューすることをやめており、その結果生じる感覚を罪悪感と表現している。
著者の折り合いのつけ方は、弁明ではなく比喩である。エージェントを信頼することを、大きな組織の中で別チームのサービスに依存することになぞらえている。ドキュメントを読み、それを使い、挙動がおかしいように見えたときにだけそのリポジトリを掘り下げる、というものだ。著者は比喩が破綻する箇所も明言している。チームはプロとしての評判を築き、説明責任を負うことができるが、コーディングエージェントは、単純な作業を繰り返し正しくこなしていても、そのどちらもできない。著者はここに潜むリスクを、逸脱の常態化の一要素だと名指ししている。
ハイライトには、さらに 2 つの論点が通っている。1 つは、開発者がかつてプロジェクトに手間がかけられているかどうかを判断するのに使っていた表面的なシグナル（コミット数、よくできた README、網羅的なテスト）が、今では 30 分で生成できてしまうということである。その結果、著者が現在最も重視するシグナルは「誰かが実際にこれを使ったか」になっており、これは個人プロジェクトの規模でもエンタープライズの規模でも同じだという。もう 1 つは、コードの産出量を増やすと、ソフトウェアのライフサイクルが両端で壊れるということである。下流では、コードの生成に時間がかかることを前提に設計された工程が壊れ、上流では、間違ったものを 3 か月かけて作るコストを前提に慎重さの度合いが決められていた設計プロセスが壊れる。
要点
- 著者は、自分がバイブコーディングとエージェント型エンジニアリングの間に引いた区別が自身の仕事の中で曖昧になり始めていると報告し、それを動揺させられることだと述べている。
- 元々の区別があらためて示される。バイブコーディングとは、コードをまったく見ず、場合によってはプログラミングの仕方を知らないまま、動くかどうかだけで結果を判断することである。
- バイブコーディングは、それを使ってよい場面（バグがあっても困るのは自分だけの個人用ツール）を分かっていれば素晴らしいものであり、他人のためのソフトウェアを作るときにはひどく無責任なものだ、と著者は主張し続けている。
- エージェント型エンジニアリングは、プロのエンジニアがこれらのツールを自分の能力の限りを尽くして使い、なお自分の経験に頼りながら、低品質なシステムをより速く作るのではなく、より高品質な本番システムを目指すことだと説明される。
- エージェントが定型的なタスクでは十分に信頼できるようになったため、本番レベルの作業であっても、エージェントが書くコードを 1 行ずつすべてレビューすることはもうしていないと著者は報告している。
- 著者が示す折り合いのつけ方は、別チームのサービスに依存するという比喩である。ドキュメントを読み、使い、問題が現れたときにだけ実装を調べる。
- その比喩の限界も著者自身が指摘している。人間のチームは説明責任とプロとしての評判を負うが、コーディングエージェントはそのどちらも負わない。
- 著者はここに逸脱の常態化の一要素を見ている。監視されていないコードが正しかったと分かるたびに、後で見当違いの信頼を置いてしまうリスクが高まる。
- 100 コミットがあり、よくできた README と徹底したテストを備えたリポジトリは、もはや手間がかけられていることのシグナルにならない。著者によれば、今ではそうしたリポジトリを 30 分で作れるからである。
- 著者は自分のプロジェクトについてさえ違いが分からないと述べており、だからこそ今では、テストやドキュメントの質よりも、誰かが実際にそれを使ったという証拠を重視している。
- 同じ好みのエンタープライズ版として、CRM に賭ける前に、他の大企業が 6 か月間うまく運用できていることを確かめたい、という例が挙げられている。
- 1 日 200 行から 2,000 行へとコード量が増えると、ライフサイクルの残りの部分が壊れる。著者は、それらがコードの生成に時間がかかることを前提に設計されていたと論じる。
- 同じことは上流にも当てはまる。大がかりな設計プロセスは、設計を正しくすることを中心に組み立てられてきた。間違ったものをエンジニアに渡すと、かつては 3 か月分の構築コストがかかったからである。構築が安価になれば、設計プロセスはより多くのリスクを取れるようになる。
- 著者は自分のキャリアを心配していないと報告している。これらのツールは既存の経験を増幅するものであり、ソフトウェアを生み出すことはツールにかかわらず依然としてとてつもなく難しいから、というのがその理由である。
- 著者は、自分でバイブコーディングするよりも、プロが運営するソフトウェア企業が AI の支援を使ってより良い製品を売ってくれるほうがいい、というあるコメンテーターの言葉を引用し、配管工を雇うほうがいいのと同じだという比喩でその考えに賛同している。
背景
この素材はポッドキャストでの会話から取られたものであり、練り上げられた議論というより考えながら話したものである。記事もそのように提示しており、著者はこの形式によって、それまで言葉にしてこなかったことを言語化するよう促されたと述べている。全体を通じて根拠となっているのは著者自身の実践と反応であり、計測ではない。また、これは著者自身の文章の中での変化も示している。以前の立場では、バイブコーディングを、責任ある使い方とは明確に区別された、狭く、レビューされない実践として位置づけていた。この記事が報告しているのは、用語の意味がずれていくことではなく、責任ある側から境界が侵食されていくことである。