Spec-Driven Development என்றால் என்ன?

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

அந்த ஏஜென்ட் கோட் எழுதுவதில் சிரமப்படவில்லை. உங்கள் நோக்கத்தைப் (intent) புரிந்துகொள்வதில்தான் அது சிரமப்பட்டது.

Spec-driven development இதைச் சரிசெய்கிறது. கோட் எழுதுவதற்கு ப்ராம்ப்ட் கொடுப்பதற்குப் பதிலாக, நீங்கள் முதலில் ஒரு spec உருவாக்குகிறீர்கள். இந்த spec என்பது ஒரு எழுதப்பட்ட திட்டமாகும். அது சரியாக இருக்கும் வரை நீங்கள் அந்தத் திட்டத்தைத் திருத்துகிறீர்கள். அதன் பின்னரே ஏஜென்ட்டை உருவாக்க அனுமதிக்கிறீர்கள்.

AWS Kiro மற்றும் GitHub spec-kit போன்ற புதிய கருவிகள் இதை எளிதாக்குகின்றன. ஆனால் இந்த யோசனை பழமையானது. இது ஒரு சிறந்த பொறியியல் முறை (engineering) மட்டுமே.

ஒரு சிறந்த spec மூன்று பகுதிகளைக் கொண்டது:

• Requirements: ஒரு அம்சம் (feature) என்ன செய்கிறது மற்றும் அதன் வெற்றியை எவ்வாறு அளவிடுவது என்பது பற்றியது. இது செயல்பாட்டை விவரிக்கிறது, கோடை அல்ல. • Design: தொழில்நுட்பத் திட்டம். இதில் architecture, data models மற்றும் constraints ஆகியவை அடங்கும். • Tasks: சிறிய, சோதனை செய்யக்கூடிய அலகுகள். இவை ஒரு ஏஜென்ட் ஒரே முயற்சியில் முடிப்பதற்கு ஏற்றவாறு எளிமையானவை.

ஒவ்வொரு பகுதியும் அடுத்த பகுதிக்கு அடிப்படையாக அமைகிறது. Requirements வடிவமைப்பிற்கு வழிகாட்டுகின்றன. Design பணிகளை உருவாக்குகிறது. Tasks ஏஜென்ட்டிற்கு வழிகாட்டுகின்றன.

கடந்த காலத்தில், கோட் எழுதுவது மெதுவாக இருந்தது. Specs எழுதுவது நேர விரயமாகத் தோன்றியது. இப்போது, AI சில நிமிடங்களில் கோட் எழுதிவிடுகிறது. தடையாக இருப்பது இனி டைப் செய்வது (typing) அல்ல. எதைச் சரியாக உருவாக்க வேண்டும் என்று தீர்மானிப்பதே இப்போது தடையாக உள்ளது.

ஒரு spec உங்கள் தவறுகளைக் குறைந்த செலவில் சரிசெய்யக்கூடிய இடத்திற்கு மாற்றுகிறது. ஒரு ஆவணத்தில் உள்ள தவறான வாக்கியத்தைச் சரிசெய்வது எளிது. ஆனால் ஒரு codebase-இல் உள்ள தவறான செயல்பாட்டை (implementation) மாற்றியமைப்பது அதிக செலவு பிடிக்கும் விஷயம்.

கோடை (code) ஆய்வு செய்வது கடினம். ஆசிரியர் என்ன சொல்ல வந்தார் என்பதை நீங்கள் reverse-engineer செய்ய வேண்டியிருக்கும். ஒரு spec-ஐ ஆய்வு செய்வது எளிது. கோட் உருவாவதற்கு முன்பே அதன் நோக்கத்தை நீங்கள் ஒப்புக்கொள்கிறீர்கள்.

இந்த முறை உங்கள் வேலையை விரிவுபடுத்தவும் (scale) உதவுகிறது. நீங்கள் வெவ்வேறு ஏஜென்ட்களுக்கு வெவ்வேறு பணிகளைக் கொடுக்கலாம். அவர்கள் அனைவரும் ஒரே பாதையில் செல்வதை உறுதி செய்ய அந்த spec ஒரு ஒப்பந்தமாக (contract) செயல்படுகிறது.

இந்த அணுகுமுறை எப்போதும் சரியான தீர்வாகாது.

  • சிறிய மாற்றங்களுக்கு இது தேவையில்லாத ஒன்று. ஒரு வரியின் மாற்றத்திற்காக நீங்கள் spec எழுதத் தேவையில்லை.
  • Specs காலாவதியாகலாம். கோட் மாறுகிறது ஆனால் spec மாறவில்லை என்றால், அந்த spec ஒரு பொய்யாகிவிடும்.
  • ஏஜென்ட்கள் எப்போதும் கீழ்ப்படியாது. ஒரு spec குழப்பத்தைக் குறைக்கிறது, ஆனால் நீங்கள் இன்னும் வெளியீட்டை (output) ஆய்வு செய்ய வேண்டும்.

உங்கள் நோக்கத்தைத் தெளிவாகக் காட்ட ஒரு spec-ஐப் பயன்படுத்துங்கள். தவறுகள் வெறும் வார்த்தைகளாக இருக்கும்போதே அவற்றைப் பிடிக்க இதைப் பயன்படுத்துங்கள்.

Source: https://dev.to/jcamarate/what-is-spec-driven-development-with-ai-coding-agents-56mc

Optional learning community: https://t.me/GyaanSetuAi