Prompts என்பவை ஆலோசனைகள். Hooks என்பவை உறுதியான கட்டுப்பாடுகள்.

பல மாதங்களாக, நான் Claude Code-ஐ ஒரு இளநிலை மென்பொருள் உருவாக்குநரைப் (junior developer) போலக் கருதினேன்; அவனுக்குத் தெளிவான அடிப்படை விதிகள் தேவை என்று நினைத்தேன். எனது திட்டக் குறிப்புகள் (project instructions) மிகத் தெளிவாக இருந்தன: ஒருபோதும் force-push செய்யக்கூடாது, கிளைகளை (branches) நீக்கக்கூடாது, அழிவை ஏற்படுத்தும் கட்டளைகளை (destructive commands) இயக்கக்கூடாது. பெரும்பாலான மாலை நேரங்களில், அது சரியாகவே வேலை செய்தது. அந்த ஏஜென்ட் (agent) சோதனைகளை (tests) எழுதின, செயல்பாடுகளை (functions) மாற்றியமைத்தது (refactored), மற்றும் git வரலாற்றில் தலையிடாமல் இருந்தது. பின்னர் ஒரு rebase செயல்முறை தவறாகியபோது நிலைமை மாறியது.

Context window முழுவதும் git பிழை வெளியீடுகளால் (error output) நிரம்பியது. முரண்பாட்டுக் குறிகள் (Conflict markers), detached HEAD செய்திகள் மற்றும் கிளை விலகல் எச்சரிக்கைகள் (branch divergence warnings) ஒவ்வொன்றாகத் குவிந்தன. அந்த இரைச்சலுக்கு அடியில், force-push செய்வதைத் தவிர்க்குமாறு நான் கொடுத்த கண்ணியமான அறிவுறுத்தல் புதைந்து போயிருந்தது. அந்த மாடலுக்கு (model), அந்தத் திரையில் கடைசியாகத் தெரிந்த மற்றும் முக்கியமான உரை அந்தப் பிழைத் தொடராகவே இருந்தது. புள்ளிவிவரக் கவனம் (Statistical attention) கொள்கையை விட மேலோங்கியது. அந்த ஏஜென்ட், இன்னும் commit செய்யப்படாத இரண்டு மணிநேர உள்ளூர் மாற்றங்களை அழிக்கும் ஒரு கட்டளையைச் செயல்படுத்தியது. அது உள்நோக்கத்துடன் செய்யப்பட்டது அல்ல; அது கவனச்சிதறலால் நடந்தது. அந்த வேறுபாடு முக்கியமானது. ஒரு LLM வன்மத்தினால் விதிகளை மீறுவதில்லை. context window-வில் உள்ள ஒரு சத்தமான வடிவம் (pattern), முந்தைய அறிவுறுத்தலைத் தற்காலிகமாகத் தள்ளிவிடுவதால் அது விதிகளை மீறுகிறது.

அந்தச் சம்பவம் ஏஜென்ட் பாதுகாப்பு (agent safety) பற்றிய எனது சிந்தனையை மாற்றியது. தொண்ணூற்று ஒன்பது சதவீதம் நேரங்களில் வேலை செய்யும் ஒரு பாதுகாப்புத் தடுப்பு (guardrail) என்பது ஒரு பொறுப்பற்ற விஷயம் (liability). ஒரு தோல்வி உங்கள் நேரம், பணம் அல்லது தயாரிப்புத் தரவை (production data) இழக்கச் செய்கிறது என்றால், அதை வெறும் prompt-க்குள் மட்டும் விட்டுவிட முடியாது. மாதிரியின் (model) சிந்தனைச் சுழற்சிக்கு வெளியே ஒரு கட்டாயச் செயல்பாட்டை (enforcement) நீங்கள் உருவாக்க வேண்டும்.

Claude Code hooks சரியாக இதையே தீர்க்கின்றன. அவை மூன்று குறிப்பிட்ட தருணங்களில் கருவி அழைப்புகளை (tool calls) இடைமறிக்கும் சிறிய ஸ்கிரிப்ட்கள்: ஒரு கருவி இயங்குவதற்கு முன் (PreToolUse), ஒரு கருவி முடிந்த பிறகு (PostToolUse), மற்றும் ஏஜென்ட் தான் முடித்துவிட்டதாகத் தீர்மானிக்கும் போது (Stop). அவை வெளிப்புறக் குறியீடாக (external code) இயங்குவதால், மாதிரியின் நினைவாற்றல், மனநிலை அல்லது context அழுத்தத்தைச் சார்ந்து இருப்பதில்லை. நீங்கள் கொடுத்த ஒவ்வொரு அறிவுறுத்தலையும் அந்த மாடல் மறக்கலாம்; ஆனால் hook எப்போதும் "இல்லை" என்று சொல்லும்.

அந்த இழந்த மாலை நேரத்திற்குப் பிறகு நான் உருவாக்கிய கட்டமைப்பை (harness) இங்கே காணலாம்.

The Guard Hook: பாதிப்பு ஏற்படும் முன் இடைமறித்தல்

எனது PreToolUse hook, ஒரு shell கட்டளையைத் தொடங்குவதற்கு முன் ஒவ்வொரு Bash கட்டளையையும் ஆய்வு செய்கிறது. அழிவை ஏற்படுத்தும் முறைகளின் (destructive patterns) ஒரு கடுமையான தடைப் பட்டியலை (denylist) நான் வைத்திருக்கிறேன். கட்டளைச் சரம் ஏதேனும் ஆபத்தான ஒன்றோடு பொருந்தினால், hook அந்தச் செயல்பாட்டைத் தடுத்துவிட்டு, நேரடியாக ஏஜென்ட்டிடம் பிழையைத் திருப்பி அனுப்புகிறது.

நான் தடுக்கும் முறைகள் எளிமையானவை மற்றும் தெளிவானவை:

  • git push --force அல்லது நான் இன்னும் நம்பாத எந்தவொரு force-with-lease வகையும்
  • git reset --hard
  • rm -rf

இது ஒரு மேம்பட்ட பாதுகாப்பு ஆராய்ச்சி அல்ல. இது ஒரு இருக்கைப்பட்டை (seatbelt) போன்றது. ஆனால், தடுப்பு ஏற்பட்ட பிறகு என்ன நடக்கிறது என்பதுதான் முக்கியமான விஷயம்.

நான் ஒருபோதும் வெறும் “Blocked” என்று மட்டும் சொல்ல மாட்டேன். ஒரு நேரடியான மறுப்பு ஏஜென்ட்டை குழப்பமடையச் செய்து, அதே அழிவை ஏற்படுத்தும் கட்டளையின் பல்வேறு வடிவங்களை அது மீண்டும் மீண்டும் முயற்சிக்கும் ஒரு சுழற்சியில் சிக்க வைக்கலாம். அதற்குப் பதிலாக, பிழைச் செய்தியில் ஒரு தப்பிக்கும் வழியையும் (escape route) நான் வழங்குகிறேன். ஒரு hard reset-ஐ hook கண்டறியும்போது, அது ஏஜென்ட்டிடம் இவ்வாறு கூறுகிறது: “commit செய்யப்படாத வேலைகளைப் பாதுகாக்க இந்தக் கட்டளை தடுக்கப்பட்டுள்ளது. முதலில் ஒரு checkpoint-ஐ commit செய்யவும், பின்னர் மீண்டும் முயற்சிக்கவும்.” அந்த ஒரு கூடுதல் வாக்கியம் ஏஜென்ட்டின் நடத்தையை முற்றிலும் மாற்றுகிறது. அது சேதத்தை சரிசெய்ய முயற்சிப்பதிலிருந்து மாறி, பாதுகாப்பை உருவாக்கத் தொடங்குகிறது. இந்த hook வெறும் சுவர் மட்டுமல்ல; அது ஒரு போக்குவரத்து கட்டுப்பாட்டுச் சிக்னல் (traffic control).

Shell கட்டளைகளுக்கு allowlist-ஐ விட denylist-ஐயே நான் தேர்ந்தெடுத்தேன். முதலில், பாதுகாப்பான git துணைக்கட்டளைகளின் (subcommands) ஒரு குறிப்பிட்ட தொகுதியை மட்டும் அனுமதிப்பதைப் பற்றி யோசித்தேன். அது விரைவாகத் தோல்வியடைந்தது. ஏஜென்ட்கள் கற்பனைத்திறனுடன் மிகத் துல்லியமாகச் செயல்படும் தன்மை கொண்டவை. அவை நிலையைச் சரிபார்க்க git stash push -m "wip" அல்லது git branch --show-current போன்ற முறையான ஆனால் எதிர்பாராத கட்டளைகளை இயக்கும். மாடல் ஒரு செல்லுபடியாகும் ஆனால் பட்டியலில் இல்லாத கட்டளையை உருவாக்கும் தருணத்திலேயே, ஒரு allowlist சாதாரணப் பணிப்பாய்வை (workflow) உடைத்துவிடும். உண்மையாகவே அழிவை ஏற்படுத்தும் முறைகளின் ஒரு சிறிய, தேர்ந்தெடுக்கப்பட்ட denylist, எல்லைகளைப் பாதுகாக்கும் அதே வேளையில் ஏஜென்ட் இயங்குவதற்கு இடமளிக்கிறது.

The Formatter Hook: தேவையற்ற வேலைகளைத் தானியக்கமாக்குதல்

"கோப்பைத் திருத்திய பிறகு எப்போதும் formatter-ஐ இயக்கவும்" என்று ஏஜென்ட்டிடம் சொல்வதற்காக நான் எனது prompt tokens-களை வீணடித்தேன். அது பாதி நேரங்களில் மறந்துவிடும். மற்ற பாதி நேரங்களில், அது தற்காலிகமாக நின்று, format செய்ய வேண்டுமா என்று கேட்கும்; இது ஒரே ஒரு சரியான விடை மட்டுமே உள்ள ஒரு முடிவிற்காக ஒரு tool call-ஐ வீணாக்குகிறது.

இப்போது நான் அதை ஒரு PostToolUse hook மூலம் கையாளுகிறேன். ஏஜென்ட் ஒரு கோப்பைத் திருத்திய பிறகு, hook அந்த கோப்பின் நீட்சியை (extension) ஆய்வு செய்கிறது. அது Python என்றால், Ruff-ஐ இயக்கும். அது JavaScript அல்லது TypeScript என்றால், Prettier-ஐ இயக்கும். அது Go என்றால், gofmt-ஐ இயக்கும். அந்த formatter இருப்பதை ஏஜென்ட் அறியத் தேவையில்லை. அதற்குத் தேவையும் இல்லை.

இதை prompt-லிருந்து வெளியேற்றியது இரண்டு விளைவுகளை ஏற்படுத்தியது. முதலாவதாக, மாடலின் அறிவாற்றல் சுமையை (cognitive load) அதிகரிக்காமல் குறியீடு (code) சீராகத் தூய்மையாக இருக்கிறது. இரண்டாவதாக, எனது திட்டக் குறிப்புகள் (project instructions) சுருங்கிவிட்டன. ஒரு prompt-லிருந்து நீங்கள் நீக்கும் ஒவ்வொரு “always” மற்றும் “never” என்பதும், மாடல் உண்மையான சிக்கலைத் தீர்ப்பதற்குப் பயன்படுத்தக்கூடிய ஒரு token ஆகும். மாறாத விதிகளுக்கு (invariant) hook பொறுப்பு; நோக்கத்திற்கு (intent) prompt பொறுப்பு.

The Quality Gate: “முடிந்தது” என்பதை மறுவரையறை செய்தல்

ஏஜென்ட் தனது பணியை முடித்துவிட்டதாக முடிவு செய்து, session-ஐ முடிக்க முயலும்போது Stop hook இயங்குகிறது. நான் அதை அனுமதிக்கவில்லை. அதற்குப் பதிலாக, அந்த hook முழுமையான test suite-ஐ இயக்குகிறது. ஏதேனும் ஒரு test தோல்வியடைந்தால், hook அந்த stop command-ஐத் தடுத்து, தோல்விக்கான வெளியீட்டை (failure output) ஏஜென்ட்டிற்குத் திருப்பி அனுப்புகிறது.

இது முடிவடைதலின் (completion) வரையறையையே மாற்றுகிறது. “முடிந்தது” (Done) என்பது இனி மாடலுக்கு ஏற்படும் ஒரு உணர்வு அல்ல. அது அளவிடக்கூடிய ஒரு நுழைவாயில் (measurable gate). harness குறியீடு (code) வேலை செய்வதை உறுதி செய்த பின்னரே ஏஜென்ட் பணியை முடிக்க முடியும். நடைமுறையில், இது ஒரு நெருக்கமான feedback loop-ஐ உருவாக்குகிறது. ஏஜென்ட் குறியீட்டை எழுதுகிறது, அது முடிந்துவிட்டதாக நினைக்கிறது, stop button-ஐ அழுத்துகிறது, மேலும் உடனடியாக ஒரு pytest traceback-ஐப் பார்க்கிறது. பின்னர் அது தானாகவே திருத்திக் கொள்கிறது (self-corrects), import error அல்லது broken assertion-ஐச் சரிசெய்கிறது, மேலும் மீண்டும் நிறுத்த முயற்சிக்கிறது. மனிதத் தலையீடு இன்றி ஏஜென்ட்கள் இந்த loop-க்குள் மூன்று அல்லது நான்கு முறை சுழல்வதைக் கண்டிருக்கிறேன். harness தரத்தை உறுதி செய்கிறது; மாடல் திருத்தங்களை (patches) வழங்குகிறது.

இது ஏஜென்ட் இன்ஜினியரிங் (Agent Engineering) பற்றி என்ன கற்பிக்கிறது

நம்பகமான தன்னாட்சி அமைப்புகளை (autonomous systems) உருவாக்குவதற்குச் சிந்தனை முறையில் ஒரு மாற்றம் தேவைப்படுகிறது. நீங்கள் நீண்ட prompts எழுதுவதிலிருந்து, வலுவான harnesses-களை உருவாக்குவதை நோக்கி நகர வேண்டும்.

விதிகளின் அமலாக்கத்திற்கு (enforcement) hooks-களையும், கொள்கைகளுக்கு (policy) prompts-களையும் பயன்படுத்தவும். ஒரு விதி நூறு சதவீதம் எப்போதும் கடைபிடிக்கப்பட வேண்டும் என்றால், அது குறியீட்டில் (code) இருக்க வேண்டுமே தவிர, இயல்பான மொழியில் (natural language) இருக்கக்கூடாது. Prompts ஆகியவை தெளிவற்ற தன்மை (ambiguity), ரசனை (taste) மற்றும் கட்டமைப்பு (architecture) ஆகியவற்றில் சிறந்து விளங்குகின்றன. ஆனால் அவை மாறாத விதிகளில் (invariants) மோசமாகச் செயல்படுகின்றன. ஒரு தவறு உங்கள் ஒரு மதிய நேரத்தை மீட்பதற்கோ அல்லது அதைவிட மோசமாக, production uptime-ஐப் பாதிப்பதற்கோ காரணமாகும் என்றால், ஒரு hook-ஐ எழுதுங்கள்.

குறுகிய prompts சிறந்த முடிவுகளைத் தரும். நீங்கள் இயந்திரத்தனமான விதிகளை (mechanical rules) ஸ்கிரிப்டுகளுக்கு (scripts) மாற்றும்போது, மாடல் நினைவில் கொள்ள வேண்டியதும், முரண்பட வேண்டியதும் குறைகிறது. ஏஜென்ட்டின் context window என்பது ஒரு அரிய வளம். அதை formatting reminders கொண்டு நிரப்பாதீர்கள்.

இறுதியாக, உங்கள் பங்கு மாறிக்கொண்டிருக்கிறது என்பதை ஏற்றுக்கொள்ளுங்கள். ஏஜென்ட்கள் தன்னாட்சியைப் பெறும்போது, மனிதனின் வேலை உள்ளடக்கத்தை உருவாக்குவதிலிருந்து (generating content) பாதுகாப்பு வளையங்களை (guardrails) வடிவமைப்பதற்கோ மாறுகிறது. மாடல் எதைத் தொடலாம், எப்போது முடிக்கலாம் மற்றும் விஷயங்கள் தவறாகும்போது எப்படி நடந்து கொள்ள வேண்டும் என்பதைத் தீர்மானிக்கும் harness-ஐ நீங்கள் உருவாக்குகிறீர்கள். அது இன்ஜினியரிங் (engineering), prompting அல்ல.

இந்த அணுகுமுறைக்குத் தூண்டுதலாக இருந்த மூல ஆதாரம் மற்றும் கூடுதல் செயலாக்க விவரங்களை இங்கே காணலாம்.

நீங்கள் AI ஏஜென்ட்களுடன் இணைந்து செயல்படுகிறீர்கள் மற்றும் பிற நிபுணர்களுடன் கருத்துக்களைப் பகிர்ந்து கொள்ள விரும்பினால், GyaanSetu கற்றல் சமூகத்தை இங்கே காணலாம்.