Tutorial 4 Prompting and Reviewing sv

Tutorial 4 · Prompta och granska

Mål: metafärdigheten. Du kan nu bygga en funktion med en agent — det här kapitlet handlar om att göra det smidigt och upprepbart: att skriva prompter som landar första gången, granska diffar effektivt, iterera när saker går snett, och hålla momentum över sessioner.

← Föregående: Tutorial 3 Din första agentuppgift · Nästa: Tutorial 5 Lokalisering

---

Prompta som en ledare, inte en sökruta

Agenten är en snabb, bokstavlig, ivrig junioringenjör. Led den som du skulle leda en bra sådan:

• Ange målet och begränsningarna. "Lägg till endorse" är svagt. "Lägg till endorse enligt connect-mönstret, endast frösatt RNG, med tester, grinden förblir grön" är starkt. Begränsningar är hur du får kod som passar.
• Peka på exempel. "Följ mönstret som används av renderConnect" slår ett stycke beskrivning. Befintlig kod är den bästa specifikationen.
• Be om en plan innan redigeringar på allt icke-trivialt. Billigt att omdirigera en plan; dyrt att riva upp tio redigerade filer.
• En uppgift per prompt. Att bunta ihop "lägg till endorse, refaktorera också RNG:n, uppdatera också README" ger en tilltrasslad diff som är svår att granska.
• Ge den testgrinden. "Kör npm test och betrakta det inte som klart förrän det är grönt" gör agenten till något som kontrollerar sitt eget arbete.

Granska diffen varje gång

Hastighet är hela poängen med en agent — men oläst hastighet är hur buggar levereras. Bygg en snabb, konsekvent granskningsreflex:

1. Omfattning: ändrade den bara det den borde? Orelaterade flyttade rader är en varningssignal.
2. Mönster: matchar den den omgivande koden, utan nya beroenden och utan I/O inuti src/?
3. Projektets regler: för det här repot är det endast frösatt RNG (grep diffen efter Math.random), användarsynlig text i språkpaketen (inte hårdkodad), och kortrader överskrider aldrig bredden som layouten polstrar till.
4. Tillgänglighet: överlever ny utdata --accessible? Kör lockedin --accessible <your command> och kontrollera att det läses som ren text — inga nya dekorativa glyfer som smyger förbi a11yFilter.
5. Tester: finns det ett nytt test, och skulle det faktiskt misslyckas om funktionen gick sönder? Fråga: "Vilken rad skulle jag ändra för att få det här nya testet att misslyckas?"
6. Kör det: npm test, kör sedan kommandot och titta på utdatan.

Du behöver inte förstå varje tecken — men du måste förstå varje beslut. Om du inte kan förklara en ändring, be agenten förklara den innan du accepterar den.

Iterera när det inte är grönt

En röd grind är ett normalt steg, inte ett misslyckande. Fixet är precis feedback:

"npm test misslyckas med: [paste the exact error]. renderEndorses breddtest förväntar sig att varje kortrad är ≤ 60 synliga kolumner. Fixa det utan att försvaga testet."

Klistra in den faktiska feltexten. "Det är trasigt" får agenten att gissa; stackspåret får den att fixa. Och föredra att fortsätta samma konversation framför att börja om — agenten har redan kontexten av vad den just skrev. Om två eller tre iterationer inte konvergerar, ta ett steg tillbaka och omfattningsbestäm uppgiften igen: den kan vara för stor för en prompt.

Håll momentum över sessioner

Riktigt arbete sträcker sig över mer än en sittning. Två vanor håller en agent effektiv över tid:

• Minne / konventioner. Om din agent stöder varaktigt minne eller en projektinstruktionsfil, notera reglerna den alltid bör följa här (t.ex. "all slumpmässighet måste använda pick/shuffle", "kör npm test innan du förklarar klart"). Du anger en konvention en gång istället för i varje prompt.
• En överlämningsanteckning. Det här repot håller ett kort, sanerat statusdokument på docs/HANDOFF.md: vad projektet är, hur det är byggt, hur det testas, och vad som är nästa. När du återvänder (eller lämnar över till en kollega — eller en annan agent) återuppbygger den anteckningen kontexten på sekunder. Be din agent hålla den uppdaterad som en del av en ändring.

Skyddsräcken värda att behålla

• Grinden är inte förhandlingsbar. Gröna tester innan något levereras. Det är vad som låter dig röra dig snabbt och lita på utdatan.
• Du är den registrerade granskaren. Agenten skriver; du bestämmer. Att acceptera en diff betyder att du går i god för den.
• Små, verifierbara steg slår ett gigantiskt hopp. Varje accepterad ändring bör lämna appen fungerande.

---

✅ Testa det med din agent

1. Skriv en specifikation på ett stycke för ett mentor-kommando ("delar ut ombedd rådgivning"), inklusive begränsningar, och låt agenten bygga det tester-först — plan, tester, kod, grind — med granskning vid varje steg.
2. Be agenten uppdatera docs/HANDOFF.md för att nämna det nya kommandot.
3. Förstör något avsiktligt (t.ex. ta bort en poolpost), kör npm test, och öva på att ge agenten det exakta felet att fixa.

---

Vart du ska gå härnäst

• Bläddra genom den riktiga koden i src/lockedin.js — du vet nu formen på den.
• Läs docs/HANDOFF.md för projektets egna status- och arkitekturanteckningar.
• Njut av skämten i Command Reference.

Det är handledningen. Du kan nu dirigera en AI-agent att bygga och ändra riktig programvara bakom en testgrind — med hjälp av det mest självsäkra exemplet man kan tänka sig. Håller du med? 👇