Discuția despre IA în software development ajunge inevitabil la aceeași întrebare: va mai fi nevoie de dezvoltatori? Experiența noastră cu Spec Kit arată că întrebarea este greșit formulată. Nu dezvoltatorul dispare, ci se schimbă locul în care acesta aduce valoare: mai puțin în scrierea manuală a codului și mai mult în definirea corectă a problemei.
Folosim Spec-Driven Development cu Spec Kit într-un proiect profesional încă de la începutul anului. La început am fost sceptici. Părea încă un instrument care promite mult, dar care riscă să transforme procesul de development într-o conversație lungă cu un model IA. Totuși, i-am dat o șansă, iar primele rezultate ne-au surprins.
În primele utilizări, am avut de implementat taskuri care, în mod normal, probabil ne-ar fi luat câteva zile de development. Cu Spec Kit, am reușit să ajungem la o soluție funcțională într-o singură zi. A fost unul dintre acele momente în care diferența de viteză nu mai este doar o promisiune abstractă, ci ceva foarte concret.
În cazul taskurilor simple sau medii, Spec Kit poate fi foarte rapid. Putem descrie o funcționalitate, putem clarifica cerințele, iar agentul ajunge într-un timp scurt la o implementare care compilează, respectă structura proiectului și se integrează relativ natural în codebase. Feedbackul este rapid, iar lucruri care înainte necesitau ore sau zile de implementare manuală pot fi prototipate sau chiar finalizate mult mai repede.
Această viteză schimbă modul în care ne raportăm la development. Vedem rezultate mai repede, putem experimenta mai ușor și putem valida idei cu un efort mai mic. În același timp, tocmai viteza ne obligă să fim mai atenți la o întrebare esențială: ceea ce am generat este doar funcțional sau este într-adevăr corect?
Una dintre primele lecții învățate a fost că o soluție care funcționează nu este neapărat o soluție corectă. Codul poate rula, testele existente pot trece, interfața poate arăta acceptabil, dar asta nu înseamnă automat că soluția este eficientă, ușor de întreținut, sigură sau aliniată cu direcția arhitecturală a produsului.
Aici apare limita peste care Spec Kit sau orice alt instrument similar nu poate trece: nu poate înlocui responsabilitatea tehnică a unui dezvoltator. Un LLM are o natură nedeterministă, ceea ce înseamnă că poate genera soluții diferite pentru cerințe similare. În plus, lucrează cu un context window: cantitatea limitată de informație pe care o poate folosi într-o interacțiune. Într-un proiect real, contextul complet nu încape niciodată perfect acolo.
Când contextul devine prea mare, modelul sau instrumentul care îl folosește ajunge să rezume, să selecteze sau să ignore detalii. Dacă în acest proces se pierd constrângeri importante sau apar assumptions greșite, implementarea poate merge într-o direcție incorectă fără ca problema să fie evidentă imediat.
Din acest motiv, rolul dezvoltatorului rămâne esențial. Avem nevoie în continuare de un engineering mindset, de capacitatea de a observa riscuri, de a înțelege compromisuri și de a face un code review real. În special în review, trebuie să fim atenți la lucruri pe care agentul le poate rata: edge cases, side effects, performanță, securitate, consistență arhitecturală și impactul asupra altor zone din aplicație.
Dacă scrierea codului devine mai ieftină, valoarea se mută spre definirea problemei, validarea soluției și menținerea calității pe termen lung. Codul este doar o parte din proces. Valoarea reală este în rezolvarea problemei corecte, în modul corect.
Un aspect pe care l-am înțeles rapid este că timpul de development nu dispare, ci se mută. Scriem mai puțin cod manual, dar petrecem mai mult timp citind, validând și corectând specificații generate de IA.
În cazul Spec Kit, aceste specificații nu sunt doar răspunsuri temporare într-un chat. Instrumentul generează fișiere .md direct în proiect, care descriu specificația, planul tehnic și taskurile de implementare. Practic, o parte din contextul de development devine documentație versionată alături de cod.
De aceea, aceste fișiere trebuie citite critic. Trebuie să verificăm dacă problema este formulată corect, dacă scenariile importante sunt acoperite, dacă direcția respectă arhitectura proiectului și dacă rezultatul poate fi testat clar. Agentul poate implementa foarte bine ceva ce a fost definit prost.
Cu alte cuvinte, nu economisim timp pentru că nu mai gândim. Economisim timp pentru că mutăm gândirea mai devreme, în specificație.
Este important să clarificăm și ce este, de fapt, Spec Kit. El nu este un LLM și nu trebuie confundat cu modelul care generează codul sau specificațiile. Spec Kit este mai degrabă un instrument care structurează procesul de Spec-Driven Development și folosește un LLM disponibil pentru a genera specificații, planuri și implementări.
Acest detaliu contează, pentru că Spec Kit nu este singurul instrument care poate susține un astfel de workflow. Vor apărea, probabil, tot mai multe soluții similare, fiecare cu propriile convenții, integrări și avantaje. Ideea importantă nu este neapărat un anumit tool, ci schimbarea de mentalitate: plecăm de la o specificație clară, o validăm, apoi folosim agentul IA pentru a accelera implementarea.
Un alt avantaj este flexibilitatea modelului folosit. În unele cazuri, putem folosi modele comerciale foarte performante. În alte cazuri, mai ales atunci când există temeri legate de confidențialitate, restricții de securitate sau constrângeri economice, putem lua în calcul și modele rulate local. Nu toate proiectele pot trimite context sensibil către servicii externe, iar faptul că un astfel de workflow poate fi adaptat la mai multe tipuri de LLM-uri este important.
Totuși, această flexibilitate vine și cu un cost. Folosirea unui instrument de acest tip poate consuma foarte multe tokenuri. Am experimentat direct acest lucru. Când agentul primește mult context din proiect, generează specificații, planuri, taskuri, apoi revine cu clarificări și implementări, consumul poate crește rapid.
La început, tentația este să îi dăm cât mai mult context, în speranța că rezultatul va fi mai bun. În practică, trebuie să învățăm să fim selectivi. Contextul relevant ajută enorm. Contextul inutil poate crește costul, poate încetini procesul și poate chiar introduce zgomot în deciziile modelului. În timp, ajungem să tratăm promptingul și selecția contextului ca pe o abilitate tehnică.
Această schimbare arată de ce discuția despre dispariția dezvoltatorilor este, în opinia noastră, simplistă. Nu dispare nevoia de dezvoltatori, ci se schimbă zona în care aceștia aduc valoare.
Adaptarea nu ține doar de echipa tehnică. Dacă specificația devine punctul central al procesului, atunci UI, Product Owners, Business Analysts, QA și Engineering Managers trebuie să fie implicați mai devreme și mai clar. Un ticket cu câteva propoziții și o cerință vagă de business nu mai este suficient atunci când devine context activ pentru agentul IA.
În acest context, rolul de Product Engineer devine tot mai relevant. Ca dezvoltatori, avem nevoie să înțelegem nu doar codul, ci și produsul, utilizatorul, designul, constrângerile tehnice, costurile și impactul de business. Nu mai este suficient să transformăm o cerință în cod. Trebuie să participăm activ la definirea problemei și să validăm că soluția generată este cea potrivită.
În echipa noastră, toți dezvoltatorii folosesc Spec Kit într-o formă sau alta. Am observat o creștere considerabilă a velocity-ului, dar nu atât de mare pe cât s-ar putea crede din exterior. O parte din timpul câștigat la implementare se mută în citirea specificațiilor, clarificări, review și verificare.
Petrecem mai mult timp validând fișierele .md generate de AI înainte ca implementarea să avanseze prea mult. Apoi, în etapa de review, apar uneori probleme care poate că ar fi fost observate mai devreme în dezvoltarea clasică, atunci când eram obligați să parcurgem manual fiecare decizie tehnică.
Tocmai de aceea, am început să ne întrebăm dacă nu trebuie adaptată inclusiv structura sprint-ului. Într-un proces bazat pe specificații, sesiunile de refinement și planning devin mai importante. Trebuie să acordăm mai mult timp definirii clare a problemei, identificării edge cases, stabilirii constrângerilor tehnice și înțelegerii potențialelor side effects.
În același timp, implementarea propriu-zisă poate ocupa mai puțin timp. Dacă scrierea codului devine mai rapidă, efortul echipei trebuie mutat acolo unde produce mai multă valoare: specificații mai bune, validare mai rapidă, testare mai solidă și decizii tehnice mai clare.
Un avantaj important este că Spec Kit poate fi introdus și în proiecte existente, nu doar în proiecte noi. Noi l-am introdus într-un proiect existent, aflat deja în producție de aproximativ trei ani. Pentru multe echipe, acest aspect contează, pentru că produsele mature nu pot fi rescrise doar pentru a adopta un instrument nou.
Procesul începe cu definirea constituției proiectului: un set de principii care ghidează implementările generate. Aceasta ar trebui să includă reguli despre arhitectură, securitate, testare, convenții de cod, performanță și limite clare privind ce este acceptabil în proiect. O constituție bună nu trebuie să fie lungă, ci clară, stabilă și ușor de aplicat.
Urmează etapa de specify. Un prompt bun nu ar trebui să ceară doar "implementează acest buton" sau "adaugă acest ecran", ci să explice contextul, problema utilizatorului, comportamentul așteptat, scenariile principale, cazurile de eroare și constrângerile. Cu cât formulăm mai clar problema, cu atât agentul are șanse mai mari să propună o direcție bună.
Etapa de clarify este esențială, pentru că scoate la suprafață ambiguitățile înainte de implementare. Aici putem clarifica reguli de securitate, impactul asupra componentelor existente, cerințe de performanță, edge cases sau comportamente care nu au fost definite suficient.
După clarificare, urmează planul tehnic, împărțirea în tasks și implementarea. Chiar și atunci, procesul nu trebuie considerat închis. Putem reveni cu noi clarificări, putem ajusta specificația și putem cere agentului să corecteze direcția.
Dacă facem modificări manuale în cod, fișierele .md generate de Spec Kit nu ar trebui să rămână în urmă. Ele pot fi referențiate ulterior de agentul IA, iar o specificație depășită poate induce în eroare următoarele implementări. Important este să tratăm aceste fișiere ca parte din codebase, nu ca documentație statică uitată după primul merge.
Una dintre primele frustrări cu Spec Kit a fost implementarea unei interfețe pornind de la un design în Figma. Agentul nu "vede" designul ca noi: spațiere, ierarhie vizuală, consistența componentelor sau diferența dintre un UI bun și unul doar funcțional. Toate acestea trebuie transmise prin context.
La început, am încercat să compensăm prin descrieri mai detaliate în text: ce componente să fie folosite, cum ar trebui să se comporte fiecare element și cum trebuie respectat design systemul existent. Funcționează, dar poate deveni anevoios, mai ales când ajungem să descriem lucruri care pentru noi par evidente.
O soluție mai bună este folosirea de MCP Servers, în special un Figma MCP server. Conectând agentul la sursa de design, îi oferim context despre componente, layout, stiluri și structură. Nu elimină complet nevoia de review, dar reduce ambiguitatea și crește consistența interfeței.
Într-un proces în care agentul IA scrie o parte semnificativă din cod, testarea devine și mai importantă. Dacă implementarea este rapidă, avem nevoie de mecanisme solide care să ne protejeze de regresii. Din acest motiv, credem că nu mai avem scuze pentru un nivel scăzut de code coverage.
Testele existente devin o formă de ghidaj pentru agent: îi arată ce comportamente sunt importante și ceea ce nu trebuie stricat. În același timp, oferă echipei o plasă de siguranță atunci când sunt modificate zone sensibile ale aplicației.
Totuși, nu este suficient să bifăm un procent de code coverage. Testele trebuie să valideze comportamente reale, nu doar să execute linii de cod. De aceea merită să acordăm mai multă atenție și unor tehnici precum mutation testing. Dacă agenții AI pot produce rapid cod și teste, trebuie să ne asigurăm că testele chiar prind probleme reale.
Este Spec-Driven Development o cale spre productivitate 10x? În anumite contexte, da. Pentru taskuri clare, bine delimitate și susținute de o specificație bună, viteza poate fi impresionantă.
Dar viteza nu elimină responsabilitatea tehnică. Dacă specificațiile .md nu sunt citite atent, dacă code review-ul este superficial sau dacă testarea este slabă, nu facem decât să producem probleme mai repede. În plus, un astfel de workflow poate consuma multe tokenuri, deci trebuie să fim atenți ce context oferim agentului și ce model alegem.
Spec Kit nu este magie, nu este un LLM și nu înlocuiește ingineria. Este un amplificator. Dacă îl folosim peste un proces slab, amplifică haosul. Dacă îl folosim într-o echipă matură, cu specificații bune, teste solide și review atent, poate deveni un avantaj real. Codul devine mai ieftin. Gândirea bună rămâne scumpă.
de Mihai Matei
