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.
在一个漫长的 Claude Code 会话中，每一个新请求都会迫使模型重新审视之前的对话历史、文件缓冲区和工作记忆。会话中的第一个任务可能很廉价。但到了第十个任务时，模型为了理解下一句话，不得不消化之前发生的一切。成本曲线会迅速向上弯曲。长会话会变成昂贵的重复阅读练习，而上下文窗口则充满了与当前任务无关的早期任务残留物。
这并非偶然现象。这是对糟糕的会话管理习惯征收的直接税。
如何解决
一旦我明确了问题所在，解决方法就很简单了。
将一个会话视为一个任务。当工作内容发生变化时，请开启新会话。保持上下文“热度”的诱惑很大——你会觉得是在节省设置时间——但实际上你是在以复利形式租用内存。
将知识保存在小型、专用的记忆文件中。不要让模型在对话上下文中携带品牌指南、组件库或 SEO 规则。将它们以简洁的文件形式写入磁盘并进行显式引用。这能将信息从昂贵的易失性上下文中转移到廉价的持久化存储中。
在不同的工作任务之间，清理现场。关闭当前会话。开启一个新会话。这三十秒的设置时间可以节省后续的资金成本并减少幻觉。
规模化经验教训
如果你打算进行如此大规模的工作，你需要建立一套将“系统”而非“文件”作为审查单元的防护准则。
发布前进行基准测试。 不要因为页面能渲染就假设它能正常工作。在部署的 URL 上检查加载时间、移动端布局和核心指标。本地开发中精美的组件在真实的网络条件下可能会崩溃。
复制前进行 Diff 对比。 永远不要盲目运行批量同步或复制操作。查看差异（delta）。理解数据的流动方向。AI 不会提醒你即将覆盖真实的客户数据。
在信任审计结果之前，先探测线上站点。 静态分析只是一个假设。实时请求才是证据。当审计工具报告死链或重定向循环时，请通过直接请求进行验证。工具也会有 Bug，尤其是那些由基于推断模式运行的 AI 所编写的工具。
在规模化之前写下规范。 在 AI 生成任何新页面之前，URL 结构、文件夹层级、规范化模式和内容分类法都需要记录在 AI 可以读取的地方。记忆文件在...时并非可选