Spec-driven development wordt steeds trager

Een paar maanden geleden heb ik heel lang aan een projectmanagementsysteem gebouwd (SCRUM / Evidence Based Management geïnspireerd) en eindigde ik met iets dat ik niet volledig begreep, en dat gebrekkig was op manieren die ik niet snel kon fixen. Dat is het eerlijke startpunt van deze post. De tooling die ik gebruikte was de superpowers plugin voor Claude Code, die bijna al het bouwwerk door een zware productie pipeline stuurt: brainstorm, design spec, implementation plan, TDD, subagent-driven development met een reviewer per taak. Op papier is dat precies wat je wil als je om kwaliteit geeft. In de praktijk, met de nieuwste modellen (Fable 5 en Opus 4.8 op dat moment), produceerde het rigoureuze code in richtingen die ik niet wilde, in een tempo dat bijsturen duur maakte. Ik was echt snel door mijn Claude abonnement heen, waardoor ik me ook begon af te vragen of de echte frontier modellen het eigenlijk nog wel waard zijn.

Het was een stuk beter om superpowers te gebruiken toen de modellen minder intelligent waren. Nu ze slimmer zijn geworden voelt het eigenlijk alsof de kwaliteit achteruitgaat. De modellen deden allebei: ze overbouwden sommige dingen, maar vooral dreven ze af van wat ik wilde, features op de verkeerde manier bouwend terwijl het heel lang duurde. Een goedkoper, minder intelligent model liet me het werk een stuk sneller doen, en hoewel het niets in één keer goed deed, was dat vanaf het begin nooit het doel.

Dus heb ik superpowers geforked en er two-speed lanes in gestopt. Volle spec-and-review ceremonie op elke taak brandde mijn abonnement op en vertraagde de build tot een slakkengang, dus de fork houdt de strengheid van upstream waar die loont en slaat die over waar dat niet zo is, en staat standaard op de goedkope lane. Ik ben ook niet de enige die klaagt, meerdere gebruikers melden dat ze vinden dat superpowers langzamer wordt (issue 2017). Een dag nadat ik de routing change had toegevoegd, bracht upstream onafhankelijk zijn eigen antwoord op dezelfde pijn uit: een three-path router, gereleased in v6.3.0. Het probleem was echt.

Wat de fork er daadwerkelijk aan toevoegt

Twaalf commits in drie dagen eind juli, grofweg 2.200 regels aan nieuwe skills en docs. De eval infrastructuur die ik schreef en terugdraaide meegerekend zijn er zo’n 3.000 regels geschreven en 760 teruggedraaid. De lanes:

• experiment en harden-experiment: een zero-ceremony throwaway lane. Elk experiment houdt een klein levend document bij waarin staat wat gevalideerd is, wat verworpen is, wat dirty is, en een iteratielog. Zodra een experiment zichzelf bewezen heeft, leest harden-experiment dat document en bouwt het ding opnieuw onder de echte pipeline. De experiment code is bewijs, niet de implementatie: die wordt herschreven, nooit gepromoot.

• quick-spec en promote-quick-spec: een lean intent lock van drie bullets (files, logic, risk) met een expliciete go/no-go vóór elke implementatie, en daarna een full-auto hardening run: compressed design, edge cases, security, test strategie, subagent-driven execution. Kwaliteit mag groeien, de product scope niet.

• quick-review: een snelle pre-commit diff scan op bugs, debug restjes en secrets. Geen vervanging voor een echte review op productiewerk.

• tokenburn: bouwt een evidence pack van een sessie (transcripts, task briefs, review diffs, commit lijsten) zodat een derde partij kan beoordelen hoe het agent process ging: waste, scope creep, loops, dubbele reviews. Het meet proces, geen tokens, en verzint nooit token aantallen.

Bovenop de lanes zit een routing patch: “let’s build X” gaat niet langer stilletjes de volledige design flow in. Je krijgt één kort menu, het staat standaard op de experiment lane, en volledige brainstorming draait alleen als je die kiest, of als er een hard gate van toepassing is (auth, payments, security) en je bevestigt.

De tradeoffs die er echt toe deden

Herschrijven, niet promoten

De experiment lane gooit bewust zijn eigen code weg. Als een gevalideerd experiment gehard wordt, wordt de code niet meegenomen, die wordt herschreven onder de volledige pipeline, en het enige dat overleeft is het levende document. Dat betekent het echte ding twee keer schrijven, en dat is de prijs. Ik vind dat prima, omdat de throwaway bestaat om erachter te komen wat je eigenlijk wil, en hem promoten zou elke gok die hij onderweg maakte meenemen. Het document is het feature memory: het zorgt dat er een echte spec geschreven kan worden nadat de chat context allang weg is, zonder dirty code de productie in te slepen.

De reverts van dezelfde dag

Op 29 juli schreef ik grofweg 760 regels eval infrastructuur: een bash test suite met fixtures, en daarna een lokale eval harness met vijf scenario’s. Ik draaide ze allebei dezelfde dag terug. Het sloeg eigenlijk nergens op om een benchmark te maken voor een human-in-the-loop fast-iteration workflow, er is geen manier om er een te maken, denk ik tenminste. Wat echt zou helpen is een manier om de hele applicatie snel visueel te zien, zodat je ziet dat het model begint af te drijven en het kan vangen voordat het volledig ontspoort. Die tool bestaat nog niet, niet in de fork en nergens waar ik heb gekeken, en dat is de gap die nog openstaat.

Scope lock boven scope creep

In de promote lane is toegestane groei het harden van hetzelfde gedrag: null en ongeldige inputs, races, authorization, injection, retries, tests die onverwachte states verbieden. Verboden is elke nieuwe user-visible feature. Onverwacht gedrag moet er door tests uitgedwongen worden, niet weggehoopt. De prijs is dat de lane star aanvoelt wanneer de originele spec iets echts blijkt te missen, maar daar is de experiment lane voor: fix de intent daar, en promote daarna.

De audit

Ik bouwde het meetinstrument en richtte het meteen op de sessie die het gemotiveerd had. Eén slice van het werk aan het managementsysteem kostte grofweg 27 subagent runs voor 11 taken, plus een final review. De product uitkomst was goed, rond de 897 tests green en een schone typecheck. De proces kosten waren dat niet. Eén enkele fix loop kostte drie commits en drie review passes: de eerste fix over-generaliseerde en creëerde de volgende finding, en de correcte fix was smaller. Die ene taak at ongeveer 22 procent van alle subagent runs, één taak van de elf. Ondertussen betaalden de puur mechanische taken nog steeds voor een volledig paar van implementer en reviewer, en de final whole-branch review herhaalde vooral issues die al bekend waren. Dezelfde sessie had als contrast een slice die op de inline manier gedaan was, en die was sneller met minder redundante gates. De audit draaide op 30 juli, en de quick-spec hardening commits landden de dag erna: de meting voedde de tooling.

Eerlijke caveats

Alles wat ik weet over of dit werkt komt uit mijn eigen sessies. Geen één ander mens heeft de fork gebruikt, en het is misschien niet voor iedereen een goede workflow fit. Ik heb gemerkt dat mijn kwaliteit en snelheid omhooggaan, maar dat is niet gemeten, het is meer een gevoelsding, al heb ik wel echte wall-clock verschillen gemerkt door gebruik te maken van mijn workflow.

De fork is lokaal. Er is geen remote, geen pull request, hij is alleen bij mij geïnstalleerd, dus je kunt hem niet installeren. Beide eval pogingen werden binnen een paar uur teruggedraaid, dus niets bewaakt het gedrag van de skills behalve dat ik ze gebruik. En de promote stap van de fork zelf is net zo langzaam als het ding dat hij moest fixen: vandaag, terwijl ik dit schrijf, heb ik een experiment naar een echte spec gepromoot en het speccen draait nu al anderhalf uur. Dat is veel te lang om snel te itereren en ik zou echt graag willen dat het sneller was.

Upstream bracht zijn three-path router uit in v6.3.0 op 12 augustus. Ik heb er nog niet naar gekeken, ik heb de tijd er niet voor gehad. Dus als deze post zegt dat de pijn onafhankelijk gediagnosticeerd was, is dat gebaseerd op weten dat de router bestaat, niet op hem gelezen te hebben.

Waar het nu staat en wat er daarna komt

De fork is wat ik nu gebruik: hij is geïnstalleerd als mijn eigen plugin en de officiële staat uitgeschakeld. Het is een secundair project, ik heb een paar ideeën om het beter te maken, maar ik wil eerst meer data verzamelen door het te gebruiken. Het managementsysteem dat dit allemaal motiveerde is vanaf nul herbouwd met de learnings, kostte ongeveer evenveel tijd, en is nu iets waar ik echt blij mee ben. Over dat systeem schrijf ik later apart.

Het enige dat ik zou meenemen: het model dwingen om dingen visueel aan de gebruiker te laten zien, verschillende visuele representaties die de gebruiker snel kan verwerken. Concreet: een manier om snel database schema’s en API routes te zien, een korte manier om te lezen wat iets doet, waarom het er is, en wat ervan afhankelijk is. Ik heb het nog niet geprobeerd, dus dat is iets om uit te zoeken.

Het ding dat ik zou verplaatsen, niet schrappen: de speccing ceremonie. Die is te langzaam voor iteratie, maar nodig voor production grade code, het superpowers framework zoals het is, is echt krachtig in het maken van solide, rigoureus geteste code. Misschien zou ik het 's nachts dingen laten speccen en bouwen terwijl ik slaap.

Snelle inference is het belangrijkste voor mijn workflow in de komende maanden. Dat is wat itereren op lichtsnelheid mogelijk maakt.

Het deel dat generaliseert

Wanneer het sturen de bottleneck is, is de taak van de workflow om jou in de loop te houden, en de taak van het model om je dingen te laten zien die je snel kunt verwerken. Kwaliteit hoeft in het begin niet perfect te zijn. Snel falen en itereren op het design, vooral aan het begin wanneer je dingen probeert om te zien wat werkt en wat niet, verslaat een correcte maar trage pipeline die afdrijft van wat je vroeg. De audit gaf een getal aan wat de langzame lane kost. De drift-catcher is het ontbrekende stuk, en het is het volgende dat ik ga proberen.