Beskriv vad som ska hända, inte hur det ska lösas. Modellen kan tekniken bättre än du. Vad den inte kan är vad du menar, vad som redan finns, och vad du kommer att bli besviken över. Det är den informationen din beställning ska bära — och det är därför en bra beställning oftast är längre än man tror men handlar om mindre än man tror.
De fyra delarna i en beställning
En beställning som fungerar innehåller nästan alltid samma fyra saker. Ordningen spelar mindre roll, men saknas någon del märks det direkt i resultatet.
Del 3 och 4 är de som oftast saknas, och de förklarar de flesta besvikelser. Utan avgränsning får du för mycket. Utan provet får du något som ser rätt ut.
Plan före bygge
Den enskilt mest lönsamma meningen i vibecoding är den här: "Beskriv först vad du tänker ändra och var. Bygg ingenting förrän jag säger till."
Anledningen är att missförstånd är billiga att rätta i punktform och dyra att rätta i kod. Om modellen har tänkt bygga en ny sida när du menade ett fält på den befintliga tar det dig fem sekunder att se det i en plan — och tjugo minuter att upptäcka det i en app som plötsligt har två formulär.
Så ser en plan du kan godkänna ut
- Den nämner vad som ändras, i vilka filer eller vilka delar av appen.
- Den säger vad som inte ändras.
- Den nämner om något nytt behöver installeras eller kopplas in.
- Den är kortare än tio punkter. Är den längre är steget för stort — dela det.
- "Jag skapar en ny struktur för …" när du bad om en liten ändring. Modellen har tolkat uppgiften större än du menade.
- Ett nytt bibliotek eller en ny tjänst som du inte bett om. Fråga varför innan du godkänner. Ofta finns en enklare väg.
- "Jag rensar upp och förbättrar samtidigt". Två ändringar i en. Be om den du beställde, och ta uppstädningen som ett eget steg.
- Ingen plan, bara kod. Modellen ignorerade instruktionen. Säg det rakt ut och be om planen igen — det fungerar.
Tre mallar att återanvända
De här är skrivna för att klistras in och fyllas i. De ser formella ut på skärmen och tar tjugo sekunder att skriva i praktiken.
Appen är [en mening om vad den gör]. Just nu finns [det som redan fungerar].
Jag vill lägga till: [vad som ska hända, ur användarens perspektiv].
Ändra ingenting annat än det som behövs för detta. Rör inte [det du vill skydda].
Beskriv först vad du tänker göra och var. Bygg ingenting förrän jag godkänner planen.
I dag händer det här: [nuvarande beteende]. Jag vill att det i stället ska hända: [nytt beteende].
Allt annat ska fungera precis som förut. Jag kommer att prova genom att [hur du testar].
Om ändringen påverkar något mer än jag räknat med — säg det innan du bygger.
Jag gör: [exakt vad du klickar och skriver, i ordning].
Jag förväntar mig: [vad som borde hända]. I stället händer: [vad som faktiskt händer, ordagrant].
Felmeddelandet är: [klistra in hela texten].
Det fungerade senast innan jag [senaste ändringen]. Förklara vad som orsakar felet innan du föreslår en fix.
Sista raden i felmallen är den viktigaste i hela guiden. Utan den får du en fix. Med den får du en förklaring, och kan avgöra om fixen är rätt.
Ord som ger fel resultat
Vissa formuleringar låter precisa men lämnar allt öppet. De är den vanligaste orsaken till att man får något helt annat än man tänkte.
Ger fel resultat
- "Gör det snyggare"
- "Fixa så att det fungerar"
- "Lägg till validering"
- "Optimera sidan"
- "Gör klart anmälningsdelen"
- "Använd best practice"
Ger rätt resultat
- "Öka avståndet mellan fälten till samma som mellan rubrikerna"
- "Knappen Anmäl gör ingenting när jag klickar. Förklara varför."
- "Om mejlfältet är tomt ska formuläret inte skickas, och texten Fyll i din mejladress ska visas under fältet"
- "Sidan tar fyra sekunder att ladda på mobil. Vad är den största orsaken?"
- "Lägg till ett fält för telefonnummer. Inget annat."
- Ingenting — stryk raden. Den betyder inget och gör svaret längre.
När du inte vet vad du vill ha
Det händer, och då är beställningen fel verktyg. Be i stället om alternativ: "Ge mig tre olika sätt att lösa det här, med en rad om vad var och en kostar i komplexitet. Bygg ingenting."
Det tar en minut att läsa och gör beslutet till ditt i stället för modellens. Samma trick fungerar för formuleringar, namn på knappar och struktur: be om tre förslag i stället för ett svar.
Fyra frågor som är värda att ställa innan du bygger vidare
- "Vad i det här är du osäker på?"
- "Vad går sönder om jag ändrar det här senare?"
- "Finns det ett enklare sätt som ger samma resultat?"
- "Vad borde jag ha frågat om men inte gjorde?"
Nästa steg
Du har en beställning som ger rätt resultat. Nästa fråga är hur du vet att resultatet faktiskt är rätt — utan att kunna programmera. Det handlar guide 3 om.
Artikeln Beskriv resultatet, gissa inte lösningen går djupare in på varför tekniska halvlösningar i prompten är den vanligaste fällan.