𝗦𝗽𝗲𝗰-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗶𝗻 𝟮𝟬𝟮𝟲
AI ஏஜெண்டுகள் குறியீடு (code) எழுதுவதில் சிறந்தவை. ஆனால் நீங்கள் எதைச் சொல்ல வருகிறீர்கள் என்பதை ஊகிப்பதில் அவை மிகவும் மோசமானவை.
இதனால்தான் 2026-இல் Spec-Driven Development (SDD) ஒரு தரநிலையாக உள்ளது.
கடந்த காலத்தில், மக்கள் "vibe coding" முறையைப் பின்பற்றினர். அதாவது, ஒரு AI-க்கு ஒரு தெளிவற்ற தூண்டுதலை (loose prompt) வழங்கி, அது எதைக் கொடுக்கிறதோ அதை அப்படியே வெளியிடுவது (ship). இது முன்மாதிரிகளுக்கு (prototypes) வேலை செய்யும். ஆனால் பராமரிப்பு தேவைப்படும் உண்மையான மென்பொருள்களுக்கு இது தோல்வியடையும்.
SDD என்பது கட்டமைப்பதற்கான ஒரு ஒழுங்குமுறை சார்ந்த வழியாகும். நீங்கள் விவரக்குறிப்பை (specification) உண்மையான ஆதாரமாக (source of truth) கருதுகிறீர்கள். விவரக்குறிப்பு உங்கள் நோக்கத்தை அறிவிக்கிறது. குறியீடு அதைச் செயல்படுத்துகிறது.
திறன்களில் ஏற்படும் மாற்றம் தெளிவாக உள்ளது: நீங்கள் குறியீடு தட்டச்சு செய்வதில் நேரத்தைச் செலவிடுவதை நிறுத்துகிறீர்கள். ஒரு இயந்திரத்தால் தவறாகப் புரிந்துகொள்ள முடியாத அளவிற்கு உங்கள் நோக்கத்தை மிகத் தெளிவாக வரையறுப்பதில் நேரத்தைச் செலவிடத் தொடங்குகிறீர்கள்.
குழுக்கள் SDD-ஐ எவ்வாறு பயன்படுத்துகின்றன:
- Spec-First: விவரக்குறிப்புகள் முதல் வரைவை வழிநடத்துகின்றன. குறியீடு பின்னர் மாறலாம். இதை முன்மாதிரிகளுக்குப் பயன்படுத்தவும்.
- Spec-Anchored: விவரக்குறிப்புகளும் குறியீடும் இணைந்து வளர்ச்சியடைகின்றன. அவை சீராக இருப்பதை தானியங்கி சோதனைகள் (automated tests) உறுதி செய்கின்றன. பெரும்பாலான உற்பத்தி அமைப்புகளுக்கு (production systems) இதுவே சிறந்த தேர்வாகும்.
- Spec-as-Source: மனிதர்கள் விவரக்குறிப்பை மட்டுமே திருத்துகிறார்கள். AI அனைத்து குறியீடுகளையும் உருவாக்குகிறது. இதற்கு உங்கள் கருவிகள் மீது அதிக நம்பிக்கை தேவை.
SDD பணிப்பாய்வு (Workflow):
- Constitution: திட்ட விதிகளை வரையறுக்கவும் (languages, frameworks, testing).
- Specify: பயனர் கதைகளைப் (user stories) பயன்படுத்தி 'என்ன' மற்றும் 'ஏன்' என்பதை வரையறுக்கவும்.
- Clarify: தெளிவற்ற தன்மையை நீக்க ஏஜென்ட் கேள்விகளைக் கேட்கிறது.
- Plan: கட்டமைப்பு (architecture) மற்றும் தரவு மாதிரிகளை (data models) வரையறுக்கவும்.
- Tasks: திட்டத்தை சிறிய, வெளியிடும் தகுதியுள்ள கூறுகளாகப் பிரிக்கவும்.
- Implement: பணிகளைச் செயல்படுத்தவும்.
- Analyze: திட்டமும் பணிகளும் அசல் விவரக்குறிப்புடன் ஒத்துப்போகின்றனவா என்று சரிபார்க்கவும்.
ஒரு பொன் விதி: விவரக்குறிப்பிலிருந்து நேரடியாக குறியீட்டிற்குச் செல்லாதீர்கள். எப்போதும் திட்டத்தையும் பணிகளையும் முதலில் மதிப்பாய்வு செய்யுங்கள்.
விவரக்குறிப்புகளைச் செயல்படுத்தக்கூடியதாக மாற்ற, EARS (Easy Approach to Requirements Syntax) முறையைப் பயன்படுத்தவும். தெளிவற்ற வாக்கியங்களுக்குப் பதிலாக, பின்வரும் வடிவங்களைப் பயன்படுத்தவும்:
- WHEN [event] THE system SHALL [action].
- IF [condition] THEN [result].
இது உங்கள் தேவைகளை நேரடியாக சோதனைத் தரவுகளுடன் (test cases) இணைக்க உதவுகிறது.
கவனிக்க வேண்டிய கருவிகள்:
- GitHub Spec Kit: Open-source மற்றும் model-agnostic.
- AWS Kiro: AWS-native நிறுவனங்களுக்குச் சிறந்தது.
- Claude Code (cc-sdd): டெர்மினல் சார்ந்த பணிப்பாய்வுகளுக்குச் சிறந்தது.
- Cursor: IDE-முதல் UX-க்குச் சிறந்தது.
சுருக்கமாகச் சொன்னால்: சிந்தனை நிகழும் இடம் விவரக்குறிப்புதான். உங்கள் குறியீட்டை எழுத நீங்கள் AI-ஐப் பயன்படுத்தினால், நீங்கள் உருவாக்கும் மிக முக்கியமான விஷயம் உங்கள் விவரக்குறிப்புதான்.
Optional learning community: https://t.me/GyaanSetuAi