When someone tells you they shipped 335 live pages across 26 repositories in 29 days, working alone, the instinct is to

ஒருவர் தனியாகவே 29 நாட்களில் 26 களஞ்சியங்களில் (repositories) 335 நேரலைப் பக்கங்களை (live pages) வெளியிட்டதாகச் சொன்னால், அவர் எப்படி இவ்வளவு வேகமாகச் செய்துகொண்டார் என்று கேட்பதே இயல்பான எதிர்வினை. ஆனால், அதைவிடச் சிறந்த கேள்வி, அவர் அவ்வாறு செய்தபோது எதெல்லாம் உடைந்து போனது என்பதுதான்.

அந்த எண்கள் உண்மையானவை: 1,549 கமிட்கள் (commits), 26 களஞ்சியங்கள் (repos), 29 நாட்கள், Claude Code பயன்படுத்தும் ஒரு டெவலப்பர். ஆனால் வேகம் மட்டுமே உங்களுக்குப் பெரிய பாடங்களைக் கற்றுத் தராது. தோல்விகளின் தன்மைதான் முக்கியமானது, ஏனெனில் அவை ஒரு stack trace-இல் கண்டறியக்கூடிய சாதாரணத் தவறுகள் அல்ல. அவை கட்டமைப்பு ரீதியான விரிசல்கள் (structural fractures). எடிட்டரிலிருந்து விலகி நின்று, தயாரிப்புச் சூழலில் (production) இயங்கும் முழு அமைப்பையும் உற்று நோக்கும்போது மட்டுமே அவற்றை உங்களால் காண முடியும்.

எது வேலை செய்தது

அந்த வேகம் ஒரு மாயை அல்ல. தூக்கமில்லாத ஒரு AI-யிடம் சில பணிகளைக் ஒப்படைக்கும்போது, அவற்றின் கால அளவு உண்மையில் வெகுவாகக் குறைகிறது.

பாடப்புத்தகம் போன்ற அல்காரிதம்கள் (Textbook algorithms) வாரக்கணக்கில் அல்லாமல், சில நாட்களிலேயே பயன்பாட்டு அம்சங்களாக (features) மாறின. 2048 solver மற்றும் minimax அடிப்படையிலான விளையாட்டுகள் விரைவாக உருவானதற்கு அவற்றின் செயல்படுத்தும் முறைகள் (implementation patterns) நன்கு ஆவணப்படுத்தப்பட்டிருந்ததே காரணம். அந்த மாடல் கல்விசார் ஆய்வுக் கட்டுரைகளில் திசைமாறிப் போவதில்லை; அது search tree, heuristic evaluation, move scoring ஆகியவற்றை எழுதிவிட்டு அடுத்த வேலைக்குச் சென்றுவிடுகிறது. இவை ஏற்கனவே தீர்க்கப்பட்ட சிக்கல்கள், மேலும் ஒரு AI pair programmer இத்தகைய சிக்கல்களை மிகுந்த திறனுடன் கையாள்கிறது.

சலிப்பூட்டும் தணிக்கைகள் (audits) இப்போது தாங்கக்கூடியதாகிவிட்டன. லிங்க் கிராஃப்களைத் தேடுதல் (Crawling link graphs), redirect சங்கிலிகளைச் சரிபார்த்தல், நூற்றுக்கணக்கான பக்கங்களில் canonical tags-களைச் சரிபார்த்தல் — இத்தகைய வேலைகள் மனிதர்களின் கவனத்தைக் குலைத்துவிடும், ஆனால் ஒரு மொழி மாதிரி (language model) எந்தப் புகாரும் இன்றித் திரும்பத் திரும்பச் செய்யும். அது ஒரே மாதிரியான அமைப்பைத் தொடர்ந்து முன்னூறு முறை சரிபார்த்துவிட்டுத் தகவல் தெரிவிக்கும்.

உண்மையான ஆச்சரியம் அதன் ஒருமைப்பாடு (consistency) தான். ஒரு AI-யிடம் டஜன் கணக்கான landing pages-களை உருவாக்கச் சொல்லும்போது, நீங்கள் அதற்கு ஒரு பிடிப்பைத் தராவிட்டால், அதன் செயல்பாட்டில் மாறுபாடுகள் (drift) ஏற்படுவது தவிர்க்க முடியாதது. ஒரு குறிப்பிட்ட பிராண்ட் அமைப்பை (brand system) நிலைநிறுத்த நான் சிறிய மெமரி கோப்புகளைப் பயன்படுத்தினேன்: குரல் விதிகள் (voice rules), வண்ண டோக்கன் பெயர்கள் (color token names), கூறு கட்டுப்பாடுகள் (component restrictions) மற்றும் பக்க மாதிரிகள் (page archetypes). அந்த மாடல் ஒவ்வொரு பணிக்கும் தொடங்கும் முன் அந்தத் தடைகளை வாசித்துவிட்டு, இருபத்தொன்பது வெவ்வேறு மனநிலைகளில் செய்யப்பட்ட வேலையாகத் தெரியாமல், ஒரே ஒரு நபரின் கைவண்ணத்தில் உருவானது போன்ற வேலையைச் செய்தது.

உண்மையில் எதெல்லாம் உடைந்தது

அந்தத் தோல்விகள் கட்டமைப்பு ரீதியானவை (architectural). ஒரு செமிகோலன் (semicolon) விடுபட்டதால் எந்த ஒரு build-உம் தோல்வியடையவில்லை. மாறாக, அனைத்தும் சரியாக இருப்பதாக என்னை மெதுவாக ஏமாற்றியது இந்த அமைப்பு.

SEO cannibalization முதலில் பாதிப்பை ஏற்படுத்தியது. பழைய tool hub அதன் அசல் பாதையிலேயே (path) இருக்கும்போது, AI ஒரு புதிய URL-இன் கீழ் புதிய tool hub-ஐ உருவாக்கியது. ஒவ்வொரு தனிப்பட்ட பக்கமும் மேம்படுத்தப்பட்டிருந்தது (optimized). தலைப்புகள் (Titles) துல்லியமாக இருந்தன. Meta descriptions தனித்துவமாக இருந்தன. உள்ளடக்கம் பயனுள்ளதாக இருந்தது. ஆனால் அவை அனைத்தும் ஒரே தேடல் நோக்கத்தை (search intent) இலக்காகக் கொண்டிருந்தன. தேடுபொறிகள் (Search engines) ஒரே மாதிரியான சொற்களுக்கு இரண்டு அதிகாரப்பூர்வத் தளங்களைக் கண்டெடுத்து, இரண்டையுமே தரவரிசைப்படுத்தவில்லை. அந்தத் தளம் கோப்புகளின் தொகுப்பாக இல்லாமல், ஒரு போர்ட்ஃபோலியோவாகப் பார்க்கப்படாததால், அந்தத் துல்லியமான பக்கங்கள் ஒன்றையொன்று ரத்து செய்துவிட்டன.

அதனைத் தொடர்ந்து URL முரண்பாடுகள் (mismatches) ஏற்பட்டன. ஒரே மாதிரியான உள்ளடக்கத்திற்கு வெவ்வேறு களஞ்சியங்கள் (repositories) சற்று மாறுபட்ட கோப்பு கட்டமைப்புகளைப் (folder structures) பயன்படுத்தின. ஒரு repo கருவிகளை /tools/utility-name என்பதன் கீழ் வைத்திருந்தது; மற்றொன்று அவற்றை /utility-name எனச் சமதளமாக்கியது. CDN இவை இரண்டையும் கண்டறிந்து, அவற்றைச் சரிசெய்ய redirect சங்கிலிகளை உருவாக்கியது, இதனால் edge-இல் பிழைகள் (errors) ஏற்படத் தொடங்கின. பக்கங்கள் இறுதியில் ஏற்றப்பட்டன, ஆனால் ஒவ்வொரு redirect-உம் crawl budget மற்றும் பயனரின் பொறுமையைக் குறைத்தது. குறியீடு (code) சரியாக இருந்தது. ஆனால் அதன் கட்டமைப்பு (topology) குழப்பமாக இருந்தது.

பின்னர் sync பொறி (sync trap) வந்தது. நான் ஒரு mirror site-ஐ (staging அல்லது backup instance) புதுப்பித்தேன், ஆனால் அந்த மாற்றங்களை மூலக் களஞ்சியத்திற்கு (source repository) கொண்டு செல்ல மறந்துவிட்டேன். பின்னர் அந்தச் சூழல்களை (environments) sync செய்யுமாறு நான் AI-யிடம் கேட்டபோது, அது mirror site-ஐ உண்மையான தரவாகக் கருதியது. ஒரு சாதாரண sync கட்டளை, தயாரிப்புத் தரவுத்தளத்தையோ (production database) அல்லது கோப்புத் தொகுப்பையோ பழைய mirror தரவைக் கொண்டு அழித்திருக்கக்கூடும். நான் என்ன விவரித்தேனோ அதைத்தான் AI செய்தது, நான் என்ன செய்ய நினைத்தேனோ அதை அல்ல. எண்ணங்களுக்கு (intentions) வித்தியாசம் காண முடியாது; கோப்புகளுக்குத்தான் (files) வித்தியாசம் காண முடியும்.

தணிக்கைக் கருவிகளே பொய் சொன்னன. தணிக்கையை நான் தானியக்கமாக்கியதால் (automated), அதன் வெளியீடு சுத்தமாக இருக்கும் என்று நான் நினைத்தேன். ஆனால் அது இல்லை. AI எழுதிய audit scripts-இல் நுணுக்கமான பிழைகள் இருந்தன: off-by-one சோதனைகள், redirect status codes பற்றிய தவறான அனுமானங்கள், மற்றும் உண்மையான தவறான கட்டமைப்புகளை விட timing அல்லது headers மூலம் தூண்டப்பட்ட மாயப் பிழைகள் (phantom errors). அவை இல்லாத சிக்கல்களைப் புகாரளித்தன, இதனால் நான் தேவையற்ற விஷயங்களைத் தேடி அலைந்தேன். நேரடித் தளத்தை (live site) நான் கைமுறையாகச் சோதித்து, ஒரு browser அல்லது நேரடி curl மூலம் அந்தப் பிரச்சனையை உறுதிப்படுத்தும் வரை, static analysis-ஐ நம்புவதை நிறுத்திவிட்டேன்.

மறைக்கப்பட்ட செலவு

யாரும பேசாத ஒரு எண் இதோ: எனது token செலவில் 93 சதவீதம் ஏற்கனவே சேமிக்கப்பட்ட சூழலை (cached context) மீண்டும் வாசிப்பதிலேயே செலவானது.

ஒரு நீண்ட Claude Code அமர்வில், ஒவ்வொரு புதிய கோரிக்கையும் முந்தைய உரையாடல் வரலாறு, கோப்பு பஃபர்கள் மற்றும் செயல்பாட்டு நினைவகத்தை மீண்டும் பார்க்க மாடலைத் தூண்டுகிறது. ஒரு அமர்வின் முதல் பணி மலிவாக இருக்கலாம். பத்தாவது பணியின் போது, அடுத்த வாக்கியத்தைப் புரிந்துகொள்வதற்காகவே மாடல் அதற்கு முன் வந்த அனைத்தையும் செரித்துக்கொண்டிருக்கிறது. செலவு வளைவு வேகமாக மேல்நோக்கிச் செல்கிறது. நீண்ட அமர்வுகள் விலையுயர்ந்த மறுவாசிப்புப் பயிற்சிகளாக மாறுகின்றன, மேலும் தற்போதைய வேலையுடன் எந்தத் தொடர்பும் இல்லாத முந்தைய வேலைகளின் கழிவுகளால் context window நிரம்புகிறது.

இது ஒரு விசித்திரம் அல்ல. இது முறையற்ற session hygiene-க்கான நேரடி வரி.

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

சிக்கல்களை நான் அடையாளம் கண்டவுடன், தீர்வுகளும் எளிதாக இருந்தன.

ஒவ்வொரு அமர்வையும் ஒரு பணியாகக் கருதுங்கள். வேலை மாறும்போது, புதிதாகத் தொடங்குங்கள். context-ஐத் தொடர்ந்து வைத்திருப்பது ஒரு தூண்டுதலாக இருக்கலாம் — நீங்கள் அமைப்பிற்கான நேரத்தைச் சேமிப்பதாக உணரலாம் — ஆனால் உண்மையில் நீங்கள் கூட்டு வட்டியுடன் நினைவகத்தை வாடகைக்கு எடுக்கிறீர்கள்.

அறிவைச் சிறிய, பிரத்யேக நினைவகக் கோப்புகளில் வைத்திருங்கள். பிராண்ட் வழிகாட்டுதல்கள், component libraries அல்லது SEO விதிகளை உரையாடல் context-க்குள் மாடல் சுமந்து செல்ல அனுமதிக்காதீர்கள். அவற்றைச் சுருக்கமான கோப்புகளாகத் வட்டில் (disk) எழுதி, அவற்றை வெளிப்படையாகக் குறிப்பிடுங்கள். இது தகவல்களை விலையுயர்ந்த நிலையற்ற context-லிருந்து மலிவான நிலையான சேமிப்பிற்கு (persistent storage) மாற்றுகிறது.

வெவ்வேறு வேலைகளுக்கு இடையில், அனைத்தையும் சுத்தம் செய்யுங்கள்