ఎవరైనా ఒంటరిగా 29 రోజుల్లో 26 రిపోజిటరీల ద్వారా 335 లైవ్ పేజీలను షిప్ చేశామని చెబితే, వారు అంత వేగంగా ఎలా చేయగలిగారు అని అడగడం సహజం. కానీ అంతకంటే మెరుగైన ప్రశ్న ఏమిటంటే, వారు అలా చేసినప్పుడు ఏది విఫలమైంది అని.
ఆ సంఖ్యలు నిజం: 1,549 కమిట్లు, 26 రిపోజిటరీలు, 29 రోజులు, Claude Code ఉపయోగిస్తున్న ఒక డెవలపర్. కానీ వేగం (velocity) మాత్రమే మీకు చాలా తక్కువ నేర్పుతుంది. ముఖ్యమైనది వైఫల్యాల స్వభావం, ఎందుకంటే అవి స్టాక్ ట్రేస్లో (stack trace) దొరికే రకానికి చెందినవి కావు. అవి నిర్మాణాత్మక పగుళ్లు (structural fractures). మీరు ఎడిటర్ నుండి కొంచెం వెనక్కి తగ్గి, ప్రొడక్షన్లో పనిచేస్తున్న మొత్తం వ్యవస్థను గమనించినప్పుడు మాత్రమే అవి కనిపిస్తాయి.
ఏది పని చేసింది
ఆ వేగం భ్రమ కాదు. నిద్రపోని AIకి కొన్ని పనులను అప్పగించినప్పుడు, వాటికి పట్టే సమయం నిజంగానే గణనీయంగా తగ్గుతుంది.
టెక్స్ట్బుక్ అల్గారిథమ్లు వారాల తరబడి కాకుండా, కేవలం రోజుల్లోనే షిప్ చేయబడిన ఫీచర్లుగా మారాయి. 2048 సాల్వర్ మరియు minimax-ఆధారిత గేమ్లు వేగంగా సిద్ధమయ్యాయి, ఎందుకంటే వాటి ఇంప్లిమెంటేషన్ ప్యాటర్న్లు బాగా డాక్యుమెంట్ చేయబడ్డాయి. మోడల్ అకడమిక్ పేపర్లలో తికమక పడదు; అది సెర్చ్ ట్రీ, హ్యూరిస్టిక్ ఎవాల్యుయేషన్, మూవ్ స్కోరింగ్ను రాసి ముందుకు వెళ్తుంది. ఇవి పరిష్కరించబడిన సమస్యలు, మరియు ఒక AI pair programmer ఇటువంటి సమస్యలను అత్యంత సమర్థవంతంగా హ్యాండిల్ చేస్తుంది.
విసుగు పుట్టించే ఆడిట్లు కూడా భరించదగినవిగా మారాయి. లింక్ గ్రాఫ్లను క్రాల్ చేయడం, రీడైరెక్ట్ చైన్లను వెరిఫై చేయడం, వందలాది పేజీలలో కానోనికల్ ట్యాగ్లను తనిఖీ చేయడం — ఈ పనులు మనుషుల ఏకాగ్రతను దెబ్బతీస్తాయి, కానీ ఒక లాంగ్వేజ్ మోడల్ ఎటువంటి ఫిర్యాదు లేకుండా పదేపదే చేయగలదు. అది ఒకే ప్యాటర్న్ను మూడు వందల సార్లు తనిఖీ చేసి రిపోర్ట్ చేస్తుంది.
నిజమైన ఆశ్చర్యం ఏమిటంటే స్థిరత్వం (consistency). మీరు AIని డజన్ల కొద్దీ ల్యాండింగ్ పేజీలను రూపొందించమని అడిగినప్పుడు, మీరు దానికి ఒక పరిధిని (anchor) నిర్ణయించకపోతే మార్పులు (drift) రావడం అనివార్యం. నేను ఒకే బ్రాండ్ సిస్టమ్ను లాక్ చేయడానికి చిన్న మెమరీ ఫైల్లను ఉపయోగించాను: వాయిస్ రూల్స్, కలర్ టోకెన్ పేర్లు, కాంపోనెంట్ పరిమితులు మరియు పేజీ ఆర్కిటైప్స్. మోడల్ ప్రతి పని ప్రారంభంలో ఆ నిబంధనలను చదివి, ఇరవై తొమ్మిది వేర్వేరు మూడ్ల నుండి వచ్చినట్లు కాకుండా, ఒకే వ్యక్తి చేసినట్లుగా ఉండే పనిని అందించింది.
నిజంగా ఏది విఫలమైంది
వైఫల్యాలు ఆర్కిటెక్చరల్ (architectural) పరంగా ఉన్నాయి. సెమీకోలన్ (semicolon) లేకపోవడం వల్ల ఏ బిల్డ్ కూడా ఫెయిల్ కాలేదు. దానికి బదులుగా, అంతా బాగుందని నమ్మించేలా వ్యవస్థ నన్ను నెమ్మదిగా మోసం చేసింది.
మొదట SEO cannibalization సంభవించింది. పాత టూల్ హబ్ తన అసలు పాత్లోనే ఉన్నప్పుడు, AI ఒక కొత్త URL కింద కొత్త టూల్ హబ్ను నిర్మించింది. ప్రతి పేజీ ఆప్టిమైజ్ చేయబడింది. టైటిల్స్ ఖచ్చితంగా ఉన్నాయి. మెటా డిస్క్రిప్షన్లు ప్రత్యేకంగా ఉన్నాయి. కంటెంట్ ఉపయోగకరంగా ఉంది. కానీ అవన్నీ ఒకే సెర్చ్ ఇంటెంట్ను లక్ష్యంగా చేసుకున్నాయి. సెర్చ్ ఇంజన్లు ఒకే అంశంపై రెండు అధికారిక వెబ్సైట్లు ఉన్నట్లు గుర్తించి, రెండింటినీ ర్యాంక్ చేయలేదు. సైట్ను కేవలం ఫైళ్ల సేకరణగా కాకుండా ఒక పోర్ట్ఫోలియోగా ఎవరూ చూడకపోవడం వల్ల, ఆ పరిపూర్ణమైన పేజీలు ఒకదానికొకటి అడ్డుగా మారాయి.
ఆ తర్వాత URL mismatches వచ్చాయి. ఒకే రకమైన కంటెంట్ కోసం వేర్వేరు రిపోజిటరీలు స్వల్పంగా భిన్నమైన ఫోల్డర్ స్ట్రక్చర్లను అనుసరించాయి. ఒక రిపోజిటరీ /tools/utility-name కింద టూల్స్ను ఉంచితే; మరొకటి వాటిని /utility-name గా మార్చింది. CDN రెండింటినీ చూసి, వాటిని పరిష్కరించడానికి రీడైరెక్ట్ చైన్లను సృష్టించి, ఎడ్జ్ (edge) వద్ద ఎర్రర్లను చూపించడం ప్రారంభించింది. పేజీలు చివరకు లోడ్ అయ్యాయి కానీ, ప్రతి రీడైరెక్ట్ క్రాల్ బడ్జెట్ను మరియు వినియోగదారుని ఓపికను దెబ్బతీసింది. కోడ్ సరిగ్గానే ఉంది, కానీ టోపోలాజీ (topology) మాత్రం గందరగోళంగా ఉంది.
తరువాత సింక్ ట్రాప్ (sync trap) ఎదురైంది. నేను ఒక మిర్రర్ సైట్ను (స్టేజింగ్ లేదా బ్యాకప్ ఇన్స్టాన్స్) అప్డేట్ చేశాను, కానీ ఆ మార్పులను సోర్స్ రిపోజిటరీకి పంపడం మర్చిపోయాను. ఆ తర్వాత నేను AIని ఎన్విరాన్మెంట్లను సింక్ చేయమని అడిగినప్పుడు, అది మిర్రర్ను అసలైన డేటాగా (ground truth) పరిగణించింది. ఒక సాధారణ సింక్ కమాండ్ ప్రొడక్షన్ డేటాబేస్ లేదా ఫైల్లను పాత మిర్రర్ డేటాతో ఓవర్రైట్ చేసే ప్రమాదం ఉంది. నేను ఏమి చెప్పానో AI అది చేసింది, నేను ఏమి చేయాలనుకున్నానో అది చేయలేదు. ఉద్దేశాలు (intentions) డిఫ్ (diff) అవ్వవు; ఫైల్స్ మాత్రమే అవుతాయి.
ఆడిట్ టూల్స్ కూడా అబద్ధం చెప్పాయి. నేను ఆడిటింగ్ను ఆటోమేట్ చేయడం వల్ల, అవుట్పుట్ ఖచ్చితంగా ఉంటుందని అనుకున్నాను. కానీ అది కాదు. AI రాసిన ఆడిట్ స్క్రిప్ట్లలో సూక్ష్మమైన బగ్స్ ఉన్నాయి: off-by-one చెక్లు, రీడైరెక్ట్ స్టేటస్ కోడ్ల గురించి తప్పుడు అంచనాలు, మరియు నిజమైన మిస్ కాన్ఫిగరేషన్ల కంటే టైమింగ్ లేదా హెడర్ల వల్ల కలిగే ఫాంటమ్ ఎర్రర్లు. అవి లేని సమస్యలను రిపోర్ట్ చేశాయి, దీనివల్ల నేను అనవసరమైన వాటి కోసం వెతికినట్లు అయింది. లైవ్ సైట్ను మాన్యువల్గా పరీక్షించి, బ్రౌజర్లో లేదా డైరెక్ట్ curl ద్వారా లక్షణాలను నిర్ధారించుకునే వరకు స్టాటిక్ అనాలిసిస్ను (static analysis) నమ్మకూడదని నేను నేర్చుకున్నాను.
దాగి ఉన్న ఖర్చు
ఎవరూ మాట్లాడని ఒక సంఖ్య ఇక్కడ ఉంది: నా టోకెన్ ఖర్చులో 93 శాతం కేష్ చేయబడిన కాంటెక్స్ట్ను (cached context) మళ్ళీ చదవడానికే పోయింది.
ఒక సుదీర్ఘమైన Claude Code సెషన్లో, ప్రతి కొత్త రిక్వెస్ట్ మోడల్ను మునుపటి సంభాషణ చరిత్ర, ఫైల్ బఫర్లు మరియు వర్కింగ్ మెమరీని మళ్ళీ పరిశీలించమని బలవంతం చేస్తుంది. సెషన్లో మొదటి టాస్క్ తక్కువ ఖర్చుతో అయిపోవచ్చు. కానీ పదవ టాస్క్ వచ్చేసరికి, మోడల్ తదుపరి వాక్యాన్ని అర్థం చేసుకోవడానికి మాత్రమే అంతకుముందు జరిగినవన్నీ మళ్ళీ చదవాల్సి వస్తుంది. దీనివల్ల ఖర్చు రేటు వేగంగా పెరుగుతుంది. సుదీర్ఘ సెషన్లు ఖరీదైన రీడింగ్ వ్యాయామాలుగా మారిపోతాయి, మరియు ప్రస్తుత పనికి సంబంధం లేని పాత పనుల వ్యర్థాలతో కాంటెక్స్ట్ విండో నిండిపోతుంది.
ఇది ఏదో వింత కాదు. ఇది సరిగ్గా సెషన్ను నిర్వహించకపోవడం వల్ల కలిగే ప్రత్యక్ష నష్టం.
దీన్ని ఎలా సరిచేయాలి
సమస్యలను గుర్తించిన తర్వాత, వాటి పరిష్కారాలు చాలా సరళంగా ఉన్నాయి.
ఒక సెషన్ను ఒకే ఒక టాస్క్గా పరిగణించండి. పని మారినప్పుడు, కొత్తగా ప్రారంభించండి. కాంటెక్స్ట్ను అలాగే ఉంచాలనే కోరిక బలంగా ఉంటుంది — మీరు సెటప్ సమయాన్ని ఆదా చేస్తున్నట్లు అనిపించవచ్చు — కానీ నిజానికి మీరు చక్రవడ్డీతో మెమరీని అద్దెకు తీసుకుంటున్నట్లు అవుతుంది.
జ్ఞానాన్ని (knowledge) చిన్న, ప్రత్యేకమైన మెమరీ ఫైళ్లలో ఉంచండి. బ్రాండ్ గైడ్లైన్స్, కాంపోనెంట్ లైబ్రరీలు లేదా SEO నియమాలను సంభాషణ కాంటెక్స్ట్లో మోడల్ మోసుకెళ్లేలా చేయకండి. వాటిని క్లుప్తమైన ఫైళ్లుగా డిస్క్లో రాసి, వాటిని స్పష్టంగా రిఫరెన్స్ చేయండి. ఇది సమాచారాన్ని ఖరీదైన అస్థిరమైన కాంటెక్స్ట్ నుండి తక్కువ ఖర్చుతో కూడిన శాశ్వత స్టోరేజ్కు మారుస్తుంది.
వేర్వేరు పనుల మధ్య, పాతవన్నీ క్లియర్ చేయండి. సెషన్ను మూసివేయండి. కొత్త సెషన్ను ప్రారంభించండి. ఆ ముప్పై సెకన్ల సెటప్, తర్వాత వచ్చే ఖర్చులను మరియు హాలూసినేషన్స్ను (hallucinations) తగ్గిస్తుంది.
స్కేలింగ్ కోసం పాఠాలు
మీరు ఈ స్థాయిలో పని చేయాలనుకుంటే, ఫైల్ను కాకుండా సిస్టమ్ను సమీక్షా ప్రమాణంగా పరిగణించే గైడ్లైన్స్ మీకు అవసరం.
పబ్లిష్ చేసే ముందు బెంచ్మార్క్ చేయండి. ఒక పేజీ రెండర్ అవుతున్నంత మాత్రాన అది సరిగ్గా పనిచేస్తుందని అనుకోవద్దు. డిప్లాయ్ చేసిన URLలో లోడ్ టైమ్, మొబైల్ లేఅవుట్ మరియు కోర్ మెట్రిక్స్ను తనిఖీ చేయండి. లోకల్ డెవలప్మెంట్లో అందంగా కనిపించే కాంపోనెంట్, నిజమైన నెట్వర్క్ పరిస్థితుల్లో విఫలం కావచ్చు.
కాపీ చేసే ముందు డిఫ్ (Diff) చూడండి. ఎప్పుడూ బల్క్ సింక్ లేదా కాపీ ఆపరేషన్ను గుడ్డిగా చేయకండి. మార్పులను (delta) గమనించండి. డేటా ఏ దిశలో ప్రవహిస్తుందో అర్థం చేసుకోండి. మీరు లైవ్ కస్టమర్ డేటాను ఓవర్రైట్ చేస్తున్నారని AI మిమ్మల్ని హెచ్చరించదు.
ఆడిట్లను నమ్మే ముందు లైవ్ సైట్లను పరీక్షించండి. స్టాటిక్ అనాలిసిస్ అనేది ఒక ఊహ మాత్రమే. లైవ్ రిక్వెస్ట్ అనేది ఒక సాక్ష్యం. ఆడిట్ టూల్ ఒక బ్రోకెన్ లింక్ లేదా రీడైరెక్ట్ లూప్ను రిపోర్ట్ చేసినప్పుడు, దాన్ని నేరుగా రిక్వెస్ట్ చేసి ధృవీకరించుకోండి. టూల్స్లో కూడా బగ్స్ ఉంటాయి, ముఖ్యంగా ఊహించిన ప్యాటర్న్స్పై పనిచేసే AI ద్వారా వ్రాయబడిన టూల్స్లో ఇవి ఎక్కువగా ఉంటాయి.
స్కేల్ చేసే ముందు నిబంధనలను (conventions) రాసి ఉంచండి. AI ఒక కొత్త పేజీని సృష్టించకముందే, URL స్ట్రక్చర్, ఫోల్డర్ హైరార్కీ, కానికానికల్ ప్యాటర్న్స్ మరియు కంటెంట్ టాక్సోనమీ వంటివి అది చదవగలిగే చోట డాక్యుమెంట్ చేయబడాలి. మెమరీ ఫైళ్లు అనేది కేవలం ఐచ్ఛికం కాదు...