AlphaEvolve Eats Its Own Infrastructure — AI Optimizes AI at Production Scale

1. AlphaEvolve Eats Its Own Infrastructure — AI Optimizes AI at Production Scale

TL;DR: Google DeepMind's one-year results for AlphaEvolve, its Gemini-powered agentic coding system, show it has graduated from research to core production infrastructure. It continuously recovers 0.7% of Google's worldwide compute, accelerated a key Gemini training kernel by 23%, and had a hardware circuit design so counterintuitive it went directly into the silicon of Google's next-generation TPUs.

Key Points:

• AlphaEvolve has been running autonomously inside Google's infrastructure for over a year, discovering Borg scheduling heuristics that are now in production
• 0.7% compute recovery across Google's entire fleet sounds small — at Google scale, that means more AI training jobs completed on the same physical footprint, continuously
• 23% speedup to a key Gemini attention kernel, delivering a 1% reduction in Gemini's total training time (meaningful when training runs cost eight figures)
• A FlashAttention kernel optimization produced a 32.5% speedup — results that hold across Transformer-based AI models generally
• The most remarkable result: a hardware circuit design generated by AlphaEvolve was so unconventional human engineers would not have proposed it, yet it was efficient enough to go directly into TPU silicon

Deep Dive:

AlphaEvolve is a two-model system: a Gemini model generates candidate code implementations, and an automated evaluator scores them. The loop runs at scale, exploring solution spaces that humans cannot enumerate. It is not a coding assistant — it generates, tests, and scores without human review in the loop.

What makes this a watershed result is not any single optimization, but the feedback structure. AlphaEvolve is now running on the same hardware its own optimization designed, training the very models it uses to generate better code. The system is already in the third iteration of its own improvement loop, which was not the original goal.

The infrastructure implications are direct. Network engineers who care about how AI infrastructure runs should understand that the optimization layer is now partially autonomous. Scheduling, hardware design, and training efficiency are no longer exclusively human engineering decisions at the frontier. The gap between what frontier labs can do with autonomous optimization and what everyone else can do is widening — not because the models are better, but because the optimization tooling compounds.

So What? The feedback loop between AI-generated code and AI-optimized hardware is now closed at Google. The practical implication for infrastructure engineers: hardware specs, NOS tuning guidance, and power consumption data from vendors will increasingly reflect AI-optimized baselines you cannot replicate manually. Your job is to understand the envelope, not derive the parameters from scratch. For automation engineers, the right takeaway is to study AlphaEvolve's architecture — the generate/evaluate loop at scale is directly applicable to network configuration validation.

SourcesGoogle DeepMind Blog

2. netlab 26.05 and the Python 3.8 Goodbye — Automation Infrastructure Grows Up

TL;DR: Ivan Pepelnjak's netlab released version 26.05 this weekend with a hard break from Python 3.8, ending support for Ubuntu 20.04 vanilla installations. The version also ships new platform capabilities. This is the right call — and the practical pain of hitting it is the exact signal that your automation infrastructure is behind.

Key Points:

• Python 3.8 reached end-of-life in October 2024; netlab 26.05 enforces that boundary — vanilla Ubuntu 20.04 installs will fail
• This is not a gotcha — it is Ivan correctly refusing to accumulate tech debt against a four-year-old Python release
• New feature highlights for 26.05 (details in upcoming ipSpace.net post): continued Codespaces deployability, updated platform support
• The broader signal: network automation tooling is on the same release cadence as software engineering — "it works on my Ubuntu 20.04 box" is no longer a valid defense
• Downstream effect: any CI/CD pipeline invoking netlab directly needs a Python version check before the June patching cycle hits

Deep Dive:

Python 3.8's EOL was announced years in advance. The fact that teams are still hitting it in 2026 is diagnostic. Automation tooling gets built on LTS operating systems and then orphaned — the OS gets patched, the automation tooling does not. Ubuntu 20.04 is hitting standard support EOL in April 2025, with extended support to 2030 available at cost. Teams running it for free are already outside the nominal window.

The netlab 26.05 break is useful precisely because it is painful for exactly the teams that need to feel it. If you have CI/CD pipelines for network testing that broke this weekend, that is the correct outcome. The fix is not to pin to an older netlab version — it is to upgrade the runtime environment. Python 3.10 or later is the current floor for the automation tooling stack.

The practical engineering advice here is simple: run python3 --version in every automation environment you own today. If the answer is not at least 3.10, schedule the upgrade before the end of this quarter. The backlog of EOL Python environments in network automation is systemic, not exceptional.

So What? If you have automation pipelines running on Ubuntu 20.04 or Python 3.8, this is your forcing function. Upgrade now rather than waiting for another library to drop the same support floor. The netlab 26.05 release is available on PyPI and GitHub Codespaces — the upgrade path is well-documented.

SourcesipSpace.net Blog

3. Arista Expands AI Networking Portfolio — R4 Family Targets 800G Fabric at Scale

TL;DR: Arista Networks has extended its R4 router family with new models carrying 800G uplinks and spine router configurations, aiming directly at the AI fabric market where it is projecting 60% growth in 2026. Combined with its earlier AI Fabrics taxonomy (scale-up, scale-out, scale-across), Arista is staking out the end-to-end AI networking position against Cisco and Juniper.

Key Points:

• New R4 line cards add 800G uplinks and spine configurations, filling gaps in the AI fabric portfolio
• Arista is guiding for 60% growth in both AI networks and campus networks in 2026 — a bullish dual-front bet
• The AI fabric taxonomy (scale-up/scale-out/scale-across with SRv6 uSID for multi-cluster) provides a vendor-neutral communication framework for design conversations
• Cisco raised its AI infrastructure revenue guidance from $2 billion to $3 billion for fiscal 2026 — validation that the market is real
• The R4 expansion is paired with EOS automation capabilities — Arista is selling the management plane alongside the forwarding plane

Deep Dive:

Arista's AI fabric play is coherent in a way that Cisco's currently is not. Arista has a clear three-tier model (scale-up for intra-rack GPU interconnect, scale-out for leaf-spine XPU reachability, scale-across for WAN multi-cluster), and the R4 expansion slots cleanly into the scale-across tier. The 800G uplink capability aligns with what large AI cluster operators actually need for inter-pod and inter-cluster traffic.

The 60% growth guidance for AI networking is more aggressive than the market consensus. If it materializes, Arista would have one of the cleanest revenue diversification stories in enterprise networking — campus + AI + datacenter, with each growing. If it misses, the stock will be punished accordingly. For infrastructure engineers, the more useful signal is Cisco moving its AI infrastructure revenue guidance from $2 billion to $3 billion — that's a floor on how much enterprises are actually spending on AI-specific networking, independent of Arista's share.

So What? If you are currently evaluating networking vendors for an AI fabric project, the R4 expansion means Arista has a complete answer for scale-across WAN needs. Ask specifically about RoCEv2 adaptive routing behavior across the R4 uplinks and how the EOS automation surface integrates with your source of truth platform.

SourcesNetwork World

ipSpace.net SR-MPLS Workshop: New Content Continues

The ipSpace.net SR-MPLS workshop series continues shipping new content this week. The series — nine topologies from the ITNOG 10 workshop — covers areas the original April 2026 event ran out of time for. For anyone who missed the earlier announcement, the GitHub repo (ipspace/SR-workshop) is Codespaces-deployable under one minute. The SR101 introductory series is already live; new topology deep dives are publishing through May.

So What? If you are planning any Segment Routing work in 2026, this is the best current free resource. Pull the repo and run two or three topologies this week.

SourcesipSpace.net Blog

AI-Assisted GitOps Reaches Production Maturity — From Drift Detection to Intent Authoring

TL;DR: The convergence of GitOps with AI-assisted automation has crossed from experiment to production pattern in 2026. Teams are now using LLM-powered systems to generate infrastructure proposals from natural language, detect drift, and auto-propose pull requests — with Git still as the audit trail and approval gate.

Key Points:

• Forward Networks Forward AI (GA April 2026) established the template: multi-step agent workflows grounded in a deterministic network twin, not LLM memory
• The general pattern is now: intent → LLM proposes config → digital twin validates → Git PR → human approves → push
• The key constraint remains data quality: AI automation hallucinations are a data-quality problem before they are a model problem
• NetBox Changes v1.0 (covered May 15) and Nautobot 3.1 (covered May 14) both represent the source-of-truth layer hardening to support this pattern
• Teams at NetDevOps maturity stage three or higher are already running pilot workflows; the question is no longer "should we" but "where is our data good enough"

Deep Dive:

The 2026 GitOps maturity shift is architectural. Two years ago, GitOps in networking meant config templates in Git with Ansible applying them. Today, the pattern has a new layer: an AI agent that reads the network's current state (via a digital twin or source-of-truth query), proposes a change in natural language converted to configuration, and submits a PR to the Git pipeline. The human approval step remains, but the authoring step has moved from engineer to agent.

The quality gate is the digital twin or source-of-truth query. Without a verified ground-truth model of what the network actually looks like, the AI agent's proposals are grounded in LLM training data — which means they are plausible but not necessarily accurate for your environment. This is why the source-of-truth graduation arc of the last two weeks (Infrahub, Nautobot 3.1, NetBox Changes) is the prerequisite infrastructure story. The AI-GitOps pattern does not work well without it.

The Network DNA blog published a detailed network automation roadmap this week that maps the maturity stages clearly — from reactive CLI to fully autonomous agentic operations. Worth reading as a planning framework.

So What? Evaluate your current automation stack against the four-layer model: inventory (source of truth), validation (digital twin or Batfish), change governance (NetBox Changes or similar), and agentic intent authoring. The fourth layer is where the AI tooling plugs in. Do not attempt the fourth layer without hardening the first three.

SourcesThe Network DNA, NTT DATA

Google I/O 2026 Starts Tomorrow — Gemini Intelligence and Agentic Android

TL;DR: Google I/O 2026 kicks off May 19 (tomorrow). The centerpiece is Gemini Intelligence — a persistent cross-app AI agent embedded in Android that can move across apps, understand screen context, and complete tasks autonomously. This is the most serious challenge to date to how people interact with software.

Key Points:

• Gemini Intelligence moves across apps on Android, reading screen state and completing multi-step tasks — not just responding to prompts
• Gemini Spark (internally "Remy") is a persistent agent that proactively manages workflows without waiting for commands
• Android AppFunctions gives developers a surface for apps to expose capabilities to Gemini agents
• Google has confirmed human-in-the-loop approval for transactions — "the human is always in the loop" is the stated design principle
• Gemini Omni (rumored) would add native video generation and editing directly within Gemini

So What? Watch tomorrow's I/O keynote specifically for what AppFunctions enables for enterprise applications. If Gemini can read and act on network management UIs the same way it can read and act on Gmail, the implications for network operations tooling UX are significant.

SourcesAndroid Authority, eWeek

Kimi K2.6 — 1.6 Trillion Parameter MoE at Near-Frontier Performance

TL;DR: Moonshot AI's Kimi K2.6 is a 1.6-trillion-parameter Mixture-of-Experts model that scored within 6 points of Claude Opus 4.7 on SWE-bench Pro. It is one of the largest open-weight models in the field and validates that non-US labs are competing at the frontier on code and reasoning tasks.

Key Points:

• 1.6 trillion parameters MoE architecture — only a fraction of those activate per inference, keeping cost manageable
• SWE-bench Pro scores within 6 points of Claude Opus 4.7 — that's a meaningful gap but not a disqualifying one for most tasks
• Moonshot AI is the same team behind the 128K-context Kimi Chat — this is their entry into the frontier coding tier
• MoE architecture means inference cost per token is much lower than parameter count suggests — routing efficiency is the key variable
• The benchmark is the highest self-reported; independent verification is ongoing

So What? For teams evaluating on-premise or self-hosted inference for code and automation tasks, Kimi K2.6 warrants a benchmark on your specific workload. The MoE architecture makes it more tractable on shared inference infrastructure than a dense 1.6T model would be.

SourcesBuildFastWithAI

AI Demands Stretch the Physical Limits of Data Center Retrofits

TL;DR: Operators retrofitting legacy data centers for AI workloads are running into hard physical constraints — not just power contracts, but floor loading, power distribution topology, and cooling infrastructure that was designed for 10-14 kW racks, not 100-140 kW GPU clusters. The retrofit vs. greenfield decision has a new calculus.

Key Points:

• Individual rack power draw has surged from 10–14 kW to over 100 kW; NVIDIA's Vera Rubin generation is expected to reach 250 kW per rack
• High-density AI racks can weigh up to 1.5 metric tons — multi-story facilities have genuine floor-loading constraints
• Power distribution at 40–50 kW per rack exceeds what standard busway and breaker infrastructure can support without major electrical work
• Liquid cooling is no longer optional or niche; it is the baseline requirement for any serious AI deployment
• Existing sites have one structural advantage: power access. Power interconnection timelines for new sites are now running 3–7 years in some markets

Deep Dive:

The retrofit vs. greenfield calculation in 2026 is not "which is cheaper to build" — it is "which has power access and can it be made to work." Utility interconnection for new greenfield AI data center sites in constrained markets (Northern Virginia, Phoenix, Silicon Valley) is running 3+ years even after site selection and permitting. Existing sites with power access are valuable precisely because they have power, even if the physical envelope is wrong.

The engineering challenge is which retrofits are feasible. A single-story warehouse-style building with a 100 MW utility connection and strong floor loading can support liquid-cooled AI clusters — with capital investment. A multi-story office-park data center with 10 kW/rack power distribution topology is likely not retrofittable to AI-cluster density without more capital than a new facility would cost.

The decision variable is the power access situation, not the building envelope. Infrastructure engineers evaluating AI workload placement should map the power access timeline first, then determine whether the physical envelope can be made to work within that timeline.

So What? Before committing to a colocation or retrofit plan for AI workloads, request the facility's power distribution topology map — specifically breaker capacity, busway ampacity, and PDU density. Floor-loading specs are less likely to be the blocker unless the facility is genuinely old. The power distribution topology is where the retrofits are failing.

SourcesData Center Knowledge

Aalto's Quasicrystal Quantum Algorithm — Simulating the Impossible in Seconds

TL;DR: Researchers at Aalto University published a quantum-inspired algorithm that simulates quasicrystals with 268 million sites in seconds — a problem that previously required more than a quadrillion floating-point numbers and exceeded the capacity of any classical supercomputer. The work appeared in Physical Review Letters and opens a path to designing topological qubits and dissipation-free electronics.

Key Points:

• Quasicrystals are non-periodic quantum materials — their simulation involves more than a quadrillion numbers, beyond classical supercomputer capacity
• The Aalto team used tensor networks (a family of algorithms encoding exponential quantum spaces) to compute a 268-million-site quasicrystal in under a second
• Immediate application target: designing materials for advanced topological qubits — a path to quantum error correction with lower overhead than current approaches
• Longer-term application: dissipation-free electronics that do not convert electricity to heat — relevant to data center power consumption at scale
• Published in Physical Review Letters, April 2026 — peer-reviewed, independent research

Deep Dive:

The physics here is worth unpacking. A quasicrystal is a material whose atomic structure has long-range order but no periodic repetition — like Penrose tiles in three dimensions. Simulating its quantum properties requires tracking the state of every atom in relation to every other, and without periodicity, you cannot use the symmetry shortcuts that make crystal simulations tractable. That's why the number of variables exceeds a quadrillion.

Tensor networks work by exploiting a different kind of structure: the entanglement structure of quantum states. Most physically relevant quantum states, even complex ones, are not maximally entangled — they have a limited entanglement structure that tensor networks can represent efficiently. The Aalto algorithm applies this insight to quasicrystals, encoding the system in a tensor-network representation that captures the relevant physics without the quadrillion-variable overhead.

The topological qubit application is the near-term one to watch. Topological qubits protect quantum information in the global structure of a material rather than in a single physical system, making them inherently more noise-resistant. If Aalto's simulation framework can identify and validate new topological qubit materials computationally, the path to fault-tolerant quantum computing gets significantly shorter.

So What? This is not a compute-today story — it is a materials-discovery story that will surface in quantum hardware roadmaps 18–36 months from now. The practical near-term action is unchanged: if you have data with five-year confidentiality requirements, ML-KEM and ML-DSA (NIST-finalized post-quantum standards) should be active engineering projects now. The hardware roadmap is advancing faster than most enterprise security planning cycles.

SourcesScienceDaily, The Quantum Insider

• netlab 26.05 released this weekend: Also adds new platform support and continued Codespaces compatibility — Python 3.8 drop is the headline change but the release is substantive. Check the ipSpace.net blog for the full feature post expected tomorrow.
• OpenClaw agent harnesses: The Register covered how agent harness tooling (OpenClaw and similar) is changing how LLM inference runs on CPUs versus GPUs — increasingly, light orchestration tasks run on CPU while heavy generation stays on GPU, with the harness managing the routing.
• AI-RAN techno-economic framework (arXiv 2603.28680): An arXiv preprint this weekend models the economics of sharing GPU infrastructure between 5G Layer-1 processing and AI inference during off-peak periods — the CAPEX case for AI-RAN deployments.

SourcesipSpace.net, The Register, arXiv

• Google I/O 2026 (May 19): Gemini Intelligence, Gemini 4.0 or Gemini 3.5, and AppFunctions for developers. Watch specifically for any enterprise developer surface announcements and what "human in the loop" means operationally for agentic transactions.
• ipSpace.net netlab 26.05 post: Ivan said he'll post the full feature highlights for 26.05 the day after the release. Worth reading if you have netlab in your automation stack.
• Arista earnings (late May): The 60% AI networking growth guidance will be the key number to watch — sets the floor for how much enterprise spending on AI-specific networking is actually happening.

Pipeline stats: 5 domains researched, 8 web searches, 10 primary items + 3 quick takes, 0 dedup rejections (all May 13–15 items on 72-hour cooldown respected), quality score 4.5/5. RSS digest used (32 articles, top score 5.2 — AI-RAN arXiv 5.2, DCK retrofit 2.0, Agent harnesses Register 2.8).