Fejlfinding med Claude Code og Codex

Claude Code og Codex kan hjælpe med fejlfinding, men de fungerer bedst, når opgaven starter med evidens. En vag prompt som “sitet virker ikke” giver værktøjet for meget plads til at gætte.

For danske virksomhedswebsites handler fejlfinding ofte om konkrete systemer: kontaktformularer, bookingflows, WordPress-plugins, Laravel-jobs, betalingscallbacks, flersprogede sider, Cloudflare-adfærd eller API-integrationer.

Start med et reproducerbart problem

Før et AI-kodeværktøj skal rette noget, bør fakta samles.

Nyttige input:

• Præcis URL eller brugerflow
• Forventet adfærd
• Faktisk adfærd
• Fejlbesked eller logudsnit
• Seneste deploy, plugin-, hosting- eller konfigurationsændringer
• Browser, device eller brugerrolle hvis relevant
• Kommando der reproducerer fejlen, hvis den findes

Jo bedre evidens, desto mindre skal værktøjet opfinde.

Bed om hypoteser før kode

Et godt fejlfindingsworkflow adskiller diagnose fra implementering.

Bed først Claude Code eller Codex om at gennemgå de relevante filer og liste sandsynlige årsager. Bed derefter om, hvilken evidens der kan bekræfte eller afkræfte hver årsag. Først derefter bør værktøjet lave et lille patch.

Det reducerer tilfældige rettelser. Det giver også udvikleren mulighed for at fange en forkert antagelse, før filer ændres.

Hold patch’et reviewbart

Fejl under pres fører ofte til for store ændringer. AI kan gøre det værre, fordi det kan redigere mange filer hurtigt.

Jeg foretrækker et lille patch, der beviser årsagen:

• Tilføj manglende validering
• Ret én forkert betingelse
• Korrigér én API-payload mapping
• Håndtér én timeout- eller retry-sti
• Gendan én route eller redirect
• Tilføj én fokuseret test

Hvis det reelle problem er større, bør den lille rettelse stadig gøre næste trin tydeligere.

Verificér rettelsen

Sidste trin er ikke “AI siger, at det er rettet”. Sidste trin er verificering.

Det kan betyde at køre en test, gentage det oprindelige workflow, tjekke logs, bekræfte et webhook-svar, indsende en formular, gennemgå en genereret side eller se en queue køre efter deploy.

For API-tunge systemer er driftssikre API-integrationer relevant. Ved akutte WordPress-problemer er akut WordPress-hjælp i Danmark ofte et mere direkte udgangspunkt.

Ofte stillede spørgsmål

Er “sitet virker ikke” en god prompt til at starte fejlfinding med Claude Code eller Codex?

Nej. En vag prompt giver værktøjet for meget plads til at gætte. Nyttig fejlfinding starter med evidens: den præcise URL eller det brugerflow, forventet mod faktisk adfærd, fejlbeskeder og eventuelle seneste deploy- eller konfigurationsændringer.

Bør et AI-kodeværktøj rette koden, før årsagen er fundet?

Nej. Et godt workflow adskiller diagnose fra implementering: bed det først om at gennemgå relevante filer og liste sandsynlige årsager, afgør derefter hvilken evidens der kan be- eller afkræfte hver af dem, og lav først patch’et bagefter.

Er et stort AI-genereret patch et godt tegn under fejlfinding?

Nej. Fejl under pres kan føre til for store ændringer, og AI kan gøre det værre ved at redigere mange filer hurtigt. Et lille patch, der beviser årsagen — for eksempel at rette én betingelse eller én payload-mapping — er som regel sikrere og lettere at gennemgå.

Er en rettelse færdig, når AI’en siger, problemet er løst?

Nej. Sidste trin er verificering: at køre en test, gentage det oprindelige workflow, tjekke logs eller bekræfte et webhook-svar. At AI’en påstår noget er rettet, er ikke i sig selv evidens.

Hvornår jeg kan hjælpe

Jeg kan hjælpe med at fejlfinde produktionsproblemer på danske virksomhedswebsites med almindelig udviklerdisciplin og AI-værktøjer, hvor de giver hastighed: repository-gennemgang, loganalyse, patchudkast, review og verificering.

Hvis et website, bookingflow, formular, integration eller backendjob fejler, kan du sende mig symptomerne og de seneste ændringer, så kan jeg foreslå næste debugging-skridt.