La semana en que la capacidad del modelo dejó de ser el cuello de botella — y el entorno, el gateway y la capacidad de inferencia se convirtieron en el producto que el CTO necesita aprender a precificar.
Cuarenta y seis por ciento.
Es la tasa en que revisores humanos rechazan los fixes de código generados por Copilot, Devin, Cursor y Claude. En 932 mil pull requests analizados. En el mundo real.
Esta es la Edition de ai|expert — edición quince. La semana en que la capacidad del modelo dejó de ser el cuello de botella, y el entorno, el gateway y el silicio se convirtieron en el producto que el CTO necesita aprender a precificar.
Un paper publicado esta semana en arXiv le puso un número a lo que mucha gente sospechaba, pero prefería no medir. El conjunto de datos se llama AIDev: 932.791 pull requests agénticos, en 116.211 repositorios, con 72.189 desarrolladores involucrados. Es el dataset más grande de comportamiento de agentes de código publicado hasta hoy. [ref: 46-of-ai-generated-code-fixes-]
Y el número central: 46,41% de los fixes propuestos por los agentes fueron rechazados por revisores humanos. Los investigadores analizaron 306 PRs no mergeados de GitHub Copilot, Devin, Cursor y Claude Code, y catalogaron 14 razones de rechazo dentro de cuatro categorías: implementación incorrecta, falla en CI pipeline, incapacidad del agente, y baja prioridad del fix. Este es el fault model que faltaba para debugar un pipeline agéntico de código.
Lo que hace el dato aún más revelador es lo que sucede cuando lo separas por agente. Copilot y Codex pasan en CI con tasas por encima de 93% y 94%, respectivamente — en 61.837 runs de GitHub Actions analizados en 2.355 repositorios. Por cualquier métrica de CI, están funcionando. Pero Copilot tiene el menor índice de merge entre todos los agentes en PRs de fix: 42,4%.
Y la contradicción se profundiza. Copilot genera un promedio de 2,56 comentarios por PR. Todos los otros agentes quedan por debajo de 1,0 comentario por PR. Copilot crea más discusión, pasa más en CI, y aún así es el que menos se convierte en código en producción. Esto tiene una lectura clara: volumen alto con bajo signal-to-noise es peor que volumen bajo con alta precisión. Estás pagando en compute de CI, en tokens, y — el costo invisible — en atención cognitiva de los revisores, por artefactos que nunca van a ningún lado.
Hay un detalle operacional sobre el Devin que merece destaque aislado.
Devin cerró automáticamente 32,1% de sus propios PRs después de detectar inactividad del revisor — publicando el comentario "Closing due to inactivity" por su cuenta. Merge rate: 42,9%. Ligeramente por encima de Copilot. Cursor, por otro lado, atrajo la mayor proporción de sentimiento negativo en los comentarios de los revisores — el único agente con mayoría de reacciones negativas en el dataset.
La correlación más importante del dataset: hay correlación negativa entre frecuencia de contribución agéntica y tasa de éxito en workflow. Cuanto más volumen genera el agente, más se deteriora la confiabilidad del pipeline en su conjunto.
Esto no es accidente. Es la consecuencia directa de tratar la generación de pull request como generación abierta, sin constraints definidos. El paper identifica tres puntos de control que reducen rechazo: proporcionar approach hints explícitos antes de la generación, delimitar constraints y patrones prohibidos, y enforcer validación de CI sin introducir breaking changes. Esto requiere una capa de guidance entre el issue tracker y el context window del agente. Un filtro de tareas de baja prioridad. Un harness de validación pre-creación de PR. Sin esto, estás generando volumen para que tu equipo de review absorba — no código para deployar.
Ahora lleva ese dato de 46% al EvoArena, y el problema se vuelve aún más denso. [ref: evoarena-benchmarks-llm-agent-] Un grupo de la National University of Singapore, con Salesforce AI Research y MIT, publicó el primer benchmark que modela drift de entorno de la forma en que funciona el mundo real: cambios progresivos, versionados, encadenados. No un snapshot estático. Una secuencia de actualizaciones donde el agente necesita mantener lo que aún es válido y descartar lo que cambió.
Tres sub-benchmarks: Terminal-Bench-Evo para workflows de CLI en evolución, SWE-Chain-Evo para codebases en cambio, y PersonaMem-Evo para preferencias de usuario que derivan en el tiempo. El resultado: los agentes actuales aciertan en promedio 39,6% de las tareas en entornos evolutivos. La falla modal tiene un nombre técnico: state collapse.
State collapse: el agente mantiene una única representación de estado más reciente. Cuando una regla de permiso o schema de API se actualiza, la nueva versión sobrescribe la anterior. El agente pierde tanto el comportamiento antiguo como el límite contextual de cuándo era válido. Los checks de compatibilidad de versión son particularmente letales para los sistemas baseline.
La solución propuesta por el paper es EvoMem — un patch log append-only que se añade al sistema de memoria existente, sin reemplazarlo. Cada cambio de entorno se convierte en un diff estructurado. Para reconstruir cualquier estado anterior, el agente reproduce la secuencia de diffs. Es conceptualmente similar a git para el estado cognitivo del agente. La ganancia: 1,5 puntos porcentuales en el promedio de EvoArena. 6,1% en GAIA. 4,8% en LoCoMo. La accuracy a nivel de chain mejora 3,7%. Me gusta la arquitectura. Pero tengo un problema con lo que el paper no publica: costo de latencia de replay, token spend por reconstrucción, comportamiento cuando el patch log tiene miles de versiones. Un log de diffs que crece indefinidamente eventualmente fuerza una etapa de compresión — que reintroduce exactamente el riesgo de state loss que EvoMem se propone resolver. Nadie puede ignorar ese punto.
Y 1,5 puntos por encima de 39,6% significa que la falla aún es el resultado modal, incluso con EvoMem. La dirección es correcta. La solución completa aún no existe.
Lo que cierra el argumento de esta primera parte es EurekAgent. [ref: agent-environment-engineering-] Investigadores de Tsinghua y Zhipu AI construyeron un agente de investigación autónoma operando sobre cuatro pilares de ingeniería de entorno. Y el resultado más limpio que publican es este:
Nuevo estado del arte en circle packing — superando el mejor resultado anterior de IA, de 2,635986, llegando a 2,635999 — con menos de once dólares en costo total de API.
En ResearchClawBench — 40 tareas en 10 dominios de investigación — Claude Code y Codex como agentes standalone superaron todos los frameworks especializados en investigación, incluyendo AlphaEvolve y AIDE. La latencia del kernel TriMul bajó de 2247,78 microsegundos a 2005,03 — mejora de 10,8% sobre el mejor resultado anterior de IA. MLE-Bench subió de 71,43% a 85,71% — ganancia de 14,28 puntos porcentuales. Sin fine-tuning. Sin RL. Sin training run especializado. Solo fronteras de ejecución más rígidas.
Los cuatro pilares que EurekAgent operacionaliza: permissions engineering con sandboxes aislados que impiden al agente leer su propia señal de recompensa o filtrar datos de entrenamiento para la validación; artifact engineering con filesystem y Git-based state handoffs entre múltiples agentes; budget engineering con hard caps de token y compute que fuerzan auto-regulación del scope de exploración; y human-in-the-loop engineering con ganchos de supervisión de bajo atrito que no bloquean al agente.
La conclusión que EurekAgent fuerza es directa: el cuello de botella no es el modelo. Es el entorno de ejecución. Esto cambia el cálculo de dónde inviertes. Puedes gastar semanas en prompt engineering y ver retorno marginal decreciente. O puedes invertir en sandboxing, tooling e isolamiento de evaluación — y ver ganancias del orden que EurekAgent demuestra, sin tocar los pesos del modelo.
Deja de optimizar prompts. Comienza a endurecer fronteras. Sandbox el runtime, aísla evaluación de los artefactos del agente, y dale al agente un filesystem Git antes de darle un workflow engine.
El segundo bloque de esta semana sucedió en la capa de infraestructura — y el timing entre los tres anuncios fue coordinado demasiado para ser coincidencia. En tres días: Microsoft anuncia el Unified Model API en Azure, abre pg_durable como extensión de PostgreSQL, y Databricks lanza plataforma de serving model-agnostic. Tres movimientos que convergen alrededor de la misma tesis: gateway más workflow primitive más serving unificado es el stack de IA de producción que está solidificándose.
Vamos por Azure. [ref: azure-api-management-ships-uni] El Unified Model API llegó a public preview en Azure API Management. La propuesta: estandarizas el client en formato OpenAI Chat Completions. El gateway transforma transparentemente a Anthropic Messages API, Vertex AI, Amazon Bedrock, o Microsoft Foundry — lo que necesites en el backend. ¿Quieres cambiar de Claude a Gemini? Cambias una routing rule. El client no reescribe una línea de código.
Las implicaciones operacionales van más allá del roteamiento. Governance policies — rate limits, token quotas, retry logic, el filtro llm-content-safety — aplicados uniformemente en todos los providers por una única capa de configuración. Circuit breakers que aíslan endpoints de inferencia no responsivos. Y el API Center MCP server llegó a general availability como endpoint de discovery unificado para la empresa — automáticamente visible para agentes conectados cuando se registra.
La cobertura de content safety fue expandida: ahora inspecciona argumentos de tool call MCP, texto de respuesta MCP, y payloads de Agent-to-Agent. El shield-prompt attribute hace scan específico para ataques de prompt injection, con thresholds configurables de severidad de 0, el más restrictivo, hasta 7.
Pero aquí está el edge case que va a morder a alguien en producción antes de fin de mes. En modo non-streaming, una violación de content safety retorna un 403 limpio. En modo streaming, la policy para de reenviar tokens silenciosamente — sin código de error. El client no puede distinguir un stream truncado por violación de un completion natural sin instrumentación adicional.
Sin código de error. En streaming.
No sabes lo que no recibiste. Vas a necesitar instrumentación extra para detectar truncación. Y Microsoft no publicó latency percentiles, token pricing, o throughput benchmarks para la translation layer — lo que significa que tienes que baselinar el hop adicional por tu cuenta antes de ir a producción. Más: el Unified Model API aún está en public preview, entonces SLAs de producción no se aplican. MCP support en APIM cubre tools, pero no resources o prompts. El rollout es staged, con tiers v2 recibiendo features primero. No es el momento de asumir comportamiento de GA.
En la misma semana, Microsoft abrió pg_durable. [ref: microsofts-postgresql-extensio] Una extensión de PostgreSQL que mueve checkpointing, retry logic, y state recovery dentro del proceso del banco de datos mismo. Sin control plane externo. Un background worker en Rust. Dos componentes: duroxide para el runtime de orquestación con replay determinístico, checkpoints, sub-orquestaciones y timers; duroxide-pg para persistir instancias, histórico y work queues en un schema dedicado dentro de Postgres.
El DSL en SQL es minimal: pasos secuenciales ligados con ~>, resultados bindados a variables con |=>, branches paralelos mergeados con &, y df.start() que inicia una función durable y retorna un instance ID. Para quien ya tiene datos y lógica en Postgres, la propuesta elimina una lista específica de infraestructura: tablas de pg_cron, status columns, retry counters, polling workers, callbacks de Airflow o Temporal. Todo reemplazado por orquestración SQL-native con backup y point-in-time recovery del propio Postgres. Disponible como paquetes Debian para PostgreSQL 17 y 18.
Los casos de uso que más sentido hacen: pipelines de embedding vectorial, ingest con deduplicación, y aprobaciones human-in-the-loop que pueden esperar minutos o días antes de avanzar al siguiente paso.
Pero no es Temporal. Si tus agentes toman decisiones en Python o Go, con lógica de aplicación arbitraria que no mapea a pasos SQL, aún necesitas un orchestrator dedicado. Y correr una extensión Rust nueva en el tier de banco tiene una implicación operacional directa — un memory leak o crash en el background worker afecta al proceso host de Postgres. Esa es una elección de dónde quieres que el failure domain esté, no una simplificación gratuita.
Y cerrando el bloque: Databricks. [ref: databricks-ai-serving-platform] Plataforma de serving model-agnostic que unifica en una única interfaz desde un clasificador scikit-learn de 2 megabytes en un core de CPU hasta un LLM fine-tuned de 70 billones de parámetros en ocho GPUs.
Los números publicados: 300 mil queries por segundo en el agregado de la plataforma, con menos de 10 milisegundos de overhead de p99. Clientes migrando de stacks self-managed reportan reducción de costo de infraestructura de hasta 90%. Runtime elegido automáticamente: Gunicorn MLflow asíncrono para modelos clásicos, vLLM, NVIDIA Triton, o runtime propio del cliente para cargas GPU — todo bajo la misma interfaz de serving. Todo endpoint emite telemetría a Unity Catalog vía OpenTelemetry: métricas, logs, traces, e inference tables streamando cada request a Delta.
La elisión de decisión que Databricks está vendiendo es real: no necesitas más decidir runtime, scaler, observability wiring por modelo. La plataforma lo infiere del perfil del modelo y del patrón de tráfico. Deploy en un click desde la etapa de entrenamiento a producción — con match exacto de entorno.
Con las ressalvas que el marketing no menciona: la reducción de 90% de costo es específica para escenarios de migración, no es steady-state. El número de 300K QPS es agregado de toda la plataforma, no capacidad de un único endpoint. No hay benchmarks independientes publicados. Y cada endpoint es un deployment Kubernetes completamente aislado — lo que significa cold-start y overhead de orquestación por endpoint que tienes que modelar antes de deployar docenas de micro-classifiers al lado de LLMs pesados. Pero el argumento estratégico cierra. El stack está convergiendo. Si aún tienes lógica de roteamiento hand-rolled entre modelos, estás acumulando deuda técnica en latencia y auditoría que va a aparecer en la cuenta cuando intentes escalar.
Trata el roteamiento de modelos como capa de governance — no como lógica de negocio. Es esa abstracción la que va a separar los stacks de IA de producción de los proofs of concept en los próximos dieciocho meses.
Tercer bloque. La capa más cara, más escasa, y más políticamente cargada de esta semana. Compute.
Una orden de compra que, si se confirma en la escala reportada, rompe un monopolio que silenciosamente controlaba el techo de capacidad de inferencia del mundo entero.
Google supuestamente encargó a Intel el packaging de más de tres millones de TPUs para entrega en 2028. [ref: google-locks-in-3m-tpus-with-i] La tecnología es EMIB — embedded multi-die interconnect bridge. En lugar de colocar cada die en un interposer de silicio grande como CoWoS de TSMC, EMIB usa bridges de silicio pequeños en el sustrato orgánico para conexiones solo entre dies adyacentes. Intel reclama utilización de paquete próxima a 90% contra aproximadamente 60% para packaging clase interposer CoWoS.
Y Bernstein estima costo de packaging EMIB en "algunas centenas de dólares por chip" contra 900 a 1000 dólares para CoWoS en un procesador clase Rubin — con una ressalva explícita insertada en la propia estimación: la ventaja es contingente en un "track record externo de producción" que aún no existe.
Para entender por qué la escala de esta orden importa, el dato que C.C. Wei, CEO de TSMC, dio a finales de 2025: la capacidad de nodo avanzado de TSMC está "aproximadamente tres veces por debajo de la demanda". NVIDIA consume aproximadamente 60% del supply global de CoWoS. Broadcom y AMD absorben otros 26%. Sobra aproximadamente 14% para todo mundo más — incluyendo los ASICs customizados de Google.
Entonces Google no está solo comprando capacidad de packaging. Está ejecutando una estrategia de dual-source: TSMC para los wafers, Intel para el assembly — y comenzando calificación dos años antes del silicio de producción. Ese es el lead time que necesitas para no quedar rehén de un único punto de falha en la supply chain de aceleradores. Pero no llamaría esto una victoria sin los datos que importan: yield en volumen, calificación formal de SK Hynix para HBM en bridges EMIB — que aún está en progreso — y claridad sobre si Intel está fabricando los dies o solo haciendo assembly. JPMorgan nota que Intel puede estar solo cuidando packaging, con TSMC fabricando el silicio — lo que es adición de capacidad significativa, pero menos transformadora que un cambio completo de foundry.
Intel Foundry perdió 10,3 billones de dólares en 17,8 billones en ingresos en 2025. En el primer trimestre de 2026, clientes externos contribuyeron solo 174 millones de dólares de 5,4 billones en ingresos totales de la división. Sin evidencia de producción en volumen. La ventaja de costo es teórica sin yield.
El takeaway para arquitectos: packaging avanzado es ahora el factor limitante en supply de aceleradores — no el silicio. Calificar un segundo proveedor de packaging toma mínimo dos años. Si necesitas capacidad de inferencia customizada en 2027, ese proceso necesitaba haber comenzado antes de fin de este trimestre.
Ahora un dato de latencia que cambia el cálculo para cargas de inferencia interactiva. D-Matrix entró en producción completa con Corsair — acelerador de inferencia basado en SRAM on-chip — con backing de M12, el brazo de venture de Microsoft. [ref: microsoft-backed-d-matrix-chip] Benchmarks independientes de Gimlet Labs: en un modelo draft especulativo de 1,6 billones de parámetros para un target de 120 billones de parámetros GPT-OSS, el tiempo de respuesta end-to-end bajó de 24 segundos a menos de 2 segundos cuando Corsair fue pareado con una GPU Blackwell.
Doce veces de mejora sobre el baseline GPU-only. Y la razón es estructural, no un quirk de benchmark. Cada card Corsair tiene 2 gigabytes de SRAM on-chip con 150 terabytes por segundo de memory bandwidth — aproximadamente veinte veces el bandwidth de una GPU high-end. Speculative decoding está memory-bandwidth-bound. Corsair alimenta el modelo draft rápido lo suficiente para mantener la GPU principal saturada todo el tiempo.
El techo de capacidad es real y no debe ser ignorado. Un servidor puede correr un Llama 3.1 de 8 billones de parámetros cuantizado. Modelos de razonamiento grandes no caben en un design basado en SRAM. D-Matrix está direccionando esto con Pavehawk, chip de próxima generación con DRAM 3D-stacked para expandir capacidad más allá de los 128 gigabytes de SRAM por servidor del sistema actual.
Hasta entonces, Corsair es un inference sidecar, no un replacement. Stacy Rasgon de Bernstein confirma clientes reales deployando Corsair "en conjunto con Nvidia" — no en lugar de. El card cuesta decenas de miles de dólares. D-Matrix vale aproximadamente 2 billones de dólares después de levantar alrededor de 500 millones, con entregas previstas para hyperscalers, neoclouds y frontier labs en junio de 2026 — 90% basados en Estados Unidos.
Para arquitectos: el caso de uso primario son workloads de voz, chatbots, y herramientas de agentic coding donde latencia es crítica y el draft model cabe en SRAM. No substituyas tu fleet de GPU. Añade Corsair como capa de latencia para workloads donde la diferencia entre 2 y 24 segundos cambia fundamentalmente la experiencia del usuario.
Y ahora el reality check que cierra este bloque de compute — y que la industria necesita escuchar sin el filtro de entusiasmo de startup. Un rack estándar de 32 GPUs. Aproximadamente 40 kilowatts de consumo. En órbita. Para disipar ese calor en vacío: 80 metros cuadrados de radiador por rack. [ref: why-orbital-data-centers-will-]
Ese no es un número teórico. Es la física de Stefan-Boltzmann aplicada al TDP del H100. Un único H100 a 700 watts TDP, mantenido a 60 grados Celsius, requiere 1,4 metros cuadrados de radiador. A 85 grados, cae a aproximadamente 1 metro cuadrado. A 20 grados, sube a casi 3 metros cuadrados por chip. Un rack de 32 GPUs: 80 metros cuadrados de radiador.
Y ese es solo el día cero. Después de cinco años en órbita, degradación de emissividad por radiación ionizante aumenta el área necesaria en aproximadamente 40% para mantener la misma capacidad de enfriamiento. Una carga térmica de un megawatt a 20 grados requiere aproximadamente 1.200 metros cuadrados de radiador — equivalente a cuatro canchas de tenis.
ABI Research modeló el TCO de un H100 en órbita por un año contra un rack terrestre a 0,20 dólares por kilowatt-hora, asumiendo costo de lanzamiento optimista de 44 dólares por kilogramo vía Starship: costo orbital es al menos un orden de magnitud por encima de la operación terrestre.
Hay apuestas reales en la mesa. Starcloud lanzó un H100 en noviembre de 2025, refrigerado por radiación pasiva. Google tiene Project Suncatcher, con dos satélites cargando TPUs previstos para principios de 2027. Starcloud tiene un filing en la FCC para una constelación de 88 mil satélites.
Y aquí está el problema que no tiene solución de hardware limpia. Chips radiation-hardened tienen 30 a 50% de costo adicional y sacrifican 20 a 30% de performance comparado al silicio terrestre. No tienen densidad de compute para correr LLMs modernos. Entonces vuelas H100s y TPUs "soft" — aceptando cosmic-ray bit-flips y latch-ups como ruido ambiental operacional. Paneles solares necesitan apuntar al sol. Radiadores necesitan apuntar para lejos. Ese es un conflicto de pointing que scheduling de software no resuelve. Y los links ópticos de multi-terabit que Google necesita para Suncatcher necesitan mantener alineación entre satélites en movimiento con drift orbital — añadiendo latencia y pérdida de paquete antes de que un único token llegue a Tierra.
El break-even económico, según análisis de IEEE Spectrum y confirmado por el equipo del Google mismo, requiere costo de lanzamiento por debajo de 200 dólares por kilogramo hasta 2035.
Para misiones de nicho — pre-procesamiento de datos de observación terrestre, rastreo hipersónico en tiempo real, collision avoidance activo en LEO — la física tiene sentido. Compute está co-localizado con el sensor. La latencia de downlink deja de existir. Para inferencia de uso general: no tiene.
Hasta que el costo de lanzamiento baje por debajo de 200 dólares por kilogramo, y un rack de 40 kilowatts sobreviva un ciclo de cinco años de degradación de radiador sin convertirse en un ancla térmica, data centers orbitales son una demostración de física — no un stack de producción.
Esta semana, el modelo paró de ser la variable que controlas. El entorno de ejecución, el gateway de roteamiento y el silicio de packaging se convirtieron en el locus de ventaja competitiva — y los tres tienen cuellos de botella físicos u operacionales que ningún anuncio borra. Próximo lunes: qué de hecho fue a producción en medio de todos estos anuncios — y quién está pagando la cuenta de capacidad de inferencia. Que tengas una buena semana.