Funktionen skulle ta två veckor att utveckla. Ärendet hade en rubrik, tre punkter och en Slack-tråd bifogad som ”bakgrundsinformation”. En utvecklare tog sig an uppgiften, gjorde rimliga antaganden och började koda. En AI-assistent hjälpte till att generera standardkoden. Det gick snabbt – ända fram till granskningen av pull-förfrågan, då någon undrade varför datamodellen inte tog hänsyn till multitenancy.
Det gjorde det inte, eftersom ingen hade sagt att det behövdes.
Funktionen levererades tre veckor för sent, var halvfärdig och hade redan en omstrukturering inplanerad. Låter det bekant? Det borde det göra. Det här är inte en berättelse om en dålig utvecklare eller ett dåligt AI-verktyg. Det är en berättelse om en dålig specifikation – eller snarare, om avsaknaden av en riktig specifikation.
De flesta misslyckanden inom utveckling beror inte på tekniska problem. De handlarom definitioner. Teamet byggde precis det som beskrevs – men det var helt enkelt inte det som någon egentligen behövde. Och här är det obekväma som AI-stödd utveckling har blottlagt: vi var aldrig så precisa som vi trodde att vi var. När en mänsklig utvecklare stötte på ett tvetydigt krav brukade hen ställa en fråga, fatta ett beslut eller tyst acceptera att behöva göra om arbetet.
När en AI-assistent stöter på samma tvetydighet skapar den helt enkelt något. Med fullt självförtroende. Helt och hållet. Baserat på vad den nu kan sluta sig till. Hastigheten är påtaglig. Det är även följderna när grunden är felaktig. Vibing ger upphov till bieffekter.
Problemet var aldrig att våra verktyg var för långsamma. Problemet var att våra specifikationer aldrig var tillräckligt bra för att kunna överlämnas till någon – vare sig människa eller maskin.
Den insikten fick oss att införaspecifikationsdriven utveckling (SDD)som standard i vårt team. Inte som en metodik hämtad från ett konferensföredrag, utan som ett svar på ett mönster vi gång på gång såg i vårt eget arbete: krav som bara fanns i människors huvuden, pull-förfrågningar som blev den första riktiga diskussionen om designen, och AI-resultat som var tekniskt imponerande men felaktiga i sitt sammanhang.
Här följer en ärlig beskrivning av hur SDD faktiskt fungerar i praktiken, var det medvetet skapar motstånd och vad data visade när vi gjorde det till ett absolut krav.
Specifikationen är inte något man skriver innan det riktiga arbetet börjar.Specifikationen är själva arbetet.
SDDomdefinierar specifikationen som utvecklingsarbetets främsta byggsten. Koden är resultatet. Specifikationen är den giltiga källan. Vad som ska byggas, för vem, under vilka förutsättningar och hur ”färdigt” egentligen ser ut – allt detta finns i specifikationen redan innan någon öppnar en IDE.
De flesta team skriver redan nernågotinnan de börjar bygga – ett Jira-ärende, en Confluence-sida, en Slack-tråd som någon tar en skärmdump av och fäster. Det är inte en specifikation. En specifikation är ett strukturerat dokument som definierar:
I ett arbetsflöde där AI står i centrum blir denna struktur ännu viktigare. Specifikationenblir själva uppgiften. Matar man en välformulerad specifikation till en AI-kodningsagent får man ett sammanhängande, granskningsbart resultat som bygger på en gemensam förståelse. Matar man den istället med en vag beskrivning blir resultatet felaktigt – kod som visserligen fungerar tekniskt sett men som inte riktigt löser det rätta problemet, och som granskas av ingenjörer som inte ens är säkra på vad ”rätt” egentligen innebär.
Se specifikationen som ett avtal – mellan produkt- och utvecklingsavdelningarna, mellan människa och AI, mellan den här sprinten och nästa utvecklare som arbetar med kodbasen.
I praktiken innebär SDD att tre saker sker i följd:
Disciplinen avspeglas i siffrorna. De team vi har samarbetat med som har infört SDD som standard – inte som ett projektbaserat experiment, utan som en fast teknisk norm – upplever vanligtvis30–50 % färre fel i de sena utvecklingsfasernaoch betydligt kortare kvalitetssäkringscykler. Oklarheter reds ut i dokumentationen, inte i felsökningsverktyget.
Beslutet att standardisera var inte av filosofisk karaktär. Det var ett svar på ett konkret, mätbart problem: när AI-verktygen gick från att vara experiment till att bli en del av infrastrukturen kunde variationerna i utdatakvaliteten nästan helt och hållet härledas till variationer i specifikationskvaliteten. Skräp in, skräp ut – men skräpet var osynligt eftersom det fanns utspritt på ett dussintal olika ställen.
Före-bilden var fragmenterad på flera sätt som samverkade:
Det sista är den tysta mördaren. Den inre kunskapen känns effektiv tills någon slutar, ett projekt växer eller en ny teammedlem måste leverera något redan under den andra veckan.
Förändringen var strukturell, inte symbolisk. Vi samlade allt på ett enda ställe agentresurser arkiv.
Kommandon som /generera-specifikation och /implementeringsspecifikation blev /mop:generera-specifikation och /mop:implementeringsspecifikation — standardiserade, versionshanterade och tillgängliga för alla projekt från en gemensam källa. Agentregler, prompter och bästa praxis samlade på ett ställe, underhållna på samma sätt som kod.
Arkivet är inte bara en samling verktyg. Det är institutionell kunskap som bevaras för framtiden.
Resultatet är märkbart annorlunda:
Vi lade mycket tid och energi i början på att förbättra utformningen av en bra specifikation. Det stora genombrottet var att standardiserahurspecifikationer skapas, lagras och används. Själva dokumentet är viktigt. Arbetsflödet kring dokumentet är lika viktigt.
På Ministry of Programming har vi gång på gång sett detta mönster i våra kunduppdrag: projekt som inleddes med en noggrann kravspecifikation resulterade i färre ändringsönskemål, färre fel efter lanseringen och snabbare överlämningar mellan teamen. Den initiala satsningen gav avkastning mitt i projektet – precis när den behövdes som mest.
SDD är ingen universallösning.Metodenär rätt, mentillämpningenanpassas efter sammanhanget. Var ni befinner er – vad gäller teamets storlek och kodbasens mognadsgrad – avgör hur snabbt ni inför den och var ni börjar.
Ett nytt projekt, ett litet team.Den enklaste segern. Inga befintliga skulder, inga gamla antaganden att reda ut. Även ett team på bara två personer har nytta av att följa specifikationerna innan kaoset i utvecklingsfasens inledningsskede sätter in. Det tvingar er att definiera vad ni faktiskt ska bygga innan ni börjar diskutera hur.
Nytt projekt, större team.Nästan ett måste. När flera utvecklare arbetar parallellt blir specifikationen det samordnande ledet – det som ersätter en veckas samordningsmöten och förhindrar att två personer bygger samma funktion på helt olika sätt. Utan den går arbetsflödena snabbt isär, och kostnaden för att få dem att stämma överens ökar exponentiellt.
Äldre kod, litet team.Försök inte specificera det som redan finns. Migrera selektivt – börja med nya funktioner och kommande förändringar, inte omstruktureringar av stabil kod. Målet är att etablera vanan i ett område med låg risk innan man utvidgar den.
Äldre kod, större team.Äldre kod, större team. Det svåraste kvadranten, och det vet vi av erfarenhet. Att försöka införa SDD i en befintlig stor kodbas på en gång tär på både arbetsmoralen och produktiviteten. Den enda realistiska vägen är en gradvis övergång – projekt för projekt, team för team. Den metod som fungerar bäst är att börja ett steg under specifikationen: fastställ först projektspecifika regler. Linting-konfigurationer, arkitekturbegränsningar, namngivningskonventioner, granskningschecklistor – allt som gör kodbasens implicita förväntningar explicita. Detta gör två saker. Det tvingar teamet att lyfta fram och enas om antaganden som har funnits i människors huvuden i månader eller år. Och det skapar en vana att arbeta enligt en definierad standard innan standarden blir en fullständig specifikation.
När den grunden väl är på plats känns övergången till SDD som ett naturligt nästa steg snarare än en påtvingad processförändring. Teamet frågar redan ”hur ser det rätta ut här?” innan de skriver kod – specifikationen formaliserar och utvidgar bara den frågan.
Verktyget är mindre viktigt än vanan. En gemensam dokumentmall är en bra första version.
När det gäller verktyg: vi tillverkade /mop:generera-specifikation eftersom vårt arbetsflöde krävde att det passade in i vår teknikstack och vår AI-agentkonfiguration – det var ett praktiskt val, inte ett filosofiskt. Mindre team bör inte vänta på det perfekta verktyget. Börja med det som skapar minst motstånd. Ett välstrukturerat Google Doc-dokument som alla faktiskt läser är bättre än ett sofistikerat specifikationssystem som ingen använder konsekvent.
Mönstret är detsamma i alla fyra scenarierna:anpassa införandet efter era faktiska begränsningar, inte efter en idealiserad bild av ert team.
Varje team som vi har presenterat SDD för har varit skeptiskt. Det är inte något varningssignal – det är ett tecken på att teamet tänker efter. Här är de invändningar vi oftast hör, och vad vi faktiskt har kommit fram till.
Ja. Det är just det som är poängen. Avmattningen sker i början – och det är rätt val. Vi har sett PR-granskningscykler i tre omgångar, ändringar av omfattningen mitt i sprintet och ”snabba lösningar” som tog två veckor eftersom ingen var överens om vad lösningen skulle göra. Specifikationsvägen är långsammare den första dagen och snabbare över hela leveranscykeln. Det är ingen teori – det är vad cykeltidsdata visar när man mäter från början till slut istället för bara hastighet till sammanfogning.
AI kan utarbeta en specifikation. Den kan inte ersätta tänkandet som ligger bakom den. Värdet ligger inte i dokumentet – det är den drivande kraften. Det ögonblick då någon skriver ”användare kan filtrera efter datum” och sedan måste svara på: Vilken tidszon? Vad händer om det inte finns några data inom intervallet? Bevaras det mellan sessioner? Det är där sju specialfall dyker upp som ingen hade tänkt på. AI kommer inte att lyfta fram dem åt dig. Den kommer med självförtroende att dölja dem.
En enkel specifikation för en snabb prototyp är fortfarande bättre än ingen alls. Bestäm vad du vill ta reda på, vad du ska bygga för att ta reda på det, och vad det färdiga ser ut. Det är en specifikation. Det tar 20 minuter och sparar dig diskussionen i slutet av sprinten där ingen är överens om huruvida experimentet lyckades.
Försök inte dokumentera det som redan finns. Börja istället med att ta fram specifikationer för det du ska bygga eller ändra. Den befintliga koden behöver ingen specifikation i efterhand — det är nästa PR som påverkar den som behöver det. Täckningen växer organiskt, och du behöver aldrig utlysa en dokumentationssprint som alla ogillar.
Nej. De överlappar varandra, men de är inte samma sak. Den viktigaste skillnaden är syftet och tidpunkten. Dokumentationen beskriver vad som byggdes. En specifikation föreskriver vad kommer att byggas.
Pilens riktning är viktig. Specifikationen först, koden sedan – inte tvärtom.
Om du är redo att förvandla din vision till en produkt som verkligen kommer ut på marknaden,
Det här är inte ett krav på att införa en ny metodik eller omstrukturera hela leveransprocessen. Det handlar om något mycket enklare:börja planera i ett tidigare skede och utforma det så att det klarar överlämningen.
Det är just vad specifikationsdriven utveckling egentligen handlar om. Det är inte ett ramverk som påtvingas uppifrån, utan en metodik som bekräftar vad de flesta erfarna utvecklare redan vet – att de beslut som formar en funktion oftast fattas under de första timmarna av arbetet med den. SDD gör helt enkelt dessa beslut tydliga, granskbara och användbara för nästa person i kedjan, inklusive de AI-verktyg som i allt högre grad arbetar vid vår sida.
Utgångspunkten är praktisk:
/mop:generera-specifikation och /mop:implementeringsspecifikation kommandona är nu tillgängliga. agentresurser Det är där du börjar.Specifikationen är inte dokumentation som man skriver efter att man har förstått problemet. Den är det sätt på vilket man kommer att förstå problemet.
Det teamen oftast upptäcker när de väl provar det är inte att specifikationen bromsar dem. Det är snarare attavsaknadenav en specifikation redan bromsade dem – de kunde bara inte se det i de oändliga omarbetningscyklerna, de dåligt samordnade granskningarna och de funktioner som lanserades men ändå inte nådde målet.
Vi har utvecklat programvara tillräckligt länge för att veta att det mesta som går fel vid leveransen kunde ha upptäckts redan innan den första committen. SDD eliminerar inte överraskningar – men det förflyttar dem till ett skede där de är billiga att åtgärda.
Det är ingen metodik. Det är bara bra ingenjörskonst.
kontakta oss om du vill gå igenom hur detta ser ut i dina aktuella projekt.