Spec-driven utveckling – från kravinsamling till färdig app med AI-assistent

14 November 2025 // Hans Thunberg

På Callista har vi varje år ett antal bootcamps, en slags träningsläger där vi tar chansen att träna på saker vi tycker verkar intressanta. Det handlar inte så mycket om att bygga muskler och kondition, mer om att bygga kompetens och självförtroende kring intressant teknologi, arbetssätt, prylar eller vad som helst egentligen.

Vid fikapauserna på höstens bootcamp hamnade jag i spännande diskussioner om MCP-lösningar för hårdvaruövervakning, specialtränade språkmodeller för systemkonfiguration, och WebAuthn/passkeys för modern autentisering. Mitt eget fokus låg på spec-driven utveckling med AI-assistenter, ett arbetssätt där vi beskriver vad vi vill uppnå istället för hur det ska kodas.

Målet? Att köra igenom ett helt utvecklingsflöde från kravinsamling till färdig implementation, med hjälp av strukturerade specifikationer och Claude Code som AI-assistent.

Vad är Spec-driven utveckling?

Spec-driven utveckling (spec-driven development, SDD) handlar om att flytta fokus från att berätta hur något ska kodas till att beskriva vad vi vill uppnå. Inom systemutveckling är detta verkligen inget nytt, att arbeta strukturerat med olika metoder har funnits med oss länge. Här undersöker jag hur en strukturerad process kan hjälpa till i integrationen med en AI-assistent.

Istället för att detaljstyra en AI-assistent med specifika implementationsdetaljer, ger vi den en strukturerad specifikation som beskriver kraven. Lite som skillnaden mellan att säga “laga en god middag med pasta” och att ge någon ett strukturerat recept med tydliga instruktioner att följa.

Specifikationerna är levande dokument som fångar upp olika aspekter av systemutvecklingen, vilket en AI-assistent sedan kan bryta ner i mindre steg och implementera. Det kan vara allt från funktionella krav (vad systemet ska göra), till agent-instruktioner (hur AI-assistenten ska bete sig), eller arbetsflöden (hur processen ska drivas och hur olika delar ska samverka).

Varför Spec-driven utveckling med AI?

Traditionell AI-assisterad utveckling kan bli kaotisk:

• Konversationen tappar kontext över tid
• Svårt att hålla översikt över vad som är implementerat
• Bristande dokumentation som blir inaktuell
• Ingen tydlig process för kvalitetssäkring

Med spec-driven utveckling får du:

• Strukturerad process
• Levande dokumentation som reflekterar faktisk implementation
• Versionshantering av beslut och krav
• Återanvändbarhet av specifikationer för liknande projekt

Befintliga verktyg och platformar

Det finns flera verktyg som implementerar spec-driven utveckling på olika sätt, några av dem jag stött på är:

• Kiro - Erbjuder en IDE och ett arbetsflöde med specifikationer
• spec-kit (GitHub) - Erbjuder verktyg och dokumentation för att komma igång med SDD
• Tessl Framework - En plattform för att jobba med specifikationer och AI-agenter

I denna blog valde jag att utgå från ett lite förenklat scenario baserat på ett redan befintligt projekt med specifikationer som jag modifierat något för att passa mitt behov, jag valde inte att dyka ner i någon av de verktyg som nämns ovan. Att bygga sitt eget ger djupare förståelse för vad som fungerar.

Specifikationerna

I det exempel-projekt jag utgick från finns flera olika typer av specifikationer med olika syften:

• Funktionella/tekniska specifikationer: Beskriver vad systemet ska göra och hur komponenter ska bete sig.
• Agent-specifikationer: Beskriver hur du vill att AI-assistenten ska bete sig, inklusive begränsningar.
• Arbetsflödes-specifikationer: Beskriver hur processen ska fortgå och hur AI-assistenten ska samordna arbetet.
• Kommando-specifikationer: Definierar interaktiva kommandon som utvecklaren kan använda för att styra arbetsflödet.
• Användningsfall: Fångar upp domänkunskap som hjälper AI-assistenten att förstå den specifika domänen.

När det gäller format är Markdown populärt, troligen för att det är lätt att läsa både för människa och AI-assistent.

Funktionella/tekniska specifikationer

Dessa dokument beskriver själva systemet som ska byggas, inte processen att bygga det. De genereras av arbetsflödet och utgör sedan grunden för implementationen.

Agent-specifikationer

Beskriver begränsningar och beteenderegler för AI-assistenten:

• CLAUDE.md - Instruktioner och riktlinjer för hur AI-assistenten ska bete sig i projektet
• settings.local.json - Definierar tillåtna/förbjudna operationer (säkerhetspolicyer)

Arbetsflödes-specifikationer

Dessa filer styr hur utvecklingsprocessen går till och hur AI-assistenten samordnar arbetet:

• requirements.md - Fångar affärskrav, användningsfall och funktionella krav
• design.md - Beskriver teknisk arkitektur, API-design och säkerhetsöverväganden
• tasks.md - Bryter ner arbetet i konkreta uppgifter med tidsuppskattningar och beroenden

Här är ett exempel från tasks.md som visar hur vi instruerar Claude att skapa en lista med uppgifter:

---
allowed-tools: Bash(cat:*), Bash(test:*), Write
description: Create implementation task list
---

## Context

Current spec: !`cat spec/.current-spec 2>/dev/null`
Design approved: !`test -f spec/$(cat spec/.current-spec)/.design-approved && echo "Yes" || echo "No"`

## Your Task

1. Verify design is approved
2. Create tasks.md with:
   - Overview with time estimates
   - Phase breakdown (Foundation, Core, Testing, Deployment)
   - Detailed task list with checkboxes
   - Task dependencies
   - Risk mitigation tasks
3. Each task should be specific and actionable
4. Use markdown checkboxes: `- [ ] Task description`

Organize tasks to enable incremental development and testing.

Kommando-specifikationer

Interaktiva kommandon som utvecklaren använder för att styra arbetsflödet:

• new.md - Skapar en ny spec-struktur med rätt ID-numrering
• approve.md - Godkänner en fas innan man går vidare till nästa
• implement.md - Startar implementation baserat på godkända tasks
• update-task.md - Markerar uppgifter som klara och uppdaterar framsteg
• review.md - Granskar nuvarande fas och ger feedback innan godkännande
• switch.md - Byter mellan olika specifikationer i projektet

Här är ett exempel från new.md som instruerar Claude att skapa en ny specifikation med numrering:

---
allowed-tools: Bash(mkdir:*), Bash(echo:*), Bash(date:*), Bash(ls:*)
description: Create a new feature specification
argument-hint: <feature-name>
---

## Current Spec Status

!`ls -la spec/ 2>/dev/null | grep "^d" | wc -l | xargs -I {} echo "Total specs: {}"`

## Your Task

Create a new specification directory for the feature: $ARGUMENTS

1. Determine the next ID number (format: 001, 002, etc.)
2. Create directory: `spec/[ID]-$ARGUMENTS/`
3. Update `spec/.current-spec` with the new spec directory name ([ID]-$ARGUMENTS)
4. Create a README.md in the new directory with:
   - Feature name
   - Creation date
   - Initial status checklist
5. Inform the user about next steps

Use the Bash tool to create directories and files as needed.

Varje kommando har regler som ska säkerställa att föregående fas är godkänd innan man går vidare, vilket ger en strukturerad process.

Arbetsflöde

Exempel på ett komplett arbetsflöde:

/spec:new todo-list-api
/spec:requirements
/spec:review
/spec:approve requirements
/spec:design
/spec:review
/spec:approve design
/spec:tasks
/spec:approve tasks
/spec:implement
/spec:update-task "Initialize project repository"
/spec:update-task "Set up development environment"

Resultat av arbetsflödet:

Under /spec/001-todo-list-api/ skapas specifikationsfilerna som utgör grunden för hela implementationen:

• requirements.md - Kravspecifikation med prioriterade user stories
• design.md - Teknisk design med arkitektur och säkerhetsaspekter
• tasks.md - Detaljerad uppgiftslista med tidsuppskattningar
• README.md - Översikt och status för specifikationen
• .requirements-approved, .design-approved, .tasks-approved - Godkännandemarkör som säkerställer att varje fas är granskad

Under /apps/todo-app/ genereras den färdiga applikationen och dokumentation.

Ett exempel på hur en del av den genererade designdokumentationen kan se ut:

# Todo List API - Technical Design Specification

**Feature ID:** 001-todo-list-api
**Document Type:** Technical Design
**Creation Date:** 2025-11-13
**Status:** Draft
**Version:** 1.0

---

## Table of Contents

1. [Architecture Overview](#architecture-overview)
2. [Technology Stack](#technology-stack)
3. [System Architecture](#system-architecture)
4. [Data Model & Schema](#data-model--schema)
5. [API Design](#api-design)
6. [Authentication & Authorization](#authentication--authorization)
7. [Security Considerations](#security-considerations)
8. [Performance Considerations](#performance-considerations)
9. [Deployment Architecture](#deployment-architecture)
10. [Technical Risks & Mitigations](#technical-risks--mitigations)

---

Ett exempel på hur en del av den genererade kravspecifikationen kan se ut:

# Requirements Specification: Todo List App

**Creation Date:** 2025-11-13
**Status:** Draft
**Last Updated:** 2025-11-13

---

## 1. Feature Overview

The Todo List App is a task management application that enables users to create, organize, and track tasks. It provides a simple, intuitive interface for managing personal or professional todo items with status tracking and basic prioritization.

---

## 2. User Stories & Acceptance Criteria

### US-001: Create a new todo item
**As a** user
**I want to** add a new task to my todo list
**So that** I can track tasks I need to complete

**Acceptance Criteria:**
- User can enter task title/description in a text field
- User can submit the task via button or Enter key
- New task appears at the top or bottom of the list
- Empty tasks cannot be submitted
- Task title supports up to 200 characters

Erfarenheter och lärdomar

Efter att ha lagt ner några timmar på att finslipa processen och sedan några timmar till på att generera den första applikationen, har jag några konkreta insikter att dela med mig av.

Anpassningar som infördes i specifikationerna

De ursprungliga specifikationerna justerades lite för att fungera efter mina krav:

Säkerhetsaspekter i design-fasen Jag lade till explicita riktlinjer i design.md för att säkerställa att säkerhetsöverväganden adresseras tidigt:

- Authentication and authorization
- Data protection and encryption
- Input validation and sanitization
- OWASP Top 10 vulnerabilities mitigation
- Secure configuration management

Begränsningar för AI-assistenten För att försöka undvika oönskade ändringar lade jag till tydliga regler om vad Claude inte får göra:

• Aldrig committa filer i .claude/ eller .vscode/
• Aldrig ändra specifika filer som .gitignore eller LICENSE i projektets rot
• Endast arbeta med filer i spec/ och applikationskatalogen

Trots detta så envisades Claude ibland att ändra i filer på fel ställen.

Resultatet

Efter cirka 2-4 timmar totalt, varav ca hälften på finputsning av processen och ca hälften på att generera applikationen, fick jag en genererad lösning från min AI-assistent:

Vad som genererades automatiskt:

• Enhetstester
• End-to-end tester
• Lasttester
• Detaljerad dokumentation
• Instruktioner för lokal utveckling och produktionsdrift
• Väldokumenterad kod med tydliga kopplingar till kravspecifikationen

Specifikationer som kommunikationsverktyg

En oväntat positiv effekt var hur detaljerade men ändå lättlästa specifikationerna blev:

• Man kan se exakt vad som ska byggas innan en rad kod skrivs
• Icke-tekniska personer kan förstå vad som kommer byggas
• Specifikationerna ligger i källkoden och kan enkelt förändras i framtiden om det behövs

Viktigt att komma ihåg

Spec-driven utveckling med AI är inte en “magic bullet”, du behöver fortfarande teknisk kompetens. AI-assistenten genererar en grund att stå på, men:

• Koden är inte perfekt och behöver granskas
• Tekniska beslut måste valideras
• Säkerhetsaspekter kräver mänsklig bedömning
• Specifikationer behöver trimmas in för specifika behov
• Domänkunskap är avgörande för bra specifikationer

Tips för att komma igång

Baserat på mina erfarenheter, några konkreta tips:

1. Börja med ett litet projekt - Testa först med en enkel feature för att lära känna flödet
2. Iterera på specifikationerna - De första versionerna kommer inte vara perfekta eller ens fungera
3. Anpassa mallarna - Använd exempel-projekt som utgångspunkt, men skräddarsy efter dina behov
4. Granska noga - Även om AI-genererar kod, är du fortfarande ansvarig för kvaliteten
5. Spara lyckade specifikationer - De kan bli mallar för framtida spännande projekt

Slutsats

Spec-driven utveckling med AI-assistenter befinner sig i en spännande fas där mycket experimenteras och utforskas. Efter att ha byggt min egen lösning har jag både sett potential och identifierat tydliga begränsningar, vilket gör det extra intressant att fortsätta följa utvecklingen.

Fördelar:

• Strukturerad process som håller AI-assistenten på rätt spår
• Snabbare från idé till fungerande prototyp

Utmaningar:

• Kräver initialt arbete att sätta upp specifikationer
• AI-assistenten kan göra en del fel som måste fångas upp
• För detaljerad spec kan bli lika omfattande som att skriva koden själv
• För många specifikationsfiler kan bli svårare att granska än kod
• Även med specifikationer behöver vi jobba i små steg när ändringar införs
• Många ändringar som skall granskas innan de versionshanteras

Min bedömning just nu är att arbetssättet passar bra för:

• Proof-of-concepts och prototyper där snabbhet är viktigare än perfektion
• Standardapplikationer med välkända mönster och etablerade best practices
• Utvecklare som vill experimentera med AI-assisterad utveckling på ett lite mer strukturerat sätt

Är du nyfiken på att testa själv? Kolla in exempel-projekt på GitHub