Pi Coding Agent: Bygga flexibla AI-verktyg för verkliga arbetsflöden

Introduktion

Kod är aldrig gratis. Det är det centrala argumentet som Mario Zechner, skaparen av Pi, framför när han diskuterar läget för AI-assisterad utveckling år 2026. Även om agenter snabbt kan generera stora mängder kod, kommer konsekvenserna av den koden förr eller senare ikapp dig. Pi finns för att Zechner upptäckte att befintliga kodningsagenter inte passade hans arbetsflöden, och istället för att anpassa sig byggde han ett verktyg som anpassar sig efter honom.

Detta samtal täcker varför arbetsflödesstabilitet betyder mer än funktionshastighet, hur man faktiskt arbetar med kodningsagenter utan att bli utbränd, och varför branschen kan vara på väg att upprepa ett 30 år gammalt misstag med specifikationsdriven utveckling.

Varför Pi finns: Arbetsflödesflexibilitet framför stabilitet

När Claude Code först lanserades var Zechner nöjd med det. Med tiden blev dock verktygets högfrekventa utgivningstakt ett problem. Claude Code får en till tre uppdateringar per dag, och med varje version följer ändringar i verktygsdefinitioner, systemprompter och underliggande beteende. För någon som bygger anpassade promptmallar, slash-kommandon och arbetsflödesbeskrivningar, förstör dessa osynliga ändringar saker.

Själva modellen verkade bete sig annorlunda från dag till dag, trots att modellversionen förblev densamma. Zechner tillskriver detta delvis ändringar i “harness”-miljön – infrastrukturen och systempromptarna som formar hur en modell svarar. Att testa effekterna av ändringar i harness-miljön på utdatakvalitet är svårt eftersom det inte finns något deterministiskt sätt att mäta det. Resultatet är att utvecklare som Zechner inte kan lita på att verktyget beter sig konsekvent, vilket motverkar syftet med att bygga anpassade arbetsflöden kring det.

Pi föddes ur denna frustration. Det är en minimal, utbyggbar kodningsagent som kan modifiera sig själv för att passa dina arbetsflöden istället för att tvinga dig att anpassa dig till dess begränsningar. Den underliggande arkitekturen abstraherar bort LLM-leverantörer, inkluderar ett bibliotek för terminalgränssnitt och tillhandahåller generella abstraktioner för agentloopar. Men den största skillnaden är kontroll: Zechner dikterar designen och kan ändra den utan att vänta på en leverantörs utgivningscykel.

Hur Pi faktiskt fungerar: Parallell bearbetning och manuell granskning

Zechners dagliga arbetsflöde med Pi är metodiskt och medvetet lågteknologiskt. Han kör inte en armé av agenter parallellt. Istället använder han en “grottmannametod”: köar upp flera sessioner, där varje session analyserar ett separat ärende från ärendehanteraren, för att sedan granska och iterera på varje enskild del.

För buggfixar och funktionsimplementeringar börjar processen med en ärendebeskrivning. Zechner matar in ärendet till en agent med en anpassad promptmall som säger: hämta all relevant information, ignorera analysen i ärendet och gör din egen analys baserat på vad vi vill uppnå. Detta analyssteg tar cirka fem minuter per ärende. Han öppnar en andra session för nästa ärende, en tredje för ett annat, och skapar på så sätt en parallell förbearbetningspipeline.

När agenten har analyserat ett ärende granskar Zechner förslagen, kontrollerar koden själv och återskapar problem manuellt vid behov. Han använder agenten som en “rubber duck” – en samtalspartner – tills han är överens med sig själv om implementeringsmetoden. När han väl ger agenten i uppdrag att implementera, innehåller kontexten så många skyddsräcken att agenten vet exakt vilka gränssnitt som ska ändras, vilka moduler som ska röras och hur tester bör fungera.

Implementeringen tar ytterligare 10 till 30 minuter. När agenten signalerar att den är klar tar Zechner fram en diff-vy och kommenterar enskilda rader med feedback. Han klickar på slutför, feedbacken matas automatiskt tillbaka till agenten och iterationen fortsätter tills koden är bra. För kärnmekanik granskar han varje ändring som han skulle göra med en människa. För andra delar godkänner han utan djupgående inspektion.

Detta arbetsflöde fungerar eftersom Zechner har över 10 års erfarenhet av kodbaser. Han vet vad som fungerar och vad som inte gör det. För nya utvecklare eller de utan den erfarenheten skulle tillvägagångssättet vara annorlunda – och mer riskfyllt.

Verkligheten kring specifikationsdriven utveckling

Branschen upprepar ett 30 år gammalt misstag. Vattenfallsmodellen bevisades vara ineffektiv för decennier sedan, men med AI-agenter är vi tillbaka i ett hyper-vattenfall: att skriva detaljerade specifikationer och låta agenter implementera dem. Den enda skillnaden är att du nu inte ens skriver specifikationen själv – du “vibe-promptar” en agent att skriva en mycket detaljerad specifikation, som sedan en annan agent implementerar.

Problemet är fundamentalt. En komplett specifikation är i princip själva programmet. Om du skriver en specifikation i naturligt språk lämnar du luckor. Agenten fyller dessa luckor med vilka mönster den än har lärt sig från 20 års kod på internet – varav mycket är skräp. Resultatet är en kodbas som ser ut som “vibe-kodad” mjukvara, eftersom det är precis vad det är.

Det finns ett motargument: kod är numera billigt och iteration går snabbt. Tidigare kunde en vattenfallsspecifikation ta månader att implementera. Nu kan det ta en dag. Du kan testa dig igenom det manuellt. Men Zechner har ännu inte sett bevis på att detta faktiskt fungerar för produktionsmjukvara. Han misstänker att utvecklare förr eller senare kommer att vakna mitt i natten och inse att allt är trasigt.

Med det sagt finns det begränsningar där agentdriven utveckling är vettig. Buns omskrivning från Zig till Rust fungerade eftersom projektet hade en omfattande testsvit. Agenten kunde i viss mån verifiera sitt eget arbete. I sådana fall är verktyg som detta genuint användbara. Men för det mesta av mjukvaruutveckling är tillvägagångssättet riskabelt.

Hantera öppen källkod i stor skala: Clanker-problemet

Innan agenter fanns kunde ett framgångsrikt projekt med öppen källkod få en eller två pull requests per vecka. Pi får nu 50 till 60 pull requests per dag – alla från agenter (Zechner kallar dem “clankers”). Varje PR har en beskrivning som en hel Harry Potter-bok och inkluderar mellan 10 och 1 000 filändringar.

Standardpositionen är att deklarera varje agentgenererad PR som skräp och automatiskt stänga den. Men Zechner hittade en lösning: kräv att folk först skriver ett ärende med sin egen röst, inte längre än en skärm, där de förklarar exakt vad de vill göra och varför. Om ärendet är bra godkänner han det och personen kan skicka en PR. Detta bevisar att de är människor, att de förstår problemet och att de förstår lösningen.

När de väl är godkända kommer meningsfulla PRs in. Clanker-PRs slutar dyka upp. Ärenden fortsätter att strömma in, men Zechner triagerar dem manuellt. Han läser igenom 30 till 60 stängda ärenden per dag och identifierar vilka som är legitima och vilka som är skräp. I hans senaste triageringsrunda kom 50 ärenden in och 2 överlevde. Det tar cirka 30 minuter eftersom de flesta är lätta att identifiera som brus.

För projekt i OpenClaws skala fungerar inte detta manuella tillvägagångssätt. Peter Steinbergs token-förbrukning nådde 1,3 miljoner dollar per månad, delvis för att automatisering av ärende- och PR-filtrering i den skalan kräver sofistikerad infrastruktur. Zechner skrev några visualiseringsverktyg för att hjälpa till att klustra liknande ärenden, men inte ens det räckte. Volymen är storleksordningar större.

Lokal inferens och framtiden för mindre modeller

Zechner är optimistisk när det gäller att köra kapabla AI-modeller lokalt på konsumenthårdvara. För sitt robotprojekt – en leksak med en smartphone som mikrokontroller som kör en kodningsagent – använder han Gemma 4 och Qwen 3.6, mindre “mixture-of-experts”-modeller. De är mer än tillräckliga för en chattbot med motor- och kamerakontroll, och de är snabba.

Installationen är prisvärd. Tal-till-text med Parakeet tar cirka 10 gigabyte enhetligt minne. Text-till-tal med Qwen TTS tar ytterligare 10 gigabyte. Qwen 3.6 tar 4 gigabyte. Totalt: 14 gigabyte enhetligt minne på macOS eller en motsvarande NVIDIA-installation på Windows. Det är överkomligt för många människor, inte hela världen, men en betydande del.

Denise Asaves från DeepMind har föreslagit att nuvarande gigantiska modeller inte behöver alla sina parametrar och kan destilleras ner till mycket mindre modeller utan att förlora särskilt mycket utdatakvalitet. Zechners hopp är att framtiden innebär att destillera stora modeller till mindre som behåller de flesta förmågor, snarare än att träna specialiserade modeller för specifika uppgifter. Antirez från Redis har börjat arbeta på en anpassad inferensmotor för DeepSeek V4 kallad ds4, som körs på en 128-gigabyte bärbar dator. Det är en riktigt kapabel modell som skulle kunna hantera 60 till 70 procent av de ärenden Zechner hanterar med Pi.

Kostnaden för kod och hantverkets disciplin

Zechner har sett människor generera 500 000 rader kod via agenter på en vecka. Resultatet är alltid detsamma: katastrof. Kod är aldrig gratis eftersom konsekvenserna förr eller senare drabbar dig. Om du tror att vilken mängd kod som helst är bra nu, har du bara skjutit upp straffet.

Den verkliga flaskhalsen i mjukvaruutveckling är inte skrivhastighet eller kodgenerering. Det är att tänka, designa och utforska lösningsrymden. Agenter är genuint användbara för den fasen – du kan be flera agenter utforska olika tillvägagångssätt och se resultaten snabbare. Men utdatan från dessa utforskningar är inte automatiskt återanvändbar. Du måste fortfarande förstå den, refaktorera den och underhålla den.

För Zechner kommer den största produktivitetsökningen från agenter från arbetets asynkrona natur. Han kan ge en agent en uppgift, gå på ett möte och komma tillbaka till resultaten. Men han tror inte att det att köra 10 agenter parallellt kommer att ge 10x hans output. Kontextbytet i sig är utmattande. Han har gjort det en eller två gånger i månaden, bearbetat 30 ärenden på en dag, och hans hjärna är mos efteråt.

Det samarbetande perspektivet är det han värdesätter mest. Att ha en agent som en parprogrammeringspartner – ställa frågor, föreslå alternativ, förklara kod – är som en cykel för sinnet. Det hjälper honom att tänka igenom problem bättre än att sitta ensam. Men det kräver disciplin: att inte delegera allt till maskinen, för varje gång han gör det hamnar han i ett hörn och gråter eftersom ingenting är bra längre och allt faller samman.

Refaktorering av Pi: Bygga för framtiden

Pi har samlat på sig historiskt bagage. Delar av det föregår Zechners användning av agenter och är solida. Andra delar, som HTML-exporten, har han aldrig tittat på och bryr sig inte om så länge det renderas. Vissa delar är “vibe-kodade”.

Refaktoreringsarbetet har flera mål. För det första, att lättare expandera till andra typer av användargränssnitt – webb, native, vad som helst – utan att förstöra befintliga tillägg. För det andra, möjliggöra fjärrkapacitet: kör en Pi-session på en maskin och anslut till den från en annan, med korrekt hållbarhet och observerbarhet. För det tredje, göra Pi:s SDK distribuerbart på Cloudflare Workers, Vercel och andra miljöer, inte bara lokala datorer med bash.

Zechner refaktorerar på huvudgrenen eftersom han inte bryr sig om stabilitet i traditionell mening. Han gör det bit för bit, med början i de lägsta paketen som pratar med LLM-leverantörer. Själva kodningsagenten kommer fortfarande att se ut och fungera likadant, men all underliggande infrastruktur kommer att vara ren och återanvändbar. Han hoppas kunna avsluta den fasen om en eller två veckor, för att sedan spendera några veckor till på den nya tilläggsmekanismen där tillägg har server-side och UI-side komponenter.

Varför Pi körs i YOLO-läge som standard

Pi ber inte om tillåtelse innan kod exekveras. Detta är avsiktligt. Genom att berätta för folk att YOLO-läge är farligt och att de bör tänka på det, får Zechner faktiskt folk att tänka på säkerhet. Han vill att de ska titta inåt för säkerhetsmedvetenhet och bestämma hur de ska skydda agentiskt arbete i sin egen miljö.

Svaret är oftast containerisering. Om du inte vill att agenten ska förstöra din dator, containerisera agenten eller verktygen den använder – fil-läsning/skrivning, bash, vad som helst. Det löser problemet. Men Zechner kan inte bestämma detta åt dig. Han skulle kunna paketera Anthropic’s sandbox eller bubble wrap, men dessa är ofullständiga lösningar. I en företagsmiljö med specifika infrastrukturkrav kanske en inbyggd sandbox inte fungerar alls.

Det som finns i Claude Code är mestadels säkerhetsteater. Claude Code frågar nu en LLM om ett bash-kommando är säkert innan det exekveras i auto-läge. Zechner tycker inte att det är bra. En LLM kan inte på ett tillförlitligt sätt avgöra om ett kommando är säkert – den kan bara gissa baserat på mönster.

Slutsats

Pi representerar en annan filosofi: bygg verktyg som utvecklare kan äga och modifiera, inte verktyg som äger utvecklare. Framgången för Pi mäts inte i funktioner eller benchmarks, utan i om Zechner kan hålla ett litet team vid liv och fortsätta utforska tillämpningar av agentiskt arbete – från kodning till robotik till lokal inferens.

Den bredare lärdomen är att arbetsflöden betyder mer än hype. Stabilitet, förutsägbarhet och förmågan att anpassa dina verktyg är värda mer än den senaste funktionen. Och kod är aldrig gratis – konsekvenserna av dina handlingar kommer förr eller senare ikapp dig.