When someone tells you they shipped 335 live pages across 26 repositories in 29 days, working alone, the instinct is to ask how they moved so fast. The better question is what broke when they did.
The numbers are real: 1,549 commits, 26 repos, 29 days, one developer using Claude Code. But velocity itself teaches you very little. What matters is the texture of the failures, because they were not the kind you catch in a stack trace. They were structural fractures. You only see them when you step back from the editor and look at the whole system breathing in production.
What Worked
The speed was not an illusion. Certain tasks really do collapse in duration when you hand them to an AI that does not sleep.
Textbook algorithms turned into shipped features over days, not weeks. A 2048 solver and minimax-based games came together fast because the implementation patterns are well documented. The model does not get lost in academic papers; it writes the search tree, the heuristic evaluation, the move scoring, and moves on. These are solved problems, and an AI pair programmer handles solved problems with brute efficiency.
Tedious audits became tolerable. Crawling link graphs, verifying redirect chains, checking canonical tags across hundreds of pages — this work destroys human attention spans, but a language model will iterate without complaint. It checks the same pattern three hundred times and reports back.
The real surprise was consistency. When you ask an AI to generate dozens of landing pages, drift is inevitable unless you anchor it. I used small memory files to lock down a single brand system: voice rules, color token names, component restrictions, and page archetypes. The model read those constraints at the start of each relevant task and produced work that felt like it came from one hand instead of twenty-nine different moods.
What Actually Broke
The failures were architectural. No build failed because of a missing semicolon. Instead, the system slowly deceived me into thinking everything was fine.
SEO cannibalization hit first. The AI built a new tool hub under a fresh URL while an older tool hub still lived at its original path. Each individual page was optimized. Titles were tight. Meta descriptions were unique. Content was useful. But they all hunted the same search intent. Search engines saw two authorities on identical terms and ranked neither. Perfect pages canceled each other out because no one was watching the site as a portfolio rather than a collection of files.
URL mismatches followed. Different repositories adopted slightly different folder structures for the same logical content. One repo nested tools under /tools/utility-name; another flattened them to /utility-name. The CDN saw both, generated redirect chains to resolve them, and started throwing errors at the edge. The pages loaded, eventually, but every redirect burned crawl budget and user patience. The code was correct. The topology was a mess.
Then came the sync trap. I updated a mirror site — a staging or backup instance — but forgot to propagate those changes back to the source repository. When I later asked the AI to sync the environments, it treated the mirror as ground truth. A simple sync command would have overwritten the production database or file set with stale mirror data. The AI executed what I described, not what I intended. Intentions do not diff; files do.
The audit tools themselves lied. Because I automated the auditing, I assumed the output was clean. It was not. The AI-written audit scripts contained subtle bugs: off-by-one checks, incorrect assumptions about redirect status codes, phantom errors triggered by timing or headers rather than real misconfigurations. They reported problems that did not exist, which sent me chasing ghosts. I learned to stop trusting static analysis until I had manually probed the live site and confirmed the symptom in a browser or a direct curl.
The Hidden Cost
Here is a number no one talks about: 93 percent of my token spend went to re-reading cached context.
Trong một phiên làm việc Claude Code kéo dài, mỗi yêu cầu mới buộc mô hình phải xem lại toàn bộ lịch sử trò chuyện, bộ đệm tệp và bộ nhớ làm việc trước đó. Tác vụ đầu tiên trong một phiên có thể rất rẻ. Nhưng đến tác vụ thứ mười, mô hình phải tiêu thụ mọi thứ đã diễn ra trước đó chỉ để hiểu được câu tiếp theo. Đường cong chi phí tăng vọt nhanh chóng. Các phiên làm việc dài trở thành những bài tập đọc lại tốn kém, và cửa sổ ngữ cảnh bị lấp đầy bởi những dữ liệu thừa từ các công việc trước đó vốn chẳng liên quan gì đến công việc hiện tại.
Đây không phải là một sự bất thường. Đó là một loại thuế trực tiếp đánh vào việc quản lý phiên làm việc kém hiệu quả.
Cách khắc phục
Các giải pháp trở nên đơn giản ngay khi tôi gọi tên được các vấn đề.
Hãy coi mỗi phiên làm việc là một tác vụ duy nhất. Khi công việc thay đổi, hãy bắt đầu lại từ đầu. Sự cám dỗ của việc giữ cho ngữ cảnh luôn "ấm" là rất lớn — bạn cảm thấy như mình đang tiết kiệm thời gian thiết lập — nhưng thực tế là bạn đang thuê bộ nhớ với lãi suất kép.
Hãy lưu trữ kiến thức trong các tệp bộ nhớ nhỏ và chuyên dụng. Đừng để mô hình mang theo các hướng dẫn thương hiệu, thư viện thành phần hoặc các quy tắc SEO bên trong ngữ cảnh trò chuyện. Hãy viết chúng vào đĩa cứng trong các tệp súc tích và tham chiếu chúng một cách rõ ràng. Điều này chuyển thông tin từ ngữ cảnh tạm thời đắt đỏ sang lưu trữ bền vững giá rẻ.
Giữa các công việc khác nhau, hãy dọn dẹp mọi thứ. Đóng phiên làm việc. Mở một phiên mới. 30 giây thiết lập ban đầu giúp tiết kiệm tiền bạc và tránh các lỗi ảo giác (hallucinations) sau này.
Bài học để mở rộng quy mô
Nếu bạn định làm việc với khối lượng lớn như thế này, bạn cần các rào chắn kiểm soát coi hệ thống, chứ không phải tệp tin, là đơn vị đánh giá.
Kiểm thử hiệu năng trước khi xuất bản. Đừng mặc định rằng một trang web hoạt động tốt chỉ vì nó hiển thị được. Hãy kiểm tra thời gian tải, bố cục trên thiết bị di động và các chỉ số cốt lõi trên URL đã triển khai. Một thành phần đẹp mắt trong môi trường phát triển cục bộ có thể bị sụp đổ dưới các điều kiện mạng thực tế.
So sánh sự khác biệt (diff) trước khi sao chép. Đừng bao giờ thực hiện thao tác đồng bộ hóa hàng loạt hoặc sao chép một cách mù quáng. Hãy xem xét phần chênh lệch (delta). Hiểu rõ dữ liệu đang chảy theo hướng nào. AI sẽ không cảnh báo bạn rằng bạn sắp ghi đè lên dữ liệu khách hàng đang hoạt động đâu.
Kiểm tra các trang web thực tế trước khi tin tưởng vào các bản kiểm định. Phân tích tĩnh chỉ là một giả thuyết. Một yêu cầu thực tế mới là bằng chứng. Khi một công cụ kiểm định báo cáo một liên kết bị hỏng hoặc một vòng lặp chuyển hướng, hãy xác minh nó bằng một yêu cầu trực tiếp. Các công cụ cũng có lỗi, đặc biệt là các công cụ được viết bởi một AI hoạt động dựa trên các mẫu suy luận.
Viết ra các quy ước trước khi mở rộng quy mô. Cấu trúc URL, phân cấp thư mục, các mẫu canonical và phân loại nội dung cần được tài liệu hóa ở một nơi mà AI có thể đọc được trước khi nó tạo ra bất kỳ trang mới nào. Các tệp bộ nhớ không phải là tùy chọn mà là bắt buộc tại