Claude voor programmeren: wat kan het écht als developer?Leestijd: maximaal 10 minuten
Een nieuwe functie laten maken is indrukwekkend. Maar Claude voor programmeren wordt pas interessant wanneer de opdracht minder netjes is: een fout in bestaande software, oude code zonder uitleg of een wijziging die elders iets kapot kan maken. Kan Claude dan nog helpen? Ja, als programmeerhulp kan het veel werk voorbereiden en uitvoeren. Maar de betere vraag is hoeveel onderzoek, correctie en controle een mens daarna nog moet doen.

Claude voor programmeren: beoordeel de hele klus
Stel: een kleine Nederlandse vereniging heeft een ledenportaal. Een vrijwilliger meldt dat een adreswijziging wel op het scherm verschijnt, maar niet in de bevestiging terechtkomt. ‘Pas de bevestiging aan’ klinkt als een korte opdracht. Toch kan de oorzaak liggen bij het formulier, de opslag of de manier waarop het bericht wordt samengesteld.
Een AI-assistent kan een aannemelijke oplossing voorstellen. In Claude Code kan de assistent, afhankelijk van de gegeven toegang, ook relevante projectbestanden onderzoeken en wijzigingen maken. Maar een aannemelijke oplossing is nog geen aangetoonde oplossing. Pas wanneer je het oorspronkelijke probleem opnieuw probeert en bestaande functies controleert, weet je meer.
Daarom kijken we bij WegwijsAI liever naar de hele klus dan naar één fraai codefragment:
Probleem begrijpen → relevante bestanden vinden → aanpak kiezen → wijzigen → controleren → herstellen → menselijke review.

Ben je vooral benieuwd hoe de programmeeromgeving zelf werkt? Lees dan onze uitleg over Claude Code. In dit artikel gaat het om de beoordeling van het resultaat, niet om installatie of functies.
De lastigste opdracht begint in bestaande code
Een leeg project geeft Claude veel vrijheid. Dat maakt een eerste demo aantrekkelijk, maar ook een beetje misleidend. In bestaande software liggen keuzes vaak al vast. Een nieuwe functie moet aansluiten op oude gegevens, afspraken en uitzonderingen die niet allemaal op één plek staan.
Neem een reserveringssysteem voor een buurthuis. Op dinsdagavond mogen zalen later openblijven dan op andere dagen. Die regel staat niet in de algemene handleiding, maar blijkt uit een oude test en een opmerking bij een functie. Als Claude alleen het nieuwe formulier bekijkt, kan het een keurige wijziging maken die de dinsdagregel negeert.
Hier zit het eerste tegenintuïtieve inzicht: een kleine wijziging in een oud project kan moeilijker zijn dan een complete demo vanaf nul. Bij een demo bepaalt de maker de spelregels. Bij onderhoud moet je de bestaande spelregels eerst vinden.

Een eerlijke beoordeling vraagt daarom niet alleen: ‘Heeft Claude de juiste code geschreven?’ Vraag ook:
- Welke bestanden heeft Claude bekeken?
- Welke bestaande afspraken heeft het genoemd?
- Heeft het iets gewijzigd buiten de opdracht?
- Welke aannames bleven onbevestigd?
- Kan een ander de wijziging later nog begrijpen?
Dat zijn vragen die ook voor een beginner begrijpelijk zijn. Je hoeft niet iedere coderegel te lezen om te zien dat ‘ik heb het opgelost’ zonder uitleg of controle onvoldoende bewijs is.
Vage opdrachten laten zien of Claude meedenkt
‘Voeg abonnementen toe aan mijn app.’ Het klinkt duidelijk totdat je moet beslissen wat er gebeurt bij een mislukte betaling. Blijft iemand toegang houden? Komt er een herinnering? En wie mag een abonnement beëindigen?
Een codegenerator kan die open plekken ongemerkt invullen. Een bruikbare ontwikkelassistent zou ze eerst zichtbaar moeten maken. Dat onderscheid kun je toetsen zonder een groot project te bouwen: geef Claude een bewust onvolledige opdracht en noteer welke vragen het stelt vóórdat het wijzigingen voorstelt.
Misverstand: als Claude direct begint te bouwen, begrijpt het de opdracht goed. Snel beginnen kan juist betekenen dat belangrijke keuzes stilzwijgend zijn aangenomen. Het gevolg zie je soms pas wanneer iemand de functie op een onverwachte manier gebruikt.
Vraag bijvoorbeeld:‘Voeg abonnementen toe. Noem eerst welke beslissingen ontbreken. Verander nog niets.’ Beoordeel daarna niet de hoeveelheid tekst, maar de relevantie van de vragen. Een vraag over een lettertype is hier minder belangrijk dan een vraag over toegang na een mislukte betaling.
Kan Claude een fout ook zelf ontdekken?
Claude Code kan wijzigingen maken en controles uitvoeren. Dat maakt een nuttige werkwijze mogelijk: laat het eerst het probleem onderzoeken, daarna een wijziging voorstellen en vervolgens het resultaat toetsen. Maar de controle moet wel iets zeggen over de werkelijke opdracht.
Mis geen nieuw Claude-artikel
Ontvang een melding zodra WegwijsAI een nieuwe handleiding, vergelijking of praktische update over Claude publiceert.
Stel dat het ledenportaal na een adreswijziging weer een bevestiging verstuurt. Een test die alleen controleert óf er een bericht wordt gemaakt, kan slagen terwijl het oude adres nog in dat bericht staat. Een groen vinkje is dan echt, maar beantwoordt de verkeerde vraag.
Dit is het tweede tegenintuïtieve inzicht: meer tests zijn niet automatisch betere tests. De waarde zit in wat ze proberen te weerleggen. Een goede controle probeert juist de fout te vinden die je vreest, inclusief gevolgen voor bestaande ledengegevens.
Bij WegwijsAI zouden we daarom drie soorten bewijs naast elkaar leggen: wat Claude zegt te hebben gedaan, wat de uitgevoerde controles laten zien en wat een mens in het werkende product ziet. Als die drie uiteenlopen, is de taak nog niet klaar.
Zo maak je er een eerlijke praktijktest van
Onderstaande opzet is een voorstel voor WegwijsAI-onderzoek, geen verslag van uitgevoerde tests. Gebruik een kopie van een project en laat een developer vooraf bepalen wat als geslaagd geldt.
- Kies vaste opdrachten. Neem bijvoorbeeld een nieuwe functie, een bestaande bug, een aanpassing aan oude code, een test en een onduidelijke opdracht.
- Leg de uitgangssituatie vast. Bewaar de projectversie, bestaande controles en de precieze opdracht. Anders vergelijk je later verschillende situaties.
- Definieer succes vóór de start. Noteer welk gedrag moet werken en wat beslist niet mag veranderen.
- Laat Claude eerst onderzoeken. Vraag welke bestanden en afspraken relevant lijken. Laat nog niets wijzigen.
- Laat één afgebakende wijziging uitvoeren. Bewaar de eerste poging, niet alleen de uiteindelijke versie.
- Controleer met onafhankelijk bewijs. Gebruik bestaande tests, een handmatige controle en beoordeling door een developer.
- Noteer de menselijke inspanning. Meet correctierondes, tijd voor review en herstel van onverwachte fouten.
Herhaal belangrijke opdrachten. Eén uitkomst kan toevallig goed of slecht zijn. Houd ook de gebruikte Claude-omgeving gelijk: een gesprek waarin je zelf code plakt, is niet dezelfde proef als een agent die toegang tot een project heeft.
Tien opdrachten voor een echte testset
| Opdracht | Belangrijkste controlevraag |
|---|---|
| Nieuwe functie toevoegen | Past de functie bij bestaande afspraken? |
| Bestaande bug oplossen | Is de oorzaak weg, niet alleen het zichtbare symptoom? |
| Oude code opschonen | Blijft het bestaande gedrag gelijk? |
| Kleine API-aanpassing | Blijven bestaande gebruikers van de koppeling werken? |
| Databasewijziging | Blijven oude gegevens bruikbaar? |
| Tests toevoegen | Vinden de tests ook een bewust aangebrachte fout? |
| Documentatie bijwerken | Komt de uitleg overeen met het werkelijke gedrag? |
| Traag onderdeel onderzoeken | Is de oorzaak aangetoond vóór de wijziging? |
| Mogelijk beveiligingsprobleem beoordelen | Is de bevinding gecontroleerd door een deskundige? |
| Onbekende codebase uitleggen | Kloppen de genoemde verbanden tussen onderdelen? |
De tabel is geen uitnodiging om Claude zelfstandig aan een echte betaalomgeving of klantendatabase te laten werken. Juist bij gegevens, betalingen en beveiliging moet een deskundige de opdracht en uitkomst beoordelen.
Meet niet alleen snelheid, maar ook herstelwerk
De eerste versie is makkelijk te timen. Het lastige werk begint soms daarna. Een snelle wijziging kan drie extra gesprekken vragen omdat Claude een uitzondering miste. Een langzamere aanpak met eerst een plan kan uiteindelijk minder review kosten.
Meet daarom per opdracht:
Totale werktijd = voorbereiding + AI-uitvoering + menselijke correcties + review + herstelwerk.
Tel daarnaast het aantal momenten waarop een mens inhoudelijk moest ingrijpen. Noem dat desgewenst de begeleidingsscore. Gebruik hem alleen om opdrachten binnen dezelfde testopzet te vergelijken. Eén ontbrekende veiligheidsvoorwaarde weegt immers zwaarder dan drie kleine tekstcorrecties.
| Opdracht | Eerste versie | Correctierondes | Reviewtijd | Bestaande controles | Onverwachte wijziging |
|---|---|---|---|---|---|
| Bug in ledenportaal | Nog niet gemeten | Nog niet gemeten | Nog niet gemeten | Nog niet uitgevoerd | Nog niet beoordeeld |
| Oude code opschonen | Nog niet gemeten | Nog niet gemeten | Nog niet gemeten | Nog niet uitgevoerd | Nog niet beoordeeld |
| Onduidelijke functieopdracht | Nog niet gemeten | Nog niet gemeten | Nog niet gemeten | Nog niet uitgevoerd | Nog niet beoordeeld |
Publiceer deze tabel pas als resultaat zodra de cellen met echte waarnemingen zijn ingevuld. Bewaar daarbij screenshots van de eerste poging, de relevante wijzigingen en de controle-uitkomst. Een mooi eindscherm alleen laat niet zien hoeveel begeleiding nodig was.
Wat zegt dit over Claude als developer?
Claude kan helpen bij het begrijpen van code, het voorbereiden van wijzigingen en het uitvoeren van afgebakende ontwikkeltaken. Maar ‘als developer’ is een grotere claim. Een developer beslist ook welke vraag eerst beantwoord moet worden, welke bestaande afspraak belangrijk is en wanneer een resultaat verantwoord gebruikt kan worden.
Daarom is ons voorlopige WegwijsAI-perspectief, nadrukkelijk geen testuitslag: behandel Claude als een krachtige uitvoerder die je beter kunt beoordelen naarmate de opdracht duidelijker en de controle sterker is. Laat het bij een onbekend project eerst uitleggen wat het denkt te veranderen. Geef het vervolgens een beperkte taak en vraag om zichtbaar bewijs van de controles.

Wil je de algemene mogelijkheden van de assistent eerst op je gemak bekijken? De Claude-kennispagina van WegwijsAI biedt daarvoor de ingang. Werk je met terugkerende achtergrondinformatie, dan helpt de aparte uitleg over Claude Projects om te bepalen welke context je vooraf kunt meegeven. Een Project met bestanden is echter niet hetzelfde als een geslaagde praktijktest in een codebase.

De beste proef begint dus niet met ‘bouw iets indrukwekkends’. Begin met een kleine fout waarvan je weet hoe de juiste uitkomst eruitziet. Dan kun je niet alleen zien wat Claude maakt, maar ook wat het begrijpt, mist en zelf weet te controleren.
👉 Wil je rustig met Claude beginnen? Kies één overzichtelijke taak, bekijk eerst de WegwijsAI-uitleg over Claude en laat belangrijke code altijd controleren vóór gebruik.
Dit artikel is geschreven en gecontroleerd door Maarten en Sanne van WegwijsAI.’
Veelgestelde vragen
Kan Claude zelfstandig een programmeerfout oplossen?
Claude Code kan een fout onderzoeken, een wijziging maken en controles uitvoeren als het toegang tot de benodigde omgeving heeft. Of de fout werkelijk is opgelost, hangt af van de opdracht en de kwaliteit van die controles. Beoordeel ook of andere functies zijn blijven werken.
Heb ik programmeerkennis nodig om Claude voor code te gebruiken?
Je kunt zonder programmeerkennis een vraag stellen of code laten uitleggen. Voor wijzigingen aan een echte website of applicatie is deskundige controle verstandig. Anders kun je moeilijk vaststellen of een oplossing betrouwbaar en onderhoudbaar is.
Wat is de beste eerste test voor Claude?
Kies een kleine, bekende fout in een kopie van een project. Leg vooraf vast wat de juiste uitkomst is. Vraag Claude eerst om een analyse en beoordeel daarna de wijziging, de uitgevoerde controles en de benodigde menselijke correcties.







