Hay un momento que se repite en muchas organizaciones. Un compañero de seguridad, de cumplimiento o de infraestructura —alguien que nunca ha escrito código de producción— abre Claude Code o Codex, describe lo que necesita en lenguaje natural y, hora y media después, tiene una aplicación funcionando. La primera reacción es entusiasmo. La segunda debería ser una pregunta: ¿cómo evitamos que esto se nos vaya de las manos?
El vibe coding ha reducido la barrera de entrada al desarrollo de meses a minutos. Personas con perfil técnico sólido pero sin formación en desarrollo están construyendo prototipos útiles. Es una excelente noticia. El problema es que cada uno lo está haciendo a su manera.
Lo que pasa cuando cada PoC vive en su propio universo
Sin marco común, lo que producen estos asistentes depende casi por completo de cómo se les pregunte. Una aplicación puede acabar con credenciales escritas a fuego en el código. Otra puede manejar datos que nunca debieron salir del sistema de origen. Todas pueden aparentar funcionar perfectamente desde fuera.
Las que sobreviven se vuelven huérfanas en semanas: sin documentación ni convenciones, quien las hereda no sabe por dónde empezar. Y cuando alguna quiere pasar a producción, operaciones recibe piezas que no encajan. Un trámite de horas se convierte en un proyecto de semanas.
La guía corporativa: los preparativos del desarrollo asistido
Cualquier cocinero sabe que la diferencia entre un servicio caótico y uno fluido no está tanto en la habilidad como en el mise en place (poner en su lugar): tener los ingredientes preparados antes de empezar. Una guía corporativa de vibe coding es eso aplicado al desarrollo asistido por IA.
No se trata de imponer burocracia, sino de no partir del folio en blanco: estructura ya pensada, instrucciones que el agente leerá automáticamente, plantillas que contemplan qué no puede subirse jamás al repositorio. El autor se centra en lo único que diferencia su prueba: la idea. El agente, con esas reglas desde el primer mensaje, respeta unas barandillas que de otra forma habría que recordar a mano una y otra vez. La guía no es un techo: es un suelo.
El PRD ligero: el documento que pocas veces se escribe y siempre se echa de menos
Hay una tentación humana al descubrir el vibe coding: abrir el agente y empezar a pedirle cosas. Es la trampa más sutil. Un agente puede escribir código a una velocidad asombrosa, pero no puede leerte la mente: cuando alguien describe lo que quiere sin haberlo pensado del todo, el agente rellena huecos con suposiciones razonables pero arbitrarias. Y cuando se descubre el desfase, ya hay tres horas de código que rehacer.
Por eso, antes del primer prompt, conviene escribir un documento funcional ligero —un PRD— de no más de una página. No es formal ni requiere aprobaciones. Es una conversación honesta con uno mismo: qué problema resuelvo, para quién, qué debe hacer la aplicación, qué no debe hacer, cómo sabré que está lista. Esa media hora transforma la sesión: el agente deja de improvisar, uno mismo se obliga a decidir antes de comprometer tres horas de código, y aparece un criterio objetivo de «terminado».
Entusiasmo con base
La pregunta que abre este artículo no tiene una respuesta dramática. No hace falta prohibir el vibe coding ni reservarlo a unos pocos. Hace falta lo contrario: ponerlo al alcance de todos sobre una base común. Una guía corporativa que estandariza el punto de partida. Un PRD ligero que estandariza el punto de llegada.
El entusiasmo no es el enemigo. La falta de base lo es.
