adrq 从一次具体的代码阅读困境写起：Agent 生成的 App.tsx 把大量组件挤在很少的行数里，静态检查又对复杂度报警。格式化、拆文件可以让代码更易读或让检查通过，却没有自动回答“这个系统为什么这样工作”。他讨论的不是是否还要亲手敲每一行代码，而是出了故障时，开发者靠什么决定下一步去哪里找。
作者提出保留基础知识和较宽的系统视野，再在问题出现时深入局部。自己写 Agent 编排器时，他曾被进程生命周期与崩溃恢复困扰；对 Kubernetes 工作方式的已有认识，帮助他换用持续比较实际状态与目标状态的思路。AI 能补实现细节，知道可以换一种组织方式仍来自人的知识地图。
讨论区补出了两种有价值的不同意见。有人认为 AI 也能按需解释系统，让人不必预先记住所有细节；另有人提醒，阅读时的不安未必等于产品真的变差，应看用户受损、事故和故障恢复。原文的经验因此更适合用来讨论“怎样维持能追问的理解”，而非证明所有 AI 代码都不可维护。