"Ya no hay una línea clara entre ambos modos de usar IA para programar. Y eso debería preocuparnos."
El artículo de Simon Willison generó una de las discusiones más activas de la semana en HN, con cientos de comentarios debatiendo si la distinción entre los dos modos sigue siendo útil o si ya es obsoleta.
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
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.
"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."
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.
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.
Para founders, CTOs y equipos chicos que usan IA como palanca, la convergencia que describe Willison tiene implicaciones concretas:
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.
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ó.
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.
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.
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.
Basado en "Vibe coding and agentic engineering are getting closer" de Simon Willison · Adaptado por ADMP