I once asked an AI to build a brand website. What came back looked convincing at first glance, but it was broken in the

ஒருமுறை நான் ஒரு பிராண்ட் இணையதளத்தை (brand website) உருவாக்க AI-யிடம் கேட்டேன். அது முதலில் பார்ப்பதற்கு நம்பகமானதாகத் தெரிந்தாலும், உண்மையில் முக்கியமான விஷயங்களில் அது உடைந்து போயிருந்தது. அதன் தலைப்பில் (header) சரியாக இரண்டு இணைப்புகள் மட்டுமே இருந்தன. எங்கும் "About" பக்கம் இல்லை. பின்புலத்தில் (backend) ஒரு நிர்வாகக் கட்டுப்பாட்டுப் பலகை (admin panel) இருந்தது, ஆனால் முன்புறத்தில் (frontend) அதைச் சென்றடைய எந்தப் பொத்தானோ அல்லது வழித்தடமோ (route) இல்லை. சர்வர் பக்கம் (server side) சரியாகச் செயல்பட்டது. பயனர் பக்கம் (user side) செயல்படவில்லை.

இதைச் சந்திப்பவர்கள் பெரும்பாலானோர் AI சோம்பேறித்தனமாகிவிட்டது அல்லது டோக்கன் வரம்பைத் (token limit) தாண்டிவிட்டது என்று நினைக்கிறார்கள். ஆனால் உண்மையில் நடப்பது அதுவல்ல. பிரச்சனை கட்டமைப்பில் உள்ளது. AI குறியீட்டு கருவிகள் (coding tools) அக ஒத்திசைவை (internal consistency) மட்டும் சரிபார்க்கும் வகையில் உருவாக்கப்பட்டுள்ளன. அவை "நான் அறிவித்த அனைத்தும் ஒன்றுடன் ஒன்று ஒத்துப்போகின்றனவா?" என்றுதான் கேட்கின்றன. "இந்த வகையான ஒரு வெளியீடு (deliverable) அதில் இருக்க வேண்டிய அனைத்தையும் கொண்டுள்ளதா?" என்று அவை கேட்பதில்லை. உங்கள் பிராண்ட் தளத்திற்கு இரண்டு பக்கங்கள் என்று நீங்கள் குறிப்பிட்டால், அந்த இரண்டு பக்கங்களும் ஒன்றுடன் ஒன்று இணைக்கப்பட்டுள்ளதா என்பதை அந்த மாடல் கடமையுடன் சரிபார்க்கும். இணைப்புகள் சரியாக இருந்தால், அந்தப் பணி முடிந்துவிட்டது என்று அது கருதும். ஒரு பிராண்ட் தளத்திற்கு ஒரு "About" பக்கம், நம்பிக்கையைத் தரும் குறிகாட்டிகள் (trust signals) அல்லது ஒரு தொடர்பு வழி (contact path) தேவைப்படும் என்ற அடிப்படை அறிவு அதற்கு இல்லை. அதன் மனதில் எந்தத் தரநிலையும் (standard) இல்லை.

இதற்கான தீர்வை நான் Completeness Baseline என்று அழைக்கிறேன்.

ஒரு Completeness Baseline என்பது ஒரு குறிப்பிட்ட வெளியீடு எவற்றையெல்லாம் கண்டிப்பாகக் கொண்டிருக்க வேண்டும் என்பதற்கான ஒரு தரமான சரிபார்ப்புப் பட்டியல் (checklist) ஆகும். நீங்கள் ஒரு பொருளை (artifact) உருவாக்குகிறீர்கள், பின்னர் அந்தத் கருவியின் "முடிந்தது" என்ற அக உணர்வை நம்புவதற்குப் பதிலாக, இந்த வெளிப்புறத் தரத்துடன் உண்மையான வெளியீட்டைச் சரிபார்க்கிறீர்கள்.

மூன்று அடுக்குகளாகச் சரிபார்த்தல்

விடுபட்ட அனைத்துப் பகுதிகளும் சமமான அளவு வெளிப்படையாக இருப்பதில்லை. ஒரு பயனுள்ள அடிப்படைத் தரம் மூன்று வெவ்வேறு அடுக்குகளைச் சரிபார்க்கிறது.

இருப்பு (Existence). அந்தப் பகுதி உண்மையில் இருக்கிறதா? இது மிகவும் அடிப்படையானதாகத் தோன்றலாம், ஆனால் ஒரு AI ஒரு டேஷ்போர்டு பக்கத்தை (dashboard page) உருவாக்காமலேயே, அந்தப் பக்கத்தைக் குறிப்பிடும் ஒரு நேவிகேஷன் ரேப்பரை (navigation wrapper) மகிழ்ச்சியுடன் உருவாக்கும். அந்தப் பார்வை (reference) இருக்கும், ஆனால் இலக்கு (target) இருக்காது.

அணுகக்கூடிய தன்மை (Reachability). ஒரு உண்மையான பயனர் உண்மையில் அதை அடைய முடியுமா? மறைக்கப்பட்ட நிர்வாகக் கட்டுப்பாட்டுப் பலகைகள் இதற்குச் சிறந்த உதாரணம். அந்த வழித்தடமும் (route) கூறுகளும் (component) குறியீட்டுத் தொகுப்பில் (codebase) இருக்கலாம், ஆனால் எந்த மெனு உருப்படியோ, பொத்தானோ அல்லது ரீடைரக்ட்டோ (redirect) அவற்றை இடைமுகத்திற்கு (interface) கொண்டு வராது. ஒரு பயனர் இயல்பான பயன்பாட்டின் போது அதைத் தற்செயலாகக் கூட கண்டறிய முடியாவிட்டால், அது உண்மையில் அங்கு இல்லை என்றுதான் அர்த்தம்.

உறுதிப்படுத்துதல் (Substantiation). மேற்பரப்பிற்குப் பின்னால் உண்மையான தரவு அல்லது கட்டமைப்பு உள்ளதா? ஒரு பக்கம் லோட் ஆகிறது, ஆனால் அதில் வெறும் மாதிரி உரை (placeholder text) மட்டுமே உள்ளது மற்றும் படம் பதிவேற்றும் வசதி இல்லை என்றால், அது ஒரு வேடம் அணிந்த எலும்புக்கூடு போன்றது. ஒரு "About" பக்கத்தில் படம் பதிவேற்றும் வசதியோ அல்லது மாற்றியமைக்கக்கூடிய உரை புலமோ இல்லையென்றால், அதன் HTML சுத்தமாகத் தெரிந்தாலும் அது முழுமையடையாததுதான்.

இந்த மூன்று அடுக்குகளும் வெவ்வேறு வகையான இடைவெளிகளைக் கண்டறிகின்றன. 'இருப்பு' விடுபட்ட காலணியைக் கண்டறியும். 'அணுகக்கூடிய தன்மை' அலமாரிக்குள் பூட்டப்பட்ட காலணியைக் கண்டறியும். 'உறுதிப்படுத்துதல்' அடிப்பாகம் இல்லாத காலணியைக் கண்டறியும்.

வகைகளுக்கேற்ப அடிப்படைத் தரங்கள் (Baselines by Type)

ஒரே ஒரு அடிப்படைத் தரம் அனைத்துத் திட்டங்களுக்கும் பொருந்தாது. நீங்கள் எதை உருவாக்குகிறீர்கள் என்பதை வகைப்படுத்த வேண்டும் மற்றும் அந்த வகைக்குத் தேவையான தவிர்க்க முடியாத விஷயங்களை வரையறுக்க வேண்டும்.

பிராண்ட் தளங்கள் (Brand sites) குறிப்பிட்ட பிரிவுகள் மற்றும் அணுகக்கூடிய பக்கங்களைக் கொண்டிருக்க வேண்டும். About, Contact, தனியுரிமைக் கொள்கை இணைப்புகள் மற்றும் அனைத்து முக்கியப் பார்வைகளையும் வெளிப்படுத்தும் நேவிகேஷன் ஆகியவற்றைக் கருத்தில் கொள்ளுங்கள்.

API-கள் ஆவணங்கள் (documentation), விரிவான பிழை குறியீடுகள் (error codes) மற்றும் விகித வரம்புகள் (rate limits) ஆகியவற்றைக் கொண்டிருக்க வேண்டும். வெற்றிக்கு 200 OK என்பதையும், மற்ற அனைத்திற்கும் பொதுவான 500 என்பதையும் வழங்கும் ஒரு வேலை செய்யும் எண்ட்பாயிண்ட் (endpoint) ஒரு முழுமையான API அல்ல. அது ஒரு ஆபத்து.

தானியக்கமாக்கல் (Automations) பதிவுகள் (logs) மற்றும் தோல்வி எச்சரிக்கைகளைக் (failure alerts) கொண்டிருக்க வேண்டும். ஒரு பணிப்பாய்வு (workflow) அதிகாலை 2 மணிக்குத் தடைபட்டு, ஒரு மனிதன் அதன் வரலாற்றைச் சரிபார்க்கும் வரை யாருக்கும் தெரியவில்லை என்றால், அந்தத் தானியக்கமாக்கல் முழுமையடையாதது. கண்காணிப்புத் திறன் (Observability) என்பது ஒரு கூடுதல் அம்சம் அல்ல. அது வழங்கப்பட வேண்டிய ஒரு பகுதியாகும்.

நீங்கள் வகையைத் தீர்மானித்துவிட்டால், அடிப்படைத் தரம் தானாகவே உருவாகிவிடும். குறியீடு உருவாக்கப்பட்ட பிறகு அதை நடைமுறைப்படுத்துவதே கடினமான பகுதி.

நிலைத்து நிற்கும் வடிவமைப்பு விதிகள்

நான் எனது சொந்தப் பணிப்பாய்வை இந்த யோசையைச் சுற்றி மறுசீரமைத்தேன் மற்றும் திட்டங்கள் மெதுவாகச் சிதைந்து போகாமல் தடுக்கும் மூன்று நடைமுறை விதிகளைக் கண்டறிந்தேன்.

திறன் சார்ந்த வடிவமைப்பு (Capability-gated design). ஒரு கருவி அல்லது உருவாக்கப்பட்ட தொகுதியை (module) நீங்கள் ஏற்றுக்கொள்வதற்கு முன், அது உண்மையில் என்ன செய்ய முடியும் என்பதைக் கண்டறியுங்கள். ஒரு கூறு நூலகத்தில் (component library) இயல்பான மொபைல் டிராயர் (mobile drawer) ஆதரவு இல்லை என்றால், அது இருப்பதாகக் கருதி ஒரு முழுமையான நேவிகேஷன் திட்டத்தை உருவாக்க AI-யை அனுமதிக்காதீர்கள். ஒரு திறன் இல்லாதபோது, சிதைந்து போவதற்குப் பதிலாக, அந்த அமைப்பு மென்மையாகச் செயல்பட வேண்டும் (degrade gracefully). எல்லைகளை முதலில் தெரிந்து கொள்ளுங்கள். அவற்றிற்குள்ளேயே வடிவமைக்கவும்.

பொது இயந்திரம், தனிப்பட்ட மதிப்புகள் (Public engine, private values). கடினமான வேலைகளுக்கு ஒரு பொதுவான இயந்திரத்தைப் பயன்படுத்துங்கள், ஆனால் உங்கள் தனிப்பட்ட தரவு, உள்ளமைப்புகள் (configs) மற்றும் மரபுகளை (conventions) ரன்டைமில் (runtime) உள்ளீடு செய்யுங்கள். இது உங்கள் தனிப்பட்ட அல்லது நிறுவன முறைகளை உருவாக்கப்பட்ட கட்டமைப்பிலிருந்து பாதுகாப்பாகவும் தனித்தனியாகவும் வைத்திருக்கும். AI கட்டமைப்பை உருவாக்குகிறது. நீங்கள் கண்ணாடியைப் பொருத்துகிறீர்கள். இது உங்கள் உண்மையான தரநிலைகளை மீறும் அல்லது முக்கியமான முறைகளை பொதுப் பயிற்சியின் சூழலில் (public training contexts) கசியவிடும் அனுமானங்களை மாடல் கடினமாக குறியீடாக்குவதைத் (hard-coding) தடுக்கிறது.

முன்மொழியுங்கள், தானாக முன்னேற அனுமதிக்காதீர்கள். AI அடுத்த கட்டத்தைப் பரிந்துரைக்கட்டும், ஆனால் ஒரு மனிதர் தான் அந்தத் தேர்வை எடுக்க வேண்டும். செயல்பாட்டின் ஓட்டத்தை தானியக்கமாக்குங்கள், ஆனால் தீர்ப்பை ஒருபோதும் அல்ல. ஒரு மாடல் ஒரே மூச்சில் ஒரு database migration, an auth scheme மற்றும் ஒரு payment hook ஆகியவற்றைத் தானாக உருவாக்கும்போது, நீங்கள் கவனக்குறைவின் விலையில் வசதியைப் பெறுகிறீர்கள். கருவி திட்டத்தை முன்வைக்கச் செய்யுங்கள். டெவலப்பர் தான் அந்தப் பொத்தானை அழுத்தட்டும்.

சரியான வேலையைச் செய்ய சரியான மாடலைத் தேர்ந்தெடுப்பது

நான் இதை வெவ்வேறு மாடல்களில் சோதித்துப் பார்த்தேன், அதன் மதிப்பில் ஒரு தெளிவான வேறுபாட்டைக் கண்டேன். மலிவான மாடல்கள் இயந்திரத்தனமான அதிகப்படியான வேலைகளை (mechanical bulk) வியக்கத்தக்க வகையில் கையாளுகின்றன. நீங்கள் தட்டச்சு செய்வதை விட வேகமாக அவை boilerplate, திரும்பத் திரும்ப வரும் கூறுகள் (repetitive components) மற்றும் structural stubs ஆகியவற்றை உருவாக்குகின்றன. விலையுயர்ந்த மாடல்கள் அவற்றின் கட்டுப்பாட்டை (restraint) வெளிப்படுத்தும் போது மட்டுமே அவற்றின் விலைக்குத் தகுதியானவை. போலித் தீர்வுகளைக் கற்பனை செய்ய மறுத்து, உண்மையான இடைவெளியைக் (gap) சுட்டிக்காட்டும்போது நீங்கள் அந்த பிரீமியம் விருப்பத்தை விரும்புகிறீர்கள். விடுபட்ட API endpoint-க்கு ஒரு போலித் தீர்வை (workaround) கற்பனை செய்து கூறும் மாடல் ஆபத்தானது. "இந்த workflow-க்கு வரையறுக்கப்படாத ஒரு webhook target தேவைப்படுகிறது" என்று கூறி நிற்கும் மாடல் அதன் விலைக்குத் தகுதியானது. அளவிற்காக அல்ல, பகுத்தறிவிற்காக (discernment) பணம் செலுத்துங்கள்.

கட்டமைப்புகளை உருவாக்குங்கள், மாயையைத் தேடாதீர்கள்

பெரிய மாடல்களையோ அல்லது கூடுதல் prompting நுணுக்கங்களையோ பயன்படுத்தி AI இடைவெளிகளைச் சரிசெய்ய முயற்சிக்காதீர்கள். அவற்றை ஒரு அடிப்படைத் தரத்தைக் (baseline) கொண்டு சரிசெய்யுங்கள். அந்த இடைவெளியானது ஒரு திறன் சார்ந்த பிரச்சனை அல்ல; அது எதிர்பார்ப்புகள் சார்ந்த பிரச்சனை.

விடுபட்ட பகுதிகளைத் தவிர்க்க, மூன்று விஷயங்களைச் செய்யுங்கள்.

எந்தக் குறியீடும் எழுதப்படுவதற்கு முன்பே, அந்த அமைப்பிற்கு ஒரு முழுமைத் தரத்தை (completeness baseline) வழங்குங்கள். அதை அந்தப் பணிக்கு அருகிலேயே இருக்கும் ஒரு சரிபார்ப்புப் பட்டியலாக (checklist) மாற்றுங்கள்.

உங்கள் மரபுகளை (conventions) மீண்டும் பயன்படுத்தக்கூடிய பாகங்களாக மாற்றுங்கள். Templates, lint rules அல்லது pre-built scaffolds மூலம் உங்கள் அடிப்படைத் தரத்தை நீங்கள் நடைமுறைப்படுத்தினால், AI உங்கள் தரநிலைகளைக் கணிப்பதாக நம்பியிருப்பதை விட, சரியான நிலையிலிருந்தே தொடங்கும்.

தீர்ப்புகளைக் கையாளும் அதிகாரத்தை மனிதனிடமே வைத்துக்கொண்டு, செயல்பாட்டின் ஓட்டத்தைத் தானியக்கமாக்குங்கள். இயந்திரங்களைத் திரும்பத் திரும்பச் செய்யும் வேலைகளைச் செய்ய விடுங்கள். சூழலைப் புரிந்துகொள்ளும் மனிதர்களுக்காக முடிவெடுக்கும் அதிகாரத்தை ஒதுக்கி வையுங்கள்.

எனது வேலை செய்யும் முறையை மாற்றிய ஒரு கடைசிப் பழக்கம் இதோ. நீங்கள் ஒரே வடிவமைப்பு முடிவை (design decision) ஏழு முறை எடுத்தால், அதை ஒரு முறை எடுக்கப்பட்ட முடிவாகக் கருதாதீர்கள். அது வெறும் திரும்பத் திரும்பச் செய்யும் செயல் அல்ல; அது ஒரு விதி. அதற்குப் பெயரிடுங்கள். அதை ஒரு விதியாக மாற்றுங்கள். ஆவணப்படுத்துங்கள். அந்த முறையை நீங்கள் முறைப்படுத்தும்போது (codify), எட்டாவது முறை AI அதிலிருந்து விலகிச் செல்லும் வாய்ப்பை நீங்கள் நீக்குகிறீர்கள்.

இந்த கட்டமைப்பிற்கான ஆதாரம் மற்றும் அசல் ஆய்வு இங்கே காணப்படலாம்.

இதே போன்ற சிக்கல்களைக் கையாண்டு வரும் மற்றவர்களுடன் கருத்துக்களைப் பகிர்ந்து கொள்ள விரும்பினால், நீங்கள் GyaanSetu learning community-இல் இணையலாம்.