Claude Opus 5.5 scrie mai puțin cod, dar densitatea bugurilor crește

Anthropic a lansat Claude Opus 5.5 la 22 septembrie 2026, potrivit anunțului oficial; tarifele sunt de 4 dolari pe milion de tokenuri de intrare și 20 de dolari pe milion de tokenuri de ieșire, iar compania estimează un cost cu 40% mai mic decât pentru Opus 5 în sarcini tipice, la setările implicite. Modelul este disponibil pe Claude Platform, precum și prin Amazon Web Services, Google Cloud și Microsoft Azure.

În evaluarea Sonar, publicată tot la 22 septembrie 2026, configurația Claude Opus 5.5 High a produs cu 27,5% mai puține linii de cod Java decât Claude Opus 5 Thinking, însă densitatea bugurilor detectate a crescut cu aproximativ 12%. Pe sarcinile cu teste executabile, rata de reușită a rămas apropiată de cea a predecesorului. Rezultatul descrie un compromis: mai puțin cod și mai puține defecte în total, dar mai multe constatări de tip bug pentru aceeași cantitate de cod.

Cum a fost măsurat codul Java

Comparația a folosit sarcini din HumanEval, MBPP și ComplexCodeEval. Rularea pentru Opus 5.5 a cuprins 4.444 de sarcini, iar rata de reușită se referă numai la cele 544 de sarcini HumanEval și MBPP pentru care existau teste executabile. Codul din ComplexCodeEval a intrat în analiza calității, dar nu în calculul acestui procent.

Pe subsetul testat funcțional, Opus 5.5 a obținut 87,68%, față de 88,6% pentru Opus 5: o diferență de 0,92 puncte procentuale. Separat, SonarQube a analizat codul produs și a semnalat tipare asociate bugurilor, vulnerabilităților și problemelor de mentenabilitate. Trecerea unui set de teste și absența constatărilor din analiza statică sunt măsuri diferite; testele executabile nu acoperă orice comportament pe care îl poate avea o soluție.

Cifrele provin dintr-o versiune Opus 5.5 testată înainte de lansarea publică. Mai contează și configurațiile comparate: High pentru noul model și Thinking pentru Opus 5. Rezultatele caracterizează aceste rulări, în limbajul Java și pe sarcinile alese, fără să stabilească rata defectelor pentru orice proiect sau configurație disponibilă utilizatorilor.

De ce scade totalul bugurilor, dar crește densitatea

Opus 5.5 a generat 664.890 de linii de cod, față de 916.813 pentru Opus 5. În acest volum mai mic au fost detectate 428 de buguri, față de 528 în codul predecesorului. Totalul a scăzut astfel cu aproximativ 19%, însă numărul de linii a scăzut mai repede. Raportate la un milion de linii, constatările cresc de la 576 la 644.

Acesta este mecanismul din spatele rezultatului aparent paradoxal. Numărul absolut arată câte constatări există în întregul cod generat pentru benchmark; densitatea permite compararea unor volume egale de cod. Pentru o revizie a întregului rezultat, mai puține linii și mai puține buguri înseamnă un volum mai mic de parcurs. Pentru o comparație a frecvenței defectelor pe unitatea de cod, noua configurație iese mai slab.

În toate categoriile reunite, constatările au coborât de la 18.814 la 10.941. Scăderea include vulnerabilități și probleme de mentenabilitate, nu doar buguri. De aceea, creșterea densității bugurilor nu trebuie extinsă la întregul profil de calitate: dintre principalele măsuri de densitate urmărite în evaluare, aceasta este cea care s-a deteriorat.

Concurența concentrează creșterea

Cea mai mare categorie de buguri detectate rămâne cea legată de concurență și fire de execuție. Densitatea acestor constatări a urcat de la 205 la 295 pe milion de linii, o creștere de 44%. În schimb, încălcările contractelor API au coborât de la 57 la 29 pe milion de linii, iar constatările privind fluxul de control au scăzut și ele. Evoluția diferită a categoriilor explică de ce o singură medie ascunde schimbări importante.

Constatările de concurență acoperă, între altele, inițializarea nesigură, blocări care nu sunt eliberate pe toate căile de execuție și incrementarea neatomică a unei valori partajate. Într-un program Java, efectul unui asemenea tipar poate depinde de ordinea în care rulează firele de execuție. Un test care parcurge o singură ordine posibilă poate trece, în timp ce problema apare intermitent când codul este executat în alte condiții.

Și severitatea schimbă lectura rezultatului. Densitatea bugurilor din categoria cea mai gravă, BLOCKER, a scăzut de la 41 la 24 pe milion de linii, deși densitatea agregată a crescut. O mare parte din creștere se află în categoria LOW. Noul model a concentrat, așadar, mai multe constatări pe unitatea de cod, dar evaluarea nu arată o creștere uniformă la toate nivelurile de gravitate.

Vulnerabilități mai rare, comentarii mai puține

Profilul de securitate s-a îmbunătățit pe măsurile generale: au fost detectate 152 de vulnerabilități în codul Opus 5.5, față de 230 pentru Opus 5, iar densitatea lor a scăzut de la 251 la 229 pe milion de linii. Constatările BLOCKER de securitate s-au redus și ele. Există însă categorii cu altă direcție: densitatea constatărilor privind atacurile de injecție a crescut, în timp ce configurațiile criptografice problematice au rămas aproape la același nivel.

Codul mai scurt oferă și mai puține explicații locale. Ponderea liniilor de comentariu a coborât de la 10,5% la 3,1%, o schimbare mai abruptă decât reducerea volumului total de cod. Pentru cine modifică ulterior o soluție, acest lucru înseamnă mai puțin context despre intenția implementării; comentariile rămân totuși o caracteristică distinctă de corectitudinea verificată prin teste.

Complexitatea ciclomată pe mia de linii a rămas aproape neschimbată, în timp ce complexitatea cognitivă pe aceeași unitate a crescut ușor. Codul rezultat este deci mai mic, fără ca fiecare porțiune de dimensiune egală să devină automat mai simplă de urmărit. Această diferență contează mai ales acolo unde logica include ramificații și stare partajată.

Ce arată testul despre cost

Prețul pe token și consumul de tokenuri sunt componente diferite ale facturii. În benchmark, cele două rulări au folosit aproximativ același volum de tokenuri de intrare, dar tokenurile de ieșire au scăzut de la 21,71 milioane la 12,96 milioane. Aceasta este o reducere de aproximativ 40% a ieșirii măsurate în test, nu o măsurare directă a costului fiecărui proiect care folosește modelul.

Estimarea de cost comunicată la lansare depinde de setările implicite și de ceea ce furnizorul numește sarcini tipice. Factura unei utilizări concrete depinde și de lungimea intrării, de răspuns și de folosirea memoriei cache. În plus, comparația din benchmark nu permite adunarea sigură a tuturor tokenurilor: pentru rularea Opus 5 nu au fost înregistrate separat tokenurile de raționament, în timp ce pentru Opus 5.5 acest câmp este prezent.

Rămâne de măsurat dacă profilul bugurilor, în special concentrarea lor în codul concurent, se păstrează într-o rulare comparabilă pe versiunea publică. Până atunci, cifrele despre calitatea codului descriu configurația testată înainte de lansare, în vreme ce tarifele și disponibilitatea privesc produsul lansat.

Citește și:

• Claude Code sau Codex: studiul nu găsește un câștigător absolut
• Românii adoptă IA, dar 52% confundă textul generat cu cel uman
• Munca autonomă prin IA s-ar putea dubla, dar valoarea rămâne în urmă