Vibe coding y agentic engineering se están fusionando

Los dos modos de programar con IA

Simon Willison es una de las voces más respetadas en el ecosistema del software. Creador de Django, referencia en Python, mantenedor de proyectos open source con millones de usuarios, y desde hace años uno de los pensadores más lúcidos sobre el impacto real de la IA en la programación.

A principios de 2026, en medio del auge de herramientas como Cursor, Copilot, Claude Code y Codex, Willison definió dos categorías para ordenar el caos. Del otro lado del charco, Andrej Karpathy había acuñado el término "vibe coding" para describir la experiencia de programar simplemente describiendo lo que querés y dejando que la IA lo escriba todo. Willison tomó ese concepto y le puso un contrapunto: el "agentic engineering".

El vibe coding es el modo más riesgoso y a la vez más popular: le pedís a una IA que escriba código, y si funciona, lo dejás así. No mirás lo que generó. No revisás la calidad. No entendés del todo qué hace. Si falla, le decís que está mal y cruzás los dedos para que lo arregle. Es rápido, es adictivo, y es perfectamente válido para herramientas personales donde un bug solo te afecta a vos.

El agentic engineering es la otra cara. Acá el programador es un profesional que entiende seguridad, mantenibilidad, performance y operaciones. Usa las herramientas de IA para aumentar su capacidad, pero revisa cada línea de código que la IA produce. El objetivo no es escribir más código más rápido. Es escribir mejor código más rápido. Como dice Willison: "si estás construyendo cosas de menor calidad más rápido, creo que eso es malo".

Lo extraño es que esas cosas ya empezaron a desdibujarse para mí. Y es bastante inquietante. Pensé que teníamos una delineación muy clara.

— Simon Willison, en el podcast High Leverage de Heavybit

Cuando la confianza reemplaza la revisión

En una entrevista con Joseph Ruscio para el podcast High Leverage, Willison tuvo una realización incómoda en vivo: las dos categorías que él mismo había definido con claridad meses atrás se estaban desdibujando en su propio flujo de trabajo diario.

"Pensé que teníamos una delineación muy clara", dice. "El vibe coding es cuando no estás mirando el código en absoluto. Quizás ni siquiera sabés programar. Le pedís algo a la IA, recibís algo, y si funciona, genial. Si no funciona, le decís que no funciona y cruzás los dedos."

Pero a medida que los agentes de IA se vuelven más confiables —escriben mejor código, con menos bugs, más consistentes— el hábito de revisar cada línea se debilita. Es un problema de calibración de confianza. Si el agente acierta 19 de cada 20 veces, el programador empieza a confiar. Y cuando confía, deja de revisar. Y cuando deja de revisar, el vibe coding y el agentic engineering se convierten en exactamente la misma cosa. La diferencia ya no está en el proceso, sino en el resultado. Y el resultado no se conoce hasta que algo sale mal.

Este fenómeno no es teórico. Willison, con 25 años de experiencia, admite que el alcance de los desafíos que puede asumir ha aumentado significativamente gracias a estas herramientas. Pero también nota que la línea entre "usar la IA como asistente" y "delegar en la IA" se está borrando más rápido de lo que le gustaría.

Años de experiencia de Simon Willison

"Sigo apoyándome en mis 25 años de experiencia como ingeniero. Pero el alcance de los desafíos que puedo asumir ha aumentado significativamente porque tengo el apoyo de estas herramientas."

El riesgo no es el código malo. Es el código bueno.

Hay una trampa conceptual en todo este debate. Casualmente se asume que el riesgo de la IA generativa es que produce código de baja calidad. Que hay que revisarlo porque la IA alucina, porque no entiende el contexto, porque es ingenua.

Willison plantea el problema inverso: el riesgo real no es que la IA escriba código malo. Es que escribe tan bien que dejamos de revisarlo. Cuando un agente produce código que se ve correcto, que pasa los tests, que tiene buena estructura, la tentación de confiar ciegamente es casi irresistible. Y ahí es donde se rompe la distinción entre vibe coding y agentic engineering.

"Un vibe coding para uso personal, donde si hay un bug te duele solo a vos, está bien", explica Willison. "Pero si estás construyendo software para otras personas, el vibe coding es irresponsable porque es información de otros. Otras personas se ven perjudicadas por tus bugs estúpidos. Necesitás un nivel más alto que ese."

El problema es que el agente no distingue entre "esto es para mí" y "esto es para otros". El agente produce el mismo código independientemente del contexto. La diferencia la hace el humano que decide cuánto revisar. Y esa decisión está cada vez más influenciada por la confianza acumulada en el agente, no por el riesgo real del producto.

El momento incómodo del podcast

Lo interesante del artículo de Willison no es solo el análisis —es cómo llegó a esa conclusión. En el podcast de Heavybit, mientras discutía con Joseph Ruscio la diferencia entre los dos modos, se dio cuenta en vivo de que ya no podía sostener la distinción con claridad.

"Cuando Joseph mencionó la distinción entre los dos, tuve una realización repentina de que ya no son tan distintos para mí como solían ser", confesó. "Es bastante inquietante."

Willison había publicado antes un artículo titulado explícitamente "Not all AI-assisted programming is vibe coding (but vibe coding rocks)", donde dejaba clara su postura: el vibe coding es fantástico cuando se entiende cuándo usarlo y cuándo no. Una herramienta personal donde un bug solo te duele a vos —adelante. Pero construir software para otros requiere un estándar más alto.

Esa distinción, que parecía tan clara en teoría, se está disolviendo en la práctica. Y Willison, siendo Willison, lo dice sin filtro: le molesta. Porque él quiere construir cosas de mayor calidad más rápido, no solo más rápido. Y cuando la línea se borra, mantener esa calidad requiere un esfuerzo consciente que no todo el mundo está dispuesto a hacer.

Qué significa esto para tu equipo

Para founders, CTOs y equipos chicos que usan IA como palanca, la convergencia que describe Willison tiene implicaciones concretas:

1. Definí el nivel de revisión según el riesgo

No todo el código merece el mismo nivel de escrutinio. Una herramienta interna que solo usás vos puede ser vibe coding. Un feature que impacta clientes requiere agentic engineering. Una API que maneja datos financieros o personales requiere algo más: revisión de seguridad, pruebas de penetración, auditoría. La línea no la define la herramienta —la define el impacto del error.

2. Automatizá la revisión, no la reemplaces

En vez de dejar de revisar el código generado por IA, automatizá la revisión. Tests unitarios, integración continua, linters, análisis estático, escaneo de seguridad. Que la máquina revise a la máquina. Pero asegurate de que el humano entienda lo que decide. Una pipeline de CI/CD con 50 tests verdes puede dar una falsa sensación de seguridad si los tests no cubren los casos borde que la IA no consideró.

3. Medí calidad, no velocidad

Si tu métrica principal es "líneas de código generadas por hora" o "PRs mergeados por día", estás optimizando para lo incorrecto. Las métricas que importan son bugs en producción, tiempo de debugging, deuda técnica acumulada, facilidad de mantener el código a los 6 meses. La velocidad sin calidad no es leverage. Es deuda técnica con intereses compuestos.

4. Creá un framework de decisión para tu equipo

Cada miembro del equipo debería poder responder dos preguntas antes de usar una herramienta de IA: (a) ¿Cuál es el riesgo si este código falla? (b) ¿Cuánto tiempo invertí en revisar lo que generó la IA? Si la respuesta a (a) es "alto" y la respuesta a (b) es "poco", tenés un problema de calibración. Estás haciendo vibe coding cuando deberías estar haciendo agentic engineering.

La línea se borra. ¿Y ahora?

No es vibe coding vs agentic engineering. Se están fusionando, como bien señala Willison. Y el que entienda primero cómo mantener calidad en un mundo donde el código lo escribe cada vez más la IA va a tener una ventaja competitiva real.

El que no, va a descubrir que el leverage sin control no es leverage. Es una bomba de tiempo en tu codebase.

Construí mejor calidad más rápido. No solo más rápido.

#IA #AgenticEngineering #VibeCoding #Leverage #CalidadDeSoftware

Basado en "Vibe coding and agentic engineering are getting closer" de Simon Willison · Adaptado por ADMP

Preguntas frecuentes

¿Qué es vibe coding y cómo funciona?

El vibe coding es una forma de programar donde describís lo que querés en lenguaje natural y la IA genera el código por vos. En vez de escribir línea por línea, le das instrucciones generales y ajustás los resultados, como si estuvieras dirigiendo a un asistente. Es ideal para prototipar rápido, pero requiere ojo para revisar lo que genera.

¿Qué es agentic engineering?

El agentic engineering es el laburo de diseñar y encadenar agentes de IA autónomos que hacen tareas por su cuenta, con herramientas y objetivos definidos. En lugar de un simple chat, armás sistemas que planifican, ejecutan y corrigen procesos de forma automática. Es una disciplina que mezcla prompts, flujos de trabajo y manejo de herramientas.

¿Por qué se están fusionando el vibe coding y el agentic engineering?

Porque el vibe coding ya no se queda solo en generar código, sino que esos mismos agentes pueden escribir, ejecutar y depurar sus propios proyectos de forma autónoma. La fusión aparece cuando usás agentes que entienden instrucciones vagas, las convierten en código y además lo iteran solos. Eso convierte una sesión de chat en una mini fábrica de software.

¿Necesito saber programar para usar vibe coding con agentes?

No hace falta ser programador avanzado, pero sí tenés que entender la lógica básica de los proyectos para no perderte. Con el vibe coding podés crear cosas sin escribir código a mano, pero si querés que los agentes laburen bien, tenés que saber explicar qué necesitás y revisar lo que hacen. O sea, más que programar, vas a aprender a dirigir a un equipo de IA.