Spec-driven utveckling betyder att du skriver ner vad som ska byggas och varför innan en AI-agent får röra koden. Specen blir källan till sanningen, agenten bygger efter den och testerna visar att resultatet stämmer. Vi byggde om activator.se på det här sättet och i repot ligger nu drygt 50 specar.
Varför räcker det inte att prompta?
Du har säkert bett en AI-agent bygga något och fått kod som ser rätt ut men löser fel problem. Det har vi också. Det beror sällan på modellen, utan på att agenten gissar där du är otydlig. Dessutom gissar den med stort självförtroende.
Arbetssättet kallas ibland vibe coding och fungerar bra för en prototyp. För kod som ska leva i flera år fungerar det sämre, eftersom kraven bara finns i ditt huvud och i en chatt som försvinner. Om ett halvår kan ingen i teamet se varför koden ser ut som den gör. Det kostar er tid varje gång något ska ändras.
Hur fungerar spec-driven utveckling?
Flödet har fem steg och varje steg bygger på det förra. Du granskar resultatet efter varje steg innan agenten går vidare, så att ett fel inte hinner växa.
- Spec: vad som ska byggas och varför, med användarberättelser och acceptanskriterier som går att testa.
- Plan: hur det ska byggas, med teknikval och datamodell som kontrolleras mot projektets regler.
- Tasks: planen bryts ner i små steg i rätt ordning, med testet före koden.
- Kod: agenten bygger ett steg i taget tills testerna är gröna.
- Granskning: en separat agent prövar koden mot specen. Ska ett krav ändras görs det i specen, med ett medvetet beslut.
Allt är vanliga textfiler i repot. Därför följer kraven med i versionshanteringen och granskas i samma pull request som koden. Byter ni modell eller agent finns allt kvar, vilket är en försäkring på en marknad som ändras snabbt.
Vad förändras i praktiken?
När vi specade chatten på sajten kom frågan om ett kostnadstak per dygn upp innan någon kod fanns. Säkerhetsgranskningen hittade sedan att en handfull adresser kunde nå taket och pausa chatten för alla. Det blev ett beslut på några minuter: ett lägre tak per besökare.
Hade vi upptäckt samma sak i drift hade chatten redan stått still. Det är hela poängen: det otydliga kommer fram som frågor innan koden skrivs och inte som buggar efteråt.
Det låter kanske som mer arbete, men i praktiken går det fortare. Det är betydligt lättare att granska två sidor krav än 800 rader kod. Ett fel i specen kostar en mening att rätta, medan samma fel i koden kostar en eftermiddag.
Hur kommer du igång med GitHub Spec Kit?
GitHub Spec Kit är ett gratisverktyg med öppen källkod som ger din agent hela flödet som färdiga kommandon. Det fungerar med Claude Code, GitHub Copilot, Cursor och flera andra. Du behöver Git, Python 3.11 eller senare och pakethanteraren uv. Räkna sedan med en kvart från installation till din första spec.
- Installera verktyget:
uv tool install specify-cli - Skapa projektet:
specify init mitt-projekt --integration claude - Skriv projektets konstitution en gång med
/speckit-constitution. Det är reglerna som alltid gäller. - Beskriv behovet med
/speckit-specifyoch låt/speckit-clarifyhitta det som är otydligt. - Låt agenten planera och bygga med
/speckit-plan,/speckit-tasksoch/speckit-implement.
Välj en liten, avgränsad funktion första gången. Det är bättre att lära känna flödet där än i det mest kritiska systemet.
Vanliga frågor om spec-driven utveckling
Behöver jag GitHub Spec Kit?
Nej. Arbetssättet går att följa med vanliga textfiler och vilken agent som helst. Spec Kit gör det enklare, eftersom mallar och kommandon redan finns.
Fungerar det i befintliga projekt?
Ja. Spec Kit går att lägga till i ett befintligt projekt och dokumentationen har en egen guide för det. Börja med en avgränsad ny funktion i stället för att specificera allt som redan finns.
Hur lång ska en spec vara?
Så kort som möjligt, med en spec per funktion. Blir den längre än några sidor är det två funktioner.
Läs hela guiden
Vi har samlat arbetssättet i guiden Bygg rätt med AI-agenter. Där får du ett genomarbetat exempel från idé till färdig funktion, en konstitution, en granskande agent och en hook att kopiera, plus en plan för din första vecka. Du behöver inga förkunskaper och exemplen fungerar i vilket språk och ramverk som helst.
När agenten väl bygger rätt dyker nästa fråga upp: hur hinner du med fler än en åt gången? Det skriver jag om i När du blir flaskhalsen. Vill ni lära er arbetssättet tillsammans? Vi utbildar teamet på plats hos er, med era egna system som exempel.
