மென்பொருள் உருவாக்குநர்களை (software developers) AI தேவையில்லாதவர்களாக மாற்றிவிடும் என்று தலைப்புச் செய்திகள் தொடர்ந்து கூறுகின்றன. நான் அதை நம்பவில்லை. இயந்திரங்கள் பொறியியல் பணிகளைக் கைப்பற்றும் என்பது உண்மையான ஆபத்து அல்ல. பொறியாளர்கள் சிந்திக்கும் கடினமான வேலையைச் செய்வதை நிறுத்திவிடுவதுதான் உண்மையான ஆபத்து.
மென்பொருள் என்பது வெறும் குறியீட்டு முறைகளை (syntax) தட்டச்சு செய்வது மட்டுமல்ல. அது சிக்கல்களைத் தன் மனதில் வைத்திருப்பது, தோல்வி முறைகளைப் (failure modes) புரிந்துகொள்வது மற்றும் எந்தத் தேர்வும் முழுமையானதாக இல்லாதபோது சமரசங்களை (trade-offs) மேற்கொள்வது பற்றியது. AI நாம் குறியீட்டை உருவாக்கும் வேகத்தை மாற்றியிருக்கலாம், ஆனால் ஏன் மனிதர்களின் பங்களிப்பு தேவை என்பதை அது மாற்றவில்லை. சொல்லப்போனால், தெளிவான சிந்தனைக்கு அது அதிக மதிப்பையும் அரிமையையும் கொடுத்துள்ளது.
முதல் வரைவு என்பது பொறியியல் அல்ல
ChatGPT அல்லது Claude-ஐ அடுத்த இருக்கையில் அமர்ந்திருக்கும் ஒரு மூத்த பொறியாளராக (senior engineer) கருதும் ஜூனியர் டெவலப்பர்களின் எண்ணிக்கை அதிகரித்து வருவதை நான் பார்க்கிறேன். அவர்கள் ஒரு டிக்கெட் விளக்கத்தைப் (ticket description) பேஸ்ட் செய்கிறார்கள், பதிலைப் பிரதி எடுக்கிறார்கள், சோதனைகளை (tests) நடத்துகிறார்கள், மற்றும் கமிட் (commit) செய்கிறார்கள். அது சரியாக இயங்கினால் (compiles), அந்தப் பணி முடிந்துவிட்டது என்று கருதுகிறார்கள். இந்தச் சுழற்சி வேகமானது, எளிதானது மற்றும் ஆபத்தானது.
AI-ஐப் பயன்படுத்துவது பிரச்சனை அல்ல. நானும் அதைப் பயன்படுத்துகிறேன். நான் அறிந்த பெரும்பாலான திறமையான பொறியாளர்கள் அதைப் பயன்படுத்துகிறார்கள். அறையில் இருக்கும் ஒரே பொறியாளராக AI மாறும்போதுதான் பிரச்சனை தொடங்குகிறது. ஒரு தீர்வு வேலை செய்கிறது என்பதற்காகவே முதல் தீர்வை அப்படியே ஏற்றுக்கொள்வது பொறியியல் அல்ல. அது உங்கள் பயனர்கள், உங்கள் வணிகக் கட்டுப்பாடுகள் அல்லது உங்கள் தொழில்நுட்பக் கட்டமைப்பு (stack) கடைசியாக எப்போது நள்ளிரவில் செயலிழந்தது என்பதைப் புரிந்து கொள்ளாத ஒரு மாடலிடம் உங்கள் தீர்ப்பை (judgment) ஒப்படைப்பதாகும்.
பெரிய மொழி மாதிரிகள் (Large language models) முற்றிலும் தவறாக இருந்தாலும், ஒருவிதத் தடுமாற்றமளிக்கும் நம்பிக்கையுடன் பதில்களை வழங்குகின்றன. ஒரு பொறியாளர் ஒரு அளவிடக்கூடிய கட்டமைப்பை (scalable architecture) வடிவமைக்க AI-யிடம் கேட்டார். அந்த மாடல், தயாரிப்பில் உண்மையில் இல்லாத ஒரு அம்சத்தை அடிப்படையாகக் கொண்டு ஒரு விரிவான, அதிகாரப்பூர்வமான முன்மொழிவை வழங்கியது. அது சரியாகத் தெரிந்தது. அது உள்நோக்கத்துடன் சீராக இருந்தது. ஆனால் அது பயனற்றது. AI தவறான தகவல்களை உருவாக்குவது (hallucinates) மட்டுமே ஆபத்து அல்ல. அந்தத் தவறுகளைக் கண்டறியத் தேவையான சூழல் அறிவு (context) இல்லாததால், இப்போது அதிகமான மக்கள் அந்தத் தவறான தகவல்களை நம்புகிறார்கள் என்பதுதான் ஆபத்து.
உராய்விலிருந்தே நீங்கள் கற்றுக்கொள்கிறீர்கள்
ஒரு ஜூனியர் டெவலப்பரிலிருந்து ஒரு முழுமையான அமைப்பைக் கையாளக்கூடிய ஒருவராக என்னை மாற்றியது எது என்று நான் சிந்திக்கும்போது, நான் மனப்பாடம் செய்த குறியீட்டு முறைகளை (syntax) நினைவில் கொள்வதில்லை. நான் ஏற்பட்ட தடங்கல்களை (outages) நினைவில் கொள்கிறேன். நான் கையால் கண்டறிய வேண்டிய மெதுவான வினவல்களை (slow queries), தயாரிப்புச் சூழலில் (production load) மட்டுமே தோன்றும் ரேஸ் கண்டிஷன்களை (race conditions) மற்றும் எனது உள்ளூர் சூழல் (local environment) நிஜ உலகத்தைப் போல இல்லாததால் ஏற்பட்ட தோல்வியுற்ற பதிவேற்றங்களை (deployments) நினைவில் கொள்கிறேன்.
பிழைத்திருத்தம் (Debugging) செய்யும் இடத்தில்தான் கற்றல் நிகழ்கிறது. நீங்கள் குறியீட்டைத் தனித்தனியாகச் சரிபார்க்கும்போது, அமைப்புகள் உண்மையில் ஏன் தோல்வியடைகின்றன என்பதைப் புரிந்துகொள்வீர்கள். தடைகள் (bottlenecks) எங்கு ஏற்படுகின்றன என்பதைக் கண்டறிவீர்கள். பத்து பயனர்களைக் கொண்ட ஒரு டெமோவிலிருந்து, பத்தாயிரம் பயனர்களைக் கையாளும் ஒரு தயாரிப்பு அமைப்பிற்கு நீங்கள் மாறும்போது, ஒரு கட்டமைப்பு எவ்வாறு செயல்படுகிறது என்பதை நீங்கள் கற்றுக்கொள்வீர்கள். ஒரு நன்கு திட்டமிடப்பட்ட டெமோவிற்கும், நிஜமான தயாரிப்புச் சூழலுக்கும் இடையிலான வேறுபாட்டை உங்கள் ஆழமான அனுபவத்தின் மூலம் உணர்வீர்கள்.
அந்த அறிவில் எதுவும் ஒரு தானியங்கி பதிலைப் பெறுவதன் மூலம் வருவதில்லை. அது ஒரு சிக்கலோடு போராடுவதன் மூலம் வருகிறது. AI ஒவ்வொரு போராட்டத்தையும் நீக்கிவிட்டால், அதுவே குறியீட்டை எழுதினால், பிழைகளைச் சரிசெய்தால் மற்றும் தோல்விகளுக்கு விளக்கம் அளித்தால், அடுத்த தலைமுறை டெவலப்பர்கள் எவ்வாறு அனுபவத்தைப் பெறுவார்கள்? அனுபவம் என்பது நீங்கள் பதிவிறக்கம் செய்யக்கூடிய ஒரு சான்றிதழ் அல்ல. அது தயாரிப்புச் சூழலில் ஏற்பட்ட சிக்கல்கள் மற்றும் தோல்வியுற்ற பதிவேற்றங்களால் நீங்கள் உருவாக்கும் ஒரு தழும்பு போன்ற அனுபவம். அந்த உராய்வை நீக்கிவிட்டால், வளர்ச்சியையும் நீக்கிவிடுகிறீர்கள்.
உருவாதலை விடத் தீர்ப்பே சிறந்தது
ஒரு காலத்தில், தொழில்முனைவோர் 'ப்ராம்ப்ட் இன்ஜினியரிங்' (prompt engineering) என்பது ரெஸ்யூமில் (resume) சேர்க்கப்பட வேண்டிய ஒரு புதிய திறனாகக் கருதப்பட்டது. அது விஷயத்தையே தவறாகப் புரிந்துகொண்டது. AI நிறைந்த சூழலில் மிகவும் மதிப்புமிக்க திறன் என்பது பல விருப்பங்களை உருவாக்குவது அல்ல; எந்தப் பரிந்துரைகளை நிராகரிக்க வேண்டும் என்று தெரிந்து கொள்வதே ஆகும்.
நான் பணிபுரியும் சிறந்த பொறியாளர்கள் அதிக ப்ராம்ப்ட்களை (prompts) எழுதுவதில்லை. அவர்கள் கடினமான கேள்விகளைக் கேட்கிறார்கள். ஒரு மறுசீரமைப்பு (refactor) மறைமுகமான ஒரு சார்பை (hidden dependency) உருவாக்கும்போது அவர்கள் அதைத் தெரிந்து கொள்கிறார்கள். ஒரு தானியங்கி சோதனை (generated test) எளிமையான பாதையை (happy path) மட்டும் கவனித்துக்கொண்டு, வாடிக்கையாளர் தரவைச் சிதைக்கக்கூடிய விளிம்பு நிலைச் சூழல்களை (edge cases) புறக்கணிப்பதை அவர்கள் அடையாளம் காண்கிறார்கள். ஒரு சரியான குறியீட்டைப் பார்த்துவிட்டு, "இந்தக் குறியீடு சரியானது, ஆனால் கட்டமைப்பு (architecture) தவறானது" என்று அவர்களால் சொல்ல முடியும்.
அந்த கடைசி வாக்கியம் இரண்டு வெவ்வேறு கலாச்சாரங்களுக்கு இடையிலான எல்லையாகும். AI-உதவி பெற்ற பொறியியல் (AI-assisted engineering) என்பது உங்கள் மூளை முடிவுகளை எடுக்கும்போது, ஒரு கட்டமைப்பை உருவாக்க அல்லது வடிவங்களை ஆராய அல்லது தேவையற்ற குறியீடுகளைத் (boilerplate) தானியக்கமாக்க இயந்திரத்தைப் பயன்படுத்துவதைக் குறிக்கிறது. AI-யைச் சார்ந்திருக்கும் பொறியியல் (AI-dependent engineering) என்பது இயந்திரமே வழிநடத்த வேண்டும் என்று நீங்கள் நம்புவதைக் குறிக்கிறது. குறுகிய காலத்தில் இது வேகமாகத் தெரிவதால், பல நிறுவனங்கள் மெதுவாக இந்தச் சார்பு நிலையை நோக்கி நகர்ந்து வருகின்றன. வேகம் என்பது சரியானது என்று அர்த்தமல்ல.
இன்னும் மனிதர்களுக்கே உரிய வேலைகள்
AI மேம்பாட்டுச் சுழற்சியின் (development lifecycle) கிட்டத்தட்ட அனைத்துப் பகுதிகளையும் விரைவுபடுத்த முடியும், இருப்பினும் மனிதர்களிடமே உறுதியாக இருக்க வேண்டிய சில முக்கிய நடைமுறைகள் உள்ளன. System design என்பது செலவு, latency, நம்பகத்தன்மை மற்றும் எதிர்காலப் பராமரிப்புத்தன்மை போன்ற ஒன்றுக்கொன்று முரணான கட்டுப்பாடுகளைச் சமநிலையில் வைத்திருப்பதை அவசியமாக்குகிறது. Architecture reviews என்பது நிறுவனத்தின் அனுபவ அறிவு (institutional memory) மற்றும் இரண்டாம் நிலை விளைவுகளைக் கணிக்கும் திறனைச் சார்ந்துள்ளன. Mentorship செய்வதற்கு, நீங்கள் எச்சரிக்கப்படும் தோல்வி முறைகளைத் தாமாகவே அனுபவித்த ஒருவர் தேவை. ஆழமான தயாரிப்புப் புரிதல் என்பது பயனர்களுடன் பேசுவதிலிருந்தும், நிஜ உலகச் செயல்பாடுகளைக் கவனிப்பதிலிருந்தும் கிடைப்பதே தவிர, training data-வை வாசிப்பதிலிருந்து வருவதல்ல.
Engineering judgment என்பது அந்த அனுபவங்களின் தொகுப்பாகும். Code review வெற்றி பெற்றிருந்தாலும், ஒரு migration-ஐ வெள்ளிக்கிழமை மதிய வேளையில் வெளியிடுவது மிகவும் ஆபத்தானது என்று உங்களுக்குச் சொல்லும் அந்த அமைதியான குரலே அது. இப்போது செய்யப்படும் ஒரு performance optimization, பின்னாளில் ஒரு security hole-ஐ உருவாக்கக்கூடும் என்ற உள்ளுணர்வு அதுவாகும். ஒரு LLM-க்கு உள்ளுணர்வு கிடையாது. அதற்கு patterns மட்டுமே தெரியும். Patterns பயனுள்ளவை, ஆனால் அவை judgment கிடையாது.
தற்போது பணியமர்த்தும் நிறுவனங்கள், AI கருவிகளைப் பயன்படுத்துவதில் மட்டும் திறமையானவர்களைத் தேடுவதை நிறுத்த வேண்டும். AI-ஐக் கேள்வி கேட்கக்கூடிய நபர்களைப் பணியமர்த்துங்கள். உருவாக்கப்பட்ட output-ஐ நிறுத்தி, கவனமாகப் படித்து, அதனுடன் ஏன் உடன்படவில்லை என்பதை விளக்கும் விண்ணப்பதாரர்களைத் தேடுங்கள். உருவாக்கப்பட்ட code, production-ன் சிக்கலான யதார்த்தத்தைச் சந்திக்கும் போது, உங்கள் அமைப்புகளை ஆரோக்கியமாக வைத்திருப்பவர்கள் இத்தகைய பொறியாளர்களே.
திசைகாட்டி இல்லாத வேகம்
AI-ஐ ஒரு accelerator pedal போலக் கருதுங்கள். ஒரு காரில்...