Kitze：なぜ「Vibe Engineering」は機能し「Vibe Coding」は機能しないのか

KitzeがVibe EngineeringとVibe Codingを区別する理由

KitzeはSizzy（開発者向けブラウザ）、Zero to Ship、その他いくつかのツールの作成者です。このカンファレンストークでは、「vibe coding」（AIの出力を何でも受け入れる）と「vibe engineering」（技術知識でエージェントを操縦する）を区別しています。彼の論点：スキル分布の中央にいる懐疑論者は間違っており、それを愛するジュニアとマスターするシニアは両方正しい - 異なる理由で。

採用のスペクトルについて： “On one hand you have juniors who are like ‘hell yeah, give me the thing, I love doing my own SaaS.’ Then you have super senior people doing libraries and frameworks. And then you have the majority in the middle like ‘this will never be good enough, my code is perfect.’ It’s hilarious, but it’s a pattern.”（一方にはジュニアがいて「最高、それをくれ、自分のSaaSを作るのが大好き」と言います。そして超シニアの人々がライブラリとフレームワークを作っています。そして大多数が真ん中にいて「これは十分に良くならない、私のコードは完璧だ」と言います。面白いですが、パターンです。）分布は二峰性です：熱狂的な初心者と経験豊富な実践者、間に懐疑的な中間層。

Vibe engineeringとは実際何かについて： “I’m not vibe coding. I love this term someone coined—vibe engineering. When you’re actually using agents to code all the time but you just look at your screen like ‘I’m going to catch you.’ You’re suspicious of the code because it’s based on our knowledge.”（私はvibe codingをしていません。誰かが作ったこの用語が好きです - vibe engineering。実際に常にエージェントを使ってコーディングしているが、画面を見て「捕まえてやる」と思っている。私たちの知識に基づいているのでコードを疑っているのです。）区別：vibe coderは盲目的に受け入れ、vibe engineerは積極的に監督します。

Composer Oneがすべてを変えたことについて： “Composer One made me realize I missed coding. What I would do is let a model run like GPT-5 Codex and it would take 37 years. Now I’m back in the driver’s seat. I can be like ‘Stop. No no no. We do the other thing.’ It feels like coding.”（Composer Oneは私がコーディングを恋しく思っていたことに気づかせてくれました。GPT-5 Codexのようなモデルを実行させると37年かかりました。今は運転席に戻りました。「止まれ。違う違う違う。別のことをしよう」と言えます。コーディングのように感じます。）フィードバックループの速度はモデル能力よりも重要です。

PA devs（面倒くさい開発者）について： “You leave a nitpick comment on a two-line PR. You spend more than 2 minutes on a PR review. The thought of agreeing with a colleague causes stomach pain. You say ‘well actually’ in code comments.”（2行のPRに細かいコメントを残す。PRレビューに2分以上かける。同僚に同意することを考えると胃が痛くなる。コードコメントで「実は」と言う。）AI採用の最大の障壁は能力ではありません - すでに逆効果だった完璧主義です。

実際の生産性向上について： “I achieved in two weeks more than I achieved in last year. This was solely due to Composer One. I was about to abandon projects… I moved Benji to Next 16 with App Router, TRPC, Monorepo, Turbo Repo, React Native app, and put in 90% of the features—in less than a week.”（2週間で去年より多くを達成しました。これは完全にComposer Oneのおかげです。プロジェクトを放棄しようとしていました…BenjiをNext 16、App Router、TRPC、Monorepo、Turbo Repo、React Nativeアプリに移行し、90%の機能を入れました - 1週間もかからずに。）速度は、そうでなければ存在しないプロジェクトを可能にします。

KitzeによるAI支援開発の6つの洞察

• Vibe engineering ≠ vibe coding - Vibe codingは盲目的に出力を受け入れる; vibe engineeringは技術知識でエージェントを監督し、リアルタイムでエラーを捕まえる
• AIをジュニアではなくシニアに与えよ - 「AIツールをインターンやジュニアに与えないでください。懐疑的なシニアを説得してvibe engineeringをさせれば、10倍の結果が得られます」
• Composer Oneはパラダイムシフト - 高速なフィードバックループは運転席にいることを可能にする; 遅いモデルは待っている間にYouTube Shortsを見させた
• PA devsが本当のブロッカー - 最適な抽象化を要求し2行のPRを細かく批評する完璧主義は、AIの有無にかかわらず逆効果
• LLMは反復的なコードを気にしない - これは機能です：人間は早すぎる抽象化をしすぎ、LLMは適切なときに喜んで複製する
• スキル要件は変わった、消えていない - モデルの限界、コンテキスト管理、プロンプトエンジニアリング、「十分に良い」コードを判断することを知ることが新しい必須スキル

開発者の生産性にとっての意味

Kitzeのトークは、AIコーディングの議論をリフレームします：問題はAIの能力ではなく、人間の完璧主義です。「Vibe coding」は監督されていないギャンブルなので失敗します。「Vibe engineering」は、AIの速度と何が十分に良いかについての人間の判断を組み合わせるので機能します。皮肉：コード品質について（過度に抽象化する完璧主義者よりも）すでに実用的だった開発者が成功しています。スキルは英語を書くことではありません - コードがいつ十分に良いかを知ることであり、それは常にエンジニアリングの最も難しい部分でした。