ChatGPT, GitHub Copilot, Cursor மற்றும் அவற்றின் உறவினர்கள், நீங்கள் ஒரு ப்ராம்ப்ட்டை (prompt) தட்டச்சு செய்து முடிப்பதற்கு முன்பே ஒரு React component-ஐ உருவாக்கித் தர முடியும். ஒரு Next.js route-ஐ Supabase உடன் இணைக்க வேண்டுமா? சில நொடிகளில் முடிந்துவிடும். சிக்கலான அந்த TypeScript utility-ஐ மாற்றியமைக்க (Refactor) வேண்டுமா? இதோ type guards உடன் கூடிய மூன்று விருப்பங்கள். நவீன வெப் ஸ்டேக் (web stacks) துறையில் பணியாற்றுபவர்களுக்கு, இந்த அனுபவம் கிட்டத்தட்ட ஒரு மந்திரம் போலத் தோன்றலாம்.
நான் இந்தத் கருவிகளைத் தினமும் பயன்படுத்துகிறேன். எனது ஸ்டேக் Next.js, TypeScript மற்றும் Supabase ஆகும், மேலும் எனது எடிட்டரிலேயே AI உள்ளது, இது custom hooks-களை உருவாக்கவும், database queries-களை உருவாக்கவும் அல்லது குழப்பமான conditional logic-களைச் சரிசெய்யவும் தயாராக உள்ளது. சிறிய அளவில் பார்த்தால், இது ஒரு மிக வேகமான ஜூனியர் டெவலப்பரைப் போலச் செயல்படுகிறது. இதற்கு syntax நன்றாகத் தெரியும். நான் கூகுளில் தேட வேண்டிய API surface areas-களை இது நினைவில் வைத்திருக்கிறது. Boilerplate குறியீடுகளை எழுதுவதற்கு இது சோர்வடைவதில்லை.
ஆனால் மென்பொருள்கள் தொடர்ந்து உடைந்து கொண்டே இருக்கின்றன. செயலிகள் மெதுவாகத் தோன்றுகின்றன. வாடிக்கையாளர் டேஷ்போர்டுகள் (dashboards) தாமதமாகின்றன. விளிம்புநிலைச் சூழல்கள் (Edge cases) படிவங்களை (forms) முடக்குகின்றன. AI கோடிங் செய்வதை இவ்வளவு எளிதாக்கியிருந்தால், சில ஆண்டுகளுக்கு முன்பு இருந்ததை விட இப்போது மென்பொருள்களைப் பயன்படுத்துவது ஏன் மோசமாகத் தோன்றுகிறது?
இதற்கான பதில் என்னவென்றால், syntax-ஐ உருவாக்குவதும் மென்பொருளை உருவாக்குவதும் ஒன்றல்ல.
Syntax என்பது Architecture அல்ல
AI டோக்கன்களை (tokens) வியக்கத்தக்க வகையில் கையாள்கிறது. ஒரு Supabase real-time channel-ஐக் கவனிக்கும் useEffect hook-ஐ எழுதச் சொன்னால், அது கம்பைல் (compile) செய்யக்கூடிய ஒன்றைத் தரும். நீங்கள் காபி குடிப்பதற்கு முன்பே, ஒரு untyped JavaScript கோப்பைத் துல்லியமான TypeScript-ஆக மாற்றவோ அல்லது Zod validation உடன் கூடிய ஒரு form component-ஐ உருவாக்கவோ இது முடியும்.
உங்கள் குறிப்பிட்ட பயன்பாட்டின் (application) நுணுக்கங்களைப் புரிந்துகொள்வது மட்டுமே இதற்குத் தெரியாது. சிறந்த மென்பொருளுக்குத் திட்டமிடப்பட்ட state management, race conditions-களைக் கவனமாகக் கையாளுதல் மற்றும் தரவு எங்குள்ளது மற்றும் எங்கு காண்பிக்கப்படுகிறது என்பதற்கான தெளிவான வரைபடம் தேவை. AI தற்போதைய கோப்பை மட்டுமே பார்க்கிறது, முழு அமைப்பையும் (system) பார்க்கவில்லை. இது உங்கள் codebase-ஐ ஒரு உயிருள்ள கட்டமைப்பாகப் பார்க்காமல், ஒரு தட்டையான உரை நடைப்பாதை (flat text corridor) போலக் கருதுகிறது.
ஒரு வீட்டில் வாழ்ந்து பார்த்திராத ஒரு கட்டிடக் கலைஞரைப் போல இதை நினைத்துப் பாருங்கள். அவர்களால் அழகான வரைபடங்களை வரைய முடியும். ஒரு படுக்கையறையில் எத்தனை ஜன்னல்கள் இருக்க வேண்டும் என்று அவர்களுக்குத் தெரியும். ஆனால் பிப்ரவரி மாதத்தில் குழாய்கள் எங்கே கசியும் அல்லது கோடை வெப்பத்தில் எந்த நடைபாதை பயன்படுத்த முடியாததாக மாறும் என்பது அவர்களுக்குத் தெரியாது. அந்த அனுபவ அறிவுதான் ஒரு கட்டிடத்தை நிலைநிறுத்துகிறது. குறியீடும் (Code) அதே வழியில் செயல்படுகிறது.
இரண்டு உராய்வுப் புள்ளிகள் (Friction Points)
கடுமையான கட்டுப்பாடுகள் (guardrails) இல்லாமல் AI-யிடம் பெரிய அளவிலான குறியீடுகளை எழுதச் சொல்லும்போது, ஒரே இரண்டு பிரச்சனைகள் மீண்டும் மீண்டும் வருவதை நான் கவனிக்கிறேன்.
முதலாவதாக, நீங்கள் ஏற்கனவே உருவாக்கியுள்ள design patterns-களை இது புறக்கணிக்கிறது. ஒருவேளை உங்கள் குழு அனைத்து தரவுப் பெறுதலையும் (data fetching) பிரத்யேக custom hooks அடுக்குக்கு மாற்றியிருக்கலாம். அல்லது Supabase RLS கொள்கைகள் frontend helpers-உடன் எவ்வாறு இணைகின்றன என்பதற்கான கடுமையான விதிமுறைகளை நீங்கள் வைத்திருக்கலாம். AI இதைப் பொருட்படுத்தாது. அந்த ப்ராம்ப்ட்டிற்கு அது தீர்வாக இருந்தால், ஒரு பட்டனின் onClick-க்குள் நேரடியாக ஒரு supabase.from().select()-ஐ அது போட்டுவிடும். குறியீடு இயங்கும். அது சுத்தமாகவும் கூடத் தெரியும். ஆனால் அது உங்கள் codebase-ல் ஒரு விதிவிலக்காக (outlier) இருக்கும், மேலும் ஒவ்வொரு விதிவிலக்கும் எதிர்கால refactoring வரி (tax) போன்றது. ஆறு மாதங்களுக்குப் பிறகு, யாராவது அந்த ஊசியைக் கண்டுபிடித்து, அது ஏன் அங்கு இருக்கிறது என்பதைப் புரிந்துகொண்டு, அதை மெதுவாகச் சரியான வரிசைக்குக் கொண்டு வர வேண்டும்.
இரண்டாவதாக, எளிமை போதுமான இடத்தில் இது சிக்கலைத் தேடிச் செல்கிறது. இந்தத் கருவி, abstract factories, சிக்கலான reducer patterns மற்றும் பல அடுக்கு বিশিষ্ট higher-order components தேவைப்படும் அளவுக்குப் பெரிய repositories-களைக் கொண்டு பயிற்சியளிக்கப்பட்டது. நீங்கள் ஒரு எளிய contact form-ஐ உருவாக்கச் சொன்னால், அது ஒரு state machine, ஒரு context provider மற்றும் மூன்று கோப்புகளைக் கொண்ட ஒரு custom hook abstraction-ஐ உங்களுக்குத் தரக்கூடும். அந்தத் தீர்வு தொழில்நுட்ப ரீதியாகத் தவறல்ல. ஆனால் அது மிகவும் கனமானது. ஒவ்வொரு தேவையற்ற அடுக்கும் அறிவாற்றல் கடனை (cognitive debt) அதிகரிக்கிறது. நீங்கள் வேலையைத் தவிர்க்கவில்லை; வட்டியுடன் அதைத் தள்ளிப்போட்டுவிட்டீர்கள்.
வேகத்தின் பொறி (The Velocity Trap)
இங்கே ஒரு ஆபத்தான பின்னூட்டச் சுழற்சி (feedback loop) உள்ளது. AI உங்களை இரண்டு மடங்கு வேகத்தில் அம்சங்களை (features) உருவாக்க அனுமதிக்கிறது, ஆனால் மனிதக் கவனம் அதே வேகத்தில் அதிகரிக்காது. நீங்கள் பாதி நேரத்தில் வெளியிடுகிறீர்கள் என்றால், code review செய்ய நீங்கள் இரண்டு மடங்கு அதிக நேரத்தைச் செலவிடுகிறீர்களா? நீங்கள் அதிக சோதனைகளை (tests) எழுதுகிறீர்களா அல்லது குறைவானவையா?
நடைமுறையில், உருவாக்கப்பட்ட குறியீட்டை நம்புவது மிகவும் எளிது, ஏனெனில் அது அதிகாரப்பூர்வமாகத் தோன்றுகிறது. அது நவீன syntax-ஐப் பயன்படுத்துகிறது. சரியான இடங்களில் கருத்துகள் (comments) சேர்க்கப்பட்டுள்ளன. மாறிப் பெயர்கள் (variable names) தொழில்முறைத் தரத்தில் உள்ளன. அந்தத் துல்லியத்திற்குள் நுட்பமான பிழைகள் (subtle bugs) ஒளிந்துள்ளன. ஒரு hook-ல் setter-ஐத் தவிர்த்த dependency array. தொழில்நுட்ப ரீதியாகச் சரியானது ஆனால் நீங்கள் கையாள மறந்த ஒரு null state-ஐ அனுமதிக்கும் TypeScript type. உங்கள் குறிப்பிட்ட schema-வில் soft-deleted வரிசைகளைக் கணக்கில் கொள்ள மறந்த ஒரு Supabase query. டெலிவரி வேகம் காரணமாக, நீங்கள் ஒவ்வொரு வரியையும் வாசிப்பதற்குப் பதிலாக மேலோட்டமாகப் பார்க்கிறீர்கள். திங்கட்கிழமை அந்த வேகம் சிறப்பாகத் தோன்றும். ஆனால் வெள்ளிக்கிழமை அந்த debugging அமர்வு நள்ளிரவு வரை நீடிக்கும்.
உண்மையான விலை (The Real Cost)
இதற்காக விலை கொடுப்பவர்கள் டெவலப்பர்கள் அல்ல. அவர்கள் இறுதிப் பயனர்கள் (end users).
மென்பொருள் பயன்பாடு மந்தமாகவும் கடினமாகவும் உணரப்படுகிறது, ஏனெனில் குழுக்கள் அதை நிர்வகிக்கும் வேகத்தை விட சிக்கல்தன்மை வேகமாக வளர்ந்து வருகிறது. நாம் நம்மை অপরাஹரமானவர்களாக உணரச் செய்யும் கருவிகளுடன், சிறிய குழுக்களைக் கொண்டு பெரிய பயன்பாடுகளை உருவாக்கி வருகிறோம். ஒரு டெவலப்பர் ஒரு மதிய வேளையிலேயே ஒரு முழு டேஷ்போர்டை (dashboard) உருவாக்கிவிட முடியும் போது, நிறுவனம் புதன்கிழமைக்குள் மூன்று டேஷ்போர்டுகளை எதிர்பார்க்கிறது. கவனமில்லாத விரிவாக்கம் (Scale) பலவீனமான அமைப்புகளை உருவாக்குகிறது. State அளவு அதீதமாக உயர்கிறது. Bundle அளவுகள் மெல்ல மெல்ல அதிகரிக்கின்றன. Race conditions பெருகுகின்றன. இடைமுகம் (Interface) நவீனமாகத் தோன்றலாம், ஆனால் ஒரு பயனர் 'back' பொத்தானை அழுத்தும்போது அது தானாகவே ரீசெட் ஆகிறது, அல்லது AI-ஆல் உருவாக்கப்பட்ட தரவுப் பெறல்களின் (data fetches) waterfall வரிசையை ஆய்வு செய்ய யாருக்கும் நேரம் இல்லாததால், அது hydrate ஆக நான்கு வினாடிகள் எடுத்துக்கொள்கிறது.
இயந்திரத்துடன் இணைந்து பணியாற்றுங்கள், அதற்காக அல்ல
இதற்கெல்லாம் நீங்கள் உங்கள் எடிட்டரிலிருந்து (editor) AI-ஐத் தூக்கி எறிய வேண்டும் என்று அர்த்தமல்ல. உங்களுக்கு எல்லைகள் தேவை என்று அர்த்தம்.
அது எதில் சிறந்து விளங்குகிறதோ அதற்காகப் பயன்படுத்துங்கள். சலிப்பூட்டும் வேலைகளை அதற்கு விட்டுவிடுங்கள்: மீண்டும் மீண்டும் வரும் TypeScript interfaces, boilerplate Supabase queries, Jest setup போன்றவை.