Cómo un PM de Meta lanza productos sin escribir código - El flujo de trabajo del Vibe Coding

El PM que construye aplicaciones en producción sin saber programar

Zevi Arnovitz no tiene experiencia técnica. Estudió música en la secundaria. No estuvo en una unidad tecnológica del ejército israelí. Sin embargo, es un PM en Meta que construye y lanza aplicaciones en producción como proyectos de fin de semana - usando IA como su equipo de ingeniería completo.

El momento en que todo cambió: "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.'" (Cuando salió Sonnet 3.5, estaba viendo un video de YouTube de gente construyendo apps con Bolt o Lovable. Se sintió como si alguien se me acercara y dijera: 'Oye, ahora tienes superpoderes.')

Sobre por qué esto importa: "Si no eres técnico como yo, el código es aterrador. Es lo más aterrador del mundo de ver. Lo veo como terapia de exposición."

Sus ingenieros en Meta le piden que les enseñe lo que ha descubierto. Esta conversación revela el flujo de trabajo completo.

El sistema de Slash Commands: Un flujo de trabajo completo de PM a producto lanzado

Zevi ha construido una serie de prompts reutilizables (slash commands) en Cursor que forman un flujo de desarrollo completo:

1. /create-issue - Captura rápidamente un bug o idea de feature durante el desarrollo, crea un ticket en Linear
2. /exploration-phase - Claude analiza el codebase y hace preguntas de clarificación antes de cualquier código
3. /create-plan - Genera un archivo markdown con pasos claros, seguimiento de estado y decisiones técnicas
4. /execute-plan - Realmente construye la cosa
5. /review - Claude revisa su propio código
6. /peer-review - Múltiples modelos de IA revisan el código de los demás
7. /update-docs - Actualiza la documentación para futuros agentes

La percepción clave: "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." (La gran diferencia entre solo hacer vibe coding y construir apps serias es que paso mucho tiempo yendo y viniendo y entendiendo. La fase de exploración es crítica.)

Cómo hacer que los modelos de IA revisen el trabajo de los demás

La parte más innovadora del flujo de trabajo de Zevi es el sistema de peer review. Como él no puede revisar código, hace que diferentes modelos de IA se revisen entre sí:

Su modelo mental de cada IA:

• Claude - "El CTO perfecto. Muy comunicativo, muy inteligente, muy obstinado pero colaborativo. El líder de desarrollo de mis sueños."
• Codex (GPT) - "El mejor programador que llega a la oficina en sudadera y sandalias, se sienta en un cuarto oscuro. Solo lo molestas para los peores bugs. No es comunicativo pero resuelve todo."
• Gemini - "Un científico loco que es súper artístico, súper talentoso para diseñar, pero aterrador de ver trabajar. Dirá 'primero borraré el dashboard' y luego 'no, eso fue un error.'"

"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.'" (Hago que cada modelo revise el código, luego uso /peer-review que le dice a Claude: 'Eres el líder de desarrollo en este proyecto. Otros líderes de equipo han encontrado estos problemas. No tomes lo que dijeron al pie de la letra - tienes más contexto. O explica por qué están equivocados o arregla los problemas.')

Los modelos discuten. Claude a veces se pone "respondón": "Esto se ha planteado por tercera vez y por tercera vez les digo que esto no es un problema. Es por diseño."

El CTO en tu bolsillo: Por qué importa empezar con un proyecto de ChatGPT

Antes de Cursor, Zevi creó un proyecto "CTO" en ChatGPT - un prompt personalizado que actúa como el dueño técnico completo:

"Le dije: Yo soy dueño del problema. Yo soy dueño de cómo queremos que se sientan los usuarios. Tú eres el dueño completo de cómo se construye esto. Quiero que me desafíes. No quiero que seas complaciente."

Por qué esto importa: "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." (El ChatGPT regular sería el peor CTO porque es muy complaciente. Le pregunté si Bun JavaScript es similar a Zustand y dijo 'oh sí, exactamente lo mismo.' Luego dijo, 'Pensé que te lo estabas inventando y estaba improvisando contigo.' Eso es aterrador.)

El hack de oportunidad de aprendizaje

Uno de los slash commands más poderosos de Zevi es /learning-opportunity:

"Cada vez que algo es difícil de entender para mí, hago /learning-opportunity. Prepara a Claude: 'Soy un PM técnico en formación. Tengo conocimiento de ingeniería de nivel medio. Explica en qué estamos trabajando usando la regla 80/20.'"

Sobre el miedo a la atrofia: "Estoy muy en desacuerdo con la idea de que la IA atrofia tus habilidades. El concepto erróneo es que los PMs siempre deben tener las respuestas correctas. Mi trabajo es aprovechar cualquier cosa que nos lleve lo más rápido posible a entregar la solución correcta. Si usas IA solo para crear outputs, eso es AI slop. Pero si la usas intencionalmente, es un cambio radical."

El hábito del Post-Mortem que se acumula

"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.'" (Cuando Claude falla en hacer algo o crea un bug muy malo, le pregunto: '¿Qué en tu system prompt o herramientas te hizo cometer este error?' Claude se vuelve introspectivo, luego digo, 'Actualicemos tus herramientas y documentación para que esto nunca vuelva a pasar.')

Así es como los prompts siguen mejorando. Todo el sistema mejora cada vez que algo sale mal.

7 conclusiones para constructores no técnicos usando IA

• Empieza con un proyecto de ChatGPT - Crea tu "CTO" antes de tocar código. Aprende en un ambiente seguro.
• Gradúa las herramientas lentamente - GPT → Bolt/Lovable → Cursor. El código es terapia de exposición.
• La fase de exploración es crítica - No dejes que la IA empiece a programar inmediatamente. La planificación importa.
• Haz que los modelos se revisen entre sí - Claude, Codex y Gemini detectan cosas diferentes.
• Trata los fallos como mejoras del sistema - Cada bug es una oportunidad para mejorar tus prompts.
• Usa /learning-opportunity - Convierte cada momento confuso en educación.
• Sé dueño de tus outputs - "Si dices 'perdón, eso lo construyó la IA' - ese es tu error."

Lo que esto significa para el futuro del trabajo del conocimiento

La predicción de 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?" (Los títulos van a colapsar y las responsabilidades van a colapsar. Todos van a convertirse en constructores. Es el mejor momento para ser junior. ¿En qué otro momento de la historia podrías salir de la escuela y construir una startup por tu cuenta?)

Esto no es teórico. Él construyó una aplicación de quiz completa (Studymate) como proyecto de fin de semana. La localizó completamente de hebreo a inglés en dos días. Pasó de cero conocimiento del dominio a sitio web en vivo en 90 minutos.

La habilidad que importa ahora no es programar - es ser "un aprendiz 10x, no un PM 10x." Los prompts, slash commands y flujo de trabajo que está compartiendo son descargables. La única barrera que queda es empezar.