# Don't Outsource the Learning
**作者**: Addy Osmani
**日期**: 2026-05-17T18:23:19.000Z
**来源**: [https://x.com/addyosmani/status/2056078124346228860](https://x.com/addyosmani/status/2056078124346228860)
---
Right now, it's too easy to let AI write the code while you skip the learning. The bug gets fixed but your mental model doesn't move. It might get worse over time. We are silently trading future capability for present-day speed, and the tools won't force us to do otherwise. That part has to come from you.
There's a default loop most of us have settled into. You paste in a spec or error message. The model hands you a fix and the symptom vanishes. You ship. Somewhere in that loop, the messy struggle between problem and solution stops happening at all.
I've written before about cognitive surrender, the moment an AI reviewer's verdict quietly replaces your own. This is the solo version of that same loop. It's just you and the model. The model is faster, so you stop trying to compete on comprehension. Across thousands of these small interactions, what you can actually build without an AI looking over your shoulder gets a little weaker every week. None of these moments feel like a problem on the day they happen.
I'm not anti-AI. I use these tools daily and have shipped more with them in the last year than in the years before it. But the default way we use them is optimized for one thing: closing tasks.
That is a completely different goal from staying sharp enough to steer them over a career that spans a long time.
## The studies are converging on the same point
Several pieces of research over the last year have landed in roughly the same place.
Anthropic ran a randomized trial in early 2026 where engineers learned a new Python library, half with AI assistance and half without. Both groups finished the tasks at the same speed. But the AI group bombed the follow-up comprehension quiz: 50% versus 67% for the manual group, with the gap widening on debugging. The interesting cut was inside the AI group itself. Engineers who used AI to ask conceptual questions scored above 65%. Engineers who copy-pasted the generated code scored under 40%. The tool didn't determine the outcome. The posture did.
MIT's Your Brain on ChatGPT study compared essay writing across LLM, search-engine, and brain-only groups. EEG measurements showed brain connectivity scaling down with every layer of external support. The LLM group showed the weakest coupling. After writing the essay, 83% of LLM users couldn't quote a single line of what they had just produced. The researchers called this cognitive debt: saving mental effort today, paying for it in critical thinking tomorrow.
A CHI 2026 study added a related finding. When people had LLM access at the start of a task, the LLM framed the entire problem. Even when the human did the rest of the work themselves, that initial anchoring produced measurably worse decisions. The order of operations mattered more than the total amount of AI used.
Different methodologies reaching the same conclusion. Using AI without an active intent to learn quietly degrades the skill you're being paid for.
## The tools default to shipping, not teaching
If you fire up a coding agent and stick to the defaults, everything is tuned for one metric: getting the task done.
The model writes the code. You accept it. The loop repeats. At no point does the tool pause and ask "what do you think the problem is?" or "try writing the first five lines yourself."
That's where UX gravity is right now. Product teams get rewarded for merged changes and shorter cycle times, not for making you a sharper engineer. We all want fewer keystrokes, so the tools have sanded the friction away. The trouble is that friction was where the learning lived.
A few companies have tried pushing back on these loops not encouraging us to really learn.
Anthropic shipped Learning Mode for Claude, which uses Socratic questioning and stops to ask you to write code before continuing. OpenAI and Google have shipped similar features. Almost nobody uses them for real production work though if we're being real. We've quietly filed them under "for students" and that's a mistake. The same feature that helps a sophomore learn React works for a senior engineer learning Rust. You just have to be willing to feel like a beginner again.
## "If the AI can do it, why do I need to understand it?"
A fair question. For some work, the answer is: maybe...you don't? If it's boilerplate, glue code, or a throwaway CI script you'll never look at again, delegate it. The opportunity cost of memorizing some syntax is too high.
For real software, pure delegation breaks down in a few specific places.
When something breaks. AI-generated code crashes the same way human code does. "The agent wrote it" doesn't help you debug problems. Somebody on the team has to understand the architecture.
When it's confidently wrong. LLMs can still hallucinate. The only defense against a plausible-looking incorrect answer is enough expertise to spot it. Bandaids like skills, CLIs etc only get you so far.
When the foundation changes. Code is temporary; systems are permanent. When frameworks update or a security review flags a structural issue, you can't re-prompt your way out. You need engineers who understand the system well enough to migrate it.
When you leave the median. AI is brilliant at problems that have been solved a million times on GitHub. The further you stray from the median, the worse it gets. The hard, undocumented problems, the ones that justify a senior engineer's salary, still require deep understanding.
When the market adjusts. Engineers who can only ship with AI, and not without it, are entering a labor pool that is already re-pricing what expertise is worth. If you use AI to skip learning, you're trading future relevance for a slightly easier Tuesday.
## The fix is in how you prompt
The good news is that the same tools that produce cognitive debt can produce sharper engineers. The difference is in what you ask of them.
Form a hypothesis before you ask. Before requesting a fix, write down two or three sentences on what you think the problem is. Use the model's answer to test your theory, not to replace it.
Ask for the explanation before the code. In unfamiliar territory, your first prompt should be something like "explain how this works, what the alternatives are, and what the tradeoffs are." Ask for the code only after you've grasped the concepts.
Turn on Learning Mode when you're out of your depth. Yes, it feels slower. That's the point.
Treat AI output like a PR from a junior engineer. Read it. Critique it. Push back on it. Would you merge it just because the tests passed? If not, don't merge it here either.
Re-derive things by hand once in a while. Take a piece of code the model wrote for you and try to recreate it from scratch. It's the calibration check that tells you how much you've quietly lost.
Ask the model to teach you what it just did. After it writes a clever function, ask what concepts it used and what you'd need to read to understand the design choice. One extra prompt changes what you take away from the session.
None of these are dramatic. They're small posture shifts inside the same tools you're already using.
## Two metrics, not one
I've started ending coding sessions with a simple question: did I learn anything today, or did I just close issues?
Sometimes the honest answer is "I just closed issues" and that's fine. If it becomes the answer for months in a row, cognitive debt is accumulating in the background.
Ship and learn are two separate metrics. Your manager and your customers will only ever ask about the first one. The second is on you.
I'd rather ship 80% of what I could have and learn 100% of what I needed to, than the reverse. Over years, those two strategies produce very different engineers.
You don't have to choose between using AI and learning. You do have to choose a workflow that does both, because the defaults won't choose it for you. The tools are ready whenever you are.
The next boring task you were about to delegate is a good place to start.
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [94K](https://x.com/addyosmani/status/2056078124346228860/analytics)
- [cognitive surrender](https://addyosmani.com/blog/cognitive-surrender/)
- [randomized trial in early 2026](https://www.anthropic.com/research/AI-assistance-coding-skills)
- [Your Brain on ChatGPT](https://www.media.mit.edu/publications/your-brain-on-chatgpt/)
- [CHI 2026 study](https://arxiv.org/html/2603.08849v1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:23 AM · May 18, 2026](https://x.com/addyosmani/status/2056078124346228860)
- [94.5K Views](https://x.com/addyosmani/status/2056078124346228860/analytics)
- [View quotes](https://x.com/addyosmani/status/2056078124346228860/quotes)
---
*导出时间: 2026/5/18 09:29:43*
---
## 中文翻译
# 不要外包你的学习
**作者**: Addy Osmani
**日期**: 2026-05-17T18:23:19.000Z
**来源**: [https://x.com/addyosmani/status/2056078124346228860](https://x.com/addyosmani/status/2056078124346228860)
---
现在，让 AI 写代码而自己跳过学习过程实在是太容易了。Bug 修好了，但你的心智模型并没有升级。甚至可能随时间推移而退化。我们正在悄无声息地用未来的能力换取当下的速度，而工具不会强迫我们改变这一点。这必须取决于你自己。
我们大多数人都陷入了一个默认的循环。你粘贴进一个规范或错误信息。模型给你一个修复方案，症状消失了。你发布产品。在这个循环中的某个环节，问题与解决方案之间那种混乱的挣扎彻底停止了。
我以前写过关于“认知投降”的文章，即 AI 审查者的结论悄然取代了你自己的判断。这是同一种循环的独奏版本。只有你和模型。模型更快，所以你停止了在理解力上与之竞争。在成千上万次这样的微小互动中，你离开 AI 后真正能构建的东西每周都在变弱。这些时刻在当时发生时，没有一个感觉像是问题。
我并不反 AI。我每天都使用这些工具，过去一年里借助它们交付的成果比以往几年加起来还多。但我们使用它们的默认方式只为一件事做了优化：完成任务。
这与保持足够的敏锐度从而在漫长的职业生涯中驾驭它们，是完全不同的目标。
## 研究正趋于同一点
过去一年里的几项研究得出了大致相同的结论。
Anthropic 在 2026 年初进行了一项随机试验，让工程师学习一个新的 Python 库，一半人使用 AI 辅助，一半人没有。两组完成任务的速度相同。但 AI 组在随后的理解测验中惨败：得分为 50%，而手动组为 67%，且在调试方面的差距更大。有趣的切入点在于 AI 组内部。使用 AI 提出概念性问题的工程师得分超过 65%。而复制粘贴生成代码的工程师得分低于 40%。决定结果的不是工具，而是姿态。
MIT 的《你的大脑面对 ChatGPT》研究比较了 LLM（大型语言模型）、搜索引擎和仅靠大脑三组写论文的情况。脑电图（EEG）测量显示，随着外部支持层级的增加，大脑连通性逐级下降。LLM 组表现出最弱的耦合。写完论文后，83% 的 LLM 用户引用不出自己刚刚写下的任何一行字。研究人员称之为认知债务：今天节省脑力，明天在批判性思维上偿还。
CHI 2026 的一项研究补充了一个相关发现。当人们在任务开始时就能使用 LLM，LLM 就会框定整个问题。即使剩下的工作都是人类自己完成的，这种初始锚定也会导致明显更差的决策。操作顺序比 AI 使用的总量更重要。
不同的方法论得出了相同的结论。在没有主动学习意图的情况下使用 AI，会悄悄降低你赖以生存的技能。
## 工具的默认设置是交付，而非教学
如果你启动一个编码代理并坚持使用默认设置，一切都会围绕一个指标进行调整：完成任务。
模型编写代码。你接受它。循环重复。工具绝不会停下来问你“你认为问题出在哪里？”或“试着先自己写前五行”。
这就是目前用户体验的重力所在。产品团队因代码合并和缩短周期时间而获得奖励，而不是因为让你成为更敏锐的工程师。我们都想要更少的击键次数，所以工具已经磨平了所有的摩擦。问题在于，学习正是存在于那些摩擦之中。
有几家公司试图反击这些循环，不再鼓励我们真正学习。
Anthropic 为 Claude 推出了“学习模式”，它利用苏格拉底式提问，并在继续之前停下来让你编写代码。OpenAI 和 Google 也推出了类似的功能。但实话实说，几乎没有人在实际生产工作中使用它们。我们悄悄地将它们归为“给学生用的”，这是一个错误。帮助大二学生学习 React 的功能同样适用于学习 Rust 的高级工程师。你只需要愿意重新感受那种初学者的感觉。
## “如果 AI 能做，为什么我还需要理解它？”
这是一个公平的问题。对于某些工作，答案是：也许……你不需要？如果是样板代码、胶水代码，或者是你永远不会再看的一次性 CI 脚本，就把它委派出去。死记某些语法的机会成本太高了。
但对于真正的软件，纯粹的委派在几个特定方面会失效。
当东西出问题时。AI 生成的代码崩溃方式和人类代码一样。“是代理写的”这一借口帮不了你调试问题。团队里必须有人理解架构。
当它自信地犯错时。LLM 仍然会产生幻觉。防范看似合理的错误答案的唯一防御，是足以发现它的专业知识。像技能插件、CLI 命令行等创可贴式的方法只能带你走到这一步。
当基础发生变化时。代码是临时的，系统是永久的。当框架更新或安全审查标记出结构性问题时，你无法通过重新提示来摆脱困境。你需要那些足够理解系统从而能对其进行迁移的工程师。
当你偏离中位数时。AI 擅长处理在 GitHub 上已被解决过数百万次的问题。你越是偏离中位数，它表现得越糟糕。那些困难的、无文档记录的问题——即证明高级工程师薪水合理的问题——仍然需要深入的理解。
当市场调整时。那些只能在 AI 辅助下交付代码，而离了 AI 就不行的工程师，正在进入一个劳动力市场，这个市场正在重新评估专业知识的价值。如果你用 AI 来跳过学习，你就是在用未来的相关性换取一个稍微轻松点的周二。
## 解决方案在于你如何提示
好消息是，同样能产生认知债务的工具，也能培养出更敏锐的工程师。区别在于你对它们的要求。
在提问之前先形成假设。在请求修复之前，先写下两三句你认为问题所在的话。利用模型的答案来测试你的理论，而不是取代它。
先要求解释，再要求代码。在不熟悉的领域，你的第一个提示词应该是类似“解释一下它是如何工作的，有哪些替代方案，以及有哪些权衡。”在掌握概念之后再索要代码。
当你感到力不从心时，开启学习模式。是的，感觉更慢。这才是重点所在。
像对待初级工程师的 PR（拉取请求）那样对待 AI 输出。阅读它。批判它。反驳它。你会仅仅因为测试通过了就合并它吗？如果不，这里也不要合并。
偶尔手动推导一下。拿一段模型为你编写的代码，尝试从头开始重建它。这是一次校准检查，能告诉你你悄悄失去了多少能力。
让模型教你它刚才做了什么。在它写了一个巧妙的函数后，问它使用了什么概念，以及你需要阅读什么资料才能理解这种设计选择。多加这一条提示词，就会改变你从这次会话中的收获。
这些都不是什么惊天动地的改变。它们只是在同样的工具中，微小的姿态转变。
## 两个指标，而不是一个
我开始在编码结束时问自己一个简单的问题：我今天学到东西了吗，还是仅仅关闭了问题？
有时诚实的回答是“我只是关闭了问题”，这没关系。但如果这成了连续几个月的答案，那就说明认知债务正在后台累积。
交付（Ship）和学习是两个独立的指标。你的经理和客户只会永远询问第一个。第二个取决于你自己。
我宁愿只交付我能交付的 80%，但学到我需要的 100%，也不愿反过来。多年以后，这两种策略会塑造出截然不同的工程师。
你不必在使用 AI 和学习之间做选择。但你必须选择一种能兼顾两者的工作流，因为默认设置不会为你做选择。工具已准备就绪，只待你出发。
你正准备委派的下一个无聊任务，就是一个很好的起点。