பலரும் AI மென்பொருள் உருவாக்கத்தை (software development) மிகவும் மலிவாக்கிவிடும் என்று கூறுகிறார்கள். மாடல்கள் பொறியாளர்களைப் பதிலீடு செய்து, பணிகளை நிமிடங்களில் முடித்துவிடும் என்று அவர்கள் கற்பனை செய்கிறார்கள். அந்தத் தகவல் கவர்ச்சிகரமானதுதான், ஆனால் அது முழுமையாக உண்மை அல்ல. மென்பொருள் உருவாக்கத்தின் பொருளாதாரம் மாறியதே தவிர, மறைந்துவிடவில்லை. முதல் கோடிங் உதவியாளர் (coding assistant) வந்தபோது தொழில்நுட்பக் கடன் (technical debt) ஆவியாகிவிடவில்லை. அதற்கு நிதி வழங்குவதற்கான ஒரு புதிய வழியை நாம் கண்டறிந்துள்ளோம், அவ்வளவுதான்.
பழைய விலைப்பட்டியல்: பணியாளர்களின் எண்ணிக்கை (Head Count)
பல தசாப்தங்களாக, தொழில்நுட்பக் கடன் ஒரு பழக்கமான அழிவுச் சுழற்சியை (doom loop) உருவாக்கியது. ஒரு கோட்பேஸ் (codebase) உடையக்கூடியதாக (brittle) வளரும். ஒரு காலத்தில் சில நாட்கள் எடுத்த அம்சங்கள் (features), இப்போது வாரக்கணக்கில் ஆகத் தொடங்கின. காலக்கெடு தவறியதால், நிர்வாகம் கூடுதல் பணியிடங்களை அறிவித்தது. பெரிய குழுக்கள் வேலையை இன்னும் மெதுவாக்கின. ஒருங்கிணைப்புச் சுமை (coordination overhead) அதிகரித்தது, ஸ்டாண்ட்-அப் கூட்டங்கள் பெருகின, மேலும் கான்வே விதி (Conway’s Law) நடைமுறைக்கு வந்தது: மென்பொருள் அதை உருவாக்கும் மக்களின் தகவல் தொடர்புத் தோல்வியையே பிரதிபலிக்கத் தொடங்கியது. அதிக பிழைகள் (bugs) உள்ளே நுழைந்தன. ஒவ்வொரு திருத்தமும் (patch) புதிய சிக்கல்களைச் சேர்த்தன. நிறுவனங்கள் இந்தச் சிதைவிற்குத் தங்களுக்குத் தெரிந்த ஒரே நாணயமான மனித ஊதியங்களைக் கொண்டே விலை செலுத்தின. அந்தச் செலவு வெளிப்படையானது. ஒவ்வொரு காலாண்டு பட்ஜெட் ஆய்விலும் அது தெளிவாகத் தெரிந்தது.
புதிய விலைப்பட்டியல்: டோக்கன்கள் மற்றும் சூழல் (Tokens and Context)
ஜெனரேட்டிவ் AI இந்தச் சுழற்சியை உடைக்கவில்லை. அது ஒரு மாற்றுச் செலுத்தும் முறையை மட்டுமே அறிமுகப்படுத்தியுள்ளது. தடைகளைத் தாண்ட ஐந்து பொறியாளர்களை வேலைக்கு அமர்த்துவதற்குப் பதிலாக, ஒரு நிறுவனம் இப்போது அதிக கம்ப்யூட் (compute) வசதிக்காக கிரெடிட் கார்டைப் பயன்படுத்துகிறது. அறிகுறிகள் வித்தியாசமாகத் தெரிந்தாலும், அடிப்படையிலுள்ள நோய் ஒன்றுதான்.
ஒரு மாடல் தோல்வியடையத் தொடங்கும்போது—உள் API-களைத் தவறாகக் கற்பனை செய்வது (hallucinating), முக்கியமான விளிம்பு நிலைச் சூழல்களைத் (edge cases) தவறவிடுவது, தவறான காரணங்களுக்காகப் Pass ஆகும் சோதனைகளை உருவாக்குவது—அதைச் சரிசெய்ய (refactor) முயற்சிப்பது அரிதாகவே உள்ளது. அதற்குப் பதிலாக இன்ஃபரன்ஸ் (inference) செய்வதற்குப் பணம் செலவழிப்பதே வழக்கமாகிவிட்டது. குழுக்கள் context-window மேம்பாடுகளை வாங்குகின்றன, பல ஏஜென்ட் மறுமுயற்சி சுழற்சிகளை (multi-agent retry loops) உருவாக்குகின்றன, அதிக திறன் கொண்ட மாடல்களுக்கு (frontier models) பணிகளை மாற்றுகின்றன, அல்லது மாற்றங்கள் (diff) ஏற்றுக்கொள்ளத்தக்கதாகத் தெரியும் வரை 'regenerate' பொத்தானை அழுத்துகின்றன. இந்த உத்திகள் ஒரு சில ஸ்பிரிண்டுகளுக்கு (sprints) மட்டும் வேகம் இருப்பது போன்ற தோற்றத்தைத் தருகின்றன. Jira போர்டு பச்சை நிறத்திலேயே இருக்கும். இதற்கிடையில், உண்மையான கட்டமைப்பு (architecture) மாற்றமடையாமல் அப்படியே இருக்கிறது: அதே சிக்கலான சார்புகள் (dependencies), அதே மாறக்கூடிய உலகளாவிய நிலை (mutable global state), மற்றும் தற்போதைய குழுவில் யாருக்கும் முழுமையாகப் புரியாத அதே மோனோலித் (monolith) அமைப்பு.
ஏன் அழுக்கான குறியீடு (Dirty Code) டோக்கன்களைச் செலவிடுகிறது?
பெரிய மொழி மாதிரிகள் (LLMs) சுத்தமான சுருக்கங்களுக்கு (clean abstractions) எதிராகச் சிறப்பாகச் செயல்படுகின்றன. இருப்பினும், பெரும்பாலான நிறுவனக் களஞ்சியங்கள் (enterprise repositories) தொல்பொருள் தளங்களைப் போல உள்ளன. அவற்றில் சுழற்சி முறையிலான பேக்கேஜ் சார்புகள் (circular package dependencies), தொடக்க ஸ்கிரிப்டுகளில் (initialization scripts) மறைந்துள்ள பக்க விளைவுகள் (side effects), மற்றும் டேட்டாபேஸ் ட்ரிகர்கள் (database triggers), மிட்ல்வேர் அடுக்குகள் (middleware layers) மற்றும் முன்முனை கூறுகளில் (front-end components) சிதறிக்கிடக்கும் வணிகத் தர்க்கங்கள் (business logic) உள்ளன. அத்தகைய சூழலில், மாடல் புதிய தர்க்கங்களை எழுதுவதற்குத் தனது ஆற்றலைச் செலவிடுவதில்லை. மாறாக, புரிந்து கொள்வதற்கே (comprehension) டோக்கன்களைச் செலவிடுகிறது.
128,000-டோக்கன் கொண்ட context window-வில் ஒரு பெரும் பகுதி, அமைப்பின் வடிவத்தை நினைவகத்தில் (memory) வைத்திருப்பதே செலவழித்துவிடும். மீதமுள்ள சிறிய பகுதி மட்டுமே உண்மையான சிக்கலைத் தீர்ப்பதற்கு இருக்கும். இது ஒரு கட்டுமானப் பொறியாளரிடம் புதிய தளத்தை வடிவமைக்கச் சொல்லிவிட்டு, ஒவ்வொரு கணக்கீட்டிற்கும் முன்னால் தற்போதுள்ள கட்டிடத்தின் வரைபடத்தை அவர் நினைவிலிருந்து மீண்டும் வரையச் சொல்வதைப் போன்றது. இதன் விளைவு மேலோட்டமான தீர்வுகளாகவே இருக்கும். மாடல் பார்க்கும் குழப்பத்தையே அது பிரதிபலிக்கிறது, ஏனெனில் அந்த அறையை முதலில் சுத்தம் செய்ய அதற்குத் தேவையான அதிகாரம் அல்லது கட்டமைப்புச் சூழல் (architectural context) இல்லை.
வேகமான வெளியீடு, மெதுவான விநியோகம் (Faster Output, Slower Shipping)
வெறும் உருவாக்கும் வேகம் (generation speed) என்பது மென்பொருளை வெளியிடும் வேகத்திற்கு (shipping speed) சமமல்ல. உங்கள் கட்டமைப்பு மாடுலாரிட்டி (modularity) அற்றதாக இருந்தால், AI மூலம் உருவாக்கப்படும் ஒவ்வொரு மாற்றமும் விரிவான மனித ஆய்வு மற்றும் ரீக்ரஷன் டெஸ்டிங் (regression testing) ஆகியவற்றைத் தேவைப்படுத்தும். ஒரு மாடல் ஒரு மதிய வேளையில் பத்து pull requests-களை உருவாக்க முடியும், ஆனால் அந்த pull requests இன்னும் ஒருங்கிணைப்பு சூழல்கள் (integration environments), பாதுகாப்பு ஸ்கேனர்கள் (security scanners), இணக்கச் சரிபார்ப்புப் பட்டியல்கள் (compliance checklists) மற்றும் புரொடக்ஷன் கனேரி (production canaries) ஆகியவற்றின் வழியாகச் செல்ல வேண்டும். தெளிவான மாட்யூல் எல்லைகள் இல்லையென்றால், AI இயந்திர வேகத்தில் பிழைகளை (bugs) உருவாக்குகிறது. அது ஒரு பொதுவான பயன்பாட்டு கருவியை (shared utility) மாற்றியமைக்கலாம், நுணுக்கமான தவறான அனுமானங்களுடன் மூன்று தொலைதூர அழைப்பு இடங்களை (call sites) புதுப்பிக்கலாம், மேலும் அதிகாலை 3 மணிக்கு வரும் அழைப்பின் போது மட்டுமே மனிதர்களால் கண்டறியக்கூடிய ரேஸ் கண்டிஷன்களை (race conditions) உருவாக்கலாம். சிக்கல் (bottleneck) விசைப்பலகையிலிருந்து சரிபார்ப்புப் பாதைக்கு (validation pipeline) மாறுகிறது, மேலும் அந்தப் பாதை மாற்றங்களின் அளவை பத்து மடங்கு அதிகரிப்பைக் கையாளும் வகையில் வடிவமைக்கப்படவில்லை.
மறைக்கப்பட்ட உச்சவரம்பு (The Hidden Ceiling)
AI-க்கு முந்தைய காலத்தில், கடினமான வரம்பு என்பது உங்கள் பணியமர்த்தல் பட்ஜெட் (hiring budget) ஆகும். அதை ஒரு ஸ்பிரெட்ஷீட்டில் (spreadsheet) பார்ப்பது எளிது. இப்போது அந்தத் தடை நிதித் குழுக்கள் மிகக் குறைவாகவே கவனிக்கும் சில செலவுப் பட்டியல்களுக்குள் புதைந்து கிடக்கிறது: இன்ஃபரன்ஸ் செலவுகள் (inference costs), எம்பெடிங் சேமிப்பு (embedding storage), context-window விரிவாக்கங்கள் மற்றும் CI ரன்னர்களை முடக்கும் தானியங்கி சோதனைத் தடைகள் (automated-testing gridlock). உற்பத்தித் திறன் டாஷ்போர்டுகள் (Productivity dashboards) பச்சை நிறத்தில் மின்னிக்கொண்டிருக்கும், ஆனால் ஒவ்வொரு புதிய அம்சத்தின் உண்மையான செலவும் அமைதியாகக் கூட்டு வட்டியாகக் கூடிக்கொண்டே போகிறது.
இங்கு உண்மையான வில்லன் கட்டமைப்புச் சிதைவு (Architectural entropy) தான். LLM-கள் குறியீடு உற்பத்தியை மிகச் சிறப்பாகப் பெருமளவில் அதிகரிக்கின்றன, ஆனால் அவை சிக்கலைக் குறைப்பதில்லை. அவை மைக்ரோசர்வீஸ்களைச் (microservices) சிக்கலிலிருந்து விடுவிக்கவோ, பயன்படாத குறியீடுகளை (dead code) நீக்கவோ அல்லது வாரிசுரிமை படிநிலைகளைச் (inheritance hierarchies) சுருக்கவோ செய்வதில்லை. ஒரு அமைப்பு, மனிதர்களால் அதைப் பற்றி பகுத்தறிய முடியாத ஒரு வரம்பைத் தாண்டிவிட்டால், AI-யும் திணறும். அந்தத் திருப்புமுனையில், நீங்கள்... ஆனாலும் செலவுகள் உயரும் போக்கிலேயே இருக்கும்.