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

જ્યારે કોઈ તમને કહે કે તેઓએ એકલા કામ કરીને 29 દિવસમાં 26 રિપોઝીટરીઝમાં 335 લાઈવ પેજ શિપ કર્યા છે, ત્યારે આપણી સહજ વૃત્તિ એ પૂછવાની હોય છે કે તેઓ આટલી ઝડપથી કેવી રીતે આગળ વધ્યા. પણ તેના કરતા વધુ સારો પ્રશ્ન એ છે કે આટલી ઝડપમાં શું બગડ્યું.

આ આંકડા સાચા છે: 1,549 કમિટ્સ, 26 repos, 29 દિવસ, અને Claude Code નો ઉપયોગ કરતો એક ડેવલપર. પરંતુ માત્ર વેલોસિટી (ઝડપ) પોતે તમને બહુ ઓછું શીખવે છે. જે મહત્વનું છે તે છે નિષ્ફળતાઓની પ્રકૃતિ, કારણ કે તે એવા પ્રકારની નહોતી જે તમે stack trace માં પકડી શકો. તે માળખાગત તિરાડો (structural fractures) હતી. તમે તેને ત્યારે જ જોઈ શકો છો જ્યારે તમે એડિટરથી થોડા દૂર હટીને પ્રોડક્શનમાં કાર્યરત સમગ્ર સિસ્ટમને જુઓ.

શું સફળ રહ્યું

આ ઝડપ કોઈ ભ્રમ નહોતો. જ્યારે તમે અમુક કાર્યો એવા AI ને સોંપો છો જે ક્યારેય ઊંઘતું નથી, ત્યારે તે કાર્યોનો સમય ખરેખર ઘટી જાય છે.

ટેક્સ્ટબુક અલ્ગોરિધમ્સ અઠવાડિયાના બદલે દિવસોમાં શિપ થયેલા ફીચર્સમાં ફેરવાઈ ગયા. 2048 solver અને minimax-આધારિત ગેમ્સ ઝડપથી તૈયાર થઈ ગઈ કારણ કે તેના અમલીકરણના પેટર્ન (implementation patterns) સારી રીતે દસ્તાવેજીકૃત છે. મોડેલ શૈક્ષણિક પેપર્સમાં ખોવાઈ જતું નથી; તે search tree, heuristic evaluation, move scoring લખે છે અને આગળ વધે છે. આ ઉકેલાઈ ગયેલી સમસ્યાઓ છે, અને એક AI pair programmer આ સમસ્યાઓને અત્યંત કાર્યક્ષમતા સાથે સંભાળી લે છે.

કંટાળાજનક ઓડિટ હવે સહન કરી શકાય તેવા બની ગયા. લિંક ગ્રાફ્સનું ક્રોલિંગ કરવું, રીડાયરેક્ટ ચેઈન્સની ચકાસણી કરવી, સેંકડો પેજ પર કેનોનિકલ ટેગ્સ તપાસવા — આ કામ માનવીય એકાગ્રતાને તોડી નાખે છે, પરંતુ એક લેંગ્વેજ મોડેલ કોઈપણ ફરિયાદ વગર વારંવાર તે કરી શકે છે. તે એક જ પેટર્નને ત્રણસો વખત તપાસે છે અને રિપોર્ટ આપે છે.

સાચો આશ્ચર્ય તેની સુસંગતતા (consistency) હતી. જ્યારે તમે AI ને ડઝનબંધ લેન્ડિંગ પેજ બનાવવા માટે કહો છો, ત્યારે જ્યાં સુધી તમે તેને મર્યાદિત ન કરો ત્યાં સુધી તેમાં વિચલન (drift) અનિવાર્ય છે. મેં એક સિંગલ બ્રાન્ડ સિસ્ટમને લોક કરવા માટે નાની મેમરી ફાઇલોનો ઉપયોગ કર્યો: વોઇસ રૂલ્સ, કલર ટોકન નામો, કમ્પોનન્ટ પ્રતિબંધો અને પેજ આર્કિટાઇપ્સ. મોડેલે દરેક સંબંધિત કાર્યની શરૂઆતમાં તે નિયમો વાંચ્યા અને એવું કામ કર્યું જેવું લાગે કે તે ૨૯ અલગ-અલગ મૂડના બદલે એક જ વ્યક્તિ દ્વારા કરવામાં આવ્યું હોય.

ખરેખર શું બગડ્યું

નિષ્ફળતાઓ આર્કિટેક્ચરલ હતી. કોઈ પણ બિલ્ડ સેમીકોલન (semicolon) ખૂટવાને કારણે ફેલ નહોતું થયું. તેના બદલે, સિસ્ટમે મને ધીમે ધીમે એવું માનવા માટે છેતરી દીધો કે બધું બરાબર છે.

સૌ પ્રથમ SEO cannibalization ની સમસ્યા આવી. જ્યારે જૂનું ટૂલ હબ તેના મૂળ પાથ પર હજુ પણ હતું, ત્યારે AI એ નવા URL હેઠળ નવું ટૂલ હબ બનાવી દીધું. દરેક વ્યક્તિગત પેજ ઓપ્ટિમાઇઝ્ડ હતું. ટાઇટલ્સ સચોટ હતા. મેટા ડિસ્ક્રિપ્શન યુનિક હતા. કન્ટેન્ટ ઉપયોગી હતું. પરંતુ તે બધા એક જ સર્ચ ઇન્ટેન્ટ (search intent) ને ટાર્ગેટ કરી રહ્યા હતા. સર્ચ એન્જિನ್‌ઓએ સમાન શબ્દો પર બે સત્તાધિકારીઓ જોયા અને બંનેમાંથી કોઈને પણ રેન્ક આપ્યું નહીં. પરફેક્ટ પેજ એકબીજાને નબળા પાડતા હતા કારણ કે કોઈ પણ સાઇટને ફાઇલોના સંગ્રહ તરીકે નહીં પણ એક પોર્ટફોલિયો તરીકે જોઈ રહ્યું નહોતું.

ત્યારબાદ URL mismatches ની સમસ્યા આવી. સમાન લોજિકલ કન્ટેન્ટ માટે અલગ-અલગ રિપોઝીટરીઝે થોડી અલગ ફોલ્ડર સ્ટ્રક્ચર અપનાવી લીધી. એક રિપોમાં ટૂલ્સ /tools/utility-name હેઠળ હતા; બીજામાં તેને /utility-name તરીકે ફ્લેટન કરવામાં આવ્યા હતા. CDN એ બંનેને જોયા, તેને ઉકેલવા માટે રીડાયરેક્ટ ચેઈન બનાવી અને એજ (edge) પર એરર આપવાનું શરૂ કર્યું. પેજ અંતે લોડ તો થયા, પરંતુ દરેક રીડાયરેક્ટ ક્રોલ બજેટ અને વપરાશકર્તાની ધીરજ બગાડતું હતું. કોડ સાચો હતો, પણ ટોપોલોજી (topology) અસ્તવ્યસ્ત હતી.

પછી સિંક ટ્રેપ (sync trap) આવી. મેં મિરર સાઇટ — સ્ટેજિંગ અથવા બેકઅપ ઇન્સ્ટન્સ — અપડેટ કર્યું, પરંતુ તે ફેરફારોને સોર્સ રિપોઝીટરીમાં પાછા મોકલવાનું ભૂલી ગયો. જ્યારે મેં પછી AI ને એન્વાયરમેન્ટ્સ સિંક કરવા કહ્યું, ત્યારે તેણે મિરરને જ સાચું (ground truth) માન્યું. એક સાધારણ સિંક કમાન્ડ પ્રોડક્શન ડેટાબેઝ અથવા ફાઇલ સેટને જૂના મિરર ડેટા સાથે ઓવરરાઈટ કરી શકત. AI એ તે જ કર્યું જે મેં વર્ણવ્યું હતું, જે હું કરવા માંગતો હતો તે નહીં. ઇન્ટેન્શન (intentions) નો 'diff' નથી થતો; ફાઇલ્સનો થાય છે.

ઓડિટ ટૂલ્સ પોતે જ જૂઠું બોલતા હતા. કારણ કે મેં ઓડિટિંગ ઓટોમેટ કર્યું હતું, તેથી મેં ધાર્યું હતું કે આઉટપુટ સાફ હશે. પણ તે નહોતું. AI દ્વારા લખાયેલા ઓડિટ સ્ક્રિપ્ટ્સમાં સૂક્ષ્મ બગ્સ હતા: off-by-one ચેક્સ, રીડાયરેક્ટ સ્ટેટસ કોડ્સ વિશે ખોટી ધારણાઓ, અને વાસ્તવિક મિસકોન્ફિગરેશનને બદલે ટાઇમિંગ અથવા હેડર્સ દ્વારા ટ્રિગર થયેલી ફેન્ટમ એરર્સ. તેઓએ એવી સમસ્યાઓ રિપોર્ટ કરી જે અસ્તિત્વમાં જ નહોતી, જેના કારણે હું નકામી વસ્તુઓ પાછળ દોડવા લાગ્યો. મેં શીખ્યું કે જ્યાં સુધી હું મેન્યુઅલી લાઈવ સાઇટ તપાસી ન લઉં અને બ્રાઉઝર અથવા ડાયરેક્ટ curl માં લક્ષણોની પુષ્ટિ ન કરી લઉં, ત્યાં સુધી સ્ટેટિક એનાલિસિસ પર વિશ્વાસ કરવાનું બંધ કરવું જોઈએ.

છુપો ખર્ચ

અહીં એક એવો આંકડો છે જેના વિશે કોઈ વાત કરતું નથી: મારા ટોકન ખર્ચના 93 ટકા કેશ્ડ કોન્ટેક્સ્ટ (cached context) ને ફરીથી વાંચવામાં જ ગયા.

Claude Code ના લાંબા સેશનમાં, દરેક નવી વિનંતી મોડેલને અગાઉની વાતચીતનો ઇતિહાસ, ફાઇલ બફર્સ અને વર્કિંગ મેમરીને ફરીથી તપાસવા માટે મજબૂર કરે છે. સેશનમાં પ્રથમ કાર્ય સસ્તું હોઈ શકે છે. દસમા કાર્ય સુધીમાં, મોડેલ આગામી વાક્ય સમજવા માટે જ અગાઉની બધી બાબતોને પચાવવા લાગે છે. ખર્ચનો વળાંક ઝડપથી ઉપર જાય છે. લાંબા સેશનો મોંઘા પુનઃવાંચન અભ્યાસમાં ફેરવાઈ જાય છે, અને કોન્ટેક્સ્ટ વિન્ડો અગાઉના કાર્યોના કચરાથી ભરાઈ જાય છે જેનો વર્તમાન કાર્ય સાથે કોઈ સંબંધ નથી.

આ કોઈ અકસ્માત નથી. તે નબળા સેશન વ્યવસ્થાપન પરનો સીધો ટેક્સ છે.

તેને કેવી રીતે સુધારવું

એકવાર મેં સમસ્યાઓને ઓળખી લીધી, પછી તેના ઉકેલો સરળ હતા.

એક સેશનને એક કાર્ય તરીકે ગણો. જ્યારે કામ બદલાય, ત્યારે નવેસરથી શરૂઆત કરો. કોન્ટેક્સ્ટને 'વોર્મ' રાખવાની લાલચ મજબૂત હોય છે — તમને લાગે છે કે તમે સેટઅપનો સમય બચાવી રહ્યા છો — પરંતુ વાસ્તવમાં તમે ચક્રવૃદ્ધિ વ્યાજ સાથે મેમરી ભાડે લઈ રહ્યા છો.

જ્ઞાનને નાની, સમર્પિત મેમરી ફાઇલોમાં રાખો. મોડેલને બ્રાન્ડ માર્ગદર્શિકા, કમ્પોનન્ટ લાઇબ્રેરીઓ અથવા SEO નિયમો વાતચીતના કોન્ટેક્સ્ટમાં રાખવા ન દો. તેમને સંક્ષિપ્ત ફાઇલોમાં ડિસ્ક પર લખો અને તેનો સ્પષ્ટ રીતે સંદર્ભ આપો. આ માહિતીને મોંઘા વોલેટાઇલ કોન્ટેક્સ્ટમાંથી સસ્તા પર્સિસ્ટન્ટ સ્ટોરેજમાં ખસેડે છે.

વિવિધ કાર્યો વચ્ચે, બધું સાફ કરી દો. સેશન બંધ કરો. નવું સેશન ખોલો. ૩૦ સેકન્ડનું સેટઅપ પછીના ડોલર અને હેલ્યુસિનેશન બચાવે છે.

સ્કેલિંગ માટેના પાઠ

જો તમે આટલા મોટા પાયે કામ કરવા માંગતા હોવ, તો તમારે એવા ગાર્ડરેલ્સની જરૂર છે જે ફાઇલને નહીં, પણ સિસ્ટમને રિવ્યુના એકમ તરીકે ગણે.

પબ્લિશ કરતા પહેલા બેન્ચમાર્ક કરો. માત્ર પેજ રેન્ડર થાય છે એટલે તે કામ કરે છે તેમ માની ન લો. ડિપ્લોય કરેલા URL પર લોડ ટાઈમ, મોબાઈલ લેઆઉટ અને મુખ્ય મેટ્રિક્સ તપાસો. લોકલ ડેવલપમેન્ટમાં સુંદર દેખાતું કમ્પોનન્ટ વાસ્તવિક નેટવર્ક પરિસ્થિતિઓમાં નિષ્ફળ જઈ શકે છે.

કોપી કરતા પહેલા ડિફ (Diff) તપાસો. ક્યારેય પણ બલ્ક સિંક અથવા કોપી ઓપરેશન અંધાધૂંધ ન કરો. ડેલ્ટા જુઓ. ડેટા કઈ દિશામાં વહી રહ્યો છે તે સમજો. તમે લાઈવ ગ્રાહક ડેટાને ઓવરરાઈટ કરવા જઈ રહ્યા છો તે માટે AI તમને ચેતવણી આપશે નહીં.

ઓડિટ પર વિશ્વાસ કરતા પહેલા લાઈવ સાઇટ્સ તપાસો. સ્ટેટિક એનાલિસિસ એ માત્ર એક ધારણા છે. લાઈવ રિક્વેસ્ટ એ પુરાવો છે. જ્યારે ઓડિટ ટૂલ બ્રોકન લિંક અથવા રિડાયરેક્ટ લૂપ રિપોર્ટ કરે, ત્યારે તેને ડાયરેક્ટ રિક્વેસ્ટ સાથે વેરિફાય કરો. ટૂલ્સમાં પણ બગ્સ હોય છે, ખાસ કરીને એવા ટૂલ્સ જે અનુમાનિત પેટર્ન પર કામ કરતા AI દ્વારા લખવામાં આવ્યા હોય.

સ્કેલ કરતા પહેલા નિયમો લખી લો. URL સ્ટ્રક્ચર, ફોલ્ડર હાયરાર્કી, કેનોનિકલ પેટર્ન અને કન્ટેન્ટ ટેક્સનોમીને એવી જગ્યાએ ડોક્યુમેન્ટ કરવાની જરૂર છે જે AI એક નવું પેજ બનાવતા પહેલા વાંચી શકે. મેમરી ફાઇલો એ વિકલ્પ નથી...