El agente de código reemplazó todos los frameworks que usaba
(blog.alaindichiappari.dev)> "La ingeniería de software ha vuelto"
- Con el avance de los modelos frontier de IA y los agentes de código, se abrió la era de la programación automatizada, en la que desaparece el trabajo manual de teclear código línea por línea y los ingenieros de software pueden volver a concentrarse en el diseño y el pensamiento esenciales
- Desde finales del año pasado, la madurez de las herramientas y los modelos mejoró de forma drástica, haciendo posible una forma de trabajo en la que uno puede dedicarse al rol de arquitecto y aun así intervenir directamente para corregir lo necesario
- En el desarrollo web, móvil y de escritorio se han acumulado frameworks y capas de abstracción innecesarias que no resolvieron la complejidad real y, por el contrario, aumentaron los problemas
- De los tres problemas que los frameworks afirman resolver —simplificación, automatización y reducción de costos laborales— solo la automatización tenía un valor legítimo, pero la automatización con IA incluso puede reemplazar eso
- En lugar de degradarse a ser operadores (operators) de sistemas diseñados por hiperescaladores como Google, Meta o Vercel, hay que volver a la verdadera ingeniería: crear directamente el propio diseño y producto
El auge de la programación automatizada
- El marco conceptual de "automated programming" acuñado por Antirez captura mucho mejor la esencia que "vibe coding"
- Como la imprenta, el telar o la línea de ensamblaje, la automatización ha sido el núcleo de las innovaciones históricas, y este cambio también forma parte de esa continuidad
- Desde diciembre de 2025, la capacidad de los modelos frontier y los agentes de código cambió drásticamente, a un nivel que ya es evidente para quien observa con atención
El cambio en el rol del ingeniero
- Las tareas que requieren pensamiento profundo —arquitectura, trade-offs, decisiones de producto, casos límite— siguen existiendo
- Lo que desapareció fue el trabajo manual agotador y desgastante de teclear personalmente cada línea de código
- Si se usan modelos y herramientas en un entorno limpio y rigurosamente configurado, es posible cumplir el rol de arquitecto sin tener que apilar ladrillos uno mismo
- Hace falta el respaldo de 20 años de experiencia escribiendo código directamente, y si algo no convence, uno puede entrar, entenderlo, corregirlo y luego actualizar la configuración
- Como se pueden crear al instante las herramientas necesarias, es posible dedicar más tiempo a materializar la tecnología imaginada
Frameworks y complejidad innecesaria
- Durante años se acumuló en el desarrollo web, móvil y de escritorio una enorme contaminación de frameworks, librerías y tooling
- Se apilaron capas de abstracción que no abstraen nada significativo, y mientras afirman resolver un problema, generan diez problemas nuevos
- En vez de agudizar su pensamiento frente a la verdadera complejidad de construir software, toda la industria optó por comprar pensamiento prefabricado
- Es como envolver una pierna rota en seda: se ve bien por fuera, pero la pierna sigue rota
Los tres problemas que los frameworks dicen resolver
- "Simplificación (Simplification)": el fenómeno por el cual los ingenieros, por miedo a diseñar por sí mismos, aceptan ciegamente la estructura de otros
- En vez de diseñar en reversa a partir del objetivo, se aplica en todas partes un diseño one-size-fits-all
- Eso no es simplificación, sino rendición intelectual (intellectual surrender)
- Automatización (Automation): el único valor realmente convincente, la eliminación del código boilerplate
- La automatización de tareas repetitivas pero esenciales como ORM, gestión CRUD, generación de código y documentación de API
- Pero justamente aquí es donde la IA lo está cambiando todo
- Reducción de costos laborales (Labour cost): la razón silenciosa que no aparece en las diapositivas de las conferencias
- Si se deja que Google, Meta o Vercel decidan cómo construir productos y desplegar código, entonces se puede contratar a un "desarrollador de React" en vez de a un ingeniero de software
- Personal tipo engranaje (cog): sin necesidad de formación, plug and play y fácilmente reemplazable
- Eso no es ingeniería, sino operación (operating)
La realidad de una nueva forma de trabajo
- Lleva más de 2 años desarrollando casi sin fallas de esta manera, y la verdadera revolución comenzó en diciembre del año pasado
- Se abrió la oportunidad de eliminar la complejidad innecesaria y concentrarse en la complejidad centrada en las ideas
- El costo de eliminar boilerplate converge casi a 0, y ya no hace falta escribir el mismo código dos veces
- Se pueden construir al instante pequeñas herramientas especializadas ajustadas exactamente al problema
- Sin un vistoso gestor de monorepo, un Makefile simple cubre el 99% de los casos de uso
- Si el problema se vuelve realmente complejo, entonces se piensa en eso; antes de eso, nunca hay que resolverlo por adelantado, y eso es ingeniería
- No se trata de resolver problemas que alguien dijo en un escenario de conferencia que algún día podrían aparecer, sino de resolver el problema que tienes ahora
Redescubrir Bash y las herramientas básicas
- Los agentes son muy hábiles con herramientas básicas (basic tools) que existen desde hace décadas
- Bash nació en 1989, y hoy incluso el modelo más común conoce Bash mejor que cualquier persona del mundo
- Hay una tendencia de los agentes de código a pasar de configuraciones MCP complejas y costosas a bucles de agentes simples basados en Bash
- La herramienta más antigua es la más preparada para el futuro (most future proof)
El costo de depender de frameworks
- Para la mayoría de los casos de uso, no hacen falta frameworks costosos y defectuosos ni librerías accesorias de las que solo se usa el 10% de la funcionalidad
- Los costos invisibles de mantenimiento, actualizaciones de seguridad y restricciones de diseño son grandes, y limitan la libertad del desarrollador
- Seguir aceptando este trade-off significa perder la mayor oportunidad en décadas
- Hay que cuidarse de una estructura subordinada a la filosofía de diseño de grandes empresas como Google, Meta o Vercel
- Los desarrolladores deben confiar en su propio pensamiento y sentido estético, y construir sus propias herramientas y productos
> “No envuelvan una pierna rota en seda; construyan algo realmente suyo”
- Los desarrolladores deben confiar en su propio pensamiento y sentido estético, y construir sus propias herramientas y productos
5 comentarios
Este sí que es un verdadero método de desarrollo para hacer que el mantenimiento sea difícil. Es alguien que, adaptándose a la era de la IA, está poniendo en práctica la forma de asegurar su puesto de por vida en esta nueva era.
La frase de “frameworks y librerías accesorias caros y defectuosos de los que en la mayoría de los casos de uso solo se utiliza el 10% de la funcionalidad” de verdad no me genera nada de empatía... ¿No era una virtud elegir bien un entorno del tamaño adecuado para el proyecto? Si parece que no vas a hacer gran cosa, usas algo liviano como express. ¿De verdad hace falta crear desde cero algo que reemplace a express?..
Si vamos a hablar de cosas con muchas funciones de las que casi no usas nada, más bien eso aplicaría todavía más a servidores web como Apache o nginx; pero, ¿porque son pesados vas a crear un servidor web desde cero? No, simplemente lo configuras y lo usas.
Ya existen frameworks bien organizados y con mucho material con el que la IA ha sido entrenada, así que no veo necesario crear algo nuevo solo para mí; más bien parece algo que reduce la productividad.
No creo que haya necesidad de desechar algo que nos permitió reducir el costo de diseñar la arquitectura y enfocarnos en lo esencial (el servicio).
Mmm... ¿no será que este tipo de práctica era de cuando Cursor ofrecía uso ilimitado? Más bien, al menos por un tiempo, parece que la dirección a futuro es cómo ahorrar tokens y apoyar bien a la IA.
Se puede eliminar la duplicación incluso sin precios de tokens caros, así que ¿cuál sería la razón para no usar frameworks?
Opiniones en Hacker News
Parece que en un futuro cercano muchos desarrolladores y empresas se van a llevar un gran golpe por el humo de la IA
Ahora mismo se puede construir algo con IA, pero el problema real está en las partes que no conoces hasta que te enfrentas a ellas directamente
Al final, quienes solo hacen ‘vibe coding’ chocarán con límites reales, y solo sobrevivirán quienes entiendan cómo funciona de verdad el sistema
Podían arreglar y hacer merge de un bug en 2 minutos, y “entender el sistema” y “no escribir el código a mano” sí pueden coexistir
AWS está apostando muchísimo por esta dirección, y conforme las herramientas no deterministas se vuelvan más estables, es muy probable que superen la calidad humana
Si delegas sin entender, no puedes garantizar la exactitud, mantenibilidad ni escalabilidad del resultado
Pero si trabajara con gente así, me preguntaría por qué habría que pagarles cientos de miles de dólares y además la suscripción al LLM
Claro que habrá casos de apps hechas con ‘vibe coding’ que se rompan, pero los equipos que acompañen eso con pruebas, control de versiones y documentación más bien van a prosperar
Al final, lo importante es un enfoque equilibrado
Tal vez algún día aparezca un ‘bot de de-slopping’
La razón para usar frameworks es que quienes los diseñaron ya se toparon con más problemas y retos de escala que yo
Al inicio de un proyecto parece fácil, pero cuando crece, rediseñar se vuelve doloroso
A veces lees textos como este y da la impresión de que el propio texto lo escribió un LLM
La metáfora de “cortar y coser ladrillos” más bien deja en evidencia esa contradicción
Seguir construyendo todo el stack por cuenta propia sigue siendo ineficiente y costoso de mantener
La diferencia ahora es que se pueden crear componentes a medida con mucha más facilidad según el problema
No hace falta aprender algo nuevo; con frameworks conocidos basta
mi problema, el problema de la plataforma y el problema de esquivar el framework
Me parece raro un texto que habla del dolor de escribir código. Codificar es más bien la parte fácil
Si Tolkien hubiera usado IA, probablemente habría desperdiciado tiempo afinando prompts
Sobre todo en las partes difíciles, la ayuda de la IA puede resultar contraproducente
en los textos sobre IA se dice que “la IA escribe el código por ti para que te concentres en pensar”
Si son las mismas personas, es contradictorio
Últimamente, si se lo dejo a Claude Code, casi siempre lo resuelve en unos minutos
Pero yo confío más en el código que escribí yo mismo. Al final, más que la velocidad, importa la profundidad de la comprensión
Si, como Warhol, aprovechas bien una herramienta nueva, eso también es arte
Los LLM solo son una herramienta que ayuda en las primeras etapas de la creación; el genio sigue viniendo del ser humano
Ver los parches de seguridad de Node.js como una molestia es un malentendido
Eso es un privilegio. Una solución hecha desde cero no tiene comunidad de seguridad y tendrá más vulnerabilidades
Es fácil conseguir desarrolladores de React, pero no hay desarrolladores de un “framework propio hecho por IA”
No es nada tan impresionante
Existe un punto intermedio entre los agentes de código y los frameworks
Yo sigo usando las mismas herramientas, pero el agente se encarga del trabajo repetitivo
y yo me concentro en la arquitectura y los casos borde
Ignorar a los agentes y confiar ciegamente en ellos son posturas extremas
La verdadera habilidad está en saber cuándo tomar el volante
El problema de este texto es que ve los frameworks y la ‘ingeniería real’ como si fueran opuestos
Plataformas como Vercel, Next.js y Firebase permiten despliegue inmediato y CI/CD
Si piensas en la época en que todo se configuraba a mano con Jenkins, eso es revolucionario
La ingeniería real no consiste en “reinventar”, sino en entregar rápido al cliente
Es ineficiente que la IA reimplemente frameworks existentes sin validación en batalla
Sin ecosistema ni patrones comunes, colaborar se vuelve difícil
Que un desarrollador sin experiencia use mal la IA no es distinto a lo de antes
Si haces uno propio, pierdes documentación, middleware y mantenimiento
Están en el nivel de volver a darse cuenta de que “se pueden conectar APIs”
Pero ese descubrimiento no viene acompañado de entender los trade-offs
En los últimos 6 meses he hecho desarrollo embebido con Cursor + Opus 4.x
Los LLM ayudan no solo con software, sino también con diseño de circuitos, CAD y CNC
Por ejemplo, terminé una función wrapper para una pantalla basada en ST7789 con solo tres prompts
Ahora casi no uso librerías fuera de LVGL, TinyUSB, compresión y cifrado
Las funciones orientadas a un propósito creadas por LLM son pequeñas, rápidas y no tienen abstracciones innecesarias
Creo que a muchas librerías ya les llegó la hora de salir de escena
Algo como .NET es irremplazable, pero una colección de funciones de propósito general sí puede sustituirse sin problema
y de inmediato me dio código completo, incluso con doble frame buffer
La parte dura de programar no es tipear, sino la colaboración con personas, las pruebas y el pensamiento de diseño
Lo más difícil que me tocó últimamente fue diseñar una estructura de datos lock-free
En la era de los LLM, el valor de los frameworks crece todavía más
Gracias a los datos de entrenamiento, los LLM son fuertes con patrones conocidos como React
También es importante que los humanos puedan intervenir para depurar
Incluso si llega la AGI, no habría razón para dejar de aprender frameworks eficientes
Esa conversación en sí misma ya es un experimento interesante