Vibe Coding → Agentic Engineering

创建时间: 2026-04-30 来源: [[sources/Andrej Karpathy From Vibe Coding to Agentic Engineering - 逐字稿]] 相关: Agent-Paradigm-ShiftHarness-EngineeringJagged-IntelligenceAgent-Native-InfrastructureState-of-AI-2026Vibe-Coding-in-ProdAI-and-HumanitySoftware-Fundamentals-in-AI-Coding


核心区分

Karpathy 在 2025 年创造了 Vibe Coding 一词,2026 年进一步提出 Agentic Engineering。两者的关系不是替代,而是分工

Vibe CodingAgentic Engineering
目标拉高地板(raising the floor)保持天花板(preserving quality bar)
适用场景任何人都能构建软件专业软件工程,有质量责任
对待质量”能用就行”不能引入漏洞,仍需对软件负责
核心问题如何让 coding 变得无障碍如何在保持质量的前提下更快
典型产物个人 side project、原型生产级软件、可部署产品

“Vibe coding is about raising the floor for everyone. Agentic engineering is about preserving the quality bar of what existed before in professional software.”

时间线:拐点在 2024 年 12 月

Karpathy 描述了从”AI 辅助编码”到”完全信任 agent”的清晰转折:

  1. 2024 年大部分时间:Agent 工具能写出代码块,但经常出错,需要手动修正——“kind of helpful”
  2. 2024 年 12 月(休假期间):最新模型产出的代码块”直接就对了”(just came out fine)。不断要求更多,始终正确。记不清上一次需要纠正是什么时候。
  3. 此后:完全进入 vibe coding 状态,side projects 文件夹爆满。

这个转折不是渐进的——Karpathy 强调它是一次 “非常鲜明的转变”(very stark transition)。很多人对 AI 的认知停留在 2024 年的 ChatGPT 体验,但 12 月之后一切都变了,尤其在 agentic coherent workflow 上。

Agentic Engineering 作为工程学科

Karpathy 将 Agentic Engineering 定义为一门工程学科,核心挑战是:

  • Agent 是锯齿状实体(spiky entities):能力不均匀,有时出错(fable),有一定随机性(stochastic),但极其强大
  • 工程问题:如何协调这些 agent 在不牺牲质量的前提下加速?
  • 10x 工程师的概念已经过时——擅长 agentic engineering 的人远超 10x 加速

招聘需要重写

传统的招聘方式(解谜题、算法题)仍停留在旧范式。Karpathy 提出的新招聘模式:

  1. 给候选人一个大项目——比如”用 agent 工具实现一个 Twitter 克隆”
  2. 要求做得真正好、真正安全
  3. 用另一组 agent(“10 个 Codex 5.4x”)模拟用户活动并尝试攻击
  4. 这些攻击 agent 不应该能攻破

“Give me a really big project and see someone implement that big project. Then have some agents simulate activity and try to break your website. They should not be able to break it.”

什么人类技能反而变得更重要

品味、判断、审美(Taste, Judgment, Aesthetics)

Agent 像实习生——你需要掌握:

  • 审美和设计决策:什么该做、什么不该做
  • 顶层架构:定义 spec、确定核心抽象
  • 监督:发现 agent 的”怪异行为”

案例 — MenuGen 的 email 关联 bug:用户用 Google 登录 + Stripe 购买积分。Agent 试图用 email 地址关联两者,但用户可能用不同 email。Karpathy 的评价:“Why would you use email addresses to cross-correlate the funds? This is such a weird thing to do.”

这类错误——把 email 当唯一用户 ID——需要人类在 spec 层面纠正。

理解(Understanding)vs 思考(Thinking)

“You can outsource your thinking but you can’t outsource your understanding.”

这是 Karpathy 反复思考的一条推文。核心理念:

  • 思考可以外包给 agent,但理解必须留在自己脑中
  • 人正在成为瓶颈——不是写代码的瓶颈,而是”知道我们在构建什么、为什么值得做、如何指挥 agent”的瓶颈
  • LLM 不擅长理解(don’t excel at understanding),人类在这方面仍然是独特的

这也是 Karpathy 对 LLM Wiki(知识库)项目如此兴奋的原因——它是一个增强理解的工具,通过不同的信息投射方式让人获得洞察。

API 细节不重要了,但底层原理仍然重要

Karpathy 的例子:PyTorch/NumPy 的 keep_dim vs keepdimsdim vs axisreshape vs permute vs transpose——这些细节他已经不记了,因为 agent 有完美的回忆能力。

仍然需要知道

  • 底层有 tensor,有 view,可以操作同一存储的 view
  • 也可以有不同存储(效率更低)
  • 不应该不必要地复制内存

→ 细节交给 agent,工程判断留在人身上

Software-Fundamentals-in-AI-Coding 是这个判断的软件工程版本:API 细节和局部实现可以交给 AI,但 design concept、通用语言、模块边界、接口设计和反馈循环必须留在人类战略层。否则 agentic engineering 会滑回“只改 spec、不看代码”的 specs-to-code 幻觉。

与 LLM Wiki 的关系

Karpathy 将 LLM 知识库视为增强理解的工具——任何时候他看到信息的不同投射(different projection onto information),都会获得洞察。这与他”理解不能外包”的核心理念一致:

  • Agent 处理信息(思考)
  • Wiki 帮助人类理解信息
  • 人在理解的基础上指挥 agent

我们的 LLM-Wiki 正是这个理念的实现。

衍生创作

参考资料