Tutorial 4 Prompting and Reviewing no

Tutorial 4 · Prompting og gjennomgang

Mål: meta-ferdigheten. Du kan nå bygge en funksjon med en agent — dette kapittelet handler om å gjøre det sømløst og repeterbart: å skrive prompter som treffer første gang, gjennomgå differ effektivt, iterere når ting går sidelengs, og holde momentum på tvers av økter.

← Forrige: Tutorial 3 Din første agentoppgave · Neste: Tutorial 5 Lokalisering

---

Prompt som en leder, ikke en søkeboks

Agenten er en rask, bokstavelig, ivrig junioringeniør. Led den slik du ville ledet en god en:

• Angi målet og begrensningene. "Legg til endorse" er svakt. "Legg til endorse etter connect-mønsteret, kun frøbasert RNG, med tester, porten forblir grønn" er sterkt. Begrensninger er hvordan du får kode som passer.
• Pek på eksempler. "Følg mønsteret brukt av renderConnect" slår et avsnitt med beskrivelse. Eksisterende kode er den beste spesifikasjonen.
• Be om en plan før redigeringer på alt ikke-trivielt. Billig å omdirigere en plan; dyrt å reversere ti redigerte filer.
• Én oppgave per prompt. Å bunte "legg til endorse, også refaktorer RNG, også oppdater README" gir en floket diff som er vanskelig å gjennomgå.
• Gi den testporten. "Kjør npm test og ikke anse det som ferdig før det er grønt" gjør agenten til noe som sjekker sitt eget arbeid.

Gjennomgå diffen hver gang

Hastighet er hele poenget med en agent — men ulest hastighet er hvordan feil sendes. Bygg en rask, konsistent gjennomgangsrefleks:

1. Omfang: endret den bare det den skulle? Urelaterte flyttede linjer er et varselstegn.
2. Mønstre: matcher den den omkringliggende koden, uten nye avhengigheter og uten I/O inne i src/?
3. Prosjektets regler: for dette repoet er det kun frøbasert RNG (grep diffen for Math.random), brukersynlig tekst i språkpakkene (ikke hardkodet), og kortlinjer overskrider aldri bredden oppsettet padder til.
4. Tilgjengelighet: overlever ny utdata --accessible? Kjør lockedin --accessible <your command> og sjekk at den leses som ren tekst — ingen nye dekorative glyffer som snek seg forbi a11yFilter.
5. Tester: er det en ny test, og ville den faktisk feile hvis funksjonen brøt sammen? Spør: "Hvilken linje ville jeg endret for å få denne nye testen til å feile?"
6. Kjør det: npm test, kjør deretter kommandoen og se på utdataen.

Du trenger ikke forstå hvert tegn — men du må forstå hver beslutning. Hvis du ikke kan forklare en endring, be agenten forklare den før du godtar den.

Iterer når det ikke er grønt

En rød port er et normalt trinn, ikke en feil. Fiksen er presis tilbakemelding:

"npm test feiler med: [paste the exact error]. renderEndorses breddetest forventer at hver kortlinje er ≤ 60 synlige kolonner. Fiks det uten å svekke testen."

Lim inn den faktiske feilteksten. "Det er ødelagt" får agenten til å gjette; stack-sporet får den til å fikse. Og foretrekk å fortsette den samme samtalen fremfor å starte på nytt — agenten har allerede konteksten av det den nettopp skrev. Hvis to eller tre iterasjoner ikke konvergerer, ta et skritt tilbake og omfang oppgaven på nytt: den kan være for stor for én prompt.

Hold momentum på tvers av økter

Ekte arbeid strekker seg over mer enn én sesjon. To vaner holder en agent effektiv over tid:

• Minne / konvensjoner. Hvis agenten din støtter varig minne eller en prosjektinstruksjonsfil, noter reglene den alltid bør følge her (f.eks. "all tilfeldighet må bruke pick/shuffle", "kjør npm test før du erklærer ferdig"). Du angir en konvensjon én gang i stedet for i hver prompt.
• Et overleveringsnotat. Dette repoet holder et kort, sanert statusdokument på docs/HANDOFF.md: hva prosjektet er, hvordan det er bygget, hvordan det testes, og hva som er neste. Når du kommer tilbake (eller overleverer til en lagkamerat — eller en annen agent), gjenoppbygger det notatet konteksten på sekunder. Be agenten din holde det oppdatert som en del av en endring.

Sikkerhetsskinner verdt å beholde

• Porten er ikke omsettelig. Grønne tester før noe sendes. Det er det som lar deg bevege deg raskt og stole på utdataen.
• Du er den registrerte gjennomgangspersonen. Agenten skriver; du bestemmer. Å godta en diff betyr at du går god for den.
• Små, verifiserbare steg slår ett gigantisk sprang. Hver godtatt endring bør etterlate appen fungerende.

---

✅ Prøv det med agenten din

1. Skriv en spesifikasjon på ett avsnitt for en mentor-kommando ("gir uoppfordrede råd"), inkludert begrensninger, og la agenten bygge den tester-først — plan, tester, kode, port — med gjennomgang ved hvert steg.
2. Be agenten om å oppdatere docs/HANDOFF.md for å nevne den nye kommandoen.
3. Ødelegg noe bevisst (f.eks. slett en pool-oppføring), kjør npm test, og øv på å gi agenten den eksakte feilen å fikse.

---

Hvor du går videre

• Bla gjennom den ekte koden i src/lockedin.js — du vet nå formen på den.
• Les docs/HANDOFF.md for prosjektets egne status- og arkitekturnotater.
• Nyt vitsene i Command Reference.

Det er veiledningen. Du kan nå dirigere en AI-agent til å bygge og endre ekte programvare bak en testport — ved å bruke det mest selvsikre eksempelet man kan tenke seg. Enig? 👇