ChatGPT mod Claude: Du begrænser dig med kun én AI

I går brugte jeg næsten en time på at få en AI til at gøre noget simpelt: konvertere et PHP-layout til Astro, beholde TailwindCSS og ikke ændre stylingen. I stedet omskrev den dele af layoutet, introducerede custom CSS og “forbedrede” ting, jeg ikke havde bedt om.

Hvis det lyder bekendt, er du ikke alene. ChatGPT og Claude er nu en del af mange udvikleres hverdag, men det nyttige spørgsmål er ikke længere, hvilken der er bedst. Det bedre spørgsmål er: hvilken slags hjælp har du brug for lige nu?

Der er ikke et reelt versus

“ChatGPT mod Claude” er en nyttig søgefrase, men det er ikke en særlig nyttig måde at arbejde på. Hvis du vælger én AI og presser alle opgaver gennem den, begrænser du dig selv.

I 2026 handler sammenligningen ikke kun om to chatvinduer. Udviklere bruger også værktøjer som OpenAI Codex og Claude Code, hvor AI’en kan indgå direkte i et udviklingsworkflow i stedet for kun at svare i en browserfane.

Det ændrer beslutningen. Den vigtige forskel er ikke kun ChatGPT mod Claude. Det handler også om kontekst, begrænsninger, adgang til værktøjer, adgang til repoet, test og hvor meget frihed du giver modellen.

Det rigtige spørgsmål er ikke:

• Hvilken AI er bedst?

Det nyttige spørgsmål er:

• Hvilken AI, i hvilken tilstand, med hvilken kontekst, passer bedst til denne opgave?

Hvad der stadig er forskelligt i praksis

Der er stadig mønstre. De er ikke faste regler, og de ændrer sig med modellen, produktet, prompten og de værktøjer, der er til rådighed. Men i praktisk udviklingsarbejde er forskellene tydelige nok til, at de betyder noget.

Claude føles ofte stærkest, når opgaven er stramt defineret. Hvis du skal bevare et layout, konvertere en komponent, refaktorere en lang fil forsigtigt eller respektere et designsystem, er Claude ofte god til at holde sig tæt på specifikationen.

ChatGPT føles ofte stærkest, når problemet er mindre defineret. Hvis du skal diagnosticere en mærkelig produktionsfejl, planlægge arkitektur, sammenligne tilgange eller forbinde frontend, backend, hosting, SEO, caching og deployment, er ChatGPT ofte god til at tænke på tværs af systemet.

Det betyder ikke, at Claude ikke kan ræsonnere. Det kan den. Det betyder heller ikke, at ChatGPT ikke kan udføre præcist. Det kan den. Fejlen er at behandle en af delene som en garanti.

Et eksempel med kodemigrering

Forestil dig opgaven: “Konverter dette PHP-layout til Astro med TailwindCSS.”

Hvis det reelle krav er at bevare det eksisterende layout, skal prompten sige det tydeligt. Den eksisterende HTML og Tailwind-klasserne er specifikationen. AI’en skal ikke redesigne, optimere, introducere custom CSS eller omstrukturere siden, medmindre du udtrykkeligt beder om det.

Til den type opgave kan Claude være et godt valg, fordi den ofte håndterer kontrolleret implementering godt. Men ChatGPT eller Codex kan også løse opgaven, hvis du begrænser opgaven ordentligt og gennemgår diffen kritisk.

Hvis det reelle krav er bredere, ændrer workflowet sig. Måske vil du vide, om PHP-strukturen passer rent til Astro-komponenter. Måske vil du splitte gentagne blokke ud i genbrugelige komponenter. Måske vil du forbedre tilgængelighed under migreringen. Så beder du ikke længere om en stram konvertering. Du beder om analyse og implementering på samme tid.

Det er her mange AI-assisterede kodeopgaver går galt. Opgaven lyder præcis, men prompten efterlader plads til fortolkning. Den plads udfylder AI’en.

Kun én AI giver blinde vinkler

Det er praktisk at bruge én AI til alt, men det skaber vaner, der er lette at overse.

• Du begynder at acceptere én models standardstil som den rigtige stil
• Du får færre alternative løsninger
• Du mister fordelen ved et uafhængigt review
• Du tilpasser dine prompts for meget til ét værktøj
• Du opdager sjældnere, når værktøjet løser det forkerte problem

Det betyder mere i rigtige kodebaser end i isolerede eksempler. En lille komponentændring, en Laravel-controller, en WordPress-pluginrettelse eller en Astro-content-migrering kan se korrekt ud og stadig introducere subtile problemer.

En anden AI er ikke magi. Den kan også tage fejl. Men den giver dig en anden vinkel. Hvis én model skriver implementeringen, og en anden gennemgår diffen for ændret adfærd, manglende edge cases, tilgængelighedsproblemer eller unødvendig abstraktion, fanger du ofte problemer tidligere.

Værdien ligger ikke i at sende tekst eller kode frem og tilbage for sjov. Værdien ligger i at tvinge et ekstra gennemløb med andre antagelser.

Et praktisk workflow for udviklere

I stedet for at give værktøjerne faste roller som “ChatGPT planlægger” og “Claude implementerer”, så brug et workflow baseret på opgaven.

Trin 1: Definer problemet

Brug en AI til at afklare mål, begrænsninger, edge cases og risici, før du ændrer kode. Ved uklare problemer er ChatGPT ofte nyttig her, fordi den har tendens til at undersøge det bredere system.

Stil spørgsmål som:

• Hvilke antagelser laver jeg?
• Hvad kan gå i stykker, hvis jeg ændrer dette?
• Hvilke filer eller systemer er sandsynligvis involveret?
• Hvad må ikke ændres?

Trin 2: Implementer med stramme rammer

Når retningen er klar, kan du gå i udførelsestilstand. Brug den AI, der har den rigtige kontekst og adgang til de rigtige værktøjer. Det kan være Claude Code, Codex, ChatGPT, Claude eller en anden coding agent i din editor.

Ved implementering bør prompten være mere stram:

• Lav den mindste ændring, der løser problemet
• Bevar eksisterende adfærd, medmindre andet er aftalt
• Redesign eller optimer ikke kode, der ikke har med opgaven at gøre
• Behold Tailwind-klasser og struktur, medmindre der er en klar grund til at ændre dem
• Spørg før du laver antagelser, der påvirker arkitektur eller styling

Trin 3: Review med en anden AI

Efter implementering kan du bruge en anden AI som reviewer. Spørg ikke bare, om koden generelt er “god”. Bed den lede efter konkrete risici.

Nyttige review-prompts er for eksempel:

• Find adfærdsændringer, der ikke var ønsket
• Led efter manglende tests eller edge cases
• Tjek om implementeringen introducerer unødvendig abstraktion
• Tjek tilgængelighed, semantisk HTML og teknisk SEO
• Sammenlign diffen med de oprindelige krav

Trin 4: Debug med reel kontekst

Debugging har normalt størst værdi, når værktøjet kan se de relevante beviser. Logs, stack traces, fejlede tests, deployment-konfiguration, cache-regler, serveradfærd og browser-output betyder alle noget.

Her hjælper bredere ræsonnement. Men bredt ræsonnement uden beviser er gætteri. Giv AI’en den konkrete fejl, relevante filer, seneste ændringer og det, du allerede har undersøgt.

Trin 5: Finpuds uden at ændre målet

Når koden virker, kan du bruge AI til oprydning. Det er en anden opgave end redesign. Vær eksplicit om det.

En god finpudsningsprompt er ikke “gør dette bedre”. En bedre prompt er: “Ryd dette op uden at ændre adfærd, public API, layout, CSS-klasser eller content-struktur. Forklar, hvis du mener noget bør ændres, men ændr det ikke endnu.”

Prompt tilstanden, ikke kun opgaven

De fleste dårlige AI-resultater kommer af, at man beskriver opgaven, men ikke tilstanden arbejdet skal udføres i.

Til stram implementering, sig det tydeligt:

• Følg den eksisterende kode som kilde til sandhed
• Introducer ikke ny struktur, medmindre det er nødvendigt
• Ændr ikke styling
• Lav ikke brede forbedringer
• Spørg hvis kravene er uklare

Til undersøgende arbejde, sig det i stedet:

• Udfordr den nuværende tilgang
• Foreslå alternativer
• Identificer trade-offs
• Led efter skjulte risici
• Foreslå en plan før du redigerer

Den samme AI kan opføre sig meget forskelligt afhængigt af den tilstand, du sætter. Hvis du ikke definerer tilstanden, vælger modellen en for dig.

Konklusion

Der er ikke et reelt ChatGPT mod Claude for udviklere. Der er forskellige værktøjer, forskellige standardmåder at arbejde på og forskellige måder at bruge dem.

Hvis du kun bruger én AI, begrænser du dig. Du får én måde at ræsonnere på, én implementeringsvane, én review-vinkel og ét sæt fejltyper.

Det bedre workflow er at bruge AI som en værktøjskasse. Brug ét værktøj til at tænke problemet igennem. Brug et andet til at implementere kontrolleret. Brug et ekstra gennemløb til review. Og behold den endelige beslutning hos udvikleren, der forstår kodebasen, forretningsmålet og hvad der faktisk skal skibes.