ਜਦੋਂ ਕੋਈ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਉਸਨੇ ਇਕੱਲੇ ਕੰਮ ਕਰਦੇ ਹੋਏ 29 ਦਿਨਾਂ ਵਿੱਚ 26 repositories ਵਿੱਚ 335 live pages ਸ਼ਿਪ ਕੀਤੇ ਹਨ, ਤਾਂ ਮਨ ਵਿੱਚ ਇਹ ਸਵਾਲ ਆਉਂਦਾ ਹੈ ਕਿ ਉਹ ਇੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕਿਵੇਂ ਵਧ ਸਕਿਆ। ਪਰ ਬਿਹਤਰ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਵੇਲੇ ਕੀ ਕੁਝ ਟੁੱਟ ਗਿਆ।

ਅੰਕੜੇ ਅਸਲੀ ਹਨ: 1,549 commits, 26 repos, 29 ਦਿਨ, ਅਤੇ Claude Code ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲਾ ਇੱਕ developer। ਪਰ ਸਿਰਫ਼ ਰਫ਼ਤਾਰ (velocity) ਤੁਹਾਨੂੰ ਬਹੁਤ ਕੁਝ ਨਹੀਂ ਸਿਖਾਉਂਦੀ। ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਉਹ ਹੈ ਅਸਫਲਤਾਵਾਂ ਦਾ ਸੁਭਾਅ, ਕਿਉਂਕਿ ਉਹ ਉਸ ਕਿਸਮ ਦੀਆਂ ਨਹੀਂ ਸਨ ਜੋ ਤੁਹਾਨੂੰ stack trace ਵਿੱਚ ਮਿਲ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ ਬਣੂਟੀ (structural) ਤਰੇੜਾਂ ਸਨ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਉਦੋਂ ਹੀ ਦੇਖ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ editor ਤੋਂ ਪਿੱਛੇ ਹਟ ਕੇ production ਵਿੱਚ ਚੱਲ ਰਹੇ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਦੇਖਦੇ ਹੋ।

ਕੀ ਕੰਮ ਕਰਿਆ

ਉਹ ਰਫ਼ਤਾਰ ਕੋਈ ਭਰਮ ਨਹੀਂ ਸੀ। ਕੁਝ ਕੰਮਾਂ ਦਾ ਸਮਾਂ ਸੱਚਮੁੱਚ ਬਹੁਤ ਘੱਟ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਜਿਹੇ AI ਨੂੰ ਸੌਂਪ ਦਿੰਦੇ ਹੋ ਜੋ ਕਦੇ ਸੌਂਦਾ ਨਹੀਂ।

Textbook algorithms ਹਫ਼ਤਿਆਂ ਦੀ ਬਜਾਏ ਦਿਨਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕੀਤੇ ਗਏ features ਵਿੱਚ ਬਦਲ ਗਏ। ਇੱਕ 2048 solver ਅਤੇ minimax-ਅਧਾਰਤ ਗੇਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਤਿਆਰ ਹੋ ਗਈਆਂ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੇ implementation patterns ਚੰਗੀ ਤਰ੍ਹਾਂ ਦਸਤਾਵੇਜ਼ੀ (documented) ਹਨ। ਮਾਡਲ ਅਕਾਦਮਿਕ ਪੇਪਰਾਂ ਵਿੱਚ ਨਹੀਂ ਗੁੰਮ ਹੁੰਦਾ; ਇਹ search tree, heuristic evaluation, move scoring ਲਿਖਦਾ ਹੈ ਅਤੇ ਅੱਗੇ ਵਧ ਜਾਂਦਾ ਹੈ। ਇਹ ਹੱਲ ਕੀਤੇ ਹੋਏ ਮਸਲੇ ਹਨ, ਅਤੇ ਇੱਕ AI pair programmer ਇਹਨਾਂ ਨੂੰ ਬਹੁਤ ਹੀ ਕੁਸ਼ਲਤਾ ਨਾਲ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ।

ਉਦਾਸੀਨ (Tedious) audits ਸਹਿਣਯੋਗ ਬਣ ਗਏ। Link graphs ਨੂੰ crawl ਕਰਨਾ, redirect chains ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ, ਸੈਂਕੜੇ ਪੇਜਾਂ ਵਿੱਚ canonical tags ਦੀ ਜਾਂਚ ਕਰਨਾ — ਇਹ ਕੰਮ ਮਨੁੱਖੀ ਧਿਆਨ (attention span) ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਪਰ ਇੱਕ language model ਬਿਨਾਂ ਕਿਸੇ ਸ਼ਿਕਾਇਤ ਦੇ ਵਾਰ-ਵਾਰ ਇਹ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕੋ ਪੈਟਰਨ ਨੂੰ ਤਿੰਨ ਸੌ ਵਾਰ ਚੈੱਕ ਕਰਦਾ ਹੈ ਅਤੇ ਰਿਪੋਰਟ ਦਿੰਦਾ ਹੈ।

ਅਸਲੀ ਹੈਰਾਨੀ ਇਕਸਾਰਤਾ (consistency) ਸੀ। ਜਦੋਂ ਤੁਸੀਂ AI ਨੂੰ ਦਰਜਨਾਂ landing pages ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਢਾਂਚੇ ਵਿੱਚ ਨਹੀਂ ਬੰਨ੍ਹਦੇ, ਫ਼ਰਕ ਆਉਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਮੈਂ ਇੱਕ ਸਿੰਗਲ brand system ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਲਈ ਛੋਟੀਆਂ memory files ਦੀ ਵਰਤੋਂ ਕੀਤੀ: voice rules, color token names, component restrictions, ਅਤੇ page archetypes। ਮਾਡਲ ਨੇ ਹਰੇਕ ਸਬੰਧਤ ਕੰਮ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਉਹਨਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ (constraints) ਨੂੰ ਪੜ੍ਹਿਆ ਅਤੇ ਅਜਿਹਾ ਕੰਮ ਕੀਤਾ ਜੋ ਲੱਗਦਾ ਸੀ ਕਿ 29 ਵੱਖ-ਵੱਖ ਮੂਡਾਂ ਦੀ ਬਜਾਏ ਇੱਕ ਹੀ ਹੱਥ ਤੋਂ ਆਇਆ ਹੈ।

ਅਸਲ ਵਿੱਚ ਕੀ ਟੁੱਟਿਆ

ਅਸਫਲਤਾਵਾਂ ਆਰਕੀਟੈਕਚਰਲ (architectural) ਸਨ। ਕੋਈ ਵੀ build ਕਿਸੇ missing semicolon ਕਰਕੇ ਫੇਲ ਨਹੀਂ ਹੋਇਆ। ਇਸ ਦੀ ਬਜਾਏ, ਸਿਸਟਮ ਨੇ ਹੌਲੀ-ਹੌਲੀ ਮੈਨੂੰ ਇਹ ਭਰਮ ਦਿੱਤਾ ਕਿ ਸਭ ਕੁਝ ਠੀਕ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ SEO cannibalization ਦੀ ਸਮੱਸਿਆ ਆਈ। AI ਨੇ ਇੱਕ ਨਵੇਂ URL ਦੇ ਹੇਠਾਂ ਇੱਕ ਨਵਾਂ tool hub ਬਣਾ ਦਿੱਤਾ ਜਦੋਂ ਕਿ ਪੁਰਾਣਾ tool hub ਅਜੇ ਵੀ ਆਪਣੇ ਅਸਲੀ ਪਾਥ (path) 'ਤੇ ਸੀ। ਹਰੇਕ ਵੱਖਰੇ ਪੇਜ ਨੂੰ optimize ਕੀਤਾ ਗਿਆ ਸੀ। Titles ਸਹੀ ਸਨ। Meta descriptions ਵਿਲੱਖਣ ਸਨ। Content ਲਾਭਦਾਇਕ ਸੀ। ਪਰ ਉਹ ਸਾਰੇ ਇੱਕੋ ਜਿਹੇ search intent ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾ ਰਹੇ ਸਨ। Search engines ਨੇ ਇੱਕੋ ਜਿਹੇ ਸ਼ਬਦਾਂ 'ਤੇ ਦੋ ਅਥਾਰਟੀ ਦੇਖੀਆਂ ਅਤੇ ਕਿਸੇ ਨੂੰ ਵੀ ਰੈਂਕ ਨਹੀਂ ਕੀਤਾ। ਸੰਪੂਰਨ ਪੇਜਾਂ ਨੇ ਇੱਕ ਦੂਜੇ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਸਾਈਟ ਨੂੰ ਫਾਈਲਾਂ ਦੇ ਸੰਗ੍ਰਹਿ ਦੀ ਬਜਾਏ ਇੱਕ ਪੋਰਟਫੋਲੀਓ ਵਜੋਂ ਨਹੀਂ ਦੇਖ ਰਿਹਾ ਸੀ।

ਇਸ ਤੋਂ ਬਾਅਦ URL mismatches ਦੀ ਸਮੱਸਿਆ ਆਈ। ਵੱਖ-ਵੱਖ repositories ਨੇ ਇੱਕੋ ਜਿਹੇ logical content ਲਈ ਥੋੜ੍ਹੇ ਵੱਖਰੇ folder structures ਅਪਣਾ ਲਏ। ਇੱਕ repo ਵਿੱਚ tools ਨੂੰ /tools/utility-name ਦੇ ਹੇਠਾਂ ਰੱਖਿਆ ਗਿਆ ਸੀ; ਦੂਜੀ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ /utility-name ਵਜੋਂ ਸਿੱਧਾ ਰੱਖਿਆ ਗਿਆ ਸੀ। CDN ਨੇ ਦੋਵਾਂ ਨੂੰ ਦੇਖਿਆ, ਉਹਨਾਂ ਨੂੰ ਸੁਲਝਾਉਣ ਲਈ redirect chains ਬਣਾਈਆਂ, ਅਤੇ edge 'ਤੇ errors ਦੇਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ। ਪੇਜ ਅੰਤ ਵਿੱਚ ਲੋਡ ਹੋ ਗਏ, ਪਰ ਹਰ redirect ਨੇ crawl budget ਅਤੇ ਉਪਭੋਗਤਾ ਦੇ ਸਬਰ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ। ਕੋਡ ਸਹੀ ਸੀ, ਪਰ topology ਬਹੁਤ ਖਰਾਬ ਸੀ।

ਫਿਰ sync trap ਦੀ ਵਾਰੀ ਆਈ। ਮੈਂ ਇੱਕ mirror site — ਇੱਕ staging ਜਾਂ backup instance — ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ, ਪਰ ਉਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਵਾਪਸ source repository ਵਿੱਚ ਭੇਜਣਾ ਭੁੱਲ ਗਿਆ। ਜਦੋਂ ਮੈਂ ਬਾਅਦ ਵਿੱਚ AI ਨੂੰ environments ਨੂੰ sync ਕਰਨ ਲਈ ਕਿਹਾ, ਤਾਂ ਇਸਨੇ mirror ਨੂੰ ਹੀ ਸਹੀ (ground truth) ਮੰਨ ਲਿਆ। ਇੱਕ ਸਧਾਰਨ sync command production database ਜਾਂ file set ਨੂੰ ਪੁਰਾਣੇ mirror data ਨਾਲ overwrite ਕਰ ਸਕਦੀ ਸੀ। AI ਨੇ ਉਹ ਕੀਤਾ ਜੋ ਮੈਂ ਦੱਸਿਆ ਸੀ, ਉਹ ਨਹੀਂ ਜੋ ਮੈਂ ਚਾਹੁੰਦਾ ਸੀ। ਇਰਾਦੇ (intentions) diff ਨਹੀਂ ਹੁੰਦੇ; ਫਾਈਲਾਂ ਹੁੰਦੀਆਂ ਹਨ।

Audit tools ਨੇ ਖੁਦ ਝੂਠ ਬੋਲਿਆ। ਕਿਉਂਕਿ ਮੈਂ auditing ਨੂੰ automate ਕਰ ਦਿੱਤਾ ਸੀ, ਮੈਂ ਮੰਨ ਲਿਆ ਸੀ ਕਿ output ਸਾਫ਼ ਹੈ। ਪਰ ਇਹ ਸਹੀ ਨਹੀਂ ਸੀ। AI ਦੁਆਰਾ ਲਿਖੇ ਗਏ audit scripts ਵਿੱਚ ਬਰੀਕ bugs ਸਨ: off-by-one checks, redirect status codes ਬਾਰੇ ਗਲਤ ਅੰਦਾਜ਼ੇ, ਅਤੇ ਅਸਲ misconfigurations ਦੀ ਬਜਾਏ timing ਜਾਂ headers ਕਾਰਨ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਫੈਂਟਮ (phantom) ਗਲਤੀਆਂ। ਉਹਨਾਂ ਨੇ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੱਸੀਆਂ ਜੋ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਸਨ, ਜਿਸ ਨਾਲ ਮੈਂ ਨਾਜਾਇਜ਼ ਚੀਜ਼ਾਂ ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਲੱਗ ਪਿਆ। ਮੈਂ ਸਿੱਖਿਆ ਕਿ ਜਦੋਂ ਤੱਕ ਮੈਂ ਮੈਨੁਅਲੀ live site ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰ ਲੈਂਦਾ ਅਤੇ browser ਜਾਂ ਸਿੱਧੇ curl ਰਾਹੀਂ ਲੱਛਣਾਂ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਲੈਂਦਾ, ਉਦੋਂ ਤੱਕ static analysis 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਲੁਕੀ ਹੋਈ ਕੀਮਤ

ਇੱਥੇ ਇੱਕ ਅਜਿਹਾ ਅੰਕ ਹੈ ਜਿਸ ਬਾਰੇ ਕੋਈ ਗੱਲ ਨਹੀਂ ਕਰਦਾ: ਮੇਰੇ token ਖਰਚੇ ਦਾ 93 ਪ੍ਰਤੀਸ਼ਤ ਹਿੱਸਾ cached context ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਵਿੱਚ ਗਿਆ।

ਇੱਕ ਲੰਬੇ Claude Code ਸੈਸ਼ਨ ਵਿੱਚ, ਹਰ ਨਵੀਂ ਬੇਨਤੀ ਮਾਡਲ ਨੂੰ ਪਿਛਲੀ ਗੱਲਬਾਤ ਦੇ ਇਤਿਹਾਸ, ਫਾਈਲ ਬਫਰਾਂ ਅਤੇ ਵਰਕਿੰਗ ਮੈਮੋਰੀ ਨੂੰ ਦੁਬਾਰਾ ਦੇਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਸੈਸ਼ਨ ਵਿੱਚ ਪਹਿਲਾ ਕੰਮ ਸਸਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਦਸਵੇਂ ਕੰਮ ਤੱਕ, ਮਾਡਲ ਅਗਲੇ ਵਾਕ ਨੂੰ ਸਮਝਣ ਲਈ ਪਹਿਲਾਂ ਜੋ ਕੁਝ ਵੀ ਹੋਇਆ ਹੈ, ਉਸ ਸਭ ਨੂੰ ਪਚਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਲਾਗਤ ਦਾ ਕਰਵ ਤੇਜ਼ੀ ਨਾਲ ਉੱਪਰ ਵੱਲ ਵਧਦਾ ਹੈ। ਲੰਬੇ ਸੈਸ਼ਨ ਮਹਿੰਗੇ ਪੜ੍ਹਨ ਦੇ ਅਭਿਆਸਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਪੁਰਾਣੇ ਕੰਮਾਂ ਦੇ ਕੂੜੇ ਨਾਲ ਭਰ ਜਾਂਦੀ ਹੈ ਜਿਸਦਾ ਮੌਜੂਦਾ ਕੰਮ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੁੰਦਾ।

ਇਹ ਕੋਈ ਅਜੀਬ ਗੱਲ ਨਹੀਂ ਹੈ। ਇਹ ਮਾੜੀ ਸੈਸ਼ਨ ਹਾਈਜੀਨ 'ਤੇ ਇੱਕ ਸਿੱਧਾ ਟੈਕਸ ਹੈ।

ਇਸ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਿਆ ਜਾਵੇ

ਇੱਕ ਵਾਰ ਜਦੋਂ ਮੈਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਨਾਮ ਦੇ ਦਿੱਤਾ, ਤਾਂ ਸੁਧਾਰ ਕਰਨਾ ਸੌਖਾ ਸੀ।

ਇੱਕ ਸੈਸ਼ਨ ਨੂੰ ਇੱਕ ਕੰਮ ਵਜੋਂ ਮੰਨੋ। ਜਦੋਂ ਕੰਮ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਕੰਟੈਕਸਟ ਨੂੰ 'ਵਾਰਮ' ਰੱਖਣ ਦਾ ਲਾਲਚ ਬਹੁਤ ਹੁੰਦਾ ਹੈ — ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸੈੱਟਅੱਪ ਦਾ ਸਮਾਂ ਬਚਾ ਰਹੇ ਹੋ — ਪਰ ਅਸਲ ਵਿੱਚ ਤੁਸੀਂ ਚੱਕਰਵਰਤੀ ਵਿਆਜ 'ਤੇ ਮੈਮੋਰੀ ਕਿਰਾਏ 'ਤੇ ਲੈ ਰਹੇ ਹੁੰਦੇ ਹੋ।

ਗਿਆਨ ਨੂੰ ਛੋਟੀਆਂ, ਸਮਰਪਿਤ ਮੈਮੋਰੀ ਫਾਈਲਾਂ ਵਿੱਚ ਰੱਖੋ। ਮਾਡਲ ਨੂੰ ਗੱਲਬਾਤ ਦੇ ਕੰਟੈਕਸਟ ਦੇ ਅੰਦਰ ਬ੍ਰਾਂਡ ਗਾਈਡਲਾਈਨਾਂ, ਕੰਪੋਨੈਂਟ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਜਾਂ SEO ਨਿਯਮਾਂ ਨੂੰ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦਿਓ। ਉਹਨਾਂ ਨੂੰ ਸੰਖੇਪ ਫਾਈਲਾਂ ਵਿੱਚ ਡਿਸਕ 'ਤੇ ਲਿਖੋ ਅਤੇ ਉਹਨਾਂ ਦਾ ਸਪੱਸ਼ਟ ਰੈਫਰੈਂਸ ਦਿਓ। ਇਹ ਜਾਣਕਾਰੀ ਨੂੰ ਮਹਿੰਗੇ ਵੋਲਾਟਾਈਲ ਕੰਟੈਕਸਟ ਤੋਂ ਸਸਤੇ ਪਰਸਿਸਟੈਂਟ ਸਟੋਰੇਜ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ।

ਵੱਖ-ਵੱਖ ਕੰਮਾਂ ਦੇ ਵਿਚਕਾਰ, ਸਭ ਕੁਝ ਸਾਫ਼ ਕਰ ਦਿਓ। ਸੈਸ਼ਨ ਬੰਦ ਕਰੋ। ਇੱਕ ਨਵਾਂ ਸੈਸ਼ਨ ਖੋਲ੍ਹੋ। ਤੀਹ ਸੈਕਿੰਡ ਦਾ ਸੈੱਟਅੱਪ ਬਾਅਦ ਵਿੱਚ ਡਾਲਰਾਂ ਅਤੇ ਭੁਲੇਖਿਆਂ (hallucinations) ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ।

ਸਕੇਲਿੰਗ ਲਈ ਸਬਕ

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਨ ਜਾ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਗਾਰਡਰੇਲਜ਼ ਦੀ ਲੋੜ ਹੈ ਜੋ ਫਾਈਲ ਦੀ ਬਜਾਏ ਸਿਸਟਮ ਨੂੰ ਸਮੀਖਿਆ ਦੀ ਇਕਾਈ ਵਜੋਂ ਮੰਨਦੇ ਹੋਣ।

ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੈਂਚਮਾਰਕ ਕਰੋ। ਇਹ ਨਾ ਮੰਨ ਲਓ ਕਿ ਇੱਕ ਪੇਜ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਰੈਂਡਰ ਹੋ ਰਿਹਾ ਹੈ। ਡਿਪਲੌਏਡ URL 'ਤੇ ਲੋਡ ਟਾਈਮ, ਮੋਬਾਈਲ ਲੇਆਉਟ, ਅਤੇ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਦੀ ਜਾਂਚ ਕਰੋ। ਲੋਕਲ ਡੈਵ ਵਿੱਚ ਇੱਕ ਸੁੰਦਰ ਕੰਪੋਨੈਂਟ ਅਸਲ ਨੈੱਟਵਰਕ ਸਥਿਤੀਆਂ ਦੇ ਅਧੀਨ ਟੁੱਟ ਸਕਦਾ ਹੈ।

ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਿਫ (Diff) ਦੇਖੋ। ਕਦੇ ਵੀ ਅੰਨ੍ਹੇਵਾਹ ਬਲਕ ਸਿੰਕ ਜਾਂ ਕਾਪੀ ਆਪਰੇਸ਼ਨ ਨਾ ਚਲਾਓ। ਡੈਲਟਾ ਨੂੰ ਦੇਖੋ। ਸਮਝੋ ਕਿ ਡਾਟਾ ਕਿਸ ਦਿਸ਼ਾ ਵਿੱਚ ਵਹਿ ਰਿਹਾ ਹੈ। AI ਤੁਹਾਨੂੰ ਇਹ ਚੇਤਾਵਨੀ ਨਹੀਂ ਦੇਵੇਗਾ ਕਿ ਤੁਸੀਂ ਲਾਈਵ ਗਾਹਕ ਡਾਟਾ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਵਾਲੇ ਹੋ।

ਆਡਿਟ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਾਈਵ ਸਾਈਟਾਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਇੱਕ ਪਰਿਕਲਪਨਾ ਹੈ। ਇੱਕ ਲਾਈਵ ਰਿਕਵੈਸਟ ਸਬੂਤ ਹੈ। ਜਦੋਂ ਕੋਈ ਆਡਿਟ ਟੂਲ ਟੁੱਟੇ ਹੋਏ ਲਿੰਕ ਜਾਂ ਰੀਡਾਇਰੈਕਟ ਲੂਪ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਿੱਧੀ ਰਿਕਵੈਸਟ ਨਾਲ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਟੂਲਜ਼ ਵਿੱਚ ਵੀ ਬੱਗ ਹੁੰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਉਹ ਟੂਲ ਜੋ ਅਨੁਮਾਨਿਤ ਪੈਟਰਨਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ AI ਦੁਆਰਾ ਲਿਖੇ ਗਏ ਹਨ।

ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਿਵਾਜਾਂ ਨੂੰ ਲਿਖ ਲਓ। URL ਬਣਤਰ, ਫੋਲਡਰ ਹਾਇਰਾਰਕੀ, ਕੈਨੋਨੀਕਲ ਪੈਟਰਨ, ਅਤੇ ਕੰਟੈਂਟ ਟੈਕਸੋਨੋਮੀ ਨੂੰ ਅਜਿਹੀ ਜਗ੍ਹਾ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ ਜਿਸਨੂੰ AI ਇੱਕ ਨਵਾਂ ਪੇਜ ਬਣਾਉਣ ਤੋਂ