Claude Code-serie handleiding 4: Wat zijn de gebruiksscenario's van Claude Code?

Typische gebruiksscenario's

Ik verdeel de gebruiksscenario's in vier categorieën, gerangschikt van hoogste naar laagste frequentie.

Categorie 1: Code begrijpen

Dit is waarschijnlijk de meest gebruikte categorie. Als je een project van iemand anders overneemt, een oude module bekijkt, of een repository zonder documentatie opent, vraag het direct aan Claude.

Concrete aanpak:

claude "Waar gaat dit project over? Waar is de ingang?" — Het leest package.json, de mappenstructuur, sleutelbestanden en geeft een samenvatting.
Open een functie, laat het de logica uitleggen en het proces beschrijven (met tekst).
Laat het een volledig pad van een API-verzoek volgen van frontend naar database.

Het werk dat het hier doet, is in wezen het 'vieze werk van code lezen' voor je doen. Je hoeft niet zelf uren te grep'en en dan de puzzel in je hoofd te leggen. Het maakt het pad duidelijk, jij maakt de beoordeling.

De alternatieven voor deze categorie zijn: handmatig door de codebase bladeren, notities maken, aanroepdiagrammen tekenen.

Categorie 2: Code schrijven en wijzigen

Dit is de meest besproken categorie, maar eigenlijk wordt deze het minst gebruikt. De scenario's voor het schrijven van code zijn meestal als volgt:

Nieuwe functionaliteit genereren: 'Voeg een interface toe om het e-mailadres te wijzigen in de user-module, valideer het e-mailformaat en schrijf unit tests.'
Cross-bestand refactoren: 'Vervang alle moment() in deze drie bestanden door dayjs(), verander geen andere logica.'
Migratie en upgrade: 'Herstructureer dit Vue 2-component naar Vue 3 Composition API-syntaxis.'

De gegenereerde code is niet per se meteen correct, maar het kan alle cross-bestand wijzigingen in één keer doen, en je kunt per bestand diffs bekijken en accepteren of weigeren.

De alternatieven voor deze categorie zijn: handmatig repetitieve code schrijven, handmatig zoeken en vervangen van cross-bestand verwijzingen.

Categorie 3: Debuggen en repareren

Wanneer een bug optreedt, is de gebruikelijke werkstroom: foutmelding bekijken, bestand lokaliseren, oorzaak raden, proberen te wijzigen, als het niet werkt terugkijken. Claude Code kan de volledige foutstack ontvangen en samen met de projectcode zelf lokaliseren.

Typisch gebruik:

Geef het de mislukte testuitvoer, het leest de relevante code, geeft een wijzigingsvoorstel, voert na wijziging de test opnieuw uit om te zien of deze slaagt.
Bij een CI-fout, plak de log, laat het repareren, en voer na reparatie git diff uit om de wijzigingen te bevestigen.

Hier fungeert het meer als een 'eerste ronde onderzoeker'. Jij besteedt tijd aan het nadenken over het probleem, maar het bladert door bestanden, vergelijkt verschillen en voert validatieopdrachten uit.

De alternatieven voor deze categorie zijn: herhaaldelijk tests uitvoeren, foutlogboeken lezen, handmatig codeverschillen vergelijken.

Categorie 4: Diverse automatisering

Deze categorie is het minst opvallend, maar opgeteld bespaart het de meeste tijd.

Voorbeelden:

Git commit-berichten schrijven: claude "Schrijf een commit-bericht in Conventional Commits-formaat op basis van de huidige git diff"
PR-beschrijving genereren: Laat het de verschillen tussen de huidige branch en main vergelijken, een samenvatting van de wijzigingen en testinstructies genereren.
Release notes schrijven: Laat Claude Code de commit-geschiedenis van de afgelopen week lezen en een CHANGELOG genereren.
Omgevingsproblemen oplossen: 'Het installeren van deze afhankelijkheid gaf een fout, kijk naar de terminaluitvoer en vind de oorzaak.'

Deze dingen hebben gemeen: ze zijn niet complex, maar tijdrovend. Zelf doen vereist vensters wisselen en veel typen. Geef het aan Claude, het is in enkele seconden klaar.

De alternatieven voor deze categorie zijn: handmatig tekst bewerken, gestandaardiseerde documentatie schrijven, omgevingsconfiguratieproblemen zoeken.

Een 'kaart'

Als we deze vier categorieën in de dagelijkse werkstroom plaatsen, ziet de kaart er ongeveer zo uit:

Een onbekend project krijgen
    │
    ▼
[Code begrijpen] ─── structuur, ingang, kernlogica achterhalen
    │
    ▼
Beginnen met schrijven van nieuwe functie of module wijzigen
    │
    ▼
[Code schrijven/wijzigen] ─── implementatie genereren, cross-bestand refactoren
    │
    ▼
Testen uitvoeren, bug gevonden
    │
    ▼
[Debuggen en repareren] ─── fout analyseren, lokaliseren, repareren, opnieuw testen
    │
    ▼
Voorbereiden om te committen
    │
    ▼
[Diverse automatisering] ─── commit, PR-beschrijving, release notes schrijven
    │
    ▼
Commit, klaar

Je hoeft het niet in alle vier de kwadranten te gebruiken. Sommige teams gebruiken het alleen om code te begrijpen, anderen alleen om tests te schrijven en PR's te versturen. Welk onderdeel je het meest stoort, begin daar.

Twee bruikbare beoordelingscriteria

Als je niet zeker weet of je een taak aan Claude Code moet overlaten, kun je jezelf twee vragen stellen:

1. Is deze taak meer 'mechanisch' dan 'creatief'?

Honderd verwijzingen wijzigen, uitvoer formatteren, boilerplate-code genereren — deze taken kosten veel tijd als je ze zelf doet, maar je hebt het idee al. Het is geschikt om aan Claude over te laten.

2. Zijn de 'validatiekosten' van deze taak hoog?

Als een wijziging herhaaldelijk schakelen, tests uitvoeren en logboeken bekijken vereist om te bevestigen, dan is het voor een persoon traag om te proberen en fouten te maken. Claude Code kan zelf de cyclus 'wijzigen - uitvoeren - bekijken - opnieuw wijzigen' voltooien, waardoor jij veel rust krijgt.