Eenvoudige tools, zelfsturende ontwikkeling: hoe Muse zichzelf bouwt

TL;DR Muse vervangt op maat gemaakte consoles voor agentorkestratie door vier tools die elk softwareteam al open heeft staan: Slack, Linear, GitHub en Claude Code. Geen dashboard, geen SPA, geen door mensen geschreven code. Elke PR doorstaat zeven CI-gates en een AI-reviewpanel met drie persona's onder een mergebeleid van nul bevindingen. 40,000 stemmen verzameld, foundation-model-evaluatie 80% sneller.

Muse, kort voor Meshy Universal System for Evaluation, is ons interne platform voor modelevaluatie. Teams bij Meshy gebruiken het dagelijks om te bepalen of nieuwe modelcheckpoints beter presteren dan oude.

Op een dag was een veelbelovend nieuw modelcheckpoint net klaar. Het had een arena-match nodig om de volgende trainingsstrategie te bepalen. Het team ontdekte dat ze een nieuwe Muse-functie nodig hadden om dit te ondersteunen.

"@Linear maak een Muse-issue hierover aan"

zei de Product Manager op Slack.

Een minuut later was Linear-issue MES-12345 aangemaakt.

De eigenaar van het Muse-platform — ik dus — zag de issue. Die moest zo snel mogelijk worden uitgerold om de evaluatietaak te ontblokkeren. Toen werd het volgende bericht naar Claude gestuurd:

"Onderzoek en los MES-12345 op"

Claude bekeek de issue en bracht twee ontwerpbeslissingen naar boven. Er werden beslissingen genomen, en ik liep weg van de terminal om aan iets anders te werken.

Anderhalf uur later was een nieuwe versie van Muse uitgerold. Klaar.

Autonome software-engineering hoeft geen chique consoles voor agentorkestratie of dashboards te zijn. En in dit artikel leg ik uit hoe we dit mogelijk hebben gemaakt.

Een galerij, een viewer en een stemknop

De vraag die Muse beantwoordt is bedrieglijk lastig: is het nieuwe modelcheckpoint daadwerkelijk beter? Natuurlijk zijn er kwantitatieve metrics om bij te houden in elke trainingsrun, maar die geven lang niet nauwkeurig weer hoe "goed" eruitziet bij 3D-generatie. Daarom doet Muse het simpele maar effectieve: dubbelblinde tests. De outputs van twee modellen worden naast elkaar gezet, met dezelfde inputafbeelding, willekeurig links of rechts geplaatst, waarna teamgenoten blind stemmen.

Een evaluatie is een batch van dit soort paren. Iemand wijst Muse op twee sets gegenereerde meshes en een map met referentieafbeeldingen, en de app neemt het daarna over: het koppelt de modellen, blindeert de toewijzing en presenteert steeds één vergelijking tegelijk. Stemmen stapelen zich op zodra mensen een vrij momentje hebben. De hele interface is ontworpen om laagdrempelig te zijn, en is bijna volledig te bedienen met sneltoetsen. Een stemmer die naar de muis moet reiken, stemt minder.

De stem-interface van Muse: twee gegenereerde meshes, dezelfde inputafbeelding, willekeurig links of rechts geplaatst.

Dat is het product. Een galerij, een viewer en een stemknop. Er is niets ingewikkelds aan de functie van Muse, en precies dat maakt het een schone case study. Wat ongebruikelijk is, is alleen hoe het gebouwd wordt.

Een architectuur waar agents hun weg in vinden

Het Muse-project ging eind 2025 van start, net toen "vibe coding" een nieuw modewoord was geworden. Naast het ondersteunen van Meshy's groeiende evaluatie-inspanningen in training- en releasecycli, had Muse ook een ambitieus doel: software bouwen voor het hele bedrijf, met nul regels door mensen geschreven code.

Vandaag de dag zijn de resultaten uitstekend:

• Meer dan 40,000 stemmen verzameld sinds de eerste oplevering van Muse, met meer dan 30 evaluatieprojecten per maand
• Meer dan 4 teams die Muse actief gebruiken voor hun dagelijkse werk
• Eerste interne codebase waaraan actief wordt bijgedragen door minstens 1 niet-technisch teamlid
• Eerste interne codebase die volledig autonome ontwikkeling bereikt

Al met al schatten we dat Muse onze foundation-model-evaluatie met minstens 80% heeft versneld en per modelrelease minstens 10 personendagen werk heeft bespaard. Zonder Muse zou het bijna onmogelijk zijn geweest om de huidige ontwikkel- en releasesnelheid van Meshy's collectie generatieve modellen, zoals geometrie, textuur en smart topology, vol te houden.

Vanaf de eerste dag is Muse ontworpen om zo goed mogelijk leesbaar te zijn voor agents. In 2025 merkten we al dat agents bij het implementeren van dezelfde use case op sommige punten moeite hadden, terwijl ze bij andere in één keer slaagden. Veel van deze iteraties resulteerden uiteindelijk in de bewust saaie techstack van vandaag. De backend is Python: FastAPI, Postgres voor records, S3 voor meshes en afbeeldingen. De frontend wordt server-side gerenderd: Jinja2-templates, HTMX voor gedeeltelijke pagina-updates, Tailwind voor styling, en één echt client-side component, de WebGL-3D-viewer die de meshes rendert. Er is geen SPA en geen apart frontend-module. De koppeling tussen de twee stacks is de oudste op het web: de backend rendert HTML, de browser toont het. Wanneer een pagina moet veranderen, vraagt HTMX een fragment op en rendert de server dat ook.

Hier is de architectuur van de kernevaluatie-app in Muse:

De gelaagde architectuur van de kernevaluatie-app van Muse. Afhankelijkheden wijzen alleen naar beneden.

Twee eigenschappen van deze opzet zijn belangrijk voor agents. Ten eerste leeft de frontend-state op de server. De HTML die een gebruiker ziet, is HTML die de backend heeft geproduceerd, zodat een test (of een agent) er direct beweringen over kan doen zonder een client-side framework te moeten aansturen om te reconstrueren wat de gebruiker zag. Ten tweede wordt elke afhankelijkheid machinaal afgedwongen en wijst die alleen naar beneden. Een feature-folder mag zijn sibling niet importeren; als twee features elkaar nodig hebben, injecteert de composition root de ene capability in de andere, zodat de afhankelijkheid in precies één bestand zichtbaar is. Elke laag heeft één taak, en die taken staan opgeschreven op de plek waar een agent er tegenaan zal lopen:

Afhankelijkheden wijzen alleen ooit naar beneden in deze lijst, en die richting wordt afgedwongen door een build-check, niet door een conventie.

Drie extra eigenschappen maken de codebase doelbewust leesbaar voor agents:

• Elke directory heeft zijn eigen documentatie (wat de service doet, de laagregels, de exacte commando's die een merge blokkeren), zodat een agent die er koud instapt zich kan oriënteren zonder te vragen of dingen zelf te verzinnen.
• Niet-triviale modules hebben docstrings met backlinks naar ontwerpdocumenten, zodat de waarom naast de wat bewaard blijft.
• Geen enkel bestand mag meer dan 500 regels bevatten, met een ratelmechanisme voor een paar uitzonderingsgevallen. Voor die uitzonderingen mogen bestanden krimpen, nooit weer groeien. Context windows zijn eindig; de architectuur houdt daar rekening mee.

Voortgang hoort niet in een klein kamertje thuis

Nu LLM-agents veel krachtiger zijn dan in 2025, willen we dat de ontwikkeling van Muse volledig autonoom verloopt. Dat wil zeggen: de mens wijst de agent alleen op de taak. De agent oriënteert zich zelf in de codebase en de taakcontext, werkt zich door de implementatie, CI en codereview heen, en stuurt de pull request uiteindelijk zelf naar de merge. De mens bepaalt alleen de prioriteit van issues en neemt de belangrijke ontwerpbeslissingen.

De eerste gedachte bij volledig autonome ontwikkeling gaat meestal uit naar op maat gemaakte platforms: orkestratieconsoles, agent-native werkruimtes, de ene na de andere app die belooft je vloot te beheren. We hebben gekeken, en bedankt ervoor. Niet omdat het geen geweldige producten zijn, maar opnieuw vanwege leesbaarheid.

We willen dat het werk van agents leesbaar is voor mensen, net zoals de codebase leesbaar moet zijn voor agents. We zijn een behoorlijk groot bedrijf. Stop autonome ontwikkeling in een eigen console, en de voortgang ervan wordt alleen zichtbaar voor de paar mensen die in die console leven.

Daarom is, opnieuw, de tool-stack voor samenwerking en ontwikkeling bewust saai. Alles in ons verhaal draaide op vier tools die elk softwarebedrijf al open heeft staan: Slack, Linear, GitHub en Claude Code. Hierdoor is de voortgang die de agent boekt precies zo waarneembaar en doorzoekbaar als die van elk teamlid. Een product manager opent Linear-issues en checkt de featurestatus zoals altijd. De GitHub bug bot of security review leest PR-threads zoals altijd. Wie een bug meldt, plakt een screenshot in hetzelfde Slack-kanaal als altijd, en de fix verschijnt als een gewone pull request. Niemand hoeft iets te leren om toezicht te houden op de "machine".

Hier is de vorm van één autonome issue, van begin tot eind:

Eén autonome issue, van begin tot eind. De mens raakt de loop op precies twee plekken aan.

De mens raakt deze loop op precies twee plekken aan: door de agent op de Linear-issue te wijzen, en bij de handvol beslissingen die de agent naar boven brengt voordat er code wordt geschreven. Alles ertussenin — de implementatie, de checks, het reviewgesprek, de merge en de deploy — verloopt zonder dat iemand achter het stuur zit. Als een check faalt of een reviewer bezwaar maakt, leest de agent de fout, lost hem op en pusht opnieuw, en draait de loop gewoon nog een rondje. Hij stopt pas wanneer de branch groen is, elke bevinding is opgelost, en de queue hem heeft gemerged.

Wat dit mogelijk maakt, is geen op maat gemaakte integratie. Het komt doordat de drie tools al command surfaces blootleggen die een agent rechtstreeks kan aansturen, dezelfde die een mens gebruikt:

• GitHub, via de CLI. De agent opent de pull request, leest de status en logs van elke CI-job terug, reageert in reviewthreads en markeert ze als opgelost, en zet de branch in de wachtrij voor merge, allemaal via gewone gh-commando's.
• Linear, via de MCP-server. De agent leest de issue waar hij op gewezen is, volgt de links naar gerelateerde issues voor context, verandert de status, en dient follow-up-issues in voor werk dat hij onderweg ontdekt, allemaal als volwaardige tool calls.
• De eigen monitor-loop van Claude Code. CI duurt minuten en de merge queue duurt langer, en er kijkt geen mens mee. In plaats daarvan kijkt de agent, en de manier waarop hij dat doet, maakt van een onbewaakte run iets praktisch in plaats van een tokenvreugdevuur.

Wanneer de agent een pull request opent, blijft hij niet zitten wachten en een pagina verversen; hij registreert waarop hij wacht — de CI-run, de reviewthreads, de merge-queue-entry — en rondt dan de beurt af. De Monitor-functie van Claude Code roept hem pas weer op wanneer die bewaakte status verandert: een job wordt rood, het reviewpanel plaatst een bevinding, de queue merget de branch. Omdat de agent wordt gewekt door berichten van de Monitor over elke statusupdate, onderneemt hij daarop de volgende actie, zoals het log van een mislukte job ophalen en een fix pushen, reageren op een reviewthread en die als opgelost markeren, of de branch in de wachtrij zetten zodra elke gate groen is.

Niets hiervan is specifiek voor Muse. Elke repository die bereikbaar is via deze drie tools kan op dezelfde manier worden aangestuurd, en precies daarom hebben we ervoor gekozen.

Vertrouwen is een build-artefact

We vertrouwen niet de LLM zelf. We vertrouwen de LLM-agent binnen een harnas, en dat harnas kan worden ontworpen als bewaker van betrouwbaarheid. Concreet is het harnas onze CI/CD-pipeline plus de reviewlaag daarbovenop. Dit is wat elke pull request doorloopt, zonder uitzondering:

Elke pull request doorloopt hetzelfde harnas: eerst geautomatiseerde checks, dan het AI-reviewpanel.

De afzonderlijke jobs, met typische tijden gemeten op recente, echte PR-runs:

De guardrails zijn de eerder beschreven architectuur, omgezet in machines. Een sibling-import is hier geen reviewopmerking; het is een rode build. De visuele goldens worden vastgelegd in CI's eigen renderomgeving, zodat "werkt op mijn machine" nooit een argument kan zijn om een bug naar main te mergen.

De AI-reviewlaag is waar het interessant wordt. Elke PR wordt gelezen door ons eigen panel van drie coding-agent-reviewers, die dezelfde diff toetsen aan de vastgelegde ontwerpprincipes van de repo, elk met een andere toegewezen persona. Hier laten we een overzicht zien van de prompts die aan elke reviewer zijn gegeven.

De Principal Engineer:

Persona: Principal Engineer, ontwerpreview, groot bereik

Je reviewt op systeemniveau: hoort deze wijziging hier thuis, past hij bij de architectuur, hergebruikt hij wat al bestaat, en blijft hij additief — niet of een regel netjes is.

Je ziet de diff + de Guides, niet de hele repo. Beoordeel hergebruik en patroonconsistentie ...; claim geen repo-brede zoekopdracht die je niet kunt uitvoeren.

Je invalshoek: Beoordeel de diff tegen deze onderdelen van de meegeleverde Guides ...

Lakmoesproef: "Als ik de principal engineer voor deze codebase was, zou ik dit dan terugsturen omdat het op de verkeerde plek zit, een bestaande capability dupliceert, of een tweede manier toevoegt om iets te doen dat al is opgelost?" Zo niet, retourneer [].

De Senior Engineer:

Persona: Senior Engineer, logica / implementatie / kwaliteit

Je reviewt binnen de wijziging: is de logica correct, schoon, testbaar en veilig. Dit is de meest doordachte review — volg de codepaden, scan niet vluchtig. Focus op de diff en de bestanden die hij raakt (lees ze volledig).

Je invalshoek: Beoordeel de diff tegen deze onderdelen van de meegeleverde Guides ...

Lakmoesproef: "Zou ik deze logica goedkeuren, of zou ik bij een zorgvuldige lezing een bug, een ontestbare naad, of een beveiligingsfout vinden?" Wees specifiek over de falende input of codepad. Als de logica solide is, retourneer [].

De QA Engineer:

Persona: QA Engineer, werkt het, is het getest, gaat het stuk

Je reviewt gedrag en risico: doet deze wijziging wat hij beweert, is hij gedekt door tests, en zou hij iets live of in productie kunnen breken? Lees de PR-titel en -beschrijving, en controleer dan of de diff dat waarmaakt.

Je invalshoek: Intent-match ...; Testdekking ...; Regressierisico ...; Productievallen ...

Lakmoesproef: "Als ik als QA moest aftekenen, zou ik dit blokkeren omdat het niet doet wat het beweert, omdat het ongeteste functionaliteit uitrolt, of omdat de wijziging prod breekt?" Als het veilig en gedekt is, retourneer [].

Naast het bekijken van dezelfde codediff vanuit verschillende invalshoeken, delen de 3 reviewers ook een gemeenschappelijke set regels die de ontwikkeling van de hele codebase sturen, oftewel de Guides:

• Dingen die samen veranderen, wonen samen; niet-gerelateerde dingen blijven scheidbaar. Het wijzigen of verwijderen van één concern raakt één plek.
• Businesslogica hangt niet af van de details van de buitenwereld. Een businesslogicafunctie draait in een test met meegegeven fakes, zonder echte I/O. Het verwisselen van een backend raakt geen businesslogica. De app roept nooit zijn eigen HTTP-endpoints aan.
• Hergebruik, verzin niet opnieuw. Elke capability heeft één implementatie; een nieuwe consumer roept de bestaande interface aan in plaats van hem te kopiëren.
• Voeg features toe door toe te voegen, niet door te bewerken. Een feature toevoegen is "nieuwe bestanden + één registratieregel", en hem verwijderen raakt geen andere feature.
• Eén gevestigde manier om elk ding te doen. Een nieuwkomer kopieert het bestaande patroon in plaats van te kiezen, en tests hebben geen server of DB nodig.
• Verwijder code zodra hij niet meer wordt gebruikt. Er wordt niets uitgerold dat niets aanroept; "voor de zekerheid bewaren" is geen reden, want git onthoudt het.
• Geef de voorkeur aan het eenvoudigste dat werkt; voeg alleen complexiteit toe als het echt moet. Elke abstractie verdient zijn plek met een concrete, actuele behoefte. De wijziging is de kleinste die het probleem oplost.

Het panel plaatst elke blokkerende bevinding als een inline comment, verankerd aan de exacte regel, en die comments blokkeren de merge totdat ze zijn opgelost.

Een review van een recente feature-PR ziet er zo uit:

[medium] Regressierisico. Deze functie is het gedeelde create-and-sync-knelpunt; hij voegt nu bestanden met een view-suffix samen tot één gegroepeerde rij. Elke bestaande dataset die onder het oude schema is ingelezen, wordt bij de volgende sync stilzwijgend hergroepeerd, waarbij de oude sample-identiteiten verdwijnen waar live evaluaties nog naar verwijzen. Geen enkele test dekt het opnieuw synchroniseren van een bestaande dataset via de nieuwe groepering.

Die bevinding klopte. De code was door de volledige testsuite gekomen en een eerste ronde groene CI. De tests klopten voor de code zoals die geschreven was. De reviewer zag dat de code zoals geschreven, verkeerd was voor de data die we daadwerkelijk hebben. Claude loste het op, voegde de ontbrekende regressietest toe, reageerde in de thread en handelde de bevinding af. De hele uitwisseling is publiek zichtbaar in de PR, precies zoals je een junior engineer door een codereview zou begeleiden.

Dat was één PR. Naarmate we de agent langer laten draaien, ontdekken we nog een aantal andere typische patronen:

• Een fix die een nieuw probleem veroorzaakt. Een diagnosetool die we uitrolden, mat de downloadsnelheid. De review merkte op dat de berekening MB (1,000,000 bytes) gebruikte terwijl de server MiB (1,048,576 bytes) stuurde, waardoor elke snelheid 5% te laag zou uitlezen. Een paar pushes later signaleerde de review dat de fix twee constanten had achtergelaten die handmatig synchroon gehouden moesten worden. Daarom werd gevraagd om de snelheid in plaats daarvan te berekenen uit de daadwerkelijk ontvangen bytes. De reviewer ving een bug op die was ontstaan door het afhandelen van zijn eerdere verzoek.
• Doodlopende use cases. Dezelfde pagina werd uitgerold met zijn link zichtbaar voor elke ingelogde gebruiker, ook al had de pagina zelf een specifieke permissie nodig. Iedereen zonder die permissie zou klikken en op een 403-fout stuiten. Geen enkele test faalde, want de link verscheen en de permissiecontrole werkte. De QA-reviewer vergeleek de twee en blokkeerde de merge totdat de link alleen nog werd getoond aan mensen die de pagina daadwerkelijk konden openen.
• Trucjes om tests te halen. De test bij één fix construeerde precies de exceptie die hij hoorde op te vangen, waardoor hij slaagde zelfs als de echte foutafhandeling kapot was, omdat de test het "juiste" exceptiebericht ontving. Het panel signaleerde dit, en de herschreven test stuurt echte fouten door de echte code. Dezelfde PR had ook een test die slaagde op de machine van de ontwikkelaar maar faalde in CI, omdat hij stilletjes leunde op een credentialsbestand dat alleen op onze devbox bestaat. Beide waren bugs in de tests zelf, opgevangen door de laag daarboven.

Ons mergebeleid is 0 AI-reviewbevindingen. Elke bevinding wordt opgelost, of weerlegd met bewijs, voordat de queue de PR overneemt. We hebben weerlegging tot een haalbare optie gemaakt omdat het reviewpanel in een acceptabele mate te veel signaleert. Opschrijven waarom een bevinding onterecht is, kan op zijn beurt af en toe een fout in de eigen redenering van het reviewpanel aan het licht brengen.

Voorbij de checks valideert de merge queue elke branch opnieuw tegen de bewegende tip van main, en een merge deployt automatisch naar productie, zonder mens in de loop.

Voorbij elke gate valideert de merge queue de branch opnieuw en deployt een merge naar productie.

Regels code zijn maar een klein deel van het verhaal

Na verloop van vele zelfsturende PR's ontdekten we een opvallend maar logisch patroon: de tijd die nodig is om te itereren op checks en reviews, is veel langer dan de tijd die nodig is om de eerste implementatie te schrijven, en die verhouding verschilt ook sterk per type taak. Hier vergelijken we twee soorten ontwikkeltaken in dezelfde week.

Case A: een dode feature uitfaseren. Een kleine legacyfeature ging offline; de link, het bevestigingsdialoog, de vertaling, de tests en de screenshot-baseline moesten allemaal weg. Van het indienen van de Linear-issue tot het mergen van de PR op main duurde het slechts 16 minuten, waarvan de eerste 2 minuten aan het schrijven van code. Reviews waren alleen adviserend.

Case B: een grote verbetering aan de netwerkdiagnosefeature. Qua regelaantal was het een vergelijkbaar grote wijziging, waarbij de eerste versie in 5 minuten klaar was, terwijl de totale tijd tot de merge ongeveer 3 uur bedroeg. Onderweg handelde de agent 5 reviewronden en 7 merge-blokkerende bevindingen af.

Ook de tijdlijnen verschillen behoorlijk:

Twee taken met een vergelijkbaar regelaantal, met verificatie-inspanning naar verhouding van het risico.

De tweede duurt elf keer langer, niet omdat de code moeilijker te schrijven was, maar omdat het risico anders lag, en de verificatie-inspanning daar naar verhouding aan werd besteed. Case A was een verwijdering: het slechtste resultaat was een kapotte link die toch al niet bezocht had moeten worden. Case B was een meetinstrument: het slechtste resultaat was dat elke gebruiker een verkeerd getal zou vertrouwen. Het reviewpanel vond de fouten, en besteedde vervolgens nog drie rondes aan het afwijzen van halve oplossingen, totdat de foutafhandeling getypeerd, compleet en grondig getest was. Elke ronde maakte de implementatie strikt strakker. Geen van die gebreken deed een test falen, en ze zouden allemaal zijn uitgerold.

Dit is het onderdeel dat one-shot codegeneratie per constructie verkeerd doet. One-shot generatie optimaliseert de metriek die het makkelijkst te zien is: de tijd van prompt tot code die compileert en draait. Beide van onze cases haalden die metriek binnen enkele minuten, en als we daar waren gestopt, zou Case B een paar minuten na de start klaar zijn geweest — en maandenlang fout.

Diezelfde pipeline die een verwijdering in 16 minuten doorwuifde, hield een meetinstrument 3 uur lang tegen, zonder dat een mens bepaalde welke behandeling elk verdiende. Als mensen vragen of AI-geschreven code in productie kan worden vertrouwd, is dit het antwoord: de code is precies zo betrouwbaar als de verificatie eromheen, en verificatiediepte is nu iets wat je koopt met agent-uren in plaats van engineer-dagen. Een verkeerd snelheidsrapport kost meer dan drie uur zodra iemand er ook maar één keer een netwerkklacht op baseert.

Wat we hebben geleerd en wat er nu volgt

Vandaag de dag is autonomie meer een eigenschap van het harnas dan van het model. Elke model-upgrade maakte onze agents beter; modelcapaciteit op zich komt echter niet met de garantie dat je de agent kunt vertrouwen om zijn pull requests vrijelijk te mergen. In plaats van meer menselijke aandacht te investeren of blindelings het duurste frontier-model te gebruiken, kozen we ervoor om de "handen" en "ogen" te bouwen, zodat agents alles hebben wat ze nodig hebben om correcte productiecode te produceren. En doordat de modelcapaciteit blijft evolueren, kunnen we op die golf meesurfen in plaats van steeds de stellage te herbouwen om de beperkingen van modellen te compenseren.

De menselijke rol concentreert zich, hij verdwijnt niet. Wat overblijft is de onherleidbare kern: beslissen wat het waard is om te bouwen, het duidelijk genoeg opschrijven, en oordeelsvermogen inzetten op de momenten die de machines als dubbelzinnig markeren. Ontwerpsmaak en de kwaliteit van specificaties zijn nu de engineeringvaardigheid met de hoogste hefboomwerking in dit team.

En de interessantste conclusie over agentteams is dat de waarde van het team voortkomt uit conflict in plaats van samenwerking. Het kan zinvol zijn om een full-stack taak te splitsen over frontend- en backend-agents. Het is minder zinvol om een frontend-agent en een backend-agent met elkaar te laten praten alleen om de taak af te ronden. Het voordeel van het team ontstaat wanneer leden tegenstrijdige doelen hebben. Onze Muse-ontwikkelagent wil de code uitrollen. Onze AI-reviewagents willen vinden waar de code fout of slecht ontworpen is. Het is hun spanning die het resultaat betrouwbaar maakt, en die getrouw de werkelijke hoeveelheid werk van een ontwikkeltaak blootlegt.

Nog belangrijker: we merken dat onze verkenningen ons leiden naar een opkomende manier om software te ontwikkelen: een autonome engineeringorganisatie. Hoewel we hebben aangetoond dat agents met bestaande tools autonoom individuele taken kunnen voltooien, nodigen een paar ontbrekende puzzelstukjes en open vragen uit tot verder onderzoek:

• Hoeveel kunnen we dit soort systemen opschalen? Naarmate de autonome organisaties met meer parallelle agents aan steeds grotere taken en projecten werken, welke nieuwe problemen zullen dan ontstaan?
• Hoe kunnen de eigen outputs van het harnas, zoals first-shot CI-slagingspercentages en AI-reviewbevindingen, evaluatiesignalen worden? Hoe meten we de prestaties van een agent binnen de organisatie, en hoe maken we dat zelf-evoluerend?
• Hoe kunnen de ontwerp- en productsmaak van mensen in zulke systemen worden ingebakken? Als engineering autonoom kan worden gemaakt met schaars menselijk oordeel, hoe ver kunnen we dit doortrekken om de vraag op te lossen voor wie we de software moeten bouwen, en hoe die eruit moet zien?

Tot slot, bedankt dat je tot helemaal het einde hebt gelezen. De to-dolijst om antwoorden op deze vragen te vinden, leeft toepasselijk genoeg in Linear, waar onze volgende agent — of jij — hem misschien oppakt.