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 लाइव पेज शिप किए हैं, तो स्वाभाविक रूप से यह पूछने की इच्छा होती है कि वे इतनी तेज़ी से कैसे आगे बढ़े। बेहतर सवाल यह है कि इतनी तेज़ी के दौरान क्या टूटा।

आंकड़े वास्तविक हैं: 1,549 commits, 26 repos, 29 दिन, और Claude Code का उपयोग करने वाला एक डेवलपर। लेकिन गति (velocity) अपने आप में आपको बहुत कम सिखाती है। जो मायने रखता है वह है विफलताओं का स्वरूप, क्योंकि वे उस प्रकार की नहीं थीं जिन्हें आप stack trace में पकड़ सकें। वे संरचनात्मक दरारें (structural fractures) थीं। आप उन्हें तभी देख पाते हैं जब आप एडिटर से पीछे हटते हैं और प्रोडक्शन में सांस लेते पूरे सिस्टम को देखते हैं।

क्या काम आया

वह गति कोई भ्रम नहीं थी। कुछ कार्य वास्तव में अपनी अवधि में सिमट जाते हैं जब आप उन्हें ऐसे AI को सौंप देते हैं जो सोता नहीं है।

Textbook algorithms हफ्तों के बजाय दिनों में शिप किए गए फीचर्स में बदल गए। एक 2048 solver और minimax-आधारित गेम तेज़ी से तैयार हो गए क्योंकि उनके implementation patterns अच्छी तरह से प्रलेखित (documented) हैं। मॉडल अकादमिक शोध पत्रों में नहीं खोता; यह search tree, heuristic evaluation, move scoring लिखता है और आगे बढ़ जाता है। ये हल की जा चुकी समस्याएं हैं, और एक AI pair programmer इन समस्याओं को अत्यधिक दक्षता के साथ संभालता है।

उबाऊ ऑडिट अब सहन करने योग्य हो गए। Link graphs को क्रॉल करना, redirect chains को सत्यापित करना, सैकड़ों पेजों पर canonical tags की जांच करना — यह काम इंसानी एकाग्रता को खत्म कर देता है, लेकिन एक language model बिना किसी शिकायत के बार-बार iterate करेगा। यह एक ही पैटर्न को तीन सौ बार जांचता है और रिपोर्ट देता है।

असली आश्चर्य निरंतरता (consistency) थी। जब आप AI को दर्जनों landing pages बनाने के लिए कहते हैं, तो जब तक आप उसे anchor न करें, drift अपरिहार्य है। मैंने एक एकल ब्रांड सिस्टम को लॉक करने के लिए छोटी memory files का उपयोग किया: voice rules, color token names, component restrictions, और page archetypes। मॉडल ने प्रत्येक प्रासंगिक कार्य की शुरुआत में उन बाधाओं को पढ़ा और ऐसा काम किया जो ऐसा लगा जैसे वह उन्नीस अलग-अलग मूड के बजाय एक ही हाथ से आया हो।

वास्तव में क्या टूटा

विफलताएं architectural थीं। कोई भी build किसी छूटे हुए semicolon के कारण विफल नहीं हुआ। इसके बजाय, सिस्टम ने धीरे-धीरे मुझे यह सोचने के लिए धोखा दिया कि सब कुछ ठीक है।

SEO cannibalization सबसे पहले हुआ। AI ने एक नए URL के तहत एक नया tool hub बनाया, जबकि एक पुराना tool hub अभी भी अपने मूल path पर मौजूद था। प्रत्येक व्यक्तिगत पेज को optimize किया गया था। Titles सटीक थे। Meta descriptions unique थे। Content उपयोगी था। लेकिन वे सभी एक ही search intent को लक्षित कर रहे थे। Search engines ने समान शब्दों पर दो authorities को देखा और किसी को भी rank नहीं किया। Perfect pages ने एक-दूसरे के प्रभाव को खत्म कर दिया क्योंकि कोई भी साइट को फाइलों के संग्रह के बजाय एक portfolio के रूप में नहीं देख रहा था।

इसके बाद URL mismatches की समस्या आई। अलग-अलग repositories ने एक ही logical content के लिए थोड़े अलग folder structures अपना लिए। एक repo ने tools को /tools/utility-name के तहत रखा; दूसरी ने उन्हें /utility-name पर flatten कर दिया। CDN ने दोनों को देखा, उन्हें हल करने के लिए redirect chains बनाई, और edge पर errors देने लगा। पेज आखिरकार load तो हो गए, लेकिन हर redirect ने crawl budget और उपयोगकर्ता के धैर्य को खत्म कर दिया। Code सही था। Topology अस्त-व्यस्त थी।

फिर sync trap आया। मैंने एक mirror site — एक staging या backup instance — को update किया, लेकिन उन बदलावों को वापस source repository में propagate करना भूल गया। जब मैंने बाद में AI से environments को sync करने के लिए कहा, तो उसने mirror को ही ground truth मान लिया। एक साधारण sync command production database या file set को पुराने mirror data के साथ overwrite कर सकती थी। AI ने वह किया जो मैंने बताया था, वह नहीं जो मेरा इरादा था। Intentions diff नहीं होते; files होती हैं।

Audit tools ने खुद झूठ बोला। क्योंकि मैंने auditing को automate कर दिया था, मैंने मान लिया कि output साफ है। ऐसा नहीं था। AI द्वारा लिखे गए audit scripts में सूक्ष्म bugs थे: off-by-one checks, redirect status codes के बारे में गलत धारणाएं, और वास्तविक misconfigurations के बजाय timing या headers के कारण होने वाली phantom errors। उन्होंने ऐसी समस्याओं की रिपोर्ट की जो अस्तित्व में ही नहीं थीं, जिससे मैं भ्रम के पीछे भागने लगा। मैंने तब तक static analysis पर भरोसा करना बंद करना सीख लिया जब तक कि मैंने मैन्युअल रूप से live site की जांच नहीं की और browser या सीधे curl में लक्षण की पुष्टि नहीं कर ली।

छिपी हुई लागत

यहाँ एक ऐसा आंकड़ा है जिसके बारे में कोई बात नहीं करता: मेरे token खर्च का 93 percent cached context को दोबारा पढ़ने में चला गया।

Claude Code के एक लंबे सेशन में, हर नया अनुरोध मॉडल को पिछली बातचीत के इतिहास, फ़ाइल बफ़र्स और वर्किंग मेमोरी को फिर से देखने के लिए मजबूर करता है। सेशन का पहला काम सस्ता हो सकता है। दसवें काम तक पहुँचते-पहुँचते, मॉडल अगले वाक्य को समझने के लिए ही उससे पहले की हर चीज़ को पचा रहा होता है। लागत का वक्र (cost curve) तेज़ी से ऊपर की ओर मुड़ता है। लंबे सेशन महंगे पुनरावलोकन के अभ्यासों में बदल जाते हैं, और कॉन्टेक्स्ट विंडो पिछले कामों के मलबे से भर जाती है जिसका वर्तमान काम से कोई लेना-देना नहीं होता।

यह कोई अजीब बात नहीं है। यह खराब सेशन हाइजीन पर लगने वाला सीधा टैक्स है।

इसे कैसे ठीक करें

एक बार जब मैंने समस्याओं को पहचान लिया, तो समाधान सरल थे।

एक सेशन को एक कार्य (task) के रूप में मानें। जब काम बदल जाए, तो नए सिरे से शुरुआत करें। कॉन्टेक्स्ट को 'वार्म' रखने का प्रलोभन बहुत अधिक होता है — आपको लगता है कि आप सेटअप का समय बचा रहे हैं — लेकिन वास्तव में आप चक्रवृद्धि ब्याज पर मेमोरी किराए पर ले रहे होते हैं।

ज्ञान को छोटी, समर्पित मेमोरी फ़ाइलों में रखें। मॉडल को ब्रांड गाइडलाइन्स, कंपोनेंट लाइब्रेरीज़, या SEO नियमों को बातचीत के कॉन्टेक्स्ट के अंदर ले जाने न दें। उन्हें संक्षिप्त फ़ाइलों में डिस्क पर लिखें और स्पष्ट रूप से उनका संदर्भ दें। यह जानकारी को महंगे अस्थिर कॉन्टेक्स्ट (volatile context) से हटाकर सस्ते स्थायी स्टोरेज (persistent storage) में ले जाता है।

अलग-अलग कामों के बीच, सब कुछ साफ़ कर दें। सेशन बंद करें। एक नया सेशन खोलें। सेटअप में लगने वाले तीस सेकंड बाद होने वाले खर्चों और हैलुसिनेशन को बचाते हैं।

स्केलिंग के लिए सबक

यदि आप इस स्तर पर काम करने जा रहे हैं, तो आपको ऐसे गार्डरेल्स की आवश्यकता है जो फ़ाइल के बजाय सिस्टम को समीक्षा की इकाई मानें।

पब्लिश करने से पहले बेंचमार्क करें। यह न मान लें कि कोई पेज काम कर रहा है क्योंकि वह रेंडर हो रहा है। तैनात (deployed) URL पर लोड टाइम, मोबाइल लेआउट और मुख्य मेट्रिक्स की जाँच करें। लोकल डेवलपमेंट में एक सुंदर कंपोनेंट वास्तविक नेटवर्क स्थितियों में विफल हो सकता है।

कॉपी करने से पहले अंतर (diff) देखें। कभी भी अंधाधुंध बल्क सिंक या कॉपी ऑपरेशन न चलाएं। डेल्टा (delta) को देखें। समझें कि डेटा किस दिशा में बह रहा है। AI आपको चेतावनी नहीं देगा कि आप लाइव कस्टमर डेटा को ओवरराइट करने वाले हैं।

ऑडिट पर भरोसा करने से पहले लाइव साइट्स की जांच करें। स्टैटिक एनालिसिस एक परिकल्पना है। एक लाइव रिक्वेस्ट प्रमाण है। जब कोई ऑडिट टूल टूटे हुए लिंक या रीडायरेक्ट लूप की रिपोर्ट करता है, तो उसे सीधे अनुरोध के साथ सत्यापित करें। टूल्स में भी बग होते हैं, विशेष रूप से वे टूल्स जो अनुमानित पैटर्न पर काम करने वाले AI द्वारा लिखे गए हों।

स्केल करने से पहले नियमों (conventions) को लिख लें। URL संरचना, फ़ोल्डर पदानुक्रम, कैनोनिकल पैटर्न और कंटेंट टैक्सोनॉमी को ऐसी जगह दस्तावेज़ित करने की आवश्यकता है जिसे AI एक नया पेज बनाने से पहले पढ़ सके। मेमोरी फ़ाइलें वैकल्पिक नहीं हैं...