Vibe coding y producción: manual de supervivencia para responsables de IT
Por un Senior Product Manager, practicante de la producción asistida por IA
Preámbulo: disipar un malentendido semántico
Antes de nada, conviene aclarar un término que genera confusión tanto en los círculos directivos como en los equipos técnicos. El vibe coding no es sinónimo de uso intensivo de la inteligencia artificial para generar código. Usar Cursor, Copilot o Claude para escribir la mayor parte de tus líneas de código, manteniéndote en un bucle de retroalimentación estrecho con el modelo, releyendo, validando y corrigiendo cada propuesta, es una práctica ya banalizada de asistencia al desarrollo. Eso no es vibe coding.
La definición que tiene autoridad, formulada por Andrej Karpathy, es mucho más radical: el vibe coding consiste en dejarse llevar por las vibraciones, abrazar la exponencial y olvidar que el código existe. La expresión clave, la que debe retener la atención de todo decisor, es la última: olvidar que el código existe.
Este giro paradigmático no es un detalle cosmético. Redefine la propia naturaleza de la relación entre el ingeniero y su artefacto y, en consecuencia, transforma la gobernanza de los sistemas de información que diriges.
Por qué el vibe coding debe interesar a los responsables de IT
La democratización inicial del vibe coding produjo resultados desiguales. En la columna de los éxitos hay videojuegos, prototipos, proyectos personales, objetos todos ellos donde el error es tolerable. En la columna de los desastres hay aplicaciones lanzadas a producción por neófitos, con su cortejo previsible: claves de API expuestas, sistemas de autenticación sorteado, cuotas pulverizadas, bases de datos contaminadas por inyecciones descuidadas. El vibe coding parecía así confinado a un uso recreativo o, como mucho, exploratorio.
Entonces, ¿por qué, como responsable de IT, deberías preocuparte por una práctica aparentemente reservada a aficionados o a prototipos de bajo riesgo?
La respuesta cabe en una palabra: la exponencial.
La longitud de las tareas que la IA puede realizar de forma autónoma se duplica cada siete meses. A ese ritmo, no es en absoluto necesario hacer vibe coding: puedes dejar que tu ingeniero pilote Claude Code o Cursor sobre una funcionalidad y luego releer íntegramente el resultado. El coste de verificación sigue siendo razonable frente a la ganancia de productividad.
Pero proyectémonos. Dentro de doce meses, dentro de veinticuatro, cuando estos sistemas produzcan el equivalente a una jornada entera de trabajo, y luego a una semana, en una sola inferencia, será materialmente imposible mantenerse en lockstep con la máquina. El ingeniero que exige leer cada línea se convierte en el cuello de botella de su organización. La negativa a adaptarse se pagará, no en deuda técnica, sino en competitividad.
La analogía fundacional: los compiladores
Para captar lo que está en juego, conviene un rodeo histórico. En los albores de los compiladores, muchos desarrolladores no confiaban en ellos. Usaban el compilador, ciertamente, pero releían sistemáticamente el ensamblador producido para asegurarse de que correspondía a lo que ellos habrían escrito. Esta práctica, legítima en una fase de aculturación, se volvió rápidamente insostenible: los sistemas crecieron demasiado como para que una relectura exhaustiva del ensamblador siguiera siendo económicamente justificable.
Hoy todos sabemos que hay ensamblador bajo el capó. Pero prácticamente ningún ingeniero de aplicaciones lo lee. Construimos software robusto sin inspeccionar esa capa. Hemos encontrado niveles de abstracción verificables que nos dispensan de inspeccionar el sustrato.
La tesis, para los decisores, es la siguiente: olvidaremos que el código existe, pero nunca olvidaremos que el producto existe. El reto de los próximos años consiste en construir las condiciones metodológicas de esa confianza delegada, exactamente como hemos construido, colectivamente, las condiciones de la confianza en los compiladores.
Un problema tan viejo como la civilización
Conviene insistir en un punto que los ingenieros, como contribuyentes individuales por cultura, a menudo aceptan con dificultad: gestionar una experiencia que uno mismo no domina es uno de los problemas más antiguos de la organización humana.
- ¿Cómo supervisa un director técnico a un experto en un ámbito en el que él no es experto?
- ¿Cómo valida un product manager una funcionalidad sin leer la totalidad del código subyacente?
- ¿Cómo verifica un dirigente el trabajo de su contable sin ser él mismo experto contable?
Estas preguntas tienen respuestas probadas, a veces desde hace siglos:
- El CTO redacta pruebas de aceptación que validan el comportamiento esperado del sistema sin presuponer su implementación.
- El product manager utiliza el producto y se asegura de que funciona como se especificó, sin releer el código.
- El dirigente muestrea puntos de control que domina, controla porciones de datos y construye así una confianza agregada en el modelo financiero global.
Estos dispositivos no responden a una ceguera gerencial: responden al arte de las capas de abstracción verificables. Todo manager competente del mundo practica ya esta delegación controlada. Lo que es nuevo, para los ingenieros de software, es tener que aplicarla a su propio oficio.
El único punto ciego actual: la deuda técnica
Seamos honestos: hoy existe un límite metodológico al vibe coding en producción, y ese límite se llama deuda técnica. A diferencia de la corrección funcional, la estabilidad o la seguridad, todas medibles con pruebas externas, la deuda técnica solo se mide bien leyendo el código. Hoy no existe una métrica de abstracción fiable que permita detectar, sin inspección humana experta, que un módulo vibe-codeado está acumulando decisiones de diseño que hipotecan las evoluciones futuras.
Este límite no invalida el vibe coding. Acota su perímetro de aplicación.
La estrategia de los nodos hoja: una doctrina para decisores
La respuesta operativa a ese límite se enuncia con sencillez: concentrar el vibe coding en los nodos hoja de tu arquitectura.
En el árbol de dependencias de un sistema de software se distingue:
-
Los troncos y ramas estructurales: capas fundamentales sobre las que se apoyan otros componentes. Arquitectura de datos, sistemas de autenticación, orquestación de servicios, APIs internas compartidas. Es el núcleo que tus ingenieros deben seguir dominando en profundidad, porque esas zonas evolucionan, se extienden, y cualquier deuda allí se multiplica.
-
Los nodos hoja: funcionalidades terminales de las que nada depende. Pantallas de usuario específicas, scripts de exportación, informes ad hoc, integraciones periféricas, conectores one-shot. Si se aloja deuda técnica en ellos, está contenida. Esas zonas cambian poco, no sirven de base a otro código, y su eventual reescritura sigue siendo local.
La recomendación estratégica es, por tanto, la siguiente: autoriza el vibe coding allí donde la deuda está arquitectónicamente confinada, prohíbelo en el núcleo estructural e invierte en una cartografía explícita de esa frontera. Esa cartografía es hoy un entregable de gobernanza tan importante como tu esquema de arquitectura objetivo.
Estudio de caso: una pull request de 22.000 líneas, fusionada con serenidad
Un episodio reciente ilustra la viabilidad de esta doctrina a escala industrial. En Anthropic, una modificación de 22.000 líneas se integró en una base de código de producción dedicada al aprendizaje por refuerzo, código en gran parte redactado por el propio Claude.
¿Cómo pudo llevarse a cabo semejante operación de forma responsable? Se aplicaron cuatro principios con rigor:
-
Una inversión humana masiva por adelantado. No se trataba de un prompt único seguido de un merge. Varias jornadas de trabajo humano se dedicaron a la elaboración de los requisitos, al pilotaje iterativo del modelo y a la especificación del sistema objetivo.
-
Concentración en los nodos hoja. La mayor parte del cambio tocaba zonas periféricas, de las que era aceptable que cargaran con una parte de deuda técnica porque no constituían una base para otros desarrollos.
-
Revisión humana intensiva en las partes estructurales. Los escasos componentes que debían seguir siendo extensibles fueron objeto de una relectura línea a línea por ingenieros experimentados.
-
Diseño explícito para la verificabilidad. Se diseñaron pruebas de estrés por adelantado, el sistema se arquitecturó en torno a entradas y salidas humanamente verificables, de modo que existen puntos de control independientes de la lectura del código.
El resultado: una confianza en ese cambio equivalente a la obtenida para cualquier otro cambio de la base de código, pero entregado en una fracción del tiempo que habría exigido una escritura manual íntegra seguida de una revisión exhaustiva.
Más interesante aún para un decisor: el efecto de arrastre sobre la estrategia de producto. Cuando el coste marginal de una funcionalidad pasa de dos semanas a un día, el cálculo de cartera cambia. Proyectos antes descartados por demasiado costosos se vuelven triviales. No nos limitamos a hacer lo mismo más rápido: hacemos cosas que nunca habríamos contemplado.
Manual del PM de Claude: metodología operativa
El mantra que recomiendo a todos los equipos embarcados en esta transición: "No preguntes qué puede hacer Claude por ti, pregunta qué puedes hacer tú por Claude."
Cuando haces vibe coding, ya no eres ingeniero, eres product manager de una IA. Eso exige un cambio cultural profundo.
El contexto es el nuevo código
La tentación es grande de tratar la IA como un chatbot: una petición corta, una corrección rápida, una funcionalidad pedida en tres líneas. Esta práctica, heredada de las primeras interacciones con asistentes conversacionales, es contraproducente en cuanto suben las apuestas.
Proyéctate: si un nuevo ingeniero llegara a tu equipo, ¿le confiarías una funcionalidad el primer día con una sola frase de briefing? Evidentemente no. Le harías visitar la base de código, le describirías las restricciones arquitectónicas, las convenciones internas, los requisitos no funcionales, los casos límite conocidos.
Es exactamente lo que el vibe coder debe hacer con Claude. Quince a veinte minutos de recogida de contexto antes del prompt de ejecución son una inversión normal. Esta fase suele tomar la forma de una conversación previa distinta, durante la cual la IA explora la base de código, identifica los archivos afectados y localiza los patrones a seguir. El entregable de esta fase es un plan documentado, que luego se inyecta, ya sea en una sesión nueva o como instrucción de ejecución, al modelo que realizará el trabajo.
La experiencia empírica muestra que este protocolo aumenta radicalmente la tasa de éxito de las tareas ambiciosas.
No sobre-constreñir
Paradójicamente, aunque el contexto es crucial, conviene guardarse de la sobre-prescripción. Los modelos actuales dan sus mejores resultados cuando el marco es claro pero no carcelario. En los aspectos en los que el cómo es indiferente, deja libre al modelo. En los aspectos en los que tienes una preferencia arquitectónica fuerte, sé explícito. Piensa en un ingeniero junior competente: ni micromanagement ni abandono.
El test-driven development revisitado
El desarrollo guiado por pruebas (TDD) encuentra aquí un segundo aliento. Pero atención a una trampa clásica: dejada a sí misma, la IA tiende a producir pruebas demasiado acopladas a la implementación, que se rompen a la mínima evolución. La solución consiste en ser prescriptivo sobre la forma: pedir explícitamente tres pruebas end-to-end, un camino nominal, dos casos de error, manteniéndose en el nivel comportamental. Esta minimización hace las pruebas humanamente legibles y suele constituir la única parte del código que el vibe coder inspecciona realmente.
Compactación e higiene de contexto
En las sesiones largas, la degradación de la coherencia (renombrados erráticos, derivas de convenciones) es un problema real. La buena práctica consiste en compactar la sesión en puntos de parada naturales, como haría un humano antes de una pausa para comer. Un workflow probado: hacer que Claude produzca un plan documentado en fase de exploración, compactar y luego atacar la ejecución sobre la base de ese documento. Esta mecánica reduce una conversación de 100.000 tokens a unos miles, sin perder lo esencial.
¿Qué productos hay que construir?
Para los editores y los decisores que pilotan plataformas, se dibuja una oportunidad estratégica mayor: sistemas de los que se pueda probar formalmente que están exentos de errores. Frameworks donde las partes sensibles, autenticación, pago, persistencia, estén preconstruidas y bloqueadas, dejando al vibe coder un sandbox bien delimitado para su capa funcional.
El ejemplo arquetípico ya existe: los artefactos Claude, donde el código generado se ejecuta en un entorno frontend restringido, sin backend, sin secretos, sin superficie de ataque significativa. Pero ahí hay todo un mercado por inventar: BaaS (backend as a service) concebidos para absorber el vibe coding sin transformar cada aplicación en un colador de seguridad. Es probablemente uno de los ejes de inversión más prometedores para los próximos años.
Abrazar la exponencial: qué significa realmente
El último principio, embrace exponentials, es el peor comprendido. "Los modelos van a mejorar" es una lectura débil, casi trivial. La lectura fuerte es mucho más exigente: los modelos van a mejorar más rápido que nuestra capacidad de imaginarlo.
Volvamos a la intuición fundacional. Un ingeniero de los años 1990 con unos pocos kilobytes de RAM habría tenido enormes dificultades para proyectarse en un mundo donde las máquinas personales albergan terabytes. No es un factor dos o cuatro: es un factor un millón. Eso es lo que produce, en veinte años, un crecimiento exponencial.
La buena pregunta estratégica no es por tanto "¿qué haremos si los modelos son dos veces mejores dentro de dos años?", esa pregunta es demasiado pequeña. La buena pregunta es: "¿qué organización, qué procesos, qué arquitectura habremos construido para seguir siendo pertinentes frente a modelos cuyas capacidades se habrán multiplicado por órdenes de magnitud?"
Recomendaciones para los decisores
A la atención de los directores técnicos, directores de sistemas de información y directores de producto que lean este artículo, estos son los ejes de acción prioritarios:
1. Cartografiar explícitamente tus nodos hoja. Produce un documento de gobernanza que distinga el núcleo arquitectónico intangible de las zonas periféricas elegibles para el vibe coding. Haz de él un entregable vivo, revisado cada trimestre.
2. Invertir en la verificabilidad. Auditorías de seguridad automatizadas, pruebas de estrés, arneses de validación independientes del código: estos artefactos se convierten en la verdadera línea de defensa cuando la lectura humana ya no es económicamente practicable. Son los nuevos controles internos de tu sistema.
3. Formar a tus equipos en la postura de product manager. El oficio de ingeniero de software está basculando hacia el de piloto de agentes. Esta mutación se trabaja: redacción de especificaciones, diseño de protocolos de prueba, arte del prompt contextualizado.
4. Construir entornos seguros por diseño. Ya seas usuario o productor de plataformas, el futuro pertenece a los entornos donde los errores del vibe coder están estructuralmente contenidos.
5. Prohibir el vibe coding en el núcleo estructural, hoy. La prudencia impone una frontera clara. Los modelos mejoran, la frontera retrocederá, pero en cada instante debes saber dónde se sitúa.
6. Preparar el relevo. Quienes dentro de dos años sigan exigiendo a sus equipos releer cada línea producida por la IA se encontrarán en una situación de desventaja competitiva estructural. No porque estén equivocados en principio, sino porque su organización se habrá convertido en el cuello de botella de su propia productividad.
Outro
El vibe coding en producción no es un capricho de geek con ganas de novedad. Es la respuesta pragmática, aún balbuceante, a una pregunta que va a imponerse a toda la industria del software en los próximos dieciocho meses: ¿cómo explotar productivamente sistemas cuya velocidad de producción supera nuestra capacidad humana de verificación línea a línea?
La respuesta no consiste ni en rechazar la herramienta ni en entregarse a ella sin red. Consiste en reinvertir, en nuestro oficio, métodos que la humanidad ha probado desde hace siglos en todas las disciplinas donde hay que gestionar experiencias que uno mismo no domina: especificación rigurosa, verificación por abstracción, confinamiento arquitectónico, muestreo selectivo.
Los decisores que comprenden hoy esta transición, que despliegan los dispositivos de gobernanza adecuados y que forman a sus equipos en la postura de product manager de la IA, construyen una ventaja competitiva duradera. Los demás aprenderán por las malas que, en régimen exponencial, el retraso se recupera con dificultad.
Olvidar que el código existe, pero nunca que el producto existe. Esta frase, bien comprendida, es la brújula de los próximos años.