Jeg har læst gode blog posts af Allan Knox og har samlet noget af essensen omkring prompt engineering.
Jeg samlet dem til 6 Do's & Don'ts til dit arbejde med AI, og vigtigst af alt: hvorfor de virker i maskinrummet.
1. Lad aldrig AI vælge dit "Hvorfor" (Own the Why)
🔴 DON'T: "Find på funktionerne til en god opgavestyrings-app."
- Hvorfor det er skidt: Du lader AI'en udfylde hullerne og gætte på, hvilket problem appen egentlig løser. Hele dit projekt ender med at bygge på en maskines forkerte antagelse.
🟢 DO: "Jeg bygger en app specifikt til freelance-tømrere, der glemmer at fakturere. Skærp denne idé."
- Hvorfor det er godt: Dit "hvorfor" er det fundament, som alle fremtidige beslutninger og funktioner skal pege tilbage på. Du skal selv eje formålet.
2. Styr dit scope (AI forbereder, du beslutter)
🔴 DON'T: Lad AI'ens gigantiske bruttoliste over mulige features blive dit faktiske projekt-scope.
- Hvorfor det er skidt: AI'ens liste ser flot ud, men det er en fælde. Det er bare en bunke af muligheder uden nogen form for prioritering. Faren er, at du ikke aktivt træffer en beslutning, men bare glemmer at vælge fra.
🟢 DO: Brug AI til at kortlægge mulighederne, men træf selv den hårde beslutning om at skære alt andet end din Minimum Viable Product (MVP) fra.
- Hvorfor det er godt: AI er fantastisk til at skabe bredde og idégenerere, men det er din opgave at prioritere og foretage fravalg.
3. Kend forskel på model og værktøj (De to lag)
🔴 DON'T: Skæld dit værktøj (f.eks. Cursor eller Copilot) ud over at være "dumt".
- Hvorfor det er skidt: Hvis du forveksler selve AI-modellen med platformen, fører det til uretfærdige sammenligninger, dårlige beslutninger og spildte penge.
🟢 DO: Husk at skelne mellem "hjernen" (Claude/GPT, som tænker og ræsonnerer) og "skrivebordet" (dit IDE/platform, som leverer filer og kontekst).
- Hvorfor det er godt: Det hjælper dig med at identificere det sande problem. Oftest er modellen fin, men dit miljø mangler at give den adgang til de rette informationer.
4. Mestre opgave-nedbrydning (Task Decomposition)
🔴 DON'T: "Byg et komplet login-system med database, emails og sikkerhed."
- Hvorfor det er skidt: Store problemer skjuler altid mindre problemer, og mange projekter fejler udelukkende fordi, opgaven aldrig blev brudt ordentligt ned.
🟢 DO: "Første trin: Skriv kun database-schemaet for brugeren. Bagefter bygger vi API'et."
- Hvorfor det er godt: God opgave-nedbrydning forvandler kompleksitet til fremdrift, og AI præsterer langt bedre med små, overskuelige opgaver.
5. Gætteri er ikke debugging
🔴 DON'T: At prompte "Det virker ikke, fix det!" eller at indsætte tilfældige print-statements.
- Hvorfor det er skidt: Gætteri er ikke debugging. Denne tilgang skjuler ofte det egentlige problem og har det med at skabe nye fejl, mens AI'en famler i blinde.
🟢 DO: Analyser fejlmeddelelser, observer systemet og find rodårsagen, før koden ændres. Prompt derefter AI'en med specifikke logs og fejlmeddelelser.
- Hvorfor det er godt: Systematisk fejlfinding identificerer selve roden til problemet, hvilket gør dine prototyper langt mere stabile og nemmere at bygge videre på.
6. Gør teknisk gæld synlig
🔴 DON'T: Bed om quick-fixes og glem alt om dem, når koden ender i produktion.
- Hvorfor det er skidt: Det lader den tekniske gæld vokse usynligt og uhåndteret. Du ofrer langsigtet vedligeholdelse for kortsigtet hastighed uden at være bevidst om konsekvenserne.
🟢 DO: Accepter genveje for at bevare farten, men efterlad altid en tydelig kommentar: // TODO: TECH DEBT.
- Hvorfor det er godt: Teknisk gæld er ofte en nødvendighed i tidlige prototyper. Når du tager genveje bevidst og gør dem eksplicitte, kan du styre gælden i stedet for, at den styrer dig.
Som jeg har nævnt før i mine indlæg: AI skal ikke erstatte din dømmekraft, den skal levere bedre input til dine beslutninger. 💡
Hvilken af disse AI-faldgruber er du oftest selv stødt på i din dagligdag? Smid en kommentar herunder – jeg vil elske at høre jeres erfaringer! 👇
Top comments (0)