Dezvoltarea ghidată de specificații: practica care înlocuiește vibe coding-ul în 2026

"Vibe coding" — descrierea unei funcționalități unui LLM în limbaj natural și acceptarea a ceea ce returnează — a fost faza distractivă a programării asistate de AI. A durat aproximativ optsprezece luni. Echipele care încă funcționează așa în 2026 simt costul: cod care funcționează inițial dar eșuează la cazurile limită, abstracțiuni inconsistente între fișiere, regresiuni care apar pentru că modelul nu a avut niciodată o specificație împotriva căreia să verifice.

Înlocuitorul are un nume — Spec-Driven Development (SDD) — și este modul în care echipele care livrează AI în producție lucrează acum. Ideea este simplă, dar implicațiile sunt mai mari decât par.

Ce înseamnă efectiv SDD

SDD înseamnă: tu scrii specificația, modelul scrie codul. Specificația este artefactul principal al muncii tale. Codul este un output derivat care poate fi regenerat oricând.

Asta nu este Waterfall reîncălzit. Specificația este scurtă, executabilă mental și ține pasul cu codul. De obicei trăiește alături de cod (un fișier SPEC.md per slice sau modul) și este actualizată în același PR ca modificarea de cod pe care o descrie. Modelul citește specificația ca prompt; tu citești specificația când revii peste șase luni.

Diferența față de "scrie un comentariu și lasă Cursor să umple gol-urile" este disciplina. O specificație SDD descrie contractul — inputuri, outputuri, invarianți, comportament la cazuri limită — nu implementarea. Modelul produce implementarea. Tu verifici că respectă contractul.

Cum arată o specificație bună

O specificație de funcționalitate care funcționează cu LLM-urile actuale arată în general așa:

# Funcționalitate: aplică reducere la coș

## Scop
Aplică un cod de reducere la coșul curent al utilizatorului. Returnează coșul actualizat
sau o eroare structurată.

## Inputuri
- userId: UUID (autentificat)
- cartId: UUID (deținut de userId)
- discountCode: string (case-insensitive, trim)

## Outputuri
- success: { cart: Cart, appliedDiscount: AppliedDiscount }
- error: { code: "INVALID_CODE" | "EXPIRED" | "CART_NOT_FOUND"
         | "ALREADY_APPLIED" | "MIN_SUBTOTAL_NOT_MET", message: string }

## Invarianți
- Doar o singură reducere activă per coș la un moment dat.
- Reducerea expirată este respinsă fără a modifica coșul.
- Subtotalul coșului este recalculat după aplicare; impozitul este recalculat în urma asta.

## Cazuri limită
- discountCode necunoscut: returnează INVALID_CODE.
- cartId aparține altui utilizator: returnează CART_NOT_FOUND (nu UNAUTHORIZED; nu scurge existența).
- Reducere deja aplicată: returnează ALREADY_APPLIED, coșul nemodificat.
- Subtotal sub minimum: returnează MIN_SUBTOTAL_NOT_MET cu pragul necesar în mesaj.

## Non-obiective
- Coduri de reducere stacked (refuzate din scop pentru această iterație).
- Coduri de reducere unice per utilizator (în Q3).

Aceasta este o specificație de ~30 de linii. Modelul poate genera implementarea, testele și migrația pornind de la ea — și mai important, un coleg de echipă o poate citi peste șase luni și înțelege ce face funcționalitatea fără a deschide codul.

Ce a stricat vibe coding

Pentru a înțelege de ce câștigă SDD, merită să fim onești despre ce nu a funcționat:

• Drift între prompt și implementare. Promptul a spus "permite o singură reducere"; modelul a produs o buclă care suprascrie tăcut codurile anterioare. Nimic nu a observat pentru că nu exista o specificație împotriva căreia să verifice.
• Hiper-personalizare per modificare. Fiecare nou prompt regenerează stilul de cod de la zero. Aceeași bază de cod ajunge cu trei convenții pentru gestionarea erorilor.
• Imposibilitatea de a face onboarding. Următorul inginer (sau următorul agent) nu poate reconstrui de ce codul arată așa cum arată — pentru că contextul era într-o fereastră de chat care s-a pierdut.

SDD adresează toate cele trei pentru că specificația este sursa adevărului, nu istoricul chat-ului.

Modurile de eșec ale SDD

SDD nu este magic. Modurile principale de eșec pe care le-am văzut:

Specificații prea detaliate. Dacă specificația prescrie fiecare apel de funcție, ai scris codul de două ori. Specificația trebuie să descrie ce, nu cum. Lasă modelul să aleagă structura.

Specificații prea vagi. "Aplică reducere la coș" nu este o specificație. Este un titlu. Specificația trebuie să acopere intrările, ieșirile, invarianții și cazurile limită care contează.

Specificații care zac. Dacă specificația și codul deviază, încrederea se prăbușește rapid. Tratează specificația ca un cetățean de primă clasă în review-urile de cod. Schimbarea codului fără actualizarea specificației este motiv de respingere.

Specificații folosite în loc de teste. Specificația spune ce ar trebui codul să facă; testele verifică că face. Ambele sunt necesare. SDD nu înlocuiește testarea.

Când să sari peste specificație

Nu fiecare modificare merită o specificație. Reguli empirice:

• Refactor pur (nicio schimbare comportamentală): fără specificație, doar lasă modelul să facă.
• Bugfix dintr-o singură linie: fără specificație.
• Modificare cosmetică UI: fără specificație.
• Funcționalitate nouă cu invarianți: specificație.
• Modificare comportamentală pe drumul critic (plăți, autentificare, date): specificație, indiferent cât pare de mică.

Mușchiul de antrenat este să recunoști când o "mică modificare" încalcă de fapt un invariant. Asta este momentul în care SDD plătește.

Pârghia SDD în 2026

Modelele sunt acum suficient de bune încât scrierea codului este partea ieftină. Înțelegerea codului, ținerea lui consistent și prevenirea regresiunilor este partea scumpă. O specificație de 30 de linii care reduce munca inginerului asupra unei funcționalități la "scrie specificația, revizuiește diff-ul" este o pârghie 5x — și se aplică fiecărui inginer de pe echipă, indiferent de senioritate.

Costul real al SDD este disciplina culturală: să tratezi specificațiile ca livrabile reale, să le revizuiești în PR-uri, să le păstrezi sincronizate. Echipele care fac asta livrează mai mult, cu mai puține regresiuni, cu agenți AI care produc cod consistent. Echipele care încă promptează ad-hoc devin treptat mai lente pe măsură ce baza lor de cod își pierde forma.

Vibe coding a fost demoul. Spec-driven development este produsul.