2026 ના Sonar સર્વેક્ષણ મુજબ 88% ડેવલપર્સનું કહેવું છે કે AI દ્વારા જનરેટ થયેલ કોડ ટેકનિકલ ડેબ્ટ (technical debt) વધારી રહ્યો છે, અને spec-driven development ના સમર્થકો દલીલ કરે છે કે એક શિસ્તબદ્ધ સ્પષ્ટીકરણ (specification) સ્ટેપ આ વિચલનને અટકાવી શકે છે.
આ સમસ્યા શા માટે મહત્વની છે
જ્યારે કોઈ વ્યક્તિને અસ્પષ્ટ ટિકિટ મળે છે, ત્યારે તેઓ સ્પષ્ટતા કરવા માટે પ્રશ્નો પૂછે છે. તેનાથી વિપરીત, એક AI એજન્ટ તેની શ્રેષ્ઠ ધારણાથી ખાલી જગ્યાઓ ભરી દે છે અને એવો કોડ આપે છે જે જોવામાં સાચો લાગે છે. સાચા હોવાનો આ ભ્રમ ખર્ચાળ સાબિત થાય છે: તે જ Sonar પોલ રિપોર્ટ કરે છે કે અડધાથી વધુ પ્રતિસાદ આપનારાઓએ એવો કોડ જોયો છે જે મૂળભૂત ચેક્સ પાસ કરે છે છતાં તેમાં સૂક્ષ્મ ખામીઓ છુપાયેલી હોય છે. આ ખામીઓ ટેકનિકલ ડેબ્ટ તરીકે જમા થાય છે, જેના કારણે પાછળથી રિફેક્ટરિંગ (refactoring) કરવું પડે છે, ફીચર ડિલિવરી ધીમી પડે છે અને મેન્ટેનન્સ બજેટ વધે છે.
Spec-driven development કેવું દેખાય છે
Spec-driven development (SDD) વર્તમાન પદ્ધતિને ઉલટાવી દે છે. AI મોડેલને ટૂંકી યુઝર સ્ટોરી આપીને પ્રોમ્પ્ટ આપવાને બદલે, ટીમ એક વિગતવાર, એજન્ટ-એક્ઝિક્યુટેબલ સ્પષ્ટીકરણ (specification) લખે છે જે કોડની જેમ જ સમાન વર્ઝન-કંટ્રોલ સિસ્ટમમાં રહે છે. આ સ્પષ્ટીકરણ 'સિંગલ સોર્સ ઓફ ટ્રુથ' (single source of truth) બની જાય છે—તે હેતુ (intent), એજ કેસીસ (edge cases), પરફોર્મન્સ અપેક્ષાઓ અને AI મોડેલે પાલન કરવું જોઈએ તેવા કોઈપણ નિયમોને રેકોર્ડ કરે છે.
આ પ્રક્રિયા માનવ ડિઝાઇન કાર્યનું સ્થાન લેતી નથી; તે તેને કોડિફાય (codify) કરે છે. નિર્ણયોને ડેવલપરની યાદશક્તિમાંથી એક નક્કર દસ્તાવેજમાં ખસેડવાથી, માણસો અને ભવિષ્યના AI એજન્ટો બંને જાણી શકે છે કે કોડનો એક ભાગ ચોક્કસ રીતે કેમ વર્તે છે. સ્પષ્ટીકરણ તૈયાર કરવામાં શરૂઆતમાં મહેનત લાગે છે, પરંતુ અસ્પષ્ટ AI આઉટપુટને ડિબગ (debug) કરવામાં પછીથી ઘણો વધુ ખર્ચ થાય છે.
વર્કફ્લોમાં ફેરફાર
Product backlog – આઇટમ્સ ટૂંકી રાખો, જેમાં માત્ર હેતુ અને ઉચ્ચ-સ્તરના સ્વીકૃતિ માપદંડો (acceptance criteria) જ સામેલ હોય. આ યાદી પ્રાથમિકતા નક્કી કરવામાં મદદ કરવાનું ચાલુ રાખશે.
Sprint planning – ટીમો મુખ્ય ધ્યેય વિશે ચર્ચા કરે છે અને Sprint Goal પર સહમત થાય છે, પરંતુ જ્યાં સુધી સ્પષ્ટીકરણ તૈયાર ન થાય ત્યાં સુધી તેઓ વિગતવાર અમલીકરણ (implementation) રોકી રાખે છે.
During the sprint – જે વ્યક્તિ કાર્ય લે છે તે ચોક્કસ, મશીન-રીડેબલ સ્પષ્ટીકરણ લખે છે. સ્પષ્ટીકરણમાં ઇનપુટ ફોર્મેટ, અપેક્ષિત આઉટપુટ, એરર હેન્ડલિંગ અને કોઈપણ નોન-ફંક્શનલ જરૂરિયાતોની યાદી હોય છે. સ્પષ્ટીકરણ વર્ઝન-કંટ્રોલ્ડ હોવાથી, રિવ્યુઅર્સ કોડની જેમ જ કોમેન્ટ કરી શકે છે, સુધારા સૂચવી શકે છે અને ફેરફારોને મંજૂરી આપી શકે છે.
Definition of Done – ક્વોલિટી ગેટમાં “Spec reviewed and approved” ઉમેરો. જ્યાં સુધી સ્પષ્ટીકરણ અમલીકરણના સમાન રિવ્યુ ધોરણો પાસ ન કરે ત્યાં સુધી કોઈ કોડ પૂર્ણ ગણાશે નહીં.
Kanban adaptation – બે નવા કોલમ ઉમેરો: “Spec Drafted” અને “Spec Approved.” હવે કામની વસ્તુઓ આ રીતે વહેશે: backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done. આ વિઝ્યુઅલ ફેરફાર અગાઉ અદ્રશ્ય રહેલા સંકલન (coordination) સ્ટેપને સ્પષ્ટ બનાવે છે.
એવા સાધનો જે પહેલેથી જ સ્પષ્ટીકરણો લાગુ કરે છે
GitHub Spec Kit અને AWS Kiro જેવા પ્લેટફોર્મ્સમાં એવા ગેટ્સ ઉમેરવામાં આવ્યા છે જે કોઈપણ AI કોડ જનરેશન શરૂ કરતા પહેલા જરૂરિયાતોના દસ્તાવેજની માંગ કરે છે. તેઓ AI મોડેલનું સ્થાન લેતા નથી; તેઓ શબ્દશઃ કામ કરતા એજન્ટોને માનવીય હેતુ સાથે સુસંગત બનાવે છે. સ્પષ્ટીકરણને પૂર્વશરત બનાવીને, આ સાધનો હાલના CI/CD પાઇપલાઇન્સને તોડ્યા વિના આ પરિવર્તનને ઓટોમેટ કરે છે.
સંભવિત વિરોધ
ટીકાકારો કહે છે કે સ્પષ્ટીકરણ લખવાથી પહેલેથી જ ઝડપી ગતિ ધરાવતા એજાઈલ (agile) કામકાજમાં અવરોધ આવે છે. તેનો વિરોધમાં મુદ્દો એ છે કે: સ્પષ્ટીકરણ તૈયાર કરવામાં વિતાવેલો સમય સામાન્ય રીતે અસ્પષ્ટ પ્રોમ્પ્ટમાંથી બનેલા AI-જનરેટેડ કોડને ડિબગ કરવામાં વિતાવેલા સમય કરતા ઘણો ઓછો હોય છે.
બીજી ચિંતા એ છે કે જરૂરિયાતો બદલાતા સ્પષ્ટીકરણો જૂના થઈ શકે છે. વર્ઝન-કંટ્રોલ ઇન્ટિગ્રેશન આ સમસ્યાનો ઉકેલ આપે છે: સ્પષ્ટીકરણમાં કોઈપણ ફેરફાર નવો કમિટ (commit) બનાવે છે, રિવ્યુ ટ્રિગર કરે છે અને ટીમને સંબંધિત કોડનું ફરીથી મૂલ્યાંકન કરવા માટે મજબૂર કરે છે. વ્યવહારમાં, સ્પષ્ટીકરણોને કોડની જેમ રાખવાથી દસ્તાવેજીકરણ (documentation) અપ-ટુ-ડેટ રહે છે.
આગળ શું જોવું
તેનો સ્વીકાર હજુ શરૂઆતના તબક્કામાં છે, પરંતુ તેની ગતિ દેખાઈ રહી છે. જેમ જેમ AI કોડ જનરેટર્સ વધુ સક્ષમ બનશે, તેમ તેમ ચોક્કસ, મશીન-રીડેબલ હેતુની જરૂરિયાત વધતી જશે.
Bottom line: અસ્પષ્ટ પ્રોમ્પ્ટ્સને નક્કર, રિવ્યુ કરેલા સ્પષ્ટીકરણોમાં બદલવા એ વધારાનું સ્ટેપ લાગી શકે છે, પરંતુ તે અનુમાનને જવાબદાર નિર્ણયોમાં ફેરવે છે.