Heb je je wel eens afgevraagd welk model vandaag écht het verschil maakt in je codebase? In deze hands-on review van de nieuwste releases zet ik GPT-5 naast Claude 4 Sonnet, met focus op real-world coding, agentic workflows en developer experience. Geen hype, maar praktische inzichten die we bij Spartner meteen toepassen.
Snelheid is niets zonder grip
Wat kies je nu?
De kern: benchmark kracht versus teamproductiviteit
Basisprestatie GPT-5 zet de toon met 74,9% op SWE-bench Verified; Claude 4 Sonnet noteert 72,7% (beiden zonder extra test-time compute). In de praktijk voelt het verschil klein, maar merkbaar op complexe bugfixes met veel afhankelijkheden.
Extended thinking Sonnet 4 loopt uit naar 80,2% met parallel test-time compute; GPT-5 claimt SOTA op real-world coding en scoort 94,6% op AIME 2025 zonder tools. Korte versie: Sonnet maximaliseert met compute, GPT-5 is sterk in first-pass redenering.
Agentic tooling Claude 4 brengt extended thinking met tool use en parallel tool calls; Claude Code integreert strak met VS Code en JetBrains. GPT-5 schuift door naar een uniform agents- en toolsmodel in ChatGPT en de API. Beide zijn klaar voor langere, multi-step taken.
Developer ervaring Uit onze ervaring blijkt: Sonnet 4 is conservatiever met edits (scherpere, "surgical" patches), GPT-5 onderneemt grotere refactors met meer context. Wat jij wil? Hangt af van je risicoprofiel, testdekking en CI-snelheid.
Mijn eerste week met beide modellen
Wat mij opvalt in de praktijk
Laatst kwam ik iets interessants tegen: hetzelfde issue, twee stijlen. GPT-5 ging voor de strategische fix inclusief herstructurering van een helper; Sonnet 4 hield het minimalistisch en raakte minder bestanden. Beide slaagden, maar de reviewervaring verschilde compleet. Het interessante is dat de keuze niet alleen over "beste benchmark" gaat, maar over teamflow, tooling en je patch-acceptatiecriteria.
Belangrijkste punten:
GPT-5 leidt op real-world coding benchmarks en excelleert in wiskundige redenering; sterk voor architectuurkeuzes en "bigger-picture" fixes.
Claude 4 Sonnet scoort dicht in de buurt op first-pass en kan met extended compute bovenaan eindigen; de IDE-integratie en patch-precisie zijn sterk.
Agentic workflows worden volwassen: parallel tool use, memory, en langere trajecten. Dit verandert hoe we code laten "leven".
Voor Laravel/monorepo's is patch-precisie goud waard; voor greenfield of grootschalige refactors is GPT-5's agressievere stijl soms efficiënter.
Actionable insights:
Zet een SWE-bench-achtige harness op voor je eigen codebase.
Meet pass@1 op jullie regressietests i.p.v. te vertrouwen op publieke benchmarks.
Start met Sonnet 4 in strikter CI, GPT-5 in exploratieve branches.
Reserveer extended compute voor lastige issues; zet caps in om kosten en runtime te bewaken. 🙂
Breng je codewerk in kaart
Onze aanpak hierbij: label issues naar "surgical fix" (één bestand, één bug), "guided refactor" (meerdere modules), en "exploratory design" (architectuur).
Tip: koppel labels aan modelkeuze. Sonnet 4 voor surgical, GPT-5 voor guided/exploratory.
Bouw een lokale SWE-harness
Wat wij doen is: elk voorstel is een patch die we in een schone checkout toepassen, vervolgens runnen we `composer test` of `phpunit` (Laravel) én E2E waar relevant.
Valkuil: laat het model geen testbestanden herschrijven. Zet read-only voor `tests/` of valideer diffs.
Tune prompts per taaktype
Pro-tip: voor Sonnet 4, vraag om "minimale diff, geen hernoemingen, motiveer per edit"; voor GPT-5, vraag om "tactisch plan, controleer side-effects in modules X/Y".
Let hier vooral op: voeg repo-specifieke constraints toe (coding standards, domain-invariants, migratiebeleid).
Activeer tools bewust
Gebruik parallel tool calls alleen waar het echt winst oplevert (dependency analyse, migraties, performance-profiling).
Handige truc: geef het model een "readme-context" file met projectregels en "do-not-touch" zones.
Review en leer
Log álle patches, testresultaten en revert-redenen. Maak een kleine "memory file" met patronen die in jullie codebase vaak fout gaan.
Zet wekelijks een model-agnostische retro op. Wat leverde minder regressies op? Waar was extended thinking noodzakelijk?
Benieuwd hoe dit in jouw stack uitpakt? Deel je context (framework, repo-omvang, testdekking) en laten we sparren over een slimme setup. Wil je een lightning-eval met jullie CI? Stuur me een berichtje—altijd leuk om mee te denken. 🚀
Wat zeggen de nieuwste releases echt?
Van benchmark naar dagelijkse praktijk
De korte samenvatting van de aankondigingen
OpenAI introduceerde GPT-5 als nieuw vlaggenschip met SOTA op real-world coding: 74,9% op SWE-bench Verified, plus 94,6% op AIME 2025 zonder tools. De boodschap: sterk in redenering, sterk in coding, en klaar voor agentic taken.
Anthropic lanceerde Claude 4 met Sonnet 4 en Opus 4; Sonnet 4 klokt 72,7% op SWE-bench Verified (pass@1), en kan met parallel test-time compute 80,2% aantikken. Daarnaast: extended thinking met tool use, parallel tool calls, en Claude Code-plugins voor VS Code en JetBrains.
Nog vers: Opus 4.1 tilt SWE-bench Verified naar 74,5%—relevant als je de "absolute top" zoekt, maar de vraag blijft: hoe vaak heb je die extra 1-2% nodig in je eigen CI?
Wat mij opvalt: benchmarks convergeren. Het speelveld gaat minder over wie "een puntje hoger" scoort, en meer over:
Hoe precies zijn de edits? Minder collateral damage wint in grote PHP/Laravel monorepo's.
Hoe goed blijft het model on track in multi-turn, tool-augmented workflows?
Hoe fijn is de integratie met je bestaande IDE, testharnas en deployment pipeline?
Sonnet 4 in een notendop
Sterk in surgical edits: "doe één ding, en doe het goed".
Extended thinking + tool use voelt volwassen: parallelle calls besparen mens-orkestratie.
IDE-integratie verlaagt frictie: diff review binnen je editor, minder context-switching.
GPT-5 in een notendop
Ambitieuze refactors met planmatige onderbouwing: prettig op legacy stukken waar eerst structuur nodig is.
Robuuste redenering geeft betere "waarom"-uitleg bij keuzes—handig voor code review en kennisoverdracht.
Agentic richting uniform: één denksysteem dat tools en geheugen combineert. Minder "welke modus gebruik ik?"-vragen.
Eerlijke noot: zonder goede testdekking schiet je met beide modellen sneller in je eigen voet. Benchmarks meten "oplossing", niet "impact op jouw refactor debt".
Zo testen wij dit in een Laravel context
Klein harnas, grote zekerheid
Waarom een eigen harness?
Publieke scores zijn nuttig, maar jouw codebase is uniek: eigen helper-functies, domain rules, migratiebeleid. Daarom meten we pass@1 op jullie regressietests en E2E. Geen magie—gewoon discipline.
Minimal patch runner (schets)
import subprocess, json, pathlib, difflib
def apply_patch(repo_path, patch):
for file, new_content in patch["files"].items():
p = pathlib.Path(repo_path, file)
old = p.read_text(encoding="utf-8")
if "tests/" in file:
raise RuntimeError("Tests zijn read-only in deze flow")
p.write_text(new_content, encoding="utf-8")
print("Diff:", "\n".join(difflib.unified_diff(old.splitlines(), new_content.splitlines(), lineterm="")))
def run_tests(repo_path):
r = subprocess.run(["composer", "test"], cwd=repo_path, capture_output=True, text=True)
print(r.stdout)
return r.returncode == 0
def evaluate(model, issue):
patch = model.propose_patch(issue) # je eigen wrapper voor GPT-5 of Sonnet 4
apply_patch("/work/repo", patch)
return run_tests("/work/repo")
Pro-tip:
Gebruik "dry-run patches" om eerst alleen diffs te zien.
Laat het model een "impact assessment" schrijven: welke modules geraakt, waarom deze keuze, risico's.
Bewaak patchgrootte: boven bepaalde diff-size altijd handmatige review.
Prompting die werkt
Sonnet 4: "pas zo min mogelijk aan", "vermijd hernoemingen", "geen stilzwijgende designwijzigingen".
GPT-5: "maak een microplan", "maak expliciet welke invariants je bewaakt", "check gebruik van helper X in module Y".
Business-impact: waar win je tijd en kwaliteit?
Van BPR naar developer happiness
Waar zit de ROI in de praktijk?
Minder regressies door conservatieve patches (Sonnet 4) in gevoelige legacy-delen.
Snellere productverbetering door grotere, goed onderbouwde refactors (GPT-5) op strategische plekken.
Agentic workflows die epics in dagen afhandelen i.p.v. weken—mits je orkestratie en observability op orde zijn.
Governance en veiligheid
Zet sandboxed code execution in voor experiments; laat secrets nooit in prompt of tool-logs lekken.
Bewaak "do-not-touch"-zones vanuit architectuurregels (bijv. domeinlaag, security-middleware).
Log denktraces beknopt (samenvattingen volstaan vaak) en archiveer diffs en testuitvoer voor auditability.
Teamdynamiek
Junior developers winnen met Claude Code's directe IDE-feedback; seniors benutten GPT-5 voor ontwerpdiscussies en grotere herstructureringen.
Maak pairing tussen mens en model expliciet: wie leidt? Wanneer schakelen we over?
Meet developer happiness. Minder context-switching en minder diff-ruis blijkt een onderschatte factor in productiviteit. 🙂
Is GPT-5 "beter" dan Claude 4 Sonnet voor coding?
Korte versie: het hangt af van je use case. GPT-5 heeft de hogere SOTA-score op real-world coding (74,9% SWE-bench Verified) en blinkt uit in redenering. Sonnet 4 zit daar vlak achter, en kan met parallel compute hoger eindigen (80,2%). Uit onze ervaring: Sonnet is preciezer in kleine, veilige edits; GPT-5 pakt makkelijker grotere refactors.
Hoe verhouden extended thinking en parallel test-time compute zich tot kosten en tijd?
Lang antwoord: extended thinking + parallel sampling verbetert scores, maar verhoogt runtime en compute. Wij gebruiken het selectief: alleen voor tickets met hoge onzekerheid of grote impact. Stel caps in, log varianten, en herhaal niet onnodig als de eerste patch al groen is.
Wat merken jullie in Laravel-projecten?
Uit onze ervaring: Sonnet 4 reduceert "onbedoelde bijwerkingen" bij service- en helper-lagen, omdat het minder geneigd is tot hernoemen of brede refactors. GPT-5 is sterk als je eerst orde wil scheppen—denk aan duplicaatlogica verwijderen en boundaries scherper trekken. Beide winnen significant met goede testdekking.
Welke setup raden jullie aan voor een monorepo met gemengde stacks?
Start met een model-router: Sonnet 4 voor surgical tickets en hotfixes, GPT-5 voor design- of refactorstories. Geef elke patch een identieke harness-run. Laat alleen het best scorende voorstel door naar review. Houd "cross-stack" context klaar (architectuurregels in een "context.md").
Is Opus 4.1 relevanter dan Sonnet 4?
Opus 4.1 levert een kleine boost op SWE-bench Verified (74,5%). Als je écht op de grens speelt of zware agentic trajecten draait, kan dat tellen. Voor veel teams is Sonnet 4's balans tussen snelheid, precisie en IDE-integratie erg aantrekkelijk. Wij testen Opus 4.1 gericht op langlopende taken.
Hoe ga ik veilig om met tools en memory?
Gebruik sandboxed execution, mask secrets, en definieer expliciet wat het model mag lezen/schrijven. Bewaar "memory files" in een gecontroleerde map; maak duidelijk onderscheid tussen tijdelijke notities en persistente kennis. Logging: samenvattingen i.p.v. volledige thought dumps helpen performance en privacy. 🔐
Welke prompts werken het best voor minder regressies?
Vraag om: "minimale diff", "geen testbestanden wijzigen", "impact assessment per wijziging", en "rollback-plan indien X faalt". Voeg code style en domain-invariants toe. Bij GPT-5 helpt een kort plan vooraf; bij Sonnet 4 helpt strakke edit-instructie.
Hoe begin ik zonder alles te verbouwen?
Zet een kleine "eval lane" op in je CI. Test 10-20 representatieve issues, meet pass@1 en reviewtijd. Kies per type issue een voorkeursmodel. Schaal langzaam op, documenteer learnings, en borg governance. Kleine stappen, grote winst. 🚀
