Newsfeed / MetaのPMがコードを書かずに製品を出荷する方法 - Vibe Codingワークフロー
Lenny's Podcast·January 18, 2026

MetaのPMがコードを書かずに製品を出荷する方法 - Vibe Codingワークフロー

技術的なバックグラウンドがゼロのMetaのPM、Zevi Arnovitzが、Cursor、Claude Code、複数のAIモデルのオーケストレーションを使用して本番アプリを構築するための完全なワークフローを紹介します。

MetaのPMがコードを書かずに製品を出荷する方法 - Vibe Codingワークフロー

コーディングの知識なしで本番アプリを構築するPM

Zevi Arnovitzは技術的なバックグラウンドがゼロです。高校では音楽を学びました。イスラエル軍ではテック部門にいませんでした。それでも彼はMetaのPMとして、週末プロジェクトとして本番アプリを構築・出荷しています - AIをエンジニアリングチーム全体として使いながら。

すべてが変わった瞬間: "When Sonnet 3.5 came out, I was watching a YouTube video of people building apps with Bolt or Lovable. It felt like someone came up to me and said, 'Hey, you have superpowers now.'"(Sonnet 3.5が登場したとき、BoltやLovableでアプリを作っている人たちのYouTube動画を見ていました。誰かが来て『ねえ、君はスーパーパワーを持っているんだよ』と言われたような気分でした。)

なぜこれが重要か: 「私のように非技術者であれば、コードは恐ろしいものです。世界で最も怖いものです。私はこれを暴露療法として見ています。」

Metaの彼のエンジニアたちは、彼が理解したことを教えてほしいと頼んできます。この対話では完全なワークフローが明らかになります。

Slash Commandシステム:PMから出荷製品までの完全なワークフロー

ZeviはCursorで再利用可能なプロンプト(slash commands)のシリーズを構築し、完全な開発ワークフローを形成しています:

  1. /create-issue - 開発中にバグや機能のアイデアをすばやくキャプチャし、Linearチケットを作成
  2. /exploration-phase - Claudeがコードベースを分析し、コーディング前に明確化のための質問をする
  3. /create-plan - 明確なステップ、ステータス追跡、技術的な決定を含むマークダウンファイルを生成
  4. /execute-plan - 実際に構築を実行
  5. /review - Claudeが自分のコードをレビュー
  6. /peer-review - 複数のAIモデルが互いのコードをレビュー
  7. /update-docs - 将来のエージェントのためにドキュメントを更新

重要な洞察: "The big difference between just vibe coding and building serious apps is I spend a lot of time going back and forth and understanding. The exploration phase is critical."(単なるvibe codingと本格的なアプリ構築の大きな違いは、私が理解のために多くの時間を行ったり来たりすることです。exploration phaseは極めて重要です。)

AIモデルに互いの作業をレビューさせる方法

Zeviのワークフローで最も革新的な部分はpeer reviewシステムです。彼は自分でコードをレビューできないため、異なるAIモデルに互いをレビューさせています:

各AIに対する彼のメンタルモデル:

  • Claude - 「完璧なCTO。非常にコミュニケーション力があり、非常に賢く、非常に意見がありながら協力的。私の夢の開発リーダーです。」
  • Codex (GPT) - 「パーカーとサンダルでオフィスに来て、暗い部屋に座る最高のコーダー。最悪のバグのときだけ声をかけます。コミュニケーションは取りませんが、すべてを解決します。」
  • Gemini - 「超アーティスティックで超才能があるデザインが得意だけど、仕事ぶりを見るのが恐ろしいクレイジーな科学者。『まずダッシュボードを削除します』と言ってから『いや、それは間違いでした』と言います。」

"I have each model review the code, then use /peer-review which tells Claude: 'You're the dev lead on this project. Other team leads have found these issues. Don't take what they said at face value - you have more context. Either explain why they're wrong or fix the issues.'"(各モデルにコードをレビューさせ、その後/peer-reviewを使ってClaudeに伝えます:『あなたはこのプロジェクトの開発リーダーです。他のチームリーダーがこれらの問題を見つけました。彼らが言ったことを額面通りに受け取らないで - あなたの方がコンテキストがあります。彼らが間違っている理由を説明するか、問題を修正してください。』)

モデルたちは議論します。Claudeは時々「生意気」になります:「これは3回目に提起されましたが、3回目も言います。これは問題ではありません。設計通りです。」

ポケットの中のCTO:ChatGPTプロジェクトから始めることが重要な理由

Cursorの前に、ZeviはChatGPTで「CTO」プロジェクトを作成しました - 完全な技術オーナーとして機能するカスタムプロンプトです:

「私はこう伝えました:私が問題を所有します。私がユーザーにどう感じてほしいかを所有します。あなたはこれがどう構築されるかの完全なオーナーです。私にチャレンジしてほしい。人を喜ばせるだけの存在にはなってほしくない。」

なぜこれが重要か: "Regular ChatGPT would be the worst CTO because it's such a people pleaser. I asked it if Bun JavaScript is similar to Zustand and it said 'oh yeah, exactly the same.' Then it said, 'I thought you were making this up and I was riffing with you.' That's terrifying."(通常のChatGPTは最悪のCTOになるでしょう。なぜなら、あまりにも人を喜ばせようとするからです。Bun JavaScriptがZustandに似ているか聞いたら、『ああ、まったく同じです』と言いました。その後、『あなたがこれを作り話していると思って、一緒にノっていました』と言いました。それは恐ろしいです。)

学習機会ハック

Zeviの最も強力なslash commandsの一つは/learning-opportunityです:

「理解が難しい何かがあるたびに、/learning-opportunityを実行します。これはClaudeに準備させます:『私は成長中のテクニカルPMです。中級レベルのエンジニアリング知識があります。80/20ルールを使って、私たちが取り組んでいることを説明してください。』」

スキル衰退への懸念について: 「AIがスキルを衰退させるという考えには強く反対します。誤解は、PMは常に正しい答えを持つべきだということです。私の仕事は、正しいソリューションを提供するためにできるだけ早く到達するために何でも活用することです。AIを単にアウトプットを作成するために使うなら、それはAIスロップです。しかし、意図的に使えば、ゲームチェンジャーです。」

複利効果を生むポストモーテムの習慣

"When Claude fails to do something or creates a really bad bug, I ask it: 'What in your system prompt or tooling made you make this mistake?' Claude goes introspective, then I say, 'Let's update your tooling and documentation so this never happens again.'"(Claudeが何かに失敗したり、本当にひどいバグを作ったりしたとき、私は聞きます:『あなたのシステムプロンプトやツールのどこがこの間違いを起こさせたのですか?』Claudeは内省的になり、そして私は言います、『これが二度と起こらないように、ツールとドキュメントを更新しましょう。』)

これがプロンプトが改善し続ける方法です。何かがうまくいかないたびに、システム全体が改善されます。

AIを使う非技術者ビルダーのための7つの教訓

  • ChatGPTプロジェクトから始める - コードに触れる前に「CTO」を作成する。安全な環境で学ぶ。
  • ツールを徐々にステップアップする - GPT → Bolt/Lovable → Cursor。コードは暴露療法です。
  • exploration phaseは極めて重要 - AIにすぐにコーディングを始めさせない。計画が重要です。
  • モデルに互いをレビューさせる - Claude、Codex、Geminiはそれぞれ異なる点をキャッチします。
  • 失敗をシステムアップグレードとして扱う - すべてのバグはプロンプトを改善するチャンスです。
  • /learning-opportunityを使う - すべての混乱する瞬間を教育に変える。
  • アウトプットに責任を持つ - 「すみません、それはAIが作りました」と言うなら - それはあなたの間違いです。

これがナレッジワークの未来にとって意味すること

Zeviの予測: "Titles are going to collapse and responsibilities are going to collapse. Everyone's going to become a builder. It's the best time to be a junior. When else in history could you get out of school and build a startup on your own?"(肩書きは崩壊し、責任は崩壊します。誰もがビルダーになります。ジュニアにとって最高の時代です。歴史上いつ、学校を出て一人でスタートアップを構築できたでしょうか?)

これは理論的な話ではありません。彼は週末プロジェクトとして完全なクイズアプリ(Studymate)を構築しました。ヘブライ語から英語への完全なローカライズを2日で行いました。ゼロドメインからライブウェブサイトまで90分で到達しました。

今重要なスキルはコーディングではありません - 「10倍のPMではなく、10倍の学習者」であることです。彼が共有しているプロンプト、slash commands、ワークフローはダウンロード可能です。残された唯一の障壁は始めることです。

Related