Jeg tror jeg var for avvisende til Cursors nye Composer-1-koding LLM. Jada, det er strengt tatt verre enn GPT-5 High Effort og GPT-5-Codex, så i den forstand, når jeg arkitekter og implementerer viktige kodeprosjekter, ser jeg egentlig ikke en plass for det i arbeidsflytene mine. På den annen side er det ekstremt raskt (lurer på hvordan de gjorde dette; bruker de Groq- eller Cerebras-maskinvare? er det fordi modellen er så liten og effektiv? ikke sikker), og dette alene låser opp mange nye arbeidsflyter og arbeidsteknikker for når koden ikke er så virksomhetskritisk, eller når du starter et nytt prosjekt og du ikke trenger å bekymre deg for å knekke eksisterende kode. Det er også mye, mye billigere sammenlignet med noen smak av GPT-5. Kombinasjonen av mye raskere og mye billigere skaper en kvalitativ forskjell i hvordan du kan bruke modellen som jeg ikke helt satte pris på før. Når kostnadene for iterasjon er så lave både når det gjelder tid og penger, kan du iterere mye flere ganger. Det senker verdien av "one-shot korrekthet"; det vil si evnen til en modell som GPT-5 Pro til å få til og med en kompleks kodeoppgave riktig aller første gang uten feil (selv om selv den modellen ofte mislykkes på denne svært strenge testen). Men hvis du kan lukke feilsøkingssløyfen og raskt mate feilene/advarslene tilbake til modellen, og hver iterasjonsrunde tar 20 sekunder til et minutt (i stedet for 5 til 10 ganger så lang tid i det minste ved å bruke GPT-5 med høy innsats), så kan du raskt løse alle de slurvete feilene den gjør første gang (eller til og med den andre, tredje eller fjerde gang) og fortsatt fullføre med fungerende kode raskere enn du kunne med GPT-5. Hvis du utvikler noe i nettleseren, kan du nå virkelig lukke sløyfen hele veien ved å bruke Cursors nye nettleserfane, som er den desidert beste implementeringen av denne typen ting jeg har sett i noe kodeverktøy (det er milevis foran å bruke Playwright MCP fra Codex eller Claude Code!). Jeg har brukt denne ledeteksten med stor effekt i dag: "Bruk nettleserfanen til å systematisk utforske denne appen og bruke grensesnittet på en naturlig måte; mens det skjer, se etter EVENTUELLE advarsler eller feil i utviklerkonsollen. Når du ser en, start interaktivt og iterativt med å diagnostisere og fikse feilene og problemene, og oppdater deretter appen og kontroller at feilen eller advarselen er fullstendig løst. Når du fikser ting, fokuser på å finne den sanne underliggende årsaken til feilen og ikke bruke falske "plaster"-rettelser!" Der denne tilnærmingen virkelig bryter sammen, er imidlertid i konsept- og planleggingsfasene der du finner ut hva du skal lage og den beste måten å implementere den på et høyt nivå. Der kan mangelen på dyp tenkning og utforskning starte deg på en dårlig vei som er vanskelig å komme seg fra. Dette er mye tydeligere når oppgaven du jobber med avviker langt fra "datamangfoldet" av vanlige kodeoppgaver. Hvis du lager enda et enkelt CRUD-nettsted, vil du sannsynligvis ikke legge merke til det mye. Hvis du prøver å tråkke ny i en kunstig livssimulering eller noe rart sånt, vil du legge merke til det mye. Men det er en fin hybrid tilnærming som fungerer veldig bra: å kombinere den smarteste modellen for planlegging med disse raske og billige modellene for å sveive ut iterasjoner. Så bruk GPT-5 Pro i nettleserappen for å komme opp med planen din og en innledende implementering, lim den deretter inn i markøren og begynn å iterere og fikse og forbedre. Det er mye bedre til å modifisere et eksisterende sterkt fundament enn det er til å legge ut selve fundamentet. Der alt dette virkelig skinner er når du leker og utforsker med noe morsomt, i et nytt prosjekt der det ikke er tidsfrister eller forventninger. I denne sammenhengen er hastigheten en virkelig game-changer. Det minner meg om den gamle forskningen utført av IBM på begynnelsen av 80-tallet som så på latens med datasystemer, som fant at når latensen kommer under et magisk nivå, som 50 ms, får du denne store endringen i atferd fordi den menneskelige hjernen oppfatter at den har å gjøre med et "levende system". Og omvendt, når latensen går over selv et overraskende beskjedent nivå, som 500 ms, får du mye mindre engasjement, og det er mentalt belastende og frustrerende. Når ventetiden øker til noen sekunder eller mer, har folk en tendens til å sjekke ut mentalt, og det blir en kamp å holde seg engasjert. Å se kodemodellen svare i løpet av sekunder og gjøre en mengde 10 redigeringer på under 15 sekunder er bare en helt annen opplevelse enn å vente 5 minutter på GPT-5 høy innsats for å metodisk sveive gjennom noe. ...