Anthropic இந்த மாதம் Claude Code பதிப்பு 2.1.207-ஐ வெளியிட்டது. அதன் வெளியீட்டுக் குறிப்புகளில் (release notes), AI-உதவி பெறும் மேம்பாட்டு முறையின் விதிகளை மாற்றியமைக்கும் ஒரு மாற்றம் மறைந்துள்ளது. இந்த ஏஜென்ட்டைத் தாங்கி நிற்கும் மூன்று முக்கிய கிளவுட் தளங்களான Amazon Bedrock, Google Vertex AI மற்றும் Microsoft Azure Foundry ஆகியவற்றில் இப்போது Auto mode இயல்பான அமைப்பாக (default) மாற்றப்பட்டுள்ளது. இயந்திரத்தால் எழுதப்பட்ட குறியீடு (code) உங்கள் ரெப்போசிட்டரிக்குள் (repository) நுழையும்போது, அதன் ஒப்புதல் சங்கிலிக்கு (approval chain) யார் பொறுப்பு என்பதை இந்த ஒற்றை மாற்றம் மாற்றியமைக்கிறது.

பழைய முறை தவறாக இருந்தது

இந்த வெளியீடு வரை, Claude Code இயல்பாக manual mode-இல் தான் இயங்கியது. அந்த ஏஜென்ட் ஒரு கோப்புத் திருத்தத்தை (file edit) தயார் செய்யும், ஒரு ஷெல் கட்டளையை (shell command) உருவாக்கும் அல்லது ஒரு git commit-ஐ வரிசையில் வைக்கும், அதன் பிறகு அப்படியே நின்றுவிடும். அந்த மாற்றங்களை (diff) ஒரு மனிதன் படித்து, கட்டளையைச் சரிபார்த்து, 'approve' என்பதைக் கிளிக் செய்யும் வரை அது காத்திருக்கும். இதன் பின்னணியில் இருந்த தியரி சரியானதுதான்: ஒரு மனிதன் கையெழுத்திடாமல் AI-யை ஒருபோதும் தயாரிப்பு குறியீட்டை (production code) தொட விடக்கூடாது என்பதுதான் அது.

ஆனால் யதார்த்தம் வேறாக இருந்தது. Manual mode-இல் இருந்த பயனர்களில் 93% பேர், ப்ராம்ப்ட்களைப் (prompts) படிக்காமலேயே அவற்றை அனுமதிப்பதாக Anthropic கண்டறிந்தது. டெவலப்பர்கள் அந்த ஒப்புதல் திரையை ஒரு சரிபார்ப்புப் புள்ளியாகப் பார்க்காமல், ஒரு இடையூறாகவே கருதினர். அவர்கள் தங்கள் வேலையின் வேகத்தைத் தொடர, மிக வேகமாக "yes" என்பதைக் கிளிக் செய்தனர், இது அந்த கைமுறைத் தடையைத் (manual gate) பயனற்றதாக்கியது. அனைவரும் தவிர்த்துச் செல்லும் ஒரு பாதுகாப்புக்கட்டுப்பாடு, உண்மையில் ஒரு கட்டுப்பாடாகாது. அது பாதுகாப்பாகத் தோற்றமளிக்கும் ஒரு இடையூறு மட்டுமே.

Auto mode எவ்வாறு மனிதர்களின் கிளிக் செய்வதை மாற்றுகிறது

Auto mode அந்தத் தானியங்கி ஒப்புதல் முறையை ஒரு இரண்டாவது AI மாடலால் (classifier) மாற்றுகிறது. இந்த classifier, ஏஜென்ட் மேற்கொள்ள முயற்சிக்கும் ஒவ்வொரு செயலையும் அது செயல்படுத்துவதற்கு முன்பே ஆய்வு செய்கிறது. அந்தப் படிநிலை அசல் பணியுடன் இணக்கமாக இருக்கிறதா மற்றும் ஏஜென்ட் பாதையிலிருந்து விலகிச் செல்கிறதா என்பதை இது சரிபார்க்கிறது. Classifier அந்தச் செயலை அனுமதித்தால், ஏஜென்ட் உடனடியாகத் தொடரும். எந்தத் தொந்தரவும் இல்லை, எந்த பாப்-அப்பும் (popup) இல்லை, நீங்கள் மதிய உணவு முடிக்கும் வரை காத்திருக்க வேண்டிய அவசியமும் இல்லை.

இது ஒரு வித்தியாசமான பாதுகாப்பு வலை. ஒரு classifier அதிகாலை 2 மணிக்குச் சோர்வடையாது. ஒரு காலக்கெடு நெருங்குவதால் அது வாசிப்பதைத் தவிர்க்காது. மேலும், முதல் செயலுக்கு எவ்வளவு முக்கியத்துவம் அளிக்கிறதோ, அதே போன்ற தீவிரமான ஆய்வை நூறாவது செயலுக்கும் அது அளிக்கும். சோர்வடைந்த ஒரு பொறியாளரால் இதைச் செய்ய முடியாது.

ஒரு நிர்வாக மாற்றத்தின் தலைகீழ் மாற்றம்

இங்குள்ள ஆழமான மாற்றம் என்பது இயல்பான அமைப்புகள் (defaults) மற்றும் பொறுப்புணர்வு பற்றியது. 2.1.207 பதிப்பிற்கு முன்பு, குழுக்கள் தாங்களாகவே முன்வந்து auto mode-ஐத் தேர்ந்தெடுக்க வேண்டும். இப்போது நிலைமை தலைகீழாக மாறியுள்ளது: அதை முடக்குவதற்கு நீங்கள் வெளிப்படையான நடவடிக்கை எடுக்க வேண்டும். உங்கள் நிறுவனம் நிதி அல்லது சுகாதாரத் துறையில் ஒழுங்குமுறைத் தரவுகளைக் (regulated data) கையாளுகிறதென்றால், இது ஒரு சிறிய UX மாற்றம் அல்ல. இது ஒரு கொள்கை சார்ந்த நிகழ்வு (policy event). யாராவது இந்த அம்சத்தை வெளிப்படையாக முடக்கவில்லை என்றால், தன்னாட்சி முறையில் செய்யப்படும் commits ஏற்கனவே உங்கள் ரெப்போசிட்டரிகளில் வந்து சேரக்கூடும் என்பதை உங்கள் இணக்கக் குழு (compliance team) தெரிந்து கொள்ள வேண்டும்.

நீங்கள் இப்போது உடனடியாக என்ன செய்ய வேண்டும்

முதலில், உங்கள் தற்போதைய நிலையைச் சரிபார்க்கவும் (audit). உங்கள் சமீபத்திய லாக்ஸ்கள் (logs) மற்றும் git வரலாற்றைத் தோண்டிப் பார்க்கவும். Claude Code மூலம் செய்யப்பட்ட commits காணப்பட்டாலும், அந்தச் அமர்வின் பதிவுகளில் (session records) அதற்கு இணையான மனித ஒப்புதல் ப்ராம்ப்ட்கள் இல்லை என்றால், auto mode ஏற்கனவே செயல்பாட்டில் உள்ளது என்று அர்த்தம். உங்கள் பழைய கட்டமைப்பு அப்படியே தொடரும் என்று assumption செய்து கொள்ளாதீர்கள்.

உங்களுக்கு மீண்டும் manual control தேவைப்பட்டால், பழைய முறைகள் இனி வேலை செய்யாது என்பதைத் தெரிந்து கொள்ளுங்கள். இந்த நடத்தையை மாற்றியமைத்த முந்தைய environment variables-களுக்கான ஆதரவை Anthropic நீக்கிவிட்டது. இப்போது நீங்கள் உங்கள் managed settings கோப்பில் disableAutoMode-ஐ அமைக்க வேண்டும். உங்கள் shell configs அல்லது container images-களில் உள்ள பழைய மாற்று வழிகள் (workarounds) அமைதியிலேயே தோல்வியடையும், எனவே மேம்படுத்திய பிறகு உங்கள் deployment pipelines-களைச் சரிபார்க்கவும்.

உங்களால் classifier-ஐ நுணுக்கமாக மாற்றியமைக்க (fine-tune) முடியாது. அதன் தீவிரத்தன்மை அல்லது இடர் வரம்பிற்கான (risk threshold) கட்டுப்பாடுகள் எதுவும் இல்லை. உங்கள் ஒரே நடைமுறைக்கட்டுப்பாடு அணுகல் கட்டுப்பாடுகள் (access controls) மட்டுமே. பாதிப்பு எல்லையை (blast radius) குறைக்கவும். ஏஜென்ட்டை குறிப்பிட்ட கோப்பகங்களுக்குள் (directories) மட்டும் கட்டுப்படுத்தவும். அதற்குத் தேவையான குறைந்தபட்ச அனுமதிகளுடன் கூடிய குறுகிய கால அடையாளச் சான்றுகளை (short-lived credentials) வழங்கவும். ஒருவேளை classifier ஒரு தவறான செயலைக் கண்டறியத் தவறினால் கூட, நிர்வாகத் திறன்கள் (admin keys) கொண்ட ஒரு ஏஜென்ட்டை விட, வரையறுக்கப்பட்ட அதிகாரங்களைக் கொண்ட ஒரு ஏஜென்ட் மிகக் குறைந்த சேதத்தையே ஏற்படுத்தும்.

Auto mode எங்கு பயனுள்ளதாக இருக்கிறது

மனிதர்களின் நேரத்தைச் செலவிடத் தேவையில்லாத பணிகளுக்கு இது பெரும் வேகத்தைத் தருகிறது. ஆபத்து குறைவாகவும், பணித் தெளிவுடனும் இருக்கும் திரும்பத் திரும்பச் செய்யப்படும் பணிகளில் Auto mode சிறப்பாகச் செயல்படும். உங்கள் linter விதிகளைப் புதுப்பித்த பிறகு, நூற்றுக்கணக்கான கோப்புகளில் ஒரு formatting pass செய்வதைக் கருத்தில் கொள்ளுங்கள். அல்லது ஒரு பாதுகாப்பு எச்சரிக்கை வந்தவுடன், ஒரு patch-level dependency-யைப் புதுப்பிப்பதைக் கருத்தில் கொள்ளுங்கள். ஒரு பொறியாளரின் கவனத்தைச் சிதறடிக்காமல், ஏஜென்ட் அந்தப் பணிகளைத் திரும்பத் திரும்பச் செய்து, சோதனை செய்து, commit செய்ய முடியும்.

பொறியியல் நேரம் என்பது வரையறுக்கப்பட்டது என்பதால் இது முக்கியமானது. ஒரு சிறிய இடைவெளி (whitespace) திருத்தத்திற்காக 'approve' என்பதைக் கிளிக் செய்ய செலவிடப்படும் ஒவ்வொரு நிமிடமும், ஆர்க்கிடெக்சர் (architecture), விபத்துத் தீர்வு (incident response) அல்லது மனிதத் தீர்ப்பு தேவைப்படும் கடினமான பணிகளிலிருந்து திருடப்பட்ட நிமிடமாகும். Auto mode அந்த நேரத்தைத் திரும்பத் தருகிறது.

ஆனால் ஒழுக்கமில்லாத வேகம் என்பது வெறும் வேகமான தொழில்நுட்பக் கடனாகவே (technical debt) முடியும். ஒரு செயல் ப்ராம்ப்ட்டுடன் ஒத்துப்போகிறதா என்பதை மட்டுமே classifier சரிபார்க்கிறது. resulting code உங்கள் integration suite-ஐத் தாண்டுகிறதா, உங்கள் domain invariants-களை மதிக்கிறதா அல்லது உங்கள் style guide-ஐப் பின்பற்றுகிறதா என்பதை அது சரிபார்ப்பதில்லை. எனவே, எந்தவொரு குறியீடும் தயாரிப்பு நிலையை (production) அடைவதற்கு முன்பும், நீங்கள் இன்னும் CI gates, code review மற்றும் தானியங்கி சோதனைகளை (automated tests) வைத்திருக்க வேண்டும்.

மல்டி-கிளவுட் சிக்கல்கள்

Bedrock, Vertex AI, மற்றும் Azure Foundry ஆகிய அனைத்திலும் இந்த இயல்புநிலை (default) ஒரே நேரத்தில் அறிமுகப்படுத்தப்பட்டதால், மல்டி-கிளவுட் அமைப்புகளைப் பயன்படுத்தும் நிறுவனங்கள் நிலைத்தன்மையைப் (consistency) பற்றி சிந்திக்க வேண்டியுள்ளது. ஒவ்வொரு தளத்தையும் நீங்கள் திட்டமிட்டு கட்டமைக்காதவரை, GCP-இல் கட்டுப்பாடுகளுடன் வைத்துக்கொண்டு, AWS-இல் தளர்வான அனுமதிகளுடன் auto mode-ஐ இயங்க விடக்கூடாது. இந்த மூன்று கிளவுட்களையும் ஒரே செயல்பாட்டு வலைப்பின்னலாக (operational mesh) கருதினால், உங்கள் disableAutoMode கொள்கையையும் அடையாள எல்லைகளையும் (identity boundaries) இப்போதே தரப்படுத்திக் கொள்ளுங்கள். தளங்களுக்கு இடையிலான மாற்றங்கள் (drift) ஒரு build-ஐப் பாதிக்கும் வரை அல்லது அதைவிட மோசமான நிலை ஏற்படும் வரை கண்ணுக்குத் தெரியாது.

வகைப்படுத்திக்கு (classifier) எது தெரியாது என்பதையும் நினைவில் கொள்வது அவசியம். அது ஏஜென்ட் (agent) தனது பணியைச் சரியாகச் செய்கிறதா என்பதை மட்டுமே மதிப்பீடு செய்கிறதா, ஒரு refactor உங்கள் codebase முழுவதும் பாதிப்புகளை (ripple effects) ஏற்படுத்துமா என்பதை அல்ல. ஒரு shared utility-ஐப் பிரித்தெடுக்கும் ஏஜென்ட், அதன் prompt-க்கு இணங்கச் செயல்படுவது போலத் தோன்றலாம், ஆனால் அது பத்து downstream சேவைகளைச் சார்ந்துள்ள ஒரு interface-ஐ நுணுக்கமாக மாற்றியிருக்கலாம். வகைப்படுத்தி ஒரு மூத்த கட்டிடக் கலைஞர் (senior architect) அல்ல. அது ஒரு பணி சரிபார்ப்பவர் (task checker) மட்டுமே.

அடுத்த ஸ்பிரிண்டிற்கான சரிபார்ப்புப் பட்டியல்

நீங்கள் இந்த மாற்றத்தை நிர்வகிப்பவர் என்றால், இந்த வாரம் எடுக்க வேண்டிய உறுதியான நடவடிக்கைகள் இதோ:

  • இரண்டு வார கால லாக்ஸ்களை (logs) தணிக்கை செய்யுங்கள். ஒவ்வொரு Claude Code commit-ஐயும் கண்டறியுங்கள். மனித ஒப்புதல் (human approval prompt) இன்றி நடந்த எதையும் குறித்துக் குறியுங்கள்.
  • தகவல் அங்கீகார வரம்புகளை (credentials) வரையறுக்கவும். ஏஜென்ட்டிற்காக ஒரு பிரத்யேக சேவை கணக்கை (service account) உருவாக்குங்கள். அதற்குத் தேவையான கோப்பகங்களுக்கு (directories) மட்டுமே எழுதும் அனுமதியை (write access) வழங்கவும். உற்பத்தித் தரவுத்தளங்கள் (production databases), வரிசைப்படுத்தல் சாவிகள் (deployment keys) அல்லது வாடிக்கையாளர் தரவுச் சேமிப்பகங்களுக்கு (customer data stores) ஒருபோதும் அனுமதி வழங்காதீர்கள்.
  • உங்கள் ஆவணங்களைப் புதுப்பிக்கவும். பழைய environment variable toggles தொடர்பான குறிப்புகளை நீக்கவும். பணியில் இருக்கும் பொறியாளர்களை (on-call engineers) புதிய disableAutoMode மேலாண்மை அமைப்பிற்கு வழிநடத்துங்கள்.
  • அபாயத்தின் அடிப்படையில் பிரிக்கவும். formatting மற்றும் சிறிய dependency bumps போன்ற டெவலப்மென்ட் சார்ந்த பணிகளுக்கு மட்டும் auto mode-ஐ அனுமதிக்கவும். பிசினஸ் லாஜிக் (business logic), அங்கீகாரம் (authentication) அல்லது தரவு கையாளுதல் (data handling) குறியீடுகளைத் தொடும் எந்தவொரு செயலிற்கும் manual mode அல்லது முழுமையான மனித ஆய்வை (human review) கட்டாயமாக்குங்கள்.
  • உங்கள் இணக்கக் குழுவிற்கு (compliance team) விளக்கமளிக்கவும். வகைப்படுத்தி என்பது ஒரு தானியங்கி சரிபார்ப்பு மட்டுமே, அது மனித ஒப்புதல் அல்ல என்பதை விளக்குங்கள். புதிய opt-out இயல்புநிலை உங்கள் தற்போதைய மாற்றக் கட்டுப்பாட்டு கொள்கைகளுடன் (change-control policies) எவ்வாறு இணைகிறது என்பதைக் காட்டுங்கள்.

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

Manual mode ஒரு சடங்காக மாறிய ஒப்புதல் முறையை நீக்குவதன் மூலம், auto mode AI-உதவி கொண்ட குறியீட்டு முறையை (AI-assisted coding) வேகமாக்குகிறது. நள்ளிரவில் சோர்வடைந்த ஒரு டெவலப்பர் "yes" என்று அழுத்துவதை விட, ஏஜென்ட்டை ஒரு இரண்டாவது மாடல் மதிப்பாய்வு செய்வது சிறந்த பாதுகாப்பாகும். ஆனால் ஒரு இயல்புநிலை (default) என்பது முன்கூட்டியே எடுக்கப்பட்ட முடிவு, மேலும் நீங்கள் மாறாகச் சொல்லும் வரை உங்களுக்குத் தன்னாட்சி (autonomy) தேவை என்று இது கருதுகிறது.

2.1.207-ஐ ஒரு வசதி மேம்பாடாகப் பார்க்காமல், ஒரு உள்கட்டமைப்பு மாற்றமாக (infrastructure change) கருதுங்கள். உங்கள் அனுமதிகளை மறுபரிசீலனை செய்யுங்கள், உங்கள் runbooks-களை மீண்டும் எழுதுங்கள், மேலும் எந்தப் பணிப்பாய்வுகள் (workflows) தானியங்கியாக இருக்க வேண்டும், எவை மனிதத் தலையீட்டுடன் இருக்க வேண்டும் என்பதைத் திட்டமிட்டுத் தேர்ந்தெடுங்கள். கடினமான பணிகளை (grunt work) ஏஜென்ட் செய்ய விடுங்கள். அந்தப் பணியைச் சுற்றியுள்ள பாதுகாப்புச் சுவர்கள் போதுமான அளவு உறுதியாக இருப்பதை உறுதி செய்வதே உங்கள் வேலை.

Telegram-இல் உள்ள GyaanSetu AI சமூகத்தில் விவாதத்தில் இணையுங்கள்.