Sixteen Claude AI agents working together created a new C compiler

Anthropic har i denne uge et meget tidstypisk budskab: Stop med at “chatte” med AI, og begynd at lede den. Som demo slap forsker Nicholas Carlini 16 instanser af Claude Opus 4.6 løs på en delt kodebase og bad dem bygge en C-compiler fra bunden—næsten uden opsyn. “Næsten” er selvfølgelig nøgleordet, for i AI-land er det ofte her, regningen og realiteterne bor.

Resultatet: over to uger og knap 2.000 Claude Code-sessioner (omkring 20.000 dollars i API-udgifter) blev der produceret en ca. 100.000 linjer stor compiler skrevet i Rust, som angiveligt kan bygge en bootbar Linux 6.9-kernel på x86, ARM og RISC-V. Det er på papiret en vild milepæl—og i praksis en påmindelse om, at “agent” også kan betyde “praktikant med adgang til produktion”, hvis du ikke styrer stramt.

Sixteen Claude AI agents working together created a new C compiler

Det, der lyder som magi, er i virkeligheden projektledelse

Hvis du har bygget software på macOS, ved du, at de “store sejre” sjældent er én genial commit. De er en endeløs parade af build-fejl, kanttilfælde, toolchain-quirks og en CI, der pludselig hader dig. En C-compiler er netop sådan et projekt: massiv overflade, uendelige hjørner og en brutal feedback-loop, hvor “det virker” først betyder “det kompilerer”, og senere betyder “det kompilerer den rigtige ting”.

At 16 agenter kan drive den proces frem, er interessant, men det skubber ikke fysikkens love af vejen: Der er stadig en menneskelig dirigent, der prioriterer, skærer opgaven ud i bidder og afgør, hvornår noget er godt nok. I Apple-verdenen svarer det lidt til at give 16 juniorudviklere adgang til Xcode og sige “vi ses om to uger”—bare med flere tokens og færre kaffepauser.

Hvorfor lige en C-compiler—og hvorfor betyder det noget?

C er stadig fundamentet under meget af den software, vi tager for givet—inklusive dele af toolchains, drivere og kerneteknologi. Og når noget kan bygge en Linux-kernel, er det en slags “crash test” af korrekthed. Det siger dog ikke alt: en compiler kan være god nok til en bestemt kernel-konfiguration, men stadig have subtile fejl, der først viser sig i andre workloads, med andre flags, eller når nogen kører den mod obskure test-suiter.

På Apple Silicon—tænk M3, M2, ARM og de små forskelle, der dukker op i praksis—er toolchain-kvalitet alt. Mange udviklere lever i dag i krydsfeltet mellem macOS, Linux-containere og cross-compiling til iOS og iPadOS. En ny compiler skrevet i Rust lyder moderne, men det hårde spørgsmål er: Kan den levere stabilitet, determinisme og fejldiagnostik på niveau med de etablerede projekter?

Min vurdering er: Det her er en sejr—men ikke den, de fleste tror

Min vurdering er, at det mest værdifulde ved eksperimentet ikke er, at “AI byggede en compiler”. Det er, at multi-agent-setup’et viser, hvor meget produktivitet der kan frigøres, når man behandler modellen som et team, ikke som en orakel-maskine. Men prisen er tydelig: 20.000 dollars, to uger, og stadig behov for dyb menneskelig management. Det er ikke en erstatning for seniorer—det er en forstørrelsesglas-effekt på dem.

Og her kommer den tørre pointe: Hvis du allerede er typen, der kan styre en kompliceret build-kæde, så hjælper agenter dig med at komme hurtigere igennem støjen. Hvis du ikke er… så får du bare støjen i højere tempo. Lidt som at sætte Metal på en dårlig idé: hurtigere, men ikke nødvendigvis bedre.

Pro Tip: Hvis du vil eksperimentere med “agentic coding” på Mac, så lås din toolchain: pin din Rust-version, frys dependencies, og kør alt i en reproducerbar container eller et isoleret build-miljø. Brug separate branches pr. agent, slå “required reviews” til, og kør en hård testpakke (compiler torture tests, fuzzing og deterministiske builds) før du overhovedet overvejer at lade noget røre main. Det er kedeligt—og præcis derfor virker det.

Hvad betyder det for Apple-udviklere lige nu?

På den korte bane er det her ikke en ny konkurrent til clang i Xcode, og det er ikke noget, der pludselig ændrer din App Store-pipeline eller TestFlight-flow. Men det er et signal om, at “AI som udviklingsmiljø” rykker fra autocomplete til orkestrering: flere processer, flere parallelle spor, mere koordination. Uanset om du bygger en Swift-app, en iOS-extension, en macOS-daemon eller en cross-platform motor, er det den disciplin, der bliver den nye flaskehals.

Hvis du vil dykke mere ned i agent-trenden og konsekvenserne for værktøjer og workflow, kan du følge emnet hos We❤️Apple. Og hvis du er nysgerrig på udvikler-vinklen—fra Xcode til builds—har vi også løbende stof om Xcode.

Hvis 16 agenter kan nå 100.000 linjer på to uger, kan du måske nøjes med én rigtig god maskine—og lidt mindre drama i din build-tid.

Se MacBook til udvikling →

Hurtig levering og officiel Apple-garanti

Den stille bagside: korrekthed, sikkerhed og tillid

En compiler er ikke bare “software”—den er et stykke infrastruktur, der kan indføre fejl og sårbarheder på den mest ubehagelige måde: uden at nogen opdager det. Derfor er modenhed, review-kultur og teststrategi vigtigere end “wow, det bootede”. Når man samtidig bruger et multi-agent-system, stiger risikoen for inkonsistens, kopierede mønstre og små afvigelser i antagelser—klassiske steder, hvor bugs gemmer sig.

Det er også her, Apple-mentaliteten faktisk er relevant: stramme toolchains, deterministiske builds, og en kultur hvor regressioner bliver slået ned hurtigt. Uanset om du deployer til iPhone med A17 Pro, til iPad, eller til Mac mini, er det de kedelige processer, der skaber stabilitet—ikke den spændende demo.

Kort sagt: Ja, det er imponerende, at en Rust-baseret compiler kan bygges så hurtigt med 16 Claude-agenter. Men den egentlige historie er, at “AI-agenter” ikke fjerner software-ingeniørarbejdet—de flytter det op et niveau, hvor din evne til at specificere, begrænse og validere bliver vigtigere end nogensinde.