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. Uansett, det er utrolig morsomt å leke med denne tingen. Det er morsommere og mer engasjerende for meg enn noe videospill noen gang kan være.

Bare les gjennom den nye LeJEPA-artikkelen av Yann LeCun og Randall Balestriero. Jeg har vært nysgjerrig på å vite hva Yann har jobbet med i det siste, spesielt med tanke på all hans kritikk av LLM-er (som jeg er uenig i, da jeg tror LLM-er vil fortsette å forbedre seg og vil ta oss til ASI ganske snart). Uansett, det er allerede flere tråder på X om artikkelen og hva den introduserer. Kortversjonen er at det er en prinsipiell, teoretisk begrunnet og sparsommelig tilnærming til selvovervåket læring som erstatter et komplekst sammensurium av ad-hoc, hacky heuristikk for å forhindre moduskollaps, som er banen for selvovervåket læring. Det er der modellen skrur seg opp og begynner å kartlegge alle innganger til nesten identiske innebygginger eller til et smalt underrom av innebygginger, og kollapser all rikdommen i problemet til en patologisk enkel og feil korrespondanse. Den første pilaren i den nye tilnærmingen er deres bevis på at isotrope Gaussiske fordelinger unikt minimerer verste fall nedstrøms prediksjonsrisiko. Så snart jeg leste det, tenkte jeg umiddelbart på CMA-ES, den beste tilgjengelige black-box-optimaliseringsalgoritmen for når du ikke har tilgang til gradienten til funksjonen du prøver å minimere, men bare kan gjøre (dyre/trege) funksjonsevalueringer. Nikolaus Hansen har jobbet med CMA-ES siden han introduserte det helt tilbake i 1996. Jeg har alltid vært fascinert av denne tilnærmingen og brukte den med stor suksess til å effektivt utforske hyperparametere til dype nevrale nett tilbake i 2011 i stedet for å gjøre ineffektive rutenettsøk. Uansett, grunnen til at jeg tar det opp er fordi det er en slående parallell og dyp forbindelse mellom den tilnærmingen og kjernen i LeJEPA. CMA-ES sier: Start med en isotrop Gaussisk fordi det er den maksimale entropifordelingen (minst partisk) gitt bare variansbegrensninger. Tilpass deretter kovariansen for å lære problemets geometri. LeJEPA sier: Oppretthold en isotrop Gaussisk fordi det er den maksimale entropifordelingen (minst partisk) for ukjente fremtidige oppgaver. Begge erkjenner at isotropi er optimal under usikkerhet av tre grunner: Prinsippet om maksimal entropi; Blant alle fordelinger med fast varians har den isotrope Gaussiske maksimal entropi; Det vil si at den gjør færrest antakelser. Det er ingen retningsbestemt skjevhet; Lik varians i alle retninger betyr at du ikke forplikter deg til en bestemt problemstruktur på forhånd. Du får verste fall optimalitet; Minimer maksimal anger på tvers av alle mulige problemgeometrier. Så hva er forskjellen? Det kommer ned til tilpasningstidspunkt. CMA-ES kan tilpasse seg under optimalisering; Den starter isotropisk, men blir deretter anisotrop når den lærer det spesifikke optimaliseringslandskapet. Derimot må LeJEPA forbli isotropisk fordi den forbereder seg på ukjente nedstrømsoppgaver som ikke er sett ennå. Denne parallellen antyder at LeJEPA bruker et grunnleggende prinsipp fra optimaliseringsteori til representasjonslæring. Det sier i hovedsak: "Den optimale søkedistribusjonen for black-box-optimalisering er også den optimale innebyggingsdistribusjonen for overføringslæring." Dette er fornuftig fordi begge problemene involverer å navigere i ukjente landskap; for CMA-ES er dette det ukjente optimaliseringslandskapet; for LeJEPA er dette det ukjente rommet for nedstrømsoppgaver. Denne forskjellen får meg til å lure på: kan vi ha "adaptiv LeJEPA" som starter isotropisk, men tilpasser sin innebyggingsfordeling når vi kjenner nedstrømsoppgaven, på samme måte som CMA-ES tilpasser seg under optimalisering? Det ville være som å metalære riktig anisotropi for spesifikke oppgavefamilier. Uansett, jeg tenkte jeg skulle dele mine tanker om dette. Det er fascinerende å se sammenhengene mellom disse ulike områdene. Black-box-optimaliseringssamfunnet har alltid vært ganske atskilt og forskjellig fra dyplæringssamfunnet, og det er ikke mye krysspollinering der. Dette er fornuftig, for hvis du har en gradient, ville du være gal å ikke bruke den. Men det er sterke sammenhenger.

Du kan komme omtrent 95 % av veien til en veldig fin, glatt, fungerende iOS-app skrevet naturlig i Swift ved hjelp av codex og GPT-5. Men så kommer du til det punktet hvor du vil legge det på AppStore, så du må få sertifikater satt opp for signering og alle disse andre tingene. På det tidspunktet slutter du å kunne gjøre alt fra kommandolinjen programmatisk, og må begynne å rote med GUI i Xcode, og det er bare et absolutt mareritt. Bare håpløst dårlige UI-mønstre, og du må gjette hvor alt er. Selv når AI forteller deg hva du skal gjøre trinn for trinn, er det en enorm kognitiv byrde å til og med finne tingene i det forvirrende og forferdelige grensesnittet. Apple bør virkelig sette arbeidet med alle andre utviklerverktøy på pause til de har en helt komplett, godt dokumentert (i en enkelt markdown-fil!) CLI og API som kan brukes ende-til-ende av AI-kodeagenter for alt som er involvert i å opprette og publisere en app.