Cinco funcionalidades de creación lanzadas entre el 2 y el 16 de abril de 2026. Cero funcionalidades de mantenimiento. Esa proporción te dice todo sobre dónde está realmente el mercado de coding con IA — y lo que se niega a cobrar honestamente.

Cursor 3 (2 de abril) lanzó Agent Tabs paralelos — múltiples agentes de IA escribiendo código simultáneamente en ramas separadas. GitHub Copilot (4 de abril) agregó modo Autopilot — agentes que aprueban sus propias llamadas a herramientas sin preguntarte. Windsurf 2.0 (10 de abril) sacó un Agent Command Center. Claude Code (14 de abril) introdujo Routines — agentes programados en segundo plano que generan código por triggers. Codex de OpenAI (16 de abril) sumó flujos multi-agente. Ni un solo anuncio aborda qué pasa con el código después de que se despliega.

Esto no es un descuido. Es una estrategia de producto.

El 60% que nadie vende

Barry Boehm estableció en 1976 que el mantenimiento consume entre el 60 y el 80% del costo total del ciclo de vida del software. IBM lo confirmó repetidamente en las décadas siguientes. Nada en cincuenta años de ingeniería de software ha revertido esa proporción.

La IA parece estar ampliándola.

Un estudio publicado en arXiv el 8 de abril de 2026 analizó diez proyectos grandes generados con Cursor, con un promedio de 17,000 líneas de código cada uno. Corrección funcional: 91% — el código funcionaba. CodeScene, una herramienta de análisis de salud de código, encontró 1,305 problemas de diseño en esos proyectos: 28.4% de código duplicado, métodos con un promedio de 171 líneas (las buenas prácticas ponen el tope en 20–30), y complejidad ciclomática — un conteo de rutas de ramificación a través de una función — promediando 17, casi el doble del techo recomendado.

El demo funciona. El codebase es estructuralmente hostil para cualquiera que lo toque después — incluyendo la IA que lo escribió.

Cada benchmark importante de coding con IA refuerza este punto ciego. SWE-bench evalúa corrección de bugs. HumanEval evalúa generación de funciones. Ningún benchmark pregunta "¿puede este modelo agregar una funcionalidad de forma segura al codebase enmarañado que generó hace tres meses sin documentación de diseño?" Sin ese benchmark, los vendors tienen cero incentivo de mercado para optimizar lo que realmente cuesta dinero.

Por qué la IA estructuralmente no puede mantener lo que crea

El mantenimiento exige tres capacidades que la creación no requiere: decisiones de diseño consistentes entre sesiones, entender por qué existe el código (no solo qué hace), y la disciplina de refactorizar en lugar de duplicar.

Las herramientas de IA actuales fallan en las tres.

Cada sesión nueva arranca con cero memoria de decisiones de diseño previas. El modelo genera cualquier patrón que encaje con el prompt actual, no el patrón que usó el martes pasado. Por eso el estudio de arXiv encontró 28.4% de duplicación — la IA resuelve el mismo problema de forma diferente cada vez porque no recuerda haberlo resuelto antes.

El ensayo controlado aleatorizado de METR — publicado en julio de 2025, todavía el único estudio controlado de su tipo — cuantificó la brecha entre percepción y realidad: 16 desarrolladores experimentados en sus propios repositorios trabajaron un 19% más lento con herramientas de IA, pero creyeron que eran un 20% más rápidos. Un delta de 39 puntos porcentuales entre lo que los desarrolladores creen que está pasando y lo que realmente pasa. En codebases que conocían. En código generado por IA que no conocían, nadie lo ha medido, porque nadie ha construido el benchmark.

Qué requeriría realmente una herramienta orientada al mantenimiento

Si diseñaras una herramienta de coding con IA para el 60–80% del trabajo que realmente cuesta dinero, no se parecería a nada de lo que se está lanzando hoy.

Justificación de diseño como metadata. No solo qué hace el código — por qué está estructurado así. Cada función generada por IA debería llevar un registro de las restricciones, alternativas consideradas y decisiones de diseño que la produjeron. CLAUDE.md de Claude Code es la aproximación más cercana: contexto persistente del proyecto entre sesiones. Pero es un archivo de texto que mantienes a mano, no un registro arquitectónico automatizado.

Consistencia entre sesiones. Una herramienta orientada al mantenimiento detectaría cuándo el modelo introduce un patrón que contradice uno existente y bloquearía el conflicto antes de que el código se genere — no después de que un humano lo revise. La indexación de codebase de Cursor (hasta 500MB, consultas en menos de un segundo) provee la capa de recuperación que esto necesita. Recuperación sin enforcement es una biblioteca sin bibliotecario.

Refactorización como modo por defecto. Las herramientas actuales optimizan para código nuevo. Una herramienta de mantenimiento por defecto modificaría código existente — localizando el lugar correcto para agregar lógica en vez de generar un archivo nuevo. Mediría y minimizaría la duplicación como métrica principal junto con la corrección funcional.

Gates de degradación. Cuando la complejidad ciclomática cruza umbrales, cuando los métodos se inflan más allá de 30 líneas, cuando las tasas de duplicación suben — la herramienta se niega a hacer commit. No como un plugin opcional. Como el comportamiento por defecto. De la misma manera que un type checker bloquea código inválido, una herramienta de mantenimiento bloquearía código inmantenible.

El estudio longitudinal de JetBrains publicado el 14 de abril de 2026 rastreó a 800 desarrolladores a lo largo de 151.9 millones de eventos registrados y reveló una señal que ninguna herramienta de coding actúa sobre ella: los desarrolladores pasan más de un tercio de su tiempo verificando sugerencias de IA, y revierten aproximadamente una de cada cinco completaciones aceptadas borrando el código después. Ese patrón de borrado es una señal de entrenamiento gratuita — un corpus de "el modelo pensó que esto estaba bien, el humano demostró que estaba mal" — guardado en la telemetría de cada IDE. Alguien podría construir un loop de retroalimentación que ingiera esas reversiones y aprenda a generar código mantenible desde el inicio. Nadie lo ha hecho, porque los demos de creación venden. Un screencast de 30 segundos de un agente levantando una app desde un prompt obtiene millones de views. Un screencast de un agente descomponiendo cuidadosamente un método de 171 líneas en seis funciones limpias consigue una charla en una conferencia, con suerte.

La realidad del pricing

Si aprobaste un proyecto construido con IA este trimestre, esto es lo que ningún vendor te va a cotizar: presupuestá tres veces el costo de creación para su primer año de mantenimiento. Si tu agente de IA escribió 17,000 líneas en una semana, tus ingenieros van a pasar tres semanas desenredando problemas de diseño antes de poder extenderlo de forma segura — y luego van a repetir el ciclo después de cada feature nuevo.

El enfoque más honesto: tratá el código generado por IA como un prototipo desechable con una vida útil de seis meses. Hacé el demo, validá la idea, después reconstruí las partes que demostraron su valor con ingenieros que entiendan la arquitectura.

Cada vendor de coding con IA en abril de 2026 cobra y promociona la creación como el producto. El verdadero centro de costos en software nunca ha sido la creación. Hasta que un vendor construya — y cobre por — un multiplicador de mantenimiento, estás comprando la fase más barata del proceso y pagando precio completo por todo lo que viene después.