Vibe Coding No Sobrevive en Producción

Una demo es terreno virgen: sin legado, sin cumplimiento normativo, sin nadie más haciendo commits en la rama. Tu base de código es todo lo contrario. La razón por la que el vibe coding —escribir prompts hasta que algo funcione— parece productivo y luego falla silenciosamente es que genera resultados más rápido de lo que cualquiera puede verificarlos. Con un solo ingeniero en un proyecto de prueba, eso está bien. A escala de equipo y producción, el output no verificado cuesta más de lo que ahorra. Los patrones que se describen a continuación existen precisamente para cerrar esa brecha.

La claridad del contexto es el paso de mayor impacto en cualquier construcción asistida por agentes, y ocurre antes de que exista una sola línea de código. Primero, somete tu propia documentación a un interrogatorio riguroso: cuestiona los requisitos, las restricciones, los casos límite y los supuestos enterrados en un ticket de hace ocho meses. El resultado es algo que conservas: un PRD comprometido que captura lo que estás construyendo, con criterios de aceptación que se van cristalizando a medida que el interrogatorio afina la imagen. Un contexto con ambigüedad casi nula es la diferencia entre un resultado limpio y una costosa reelaboración. Basura entra, basura sale: un agente construirá con total confianza la cosa equivocada más rápido de lo que cualquier humano podría hacerlo.

Una ventana de contexto es efímera; tu repositorio no lo es. Por eso, cada artefacto que vale la pena conservar se confirma y recibe un lugar duradero que sobrevive a la sesión. Un esquema consistente por ticket lo hace automático:

feature-name/ raw/ recursos externos obtenidos de Jira, Figma, Linear PRD.md el "qué" más los criterios de aceptación, de la sesión de análisis implementation-plan.md los cortes verticales de bala trazadora execution-plan.md bloc de notas activo que se mantiene mientras se construye cada corte docs/adr/ registros de decisiones arquitectónicas (a nivel de repositorio, de primera clase)

El PRD contiene el qué, no el cómo, y permanece confirmado. El plan de implementación es tu lista de cortes verticales de bala trazadora — recortes delgados que cada uno demuestra que todo el camino funciona de extremo a extremo. Puede vivir en el repositorio, GitHub, Jira o Linear, siempre que tenga existencia fuera de cualquier sesión de contexto individual. El plan de ejecución es el bloc de notas que mantienes mientras implementas cada corte con TDD: las sorpresas y obstáculos que encuentras, capturados para que puedas convertirlos más tarde en documentos de mayor impacto, como guías de arquitectura y runbooks.

Los registros de decisiones arquitectónicas se ubican aparte del ticket, en un lugar de primera clase como docs/adr/, porque sobreviven a la funcionalidad que los originó. Cualquier decisión estructural — algo difícil de revertir — se registra en el momento en que el análisis la revela, con la justificación, las alternativas que se evaluaron y las compensaciones. Así es como el trabajo sobrevive a un reinicio de sesión, a una incorporación de nuevo integrante o a tu propia memoria tres semanas después, y le entrega al siguiente agente la misma claridad que tuvo el anterior, en lugar de empezar desde cero.

No dejes que una ventana de contexto se convierta en un cajón de sastre. La calidad se deteriora a medida que se llena, así que inicia nuevas sesiones de forma deliberada. Distribuye subagentes para la investigación de modo que el hilo principal se mantenga limpio. Usa habilidades de transferencia para pasar resultados entre sesiones en lugar de arrastrar todo consigo. Como regla práctica, mantente por debajo de los 200k tokens de contexto si quieres una salida consistente, y monitoréalo constantemente. La saturación del contexto es una de las causas más comunes y menos visibles del deterioro en la calidad de los agentes.

La generación es barata ahora. La verificación es donde se gana o se pierde el valor. Una tarea autónoma de larga duración solo es tan buena como la capacidad del agente para revisar su propio trabajo, y esa capacidad hay que construirla de forma deliberada. El desarrollo guiado por pruebas es la manera de construirla: rojo, verde, refactorizar, una prueba a la vez, sigue produciendo el código más limpio incluso cuando es un agente quien lo escribe. Cada prueba superada es un punto de control que el agente no puede falsificar. Combina eso con Playwright para una cobertura de extremo a extremo que se ejecute localmente y en CI, y la calidad de tu desglose de bala trazadora se convierte en el factor que decide si obtienes valor real o basura convincente.

No necesitas un solo modelo para hacer todo, así que utiliza tu modelo más potente para el razonamiento y la planificación, donde la profundidad importa más que la velocidad. Luego cambia a modelos más rápidos y de alta inteligencia para la fase de construcción, donde el rendimiento es lo que cuenta y el plan ya está definido. Adaptar el modelo a la tarea mantiene tanto el costo como la calidad donde los quieres, y evita que pagues tarifas premium de razonamiento para rellenar contenido repetitivo.

Lo fundamental es que nada de esto tiene que ver con perseguir la herramienta más nueva. La ventaja se acumula para los equipos que hacen el trabajo poco glamoroso de construir una base de código que los agentes puedan leer, con disciplina de contexto y ciclos de verificación lo suficientemente rigurosos como para confiar en los resultados autónomos. Si lideras una organización técnica, empieza por lo que genera resultados inmediatos: escribe el PRD y los fragmentos de bala trazadora para tu próxima construcción, y registra tus decisiones arquitectónicas en el repositorio donde el próximo agente las encontrará. Luego, haz que el TDD sea innegociable para el código escrito por agentes.

El futuro del desarrollo no es el "vibe coding". Es una ingeniería estructurada, basada en artefactos y asistida por agentes, y los equipos que están construyendo esa disciplina ahora son los que seguirán entregando resultados cuando la novedad se desvanezca.