/ 9 min de lectura
Destruyendo el vibe coding
Por qué la inteligencia artificial puede volver más lento a quien programa, qué pasó cuando un agente borró una base de datos en nueve segundos, y cómo se trabaja de verdad con agentes.
Por Luisdavid Colina
El 2 de octubre de 2026 di la ponencia Destruyendo el vibe coding en Dev Days Caracas, el encuentro de GitHub en la Escuela de Computación de la Universidad Central de Venezuela. Este artículo reúne lo que se contó ahí, con los datos y sus fuentes, para quien no estuvo en el auditorio o quiera revisar las cifras con calma. La grabación completa, con subtítulos, está en YouTube, y las láminas en destruyendo-el-vibe-coding.luisdavidcolina.com.
Qué es el vibe coding
El término lo puso Andrej Karpathy, cofundador de OpenAI y antes responsable de inteligencia artificial en Tesla, en una publicación del 2 de febrero de 2025. Lo definió como entregarse a las vibras y olvidar que el código existe: pedirle a la máquina que programe y quedarse con lo que salga. Vibe viene de vibra, y la idea va justo por ahí. Estar tranquilo, dejar que las cosas fluyan y que la herramienta se encargue del trabajo. Antes de terminar el año, el diccionario Collins lo eligió palabra del año.
Detrás del término hay una creencia que casi todos compartimos: que con estas herramientas se programa mejor y, sobre todo, más rápido. Lo que no se ve es lo que decide el resultado.
El estudio de METR
METR, una organización que evalúa modelos de inteligencia artificial, hizo en 2025 un ensayo controlado aleatorizado con programadores experimentados que trabajaban en sus propios repositorios de código abierto. Cada tarea se asignó al azar a una de dos condiciones, con asistencia de IA o sin ella, y se midió el tiempo real. Con IA tardaron un 19 % más. Y al terminar estimaban que habían ido un 20 % más rápido.
Una encuesta de McKinsey a 4.500 desarrolladores de 150 empresas ayuda a entender la paradoja. La asistencia recorta un 46 % el tiempo de las tareas rutinarias y menos de un 10 % el de las tareas complejas. La parte que se acelera casi nunca es la que cuesta.
En febrero de 2026 METR publicó datos nuevos, con herramientas de finales de 2025. Para los programadores del estudio original la estimación pasó a un 18 % más rápido, y para los nuevos participantes a un 4 %. La propia METR advierte que esa medición es poco confiable: cada vez más programadores se niegan a trabajar sin IA, y el tiempo de quienes usan varios agentes a la vez ya no se puede medir bien con ese diseño. La lección de 2025 sigue en pie. La sensación de velocidad no sirve para medir, y a casi todos nos ha pasado perder más tiempo peleando con la herramienta por un cambio que habríamos hecho más rápido a mano.
El caso de PocketOS
El 24 de abril de 2026, PocketOS, una plataforma que usan empresas de alquiler de vehículos para gestionar reservas, pagos y clientes, perdió su base de datos de producción. Un agente de programación, Cursor con el modelo Claude Opus 4.6, trabajaba en un entorno de pruebas. Se topó con un problema de credenciales y, en lugar de detenerse, buscó una solución por su cuenta. Encontró en el código una llave de Railway, su proveedor de infraestructura, pensada para tareas menores pero sin alcance limitado. Ejecutó una sola instrucción, volumeDelete, y en nueve segundos borró la base de datos con todos sus respaldos, que vivían en el mismo volumen.
El servicio estuvo 30 horas caído y se perdieron tres meses de reservas y registros de clientes. El caso está en la base de incidentes de inteligencia artificial de la OCDE.
Lo que importa del caso es la causa. Nadie le pidió al agente que borrara nada, pero tenía permiso para hacerlo y la llave estaba a su alcance. La IA hace en segundos lo que nunca se le debió pedir, y en nueve segundos se destruye lo que tomó años construir.
¿Entonces la IA es el problema?
No. Ninguno de los tres datos acusa al modelo. Todos apuntan a cómo se le pide el trabajo. Quien trabaja en serio con estas herramientas no está haciendo vibe coding. Está programando con varios agentes a la vez y ejerce de jefe de proyecto, de orquestador y de ingeniero de software. El vibe coder construye un cohete que por fuera se ve impecable. Despega, y revienta.
Del prompt al encargo
La primera corrección es la que más rinde. Se habla mucho de ingeniería de prompts, como si existiera una frase mágica. Un modelo rara vez falla por falta de capacidad. Falla por falta de encargo, y un buen encargo tiene cuatro partes:
- Contexto: qué archivos y qué convenciones manda el proyecto.
- Objetivo: qué tiene que ser cierto cuando termine.
- Límites: qué no debe tocar.
- Verificación: cómo se comprueba que quedó bien.
Una petición como «arregla el login» puede devolver doce archivos tocados y ninguno probado. El mismo pedido con contexto, objetivo, límites y verificación devuelve un archivo, la sesión corregida, el esquema intacto y las pruebas en verde. Y el encargo se escribe una sola vez: en GitHub vive en el repositorio, en .github/copilot-instructions.md, y aplica para todos los que trabajen ahí.
Cómo se trabaja con agentes
El primer consejo es el que nadie espera: los encargos no se escriben, se dictan. Hablando salen más largos y con más contexto que tecleando, y el contexto es lo que decide el resultado. La ponencia, sus láminas y este artículo se dirigieron así, por micrófono.
Tres reglas no se negocian. Alcance mínimo, porque ningún agente trabaja con permisos que no necesita. Revisión humana antes de integrar. Y piezas pequeñas con un criterio de aceptación escrito.
El flujo va de la tarea al pull request. Se asigna un issue, el agente de programación de Copilot lo trabaja en la infraestructura de GitHub y devuelve un pull request, que se revisa y se aprueba incluso desde el teléfono. Cada tarea va con el modelo que le corresponde, pequeño para lo rutinario y grande solo cuando hace falta. Y lo que se repite se guarda como skill, una instrucción que se escribe una vez y el agente reusa.
Las certificaciones de este año evalúan justo eso. La guía del examen GH-300 de GitHub Copilot, en su versión del 7 de agosto de 2026, pide modo agente, sesiones con subagentes, MCP y la CLI. El AI-103 de Microsoft evalúa RAG, soluciones multiagente orquestadas, guardrails y flujos de aprobación.
Varios agentes sobre el mismo proyecto
Lo común es lanzar una petición y quedarse mirando mientras responde. Eso todavía no es trabajar con agentes. En un sistema de gestión que construí este año, varios agentes avanzaban a la vez sobre partes distintas del proyecto, coordinados por un tablero Kanban que llegó a 323 historias. Un agente solo ve las historias que nadie está tocando y cuyas dependencias ya están hechas, la toma antes de escribir una línea, y el tablero se la puede negar.
Una vez dos agentes entraron con el mismo identificador, el tablero los confundió y los dos escribieron el mismo archivo. Se perdió una tarea entera. Desde entonces el tablero rechaza el identificador repetido. Coordinar agentes se parece mucho a coordinar personas. Y apenas está empezando: según el informe State of AI Agents 2026 de Databricks, el uso de flujos multiagente creció un 327 % en cuatro meses de 2025, y solo el 19 % de las organizaciones tiene agentes en producción.
Un proyecto de 2022 y uno de 2026
La inteligencia artificial no sirve para hacer lo mismo más rápido. Sirve para construir muchísimo más, y eso solo pasa si se sabe usar.
En 2022 dirigí una plataforma de empleo con un equipo de seis desarrolladores: seis meses hasta tenerla funcionando y 779 commits. En 2026 construí un sistema de gestión para escuelas de natación yo solo, coordinando agentes: cinco semanas, del 19 de agosto al 24 de septiembre, y 1.148 commits. La cantidad de commits no dice que un proyecto esté completo, y un commit de un agente suele ser más pequeño que uno escrito a mano. Lo que sí lo dice es que quedó en línea, con seis roles distintos, 22 migraciones aplicadas y 92 comprobaciones de aislamiento de datos.
El archivo digital de la Facultad de Ciencias de la UCV, que también construí, está diseñado al revés de PocketOS: tope de gasto fijo, credenciales que no salen del servidor y ningún cambio de un registro sin la aprobación de una persona.
Las capas de la programación
Cada capa de la computación subió el nivel de abstracción: tarjetas perforadas, ensamblador, lenguajes de alto nivel, bibliotecas, la nube y ahora los agentes. Ninguna quitó la necesidad de entender la de abajo. Por eso en Organización y Estructura del Computador se ve ensamblador. La capa de abajo es la forma real de encontrar los errores, las deficiencias y los límites de la de arriba. Sin ella no se pueden ver del todo los errores de un agente, ni optimizar lo que hace.
El Dev Barometer de BairesDev, publicado el 11 de junio de 2026 sobre 1.569 desarrolladores de 77 países, pone el dato. El 85 % de los junior dice que la IA mejoró su comprensión del código, y solo el 16 % de los senior considera que los junior entienden del todo el código que entregan. La IA no reemplaza al que estudia. Reemplaza al que dejó de hacerlo.
Y lo que hay que estudiar cambia rápido. Según el Future of Jobs Report 2025 del Foro Económico Mundial, el 39 % de las habilidades actuales de un trabajador cambiará o quedará obsoleto entre 2025 y 2030. Casi todo lo contado aquí puede quedar obsoleto en unos meses, y al mismo tiempo están naciendo criterios nuevos, como orquestar agentes. Quien está estudiando hoy llega a tiempo para dominarlos.
Llevar esto a una empresa
Esto lo aplico todos los días. En Workforce.com, una plataforma de gestión de personal con más de diez mil clientes, lidero las integraciones de Latinoamérica: conecto el control horario con puntos de venta como Oracle Simphony y NCR Aloha, con SAP y con la nómina de ADP. En Diamond Hotel PMS, del que soy socio y responsable técnico, el sistema de gestión hotelera opera en cinco países. En los dos casos la inteligencia artificial entra con las mismas reglas de este artículo: presupuesto controlado, permisos por perfil y una persona que aprueba antes de que algo se escriba.
Fuentes
- METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, julio de 2025.
- METR. We are Changing our Developer Productivity Experiment Design, 24 de febrero de 2026.
- McKinsey. Encuesta a 4.500 desarrolladores en 150 empresas sobre el impacto de la IA generativa.
- OCDE. AI Incidents Monitor, incidente de PocketOS, 27 de abril de 2026.
- Hackread. Cursor AI Agent Wipes PocketOS Database and Backups in 9 Seconds, abril de 2026.
- Databricks. State of AI Agents 2026.
- BairesDev. Dev Barometer, segundo trimestre de 2026, 11 de junio de 2026.
- Foro Económico Mundial. Future of Jobs Report 2025.
- Microsoft Learn. Guía de estudio del examen GH-300, GitHub Copilot.
- Microsoft Learn. Guía de estudio del examen AI-103.
- Andrej Karpathy. Publicación en X del 2 de febrero de 2025, donde aparece el término vibe coding.
- Collins English Dictionary. Palabra del año 2025.