wewr
就在昨天，大神Andrej Karpathy在X上发了一篇长帖，记录了自己最近几周用Claude 写代码时的一些零碎想法。
他表示，自己遭遇了20年来编程生涯中的最大改变，而且这个转变只用了几个星期！
这篇帖子一出来，立刻引发了大量网友点赞转发。有网友在底下评论：“被AI伤了自尊心”这句话最能引发共鸣。
CC之父Boris Cherny也很快闻风而来，特意写了一条长评论表示：我们几乎 100%的代码都是由 Claude Code + Opus 4.5 编写的。马斯克则感慨：Karpathy的帖子总结了时代精神。
Kapathy表示，他的编程方式在 2025 年 11 月到 12 月之间发生了剧烈变化。
11 月的时候，大概 80% 还是手写代码加自动补全，只有 20% 用 Agent。到了 12 月，这个比例彻底反过来了，80% 靠 Agent 编程，自己只做 20% 的修改和润色。
他坦言：现在自己主要用英语编程。虽然有点羞愧，但在更大尺度的“代码动作”上操作软件的能力，整体收益实在太高了——尤其是在你逐渐适应它、配置好它、学会如何使用它，并真正理解它能做什么、不能做什么之后。
Karpathy之前还发了一条X帖子调侃：“最热门的新编程语言是英语。”看来和现在这番感慨不无关系。
他估计，类似的变化正在发生在“两位数百分比”的工程师身上，但大众对这件事的认知可能还停留在“个位数百分比”。
但是，关于不再需要 IDE 和 Agent 集群的炒作，Karpathy 认为现在还言之过早。
在他看来，模型虽然强，但依然会犯错。只要是在编写任何真正重要、需要长期维护的代码，就必须对 agent 保持高度警惕。最理想的方式，是在一旁打开一个清晰、完整的 IDE，一直盯着生成结果。
Karpathy指出，错误的类型已经发生了显著变化：今天的问题不再是低级的语法错误，而是更隐蔽、更危险的概念性错误。
比如，模型会在未经确认的情况下，自行替人类做出假设，并在这些假设之上一路推进。与此同时，模型在“管理自身不确定性”方面仍然明显不足，包括：
不主动请求澄清
不主动暴露潜在的不一致
不呈现不同方案之间的权衡
在应该提出质疑或反对时保持沉默
表现出一定程度的过度迎合
在启用 plan mode 的情况下，这些问题会有所缓解，但 Karpathy 认为，当前仍然缺少一种轻量级、可内联的规划模式，能够在不中断工作流的前提下发挥作用。
他还指出，模型非常容易把代码和 API 设计得过于复杂，具体表现为：
抽象层级不断膨胀
死代码得不到清理
系统结构臃肿、脆弱
一个典型场景是：模型会先实现一个低效、冗长、易碎的 1000 行方案，而当人类提示“其实可以更简单”时，它又能立刻将实现压缩到 100 行，并且承认这是更合理的解法。
有时候，模型还会顺手改掉或删掉一些它们不喜欢或不理解的注释和代码，即使这些跟当前任务毫无关系。而且这些问题在 CLAUDE.md 里写了明确的指令要求也解决不了。
但即便如此，Karpathy认为整体上还是巨大的改进，很难想象再回到手写代码的时代。
现在他的工作流是这样的：左边开几个Ghostty 窗口放着 Claude Code 会话，右边开着 IDE 看代码和做手动编辑。
此外，Karpathy还分享了几个他与Agent协作的直观感受：
1、不知疲倦的韧性
Karpathy认为，看着 Agent 不知疲倦地工作，是一件很有意思的事。
它们从不累，从不泄气，就是一直尝试。换做人类，早就放弃改天再战了。但 Agent 可以挣扎 30 分钟，最后还是把问题解决了。
这是一种感受 AGI 的时刻。你会意识到，耐力是工作的核心瓶颈之一，而有了 LLM，这个瓶颈被大大突破了。
2、速度提升
LLM 辅助编程的加速效果如何？这个问题其实很难衡量。
Karpathy 说，他确实感觉做事快了很多，但更重要的是他能做远比原计划更多的事情：
可以实现很多以前“完全不值得写”的东西
可以开始接触以前因为知识或技能不足而无法碰的代码
这不仅仅是加速，更像是一种能力的扩展。
3、杠杆效应
LLM 在持续循环、直到满足明确目标这件事上异常强大，这也是大多数“AGI 体感”的来源。
Karpathy表示，不要告诉Agent怎么做，告诉它成功标准是什么，然后看它自己跑。具体做法包括：让它先写测试，再通过测试；把它和浏览器 MCP 放在同一个循环里；先写一个很可能正确但很朴素的算法，再让它在保持正确性的前提下优化；把你的方法从命令式转为声明式，可以让 Agent 循环得更久、杠杆更大。
4、有趣
Karpathy 直言：他没想到 Agent 编程会让编程变得更有趣。
因为大量填空式的苦力活被移除了，剩下的是创造性的部分。他感觉更少被卡住了，也更有勇气了，因为几乎总能找到一种方式跟 AI 协作推进。
不过他也提到，有些人可能会有相反的感受。AI 编程可能会让工程师分化成两类，一类是喜欢编程本身的，一类是喜欢构建的。
5、能力退化
另外，Karpathy也敲了个警钟：他觉得自己手写代码的能力在日益退化。
生成代码和判别代码是大脑里两种不同的能力。这主要是因为编程涉及大量语法细节，即使写起来费劲，读代码还是没问题的。
最后，Karpathy忧心忡忡地表述了他眼中的2026：Slopacolypse（垃圾内容末日）。
我已经在为 2026 年做心理准备——那将是 GitHub、Substack、arXiv、X / Instagram，以及几乎所有数字媒体的 “垃圾内容末日年”。
与此同时，我们也会看到大量 AI 炒作式的“生产力表演”（这居然还能再多？），以及真正、实质性的改进并存。
他还提出了几个一直盘旋在脑海中的疑问：
“10X 工程师”会发生什么变化？平均工程师和顶尖工程师之间的生产力差距，是否会显著扩大？
在 LLM 的加持下，通才是否会越来越压过专才？LLM 在“补细节”上远强于宏观战略。
未来的 LLM 编码体验会像什么？是玩《星际争霸》？玩《Factorio》？还是演奏音乐？
社会中到底有多少瓶颈，来自于数字化知识工作？
CC之父：几乎100%代码由Claude Code + Opus 4.5 编写
在Karpathy的帖子发出后不久，最近一直热衷于在X上“冲浪”的 CC之父Boris Cherny 也很快闻风而来，认真地写了一条长评论。
Boris表示，自己从头到尾看完了Karpathy的帖子，认为这是一个“非常有思考深度、论证充分的观点”。
他指出，Claude Code 团队本身，可能就是一个很好的“未来走向指示器”。对于 Karpathy 最后提出的几个问题，他们已经有了“方向性答案”。
首先，在招聘上，Claude Code 团队以通才为主。
Boris表示，“10X工程师”确实存在，而且他们往往横跨多个领域——比如：
产品 + 设计
产品 + 商业
产品 + 基础设施
Boris 还点名 Jarred Sumner 就是“产品 + 基础设施”的一个很好的例子。
Jarred Sumner是 Bun 的创建者，Bun 是以Zig语言编写的一套JavaScript运行时系统、包管理器、测试运行器及打包工具。
目前，Jarred Sumner 在 Anthropic 负责 Bun 和 Claude Code。
接着，Boris还自曝了一件惊人的事情：目前Claude Code团队几乎100% 的代码，都是由 Claude Code + Opus 4.5 写出来的。
Boris直言：就他个人而言，这个比例已经持续两个月以上了，他甚至连小的手动修改都不做。
他认为，接下来的几个月里，行业整体都会看到类似的比例——只是有些团队快一些，有些慢一些。再往后，非编程类的计算机工作中也会看到类似的数据。
另外，Boris也肯定了Karpathy提到的AI Coding问题，都是真实存在的：
模型会把事情搞复杂
会留下死代码
在该重构的时候不太愿意重构
但他表示，这些问题会随着模型能力的提升而持续改善；同时，他们对代码质量的要求也会随之进一步提高。
Boris个人的判断是：不会出现所谓的Slopocalypse（垃圾代码末日）。原因在于：模型会越来越擅长写出不那么“糟糕”的代码，也会越来越擅长修复已有代码中的问题。他认为Opus 4.5在这方面已经相当不错了，而且只会继续变好。
他还提供了一个建议：用一个全新的上下文窗口，让模型对自己写的代码做 code review。
Boris的评论很快也引来了一大波网友。
有网友继续向Boris追问细节，当代码质量有问题的时候，0手工编辑是如何做到的。
Boris表示，他们会把它作为代码审查的一部分。
也有网友询问，如何在PR上使用Claude -p。Boris贴心地甩了个github链接，并表示他们会交替使用 -p 和 ts/python 的 sdk。
还有网友感慨：最优秀的人工智能工程团队选择了通才，这应该让专家感到害怕。
毕竟一位是前特斯拉AI总监、OpenAI联合创始人，另一位是Claude Code的创造者，如果连他们都有了如此紧迫的危机感，那说明模型编程能力的进化速度可能比我们想象的还要快。
Karpathy 提到， Claude 和 Codex 在 2025 年 12 月左右跨过了某种“一致性 / 连贯性门槛”，让这种以 Agent 为主的写法突然变得可行，并且很难再回到完全手写的状态。
他预计，2026 年将是一个高能量之年——整个行业都在努力消化、吸收这一全新的能力。
那么，评论区的各位大佬，
你对Karpathy和Boris的发言怎么看呢？
你觉得2026年的AI Coding将进化到什么水平？
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
；
