Mediciones de 46 operaciones de .NET: el agente Copilot añadió una caída del 16% en el primer resolve de DI

El debate sobre si la IA estropea el código suele basarse en impresiones. El autor de este material decidió medirlo. Tomó un punto de partida: .NET 7 salió tres semanas antes que ChatGPT y fue la última versión escrita antes de la era de los asistentes. Desde mayo de 2025, el Copilot coding agent trabaja en dotnet/runtime: a finales de octubre de 2026 había abierto 1734 pull requests, de los cuales 1207 se fusionaron.

Cómo se midió

El runtime se fijó en .NET 10.0.11 y solo cambiaron los paquetes NuGet Microsoft.Extensions.* de la versión 6 a la 11 y EF Core de la 6 a la 10. Así, las mejoras de JIT y GC no afectan al resultado. En total: 46 operaciones, 30 rondas, cada escenario en un proceso independiente sobre núcleos dedicados, con el orden de versiones mezclado. El veredicto «más rápido» o «más lento» solo se emite si todo el intervalo de confianza del 95% queda más allá de un umbral del 5%.

La primera imagen es ambigua. Versión 10.0 frente a 7.0: 9 operaciones más rápidas, 13 más lentas y 10 dentro del ruido. El código ya calentado se aceleró entre un 14% y un 35%: LoggerMessage.Define pasó de 377 a 244 ns, y DetectChanges con 10 mil entidades, de 6,1 a 4,3 ms. En cambio, las primeras llamadas y la creación de objetos se encarecieron entre un 39% y un 64%: la primera consulta de EF subió de 996 a 1162 ms. Para un servicio de larga duración el intercambio es favorable; para procesos cortos y arranque en frío, no.

La mayoría de los cambios, 19 de 46, se concentró en el paso a 8.0, es decir, la primera versión posterior a ChatGPT. Pero el autor aclara con honestidad que las mediciones muestran qué cambió, no por qué. Además, este paso incluye el cambio del ensamblado de destino de net7.0 a net8.0.

Dónde estaba el agente

En el historial de Git entre v7.0.20 y v10.0.14 se encontraron 113 commits en DI y caché, ninguno del agente. En la ventana previa a 11 RC el agente apareció: por ejemplo, 3 de 11 cambios en métodos críticos de DI y caché. Una salvedad importante: un commit del agente significa «PR abierto por el agente», no «escrito sin intervención humana». Todos los PR pasan revisión humana, y un asistente del IDE no se ve en Git en absoluto.

Dos caídas en 11 RC

La mayor: el binding de un POCO de 50 campos pasó de 61 a 145 µs, e IOptionsSnapshot en un nuevo scope, de 52 a 136 µs. La causa estaba en una sola línea del PR #126396 con el atributo [ConfigurationIgnore]: property.IsDefined(...)

se ejecuta para cada propiedad en cada binding. El autor compiló el binder desde el código fuente, sustituyó la expresión por false y reemplazó una DLL: el tiempo volvió a 60 µs. El mayor coste lo aporta la sobrecarga con inherit: true por defecto.

El PR lo escribió una persona. Los mantenedores reconocieron la regresión, pero recordaron que para las rutas críticas se recomienda el generador de código fuente. La corrección para 11.

0 está prometida, pero no garantizada: el issue está vinculado al milestone 12.0.0.

La segunda caída es menor: el primer resolve en DI aumentó un 16,5%. Un bisect de commits señaló al culpable, el PR del agente #124331, que corrige un deadlock con dependencias circulares a través de factorías. Ahora VisitRootCache mantiene un HashSet ThreadStatic, lo que cuesta unos 0,9 µs por primer resolve. Revertir solo este PR devuelve el tiempo al nivel de 10.0. El commit no afecta a singleton ni scoped ya calentados, ni a la construcción del proveedor. El autor considera razonable el precio por un deadlock corregido.

Qué hacer

• Si usa 11 RC y hace mucho binding de configuración, active el generador de código fuente (EnableConfigurationBindingGenerator): 12 µs frente a 29 µs en 10.0.
• En lugar de IOptionsSnapshot, donde no se necesita actualización dentro de la petición, use IOptionsMonitor.
• Vigile el arranque en frío: se encareció en varios puntos.

Limitaciones: se trata de un release candidate, las mediciones se hicieron en un solo portátil, y la pista principal usa la compilación 11.0 sobre el runtime .NET 10. La conclusión sobre la IA es modesta: ninguna de las dos caídas demuestra que la IA empeore el código. Una la introdujo una persona; la otra, un agente a cambio de corregir un error real. Pero una metodología en la que las regresiones se detectan con mediciones y bisect vale más que cualquier discusión.