O copie veche de lucru poate expune remedierea din viitor
Cazul SWE-bench 465 arată de ce izolarea evaluării include metadatele Git. Distingeți scurgerile raportate, remediile și ce mai poate demonstra un scor.
De 
Paul. AI și programare cu agenți
O evaluare a unui agent poate afișa fișierele vechi corecte și totuși poate expune informații din viitor. Selectarea unei versiuni istorice schimbă copia de lucru; nu stabilește că fiecare referință, obiect sau mesaj accesibil aparține acelui moment. O evaluare justificabilă a programării are nevoie de limite pentru informația disponibilă, nu doar de o revizie de bază.
Privind din noiembrie 2026, sesizarea SWE-bench #465 oferă un exemplu concret. Jacob Kahn a deschis-o la 3 septembrie 2025. Discuția comunității care a adus-o în atenția unui public mai larg la 11 septembrie nu a fost originea raportării. Cronologia contează deoarece răspunsul proiectului începuse deja înaintea acelei discuții.
Ce stabilește efectiv raportarea
Kahn a prezentat exemple publice de parcursuri în care agenții au consultat istoricul depozitului, care conținea remedieri ulterioare sau descrierile lor. Un caz privea o sarcină pytest; altele priveau Django. Raportarea este o sursă primară despre ce a observat și furnizat autorul, nu o repetare independentă în acest articol. Aici nu a fost executat niciun test comparativ și nu au fost accesate depozite private sau răspunsuri ascunse.
Un mesaj ulterior al unui colaborator al raportorului separa parcursurile considerate a fi obținut modificarea de referință de cele care doar aflaseră informații din viitor, fără o legătură demonstrată cu acea modificare. Colaboratorul numea căutarea preliminară, admitea posibile erori de clasificare și spunea că echipa nu avea o metodă automată de detectare. Păstrați aceste precizări. Expunerea la informații viitoare și dovada că ele au schimbat un răspuns reușit sunt afirmații diferite.
Faptul documentar confirmat este că raportarea publică include exemple și limite concrete. Afirmația mai largă este că asemenea scurgeri pot deforma scorurile. Exemplele justifică inspectarea execuțiilor afectate, dar nu stabilesc proporția afectată din fiecare clasament. O comandă suspectă, un mediu contaminat și un rezultat care ar eșua în condiții de izolare reprezintă trei constatări diferite.
Data privește întregul mediu accesibil
Git poate păstra mai multe informații decât fișierele selectate în prezent. Referințele pot indica modificări ulterioare. Jurnalele referințelor pot păstra deplasări și mesaje. Baza de obiecte poate conține material din afara perspectivei istorice dorite. Prin urmare, „fără internet” descrie incomplet izolarea: agentul poate întâlni informații viitoare nepermise fără nicio cerere de rețea.
Cerința defensivă este să definiți ce informații aparțin sarcinii. Contextul istoric poate fi legitim și util în investigarea unei regresii. Remedierile viitoare nu sunt dovezi legitime când testul întreabă dacă sistemul poate deduce remedierea dintr-o stare anterioară. Limita trebuie să urmeze întrebarea evaluării, nu o interdicție arbitrară asupra oricărei folosiri a istoricului.
Construiți artefactele evaluării pentru această limită și inspectați ce poate citi efectiv agentul. Tratați metadatele depozitului, datele cache montate și artefactele preinstalate ca intrări de verificat. Păstrați răspunsul de referință și testele ascunse în afara mediului accesibil agentului. Sunt recomandări de proiectare, nu instrucțiuni pentru extragerea remedierii din testul altcuiva sau o afirmație că o rețetă de curățare a fost verificată aici.
Răspunsul responsabililor a schimbat situația
Un răspuns al unui responsabil din 4 septembrie spunea că infrastructura de evaluare și imaginile erau adaptate. La 11 septembrie, Carlos Jimenez a raportat actualizarea imaginilor Verified și remedierea construirii lor prin PR #471, în versiunea 4.1.0 a pachetului, cu păstrarea istoricului trecut și a etichetelor anterioare reviziei de bază. Răspunsul distinge măsura raportată de expunerea inițială.
Aceeași discuție consemnează o căutare inițială a unui responsabil, care găsise puține potriviri pentru anumite comenzi de istoric și respingea atunci repetarea tuturor evaluărilor. Metoda era restrânsă; nu dovedea absența altor forme de acces. Invers, constatările preliminare ale raportorului nu justifică înlocuirea acelei estimări cu o rată globală de contaminare inventată. Dezacordul justifică prezentarea metodei și a limitelor.
Sesizarea este acum închisă; API-ul public înregistrează închiderea la 24 martie 2026. Un comentariu din februarie spusese că Verified și Multilingual erau remediate, iar lucrul la Multimodal continua. Consultate la 9 noiembrie 2026, aceste înregistrări nu certifică fiecare imagine păstrată sau fiecare evaluare derivată. Închiderea indică starea proiectului, nu dovedește ce artefact a produs un scor anterior.
Comparați rezultatele împreună cu mediul lor
Decizia practică de achiziție privește măsura în care scorul răspunde întrebării despre munca în depozitul propriu. Cereți configurația modelului și a agentului, versiunea mediului, identitatea imaginii și data evaluării. Dacă execuția precedă remedierea sau folosește un artefact păstrat, scorul are nevoie de acel context. Răspunsul potrivit poate fi repetarea sau o comparație cu rezerve explicite, în funcție de dovezile disponibile.
Cel mai puternic contraargument este că istoricul versiunilor face parte din ingineria reală. Un agent care consultă o modificare anterioară poate lucra util, iar eliminarea agresivă a istoricului poate face sarcina mai puțin realistă. Obiecția susține păstrarea contextului trecut permis. Nu legitimează o soluție viitoare într-un test menit să măsoare remedierea independentă pornind de la o stare anterioară.
Un asistent folosit în producție poate fi util chiar când o afirmație despre evaluare trebuie corectată. Nu transformați un defect al izolării într-o afirmație că întreaga muncă asistată de modele nu are valoare. Tot astfel, nu folosiți o experiență utilă cu produsul pentru a valida o metodă de clasament fără legătură. Cele două decizii cer dovezi proprii.
În dezvoltarea de software la comandă, o sarcină locală de acceptare ar trebui să precizeze informațiile permise și să păstreze identitatea mediului alături de rezultat. Verificați limita în pregătire, înaintea comparației între candidați. O copie veche de lucru datează fișierele vizibile. O evaluare credibilă trebuie să țină seama și de restul informațiilor pe care agentul le putea cunoaște.