Addable Labs – Blogg

Ashlands: vad en enda prompt byggde

Tue, 22 Sep 2026 00:00:00 +0000

Den 31 juli 2026 gav vi Claude Code en enda prompt: bygg ett action-rollspel i nivå med Morrowind, i Three.js, starta subagenter parallellt, låt en separat hård kritiker jämföra varje del sida vid sida med det riktiga spelet och sluta inte förrän varje kritiker är imponerad. Ingen arkitektur, ingen uppgiftslista, ingen definition av vad som är klart. Bygget pågick i tre dagar; den 10 augusti skrev agenten på vår begäran en utvärdering av sin egen körning. Båda är offentliga: Ashlands är MIT-licensierat och dess utvärderingsrapport lutar medvetet åt det som gick fel – och är agentens egen redogörelse för sin egen körning, värt att minnas för varje siffra nedan.

Prompten följer Gauntlet Loop, metoden Matt Shumer beskrev i How to Run a Gauntlet Loop – ett gatlopp där varje del av arbetet får löpa förbi kritiker om och om igen: kör den i ett agentsystem i stället för i en chatt, formulera målet utan att föreskriva lösningen, ge kritikern en konkret referens att jämföra mot, låt ledaragenten dela upp arbetet i delar som kan bedömas var för sig och låt aldrig en byggare sätta betyg på sitt eget arbete. Andra har kört den sedan dess och spelen de byggde finns samlade på hans sajt, flera av dem riktigt bra.

Vad som kom ut

Ungefär 94 000 rader TypeScript i 160 filer; sexton delsystem, vart och ett bakom ett namngivet kontrakt; arton uppdrag med dialog, fraktioner, brott och en dagbok; noll binära resurser – terräng, material, himmel, växtlighet, arkitektur, varelser, musik och ljud genereras alla ur kod. Agenten byggde också maskineriet som dömer den: 32 grindkontroller och 17 end-to-end-kontroller som kör en riktig webbläsare. Vid körningens slut föll 1 av 32 grindkontroller, 16 av 16 end-to-end-kontroller gick igenom och spelet gick i 20 till 35 bilder per sekund i den upplösning som bilderna fångades i, på en MacBook Air.

Och det går att spela: du kan vandra i världen, använda färdigheter och slutföra alla arton uppdrag – ett skript driver vart och ett till sista steget utan att fastna. Det som står öppet är bildfrekvensen och den konstnärliga riktningen: en palettkontroll som faller på en vy, trappsteg där vatten möter terräng, fläckighet på avstånd. Inte ett spel som faller ihop – ett ofärdigt.

Vad metoden fick rätt

Kontrakten först: ett namngivet gränssnitt per delsystem som bara kommunicerar genom en händelsebuss, vilket lät subagenter skriva terräng, himmel, strid och ljud samtidigt med nästan inga integrationskonflikter – rapporten kallar det det beslut som mest av allt är skälet till att kodbasen finns. Byggare hålls isär från kritiker: agenter som satte betyg på sitt eget arbete förklarade sig klara, fristående kritiker gjorde det inte. Och negativa resultat som det mest värdefulla en agent lämnade ifrån sig – fyra av slutfasens sex rundor slutade med att en agent gjorde en ändring, mätte den, fann den sämre och tog tillbaka den men behöll mätningen. Var och en av dem stängde ett undersökningsspår för gott.

Vad som gick fel

Uppdragets slutvillkor, en blind jämförelse sida vid sida med det riktiga spelet, inträffade aldrig: inga referensbilder togs någonsin fram, så varje omdöme om att något "slår Morrowind" var en agent som jämförde en bildruta med sitt eget minne – en avvikelse från metoden, vars tredje princip är att ge kritikern något konkret att granska.

Det dyraste felet var inte dålig kod utan självsäkert felaktig diagnos. En utsiktspunkt renderades som ett platt terrakottafärgat svep och tre rundor subagenter skickades till terrängmaterialet, ljussättningen och atmosfären; alla tre mätte rätt, fann ingenting och tog tillbaka sina ändringar. Orsaken var en enda saknad avståndsterm i sökningen efter kameraläge, som hade klättrat upp på närmaste höjd och siktat rakt på toppen: ingen ändring i en shader kan rädda en bildruta utan djup. En andra flerrundig jakt var samma sorts fel.

Varifrån rättelserna kom

Rapporten är agentens röst och den är tunn just där människan var avgörande: vi spelade spelet medan det byggdes och styrde det. Armarna i förstapersonsvy tog ett elvatal rundor. Den 1 augusti (citaten är översatta från engelska): "Vilka hemska armar! Fingrarna pekar åt fel håll och armarna ser ut som rör snarare än riktiga armar." Senare samma dag: "Handen ser ut som en vänsterhand, men spelaren håller svärdet i höger hand." På kvällen jämförde vi det med tidig bildgenerering där hästar hade fem ben och bad om att armen skulle göras om från en bild i stället för att lappas. Den 2 augusti, med en skärmbild: "knogarna ska vara på höger sida av handen, inte på vänster". Sedan: "om du inte får handen rätt den här gången vill jag att du undersöker hur andra gör". Agentens egen sammanfattning den 3 augusti är rakare än rapporten: "Användarens återkoppling var korrekt varje gång och min var det inte."

Med bildfrekvensen gick det likadant: varje subagent ville nå 60 bilder per sekund på en fläktlös dator, ingen kom i närheten och vi kom på varför – flera agenter testade samtidigt, var och en med sin egen webbläsare och grafikkrets, så det som var och en mätte var inte det en spelare skulle se. "Vi gör all utveckling på en MacBook Air. Fps kommer inte att bli perfekt. Dessutom arbetar några andra agenter också. Fortsätt", skrev vi den 1 augusti. Rapporten noterar den kollisionen som ett eget fynd – en systembelastning på 37 på åtta kärnor – och ger "användaren" en enda bisats.

Sedan bad vi om de två saker körningen saknade: "Bygg regressionsgrinden och fundera på hur vi kan gå från ett slumpvandrande arbetsflöde till en tydligt strukturerad och avsiktlig karta över de steg subagenterna behöver ta." Båda finns i kodförrådet nu: grinden som ingen ändring får slås samman utan att ha klarat och en arbetsordning som håller verifieringen till en webbläsare i taget och tillåter en enda ändring av det gemensamma utseendet per runda – en fabrik som kommer inifrån en körning på en enda prompt, två dagar in.

Vad det kostade

Under tre dygn startade körningen 242 subagenter i 34 arbetsflöden – som mest sju samtidigt och aldrig tio. De är kortlivade, i median fyrtio minuter, så totalen växte medan antalet som kördes samtidigt förblev litet: fem eller fler under sjutton av de sjuttiotvå timmarna – trängseln bakom systembelastningen på 37.

De sista sex av de 242 kördes i slutfasen och fem blev klara: ungefär 1,32 miljoner tokens och 654 verktygsanrop på omkring 3,8 timmar, för en skeppad visuell rättning och fyra avslutade utredningar. Den sjätte dog innan den läst en enda fil när kontot slog i veckogränsen för tokens – taket för den här metoden är kvoten och kvoten tar slut utan förvarning. Ungefär en miljon av de tokens gick till den enda utsiktspunkt vars orsak var den saknade avståndstermen.

Var loopen passar

Rapportens avslutande resonemang, som den själv märker som åsikt och inte mätning, är att kostnaden för loopen sätts av kritikern och inte av byggaren. Byggarsidan fungerade; det var att döma arbetet som slukade tokens och den här körningen hade nära nog värsta tänkbara kritiker på varje axel. Två frågor förutsäger utfallet bättre än något annat: finns det ett körbart orakel som svarar ja eller nej utan en modells åsikt och pekar en fallerande kontroll ut det som ska rättas? Att porta ett bibliotek, implementera en specifikation, optimera för snabbhet, balansera ett kortspel över hundratusen simulerade matcher – allt ja. En renderare utan referensbilder: nej på båda.

Vad vi tar med oss in i fabriken

Vi kör agenter tvärtom – steg, kvalitetsgrindar, ett gemensamt register och en granskning av grundaren innan något publiceras, vilket är så den här sajten byggdes och vad fabriksartikeln beskriver. Den här körningen styrdes och styrningarna finns i kodförrådet: armarna, diagnosen av bildfrekvensen, grinden och kartan över steg. Instrumenten byggdes under loopen av den agent vars arbete de dömde och de hade fel sju gånger. Så, för våra egna körningar: bygg instrumentet först och kalibrera det mot en känd defekt, lägg referensen i kritikerns händer före första rundan och håll kvar en människa där en agent inte kan tala om för dig att den har fel. Kontrakten först, byggare som hålls isär från kritiker och ett rent negativt resultat som ett fullgott svar tar vi som de är.

Metoden är det som fick 94 000 rader att köra över huvud taget och rapporten avslutas med att bygga på den: en omarbetad startprompt för den som vill göra om körningen, där tillägget är hur arbetet ska verifieras – namnge referensen, namnge instrumentet, säg vad ett godkänt resultat är innan första agenten startar. Kör den så och den här körningen hade slutat längre fram.

Morrowind nämns här bara som den designförebild experimentet mätte sig mot; Ashlands innehåller inga resurser från de spelen. The Elder Scrolls och Morrowind är varumärken som tillhör ZeniMax Media.

Därför driver vi en agentdriven mjukvarufabrik

Mon, 21 Sep 2026 00:00:00 +0000

Addable Labs bygger mjukvara till stor del med AI-agenter och sedan september 2026 byggs och underhålls den här sajten av det vi kallar fabriken: ett litet team av kodande agenter, organiserat som ett företag, som samordnar sig genom en gemensam ärendehanterare, med en person som är ansvarig för fabriken. Artikeln Så byggdes den här sajten av agenter berättade om ett bygge; den här serien beskriver själva uppsättningen – ett lager i taget – och börjar med den uppenbara frågan: varför driva något sådant över huvud taget och vad bygger det på?

Vad en agent och en person inte kunde göra

nivå byggdes tvärtom: en kodande agent och en person, 480 commits på 26 dagar, varenda en med agenten som medförfattare. Den uppsättningen börjar inte från noll. En fil med arbetsöverenskommelser, fyra nedskrivna rutiner – granskning, kvalitetsgrindar, driftsättning och innehållsändringar – arton anteckningar som agenten för åt sig själv, tio av dem om sådant som vi har rättat, en framstegslogg med en post per session och 105 dokumenterade beslut bär arbetet från en session till nästa.

Det den uppsättningen inte kan är att prata med någon annan än oss. Den 12 september, med fyra agenter på en dator, var och en med sitt eget projekt, lät vi nivå-agenten skriva ett meddelande som vi själva kunde bära till de andra tre och klistrade in det i den regelfil som varje agent på maskinen läser först. Varje uppgift börjar hos oss och när två sessioner behöver veta något om varandra är det vi som bär meddelandet emellan. Det skalar inte till agenter som planerar, bygger, granskar och publicerar medan vi gör något annat och det håller oss kvar i detaljer vi inte vill vara i.

Tre saker behövde ändras: arbetet behövde ligga i ett gemensamt register som vilken session som helst kan ta uppgifter ur, inte i ett enda projekts anteckningar; sessioner behövde kunna lämna över arbete till varandra och följa upp det utan en person emellan; och den som är ansvarig behövde vara inblandad vid några få kända punkter – en plan att godkänna, en gren att läsa innan den pushas – i stället för hela tiden.

Steve Yegges iterationer

Uppsättningen vi driver bygger på öppen källkod som Steve Yegge påbörjade i oktober 2025 med Beads, en ärendehanterare som han beskriver som minne för kodande agenter snarare än som en att-göra-lista för människor. I januari 2026 kom Gas Town, hans orkestreringsverktyg: upp till trettio agentsessioner som samordnar sig genom Beads, ett dussintal aktiva åt gången, med en fast uppsättning roller och en tes som vi har anammat rakt av, med hans egna ord: "en agent är inte en session" (vår översättning) – sessioner är utbytbara, arbetet är beständigt. I april 2026 kom Gas City: med hans egna ord "Gas Town, men sönderplockat och omskrivet från grunden som ett SDK för att bygga egna mörka fabriker" (vår översättning). Han är noga med att säga att han inte skrev det – det gjorde Julian Knutsen och Chris Sells. I augusti 2026 beskrev sedan "Fences, not Sandboxes" den organisation på femtio till sextio agenter som han driver, styrd av skrivna regler snarare än av inlåsning.

Vi gick igenom allt det där den 20 september 2026 och fann att nästan allt vi ville ha – en fabrik per projekt, en samordnare du kan prata med, delegering med uppföljning, ett gemensamt register – redan fanns, underhölls aktivt och var MIT-licensierat. Vi byggde vidare på det i stället för att bygga ännu ett orkestreringsverktyg och körde det första bygget samma eftermiddag.

Gas City och Beads, i korthet

Beads är en kommandoradsbaserad ärendehanterare ovanpå en versionshanterad databas. Varje arbetsenhet är en bead – en uppgift, ett meddelande mellan agenter, en anteckning om en session – med beroenden mellan dem. En bead som blockeras av en annan erbjuds inte till någon agent, och det är så ordningen hålls utan någon central schemaläggare. En agent tar en bead, arbetar, skriver ner vad den gjorde och stänger den; om sessionen dör halvvägs förblir beaden öppen för nästa.

Gas City är orkestreringsverktyget runt det registret och hårdkodar inga roller. En agent är konfiguration: ett namn, en prompt, ett ansvarsområde. En formel är ett arbetsflöde skrivet som steg och beroenden; när den tillämpas blir den en graf av beads som Gas City driver till avslut och startar om sessioner som kraschar. Paket (packs) buntar ihop agenter och formler så att en metodik kan låsas till en version som vilket beroende som helst. Underhållarnas egen regel för ramverket är att det "flyttar arbete; det resonerar inte om det" (vår översättning) – omdömet bor i prompterna.

Vad vi tog och vad vi ändrade

Vi tog principerna som de är. Arbetet består, sessionerna gör det inte. Roller är konfiguration, inte kod. Planerare, byggare och granskare är olika agenter och granskningen går i flera spår. Reglerna står i de filer varje session läser först. Och, från "Fences, not Sandboxes", styrning genom avvisning snarare än inlåsning – ett staket (fence) är, enligt den definition han citerar, "varje mekanism som avvisar dig om du inte ska vara där" (vår översättning).

Yegge driver femtio till sextio agenter; vi kör en handfull sessioner åt gången på en enda dator och siktar på en fabrik per projekt – hittills finns en, för den här sajten. Organisationsschemat är litet: en borgmästare och ett golv av roller tagna som de är från startpaketet i Gas Citys paketregister – krav, plan, plangranskning, nedbrytning, genomförande, tre granskningsspår, en publicerare – var och en startad som en session när ett steg i bygget behöver den och avslutad efteråt. Vårt eget bidrag hittills är borgmästarens prompt, gränser för hur många sessioner en dator kör samtidigt och reglerna för en delad maskin. Grundarens grind sitter vid planen, sedan det andra bygget. Ingen agent pushar på egen hand: att publicera betyder en gren som vi läser lokalt och ingenting når GitHub förrän vi säger till. Vi pratar med borgmästaren via Discord.

Ett bygge, i siffror

Omdesignen av den här sajten var fabrikens andra bygge och dokumenten den skrev finns i kodförrådet. Det började den 20 september 2026 klockan 17:34 UTC med en kort uppdragsbeskrivning och granskningsrapporten färdigställdes 00:14 nästa morgon: sex timmar och fyrtio minuter från start till mål. Däremellan tog kravsteget fram 31 krav med acceptanskriterier; plansteget renderade tre designriktningar som riktiga sidor – vi såg dem redan på förhandsvisningsservern och valde en inom två minuter efter att ha fått frågan – och godkände den granskade planen 19:45; nedbrytningen gav tio arbetspaket; en genomförandeagent arbetade sig igenom dem i fyra sessioner och 22 commits; och tre granskningsspår hittade två fel som måste rättas, vilket ett rättningsspår gjorde innan rapporten skrevs. Grenen slutade på 39 commits som rörde 90 källfiler, klarade tio automatiska kvalitetsgrindar, 101 tester och Lighthouse-poäng på 97 till 100 på alla sju sidor som kontrolleras. Vår del var sex korta meddelanden medan körningen pågick – valet, våra rättelser, svaren vid plangrinden – och morgonen därpå vårt omdöme om den färdiga sidan. Själva körningen var 112 beads, 17 agentsessioner i tio roller och tio mejl mellan borgmästaren och golvet som vi aldrig behövde bära; ingenting blev offentligt enbart på agenternas ord.

Det första bygget, tidigare samma dag, tog ungefär fyra timmar för 27 krav och tio arbetspaket, behövde en rättning och hade ingen grind före slutet: vi såg resultatet när det var klart och gillade inte utseendet. Ingen av körningarna var felfri. I den första tog en session en administrativ post i registret i stället för sin uppgift och behövde fjorton minuter för att ta sig runt det; den skrev ner lösningen i sina anteckningar och när det andra byggets första session råkade ut för samma kapplöpning var den igång med sin uppgift inom en minut. Båda körningarna lämnade oss en lista med öppna punkter; vi ser de listorna som en del av produkten.

Tack

Inget av det här skulle finnas utan Steve Yegges vilja att bygga öppet och att släppa Beads och Gas Town under en licens som lät oss bygga vidare på dem – och inte heller utan Julian Knutsen, Chris Sells och gemenskapen kring organisationen Gas Town Hall, som byggde Gas City. Tack. Koden finns på GitHub – Gas City, Beads och paketregistret – och essäerna finns på Yegges webbplats: Welcome to Gas Town, Welcome to Gas City, Fences, not Sandboxes och Beads Best Practices.

Vad som kommer härnäst

De kommande artiklarna tar uppsättningen ett lager i taget – rollerna, de beads som agenterna kommunicerar genom, en begärans väg, reglerna en ändring måste klara, vad grundaren ser och beslutar, vad som gick fel och vad det kostar.

Så byggdes den här sajten av agenter

Sun, 20 Sep 2026 00:00:00 +0000

Addable Labs bygger mjukvara till stor del med AI-agenter och den här sajten är det första som en agentdriven mjukvarufabrik tog fram åt företaget från början till slut, i två byggen. Den här artikeln beskriver stegen, vad vi tittade på och de kontroller som står mellan en agents ändring och en publicerad sida.

Stegen

Varje körning gick igenom en fast sekvens och varje steg skrev ett dokument som nästa steg var tvunget att läsa: krav, en plan, en granskning av den planen, en nedbrytning i arbetspaket, genomförandet, en granskning av resultatet och publicering. Kraven förvandlade en kort uppdragsbeskrivning till numrerade påståenden med acceptanskriterier. I det första bygget valde planen tekniken och låste URL-strukturen, artiklarnas schema och färgpaletten, med de alternativ den förkastade; i det andra valde den designsystemet. Nedbrytningen delade upp planen i arbetspaket, vart och ett med ett eget beviskommando och en agent genomförde dem ett i taget på en lokal gren.

Vad grundaren granskar

Ingenting på den här sajten blir offentligt enbart på en agents ord. Men det första bygget kördes utan grind: krav, plan och tio arbetspaket gick igenom på fyra timmar och grundarens omdöme om den färdiga sajten var "en sida från 90-talet". Det andra bygget satte vår grind vid planen: vi valde en av tre renderade riktningar, svarade på planens öppna frågor och gav vårt omdöme om resultatet på förhandsvisningen morgonen därpå. Vi äger de delar som ingen agent kan avgöra: formuleringarna om företaget, den svenska texten, vilka privata projekt som får nämnas och stegen som rör domänen och driften.

Kvalitetsgrindarna

Ett enda kommando kör varje kontroll och samma kommando är inställt att köras på varje pull request. Det bygger webbplatsen, kontrollerar att varje intern länk leder någonstans, validerar HTML-koden, kontrollerar strukturen på varje sida – landmärken, en enda huvudrubrik, en hopplänk, alt-text – mäter kontrasten för varje färgpar i båda teman, bekräftar att varje engelsk sida har en svensk motsvarighet och att de två uppsättningarna gränssnittstexter har samma nycklar, validerar flödena och söker igenom resultatet efter de fakta som sidorna måste ange. Varje kvalitetsgrind har ett test som bevisar att den misslyckas när något medvetet har gjorts sönder.

Två ärliga iakttagelser

Det mesta av det agenterna skrev var inte kod: i det första bygget 6 900 rader krav, planer, sammanfattningar och granskningar mot 3 700 rader webbplats, kvalitetsgrindar och tester. Precision i dokumenten betydde mer än finurlighet i koden: den enda rättning som granskningen krävde var en grind som hade hårdkodat en platshållare som vi ska byta ut.

Kvalitetsgrindarna fångar mekaniska misstag, inte osanningar: en saknad svensk sida eller en färg som inte klarar kontrastkravet fångas automatiskt; om en mening om en produkt är sann kan de däremot inte avgöra. Därför kan fakta om apparna spåras till en källa – den README som var och en hämtades från och datumet då den lästes – och vi läser ändå allt. Agenterna gjorde också misstag: en session tog en administrativ post i registret i stället för sin uppgift och behövde fjorton minuter för att ta sig runt det.

Webbplatsen är enkel: statisk HTML och CSS, två små skript (ett som växlar mellan mörkt och ljust läge och ett som tonar in innehållet när du rullar; sidan fungerar utan båda), ett typsnitt vi levererar från vår egen server och inga anrop till tredje part, ingen webbanalys. Det var ett beslut och den del som spelar roll – att inget laddas från någon annans servrar – verifieras av en kvalitetsgrind vid varje bygge.