Eighty
← Blog

Claude Code als diagnosetool: bouw een slimme foutanalyse in je SaaS met één prompt

4 mei 2026/5 min lezen/Door de Eighty redactie

Harvard zegt: AI diagnosticeert beter. Geldt dat ook voor jouw app?

Een nieuw Harvard-onderzoek laat zien dat grote taalmodellen in meerdere medische contexten nauwkeuriger diagnoses stellen dan echte SEH-artsen. Dat staat vandaag op TechCrunch. Het gaat om echte spoedgevallen waarbij het model beter presteerde dan twee menselijke dokters.

Nu, jij bent geen dokter en je SaaS is geen ziekenhuis. Maar de kern van dat onderzoek raakt iets dat elke maker herkent: AI is extreem goed in patroonherkenning op basis van symptomen. En wat zijn errors in je app anders dan symptomen?

Wat betekent dit voor jouw project?

Als je een SaaS bouwt, ken je het gevoel: een gebruiker stuurt een screenshot van een rode foutmelding, of je ziet in je logs iets als Error: Cannot read properties of undefined en je hebt geen idee waar het vandaan komt. Je begint te gissen, te googelen, Stack Overflow af te struinen.

Claude Code kan die diagnostische rol overnemen. Niet als vervanging van je gezond verstand, maar als co-pilot die de symptomen leest en je direct de meest waarschijnlijke oorzaak plus een fix geeft. Vanavond bouw je die workflow in je eigen project.

Hoe pak je het aan met Claude Code?

Stap 1: Geef Claude Code de context van je project

Dit werkt het beste als Claude weet hoe jouw stack eruitziet. Open je project in Claude Code en begin met een contextuele instructie. Zet dit in je CLAUDE.md als je dat nog niet hebt:

# CLAUDE.md

## Stack
- Next.js 14 (App Router)
- Supabase voor database en auth
- Stripe voor betalingen
- Deployed op Vercel

## Foutanalyse-aanpak
Als ik een error deel, analyseer dan:
1. Wat de directe oorzaak is
2. In welk bestand/functie dit waarschijnlijk zit
3. Een concrete fix met codevoorbeeld
4. Hoe ik dit in de toekomst voorkom

Die CLAUDE.md zorgt ervoor dat Claude bij elke sessie weet wat voor soort app je bouwt, zonder dat je dat elke keer opnieuw hoeft uit te leggen.

Stap 2: Plak een error en vraag om diagnose

Kopieer de volledige foutmelding uit je terminal of browser console en gebruik deze prompt:

Hier is een error die ik krijg in mijn Next.js app:

[PLAK HIER JE VOLLEDIGE ERROR INCLUSIEF STACK TRACE]

Analyseer de oorzaak stap voor stap. Wat gaat er mis, in welk bestand zit het waarschijnlijk, en geef me de exacte fix. Als je meer context nodig hebt, vraag ernaar.

Het "als je meer context nodig hebt, vraag ernaar" is cruciaal. Het zorgt ervoor dat Claude niet gaat raden maar jou om het juiste bestand vraagt als de stack trace niet genoeg info geeft.

Stap 3: Bouw een herbruikbare error-logger in je app

In plaats van errors alleen in de console te laten verschijnen, bouw je een kleine utility die errors gestructureerd vastlegt zodat je ze makkelijker naar Claude kunt kopiëren:

// lib/logger.ts
export function logError(context: string, error: unknown) {
  const timestamp = new Date().toISOString();
  const message = error instanceof Error ? error.message : String(error);
  const stack = error instanceof Error ? error.stack : undefined;

  console.error(JSON.stringify({
    timestamp,
    context,
    message,
    stack,
  }, null, 2));
}

Gebruik het zo in je server actions of API routes:

// app/actions/subscribe.ts
import { logError } from "@/lib/logger";

export async function subscribeUser(email: string) {
  try {
    // jouw logica hier
  } catch (error) {
    logError("subscribeUser", error);
    throw error;
  }
}

Vraag Claude Code dit door je bestaande project te laten uitrollen:

Voeg de logError utility toe aan mijn project in lib/logger.ts en wrap daarna alle try/catch blokken in mijn /app/actions map met deze logger. Zorg dat de context-string de naam van de functie bevat.

Stap 4: Vraag Claude om preventieve diagnose

Dit is de krachtigste stap. Je hoeft niet te wachten tot er iets kapot gaat. Laat Claude proactief zwakke plekken opsporen:

Bekijk mijn bestand app/actions/subscribe.ts en identificeer de drie meest waarschijnlijke plekken waar dit fout kan gaan in productie. Leg per risico uit wat er mis kan gaan en geef een fix.

Of breder:

Loop door alle bestanden in mijn /app/api map en zoek naar ontbrekende error handling, unhandled promises, en plekken waar ik userinput niet valideer. Maak een lijst met de gevonden problemen gesorteerd op ernst.

Dat is precies de diagnostische logica uit het Harvard-onderzoek: patronen herkennen voordat de patient neerslaat.

Stap 5: Maak een error-template voor terugkerende problemen

Als je merkt dat je steeds hetzelfde soort errors krijgt (bv. Supabase auth-problemen of Stripe webhook-fouten), vraag Claude dan om een template te maken:

Ik krijg regelmatig errors met Supabase Row Level Security. Maak voor mij een standaard debug-checklist die ik kan doorlopen als ik een RLS-error krijg, inclusief de SQL-queries die ik in het Supabase dashboard kan runnen om het probleem te isoleren.


Wat te checken na afloop

  • Staat je CLAUDE.md in de root van je project en bevat het je stack-informatie?
  • Kun je een echte error uit je project naar Claude plakken en een bruikbare fix terugkrijgen binnen twee uitwisselingen?
  • Is de logError utility aangemaakt en gebruikt in minimaal één bestand?
  • Heeft Claude bij de preventieve scan minimaal twee concrete problemen gevonden die je daarna hebt opgelost?

Als je op alle vier ja kunt zeggen, heb je vanavond een diagnostische laag toegevoegd aan je workflow die je uren debuggen gaat schelen.


Wil je dit zelf leren?

Bij Eighty leer ik je Claude Code in het Nederlands gebruiken, van installatie tot een werkend SaaS-product. Wekelijks een nieuwe module, persoonlijke begeleiding.