Cred că am fost prea disprețuitor față de noul cod Composer-1 al lui Cursor LLM. Sigur, este strict mai rău decât GPT-5 High Effort și GPT-5-Codex, așa că, în acest sens, atunci când proiectez și implementez proiecte importante de cod, nu prea văd un loc pentru asta în fluxurile mele de lucru. Pe de altă parte, este extrem de rapid (mă întreb cum au făcut asta; folosesc hardware Groq sau Cerebras? este pentru că modelul este atât de mic și eficient? nu sunt sigur), iar acest lucru deblochează o mulțime de fluxuri de lucru noi și tehnici de lucru pentru atunci când codul nu este atât de critic sau când începi un nou proiect și nu trebuie să-ți faci griji cu privire la spargerea codului existent. De asemenea, este mult, mult mai ieftin în comparație cu orice aromă de GPT-5. Combinația dintre mult mai rapid și mult mai ieftin creează o diferență calitativă în modul în care puteți folosi modelul pe care nu am apreciat-o pe deplin înainte. Când costul iterației este atât de scăzut atât în ceea ce privește timpul, cât și banii, puteți itera de mult mai multe ori. Asta scade valoarea "corectitudinii one-shot"; adică capacitatea unui model precum GPT-5 Pro de a obține chiar și o atribuire complexă de codare corectă de prima dată, fără erori (deși chiar și acel model eșuează adesea la acest test foarte strict). Dar dacă puteți închide bucla de depanare și puteți introduce rapid erorile/avertismentele înapoi în model și fiecare rundă de iterație durează între 20 de secunde și un minut (în loc de 5 până la 10 ori mai mult folosind GPT-5 cu efort mare), atunci puteți rezolva rapid toate greșelile neglijente pe care le face prima dată (sau chiar a doua, a treia sau a patra oară) și totuși terminați cu codul de lucru mai devreme decât ați putea cu GPT-5. Dacă dezvoltați ceva în browser, acum puteți închide bucla până la capăt folosind noua filă de browser a Cursor, care este de departe cea mai bună implementare a acestui gen de lucruri pe care am văzut-o în orice instrument de codare (este cu mult înaintea utilizării Playwright MCP de la Codex sau Claude Code!). Am folosit acest mesaj cu mare efect astăzi: "Utilizați fila browserului pentru a explora sistematic această aplicație și utilizați interfața într-un mod natural; în timp ce se întâmplă asta, fiți atenți la ORICE avertismente sau erori în consola de dezvoltare. Când vedeți unul, începeți să diagnosticați și să remediați erorile și problemele în mod interactiv și iterativ, apoi reîmprospătați aplicația și verificați dacă eroarea sau avertismentul este complet rezolvat. Când remediați lucrurile, concentrați-vă pe determinarea adevăratei cauze principale a erorii și nu pe aplicarea unor remedieri false de "pansament"!" Totuși, această abordare se descompune cu adevărat este în fazele conceptuale și de planificare, în care îți dai seama ce să faci și cel mai bun mod de a o implementa la un nivel înalt. Acolo, lipsa de gândire profundă și explorare te poate porni pe o cale proastă din care este greu să te recuperezi. Acest lucru este mult mai evident atunci când sarcina la care lucrați se îndepărtează de "varietatea de date" a sarcinilor obișnuite de codare. Dacă creați încă un site CRUD simplu, atunci probabil că nu îl veți observa prea mult. Dacă încercați să pășiți pe un teren nou într-o simulare de viață artificială sau ceva ciudat de genul acesta, veți observa foarte mult. Dar există o abordare hibridă frumoasă care funcționează foarte bine: combinarea celui mai inteligent model de planificare cu aceste modele rapide și ieftine pentru a lansa iterații. Deci, utilizați GPT-5 Pro în aplicația de browser pentru a veni cu planul și o implementare inițială, apoi lipiți-l în Cursor și începeți să iterați, să reparați și să îmbunătățiți. Este mult mai bun la modificarea unei fundații puternice existente decât la stabilirea acelei fundații în sine. Unde toate acestea strălucesc cu adevărat este atunci când te joci și explorezi cu ceva distractiv, într-un proiect nou în care nu există termene limită sau așteptări. În acest context, viteza schimbă cu adevărat jocul. Îmi amintește de acea cercetare veche făcută de IBM la începutul anilor '80 care a analizat latența cu sistemele de calculatoare, care a descoperit că atunci când latența scade sub un anumit nivel magic, cum ar fi 50 ms, ai o mare schimbare de comportament pentru că creierul uman percepe că are de-a face cu un "sistem live". Și, invers, atunci când latența depășește chiar și un nivel surprinzător de modest, cum ar fi 500 ms, obții mult mai puțină implicare și este obositor și frustrant din punct de vedere mental. Când latența crește la câteva secunde sau mai mult, oamenii tind să verifice mental și devine o luptă să rămână implicați. Să vezi modelul de codare răspunzând în câteva secunde și făcând o rafală de 10 editări în mai puțin de 15 secunde este doar o experiență complet diferită decât așteptarea a 5 minute pentru ca GPT-5 să treacă metodic prin ceva. ...