Vibe coding y agentic engineering se están acercando más de lo que yo quería
(simonwillison.net)- vibe coding y agentic engineering originalmente se distinguían por los estándares de revisión de código y responsabilidad, pero a medida que aumenta la confiabilidad de los agentes de programación, el límite se está volviendo borroso en el trabajo real de producción
- El vibe coding puede ser útil para herramientas personales porque consiste en casi no mirar el código y aceptar el resultado si hace lo que se quería, pero parece una forma irresponsable de trabajar cuando se trata de software del que dependen la información y la experiencia de otras personas
- Agentes como Claude Code resuelven repetidamente bien endpoints JSON API, consultas SQL, pruebas y documentación, lo que lleva a situaciones en las que ya no se revisa cada línea generada, y eso crea el riesgo de depositar confianza en algo que, a diferencia de un equipo humano, no tiene reputación ni responsabilidad
- Ahora ya se puede crear en 30 minutos un repositorio con 100 commits, un buen README y una batería completa de pruebas, así que se volvió difícil juzgar la calidad por la apariencia; el criterio real pasa a ser si alguien ha usado ese software de forma sostenida
- Las herramientas de IA no reemplazan la experiencia del ingeniero de software, sino que la amplifican; si la velocidad de producción de código pasa de 200 líneas por día a 2,000, el cuello de botella se mueve hacia el diseño, la validación, la operación y el uso real
La frontera entre vibe coding y agentic engineering
- En Heavybit High Leverage podcast Ep. #9, al hablar de herramientas de programación con IA, surge la idea de que vibe coding y agentic engineering se están acercando cada vez más en el trabajo real
- Antes, en Not all AI-assisted programming is vibe coding (but vibe coding rocks), se distinguía claramente entre vibe coding y la programación asistida por IA de forma responsable, y a esta última después empezó a llamársele agentic engineering
- El vibe coding se define como una forma de trabajo en la que casi no se mira el código; un usuario que incluso podría no saber programar pide el resultado que quiere, y si funciona lo acepta, y si no, vuelve a pedirlo
- En casos como herramientas personales, donde un bug solo te perjudica a ti mismo, el vibe coding puede ser útil, pero al crear software del que dependen la información y la experiencia de otras personas, parece una forma irresponsable de trabajar
- El agentic engineering consiste en que un ingeniero de software profesional aprovecha al máximo las herramientas de IA entendiendo restricciones como seguridad, mantenibilidad, operación y rendimiento
- El objetivo no es crear resultados de menor calidad más rápido, sino crear sistemas de producción de mayor calidad más rápido
- El problema es que, a medida que los agentes de programación se vuelven más confiables, incluso en tareas de nivel producción ya se deja de revisar cada línea del código generado
La confianza que lleva a omitir la revisión de código
- Si se le pide a Claude Code que cree un endpoint JSON API, ejecute una consulta SQL y muestre el resultado como JSON, nace la confianza de que lo hará bien
- Incluso al pedirle que agregue pruebas automatizadas y documentación, se empieza a esperar que el resultado sea aceptable, y en ese proceso aparecen casos en los que el código real no se revisa
- Si no se revisó el código, queda una sensación de culpa sobre si realmente es responsable usarlo en producción
- Esto puede verse de forma parecida a cómo se usa software de otros equipos cuando se trabaja como engineering manager en una organización grande
- Si otro equipo ofrece un servicio de redimensionado de imágenes, normalmente no se leen todas las líneas del código que ese equipo escribió
- Se revisa la documentación, se prueba redimensionar imágenes y luego se lanza la propia funcionalidad
- Solo cuando aparecen bugs o problemas de rendimiento se llega a mirar el repositorio Git
- En la mayoría de los casos, ese servicio se trata como una caja negra a medias
- Poco a poco también se empieza a tratar a los agentes de la misma manera, pero a diferencia de un equipo humano, Claude Code no tiene reputación profesional ni responsabilidad (accountability)
- Un equipo humano puede construir reputación al crear buen software en el pasado y siente la presión de que un resultado deficiente afecte su reputación profesional
- Claude Code no puede tener esa reputación, pero está construyendo confianza al resolver repetidamente tareas simples de forma correcta y de una manera alineada con una preferencia por el trabajo repetitivo
- Aquí hay un elemento de normalización de la desviación
- Cada vez que el modelo escribe código correcto sin supervisión cercana, la confianza aumenta
- Y también crece el riesgo de volverse excesivamente confiado en el momento equivocado y salir perjudicado después
Evaluar software se vuelve más difícil
- Antes, si un repositorio de GitHub tenía 100 commits, un buen README y pruebas automatizadas, era fácil concluir que el proyecto había recibido bastante dedicación y cuidado
- Ahora se puede crear en 30 minutos un repositorio Git con 100 commits, un README impecable y pruebas que cubran cada línea de código
- Ese tipo de repositorios puede verse por fuera exactamente igual que un proyecto construido con cuidado y dedicación durante mucho tiempo
- Puede que realmente sea así de bueno, pero es difícil saberlo solo por la apariencia, y el mismo problema aparece incluso con los propios proyectos
- Un criterio que pesa más que la calidad de las pruebas y la documentación es si alguien realmente ha usado ese software
- Incluso si es un resultado hecho con vibe coding, si quien lo creó lo ha usado todos los días durante las últimas dos semanas, se considera mucho más valioso que algo generado y apenas probado
El cuello de botella se mueve de escribir código a otras etapas
- Si se pasa de producir 200 líneas de código al día a poder producir 2,000, otras partes del ciclo de vida del desarrollo de software empiezan a romperse
- El ciclo de vida tradicional del desarrollo de software estaba diseñado bajo la premisa de producir apenas unos cientos de líneas de código por día
- El cambio en los cuellos de botella no afecta solo a las etapas posteriores, sino también a las anteriores
- En la charla de Jenny Wen, se plantea que el proceso de diseño tradicional parte del supuesto de que “hay que acertar con el diseño”
- Porque si se le entrega algo equivocado al equipo de ingeniería y pasan 3 meses construyéndolo, eso es un desastre
- Como el diseño lleva a trabajo costoso, se establecen procesos de diseño extensos
- Pero si el build no tarda 3 meses, entonces el costo de equivocarse baja mucho y el proceso de diseño puede asumir muchos más riesgos
Por qué aun así no parece el fin de la carrera de ingeniería de software
- Hablar con agentes se siente como un “moon language” difícil de entender para la mayoría de la gente
- Una de las razones por las que esto no parece el fin de la carrera de ingeniería de software, aunque las computadoras ya puedan escribir código por sí solas, es que estas herramientas amplifican la experiencia previa
- Quien sabe lo que está haciendo puede moverse mucho más rápido junto con herramientas de IA
- Cuanto más se usan herramientas de IA, más se confirma una y otra vez que crear software en sí sigue siendo algo muy difícil
- Incluso teniendo todas las herramientas de IA, lo que se busca lograr sigue siendo difícil
- Matthew Yglesias escribió en un tuit: “Después de cinco meses, me doy cuenta de que no quiero hacer vibecode. Quiero que empresas de software gestionadas profesionalmente usen asistentes de programación con IA para crear productos de software más numerosos, mejores y más baratos, y luego me los vendan”, y se coincide con esa idea
- Se resume con la analogía de que, aunque uno podría arreglar la plomería de su casa viendo suficientes videos de YouTube sobre plomería, de todos modos preferiría contratar a un plomero
El riesgo de SaaS frente al desarrollo interno
- Incluso frente a la amenaza de que las empresas dejen de usar SaaS y puedan crear sus propias soluciones, sigue aplicando el mismo criterio de preferir software validado por el uso real
- En proyectos personales, se prefiere al menos una herramienta que su creador haya usado directamente durante unas semanas
- En versión enterprise, el criterio pasa a ser que no se querría adoptar un CRM a menos que al menos dos grandes empresas distintas lo hayan usado con éxito durante 6 meses
- Antes de asumir el riesgo, se quiere una solución que haya demostrado en la práctica que realmente funciona
1 comentarios
Comentarios de Hacker News
El vibe coding y los LLM no crearon organizaciones o ingenieros sin disciplina; solo expusieron y aceleraron problemas que ya existían
Muchos ingenieros tienen estándares y prácticas de escritura de código laxos o inexistentes, y muchos equipos también tienen criterios débiles para desplegar código a producción
No es un fenómeno nuevo; significa que ahora muchas más personas y equipos que nunca han seguido estándares dentro del ciclo de vida de desarrollo de software pueden producir mucho más código y concretar ideas con mayor facilidad
Nunca he visto a un colega convertirse en buen ingeniero solo por escribir código rápido
Los mejores ingenieros que conozco fueron personas que, con base en experiencia y juicio cuidadoso, compartían ideas clave con el equipo y ayudaban a orientar bien la dirección del sistema
“Claude, hazme un sistema. Pero hazlo bien. ¡Gracias!”
Antes, cuando una base de código empezaba a resistirse al desarrollo de features, se arreglaba el cuello de botella inmediato y se posponía lo demás hasta el siguiente punto de resistencia
Era una forma de refactorizar un poco mientras se desarrollaban features, pero los modelos de frontera empujan ese “momento en que se vuelve un problema” más hacia adelante
Como pueden manejar cierto montón de código dado, se manifiesta más como que el LLM introduce más regresiones o se salta más requisitos, pero se siente menos como que el trabajo se volvió más difícil para la persona
Hasta que un día hay tantas cosas rotas que hay que arreglarlas, pero toda la base de código se volvió una capa fractal de decisiones que yo no tomé, y desentrañarla resulta difícil
Como ya no editas el código directamente, desaparece esa reacción visceral de “si agrego esto de esta manera, aquí hay mucha tensión”, y también se vuelve más difícil encontrar una salida mediante refactorización
El código siempre se puede refactorizar, y se puede obligar al agente a escribir piezas y archivos pequeños y modulares
Haya sido escrito por un agente o por una persona, la buena ingeniería sigue siendo buena ingeniería
Por ahora, al menos una persona todavía tiene que entender y liderar la arquitectura, y los agentes pueden ayudar muchísimo en exploración y sugerencias
A menos que me haya perdido avances de las últimas semanas, no parece que la IA se haya vuelto más confiable; más bien sus errores se volvieron más sutiles
Si el código no compila, es fácil detectarlo; y si compila pero no funciona, también es relativamente fácil detectarlo
Pero si compila y funciona, aunque falle en algunos casos límite, tenga vulnerabilidades de seguridad o arrastre deuda técnica y decisiones arquitectónicas dudosas, eso es mucho más difícil de encontrar, y la carga de revisión no disminuye en absoluto
De hecho, el código plausible es mentalmente más pesado de revisar que el código obviamente malo
Puedes hacer que primero escriba varias pruebas, verificar que el código se ajuste a ellas y pedirle al agente que organice el código correctamente
Pero ahora mismo la presión desde arriba es tan fuerte que el ambiente empuja a aplicarlos de forma amplia en todas partes, y oponerse a eso resulta tan desalentador y tan limitante para la carrera que desgasta mentalmente
Cuando señalas un problema obvio, aparecen igual de muchas soluciones alternativas, y pronto esas soluciones muestran otros problemas, generando interminablemente nuevas soluciones
En algún punto todo esto empieza a sentirse como trabajo para la máquina misma
En muchas empresas, da la impresión de que el objetivo real se ha desdibujado y lo único que queda es el LLM en sí
No sé si a quienes apuestan el futuro de la empresa por esa visión se les está garantizando una salida suave para evitar consecuencias, o si la racionalidad entera se está tirando por la borda
Se pueden mitigar problemas con principios sanos de ingeniería, pero sigo dudando qué eficiencia real se obtiene en términos de carga cognitiva, tiempo de desarrolladores, dinero y recursos finitos
En la frase “qué se rompe cuando puedes producir de 200 líneas al día a 2,000”, usar líneas de código como medida del output de ingeniería da vergüenza
Revisar 200 líneas y revisar 2,000 líneas son cargas de trabajo completamente distintas
Rehice el mismo programa con mi propia cabeza y usé ChatGPT solo como búsqueda y autocompletado, y obtuve el mismo resultado con 1,500 líneas
Sinceramente, la diferencia de esfuerzo tampoco fue enorme, aunque el enfoque escrito a mano quizá tuvo la ventaja de que ya había pensado lo que quería construir gracias a la versión hecha primero con vibe coding
Tiene sentido usar líneas de código como input del proceso de revisión de software
Literalmente porque hay que leer cada línea
Solo que son pésimas como única medida de productividad del desarrollador, y ahí es donde empiezan los problemas
Aun así, son útiles porque son casi la única métrica que se entiende de inmediato y se puede comparar de forma intuitiva entre empresas, equipos, lenguajes y contextos de aplicación
Incluso si el mismo equipo trabaja en el mismo producto, un cambio de 1,000 líneas puede terminarse rápido, mientras que corregir un bug de 1 línea puede requerir días de depuración
Por eso es difícil comparar PR, features o story points fuera de contexto, y si existiera una métrica estándar de productividad de desarrolladores que realmente funcionara, todo el mundo la usaría, pero parece algo intrínsecamente difícil
Para este tipo de comparaciones, ayuda asumir que el contexto es el mismo
Por ejemplo, si un equipo de cierta empresa que construía cierto producto con cierto stack y cierto proceso de calidad ayer producía N1 líneas y hoy con IA produce N2 líneas, con el tiempo la diferencia entre N1 y N2 aproxima el impacto real
Incluso los estudios rigurosos sobre productividad en desarrollo asistido por IA han medido en gran parte con pruebas tipo A/B test comparando PR del mismo grupo antes y después de usar IA
Para mí, la diferencia está en la calidad y el rigor del pipeline
El vibe coding consiste en intentarlo una o varias veces, verificar superficialmente el resultado y usarlo hasta que se rompa
Sirve para pruebas de concepto ligeras o apps personales, familiares o de equipos pequeños con poco riesgo
La ingeniería con agentes se preocupa por un rango más amplio de cuestiones, como corrección funcional, rendimiento, infraestructura, resiliencia/disponibilidad, escalabilidad y mantenibilidad
Tiene un pipeline de varias etapas para gestionar el flujo de trabajo, con fases como intake del proyecto, selección, especificación, descomposición en épicas, descomposición en historias, codificación, documentación y despliegue
Cada fase mezcla puertas de calidad deterministas, como pasar pruebas o cumplir criterios de rendimiento, con revisiones adversariales sobre valor de negocio, completitud de especificaciones, elegancia del código o rigor y simplicidad del lenguaje ubicuo
Esto también es un deslizador
A veces, para desplegar una sola feature, no quieres entrevistar, quemar tokens, pasar por tres revisiones adversariales, estimar valor y redactar especificaciones detalladas; solo quieres lanzar el ticket al sistema
Uso Opus, GPT-5.5 y modelos más pequeños todos los días, pero no les delego el trabajo completo
Incluso si invierto bastante esfuerzo en definir y pulir especificaciones, siguen haciendo muchas tonterías que no pasarían una revisión humana de PR
Si hubiera confiado en la salida o construido un gran pipeline de agentes para conseguir una falsa sensación de estabilidad, habría sido fácil dejar que eso entrara directamente en la base de código
En 10 años quizá mejore, pero hoy tanto el vibe coding como los pipelines de ingeniería con agentes parecen variaciones del mismo tema: delegarlo todo al LLM
Incluso esta mañana pensé que podía dejarle a Opus on Max unos cambios en un solo archivo, pero en casi cada turno cometía errores o se le escapaban cosas, así que tuve que corregirlo
El código que proponía probablemente habría funcionado, pero era demasiado complejo y volvió a degradar partes que yo ya había simplificado a mano
Si esto se multiplica por miles de commits de agentes, la base de código se deteriora rápidamente
Los equipos de desarrollo se meten en problemas cuando intentan construir sin el proceso correcto de diseño, pruebas y revisión
Eso ya era cierto antes del coding con agentes, pero ahora todavía más, y los equipos que entiendan cómo usar agentes dentro de ese proceso serán los más exitosos
¿No has sentido que los agentes de código llegan muy cerca de la solución en el primer intento, pero que hace falta un trabajo enorme para acertar ese último 10% o 5%?
Si cambias la forma de abordar el problema, el agente puede cerrar esa brecha
Hace 10 años dejábamos de programar cada 10 o 15 minutos para refactorizar, probar y analizar, comprobando que todo estuviera perfecto
Porque un bug luego contamina todo el resto del código
Los agentes de código no hacen eso, y siguen adelante cargando bugs o arquitectura equivocada
Instintivamente uno quiere detener al agente de vez en cuando, pero por varias razones eso no es posible
En cambio, como el costo es muy barato, hay que encontrar el punto donde el agente se equivocó por primera vez, corregir el prompt y, en vez de editar el código, borrar todo y volver a correrlo desde cero
Solo hay que repetir ese ciclo hasta que el prompt produzca código perfecto
Algunos objetarán que ahí todavía hay mucho trabajo humano, pero justamente ese es el punto
La persona sigue siendo necesaria, y usando la herramienta así la velocidad de escritura de código aumenta 10 veces
Puedes construir algo que “funcione” bastante rápido, pero lleva mucho tiempo evaluar alternativas, pulir, probar y ganar confianza
La idea general es correcta, pero nadie sabe dónde está exactamente el límite
Probablemente el próximo año será una etapa en la que todos intenten encontrarlo, y por eso se escucha tanto eso de que “hay que reinventar GitHub”
En muchos casos, no tiene sentido económico invertir para mecanizar también esa parte final
Creo que los proveedores de LLM eligieron un enfoque equivocado desde el principio
En vez de concentrarse en reemplazar trabajo, deberían haberse enfocado en complementarlo, y parece que aprendieron esa lección de la forma cara
Quizá habría sido mejor empezar desde cero, pero al principio ni siquiera sabía qué forma quería que tuviera la arquitectura
Aunque el LLM tenga dificultades para ajustar una feature a la arquitectura existente, no puedes simplemente tirar toda la base de código en producción y empezar de nuevo
Es un gran texto escrito por alguien inteligente, humilde y que sigue aprendiendo
Me gustó la frase: “Hay muchas razones por las que no temo que mi carrera de ingeniería de software se haya terminado solo porque las computadoras ahora puedan escribir su propio código. En parte, porque estas cosas son amplificadores de la experiencia existente. Si sabes lo que haces, puedes correr mucho más rápido”
También me gustó: “Usar estas herramientas me recuerda constantemente lo difícil que es lo que hacemos. Construir software es ferozmente difícil. Aunque nos den todas las herramientas de IA del mundo, lo que intentamos lograr aquí sigue siendo realmente difícil”
Es acertada la observación de que el trabajo upstream también cambia
Las herramientas del lado de diseño están evolucionando especialmente rápido, así que ya no parece valer la pena asumir el costo de traducción de quedarse en Figma
La parte aterradora es que se acumulen capas de complejidad de IA en la base de código, hasta que los humanos ya no puedan entenderla y cueste mucho que los modelos más nuevos la descifren y modifiquen
En poco tiempo podría desaparecer la reutilización de código, y podríamos terminar quemando dinero al reinventar la rueda una y otra vez
Cuando hacías apps de Android al principio, tenías que usar IDE sí o sí, y se sentía como perder el alma escribiendo cantidades absurdas de código boilerplate solo para que, al hacer clic en un botón, apareciera una alerta de “Hello World”
Repítanlo conmigo: la mayor parte del software pasa la mayor parte de su vida útil en fase de mantenimiento
Por lo tanto, la mayor parte del dinero que genera el software también se produce en la fase de mantenimiento
Después de casi 100 años, la industria todavía no entiende esto
Alan Kay tenía 100% razón cuando dijo que la revolución de la computadora todavía no había ocurrido
A pesar de todos los avances actuales, las herramientas siguen siendo en gran medida de la edad de piedra
Mi gran esperanza es que la IA nos acelere hasta el punto de romper por completo el paradigma existente de una forma irreparable, para que por fin podamos hacer algo nuevo, diferente y mejor
Así que por ahora pongámosle un jetpack de IA al ciclo de vida del desarrollo de software y veamos qué pasa
Movámonos rápido y rompamos cosas de verdad
Es una observación oportuna y también me hace sentido
Necesitaba levantar algo relativamente simple de descarga por lotes → transformación → endpoint de API, y escribí un prompt bastante detallado, pero dejé bastante abiertos los detalles de implementación, como la fuente de datos
Opus 4.7 lo hizo en un 90% parecido a como yo lo habría hecho, y además agregó muchos más métodos de conveniencia y validación paso a paso
Estuvo muy bien, y me dejó espacio mental para pensar en problemas más difíciles
Soy principalmente desarrollador de Python, pero uso constantemente otros lenguajes backend que conozco bien, aunque no al mismo nivel, como Rust o Go
Con unos 13 años de experiencia muy cargada a un lenguaje y aprendizaje formal en otros, me resulta mucho más fácil dirigir a un LLM
La carga de aprender sintaxis, componentes básicos, gestores de paquetes, pruebas, etc., no es grande comparada con la forma de programar de antes
Hace poco ayudé a un colega no desarrollador que estaba automatizando reportes con Claude cowork/code
Esa persona entendía bien la parte de business intelligence, pero tenía dificultades con la expresión básica necesaria para hacer vibe coding de un wrapper de pyautogui que levantara RDP y llenara valores sobre una abstracción de MS Access encima de una base de datos del proveedor
Creo que los desarrolladores como profesión van a estar bien durante los próximos 5~10 años