Conversația care nu a produs cod

Articolul precedent s-a încheiat cu un checklist și cu o promisiune. Checklistul e bifat, iar textul de acum e ce a ieșit din promisiune.

Am purtat cea mai lungă conversație din tot proiectul și nu am scris nicio linie de cod. Nu e o scăpare, e chiar rezultatul: la capătul ei aveam patru decizii de temelie, fiecare cu motivul ei și cu condiția scrisă în care se reia. Dacă preferi varianta audio, subiectul are și un episod de podcast de 19 minute, din seria SAF-T.

Iată cum a decurs, în ordinea în care s-a petrecut.

Am construit ce am descris

Fără nicio abatere de la ce a fost publicat: proiect dedicat, folder local conectat, fișierul de reguli în rădăcină, subfolderele la locul lor.

SAFT-D406\
├─ CLAUDE.md         regulile permanente ale proiectului
├─ MEMORY.md         jurnalul de lucru, scris de asistent
├─ .claude\skills\   procedurile repetabile
├─ surse\            documentele oficiale si materialele de referinta
├─ calibrare\        luna deja depusa si acceptata
├─ app\              codul aplicatiei
└─ rapoarte\         iesirile aplicatiei

Singura adăugire față de structura publicată e MEMORY.md, jurnalul pe care îl scrie asistentul, nu eu. Acolo ajung deciziile luate și motivul respingerii variantei alternative. În articolul precedent l-am descris ca mecanism. De aici înainte e un fișier care se completează singur, conversație după conversație.

În surse\ au intrat schema oficială, registrul de definiții cu cele 55 de file, ghidul ANAF, întrebările și răspunsurile specifice și ambele serii de teste de consistență. calibrare\ aici avem datele pentru o lună deja depusă și acceptată ca să am cu ce compara rezultatul.

Ce scrie în fișierul de reguli

CLAUDE.md e singurul lucru din tot proiectul care se citește la începutul fiecărei conversații. Deci acolo pui ce nu vrei să reexplici niciodată.

L-am ținut sub o pagină și l-am scris în ordinea în care apar întrebările: ce trebuie să facă aplicația, ce nu se negociază, cum lucrăm, ce convenții respectăm și ce nu se face niciodată. Îl las mai jos, fiindcă e mai util citit decât descris.

# SAF-T-D406

Aplicatie locala de verificare a declaratiei D406, construita pas cu pas prin
conversatie. Proiectul va trebui explicat către echipă, deci fiecare
decizie trebuie sa fie explicabila in scris, nu doar sa functioneze.

## Ce trebuie sa faca aplicatia
1. Citeste fisierul XML D406 si exporta sectiunile in tabele.
2. Valideaza, ruland testele de consistenta publicate de ANAF.
3. Reconciliaza datele cu decontul de TVA, D300.
4. Verifica fata de contabilitate: balanta, analitice de clienti si furnizori.
5. Confrunta cu D390 si D394.
Ordinea de mai sus e si ordinea de constructie.

## Cele trei reguli care nu se negociaza
1. Fisierul real nu se incarca in instrumente AI publice. Ce se genereaza cu AI
   e codul. Prelucrarea datelor ramane pe calculatorul acesta.
2. Enuntul testelor se ia din documentul ANAF, nu din memoria modelului. Fiecare
   test citeaza sursa: numele fisierului si numarul testului.
3. Orice verificare se calibreaza pe o luna deja depusa si acceptata. Daca
   rezultatul nu se potriveste cu fisierul real, aplicatia trebuie verificată.

## Guardrail
Daca informatia nu se afla in documentele din surse\, scrie exact:
"Nu rezulta din textele furnizate." Nu completa cu ce pare probabil.

## Cum lucram
- Intai planul, apoi codul. Daca in primele doua raspunsuri apare cod, cererea
  a fost formulata gresit.
- Intrebari inainte de a incepe: 3-5, despre ce a ramas ambiguu.
- Iteratii mici, verificate. V&V, Vibe & Verify.
- Deciziile se scriu, cu motivul respingerii celeilalte variante.

## Conventii
- Ce se schimba in timp nu intra in cod, ci intr-un fisier de configurare extern.
- Fiecare rulare scrie un jurnal. Fara jurnal nu exista pista de audit.
- Fara dependente noi fara discutie.

## Ce nu se face niciodata
- Nu se editeaza XML-ul manual ca sa treaca o verificare.
- Nu se ajusteaza pragurile ca sa iasa rezultatul.

Fișierul e scris fără diacritice, ca tot ce ajunge în folderul de lucru. E convenția pe care am fixat-o în articolul precedent și pe care o respect inclusiv în conținutul fișierelor tehnice, ca să nu am două reguli de ținut minte.

Conversația în care nu se scrie cod

Am lucrat în plan mode și, practic, am purtat cu asistentul o discuție de descoperire. Nu am scris un prompt elaborat. Am povestit contextul, exact cum i l-aș fi povestit unui coleg care preia dosarul.

Trei lucruri de reținut din felul în care a decurs:

• Nu s-a scris niciun fel de cod, și nu pentru că am cerut asta la fiecare mesaj, ci pentru că modul de lucru o garantează. E diferența dintre o rugăminte, care se poate pierde până la al treizecilea mesaj, și o constrângere, care nu are cum.
• Am cerut direcții și clarificări, nu soluții. O direcție vine cu un motiv, o soluție vine de-a gata. Prima se poate contesta, a doua doar se acceptă sau se refuză.
• Promptul a venit la sfârșit, nu la început, și l-a scris asistentul. Asta corectează o așteptare răspândită, aceea că „a lucra cu AI” înseamnă să știi să scrii cereri complicate.

Meritul principal al acestui mod de lucru nu e că oprește codul. E că oprește atașamentul față de cod. Odată ce implementarea există, nimeni nu mai are chef să o arunce, iar discuția despre variante se transformă în discuție despre cum salvăm ce s-a scris deja.

Întrebările la care am căutat răspuns

Le-am pus punctual, după ce dădusem contextul, nu înainte. Ordinea contează: aceleași întrebări, puse pe gol, ar fi primit răspunsuri de manual.

• Ce limbaj de programare folosim? Cu variante la plural, nu cu recomandarea cea mai bună, și cu motivul fiecărei eliminări.
• Cum se scrie interfața? Nu ce tip de soluție, ci ce bibliotecă anume, și de ce ea și nu alta din același limbaj.
• Cum se împachetează aplicația, ca să ajungă la un coleg fără instalări pe stația lui?
• Ce formă vor avea fișierele de export? Și, separat, în ce format rămân datele între rulări, dacă aplicația trebuie să citească tot fișierul înainte de a exporta ceva.
• În ce format iese raportul de rulare, cel care merge la dosarul de lucru, și poate fi el completat dintr-un șablon editabil, fără atingerea codului?
• Ce dintre cerințele mele e greșit? Întrebarea asta a produs cea mai utilă parte a răspunsului.

Fiecare întrebare a cerut argumentul, nu doar concluzia. Argumentul e singurul lucru pe care îl poți verifica peste șase luni, când nu mai ții minte discuția.

Contextul pe care i l-am dat

Fără el, întrebările de mai sus ar fi primit o listă de bune practici generale.

• Documentele oficiale, descărcate de pe site-ul ANAF: schema XSD, registrul de definiții, ghidul contribuabilului, întrebările și răspunsurile specifice, cele două serii de teste. Cu regula că enunțul oricărei reguli se ia din ele, iar schema are întâietate când două documente se contrazic.
• Un eșantion de rezultat, adică un fișier Excel anonimizat care arată cum ar trebui să arate ieșirea finală: câte o filă per secțiune, aplatizată. I-am spus explicit că e model de formă, nu sursă de reguli, și că are imperfecțiuni de găsit.
• Mărimea fișierelor: la unele companii XML-ul depășește 1, 2, 3 GB sau chiar mai mult.
• Numărul de rânduri: unele secțiuni au sute de mii, chiar milioane de rânduri după aplatizare, excel pentru output s-ar putea să nu fie potrivit.
• Echiparea stațiilor: Windows 11, cel mult 8 GB memorie disponibilă.
• Distribuția: aplicația trebuie să se mute ușor de pe un calculator pe altul, fără instalări suplimentare pe stațiile noi, nici de limbaje, nici de programe ajutătoare.
• Utilizatorii: colegi contabili, fără pregătire tehnică, care deschid aplicația câteva zile pe lună și nu au cui cere ajutor când ceva nu merge.
• Confidențialitatea: totul local, fără date luate de pe internet, fișierul și rezultatele rămân pe stație.
• Toată aplicația, nu doar bucata pe care voiam să o construiesc. Pare risipă de context. Nu e: o decizie luată pentru modulul 1 e bună doar dacă nu blochează etapele 2 până la 5, iar asta nu se poate verifica fără să știi ce urmează.

Direcțiile primite

• Python Argumentul obișnuit împotriva Python-ului, viteza, a fost măsurat, nu presupus, și s-a dovedit că nu se aplică unei prelucrări în flux, în care fișierul se citește bucată cu bucată și nu se ține niciodată întreg în memorie.
• PySide6 pentru interfață, singura bibliotecă din Python care rezolvă simultan tabelul de milioane de rânduri și fereastra care rămâne utilizabilă în timpul unei prelucrări de minute. Biblioteca pe care o cunoșteam deja (Streamlit), din uneltele construite în articolele anterioare, a fost eliminată: nu are tabel virtualizat, adică afișarea ei încarcă în memorie toate rândurile, nu doar pe cele vizibile.
• Folder portabil, copiat pe disc sau pe stick și pornit cu dublu clic. Varianta „un singur fișier executabil”, care pare mai curată, a fost respinsă cu motive concrete: pornire lentă, dezarhivare într-un folder temporar la fiecare rulare și, mai ales, semnalări false din partea antivirusului, exact pe genul de stație pe care nu ai cui să te plângi.
• Trei formate produse la fiecare export: Excel ca livrare principală, CSV și Parquet. Formatul nu mai e o alegere a utilizatorului, e o consecință a apăsării butonului.
• O bază de lucru locală între rulări, ca fișierul XML să fie citit exact o dată, iar sinteza și toate exporturile să se construiască din ea. Tot ea e punctul de plecare al etapelor următoare, adică al validărilor și al reconcilierilor.
• Raportul de rulare direct în PDF, fiindcă orice conversie din Word ar presupune un program instalat pe stație, ipoteză pe care un folder portabil nu o poate face. Textele raportului ies într-un fișier de configurare editabil.

Aveam direcțiile. Nu aveam motivele scrise nicăieri, ci împrăștiate într-o conversație lungă. Iar o direcție fără motivul ei se uită exact atunci când cineva propune alta.

Promptul pe care nu l-am scris eu

I-am cerut asistentului să scrie el cererea care transformă discuția noastră într-un raport final de decizii. Nu i-am cerut raportul. I-am cerut instrumentul cu care se produce raportul.

Promptul e produsul conversației, nu punctul ei de plecare. Ordinea cu care suntem obișnuiți se răstoarnă: nu scrii o cerere bună ca să obții un răspuns bun, ci discuți până înțelegi ce ceri, și abia atunci ai cum să scrii cererea. Termenul pentru asta, dacă vă e de folos într-o discuție cu un coleg, e meta-prompt.

Ce a ieșit e un prompt care fixează rolul, adică evaluator, nu consultant care validează, ca antidot direct la tendința asistentului de a-ți da dreptate. Separă faptele despre D406, care se iau exclusiv din documentele oficiale, de analiza tehnică, care e a modelului. Și impune raportului o formă anume: minimum trei opțiuni comparate pentru fiecare decizie, un nivel de certitudine pe fiecare afirmație, o condiție scrisă dinainte în care decizia se reia, o secțiune întreagă rezervată contestării cerințelor mele și una finală care verifică dacă documentele din folderul de surse conțin instrucțiuni adresate asistentului.

Ultima are un nume și merită reținut, fiindcă e o problemă reală, nu o precauție teoretică: prompt injection. Un document pe care îl dai ca sursă poate conține, ascuns în el, text formulat ca instrucțiune. Când sursele sunt PDF-uri oficiale descărcate direct de la ANAF riscul e mic. Obiceiul de a verifica se formează însă acum, nu în ziua în care cineva îți trimite pe mail un fișier de pus în folderul de surse.

Apoi l-am rulat în alte două modele AI, cu aceleași documente. Rezultatele au fost asemănătoare: toate trei au ajuns la Python din același motiv, la Qt pentru interfață, la folderul portabil și la un pas intermediar pe disc între citire și export. Toate trei rapoartele sunt în arhiva descărcabilă.

Înainte să rulați și voi promptul

Promptul din arhivă e scris pentru un caz anume. Dacă îl rulați ca atare, primiți răspunsul meu, nu al vostru.

Recomandarea: îl încărcați într-o conversație nouă, cu instrucțiunea explicită să nu îl ruleze, și îi dați datele voastre completate în locul exemplelor. Copiați șablonul de mai jos ca atare. Singurul lucru pe care îl schimbați sunt câmpurile din paranteze drepte, iar exemplele scrise stins se șterg pe măsură ce le înlocuiți:

Îți încarc un prompt scris pentru alt context.

NU îl executa. Vreau să îl adaptezi la situația mea.

Rescrie, cu datele de mai jos, secțiunile <context>,
<cerinte_functionale>, <cerinte_interfata> și <constrangeri>.
Restul promptului îl păstrezi neatins.

[CE FACE APLICAȚIA]     ex: citește un XML și scoate fiecare secțiune în Excel
[FIȘIERUL DE INTRARE]   ex: XML de 40 MB, unul pe lună
[CÂTE RÂNDURI]          ex: 30.000 pe cea mai mare secțiune
[STAȚIA]                ex: Windows 11, 16 GB memorie
[DREPTURI PE STAȚIE]    ex: fără drepturi de instalare, laptop administrat
[CINE ÎNTREȚINE CODUL]  ex: eu, fără pregătire tehnică
[CINE O FOLOSEȘTE]      ex: patru colegi contabili, două zile pe lună
[UNDE AJUNG DATELE]     ex: totul local, nimic în instrumente AI publice
[CE IESE LA CAPĂT]      ex: un Excel pentru mine, un PDF pentru dosar
[CE NU VREAU]           ex: nicio instalare pe stațiile colegilor

Dacă un câmp a rămas necompletat, sau dacă răspunsul meu e prea
vag ca să scrii o cerință din el, întreabă-mă despre el înainte
să rescrii. Nu presupune și nu completa cu ce pare probabil.

La final dă-mi promptul rescris, integral, în aceeași structură,
și spune-mi ce ai schimbat și de ce.

Ultimele trei rânduri contează la fel de mult ca datele. Fără ele, un câmp lăsat gol se umple singur cu presupunerea cea mai plauzibilă, iar presupunerea intră în cerință fără să o vedeți trecând.

Câteva dintre câmpuri schimbă răspunsul mai mult decât toate celelalte la un loc:

• Mărimea fișierului și numărul de rânduri. Dacă XML-ul vostru are 40 MB, jumătate din raportul meu devine irelevantă: constrângerile de memorie și pragurile de spargere a filelor pică, iar concluzia despre formate se simplifică. Probabil vă ajunge Excel, fără CSV și fără Parquet.
• Drepturile pe stație. Dacă aveți drepturi de administrator și puteți instala ce vreți, constrângerea folderului portabil dispare, iar cu ea și o parte din argumentul pentru un limbaj sau altul.
• Câți oameni o folosesc. Pentru un singur utilizator, cel care a scris-o, dispar jumătate din cerințele de interfață și tot capitolul despre distribuție.
• Unde ajung datele. Dacă firma are un tenant AI propriu sau o politică deja aprobată, regula „fișierul nu părăsește calculatorul” se rescrie, și se deschid soluții pe care eu le-am eliminat din start.
• Ce faceți cu rezultatul. Un fișier pentru voi, un fișier pentru dosarul de lucru și un fișier pentru Power BI sunt trei cerințe diferite, nu una.

Restul promptului, adică regimul surselor, nivelul de certitudine, condiția de răsturnare și secțiunea de obiecții, îl păstrați. Acolo stă valoarea lui, și e independentă de mărimea fișierului vostru.

Resursele descărcabile

Promptul integral și cele trei rapoarte, publicate ca material de lucru, nu ca recomandare tehnică. Raportul final e cel care intră ca punct de plecare pentru specificația tehnică, adică pentru pasul următor.

Ce urmează

Săptămâna viitoare se scrie cod: modulul 1, citirea fișierului XML și transpunerea lui în tabele. Adică exact bucata pe care o promite prima linie din fișierul de reguli, și prima ocazie de a vedea dacă direcțiile de mai sus rezistă la contactul cu un fișier real.

După cea mai lungă conversație din tot proiectul, zero linii de cod. De săptămâna viitoare nu mai e adevărat.