Spec-driven development vs. vibe coding: Vattenfall?

Specifikationer som källa till sanning, eller långsam ceremoni?

Sidinnehåll

Spec-driven development (SDD) inledde 2026 som det seriösa alternativet för utvecklare som ville motverka drift i “vibe coding”.

Argumentet är enkelt: AI-agenter producerar bättre och mer konsekventa resultat när de implementerar mot en granskad specifikation snarare än en ad hoc-prompt. Det är svårt att argumentera emot i teorin.

I praktiken kallade Hacker News det för “Waterfall Strikes Back” (Vattenfallet kommer tillbaka).

Båda sidor har en poäng.

Spec-Driven Development versus Vibe Coding

Fallet för SDD i en värld med vibe coding

Vibe coding – praktiken att skriva en löst formulerad prompt och iterera på vad AI-agenten producerar – fungerar exceptionellt bra för små, utforskande och kassabara projekt. Under de första sex månaderna av 2025 var det dominerande mönstret för AI-kodning. Utvecklare levererade skript, prototyper och enkla verktyg snabbare än någonsin tidigare.

Då började projekten växa. Funktioner som rörde flera filer började driva iväg. Begränsningar som fastställdes i session ett glömdes i session tre. Säkerhetsantagningar droppades. Arkitekturella beslut förskölls mitt i en funktion eftersom agenten hade ingen hållbar minne av avsikten.

Spec-Driven Development (SDD) dök upp som det disciplinerade svaret. Kärnanspråket: gör specifikationen till den centrala artefakten, inte prompten. Skriv krav, en design och en arbetsplan först. Låt agenten implementera mot dessa artefakter en del i taget. Håll specifikationen versionerad och uppdaterad.

AI-kodningsverktyg – GitHub Spec Kit, Kiro, BMAD och ett växande antal anpassade arbetsflöden för Claude Code – är alla implementationer av denna idé. Verktygen är verkliga. Intresset är verkligt. Motståndet är också verkligt.

Vad vibe coding är bra på

Innan man avfärdar vibe coding är det värt att vara exakt kring vad den gör bra.

Utforskande prototyper. När du inte är säker på vad du vill bygga, är den snabbaste vägen att bygga något grovt och reagera på resultatet. SDD kräver att du vet vad du ska specificera. Om du inte vet det ännu är specifikationer för tidiga.

UI-experiment. Visuell layout och interaktionskänsla är svåra att specificera i förväg. Vibe coding låter dig se alternativ snabbt, kasta bort de flesta och konvergera mot något som faktiskt känns rätt. En kravdokument hjälper dig inte här.

Kassabar automation. Engångsskript, dataextraheringsjobb, migreringshjälpare – dessa behöver sällan ett design dokument. Kostnaden för att göra det lite fel är låg. Kostnaden för en långsam, ceremoniell process är verklig.

Snabb feedback. När du behöver lära dig något snabbt – fungerar detta API som jag tror att det gör? – klipper vibe coding inlärningsloopen till minuter. SDD skulle sänka tempot utan någon nytta.

Mistaken är att ta framgångsmönstren från dessa sammanhang och tillämpa dem på produktionsfunktioner med verkliga begränsningar, verkliga användare och verkliga konsekvenser för att göra det fel.

Där vibe coding bryter samman

Vibe coding försämras förutsägbarhandeldet som omfång och insatser ökar.

Ändringar i flera filer. När en funktion rör fem eller fler filer börjar agentens kontextfönster tappa spåren av invarianser. Utan ett design dokument måste varje prompt återigen etablera kontext som etablerades och glömdes i en tidigare session.

Arkitekturell drift. Utan explicita icke-mål implementerar agenter saker. Agenten lägger till ett cachelager eftersom det verkar rimligt. Tre sessioner senare är cache-antagningen inbakad i datamodellen och att ta bort den är dyrt.

Glömda begränsningar. “Endast autentiserade användare kan trigga detta” är en mening i ett kravdokument. I en vibe coding-session är det något du nämnde en gång i session ett och agenten inte minns i session fyra när den skriver den nya endpointen.

Dolda säkerhetsantagningar. Autoriseringregler, gränser för inmatningsvalidering, hantering av hemligheter – detta är exakt den typ av implicita krav som missas när agenten optimerar för plausibel fungerande kod snarare än korrekt, begränsad kod.

Överlämning till teamet. Om du byggde det genom iterativ promptning, är artefakten som dokumenterar vad som beslutades och varför… git-loggen. Lycka till med det.

Vad Spec-Driven Development ändrar

SDD påstår inte att det eliminerar iteration. De goda versionerna av SDD är explicit iterativa. Det de ändrar är var iterationen sker. För den fullständiga definitionen – inklusive hur SDD skiljer sig från TDD, BDD och formella metoder – se Vad är Spec-Driven Development?

Istället för att iterera på kod och härleda avsikt från diffs, itererar du på specen och implementerar sedan. Specen blir artefakten som dokumenterar vad som beslutades, varför och vad som är utanför scope – och tjänar en liknande funktion som Arkitekturella beslutsdokument men orienterat kring funktionsavsikt snarare än systemnivåval. Koden implementerar den avsikten.

En typisk SDD-arbetsflöde går igenom fem faser:

Specificera. Problembeskrivning, användare, mål, icke-mål, acceptanskriterier, öppna frågor.

Planera. Arkitekturella beslut, påverkade moduler, datamodell, API-kontrakt, säkerhetsaspekter, teststrategi.

Arbetsuppdelning. Små implementeringsbitar med explicita valideringskriterier och kontroller för mänsklig granskning.

Implementera. En uppgift i taget, med kontextåterställning mellan uppgifter, tillämpa begränsningar från specen och uppdatera planen när verkligheten skiljer sig från designen.

Validera. Tester, lint, typkontroller, acceptanskriterier, diff mellan spec och kod.

Agenten deltar i de flesta faserna – utkastar specen, genererar designen, föreslår uppgifter – men människor granskar artefakterna innan implementeringen startar. Den granskningssteget är den centrala skillnaden mellan SDD och vibe coding.

Varför utvecklare kallar det Waterfall

Kritiken av vattenfallet är inte fel. Den är bara riktad mot dålig SDD, inte SDD i sig.

Den specifika felmoden är lång planering i förväg. Vattenfallets definierande karaktäristik är en feedbackloop som sträcker sig över veckor eller månader: kravfas, designfas, byggfas, testfas, leverans. Feedback kommer sent. När du upptäcker att designantagningen var fel, har du byggt på den i veckor.

När en utvecklare använder Spec Kit och genererar en 200-raders uppgiftslista innan de skriver en enda rad kod, och sedan spenderar två dagar på att putsar kravdokumentet innan agenten rör något, det är vattenfall. Det är vattenfall med markdown istället för UML, men felmoden är identisk.

En HN-kommentator beskrev användningen av Spec Kit för ett litet CLI-verktyg och upplevde det som “för långsamt, för mycket justeringar innan man ser kod.” Det är den dåliga versionen. Den användaren hade rätt att avvisa det för den uppgiften.

Den användbara kritiken är inte “specifikationer är dåliga.” Det är “lång planering i förväg innan feedback är dålig.” Det är olika påståenden.

Den användbara mellangrunden

Bra SDD undviker vattenfallsfällan genom att hålla specen liten och starta implementeringen tidigt.

Små specifikationer. Ett kravdokument för en enda funktion bör få plats på en skärm. Om specen är tio sidor lång är det antingen en plattformdesign eller så behöver den brytas upp i mindre funktioner. Specifikationer som är för stora tar för lång tid att granska och blir snabbt föråldrade.

Korta uppgiftsbitar. Varje uppgift ska kunna implementeras i en enda agent-session, granskas som en liten diff och testas isolerat. Om uppgifterna är för stora sträcker implementeringsloopen ut sig och mappningen mellan spec och kod blir svår att verifiera.

Tidig implementation. Specificera den första uppgiften, implementera den, validera den, och gå sedan till nästa uppgift. Specificera inte allt innan du implementerar något. Den första implementeringen kommer att avslöja saker som din spec fick fel. Uppdatera specen innan du fortsätter.

Levande specifikation. När verkligheten skiljer sig från designen – och den kommer att göra det – uppdatera specen, inte bara koden. Specen är bara användbar om den speglar vad som faktiskt byggdes.

Tester som exekverbar feedback. Varje acceptanskriterium ska mappa till minst en test. Testsuiten är den maskinläsbara versionen av specen. Om specen säger “endast autentiserade användare kan trigga detta”, bör det finnas en test som verifierar att oautentiserade begäran avvisas.

Denna hybrid – små specifikationer, korta uppgifter, tidig implementation, levande dokument – är det som faktiskt fungerar. Det är inte vibe coding och det är inte vattenfall. Det är kontrollerad iteration med hållbara artefakter.

När SDD slår vibe coding

Använd SDD – även lättviktig SDD – när kostnaden för att göra det fel är verklig.

Riskabel affärslogik. Fakturering, behörigheter, datamigreringar, idempotens – all logik där felaktigt beteende är dyrt eller svårt att ångra. Vibe coding lämnar dessa krav implicita. SDD gör dem explicita och granskbara innan implementering.

Ändringar i produktions-API. All ändring av ett offentligt eller internt API-kontrakt bör ha ett design dokument. Design dokumentet är det du granskar innan agenten skriver kod som kallar avbryter.

Flervals-agentarbetsflöden. När flera agenter implementerar olika delar av en funktion, är specen den delade källan till sanningen. Utan den optimerar varje agent lokalt och bitarna kanske inte passar ihop.

Överlämning till teamet. Om en annan utvecklare eller en annan agent ska fortsätta detta arbete, är specen överlämningsartefakten. En git-log och en README räcker inte.

Stora refactoreringar. Refactoreringar som rör kärnabstraktioner behöver en explicit uttalande om vad som måste förbli detsamma (beteende) och vad som får ändras (struktur). Utan det kan agenten bryta kontrakt som du trodde var bevarade.

När vibe coding fortfarande är bättre

SDD är overhead. Ibland är overhead inte värt det.

Snabba skript. Ett 50-raders skript för att döpa om filer eller transformera JSON behöver inte ett kravdokument. Skriv prompten, kontrollera utdata, leverera det.

Experiment. Om du lär dig om en approach är möjlig – utforskar ett API, testar ett bibliotek, validerar en hypotes – behöver du hastighet, inte struktur. Experimentera först, specificera om experimentet lyckas.

UI-skisser. Interaktionsdesign gynnas av att se snarare än att specificera. Bygg flera grova variationer snabbt, reagera på vad du ser, och specificera bara det du faktiskt kommer att leverera.

Kassabar automation. Engångsskript, dataimporter, migreringshjälpare – kostnaden för ett lite felaktigt resultat är vanligtvis låg, och artefakten kommer att raderas efter användning ändå.

Solo-prototyper. Om du är den enda personen som någonsin kommer att se denna kod och målet är lärande snarare än produktion, är vibe coding snabbare och nackdelarna är begränsade.

Ett enkelt beslutsramverk

Den praktiska frågan är inte “SDD eller vibe coding?” Det är “hur mycket spec behöver jag för denna specifika uppgift?”

Använd vibe coding när:

  • Uppgiften tar mindre än en dag
  • Du utforskar eller lär dig
  • Artefakten är kassabar eller låginsats
  • Du är den enda personen som kommer att röra detta
  • Feedbackhastighet betyder mer än korrekthet

Använd lättviktig SDD när:

  • Uppgiften tar två eller fler dagar
  • Flera filer påverkas
  • Det finns explicita säkerhets- eller korrekthetskrav
  • En annan person eller agent kommer att fortsätta arbetet
  • Du behöver skriva tester som mappar till krav

Använd full SDD när:

  • Funktionen rör ett offentligt gränssnitt eller datakontrakt
  • Flera agenter eller teammedlemmar är involverade
  • Organisationen kräver en designgranskning innan implementering
  • Efterlevnad eller revisionsspår krävs

Det vanligaste misstaget är att tillämpa full SDD på uppgifter som bara behöver lättviktig SDD, och att tillämpa ingen spec alls på uppgifter som behöver åtminstone en lättviktig en.

Dålig SDD är vattenfall med markdown. Bra SDD är kontrollerad iteration med hållbara artefakter. Vibe coding är rätt verktyg för rätt uppgifter – och fel verktyg för fel uppgifter. Att känna skillnaden är färdigheten.

Användbara länkar

Prenumerera

Få nya inlägg om system, infrastruktur och AI-ingenjörskonst.