"人机协同"模式已显疲态：AI 辅助编程正在消耗开发者的认知与满足感

又是一篇关于大型语言模型（LLM）的思考文章。我知道。请耐心看完。

这是一次尝试，把我认为大多数开发者现在都在经历但还没来得及理清的感受用语言表达出来。使用LLM进行编程确实有用，同时也会让人感到不稳定。这两件事是共存的。如果我们假装后者不存在，我们都会精疲力竭。

在Pydantic：https://pydantic.dev，我们构建供开发者使用的工具，用于验证数据：https://pydantic.dev/docs/validation/latest/get-started/、构建AI代理：https://pydantic.dev/pydantic-ai，以及监控他们的系统在生产环境中的表现：https://pydantic.dev/logfire。我们实际上是在让基于LLM的软件更可靠的业务中工作。同时，我们也在经历一段奇怪的时期。

这并不是一篇讨论AI是否会取代程序员的文章。这既不是悲观的文章，也不是炒作文章。这是从内部开发者视角出发，对当前开发者的真实感受的记录，以及一些可能实际有帮助的思考。

当我二十出头时第一次学习编程，我记得有这样一种独特的感觉：编程让我能够将双手伸入宇宙的结构，并按照自己的意愿塑造它。当然，这还是在我还没有遇到太多编译错误的时候。但这种触碰到某种深层抽象层的感觉，以及仅凭逻辑就能创造事物的能力，一直伴随着我。

我不是计算机科学专业毕业的。我是一名设计师和程序员——前者是正规培训的，后者是自学的。我是通过痛苦的经验而非学术教育进入软件工程的形式主义领域的。如果说这有什么影响，那就是一旦理解了这些原则，我会更加认真地对待它们。当你通过艰难的方式获得对架构和代码质量的见解时，它们感觉不再像课本上的规则，而更像是疤痕组织。

那种原始的创造感？这正是2010年代低代码和无代码工具一直承诺却从未真正实现的。我年纪够大，还记得在Dreamweaver里做网页，看Adobe宣传零代码设计工具，而这些工具在底层生成的完全是杂乱无章的代码。它总是差一点，好像触手可及，只够让人对即将到来的未来有所预感（如果你足够聪明去理解它的话）。

如果你对当前一波AI工具持怀疑态度，我理解。我们以前也被承诺过这样的事情。但这一次，承诺与现实之间的差距确实，终于，缩小到了有意义的程度。正因为如此，这种感觉才如此令人不安。

是的，代码（某种程度上）可以自动生成，但人的审查、指导和纠正感觉反而更糟，而不是更好。

我最近和我的同事Douwe交谈过：https://github.com/DouweM，他维护Pydantic AI框架，是我所认识的关于将LLM整合到开源工作流中最有思想的人之一。他描述了每天早晨醒来都有三十个PR，每一个都是过夜由某人的AI提交的，并且需要对每一个做出快速判断。把审查任务交给AI的诱惑非常大。但正如他所说：“在那一刻，我还在这里做什么呢？”。

坦诚地说，在过去几个月里，有的日子我几乎花了整整两天时间为一个LLM写执行计划：执着地澄清、指定、重新指定，却仍让它做出一些莫名其妙的愚蠢操作。比如，把一个React hook移植到Storybook故事文件中；从错误的计划读取信息；发明不存在的组件。这些不是能力上的错误，而是连贯性上的错误。模型足够聪明，可以生成看似合理的代码，但并不总是足够聪明，无法在复杂的变更中保持连贯的意图。

这会产生一种奇特的新型疲劳——监督疲劳：在机器生成大量大部分正确的输出时，你必须将意图保持在脑中，同时仍然需要你的眼睛、判断力和品味。Douwe 说得很好：他过去会从与真实人在开源项目中一起合作某个酷功能时获得多巴胺的快感。帮助别人提升他们的技能。现在，他说，“我写的所有东西都会进入某个 AI 黑洞。对面没有人在实际学到任何东西。”这种失落是真实存在的，也值得被命名。

Simon Willison：https://simonwillison.net/2026/Feb/9/ai-intensifies-work/ 最近指出了一项伯克利哈斯：https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it 研究，该研究描述了 AI 使用如何增加工作的强度。“一天结束时再来一个提示，再添加一个可能让它完美的功能”的持续拉扯。我深有体会。我最近几乎熬到凌晨两点，还在提示，因为我离把计划做对已经非常近了。或者我以为是这样。

Marcelo：https://github.com/kludex，另一位 Pydantic 同事，当被问及他的 Claude Code 会话冻结时说：“只要打开五个 Claude 会话。你永远不会注意到，因为你正忙着给其他会话反馈。” 他在开玩笑。我想。但这捕捉到了当前时刻的某种真实情况。并行处理令人振奋，也有些野性。你可以开始的事情数量显著增加。但你能认真完成的事情数量几乎没有变化，因为那部分仍需依赖我们无法并行化的资源：你的大脑。

这里有一个术语可以描述我认为正在发生的事情：人类奖励函数问题。在机器学习中，奖励函数告诉代理什么是好的。手工写代码从来都不容易，但充满了小小的奖励。在脑中解决一个问题。理解一段复杂的逻辑。观看代码编译。控制感。基于 LLM 的编程已经自动化了产生这些多巴胺快感的大部分工作，并以复审与监督的认知负荷取而代之。令人满意的部分减小了，而令人疲惫的部分增加了。而且没有新的奖励来弥补这个空缺。

如果你觉得你的工作在同时更高效但又不那么令人满足，你并没有出问题。反馈循环出了问题。我认为我们需要开始把这个问题当作一个独立的工程问题来处理，而不是个人失败。

坦率地说，这也相当孤独。使用大型语言模型编程是一种极度孤立的活动。

你和机器不断往复，精炼、提示和审查。那些你本来会转向同事提问、讨论问题、分享最后终于理解某个问题的小胜利的自然时刻，这些瞬间 quietly 被另一个提示取代。在没有强大的现有合作文化的团队中，这往往会进一步疏远人们，在你最需要确认其他人也觉得困难的时候，反而冷却了交流。

而且，这种方式具有上瘾性，使孤立感更强。有时你会得到一些出色的东西，有时是垃圾，而且你永远无法确定哪种。教科书式操作斯金纳箱：https://en.wikipedia.org/wiki/Operant_conditioning_chamber。确实很难后退一步，记住你是可以只是……写代码的。但在大型语言模型辅助和手动工作之间切换会令人震惊和不适，这两种思维模式非常不同，而要允许自己切换需要一种成熟和自信。

这一时刻让我想起响应式设计带来的恐惧和焦虑。当时我是一名设计师兼前端开发，每个人都在跟随 Ethan Marcotte：https://alistapart.com/article/responsive-web-design/ 和 Zeldman：https://zeldman.com/2024/12/05/of-books-and-conferences-past/ / A Book Apart：https://ethanmarcotte.com/books/responsive-web-design/ 的人群，我记得被告知我们都已经掌握的固定宽度布局基本上结束了，那种感觉有多不安定。

对于年轻的开发者来说：在2009年前后，网站从固定的、像杂志一样的像素完美布局转向流动的、响应式布局，这是一个真正的文化时刻。设计师们非常讨厌这种变化。对于那些建立整个身份于精确布局和完美网格的人来说，失去控制感是生死攸关的。你是说用户可能在任何宽度下看到我的设计？在任何设备上看到？我精心制作的布局会…流动？

图片设计：Jyotika Sofia Lindqvist：https://www.behance.net/jyotikasofia

抵制的情绪非常强烈，这也能理解。人们在一个正在被根本颠覆的范式中建立了真正的专业技能。那些在转型中茁壮成长的设计师，是那些重新定义自己技能的人。对比例的敏感仍然重要。对层次结构的理解仍然重要。工艺没有消失，而是进化了。不再那么相关的是对像素级控制的痴迷。变得更加相关的是理解系统、适应能力以及为不确定性进行设计的能力。

我不想过度强调这种类比。响应式设计是几年积累的变化。当前的转型是以几个月计量的。在响应式转型期间，机构失去了客户，设计师失去了工作，但它没有带来同样的生死恐惧。利害关系实质上不同，而且进度确实以一种令人疲惫的方式推进，这是响应式转型从未出现的。但其底层模式——工艺在进化而非消亡，核心技能变得越发重要而非不再重要——我认为是成立的。

在代码上与大型语言模型（LLM）协作感觉像一个类似的拐点。技能并未消失，而是在转变。你并不会因为不是手写每一行代码而变得不称职。但你仍然需要知道优秀是什么样的，可以说比以往任何时候都更重要，因为你现在是大量产出的质量关卡。

在任何人都可以生成看起来不错的界面和可编译代码的时代，区别性标志变成了：品味、细微差别、成熟的架构观点，以及源自真正专业知识而非模式匹配的逆向判断。

我注意到，我们在指导大语言模型（LLM）时最成功的领域，往往是那些我们对代码、决策和权衡有最深理解的领域。当我们进入技能较浅的领域时，输出明显变得更具印象派风格，更远离可投入生产的水平。看起来更合理，但实际上正确性较低。模型不知道自己不知道的东西，所以它会自信地填补空白。听起来熟悉吗？这也是一种非常典型的人类失败模式。

但新的技能也在不断出现。我开始对复杂计划进行我称之为“预复盘”的操作：让一个新的 LLM 会话假设该计划已经彻底失败，并分析原因。它能发现我在深陷细节两天后仍未发现的规格漏洞。我们的一位工程师开发了一个工具，从他过去数千条代码审查评论中提取规则，用于生成 AGENTS.md 文件，本质上是将多年的隐性工程判断编码成 LLM 可以遵循的指令。这不是专业知识的消亡，而是一种专业知识的提炼。

那些目前正站稳脚跟的人似乎有一些共同特征：他们通过实践获得了强烈的见解，他们能够区分仍然适用的原则和仅因为资源限制而形成的习惯，并且他们愿意在不放弃标准的前提下调整工作流程。

我不认为目前的人工智能浪潮意味着软件工程作为职业的终结。但我确实认为，这意味着工作量的严重收缩以及工作的本质被根本性地重塑。对被淘汰的担忧是合理的。对技能退化的担忧是合理的。而担心如果行动不够快会被落下 —— 虽然经常被夸大 —— 也并非完全没有根据。

但瓶颈从来不是代码。瓶颈一直是人类的注意力、工程判断和保持系统一致愿景的能力。我们之所以没注意到，是因为写代码感觉才是最难的部分。现在代码被自动化，这些人类能力才显露为真正稀缺的资源。而稀缺资源本身是有价值的。

所以，如果你感到不知所措、不稳定，同时变得更高效但不那么快乐，请知道你并不孤单。正在构建你可能用来应对这一刻的工具的团队，也有同样的感受。我们正在实时调试我们的奖励函数，就像你一样。

代码在变化。我们如何使用它也在变化。它的感觉是……仍在改进中。

但人类仍然在循环中。我们只是累了。而这值得讨论。

我们正在构建工具以减少这种混乱：Pydantic AI：https://pydantic.dev/docs/ai/overview/ 和 Logfire：https://logfire.pydantic.dev。我们也在招聘：https://pydantic.dev/jobs。

Yet another thought piece about LLMs. I know. Bear with me.

This is an attempt to put words around something I think most developers are experiencing right now but haven't had time to make sense of. Programming with LLMs is genuinely useful and genuinely destabilizing. These two things coexist. If we pretend the second one isn't happening, we will all burn out.

At Pydantic：https://pydantic.dev, we build tools that developers use to validate data：https://pydantic.dev/docs/validation/latest/get-started/, build AI agents：https://pydantic.dev/pydantic-ai, and observe what their systems are doing：https://pydantic.dev/logfire in production. We are, quite literally, in the business of making LLM-powered software more reliable. And we are also having a weird time.

This isn't a thinkpiece about whether AI will replace programmers. It's not a doomer essay and it's not a hype piece. It's an honest account of what it feels like to be a developer right now, from someone inside it, and some thoughts on what might actually help.

When I was first learning to code in my early twenties, I remember having this distinct sensation that programming let me dip my hands into the fabric of the universe and shape it to my will. This was, of course, before I'd hit too many compile errors. But that feeling of touching some deep fundamental layer of abstraction, of being able to make things from nothing but logic, has always stuck with me.

I'm not a Computer Science graduate. I'm a designer and a programmer — formally trained in the first, self-taught in the second. I came to the formalisms of software engineering through painful experience rather than academic instruction. If anything, that made me take those principles more seriously once I understood them. When you've earned your opinions about architecture and code quality the hard way, they feel less like textbook rules and more like scar tissue.

That primal feeling of creation? It's the same promise that the low-code and no-code tools of the 2010s kept making but never quite delivered on. I'm old enough to remember building web pages in Dreamweaver, watching Adobe spruik zero-code design tools that generated absolute spaghetti under the hood. It was always almost there, just good enough to hint at a future that was just around the corner (if only you were smart enough to grasp it).

If you're cynical about the current wave of AI tools, I get it. We've been promised this before. But this time the gap between promise and reality has actually, finally, narrowed to something meaningful. And that's exactly what makes it so unsettling.

Yes the code (sorta) writes itself, but the human reviewing, directing, and course-correcting feels worse, not better.

I recently had a conversation with my colleague Douwe：https://github.com/DouweM, who maintains the Pydantic AI framework and has been one of the most thoughtful people I know about integrating LLMs into open source workflows. He described waking up to thirty PRs every morning, each one pulled overnight by someone's AI, and needing to make snap judgment calls on every single one. The temptation to delegate the review itself to an AI was enormous. But, as he put it: "at that point, what am I still doing here?" .

The honest truth is that in the last few months, there have been days when I have spent close to two full days writing a plan for an LLM to execute: obsessively clarifying, specifying, re-specifying, only to have it still do something inexplicably stupid. Port a React hook into a Storybook story file. Read from the wrong plan. Invent components that don't exist. And these aren't errors of capability; they're errors of coherence. The models are smart enough to produce plausible code, but not always smart enough to maintain a coherent intent across a complex change.

This creates a peculiar new kind of fatigue, the fatigue of supervision : of holding the intent in your head while the machine generates volumes of mostly-correct output that still needs your eyes, your judgment, and your taste. Douwe put it well: he used to get a dopamine hit from collaborating with a real person on a cool feature in open source. Helping someone become better at their craft. Now, he said, "everything I write goes into some AI black hole. There's no person on the other side actually learning anything." That loss is real and it's worth naming.

Simon Willison：https://simonwillison.net/2026/Feb/9/ai-intensifies-work/ recently highlighted a Berkeley Haas：https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it study which describes how AI usage increases the intensity of work. The constant pull of "one more prompt at the end of the day, one more feature that could make this perfect." I felt that one in my bones. I was up until nearly 2am recently, prompting, because I was so close to getting a plan right. Or so I thought.

Marcelo：https://github.com/kludex, another Pydantic colleague, when asked about his Claude Code session freezing said: "just open 5 claude sessions. You'll never notice because you're busy giving feedback to the others." He was joking. I think. But it captures something true about the current moment. The parallelism is exhilarating and kind of feral. The number of things you can start has dramatically increased. The number of things you can thoughtfully finish hasn't changed at all, because that part still requires the one resource we can't parallelise: your brain.

Here's a term for what I think is happening: the human reward function problem . In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated those dopamine hits and replaced it with the cognitive load of review and supervision. The satisfying part shrank. The exhausting part grew. And there are no new rewards to fill the gap.

If you're feeling like your work is simultaneously more productive and less satisfying, you're not broken. The feedback loop is broken. And I think we need to start treating that as an engineering problem in its own right, not a personal failure.

It's also, frankly, quite lonely. Programming with an LLM is an intensely solitary activity.

You and the machine, going back and forth, refining and prompting and reviewing. The natural moments where you'd turn to a colleague to ask a question, to rubber-duck a problem, to share the small victory of something finally clicking. Those moments get quietly replaced by another prompt. In a team without a strong existing culture of collaboration, this has a tendency to further separate people, to chill communication at precisely the moment when you most need the reassurance that other humans are finding this hard too.

And it's addictive in a way that makes the isolation worse. Sometimes you get something brilliant, sometimes garbage, and you never quite know which. Textbook Skinner Box：https://en.wikipedia.org/wiki/Operant_conditioning_chamber. It can be genuinely hard to step back and remember that you're allowed to just... write code. But switching between LLM-assisted and manual work is jarring and uncomfortable, two very different modes of thinking, and it takes a kind of maturity and confidence to give yourself permission to switch.

This moment brings to mind the fear and angst caused by responsive design. I was working as a designer and frontend developer at the time, following Ethan Marcotte：https://alistapart.com/article/responsive-web-design/ and the Zeldman：https://zeldman.com/2024/12/05/of-books-and-conferences-past/ / A Book Apart：https://ethanmarcotte.com/books/responsive-web-design/ crowd like everyone else, and I remember how unsettling it felt to be told that the fixed-width layouts we'd all mastered were basically over.

For the younger devs: there was a genuine cultural moment around 2009 when websites moved from fixed, pixel-perfect, magazine-style layouts to fluid, responsive ones. And designers hated it. The loss of control was existential for people whose entire identity was built around precise layouts and perfect grids. You're telling me the user might see my design at any width? On any device? That the layout I crafted would... flow?

Image design by Jyotika Sofia Lindqvist：https://www.behance.net/jyotikasofia

The resistance was intense. And it was understandable. People had built real expertise in a paradigm that was being fundamentally disrupted. The designers who thrived through that transition were the ones who reframed their skills. The eye for proportion still mattered. The understanding of hierarchy still mattered. The craft didn't die, it evolved. What became less relevant was the obsession with pixel-level control. What became more relevant was understanding systems, adaptability, and designing for uncertainty.

I don't want to oversell this parallel. Responsive design played out over years. The current shift is measured in months. Agencies lost clients and designers lost gigs over the responsive transition, but it didn't carry the same existential dread. The stakes are materially different, and the pace is genuinely exhausting in a way that the responsive transition never was. But the underlying pattern, of craft evolving rather than dying, of the core skills mattering more not less, I think that holds.

Working with LLMs on code feels like a similar inflection point. The skill isn't gone, it's shifting. You're not less of an engineer because you didn't hand-write every line. But you do still need to know what good looks like, arguably more than ever, because you're now the quality gate for a much higher volume of output.

In an era when anyone can produce reasonable-looking UI and code that compiles, the distinguishing markers become: taste, nuance, mature architectural opinions, and the contrarian calls that come from genuine expertise rather than pattern-matching.

It's noticeable to me that we are most successful guiding LLMs in the domains where we understand the code, the decisions, and the trade-offs most deeply. As we venture into the shallow ends of our skill sets, the outputs become markedly more impressionistic . Further from production-ready. More plausible-looking, less actually correct. The model doesn't know what it doesn't know, so it fills the gaps with confidence. Sound familiar? It's a very human failure mode, too.

But new skills are also emerging. I've started running what I call pre-mortems on complex plans: asking a fresh LLM session to assume the plan has catastrophically failed and diagnose why. It catches specification gaps that I miss after two days of being too deep in the details. One of our engineers built a tool that extracts rules from thousands of his past code review comments to seed an AGENTS.md file, essentially encoding years of implicit engineering judgment into instructions an LLM can follow. That's not the death of expertise. That's expertise being distilled .

The people who are finding their footing right now seem to share a few traits: they have strong opinions earned through practice, they can distinguish between principles that still apply and habits that were just bandwidth constraints, and they're willing to evolve their workflow without abandoning their standards.

I don't think the current wave of AI represents the end of software engineering as a profession. I do think it represents a serious contraction and a fundamental reshaping of what the work is . The fear of obsolescence is legitimate. The fear of skill rot is legitimate. And the fear that if you don't go fast enough you'll be left behind is — while often overstated — not entirely unfounded.

But the bottleneck was never the code. It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. We just didn't notice because writing code felt like the hard part. Now that it's being automated, those human capacities are revealed as the actual scarce resource. And scarce resources are valuable.

So if you're feeling overwhelmed, destabilized, simultaneously more productive and less happy, know that you're not alone. The team building the tools you're probably using to navigate this moment is feeling it too. We're debugging our reward functions in real time, same as you.

The code is changing. What we do with it is changing. How it feels is... a work in progress.

But the humans are still in the loop. We're just tired. And that's worth talking about.

We're building tools to make this less chaotic: Pydantic AI：https://pydantic.dev/docs/ai/overview/ and Logfire：https://logfire.pydantic.dev. We're also hiring：https://pydantic.dev/jobs.