Tutorial 4 Prompting and Reviewing nl

Tutorial 4 · Prompting en review

🌎 Taal: Nederlands — bekijk alle 33 talen

Doel: de meta-vaardigheid. Je kunt nu een feature bouwen met een agent — dit hoofdstuk gaat over het soepel en herhaalbaar doen: prompts schrijven die de eerste keer landen, diffs efficiënt reviewen, itereren wanneer het scheefgaat en vaart houden tussen sessies.

← Vorige: Tutorial 3 Je eerste agenttaak · Volgende: Tutorial 5 Lokalisatie

---

Prompt als een lead, niet als een zoekbalk

De agent is een snelle, letterlijke, gretige junior engineer. Stuur hem aan zoals je een goede zou aansturen:

• Noem het doel én de beperkingen. "Voeg endorse toe" is zwak. "Voeg endorse toe volgens het connect-patroon, alleen RNG met seed, mét tests, en de barrière blijft groen" is sterk. Beperkingen zijn hoe je code krijgt die past.
• Wijs naar voorbeelden. "Volg het patroon van renderConnect" verslaat een hele alinea beschrijving. Bestaande code is de beste specificatie.
• Vraag om een plan vóór er bewerkt wordt bij alles wat niet triviaal is. Een plan ombuigen is goedkoop; tien aangepaste bestanden terugdraaien is duur.
• Eén taak per prompt. "Voeg endorse toe, refactor ook meteen de RNG en werk ook de README bij" levert een verwarde diff op die lastig te reviewen is.
• Geef de testbarrière mee. "Draai npm test en beschouw het pas als klaar als die groen is" verandert de agent in iets dat zijn eigen werk controleert.

Review de diff elke keer

Snelheid is het hele punt van een agent — maar ongelezen snelheid is hoe bugs worden opgeleverd. Bouw een snelle, consistente reviewreflex op:

1. Scope: veranderde het alleen wat het moest veranderen? Niet-gerelateerde verschoven regels zijn een alarmsignaal.
2. Patronen: past het bij de omliggende code, zonder nieuwe dependencies en zonder I/O binnen src/?
3. De regels van het project: in deze repo betekent dat alleen RNG met seed (zoek in de diff naar Math.random), zichtbare tekst in de talenbundels (niet hardcoded) en kaartregels die nooit breder zijn dan de breedte waarop de lay-out opvult.
4. Toegankelijkheid: overleeft nieuwe uitvoer --accessible? Draai lockedin --accessible <your command> en controleer dat het leest als schone platte tekst — zonder nieuwe decoratieve gliefen die langs a11yFilter glippen.
5. Tests: is er een nieuwe test, en zou die echt falen als de feature stuk ging? Vraag: "Welke regel zou ik moeten veranderen om deze nieuwe test te laten falen?"
6. Draai het: npm test, draai daarna het commando en kijk naar de uitvoer.

Je hoeft niet elk teken te begrijpen — maar wel elke beslissing. Als je een wijziging niet kunt uitleggen, vraag de agent dan eerst om haar uit te leggen voordat je haar accepteert.

Itereer wanneer het niet groen is

Een rode barrière is een normale stap, geen mislukking. De oplossing is nauwkeurige feedback:

"npm test faalt met: [paste the exact error]. De breedtetest van renderEndorse verwacht dat elke kaartregel ≤ 60 zichtbare kolommen heeft. Los het op zonder de test zwakker te maken."

Plak de echte fouttekst. "Het is stuk" laat de agent gokken; de stack trace laat hem het repareren. En geef er de voorkeur aan om in hetzelfde gesprek verder te gaan in plaats van opnieuw te beginnen — de agent heeft de context van wat hij net schreef al. Als twee of drie iteraties niet convergeren, doe dan een stap terug en herschaal: de taak is misschien te groot voor één prompt.

Houd vaart tussen sessies

Echt werk bestrijkt meer dan één zit. Twee gewoonten houden een agent door de tijd heen effectief:

• Geheugen / conventies. Als je agent duurzaam geheugen of een projectinstructiebestand ondersteunt, zet daar dan de regels in die die altijd moet volgen (bijv. "alle willekeur moet pick/shuffle gebruiken", "zet zichtbare tekst in de talenbundels", "draai npm test voordat je klaar zegt"). Dan spreek je een conventie één keer af in plaats van in elke prompt.
• Een overdrachtsnotitie. Deze repo houdt een korte, opgeschoonde statusnota bij in docs/HANDOFF.md: wat het project is, hoe het gebouwd is, hoe het getest wordt en wat hierna komt. Wanneer je terugkomt (of het overdraagt aan een teamgenoot — of een andere agent), bouwt die notitie de context in seconden weer op. Vraag je agent om die als onderdeel van een wijziging actueel te houden.

Guardrails die je wilt houden

• De barrière is niet onderhandelbaar. Groene tests voordat er iets wordt opgeleverd. Dat is wat je snel laat bewegen én de uitvoer laat vertrouwen.
• Jij bent de reviewer van record. De agent schrijft; jij beslist. Een diff accepteren betekent dat jij ervoor instaat.
• Kleine, verifieerbare stappen verslaan één gigantische sprong. Elke geaccepteerde wijziging moet de app werkend achterlaten.

---

✅ Probeer het met je agent

1. Schrijf een specificatie van één alinea voor een mentor-commando ("deelt ongevraagd advies uit"), inclusief beperkingen, en laat de agent het test-first bouwen — plan, tests, code, barrière — met review op elke stap.
2. Vraag de agent om docs/HANDOFF.md bij te werken zodat het nieuwe commando erin staat.
3. Maak expres iets stuk (bijv. verwijder een pool-item), draai npm test en oefen ermee om de agent de exacte fout te voeren die hij moet oplossen.

---

Waar je hierna heen kunt

• Bekijk de echte code in src/lockedin.js — je kent de vorm er nu van.
• Lees docs/HANDOFF.md voor de eigen status- en architectuurnotities van het project.
• Geniet van de grappen in de Commandoreferentie.

Dat is de tutorial. Je kunt nu een AI-agent aansturen om echte software te bouwen en te veranderen achter een testbarrière — met het meest overmoedige voorbeeld denkbaar. Mee eens? 👇