ஒரு ஆளுமை இல்லாத திறன் என்பது ஒரு கட்டளை அதிகாரி இல்லாத கட்டளை போன்றது. நீங்கள் ஒரு வரையறை கோப்பை கட்டுப்பாடுகள் மற்றும் வெளியீட்டு வடிவங்களுடன் நிரப்பலாம்

ஆளுமை இல்லாத ஒரு திறன், கட்டளை இல்லாத ஒரு கட்டளை போன்றது. நீங்கள் ஒரு வரையறை கோப்பில் (definition file) கட்டுப்பாடுகள், வெளியீட்டு வடிவங்கள் மற்றும் பாணி விதிகளை நிரப்பலாம், ஆனால் AI யாராக இருக்க வேண்டும் என்று நீங்கள் ஒருபோதும் கூறவில்லை என்றால், ஒரு திறமையான ஆனால் திசை தெரியாத பணியாளரிடம் அவருடைய பணி என்னவென்று யூகிக்கச் சொல்வதற்குச் சமம். இதன் விளைவு நீங்கள் எதிர்பார்ப்பது போலவே இருக்கும்: தொனிகளுக்கு இடையே மாறுபடும் பொதுவான வெளியீடு, ஒவ்வொரு முறையும் மாறுபடும் நிபுணத்துவ நிலைகள் மற்றும் புகையைத் துரத்துவது போன்ற ஒரு பிழைத்திருத்த செயல்முறை (debugging process).

இது முக்கியமானது, ஏனெனில் நவீன AI குறியீட்டுப் பணிப்பாய்வுகள் (coding workflows) இனி ஒற்றை முறை தூண்டுதல்கள் (single-shot prompts) மட்டுமல்ல. அவை பல சிறிய திறன்களால் ஒன்றோடொன்று இணைக்கப்பட்ட மட்டுப்படுத்தப்பட்ட அமைப்புகள் (modular systems). ஒவ்வொரு திறனுக்கும் தெளிவான அடையாளம் இல்லாதபோது, முழு செயல்முறைத் தொடரும் (pipeline) பாதிக்கப்படுகிறது.

ஆளுமை இல்லாமை உங்கள் பணிப்பாய்வை எவ்வாறு பாதிக்கிறது

நீங்கள் ஒரு பங்கின் அறிவிப்பைத் (role declaration) தவிர்க்கும்போது, அந்த மாதிரி (model) தனது அதிகாரத்தை நீங்களே உருவாக்கத் தூண்டப்படுகிறதே தவிர, அது சரியாக இருக்காது. ஒரு நிமிடம், அது கட்டமைப்பை (build) உடைக்காமல் இருக்க முயற்சிக்கும் ஒரு எச்சரிக்கையான பயிற்சிப் பணியாளரைப் (intern) போல குறியீட்டை எழுதும். அடுத்த நிமிடம், அது அனைத்து விளிம்பு நிலைகளையும் (edge cases) அறிந்த ஒரு முதன்மைப் பொறியாளரைப் (principal engineer) போல ஒரு விநியோகிக்கப்பட்ட அமைப்பை (distributed system) வடிவமைக்கும். அந்தத் தெளிவற்ற தன்மை எரிச்சலூட்டுவது மட்டுமல்ல, அது உங்கள் பணிப்பாய்வை நம்பகத்தன்மையற்றதாக மாற்றுகிறது.

சிக்கல்கள் விரைவாகத் தேங்கத் தொடங்கும். AI ஒரு தன்னிச்சையான குரலைத் தேர்ந்தெடுக்கும், இதனால் உங்கள் குறியீட்டுத் தளம் (codebase) ஒருபோதும் சந்திக்காத ஒரு குழுவினால் எழுதப்பட்டது போலத் தோன்றும். ஒவ்வொரு முறையும் நீங்கள் திறனை இயக்கும்போது வெளியீடுகள் மாறுபடும், அதாவது உங்களால் தானியங்கி சோதனைகள் (automated tests) அல்லது diff ஆய்வுகளை நம்ப முடியாது. எந்தக் கண்ணோட்டத்தில் இந்த முடிவு பெறப்பட்டது என்று உங்களுக்குத் தெரியாததால், தணிக்கை (auditing) செய்வது சாத்தியமற்றதாகிறது. இது ஒரு பாதுகாப்பு சார்ந்த பொறியாளரா அல்லது ஒரு தயாரிப்பு பொதுவியலாளரா (product generalist) மூலம் உருவாக்கப்பட்டது? பதில் "மாதிரிக்குத் தோன்றியது எதுவோ அது" என்று இருந்தால், தர்க்கத்தை (logic) சரிபார்க்க உங்களுக்கு வழியில்லை.

திறன் இணைப்பு (Skill chaining) இதை இன்னும் மோசமாக்குகிறது. API ஒப்பந்தங்களை (API contracts) உருவாக்கும் ஒரு திறனையும், அதைச் செயல்படுத்துவதை (implementation) எழுதும் மற்றொரு திறனையும் கற்பனை செய்து பாருங்கள். முதலாவது திறன் கடுமையான சரிபார்ப்பை வலியுறுத்தும் ஒரு நுணுக்கமான மூத்த கட்டிடக் கலைஞரைப் (senior architect) போலச் செயல்பட்டு, இரண்டாவது திறன் பிழை கையாளுதலைத் (error handling) தவிர்க்கும் ஒரு இளநிலை மேம்பாட்டாளரைப் (junior developer) போல நடந்துகொண்டால், உங்கள் ஒருங்கிணைப்பு (integration) முறிந்துவிடும். ஒவ்வொரு இணைப்பும் தனது அடையாளத்தை அறிந்திருக்கும்போது மட்டுமே அந்தச் சங்கிலி உறுதியாக இருக்கும். அது இல்லையென்றால், பொறுப்புக்கூறல் (accountability) மறைந்துவிடும். ஏதேனும் ஒன்று முறிந்துவிட்டால், எந்தக் கண்ணோட்டம் தோல்வியடைந்தது என்று உங்களால் சுட்டிக்காட்ட முடியாது, ஏனெனில் எந்தக் கண்ணோட்டமும் வரையறுக்கப்படவில்லை.

இதை எவ்வாறு சரி செய்வது

தீர்வு எளிமையானது ஆனால் குறிப்பிட்டது. உங்கள் திறன் கோப்பில் (skill file) ஒரு பங்கின் அறிவிப்பை (role declaration) முதல் கட்டளையாகச் சேர்க்கவும். அதை வடிவமைப்பு விதிகள் அல்லது வெளியீட்டுத் திட்டங்களுக்கு (output schemas) அடியில் புதைக்க வேண்டாம். அடையாளத்துடன் தொடங்குங்கள்.

ஒரு தெளிவான கட்டமைப்பைப் பயன்படுத்தவும்: "நீங்கள் [domain]-இல் நிபுணத்துவம் பெற்ற ஒரு [role] ஆவீர்கள்." அதைத் தொடர்ந்து அந்தப் பணி சூழலில் இந்தத் பங்கு உண்மையில் என்ன செய்கிறது என்பது பற்றிய ஒன்று அல்லது இரண்டு வாக்கியங்களைச் சேர்க்கவும். உதாரணமாக: "நீங்கள் விநியோகிக்கப்பட்ட அமைப்புகளில் (distributed systems) நிபுணத்துவம் பெற்ற ஒரு மூத்த பின்னணிப் பொறியாளர் (senior backend engineer) ஆவீர்கள். உங்கள் பணி, pull requests-களைக் கன்கரன்சி அபாயங்கள் (concurrency risks) மற்றும் தரவு நிலைத்தன்மை சிக்கல்களுக்காக (data consistency issues) ஆய்வு செய்வதாகும். நீங்கள் நிலை மேலாண்மை (state management) குறித்த அனுமானங்களை கேள்வி கேட்கிறீர்கள் மற்றும் முறையான பிழை கையாளுதல் (error handling) இல்லாத குறியீட்டை அங்கீகரிக்க மறுக்கிறீர்கள்."

அதுவே போதுமானது. அதிகபட்சம் மூன்று வாக்கியங்கள். நீண்ட வாழ்க்கை வரலாறுகள் தேவையற்ற குழப்பங்களை (noise) ஏற்படுத்தும். மாதிரிக்கு (model) சிறுவயது பின்னணியோ அல்லது பொழுதுபோக்குகளின் பட்டியலோ தேவையில்லை. அதன் முடிவெடுக்கும் திறனை வடிவமைக்கும் ஒரு தொழில்முறைத் தளம் (professional anchor) மட்டுமே அதற்குத் தேவை.

உண்மையான தொழில்முறைப் பங்குகளைப் பயன்படுத்துங்கள். ஒரு ஸ்டாஃப் மென்பொருள் பொறியாளர் (staff software engineer) அல்லது ஒரு தொழில்நுட்ப ஆவண எழுத்தாளர் (technical documentation writer) மாதிரிக்குத் தெளிவான பொறுப்பு கட்டமைப்பை வழங்குகிறது. அதை ஷெர்லாக் ஹோம்ஸ் அல்லது ஒரு இடைக்கால மந்திரவாதி போலச் செயல்படச் சொல்வது ஆக்கப்பூர்வமாகத் தோன்றலாம், ஆனால் அது உங்கள் குறியீடு ஆய்வுப் பணிப்பாய்வோடு (code review pipeline) தொடர்பில்லாத கணிக்க முடியாத தொடர்புகளை உருவாக்குகிறது. உண்மையான பங்குகள் உண்மையான கட்டுப்பாடுகளைக் கொண்டுள்ளன.

நீங்கள் சரியாகச் செய்யும்போது என்ன மாற்றங்கள் ஏற்படும்

ஒவ்வொரு திறனும் அதன் சொந்த ஆளுமையைக் கொண்டிருக்கும்போது, உங்கள் முழுமையான செயல்முறைத் தொடரும் (pipeline) நிலைபெறுகிறது.

கணிக்கக்கூடிய தன்மைதான் முதல் வெகுமதி. AI தனது அனுபவ நிலையைத் தானே யூகிக்கத் தேவையில்லை. ஒரு மூத்த ஆளுமை (senior persona) கடினமான கேள்விகளைக் கேட்கும். அது தெளிவற்ற தேவைகளை எதிர்த்துப் போராடும், விளிம்பு நிலைகளைக் (edge cases) கண்டறியும் மற்றும் ஒரு இயல்புநிலை அல்லது இளநிலை குரல் புறக்கணிக்கும் சூழலை (context) கோரும். நீங்கள் ஒரு பங்கினை வரையறுக்கும்போது, நீங்கள் ஒரு தரநிலையை (standard) வரையறுக்கிறீர்கள்.

ஆய்வுகள் விரைவாகும். ஒரு குழு உறுப்பினர் தெளிவான ஆளுமையால் குறிக்கப்பட்ட வெளியீட்டைப் படிக்கும்போது, ஒவ்வொரு பரிந்துரையின் பின்னணியில் உள்ள கண்ணோட்டத்தையும் புரிந்துகொள்வார். ஒரு பின்னூட்டத்தை (feedback) ஒரு கடுமையான கட்டிடக்கலைத் தேவையாக (architectural requirement) கருத வேண்டுமா அல்லது ஒரு மென்மையான பாணி விருப்பமாக (style preference) கருத வேண்டுமா என்பதை அவர் அறிவார். சூழல் (context) மறைமுகமாக இல்லாமல் வெளிப்படையாக இருக்கும்.

திறன் இணைப்பு (Skill chaining) இறுதியாகத் திட்டமிட்டபடி செயல்படுகிறது. ஒவ்வொன்றும்...