२०२६ च्या Sonar सर्वेक्षणातून असे दिसून येते की ८८% डेव्हलपर्सच्या मते AI-जनरेटेड कोडमुळे तांत्रिक कर्ज (technical debt) वाढत आहे, आणि spec-driven development चे समर्थक असा युक्तिवाद करतात की एक शिस्तबद्ध specification टप्पा हा हा कल रोखू शकतो.

ही समस्या का महत्त्वाची आहे

जेव्हा एखाद्या माणसाला अस्पष्ट तिकीट मिळते, तेव्हा ते स्पष्टीकरण विचारण्यासाठी प्रश्न विचारतात. याउलट, एक AI agent स्वतःच्या अंदाजानुसार रिकाम्या जागा भरतो आणि असा कोड देतो जो वरवर पाहता योग्य वाटतो. बरोबर असल्याचा हा आभास महागडा पडू शकतो: त्याच Sonar पोलनुसार, निम्म्याहून अधिक उत्तरदात्यांनी असा कोड पाहिला आहे जो मूलभूत तपासण्यांमध्ये (basic checks) उत्तीर्ण होतो, परंतु त्यात सूक्ष्म दोष लपलेले असतात. हे दोष तांत्रिक कर्ज (technical debt) म्हणून साचत जातात, ज्यामुळे नंतर रिफॅक्टरिंग (refactoring) करावे लागते, नवीन फीचर्स देण्याचा वेग मंदावतो आणि देखभालीचा खर्च (maintenance budget) वाढतो.

Spec-driven development कसे दिसते

Spec-driven development (SDD) सध्याची पद्धत पूर्णपणे बदलून टाकते. AI मॉडेलला केवळ एक संक्षिप्त user story देऊन प्रॉम्प्ट देण्याऐवजी, टीम एक तपशीलवार, agent-executable specification लिहिते, जे कोडच्या त्याच version-control system मध्ये असते. हे spec हे 'single source of truth' बनते—ते मूळ उद्देश (intent), edge cases, कामगिरीच्या अपेक्षा आणि AI मॉडेलने पाळायचे असलेले सर्व निर्बंध (constraints) नोंदवते.

ही प्रक्रिया मानवी डिझाइन कामाची जागा घेत नाही; तर ती त्याला अधिक सुव्यवस्थित करते. निर्णय डेव्हलपरच्या स्मृतीतून एका ठोस दस्तऐवजात हलवल्यामुळे, मानव आणि भविष्यातील AI agents दोन्ही हे शोधू शकतात की कोड एका विशिष्ट पद्धतीने का वागतो. spec तयार करण्यासाठी सुरुवातीला कष्ट घ्यावे लागतात, परंतु अस्पष्ट AI आउटपुटमधील त्रुटी शोधणे (debugging) नंतर खूप महाग पडू शकते.

वर्कफ्लोमध्ये बदल

Product backlog – गोष्टी संक्षिप्त ठेवा, केवळ मूळ उद्देश आणि उच्च-स्तरीय स्वीकृती निकष (acceptance criteria) नोंदवा. ही यादी प्राधान्यक्रम (prioritization) ठरवण्यासाठी वापरली जाते.

Sprint planning – टीम्स मुख्य ध्येयावर चर्चा करतात आणि 'Sprint Goal' वर सहमत होतात, परंतु spec तयार होईपर्यंत ते तपशीलवार अंमलबजावणी थांबवून ठेवतात.

स्प्रिंट दरम्यान (During the sprint) – टास्क घेणारी व्यक्ती एक अचूक, मशीन-रीडेबल spec लिहिते. या spec मध्ये इनपुट फॉरमॅट्स, अपेक्षित आउटपुट, एरर हँडलिंग आणि इतर सर्व नॉन-फंक्शनल आवश्यकतांची यादी असते. spec हे version-controlled असल्यामुळे, रिव्ह्यूअर्स कोडप्रमाणेच त्यावर कमेंट करू शकतात, सुधारणा सुचवू शकतात आणि बदल मंजूर करू शकतात.

Definition of Done – क्वालिटी गेटमध्ये “Spec reviewed and approved” हा मुद्दा जोडा. जोपर्यंत spec अंमलबजावणीप्रमाणेच (implementation) समान रिव्ह्यू मानकांवरून जात नाही, तोपर्यंत कोड पूर्ण मानला जाणार नाही.

Kanban adaptation – दोन नवीन कॉलम्स जोडा: “Spec Drafted” आणि “Spec Approved.” आता कामाचा प्रवाह backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done असा असेल. या दृश्य बदलामुळे पूर्वी अदृश्य असलेला समन्वय (coordination) टप्पा स्पष्ट होतो.

सध्या उपलब्ध असलेली टूल्स जी specs लागू करतात

GitHub Spec Kit आणि AWS Kiro सारख्या प्लॅटफॉर्म्सनी असे gates जोडले आहेत जे AI कोड जनरेशन सुरू होण्यापूर्वी आवश्यकता दस्तऐवज (requirements document) अनिवार्य करतात. ते AI मॉडेलची जागा घेत नाहीत; तर ते शब्दशः काम करणाऱ्या एजंट्सना मानवी उद्देशाशी सुसंगत करतात. spec ला पूर्वअट (prerequisite) बनवून, ही टूल्स विद्यमान CI/CD pipelines मध्ये अडथळा न आणता हा बदल स्वयंचलित करतात.

संभाव्य विरोध

टीकाकारांचे म्हणणे आहे की spec लिहिण्यामुळे आधीच वेगाने चालणाऱ्या agile cadence मध्ये अडथळा येतो. यावर प्रतिवाद असा आहे की: spec तयार करण्यासाठी लागणारा वेळ हा अस्पष्ट प्रॉम्प्टमुळे तयार झालेल्या AI-जनरेटेड कोडमधील त्रुटी शोधण्यासाठी (debugging) नंतर लागणाऱ्या वेळेच्या तुलनेत खूपच कमी असतो.

दुसरी चिंता अशी आहे की आवश्यकता बदलल्यामुळे specifications जुने होऊ शकतात. version-control इंटिग्रेशन यावर उपाय देते: spec मध्ये होणाऱ्या कोणत्याही बदलामुळे एक नवीन commit तयार होतो, रिव्ह्यू सुरू होतो आणि टीमला संबंधित कोडचे पुन्हा मूल्यांकन करण्यास भाग पाडतो. व्यवहारात, spec ला कोडप्रमाणे मानल्यामुळे दस्तऐवजीकरण (documentation) अद्ययावत राहते.

पुढे काय पाहावे

याचा स्वीकार अजून सुरुवातीच्या टप्प्यात आहे, परंतु त्याचा वेग दिसून येत आहे. जसे AI कोड जनरेटर्स अधिक सक्षम होतील, तशी अचूक आणि मशीन-रीडेबल उद्देशाची गरज अधिक वाढत जाईल.

थोडक्यात सांगायचे तर: अस्पष्ट प्रॉम्प्ट्सचे रूपांतर ठोस आणि रिव्ह्यू केलेल्या specifications मध्ये करणे हे एक अतिरिक्त पाऊल वाटू शकते, परंतु ते केवळ अंदाज लावण्याऐवजी जबाबदार निर्णय घेण्यास मदत करते.