ಯಾರಾದರೂ ಒಬ್ಬರು ಒಬ್ಬರೇ ಕೆಲಸ ಮಾಡುತ್ತಾ 29 ದಿನಗಳಲ್ಲಿ 26 ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ (repositories) 335 ಲೈವ್ ಪೇಜ್ಗಳನ್ನು ಶಿಪ್ ಮಾಡಿದ್ದೇವೆ ಎಂದು ಹೇಳಿದಾಗ, ಅವರು ಅಷ್ಟು ವೇಗವಾಗಿ ಹೇಗೆ ಮಾಡಿದರು ಎಂದು ಕೇಳುವುದು ಸಹಜ. ಆದರೆ ಅದಕ್ಕಿಂತ ಉತ್ತಮವಾದ ಪ್ರಶ್ನೆ ಏನೆಂದರೆ, ಅವರು ಅಷ್ಟು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಿದಾಗ ಏನಾದರೂ ಮುರಿದುಹೋಯಿತೇ?
ಅಂಕಿಅಂಶಗಳು ನಿಜವಾಗಿವೆ: 1,549 ಕಮಿಟ್ಗಳು (commits), 26 ರೆಪೊಗಳು (repos), 29 ದಿನಗಳು, Claude Code ಬಳಸುವ ಒಬ್ಬ ಡೆವಲಪರ್. ಆದರೆ ವೇಗವು ನಿಮಗೆ ಬಹಳ ಕಡಿಮೆ ಕಲಿಸುತ್ತದೆ. ಮುಖ್ಯವಾದುದು ವಿಫಲತೆಗಳ ಸ್ವರೂಪ, ಏಕೆಂದರೆ ಅವು ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ನಲ್ಲಿ (stack trace) ಸಿಗುವಂತಹ ವಿಫಲತೆಗಳಲ್ಲ. ಅವು ರಚನಾತ್ಮಕ ಬಿರುಕುಗಳಾಗಿದ್ದವು (structural fractures). ನೀವು ಎಡಿಟರ್ನಿಂದ ಹಿಂದೆ ಸರಿದು, ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ (production) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ನೋಡಿದಾಗ ಮಾತ್ರ ಅವುಗಳು ಕಾಣಿಸುತ್ತವೆ.
ಯಾವುದು ಕೆಲಸ ಮಾಡಿತು
ಆ ವೇಗವು ಭ್ರಮೆಯಲ್ಲವಾಗಿತ್ತು. ನಿದ್ರೆಯಿಲ್ಲದ AI ಗೆ ನೀವು ಕೆಲವು ಕೆಲಸಗಳನ್ನು ವಹಿಸಿದಾಗ, ಅವುಗಳ ಅವಧಿಯು ನಿಜವಾಗಿಯೂ ಗಣನೀಯವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಪಠ್ಯಪುಸ್ತಕದ ಅಲ್ಗಾರಿದಮ್ಗಳು (algorithms) ವಾರಗಳ ಬದಲಾಗಿ ದಿನಗಳಲ್ಲಿ ಶಿಪ್ ಮಾಡಿದ ಫೀಚರ್ಗಳಾಗಿ ಬದಲಾದವು. 2048 ಸಾಲ್ವರ್ (solver) ಮತ್ತು minimax ಆಧಾರಿತ ಗೇಮ್ಗಳು ವೇಗವಾಗಿ ಸಿದ್ಧವಾದವು ಏಕೆಂದರೆ ಅವುಗಳ ಅನುಷ್ಠಾನ ಮಾದರಿಗಳು (implementation patterns) ಉತ್ತಮವಾಗಿ ದಾಖಲಾಗಿವೆ. ಮಾಡೆಲ್ ಶೈಕ್ಷಣಿಕ ಪ್ರಬಂಧಗಳಲ್ಲಿ ಕಳೆದುಹೋಗುವುದಿಲ್ಲ; ಅದು ಸರ್ಚ್ ಟ್ರೀ (search tree), ಹ್ಯೂರಿಸ್ಟಿಕ್ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ (heuristic evaluation), ಮೂವ್ ಸ್ಕೋರಿಂಗ್ (move scoring) ಅನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಕೆಲಸಕ್ಕೆ ಸಾಗುತ್ತದೆ. ಇವು ಪರಿಹರಿಸಲಾದ ಸಮಸ್ಯೆಗಳಾಗಿದ್ದು, AI ಪೇರ್ ಪ್ರೋಗ್ರಾಮರ್ ಇಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ಅತ್ಯಂತ ದಕ್ಷತೆಯಿಂದ ನಿಭಾಯಿಸುತ್ತದೆ.
ಬೇಸರ ತರಿಸುವ ಆಡಿಟ್ಗಳು (audits) ಸಹನೀಯವಾದವು. ಲಿಂಕ್ ಗ್ರಾಫ್ಗಳನ್ನು ಕ್ರಾಲ್ ಮಾಡುವುದು (crawling), ರಿಡೈರೆಕ್ಟ್ ಚೇನ್ಗಳನ್ನು (redirect chains) ಪರಿಶೀಲಿಸುವುದು, ನೂರಾರು ಪೇಜ್ಗಳಲ್ಲಿ ಕ್ಯಾನಾನಿಕಲ್ ಟ್ಯಾಗ್ಗಳನ್ನು (canonical tags) ಪರೀಕ್ಷಿಸುವುದು — ಈ ಕೆಲಸಗಳು ಮನುಷ್ಯನ ಏಕಾಗ್ರತೆಯನ್ನು ಕುಂದಿಸುತ್ತವೆ, ಆದರೆ ಒಂದು ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ (language model) ದೂರು ನೀಡದೆ ಪದೇ ಪದೇ ಮಾಡುತ್ತದೆ. ಅದು ಒಂದೇ ಮಾದರಿಯನ್ನು ನೂರು ಬಾರಿ ಪರೀಕ್ಷಿಸಿ ವರದಿ ನೀಡುತ್ತದೆ.
ನಿಜವಾದ ಆಶ್ಚರ್ಯವೆಂದರೆ ಸ್ಥಿರತೆ (consistency). ನೀವು AI ಗೆ ಡಜನ್ಗಟ್ಟಲೆ ಲ್ಯಾಂಡಿಂಗ್ ಪೇಜ್ಗಳನ್ನು (landing pages) ತಯಾರಿಸಲು ಹೇಳಿದಾಗ, ನೀವು ಅದನ್ನು ನಿಯಂತ್ರಿಸದ ಹೊರತು ಬದಲಾವಣೆಗಳು ಅನಿವಾರ್ಯ. ನಾನು ಒಂದು ಬ್ರ್ಯಾಂಡ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿಡಲು ಸಣ್ಣ ಮೆಮೊರಿ ಫೈಲ್ಗಳನ್ನು ಬಳಸಿದೆ: ಧ್ವನಿಯ ನಿಯಮಗಳು (voice rules), ಬಣ್ಣದ ಟೋಕನ್ ಹೆಸರುಗಳು (color token names), ಘಟಕದ ನಿರ್ಬಂಧಗಳು (component restrictions) ಮತ್ತು ಪೇಜ್ ಆರ್ಕಿಟೈಪ್ಗಳು (page archetypes). ಮಾಡೆಲ್ ಪ್ರತಿ ಕೆಲಸದ ಆರಂಭದಲ್ಲಿ ಆ ನಿರ್ಬಂಧಗಳನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಇಪ್ಪತ್ತೊಂಬತ್ತು ವಿಭಿನ್ನ ಮನಸ್ಥಿತಿಗಳಿಂದ ಬಂದಂತೆ ಕಾಣುವ ಬದಲು, ಒಂದೇ ಕೈಯಿಂದ ಮಾಡಿದಂತೆ ಕಾಣುವ ಕೆಲಸವನ್ನು ನೀಡುತ್ತದೆ.
ನಿಜವಾಗ فونب ಏನವು ಮುರಿದುಹೋಯಿತು
ವಿಫಲತೆಗಳು ವಾಸ್ತುಶಿಲ್ಪಾತ್ಮಕವಾಗಿದ್ದವು (architectural). ಸೆಮಿಕೋಲನ್ (semicolon) ಮಿಸ್ ಆಗಿದ್ದರಿಂದ ಯಾವುದೇ ಬಿಲ್ಡ್ (build) ವಿಫಲವಾಗಲಿಲ್ಲ. ಬದಲಾಗಿ, ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ನಂಬುವಂತೆ ವ್ಯವಸ್ಥೆಯು ನನ್ನನ್ನು ನಿಧಾನವಾಗಿ ವಂಚಿಸಿತು.
ಮೊದಲನೆಯದಾಗಿ SEO cannibalization ಸಂಭವಿಸಿತು. ಹಳೆಯ ಟೂಲ್ ಹಬ್ (tool hub) ತನ್ನ ಮೂಲ ಪಾತ್ನಲ್ಲಿ (path) ಇರಲು, AI ಹೊಸ URL ಅಡಿಯಲ್ಲಿ ಹೊಸ ಟೂಲ್ ಹಬ್ ಅನ್ನು ನಿರ್ಮಿಸಿತು. ಪ್ರತಿಯೊಂದು ಪೇಜ್ ಅನ್ನು ಆಪ್ಟಿಮೈಸ್ (optimize) ಮಾಡಲಾಗಿತ್ತು. ಶೀರ್ಷಿಕೆಗಳು (titles) ಚೊಕ್ಕವಾಗಿದ್ದವು. ಮೆಟಾ ಡಿಸ್ಕ್ರಿಪ್ಶನ್ಗಳು (meta descriptions) ವಿಶಿಷ್ಟವಾಗಿದ್ದವು. ಕಂಟೆಂಟ್ ಉಪಯುಕ್ತವಾಗಿತ್ತು. ಆದರೆ ಅವೆಲ್ಲವೂ ಒಂದೇ ರೀತಿಯ ಸರ್ಚ್ ಇಂಟೆಂಟ್ (search intent) ಅನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದ್ದವು. ಸರ್ಚ್ ಇಂಜಿನ್ಗಳು ಒಂದೇ ಪದಗಳ ಮೇಲೆ ಎರಡು ಅಧಿಕಾರ ಕೇಂದ್ರಗಳನ್ನು ಕಂಡವು ಮತ್ತು ಎರಡನ್ನೂ ರ್ಯಾಂಕ್ ಮಾಡಲಿಲ್ಲ. ಯಾರೂ ಸೈಟ್ ಅನ್ನು ಕೇವಲ ಫೈಲ್ಗಳ ಸಂಗ್ರಹವಾಗಿ ನೋಡದೆ, ಒಂದು ಪೋರ್ಟ್ಫೋಲಿಯೊ ಆಗಿ ಗಮನಿಸದ ಕಾರಣ, ಆ ಪರಿಪೂರ್ಣ ಪೇಜ್ಗಳು ಪರಸ್ಪರ ಅಳವಡಿಸಿಕೊಂಡವು.
ನಂತರ URL mismatch ಸಂಭವಿಸಿತು. ಒಂದೇ ರೀತಿಯ ತಾರ್ಕಿಕ ಕಂಟೆಂಟ್ಗಾಗಿ ವಿಭಿನ್ನ ರೆಪೊಸಿಟರಿಗಳು ಸ್ವಲ್ಪ ವಿಭಿನ್ನ ಫೋಲ್ಡರ್ ರಚನೆಗಳನ್ನು (folder structures) ಅಳವಡಿಸಿಕೊಂಡವು. ಒಂದು ರೆಪೊ ಟೂಲ್ಗಳನ್ನು /tools/utility-name ಅಡಿಯಲ್ಲಿ ಇರಿಸಿದ್ದರೆ; ಇನ್ನೊಂದು ಅವುಗಳನ್ನು /utility-name ಎಂದು ಸರಳಗೊಳಿಸಿತು. CDN ಇವೆರಡನ್ನೂ ನೋಡಿ, ಅವುಗಳನ್ನು ಪರಿಹರಿಸಲು ರಿಡೈರೆಕ್ಟ್ ಚೇನ್ಗಳನ್ನು (redirect chains) ಸೃಷ್ಟಿಸಿತು ಮತ್ತು ಎಡ್ಜ್ನಲ್ಲಿ (edge) ದೋಷಗಳನ್ನು (errors) ತೋರಿಸಲು ಪ್ರಾರಂಭಿಸಿತು. ಪೇಜ್ಗಳು ಅಂತಿಮವಾಗಿ ಲೋಡ್ ಆದವು, ಆದರೆ ಪ್ರತಿಯೊಂದು ರಿಡೈರೆಕ್ಟ್ ಕೂಡ ಕ್ರಾಲ್ ಬಜೆಟ್ (crawl budget) ಮತ್ತು ಬಳಕೆದಾರರ ತಾಳ್ಮೆಯನ್ನು ವ್ಯರ್ಥ ಮಾಡಿತು. ಕೋಡ್ ಸರಿಯಾಗಿತ್ತು, ಆದರೆ ಟೋಪೋಲಜಿ (topology) ಗೊಂದಲಮಯವಾಗಿತ್ತು.
ನಂತರ ಸಿಂಕ್ ಟ್ರ್ಯಾಪ್ (sync trap) ಎದುರಾಯಿತು. ನಾನು ಮಿರರ್ ಸೈಟ್ ಅನ್ನು (mirror site) — ಅಂದರೆ ಸ್ಟೇಜಿಂಗ್ ಅಥವಾ ಬ್ಯಾಕಪ್ ಇನ್ಸ್ಟೆನ್ಸ್ ಅನ್ನು — ಅಪ್ಡೇಟ್ ಮಾಡಿದೆ, ಆದರೆ ಆ ಬದಲಾವಣೆಗಳನ್ನು ಮೂಲ ರೆಪೊಸಿಟರಿಗೆ (source repository) ತಲುಪಿಸಲು ಮರೆತಿದೆ. ನಂತರ ನಾನು ಪರಿಸರಗಳನ್ನು (environments) ಸಿಂಕ್ ಮಾಡಲು AI ಗೆ ಹೇಳಿದಾಗ, ಅದು ಮಿರರ್ ಅನ್ನು ಸತ್ಯಾಂಶವೆಂದು (ground truth) ಪರಿಗಣಿಸಿತು. ಒಂದು ಸರಳ ಸಿಂಕ್ ಕಮಾಂಡ್ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಫೈಲ್ ಸೆಟ್ ಅನ್ನು ಹಳೆಯ ಮಿರರ್ ಡೇಟಾ ಬಳಸಿ ಅಳಿಸಿಹಾಕುತ್ತಿತ್ತು. ನಾನು ಏನು ವಿವರಿಸಿದ್ದೆನೋ ಅದನ್ನು AI ಮಾಡಿತು, ನಾನು ಏನನ್ನು ಉದ್ದೇಶಿಸಿದ್ದನೋ ಅದನ್ನು ಅಲ್ಲ. ಉದ್ದೇಶಗಳು ಡಿಫ್ (diff) ಆಗುವುದಿಲ್ಲ; ಫೈಲ್ಗಳು ಆಗುತ್ತವೆ.
ಆಡಿಟ್ ಟೂಲ್ಗಳೇ ಸುಳ್ಳು ಹೇಳಿದವು. ನಾನು ಆಡಿಟಿಂಗ್ ಅನ್ನು ಆಟೋಮೇಟ್ ಮಾಡಿದ್ದರಿಂದ, ಔಟ್ಪುಟ್ ಸ್ವಚ್ಛವಾಗಿದೆ ಎಂದು ಭಾವಿಸಿದೆ. ಆದರೆ ಅದು ಹಾಗಿರಲಿಲ್ಲ. AI ಬರೆದ ಆಡಿಟ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳಲ್ಲಿ ಸೂಕ್ಷ್ಮ ದೋಷಗಳಿದ್ದವು: off-by-one ಚೆಕ್ಗಳು, ರಿಡೈರೆಕ್ಟ್ ಸ್ಟೇಟಸ್ ಕೋಡ್ಗಳ ಬಗ್ಗೆ ತಪ್ಪು ಕಲ್ಪನೆಗಳು, ನೈಜ ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್ಗಳಿಗಿಂತ ಸಮಯ ಅಥವಾ ಹೆಡರ್ಗಳಿಂದ ಉಂಟಾದ ಕಾಲ್ಪನಿಕ ದೋಷಗಳು. ಅವು ಅಸ್ತಿತ್ವದಲ್ಲೇ ಇಲ್ಲದ ಸಮಸ್ಯೆಗಳನ್ನು ವರದಿ ಮಾಡಿದವು, ಇದು ನನ್ನನ್ನು ಸುಳ್ಳು ಹುಡುಕಾಟದಲ್ಲಿ ತೊಡಗಿಸಿತು. ಲೈವ್ ಸೈಟ್ ಅನ್ನು ನಾನು ಸ್ವತಃ ಪರೀಕ್ಷಿಸಿ, ಬ್ರೌಸರ್ ಅಥವಾ ಡೈರೆಕ್ಟ್ curl ಮೂಲಕ ಲಕ್ಷಣಗಳನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವವರೆಗೆ ಸ್ಟ್ಯಾಟಿಕ್ ಅನಾಲಿಸಿಸ್ (static analysis) ಅನ್ನು ನಂಬುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕೆಂದು ನಾನು ಕಲಿತೆ.
ಗುಪ್ತ ವೆಚ್ಚ
ಯಾರೂ ಮಾತನಾಡದ ಒಂದು ಅಂಕಿಅಂಶ ಇಲ್ಲಿದೆ: ನನ್ನ ಟೋಕನ್ ಬಳಕೆಯ ಶೇಕಡಾ 93 ರಷ್ಟು ಭಾಗವು ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಕಾನ್ಟೆಕ್ಸ್ ಅನ್ನು (cached context) ಮರು ಓದಲು ವ್ಯಯವಾಯಿತು.
ದೀರ್ಘವಾದ Claude Code ಸೆಷನ್ನಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ಹೊಸ ವಿನಂತಿಯು ಮಾದರಿಯನ್ನು ಹಿಂದಿನ ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸ, ಫೈಲ್ ಬಫರ್ಗಳು ಮತ್ತು ವರ್ಕಿಂಗ್ ಮೆಮೊರಿಯನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಸೆಷನ್ನ ಮೊದಲ ಕಾರ್ಯವು ಅಗ್ಗವಾಗಿರಬಹುದು. ಹತ್ತನೇ ಕಾರ್ಯದ ವೇಳೆಗೆ, ಮಾದರಿಯು ಮುಂದಿನ ವಾಕ್ಯವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕೇವಲ ಅದಕ್ಕೂ ಮೊದಲು ಬಂದಿದ್ದನ್ನೆಲ್ಲಾ ಜೀರ್ಣಿಸಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ವೆಚ್ಚದ ರೇಖೆಯು ವೇಗವಾಗಿ ಮೇಲಕ್ಕೆ ಏರುತ್ತದೆ. ದೀರ್ಘ ಸೆಷನ್ಗಳು ದುಬಾರಿ ಮರುಪಠನ ವ್ಯಾಯಾಮಗಳಾಗಿ ಬದಲಾಗುತ್ತವೆ ಮತ್ತು ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋವು ಪ್ರಸ್ತುತ ಕೆಲಸಕ್ಕೆ ಸಂಬಂಧವಿಲ್ಲದ ಹಿಂದಿನ ಕೆಲಸಗಳ ಅವಶೇಷಗಳಿಂದ ತುಂಬಿಹೋಗುತ್ತದೆ.
ಇದು ಯಾವುದೇ ವಿಚಿತ್ರತೆಯಲ್ಲ. ಇದು ಕಳಪೆ ಸೆಷನ್ ಹೈಜೀನ್ನ ಮೇಲೆ ವಿಧಿಸಲಾದ ನೇರ ತೆರಿಗೆಯಾಗಿದೆ.
ಇದನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸುವುದು
ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಿದ ನಂತರ ಪರಿಹಾರಗಳು ಸರಳವಾಗಿದ್ದವು.
ಒಂದು ಸೆಷನ್ ಅನ್ನು ಒಂದು ಕಾರ್ಯವೆಂದು ಪರಿಗಣಿಸಿ. ಕೆಲಸ ಬದಲಾದಾಗ, ಹೊಸದಾಗಿ ಪ್ರಾರಂಭಿಸಿ. ಕಾಂಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿಕೊಳ್ಳುವ ಆಸೆ ಬಲವಾಗಿರಬಹುದು — ನೀವು ಸೆಟಪ್ ಸಮಯವನ್ನು ಉಳಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ನಿಮಗೆ ಅನಿಸಬಹುದು — ಆದರೆ ವಾಸ್ತವವಾಗಿ ನೀವು ಸಂಯುಕ್ತ ಬಡ್ಡಿಯೊಂದಿಗೆ ಮೆಮೊರಿಯನ್ನು ಬಾಡಿಗೆಗೆ ಪಡೆಯುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ.
ಜ್ಞಾನವನ್ನು ಸಣ್ಣ, ಮೀಸಲಾದ ಮೆಮೊರಿ ಫೈಲ್ಗಳಲ್ಲಿ ಇರಿಸಿ. ಬ್ರ್ಯಾಂಡ್ ಮಾರ್ಗಸೂಚಿಗಳು, ಕಾಂಪೊನೆಂಟ್ ಲೈಬ್ರರಿಗಳು ಅಥವಾ SEO ನಿಯಮಗಳನ್ನು ಸಂಭಾಷಣೆಯ ಕಾಂಟೆಕ್ಸ್ಟ್ನೊಳಗೆ ಹೊತ್ತುಕೊಂಡು ಹೋಗಲು ಮಾದರಿಗೆ ಬಿಡಬೇಡಿ. ಅವುಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತ ಫೈಲ್ಗಳಲ್ಲಿ ಡಿಸ್ಕ್ಗೆ ಬರೆಯಿರಿ ಮತ್ತು ಅವುಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಉಲ್ಲೇಖಿಸಿ. ಇದು ಮಾಹಿತಿಯನ್ನು ದುಬಾರಿ ವೋಲಟೈಲ್ ಕಾಂಟೆಕ್ಸ್ಟ್ನಿಂದ ಅಗ್ಗದ ಪರ್ಸಿಸ್ಟೆಂಟ್ ಸ್ಟೋರೇಜ್ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ.
ವಿಭಿನ್ನ ಕೆಲಸಗಳ ನಡುವೆ, ಹಳೆಯದನ್ನೆಲ್ಲಾ ಸ್ವಚ್ಛಗೊಳಿಸಿ. ಸೆಷನ್ ಮುಚ್ಚಿ. ಹೊಸದನ್ನು ತೆರೆಯಿರಿ. ಮೂವತ್ತು ಸೆಕೆಂಡ್ಗಳ ಸೆಟಪ್ ನಂತರದ ಡಾಲರ್ಗಳನ್ನು ಮತ್ತು ಹ್ಯಾಲ್ಯುಸಿನೇಷನ್ಗಳನ್ನು ಉಳಿಸುತ್ತದೆ.
ಸ್ಕೇಲಿಂಗ್ಗಾಗಿ ಪಾಠಗಳು
ನೀವು ಇಷ್ಟೊಂದು ಪ್ರಮಾಣದಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕೆಂದರೆ, ಫೈಲ್ ಅನ್ನು ಅಲ್ಲದೆ, ಸಿಸ್ಟಮ್ ಅನ್ನು ವಿಮರ್ಶೆಯ ಘಟಕವಾಗಿ ಪರಿಗಣಿಸುವ ಗಾರ್ಡ್ರೈಲ್ಗಳು ನಿಮಗೆ ಬೇಕಾಗುತ್ತವೆ.
ಪ್ರಕಟಿಸುವ ಮೊದಲು ಬೆಂಚ್ಮಾರ್ಕ್ ಮಾಡಿ. ಒಂದು ಪೇಜ್ ರেন্ডರ್ ಆಗುತ್ತಿದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಡಿ. ನಿಯೋಜಿತ URL ನಲ್ಲಿ ಲೋಡ್ ಸಮಯ, ಮೊಬೈಲ್ ಲೇಔಟ್ ಮತ್ತು ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಲೋಕಲ್ ಡೆವ್ನಲ್ಲಿರುವ ಸುಂದರವಾದ ಕಾಂಪೊನೆಂಟ್ ನೈಜ ನೆಟ್ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕುಸಿಯಬಹುದು.
ಕಾಪಿ ಮಾಡುವ ಮೊದಲು ಡಿಫ್ ಮಾಡಿ. ಎಂದಿಗೂ ಬಲ್ಕ್ ಸಿಂಕ್ ಅಥವಾ ಕಾಪಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಕುರುಡಾಗಿ ಮಾಡಬೇಡಿ. ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಿ. ಡೇಟಾ ಯಾವ ದಿಕ್ಕಿನಲ್ಲಿ ಹರಿಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ. ನೀವು ಲೈವ್ ಗ್ರಾಹಕರ ಡೇಟಾವನ್ನು ಓವರ್ರೈಟ್ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು AI ನಿಮಗೆ ಎಚ್ಚರಿಸುವುದಿಲ್ಲ.
ಆಡಿಟ್ಗಳನ್ನು ನಂಬುವ ಮೊದಲು ಲೈವ್ ಸೈಟ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ. ಸ್ಟ್ಯಾಟಿಕ್ ಅನಾಲಿಸಿಸ್ ಒಂದು ಕಲ್ಪನೆ ಮಾತ್ರ. ಲೈವ್ ರಿಕ್ವೆಸ್ಟ್ ಒಂದು ಸಾಕ್ಷಿ. ಆಡಿಟ್ ಟೂಲ್ ಒಂದು ಬ್ರೋಕನ್ ಲಿಂಕ್ ಅಥವಾ ರಿಡೈರೆಕ್ಟ್ ಲೂಪ್ ಅನ್ನು ವರದಿ ಮಾಡಿದಾಗ, ನೇರ ರಿಕ್ವೆಸ್ಟ್ ಮೂಲಕ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ. ಟೂಲ್ಗಳಿಗೂ ಬಗ್ಗಳಿರುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಅನ್ವಯಿತ ಮಾದರಿಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ AI ಬರೆದ ಟೂಲ್ಗಳಲ್ಲಿ ಇವು ಹೆಚ್ಚು.
ಸ್ಕೇಲ್ ಮಾಡುವ ಮೊದಲು ನಿಯಮಗಳನ್ನು ಬರೆದಿಡಿ. URL ರಚನೆ, ಫೋಲ್ಡರ್ ಹೈರಾರ್ಕಿ, ಕ್ಯಾನಾನಿಕಲ್ ಪ್ಯಾಟರ್ನ್ಗಳು ಮತ್ತು ಕಂಟೆಂಟ್ ಟ್ಯಾಕ್ಸಾನಮಿಗಳನ್ನು AI ಒಂದು ಹೊಸ ಪೇಜ್ ಅನ್ನು ರಚಿಸುವ ಮೊದಲು ಅದು ಓದಬಲ್ಲ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಿಸಬೇಕಾಗುತ್ತದೆ. ಮೆಮೊರಿ ಫೈಲ್ಗಳು ಕೇವಲ ಆಯ್ಕೆಯಲ್ಲ...