Superpowers, noen måneder senere

Siden jeg snakket om Superpowers på 321-frokosten i februar, har det tatt litt av. Repoet er oppe i 160 000 stjerner på GitHub nå (opp fra ca. 50 000 i februar).

På frokosten viste jeg den grunnleggende arbeidsflyten i Superpowers: brainstorming, opprette worktrees, skrive planer, testdrevet utvikling og kodereview. Poenget fra 321-frokosten i februar: det er mye lettere å jobbe med kodeagenter når de følger en strukturert prosess.

Samme skill, andre modeller

Jeg har fått testet Superpowers med GPT-5.4, Claude Opus 4.6 og Claude Opus 4.7, og med både Claude Code og OpenCode. Det oppfører seg ganske likt. Agenten glemmer de samme tingene, først og fremst worktrees, uavhengig av hvilken modell som styrer.

Det vitner om at det begynner å bli et stabilt verktøy som fungerer på tvers av modeller (hvis du ser bort fra worktrees). Å lære seg flyten i Superpowers låser deg verken inn i en modell eller et harness. Og uansett: du lærer litt mer om hvordan en strukturert flyt med AI kan se ut.

Lange spesifikasjoner

Superpowers genererer utrolig lange spesifikasjoner. Så lange at jeg ikke føler at jeg kan be kollegene mine om å reviewe dem. Og Superpowers bruker lang tid på implementasjonen sammenlignet med en enklere flyt som plan → build, der det er færre steg involvert. Skal du være effektiv, må du nesten ha flere tråder gående samtidig.

Det kan også være at jeg bare prøver meg på for store features på én gang, noe som krever at spesifikasjonen blir lang. Men jeg tror de fleste utviklere er enige i at det å sitte og lese (eller skrive) en lang spesifikasjon er lite motiverende.

Implementasjonsplanen er i hvert fall ikke noe man kan lese, og jeg tror ikke den er noe man skal lese heller. Fremfor lange spesifikasjoner generert av agenten har jeg mer tro på å få agenten til å generere arkitekturdiagrammer eller andre artefakter som er lettere for mennesker å reviewe enn en wall of text.

TDD som funker

Det som ser ut til å funke bra, er TDD-opplegget skill-en innfører. Jeg synes fortsatt testene ser ut som de kunne ha kommet fra et menneske som utøver TDD. Et lite kompliment til agentene, der altså. Håper du fikk med deg det, Claude Opus 33.10 🙏.

Ting som fortsatt lugger

I februar pekte jeg ut fire friksjoner: worktrees, tokenforbruk, implementasjonsplan og /clear. Worktrees blir fortsatt glemt innimellom. Tokenforbruket er høyt. Når det gjelder implementasjonsplanen, har jeg ikke sett at den har manglet i det siste.

Noe som ofte skjer når man skriver en spesifikasjon, er at man kommer på andre ting underveis. Jeg savner en måte å skrive ned to-dos på, slik at man kan komme tilbake til det man har skrevet ned i senere brainstorming-sesjoner.

Kontekstvinduet

Det er flere som hevder at kontekstvinduer degraderes lenge før de er fulle. Chroma kaller dette fenomenet context rot. Men Superpowers gir ikke oss mennesker strukturen til å cleare context.

Jeg er usikker på om Superpowers lærer folk å håndtere kontekstvinduet sitt riktig. Den bare fortsetter og fortsetter helt til du treffer “compaction”, uten noe hint om at du kunne ha tømt kontekstvinduet på et eller annet tidspunkt.

Strukturen Superpowers innfører er grunnen til at jeg fortsatt anbefaler verktøyet til kolleger, særlig de som ikke er vant til agentisk koding. Det tvinger deg til å planlegge sammen med agenten først, og der lærer du hva du liker.

Fremover: deterministiske pipelines

Jeg leker med tanken på å lage en versjon av Attractor hvor man kan integrere kodeagenter gjennom ACP-protokollen. Det vil si at du kan bruke Claude Code eller OpenCode som kodeagent i en deterministisk pipeline.

Å modellere utviklingspipelinen som en deterministisk prosess er for meg det neste logiske steget etter Superpowers. Da unngår du problemer med at Superpowers ikke følger oppskriften til punkt og prikke.

Et eksempel er byggesteget. Hvis bygget går ok, går du videre til å planlegge oppgaven du skal gjøre. Hvis bygget ikke går ok, sender du i stedet byggeloggene til en agent som ekstraherer det viktigste fra dem, for eksempel en stacktrace. Outputen derfra sender du kanskje til en ny agent som finner rotårsaken og fikser bygget.

Det er ikke sikkert du trenger en agent til å lese logger i det hele tatt. Kanskje det holder med en regex. Hvis regexen ikke finner noe, bruker du en billig agent som fallback. Dette er ting Superpowers og kodeagenter helt klart får til. Agentene har ikke noe problem med å kjøre en regex og finne ting i en loggfil. Poenget er at tokenene kanskje er bedre anvendt på noe annet enn logger.

Hvis du finner en flyt som gjentar seg ofte, er du kanskje bedre tjent med å kode den opp som en flyt der mange av stegene er deterministiske og ikke koster tokens, i stedet for å bruke tokens på ting som ikke er nødvendig.

Noen kan også hevde at det er nettopp det som er styrken til Superpowers, nemlig at agenten kan bruke skjønn til å vurdere om den skal droppe et steg som ikke er nødvendig. Men den som styrer prosessen har jo også mulighet til å velge en enkel pipeline, hvis man vet at problemet ikke er så vanskelig. Og noen ting bør vi mennesker kanskje gjøre selv.

Mulighetene er egentlig uendelige her, og det er det som er så spennende med Attractor: du kan bygge din helt egen flyt og samtidig holde den deterministisk.

Attractor er relativt nytt, og jeg er usikker på hvor godt testet implementasjonene er. Så hvis du har lyst til å prøve en strukturert flyt, er Superpowers fortsatt et bra sted å starte.