Qué Es Vibecoding y Por Qué Cambia el Desarrollo de Software para Siempre
Vibecoding es una metodología de desarrollo donde el programador describe intención — en lenguaje natural — y un agente de IA genera, prueba y refina el código. Acuñado por Andrej Karpathy en 2025, el término describe la transición del desarrollador de escritor de código a director de agentes. ITERRUPTIVO usa vibecoding en producción desde 2025, con una capa obligatoria de auditoría humana en cada commit para garantizar seguridad OWASP.
El origen del término: Andrej Karpathy, 2025
"Vibecoding" lo nombró Andrej Karpathy en un post de X (antes Twitter) en febrero de 2025. Karpathy describió una forma de programar donde el desarrollador no escribe código línea a línea sino que "da la vibe" de lo que quiere — describe el comportamiento, el resultado esperado, el estilo — y el modelo de lenguaje construye el código.
La palabra resonó porque capturó algo que muchos desarrolladores ya estaban experimentando con herramientas como GitHub Copilot, Cursor y Claude Code: el trabajo de programar se estaba desplazando de la sintaxis a la intención.
De qué estaba hablando realmente
Karpathy no estaba diciendo que programar se volvió fácil o que los desarrolladores ya no importan. Estaba observando que el modelo mental del desarrollo estaba cambiando. El desarrollador competente de 2025 no es el que memoriza más sintaxis — es el que sabe descomponer un problema en especificaciones claras, evaluar el código generado con criterio y dirigir al agente cuando se equivoca.
Esa transición no es trivial. Requiere un conjunto de habilidades diferente: capacidad de especificación precisa, criterio arquitectónico para evaluar lo que el agente propone, y conocimiento de seguridad para detectar cuando el código generado tiene vulnerabilidades que el agente no identificó.
Por qué resonó en la comunidad de devs
El término se volvió viral porque describía algo real que estaba pasando sin nombre. Los desarrolladores que llevaban meses usando Claude Code o Cursor reconocieron inmediatamente la experiencia: esa sensación de dirigir un agente que ejecuta rápido, que a veces sorprende con soluciones elegantes, y que a veces hace algo completamente inesperado que tienes que corregir.
La comunidad se dividió, como suele ocurrir. Algunos lo celebraron como el fin del trabajo repetitivo de escribir boilerplate. Otros lo criticaron como una receta para código inseguro generado sin entendimiento real. Ambos tienen algo de razón, y la tensión entre esas dos posiciones es exactamente donde vive la práctica honesta del vibecoding.
Cómo funciona el vibecoding en la práctica
Vibecoding en la práctica no es hablar con la IA y esperar que aparezca una aplicación funcionando. Tiene un ciclo estructurado que, cuando se hace bien, es sorprendentemente eficiente.
El ciclo: intención → prompt → generación → revisión → commit
Intención: El desarrollador tiene un objetivo claro. No "hacer algo con usuarios" sino "implementar un endpoint REST que recibe una petición POST con email y contraseña, valida con bcrypt, y devuelve un JWT con expiración de 24 horas".
Prompt: La intención se convierte en un prompt que incluye el contexto necesario: el stack técnico, las convenciones del proyecto, las restricciones de seguridad y el comportamiento esperado en casos de error. Un prompt bien escrito es la diferencia entre código que encaja en el proyecto y código que hay que reescribir.
Generación: El agente genera el código, incluyendo (cuando el prompt lo especifica) los tests unitarios correspondientes. En herramientas como Claude Code, el agente también puede ejecutar los tests y corregir los errores automáticamente antes de presentar el resultado.
Revisión: El desarrollador humano revisa el código generado. No busca errores de sintaxis — el agente rara vez los comete. Busca problemas de arquitectura, decisiones de seguridad implícitas que podrían ser incorrectas, y alineación con el diseño del sistema completo.
Commit: El código aprobado se commitea. En el modelo ITERRUPTIVO, antes del merge se ejecuta automáticamente la capa de seguridad (Robin Hood) que verifica OWASP Top 10.
Este ciclo puede iterar. Si la revisión encuentra un problema, el desarrollador da el feedback al agente y el ciclo se repite. En la práctica, para tareas bien especificadas, 1-2 iteraciones son suficientes.
Qué herramientas se usan hoy
Las herramientas de vibecoding más usadas en producción real en 2026:
Claude Code (Anthropic) — Agente de desarrollo que opera directamente en el terminal, puede leer y modificar el filesystem, ejecutar comandos y hacer commits. La herramienta principal en el stack de ITERRUPTIVO. Su ventaja: contexto largo que le permite entender proyectos grandes, y capacidad de razonamiento profundo para problemas de arquitectura.
Cursor — Editor de código con IA integrada profundamente. Fuerte en edición de archivos existentes y refactoring. Popular entre desarrolladores que prefieren un IDE tradicional con capacidades de IA.
GitHub Copilot Workspace — La apuesta de GitHub para flujos de trabajo completos de IA. Integrado con el ecosistema de GitHub. Más fuerte en proyectos que ya viven en GitHub y menos flexible para configuraciones custom.
Windsurf (Codeium) — Competidor directo de Cursor, con modelos propios. Interesante para equipos que quieren control sobre qué modelo usan.
La elección de herramienta depende del equipo y el proyecto. No hay un ganador absoluto. Lo que sí es claro: tener experiencia en al menos una de estas herramientas pasó de ser una ventaja a ser un requisito para desarrolladores que quieren seguir siendo competitivos.
El rol del desarrollador cuando la IA escribe
El desarrollador en un flujo de vibecoding hace cuatro cosas que la IA no puede hacer sola:
-
Define el problema correctamente. El agente es excelente ejecutando especificaciones claras. Es malo infiriendo qué es lo correcto cuando la especificación es ambigua. El desarrollador es quien convierte el requerimiento de negocio en una especificación técnica precisa.
-
Evalúa la arquitectura. El agente puede generar código que funciona pero que no escala, que crea dependencias circulares o que viola convenciones del proyecto. El desarrollador con criterio arquitectónico detecta esos problemas antes de que se conviertan en deuda técnica.
-
Audita la seguridad. Este punto es crítico y lo expandemos más abajo. El código generado puede tener vulnerabilidades que el agente no identificó porque el prompt no las especificó. El desarrollador — o en el modelo ITERRUPTIVO, el agente de seguridad Robin Hood — verifica que el código es seguro.
-
Toma las decisiones de producto. Cuando el agente genera dos alternativas válidas técnicamente, alguien tiene que elegir cuál es mejor para el producto. Esa decisión requiere contexto de negocio que solo el humano tiene.
Vibecoding vs metodologías anteriores
Para entender qué cambia el vibecoding, es útil compararlo con las metodologías que dominaban antes:
| Metodología | Quién escribe el código | Velocidad | Seguridad nativa | Curva de aprendizaje | |---|---|---|---|---| | Desarrollo tradicional | El desarrollador, solo | Lenta | Dependiente del dev | Alta (lenguajes + frameworks) | | Pair programming | Dos devs, uno escribe, uno revisa | Media | Mejor que solo | Alta | | TDD | El desarrollador, guiado por tests | Media-alta | Variable | Media | | No-code / Low-code | Plataforma hace el código | Alta para casos simples | Limitada por la plataforma | Baja | | Vibecoding | El agente, dirigido por el dev | Muy alta | Requiere capa explícita | Media (especificación + auditoría) |
El vibecoding no reemplaza TDD — los dos son complementarios. Un agente puede generar los tests y el código al mismo tiempo. Lo que vibecoding sí reemplaza en muchos flujos es el pair programming para tareas de implementación rutinaria: el agente es el "par" que escribe, el desarrollador es el que revisa.
La diferencia fundamental con no-code es el nivel de control. En plataformas no-code, el código que genera la plataforma es opaco. En vibecoding con agentes como Claude Code, el código es tuyo, es legible, es auditable y es portable.
Los límites reales del vibecoding que nadie te cuenta
El vibecoding tiene limitaciones reales que los defensores entusiastas suelen suavizar. Aquí van sin filtro.
Qué tareas siguen requiriendo juicio humano profundo
Diseño de arquitectura de sistemas distribuidos. Cuando tienes que decidir cómo distribuir responsabilidades entre microservicios, cómo manejar la consistencia eventual en un sistema con alta concurrencia, o cómo diseñar un modelo de datos que va a vivir 10 años, el agente puede proponer opciones pero no puede hacer la decisión correcta sin el contexto completo del negocio y los patrones de uso esperados. Eso requiere un arquitecto humano.
Debugging de problemas de producción complejos. Cuando un sistema está fallando en producción y el error es una combinación de condición de carrera, problema de configuración de red y estado inconsistente en la base de datos, el debugging requiere razonamiento causal que los agentes todavía hacen con menos confiabilidad que un ingeniero experimentado.
Decisiones de modelo de negocio reflejadas en el código. Cómo modelar un contrato de suscripción, qué pasa cuando un usuario cambia de plan en mitad del ciclo de facturación, cómo manejar los casos edge de una regla de negocio compleja — esas decisiones tienen implicaciones de negocio que el agente no puede inferir correctamente sin un human in the loop que las valide.
Refactoring profundo de código legacy. Cuando el código base tiene décadas de historia y la lógica de negocio está enterrada en naming inconsistente, el agente puede generar código que parece correcto pero cambia silenciosamente un comportamiento que era intencional (aunque no estuviera documentado).
El riesgo de vibecoding sin seguridad: OWASP en cada commit
Este es el punto más importante de este artículo desde la perspectiva de un CTO o CISO.
Los agentes de IA son buenos escribiendo código funcional. No son consistentemente buenos escribiendo código seguro. La razón es estructural: los datos de entrenamiento contienen millones de ejemplos de código que funciona, incluyendo código con vulnerabilidades conocidas. El agente aprende a generar código que resuelve el problema, no necesariamente código que es seguro.
Las vulnerabilidades más comunes que hemos visto en código generado por agentes:
- Inyección SQL: El agente usa concatenación de strings en queries cuando debería usar prepared statements.
- Falta de validación de input: El agente asume que el input es válido sin sanitizarlo.
- Secretos hardcodeados: El agente incluye API keys o credenciales directamente en el código cuando está construyendo un ejemplo rápido.
- Lógica de autorización incompleta: El agente verifica autenticación pero olvida verificar que el usuario autenticado tiene permisos para acceder al recurso específico.
- Dependencias con CVEs conocidos: El agente usa versiones de librerías que en el momento de su entrenamiento eran recientes, pero que hoy tienen vulnerabilidades documentadas.
Ninguna de estas vulnerabilidades es imposible de detectar con una revisión humana o una herramienta de SAST. El problema es la velocidad: si estás haciendo vibecoding a alta velocidad y haciendo commits cada hora, el proceso manual de revisión de seguridad no escala.
La solución no es hacer vibecoding más lento. Es automatizar la verificación de seguridad para que corra en cada commit sin depender del tiempo humano. Para más detalles sobre cómo implementar esto, ve a DevSecOps con Agentes IA: OWASP en Cada Commit.
Vibecoding con auditoría humana: el modelo ITERRUPTIVO
En ITERRUPTIVO, el vibecoding tiene una capa de auditoría obligatoria que lo hace viable en producción.
Por qué no es suficiente con "revisar el código al final"
La revisión al final del sprint es el equivalente en seguridad de hacer el control de calidad cuando la fábrica ya cerró. Cuando encuentras un problema estructural de seguridad en la revisión final, tienes dos opciones: retrasas el release o lanzas sabiendo que hay un riesgo. Ninguna es buena.
El modelo correcto es integrar la verificación de seguridad en el ciclo de generación. No como una etapa separada, sino como una condición del merge.
Cómo funciona la capa de auditoría DevSecOps en cada generación
En el pipeline de ITERRUPTIVO, cada pull request pasa por tres capas antes del merge:
Capa 1 — Agente Robin Hood (automática): Analiza el código contra el OWASP Top 10, revisa las dependencias contra la base de datos de CVEs, verifica que no hay secretos hardcodeados, y valida las configuraciones de seguridad críticas. Si detecta problemas de severidad alta o crítica, bloquea el merge automáticamente. El reporte es visible para el desarrollador y el CISO.
Capa 2 — Revisión de ingeniero senior (humana): Un ingeniero senior revisa la lógica de negocio, la coherencia arquitectónica y los casos edge que el agente de seguridad no cubre. Esta revisión no reemplaza a Robin Hood — la complementa con el juicio que requiere contexto de proyecto.
Capa 3 — Revisión CISO (para cambios de arquitectura de seguridad): Cristian Luciano revisa cambios que afectan autenticación, autorización, manejo de datos sensibles o integraciones con sistemas externos. No todos los commits pasan por esta capa — solo los que tienen cambios en áreas de seguridad definidas.
El resultado: la velocidad del vibecoding más la seguridad de un proceso de revisión estructurado. No es gratis — el proceso agrega tiempo al ciclo. Pero es significativamente más rápido que una revisión de seguridad post-sprint, porque los problemas se detectan cuando el código es nuevo y fácil de cambiar.
Cómo está cambiando el mercado laboral de desarrolladores
El impacto del vibecoding en el mercado laboral es real, y esconder la cabeza no ayuda a nadie.
Qué habilidades se vuelven críticas
Especificación de requisitos técnicos en lenguaje natural con precisión. El desarrollador que sabe escribir un prompt que produce el código correcto en la primera o segunda iteración es significativamente más productivo que uno que necesita 10 iteraciones de ajuste.
Criterio arquitectónico y de seguridad. Las habilidades de evaluación se vuelven más valiosas que las de producción. Saber si una solución es correcta, si escala, si es segura — eso no lo automatiza el agente.
Comprensión de cómo funcionan los modelos de IA. No hace falta ser un investigador de ML, pero entender las limitaciones de los modelos — qué tipos de código generan bien, en qué contextos se confunden, cómo formular el prompt para obtener el resultado correcto — es una habilidad diferencial.
Sistemas thinking. El nivel de abstracción al que trabaja el desarrollador sube. En lugar de pensar en líneas de código, se piensa en componentes, flujos de datos, contratos entre servicios.
Qué habilidades se deprecan
Memorización de sintaxis y APIs. Si el agente genera el código correcto para usar una API, memorizar los métodos exactos de esa API tiene cada vez menos valor.
Escritura de boilerplate. El código repetitivo — configuraciones, CRUD básico, mapeo de entidades, serialización — es exactamente lo que los agentes generan mejor. No tiene sentido que un desarrollador senior invierta tiempo en eso.
Debug de errores de compilación triviales. Los agentes no cometen errores de sintaxis. El debugging que queda para humanos es el conceptualmente difícil, no el mecánico.
Lo que no cambia: el entendimiento profundo de sistemas, la capacidad de tomar decisiones de diseño con implicaciones de largo plazo, y el criterio de negocio para saber qué construir. Esas habilidades se vuelven más valiosas, no menos.
Caso real: vibecoding en la Suite Inmobiliaria de Global EcoPlaza
La Suite Inmobiliaria de Global EcoPlaza fue construida usando vibecoding con auditoría humana como metodología principal. Fue el primer proyecto a escala donde validamos que el modelo era viable para producción real.
Distribución de código generado vs código humano
No publicamos el porcentaje exacto porque el número solo tiene sentido con contexto. Lo que sí podemos decir: la mayoría del código de la Suite fue generado inicialmente por agentes. El código escrito directamente por humanos fue principalmente en dos categorías: decisiones de arquitectura central que preferimos controlar directamente, y casos edge de lógica de negocio compleja donde el contexto de la empresa era demasiado específico para que el agente lo infiera correctamente.
El total de código revisado por humanos fue el 100%. Cada línea, sin excepción, pasó por revisión antes del merge.
Bugs encontrados antes y después de implementar auditoría
Implementamos la capa de auditoría de seguridad (Robin Hood) en una etapa intermedia del proyecto, no desde el inicio. Tenemos por lo tanto datos comparativos del período sin auditoría automática versus el período con auditoría.
La diferencia más significativa: antes de la auditoría automática, los problemas de dependencias con vulnerabilidades conocidas llegaban a revisión humana sin ser detectados en el proceso de generación. El agente usaba versiones de librerías que en su contexto de entrenamiento eran recientes, pero que tenían CVEs publicados después. La revisión humana no siempre los detectaba porque no es posible verificar manualmente todas las dependencias en cada commit.
Con la auditoría automática, esos problemas se detectan y reportan antes del merge, sin depender del tiempo o la atención del revisor humano. El costo de corrección baja dramáticamente cuando el bug se encuentra en el punto de generación versus cuando se encuentra en producción.
Academia ITERRUPTIVO: aprende vibecoding con auditoría
Si quieres adoptar vibecoding en tu equipo con las salvaguardas correctas, la Academia ITERRUPTIVO tiene programas específicos para equipos de desarrollo que quieren hacer la transición sin comprometer la seguridad del código.
El programa cubre especificación de prompts, flujo de revisión de código generado, integración de herramientas de seguridad en el pipeline, y los criterios de evaluación para saber cuándo el agente está tomando decisiones correctas versus cuándo necesita corrección humana.
No es un curso de "cómo usar GitHub Copilot para novatos". Es formación para equipos que ya desarrollan y quieren subir de nivel en la dirección correcta.
Preguntas frecuentes
¿Necesito saber programar para hacer vibecoding?
Técnicamente puedes generar código sin saber programar usando herramientas actuales. Pero para hacer vibecoding de manera responsable en producción, necesitas suficiente comprensión de código para evaluar si lo que el agente generó es correcto y seguro. No necesitas ser un experto en todos los lenguajes, pero sí necesitas criterio técnico. La persona que no puede leer el código que el agente generó no puede auditarlo. Y sin auditoría, estás desplegando código en producción sin saber qué hace realmente.
¿El código generado es seguro?
No por defecto. Los agentes de IA generan código funcional con mayor consistencia que código seguro. La diferencia es que la seguridad requiere conocimiento de patrones de ataque que no siempre están bien representados en los datos de entrenamiento, y requiere considerar el contexto de cómo se va a usar el código. La respuesta correcta es: el código generado puede ser seguro si tienes un proceso de verificación de seguridad integrado en el flujo de desarrollo. Sin ese proceso, asumir que el código es seguro es un riesgo real.
¿Las empresas contratan devs que solo hacen vibecoding?
Todavía no, pero el perfil está cambiando. Las empresas que adoptan IA para desarrollo buscan desarrolladores que combinen criterio técnico sólido con habilidad de especificación y dirección de agentes. El "solo vibecoding" sin comprensión profunda de sistemas todavía no tiene demanda en el mercado. Lo que sí tiene demanda es el desarrollador que sabe usar agentes eficientemente y no pierde tiempo en tareas que la IA hace mejor.
¿Cómo se testa el código que genera la IA?
Igual que cualquier código: con tests unitarios, de integración y E2E. La diferencia en el modelo AI-first es que el agente puede generar los tests al mismo tiempo que genera el código de implementación. Eso no garantiza que los tests sean buenos — un agente puede generar tests que validan el comportamiento incorrecto si la especificación era ambigua. La revisión humana de los tests es tan importante como la revisión del código. En el pipeline de ITERRUPTIVO, los tests deben pasar antes del merge, pero la calidad de los tests también es parte de la revisión humana.
Conclusión
El vibecoding no es una moda. Es una transición estructural en cómo se produce el software, y está pasando independientemente de si una empresa lo adopta o no.
La pregunta relevante no es "¿debo hacer vibecoding?" sino "¿cómo hago vibecoding con los controles correctos para que sea una ventaja y no un pasivo de seguridad?". La respuesta que hemos desarrollado en ITERRUPTIVO es: con auditoría humana en cada commit, con un agente de seguridad integrado en el pipeline, y con un equipo que entiende tanto las capacidades como las limitaciones de los modelos que usa.
El desarrollador que adopta esta metodología correctamente no se convierte en menos técnico — se convierte en técnicamente más eficiente y estratégicamente más valioso. Escribe menos código de boilerplate y toma más decisiones que importan. Eso es la evolución del oficio, no su reemplazo.
Ser Iterativamente Disruptivo en este contexto significa no esperar a que el mercado valide el modelo antes de adoptarlo. Significa probarlo, aprender de los errores y construir las salvaguardas que hacen que funcione en producción real.
¿Quieres dar el siguiente paso?
Si quieres ver cómo ITERRUPTIVO aplica vibecoding con auditoría humana en proyectos reales, o si tu equipo quiere adoptar la metodología con acompañamiento, hay dos opciones: