Enkla verktyg, självkörande utveckling: Så bygger Muse sig själv

TL;DR Muse ersätter skräddarsydda konsoler för agentorkestrering med fyra verktyg som varje mjukvaruteam redan har öppna: Slack, Linear, GitHub och Claude Code. Ingen dashboard, ingen SPA, ingen manuellt skriven kod. Varje PR tar sig igenom sju CI-grindar och en granskningspanel med tre AI-personas enligt en policy om noll anmärkningar vid sammanslagning. 40,000 röster insamlade, utvärdering av grundmodeller 80% snabbare.

Muse, en förkortning för Meshy Universal System for Evaluation, är vår interna plattform för modellutvärdering. Team på Meshy använder den dagligen för att ta reda på om nya modellcheckpoints presterar bättre än de gamla.

En dag hade en het ny modellcheckpoint precis blivit klar. Den behövde en arena-match för att avgöra nästa träningsstrategi. Teamet insåg att de behövde en ny Muse-funktion för att stödja det.

"@Linear skapa ett Muse-ärende om det här"

sa produktchefen på Slack.

En minut senare skapades Linear-ärendet MES-12345.

Muse-plattformens ägare – jag – såg ärendet. Det behövde skeppas ASAP för att låsa upp utvärderingsuppgiften. Sedan skickades meddelandet till Claude:

"Undersök och åtgärda MES-12345"

Claude tittade på ärendet och lyfte sedan fram två designbeslut. Besluten fattades, och jag lämnade terminalen för att jobba med något annat.

En och en halv timme senare var en ny version av Muse driftsatt. Klart.

Autonom mjukvaruutveckling behöver inte betyda flashiga konsoler för agentorkestrering eller dashboards. Och i den här artikeln förklarar jag hur vi gjorde det möjligt.

Ett galleri, en visare och en röstknapp

Frågan Muse besvarar är bedrägligt svår: är den nya modellcheckpointen faktiskt bättre? Visst finns det kvantitativa mått att följa i varje träningskörning, men de fångar långt ifrån vad "bra" faktiskt innebär inom 3D-generering. Så Muse gör det enkla men effektiva: dubbelblind testning. Den ställer två modellers resultat sida vid sida, med samma inputbild, slumpmässigt placerade till vänster och höger, och låter kollegorna rösta blint.

En utvärdering är en batch av sådana par. Någon pekar Muse mot två uppsättningar genererade meshar och en mapp med referensbilder, och appen tar det därifrån: parar ihop modellerna, gör tilldelningen blind och visar en jämförelse i taget. Röster samlas in varje gång någon har en ledig minut. Hela gränssnittet är byggt för att vara "snackable", och går nästan uteslutande att navigera med snabbkommandon. Den som måste sträcka sig efter musen röstar mindre.

Muses röstningsgränssnitt: två genererade meshar, samma inputbild, slumpmässigt placerade till vänster och höger.

Det är hela produkten. Ett galleri, en visare och en röstknapp. Ingenting kring Muses funktion är komplicerat, vilket är precis varför det blir ett så rent fallstudieobjekt. Det ovanliga är bara hur det byggs.

En arkitektur agenter kan navigera

Muse-projektet startade i slutet av 2025, när "vibe coding" precis hade blivit ett nytt buzzword. Förutom att stödja Meshys växande utvärderingsarbete i tränings- och releasecykler hade Muse också ett ambitiöst mål: att bygga mjukvara för hela företaget, med noll rader manuellt skriven kod.

Idag är resultaten lysande:

• Över 40,000 röster insamlade sedan Muses första leverans, med över 30 utvärderingsprojekt per månad
• Fler än 4 team som aktivt använder Muse i sitt dagliga arbete
• Första interna kodbasen som aktivt får bidrag från minst 1 icke-teknisk teammedlem
• Första interna kodbasen som uppnår fullt autonom utveckling

Sammantaget uppskattar vi att Muse har snabbat upp vår utvärdering av grundmodeller med minst 80% och skurit ner minst 10 persondagar av arbete vid varje modellrelease. Utan Muse hade det varit nästan omöjligt att upprätthålla den nuvarande utvecklings- och releasetakten för Meshys samling av generativa modeller, såsom geometri, textur och smart topologi.

Från första dagen designades Muse för att vara så agentläsbart som möjligt. Redan 2025 upptäckte vi att agenter, för att implementera samma användningsfall, kämpade på vissa sätt medan de lyckades direkt på andra. Många av dessa iterationer resulterade till slut i en medvetet tråkig teknikstack idag. Backend är Python: FastAPI, Postgres för poster, S3 för meshar och bilder. Frontend renderas på serversidan: Jinja2-mallar, HTMX för partiella sidouppdateringar, Tailwind för styling, och en enda riktig klientsideskomponent, WebGL-3D-visaren som renderar meshar. Det finns ingen SPA och ingen separat frontend-modul. Kopplingen mellan de två stackarna är den äldsta som finns på webben: backend renderar HTML, webbläsaren visar det. När en sida behöver ändras begär HTMX ett fragment, och servern renderar det också.

Här är arkitekturen för kärnutvärderingsappen i Muse:

Den lagerindelade arkitekturen för Muses kärnutvärderingsapp. Beroenden pekar bara nedåt.

Två egenskaper hos den här formen spelar roll för agenter. För det första lever frontend-tillståndet på servern. HTML:en användaren ser är HTML som backend har producerat, så ett test (eller en agent) kan kontrollera den direkt utan att behöva köra ett klientsidesramverk för att återskapa vad användaren såg. För det andra är varje beroende maskinellt påtvingat och pekar bara nedåt. En feature-mapp får inte importera sin syskonmapp; om två features behöver varandra injicerar kompositionsroten en förmåga i den andra, så att beroendet syns i exakt en fil. Varje lager har en enda uppgift, och uppgifterna är nedskrivna där en agent kommer att snubbla över dem:

Beroenden pekar alltid bara nedåt i den här listan, och riktningen tvingas fram av en byggkontroll, inte av en konvention.

Tre ytterligare egenskaper gör kodbasen medvetet agentläsbar:

• Varje katalog har sin egen dokumentation (vad tjänsten gör, dess lagerregler, de exakta kommandona som avgör en sammanslagning), så att en agent som landar helt kallt kan orientera sig utan att fråga eller hitta på saker själv.
• Icke-triviala moduler har docstrings med bakåtlänkar till designdokument, så att varför lever kvar bredvid vad.
• Ingen fil får överstiga 500 rader, med en spärr för ett fåtal undantagsfall. För undantagen får filer krympa, aldrig växa tillbaka. Kontextfönster är ändliga; arkitekturen respekterar det.

Framsteg ska inte bo i ett litet rum

Idag, när LLM-agenter är mycket kraftfullare än 2025, vill vi att utvecklingen av Muse ska vara helt autonom. Det innebär att människan bara pekar agenten mot uppgiften. Agenten orienterar sig själv kring kodbasen och uppgiftens kontext, arbetar sig igenom implementation, CI och kodgranskning, och kör till slut själv pull requesten hela vägen till sammanslagning. Människan avgör bara prioriteten på ärenden och fattar de viktiga designbesluten.

De första tankarna kring helt autonom utveckling handlar oftast om skräddarsydda plattformar: orkestreringskonsoler, agentinfödda arbetsytor, app efter app som lovar att hantera din flotta av agenter. Vi tittade på dem och tackade nej. Inte för att de inte är bra produkter, utan återigen på grund av läsbarheten.

Vi vill att agenternas arbete ska vara läsbart för människor, precis som kodbasen ska vara läsbar för agenter. Vi är ett företag av rejäl storlek. Lägger man in autonom utveckling i en anpassad konsol blir framstegen bara synliga för de få personer som lever i den konsolen.

Som ett resultat är, återigen, verktygsstacken för samarbete och utveckling medvetet tråkig. Allt i vår historia kördes på fyra verktyg som varje mjukvaruföretag redan har öppna: Slack, Linear, GitHub och Claude Code. Det gör att framstegen agenten gör blir precis lika synliga och sökbara som vilken teammedlems som helst. En produktchef öppnar Linear-ärenden och kollar featurestatus precis som alltid. GitHubs bugg-bot eller säkerhetsgranskning läser PR-trådar precis som alltid. Den som rapporterar en bugg klistrar in en skärmdump i samma Slack-kanal som alltid, och fixen dyker upp som en helt vanlig pull request. Ingen behöver lära sig något nytt för att övervaka "maskinen".

Här är formen på ett enda autonomt ärende, från start till mål:

Ett autonomt ärende, från start till mål. Människan rör vid loopen på exakt två ställen.

Människan rör vid den här loopen på exakt två ställen: genom att peka agenten mot Linear-ärendet, och genom den handfull beslut agenten lyfter fram innan den skriver kod. Allt däremellan, implementationen, kontrollerna, granskningssamtalet, sammanslagningen och driftsättningen, körs utan någon vid ratten. När en kontroll misslyckas eller en granskare invänder läser agenten felet, åtgärdar det och pushar igen, och loopen kör helt enkelt ett varv till. Den avslutas bara när grenen är grön, varje anmärkning är löst och kön har slagit ihop den.

Det som gör det här möjligt är ingen skräddarsydd integration. Det är att de tre verktygen redan exponerar kommandoytor en agent kan styra direkt, samma ytor en människa använder:

• GitHub, via sitt CLI. Agenten öppnar pull requesten, läser tillbaka status och loggar för varje CI-jobb, svarar i granskningstrådar och markerar dem som lösta, och köar grenen för sammanslagning, allt via vanliga gh-kommandon.
• Linear, via sin MCP-server. Agenten läser ärendet den pekades mot, följer länkarna till relaterade ärenden för kontext, flyttar status och skapar uppföljningsärenden för arbete den upptäcker på vägen, allt som förstklassiga tool calls.
• Claude Codes egen Monitor-loop. CI tar minuter och sammanslagningskön tar längre tid, och ingen människa håller koll. Istället håller agenten koll, och sättet den håller koll på är det som gör en obevakad körning till något praktiskt istället för en tokenbrasa.

När agenten öppnar en pull request sitter den inte och uppdaterar en sida; den registrerar vad den väntar på, CI-körningen, granskningstrådarna, sammanslagningsköns post, och avslutar sedan sin tur. Claude Codes Monitor-funktion väcker den bara till liv igen när det övervakade tillståndet ändras: ett jobb blir rött, granskningspanelen postar en anmärkning, kön slår ihop grenen. Eftersom agenten väcks av meddelanden från Monitor om varje statusuppdatering vidtar den nästa åtgärd därefter, som att hämta loggen för ett misslyckat jobb och pusha en fix, svara i en granskningstråd och markera den som löst, eller köa grenen så snart varje grind är grön.

Inget av det här är specifikt för Muse. Varje repo som nås av de här tre verktygen kan styras på samma sätt, vilket är precis varför vi valde dem.

Förtroende är en byggartefakt

Vi litar inte på själva LLM:en. Vi litar på LLM-agenten inuti en sele, och selen kan konstrueras för att vara väktaren av tillförlitlighet. Konkret är selen vår CI/CD-pipeline plus granskningslagret ovanpå den. Det här är vad varje pull request går igenom, utan undantag:

Varje pull request passerar samma sele: först automatiserade kontroller, sedan AI-granskningspanelen.

De enskilda jobben, med typiska tider uppmätta från nyliga verkliga PR-körningar:

Guardrails är arkitekturen vi beskrev, omsatt i maskinform. En syskonimport är inte en granskningskommentar här; det är ett rött bygge. De visuella goldens fångas i CI:s egen renderingsmiljö, så "funkar på min maskin" kan aldrig vara ett argument för att slå ihop en bugg i main.

AI-granskningslagret är där det blir intressant. Varje PR läses av vår egen panel av tre kodande agentgranskare som läser samma diff mot repots nedskrivna designprinciper, var och en med en tilldelad persona. Här visar vi ett utdrag av de prompter som ges till varje granskare.

Principalingenjören:

Persona: Principalingenjör, designgranskning, stort omfång

Du granskar på systemnivå: hör den här ändringen hemma här, passar den in i arkitekturen, återanvänder den det som redan finns, och förblir den additiv, inte om en rad är prydlig.

Du ser diffen + Guiderna, inte hela repot. Bedöm återanvändning och mönsterkonsistens ...; hävda inte en repobred sökning du inte kan utföra.

Din lins: Bedöm diffen mot dessa delar av de tillhandahållna Guiderna ...

Lackmustest: "Om jag vore principalingenjören för den här kodbasen, skulle jag skicka tillbaka det här för att det hör hemma på fel ställe, dubblerar en befintlig funktion, eller lägger till ett andra sätt att göra något som redan är löst?" Om nej, returnera [].

Senioringenjören:

Persona: Senioringenjör, logik/implementation/kvalitet

Du granskar inom ändringen: är logiken korrekt, ren, testbar och säker. Det här är den mest genomtänkta granskningen, följ kodvägarna, skumma inte. Fokusera på diffen och de filer den rör (läs dem i sin helhet).

Din lins: Bedöm diffen mot dessa delar av de tillhandahållna Guiderna ...

Lackmustest: "Skulle jag godkänna den här logiken, eller skulle jag hitta en bugg, en otestbar söm, eller ett säkerhetsmisstag vid en noggrann läsning?" Var specifik om vilken input eller kodväg som failar. Om logiken håller, returnera [].

QA-ingenjören:

Persona: QA-ingenjör, fungerar det, är det testat, kommer det gå sönder

Du granskar beteende och risk: gör den här ändringen det den påstår, täcks den av tester, och skulle den kunna göra sönder något som är live eller i produktion? Läs PR:ens titel och beskrivning, kontrollera sedan att diffen levererar det.

Din lins: Intent-matchning ...; Testtäckning ...; Regressionsrisk ...; Produktionsfällor ...

Lackmustest: "Om jag vore QA som skulle godkänna, skulle jag blockera det här för att det inte gör vad det påstår, för att det skeppar otestat beteende, eller för en ändring som förstör prod?" Om det är säkert och täckt, returnera [].

Förutom att titta på samma kodiff ur olika vinklar delar de tre granskarna också en gemensam uppsättning regler som styr utvecklingen av hela kodbasen, det vill säga Guiderna:

• Saker som förändras tillsammans bor tillsammans; orelaterade saker förblir separerbara. Att ändra eller ta bort en angelägenhet rör bara en plats.
• Affärslogik beror inte på omvärldens detaljer. En affärslogikfunktion körs i ett test med fejkade beroenden inskickade, ingen riktig I/O. Att byta ut en backend rör ingen affärslogik. Appen anropar aldrig sina egna HTTP-endpoints.
• Återanvänd, uppfinn inte på nytt. Varje funktion har en implementation; en ny konsument anropar det befintliga gränssnittet istället för att kopiera det.
• Lägg till features genom att lägga till, inte genom att redigera. Att lägga till en feature är "nya filer + en registreringsrad", och att ta bort den rör ingen annan feature.
• Ett etablerat sätt att göra varje sak. En nykomling kopierar det befintliga mönstret istället för att välja, och tester behöver ingen server eller databas.
• Ta bort kod i samma stund den slutar användas. Inget skeppas som inget anropar; "spara det bara i fall" är inget skäl eftersom git kommer ihåg.
• Föredra det enklaste som fungerar; lägg bara till komplexitet när det tvingas fram. Varje abstraktion förtjänar sin plats genom ett konkret nuvarande behov. Ändringen är den minsta som löser problemet.

Panelen postar varje blockerande anmärkning som en inline-kommentar förankrad till den exakta raden, och de kommentarerna spärrar sammanslagningen tills de är lösta.

En granskning från en nyligen genomförd feature-PR ser ut så här:

[medium] Regressionsrisk. Den här funktionen är den delade flaskhalsen för create-and-sync; den slår nu ihop view-suffigerade filer till en enda grupperad rad. Varje befintligt dataset som togs in under det gamla schemat kommer, vid sin nästa synk, tyst att grupperas om, vilket raderar de gamla sampleidentiteter som pågående utvärderingar fortfarande refererar till. Inget test täcker återsynkning av ett befintligt dataset genom den nya grupperingen.

Den anmärkningen var korrekt. Koden hade klarat hela testsviten och en första omgång grön CI. Testerna var rätt för koden som den var skriven. Granskaren såg att koden som den var skriven var fel för datan vi faktiskt har. Claude åtgärdade det, lade till det saknade regressionstestet, svarade i tråden och löste anmärkningen. Hela utbytet är publikt i PR:en, exakt på samma sätt som man skulle handleda en junior ingenjör genom kodgranskning.

Det var en PR. När vi kör agenten över tid kan vi även upptäcka några andra typiska mönster:

• En fix som orsakar ett nytt problem. Ett diagnostikverktyg vi skeppade mätte nedladdningshastighet. Granskningen upptäckte att beräkningen använde MB (1 000 000 byte) men servern skickade MiB (1 048 576 byte), så varje hastighet skulle ha visat 5% för lågt. Några pushar senare flaggade granskningen att fixen lämnade två konstanter som hölls synkroniserade för hand. Så den begärde att hastigheten istället skulle beräknas från de faktiska mottagna bytesen. Granskaren fångade en bugg som uppstått av att man åtgärdat dess tidigare begäran.
• Återvändsgränder i användningsfall. Samma sida skeppades med sin länk synlig för alla inloggade användare, trots att sidan själv krävde en specifik behörighet. Vem som helst utan den behörigheten skulle klicka och få ett 403-fel. Inget test misslyckades, eftersom länken visades och behörighetsspärren fungerade. QA-granskaren jämförde de två och blockerade sammanslagningen tills länken bara visades för personer som faktiskt kunde öppna sidan.
• Att fuska för att klara tester. Ett fixtest tillverkade exakt det undantag det skulle fånga, så det klarade sig även om den riktiga felhanteringen var trasig, eftersom testet fick det "korrekta" undantagsmeddelandet. Panelen flaggade det, och det omskrivna testet kör riktiga fel genom den riktiga koden. Samma PR hade också ett test som klarade sig på utvecklarens maskin men misslyckades i CI, eftersom det i tysthet förlitade sig på en credentials-fil som bara finns på vår devbox. Båda var buggar i själva testerna, fångade av lagret ovanför dem.

Vår sammanslagningspolicy är 0 AI-granskningsanmärkningar. Varje anmärkning åtgärdas, eller motbevisas med bevis, innan kön tar hand om PR:en. Vi gjorde motbevisning till ett gångbart alternativ eftersom granskningspanelen överflaggar i en tolererbar takt. Att skriva ner varför en anmärkning är fel kan i sin tur ibland fånga ett misstag i granskningspanelens egna resonemang.

Efter kontrollerna omvaliderar sammanslagningskön varje gren mot mains rörliga spets, och en sammanslagning driftsätts till produktion automatiskt utan någon människa i loopen.

Efter varje grind omvaliderar sammanslagningskön grenen, och en sammanslagning driftsätts till produktion.

Rader kod är bara en liten del av historien

Över många självkörande PR:ar hittade vi ett slående men rimligt mönster: tiden det tar att iterera på kontroller och granskningar är mycket längre än tiden det tar att skriva den första implementationen, och förhållandet varierar också kraftigt beroende på typ av uppgift. Här jämför vi två typer av utvecklingsuppgifter under samma vecka.

Fall A: pensionera en död feature. En liten legacy-feature togs offline; dess länk, bekräftelsedialog, översättning, tester och skärmdumpsbaseline behövde alla bort. Från att Linear-ärendet skapades till att PR:en slogs samman med main tog det bara 16 minuter, varav de första 2 minuterna gick till att skriva kod. Granskningarna var enbart rådgivande.

Fall B: en stor förbättring av nätverksdiagnostikfunktionen. Det var en ändring av liknande storlek räknat i rader, med den första versionen klar på 5 minuter, medan den totala tiden till sammanslagning var cirka 3 timmar. Under tidens gång löste agenten 5 granskningsrundor och 7 sammanslagningsblockerande anmärkningar.

Tidslinjerna skiljer sig också ganska mycket åt:

Två uppgifter med jämförbart antal rader, som fått verifieringsinsats i proportion till risk.

Den andra tar elva gånger längre tid, inte för att koden var svårare att skriva, utan för att risken var annorlunda och verifieringsinsatsen lades i proportion till den. Fall A var en borttagning: värsta utfallet var en trasig länk som redan inte var tänkt att besökas. Fall B var ett mätverktyg: värsta utfallet var att varje användare litade på ett fel tal. Granskningspanelen hittade felen, och lade sedan ner tre ytterligare rundor på att neka partiella fixar tills felhanteringen var typad, komplett och grundligt testad. Varje runda gjorde implementationen strikt stramare. Inget av de här felen fick ett test att misslyckas, och alla hade skeppats.

Det här är den del one-shot-kodgenerering får fel av konstruktion. One-shot-generering optimerar det mått som är enklast att se: tiden från prompt till kod som kompilerar och kör. Båda våra fall träffade det måttet på några minuter, och om vi hade stannat där hade Fall B varit klart bara några minuter efter att det startade, och fel i månader.

Samma pipeline som vinkade igenom en borttagning på 16 minuter höll kvar ett mätverktyg i 3 timmar, utan att någon människa avgjorde vilken behandling vardera förtjänade. När folk frågar om man kan lita på AI-skriven kod i produktion, är det här svaret: koden är exakt lika pålitlig som verifieringen som omger den, och verifieringsdjup är nu något man köper med agenttimmar istället för ingenjörsdagar. En felaktig hastighetsrapport kostar mer än tre timmar första gången någon hanterar ett nätverksklagomål utifrån den.

Vad vi lärde oss och vad som är nästa steg

Idag är autonomi mer en egenskap hos selen än hos modellen. Varje modelluppgradering gjorde våra agenter bättre; modellens förmåga i sig kommer dock inte med någon garanti att man kan lita på att agenten fritt slår ihop sina pull requests. Istället för att investera mer mänsklig uppmärksamhet eller blint använda den dyraste frontiermodellen valde vi att bygga "händerna" och "ögonen" så att agenter är utrustade med allt de behöver för att producera korrekt produktionskod. Och i takt med att modellernas förmåga utvecklas gör det här också att vi surfar på vågen istället för att bygga om ställningen för att kompensera för modellernas begränsningar.

Människans roll koncentreras, den försvinner inte. Det som blir kvar är den oreducerbara kärnan: att avgöra vad som är värt att bygga, skriva ner det tydligt nog, och utöva omdöme i de stunder maskinerna flaggar som tvetydiga. Designsmak och specifikationskvalitet är nu den mest hävstångsgivande ingenjörsskickligheten i det här teamet.

Och den mest intressanta insikten om agentteam är att teamets värde kommer från konflikt snarare än samarbete. Det kan vara vettigt att dela upp en fullstack-uppgift mellan frontend- och backend-agenter. Det är mindre vettigt att låta en frontend-agent och en backend-agent prata med varandra bara för att slutföra uppgiften. Fördelen med teamet uppstår när medlemmarna har motstridiga mål. Vår Muse-utvecklingsagent vill skeppa koden. Våra AI-granskningsagenter vill hitta var koden är fel eller dåligt designad. Det är deras spänning som gör resultatet pålitligt, och som troget avslöjar den verkliga mängden arbete i en utvecklingsuppgift.

Ännu viktigare är att vi ser att våra utforskningar leder oss mot ett framväxande sätt att utveckla mjukvara på: en autonom ingenjörsorganisation. Även om vi har visat att agenter autonomt kan slutföra enskilda uppgifter med befintliga verktyg, bjuder några saknade delar och öppna frågor in till framtida ansträngningar:

• Hur mycket kan vi skala upp sådana system? När de autonoma organisationerna arbetar på allt större uppgifter och projekt med fler parallella agenter, vilka nya problem kommer att uppstå?
• Hur kan selens egna utdata, som första-försöks-CI-godkännandegrad och AI-granskningsanmärkningar, bli utvärderingssignaler? Hur mäter vi en agents prestation i organisationen, och hur gör vi den självutvecklande?
• Hur kan människors design- och produktsmak bakas in i sådana system? Om ingenjörsarbete kan göras autonomt med sparsamma mänskliga bedömningar, hur långt kan vi ta det här för att lösa frågorna om vem vi ska bygga mjukvaran för, och hur den ska se ut?

Slutligen, tack för att du läste ända till slutet. Att-göra-listan för att hitta svaren på de här frågorna finns passande nog i Linear, där vår nästa agent, eller du, kanske plockar upp den.