Du är expert på vad appen ska göra. Modellen är expert på hur. När du blandar ihop rollerna förlorar båda: din beskrivning blir teknisk och otydlig, och modellen får ingen chans att välja en bättre väg — för du har redan valt den åt den.
Hur det ser ut
Fällan är svår att känna igen just för att formuleringarna låter kompetenta. De innehåller ord man hört, och de känns mer precisa än de är.
En gissad lösning
- "Lägg till en localStorage för anmälningarna"
- "Gör en API-endpoint som returnerar listan"
- "Använd en modal för bekräftelsen"
- "Lägg till en cache så det går snabbare"
- "Skapa en användartabell med roller"
Ett beskrivet resultat
- "Anmälningarna ska finnas kvar när sidan laddas om"
- "Styrelsen ska kunna se listan på en egen sida"
- "Efter Anmäl ska det stå tack, du är anmäld, utan att listan försvinner"
- "Listan tar fyra sekunder att visa. Vad är den största orsaken?"
- "Bara styrelsen ska se mejladresserna, medlemmar ska bara se antalet"
Titta på högerkolumnen. Ingen av raderna nämner en teknik, och varje rad går att prova när den är byggd. Det är hela skillnaden — och notera att de också är kortare.
Varför det kostar
Tre saker händer när du beställer en lösning i stället för ett resultat, och de förstärker varandra.
Vändningen: tre frågor
När du märker att du håller på att beskriva en lösning, ställ dig själv de här tre frågorna. Svaren är din beställning.
Vad ska användaren se eller kunna göra? Beskriv det som om du berättade för en kollega vad appen gör.
Hur skulle jag märka att det är klart? Om du inte kan svara är beställningen för vag — inte för lite teknisk.
Vad bryr jag mig faktiskt inte om? Säg det. "Jag har ingen åsikt om hur det lagras, bara att det finns kvar" är en mycket bra rad att skriva.
Sista raden är den som frigör modellen att göra det den är bra på. Den läser den som en tillåtelse att välja enklaste vägen, i stället för att följa din halva idé.
När det är rätt att vara teknisk
Regeln har undantag, och de är värda att känna till — annars blir rådet en ny sorts oflexibilitet.
Var konkret om tekniken när
- Något redan är valt. Ligger data redan i en viss databas ska du säga det, annars föreslås en annan.
- Du har ett krav som är tekniskt. "Data måste lagras inom EU" är ett riktigt krav och ska stå med.
- Du vill undvika något specifikt. "Använd inget nytt bibliotek för det här" är en bra avgränsning.
- Du har provat något och det gick fel. Då är det information, inte en gissning.
En teknisk begränsning hjälper alltid. En teknisk lösning hjälper bara när du vet varför du valt den. Om du inte kan förklara varför — beskriv resultatet i stället och låt modellen föreslå.
Övningen
Nästa gång du ska beställa något: skriv beställningen, läs igenom den och stryk varje ord som är ett tekniskt namn. Om det som återstår fortfarande säger vad du vill ha — skicka det. Om det inte gör det har du hittat vad du behöver formulera om.
Det tar tio sekunder och är den mest lönsamma tio sekunder som finns i vibecoding. Guide 2 går igenom hela beställningen, med mallar. En sak i taget handlar om den andra halvan av samma problem: storleken på det du ber om.