Evaluarea funcționalităților cere reguli de notare cu versiuni

Rezultatul unui agent de programare depinde de regulile care transformă schimbarea propusă într-o reușită sau într-un eșec. Pentru cererile de funcționalități, regulile trebuie să țină cont de schimbările legitime ale testelor existente. Păstrați versiuni ale contractului de notare alături de versiunile setului de sarcini. Altfel, aceeași implementare poate primi alt rezultat, în timp ce titlul pare să descrie același experiment.

Articolul Agents on Rails Stage 2 este datat 9 septembrie 2026. Textul său actual conține o actualizare datată explicit 15 septembrie, care schimbă tratarea directoarelor de teste în notarea funcționalităților. Articolul ulterior din 21 septembrie explică reevaluarea și o corecție separată a izolării. Aceste relatări ulterioare oferă context retrospectiv, iar rezultatele revizuite nu ar trebui prezentate ca măsurători inițiale din 9 septembrie.

Funcționalitatea poate schimba așteptarea unui test

Prezentarea Stage 2 descrie cereri de funcționalități pentru Fizzy. Discuția despre notare compară restaurarea directoarelor de teste cu păstrarea modificărilor legate de funcționalitate. Distincția contează deoarece o verificare existentă poate descrie un comportament pe care funcționalitatea cerută trebuie să îl schimbe. Restaurarea verificării vechi poate face evaluatorul să respingă comportamentul urmărit.

Întrebarea tehnică este ce intenționează autorul cererii să păstreze neschimbat. Unele comportamente existente ar trebui să supraviețuiască funcționalității; altele trebuie să se schimbe pentru ca funcționalitatea să existe. Un contract corect are nevoie de o cale de a le deosebi. „Toate testele trec” este incomplet dacă nu precizează ce versiune a testelor definește finalizarea.

Permiterea editării nu echivalează cu acceptarea fiecărui test modificat. Un candidat ar putea slăbi o verificare fără să implementeze cerința. Evaluatorul are în continuare nevoie de dovezi independente ale comportamentului cerut. Limita potrivită protejează sensul sarcinii și permite lucrul obișnuit necesar pentru îndeplinirea ei.

De aceea, descrierea sarcinii și verificările ascunse trebuie să concorde. Dacă descrierea permite schimbarea comportamentului, dar verificarea impune comportamentul vechi, rezultatul măsoară un conflict din evaluare. Dacă descrierea este prea vagă pentru a lămuri întrebarea, responsabilul evaluării are o problemă de specificație de rezolvat înainte de a trata eșecul ca pe o constatare despre capacitate.

Testele protejate au un scop legitim

Contraargumentul cel mai puternic vine din sarcinile atomice. Când o suită fixă de teste definește comportamentul cerut, restaurarea ei protejează împotriva unui candidat care schimbă definiția reușitei. O suită protejată la editare poate fi o limită rezonabilă împotriva manipulării evaluării. Evaluarea unei funcționalități ar trebui să explice de ce folosește altă limită, fără să trateze protejarea evaluatorului ca pe o greșeală în sine.

Distincția urmează sarcina. O sarcină atomică poate cere o implementare precisă, cu așteptări neschimbate. O cerere de funcționalitate poate cere comportament nou și revizuirea corespunzătoare a așteptărilor vechi. Aplicarea aceleiași politici pentru ambele poate confunda consecvența cu echitatea. O regulă consecventă este utilă doar când sensul ei se potrivește sarcinii măsurate.

Pentru cei care revizuiesc, aceasta sugerează o verificare concretă a contractului. Identificați dovezile pe care candidatul le poate modifica și dovezile care rămân independente. Explicați de ce separarea păstrează cerința urmărită. Explicația permite revizuirea politicii fără să oblige cititorul să îi deducă scopul dintr-un tabel de scoruri.

Reevaluarea schimbă interpretarea unei execuții vechi

Explicația din 21 septembrie spune că execuțiile Stage 2 înregistrate au fost reevaluate după regula revizuită pentru funcționalități. Reevaluarea sub o altă regulă este o judecată nouă asupra lucrului păstrat. Ar trebui să poată fi deosebită de o încercare nouă de generare și de judecata inițială.

O evidență utilă a rezultatelor ar păstra, așadar, împreună versiunea sarcinii, identitatea soluției propuse și versiunea politicii de notare. Datele generării și ale evaluării pot fi diferite. Cititorii au nevoie de suficiente informații pentru a înțelege dacă schimbarea rezultatului provine din altă soluție sau din altă interpretare a aceleiași soluții. Un procent fără această legătură pierde o parte din sens.

Corecțiile pot îmbunătăți o evaluare. Păstrarea contractului anterior rămâne utilă fiindcă explică schimbarea și le permite cititorilor să aprecieze corecția. Obiectivul ar trebui să fie posibilitatea de a urmări proveniența, fără impresia că regula corectată a fost mereu în vigoare. Data publicării din partea de sus a unei pagini modificabile nu poate oferi singură această istorie.

Izolarea își are locul lângă regulile de notare

Articolul ulterior relatează și o problemă de izolare, urmată de execuții corectate. Este relatarea autorilor despre mediul propriu de evaluare, nu un experiment local reprodus aici. Oferă încă un motiv pentru a lega condițiile execuției de rezultate: sensul unei sarcini depinde de resursele pe care candidatul le putea folosi efectiv.

Pentru responsabilul evaluării, resursele permise fac parte din specificație. Dacă mediul pune la dispoziție informații suplimentare, rezultatul poate răspunde altei întrebări decât celei anunțate. Schimbarea mediului poate fi necesară, dar execuția rezultată are nevoie de propriile condiții. Combinarea unor execuții diferite fără explicație ar ascunde distincția necesară cititorilor pentru interpretare.

Observația nu justifică o recomandare de cumpărare sau un clasament general al modelelor de programare. Acestea sunt execuții pentru sarcini specifice, în configurația declarată de autori. Echipa de mentenanță care își alege procesul ar avea nevoie de dovezi potrivite lucrului și restricțiilor sale. O evaluare limitată la contextul autorilor poate informa întrebările fără să răspundă la fiecare decizie de exploatare.

Pentru mentenanța software, păstrați aceeași disciplină când acceptați funcționalități scrise de agenți: definiți ce comportament se poate schimba și ce dovezi independente stabilesc finalizarea. Păstrați împreună versiunile sarcinii și ale contractului său de notare. Rezultatul devine mai util când cititorul poate spune exact pe ce se bazează.