De ce ai nevoie de acest ghid
Folosești deja AI în business. Ai cont la Claude, ChatGPT sau Gemini. Plătești lunar pentru ele. Dar undeva, la fundul stomacului, simți că nu obții tot ce-ai putea obține.
Nu e o senzație neîntemeiată. Diferența între un om care primește rezultate mediocre de la AI și unul care primește rezultate profesionale nu e talentul, nici experiența tehnică. Este vocabularul. Sunt 40-50 de cuvinte-cheie în engleza tehnică pe care, dacă le folosești în comenzile tale, AI-ul îți răspunde cu un alt registru de calitate.
Ghidul acesta îți dă acele cuvinte. Fără burdușeală teoretică, fără jargon inutil. Cu exemple concrete și analogii din viața reală.
Ore în care reformulezi aceeași comandă
Primești un draft, e aproape de ce vrei dar nu chiar, ceri modificări, primești altceva, reîncepi. Cu vocabularul potrivit, prima livrare e cea bună în 80% din cazuri.
Costuri AI duble pentru același output
Fiecare "mai încearcă o dată" costă tokenuri. Fiecare ciclu de revizie consumă din abonament. Comenzile precise reduc consumul cu 30-60%.
Dependență de freelanceri pe care nu-i poți audita
Plătești pe cineva care îți face "ceva tehnic", nu înțelegi ce a livrat, nu poți verifica. Cu vocabularul de aici, poți pune întrebări care arată că știi ce ceri.
Cui se adresează
Antreprenori, manageri, marketeri și oameni de business care folosesc deja AI în muncă, dar simt că rezultatele sunt sub potențialul real. Nu trebuie să fii programator. Trebuie doar să fii curios și să vrei să-ți treci munca digitală la nivelul următor.
Dacă deja vorbești fluent engleză tehnică și ai construit sisteme AI pentru clienți — acest ghid e prea de bază pentru tine. Pentru toți ceilalți: e exact ce-ți trebuie.
Trei moduri de a-l folosi
Ghidul te învață cuvintele. Dacă vrei să le și folosești fără să construiești singur infrastructura, există două produse RoboMarketing care fac exact asta:
robOS
Memorie, workspace-uri și verificare anti-improvizație peste Claude Code. "Don't guess, verify" devine comportament implicit.
Fabrica de Agenți
VPS dedicat cu 4 agenți AI care publică zilnic. Idempotency, rate limiting, secrets management — pre-instalate.
★ Recomandare
Indiferent ce mod alegi, fă două lucruri în primele 15 minute: (1) tipărește cheat sheet-ul și pune-l lângă monitor, (2) memorează cele 5 cuvinte din Top 5. Restul vine cu practica.
Cum să folosești acest ghid
Acest ghid nu se citește o singură dată, de la cap la coadă. Este construit ca o unealtă de lucru: îl deschizi când ai de scris o comandă către un agent AI și nu știi cum s-o formulezi ca să obții ce vrei.
Fiecare capitol acoperă o familie de "cuvinte de aur" — termeni tehnici în engleză care, atunci când îi pui în comanda ta (chiar dacă restul comenzii e în română), îi semnalează agentului AI că vrei un anumit nivel de calitate, rigoare sau tip de gândire.
Pentru fiecare cuvânt vei găsi:
- Ce înseamnă — în două vorbe, în română simplă
- O analogie din viața reală — ca să rămână în memorie
- Când să-l folosești — situații concrete din business
- Comandă slabă vs. comandă cu cuvinte de aur — exemple alăturate
- Capcane — greșeli pe care le fac cei mai mulți
★ Cel mai important sfat
Nu trebuie să memorezi tot ghidul. Memorează doar cele 5 cuvinte din secțiunea "Top 5: Pus pe perete". Restul le cauți când îți trebuie. Ghidul are un cheat sheet la final exact pentru asta.
De ce contează cuvintele
Imaginează-ți că ai angajat un programator extrem de talentat, care a citit tot ce s-a scris vreodată despre programare, business, design și marketing. Singura problemă: nu îți poate citi gândurile.
Dacă îi spui "fă-mi o integrare cu Shopify", va face ceva — probabil ce a văzut că fac alții, pe scurt, fără verificări, fără să se gândească la cazurile în care lucrurile pică. Va merge "așa și-așa".
Dar dacă îi spui "fă-mi o integrare cu Shopify, idempotentă, cu rate limiting, și înainte să zici că ai terminat scrie evals pentru ea" — același programator îți va livra ceva substanțial mai bun. Nu pentru că cuvintele sunt magice. Ci pentru că fiecare cuvânt activează în mintea lui un set de standarde și verificări pe care altfel le-ar fi sărit.
Agenții AI funcționează exact așa. Ei au fost antrenați pe milioane de documente tehnice unde, de exemplu, cuvântul "idempotent" apare mereu lângă proceduri de siguranță, retry logic și protecție împotriva dublurilor. Când îl pui în comanda ta, agentul "trage" cu el toate acele standarde.
Marele secret: limbajul agenților
Aici este vestea bună pentru tine, dacă nu vorbești engleza tehnică: nu trebuie să o vorbești fluent. Trebuie doar să cunoști acești 40-50 de termeni-cheie și să-i strecori printre cuvintele tale românești.
E ca atunci când mergi la un mecanic și nu știi nimic despre mașini, dar spui: "vreau să-mi verifici suspensiile și frânele înainte să-mi dai mașina înapoi". Faptul că ai folosit cuvintele "suspensii" și "frâne" îi spune mecanicului că nu ești complet în ceață și că aștepți o verificare serioasă, nu o reparație de mântuială. La fel funcționează și cu agenții AI.
Acest ghid îți dă vocabularul mecanicului. Nu trebuie să devii mecanic. Trebuie doar să știi ce să ceri.
Anatomia unei comenzi bune
O comandă bună către un agent AI are aproape întotdeauna trei părți:
| Parte | Rol | Exemplu |
|---|---|---|
| 1. CE? | Sarcina concretă | "Construiește integrarea cu Shopify." |
| 2. CUM? | Standardele și constrângerile (aici intră cuvintele de aur) | "Fă-o idempotentă, cu rate limiting și retry exponential backoff." |
| 3. GATA CÂND? | Verificările și acceptance criteria | "Înainte să zici că ai terminat, scrie evals și rulează-le." |
Majoritatea oamenilor scriu numai partea 1: "construiește integrarea cu Shopify". Apoi se miră că rezultatul e dezamăgitor. Cuvintele de aur sunt instrumentul cu care umpli părțile 2 și 3 fără efort.
5 reguli înainte să începi
1. Folosește cuvintele în engleză, chiar dacă scrii în română.
Agenții AI înțeleg termenii tehnici cel mai bine în engleză. Scrie "fă-o idempotentă", nu "fă-o să fie idempotentă în sensul că...". Termenul tehnic e mai precis decât orice traducere.
2. Nu folosi cuvinte pe care nu le înțelegi.
Dacă strecori un termen doar ca să "sune tehnic", și agentul îți pune o întrebare despre el, vei fi pierdut. Folosește doar cuvintele pe care le poți explica în două vorbe.
3. Începe simplu, apoi adaugă rigoare.
Pentru un task mic, nu ai nevoie de toate cele 50 de cuvinte. Folosește 1-3, cele relevante. Pentru un proiect mare, urcă la 5-10.
4. Cere verificare, mereu.
Cea mai bună regulă din tot ghidul: indiferent ce ceri, adaugă la final "don't guess, verify" sau "scrie evals și rulează-le". Asta singură elimină 70% din greșelile agenților.
5. Recitește rezultatul cu ochi critici.
Cuvintele de aur îmbunătățesc rezultatul, dar nu îl fac perfect. Tu rămâi cel care decide dacă ce a livrat agentul e bun pentru afacerea ta.
✓ Verdict înainte de capitolul 1
Dacă ești gata să oprești aici și să încerci doar regulile de mai sus, vei obține deja rezultate considerabil mai bune. Capitolele care urmează îți dau vocabularul concret. Citește-le în ritmul tău.
Calitate și verificare
Aceste cinci cuvinte sunt cele mai importante din tot ghidul. Dacă reții doar atât din acest document, deja te plasezi în top 10% al oamenilor care lucrează cu agenți AI.
Toate sunt despre același lucru: cum forțezi agentul să-și verifice singur munca înainte să ți-o predea. Fără ele, vei primi mereu rezultate "care par bune" până în clipa în care le pui în producție și descoperi că nu sunt.
evals
de la "evaluations" — evaluări
Ce înseamnă: Seturi de teste automate care verifică dacă agentul tău (sau funcționalitatea construită) face cu adevărat ce ar trebui să facă. Sunt ca un "examen scris" pe care îl dai agentului, cu sute de întrebări, și agentul îți raportează câte a luat corect.
Gândește-te la un brutar care vrea să cumpere un cuptor nou. Înainte să-l plătească, vrea să-l testeze: coace 5 pâini la temperaturi diferite, vede dacă crustea iese bine, dacă se face uniform, dacă se strică ceva. Evals sunt cele 5 pâini de probă. Fără ele, brutarul cumpără pe încredere — și află că ceva e greșit abia când are 200 de clienți care așteaptă.
Când să-l folosești
Întotdeauna când construiești ceva nou. Înainte să "dai drumul" oricărei funcționalități noi — fie că e un agent care răspunde clienților, un script care trimite emailuri, o integrare cu Shopify — cere evals. Și mai ales când modifici ceva care merge: evals îți spun dacă modificarea a stricat ceva.
Comandă slabă vs. comandă cu cuvinte de aur
⚠ Capcană frecventă
Mulți cer "fă evals" și se opresc aici. Agentul îți va scrie 3 teste banale care trec toate și-ți va zice că e gata. Specifică câte teste vrei și ce tip de scenarii să acopere (happy path + edge cases — vezi cuvintele din capitolele următoare).
ground truth
literal: "adevărul de la sol" — adevărul de referință
Ce înseamnă: Răspunsul corect, verificat de un om, cu care se compară rezultatul agentului. Dacă evals sunt "examenul", ground truth e "grila de corectare". Fără grilă, nu știi dacă răspunsurile sunt bune sau proaste.
La un examen de matematică, profesorul are o foaie cu răspunsurile corecte. Asta e ground truth. Fără ea, nu poate corecta lucrările elevilor. La fel, fără ground truth, agentul tău nu știe dacă răspunsul lui la întrebarea "câte comenzi am avut ieri?" e corect — știe doar că a dat un răspuns.
Când să-l folosești
Mereu lângă cuvântul "evals". Cere agentului să-și definească ground truth-ul pentru fiecare test. De exemplu: dacă întreabă "câte comenzi am avut ieri?" și ground truth-ul (verificat manual) e 47, agentul știe că răspunsul "vreo 50" e prea vag, iar "23" e clar greșit.
Comandă slabă vs. comandă cu cuvinte de aur
sanity check
literal: "verificare de bun simț"
Ce înseamnă: O verificare rapidă, evidentă, că un rezultat are sens în lumea reală. Nu o verificare profundă — doar "asta poate fi adevărat?". Sanity checks prind greșelile mari, evidente, care altfel ar trece neobservate.
Dacă un copil zice că a alergat 100 de metri în 3 secunde, nu trebuie să fii antrenor olimpic ca să spui "stai, nu se poate". Asta e un sanity check. Dacă agentul tău îți raportează că ai avut 50.000 de comenzi pe Shopify într-o oră (când media e 20/oră), un sanity check ar prinde asta imediat.
Când să-l folosești
Pe orice raport automat, înainte să fie trimis mai departe (la client, pe Slack, în email). Pe orice tranzacție mare. Pe orice modificare în masă (de ex. update preț la 500 de produse).
Comandă slabă vs. comandă cu cuvinte de aur
dry run
literal: "rulare uscată" — rulare în gol, fără efecte reale
Ce înseamnă: Rulezi acțiunea, dar fără să se întâmple efectiv. Agentul îți arată ce ar face, ca să poți verifica înainte să apeși "execută pe bune". E plasa de siguranță cea mai importantă când acțiunea are consecințe (trimite emailuri, modifică prețuri, șterge clienți).
Înainte ca un pilot să decoleze, parcurge un checklist întreg fără să atingă comenzile reale: "verific manete... ok, dar nu mișc... verific flapsuri... ok, dar nu mișc". E dry run. Apoi, mulțumit că totul e pregătit, începe să facă acțiunile reale. La fel, înainte să trimită 5.000 de emailuri către clienții tăi, vrei să vezi lista celor 5.000 fără să fie trimise.
Când să-l folosești
Obligatoriu pentru: trimitere mass-email, modificări de preț în masă, ștergere de date, sincronizări mari între sisteme, orice fel de operație în lot. Recomandat pentru: scripturi noi pe care le rulezi prima dată.
Comandă slabă vs. comandă cu cuvinte de aur
★ Sfat
Combină dry run cu sanity check. Dry run îți arată ce s-ar întâmpla, sanity check verifică dacă are sens. Împreună, sunt aproape imposibil de păcălit.
smoke test
literal: "testul fumului" — vine din electronică
Ce înseamnă: Cel mai mic test posibil care confirmă că sistemul nu e complet rupt. Numele vine de la inginerii care, după ce reparau un aparat, îl porneau pentru prima dată ținându-se la distanță: dacă scotea fum, era clar că ceva fundamental nu mergea.
Când îți pornești mașina dimineața, înainte să pleci în vacanță cu copiii, asculți motorul 5 secunde. Dacă auzi un zgomot ciudat, te oprești și verifici. Dacă merge normal, pleci. Nu faci o revizie completă în fiecare dimineață — doar acel scurt smoke test. La fel, după orice modificare la sistemul tău, rulează 2-3 acțiuni-cheie ca să confirmi că nimic fundamental nu e rupt.
Când să-l folosești
După fiecare schimbare, oricât de mică. După update de versiune. După modificarea unui token. După rebranding. După mutare de servere. Smoke test = singura siguranță că modificarea nu a omorât ceva critic.
Comandă slabă vs. comandă cu cuvinte de aur
Recapitulare capitolul 1
| Cuvânt | În două vorbe | Când |
|---|---|---|
| evals | Teste automate care verifică agentul | Mereu, când construiești sau modifici |
| ground truth | Răspunsul corect cu care se compară | În fiecare eval |
| sanity check | Verificare rapidă "asta are sens?" | Rapoarte, tranzacții, update-uri |
| dry run | Rulare în gol, fără efecte reale | Mass-email, ștergeri, modificări mari |
| smoke test | Test minim "nimic nu e rupt" | După orice schimbare |
◆ Comanda combinată pe care o poți copia
"Construiește [X]. Înainte să zici că e gata: scrie evals cu happy path și edge cases, definește ground truth pentru fiecare test, adaugă sanity checks pe numerele cheie, fă dry run dacă acțiunea are efecte reale, și rulează un smoke test la final."
"evals", "ground truth", "sanity check" — făcute automat
Dacă folosești deja Claude Code, există un produs care exact asta face: verifică afirmațiile înainte să scrie, te oprește dacă vrei să închizi sesiunea fără să salvezi, ține un audit al deciziilor. Toate cuvintele din acest capitol — instalate cu o comandă.
Vezi robOS →Cum gândește agentul
Cuvintele din acest capitol nu cer agentului să facă ceva diferit, ci să gândească diferit înainte să facă. Diferența între un agent care aruncă cu prima soluție care-i vine în minte și unul care chiar se gândește.
think step by step
literal: "gândește pas cu pas"
Ce înseamnă: Spui agentului să-și descompună gândirea în pași explicați, în loc să "sară" la răspuns. Pare banal, dar e una dintre cele mai studiate tehnici din lumea AI: agenții fac considerabil mai puține greșeli când sunt forțați să gândească pas cu pas.
La școală, când profesorul îți cerea să rezolvi o problemă de matematică, îți spunea: "arată-mi pașii, nu doar răspunsul". Nu pentru că pașii erau interesanți, ci pentru că scrierea pașilor te forța să gândești corect. Dacă scriai doar răspunsul, ghiceai. Agenții AI au aceeași slăbiciune și aceeași soluție.
Când să-l folosești
În orice cerere care implică o decizie complexă, un calcul, o comparație, sau analiza unei situații. Nu pentru sarcini simple ("trimite emailul X"), unde doar adaugă zgomot.
first principles
literal: "din primele principii" — de la bază, nu din analogii
Ce înseamnă: Pornește de la bazele fundamentale ale problemei, nu de la "cum se face de obicei". E opusul gândirii prin imitație. Cere agentului să nu copieze pur și simplu ce a văzut în alte proiecte, ci să se întrebe "de ce e nevoie cu adevărat aici?"
Toată lumea construia rachete refolosind designul vechi al NASA. Cineva s-a întrebat din first principles: "de ce e o rachetă scumpă? Din ce e făcută? Cât costă materialele brute?" A descoperit că materialele costau 2% din preț, restul era manopera și pierderea rachetei după lansare. Așa a apărut ideea de rachete refolosibile. Aceeași gândire poate descoperi soluții simple la probleme aparent complicate în business.
Când să-l folosești
Când suspectezi că agentul îți va da o soluție "standard" care nu se potrivește cazului tău. Sau când vrei să optimizezi costuri / procese și restul lumii face "așa pentru că așa s-a făcut mereu".
chain of thought
literal: "lanțul gândirii" — fluxul complet al raționamentului
Ce înseamnă: Variantă mai detaliată decât "think step by step". Ceri nu doar pașii, ci raționamentul complet — de ce ai ales pasul A în loc de B, ce ai considerat și ai respins, ce presupuneri ai făcut. Folosit corect, îți permite să "auditezi" gândirea agentului și să prinzi raționamente greșite.
Diferența între un consultant care îți zice "recomand să investiți în campanii Meta" și unul care îți zice "am analizat 3 opțiuni: Meta, Google și TikTok. Am ales Meta pentru că publicul vostru target are 35-55 ani (70% sunt acolo), bugetul este mic (Meta merge bine sub 1000 EUR/lună), iar voi aveți deja conținut visual de calitate." A doua e chain of thought. Poți să-l contrazici dacă vezi o greșeală. Pe primul nu ai cum.
Când să-l folosești
Pentru decizii strategice. Pentru cazurile când agentul îți dă o recomandare și tu vrei să înțelegi pe ce se bazează, nu doar care e răspunsul.
red team
termen militar: "echipa roșie" care simulează atacul inamic
Ce înseamnă: Ceri agentului să-și atace propria soluție. Să se pună în pielea unui critic, hacker, sau client nemulțumit și să găsească toate modurile în care soluția ar putea pica. E exact opusul a ceea ce un agent face natural (justifică ce a livrat).
În armată, când plănuiesc o misiune, fac doi colectivi: unul plănuiește atacul ("echipa albastră"), celălalt joacă rolul inamicului care încearcă să-l oprească ("echipa roșie"). Așa descoperă punctele slabe înainte să devină victime. La fel, după ce agentul îți construiește o soluție, pune-l pe el însuși să joace rolul de "client care vrea s-o spargă".
Când să-l folosești
Pe soluții critice (procese cu bani, securitate, comunicare cu clienții). Pe cod nou înainte să intre în producție. Pe planuri de campanie înainte să le aprobi. Pe orice livrare care, dacă pică, te costă scump.
steel-man
opusul lui "straw-man" — construiește cea mai puternică versiune a argumentului opus
Ce înseamnă: Înainte să iei o decizie, ceri agentului să construiască cel mai bun argument împotriva a ceea ce vrei tu să faci. Nu o caricatură a opoziției, ci versiunea cea mai inteligentă, cea mai serioasă. Doar așa știi dacă decizia ta rezistă cu adevărat sau e doar entuziasm.
Înainte să cumperi o casă pe care o iubești, întreabă un prieten deștept să-ți spună cele mai bune motive să NU o cumperi — nu glume, nu critică superficială, ci adevăratele riscuri pe care el le vede. Dacă reziști la steel-man-ul lui, decizia ta e solidă. Dacă te clătină, ai aflat ceva important înainte să-ți dai banii.
Când să-l folosești
Pe decizii mari: lansare produs nou, schimbare de strategie, semnare contract important, angajare. Steel-man te protejează de propriul entuziasm.
Recapitulare capitolul 2
| Cuvânt | În două vorbe | Când |
|---|---|---|
| think step by step | Forțează pașii explicați | Decizii complexe, calcule |
| first principles | De la bază, nu copiere | Optimizări, soluții non-standard |
| chain of thought | Raționamentul complet, auditabil | Decizii strategice, recomandări |
| red team | Atacă-ți propria soluție | Înainte de lansare în producție |
| steel-man | Cel mai bun argument împotriva | Decizii mari |
Anti-ghicit: forțează rigoarea
Cea mai mare problemă a agenților AI nu e că nu știu lucruri — ci că nu știu că nu știu. Cuvintele din acest capitol sunt instrumentele cu care îi forțezi să recunoască incertitudinea și să verifice înainte să afirme.
don't guess, verify
literal: "nu ghici, verifică"
Ce înseamnă: Probabil cea mai puternică instrucțiune din tot acest ghid. Îi spui explicit agentului: nu inventa. Dacă nu știi sigur, caută, întreabă, verifică în documente. Mai bine recunoști că nu știi decât să spui un lucru greșit cu siguranță.
Diferența între un medic bun și unul prost: medicul prost îți spune un diagnostic pe loc, ca să pară sigur pe el. Medicul bun zice "sunt 3 posibilități; trebuie să facem aceste analize ca să fim siguri". Vrei ca agentul tău AI să fie medicul al doilea, nu primul. "Don't guess, verify" e exact comanda care îl transformă din unul în celălalt.
Când să-l folosești
Aproape întotdeauna. Adaugă la sfârșitul oricărei comenzi care implică fapte, date concrete, sau acțiuni cu consecințe. Costă două cuvinte și elimină probabil 50% din "halucinațiile" agentului.
⚠ Adevărul incomod
Agenții AI sunt antrenați să pară de ajutor. Asta înseamnă că, dacă nu cunosc un răspuns, vor inventa unul plauzibil în loc să spună "nu știu". "Don't guess, verify" e antidotul direct.
cite your sources
literal: "citează-ți sursele"
Ce înseamnă: Pentru fiecare afirmație factuală, ceri sursa concretă. Un link, un nume de fișier, un document, o secțiune din documentație. Forțează agentul să-și bazeze răspunsurile pe ceva verificabil, nu pe ce-i sună bine.
În școală, când scriai o lucrare, profesorul îți cerea bibliografie. Nu pentru că-l interesa lista cărților, ci pentru că simpla obligație de a cita te forța să nu inventezi fapte. La fel cu agenții AI.
Când să-l folosești
Pe cercetări, comparații tehnice, recomandări de furnizori, statistici, orice afirmație de tipul "X% din clienți...", "studiile arată că...", "best practice e să...".
show your work
literal: "arată-mi calculele/lucrul tău"
Ce înseamnă: Pentru orice calcul, decizie, sau rezultat, vrei să vezi cum a ajuns acolo, nu doar răspunsul final. Diferit de "chain of thought" — acela e pentru raționamente complete; "show your work" e mai punctual, pentru pași concreți, calcule, formule.
Când contabilul îți dă cifra finală a profitului, vrei să vezi cum a ajuns acolo: ce venituri, ce costuri, ce taxe. Dacă-ți dă doar cifra, nu o poți verifica. La fel cu agentul: dacă-ți zice "campania a generat 47.000 RON", vrei să vezi de unde rezultă 47.000 — câte vânzări, prin ce canale, pe ce perioadă.
Când să-l folosești
Pe rapoarte cu cifre. Pe decizii bazate pe calcule. Pe orice rezultat care va influența o acțiune importantă. Nu pe sarcini creative sau conversaționale.
acceptance criteria
literal: "criterii de acceptare" — ce trebuie să fie adevărat ca taskul să fie considerat finalizat
Ce înseamnă: Înainte ca agentul să înceapă, definește împreună cu el o listă concretă de condiții care, dacă sunt toate îndeplinite, taskul e gata. E ca un contract: "dacă faci A, B și C — am terminat. Dacă nu — nu."
Când angajezi un zugrav, contractul nu spune "zugrăvește bine". Spune lucruri concrete: "două straturi de vopsea, suprafețele să fie netede, fără pete, colțurile drepte". Astea sunt acceptance criteria. Fără ele, "bine" înseamnă orice. Cu ele, ai bază să zici "stai, n-ai terminat încă".
Când să-l folosești
La începutul fiecărei sarcini netriviale. Cere agentului să-ți propună acceptance criteria, le confirmi tu, apoi îi dai drumul. Asta singură elimină 80% din situațiile "credeam că ai vrut altceva".
definition of done
literal: "definiția lui «gata»"
Ce înseamnă: Variantă mai strictă decât acceptance criteria. Definiția unui standard universal de calitate pe care orice livrare trebuie să-l atingă înainte de a fi declarată "gata". Acceptance criteria sunt specifice taskului; definition of done se aplică la tot ce livrezi.
În restaurantele bune, înainte ca orice farfurie să iasă din bucătărie, chef-ul o verifică: temperatură corectă, prezentare curată, ingrediente proaspete. Asta e definition of done pentru tot ce iese din bucătărie. Nu contează dacă e ciorbă sau friptură — toate trec prin acest filtru.
Exemplu de definition of done
- ✓ Toate testele (evals) trec
- ✓ Codul e comentat în zonele complexe
- ✓ Există documentație pentru utilizator
- ✓ S-a făcut sanity check pe rezultate
- ✓ S-a făcut un smoke test
- ✓ Erorile sunt logate (observability)
- ✓ Token-urile sunt în secrets, nu în cod
- ✓ Pot reproduce rezultatul cu aceleași inputuri (idempotent)
★ Sfat
Tipărește definition of done-ul tău și pune-l undeva vizibil. Apoi, la fiecare comandă majoră către agent, scrie pur și simplu: "respectă definition of done-ul standard". Agentul va parcurge fiecare punct.
Recapitulare capitolul 3
| Cuvânt | În două vorbe | Când |
|---|---|---|
| don't guess, verify | Nu inventa — caută, verifică | Aproape mereu |
| cite your sources | Surse pentru fiecare afirmație | Cercetări, statistici, "best practices" |
| show your work | Arată calculele, nu doar rezultatul | Rapoarte cu cifre, decizii numerice |
| acceptance criteria | Lista de condiții ca taskul să fie gata | La începutul fiecărei sarcini |
| definition of done | Standard universal pentru toate livrările | Definit o dată, aplicat mereu |
"Don't guess, verify" — aplicat continuu, fără să-l mai scrii
Cea mai puternică instrucțiune din ghid devine inutilă dacă trebuie să o repeți la fiecare comandă. Există un produs construit exact pe această filosofie: spune "nu știu" în loc să inventeze, ține jurnal de decizii pe care le poți audita peste 6 luni, refuză să improvizeze când nu are bază.
Vezi robOS →Cod și arhitectură
Aici intrăm pe teritoriul "construcției" — cum e construit ce-ți livrează agentul, ca să fie solid și să nu se rupă peste 3 luni. Aceste cuvinte nu sunt doar pentru programatori. Cu ele, chiar dacă nu vezi codul, poți pretinde ca el să respecte standarde de calitate.
separation of concerns
literal: "separarea preocupărilor" — fiecare bucată face un singur lucru
Ce înseamnă: Codul tău nu trebuie să fie un "ghemotoc" în care totul depinde de tot. Fiecare bucată ar trebui să aibă o singură responsabilitate clară. Bucata care trimite emailuri să nu fie aceeași cu cea care calculează reduceri.
Într-o bucătărie bună, există stații separate: una pentru tăiat, una pentru pregătit sosurile, una pentru gătit. Dacă vine un comandant nou și vrea să schimbe sosul, modifică doar stația sosurilor — nu se atinge de cuțitele pentru tăiat. La fel, dacă vrei să schimbi cum trimiți emailurile, nu trebuie să umbli prin codul care calculează reducerile.
single source of truth
prescurtat SSOT — "o singură sursă a adevărului"
Ce înseamnă: Pentru orice informație importantă, există un singur loc unde "trăiește". Dacă vrei să o modifici, o schimbi într-un singur loc și restul sistemului se actualizează singur. Opusul e haosul: același preț scris în 5 locuri.
În birou, dacă fiecare angajat ține propria sa listă de prețuri, în două săptămâni ai 5 liste diferite și clienții primesc 5 oferte diferite. Dacă există o singură listă oficială, toată lumea se uită la ea. Asta e single source of truth.
idempotent
termen matematic: "operație care, repetată, dă același rezultat"
Ce înseamnă: O acțiune e idempotentă dacă poți să o rulezi de 10 ori și rezultatul e același ca după prima rulare. Crucial pentru orice acțiune cu consecințe (trimitere emailuri, plăți, modificări de stoc) — pentru că, în lumea reală, ceva tot se va rula de două ori din greșeală.
Apăsarea butonului "Etajul 5" în lift e idempotentă. Dacă o apeși de 10 ori, liftul tot la etajul 5 te duce, nu la 50. Apăsarea butonului "Comandă acum" pe un site nu e idempotentă — dacă clientul apasă de 3 ori, primește 3 comenzi și 3 facturi. Vrei ca acțiunile sistemului tău să se comporte ca butonul liftului, nu ca butonul "Comandă".
Când să-l folosești
Mereu. Pentru orice integrare. Orice script care trimite emailuri. Orice sincronizare. Orice acțiune declanșată de un webhook.
★ Top 3 motive pentru care "idempotent" îți salvează business-ul
1. Webhook-urile de la Shopify uneori se trimit de 2-3 ori (e prevăzut în documentație).
2. Dacă scriptul tău pică la jumătate, vei vrea să-l rulezi din nou — și să nu trimită din nou ce a trimis deja.
3. Clienții fac click pe butoane de 2-3 ori. Idempotența îi salvează de duplicate.
observability
literal: "observabilitate" — poți vedea ce face sistemul când rulează
Ce înseamnă: Sistemul tău "vorbește" despre ce face — prin loguri, metrici, alertări — astfel încât atunci când ceva pică să poți investiga rapid. Fără observability, un sistem care nu mai merge e o cutie neagră.
Mașina ta are observability: tahometru, indicator de combustibil, lumini "check engine", senzor de presiune anvelope. Dacă pică ceva, vezi imediat ce. Imaginează-ți o mașină fără bord — ai doar volanul. Asta sunt sistemele fără observability. Mergi până se oprește brusc, fără să știi de ce.
fail loudly vs fail gracefully
"să picaie zgomotos" vs "să picaie cu eleganță"
Ce înseamnă: Două filosofii complementare. Fail loudly — în mediul de dezvoltare, vrei ca erorile să fie evidente, ca să le repari. Fail gracefully — în producție, vrei ca erorile să fie "absorbite" elegant (mesaj prietenos, retry automat, fallback), ca să nu strice experiența clientului.
Când înveți să gătești, vrei ca soțul/soția să-ți zică direct "sarea e prea multă" — fail loudly. Așa înveți. Când servești invitați, vrei ca ei să găsească politicos felia mai bună de carne dacă una e prea sărată, fără să o anunțe la masă. Fail gracefully. Sistemele tale au nevoie de ambele, în momente diferite.
DRY
acronim: "Don't Repeat Yourself" — nu te repeta
Ce înseamnă: Dacă observi că aceeași logică / cod / configurare apare în 3-4 locuri, e timpul să o centralizezi într-un singur loc. Repetiția duce la bug-uri: schimbi într-un loc, uiți în altul, sistemul devine inconsistent.
Dacă scrii adresa firmei tale separat pe fiecare factură, contract, broșură, website — când te muți, ai 50 de locuri de actualizat și sigur uiți unul. Mai bine ai o singură "sursă oficială", restul citește de acolo.
YAGNI
acronim: "You Aren't Gonna Need It" — n-ai să ai nevoie
Ce înseamnă: Antidotul împotriva tendinței de a construi feature-uri "pentru viitor". Construiește doar ce ai nevoie acum. Restul îl adaugi când chiar îți trebuie.
Când îți cumperi o casă, nu construiești 6 dormitoare pentru că "poate cândva o să avem 4 copii și 2 bone". Construiești dormitoarele de care ai nevoie acum. La fel cu agenții AI: fără YAGNI, vei avea un sistem cu 30 de feature-uri din care folosești 5.
Recapitulare capitolul 4
| Cuvânt | În două vorbe | Când |
|---|---|---|
| separation of concerns | Fiecare bucată, un lucru | Proiecte mai mari |
| single source of truth | Un loc per informație | Token-uri, configurări |
| idempotent | Rulare repetată = OK | Integrări, webhooks, plăți |
| observability | Loguri, metrici, alerte | Tot ce rulează în producție |
| fail loudly / gracefully | Zgomot în dev, eleganță în prod | Error handling |
| DRY | Nu te repeta | Refactor, review-uri |
| YAGNI | Doar ce-ți trebuie acum | Anti-over-engineering |
Integrări
(Shopify, Klaviyo, WhatsApp)
Aproape orice business modern depinde de "integrări" — bucățile de cod care leagă două sisteme externe. Integrările sunt cel mai fragil tip de cod din lume. Cuvintele de aici sunt instrumentele cu care construiești integrări care nu pică la prima furtună.
rate limiting
literal: "limitarea ratei" — limitezi câte cereri trimiți pe secundă
Ce înseamnă: Fiecare API extern (Shopify, Klaviyo, WhatsApp) are o limită clară: "nu poți trimite mai mult de X cereri pe secundă". Dacă depășești, te blochează. Rate limiting e codul care se asigură că nu depășești limita.
Pe autostradă există limita de viteză. Poți merge mai repede, dar te amendează poliția. La fel, Shopify zice "40 cereri pe secundă, maxim". Dacă scriptul tău trimite 100 într-o secundă, Shopify te "amendează" — blochează cererile. Rate limiting e ca un cruise control care te ține mereu sub limită.
Când să-l folosești
În orice integrare. Necunoașterea acestui lucru e una dintre cauzele principale ale "scripturilor care merg perfect 30 de zile și apoi se rup brusc".
retry with exponential backoff
literal: "reîncearcă cu retragere exponențială" — așteaptă din ce în ce mai mult
Ce înseamnă: Când o cerere pică, nu te dai bătut imediat. Reîncearcă — dar cu o pauză din ce în ce mai mare. Prima oară aștepți 1 secundă, a doua oară 2, a treia 4, a patra 8. Asta dă timp serverului celuilalt să "respire".
Suni la un prieten. Nu răspunde. Dacă suni înapoi imediat, apoi iar imediat, apoi iar — îl enervezi și te blochează. Dacă suni o dată acum, peste 5 minute, peste 15 minute, peste 1 oră — e civilizat, și va răspunde. La fel se comportă serverele cu retry-urile.
★ Sfat
Setează un "ceiling" la backoff (60 sau 120 de secunde). Altfel a 10-a încercare ar fi peste ~17 minute, ceea ce de obicei nu mai are sens.
webhook vs polling
"ești anunțat când se întâmplă ceva" vs. "întrebi în mod repetat"
Ce înseamnă: Două moduri opuse de a afla când s-a întâmplat ceva într-un sistem extern. Polling: îți întrebi sistemul la fiecare 5 minute. De 99% din ori, răspunsul e nu. Risipă. Webhook: sistemul te anunță automat când se întâmplă ceva. Eficient, în timp real.
Polling = să suni la curier o dată pe oră "a sosit coletul?". Webhook = să las curierul să te sune când e la ușă. Care e mai bună? Evident.
idempotency key
literal: "cheia idempotenței" — un cod unic per cerere
Ce înseamnă: Un cod unic pe care îl trimiți cu fiecare cerere importantă (plată, comandă, email). Dacă din greșeală trimiți aceeași cerere de 2 ori, serverul vede aceeași idempotency key și înțelege "duplicare, am procesat-o deja" — și nu o procesează din nou.
Când plătești cu cardul, fiecare tranzacție are un cod unic. Dacă plătești din greșeală de 2 ori cu același cod, banca refuză a doua oară. Asta e idempotency key. Fără ea, dublurile sunt inevitabile.
pagination
literal: "paginare" — iei datele în pagini, nu pe toate odată
Ce înseamnă: Când ai 10.000 de comenzi în Shopify, nu poți cere toate 10.000 deodată — serverul refuză sau, mai rău, îți dă doar primele 50 și pierzi restul fără să-ți dai seama. Pagination = iei comenzile în "pagini" și parcurgi toate paginile.
Imaginează-ți o carte cu 1.000 de pagini. N-o citești toată odată — o parcurgi pagină cu pagină. Dacă cineva îți cere conținutul cărții și tu arunci doar primele 5 pagini cu "asta e tot", pierzi 995 de pagini. Asta pățesc scripturile fără pagination.
Recapitulare capitolul 5
| Cuvânt | În două vorbe | Când |
|---|---|---|
| rate limiting | Stai sub limita API-ului | Orice integrare |
| retry with exponential backoff | Reîncearcă cu pauze tot mai mari | Orice apel către API extern |
| webhook vs polling | Fii anunțat, nu întreba mereu | Notificări externe |
| idempotency key | Cod unic ca să eviți duplicarea | Plăți, comenzi, acțiuni cu efecte |
| pagination | Iei datele în pagini | Sincronizări masive |
★ Comanda master pentru orice integrare
"Construiește integrarea cu [X]. Aplică: rate limiting conform limitelor oficiale, retry with exponential backoff (max 5), idempotency key per cerere, pagination pentru date masive, webhooks în loc de polling când e posibil. Adaugă observability completă. Scrie evals."
O singură propoziție = o integrare profesională.
Rate limiting, retry, observability — pre-instalate
Toate aceste pattern-uri sunt deja construite și pornite pe un VPS la finalul cursului. Nu plănuiești o lună arhitectura, nu cauți biblioteci, nu debuggezi rate limits — totul rulează din ziua 1. 4 agenți AI live, panou de control vizual, monitorizare 24/7. Pleci cu sistemul, nu cu o listă de tutoriale.
Vezi Fabrica de Agenți →Securitate pentru business
Securitate înseamnă tot ce poate să se transforme dintr-un detaliu tehnic mărunt într-un dezastru juridic, financiar sau de reputație. Aceste 4 cuvinte sunt minimul pe care orice business care lucrează cu date de clienți trebuie să-l ceară.
least privilege
literal: "privilegiu minim" — fiecare are exact ce-i trebuie
Ce înseamnă: Când dai unui token sau utilizator acces — îi dai doar acele permisiuni de care are nevoie. Nu mai mult. Dacă scriptul tău doar citește comenzi din Shopify, token-ul lui nu trebuie să aibă permisiunea de a șterge comenzi.
Când angajezi o femeie de serviciu, îi dai cheia de la birou. Nu îi dai și cheia de la seif, accesul la conturile bancare și parola de wifi de acasă. Are ce-i trebuie pentru muncă, nimic în plus. Dacă cineva îi fură cheia, paguba e limitată. Asta e least privilege.
secrets management
literal: "managementul secretelor"
Ce înseamnă: Token-urile API, parolele, cheile private — toate sunt "secrete". Niciodată nu sunt scrise direct în cod, niciodată nu sunt trimise pe email, niciodată nu sunt comise în Git. Stau într-un loc dedicat (variabile de mediu, vault).
Cheia de la seif nu o lași pe biroul de la recepție. Și nici nu o tipărești pe broșura companiei "pentru transparență". Stă într-un loc dedicat, cu acces limitat, înregistrat. La fel cu token-urile API: ele sunt cheile de la business-ul tău digital.
⚠ Test rapid
Întreabă agentul: "Dacă cineva ar avea acces la repo-ul nostru de cod, ar putea să fure token-urile?". Dacă răspunsul e da, ai o problemă urgentă.
PII
acronim: "Personally Identifiable Information" — date personale identificabile
Ce înseamnă: Orice informație care permite să identifici o persoană reală: nume, email, telefon, adresă, CNP, IP, fotografie. În UE (deci și România), PII e protejată prin GDPR — există obligații legale stricte despre cum o stochezi, cine are acces, cât timp o păstrezi.
Datele clienților tăi sunt ca actele lor de identitate. Dacă i-ai lăsa să-și pună buletinul pe biroul tău, nu l-ai photocopia, nu l-ai trimite pe WhatsApp către prieteni, nu l-ai pune în vitrina magazinului. Aceeași rigoare se aplică datelor digitale.
audit log
literal: "jurnal de audit" — cine a făcut ce și când
Ce înseamnă: Jurnal cu toate acțiunile importante: cine le-a făcut, când, asupra cui, ce s-a schimbat. Diferit de log-urile tehnice — audit log-ul arată activitatea (cine a șters un client, cine a modificat un preț).
În contabilitate, fiecare modificare se înregistrează: cine a făcut corectarea, când, de ce. Dacă peste 6 luni cineva întreabă "de ce e cifra asta așa?", poți reconstrui istoria. Fără audit log, orice problemă rămâne nerezolvată.
Recapitulare capitolul 6
| Cuvânt | În două vorbe | Când |
|---|---|---|
| least privilege | Doar permisiunile strict necesare | Fiecare token nou |
| secrets management | Token-uri în secrets, NU în cod | Mereu — fără excepție |
| PII | Date personale — GDPR | Orice proiect cu date de clienți |
| audit log | Jurnal: cine, ce, când | Modificări ireversibile |
Secrets management, audit log, VPN — de la ziua 0
Cele 4 cuvinte din acest capitol sunt diferența între un sistem AI care îți crește business-ul și unul care îl pune în pericol. Pe VPS-ul construit la Fabrica de Agenți, vault-ul pentru token-uri, accesul prin VPN criptat, audit log-ul și separația de privilegii sunt configurate înainte ca tu să te conectezi prima dată. Securitatea nu se "adaugă mai târziu".
Vezi Fabrica de Agenți →Produs și decizii
Ultimul capitol e diferit: aici nu vorbim despre cum să construiești, ci despre ce să construiești. Cuvintele te ajută să faci alegeri mai bune și să-l ghidezi pe agent să nu construiască lucruri care nu trebuie construite.
MVP
acronim: "Minimum Viable Product" — produsul minim viabil
Ce înseamnă: Cea mai simplă versiune posibilă care încă rezolvă problema reală. Nu cea mai bună — cea minimă, dar funcțională. Construiești MVP-ul în 2 săptămâni, îl testezi cu utilizatori reali, înveți, apoi îl îmbunătățești.
Vrei să vezi dacă oamenilor le-ar plăcea o tartă cu trufe. Două opțiuni: (A) Investești 5.000 EUR în echipamente, cumperi trufe scumpe, închiriezi spațiu, deschizi cofetărie peste 3 luni. (B) Faci 5 tarte mâine, le scoți la o piață de weekend, ceri 30 RON. Dacă le cumpără lumea — investește. Dacă nu — ai pierdut 50 RON. B este MVP.
happy path first
literal: "calea fericită întâi" — construiește mai întâi cazul ideal
Ce înseamnă: Când construiești ceva, începe cu cazul în care totul merge perfect. Abia după ce funcționează happy path-ul, începi să tratezi edge cases (clientul renunță la mijloc, plata e refuzată, internetul pică).
Când construiești o casă, întâi pui zidurile drepte și acoperișul. Apoi te gândești "dar dacă vine cutremur de 7?" și adaugi sistem antiseismic. Nu construiești fundația antiseismică pentru o casă care încă nu există.
north star metric
literal: "metrica stelei polare" — singura metrică care contează cu adevărat
Ce înseamnă: Singura metrică despre care echipa ta nu va face compromisuri. Dacă ai 50 de metrici pe dashboard, în practică nu te concentrezi pe niciuna. North star e cea unică pe care, dacă crește, business-ul tău e sigur că merge bine.
Pentru un magazin online de produse de gospodărie, "vânzări lunare" pare north star. Dar poate că adevăratul north star e "clienți care cumpără a doua oară în 90 de zile" — pentru că reflectă calitatea, nu doar cantitatea.
feedback loop
literal: "bucla de feedback" — cât de repede afli dacă a mers
Ce înseamnă: Cât timp trece între momentul în care faci o acțiune și momentul în care afli rezultatul. Feedback loops scurte = înveți rapid, corectezi rapid. Feedback loops lungi = lucrezi în orb.
Când înveți să gătești, ai un feedback loop de 30 de minute (gătești, guști, ajustezi). Când înveți să faci vin, ai feedback loop de un an. De-asta cei mai mulți gătesc bine și foarte puțini fac vin bun. Vrei feedback loops scurte: lansează rapid, măsoară rapid, ajustează rapid.
Recapitulare capitolul 7
| Cuvânt | În două vorbe | Când |
|---|---|---|
| MVP | Versiunea minimă care rezolvă problema | Început de proiect nou |
| happy path first | Cazul ideal întâi, edge cases după | Începutul oricărei construcții |
| north star metric | Singura metrică care contează | Dashboard-uri, strategie |
| feedback loop | Viteza cu care afli dacă a mers | Lansări, experimente |
Top 5: de pus pe perete
Dacă din tot ghidul reții doar 5 cuvinte, alege-le pe acestea. Le-am selectat după un singur criteriu: impactul per cuvânt.
Recomandare: tipărește pagina asta și pune-o lângă monitor. În primele 2 săptămâni, te uiți la ea înainte de fiecare comandă lungă. După 2 săptămâni, devine reflex.
don't guess, verify
Eradică ghicitul
Adăugat la sfârșitul oricărei comenzi factuale, elimină ~50% din "halucinațiile" agentului. Costă 3 cuvinte, salvează ore de verificări manuale.
evals
Eradică "sper că merge"
Forțează agentul să-și verifice singur munca înainte să zică "gata". Cu evals, găsești bug-urile la livrare. Fără evals, le găsesc clienții.
idempotent
Eradică dublurile
Comenzi duplicate, emailuri trimise de 2 ori, plăți încasate dublu — toate vin din funcții ne-idempotente. Un cuvânt te scapă de un an de reclamații.
acceptance criteria
Eradică "credeam că ai vrut altceva"
Definite la început, te scapă de 80% din situațiile când agentul livrează lângă subiect. E contractul scris cu agentul.
observability
Eradică debugging-ul orb
Când ceva pică (și va pica), observability îți spune de ce în 5 minute, nu în 5 zile. Diferența între "panică" și "calm operativ".
★ Cum le folosești împreună
O singură comandă care le combină pe toate cinci:
"Construiește [X]. Definește-mi întâi acceptance criteria — îmi confirmi, apoi treci la treabă. Fă-l idempotent. Adaugă observability. Scrie evals. Don't guess, verify — caută în documentația oficială dacă nu ești sigur."
O propoziție = produsul tău, livrat cum trebuie.
Template-uri de comenzi
Aceste template-uri sunt scrise în română, cu cuvintele de aur strecurate în engleză. Le poți copia direct și înlocui doar bucățile [între paranteze].
Template 01 — Construire integrare nouă
Când conectezi două sisteme (Shopify ↔ Klaviyo, etc.)
- separation of concerns: componente independente pentru fiecare sistem
- idempotent: rulare repetată = același rezultat
- rate limiting conform documentației oficiale a fiecărui API
- retry with exponential backoff (max 5 încercări)
- idempotency key per cerere
- pagination pentru date masive
- webhooks în loc de polling unde e posibil
- secrets management: token-urile în .env, nu în cod
- observability: loghează fiecare apel și fiecare eroare
Template 02 — Raportare automată
Când vrei un raport săptămânal / lunar de business
- Identifică întâi north star metric și pune-l mare, în top
- 3-5 metrici de suport sub el, care explică nord star-ul
- Pentru fiecare cifră: show your work — sursa datelor, perioada, formula
- Sanity check înainte de trimitere: dacă o cifră iese din interval, oprește-te
- Nu loghea PII — folosește ID-uri interne
- Idempotent: dacă rulează de 2 ori, nu trimite de 2 ori
Template 03 — Campanie de marketing
Mass-email, mass-SMS, push notifications
- Dry run obligatoriu: arată-mi câți destinatari, către ce segmente, 3 mesaje exemple
- Sanity check: dacă numărul e cu ±30% diferit de medie, oprește-te
- Idempotency key per destinatar: dacă scriptul rulează de 2 ori, fiecare primește un singur mesaj
- Rate limiting conform limitelor furnizorului
- Respectă GDPR și PII
- Audit log: cine a aprobat trimiterea, când
Template 04 — Lansare feature nou
Funcționalitate nouă pe site / app / sistem intern
- Evals pe scenariile cheie
- Red team pe feature: ce ar putea pica, cum poate fi spart
- Smoke test în staging înainte de producție
- Setează feedback loop scurt: măsoară zilnic primele 2 săptămâni
- Definește pragul la care ne oprim dacă nu merge"
Template 05 — Debugging când ceva nu merge
Sistem care pica, eroare necunoscută, comportament ciudat
- Think step by step: ce date primim? ce procesăm? ce livrăm? unde se rupe lanțul?
- Don't guess: nu ghici cauza din memorie. Verifică observability (loguri)
- Cite your sources: pentru fiecare ipoteză, indică linia din log / cererea din network
- Show your work: arată-mi raționamentul
- După ce găsești cauza, propune un fix minim + un eval care prinde problema asta dacă mai apare"
Template 06 — Modificare la sistem care merge
Schimbare la cod / configurare deja în producție
- Spune-mi chain of thought: ce schimbi exact, ce ar putea afecta
- Red team propria modificare: ce ar putea pica?
- Asigură-te că respectă backward compatibility
- Smoke test: rulează acțiunile-cheie
- Rulează evals existente de regression
- Loghează modificarea în audit log"
Greșeli comune
În primele luni de folosire a "cuvintelor de aur", aproape toată lumea face aceleași 8 greșeli. Le-am listat aici ca să le poți recunoaște din timp.
Suprasaturare cu termeni tehnici
Pui toate cele 40 de cuvinte într-o singură comandă, gândindu-te că "mai mult e mai bine". Rezultat: agentul se confuzează, încearcă să satisfacă toate criteriile și nu satisface niciunul bine.
Soluția: Folosește 3-7 cuvinte relevante per comandă. Pentru sarcini simple, 1-3. Cele 5 din Top 5 + 2-3 specifice contextului — atât.
Folosirea cuvintelor pe care nu le înțelegi
Strecori "idempotency key" într-o comandă pentru că ai văzut că sună bine, dar nu știi ce înseamnă. Agentul îți pune o întrebare clarificatoare și ești blocat.
Soluția: Folosește doar cuvinte pe care le poți explica în 2 vorbe. Lista de care ești sigur va crește natural cu timpul.
Lipsa acceptance criteria
Te grăbești și sari peste etapa "definește ce înseamnă gata". Apoi agentul îți livrează ceva care e tehnic corect dar nu rezolvă problema ta reală. Refaceți totul.
Soluția: 5 minute investite în acceptance criteria la început salvează 5 ore de refacere ulterior. Niciun task netrivial fără ele.
Evals fără ground truth
Ceri "fă evals" și primești 10 teste care toate trec. Pe scurt: agentul își verifică singur ipotezele cu propriile ipoteze. Inutil. Evals fără ground truth verificat de om sunt teatru.
Soluția: Pentru fiecare eval important, ai un răspuns corect verificat manual. Acela e ground truth.
Ignorarea sanity check-urilor
Lași raportul să se trimită automat fără sanity check. Într-o zi, un bug face ca raportul să arate "0 RON vânzări săptămâna trecută". Tu trimiti asta pe Slack la 15 oameni.
Soluția: Pe orice raport / acțiune automată, definește 2-3 sanity checks. "Cifrele trebuie să fie între X și Y; altfel, oprește-te."
Webhooks fără idempotency
Construiești un sistem care reacționează la webhooks de la Shopify. Merge perfect 2 săptămâni. Apoi Shopify retrimite un webhook (perfect legitim) și sistemul tău procesează aceeași comandă de 2 ori.
Soluția: Orice handler de webhook e idempotent prin design. Folosește event_id ca cheie de deduplicare. Asta nu e opțional.
Token-uri în cod sau în Git
Pui token-ul Shopify direct în config.py "ca să meargă rapid". Mai târziu, cineva clonează repo-ul și ai 200 de boți care încearcă să intre. Sau comizi din greșeală în Git public și un scanner îl găsește în 30 de minute.
Soluția: Niciodată token-uri direct în cod. Niciodată .env în Git. Folosește secrets management de la început.
Confuzia "evals" cu "merge?"
Întrebi "merge?" și agentul îți zice "da, merge". Tu crezi că a verificat. El nu a verificat — doar a estimat că probabil merge. "Merge?" nu e o întrebare verificabilă; "trec evals?" este.
Soluția: Nu accepta răspunsuri vagi. Cere mereu evidență concretă: "câte evals trec? care nu trec? arată-mi output-ul."
Cheat Sheet final
Toate cuvintele de aur, într-o singură privire. Tipărește această secțiune și pune-o lângă monitor.
Vrei să-l tipărești frumos?
Cheat sheet în format A4, design poster, gata de print. Fără cont, fără email.
Acum că știi cuvintele...
Vocabularul e prima cărămidă. Restul depinde de unde ești și ce vrei să construiești.
robOS
Memorie pe 5 niveluri, verificare anti-improvizație, multi-workspace. Toate cuvintele din capitolele 1-3 — automate.
Fabrica de Agenți
VPS cu 4 agenți AI care publică zilnic articole și video. Toate pattern-urile din capitolele 4-6 — pre-instalate.
Discuție directă
15 minute pe WhatsApp despre business-ul tău. Aflăm împreună ce ți se potrivește — fără presiune de vânzare.