ஒரு மாத காலத்திற்கு எனது CI/CD பைப்லைனை ஒரு AI-ஆல் இயக்கப்படும் ஏஜென்ட் (AI-driven agent) மூலம் இயக்கினேன். சோதனையின் முடிவில், அது தோல்வியடைந்த பில்டுகளைச் சரிசெய்தது, pull requests-களைத் தொடங்கியது மற்றும் வேலைகளை மீண்டும் இயக்கத் தொடங்கியது; மனிதர்களின் ஒப்புதலுக்கு ஒரே ஒரு படிநிலை மட்டுமே எஞ்சியிருந்தது. இந்தச் சோதனை, “agentic” DevOps என்பது வழக்கமான வகைப்படுத்துதல் (triage) பணிகளைப் பின்னணி அலுவலகத்திலிருந்து ஒரு தானியங்கி மூளைக்கு மாற்ற முடியும் என்பதைக் காட்டுகிறது, ஆனால் ஒரு தன்னாட்சி அமைப்பு (autonomous system) புதிய இடர்பாட்டு ஆதாரமாக மாறுவதைத் தடுக்கும் பாதுகாப்பு வளையங்களின் (guardrails) அவசியத்தையும் இது வெளிச்சம் போட்டுக் காட்டுகிறது.
இந்தச் சோதனை ஏன் முக்கியமானது
பெரும்பாலான மென்பொருள் குழுக்கள் இன்னும் AI-ஐ ஒரு நவீன ஆட்டோகம்ப்ளீட் (autocomplete) கருவியாகவே கருதுகின்றன—அதாவது ஒரு வரியைக் குறியீடாகப் பரிந்துரைக்கும் அல்லது ஒரு பிழைச் செய்தியை விளக்கும் ஒரு கருவி. 2025-இல், இந்தத் துறை “உங்களுக்குத் தட்டச்சு செய்ய உதவும் AI”-லிருந்து “செயல்படும் AI”-க்கு மாறி வருகிறது. செயல்படும் ஒரு ஏஜென்ட், லாக்ஸ்களை (logs) படிக்க முடியும், ஒரு தீர்வைத் தீர்மானிக்க முடியும், அதைச் செயல்படுத்த முடியும் மற்றும் அதன் முடிவிலிருந்து கற்றுக்கொள்ள முடியும்—இவை அனைத்தும் ஒரு டெவலப்பர் ஒரு கட்டளையைத் தட்டச்சு செய்யாமலேயே நடக்கும்.
அடிப்படை யோசனை: ஒரு agentic பைப்லைன்
ஒரு agentic பைப்லைன் என்பது உற்பத்திச் சூழலுக்கு (production) கட்டுப்பாடற்ற அணுகல் கொண்ட ஒற்றை மாடல் (monolithic model) அல்ல. இது சிறப்புத் கருவிகளை ஒருங்கிணைக்கும், சூழலைத் தக்கவைக்கும் மற்றும் கடுமையான பாதுகாப்பு வளையங்களுக்குப் பின்னால் இயங்கும் ஒரு குறுகிய ஒருங்கிணைப்பாளர் (orchestrator) ஆகும். இதன் முக்கியச் சுழற்சி ஒரு மனிதனின் சிக்கலைத் தீர்க்கும் முறையைப் பிரதிபலிக்கிறது:
- உணர்தல் (Perceive) – லாக்ஸ் (logs), சோதனை முடிவுகள் மற்றும் அளவீடுகளைப் பெறுதல்.
- சிந்தித்தல் (Reason) – தோல்வியைப் பகுப்பாய்வு செய்து, பாதுகாப்பான தீர்வைத் திட்டமிடுதல்.
- செயல்படுதல் (Act) – ஒரு பேட்ச் (patch) எனப்படும் திருத்தத்தைச் செயல்படுத்த அல்லது ஒரு சார்பை (dependency) மேம்படுத்த அல்லது ஒரு வேலையை மீண்டும் இயக்க ஒரு குறிப்பிட்ட கருவியைப் பயன்படுத்துதல்.
- கற்றல் (Learn) – அடுத்த முடிவு சிறப்பாக எடுக்கப்படுவதற்காக முடிவுகளைப் பதிவு செய்தல்.
இந்தச் சோதனையை பாதுகாப்பாக வைத்திருந்த கட்டமைப்பு இவ்வாறு இருந்தது:
- CI/CD platform – வேலைகளைத் திட்டமிட்டு இயக்குகிறது.
- Orchestrator – தரவைப் பெற்று, கட்டுப்பாட்டுச் சுழற்சியை (control loop) இயக்கி, என்ன செய்ய வேண்டும் என்று தீர்மானிக்கும் “மூளை”.
- Tools – குறிப்பிட்ட செயல்களைச் செய்யும் கைகள் (எ.கா., ஒரு PR-ஐத் தொடங்குதல், ஒரு பதிப்பை மேம்படுத்துதல்).
- Context store – சமீபத்திய தோல்விகள் மற்றும் திருத்தங்களின் ஒரு லேசான நினைவகம்.
- Guardrails – ஏஜென்ட் நேரடியாக உற்பத்திச் சூழலைத் தொடாமல் இருக்க அல்லது மனிதனின் தெளிவான ஒப்புதல் இன்றி மாற்றங்களைச் செய்யாமல் இருக்கக் கட்டுப்படுத்தும் கடுமையான வரம்புகள்.
பெரிய மொழி மாதிரியை (LLM) நேரடியாக உற்பத்திச் சூழலில் மாற்றங்களைச் செய்வதிலிருந்து விலக்கி வைத்ததன் மூலம், இந்த அமைப்பு தாக்குதல் பரப்பளவைக் (attack surface) குறைத்தது, அதே நேரத்தில் சிக்கலைப் பற்றி அந்த மாதிரியால் சிந்திக்கவும் அனுமதித்தது.
ஏஜென்ட்டின் ஒரு மாத வாழ்க்கை முறை
வாரம் 1 – வாசிப்பு-மட்டும் கவனிப்பு (read-only observation)
ஏஜென்ட் “விளக்கம் அளிக்கும் முறை” (explain-only mode)-இல் இயங்கியது. ஒவ்வொரு தோல்வியடைந்த பில்டும் பிழைச் செய்தியைச் சுருக்கி, சாத்தியமான காரணங்களைப் பரிந்துரைக்கும் வகையில் ஒரு Slack செய்தியை உருவாக்கியது. எந்தக் குறியீடும் மாற்றப்படவில்லை. இந்த நிலை, உணர்தல் மற்றும் சிந்தித்தல் நிலைகள் உண்மையான லாக்ஸ்களில் (logs) வேலை செய்வதை நிரூபித்தது மற்றும் ஏஜென்ட் குறியீட்டுத் தளத்தைப் (codebase) புரிந்துகொண்டது என்ற நம்பிக்கையைத் குழுவிற்கு அளித்தது.
வாரம் 2 – தீர்வுகளைப் பரிந்துரைத்தல்
அடுத்த ஏழு நாட்களுக்கு, linting தோல்விகள் அல்லது காலாவதியான சார்புகள் (outdated dependencies) போன்ற குறைந்த ஆபத்துள்ள சிக்கல்களுக்கு ஒருங்கிணைப்பாளர் (orchestrator) pull requests-களைத் தொடங்கினார். பொறியாளர்கள் அவற்றை இணைப்பதற்கு (merging) முன் ஆய்வு செய்தனர்.
வாரம் 3 – கட்டுப்படுத்தப்பட்ட செயல்பாடு
ஒப்புதல் பணிப்பாய்வு (approval workflow) அமலில் இருந்ததால், உற்பத்தி அல்லாத சூழலில் (non-production environment) வேலைகளை மீண்டும் இயக்க ஏஜென்ட்டிற்கு அனுமதி கிடைத்தது. ஒரு பில்ட் தோல்வியடையும் போது, ஒருங்கிணைப்பாளர் தானாகவே ஒரு பழுதான சார்பின் (dependency) சரியான பதிப்பைப் பயன்படுத்திக் கொண்டு, ஒரு PR-ஐத் தொடங்கி, அது இணைக்கப்பட்ட பிறகு, பைப்லைனை மீண்டும் இயக்கினார்.
வாரம் 4 – தாக்கத்தை அளவிடுதல்
இறுதி வாரம் முடிவுகளை அளவிடுவதிலும், ஏஜென்ட் எத்தனை தோல்விகளைத் தீர்த்தது என்பதைக் கண்காணிப்பதிலும் கவனம் செலுத்தியது.
நன்மைகள்: சலிப்பூட்டும் வேலைகளைத் தவிர்த்தல்
CI/CD-இன் மீண்டும் மீண்டும் செய்யப்படும் பணிகளான லாக்ஸ்களைப் படித்தல், தெரிந்த முறைகளைக் கண்டறிதல், பதிப்புகளை மேம்படுத்துதல் மற்றும் வேலைகளை மீண்டும் இயக்குதல் போன்றவற்றை ஒரு AI ஏஜென்ட் கையாள முடியும் என்பதை இந்தச் சோதனை காட்டியது. பொறியாளர்கள் இறுதி மாற்றங்களை மட்டும் ஒப்புக்கொள்ளவும், ஏஜென்ட்டால் தீர்க்க முடியாத சில விளிம்புநிலைத் தோல்விகளை (edge-case failures) ஆய்வு செய்யவும் மட்டுமே வேண்டியிருந்தது. நடைமுறையில், இது நள்ளிரவில் வரும் அழைப்புகளைக் குறைக்கவும், சூழல் மாற்றங்களைக் (context-switching) குறைக்கவும் மற்றும் டெவலப்பர்களுக்கு விரைவான பின்னூட்டச் சுழற்சியை (feedback loop) வழங்கவும் உதவியது.
சிக்கல்கள் மற்றும் அவற்றை எவ்வாறு குறைப்பது
- நம்பிக்கையுடன் தவறான தீர்வுகளை வழங்குதல் – ஏஜென்ட் சில நேரங்களில் ஒரு ஆழமான பிழையை மறைக்கும் வகையில், ஒரு அறிகுறிக் கட்டத்தை (symptom-level patch) மட்டும் பயன்படுத்தியது. உற்பத்தி குறியீட்டைத் (production code) தொடும் எந்தவொரு மாற்றத்திற்கும் மனித ஒப்புதல் தேவைப்படும் பாதுகாப்பு வளையங்கள் இந்த அபாயத்தைக் கட்டுப்படுத்தின.
- தேவையற்ற தகவல்களின் மிகுதி (Noise overload) – வடிகட்டப்படாத அறிவிப்புகள் உண்மையான எச்சரிக்கைகளை மறைத்துவிடக்கூடும்.
- எல்லை மீறுதல் (Scope creep) – மாடலுக்குக் கட்டுப்பாடற்ற அணுகலை வழங்குவது விரைவாக
- orchestrator-ஐ அமைக்கவும் – இது LLM-ஐ அழைக்கவும், சூழலைச் சேமிக்கவும் மற்றும் CI/CD APIs-ஐ இயக்கவும் கூடிய ஒரு இலகுரகச் சேவையாகும்.
- பாதுகாப்பு வழிமுறைகளை (guardrails) வரையறுக்கவும் – ஏஜென்ட் தொடங்கும் CI/CD வேலைகளை அனுமதிப்பட்ட பட்டியலில் (whitelist) சேர்க்கவும், PR ஒப்புதலைக் கோரவும் மற்றும் நேரடித் தயாரிப்பு (production) மாற்றங்களைத் தடுக்கவும்.
- வாரம் 1: கண்காணிப்பு முறை (Observation mode) – பதிவுகளை (logs) orchestrator-க்கு வழங்கவும், மேலும் அது கண்டறியும் சுருக்கங்களை (diagnostic summaries) ஒரு அரட்டை சேனலில் (chat channel) பதிவிட அனுமதிக்கவும்.
- வாரம் 2: பரிந்துரை முறை (Suggestion mode) – முக்கியமானதல்லாத சரிசெய்தல்களுக்கு (non-critical fixes) PR-களைத் திறக்க ஏஜென்ட்டை அனுமதிக்கவும்; மனித ஆய்வு (human review) கட்டாயமாக்கப்பட வேண்டும்.
- வாரம் 3: கட்டுப்படுத்தப்பட்ட செயல்பாடு (Controlled action) – ஒரு PR இணைக்கப்பட்ட பிறகு (merges), staging அல்லது சோதனைச் சூழல்களில் (test environments) வேலைகளை மீண்டும் இயக்க அனுமதி வழங்கவும்.
- வாரம் 4: அளவீடுகள் மற்றும் சரிசெய்தல் (Metrics and tuning) – வகைப்படுத்தப்பட்ட தோல்விகள் (triaged failures), தவறான நேர்மறைகள் (false positives) மற்றும் சேமிக்கப்பட்ட நேரத்தைக் கண்காணிக்கவும்; அதற்கேற்ப எச்சரிக்கை வரம்புகள் (alert thresholds) மற்றும் பாதுகாப்பு வழிமுறைகளைச் சரிசெய்யவும்.
- மீண்டும் மீண்டும் மேம்படுத்தவும் (Iterate) – ஒவ்வொரு புதிய திறனும் அதே பாதுகாப்புச் சோதனைகளைக் கடந்த பின்னரே கருவித் தொகுப்பை (எ.கா., தானியங்கித் திரும்பப் பெறுதல்கள் (automated rollbacks), பாதுகாப்பு ஸ்கேன்கள் (security scans)) விரிவுபடுத்தவும்.
எதிர்வாதம் (The counter-argument)
ஏஜென்ட்கள் நம்பிக்கையுடன் தவறாகச் செயல்படக்கூடும் என்று சந்தேகப்படுபவர்கள் சுட்டிக்காட்டுகின்றனர். இந்தச் சோதனை அந்த கவலையை நீக்கவில்லை; ஒழுங்குபடுத்தப்பட்ட பாதுகாப்பு வழிமுறைகள் (guardrails) மூலம் அபாயத்தைக் கட்டுப்படுத்தியபடியே அதன் பலன்களைப் பெற முடியும் என்பதை மட்டுமே இது காட்டியது.
முக்கியக் கருத்து (Takeaway)
CI/CD கட்டுப்பாட்டுச் சுழற்சியை (control loop) இயக்கும் ஒரு AI ஏஜென்ட், நீங்கள் மாதிரியைத் தனிமைப்படுத்தியும் (isolate), கடுமையான ஒப்புதல் படிகளை நடைமுறைப்படுத்தியும், குறைந்த அபாயம் கொண்ட கண்காணிப்பு சார்ந்த அணுகுமுறையுடன் தொடங்கினால், ஒரு எதிர்வினை ஆற்றும், கைமுறை வகைப்படுத்தும் செயல்முறையை கிட்டத்தட்டத் தானாகவே சரிசெய்யும் (self-healing) pipeline-ஆக மாற்ற முடியும். இதன் உண்மையான மதிப்பு பொறியாளர்களை மாற்றுவதில் இல்லை; மாறாக, pipeline-களைச் சீராக வைத்திருக்கவும் (keep pipelines green), டெவலப்பர்கள் உருவாக்குவதில் கவனம் செலுத்தவும் உதவும் சலிப்பூட்டும், மீண்டும் மீண்டும் செய்யப்படும் வேலைகளைப் பகிர்ந்தளிப்பதில்தான் உள்ளது.