Het klinkt misschien dom, maar een van de grootste productiviteits hacks bij het gebruik van Claude Code met Opus 4.1 is dit: nadat je CC hebt gevraagd om een functie te implementeren of een bug te verhelpen of wat dan ook, en nadat het zegt dat het alles heeft voltooid, zeg je gewoon herhaaldelijk het volgende tegen het totdat het geen fouten meer kan vinden (wat soms tot 7 of 8 pogingen kan duren!): "Geweldig, nu wil ik dat je zorgvuldig alle nieuwe code die je net hebt geschreven en andere bestaande code die je net hebt aangepast, opnieuw doorleest met 'verse ogen', en super zorgvuldig kijkt naar eventuele duidelijke bugs, fouten, problemen, kwesties, verwarring, enz." Ja, dit kost wel even tijd, maar daarom is het zo handig om een aantal CC-sessies tegelijk open te hebben. Dan kun je gewoon door ze heen draaien en die zin steeds opnieuw plakken. Op de een of andere manier verandert de 'verse ogen' aanpak hoe het waarneemt wat het net heeft geschreven op een echt nuttige manier. Vreemd genoeg lijkt deze truc niet zo goed te werken met GPT-5 denken - het zegt meestal gewoon "Ja, alles ziet er goed uit!" Claude is veel meer geneigd om zich te twijfelen en om slordige fouten de eerste keer te maken, maar goed in het opmerken ervan als het genoeg kansen krijgt.

Wie bij OpenAI heeft besloten om de API voor GPT-5 (en o3, het is een oud probleem) te breken door de parameter "max_tokens" te veranderen in "max_completion_tokens" in een poging om dingen duidelijker te maken... je hebt een grote fout gemaakt. Het zal nooit de ontelbare uren dekken die door ontwikkelaars zijn verspild aan kapotte code.

Na nog enkele dagen intensief gebruik van GPT-5 via Cursor en via het GPT-5 Pro-model in de webapp, sta ik achter alles wat ik heb gezegd over het feit dat het een veel slimmer model is en beter in coderen dan Opus 4.1. Ik vind Opus nog steeds leuk en vind de ergonomie van Claude Code op veel manieren prettiger, maar als je echt moeilijke dingen probeert te doen die echt slim denken vanuit eerste principes en computerwetenschappelijke vaardigheden vereisen, is GPT-5 van een volgend niveau. Maar ik vermoed dat dit alleen naar voren komt wanneer de redeneermodus is ingesteld op ten minste gemiddeld, en zich echt manifesteert met de hoge inspanningsinstelling. Een goed voorbeeldprobleem is het voorbereiden van document "redlines" van twee lange, complexe juridische documenten. Niet verschillende versies van hetzelfde document, maar twee verschillende documenten die voortkomen uit een gedeeld algemeen sjabloon. Dit is een zeer, zeer moeilijk probleem om goed op te lossen, en vereist veel slimme trucs en heuristieken om een behoorlijke prestatie en outputkwaliteit te geven (ik heb het hier over het gebruik van traditionele programmeertechnieken, niet over het gebruik van LLM's om deze vergelijking te maken). GPT-5 met de Cursor-agent kan simpelweg sneller meer, betere, slimme (maar pragmatische) ideeën bedenken en deze correct en zonder veel begeleiding implementeren, vergeleken met Opus 4.1. Het hangt echter af van waar je aan werkt. Ik denk nog steeds dat ik bijvoorbeeld de frontend-code in NextJS van Opus verkies. Maar je moet absoluut zelf controleren op je eigen werkelijke problemen en niet vertrouwen op al die mensen die zeggen dat het model slecht is en dat het bewijs is dat we tegen een muur zijn aangelopen. Of ze gebruiken de slechte gratis versie zonder na te denken, of ze hebben geen idee hoe ze effectief moeten prompten, of ze laten hun gevoelens ten opzichte van OpenAI en Altman hun mening kleuren.

Ik hou ervan hoe eenvoudig "upgrades" zijn in het tijdperk van LLM's. Boom, je hebt je applicatie in ongeveer 3 seconden veel beter gemaakt!

De gratis GPT-5 Max in Cursor voor de lanceringsweek is een ongelooflijk cadeau dat veel geld waard is. Ik heb al 6 Cursor-agenten die hard aan het werk zijn om eventuele problemen in een groot project te vinden. Tot nu toe ziet het er erg goed uit!

Zeggen dat GPT-5 veel minder liegt dan o3 betekent eigenlijk niet zoveel gezien wat een absoluut pathologisch liegend freak o3 is! Zelfs een vermindering van 80% zou nog steeds resulteren in meerdere leugens per dag bij intensief gebruik.

Grappig dat de GPT-5 demo benadrukt wat een geweldige schrijver het is... en dan pure turbo-rommel laat zien met emdashes in elke andere zin. Ze zouden zich moeten richten op de coding demo's, die veel indrukwekkender zijn! Ook haat ik het dat ze alle oude modellen afschaffen...

Terugkijkend is het moeilijk te geloven dat niemand zich de moeite heeft genomen om een multi-layer neuraal netwerk met basis stochastic gradient descent te implementeren in 1997 op de 3dfx Voodoo, een paar jaar voordat zelfs Nvidia's eerste GPU in 1999 uitkwam. De onderdelen waren in wezen allemaal aanwezig voor een kleine LLM.

Ik denk dat het hoogste compliment dat ik @patrickc en het Stripe-team kan geven is dat ze zo'n geweldige reputatie en staat van dienst hebben in het maken van echt gepolijste en intuïtieve UI/UX voor hun diensten, dat het heel handig is om ze bij naam te noemen in codeerprompts om betere resultaten van AI-codeeragenten te krijgen. Bijvoorbeeld, ik heb een variant hiervan opgeslagen in mijn teksteditor en plak het minstens 10 keer per dag in Claude Code: "Ik wil dat je een spectaculaire job doet met het bouwen van absoluut wereldklasse UI/UX-componenten voor het weergeven van deze beoordelingsrapporten, die zowel de details tonen als ook als "badges" of "samenvattingskaarten," met een intense focus op het maken van de meest visueel aantrekkelijke, gebruiksvriendelijke, intuïtieve, slick, gepolijste, "Stripe-niveau" kwaliteit UI/UX mogelijk voor dit, dat gebruik maakt van de goede bibliotheken die al deel uitmaken van het project." Dan vertel ik het dat wat het ook maakt echt niet zo geweldig is ("vreselijk" of "ongelooflijk slecht") zelfs als het al best goed is, en dat het DRAMATISCH moet verbeteren om echt op Stripe-niveau van gebruikersplezier en slickness, polish, intuïtiviteit, enz. te komen. In wezen, het toepassen van de Steve Jobs Gaslighting Techniek om iteratief "krankzinnig geweldige" resultaten te bereiken. En ja, dit werkt ongelooflijk goed als je het keer op keer blijft doen. De truc is dat je AL die bijvoeglijke naamwoorden moet opnemen, anders zal het vervallen in iconen die rond draaien en pulseren als acrobaten ("slick" en "visueel aantrekkelijk"); je hebt de andere termen zoals "gepolijst" en "intuïtief" en "Stripe-niveau" nodig om dat te temperen zodat het ook enigszins minimalistisch en prettig in gebruik is in de praktijk. Ik ben blij dat ik niet voor mezelf hoef te werken als een AI-agent :/

Ik heb zojuist het nieuwe GSPO-document van het Qwen-team gelezen. Het is grappig hoe veel van deze grote theoretische verbeteringen, ondanks dat ze een schijnbaar diep fundamentele basis hebben (in dit geval dat optimaliseren over tokenreeksen beter is dan optimaliseren over individuele tokens), uiteindelijk neerkomen op het beter laten stromen van de gradiënten door numerieke conditioneringsproblemen te vermijden. Als je een stap terugneemt en ernaar kijkt, is GSPO in wezen een manier om betere numerieke conditionering te krijgen door dingen meer samen te middelen in updates om ruisachtige bumpen te vermijden (bijna zoals het gebruik van momentum in rmsprop of Adam) en ook updates te negeren die zouden leiden tot numeriek "gevaarlijke" situaties in termen van conditionering. Maar het is allemaal logisch vanuit een historisch perspectief, aangezien deep learning echt explodeerde toen we ontdekten hoe we het probleem van verdwijnende/exploderende gradiënten konden vermijden door dingen zoals momentum in optimalisatoren te gebruiken. Dus op een bepaalde manier is dit gewoon de laatste stap in die traditie van het navigeren door het verlieslandschap op een robuustere manier om te voorkomen dat we "in een greppel rijden."