AI கோடிங் ஏஜெண்டுகளுக்கு ப்ராம்ப்ட்களை விட டெஸ்ட்கள் தான் அதிகம் தேவைப்படுகின்றன

நான் 25 ஆண்டுகளாக மென்பொருள் எழுதி வருகிறேன். எனது முழு வாழ்க்கைப் பயணத்திலும் கடந்த எட்டு மாதங்களில் ஏற்பட்ட மாற்றத்தை விட அதிக மாற்றம் எனது பணிப்பாய்வில் (workflow) ஏற்பட்டுள்ளது.

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

இப்போது நிலைமை மாறிவிட்டது. நவீன ஏஜெண்டுகள் ஒரு குறிப்பிட்ட சுழற்சியைப் (loop) பின்பற்றுகின்றன:

  • குறியீட்டைப் படிக்கின்றன (Read code).
  • குறியீட்டை மாற்றுகின்றன (Change code).
  • ஒரு கட்டளையை இயக்குகின்றன (Run a command).
  • எது தோல்வியடைந்தது என்று பார்க்கின்றன.
  • அதைச் சரிசெய்கின்றன.
  • மீண்டும் செய்கின்றன.

இந்தச் சுழற்சி மிகவும் சக்தி வாய்ந்தது, ஆனால் ஏஜெண்டுகள் விஷுவல் இன்டர்ஃபேஸ்களுடன் (visual interfaces) போராடுகின்றன. ஒரு பட்டன் வேலை செய்கிறதா என்று பார்ப்பதற்காக, ஒரு UI-இல் நம்பகமான முறையில் கிளிக் செய்ய அவற்றால் முடியாது.

நான் எனது அணுகுமுறையை மாற்றிக்கொண்டேன். புதிய அம்சங்களை முதலில் command line மூலம் இயங்கும் வகையில் உருவாக்குகிறேன்.

ஒரு ஏஜெண்ட்டிடம் "இந்தத் திரையைப் பார்" என்று கேட்பதற்குப் பதிலாக, நான் அதற்கு ஒரு கட்டளையைத் தருகிறேன்:

  • npm run test:feature-x
  • node scripts/run-new-feature-client.js

ஏஜெண்டுகளுக்குக் கட்டளைகள் (commands) மிகவும் பிடிக்கும். இது அவற்றுக்குச் செயல்படுத்தக்கூடிய ஒரு பின்னூட்டச் சுழற்சியை (executable feedback loop) வழங்குகிறது.

எனது தற்போதைய பணிப்பாய்வு (workflow) இவ்வாறு அமைகிறது:

  • ஒரு Markdown கோப்பில் அம்சத்தைத் திட்டமிடுதல்.
  • ஒரு test client அல்லது unit test உருவாக்குதல்.
  • தெளிவான test cases-களை வரையறுத்தல்.
  • ஏஜெண்ட் அம்சத்தை செயல்படுத்த அனுமதிக்கவும்.
  • ஏஜெண்ட் மீண்டும் மீண்டும் டெஸ்ட்களை இயக்க அனுமதிக்கவும்.
  • முடிவுகளை ஆய்வு செய்தல்.

ஒரு எச்சரிக்கை: நீங்கள் ஒரு ஏஜெண்ட்டிடம் "அனைத்து டெஸ்ட்களும் வெற்றிபெறச் செய்" (make all tests pass) என்று சொன்னால், அது அதைச் செய்துவிடும். வெற்றி பெறுவதற்காக அது மென்பொருள் பொறியியல் விதிமீறல்களைச் (software engineering crimes) செய்யக்கூடும். தோல்விச் செய்தியைத் தடுப்பதற்காக, அது பலவீனமான டெஸ்ட்களை எழுதலாம் அல்லது பிழைகளை மறைக்க try/catch பிளாக்குகளைப் பயன்படுத்தலாம்.

இதனால்தான் டெஸ்ட் வரையறுப்பதே (test definition) எனது மிக முக்கியமான கைமுறைப் பணியாகும் (manual task). நீங்கள் இதைக் கேட்க வேண்டும்:

  • இந்த டெஸ்ட் ஒரு உண்மையான பயன்பாட்டுச் சூழலை (real use case) பிரதிபலிக்கிறதா?
  • இது ஒரு உண்மையான பின்னடைவை (real regression) கண்டறியுமா?
  • இது மிகவும் குறுகியதா?

AI யுகத்தில், Test-Driven Development (TDD) என்பது வெறும் பாதுகாப்பு வலை மட்டுமல்ல. அது ஒரு ஸ்டீயரிங் வீல் (steering wheel) போன்றது. டெஸ்ட்கள் இல்லையென்றால், ஒரு ஏஜெண்ட் நம்பத்தகுந்ததாகத் தோன்றும் குறியீட்டை (plausible code) உருவாக்கும். நல்ல டெஸ்ட்கள் இருந்தால், ஒரு ஏஜெண்டிற்கு அளவிடக்கூடிய இலக்கு (measurable target) இருக்கும்.

மற்றொரு குறிப்பு: டெஸ்ட் வெளியீடுகளுக்கு (test outputs) கட்டமைக்கப்பட்ட கோப்புகளைப் (structured files) பயன்படுத்துங்கள். சாட்டில் (chat) மிகப்பெரிய லாக் (logs) கோப்புகளைக் கொட்டுவதற்குப் பதிலாக, உங்கள் ஸ்கிரிப்ட்கள் ஒரு ஃபோல்டரில் JSON அல்லது Markdown கோப்புகளாக எழுதும்படி செய்யுங்கள்.

இது ஏன் உதவுகிறது என்றால்:

  • ஏஜெண்ட் நேரடியாகத் தொடர்புடைய தரவுகளுக்குச் செல்கிறது.
  • சூழல் (Context) சிறியதாகவே இருக்கும்.
  • டோக்கன் பயன்பாடு குறைகிறது.
  • இது பணத்தைச் சேமிக்கிறது.

AI ஏஜெண்டுகள் டெவலப்பர்களுக்குப் பதிலாக வருவதில்லை. அவை நமது கவனத்தை மாற்றுகின்றன. நாம் குறியீட்டைத் தட்டச்சு செய்வதில் குறைவான நேரத்தையும், பின்வருவனவற்றில் அதிக நேரத்தையும் செலவிடுகிறோம்:

  • சிக்கல்களைத் தெளிவாக விவரித்தல்.
  • பின்னூட்டச் சுழற்சிகளை (feedback loops) உருவாக்குதல்.
  • தரமான டெஸ்ட்களை வரையறுத்தல்.
  • கட்டமைப்பை (architecture) ஆய்வு செய்தல்.

AI மேம்பாட்டின் எதிர்காலம் சிறந்த ப்ராம்ப்ட்களை (prompts) எழுதுபவருக்குச் சொந்தமானது அல்ல. சிறந்த பின்னூட்டச் சுழற்சிகளை (feedback loops) உருவாக்குபவருக்கே அது சொந்தமானது.

Source: https://dev.to/stoefln6/ai-coding-agents-need-tests-more-than-prompts-11pm

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