Scena aceasta merită recunoscută din prima, așa că începem cu ea. Ați terminat de scris un joc, scorul se resetează după repornire și îl întrebați pe agent:
De ce se pierde scorul după repornire?Răspunsul vine calm și bine închegat:
Proiectul salvează deja scorul, doar că scrierea nu este activată nicăieri.
Este suficient să schimbați o singură setare și rezultatul va supraviețui repornirii.Mergeți să verificați. În proiect nu există și nu a existat nici setarea, nici salvarea scorului - niciun rând, nicio aluzie. Răspunsul suna ca o analiză a codului dumneavoastră, dar era o presupunere despre felul în care sunt structurate de obicei astfel de proiecte.
Și înainte de el nu a existat nicio pauză, nicio rezervă. Tonul a fost exact același ca la toate răspunsurile anterioare, care s-au dovedit corecte. Instrumentul funcționează normal, iar modelul nu a devenit mai slab decât era ieri.
Cauza ține de felul în care apare răspunsul. Modelul nu scoate un fapt gata făcut dintr-o arhivă - alege o continuare probabilă a textului dumneavoastră, bucată cu bucată. Iar probabil și corect sunt lucruri diferite, mai ales când e vorba de proiectul dumneavoastră, pe care modelul nu l-a văzut. Detaliile inventate, dar plauzibile, se numesc de obicei halucinații.
Mai departe - unde sunt întinse capcanele, de ce eroarea are mereu un ton calm și ce trei verificări acoperă majoritatea acestor cazuri.
Ce vede modelul în cererea dumneavoastră
Capcana de aici e cea mai simplă dintre toate: pare că modelul se uită la proiectul dumneavoastră. De fapt, se uită doar la ce i s-a transmis, iar i se transmit următoarele:
- Cunoștințe încorporate. Tipare care s-au fixat în parametrii modelului în timpul antrenării. Nu fișe cu fapte și surse, ci numere, de aceea modelul poate reproduce inexact chiar și un fapt cunoscut. Și au o limită în timp: despre o bibliotecă apărută mai târziu, modelul știe exact cât i s-a arătat.
- Conversația curentă. Cererea dumneavoastră, istoricul discuției, fișierele pe care agentul le-a citit, ieșirea comenzilor pe care le-a rulat.
- Memoria aplicației. Ce e salvat în fișiere separate și ajunge în conversație la începutul sesiunii următoare. În Claude Code, asta înseamnă
CLAUDE.md, pe care îl scrieți dumneavoastră, și auto memory, în care agentul își notează singur observațiile. - Surse externe. Documentație, căutare, bază de date, fișierele proiectului - tot ce putea să lipsească din datele de antrenare sau s-a schimbat de atunci.
Ultimele trei ajung pe aceeași cale: ca să influențeze răspunsul, trebuie să ajungă în conversația curentă. Modelul, de unul singur, nu se uită în proiect.
De aici o consecință pe care merită s-o așezați în minte o dată pentru totdeauna. Un fișier pe care nu l-a deschis nimeni nu există pentru model. Cât timp textul lui nu a ajuns în conversație, întrebarea "unde se face la noi autentificarea" e mai onest s-o citiți ca "cum se numește de obicei un astfel de fișier în proiecte asemănătoare". Veți primi un răspuns în ambele cazuri și va arăta la fel.
Alături stă o capcană mai mică, dar enervantă. Un fișier citit rămâne în conversație așa cum a fost citit. Ați corectat un rând în editor, iar în istoricul conversației se află versiunea veche. Claude Code va semnala că fișierul s-a schimbat, dar dacă agentul îl va reciti decide deja modelul. Ați editat manual în mijlocul conversației - e mai sigur să-i cereți direct să recitească fișierul.
Claude Code citește mai întâi proiectul și rulează comenzi, și abia apoi răspunde. În răspuns se vede de obicei ce fișiere a deschis și ce a rulat. Dacă răspunsul despre codul dumneavoastră a apărut înainte ca agentul să citească ceva, aveți în față o presupunere despre un proiect tipic, nu o analiză a proiectului dumneavoastră.
De ce formularea schimbă rezultatul
Din tot ce ajunge în conversație, cererea dumneavoastră este singurul lucru pe care îl scrieți chiar dumneavoastră. De aceea detaliile mărunte din ea decid: ați mutat două cuvinte, ați adăugat o precizare - și răspunsul a luat-o în altă direcție. Nu e un capriciu al instrumentului.
Aici e ușor să vă încurcați, așa că o spun separat. Și aceeași cerere trimisă de două ori dă răspunsuri diferite: în răspuns nu intră neapărat cea mai probabilă continuare, iar generarea are setări care stabilesc cât de ușor se alege o variantă mai puțin probabilă. Se naște întrebarea: dacă răspunsul oricum variază, ce rol mai au cuvintele mele? Diferența stă în ce anume variază. Variația între cereri identice e zgomot în jurul aceleiași alegeri: formulările vor diferi, direcția rămâne aceeași. Cuvintele din cerere, în schimb, mută direcția însăși, și o fac constant.
Cel mai prost funcționează o cerere vagă. Îi lasă modelului de ales, iar modelul alege ce e cel mai probabil în general - o medie a tot ce a văzut. Luați un simplu "scurtează textul". Cu cât - cu un procent, cu o treime, la jumătate? Ce se poate scoate și ce nu trebuie atins? Niciuna dintre aceste întrebări nu are răspuns în cerere, deci va răspunde modelul, și formal va avea dreptate. În schimb, "scurtează descrierea cu 30%" sau "scurtează descrierea la 300 de caractere" nu îi lasă de ales acolo unde alegerea e a dumneavoastră.
Se vede bine pe două cereri despre același lucru. "Repară sortarea" lasă totul deschis: ce listă, după ce câmp, ce înseamnă de fapt defecțiunea. A doua formulare, în schimb, nu lasă deschis aproape nimic:
În lista de comenzi, datele sunt de la cele vechi la cele noi, trebuie invers.
Mai întâi arată-mi fișierul și rândul unde e setată ordinea de sortare, apoi propune modificarea.E mai lungă exact cu cât prima lăsa de ghicit. Și pe deasupra face jumătate din verificare în locul dumneavoastră: agentul vă aduce locul din cod înainte să-l întrebați de el.
Concluzia e simplă: cu cât cererea lasă mai puțină libertate, cu atât răspunsul conține mai puțină ghicire. Nu e vorba de formule magice, ci de un lucru banal - ori stabiliți dumneavoastră cadrul, ori îl alege altcineva în locul dumneavoastră.
Tonul sigur nu înseamnă fapt
Iată și capcana principală. Modelul nu are o intonație separată pentru "asta știu sigur" și alta pentru "asta tocmai am completat": ambele fraze se construiesc la fel și ies la fel de calme. Legătura nu e chiar nulă, dar nu vă folosește la nimic: încrederea modelului e mereu umflată, așa că după ton nu veți deosebi ce e verificat de ce e completat.
Într-un text obișnuit, o afirmație ciudată vă sare în ochi și încetiniți singur. În cod, protecția asta nu funcționează: numele arată corect, construcțiile sunt familiare, iar o metodă reală a unei biblioteci nu se deosebește din priviri de una compusă prin analogie, dacă nu știți biblioteca pe de rost. De aceea greșeala iese la iveală mai des la rulare decât la citire.
Pe deasupra, numele e rareori inventat de la zero. Într-o analiză a codului generat, în care s-au căutat referințe la biblioteci inexistente, peste o treime dintre aceste nume s-au dovedit a fi lipituri din două nume reale. De aici și senzația de autenticitate: părți din nume le-ați mai văzut undeva, doar că nu în combinația asta.
Patru cazuri pe care le recunoașteți din prima, dacă știți ce să căutați:
| Cum arată | Ce s-a întâmplat | Cum se prinde |
|---|---|---|
| o comandă primește un flag pe care nu îl are | modelul a construit rândul după forma obișnuită, de aceea flagul și arată real | ajutorul comenzii sau documentația ei |
| e numit un fișier, o funcție sau un câmp de configurare care nu există în proiect | numele pare tipic pentru un astfel de proiect, dar proiectul nu l-a citit nimeni | căutare în proiect, cererea de a arăta rândul |
| se povestește cu încredere cum e structurat proiectul dumneavoastră | în conversație nu a existat niciun fișier din proiect, deci e descris unul tipic | întrebați ce fișiere a deschis înainte de răspuns |
| se spune "gata", dar comanda nu a fost rulată | raportul e construit din textul sarcinii, nu din rezultatul rulării | rulați singur și uitați-vă la ieșire |
Toate patru au un singur lucru în comun: răspunsul sună ca rezultatul unei munci, deși în spatele lui nu a stat nicio muncă.
Ultimul caz merită discutat separat, pentru că arată ca o înșelăciune, dar nu e. Agentul se oprește când munca pare făcută. Dacă nu are ce rula, "pare făcută" e singurul semnal disponibil, iar bucla de verificare deveniți dumneavoastră.
Prețul are cifre. Într-o analiză a logurilor unor agenți, "gata"-urile false au dat aproape jumătate din toate eșecurile. Iar acolo unde starea era verificată independent de raportul agentului, astfel de cazuri aproape dispăreau. Exact ăsta e rostul celei de-a doua verificări din secțiunea următoare: pune în locul raportului ceva ce puteți vedea cu ochii dumneavoastră.
Rămâne întrebarea de ce modelul preferă să completeze în loc să recunoască. Ține de felul în care a fost antrenat și evaluat. Imaginați-vă un test grilă în care o foaie goală primește sigur zero, iar un răspuns bifat la noroc are o șansă la un punct. Într-un astfel de sistem, tăcerea nu se merită niciodată, iar să răspunzi la orice nesiguranță e rațional. Omul se dezvață mai târziu, pe sarcini reale, unde un răspuns greșit costă mai mult decât un "nu știu" onest. Modelul nu trece printr-o astfel de dezvățare.
Dacă îi cereți modelului să vă avertizeze sincer când nu e sigur, ajută - dar și avertismentul e text construit de același mecanism. Ca semnal suplimentar e bun, ca înlocuitor al verificării nu.
Instrumentele reduc punctele oarbe
Aici e util să despărțim două cuvinte care de obicei se amestecă în discuție. Modelul știe să facă un singur lucru: primește conversația și produce o continuare. Agentul e programul din jurul modelului, care are instrumente: citirea unui fișier, rularea unei comenzi, modificarea proiectului.
Și acum un detaliu de care depinde unde anume apare greșeala. Instrumentele nu le alege programul. Modelul cere în răspunsul său să se deschidă un anumit fișier sau să se ruleze o anumită comandă, iar programul verifică cererea, o execută și întoarce rezultatul în conversație. Decizia o ia modelul, acțiunea o execută programul. Deci poate greși și decizia însăși: nu fișierul care trebuie, nu comanda care trebuie, nu testul care trebuie.
Diferența rămâne totuși uriașă. Cât timp fișierul nu e deschis, răspunsul despre el se construiește din memoria despre proiecte asemănătoare. De îndată ce fișierul a fost citit și testul rulat, în conversație apare un fapt: iată conținutul, iată ieșirea. Asta nu mai e o amintire, ci o verificare, iar calitatea răspunsurilor de după ea e vizibil alta.
De aici un truc care costă un singur rând la începutul conversației:
Mai întâi găsește și arată-mi unde se află asta în proiect, și abia apoi explică.Punctele oarbe se îngustează, dar nu dispar. Agentul poate deschide fișierul de alături în locul celui corect, poate interpreta ieșirea comenzii în felul lui sau se poate opri la prima explicație plauzibilă fără să ajungă la cauza reală. Pe toate le-am văzut, și nu o singură dată. De aceea un semnal extern - ieșirea unui test, textul documentației, conținutul unui fișier - cântărește mai mult decât cel mai sigur raționament fără sprijin.
Trei verificări care merită un minut
Vestea bună e că astfel de greșeli se prind aproape fără efort. Totul se reduce la o singură bifurcație.
Nu contează cât de convingător e scris, ci dacă răspunsul vă oferă ceva de care să vă agățați: un fișier anume, un rând anume, o comandă cu ieșirea ei. Fără punct de sprijin, aveți deocamdată în față o ipoteză, nu un rezultat. Multe răspunsuri așa și încep, întrebarea e doar ce faceți mai departe.
Urmează trei verificări. Fiecare durează mai puțin de un minut și rareori aveți nevoie de toate trei deodată.
- Cereți să vi se arate locul. Nu "explică mai detaliat", ci "arată-mi fișierul, rândul și fragmentul în sine". Dacă locul nu există, se vede imediat.
- Deschideți sau rulați rezultatul personal. Pagina în browser, comanda în terminal, testul în proiect. Raportul despre muncă și munca nu sunt același lucru.
- Comparați afirmația despre un instrument cu instrumentul însuși. O comandă are ajutor încorporat, o bibliotecă are documentație. Flagul sau cheia de configurare numită fie există acolo, fie nu, și aflați asta în jumătate de minut. Cu metodele unei biblioteci e mai delicat: în documentație nu intră totul, de aceea lipsa unei metode e un motiv să întrebați din nou, nu o sentință.
În loc să vă contraziceți cu răspunsul, cereți direct un punct de sprijin:
Arată-mi fișierul și rândul unde e descris asta.
Dacă un astfel de loc nu există în proiect, spune direct că e o presupunere.Două rânduri care merită ținute la îndemână. Primul trimite agentul în proiect, în loc să răspundă din memoria despre proiecte asemănătoare. Al doilea îi oferă o ieșire: să spună că locul nu există devine mai ieftin decât să completeze răspunsul până la ceva plauzibil.
Pentru un raport "gata" funcționează aceeași cerere, doar că despre rulare: "arată-mi comanda pe care ai rulat-o și ieșirea ei completă".
Garanție nu devine: fraza "asta e o presupunere" e construită de același mecanism ca tot restul. Reduce șansa unei greșeli, dar nu înlocuiește verificarea.
Și imediat o precizare, ca să nu rămână un gust greșit. A verifica nu înseamnă a nu avea încredere în instrument. Și propriul diff îl recitiți înainte de commit, deși l-ați scris chiar dumneavoastră. Aici e la fel, doar că motivul e ceva mai serios.
Ce înseamnă asta pentru lucrul cu Claude Code
Ce rezultă din toate acestea direct la tastatură:
- un răspuns cu trimitere la un fișier, un rând sau ieșirea unei comenzi se verifică în câteva secunde. Un răspuns fără ele nu aveți cu ce să-l verificați: nu vă rămâne decât să-l recitiți și să fiți de acord;
- lăsați agentul să citească ce trebuie înainte să puneți întrebarea. Un pas în plus elimină o întreagă clasă de greșeli;
- după siguranța din ton nu se poate judeca: e umflată indiferent dacă în spatele cuvintelor stă o verificare sau o ghicire;
- "sună corect" și "funcționează corect" sunt lucruri diferite, și doar rularea le deosebește;
- cu cât greșeala costă mai mult, cu atât mai devreme ar trebui să apară în conversație ceva extern: un test, documentația, fișierul real. La o modificare mică ajunge o privire pe diff;
- dacă agentul a greșit, spuneți-i asta ca fapt, nu ca evaluare. "Funcția asta nu există în proiect, iată ce e în folder" duce munca mai departe, "iar ai inventat totul" nu duce nicăieri. Și țineți minte: la o obiecție sigură pe ea, agentul mai degrabă se adaptează decât să conteste, chiar și când dreptatea era de partea lui. Acordul agentului nu confirmă că aveți dreptate.
Un mecanism care uneori greșește cu încredere rămâne totuși extrem de util. Limitele lui merită cunoscute tocmai ca să nu pierdeți timp mirându-vă și să treceți direct la verificare.
GO TO FULL VERSION