Ik denk dat ik te afwijzend was tegenover Cursor's nieuwe Composer-1 coding LLM. Natuurlijk is het strikt slechter dan GPT-5 High Effort en GPT-5-Codex, en in die zin zie ik er geen plaats voor in mijn workflows wanneer ik belangrijke codeprojecten architecteer en implementeer. Aan de andere kant is het extreem snel (ik vraag me af hoe ze dit hebben gedaan; gebruiken ze Groq of Cerebras-hardware? Is het omdat het model zo klein en efficiënt is? Niet zeker), en dit alleen al ontgrendelt veel nieuwe workflows en werktechnieken voor wanneer de code niet zo cruciaal is, of wanneer je een nieuw project begint en je je geen zorgen hoeft te maken over het breken van bestaande code. Het is ook veel, veel goedkoper in vergelijking met welke variant van GPT-5 dan ook. De combinatie van veel sneller en veel goedkoper creëert een kwalitatief verschil in hoe je het model kunt gebruiken dat ik eerder niet volledig waardeerde. Wanneer de kosten van iteratie zo laag zijn, zowel in termen van tijd als geld, kun je veel vaker itereren. Dat verlaagt de waarde van "one-shot correctness"; dat wil zeggen, het vermogen van een model zoals GPT-5 Pro om zelfs een complexe codeopdracht de eerste keer goed te krijgen zonder bugs (hoewel zelfs dat model vaak faalt op deze zeer strenge test). Maar als je de debugcyclus kunt sluiten en snel de fouten/warnings terug in het model kunt voeren, en elke iteratieronde 20 seconden tot een minuut duurt (in plaats van minstens 5 tot 10 keer zo lang met GPT-5 met hoge inspanning), dan kun je snel alle slordige fouten oplossen die het de eerste keer maakt (of zelfs de tweede, derde of vierde keer) en toch eerder eindigen met werkende code dan je zou kunnen met GPT-5. Als je iets in de browser ontwikkelt, kun je nu echt de cyclus helemaal sluiten met Cursor's nieuwe Browser Tab, wat veruit de beste implementatie van dit soort dingen is die ik in een coding tool heb gezien (het is mijlenver vooruit op het gebruik van Playwright MCP van Codex of Claude Code!). Ik heb deze prompt vandaag met groot effect gebruikt: "Gebruik de browsertab om deze app systematisch te verkennen en gebruik de interface op een natuurlijke manier; terwijl dat gebeurt, let op ALLE waarschuwingen of fouten in de dev-console. Wanneer je er een ziet, begin dan interactief en iteratief de bugs en problemen te diagnosticeren en op te lossen en vernieuw de app en verifieer dat de fout of waarschuwing volledig is opgelost. Bij het oplossen van dingen, concentreer je op het bepalen van de ware onderliggende oorzaak van de bug en niet op het toepassen van nep 'pleister'-oplossingen!" Waar deze aanpak echt faalt, is in de conceptuele en planningsfasen waarin je uitzoekt wat je moet maken en de beste manier om het op hoog niveau te implementeren. Daar kan het gebrek aan diepgaand denken en verkenning je op een slecht pad zetten dat moeilijk te herstellen is. Dit is veel duidelijker wanneer de taak waaraan je werkt ver afwijkt van de "data manifold" van veelvoorkomende codingtaken. Als je weer een eenvoudige CRUD-website maakt, zul je het waarschijnlijk niet veel opmerken. Als je probeert nieuw terrein te betreden in een kunstmatige levenssimulatie of iets vreemds zoals dat, zul je het veel opmerken. Maar er is een mooie hybride aanpak die echt goed werkt: het combineren van het slimste model voor planning met deze snelle en goedkope modellen voor het genereren van iteraties. Dus, gebruik GPT-5 Pro in de browserapp om je plan en een initiële implementatie te bedenken, plak dat vervolgens in Cursor en begin met itereren en verbeteren. Het is veel beter in het aanpassen van een bestaande sterke basis dan in het leggen van die basis zelf. Waar dit alles echt opvalt, is wanneer je speelt en verkent met iets leuks, in een nieuw project waar geen deadlines of verwachtingen zijn. In deze context is de snelheid een echte game-changer. Het doet me denken aan dat oude onderzoek dat IBM in de vroege jaren '80 deed, dat keek naar latentie met computersystemen, wat ontdekte dat wanneer de latentie onder een bepaalde magische grens komt, zoals 50 ms, je deze grote verandering in gedrag krijgt omdat de menselijke hersenen waarnemen dat ze met een "live systeem" te maken hebben. En, omgekeerd, wanneer de latentie boven zelfs een verrassend bescheiden niveau gaat, zoals 500 ms, krijg je veel minder betrokkenheid, en het is mentaal belastend en frustrerend. Wanneer de latentie stijgt tot enkele seconden of meer, hebben mensen de neiging om mentaal af te haken en wordt het een strijd om betrokken te blijven. Het zien van het codingmodel dat binnen enkele seconden reageert en een stortvloed van 10 bewerkingen in minder dan 15 seconden maakt, is gewoon een totaal andere ervaring dan 5 minuten wachten op GPT-5 met hoge inspanning om methodisch iets door te nemen. ...