2026 Sonar ஆய்வின்படி, 88% டெவலப்பர்கள் AI-ஆல் உருவாக்கப்பட்ட குறியீடு (code) தொழில்நுட்பக் கடனை (technical debt) அதிகரிப்பதாகக் கூறுகின்றனர்; மேலும், விவரக்குறிப்பு சார்ந்த மேம்பாட்டின் (spec-driven development) ஆதரவாளர்கள், ஒரு ஒழுங்குமுறைப்படுத்தப்பட்ட விவரக்குறிப்புப் படிநிலை இந்தச் சரிவை தடுத்து நிறுத்த முடியும் என்று வாதிடுகின்றனர்.

இந்தப் பிரச்சனை ஏன் முக்கியமானது

ஒரு மனிதருக்குத் தெளிவற்ற பணிச் செய்தி (ticket) கிடைக்கும்போது, அவர்கள் விளக்கக் கேள்விகளைக் கேட்பார்கள். மாறாக, ஒரு AI ஏஜென்ட், விடுபட்ட இடங்களை தனது சிறந்த யூகத்தைக் கொண்டு நிரப்பி, நம்பகமானதாகத் தோன்றும் குறியீட்டை வழங்குகிறது. இந்தத் தவறானத் தோற்றம் பெரும் செலவை ஏற்படுத்துகிறது: அதே Sonar கருத்துக்கணிப்பின்படி, பாதிக்கும் மேற்பட்ட பதிலளிப்பவர்கள், குறியீடு அடிப்படைச் சோதனைகளில் தேர்ச்சி பெற்றாலும், அதில் நுட்பமான குறைபாடுகள் மறைந்திருப்பதைச் சுட்டிக்காட்டுகின்றனர். அந்தத் தவறுகள் தொழில்நுட்பக் கடனாகக் குவிந்து, பின்னர் குறியீட்டை மறுசீரமைக்க (refactor) வேண்டிய கட்டாயத்தை ஏற்படுத்துகின்றன, அம்சங்களை வழங்குவதைத் தாமதப்படுத்துகின்றன மற்றும் பராமரிப்புச் செலவுகளை அதிகரிக்கின்றன.

விவரக்குறிப்பு சார்ந்த மேம்பாடு (Spec-driven development) எப்படி இருக்கும்

விவரக்குறிப்பு சார்ந்த மேம்பாடு (SDD) தற்போதைய முறையை மாற்றியமைக்கிறது. ஒரு சுருக்கமான பயனர் கதையை (user story) AI மாடலுக்குத் தூண்டுதலாக (prompt) வழங்குவதற்குப் பதிலாக, குழுவினர் குறியீட்டுடன் ஒரே பதிப்பு-கட்டுப்பாட்டு அமைப்பில் (version-control system) இருக்கும் விரிவான, ஏஜென்ட்-செயல்படுத்தக்கூடிய ஒரு விவரக்குறிப்பை (specification) எழுதுகிறார்கள். இந்த விவரக்குறிப்பு ஒரு ஒற்றை உண்மை ஆதாரமாக (single source of truth) மாறுகிறது—இது நோக்கம், விளிம்பு நிலைச் சூழல்கள் (edge cases), செயல்திறன் எதிர்பார்ப்புகள் மற்றும் ஒரு AI மாடல் பின்பற்ற வேண்டிய அனைத்துக் கட்டுப்பாடுகளையும் பதிவு செய்கிறது.

இந்தச் செயல்முறை மனித வடிவமைப்புப் பணியைத் தவிடுபொடியாக்கிவிடவில்லை; மாறாக அதை முறைப்படுத்துகிறது. முடிவுகளை ஒரு டெவலப்பரின் நினைவகத்திலிருந்து ஒரு தெளிவான ஆவணமாக மாற்றுவதன் மூலம், மனிதர்களும் எதிர்கால AI ஏஜென்ட்களும் ஒரு குறிப்பிட்ட குறியீடு ஏன் அவ்வாறு செயல்படுகிறது என்பதைத் தொடர முடியும். ஒரு விவரக்குறிப்பைத் தயாரிப்பதற்கு ஆரம்பத்தில் முயற்சி தேவைப்படலாம், ஆனால் தெளிவற்ற AI வெளியீட்டைப் பிழைதிருத்தம் (debugging) செய்வது பின்னர் அதிகச் செலவை ஏற்படுத்தும்.

பணிப்பாய்வை (Workflow) மாற்றுதல்

Product backlog – உருப்படிகளைச் சுருக்கமாக வைத்திருக்கவும், நோக்கம் மற்றும் உயர்நிலை ஏற்புத் தகுதிகளை (acceptance criteria) மட்டும் பதிவு செய்யவும். இந்தப் பட்டியல் முன்னுரிமைப்படுத்துதலைத் தொடர்ந்து வழிநடத்தும்.

Sprint planning – குழுக்கள் ஒட்டுமொத்த இலக்கைப் பற்றி விவாதித்து, ஒரு Sprint Goal-இல் உடன்படுகிறார்கள், ஆனால் விவரக்குறிப்பு தயாராகும் வரை விரிவானச் செயலாக்கத்தைத் தவிர்க்கிறார்கள்.

During the sprint – பணியை எடுத்துக்கொள்ளும் நபர் துல்லியமான, இயந்திரம்-வாசிக்கக்கூடிய (machine-readable) விவரக்குறிப்பை எழுதுகிறார். இந்த விவரக்குறிப்பு உள்ளீட்டு வடிவங்கள் (input formats), எதிர்பார்க்கப்படும் வெளியீடுகள், பிழை கையாளுதல் மற்றும் பிற செயல்பாட்டுத் தேவைகளை (non-functional requirements) பட்டியலிடுகிறது. விவரக்குறிப்பு பதிப்பு-கட்டுப்பாட்டில் இருப்பதால், ஆய்வாளர்கள் குறியீட்டைப் போலவே கருத்துகளைப் பதிவிடவும், திருத்தங்களை முன்மொழியவும் மற்றும் மாற்றங்களை அங்கீகரிக்கவும் முடியும்.

Definition of Done – தரக் கட்டுப்பாட்டில் (quality gate) “Spec reviewed and approved” என்பதைச் சேர்க்கவும். விவரக்குறிப்பு, செயலாக்கத்தைப் போலவே அதே ஆய்வுத் தரங்களைக் கடக்கும் வரை எந்தக் குறியீடும் முழுமையடைந்ததாகக் கருதப்படாது.

Kanban adaptation – “Spec Drafted” மற்றும் “Spec Approved” என இரண்டு புதிய நெடுவரிசைகளைச் சேர்க்கவும். பணி உருப்படிகள் இப்போது backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done எனப் பாயும். இந்தத் தெளிவான மாற்றம், முன்னதாகத் தெரியாத ஒருங்கிணைப்புப் படிநிலையை வெளிப்படையாக்குகிறது.

ஏற்கனவே விவரக்குறிப்புகளைக் கட்டாயப்படுத்தும் கருவிகள்

GitHub Spec Kit மற்றும் AWS Kiro போன்ற தளங்கள், எந்தவொரு AI குறியீடு உருவாக்கமும் தொடங்குவதற்கு முன் ஒரு தேவைகுறிப்பு ஆவணத்தைக் (requirements document) கோரும் கட்டுப்பாடுகளைச் சேர்த்துள்ளன. அவை AI மாடலுக்கு மாற்றாகச் செயல்படுவதில்லை; மாறாக, இயந்திரத்தனமாகச் செயல்படும் ஏஜென்ட்களை மனித நோக்கத்துடன் ஒருங்கிணைக்கின்றன. விவரக்குறிப்பை ஒரு முன்நிபந்தனையாக மாற்றுவதன் மூலம், இந்தத் தளங்கள் ஏற்கனவே உள்ள CI/CD குழாய்களை (pipelines) உடைக்காமல் இந்த மாற்றத்தை தானியக்கமாக்குகின்றன.

ஏற்படக்கூடிய எதிர்ப்புக்கள்

விமர்சகர்கள், ஒரு விவரக்குறிப்பை எழுதுவது ஏற்கனவே வேகமாகச் செல்லும் அஜைல் (agile) வேகத்தில் தேவையற்றத் தடைகளை உருவாக்குவதாகக் கூறுகின்றனர். இதற்குப் பதிலாகச் சொல்லப்படுவது என்னவென்றால்: ஒரு விவரக்குறிப்பைத் தயாரிப்பதற்குக் செலவிடப்படும் நேரம், தெளிவற்ற தூண்டுதலால் (prompt) உருவாக்கப்பட்ட AI குறியீட்டைப் பிழைதிருத்தம் செய்யப் பிற்காலத்தில் செலவிடப்படும் நேரத்தை விட மிகக் குறைவு.

தேவைகள் மாறும்போது விவரக்குறிப்புகள் காலாவதியாகிவிடும் என்பதும் மற்றொரு கவலையாக உள்ளது. பதிப்பு-கட்டுப்பாட்டு ஒருங்கிணைப்பு இதற்குத் தீர்வாக அமைகிறது: விவரக்குறிப்பில் செய்யப்படும் எந்தவொரு மாற்றமும் ஒரு புதிய கமிட்டை (commit) உருவாக்குகிறது, ஒரு ஆய்வைத் தூண்டுகிறது மற்றும் தொடர்புடைய குறியீட்டை மறுமதிப்பீடு செய்யக் குழுவை வற்புறுத்துகிறது. நடைமுறையில், விவரக்குறிப்புகளைக் குறியீடு போலக் கருதுவது ஆவணங்களை எப்போதும் தற்போதைய நிலையில் வைத்திருக்க உதவுகிறது.

அடுத்து கவனிக்க வேண்டியவை

இதைப் பின்பற்றுவது இன்னும் ஆரம்பக் கட்டத்திலேயே உள்ளது, ஆனால் அதன் வேகம் புலனாகிறது. AI குறியீடு உருவாக்குநர்கள் அதிகத் திறன் கொண்டவர்களாக மாறும்போது, துல்லியமான, இயந்திரம்-வாசிக்கக்கூடிய நோக்கத்தின் தேவை மேலும் அதிகரிக்கும்.

முக்கியக் கருத்து: தெளிவற்ற தூண்டுதல்களை (prompts) உறுதியான, ஆய்வு செய்யப்பட்ட விவரக்குறிப்புகளாக மாற்றுவது ஒரு கூடுதல் படிநிலையாகத் தோன்றலாம், ஆனால் இது யூகங்களை பொறுப்பான முடிவுகளாக மாற்றுகிறது.