Sixteen AI agents built a C compiler together — why that matters (and what it doesn't mean yet)

Antraštė, pavyzdžiui, „šešiolika dirbtinio intelekto agentų sukūrė C kompiliatorių“, skamba kaip magiškas triukas arba mokslinės fantastikos siužeto pradžia. Iš tikrųjų tai yra kai kas įdomesnio: žvilgsnis į tai, kaip keičiasi programinės įrangos inžinerija, kai dirbtinio intelekto modelį galima traktuoti ne kaip pokalbių partnerį, o kaip...darbo jėga– pusiau nepriklausomų agentų rinkinys, galintis planuoti, dalytis užduotimis, rašyti kodą, peržiūrėti vienas kitą ir iteruoti.

Šiame įraše analizuojama, kas yra C kompiliatorius, ko reikia jam sukurti, kaip praktiškai atrodo „daugiaagentis“ darbas ir kokius projektus šios sistemos greičiausiai palengvins (ir kuriuos iš jų atkakliai teks atlikti).

Kas yra kompiliatorius, paprastai tariant?

Kompiliatorius yra programa, kuri verčia jūsų parašytą kodą (pvz.šaltinio kalba) į formą, kurią kompiuteris gali vykdyti (atikslinė kalba, dažnai mašininis kodas). Tačiau „vertimas“ yra per mažai pasakyta. Gamybos kompiliatorius taip pat turi:

Atmesti netinkamas programas(ir paaiškinkite, kodėl, geriausia pateikdami naudingus klaidų pranešimus).
Įgyvendinti kalbos taisykles(tipai, apimtis, atminties modelio taisyklės, neapibrėžti elgesio apribojimai).
Optimizuotikodą, kad jis veiktų greitai ir naudotų mažiau atminties.
Taikyti į kelis procesorius ir operacines sistemas(x86‑64, ARM64, RISC‑V; „Linux“, „macOS“, „Windows“; įterptosios paskirties sistemos).
Integruoti su įrankių grandinėmis: susiejikliai, asembleriai, derinimo programos, kompiliavimo sistemos.

Naudingas mentalinis modelis yra tas, kad kompiliatorius yra ne vienas dalykas, o konvejeris:

Leksingas: paverskite veikėjus žetonais.
Analizė: paverskite žetonus struktūrizuotu sintaksės medžiu.
Semantinė analizė: išspręsti pavadinimus, tipus ir taisykles, kurie nėra matomi vien iš sintaksės.
Tarpinis atstovavimas (IR): transformuoti programą į „kompiliatoriui patogią“ formą.
Optimizavimas: pagerinti IR.
Kodo generavimas: skleisti mašininį kodą (arba kitą tikslinę kalbą).

Tai „vadovėlinis“ požiūris. Inžinerinis požiūris prideda našumą, atkuriamumą, saugumo stiprinimą, diagnostiką ir begalinę realaus pasaulio kodų bazių realybę, naudojant kiekvieną kalbos kampelį.

Kodėl C yra žiaurus taikinys

PastatasaKompiliatorius yra sudėtingas. SukurtiCKompiliatorius yra ypatinga sudėtingumo rūšis, nes C kalboje yra:

Didelis „aštrių briaunų“ paviršius (rodyklės, rankinis atminties valdymas).
Ilga kompiliatoriaus priklausomo elgesio istorija.
Specifikacija, pilnaneapibrėžtas elgesys— atvejai, kai kalba sąmoningai nenurodo, kas vyksta.

Neapibrėžtas elgesys nėra vien akademinis. Tai sutartis: kompiliatorius gali manyti, kad neapibrėžtas elgesys niekada nevyksta, o tai leidžia optimizuoti, bet kartu sukuria spąstų, kai tikras kodas netyčia jį suaktyvina.

AC kompiliatorius, kuris yrašiek tiek neteisinganėra „dažniausiai geras“; jis gali generuoti šiek tiek neteisingus dvejetainius failus, kurie neveikia tik esant tam tikriems optimizavimo lygiams, tam tikriems procesoriams arba tam tikroms įvesties reikšmėms. Štai kodėl kompiliatorių testavimas yra toks intensyvus: reikia daugybės programų rinkinių, supaprastinimo, diferencialinio testavimo su žinomais kompiliatoriais (pvz., GCC/Clang) ir realaus pasaulio kompiliavimo aprėpties.

Taigi, ką reiškia, kad „šešiolika agentų“ jį pastatė?

Pagrindinė idėja ne ta, kad vienas modelis per naktį tapo išmanesnis. Tai ta, kad darbo eiga tapo labiau struktūrizuota.

Kelių agentų sąranka paprastai atrodo taip:

Aplanuotojas / vadybininkas agentassuskirsto projektą į modulius ir etapus.
Įgyvendinimo agentairašyti kodą konkrečioms posistemėms (lekseriui, analizatoriui, IR, kodo generavimui, testams).
Recenzentų agentaikritikuoti projektus ir patikrinti, ar nėra loginių spragų.
Abandymo / pūkelių agentaskuria testus ir ieško klaidų.
Adokumentacijos agentasrašo naudojimo dokumentus ir pavyzdžius.

Jei kada nors dirbote su kompiliatoriaus projektu, tai turėtų atrodyti pažįstama – tai atspindi, kaip veikia žmonių komandos. Skirtumas tas, kad galite akimirksniu pasitelkti „komandos draugus“, ir jie nori sunkiai dirbti pasikartojantį darbą be nuovargio.

Tačiau nepainiokite to su garantuota kokybe. Daugiagentės sistemos vis tiek gali:

Sukurkite kodą, kurisatrodo įtikinamaibet yra neteisus.
Praleisti kraštutinius atvejus.
„Užstrigkite“ vietinėje optimoje (projekte, kuris kompiliuojasi, bet negali būti išplėstas).
Per didelis pritaikymas testų rinkiniui (testų išlaikymas netinkamai įdiegus kalbą).

Ką siūlo šis metodasparalelizmasiriteracijos greitisJei žmonių komandai pirmajam posistemės prototipui sukurti prireiktų savaitės, tai daugiaagentė sistema per dieną galėtų sukurti kelis alternatyvius prototipus – tuomet jūs pasirenkate geriausią kryptį.

Tikrasis etapas: integracija, o ne generavimas

Dauguma žmonių įsivaizduoja dirbtinio intelekto kodavimo pažangą kaip „galinčią parašyti daugiau kodo eilučių“. Kompiliatoriams kodo eilutės nėra kliūtis. Kliūtis yraintegracija:

Ar lekseris ir analizatorius sutaria dėl tokenizavimo taisyklių?
Ar semantiniai patikrinimai sukuria nuoseklias, veiksmingus klaidas?
Ar IR išsaugo įvesties programos semantiką?
Ar optimizavimas išsaugo elgseną nepakitusią per neapibrėžtas elgsenos ribas?
Ar jis gali sukompiliuoti dideles realaus pasaulio kodų bazes nesugadindamas laiko limito ir neišeikvodamas atminties?

Daugiafunkcinė komanda, galinti išlaikyti šias dalis darnias, daro kažką kokybiškai kitokio nei modelis, galintis sugeneruoti tvarkingą analizatoriaus fragmentą.

Kaip sužinoti, ar kompiliatorius yra „tikras“

Yra keletas lakmuso testelių, kurie skiria „tvarkingą demonstracinę versiją“ nuo „kompiliatoriaus, kuriuo galite pasitikėti darbe“:

Savarankiškas talpinimasAr kompiliatorius gali pats save kompiliuoti?
C standarto atitiktisAr jis praeina žinomus testų rinkinius?
Diferencinis testavimasAr rezultatai atitinka GCC/Clang dideliuose atsitiktinių imčių testų rinkiniuose?
Derinimo galimybėsAr jis gali generuoti simbolius ir bendradarbiauti su derinimo programomis?
Tikslinis plotisAr jis palaiko daugiau nei vieną procesorių / platformą?

Daugelis ankstyvųjų kompiliatorių istorijoje buvo „tikri“ dar gerokai prieš tai, kai tapo gamybinės klasės, todėl naują kompiliatorių galima vadinti tikru, net jei jis dar nėra paruoštas branduolio kompiliavimui. Tačiau atstumas nuo „gali kompiliuoti mažas C programas“ iki „yra saugus gamybinei aplinkai“ yra milžiniškas.

Kodėl tai svarbu, net jei niekada nenaudojate to kompiliatoriaus

Įdomi išvada yra ne ta, kad „DI pakeitė kompiliatorių inžinierius“. Bet tai, kadkompiliatoriaus inžinerijatampa prieinamesniu eksperimentų taikiniu.

Istoriškai kompiliatoriaus darbas turi didelę aktyvacijos energiją:

Jums reikia gilių kalbos dizaino ir semantikos žinių.
Jums reikia daug pastolių: analizatorių, IR infrastruktūros, bandymų laidai.
Tau reikia laiko.

Jei daugiaagentės priemonės gali sugeneruoti ir palaikyti didelę dalį šių pastolių, daugiau žmonių gali ištirti:

Nišinės kalbos (konkrečioms sritims skirtos kalbos, įterptųjų scenarijų kalbos).
Alternatyvios kompiliatorių architektūros.
Saugos ir tikrinimo įrankiai (pvz., kompiliatoriai su integruotu valymu).
Kompiliatorių įrankiai: automatiniai klaidų minimizatoriai, testų atvejų generatoriai, regresinės sistemos.

Tai panašu į tai, kas nutiko, kai subrendo žiniatinklio sistemos: nustojote rašyti neapdorotus lizdų serverius ir pradėjote kurti aukštesnio lygio dalis. Tai nepanaikino vidinės inžinerijos; ji ją pakeitė.

Paslėptos išlaidos: patikimumas ir kilmė

Viena iš priežasčių, kodėl kompiliatoriai yra jautrūs, yra ta, kad jie yra programinės įrangos pagrindas. Jei nepasitikite savo kompiliatoriumi, nepasitikite ir dvejetainiu failu. Tai iškelia du neatidėliotinus klausimus dirbtinio intelekto padedamiems kompiliatorių projektams:

KilmėKas parašė kurias dalis? Kokį modelį? Kokie raginimai? Kokios žmonių peržiūros buvo atliktos?
SaugumasKaip užtikrinate, kad nebūtų atsitiktinai (arba dėl pažeistos priklausomybės) atsiradusių subtilių užpakalinių durų ar pažeidžiamumų?

Taip pat yra klasikinė „pasitikėjimo pasitikėjimu“ problema: kompiliatorius, pats kompiliuodamas, gali įterpti kenkėjišką elgseną į išvesties duomenis. Šiuolaikinės įrankių grandinės šią problemą išsprendžia naudodamos tokias technikas kaip įvairus dvigubas kompiliavimas ir atkuriamos versijos, o dirbtinio intelekto generuojamas kodas greičiausiai padidins spaudimą plačiau taikyti šią praktiką.

Kokiose daugiaagentio kodavimo srityse greičiausiai bus gerai toliau

Daugiafunkcinės sistemos puikiai veikia, kai:

Darbą galima suskirstyti į modulius.
Yra aiškios sąsajos.
Yra greitas grįžtamasis ryšys (testai, lyginamieji testai, patikros).

Kompiliatoriai puikiai tinka: jie yra moduliniai, valdomi sąsajos ir testuojami.

Kita banga greičiausiai atrodys taip:

Agentų valdomas perkėlimas„ARM64 Windows palaikymas“ tampa struktūrizuotų užduočių seka.
Automatinės diagnostikos patobulinimas: generuoti ir patvirtinti geresnius klaidų pranešimus.
Pūkuotuko + fiksatoriaus kilposagentai, kurie generuoja neveikiančias programas, jas sumažina ir siūlo pataisymus.
IR tyrinėjimas: alternatyvių optimizavimo etapų generavimas ir teisingumo / našumo matavimas.

Ką tai daronereiškia (kol kas)

Tai nereiškia:

Kiekviena didelė programinės įrangos sistema gali būti sukurta „sukuriant agentus“.
Specifikacijos darbą galite praleisti.
Galite ignoruoti testus.
Saugumas ir priežiūra yra išspręsti.

Kompiliatorius yra puikus demonstracinis taikinys, nes teisingumą galima išmatuoti, o projektas yra ribotas. Tikrosios techninės programinės įrangos problemos dažnai yra neribotos: netvarkingi reikalavimai, UX kompromisai, ilgos integracijos ir žmonių koordinavimas.

Esmė

Dirbtinio intelekto agentų komanda, sukurianti veikiantį C kompiliatorių, yra reikšmingas etapas – ne todėl, kad kompiliatoriai staiga tapo paprasti, o todėl, kad tai rodo darbo eigos pokytį:Dirbtinis intelektas kaip koordinuota inžinierių komandao ne vienos automatinio užbaigimo smegenys. Ilgas kelias išlieka pasitikėjimas, testavimas ir integracija su realaus pasaulio įrankių grandinėmis, tačiau kryptis aiški: daugiau programinės įrangos bus kuriama derinant sistemas, o ne tik rašant kodą.

Šaltiniai

Document Title
Sixteen AI agents built a C compiler together — why that matters (and what it doesn't mean yet)	Šešiolika dirbtinio intelekto agentų kartu sukūrė C kompiliatorių – kodėl tai svarbu (ir ko tai dar nereiškia)

A practical explainer of what it means for a team of AI agents to design, implement, and validate a new C compiler — and the hard engineering realities that still apply.	Praktinis paaiškinimas, ką reiškia dirbtinio intelekto agentų komandai sukurti, įdiegti ir patvirtinti naują C kompiliatorių, ir kokios griežtos inžinerijos realijos vis dar galioja.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Abdul Jabbar	Peržiūrėti visus Abdul Jabbar įrašus
Zuckerberg’s unsealed email raises an uncomfortable question: should platforms study their harms less?	Atvirai paskelbtas Zuckerbergo el. laiškas kelia nemalonų klausimą: ar platformos turėtų mažiau tyrinėti savo daromą žalą?
Waymo and the rise of “world models” for driving: what a Genie-style simulator changes	„Waymo“ ir „pasaulio modelių“ vairavimui iškilimas: ką keičia „Genie“ stiliaus simuliatorius
Page Content
Sixteen AI agents built a C compiler together — why that matters (and what it doesn't mean yet)	Šešiolika dirbtinio intelekto agentų kartu sukūrė C kompiliatorių – kodėl tai svarbu (ir ko tai dar nereiškia)
Blog
Sixteen AI agents built a C compiler together — why that matters (and what it doesn’t mean yet)	Šešiolika dirbtinio intelekto agentų kartu sukūrė C kompiliatorių – kodėl tai svarbu (ir ko tai dar nereiškia)
/
General
/ By
Abdul Jabbar
A headline like “sixteen AI agents built a C compiler” sounds like either a magic trick or the start of a sci‑fi plot. In reality, it’s something more interesting: a glimpse of how software engineering is changing when you can treat an AI model not as a chat partner, but as a	Antraštė, pavyzdžiui, „šešiolika dirbtinio intelekto agentų sukūrė C kompiliatorių“, skamba kaip magiškas triukas arba mokslinės fantastikos siužeto pradžia. Iš tikrųjų tai yra kai kas įdomesnio: žvilgsnis į tai, kaip keičiasi programinės įrangos inžinerija, kai dirbtinio intelekto modelį galima traktuoti ne kaip pokalbių partnerį, o kaip...
workforce
— a set of semi‑independent agents that can plan, divide tasks, write code, review one another, and iterate.	– pusiau nepriklausomų agentų rinkinys, galintis planuoti, dalytis užduotimis, rašyti kodą, peržiūrėti vienas kitą ir iteruoti.
This post breaks down what a C compiler is, what it takes to build one, what “multi‑agent” work actually looks like in practice, and what kinds of projects these systems are likely to make easier (and which ones will stay stubbornly hard).	Šiame įraše analizuojama, kas yra C kompiliatorius, ko reikia jam sukurti, kaip praktiškai atrodo „daugiaagentis“ darbas ir kokius projektus šios sistemos greičiausiai palengvins (ir kuriuos iš jų atkakliai teks atlikti).
What is a compiler, in plain terms?	Kas yra kompiliatorius, paprastai tariant?
A compiler is a program that translates code you write (a	Kompiliatorius yra programa, kuri verčia jūsų parašytą kodą (pvz.
source language
) into a form a computer can execute (a	) į formą, kurią kompiuteris gali vykdyti (a
target language
, often machine code). But “translation” is an understatement. A production compiler also has to:	, dažnai mašininis kodas). Tačiau „vertimas“ yra per mažai pasakyta. Gamybos kompiliatorius taip pat turi:
Reject invalid programs
(and explain why, ideally with useful error messages).	(ir paaiškinkite, kodėl, geriausia pateikdami naudingus klaidų pranešimus).
Enforce language rules
(types, scope, memory model rules, undefined behavior constraints).	(tipai, apimtis, atminties modelio taisyklės, neapibrėžti elgesio apribojimai).
Optimize
code so it runs fast and uses less memory.	kodą, kad jis veiktų greitai ir naudotų mažiau atminties.
Target multiple CPUs and operating systems	Taikyti į kelis procesorius ir operacines sistemas
(x86‑64, ARM64, RISC‑V; Linux, macOS, Windows; embedded targets).	(x86‑64, ARM64, RISC‑V; „Linux“, „macOS“, „Windows“; įterptosios paskirties sistemos).
Integrate with toolchains	Integruoti su įrankių grandinėmis
: linkers, assemblers, debuggers, build systems.	: susiejikliai, asembleriai, derinimo programos, kompiliavimo sistemos.
A helpful mental model is that a compiler is not one thing but a pipeline:	Naudingas mentalinis modelis yra tas, kad kompiliatorius yra ne vienas dalykas, o konvejeris:
Lexing
: turn characters into tokens.	: paverskite veikėjus žetonais.
Parsing
: turn tokens into a structured syntax tree.	: paverskite žetonus struktūrizuotu sintaksės medžiu.
Semantic analysis
: resolve names, types, and rules that aren’t visible from syntax alone.	: išspręsti pavadinimus, tipus ir taisykles, kurie nėra matomi vien iš sintaksės.
Intermediate representation (IR)
: transform the program into a “compiler friendly” form.	: transformuoti programą į „kompiliatoriui patogią“ formą.
Optimization
: improve the IR.
Code generation
: emit machine code (or another target language).	: skleisti mašininį kodą (arba kitą tikslinę kalbą).
That’s the “textbook” view. The engineering view adds build performance, reproducibility, security hardening, diagnostics, and the endless reality of real‑world codebases using every corner of the language.	Tai „vadovėlinis“ požiūris. Inžinerinis požiūris prideda našumą, atkuriamumą, saugumo stiprinimą, diagnostiką ir begalinę realaus pasaulio kodų bazių realybę, naudojant kiekvieną kalbos kampelį.
Why C is a brutal target
Building
a
compiler is hard. Building a	Kompiliatorius yra sudėtingas. Sukurti
C
compiler is a special kind of hard because C contains:	Kompiliatorius yra ypatinga sudėtingumo rūšis, nes C kalboje yra:
A large surface of “sharp edges” (pointers, manual memory management).	Didelis „aštrių briaunų“ paviršius (rodyklės, rankinis atminties valdymas).
A long history of compiler‑dependent behavior.	Ilga kompiliatoriaus priklausomo elgesio istorija.
A specification full of
undefined behavior
— cases where the language deliberately doesn’t specify what happens.	— atvejai, kai kalba sąmoningai nenurodo, kas vyksta.
Undefined behavior is not just academic. It’s a contract: the compiler is allowed to assume undefined behavior never happens, which enables optimizations — and also creates pitfalls when real code accidentally triggers it.	Neapibrėžtas elgesys nėra vien akademinis. Tai sutartis: kompiliatorius gali manyti, kad neapibrėžtas elgesys niekada nevyksta, o tai leidžia optimizuoti, bet kartu sukuria spąstų, kai tikras kodas netyčia jį suaktyvina.
A C compiler that is
slightly wrong
isn’t “mostly fine”; it can generate subtly incorrect binaries that only fail in certain optimization levels, certain CPUs, or under certain inputs. This is why compiler testing is so intense: you need vast suites, fuzzing, differential testing against known compilers (like GCC/Clang), and real‑world build coverage.	nėra „dažniausiai geras“; jis gali generuoti šiek tiek neteisingus dvejetainius failus, kurie neveikia tik esant tam tikriems optimizavimo lygiams, tam tikriems procesoriams arba tam tikroms įvesties reikšmėms. Štai kodėl kompiliatorių testavimas yra toks intensyvus: reikia daugybės programų rinkinių, supaprastinimo, diferencialinio testavimo su žinomais kompiliatoriais (pvz., GCC/Clang) ir realaus pasaulio kompiliavimo aprėpties.
So what does it mean that “sixteen agents” built one?	Taigi, ką reiškia, kad „šešiolika agentų“ jį pastatė?
The key idea isn’t that a single model got smarter overnight. It’s that the workflow got more structured.	Pagrindinė idėja ne ta, kad vienas modelis per naktį tapo išmanesnis. Tai ta, kad darbo eiga tapo labiau struktūrizuota.
A multi‑agent setup typically looks like this:	Kelių agentų sąranka paprastai atrodo taip:
A
planner/manager agent	planuotojas / vadybininkas agentas
breaks down the project into modules and milestones.	suskirsto projektą į modulius ir etapus.
Implementer agents
write code for specific subsystems (lexer, parser, IR, codegen, tests).	rašyti kodą konkrečioms posistemėms (lekseriui, analizatoriui, IR, kodo generavimui, testams).
Reviewer agents
critique designs and check for logic gaps.	kritikuoti projektus ir patikrinti, ar nėra loginių spragų.
test/fuzz agent
creates test cases and looks for failures.	kuria testus ir ieško klaidų.
documentation agent
writes usage docs and examples.	rašo naudojimo dokumentus ir pavyzdžius.
If you’ve ever worked on a compiler project, this should feel familiar — it mirrors how human teams work. The change is that you can spin up “teammates” instantly, and they’re willing to grind through repetitive work without fatigue.	Jei kada nors dirbote su kompiliatoriaus projektu, tai turėtų atrodyti pažįstama – tai atspindi, kaip veikia žmonių komandos. Skirtumas tas, kad galite akimirksniu pasitelkti „komandos draugus“, ir jie nori sunkiai dirbti pasikartojantį darbą be nuovargio.
But don’t confuse that with guaranteed quality. Multi‑agent systems can still:	Tačiau nepainiokite to su garantuota kokybe. Daugiagentės sistemos vis tiek gali:
Produce code that
looks plausible
but is wrong.
Miss edge cases.	Praleisti kraštutinius atvejus.
Get “stuck” in local optima (a design that compiles but can’t be extended).	„Užstrigkite“ vietinėje optimoje (projekte, kuris kompiliuojasi, bet negali būti išplėstas).
Overfit to a test suite (passing tests without correctly implementing the language).	Per didelis pritaikymas testų rinkiniui (testų išlaikymas netinkamai įdiegus kalbą).
What the approach does offer is
parallelism
and
iteration speed
. If a human team might take a week to produce a first prototype of a subsystem, a multi‑agent setup might produce several alternative prototypes in a day — then you pick the best direction.	Jei žmonių komandai pirmajam posistemės prototipui sukurti prireiktų savaitės, tai daugiaagentė sistema per dieną galėtų sukurti kelis alternatyvius prototipus – tuomet jūs pasirenkate geriausią kryptį.
The real milestone: integration, not generation	Tikrasis etapas: integracija, o ne generavimas
Most people imagine AI coding progress as “it can write more lines of code.” For compilers, lines of code are not the bottleneck. The bottleneck is	Dauguma žmonių įsivaizduoja dirbtinio intelekto kodavimo pažangą kaip „galinčią parašyti daugiau kodo eilučių“. Kompiliatoriams kodo eilutės nėra kliūtis. Kliūtis yra
integration
:
Do the lexer and parser agree on tokenization rules?	Ar lekseris ir analizatorius sutaria dėl tokenizavimo taisyklių?
Do semantic checks produce consistent, actionable errors?	Ar semantiniai patikrinimai sukuria nuoseklias, veiksmingus klaidas?
Does the IR preserve the semantics of the input program?	Ar IR išsaugo įvesties programos semantiką?
Do optimizations keep behavior intact across undefined‑behavior boundaries?	Ar optimizavimas išsaugo elgseną nepakitusią per neapibrėžtas elgsenos ribas?
Can it compile large real‑world codebases without timing out or blowing memory?	Ar jis gali sukompiliuoti dideles realaus pasaulio kodų bazes nesugadindamas laiko limito ir neišeikvodamas atminties?
A multi‑agent team that can keep these parts coherent is doing something qualitatively different from a model that can generate a neat parser snippet.	Daugiafunkcinė komanda, galinti išlaikyti šias dalis darnias, daro kažką kokybiškai kitokio nei modelis, galintis sugeneruoti tvarkingą analizatoriaus fragmentą.
How you can tell whether the compiler is “real”	Kaip sužinoti, ar kompiliatorius yra „tikras“
There are a few litmus tests that separate “a neat demo” from “a compiler you can trust for work”:	Yra keletas lakmuso testelių, kurie skiria „tvarkingą demonstracinę versiją“ nuo „kompiliatoriaus, kuriuo galite pasitikėti darbe“:
Self‑hosting
: can the compiler compile itself?	Ar kompiliatorius gali pats save kompiliuoti?
C standard conformance
: does it pass known test suites?	Ar jis praeina žinomus testų rinkinius?
Differential testing
: do outputs match GCC/Clang across huge randomized test sets?	Ar rezultatai atitinka GCC/Clang dideliuose atsitiktinių imčių testų rinkiniuose?
Debuggability
: can it produce symbols and cooperate with debuggers?	Ar jis gali generuoti simbolius ir bendradarbiauti su derinimo programomis?
Target breadth
: does it support more than one CPU / platform?	Ar jis palaiko daugiau nei vieną procesorių / platformą?
Many early compilers in history were “real” long before they were production grade — so it’s fair to call a new compiler real even if it’s not ready for your kernel build yet. But the distance from “can compile small C programs” to “is safe for production” is enormous.	Daugelis ankstyvųjų kompiliatorių istorijoje buvo „tikri“ dar gerokai prieš tai, kai tapo gamybinės klasės, todėl naują kompiliatorių galima vadinti tikru, net jei jis dar nėra paruoštas branduolio kompiliavimui. Tačiau atstumas nuo „gali kompiliuoti mažas C programas“ iki „yra saugus gamybinei aplinkai“ yra milžiniškas.
Why this matters even if you never use that compiler	Kodėl tai svarbu, net jei niekada nenaudojate to kompiliatoriaus
The interesting implication is not “AI replaced compiler engineers.” It’s that	Įdomi išvada yra ne ta, kad „DI pakeitė kompiliatorių inžinierius“. Bet tai, kad
compiler engineering
becomes a more accessible target for experimentation.	tampa prieinamesniu eksperimentų taikiniu.
Historically, compiler work has a high activation energy:	Istoriškai kompiliatoriaus darbas turi didelę aktyvacijos energiją:
You need deep knowledge of language design and semantics.	Jums reikia gilių kalbos dizaino ir semantikos žinių.
You need a lot of scaffolding: parsers, IR infrastructure, test harnesses.	Jums reikia daug pastolių: analizatorių, IR infrastruktūros, bandymų laidai.
You need time.
If multi‑agent tools can generate and maintain much of that scaffolding, then more people can explore:	Jei daugiaagentės priemonės gali sugeneruoti ir palaikyti didelę dalį šių pastolių, daugiau žmonių gali ištirti:
Niche languages (domain‑specific languages, embedded scripting languages).	Nišinės kalbos (konkrečioms sritims skirtos kalbos, įterptųjų scenarijų kalbos).
Alternative compiler architectures.	Alternatyvios kompiliatorių architektūros.
Safety and verification tooling (e.g., compilers with built‑in sanitization).	Saugos ir tikrinimo įrankiai (pvz., kompiliatoriai su integruotu valymu).
Tooling around compilers: auto‑minimizers for bugs, test case generators, regression systems.	Kompiliatorių įrankiai: automatiniai klaidų minimizatoriai, testų atvejų generatoriai, regresinės sistemos.
This is similar to what happened when web frameworks matured: you stopped writing raw socket servers and started composing higher‑level pieces. That didn’t eliminate backend engineering; it shifted it.	Tai panašu į tai, kas nutiko, kai subrendo žiniatinklio sistemos: nustojote rašyti neapdorotus lizdų serverius ir pradėjote kurti aukštesnio lygio dalis. Tai nepanaikino vidinės inžinerijos; ji ją pakeitė.
The hidden cost: trust and provenance	Paslėptos išlaidos: patikimumas ir kilmė
One reason compilers are sensitive is that they sit at the foundation of the software stack. If you don’t trust your compiler, you don’t trust your binary. This creates two immediate questions for AI‑assisted compiler projects:	Viena iš priežasčių, kodėl kompiliatoriai yra jautrūs, yra ta, kad jie yra programinės įrangos pagrindas. Jei nepasitikite savo kompiliatoriumi, nepasitikite ir dvejetainiu failu. Tai iškelia du neatidėliotinus klausimus dirbtinio intelekto padedamiems kompiliatorių projektams:
Provenance
: Who authored which parts? What model? What prompts? What human reviews happened?	Kas parašė kurias dalis? Kokį modelį? Kokie raginimai? Kokios žmonių peržiūros buvo atliktos?
Security
: How do you ensure there isn’t a subtle backdoor or vulnerability introduced by accident (or by a compromised dependency)?	Kaip užtikrinate, kad nebūtų atsitiktinai (arba dėl pažeistos priklausomybės) atsiradusių subtilių užpakalinių durų ar pažeidžiamumų?
There’s also the classic “trusting trust” problem: a compiler could insert malicious behavior into outputs while compiling itself. Modern toolchains mitigate this with techniques like diverse double‑compiling and reproducible builds — and AI‑generated code will likely increase pressure to adopt these practices more broadly.	Taip pat yra klasikinė „pasitikėjimo pasitikėjimu“ problema: kompiliatorius, pats kompiliuodamas, gali įterpti kenkėjišką elgseną į išvesties duomenis. Šiuolaikinės įrankių grandinės šią problemą išsprendžia naudodamos tokias technikas kaip įvairus dvigubas kompiliavimas ir atkuriamos versijos, o dirbtinio intelekto generuojamas kodas greičiausiai padidins spaudimą plačiau taikyti šią praktiką.
What multi‑agent coding is likely to be good at next	Kokiose daugiaagentio kodavimo srityse greičiausiai bus gerai toliau
Multi‑agent systems shine when:	Daugiafunkcinės sistemos puikiai veikia, kai:
The work can be decomposed into modules.	Darbą galima suskirstyti į modulius.
There are clear interfaces.
There’s fast feedback (tests, benchmarks, fuzzers).	Yra greitas grįžtamasis ryšys (testai, lyginamieji testai, patikros).
Compilers fit surprisingly well: they’re modular, interface‑driven, and testable.	Kompiliatoriai puikiai tinka: jie yra moduliniai, valdomi sąsajos ir testuojami.
The next wave is likely to look like:	Kita banga greičiausiai atrodys taip:
Agent‑driven porting
: “support ARM64 Windows” becomes a series of structured tasks.	„ARM64 Windows palaikymas“ tampa struktūrizuotų užduočių seka.
Automated diagnostics improvement	Automatinės diagnostikos patobulinimas
: generate and validate better error messages.	: generuoti ir patvirtinti geresnius klaidų pranešimus.
Fuzzer + fixer loops	Pūkuotuko + fiksatoriaus kilpos
: agents that generate failing programs, minimize them, and propose patches.	agentai, kurie generuoja neveikiančias programas, jas sumažina ir siūlo pataisymus.
IR exploration
: generating alternative optimization passes and measuring correctness/performance.	: alternatyvių optimizavimo etapų generavimas ir teisingumo / našumo matavimas.
What it does
not
mean (yet)
It does not mean:
Every big software system can be created by “spinning up agents.”	Kiekviena didelė programinės įrangos sistema gali būti sukurta „sukuriant agentus“.
You can skip specification work.	Specifikacijos darbą galite praleisti.
You can ignore tests.
Security and maintainability are solved.	Saugumas ir priežiūra yra išspręsti.
A compiler is an excellent demo target because correctness is measurable and the project is bounded. The truly hard software problems are often unbounded: messy requirements, UX tradeoffs, long‑tail integrations, and human coordination.	Kompiliatorius yra puikus demonstracinis taikinys, nes teisingumą galima išmatuoti, o projektas yra ribotas. Tikrosios techninės programinės įrangos problemos dažnai yra neribotos: netvarkingi reikalavimai, UX kompromisai, ilgos integracijos ir žmonių koordinavimas.
Bottom line
A team of AI agents producing a functioning C compiler is a meaningful milestone — not because compilers are suddenly easy, but because it demonstrates a workflow shift:	Dirbtinio intelekto agentų komanda, sukurianti veikiantį C kompiliatorių, yra reikšmingas etapas – ne todėl, kad kompiliatoriai staiga tapo paprasti, o todėl, kad tai rodo darbo eigos pokytį:
AI as a coordinated engineering team	Dirbtinis intelektas kaip koordinuota inžinierių komanda
rather than a single autocomplete brain. The long runway remains trust, testing, and integration with real‑world toolchains, but the direction is clear: more software will be built by orchestrating systems, not just writing code.	o ne vienos automatinio užbaigimo smegenys. Ilgas kelias išlieka pasitikėjimas, testavimas ir integracija su realaus pasaulio įrankių grandinėmis, tačiau kryptis aiški: daugiau programinės įrangos bus kuriama derinant sistemas, o ne tik rašant kodą.
Sources
https://arstechnica.com/ai/2026/02/sixteen-claude-ai-agents-working-together-created-a-new-c-compiler/	https://arstechnica.com/ai/2026/02/sixteen-claude-ai-agents-working-together-created-a-new-c-compiler/
https://en.wikipedia.org/wiki/Compiler	https://lt.wikipedia.org/wiki/Kompiliatorius
https://en.wikipedia.org/wiki/C_(programming_language	https://lt.wikipedia.org/wiki/C_(programavimo_kalba
)
https://clang.llvm.org/
https://gcc.gnu.org/
←
Previous Post
Next Post
→
→ Zuckerberg’s unsealed email raises an uncomfortable question: should platforms study their harms less?	→ Atvirai paskelbtas Zuckerbergo el. laiškas kelia nemalonų klausimą: ar platformos turėtų mažiau tyrinėti savo daromą žalą?
Waymo and the rise of “world models” for driving: what a Genie-style simulator changes ←	„Waymo“ ir vairavimo „pasaulio modelių“ iškilimas: ką keičia „Genie“ stiliaus simuliatorius ←
Copyright © 2026 Rill.blog	Autorių teisės © 2026 Rill.blog
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Abdul Jabbar	Peržiūrėti visus Abdul Jabbar įrašus
Zuckerberg’s unsealed email raises an uncomfortable question: should platforms study their harms less?	Atvirai paskelbtas Zuckerbergo el. laiškas kelia nemalonų klausimą: ar platformos turėtų mažiau tyrinėti savo daromą žalą?
Waymo and the rise of “world models” for driving: what a Genie-style simulator changes	„Waymo“ ir „pasaulio modelių“ vairavimui iškilimas: ką keičia „Genie“ stiliaus simuliatorius
A practical explainer of what it means for a team of AI agents to design, implement, and validate a new C compiler — and the hard engineering realities that still apply.	Praktinis paaiškinimas, ką reiškia dirbtinio intelekto agentų komandai sukurti, įdiegti ir patvirtinti naują C kompiliatorių, ir kokios griežtos inžinerijos realijos vis dar galioja.

Document Title

Sixteen AI agents built a C compiler together — why that matters (and what it doesn't mean yet)

A practical explainer of what it means for a team of AI agents to design, implement, and validate a new C compiler — and the hard engineering realities that still apply.

Title Attribute

oEmbed (JSON)

oEmbed (XML)

JSON

View all posts by Abdul Jabbar

Zuckerberg’s unsealed email raises an uncomfortable question: should platforms study their harms less?

Waymo and the rise of “world models” for driving: what a Genie-style simulator changes

Page Content

Sixteen AI agents built a C compiler together — why that matters (and what it doesn't mean yet)

Blog

Sixteen AI agents built a C compiler together — why that matters (and what it doesn’t mean yet)

General

/ By

Abdul Jabbar

A headline like “sixteen AI agents built a C compiler” sounds like either a magic trick or the start of a sci‑fi plot. In reality, it’s something more interesting: a glimpse of how software engineering is changing when you can treat an AI model not as a chat partner, but as a

workforce

— a set of semi‑independent agents that can plan, divide tasks, write code, review one another, and iterate.

This post breaks down what a C compiler is, what it takes to build one, what “multi‑agent” work actually looks like in practice, and what kinds of projects these systems are likely to make easier (and which ones will stay stubbornly hard).

What is a compiler, in plain terms?

A compiler is a program that translates code you write (a

source language

) into a form a computer can execute (a

target language

, often machine code). But “translation” is an understatement. A production compiler also has to:

Reject invalid programs

(and explain why, ideally with useful error messages).

Enforce language rules

(types, scope, memory model rules, undefined behavior constraints).

Optimize

code so it runs fast and uses less memory.

Target multiple CPUs and operating systems

(x86‑64, ARM64, RISC‑V; Linux, macOS, Windows; embedded targets).

Integrate with toolchains

: linkers, assemblers, debuggers, build systems.

A helpful mental model is that a compiler is not one thing but a pipeline:

Lexing

: turn characters into tokens.

Parsing

: turn tokens into a structured syntax tree.

Semantic analysis

: resolve names, types, and rules that aren’t visible from syntax alone.

Intermediate representation (IR)

: transform the program into a “compiler friendly” form.

Optimization

: improve the IR.

Code generation

: emit machine code (or another target language).

That’s the “textbook” view. The engineering view adds build performance, reproducibility, security hardening, diagnostics, and the endless reality of real‑world codebases using every corner of the language.

Why C is a brutal target

Building

compiler is hard. Building a

compiler is a special kind of hard because C contains:

A large surface of “sharp edges” (pointers, manual memory management).

A long history of compiler‑dependent behavior.

A specification full of

undefined behavior

— cases where the language deliberately doesn’t specify what happens.

Undefined behavior is not just academic. It’s a contract: the compiler is allowed to assume undefined behavior never happens, which enables optimizations — and also creates pitfalls when real code accidentally triggers it.

A C compiler that is

slightly wrong

isn’t “mostly fine”; it can generate subtly incorrect binaries that only fail in certain optimization levels, certain CPUs, or under certain inputs. This is why compiler testing is so intense: you need vast suites, fuzzing, differential testing against known compilers (like GCC/Clang), and real‑world build coverage.

So what does it mean that “sixteen agents” built one?

The key idea isn’t that a single model got smarter overnight. It’s that the workflow got more structured.

A multi‑agent setup typically looks like this:

planner/manager agent

breaks down the project into modules and milestones.

Implementer agents

write code for specific subsystems (lexer, parser, IR, codegen, tests).

Reviewer agents

critique designs and check for logic gaps.

test/fuzz agent

creates test cases and looks for failures.

documentation agent

writes usage docs and examples.

If you’ve ever worked on a compiler project, this should feel familiar — it mirrors how human teams work. The change is that you can spin up “teammates” instantly, and they’re willing to grind through repetitive work without fatigue.

But don’t confuse that with guaranteed quality. Multi‑agent systems can still:

Produce code that

looks plausible

but is wrong.

Miss edge cases.

Get “stuck” in local optima (a design that compiles but can’t be extended).

Overfit to a test suite (passing tests without correctly implementing the language).

What the approach does offer is

parallelism

and

iteration speed

. If a human team might take a week to produce a first prototype of a subsystem, a multi‑agent setup might produce several alternative prototypes in a day — then you pick the best direction.

The real milestone: integration, not generation

Most people imagine AI coding progress as “it can write more lines of code.” For compilers, lines of code are not the bottleneck. The bottleneck is

integration

Do the lexer and parser agree on tokenization rules?

Do semantic checks produce consistent, actionable errors?

Does the IR preserve the semantics of the input program?

Do optimizations keep behavior intact across undefined‑behavior boundaries?

Can it compile large real‑world codebases without timing out or blowing memory?

A multi‑agent team that can keep these parts coherent is doing something qualitatively different from a model that can generate a neat parser snippet.

How you can tell whether the compiler is “real”

There are a few litmus tests that separate “a neat demo” from “a compiler you can trust for work”:

Self‑hosting

: can the compiler compile itself?

C standard conformance

: does it pass known test suites?

Differential testing

: do outputs match GCC/Clang across huge randomized test sets?

Debuggability

: can it produce symbols and cooperate with debuggers?

Target breadth

: does it support more than one CPU / platform?

Many early compilers in history were “real” long before they were production grade — so it’s fair to call a new compiler real even if it’s not ready for your kernel build yet. But the distance from “can compile small C programs” to “is safe for production” is enormous.

Why this matters even if you never use that compiler

The interesting implication is not “AI replaced compiler engineers.” It’s that

compiler engineering

becomes a more accessible target for experimentation.

Historically, compiler work has a high activation energy:

You need deep knowledge of language design and semantics.

You need a lot of scaffolding: parsers, IR infrastructure, test harnesses.

You need time.

If multi‑agent tools can generate and maintain much of that scaffolding, then more people can explore:

Niche languages (domain‑specific languages, embedded scripting languages).

Alternative compiler architectures.

Safety and verification tooling (e.g., compilers with built‑in sanitization).

Tooling around compilers: auto‑minimizers for bugs, test case generators, regression systems.

This is similar to what happened when web frameworks matured: you stopped writing raw socket servers and started composing higher‑level pieces. That didn’t eliminate backend engineering; it shifted it.

The hidden cost: trust and provenance

One reason compilers are sensitive is that they sit at the foundation of the software stack. If you don’t trust your compiler, you don’t trust your binary. This creates two immediate questions for AI‑assisted compiler projects:

Provenance

: Who authored which parts? What model? What prompts? What human reviews happened?

Security

: How do you ensure there isn’t a subtle backdoor or vulnerability introduced by accident (or by a compromised dependency)?

There’s also the classic “trusting trust” problem: a compiler could insert malicious behavior into outputs while compiling itself. Modern toolchains mitigate this with techniques like diverse double‑compiling and reproducible builds — and AI‑generated code will likely increase pressure to adopt these practices more broadly.

What multi‑agent coding is likely to be good at next

Multi‑agent systems shine when:

The work can be decomposed into modules.

There are clear interfaces.

There’s fast feedback (tests, benchmarks, fuzzers).

Compilers fit surprisingly well: they’re modular, interface‑driven, and testable.

The next wave is likely to look like:

Agent‑driven porting

: “support ARM64 Windows” becomes a series of structured tasks.

Automated diagnostics improvement

: generate and validate better error messages.

Fuzzer + fixer loops

: agents that generate failing programs, minimize them, and propose patches.

IR exploration

: generating alternative optimization passes and measuring correctness/performance.

What it does

not

mean (yet)

It does not mean:

Every big software system can be created by “spinning up agents.”

You can skip specification work.

You can ignore tests.

Security and maintainability are solved.

A compiler is an excellent demo target because correctness is measurable and the project is bounded. The truly hard software problems are often unbounded: messy requirements, UX tradeoffs, long‑tail integrations, and human coordination.

Bottom line

A team of AI agents producing a functioning C compiler is a meaningful milestone — not because compilers are suddenly easy, but because it demonstrates a workflow shift:

AI as a coordinated engineering team

rather than a single autocomplete brain. The long runway remains trust, testing, and integration with real‑world toolchains, but the direction is clear: more software will be built by orchestrating systems, not just writing code.

Sources

https://arstechnica.com/ai/2026/02/sixteen-claude-ai-agents-working-together-created-a-new-c-compiler/

https://en.wikipedia.org/wiki/Compiler

https://en.wikipedia.org/wiki/C_(programming_language

)

https://clang.llvm.org/

https://gcc.gnu.org/

←

→

→ Zuckerberg’s unsealed email raises an uncomfortable question: should platforms study their harms less?

Waymo and the rise of “world models” for driving: what a Genie-style simulator changes ←

oEmbed (JSON)

oEmbed (XML)

JSON

View all posts by Abdul Jabbar

Zuckerberg’s unsealed email raises an uncomfortable question: should platforms study their harms less?

Waymo and the rise of “world models” for driving: what a Genie-style simulator changes

A practical explainer of what it means for a team of AI agents to design, implement, and validate a new C compiler — and the hard engineering realities that still apply.

Document Title
Page not found - Rill.blog
Image Alt
Rill.blog
Title Attribute
Rill.blog » Feed
RSD
Skip to content
Placeholder Attribute
Search...
Email address
Page Content
Page not found - Rill.blog
Skip to content
Home
Read Now
Urdu Novels
Mukhtasar Kahanian
Urdu Columns
Main Menu
This page doesn't seem to exist.
It looks like the link pointing here was faulty. Maybe try searching?	Panašu, kad nuoroda čia buvo klaidinga. Gal paskaityti paieškoti?
Search for:
Search
Get all the latest news and info sent to your inbox.	gauti visas naujausias naujienas ir informaciją tiesiai į savo el. pašto dėžutę.
Please enable JavaScript in your browser to complete this form.	pašalini šią formą, įjunkite „JavaScript“ savo naršyklėje.
Email
*
Subscribe
Categories
Copyright © 2025 Rill.blog	Autorių teisės © 2025 Rill.blog
English
العربية
Čeština
Dansk
Nederlands
Eesti
Suomi
Français
Deutsch
Ελληνικά
Magyar
Bahasa Indonesia
Italiano
日本語
한국어
Latviešu valoda
Lietuvių kalba
Norsk bokmål
Polski
Português
Română
Русский
Slovenčina
Slovenščina
Español
Svenska
ไทย
Türkçe
Українська
Tiếng Việt
Notifications
Rill.blog
Rill.blog » Feed
RSD
Search...
Email address

Document Title

Page not found - Rill.blog

Image Alt

Rill.blog

Title Attribute

Rill.blog » Feed

RSD

Placeholder Attribute

Search...

Email address

Page Content

Page not found - Rill.blog

Home

Read Now

Urdu Novels

Mukhtasar Kahanian

Urdu Columns

Main Menu

This page doesn't seem to exist.

It looks like the link pointing here was faulty. Maybe try searching?

Search for:

Get all the latest news and info sent to your inbox.

Please enable JavaScript in your browser to complete this form.

Kas yra kompiliatorius, paprastai tariant?

Kodėl C yra žiaurus taikinys

Taigi, ką reiškia, kad „šešiolika agentų“ jį pastatė?

Tikrasis etapas: integracija, o ne generavimas

Kaip sužinoti, ar kompiliatorius yra „tikras“

Kodėl tai svarbu, net jei niekada nenaudojate to kompiliatoriaus

Paslėptos išlaidos: patikimumas ir kilmė

Kokiose daugiaagentio kodavimo srityse greičiausiai bus gerai toliau

Ką tai daronereiškia (kol kas)

Esmė

Šaltiniai

gauti visas naujausias naujienas ir informaciją tiesiai į savo el. pašto dėžutę.