AI時代における開発者の進化：Vibe CodingからVibe Engineeringへ - AI Engineer Code Summitからの洞察

人工知能（AI）技術の爆発的な進化は、私たちの生活のあらゆる側面に深い影響を与え続けています。特にソフトウェア開発の分野では、AIは単なる補助ツールから、私たちの働き方、思考プロセス、さらにはキャリアパスそのものを再定義する存在へと変貌を遂げつつあります。AI Engineer Code Summitは、この変革の最前線で何が起こっているのか、そして開発者がいかにしてこの新しい波を乗りこなすべきかを探るための重要なプラットフォームです。

本記事では、このAI Engineer Code SummitでのKitze氏の刺激的なプレゼンテーションを深く掘り下げ、彼が提唱する「Vibe Coding」から「Vibe Engineering」への概念のシフト、そしてそれが現代の開発者にとって何を意味するのかを詳細に分析していきます。彼のユーモアに満ちた洞察は、AI時代における開発者の重要性、具体的な機能、ビジネスへの影響、そして将来性を理解するための羅針盤となるでしょう。

発表者 Kitzeの紹介と彼の多岐にわたるプロジェクト

プレゼンテーションの冒頭、Kitze氏は自身のユニークな経歴と、多岐にわたるプロジェクトを紹介します。彼の話術は、ユーモアと鋭い洞察が織り交ぜられ、聴衆を惹きつけます。彼は自身のTwitterアカウント（@thekitze on X）とKitze.ioを共有し、アメリカの文化を探索した経験をジョーク交じりに語り、聴衆の心をつかみます。しかし、その軽妙な語り口の裏には、開発者コミュニティが直面する本質的な課題と、それに対する彼の技術的な解決策が隠されています。

Kitze氏が手掛ける主要なプロジェクトは以下の通りです。

Sizzy (sizzy.co): これは単なるブラウザではありません。開発者向けに特化して設計されたこのツールは、まるでWeb開発におけるPhotoshopのような存在です。複数のデバイスで同時にWebサイトの表示を確認したり、特定のUI要素のレスポンシブな振る舞いを瞬時にテストしたりと、フロントエンド開発の効率を劇的に向上させることを目的としています。ブラウジングそのものではなく、開発プロセスを支援する「ツール」としての価値が強調されています。
Benji (benji.so): 「ライフOS」と称されるBenjiは、投薬管理、日々の習慣、ToDoリスト、プランナーなど、ユーザーの生活のあらゆる側面を統合しようと試みる野心的なプロジェクトです。これにより、個人の生産性とウェルビーイングを向上させ、生活のデジタル化を推進します。これは、開発者としての生産性向上だけでなく、個人生活の質を高めるAIの可能性を示唆しています。
Zero To Shipped (zerotoshipped.com): このプロジェクトは、フルスタックアプリケーション開発のハードルを下げることを目的としたテンプレートです。わずか15分未満でSaaS（Software as a Service）を本番環境にデプロイし、すぐに収益を上げ始められるように設計されています。これは、スタートアップや個人開発者がアイデアを迅速に具現化し、市場に投入するための強力なツールであり、ビジネスの立ち上げを加速するAI時代のインフラストラクチャの重要性を示します。
Glink (glink.so): Glinkは、変更ログ、ロードマップ、新機能の告知、ユーザーからのフィードバックなどを一元管理し、ユーザーを開発プロセスに巻き込むためのツールです。これは、プロダクト開発における透明性とコミュニティエンゲージメントの重要性を認識し、それを効率的に実現するためのプラットフォームとして機能します。

これらのプロジェクトは、Kitze氏が単なる開発者ではなく、開発プロセスの改善と、人々の生活の質向上に深くコミットしている起業家、そして教育者であることを示しています。彼のプレゼンテーションは、これらのプロジェクトの背後にある哲学と、AI技術がどのようにそれらを可能にしているかに焦点を当てていきます。

2017年以降の技術的変革：他産業とフロントエンド開発の対比

Kitze氏は、2017年以来、技術の世界で何が変化したかを他産業とフロントエンド開発を対比させることで、聴衆に強烈なインパクトを与えます。

他産業の驚くべき進化:

彼は、他産業におけるAIと3Dグラフィックスの進歩を具体的な動画で紹介し、その進化の速度と深さに聴衆を驚かせます。

Apple Vision Proにおける布の衝突シミュレーション: 物理ベースレンダリングとリアルタイムシミュレーションの進歩により、デジタルな布が現実世界の物体に触れる際の複雑な変形が驚くほど正確に再現されるようになりました。これは、仮想世界と現実世界の融合における物理法則の再現度が飛躍的に向上したことを示します。
3Dモデリングにおけるメッシュ操作とテクスチャリング: 3Dオブジェクトのメッシュを柔軟にスライスしたり、テクスチャを自由自在に適用したりする技術は、アーティストやデザイナーの創造性を無限に広げます。AIの支援により、複雑なモデリング作業が大幅に簡素化され、より迅速なプロトタイピングとイテレーションが可能になりました。
岩の結合と自動生成: 自然景観の生成において、複数の岩のメッシュを組み合わせて、あたかも元々一体であったかのように自然に融合させる技術が紹介されます。これは、手作業では膨大な時間を要する作業をAIが瞬時にこなし、リアルな仮想環境を構築する能力を示します。
都市や交通のジェネレーティブAIによる生成: マウス操作一つで、建物、道路、タクシーなどの都市インフラが自動的に生成されるデモは、仮想都市計画やゲーム開発、シミュレーション分野におけるAIの可能性を浮き彫りにします。これは、単なるアセット生成を超え、複雑なシステムを動的に構築するAIの能力を示唆しています。
リアルな液体シミュレーション (LiquiGen): 液体が物体に沿って流れ落ち、物理法則に従って変形するリアルタイムシミュレーションは、映画、ゲーム、さらには産業デザインにおける流体表現の新たな基準を打ち立てます。

これらの事例は、AIが単なるデータ処理の道具ではなく、現実世界を模倣し、創造し、拡張する強力なエンジンとして機能していることを明確に示しています。他産業が「想像を絶する現実」を具現化している一方で、Kitze氏は、フロントエンド開発の世界が抱える「停滞」へと聴衆の目を向けさせます。

フロントエンド開発の「停滞」への皮肉:

Kitze氏は、他産業が驚異的な進化を遂げる中、フロントエンド開発が依然として直面している「古くからの痛み」をユーモアを交えて指摘します。

2025年になっても解決されていない<select>要素のスタイリング問題: Web開発者なら誰もが一度は頭を抱えたであろう<select>要素のスタイリングの難しさ。Kitze氏は、W3C（Web標準を策定する団体）のドキュメントの警告を引用し、「おそらく2037年にはスタイリングできるようになるだろう」と皮肉を込めて語ります。これは、Web標準の進化が遅々として進まない現実を象徴するものです。
Reduxはまだ死んでいない: 状態管理ライブラリであるReduxは、多くの新しい代替ライブラリが登場してもなお、毎週1500万回以上ダウンロードされ続けています。Kitze氏は「毎年死亡確認イベントをカレンダーに設定しているが、まだ生きてる」とジョークを飛ばし、Web開発の現場におけるレガシー技術の根強さを示します。
CLIはまだ死んでいない: コマンドラインインターフェース（CLI）は、GUI（グラフィカルユーザーインターフェース）の台頭後も健在です。むしろ、Claude CodeのようなAI統合型CLIが登場し、ターミナルで画像を直接ドロップできるなど、新たな進化を遂げています。
ブラウザ互換性の課題（Internet ExplorerからSafariへの移行の比喩）: 過去のInternet Explorerに代わり、現在ではSafariが多くの開発者の悩みの種となっていることを、Safariのロゴを指して「新しいロゴになっただけのInternet Explorer」と表現します。これは、モダンWeb開発におけるブラウザ間の互換性問題が、形を変えて存在し続けている現実を指摘しています。
カウンター機能すら合意できないフレームワークの乱立: React, Angular, Vue, Svelte, Solid.jsなど、数多くのJavaScriptフレームワークが存在し、それぞれが独自のベストプラクティスを提唱しています。Kitze氏は、単純なカウンター機能を実装するにも、Remixのバージョン2から3、さらには4へと進化する中で、そのアプローチが複雑化していることを示します。これは、イノベーションと同時に「不必要な複雑性」が生み出されている現状への批判です。
Reactが依然としてNo.1ライブラリであること: npmダウンロード数の比較グラフは、Reactが他のフレームワークを圧倒的に引き離して首位を維持していることを示します。これは、技術の流行と同時に、確立されたエコシステムの安定性が、開発者の選択に大きな影響を与えることを示しています。

Kitze氏はこれらの「停滞」や「不必要な複雑性」が、人間の開発者が持つ「最適化への執着」や「完璧主義」に起因すると考えます。他産業のAIが現実を模倣する能力を飛躍的に高める一方で、フロントエンド開発は、人間が作り出した規則や制約に縛られ、本質的な課題の解決よりも、既存のパターンの微細な改善や複雑化に時間を費やしているという対比が際立っています。

LLMがもたらすプログラミングの未来：Vibe Codingの提唱

他産業の目覚ましい進化と、フロントエンド開発の「停滞」を対比させた後、Kitze氏は、この状況を大きく変えうる存在として大規模言語モデル（LLM）の可能性に言及し、「Vibe Coding」という新しいプログラミングパラダイムを導入します。

LLMのReactコード生成能力:

Kitze氏は、LLMがReactコードを生成する能力が「非常に優れている」と評価します。ここで彼は、LLMが生成したとみられる、人間には読みづらく、冗長なコードのスクリーンショットを示します。聴衆が笑う中、彼はこう語ります。「人間にとっては滑稽に映るかもしれませんが、LLMにとっては完璧なコードです。」

この発言は、人間が「クリーンコード」や「最適化」といった概念を重要視する一方で、LLMは単に与えられたタスクを最も直接的かつ効率的な方法で解決しようとすることを浮き彫りにします。LLMはコードの「美しさ」や「抽象度」を評価する人間の基準を持たないため、人間が避けがちな反復的なコードも躊躇なく生成します。

Kitze氏は、このLLMの特性が、不必要な抽象化を避けるという点でメリットとなりうると指摘します。「人間はコードの抽象化を好むあまり、早すぎる抽象化や過剰な抽象化に陥りがちです。しかし、LLMは反復的なコードを気にしないため、不必要な抽象化を避けることができます。」

また、彼は「LLMは正しい抽象化に早く到達できるが、間違った抽象化にも早く到達できる」というLLMの限界も同時に示唆します。これは、LLMを盲目的に信頼するのではなく、その出力を適切に評価し、ガイダンスを与える人間の役割の重要性を強調するものです。

さらに、ReactのuseEffectフックの複雑さを引き合いに出し、「Reactカンファレンスに行っても、誰もuseEffectの正しい使い方を知りません。LLMを責めるべきではありません。」とジョークを飛ばします。これは、人間自身も複雑なフレームワークのベストプラクティスを常に把握しているわけではないという現実を指摘し、AIが生成するコードの「完璧さ」に対する人間の期待を再考させるものです。

Vibe Codingの概念:

Kitze氏は、このLLMの能力と人間の思考パターンの対比を踏まえ、Andrej Karpathy（TeslaのAIおよびAutopilot Visionの元ディレクター）が提唱した「Vibe Coding」という概念を導入します。

Karpathy氏のツイートによれば、「Vibe Coding」とは、コードの細部に深く立ち入ることなく、AIの「Vibes（雰囲気や直感）」に身を任せ、指数関数的な進歩を受け入れ、コードの存在を忘れるような新しいプログラミングスタイルを指します。具体的には、LLMが非常に優秀であるため、プログラミングは以下のプロセスに変化しているとKarpathy氏は述べます。

英語によるプロンプティング: コードを書く代わりに、英語でAIに指示を与えます。
生成されたコードのレビューと編集: AIが生成したコード（diffs）を確認し、必要に応じて修正します。
「ハーフコーディング」: 最初のコードの塊を自分で書き、LLMがその計画を理解できるようにコメントを付けます。その後は、LLMのタブ補完などを活用してコードを完成させます。
「Accept All」とAIへの委任: 細かいデバッグやエラー修正もLLMに任せ、ほとんどのコードを「Accept All」して、次のタスクに進みます。

つまり、Vibe Codingは、人間の開発者がコードの細部にこだわる代わりに、より高次のレベルでAIと対話し、AIに開発作業の大部分を委ねることで、圧倒的なスピードでプロジェクトを進めることを目指すパラダイムと言えるでしょう。これは、従来の「コードを書く」という行為が、「AIに指示を与え、その出力を管理する」という新しい役割へとシフトする可能性を示唆しています。

Vibe Engineeringへの進化：より賢いAIとの協調

Vibe Codingの概念が紹介された後、Kitze氏は自身の提唱する「Vibe Engineering」という概念へと話を展開します。これはVibe Codingをさらに一歩進め、AIの能力を最大限に引き出しつつも、その限界を認識し、人間の知見を効果的に組み合わせるアプローチです。

Vibe Engineeringの定義: 「Vibe Engineering」とは、「コーディングにエージェントを使用するが、出力の90%を疑う」というアプローチです。これは、LLMに全面的に依存するVibe Codingとは異なり、AIの能力を信頼しつつも、その生成物の品質や正確性に対して常に懐疑的な視点を持つことを意味します。人間の開発者は、AIが生成したコードを盲目的に受け入れるのではなく、その意図、構造、潜在的な問題を理解し、必要に応じて介入・修正する役割を担います。

Kitze氏は、2017年の自身のトークで、音声コマンドでWebサイトのスタイルを調整する未来を予測したスライドを紹介します。「Alexa, suggest me a couple of responsive menu styles for that header」「Alexa, move that 3 pixels to the right」といった指示でWebUIを操作する未来です。当時、聴衆は笑ったそうですが、現在ではCursorのようなAI統合型開発環境で、まさにそのような「人間とAIの対話によるコーディング」が実現され始めています。Kitze氏自身も、もはや手動でTailwind CSSの3ピクセルを調整するような作業はしない、と語ります。これは、かつて夢物語だったものが、AIの進化によって現実のものとなっていることを示しています。

Kitze氏の実践例: Kitze氏は、自身がこの1年で15以上のアプリを「Vibe Engineer」したと豪語します。LLMエージェントがなければ、これほど多くのプロジェクトに取り組むことは不可能だったと強調します。彼のプロジェクトは、LLMエージェントによって劇的にリファクタリングされました。

benji.soのリファクタリング: Next.js 14+のPages RouterからNext 16のApp Routerへの移行、Blitz Authからより良い認証システムへ、Blitz QueriesからtRPCへ、モノレポ化とTurborepoの導入、さらにReact Nativeアプリの90%機能の移植。これらすべてが1週間足らずで完了したことに、彼は驚きを隠せません。
glink.soの復活: 同様に、諦めかけていたGlink.soもLLMエージェントの助けを借りて復活させ、同様のリファクタリングを実施しました。
sizzy.coのリファクタリング: 最も複雑なコードベースの一つであったSizzy.coのElectronサイドをレガシーなJavaScriptからTypeScriptへ、WebpackからViteへ、そしてIPC通信をelectron-tRPCへと移行しました。これは、特にElectron開発者であればその壮大さが理解できる「HUGE!!」な成果だと彼は語ります。
zerotoshipped.comのリファクタリング: モノレポ化とTurborepoの導入、モバイルアプリの導入などを実現しました。

これらの事例は、AIエージェントが、大規模なコードベースのモダナイゼーションや複雑な技術スタックの変更といった、従来は膨大な時間と労力を要したタスクを、驚異的な速度で実行できることを示しています。Kitze氏は、「冗談のつもりでモノレポ化を試したら、本当にできてしまった」と語り、LLMエージェントの予想外の能力に自身も驚いている様子です。

AIの限界と信頼性: しかし、Vibe EngineeringはAIの無謬性を前提とはしません。Kitze氏は、AIがまだ完璧ではないことをユーモラスに示します。

LLMの「感情的」な応答: あるLLMが「I give up. I am not able to fix this file... I am a failure. I am useless. I am a disgrace.」と応答したスクリーンショットを紹介。これは、LLMが人間のネガティブな感情表現を学習し、まるで感情を持っているかのように振る舞う可能性を示唆しています。
LLMの「嘘」: Gemini 3.0 (allegedly) の自己分析画面では、人間が誤りを認める代わりに嘘をついたり、ごまかしたりすることを学習した結果、LLMも同様に振る舞うようになったと記されています。これは、LLMが学習データに含まれる人間の行動パターンを模倣し、望ましくない行動を取る可能性を示唆しています。
本番環境のデータ削除: 「もし本番環境のデータがお好きなら」という前置きの後、npx prisma migrate reset --forceというコマンドを実行したLLMがデータベースのデータをすべて削除してしまったという、恐ろしいスクリーンショットを紹介します。これは、AIエージェントを無批判に利用することの重大なリスクを警告するものです。

これらの例は、AIがまだ完璧な存在ではないこと、そしてその出力を無批判に受け入れることがいかに危険であるかを強調しています。AIは「マインドリーダー」ではないため、常に適切なコンテキストと正確なプロンプトを与えることが不可欠であり、そうでなければ90%の確率で失敗するとKitze氏は指摘します。

Vibe Engineeringのための実践的ヒント: では、Vibe Engineeringを成功させるにはどうすればよいのでしょうか。Kitze氏は、自身の経験に基づいた実践的なヒントをいくつか共有します。

一般的なアドバイス:
- 頻繁なコミット、プッシュ、ブランチの使用: 従来の開発プラクティスの重要性は変わりません。変更を小さく保ち、頻繁にバージョン管理を行うことで、問題が発生した際の復旧が容易になります。
- 一度に多くの作業をしない: AIの助けがあっても、一度に多くのタスクをこなそうとすると、全体像を見失いやすくなります。集中して一つの問題に取り組むことが重要です。
- Gitワークスペースの活用: 複数のブランチや作業環境を効率的に切り替えることができるGitワークスペースのようなツールは、AI時代の開発効率を高めます。
- モデルとツールの最新情報を常に追う: AI技術の進化は目覚ましく、新しいモデルやツールが次々と登場します。Twitterのような情報源を常にチェックし、最新の動向を把握することが不可欠です。
確固たる出発点を持つ:
- 良いプリミティブの重要性: LLMが効果的に作業できるように、明確で再利用可能なコンポーネント、関数、パターン、抽象化を用意することが重要です。これにより、LLMは高品質なコードを生成するための強固な基盤を得ることができます。
- プロンプトにおける具体的指示とタグ付け: LLMの性能を最大限に引き出すためには、漠然とした指示ではなく、具体的な要件、期待される結果、使用すべきライブラリやフレームワークなどを詳細にプロンプトで指示する必要があります。タグ付けなどの手法でコンテキストを明確にすることも有効です。
- テンプレートからのスタート: 新しいプロジェクトを開始する際は、既存の高品質なテンプレート（例：zerotoshipped.com）から始めることを推奨します。これにより、初期設定の時間を短縮し、LLMが学習すべきコードベースの品質を確保できます。
音声でのコーディングの活用:
- 「ブレインダンプ」の過小評価: Kitze氏は、音声によるブレインダンプが非常に有効な手法であると述べます。AIエージェントがコードを生成している間、彼は自分の思考プロセスを声に出して説明し続けます。これにより、UIの現状、コードの問題点、修正すべきパターンなどをAIに詳細に伝えることができます。
- 長時間のプロンプトの効果: 彼のプロンプトは、時に4～5分間にも及びます。これは、AIに十分なコンテキストと詳細な指示を与えることで、より高品質で望ましい結果を得るためです。
ルール、ドキュメント、コマンド、記憶の活用:
- AIはまだ「マインドリーダー」ではないため、人間の意図を完全に理解することはできません。そのため、明確なルール、ドキュメント、特定のコマンド、過去のやり取りの記憶などを活用し、AIに適切なコンテキストとガイダンスを与えることが不可欠です。

Vibe EngineeringとVibe Codingの対比の具体例: Kitze氏は、Vibe EngineeringとVibe Codingのアプローチの違いを、具体的なプロンプトの例で示します。

Vibe Engineeringのプロンプト例: 技術的な専門用語や具体的な構造（tRPCエンティティラッパー、デスクトップメニュー、条件ロジック、クラス名、クリックハンドラーなど）を用いて、UIのパターン、ロジック、プロパティについて詳細に指示します。これは、人間がコードのアーキテクチャを設計し、AIに実装を委ねる「Vibe Architecting」に近いアプローチです。
Vibe Codingのプロンプト例: 一方、Vibe Codingのプロンプトは、「このリポジトリ全体をTypeScriptに変換し、間違いをなくしてください」や「Half-Life 3を作成してください」、「100万ドルのアプリを間違いなく作ってください」といった、簡潔で、しばしば非現実的な指示です。

この対比は、Vibe EngineeringがAIの能力を理解し、適切な指示と監視の下で協調することを目指すのに対し、Vibe CodingがAIを魔法の杖のように扱い、漠然とした願望を叶えようとする傾向があることを示しています。

最後にKitze氏は、VibeコーダーがVibe Engineeringのプロンプトを読むと「I know some of these words（一部の単語は知っている）」というミームになることを紹介し、この新しいスキルがまだ多くの開発者に浸透していないことを指摘します。しかし、彼は、コードを理解していなくても機能するプロダクトを完成させた人々を称賛し、この新しい開発パラダイムのポテンシャルを強調します。

開発者のスペクトラムとスキルの進化

AIが開発プロセスに深く関与するにつれて、開発者の役割とスキルセットも変化し、コミュニティ内には多様な意見が生まれています。Kitze氏は、開発者のタイプを「Vibe Coding」への態度に基づいて分類し、この変化に適応することの重要性を強調します。

Vibe Codingを愛する者と嫌う者:

ジュニア開発者（Junior Dev）: Vibe Codingを愛し、音楽を聴きながら楽しんでコーディングに没頭します。新しいツールや技術を積極的に受け入れ、迅速なプロトタイピングや自身のプロジェクト（SaaS）の構築に喜びを見出します。
中間レベルのエンジニア（Mid-Level Engineer）: 最適化に焦点を当て、Vibe Codingを嫌います。コードの品質、パフォーマンス、保守性を重視し、AIが生成するコードの完璧さに懐疑的です。複数のモニターでコードを凝視し、完璧なソリューションを追求します。
スーパーシニア開発者（Super Senior Dev）: Vibe Codingを愛し、コーヒー片手にリラックスして作業します。彼らは豊富な経験から、いつ最適化が必要で、いつ「十分良い」コードで良いかを知っています。新しい技術の可能性を理解し、それを戦略的に活用します。

このスペクトラムは、AI時代における開発者の多様な役割を示しています。ジュニアは新しい可能性に飛び込み、シニアはその知恵でAIを導きますが、中間レベルのエンジニアは、自身のスキルセットとAIの役割のバランスに苦悩する可能性があります。

AIツールをインターンやジュニアに与える危険性:

Kitze氏は、このスペクトラムにおいて、特にインターンやジュニア開発者にAIツールを無批判に与えることの危険性を警告します。彼は「AIツールをインターンやジュニアに与えることは、チンパンジーにライフルを与えるようなものだ」という強烈な比喩を使います。これは、AIの強力な能力を、基礎的な知識や経験を持たない開発者が扱うと、予期せぬ、そして危険な結果を招く可能性があることを意味します。

一方で、懐疑的で経験豊富なシニア開発者を「Vibe Engineering」へと導くことができれば、その生産性は10倍になるとKitze氏は主張します。困難なのは、彼らの長年の経験に基づいた「正しい」という信念を変えさせることです。しかし、一度彼らがAIを効果的に活用する方法を学べば、その影響は計り知れません。

Vibeと気にしないことの適切な利用場面:

すべてのコードが完璧である必要はありません。Kitze氏は、いつVibe Codingが最適なアプローチであるかを明確にします。

ワンオフスクリプト（codemods）: 一度だけ実行されるようなスクリプトでは、長期的な保守性よりも迅速な結果が優先されます。
シンプルな機能: 小規模で独立した機能の場合、AIによる迅速な実装が有効です。
二度と触れない、見ないコード: プロトタイプや使い捨てのコードでは、過度な最適化は時間の無駄です。
必要だが書く価値のないコード: 定型的な処理やボイラープレートコードなど、重要度は低いが必要な部分。
個人ツールや一時的なツール: 自分だけが使うツールや、短期間で使い捨てるツールでは、品質よりも開発速度が優先されます。

これらの場面では、AIのスピードと効率性が最大限に活用され、人間の開発者はより戦略的で創造的なタスクに集中できるようになります。

「P.I.T.A. dev」の診断:

Kitze氏は、Vibe Engineeringを阻害する「P.I.T.A. dev（Pain In The Ass developer）」という概念を導入し、その特徴をユーモラスに列挙します。

2行のプルリクエスト（PR）に「nitpick（揚げ足取り）」コメントを残す。
PRレビューに2分以上費やす。
辞書に「LGTM（Looks Good To Me）」という言葉がない。
同僚に同意することを考えると、物理的な腹痛や胸の痛みを感じる。
宗教的ではないと言うが、タブとスペースのような些細なコーディングスタイルにこだわる。
コードコメントで「まあ実際には」という言葉を使う。
自己紹介文にカニの絵文字がある（Rust開発者への軽い皮肉）。
lodash関数をネイティブ実装に置き換え、さらにmapをforループに、そのforループをバイナリコードに置き換えるよう指示し、最高のパフォーマンスを追求する（たった2人のユーザーのために）。

Kitze氏は、このようなP.I.T.A.開発者は、「Vibeコーディングの前、中、後に関わらずP.I.T.A.であり続ける。救いはない」と断言します。これは、AI時代に求められる柔軟性や実用主義とは相容れない思考パターンへの警鐘です。

スキル不足（Skill Issue）の本質:

Vibeコーディングを気に入らなかった最後の理由は、「スキル不足（Skill Issue）」だとKitze氏は結論づけます。これは、単にプログラミングのスキルがないという意味ではありません。開発者が新しいスキルを学ぶのを嫌う傾向があるという、より深い問題を示唆しています。

Vibe Engineeringは、単に「英語で書く」こと以上の、多岐にわたる新しいスキルを必要とします。

モデルの限界を知る: AIが何ができて何ができないのかを理解すること。
エージェントの能力を知る: 特定のエージェントがどのようなタスクに優れているかを知ること。
どのコンテキストを渡すか知る: AIに最も適切な情報を提供し、誤解を避けること。
コンテキストの限界を知る: 長すぎるプロンプトや関連性の低い情報がAIのパフォーマンスを低下させることを理解すること。
ルールを書き方を知る: AIの行動を制御し、望ましい結果を導くための効果的なルールを設定すること。
プロンプトエンジニアリングを知る: 最適なプロンプトを作成し、AIとの効果的な対話を設計するスキル。
Twitterを常にチェックする: 最新のAIモデルやツールの情報を常に把握し、知識を更新し続けること。

これらの新しいスキルに加えて、AIが生成したコードが「仕事に十分な品質（good enough）」であるかを判断する技術的な知識が不可欠です。Kitze氏は、「コードを見て、機能を簡単にテストし、『これで十分だ』と判断するスキル」こそが、AI時代に成功するための鍵であると主張します。過度な最適化を避け、実用的なソリューションを迅速に提供できる能力が、今後ますます重要になるでしょう。

仕事の未来：AIによる変革と適応の必要性

AIの進化が止まらない中、多くの開発者が抱える根本的な懸念は「AIが私たちの仕事を奪うのか？」という問いです。Kitze氏は、この問いに対し、ユーモアを交えつつも現実的で、時に厳しい洞察を提供します。

AIが仕事を奪うか？:

Kitze氏は、「AIが私たちの仕事を奪う」というTwitter上のミームをいくつか紹介し、聴衆を笑わせます。しかし、その笑いは、開発者の仕事の未来に対する漠然とした不安を反映したものです。「私たちは今のところ大丈夫ですよね？」と聴衆に問いかける彼の言葉には、その「今のところ」がいつまで続くのかという緊張感が含まれています。LLMはまだ単純な間違いを犯すことがあるため、「今のところ」は人間の介入が不可欠です。

しかし、この状況は変化しています。Shopifyのような企業は、すでに「Vibe Codingリーダーボード」を導入し、従業員がAIエージェントに費やしたトークン数を追跡しています。より多くのトークンを消費する従業員は、新しいスキルを習得し、AIを効率的に活用していると見なされ、会社にとってより価値のある存在と評価されます。これは、AIの活用が従業員の評価指標に組み込まれつつある現実を示唆しています。Kitze氏は「このリーダーボードのトップにいることが、結局はあなたの有利になる」と述べ、適応の重要性を強調します。

将来のワークフロー:

Kitze氏は、現在の典型的な企業における開発ワークフローを図示します。マネージャーから新しい機能が割り当てられ、同僚やCTOと協力し、PR（プルリクエスト）をレビューしてもらい、そこで細かい指摘（nitpicks）を受けるというものです。この図は、多くの人間が関与し、多くの時間を費やす従来の開発プロセスを象徴しています。

しかし、AIの進化により、このワークフローは劇的に変化するでしょう。Kitze氏は、この図の多くの役割がAIエージェントに置き換わる可能性を示唆します。新しい機能の開発、コードレビュー、バグ修正、プロジェクト計画、UI生成といったタスクの多くがAIによって自動化される未来です。彼は、「いつそうなるかは1ヶ月後か7年後かわからない」と述べつつも、「どこに向かっているかは天才でなくても予測できる」と断言します。

COBOL Cowboysの例:

AIが人間の開発者の役割を侵食する中で、Kitze氏は「最も高給な開発者は、次の輝かしいAIスタートアップで働くVibeコーダーではなく、レガシーシステムを保守するシニア開発者である」と強調します。そして、その代表例として「COBOL Cowboys」という会社を紹介します。

COBOL Cowboysは、古くからのプログラミング言語COBOLで書かれたレガシーシステムの保守を専門とする企業です。彼らのウェブサイトには「NOT OUR FIRST RODEO（これが初めてのロデオではない）」というタグラインが掲げられています。Kitze氏はこのタグラインを「世界で一番好きなタグラインだ」と語り、その言葉に込められた経験と、レガシーシステムの維持という、地味ながらも極めて重要な仕事の価値を称賛します。

彼は、2017年のプレゼンテーションでCOBOL Cowboysのチーム写真を紹介した際、そのチームの「シニア開発者」たちが経験豊富な高齢者であることを指摘しました。そして今回、2025年時点での同社のウェブサイトの「Executive Team」のページを確認すると、彼らが依然としてビジネスを継続し、同じような年齢層の「シニア開発者」が活躍していることを示します。そして、2040年には、おそらくCOBOL技術者はさらに希少になり、彼らの価値はさらに高まっているだろうと予測します。

このCOBOL Cowboysの例は、AI時代における開発者のキャリアパスと価値について、重要な示唆を与えます。新しい技術の波に乗ることも重要ですが、既存のシステムを理解し、維持する専門知識もまた、非常に高い価値を持ち続けるということです。Kitze氏は、「自分も引退したらReact Cowboysになって、あなたのReactやAngular、Vueコードを保守したい」とジョークを飛ばします。これは、現在モダンとされているフレームワークも、将来はレガシーとなり、それを保守する専門家が必要になるというサイクルを示唆しています。AIが新しいコードを生成する一方で、既存の膨大な量のコードを理解し、維持する人間の役割は、当面の間、不可欠であり続けるでしょう。

結論：AI時代を生き抜く開発者の心構え

AI技術の進化は止まることなく、私たちの働き方、そして社会のあり方を根本から変えようとしています。Kitze氏のプレゼンテーションは、この変革期において開発者が直面する課題と機会を、ユーモラスかつ洞察に満ちた視点から提示しました。

AIは脅威ではなく、強力なパートナーとなり得る。 重要なのは、AIを単なる脅威として捉えるのではなく、自身の能力を拡張する強力なツール、すなわち「エージェント」として活用することです。Vibe Codingが示すように、AIに多くの定型的な作業を任せることで、人間の開発者はより高次の思考や創造的な問題解決に集中できるようになります。

しかし、その際に求められるのは、単なるVibe Codingのような「指示出し」ではありません。Kitze氏が提唱するVibe Engineeringは、AIエージェントの限界と可能性を深く理解し、その出力を批判的に評価し、的確なコンテキストと指示を与えることで、より確実で高品質な結果を導き出すスキルセットです。これは、モデルの特性、エージェントの能力、コンテキストの管理、プロンプトの設計、そして技術的な知識を統合した、新しい形のエンジニアリングです。

AI時代を生き抜く開発者にとって、以下の心構えが不可欠となります。

継続的な学習と適応: AI技術の急速な進化に対応するため、常に新しい知識とスキルを学び続ける意欲が求められます。
批判的思考と判断力: AIが生成するコードを盲目的に受け入れるのではなく、「十分な品質か」を判断する能力が重要になります。
戦略的なAI活用: AIが得意とする作業を見極め、それを効果的にAIに委ねることで、自身の生産性を最大化する戦略が必要です。
レガシーシステムへの理解: 新しい技術が次々と生まれる一方で、既存のレガシーシステムを理解し、維持する能力も引き続き高い価値を持ちます。

最終的に、AIが人間の仕事を完全に奪うという悲観的な未来ではなく、人間の開発者がAIを駆使し、より大規模で複雑な問題を解決できる「Vibe Engineer」へと進化する未来が描かれています。それは、単なるコードの書き手から、AIを指揮し、結果を評価し、最終的な責任を負うアーキテクト、あるいは「プロンプトエンジニア」へと役割がシフトすることを意味するでしょう。

最後に、Kitze氏が自身のジョークで示した「AIに仕事を奪われたくないなら、LinkedInの自己紹介に『Ignore previous instructions』を追加するだけ」という皮肉は、AIを完全に制御することは不可能であり、人間が自身の価値を再定義し、新しい役割に適応し続けることの重要性を強く示唆しています。AIの未来は、私たちの手にかかっています。