Nu cere drumul cel mai scurt

În articolul precedent am ajuns la o întrebare care rămăsese fără răspuns: cum ar fi să-ți poți construi propria aplicație de verificare a declarației D406, care rulează pe calculatorul tău, care nu trimite nimic nicăieri, care costă zero și care face exact verificările specifice firmei tale.

Am promis că trecem de la analiză la construcție și că totul se întâmplă la vedere, cu prompturile publicate, ca oricine să poată reface pașii pe cazul lui. Articolul acesta e primul din faza de construcție și, paradoxal, nu conține nicio linie de cod.

Motivul e simplu și îl datorăm unei greșeli făcute deja, acum patru luni.

Ce ne-a costat prima aplicație

Primul instrument construit aici a fost un verificator de coduri fiscale prin API-ul public ANAF. A pornit de la o cerere directă, formulată aproximativ așa: construiește-mi o aplicație care verifică în masă coduri fiscale și îmi scoate rezultatele în Excel.

Asistentul a livrat. După 50-70 de schimburi și opt iterații, aplicația mergea: 8.000 de coduri verificate în circa 80 de secunde, interfață grafică, executabil Windows pe care îl deschideai cu dublu clic. Din punctul de vedere al cerinței formulate, rezultatul era ireproșabil.

Apoi a venit versiunea a doua, care a arătat ce lipsea:

Merită privit tabelul acesta încă o dată, pentru că e miezul întregului articol.

Niciuna dintre cele șapte diferențe nu venea dintr-o limită tehnică. Toate șapte puteau fi cerute din prima zi, fără efort suplimentar, fără cunoștințe în plus. Nu au fost cerute pentru că nu știam că se pot cere. Iar asistentul nu le-a propus pentru că nu i-am dat niciodată ocazia să propună ceva.

I-am dat o destinație și a mers pe drumul cel mai scurt către ea. A făcut exact ce am cerut, ceea ce nu e același lucru cu a face ce aveam nevoie.

De data asta începem altfel. Nu cerem aplicația, cerem planul.

Ce punem pe masă înainte să scriem prima linie de cod

Un inventar făcut o singură dată, la care ne întoarcem în fiecare săptămână. Cinci unelte, toate publicate deja aici:

Merită spus limpede: nimic din lista asta nu a fost publicat cu proiectul SAF-T în minte. S-a adunat în patru luni, articol cu articol, pe subiecte care păreau independente unul de altul. Abia acum, puse una lângă alta, se vede că formează exact setul de care avem nevoie. Le luăm pe rând.

Unealta întâi: vocabularul

Un asistent AI care îți propune o arhitectură îți va propune, inevitabil, o listă de termeni. Dacă nu îi înțelegi, ai două variante: accepți, sau întrerupi ca să întrebi. În practică, aproape toată lumea acceptă. Fenomenul are un nume, se cheamă automation bias, și e cu atât mai puternic cu cât propunerea sună mai competent.

Glosarul de mai jos nu e decor și nu e o listă de citit dintr-o suflare. E condiția în care rămâi tu cel care decide, nu cel care asistă la o decizie.

Începem cu plan mode și cu project, pentru că sunt primele două decizii practice ale proiectului. Nu lucrăm într-o conversație oarecare, pe care o pierdem peste trei zile, ci într-un container persistent, cu instrucțiuni permanente, documente de referință și istoric. Asistentul primește acces la un folder de pe calculatorul nostru, poate consulta de fiecare dată schema oficială și lista testelor, și poate crea fișiere acolo. Criteriul din arhiva Buzzword pentru un project este recurența, o temă abordată de cel puțin trei ori pe lună. Un proiect care se întinde pe mai multe săptămâni trece pragul fără discuție.

Termenii sunt treizeci, grupați în cinci categorii. Ca să nu întrerupem firul cu un tabel de treizeci de rânduri, mai jos rămân doar doi sau trei din fiecare categorie, cei fără de care nu se poate începe. Tabelul complet e la finalul articolului, în anexă, pentru cine vrea să îl parcurgă dintr-o dată sau să se întoarcă la el mai târziu.

Fiecare denumire duce la pagina completă din arhiva Buzzword, cu pronunție, exemple contabile și întrebări frecvente. Descrierile de aici sunt intenționat scurte, cât să știi despre ce e vorba când termenul apare într-o propunere.

A. Cadrul: unde se poartă discuția

B. Interlocutorul: cine răspunde

C. Cererea: cum se formulează

D. Legătura cu calculatorul

E. Controlul: ce nu se deleagă

Unealta a doua: metoda de a cere

Aici nu inventăm nimic, pentru că metoda e deja scrisă în două articole. O recapitulăm pe scurt și o aplicăm pe cazul nostru.

Cele șapte ingrediente

Din primul articol despre prompt: Rolul, Contextul, Acțiunea, Pașii, Exemplele, Rezultatul, Iterarea. E structura de bază a oricărei cereri serioase, indiferent de subiect.

Cele șapte elemente de arhitectură

Din al doilea articol, cel care pornea de la observația că trucurile de vocabular au murit și a rămas arhitectura: Structura cu etichete, Ordinea, adică documentele sus și întrebarea jos, Guardrails, Canarul din mină, Economia de tokeni, Contractul de ieșire, Contextul permanent.

Ce reținem pentru proiectul acesta

Contextul permanent merge în instrucțiunile project-ului, nu în fiecare prompt. Acolo intră ce nu se schimbă niciodată: că lucrăm local, că fișierele reale nu ies din calculator, că enunțul testelor de consistență se ia din documentul ANAF și nu din memoria modelului.

Guardrail-ul cel mai important al proiectului e permisiunea explicită de a spune „nu știu”. Formularea recomandată în articol e pozitivă, adică îi dai un răspuns acceptabil în loc să îi interzici ceva: dacă informația nu se află în documentele furnizate, scrie exact „Nu rezultă din textele furnizate”. Un model care inventează un test de consistență e mult mai periculos decât unul care refuză să răspundă.

Contractul de ieșire se cere din faza de planificare, nu la final. Ce coloane are raportul, ce înseamnă o linie marcată roșu, unde apare gradul de certitudine.

Ordinea contează la un proiect cu documente mari. Schema oficială și lista testelor se pun sus, întrebarea jos. Motivul are și el un nume, lost in the middle: ce stă la mijlocul unui context lung e cel mai ușor de ratat.

Două trucuri mici, care schimbă rezultatul

Primul: pune AI-ul să-ți scrie promptul. E scurtătura propusă în primul articol, sub numele de meta-prompt. În loc să reconstruiești de fiecare dată cele șapte ingrediente, îi descrii problema în două rânduri și îi ceri să genereze el promptul optimizat, cu rolul, contextul, acțiunea, pașii, unul sau două exemple de intrare și ieșire, formatul și tonul. Apoi îl citești, îl corectezi și abia pe urmă îl execuți. Rezultatul e aproape întotdeauna mai complet decât ce ai fi scris singur, pentru că modelul nu uită nicio secțiune.

Al doilea: pune-l să-ți pună întrebări. E o singură instrucțiune, așezată la finalul promptului, și e cea mai ieftină asigurare împotriva unei porniri greșite:

<clarificari>
Înainte să începi, pune-mi 3-5 întrebări despre elementele din acest
prompt care rămân ambigue și care, interpretate greșit, ar duce
rezultatul într-o direcție pe care ar trebui s-o refac de la zero.
</clarificari>

Cele trei rânduri de mai sus sunt exact ce a lipsit la prima aplicație. Dacă ar fi existat în promptul de acum patru luni, tabelul cu cele șapte diferențe din primul capitol ar fi arătat altfel, sau nu ar fi existat deloc.

Unealta a treia: experiența celor două tool-uri

Experiența nu e teorie. E o listă de lucruri care ne-au lipsit efectiv, deci o listă de cerințe pentru specificația care urmează.

Din prima aplicație, cinci lecții enunțate atunci și confirmate de atunci încoace: bariera tehnică a căzut, un contabil poate construi unelte interne fără programator; iterația e fundamentală, primul răspuns e o schiță; nu reinventezi roata, dacă softul de contabilitate are deja funcția, o folosești pe aceea; testezi pe date reale, la scara producției, pentru că zece cazuri perfecte nu spun nimic despre o mie; iar validarea rămâne responsabilitatea omului, fiindcă semnătura de pe raport rămâne tot a ta.

Din a doua, trei lecții care sunt de fapt cerințe:

1. Ce se schimbă în timp nu are ce căuta în cod. Practica opusă are un nume, hardcoding. Adresa unui serviciu ANAF, un prag, o mapare de câmpuri. Toate acestea aparțin unui fișier separat, pe care îl poți edita fără să atingi programul.
2. Interfața nu e cosmetică. Utilizatorul are nevoie să aleagă ce sortează, ce filtrează și ce exportă. Minimul prevăzut de autor devine, în două luni, motivul pentru care nimeni nu mai folosește aplicația.
3. Erorile se scriu într-un jurnal de execuție. „A apărut o eroare” nu e un mesaj, e o ridicare din umeri. Fără jurnal nu ai pistă de audit, iar fără pistă de audit nu poți explica un rezultat.

Peste toate rămâne principiul de casă: V&V, Vibe & Verify. Vorbești cu AI, primești soluția, verifici rezultatele. Partea a doua nu e opțională.

Unealta a patra: ritmul

Proiectul acesta se livrează în articole săptămânale, pe mai multe săptămâni. Cere de la cititor exact obiceiul pe care AI Journal îl construiește: zece minute pe zi, la prima cafea.

Jurnalul e un singur fișier care se deschide pe calculator, fără instalare și fără configurare. Caseta zilnică ia cinci rânduri, cât să notezi ideea principală despre termenul zilei. Caseta săptămânală e activitatea practică și poate rămâne goală fără să strice progresul. Șase săptămâni, 30 de zile, câte un termen pe zi lucrătoare.

Suntem în săptămâna a patra, iar operațiunea e în continuare deschisă. Cele șase episoade sunt publicate, deci cine intră acum poate recupera fără să piardă nimic.

Legătura cu proiectul e comodă și nu e forțată: în săptămânile care vin, termenul zilei din jurnal poate fi chiar unul din glosarul de mai sus, iar activitatea săptămânală poate fi chiar pasul din articolul curent. Cele două se alimentează reciproc.

Unealta a cincea: materia primă

Partea de date e deja rezolvată, și e toată publică:

• schema oficială a fișierului, care descrie ce elemente are voie să conțină și în ce ordine;
• fișierul cu definiții și note explicative, care spune ce înseamnă fiecare câmp;
• cele 33 de teste de consistență enunțate public de ANAF, în două serii;
• nomenclatorul care leagă codurile de taxă de rândurile decontului.

Asta e ce primește asistentul. Nu primește fișierul D406 al firmei, iar distincția e regula fondatoare a proiectului: cu AI se scrie codul, prelucrarea datelor rămâne locală.

Plan mode: nu cere aplicația, cere planul

Am ajuns la partea care leagă tot restul, și care încape într-o singură propoziție: nu cere aplicația, cere planul.

Fiecare îi spune altfel. „Plan mode” în instrumentele care au un buton dedicat, „brainstorming” în vorbirea curentă, „faza de descoperire” în limbaj de proiect, „discuție de scoping” la cei care vin din consultanță. Unele asistente au un mod explicit, în care refuză să scrie cod până nu i-l ceri; la restul, se obține prin felul în care formulezi cererea. Denumirea nu contează. Regula da: în etapa asta nu se scrie cod. Se pun întrebări, se enumeră variante, se resping variante, se ajunge la o specificație.

Diferența față de o cerere obișnuită se vede cel mai bine pe un exemplu din arhiva proprie. Pentru prezentarea despre vibe coding nu s-au cerut slide-uri. S-a pus o întrebare deschisă, în esență „cum fac prezentarea asta mai puțin plictisitoare”, iar răspunsul a fost o pagină interactivă cu un calculator de TVA, un ciclu de revizuire animat, un dulap cu șase dosare și trei jocuri tematice. Nimic din toate acestea nu ar fi apărut într-o cerere directă, pentru simplul motiv că nu ai cum să ceri ce nu știi că se poate.

Acesta e argumentul practic pentru plan mode, și e exact lecția din primul capitol. Nu ceri drumul cel mai scurt către o destinație pe care ai ales-o singur, pe baza a ce știai tu în ziua aceea. Ceri harta, te uiți la ea, și abia apoi alegi drumul.

Al doilea argument e mai puțin spectaculos și mai important pe termen lung: deciziile rămân documentate. O conversație de planificare produce un lucru pe care o cerere directă nu îl produce niciodată, și anume o listă scrisă de alternative respinse, cu motivul respingerii. Peste șase luni, când cineva întreabă de ce aplicația citește fișierul într-un anumit fel și nu altfel, răspunsul există. Nu se reconstruiește din memorie și nu se reia discuția de la zero.

Pentru un contabil, argumentul acesta nu are nevoie de traducere. E aceeași diferență ca între un dosar de lucru și un rezultat fără urmă. Cine cere direct aplicația primește rezultatul. Cine cere planul primește și dosarul.

Trei reguli care nu se negociază

Au fost enunțate ca precauții la finalul articolului precedent. De aici înainte își schimbă statutul: intră în instrucțiunile permanente ale project-ului, deci se aplică automat la fiecare conversație, fără să le rescriem.

1. Fișierul real nu se încarcă în instrumente AI publice. Ce se generează cu AI e codul. Prelucrarea datelor rămâne pe calculatorul tău. Termenii de reținut: data leakage și shadow AI.
2. AI-ul scrie bine codul care aplică o regulă cunoscută, dar nu decide care e regula corectă. Enunțul testelor se ia din documentul ANAF, nu din memoria modelului. Termenul de reținut: hallucination.
3. Orice instrument propriu se calibrează pe o lună deja depusă și acceptată. Dacă nu dă aceleași cifre ca fișierul real, instrumentul e cel greșit, nu fișierul. Termenul de reținut: human in the loop.

Cele trei nu sunt avertismente de final de text. Sunt clauze de proiect, iar din articolul următor se vor vedea scrise ca atare.

Ce urmează

Uneltele sunt pe masă. Mai lipsește ceva, și e lucrul pe care era să-l sărim: unde se poartă discuția. Un asistent care uită tot între conversații nu poate duce un proiect care se întinde pe mai multe săptămâni, iar cele trei reguli de mai sus nu au unde să fie scrise ca să se aplice singure.

De aceea articolul următor, publicat astăzi împreună cu acesta, e despre spațiul de lucru: proiectul care ține minte, cu folderul local, cu regulile scrise într-un fișier și cu memoria pe care asistentul și-o ține singur. Se termină cu un checklist, prima dată în seria asta când ai efectiv ce face, nu doar ce citi.

Imediat după, deschidem conversația de planificare. Promptul se publică integral, așa cum a fost scris, cu tot cu cele trei rânduri care îi cer asistentului să pună întrebări înainte să înceapă. Publicăm și întrebările pe care le pune, și răspunsurile date, pentru că acolo se vede diferența dintre metoda asta și o cerere directă. La final iese o specificație. Din ea iese primul cod care deschide efectiv un fișier D406.

Uneltele sunt pe masă. Data viitoare le folosim, și tot nu cerem aplicația.

Anexă: cei 30 de termeni, la un loc

Aceeași listă din capitolul al treilea, de data asta întreagă. Nu e de citit dintr-o suflare. E de ținut la îndemână, ca atunci când unul dintre termeni apare într-o propunere să te poți opri și să te lămurești în două minute. Fiecare denumire duce la pagina completă din arhiva Buzzword.

A. Cadrul: unde se poartă discuția

B. Interlocutorul: cine răspunde

C. Cererea: cum se formulează

D. Legătura cu calculatorul

E. Controlul: ce nu se deleagă