Software efímero: qué cambia cuando escribir código cuesta casi nada

Durante décadas, escribir código fue la parte cara del desarrollo de software. Por eso lo tratábamos como un activo, algo que se diseña con cuidado, se mantiene durante años y se amortiza. La IA está rompiendo esa ecuación. Cuando generar código cuesta casi nada, la pregunta deja de ser cómo escribirlo y pasa a ser qué merece la pena conservar.

Lo que dicen los datos

La encuesta State of Code de Sonar, publicada en enero con más de 1.100 desarrolladores profesionales, da una foto bastante clara del momento:

• La IA ya genera en torno al 42% del código que se sube a los repositorios, y los propios desarrolladores esperan que llegue al 65% en 2027.
• El 96% no confía del todo en ese código.
• Solo el 48% lo verifica siempre antes de hacer commit.
• El 38% dice que revisar código de la IA cuesta más que revisar el de un compañero.

Otras mediciones basadas en telemetría dan cifras más bajas, en torno a una cuarta parte del código en producción, pero la tendencia es la misma en todas. Y el matiz importante también. Escribir se ha abaratado, verificar no.

Ya en 2025, un estudio controlado de METR con desarrolladores experimentados de proyectos open source encontró que, en su propio código, tardaban un 19% más con herramientas de IA, mientras creían ir un 20% más rápido. No significa que la IA no sirva, significa que el tiempo se va a otra parte, a revisar, corregir y entender lo que se ha generado.

El cuello de botella se ha movido

Si el coste ya no está en teclear, está en tres sitios:

• Decidir qué construir con la precisión suficiente para que un agente no improvise.
• Verificar que lo generado hace lo que tiene que hacer, y nada más.
• Integrar el resultado con datos, sistemas y usuarios reales.

Por eso la especificación ha vuelto al centro. Como contaba esta mañana en la comparativa de Spec Kit, Kiro y OpenSpec, el Spec-Driven Development nace precisamente de ese desplazamiento. Si el agente escribe el código, el artefacto que de verdad hay que cuidar es el documento que dice qué debe hacer ese código, y cómo sabremos que lo hace.

Y aquí aparece una consecuencia que va más allá de la productividad. Si la spec es lo que perdura, el código empieza a parecerse a un derivado, algo que se puede volver a generar.

Qué es el software efímero

La idea tiene varios nombres. Anish Acharya, socio de a16z, la llamó disposable software en un ensayo de agosto de 2025, con ejemplos muy domésticos, como un juego de matemáticas para sus hijos o una mini-Instagram para las fotos de su gato. No son productos ni startups, no están pensados para escalar ni para monetizar. Se hacen, se usan y se olvidan. En Vercel hablan de apps desechables que se generan con la completitud justa, se saltan el mantenimiento y se tiran cuando han cumplido su función.

La lógica económica es sencilla. Cuando regenerar una herramienta cuesta menos que depurarla o mantenerla, deja de tener sentido mantenerla. Y eso abre la puerta a software que antes nunca se habría escrito porque no compensaba:

• Scripts de migración o limpieza de datos que se ejecutan una vez.
• Dashboards e informes para una reunión o una decisión concreta.
• Prototipos para validar una idea con usuarios antes de comprometer un equipo.
• Herramientas internas de un solo uso, hechas por quien las necesita y no por el departamento de IT.
• Interfaces generadas al vuelo dentro de un agente, que existen solo mientras dura la tarea.

Esto es real y ya está pasando. Cualquiera que use un agente de código a diario ha generado decenas de estas piezas. La pregunta interesante es hasta dónde llega.

Dónde no funciona

La crítica más sólida que he leído es The Flawed Ephemeral Software Hypothesis, de Andreas Kirsch. Su tesis es que la IA abarata generar código, pero no elimina los costes que de verdad pesan en el software que importa. Esos costes siguen ahí:

• El estado y la compatibilidad. Los datos sobreviven a la aplicación. Un esquema, una API o un formato de fichero tienen consumidores que no se regeneran contigo.
• Los casos límite. El comportamiento correcto se descubre cuando el sistema choca con usuarios y datos reales. Si regeneras desde cero, vuelves a descubrirlos, uno a uno.
• La estabilidad de la interfaz. Los usuarios construyen hábitos. Una interfaz que cambia en cada versión genera errores, y en sectores como la sanidad eso tiene consecuencias graves.
• La auditoría. En un entorno regulado, «ejecutamos este prompt» no es una prueba aceptable de qué hacía el sistema.
• La variabilidad. El lenguaje natural es ambiguo, y la misma petición puede producir comportamientos distintos en dos ejecuciones.

Kirsch propone otro término, software maleable. El código y los artefactos de más alto nivel, como specs y tests, persisten juntos, y lo que la IA abarata es cambiarlos. Me parece una descripción más honesta de lo que está ocurriendo en la mayoría de equipos serios.

Un espectro, no una revolución

En la práctica no hay que elegir entre una tesis y otra. Lo que veo es un espectro con tres zonas:

• Efímero. Sin estado, de bajo riesgo y con un usuario o una tarea concreta. Aquí regenerar es lo razonable y mantener es tirar el dinero.
• Maleable. Productos y herramientas internas que viven tiempo pero cambian mucho. El código se conserva, pero la spec y los tests son el contrato, y la IA hace barato el cambio.
• Durable. Sistemas con datos críticos, regulación o muchos consumidores. La IA ayuda a escribirlos, pero cada línea sigue pasando por revisión, versionado y trazabilidad.

El Spec-Driven Development es justo el puente entre las dos últimas zonas. Convierte la intención en un artefacto versionado y revisable, y eso permite tratar partes del código como regenerables sin perder el control del sistema.

Qué cambia para los equipos

Si diriges un equipo de desarrollo, hay decisiones que conviene tomar ya:

• Decide qué es desechable por diseño. Etiquétalo como tal, con fecha de caducidad, y no lo metas en el mismo saco que el producto.
• Invierte en lo que perdura. Specs, tests de aceptación, contratos de API y modelos de datos son ahora tu activo principal, más que el código.
• Gobierna lo efímero. Una app que se borra también procesó datos. Necesitas saber qué existió, qué datos tocó y quién la creó.
• Mide la verificación, no solo la velocidad. Si el 52% del equipo no revisa siempre lo que la IA genera, el problema no es de productividad, es de calidad.
• Cuida las habilidades que suben de valor. Especificar bien, diseñar arquitectura, revisar con criterio y entender el dominio pesan hoy más que escribir rápido.

Conclusión

El software efímero va a ser enorme en la periferia, en todo lo que antes no se escribía porque no compensaba. Pero en el núcleo de los negocios, el software no se va a volver desechable, se va a volver maleable. Lo que sí está cambiando para siempre es cuál es el activo. Ya no es el código, es la intención bien especificada, los datos y la capacidad de verificar que lo generado es correcto. Los equipos que entiendan eso antes van a sacar mucha más ventaja de la IA que los que solo midan cuántas líneas escriben sus agentes.

Fuentes: Sonar, State of Code Developer Survey (enero de 2026), a16z, Disposable Software (agosto de 2025), Andreas Kirsch, The Flawed Ephemeral Software Hypothesis y el estudio de METR sobre productividad de desarrolladores experimentados con IA (julio de 2025).