The week when model capacity stopped being the bottleneck — and the environment, the gateway, and inference capacity became the product the CTO needs to price.
Forty-six percent.
That's the rate at which human reviewers reject code fixes generated by Copilot, Devin, Cursor, and Claude. In 932 thousand pull requests analyzed. In the real world.
This is the Edition from ai|expert — edition fifteen. The week when model capacity stopped being the bottleneck, and the environment, the gateway, and silicon became the product the CTO needs to learn to price.
A paper published this week on arXiv put a number on what many people suspected, but preferred not to measure. The dataset is called AIDev: 932,791 agentic pull requests, across 116,211 repositories, with 72,189 developers involved. It's the largest dataset of code agent behavior published to date. [ref: 46-of-ai-generated-code-fixes-]
And the central number: 46.41% of the fixes proposed by the agents were rejected by human reviewers. The researchers analyzed 306 unmerged PRs from GitHub Copilot, Devin, Cursor, and Claude Code, and cataloged 14 rejection reasons within four categories: incorrect implementation, CI pipeline failure, agent inability, and low fix priority. This is the fault model that was missing to debug an agentic code pipeline.
What makes the data even more revealing is what happens when you separate it by agent. Copilot and Codex pass CI with rates above 93% and 94%, respectively — in 61,837 GitHub Actions runs analyzed across 2,355 repositories. By any CI metric, they're functioning. But Copilot has the lowest merge rate among all agents in fix PRs: 42.4%.
And the contradiction deepens. Copilot generates an average of 2.56 comments per PR. All other agents stay below 1.0 comment per PR. Copilot creates more discussion, passes more CI, and yet is the one that least often becomes production code. This has a clear reading: high volume with low signal-to-noise is worse than low volume with high precision. You're paying in CI compute, in tokens, and — the invisible cost — in reviewer cognitive attention, for artifacts that never go anywhere.
There's an operational detail about Devin that deserves isolated emphasis.
Devin automatically closed 32.1% of its own PRs after detecting reviewer inactivity — posting the comment "Closing due to inactivity" on its own. Merge rate: 42.9%. Slightly above Copilot. Cursor, on the other hand, attracted the highest proportion of negative sentiment in reviewer comments — the only agent with a majority of negative reactions in the dataset.
The most important correlation in the dataset: there's a negative correlation between frequency of agentic contribution and success rate in workflow. The more volume the agent generates, the more reliability of the pipeline as a whole deteriorates.
This isn't accident. It's the direct consequence of treating pull request generation as open-ended generation, without defined constraints. The paper identifies three control points that reduce rejection: providing explicit approach hints before generation, delimiting constraints and prohibited patterns, and enforcing CI validation without introducing breaking changes. This requires a guidance layer between the issue tracker and the agent's context window. A filter for low-priority tasks. A validation harness pre-PR creation. Without it, you're generating volume for your review team to absorb — not code to ship.
Now take that 46% number to EvoArena, and the problem becomes even denser. [ref: evoarena-benchmarks-llm-agent-] A group from National University of Singapore, with Salesforce AI Research and MIT, published the first benchmark that models environment drift the way the real world works: progressive, versioned, chained changes. Not a static snapshot. A sequence of updates where the agent needs to maintain what's still valid and discard what changed.
Three sub-benchmarks: Terminal-Bench-Evo for evolving CLI workflows, SWE-Chain-Evo for changing codebases, and PersonaMem-Evo for user preferences that drift over time. The result: current agents get 39.6% of tasks correct in evolutionary environments on average. The failure mode has a technical name: state collapse.
State collapse: the agent maintains a single most-recent state representation. When a permission rule or API schema is updated, the new version overwrites the previous one. The agent loses both the old behavior and the contextual boundary of when it was valid. Version compatibility checks are particularly lethal for baseline systems.
The solution proposed by the paper is EvoMem — an append-only patch log that is added to the existing memory system, without replacing it. Each environment change becomes a structured diff. To reconstruct any prior state, the agent replays the sequence of diffs. It's conceptually similar to git for the agent's cognitive state. The gain: 1.5 percentage points on the EvoArena average. 6.1% on GAIA. 4.8% on LoCoMo. Chain-level accuracy improves 3.7%. I like the architecture. But I have a problem with what the paper doesn't publish: replay latency cost, token spend per reconstruction, behavior when the patch log has thousands of versions. A diff log that grows indefinitely eventually forces a compression step — which reintroduces exactly the state loss risk that EvoMem proposes to solve. Nobody can ignore that point.
And 1.5 points on top of 39.6% means failure is still the modal outcome, even with EvoMem. The direction is right. The complete solution doesn't exist yet.
What closes the argument of this first section is EurekAgent. [ref: agent-environment-engineering-] Researchers from Tsinghua and Zhipu AI built an autonomous research agent operating on four pillars of environment engineering. And the cleanest result they publish is this:
New state of the art in circle packing — surpassing the best previous AI result of 2.635986, reaching 2.635999 — with less than eleven dollars in total API cost.
On ResearchClawBench — 40 tasks across 10 research domains — Claude Code and Codex as standalone agents outperformed all specialized research frameworks, including AlphaEvolve and AIDE. The TriMul kernel latency dropped from 2247.78 microseconds to 2005.03 — a 10.8% improvement over the best previous AI result. MLE-Bench rose from 71.43% to 85.71% — a gain of 14.28 percentage points. No fine-tuning. No RL. No specialized training run. Just tighter execution boundaries.
The four pillars that EurekAgent operationalizes: permissions engineering with isolated sandboxes that prevent the agent from reading its own reward signal or leaking training data to validation; artifact engineering with filesystem and Git-based state handoffs between multiple agents; budget engineering with hard caps on tokens and compute that force self-regulation of exploration scope; and human-in-the-loop engineering with low-friction supervision hooks that don't block the agent.
The conclusion that EurekAgent forces is direct: the bottleneck is not the model. It's the execution environment. This changes the calculus of where you invest. You can spend weeks on prompt engineering and see diminishing marginal returns. Or you can invest in sandboxing, tooling, and evaluation isolation — and see gains on the order that EurekAgent demonstrates, without touching the model weights.
Stop optimizing prompts. Start hardening boundaries. Sandbox the runtime, isolate evaluation from the agent's artifacts, and give the agent a Git filesystem before you give it a workflow engine.
The second block this week happened at the infrastructure layer — and the timing between the three announcements was too coordinated to be coincidence. In three days: Microsoft announces the Unified Model API on Azure, opens pg_durable as a PostgreSQL extension, and Databricks launches a model-agnostic serving platform. Three moves that converge around the same thesis: gateway plus workflow primitive plus unified serving is the production AI stack that is solidifying.
Let's go through Azure. [ref: azure-api-management-ships-uni] The Unified Model API reached public preview in Azure API Management. The proposal: you standardize the client in OpenAI Chat Completions format. The gateway transparently transforms to Anthropic Messages API, Vertex AI, Amazon Bedrock, or Microsoft Foundry — whatever you need on the backend. Want to switch from Claude to Gemini? Change a routing rule. The client doesn't rewrite a line of code.
The operational implications go beyond routing. Governance policies — rate limits, token quotas, retry logic, the llm-content-safety filter — applied uniformly across all providers by a single configuration layer. Circuit breakers that isolate non-responsive inference endpoints. And the API Center MCP server reached general availability as a unified discovery endpoint for the company — automatically visible to connected agents when registered.
Content safety coverage was expanded: now inspects MCP tool call arguments, MCP response text, and Agent-to-Agent payloads. The shield-prompt attribute scans specifically for prompt injection attacks, with configurable severity thresholds from 0, most restrictive, through 7.
But here's the edge case that's going to bite someone in production before month's end. In non-streaming mode, a content safety violation returns a clean 403. In streaming mode, the policy stops forwarding tokens silently — with no error code. The client can't distinguish a stream truncated by violation from a natural completion without additional instrumentation.
No error code. In streaming.
You don't know what you didn't receive. You'll need extra instrumentation to detect truncation. And Microsoft hasn't published latency percentiles, token pricing, or throughput benchmarks for the translation layer — which means you need to baseline the additional hop yourself before going to production. More: the Unified Model API is still in public preview, so production SLAs don't apply. MCP support in APIM covers tools, but not resources or prompts. Rollout is staged, with v2 tiers receiving features first. It's not the time to assume GA behavior.
The same week, Microsoft opened pg_durable. [ref: microsofts-postgresql-extensio] A PostgreSQL extension that moves checkpointing, retry logic, and state recovery into the database process itself. With no external control plane. A background worker in Rust. Two components: duroxide for the orchestration runtime with deterministic replay, checkpoints, sub-orchestrations and timers; duroxide-pg to persist instances, history and work queues in a dedicated schema inside Postgres.
The SQL DSL is minimal: sequential steps linked with ~>, results bound to variables with |=>, parallel branches merged with &, and df.start() that initiates a durable function and returns an instance ID. For anyone who already has data and logic in Postgres, the proposal eliminates a specific list of infrastructure: pg_cron tables, status columns, retry counters, polling workers, Airflow or Temporal callbacks. All replaced by SQL-native orchestration with backup and point-in-time recovery from Postgres itself. Available as Debian packages for PostgreSQL 17 and 18.
The use cases that make the most sense: vector embedding pipelines, ingest with deduplication, and human-in-the-loop approvals that can wait minutes or days before advancing to the next step.
But it's not Temporal. If your agents make decisions in Python or Go, with arbitrary application logic that doesn't map to SQL steps, you still need a dedicated orchestrator. And running a new Rust extension on the database tier has a direct operational implication — a memory leak or crash in the background worker affects the Postgres host process. That's a choice of where you want the failure domain to be, not a free simplification.
And closing the block: Databricks. [ref: databricks-ai-serving-platform] Model-agnostic serving platform that unifies into a single interface everything from a 2-megabyte scikit-learn classifier on a single CPU core to a fine-tuned 70-billion-parameter LLM on eight GPUs.
Published numbers: 300 thousand queries per second aggregated across the platform, with less than 10 milliseconds p99 overhead. Customers migrating from self-managed stacks report infrastructure cost reductions of up to 90%. Runtime automatically selected: asynchronous MLflow Gunicorn for classical models, vLLM, NVIDIA Triton, or the customer's own runtime for GPU workloads — all under the same serving interface. Every endpoint emits telemetry to Unity Catalog via OpenTelemetry: metrics, logs, traces, and inference tables streaming every request to Delta.
The elision of choice that Databricks is selling is real: you no longer need to decide runtime, scaler, observability wiring per model. The platform infers it from the model profile and traffic pattern. Deploy in a single click from the training stage to production — with exact environment parity.
With the caveats that marketing doesn't mention: the 90% cost reduction is specific to migration scenarios, not steady-state. The 300K QPS number is aggregated across the entire platform, not capacity of a single endpoint. No independent benchmarks are published. And each endpoint is a completely isolated Kubernetes deployment — which means cold-start and orchestration overhead per endpoint that you need to model before deploying dozens of micro-classifiers alongside heavy LLMs. But the strategic argument closes. The stack is converging. If you still have hand-rolled routing logic between models, you're accumulating technical debt in latency and audit that will show up on the bill when you try to scale.
Treat model routing as a governance layer — not as business logic. It's that abstraction that's going to separate production AI stacks from proofs of concept in the next eighteen months.
Third block. The most expensive, most scarce, and most politically charged layer this week. Compute.
A purchase order that, if confirmed at the scale reported, breaks a monopoly that silently controlled the ceiling on global inference capacity.
Google reportedly ordered Intel to package more than three million TPUs for delivery in 2028. [ref: google-locks-in-3m-tpus-with-i] The technology is EMIB — embedded multi-die interconnect bridge. Instead of placing each die on a large silicon interposer like TSMC's CoWoS, EMIB uses small silicon bridges on the organic substrate for connections only between adjacent dies. Intel claims package utilization close to 90% versus approximately 60% for CoWoS-class interposer packaging.
And Bernstein estimates EMIB packaging cost at "a few hundred dollars per chip" versus 900 to 1000 dollars for CoWoS on a Rubin-class processor — with an explicit caveat embedded in the estimate itself: the advantage is contingent on an "external track record of production" that doesn't yet exist.
To understand why the scale of this order matters, the data that TSMC CEO C.C. Wei gave at the end of 2025: TSMC's advanced-node capacity is "roughly three times below demand". NVIDIA consumes approximately 60% of global CoWoS supply. Broadcom and AMD absorb another 26%. Leaves approximately 14% for everyone else — including Google's custom ASICs.
So Google isn't just buying packaging capacity. It's executing a dual-source strategy: TSMC for the wafers, Intel for assembly — and beginning qualification two years ahead of production silicon. That's the lead time you need so you don't become hostage to a single point of failure in the accelerator supply chain. But I wouldn't call this a victory without the data that matters: yield at volume, formal SK Hynix HBM qualification on EMIB bridges — which is still ongoing — and clarity on whether Intel is fabricating the dies or just doing assembly. JPMorgan notes that Intel may only be handling packaging, with TSMC fabricating the silicon — which is significant capacity addition, but less transformative than a complete foundry switch.
Intel Foundry lost 10.3 billion dollars on 17.8 billion in revenue in 2025. In Q1 2026, external customers contributed only 174 million dollars of 5.4 billion in total division revenue. With no evidence of volume production. The cost advantage is theoretical without yield.
The takeaway for architects: advanced packaging is now the limiting factor in accelerator supply — not silicon. Qualifying a second packaging supplier takes minimum two years. If you need customized inference capacity in 2027, that process needed to start before the end of this quarter.
Now a latency data point that changes the calculus for interactive inference workloads. D-Matrix entered full production with Corsair — an SRAM on-chip based inference accelerator — with backing from M12, Microsoft's venture arm. [ref: microsoft-backed-d-matrix-chip] Independent benchmarks from Gimlet Labs: on a 1.6-billion-parameter draft speculative model for a 120-billion-parameter GPT-OSS target, end-to-end response time dropped from 24 seconds to less than 2 seconds when Corsair was paired with a Blackwell GPU.
Twelve times improvement over the GPU-only baseline. And the reason is structural, not a benchmark quirk. Each Corsair card has 2 gigabytes of on-chip SRAM with 150 terabytes per second of memory bandwidth — roughly twenty times the bandwidth of a high-end GPU. Speculative decoding is memory-bandwidth-bound. Corsair feeds the fast draft model enough data to keep the main GPU saturated the entire time.
The capacity ceiling is real and shouldn't be ignored. One server can run Llama 3.1 with 8 billion parameters quantized. Large reasoning models don't fit in an SRAM-based design. D-Matrix is addressing this with Pavehawk, next-generation chip with 3D-stacked DRAM to expand capacity beyond the current 128 gigabytes of SRAM per server system.
Until then, Corsair is an inference sidecar, not a replacement. Bernstein's Stacy Rasgon confirms real customers deploying Corsair "alongside Nvidia" — not in place of. The card costs tens of thousands of dollars. D-Matrix is valued at approximately 2 billion dollars after raising roughly 500 million, with deliveries planned for hyperscalers, neoclouds, and frontier labs in June 2026 — 90% based in the United States.
For architects: the primary use case is voice, chatbots, and agentic coding tools where latency is critical and the draft model fits in SRAM. Don't replace your GPU fleet. Add Corsair as a latency layer for workloads where the difference between 2 and 24 seconds fundamentally changes the user experience.
And now the reality check that closes this compute block — and that the industry needs to hear without the startup enthusiasm filter. A standard 32-GPU rack. Approximately 40 kilowatts of consumption. In orbit. To dissipate that heat in vacuum: 80 square meters of radiator per rack. [ref: why-orbital-data-centers-will-]
That's not a theoretical number. It's Stefan-Boltzmann physics applied to H100 TDP. A single H100 at 700 watts TDP, maintained at 60 degrees Celsius, requires 1.4 square meters of radiator. At 85 degrees, it falls to about 1 square meter. At 20 degrees, it rises to nearly 3 square meters per chip. A 32-GPU rack: 80 square meters of radiator.
And that's just day zero. After five years in orbit, emissivity degradation from ionizing radiation increases the required area by approximately 40% to maintain the same cooling capacity. One megawatt of thermal load at 20 degrees requires approximately 1,200 square meters of radiator — equivalent to four tennis courts.
ABI Research modeled the TCO of an H100 in orbit for one year versus a rack on Earth at 0.20 dollars per kilowatt-hour, assuming optimistic launch cost of 44 dollars per kilogram via Starship: orbital cost is at least an order of magnitude above terrestrial operation.
There are real bets on the table. Starcloud launched an H100 in November 2025, cooled by passive radiation. Google has Project Suncatcher, with two TPU-carrying satellites planned for early 2027. Starcloud has an FCC filing for a constellation of 88 thousand satellites.
And here's the problem that has no clean hardware solution. Radiation-hardened chips carry 30 to 50% cost premium and sacrifice 20 to 30% performance versus terrestrial silicon. They don't have the compute density to run modern LLMs. So you fly H100s and TPUs "soft" — accepting cosmic-ray bit-flips and latch-ups as ambient operational noise. Solar panels need to point at the sun. Radiators need to point away. That's a pointing conflict that software scheduling doesn't resolve. And the multi-terabit optical links that Google needs for Suncatcher must maintain alignment between moving satellites with orbital drift — adding latency and packet loss before a single token reaches Earth.
The break-even economics, according to IEEE Spectrum analysis and confirmed by Google's own team, requires launch cost below 200 dollars per kilogram by 2035.
For niche missions — preprocessing observation data from Earth, real-time hypersonic tracking, active collision avoidance in LEO — the physics makes sense. Compute is co-located with the sensor. Downlink latency ceases to exist. For general-purpose inference: it doesn't.
Until launch cost drops below 200 dollars per kilogram, and a 40-kilowatt rack survives a five-year cycle of radiator degradation without becoming a thermal anchor, orbital data centers are a physics demonstration — not a production stack.
This week, the model stopped being the variable you control. The execution environment, the routing gateway, and packaging silicon became the locus of competitive advantage — and all three have physical or operational bottlenecks that no announcement erases. Back Monday: what actually went to production in the middle of all these announcements — and who's paying the bill for inference capacity. Have a good week.