我们应该比模型更累。
We should be more tired than the model

原始链接: https://vickiboykis.com/2026/05/28/we-should-be-more-tired-than-the-model/

作者担忧,过度依赖智能体代码生成会导致“脑雾”和认知控制力的丧失,因为它绕过了手动编码过程中涉及的整合与记忆过程。通过自动化解决问题的流程,开发者面临失去在阅读、处理和调试代码时所获得的技能积累的风险。 为应对这一问题,作者提倡在开发工作流中“重新加入阻力”,以确保人类——而非人工智能——始终是理解过程的主导者。作者建议采取更审慎的方法,而非直接使用 AI 获取即时方案: * **手动编写初始代码**,仅将 AI 用于审核。 * **进行主动学习**,要求 AI 解释概念、对比不同方法或查阅文档。 * **实施约束**,例如在使用工具前,先尝试自行解决问题 20 分钟。 * **强化基础**,通过阅读并重新实现核心结构来巩固知识。 虽然这些方法降低了即时效率,但它们优先保障了长期的技能留存与精通。作者最终总结认为,开发者应专注于深度参与,并强调“我们应该比模型更感到疲惫”。

这次 Hacker News 的讨论探讨了在软件开发中使用大语言模型(LLM)所带来的认知负担及职业影响。核心议题在于“理解的瓶颈”:人工智能虽然提升了产出速度,但也可能导致开发者以肤浅的自动化方案取代深度的专业理解。 参与者从多个角度提出了应对思路: * **认知权衡**:开发者们指出,尽管大模型能处理繁琐任务,但向更高层次的决策及管理 AI 输出的转变,往往会增加心理疲劳。 * **方法论**:一些人建议在流程中“增加摩擦”——将 AI 作为查找文档的研究工具,而非获取代码片段的“老虎机”,以确保开发者真正理解底层的逻辑。 * **职业焦虑**:一个普遍的担忧是,AI 带来的生产力提升可能导致行业内部被迫追求更高产出,甚至引发潜在的失业问题,而非真正减轻开发者的负担。 * **对新工具的需求**:用户认为当前的“提示-响应”交互模式已不足够,呼吁开发以人为本、注重监督与抽象的代理式编程新范式。 归根结底,共识在于开发者必须主动抵制对 AI 的“盲目”依赖,以保持技术掌控力及职业竞争力。
相关文章

原文

Lately, I’ve been feeling like I’m losing control over the code I write when I work with agentic code generation.

When I finish an agentic session, I get all the outward signs of having written code, but none of the internal processes that happen when we write code by hand.

As a quick primer, the human brain has several types of memory, short-term, working, and long-term. Short-term memory gathers information temporarily and processes it quickly, like RAM. Long-term memory includes things you’ve learned previously and tucked away, like database storage. Working memory takes the information from short-term memory and long-term memory and combines them to synthesize, or process the information and come up with a solution.

When we’re working on code, (and by working on, we mean most often reading someone else’s code) all of these processes are going on in our brain simultaneously to try to help us make sense of the programming environment.

It’s not surprising. Code generation, in its default mode, is antithetical to skill retention, particularly because its UX affordances are reminiscent of a slot machine’s: you pull the lever, you get a reward (a solution to your coding problem.) In some ways, we’ve replaced the social media feed with a stream of tokens, and I look forward to reading those papers in ten years.

It really does take extra concerted effort to move from just generating answers to using the tool deliberately. One thing Oz suggested when I posted on X that I felt like I came away from an agentic session with a brain fog was rewriting portions of code myself.

Inspired by that advice, the paper, thoughts on slowing down, and using AI to write better code more slowly, and Mitchell’s adoption journey, I’ve been working on using the tool more deliberately and adding friction back into development.

Here’s what’s worked for me so far:

  • Writing the initial implementation myself and asking the agent to review the code, then going through comment by comment and manually making the changes
  • Using the agent to keep asking questions about pieces of the code I don’t understand instead and pull up relevant documentation and PRs.
  • Asking the agent to think about implementing two approaches and choosing between them and then critiquing the other approach
  • Discussing an agent’s proposed implementation with another person instead
  • Starting to use the agent only after I’ve spent 20 minutes on the problem
  • Going back and reading books and academic papers
  • Reimplementing fundamental data structures

All of these negate the supposed speed up effects of LLM-generated code in the short-term by adding friction, and yet, in the longer term, make me better at using the tool, because they solidify my own foundation instead of the foundation models'.

We should be more tired than the model.

联系我们 contact @ memedata.com