Hace no tanto, hablar de desarrollo de software era hablar de un editor de código y de escribir todo a mano. Eso ya no es así. Aunque mucha gente todavía no se adapta, ya hay herramientas que se encargan de gran parte del trabajo que antes hacíamos nosotros: el código, los tests, el despliegue e incluso la elección del lenguaje.

En este artículo te cuento cinco cambios que están pasando justo ahora. Te sirven tanto si llevas años programando y quieres ponerte al día como si estás creando aplicaciones con IA y quieres entender cómo se trabajaba antes y cómo se trabaja ahora.

1. Rust se vuelve popular… porque ya nadie lo escribe a mano

Rust está más de moda que nunca, pero no porque de repente todo el mundo lo esté aprendiendo. La razón es que mucha gente genera aplicaciones con IA y ha escuchado que Rust es la forma de ganar rendimiento y consumir pocos recursos.

Fuera del vibe coding también hay proyectos serios. El caso más llamativo es Bun, que se reescribió de Zig a Rust. El motivo principal fueron los bugs de memoria (use-after-free, double-free…), justo lo que el borrow checker de Rust detecta en tiempo de compilación. Lo interesante es cómo lo hicieron: un solo ingeniero con agentes de Claude Code, en unos 11 días. El pull request suma más de un millón de líneas añadidas, aunque el código final en Rust ronda las 780.000.

En el lado del vibe coding está ArtCraft, un proyecto open source con apps en Rust que reimplementan programas de Adobe (PhotoCraft, VectorCraft, EffectCraft…) y ahora también de Microsoft, como GridCraft para Excel. Un matiz sobre lo que conté en el video: el propio proyecto se declara en "early alpha" y todavía está lejos de tener las funciones de Photoshop. Ha gustado la idea, pero no es un reemplazo real.

Y luego está DHH, el creador de Ruby on Rails. En la keynote de Rails World 2026 dejó claro que le encanta Rust… siempre que no tenga que escribirlo ni mirarlo. Días después publicó que tenía Campfire funcionando reescrito en Rust y que "nunca tuvo que mirar el código directamente". Es gracioso: vas a una conferencia de un lenguaje y te promueven otro.

Ahora, el punto importante. El blog de JetBrains publicó un análisis sobre reescribir en Rust y su conclusión es que las mejoras no son automáticas. Parte del rendimiento viene de Rust, sí, pero otra parte viene de reescribir el código desde cero con lo que ya aprendiste, corrigiendo errores por el camino. Y toda reescritura introduce bugs nuevos. Hay ejemplos de proyectos que lo intentaron y dieron marcha atrás:

  • Prisma: su motor en Rust tenía que serializar datos entre Rust y JavaScript, y eso costaba más de lo que ganaba. En Prisma 7 ya no usa Rust por defecto.
  • LogLog Games: dejó Rust tras tres años haciendo videojuegos, por las reescrituras constantes que le exigía el borrow checker.
  • curl: intentó integrar de forma gradual un backend en Rust, llegó al 95 % y lo abandonó.

Mi conclusión: si no vas a escribir Rust a mano, igual vas a necesitar leerlo para revisar y medir lo que genera la IA.

2. Tests escritos en texto (y la polémica de borrarlos)

En testing apareció e2e de TesterArmy, un framework de tests end to end que combina pasos deterministas con pasos de agente. Antes escribías cada paso en código: abrir la página, hacer clic, llenar el formulario. Ahora puedes escribir algo como agent.act('upgrade the workspace to the Pro plan') y luego comprobar que la vista previa de la factura muestra el importe correcto. Estás escribiendo texto, no código.

La polémica vino por otro lado. Sherwood Callaway, fundador de Sazabi, contó que habían borrado 811.883 líneas de tests unitarios de su monorepo. Sus razones: que los tests "congelan" el código basura que genera la IA, que ralentizan los ciclos de desarrollo y que gastan tokens y tiempo de CI. Ojo, él los sustituye por tests de integración; no quita todas las validaciones.

Una de las respuestas más compartidas fue la de Norbert Orzechowicz, en tono de sátira: primero quitas los tests, luego el CI/CD porque te frena, luego los agentes despliegan solos… y al final el agente decide que la base de datos va más rápido sin usuarios.

Si estás pensando en quitar tu CI/CD para ir más rápido, no te lo recomiendo. Para eso existen los entornos: producción con su CI/CD y un entorno de staging o desarrollo donde puedes probar cambios al instante. Lo realmente nuevo aquí es que cada vez más gente lanza código que no ha leído.

3. El vibe coding ya no está mal visto

Hasta hace poco, el vibe coding era motivo de burla. Hoy hay programadores muy experimentados que lo defienden. Linus Torvalds dijo que puede ser una forma maravillosa de disfrutar programando y que permite a la gente nueva hacer cosas que antes le costarían mucho. Eso sí, mantiene que no lo usaría para algo crítico como el kernel.

Notch, el creador de Minecraft, que hace unos meses criticaba a quien programara con IA, ahora admite que lo está disfrutando y que "puede que se equivocara un poquito".

4. Las nubes se simplifican (y cuidado con la factura)

AWS siempre fue criticada por su complejidad: cientos de servicios y configuraciones que hasta requerían certificaciones. Ahora presentó una nueva experiencia de inicio para clientes nuevos: registro con Google, GitHub o Apple, proyectos con valores por defecto e incluso un prompt para configurar el CLI desde tu agente de código. No es un rediseño de toda la consola, pero tiene sentido: si un agente despliega por ti, ya no necesitas pelearte con la interfaz.

Lo que no siempre sale bien es dejar todo en manos del agente. Un desarrollador chino desplegó en Cloudflare un experimento hecho con Codex. Un bug hizo que una alarma se reprogramara sin parar y generó billones de operaciones. La factura: más de 10.800 dólares, por una app que nadie usaba. Un matiz sobre lo que conté en el video: después de pagarla, Cloudflare le devolvió casi todo el dinero. Aun así, no conviene contar con eso.

Mi recomendación: si despliegas en la nube y no sabes bien qué hace cada servicio, configura un límite de gasto o al menos alertas. Lo nuevo de AWS ya trae un límite por proyecto que pausa todo al alcanzarlo, y plataformas como Vercel o Railway tienen opciones parecidas. Es especialmente importante con funciones serverless, bases de datos serverless y APIs de IA: un bucle es como un caño abierto.

5. Orquestar agentes es la nueva interfaz

El último cambio es que las herramientas para manejar muchos agentes a la vez ya están al alcance de cualquiera. Lauren Tan, que trabaja en Grok Bot, publica a menudo cómo lanza un montón de proyectos gracias a esto. Grok Bot es un chat donde creas varios bots con su propio ordenador en la nube que se reparten el trabajo. OpenAI también presentó dots, sus agentes siempre activos dentro de ChatGPT, aunque de momento es uno por usuario.

¿Por qué es un cambio real? Porque antes la pantalla principal era el editor de código y el chat era secundario. Ahora es al revés: el agente es lo principal y los archivos quedan en segundo plano. Por eso crecen tanto proyectos open source como Orca o Herdr, pensados para manejar muchas sesiones de agentes a la vez.

Conclusión

Si lo piensas, seguimos haciendo lo mismo de siempre: escribir código, probarlo, desplegarlo y revisarlo. Lo que cambió son las herramientas y el enfoque. Mucha gente sigue con su editor, desplegando a mano, y está bien: si haces un trabajo muy concreto o tu app aún no tiene usuarios, no necesitas orquestar agentes ni montar un CI/CD complejo.

La IA no hace el trabajo por ti. Es más bien un trabajador al que le delegas tareas concretas, y brilla sobre todo en lo repetitivo y predecible. Lo que sí está claro es que revisar, medir y entender lo que genera es cada vez más importante.

¿Cuál de estos cambios ya estás viviendo en tu trabajo, o cuál has visto que no mencioné?

Fuentes