Opus 4.8 și Sonnet 5 par să facă ceva ce versiunile mai vechi nu făceau: inventează câmpuri suplimentare într-un tool call și strică un schema custom perfect valid pentru editare. Asta contează pentru că modele mai bune nu sunt automat mai bune la tool-urile tale. Dacă construiești coding agents, servere MCP sau orice harness custom bazat pe tool use, genul acesta de regresie doare imediat în producție.
Este o postare scurtă de la Simon Willison care trimite la experiența lui Armin Ronacher cu Pi. Modul concret în care apare eroarea este simplu: modelul face editarea corectă, dar o împachetează în argumente care nu respectă schema, iar harness-ul respinge apelul și îi cere să încerce din nou. Partea surprinzătoare nu este că apar tool calls malformed. Asta se întâmplă. Partea surprinzătoare este că modelele noi de top pot fi mai slabe decât cele vechi la un tool third-party pentru care nu au fost antrenate implicit.
Ce se întâmplă de fapt?
Teoria este plauzibilă: vendorii antrenează din ce în ce mai mult modelele în jurul propriilor contracte de tool use. Fluxul de editare Anthropic pare să favorizeze un editor de tip search-and-replace; OpenAI și-a împins și el modelele spre tipare specifice de editare bazate pe patch. Din perspectiva vendorului, este logic. Face produsul lor first-party de coding să pară mai fiabil.
Pentru toți ceilalți însă, asta creează o problemă de compatibilitate. Dacă produsul tău expune un singur edit tool custom, iar modelul are un bias puternic spre altă structură, vei vedea mai multe retry-uri, mai multe validări eșuate și o experiență mai slabă pentru utilizator, chiar dacă modelul în sine este mai inteligent.
În practică, asta împinge echipele spre una din două variante:
- adaptezi suprafața tool-urilor tale la obiceiurile modelului
- suporți mai multe contracte de tool use și faci rutare după familia de modele
Nu m-ar surprinde deloc dacă a doua variantă devine normală pentru echipele care construiesc agenți serioși. Asta este relevant mai ales pentru cei care construiesc servere MCP custom sau Copilot și AI agents care trebuie să funcționeze pe mai mulți provideri.
De ce contează dincolo de un singur edit tool
Există și un efect de ordinul doi aici. Când vendorii optimizează modelele pentru propriile harness-uri, ecosistemele third-party devin puțin mai fragile. Nu pentru că API-urile sunt închise, ci pentru că comportamentul din jurul acelor API-uri devine modelat de vendor.
Asta este diferit de un simplu schema mismatch. Un mismatch normal este un bug. Aici vorbim mai degrabă despre lock-in comportamental.
Consecința operațională este directă: dacă rulezi agenți în producție, validarea de schemă nu este suficientă. Ai nevoie și de compatibility testing pe versiuni și familii de modele și trebuie să îl rulezi din nou când modelul se schimbă. Pentru majoritatea echipelor, asta nu este o problemă de research. Este o problemă de release engineering. Dacă faci deja AI workflow automation, asta ar trebui să stea în suita ta de regresie lângă auth, latență și retry handling.
Părerea mea
Cred că observația de bază este corectă: toolkit-urile coerente sunt mai bune decât cele împrăștiate, iar modelele se descurcă mai bine când există o singură cale evidentă pentru a face o sarcină. Dar lecția mai importantă este pentru platform teams, nu pentru vendorii de modele. Proiectează tool-urile ca adaptoare, nu ca abstracții sacre.
Dacă o familie de modele preferă clar semantica search-replace sau patch, întâlnește-o acolo. Ține-ți modelul intern de acțiuni stabil, dar expune un strat de compatibilitate pe care modelul chiar îl poate folosi. Altfel ajungi să dai vina pe model pentru o problemă de integrare de sistem.
Concluzia practică: testează tool use pe familii de modele, așteaptă-te la regresii la noile release-uri și nu presupune că "best model" înseamnă și "best fit" pentru stack-ul tău de agenți.
