Det høres så dumt ut, men et av de største produktivitetshackene når du bruker Claude Code med Opus 4.1 er dette: etter å ha bedt CC om å implementere en funksjon eller fikse en feil eller hva som helst, og etter at den sier at den har fullført alt, sier du bare gjentatte ganger følgende til den om og om igjen til den ikke finner flere feil (som noen ganger tar opptil 7 eller 8 forsøk!): "Flott, nå vil jeg at du skal lese nøye gjennom all den nye koden du nettopp skrev og annen eksisterende kode du nettopp endret med "friske øyne", og se supernøye etter åpenbare feil, feil, problemer, problemer, forvirring osv." Ja, dette tar litt tid, men det er derfor det er så praktisk å ha en haug med CC-økter åpne samtidig. Så kan du bare rotere gjennom dem, lime inn den setningen igjen og igjen. På en eller annen måte endrer "friske øyne"-greiene hvordan den oppfatter det den nettopp skrev på en veldig nyttig måte. Merkelig nok ser ikke dette trikset ut til å fungere like bra med GPT-5-tenkning - det har en tendens til å bare si "Jepp, alt ser riktig ut!" Claude er mye mer tilbøyelig til å gjette og gjøre uforsiktige feil første gang, men flink til å fange dem hvis de får nok sjanser.

Den som hos OpenAI bestemte seg for å bryte API-en for GPT-5 (og o3, det er et gammelt problem) for å endre "max_tokens"-parameteren til "max_completion_tokens" i et forsøk på å gjøre ting klarere... du gjorde en stor feil. Det vil aldri dekke de utallige timene som utviklere kaster bort på ødelagt kode.

Etter flere dager med intens bruk av GPT-5 via Cursor og via GPT-5 Pro-modellen i nettappen, står jeg ved alt jeg sa om at det er en mye smartere modell og bedre til å kode enn Opus 4.1 Jeg liker fortsatt Opus og synes ergonomien til Claude Code er bedre på mange måter, men hvis du prøver å gjøre virkelig vanskelige ting som krever virkelig smart førsteprinsippstenkning og informatikkkoteletter, er GPT-5 neste nivå. Men jeg mistenker at dette bare dukker opp når resonneringsinnsatsmodusen er satt til minst middels, og virkelig manifesterer seg med innstillingen for høy innsats. Et godt eksempel på et problem er å utarbeide dokument-"redlines" av to lange, komplekse juridiske dokumenter. Ikke forskjellige versjoner av samme dokument, men to forskjellige dokumenter som kommer fra en delt generell mal. Dette er et veldig, veldig vanskelig problem å gjøre en god jobb med, og krever mange smarte triks og heuristikker for å gi anstendig ytelse og utskriftskvalitet (jeg snakker om å bruke tradisjonelle programmeringsteknikker her, ikke bruke LLM-er for å gjøre denne sammenligningen). GPT-5 med Cursor agent kan ganske enkelt komme opp med flere, bedre, smarte (men likevel pragmatiske) ideer raskere, og implementere disse riktig og uten mye håndhold, sammenlignet med Opus4.1. Det kommer imidlertid an på hva du jobber med. Jeg tror fortsatt jeg foretrekker frontend-kode i NextJS av Opus, for eksempel. Men du bør absolutt sjekke selv på dine egne faktiske problemer og ikke stole på alle de mange som sier at modellen suger og at det er et bevis på at vi har møtt en vegg. Enten bruker de den dårlige gratisversjonen uten å tenke, eller så har de ingen anelse om hvordan de skal spørre effektivt, eller så lar de følelsene sine overfor OpenAI og Altman farge synspunktene deres.

Jeg elsker hvor enkle "oppgraderinger" er i LLM-enes tidsalder.

Den gratis GPT-5 Max i Cursor for lanseringsuken er en utrolig gave verdt massevis av penger. Jeg har allerede 6 Curor-agenter som tøffer sammen på jakt etter problemer/problemer i et stort prosjekt. Ser veldig bra ut så langt!

Å si at GPT-5 lyver mye mindre enn o3 betyr faktisk ikke så mye gitt hvilken absolutt patologisk løgnaktig freak o3 er! Selv en reduksjon på 80 % vil fortsatt ende opp med flere løgner per dag under tung bruk.

Morsomt at GPT-5-demoen understreker hvilken flott forfatter det er... og deretter vise frem ren turbo-slop med bindestreker i annenhver setning. De bør holde seg til kodedemoene, som er mye mer imponerende! Dessuten hater jeg at de avskriver alle de gamle modellene ...

I ettertid er det vanskelig å tro at ingen gadd å implementere et flerlags nevralt nettverk med grunnleggende stokastisk gradientnedstigning tilbake i 1997 på 3dfx Voodoo, et par år før til og med Nvidias første GPU i 1999. Brikkene var i utgangspunktet alle der for en liten LLM.

Jeg tror det høyeste komplimentet jeg kan gi til @patrickc og Stripe-teamet er at de har et så godt rykte og merittliste for å lage virkelig polert og intuitivt UI/UX for tjenestene sine at det er veldig nyttig å referere dem ved navn i kodemeldinger for å få bedre resultater fra AI-kodeagenter. For eksempel har jeg en variant av dette lagret i tekstredigeringsprogrammet mitt og limer den inn i Claude Code minst 10 ganger om dagen: «Jeg vil at du skal gjøre en spektakulær jobb med å bygge UI/UX-komponenter i absolutt verdensklasse for å vise disse karakterrapportene, som viser både detaljene og også som «merker» eller «sammendragskort», med et intenst fokus på å gjøre det mest visuelt tiltalende, brukervennlige, intuitive, glatte, polerte, «stripe-nivå» av UI/UX av høy kvalitet mulig for dette som utnytter de gode bibliotekene som allerede er en del av prosjektet.» Så forteller jeg den at uansett hva den har laget egentlig ikke er så bra ("gud-forferdelig" eller "utrolig dårlig") selv om den allerede er ganske bra, og at den må DRAMATISK forbedre den for å virkelig komme til Stripe-klassenivåer av brukerglede og glatthet, polering, intuitivitet osv. I utgangspunktet, å bruke Steve Jobs Gaslighting-teknikk for å iterativt oppnå "sinnsykt gode" resultater. Og ja, dette fungerer utrolig bra hvis du fortsetter å gjøre det om og om igjen. Trikset er at du må inkludere ALLE disse adjektivene, ellers vil det utvikle seg til ikoner som snurrer rundt og pulserer som akrobater ("glatt" og "visuelt tiltalende"); du trenger de andre begrepene som "polert" og "intuitiv" og "stripe-nivå" for å dempe det, så det er også litt minimalistisk og fint å bruke i praksis. Jeg er glad jeg ikke trenger å jobbe for meg som AI-agent :/

Bare les den nye GSPO-artikkelen fra Qwen-teamet. Det er morsomt hvor mye disse store teoretiske forbedringene, til tross for at de har et tilsynelatende dypt grunnleggende grunnlag (i dette tilfellet at optimalisering på tvers av tokensekvenser er bedre enn optimalisering på tvers av individuelle tokens), til syvende og sist handler om å bare la gradientene flyte bedre ved å unngå numeriske kondisjoneringsproblemer. Når du tar et skritt tilbake og ser på det, er GSPO grunnleggende en måte å få bedre numerisk kondisjonering ved å beregne gjennomsnittet av ting mer i oppdateringer for å unngå støyende støt (nesten som å bruke momentum i rmsprop eller Adam) og også ignorere oppdateringer som vil føre til numerisk "farlige" situasjoner når det gjelder kondisjonering. Men det hele gir mening fra et historisk perspektiv, siden dyp læring virkelig eksploderte da vi fant ut hvordan vi kunne unngå problemet med forsvinnende/eksploderende gradienter ved å bruke ting som momentum i optimalisatorer. Så på en måte er dette rett og slett det siste trinnet i den tradisjonen med å navigere i tapslandskapet på en mer robust måte for å unngå å «kjøre i grøften».