Cum gândește Claude Code (și cum să-i ceri lucruri ca să funcționeze de prima dată)

Două persoane primesc același acces la Claude Code în aceeași săptămână. După 30 de zile, una a livrat 4 proiecte funcționale, cealaltă a abandonat-o după prima săptămână frustrată că "scrie cod care nu compilează".

Diferența nu e seniority, nu e curiozitate, nu e timp investit. E înțelegerea modelului mental al agentului. Cei care înțeleg cum gândește Claude Code îi dau instrucțiuni care produc cod de prima dată. Cei care nu, intră în bucle frustrante de "nu, nu așa, refă".

Articolul ăsta e tot ce am învățat în 18 luni de utilizare zilnică intensă. E lung pentru un motiv: skill-ul ăsta îți schimbă productivitatea cu 3-5x.

Modelul mental: agent autonom, nu autocomplete

Cea mai mare greșeală pe care o face un începător: tratează Claude Code ca pe un Copilot mai bun. Nu este.

Claude Code e un agent autonom care:

• Citește file system-ul tău (vede toate fișierele proiectului)
• Rulează comenzi în terminal (npm, git, docker, orice)
• Își face propriul plan din instrucțiunile tale
• Execută planul pas cu pas
• Verifică rezultatul (rulează teste, citește log-uri)
• Iterează până când consideră că e gata

Asta înseamnă că NU îi dai instrucțiuni line-by-line. Îi dai obiective.

Greșit: "Scrie funcția handleSubmit care primește event."

Corect: "Adaugă un formular de contact pe pagina /contact care, la submit, salvează în tabel contact_messages și trimite email la hello@aihost.md cu Resend. Validează email să fie format valid."

În al doilea caz, Claude Code va: crea tabelul dacă lipsește, scrie schema, scrie pagina, scrie server action, configura Resend, valida cu zod, gestiona erorile. Și-ți va spune când e gata.

Cum își face Claude Code planul

Când îi dai o instrucțiune complexă, prima dată face un plan intern. Pașii lui sunt cam așa:

1. Citește contextul: ce-i în CLAUDE.md, ce-i în README, structura folderelor, package.json
2. Identifică ce trebuie modificat: care fișiere existente, care fișiere noi
3. Verifică convențiile codului: cum se scriu component-uri în acest proiect, ce style folosești
4. Face un mini-plan (2-5 pași concreți)
5. Execută, verificând după fiecare pas

Dacă contextul e prost (lipsește CLAUDE.md, README e pe 2 rânduri, codul e neconsistent), planul lui va fi aproximativ. Dacă contextul e bun, planul va fi precis.

Anatomia unui prompt care funcționează

Un prompt bun are 4 componente:

1. Context complet (ce ai și unde)

Slab: "Adaugă autentificare."

Bun: "În proiectul ăsta folosesc Better-Auth (vezi src/lib/auth.ts). Adaugă login social cu Google. Folosește credentials din .env: GOOGLE_CLIENT_ID și GOOGLE_CLIENT_SECRET (le pun eu manual)."

În al doilea caz, Claude știe exact unde să se uite, ce librărie să folosească, și ce să nu modifice (variabilele de mediu).

2. Constrângeri explicite

Slab: "Refactorizează componenta asta."

Bun: "Refactorizează UserProfile.tsx ca să nu mai aibă useState — folosește server component cu data fetched on the server. Nu modifica props-urile externe (componenta e folosită în 6 alte locuri)."

Constrângerile (negativă: "nu modifica X") sunt la fel de importante ca instrucțiunile pozitive. Te scapă de "a refactorizat exact ce-am cerut, dar a stricat 6 alte pagini fiindcă a schimbat API-ul".

3. Format așteptat (când relevant)

Slab: "Generează test data."

Bun: "Generează 20 de utilizatori demo în formatul: { id, email, name, role: 'user' | 'admin' }. Salvează ca array exportabil în src/lib/demo-users.ts. 18 cu rol 'user', 2 cu rol 'admin'."

4. Acceptance criteria

Slab: "Asigură-te că funcționează."

Bun: "Trebuie ca npm test să treacă. Plus, când deschid localhost:3000/admin și nu sunt logat, să fiu redirectat la /login. Când mă loghez ca user normal, să primesc 403 pe /admin."

Cu acceptance criteria clare, Claude Code verifică singur că s-a îndeplinit ce ai cerut. Fără ele, "funcționează" devine subiectiv.

Antipatterns: ce să nu faci

Antipattern 1: Prompts vagi

"Fă-l mai bun." Mai bun cum? Mai rapid? Mai ușor de citit? Mai securizat? Claude va alege o interpretare la întâmplare. Specifică.

Antipattern 2: Schimbarea instrucțiunilor mid-conversation

Începi cerând feature A. Pe parcurs zici "ah, și să fie și B". Apoi "ai uitat că trebuia să facă și C". Conversațiile lungi cu obiective shifting devin haotice — Claude pierde firul, codul devine inconsistent.

Soluția: Când ai un nou obiectiv mare, închide sesiunea și pornește una nouă. Sau pune-l să rezume ce-a făcut, apoi îi dai noul obiectiv ca pe ceva de la zero.

Antipattern 3: Ignorarea CLAUDE.md

CLAUDE.md (sau .claude/instructions.md) e ca briefing-ul agentului. Acolo pui:

• Convenții de cod (TypeScript strict, Tailwind, server components default)
• Tools-urile preferate (Drizzle peste Prisma, Better-Auth peste NextAuth)
• Reguli importante ("nu rula drizzle-kit push --force niciodată")
• Persoane care lucrează la proiect și preferințele lor

Fără CLAUDE.md, Claude Code repetă greșeli pe care i le-ai corectat de 5 ori. Cu, le evită din prima.

Antipattern 4: Prea mult context (saturează)

Există un punct unde îi dai prea mult context (10 fișiere paste-uite în prompt) și performance-ul scade. Claude prioritizează prost când vede prea multe lucruri simultan.

Soluția: Lasă-l să decidă singur ce fișiere să citească. Spune doar "vezi src/lib/auth.ts și src/components/LoginForm.tsx" — el le va deschide.

Antipattern 5: Nu verifici, doar accepți

Claude Code spune "gata, am implementat X". Tu accepți și mergi mai departe. La 3 pași distanță descoperi că X-ul e fundamental greșit. Acum trebuie să refaci 3 pași.

Soluția: După fiecare pas mare, verifică tu manual. Nu testează doar testele — folosește produsul tu.

Tehnici avansate

1. CLAUDE.md ca file-driven config

În proiectele mature, CLAUDE.md e un fișier vital. Exemplu de structură:

# Project: aihost-md

## Stack
Next.js 15 App Router, TypeScript strict, Tailwind 4, Drizzle ORM, Better-Auth, Postgres.

## Conventions
- Server components by default; client only when needed (forms, animations)
- Server actions over API routes
- Prefer Drizzle over raw SQL
- Tailwind utility classes; no styled-components

## CRITICAL rules
- Never push to prod without explicit "push live" from RT
- Never run drizzle-kit push --force (only --generate then --migrate)
- Schema changes must be additive (no DROP, no ALTER COLUMN ... NOT NULL)

## Files to always read first
- src/lib/auth.ts
- src/lib/db.ts
- packages/db/src/schema.ts

Astfel agent-ul vine cu briefing-ul deja făcut.

2. TDD (Test-Driven Development) cu agent

În loc de "implementează X, apoi scrie teste", inversezi: "Scrie întâi testele pentru X (care vor pica). Apoi implementează ca să treacă".

De ce funcționează: testele devin acceptance criteria-ul concret. Claude știe exact când e gata.

3. Sub-agents pentru task-uri lungi

În Claude Code există conceptul de "agent" — sub-sesiune cu scope restrâns. Util când vrei să faci ceva care ar costa mult context în sesiunea principală.

Ex: "Cere unui agent de research să găsească toate locurile unde folosim useState în proiect și să raporteze cum sunt distribuite. NU modifica nimic."

Agent-ul citește, raportează, returnează un summary. Sesiunea ta principală nu se umple cu 50 de file reads.

4. Skill-uri (skills/)

Skills sunt instrucțiuni reutilizabile pe care Claude Code le încarcă automat când contextul cere. Ex: un skill "debugging" care îi spune "când întâlnești o eroare, întâi verifică log-urile, apoi google-uiește mesajul, apoi încearcă să reproduci în izolare".

Workflow recomandat pentru o sesiune

1. Pornește cu obiectiv clar. O singură propoziție care descrie ce vrei la final.
2. Lasă agentul să facă plan. "Înainte să implementezi, dă-mi planul în 5 pași."
3. Aprobă planul sau ajustează: "Pasul 3 e prea mare, sparge-l în 2."
4. Lasă-l să execute. Nu intervieni la fiecare comit. Lasă-l 5-15 min.
5. Verifică tu rezultatul. Deschide aplicația, testează manual.
6. Feedback structurat: "Funcționează X. Nu funcționează Y — eroarea e Z. Te rog rezolvă Y."
7. Commit-ezi des. O dată pe feature, nu o dată pe zi.

Concluzie

Vibe coding-ul nu e magie. E un dialog structurat cu un agent care, dacă e brief-uit bine, livrează cod corect de prima dată. Dacă e brief-uit prost, livrează cod aproximativ pe care-l rescrii de 3 ori.

Skill-ul ăsta nu se învață citind articole (nici măcar pe ăsta). Se învață folosindu-l. Începe cu un proiect mic, observă-ți greșelile, ajustează prompt-urile, vezi diferența. În 2 săptămâni de practică intensivă vei avea reflexele bune.

Vezi și 20 de prompt-uri zilnice cu Claude Code pentru exemple concrete.

Începe să exersezi pe un mediu pre-pregătit aihost.md →