14 dec 2025·6 min
Claude Code taakafbakening: van vage verzoeken naar commits
Leer Claude Code taakafbakening om rommelige functieverzoeken om te zetten in duidelijke acceptatiecriteria, een minimaal UI/API-plan en een paar kleine commits.
Leer Claude Code taakafbakening om rommelige functieverzoeken om te zetten in duidelijke acceptatiecriteria, een minimaal UI/API-plan en een paar kleine commits.
Een vaag verzoek klinkt onschuldig: “Voeg een betere zoekfunctie toe”, “Maak onboarding soepeler”, “Gebruikers hebben meldingen nodig.” In echte teams komt het vaak binnen als een eendelige chatmelding, een screenshot met pijlen, of een half-onthouden klantgesprek. Iedereen is het erover eens, maar iedereen heeft iets anders voor ogen.
De kosten verschijnen later. Als de scope onduidelijk is, bouwen mensen op gissingen. De eerste demo wordt weer een ronde van verduidelijking: “Dat is niet wat ik bedoelde.” Werk wordt opnieuw gedaan en de verandering groeit stilletjes. Ontwerptweaks veroorzaken codewijzigingen, die weer meer testen nodig maken. Reviews vertragen omdat een vage wijziging moeilijk te verifiëren is. Als niemand kan definiëren wat “correct” is, eindigen reviewers met het bespreken van gedrag in plaats van het controleren van kwaliteit.
Je kunt een va taak meestal vroeg herkennen:
Een goed afgebakende taak geeft het team een finishlijn: duidelijke acceptatiecriteria, een minimaal UI- en API-plan, en expliciete grenzen rond wat niet inbegrepen is. Dat is het verschil tussen “zoek verbeteren” en een kleine wijziging die makkelijk te bouwen en reviewen is.
Een praktische gewoonte: scheid “definition of done” van “nice-to-have.” “Done” is een korte lijst checks die je kunt uitvoeren (bijv.: “Zoek geeft resultaten terug op titel, toont ‘Geen resultaten’ bij leeg, en behoudt de query in de URL”). “Nice-to-have” is alles dat kan wachten (synoniemen, ranking-aanpassingen, markering, analytics). Dit vooraf labelen voorkomt onbedoelde scopegroei.
Vage verzoeken beginnen vaak als voorgestelde fixes: “Voeg een knop toe”, “Schakel naar een nieuwe flow”, “Gebruik een ander model.” Pauzeer en vertaal het voorstel eerst naar een resultaat.
Een eenvoudig format helpt: “Als een [gebruiker], wil ik [iets doen], zodat ik [een doel bereik].” Houd het simpel. Als je het niet in één zin kunt zeggen, is het nog te vaag.
Beschrijf daarna wat er voor de gebruiker verandert als het af is. Richt je op zichtbaar gedrag, niet op implementatiedetails. Bijvoorbeeld: “Nadat ik het formulier heb ingediend, zie ik een bevestiging en kan ik het nieuwe record in de lijst terugvinden.” Dat creëert een duidelijke finishlijn en maakt het lastiger dat “nog even een wijziging” er ongemerkt insluipt.
Schrijf ook op wat hetzelfde blijft. Non-goals beschermen je scope. Als het verzoek is “onboarding verbeteren”, kan een non-goal zijn “geen dashboard redesign” of “geen wijzigingen in prijsplannen”.
Kies tenslotte één primaire pad om eerst te ondersteunen: de enkele end-to-end slice die bewijst dat de feature werkt.
Voorbeeld: in plaats van “voeg snapshots overal toe”, schrijf: “Als project-eigenaar kan ik de laatste snapshot van mijn app herstellen, zodat ik een slechte wijziging ongedaan kan maken.” Non-goals: “geen bulk restore, geen UI-ontwerpwijziging.”
Een vaag verzoek mist zelden moeite. Het mist beslissingen.
Begin met constraints die de scope stilletjes veranderen. Deadlines doen ertoe, maar ook toegangsregels en compliance-eisen. Als je bouwt op een platform met tiers en rollen, beslis vroeg wie de feature krijgt en onder welk plan.
Vraag vervolgens om één concreet voorbeeld. Een screenshot, het gedrag van een concurrent, of een eerder ticket onthullen wat “beter” daadwerkelijk betekent. Als de aanvrager dat niet heeft, vraag ze om de laatste keer dat ze de pijn voelden na te spelen: op welk scherm waren ze, wat klikten ze, wat verwachtten ze?
Randgevallen zijn waar scope explodeert, dus benoem de grote vroeg: lege data, validatiefouten, trage of mislukte netwerkoproepen, en wat “ongedaan maken” echt betekent.
Bepaal ten slotte hoe je succes verifieert. Zonder een testbaar resultaat verandert de taak in meningen.
Deze vijf vragen halen meestal het grootste deel van de ambiguïteit weg:
Voorbeeld: “Voeg custom domains toe voor klanten” wordt duidelijker zodra je beslist tot welke tier het behoort, wie het kan instellen, of hostinglocatie voor compliance van belang is, welke foutmelding bij een ongeldige DNS verschijnt, en wat “klaar” betekent (domein geverifieerd, HTTPS actief en een veilige rollback-optie).
Rommelige verzoeken mengen doelen, gissingen en half-herstelde randgevallen. De taak is om dat om te zetten in uitspraken die iedereen kan testen zonder in je hoofd te moeten lezen. Dezelfde criteria moeten ontwerp, codering, review en QA sturen.
Een eenvoudig patroon houdt het helder. Je kunt Given/When/Then gebruiken, of korte bullets die hetzelfde betekenen.
Schrijf elk criterium als één test die iemand kan uitvoeren:
Pas het nu toe. Stel dat de notitie zegt: “Maak snapshots makkelijker. Ik wil terugrollen als de laatste wijziging dingen kapot maakt.” Zet het om in testbare uitspraken:
Als QA deze checks kan uitvoeren en reviewers ze kunnen verifiëren in de UI en logs, ben je klaar om UI- en API-werk te plannen en het op te splitsen in kleine commits.
Een minimaal UI-plan is een belofte: de kleinste zichtbare verandering die bewijst dat de feature werkt.
Begin met het benoemen van welke schermen veranderen en wat een persoon binnen 10 seconden zal opmerken. Als het verzoek zegt “maak het makkelijker” of “maak het schoner”, vertaal dat naar één concrete wijziging die je kunt aanwijzen.
Schrijf het als een kleine kaart, geen redesign. Bijvoorbeeld: “Orders-pagina: voeg een filterbalk boven de tabel toe”, of “Instellingen: voeg een nieuwe schakelaar toe onder Meldingen.” Als je het scherm en het exacte element niet kunt benoemen, is de scope nog onduidelijk.
De meeste UI-wijzigingen hebben een paar voorspelbare staten nodig. Noem alleen degene die van toepassing zijn:
UI-tekst hoort bij de scope. Leg labels en meldingen vast die goedgekeurd moeten worden: knoptekst, veldlabels, helpertekst en foutmeldingen. Als de tekst nog open staat, markeer het als placeholder en noteer wie het zal bevestigen.
Houd een kleine “niet nu”-notitie voor alles wat niet nodig is om de feature te gebruiken (responsieve polish, geavanceerde sortering, animaties, nieuwe iconen).
Een afgebakende taak heeft een klein, duidelijk contract tussen UI, backend en data. Het doel is niet om het hele systeem te ontwerpen, maar om de kleinste set requests en velden te definiëren die bewijzen dat de feature werkt.
Begin met het opnoemen van de data die je nodig hebt en waar het vandaan komt: bestaande velden die je kunt lezen, nieuwe velden die je moet opslaan, en waarden die je kunt berekenen. Als je voor elk veld geen bron kunt noemen, heb je nog geen plan.
Houd het API-oppervlak klein. Voor veel features is één read en één write genoeg:
GET /items/{id} retourneert de staat die nodig is om het scherm te renderenPOST /items/{id}/update accepteert alleen wat de gebruiker kan aanpassen en retourneert de bijgewerkte staatSchrijf inputs en outputs als platte objecten, niet als paragrafen. Voeg verplichte versus optionele velden toe, en wat er gebeurt bij veelvoorkomende fouten (niet gevonden, validatie mislukt).
Doe een snelle auth-check voordat je de database aanraakt. Beslis wie kan lezen en wie kan schrijven, en formuleer de regel in één zin (bijv.: “elke ingelogde gebruiker kan lezen, alleen admins kunnen schrijven”). Het overslaan hiervan leidt vaak tot herwerk.
Bepaal tenslotte wat bewaard moet worden en wat berekend kan worden. Een eenvoudige regel: sla feiten op, bereken weergaven.
Claude Code werkt het beste als je een duidelijk doel en een smalle box geeft. Begin met het plakken van het rommelige verzoek en eventuele beperkingen (deadline, getroffen gebruikers, dataregels). Vraag vervolgens om een afgebakende output die bevat:
Lees het antwoord daarna als een reviewer. Als je zinnen ziet zoals “prestaties verbeteren” of “maak het schoner”, vraag dan om meetbare bewoording.
Verzoek: “Voeg een manier toe om een abonnement te pauzeren.”
Een afgebakende versie zou kunnen zeggen: “Gebruiker kan pauzeren voor 1 tot 3 maanden; volgende factuurdatum wordt aangepast; admin kan pauze-status zien,” en out-of-scope: “Geen wijziging in proration.”
Vanaf daar wordt het commit-plan praktisch: één commit voor DB en API-shape, één voor UI-controls, één voor validatie en foutstaten, één voor end-to-end tests.
Grote wijzigingen verbergen bugs. Kleine commits maken reviews sneller, rollbacks veiliger en helpen je te merken wanneer je van de acceptatiecriteria afdwaalt.
Een nuttige regel: elke commit moet één nieuw gedrag ontgrendelen en een snelle manier bevatten om te bewijzen dat het werkt.
Een veelvoorkomende volgorde ziet er zo uit:
Houd elke commit gefocust. Vermijd “terwijl ik hier toch was”-refactors. Zorg dat de app end-to-end blijft werken, ook als de UI basic is. Bundel migraties, gedrag en UI niet in één commit tenzij er een sterke reden voor is.
Een stakeholder zegt: “Kunnen we Export reports toevoegen?” Dat verbergt veel keuzes: welk rapport, welk formaat, wie kan exporteren en hoe levering werkt.
Stel alleen de vragen die het ontwerp veranderen:
Stel dat de antwoorden zijn: “Sales Summary report, alleen CSV, rol manager, directe download, max laatste 90 dagen.” Nu wordt de v1 acceptatiecriteria concreet: managers kunnen op Export klikken op de Sales Summary pagina; de CSV komt overeen met de kolommen in de tabel; de export respecteert de huidige filters; exporteren van meer dan 90 dagen toont een duidelijke fout; de download voltooit binnen 30 seconden tot 50k rijen.
Minimaal UI-plan: een Export-knop bij de tabelacties, een laadstaat tijdens het genereren en een foutmelding die de gebruiker vertelt hoe het probleem op te lossen (bijv. “Kies 90 dagen of minder”).
Minimaal API-plan: één endpoint dat filters accepteert en een gegenereerde CSV als file-response terugstuurt, hergebruikmakend van dezelfde query als de tabel en de 90-dagenregel server-side afdwingend.
Verstuur het vervolgens in een paar strakke commits: eerst het endpoint voor het vaste happy path, dan UI-koppeling, daarna validatie en gebruikersfouten, en tenslotte tests en documentatie.
Verzoeken zoals “voeg teamrollen toe” verbergen vaak regels over uitnodigen, bewerken en wat er met bestaande gebruikers gebeurt. Als je betrapt wordt op gissingen, schrijf de aanname op en verander het in een vraag of expliciete regel.
Teams verliezen dagen als één taak zowel “werkend maken” als “mooi maken” bevat. Houd de eerste taak gefocust op gedrag en data. Zet styling, animaties en spacing in een vervolgtaak tenzij ze noodzakelijk zijn om de feature te gebruiken.
Edge-cases zijn belangrijk, maar niet allemaal hoeven ze direct opgelost te zijn. Los de paar op die vertrouwen kunnen breken (dubbele submits, conflicterende edits) en stel de rest uit met duidelijke notities.
Als je ze niet opschrijft, mis je ze. Neem ten minste één unhappy path en één permissieregel op in je acceptatiecriteria.
Vermijd “sneller” of “intuïtief” tenzij je er een getal of een concrete check aan koppelt. Vervang ze door iets dat je kunt bewijzen in een review.
Maak de taak zodanig vast dat een collega kan reviewen en testen zonder gedachten te lezen:
Voorbeeld: “Add saved searches” wordt “Gebruikers kunnen een filter opslaan en later opnieuw toepassen”, met non-goals zoals “geen delen” en “geen sorteerwijzigingen”.
Als je eenmaal een afgebakende taak hebt, bescherm die dan. Doe voor het coderen een korte sanity-review met de mensen die om de wijziging vroegen:
Bewaar daarna de criteria waar het werk gebeurt: in het ticket, in de PR-beschrijving en overal waar je team echt kijkt.
Als je bouwt in Koder.ai (koder.ai), helpt het om eerst het plan vast te leggen en daarna code te genereren vanuit dat plan. Planning Mode past goed bij die workflow, en snapshots en rollback houden experimenten veilig wanneer je een aanpak wilt uitproberen en weer terugdraaien.
Als er tijdens het bouwen nieuwe ideeën opkomen, houd dan de scope stabiel: schrijf ze in een follow-up lijst, pauzeer om ze opnieuw te scopen als ze de acceptatiecriteria veranderen, en houd commits gekoppeld aan één criterium per keer.
Begin met het resultaat in één zin te beschrijven (wat de gebruiker kan doen als het klaar is), en voeg dan 3–7 acceptatiecriteria toe die een tester kan verifiëren.
Als je het "correcte" gedrag niet kunt beschrijven zonder erover te debatteren, is de taak nog steeds vaag.
Gebruik dit snelle format:
Voeg vervolgens één concreet voorbeeld toe van het verwachte gedrag. Als je geen voorbeeld kunt geven, speel dan de laatste keer na dat het probleem zich voordeed en beschrijf wat de gebruiker klikte en verwachtte te zien.
Schrijf eerst een korte "Definition of done"-lijst (de checks die moeten slagen), daarna een aparte "Nice-to-have"-lijst.
Standaardregel: als het niet nodig is om te bewijzen dat de feature end-to-end werkt, hoort het bij nice-to-have.
Stel de paar vragen die de scope veranderen:
Deze dwingen de ontbrekende beslissingen naar boven.
Behandel edge-cases als scope-items, niet als verrassingen. Voor v1 dek je de gevallen die vertrouwen kunnen breken:
Alles wat daarna komt kan expliciet als out-of-scope worden aangemerkt.
Gebruik testbare uitspraken die iedereen kan uitvoeren zonder te raden:
Voeg minstens één foutgeval en één permissieregel toe. Als een criterium niet getest kan worden, herschrijf het dan totdat dat wel kan.
Noem de exacte schermen en de ene zichtbare verandering per scherm.
Noem ook de vereiste UI-staten:
Houd copy (knoptekst, fouten) in scope, ook als het tijdelijke tekst is.
Houd het contract klein: vaak is één lees en één schrijf genoeg voor v1.
Definieer:
Sla feiten op; bereken weergaven wanneer mogelijk.
Vraag om een geblokkeerde deliverable:
Vraag daarna onduidelijke zinnen zoals "make it cleaner" te specificeren in meetbaar gedrag.
Standaardvolgorde:
Vuistregel: één commit = één nieuw zichtbaar gebruikersgedrag + een snelle manier om te bewijzen dat het werkt. Vermijd het meepakken van "while I’m here" refactors in feature-commits.