Vibe coding no empieza en el prompt.
Empieza en el contexto.
Un agente sin contexto trabaja por aproximación. Intenta adivinar el proyecto, el tono, las restricciones, la arquitectura y el criterio de listo.
A veces acierta. Muchas veces solo parece que acertó.
El contexto no es adorno. Es infraestructura de trabajo.
Cada etapa pide su propio contexto.
El diagnóstico no usa el mismo contexto que la planificación.
La planificación no usa el mismo contexto que la implementación.
Juntar todo en el mismo prompt es pedirle al agente que mezcle pregunta, decisión y ejecución.
Qué cuenta como contexto
Contexto no es volcarlo todo en el chat.
Buen contexto es información organizada, actual y útil para la tarea.
Puede estar en:
AGENTS.md;README.md;PLANS.md;- documentación en
docs/; - código existente;
- pruebas;
- decisiones registradas;
- criterios de listo;
- comandos de validación.
El agente necesita entender dónde está pisando.
No para obedecer ciegamente. Para actuar con menos ruido.
El error del chat único
Una mala práctica es intentar ejecutar todo el vibe coding en un único chat, conversación o tarea.
Parece eficiente.
No lo es.
Las conversaciones largas acumulan intención, corrección, desvío, excepción e improvisación. Después de muchas vueltas, nadie sabe exactamente qué decisión sigue vigente.
El agente pierde nitidez.
La persona también.
Exploración, planificación, implementación y revisión son fases diferentes. Mezclar todo en una sola conversación convierte el proceso en algo difícil de auditar.
Lo mismo vale para el prompt.
No pidas diagnóstico, planificación e implementación en el mismo pedido.
Cada etapa debe ser una tarea separada, con entrada, objetivo y salida propios.
Un proyecto no debe depender de la memoria frágil de una ventana abierta.
Debe depender de archivos, historial, validaciones y decisiones registradas.
Una etapa por tarea
El mejor flujo es más pequeño.
Más simple.
Más verificable.
El diagnóstico es una tarea.
La planificación es otra.
La implementación es otra.
Deben ocurrir en ese orden.
Y deben ocurrir en prompts separados.
Esta regla también vale para cualquier prompt de ejemplo.
Un prompt sugerido debe enfocarse en una sola etapa: diagnóstico, planificación o implementación.
Si el prompt es de diagnóstico, no debe pedir un plan.
Si el prompt es de planificación, no debe pedir cambios de código.
Si el prompt es de implementación, debe partir de un plan aprobado y ejecutar solo una parte.
El ejemplo necesita enseñar la frontera.
No solo resolver el caso.
Diagnóstico
El diagnóstico sirve para entender el estado actual.
No debe planificar toda la solución.
No debe editar archivos.
Etapa: diagnóstico.
Lee AGENTS.md, README.md y los documentos relevantes.
Haz solo un diagnóstico.
No implementes nada.
No crees todavía un plan detallado.
Lista el contexto encontrado, lagunas, riesgos y dudas.Planificación
La planificación sirve para transformar el diagnóstico en una secuencia de trabajo.
No debe implementar.
Debe crear etapas pequeñas, verificables y ordenadas.
Etapa: planificación.
Con base en el diagnóstico aprobado, crea un plan incremental.
No alteres código.
Separa las etapas por objetivo, archivos probables y validaciones.
Indica la primera etapa lo bastante pequeña para una implementación aislada.Implementación
La implementación sirve para ejecutar una etapa específica del plan.
No debe reabrir todo el diagnóstico.
No debe reinventar la planificación.
Etapa: implementación.
Implementa solo la etapa 1 del plan aprobado.
Antes de editar, di qué archivos pretendes modificar.
Después ejecuta las validaciones disponibles.
Lista archivos modificados, riesgos y pendientes.Estos prompts están limitados a propósito.
El límite no estorba al agente. El límite da dirección.
Si el prompt pide diagnóstico, planificación e implementación al mismo tiempo, ya empezó mal.
Buen vibe coding no es una gran sesión heroica.
Es una secuencia de ciclos claros.
Las skills no son decoración
Las skills existen para ampliar la capacidad del agente en situaciones específicas.
Esa es la parte importante: específicas.
Usar una skill sin necesidad es una mala práctica.
Puede añadir demasiadas instrucciones, llamar herramientas equivocadas, aumentar el costo de la tarea, producir archivos innecesarios o desplazar el foco del problema real.
No toda tarea necesita una skill.
Corregir un texto simple no exige el mismo aparato que crear una presentación. Ajustar un post no exige el mismo flujo que investigar una falla de CI. Implementar un pequeño cambio de layout no exige transformar la tarea en una investigación amplia.
La pregunta correcta es:
¿Esta skill ayuda directamente a la etapa actual?
Si la respuesta es no, no la uses.
Una buena herramienta también necesita el momento correcto.
Demasiado contexto también estorba
Existe el otro error: enviar demasiado contexto.
Un agente no mejora solo porque recibió más archivos, más enlaces, más reglas y más historial.
Mejora cuando recibe el contexto relevante.
Antes de pedir cualquier etapa, conviene separar:
- el objetivo de esa etapa;
- los archivos probables;
- las restricciones;
- los ejemplos importantes;
- los comandos de validación;
- lo que no debe alterarse.
El resto puede esperar.
Buen contexto es recorte.
Cómo dividir una tarea grande
Cuando la idea sea grande, no pidas todo.
Transfórmala en etapas.
1. Diagnóstico: entiende el problema, el repositorio y los riesgos. No planifiques en detalle. No implementes.
2. Planificación: transforma el diagnóstico aprobado en etapas pequeñas. No implementes.
3. Implementación: ejecuta solo una etapa aprobada.
4. Validación: ejecuta los comandos disponibles y revisa el resultado.
5. Registro: documenta decisiones, riesgos y próximos pasos.
6. Próxima etapa: avanza solo después de validar la etapa anterior.Ese flujo protege el proyecto.
También protege tu cabeza.
No necesitas decidir todo de una vez. Necesitas crear condiciones para que la próxima decisión sea mejor.
Un prompt malo
Etapa declarada: diagnóstico.
Haz el diagnóstico.
Después, en la misma tarea, crea el plan e implementa todo lo necesario
para resolver todo el proyecto.Ese pedido abre demasiadas puertas.
El agente tendrá que diagnosticar, decidir y ejecutar al mismo tiempo.
Puede parecer productivo al comienzo. Pero el costo aparece después, cuando cada ajuste exige deshacer elecciones que nunca fueron realmente decididas.
Un prompt mejor
Etapa: diagnóstico.
Lee AGENTS.md y docs/convencoes-conteudo.md.
Haz solo el diagnóstico para la publicación de un nuevo post.
No planifiques la implementación.
No edites archivos.
Lista contexto encontrado, riesgos, dudas y próximos pasos sugeridos.Ese pedido tiene frontera.
Separa lectura de decisión. Separa decisión de ejecución. Evita que una buena idea se convierta en cambio automático antes de la revisión humana.
Así trabaja mejor el agente.
No por libertad total.
Por dirección suficiente.
El principio
Contexto es la diferencia entre pedir ayuda y dirigir trabajo.
Las skills deben entrar cuando sirven al ciclo actual.
Las conversaciones deben ser lo bastante pequeñas para ser comprendidas.
Las tareas deben ser lo bastante pequeñas para ser validadas.
Diagnóstico, planificación e implementación deben estar separados.
Siempre en secuencia.
Nunca en el mismo prompt.
El proyecto debe cargar su propia memoria.
Vibe coding no es dejar correr a la máquina.
Es crear un ambiente donde corre en la dirección correcta.