Prompt → plan → implementation → review: mitt standardflöde

I större AI- och codingprojekt har jag gått från att se prompten som hela instruktionen till att se den som startpunkten för en kedja: prompt → plan → implementation → review. Varje steg har en annan uppgift och en annan typ av fel som ska stoppas.

Jag använder prompten som intake, inte som slutprodukt

Mitt standardflöde i större AI-arbeten är numera prompt → plan → implementation → review. Prompten beskriver uppgiften och begränsningarna. Planen översätter den till ett utförbart arbete. Implementation gör ändringen. Review jämför resultatet mot intentionen. Den enkla uppdelningen har gjort större skillnad för mig än att försöka skriva en enda perfekt prompt.

Skälet är att en superprompt som blandar discovery, design, execution och QA i samma kontext gör det lätt för modellen att låta "det fungerar på min demo" glida in som bevis på att "systemet är specificerat" — trots att koden kan vara korrekt och ändå bygga fel sak.

Prompt: fånga what och why

I första steget försöker jag undvika implementationsdetaljer som modellen ännu inte har undersökt. Jag vill veta problemet, målbilden, constraints och vad som absolut inte får ändras. Det ligger nära spec-driven utveckling: GitHub Spec Kit håller fortfarande fast vid kärnsekvensen Spec → Plan → Tasks → Implement, där varje artefakt matar nästa.

Plan: gör oklarheter synliga

Planen ska inte vara en snygg sammanfattning. Den ska exponera frågor: vilka filer påverkas, vilka beroenden finns, vilka dataflöden ändras, vilka tester behövs och vilka beslut är reversibla? Jag föredrar en plan som säger 'detta vet vi inte ännu' framför en självsäker lista som råkar anta fel arkitektur.

En plan i små tasks gör dessutom scope synligt: vad som saknas, vad som kan testas separat och vilka beroenden som finns. Det minskar risken att agenten bygger en elegant sidolösning som aldrig fanns i kravet.

Implementation: håll dig till kontraktet

När planen är godkänd ska implementationen kunna härledas till den. Det betyder inte att agenten aldrig får upptäcka något nytt. Men nya fynd ska antingen uppdatera planen eller markeras som avvikelse. Annars blir planen dekorativ och koden blir återigen den enda sanningen.

Produktionskrav som vibe coding missar

Retries, behörigheter, migrationer, observability och rollback syns sällan i en första vibe-coded prototyp. De behöver bli explicita krav innan implementationen växer, inte något som upptäcks efteråt. Det är också därför acceptanskriterierna i planen inte bara är dokumentation: varje viktig behavior kan översättas till ett test eller en kontroll, så specen blir input till regressionssviten snarare än en beskrivning som skrivs efter att koden redan finns.

Review: jämför mot intention, inte bara tester

Ett test kan passera samtidigt som lösningen löser fel problem. Därför reviewar jag både teknisk korrekthet och intention: uppfylls användarflödet, acceptanskriterierna och begränsningarna? Spec Kit har i skrivande stund även convergence-liknande kontroller som jämför nuvarande implementation mot spec, plan och tasks. Den principen är viktigare än verktyget.

Varför fyra steg är bättre än en superprompt

Separata artefakter skapar friktion på rätt ställen. Jag kan granska planen innan kod skapas och reviewa koden mot något som existerade före implementationen.

Mitt minsta kontrakt

För små ändringar räcker ofta fyra filer eller fyra tydliga avsnitt: request.md, plan.md, förändringen i repo:t och review.md. Poängen är inte dokumentation för dokumentationens skull. Poängen är att intentionen ska överleva längre än en modellkonversation.

Min praktiska tumregel

Låt prompten fånga intention, planen göra antaganden synliga, implementationen följa planen och reviewn jämföra mot intentionen igen.