Pi Coding Agent: Flexibele AI-tools bouwen voor echte workflows

Introductie

Code is nooit gratis. Dat is het centrale argument van Mario Zechner, de maker van Pi, wanneer hij de staat van AI-ondersteunde ontwikkeling in 2026 bespreekt. Hoewel agents snel enorme hoeveelheden code kunnen genereren, halen de consequenties van die code je uiteindelijk altijd in. Pi bestaat omdat Zechner merkte dat bestaande coding agents niet in zijn workflows pasten, en in plaats van zich aan te passen, bouwde hij een tool die zich aan hem aanpast.

Dit gesprek gaat over waarom workflow-stabiliteit belangrijker is dan de snelheid van nieuwe functies, hoe je daadwerkelijk met coding agents kunt werken zonder een burn-out te krijgen, en waarom de industrie mogelijk een 30 jaar oude fout herhaalt met specificatiegestuurde ontwikkeling.

Waarom Pi bestaat: Workflow-flexibiliteit boven stabiliteit

Toen Claude Code voor het eerst werd gelanceerd, was Zechner er tevreden over. Na verloop van tijd werd het hoge release-tempo van de tool echter een probleem. Claude Code krijgt één tot drie updates per dag, en met elke release komen er wijzigingen in tooldefinities, systeemprompts en het onderliggende gedrag. Voor iemand die aangepaste prompt-templates, slash-commando’s en workflow-beschrijvingen bouwt, zorgen deze onzichtbare wijzigingen voor problemen.

Het model zelf leek zich van dag tot dag anders te gedragen, ook al bleef de modelversie hetzelfde. Zechner schrijft dit deels toe aan wijzigingen in de “harness”—de infrastructuur en systeemprompts die bepalen hoe een model reageert. Het testen van de effecten van wijzigingen in de harness op de outputkwaliteit is lastig omdat er geen deterministische manier is om dit te meten. Het resultaat is dat ontwikkelaars zoals Zechner niet kunnen vertrouwen op consistent gedrag van de tool, wat het doel van het bouwen van aangepaste workflows eromheen tenietdoet.

Pi is voortgekomen uit deze frustratie. Het is een minimale, uitbreidbare coding agent die zichzelf kan aanpassen aan jouw workflows in plaats van je te dwingen je aan te passen aan zijn beperkingen. De onderliggende architectuur abstraheert LLM-providers, bevat een terminal user interface-bibliotheek en biedt algemene abstracties voor agent-loops. Maar het belangrijkste verschil is controle: Zechner bepaalt het ontwerp en kan het wijzigen zonder te wachten op de releasecyclus van een leverancier.

Hoe Pi daadwerkelijk werkt: Parallelle verwerking en handmatige controle

De dagelijkse workflow van Zechner met Pi is methodisch en bewust low-tech. Hij draait geen leger aan agents parallel. In plaats daarvan gebruikt hij een ‘holbewoners’-aanpak: zet meerdere sessies in de wachtrij, die elk een ander issue uit de tracker analyseren, en beoordeel en itereer vervolgens op elk daarvan.

Voor bugfixes en de implementatie van functies begint het proces met een issue-beschrijving. Zechner voert het issue in bij een agent met een aangepaste prompt-template die zegt: haal alle relevante informatie op, negeer de analyse in het issue en voer je eigen analyse uit op basis van wat we willen bereiken. Deze analysestap duurt ongeveer vijf minuten per issue. Hij opent een tweede sessie voor het volgende issue, een derde voor nog een, en creëert zo een parallelle voorverwerkingspijplijn.

Zodra de agent klaar is met het analyseren van een issue, beoordeelt Zechner de suggesties, controleert hij de code zelf en reproduceert hij problemen handmatig indien nodig. Hij gebruikt de agent als een ‘rubber duck’—een denkpartner—totdat hij het met zichzelf eens is over de implementatie-aanpak. Tegen de tijd dat hij de agent vertelt om te implementeren, bevat de context zoveel vangrails dat de agent precies weet welke interfaces hij moet aanpassen, welke modules hij moet aanraken en hoe tests moeten werken.

De implementatie duurt nog eens 10 tot 30 minuten. Wanneer de agent aangeeft dat hij klaar is, opent Zechner een diff-viewer en voorziet hij individuele regels van feedback. Hij klikt op voltooien, de feedback wordt automatisch teruggevoerd naar de agent en de iteratie gaat door totdat de code goed is. Voor kernmechanismen beoordeelt hij elke wijziging zoals hij dat bij een mens zou doen. Voor andere onderdelen keurt hij ze goed zonder diepe inspectie.

Deze workflow werkt omdat Zechner meer dan 10 jaar ervaring heeft met codebases. Hij weet wat werkt en wat niet. Voor nieuwe ontwikkelaars of degenen zonder die ervaring zou de aanpak anders—en risicovoller—zijn.

De realiteit van specificatiegestuurde ontwikkeling

De industrie herhaalt een 30 jaar oude fout. Waterfall-ontwikkeling bleek decennia geleden al ineffectief, maar met AI-agents zijn we terug bij ‘hyper-waterfall’: gedetailleerde specificaties schrijven en agents deze laten implementeren. Het enige verschil is dat je nu niet eens meer zelf de specificatie schrijft—je ‘vibe-prompt’ een agent om een zeer gedetailleerde specificatie te schrijven, die vervolgens door een andere agent wordt geïmplementeerd.

Het probleem is fundamenteel. Een volledige specificatie is in feite het programma zelf. Als je een specificatie in natuurlijke taal schrijft, laat je gaten vallen. De agent vult die gaten op met patronen die hij heeft geleerd van 20 jaar aan code op het internet—waarvan een groot deel rommel is. Het resultaat is een codebase die eruitziet als ‘vibe-coded’ software, omdat dat het ook is.

Er is een tegenargument: code is tegenwoordig goedkoop en iteratie gaat snel. Voorheen kon een waterfall-specificatie maanden duren om te implementeren. Nu kan het een dag duren. Je kunt je er handmatig doorheen testen. Maar Zechner heeft nog geen bewijs gezien dat dit daadwerkelijk werkt voor productiesoftware. Hij vermoedt dat ontwikkelaars uiteindelijk ‘s nachts wakker zullen worden met het besef dat alles kapot is.

Dat gezegd hebbende, zijn er situaties waarin agent-gestuurde ontwikkeling zinvol is. De herschrijving van Bun van Zig naar Rust werkte omdat het project een uitgebreide testsuite had. De agent kon zijn eigen werk tot op zekere hoogte verifiëren. In die gevallen zijn tools als deze oprecht nuttig. Maar voor de meeste software is de aanpak riskant.

Open source op schaal beheren: Het ‘Clanker’-probleem

Voor de komst van agents ontving een succesvol open-sourceproject misschien één of twee pull requests per week. Pi ontvangt nu 50 tot 60 pull requests per dag—allemaal van agents (Zechner noemt ze “clankers”). Elke PR heeft een beschrijving als een volledig Harry Potter-boek en bevat 10 tot 1.000 bestandswijzigingen.

De standaardhouding is om elke door een agent gegenereerde PR als rommel te bestempelen en automatisch te sluiten. Maar Zechner vond een oplossing: vereis dat mensen eerst een issue schrijven in hun eigen woorden, niet langer dan één scherm, waarin ze precies uitleggen wat ze willen doen en waarom. Als het issue goed is, keurt hij het goed en kan de persoon een PR sturen. Dit bewijst dat ze menselijk zijn, het probleem begrijpen en de oplossing begrijpen.

Eenmaal goedgekeurd komen er zinvolle PR’s binnen. De ‘clanker’-PR’s stoppen met verschijnen. Issues blijven binnenstromen, maar Zechner sorteert ze handmatig. Hij leest dagelijks 30 tot 60 gesloten issues door en identificeert welke legitiem zijn en welke rommel. Bij zijn laatste triage kwamen er 50 issues binnen en bleven er 2 over. Het duurt ongeveer 30 minuten omdat de meeste snel als ruis te identificeren zijn.

Voor projecten op de schaal van OpenClaw werkt deze handmatige aanpak niet. Het tokenverbruik van Peter Steinberger bereikte 1,3 miljoen dollar per maand, deels omdat het automatiseren van issue- en PR-filtering op die schaal geavanceerde infrastructuur vereist. Zechner schreef wat visualisatietools om vergelijkbare issues te helpen groeperen, maar zelfs dat was niet genoeg. Het volume is vele malen groter.

Lokale inferentie en de toekomst van kleinere modellen

Zechner is optimistisch over het lokaal draaien van capabele AI-modellen op consumentenhardware. Voor zijn robotproject—speelgoed met een smartphone als microcontroller die een coding agent draait—gebruikt hij Gemma 4 en Qwen 3.6, kleinere ‘mixture-of-experts’-modellen. Ze zijn meer dan voldoende voor een chatbot met motor- en camerabesturing, en ze zijn snel.

De opzet is betaalbaar. Speech-to-text met Parakeet kost ongeveer 10 gigabyte aan unified memory. Text-to-speech met Qwen TTS kost nog eens 10 gigabyte. Qwen 3.6 kost 4 gigabyte. Totaal: 14 gigabyte aan unified memory op macOS of een vergelijkbare NVIDIA-opstelling op Windows. Dat is betaalbaar voor veel mensen; niet voor de hele wereld, maar wel voor een aanzienlijk deel.

Denise Asaves van DeepMind heeft gesuggereerd dat huidige gigantische modellen niet al hun parameters nodig hebben en kunnen worden gedestilleerd tot veel kleinere modellen zonder veel outputkwaliteit te verliezen. De hoop van Zechner is dat de toekomst inhoudt dat grote modellen worden gedestilleerd tot kleinere die de meeste capaciteiten behouden, in plaats van het trainen van gespecialiseerde modellen voor specifieke taken. Antirez van Redis is begonnen met het werken aan een aangepaste inferentie-engine voor DeepSeek V4 genaamd ds4, draaiend op een laptop met 128 gigabyte. Het is een zeer capabel model dat 60 tot 70 procent van de issues die Zechner met Pi afhandelt, zou kunnen verwerken.

De kosten van code en de discipline van het vakmanschap

Zechner heeft mensen in een week tijd 500.000 regels code zien genereren via agents. De uitkomst is altijd hetzelfde: een ramp. Code is nooit gratis omdat de consequenties je uiteindelijk inhalen. Als je denkt dat een grote hoeveelheid code nu goed is, heb je de straf alleen maar uitgesteld.

De echte bottleneck in softwareontwikkeling is niet typsnelheid of codegeneratie. Het is nadenken, ontwerpen en de oplossingsruimte verkennen. Agents zijn oprecht nuttig voor die fase—je kunt meerdere agents vragen om verschillende benaderingen te verkennen en de resultaten sneller zien. Maar de output van die verkenningen is niet automatisch herbruikbaar. Je moet het nog steeds begrijpen, refactoren en onderhouden.

Voor Zechner komt de grootste productiviteitswinst van agents door het asynchrone karakter van het werk. Hij kan een agent een taak geven, naar een vergadering gaan en terugkomen bij de resultaten. Maar hij gelooft niet dat het parallel draaien van 10 agents zijn output met 10x zal verhogen. Het context-switchen alleen al is uitputtend. Hij heeft het één of twee keer per maand gedaan, waarbij hij 30 issues op een dag verwerkte, en zijn brein was daarna volledig ‘pap’.

Het collaboratieve aspect is wat hij het meest waardeert. Een agent hebben als pair-programming partner—vragen stellen, opties voorstellen, code uitleggen—is als een fiets voor de geest. Het helpt hem beter over problemen na te denken dan wanneer hij alleen zit. Maar dat vereist discipline: niet alles delegeren aan de machine, want elke keer dat hij dat doet, eindigt hij in een hoekje huilend omdat niets meer goed is en alles uit elkaar valt.

Pi refactoren: Bouwen voor de toekomst

Pi heeft historische bagage verzameld. Delen ervan dateren van vóór Zechner’s gebruik van agents en zijn solide. Andere delen, zoals de HTML-export, heeft hij nooit bekeken en boeien hem niet zolang het maar rendert. Sommige stukken zijn ‘vibe-coded’.

De refactoring-inspanning heeft verschillende doelen. Ten eerste: gemakkelijker uitbreiden naar andere soorten gebruikersinterfaces—web, native, wat dan ook—zonder bestaande extensies te verbreken. Ten tweede: remote-mogelijkheden inschakelen: één Pi-sessie op één machine draaien en er vanaf een andere verbinding mee maken, met de juiste duurzaamheid en observeerbaarheid. Ten derde: de SDK van Pi inzetbaar maken op Cloudflare Workers, Vercel en andere omgevingen, niet alleen op lokale computers met bash.

Zechner refactort op de main-branch omdat hij niet geeft om stabiliteit in de traditionele zin. Hij doet het stukje bij beetje, beginnend met de laagste pakketten die communiceren met LLM-providers. De coding agent zelf zal er nog steeds hetzelfde uitzien en werken, maar alle onderliggende infrastructuur zal schoon en herbruikbaar zijn. Hij hoopt die fase over een week of twee af te ronden, en daarna nog een paar weken te besteden aan het nieuwe extensiemechanisme waarbij extensies server-side en UI-side componenten hebben.

Waarom Pi standaard in YOLO-modus draait

Pi vraagt niet om toestemming voordat het code uitvoert. Dit is opzettelijk. Door mensen te vertellen dat YOLO-modus gevaarlijk is en dat ze erover na moeten denken, dwingt Zechner mensen daadwerkelijk na te denken over beveiliging. Hij wil dat ze in zichzelf op zoek gaan naar beveiligingsbewustzijn en beslissen hoe ze agent-werk in hun eigen omgeving willen beveiligen.

Het antwoord is meestal containerisatie. Als je niet wilt dat de agent je computer kapotmaakt, containeriseer dan de agent of de tools die hij gebruikt—bestand lezen/schrijven, bash, wat dan ook. Dat lost het probleem op. Maar Zechner kan dit niet voor jou beslissen. Hij zou Anthropic’s sandbox of ‘bubble wrap’ kunnen bundelen, maar dit zijn onvolledige oplossingen. In een bedrijfsomgeving met specifieke infrastructuurbeperkingen werkt een ingebouwde sandbox misschien helemaal niet.

Wat in Claude Code bestaat, is grotendeels ‘security theater’. Claude Code vraagt nu aan een LLM of een bash-commando veilig is voordat het in de auto-modus wordt uitgevoerd. Zechner vindt dat niet goed. Een LLM kan niet betrouwbaar bepalen of een commando veilig is—hij kan alleen gokken op basis van patronen.

Conclusie

Pi vertegenwoordigt een andere filosofie: bouw tools die ontwikkelaars kunnen bezitten en aanpassen, in plaats van tools die de ontwikkelaars bezitten. Het succes van Pi wordt niet gemeten in functies of benchmarks, maar in of Zechner een klein team in leven kan houden en toepassingen van agent-werk kan blijven verkennen—van coderen tot robotica tot lokale inferentie.

De bredere les is dat workflows belangrijker zijn dan hype. Stabiliteit, voorspelbaarheid en het vermogen om je tools aan te passen zijn meer waard dan de nieuwste functie. En code is nooit gratis—de consequenties van je acties zullen je uiteindelijk inhalen.