El mindset de build
Ya tenés la herramienta, la carpeta y el cerebro. Lo último que falta instalar es lo único que no es software: cómo le hablás a Claude Code para que buildee lo que de verdad querés.
Acá es donde la mayoría o vuela o se traba. Los que se traban intentan escribir código, o escriben prompts vagos y rezan. Los que vuelan describen resultados con claridad y manejan con un puñado de comandos chiquitos. Vamos a instalar el segundo hábito.
Describí el output, no el código
El movimiento central del "vibe coding", como lo plantea Riley Brown: describís lo que querés y el output esperado, y Claude lo buildeaa. Vos sos el de producto, no el ingeniero. Tu trabajo es ser claro con el qué y el por qué — el cómo es de Claude.
Así es exactamente como los no-programadores shippean herramientas reales. Jithin Raaj lo dijo mejor sobre su dashboard de 37 cuentas: "What I brought was a clear description of the problem and a clear picture of what the output should look like." No hay código en esa frase — solo una descripción afilada. Volvete bueno describiendo el output y ya tenés el 90% del camino hecho.
Los micro-comandos
No necesitás un vocabulario de cien prompts. Necesitás tres comandos chiquitos que vas a usar todo el tiempo para manejar un build:
run this locally— que Claude corra el script en tu máquina de verdad, así lo ves funcionar (o fallar) en serio.fix— cuando algo se rompe, pegá el error y decífix. Claude lee el error y lo repara. Vos no diagnosticás; retransmitís.change nothing else— para ediciones quirúrgicas. Pedí un cambio específico y prohibí el daño colateral, así el código que funciona no se desvía mientras lo tocás.
fix es el destrabe para los no-coders. Cuando te pega un error, no necesitás entenderlo — copiá todo, pegalo, y decí fix. Repetí hasta que corra. Ese loop solo te saca de casi todo.
Una cosa a la vez
La disciplina más importante: cambiá una cosa por prompt. La regla de Riley Brown es directa — "Do one thing at a time, don't make too many changes per prompt." Cuando pedís cinco cambios de una y algo se rompe, no tenés idea cuál lo hizo. Cuando pedís uno, la causa y el efecto quedan obvios, y fix sigue siendo fácil.
Los pasos chicos se sienten más lentos. No lo son — son el camino rápido, porque nunca te perdés. Buildeá una pieza, run this locally, confirmá que funciona, y recién ahí seguís.
Human-in-the-loop: el sistema sugiere, vos decidís
Acá está la línea que separa un sistema de contenido de un piloto automático del que te vas a arrepentir: nada se postea solo. El Content OS te muestra los outliers, extrae los hooks, y te enseña qué funciona en tus números — y después vos decidís qué crear y vos apretás publicar. Todos los builders serios ponen este gate. Como dijo uno sobre sus herramientas: "None of them auto-post. They suggest, I decide."
Eso no es una limitación a esquivar. Es el punto. La máquina se encarga del análisis; vos te quedás con el criterio y la voz.
La única regla dura de todo este curso: la IA buildeaa el sistema, vos te quedás con tu voz. Dejá que Claude escriba cada línea de código — pero nunca lo dejes escribir como vos ni postear por vos. En el momento en que el sistema publica solo, deja de ser tuyo. Sugerí, no postees.
¿Por qué el Content OS nunca postea solo?
Lo que te llevás
Describí el output, no el código, y manejá con tres micro-comandos: run this locally, fix (pegá el error), y change nothing else. Moveté de a una cosa a la vez así la causa y el efecto quedan claros. Y nunca rompas la única regla dura — el sistema sugiere, vos decidís. La IA buildeaa el sistema; vos te quedás con tu voz.