AI时代,人类还要写代码吗?
作者：微信文章2025年6月17日，在旧金山的“AI Startup School”，Andrej Karpathy发表了题为“Software is Changing”的主题演讲，介绍了AI时代，传统的软件开发模式正在经历怎样的变化，过程中他提到了软件开发的三个阶段，大模型在未来社会中的重要地位，AI编程目前存在的挑战和解决方案。在分享具体内容之前，我们先一起了解一下Andrej Karpathy这个人。Andrej Karpathy是当代人工智能（AI）领域最具影响力的研究者和工程师之一，尤其以其在深度学习、计算机视觉和大语言模型方面的研究和工程实践而闻名。他在学术界、工业界和开源社区都留下了重要贡献。Andrej Karpathy 1986年出生于斯洛伐克，15岁移民加拿大。2009 年在多伦多大学获得计算机科学与物理双学士，2011 年在不列颠哥伦比亚大学获硕士学位（研究物理模拟），2015 年在斯坦福大学获博士，导师为李飞飞（Fei-Fei Li），研究聚焦视觉与自然语言交叉领域。他是OpenAI的早期核心研究者，2015-2017年，参与构建 GPT 系列早期版本，包括 GPT-2 的架构优化；2017年加入Tesla，担任高级 AI 主管，全面负责视觉系统研发，主导将端到端神经网络应用于自动驾驶（包括训练、部署、软硬协同如 Tesla 自研推理芯片），领导团队成功将Tesla 切换至全视觉路线；2023年短暂回归OpenAI，参与了GPT-4 的工程攻关及运行机制研究。现在，Andrej Karpathy是独立技术布道者和开发者，创立 AI 教育平台Eureka Labs，推出“GPT101n”、编程助手等工具；编写了miniGPT/nanoGPT开源代码库，帮助开发者从零实现小型 GPT；并且发布大量教育资源，包括解释反向传播、可视化模型结构等内容。下面我们就来看看这样一位AI界的资深人士，对AI时代的软件开发有着怎样的理解和建议。Karpathy的核心论点是“软件正在改变，但更重要的是--编程正在改变。”传统软件开发模式正被AI技术所颠覆，从底层工具、开发流程到开发者角色都在转型。
Karpathy首先提出了一个极具洞察力的概念体系，即软件开发方式的三次演变浪潮：Software 1.0、Software 2.0和Software 3.0。
Software 1.0：传统编码范式软件开发1.0是大家最为熟悉的范式，由人类显式编写逻辑规则和算法，程序行为完全由开发者控制，依赖C++、Java、Python等语言进行逐步构造。
Software 2.0：以数据训练为核心的机器学习范式软件开发2.0的核心，是“我们不再写规则，而是教机器从数据中学规则”。开发者不再编写规则，而是提供大量数据+神经网络结构，软件行为由“数据+模型训练”自动学习得出，开发重心从“写代码”转向“设计模型与数据集”。这也是目前流行的各类大模型的生成模式。
Software 3.0：AI智能体+人类写作范式（Agentic Software）软件3.0的范式不只是调用模型，而是围绕AI智能体的状态管理、任务调度和工具能力构建系统。软件通过“对话+工具使用+规划+反馈”来完成任务，开发者由“模型设计者”进化为“目标定义者与监督者”。
Karpathy借助“Software 3.0”这一概念提出，软件不再只是“写出来的东西”，而是“组织和指挥AI Agent完成工作的系统”。软件工程正从“人写机器运行”转向“人与机器共创、协商、调度”的新纪元。
到这里，我想大家可能已经注意到，Karpathy并不主张完全由AI独立完成开发，而是强调一种更为可持续、现实且高效的范式--“AI 与人类协作”的软件开发新模式。Karpathy明确表达了对“全自动化开发”的质疑，并提出了更具前瞻性的替代方案。
反对“全自动AI开发”的幻想主义Karpathy在演讲中提到 “The best future of software is not agents that write software alone. It is agents that write software with you.”
即：“最理想的软件开发未来，并不是完全由AI独立编写软件，而是AI与你共同开发软件。”
为什么“全自动AI开发”不是最佳路径？
失控风险：不透明、不解释、不受控
AI作为黑箱模型，自动完成整套系统构建流程，人类无法逐步验证与干预，容易导致隐蔽错误、安全隐患、不合需求的产品架构和零责任归属。无人审阅的情况下，即便模型能构建“看似正常”的系统，也可能潜藏深层缺陷。
工程价值不止于完成任务，更关乎思维结构
Karpathy认为开发软件的过程，本质上不只是“把事情做完”，而是表达思维、定义结构、组织团队合作的过程。
需求解释与产品意图依赖人类理解
产品开发的起点是“需求转化为设计”，这依赖于模糊语言的理解（用户需求不明确）、商业目标的判断（是否有盈利性与合规性）和道德选择（例如推荐算法是否歧视某些群体）。这些问题AI在现阶段根本无法解决或无法独立判断，仍然严重依赖人类。
Karpathy主张的理想范式是协同开发（Collaborative Programming），即人类开发者负责提出目标，定义意图，监督过程，审查结果，调优反馈；AI智能体负责编写函数，生成模块，运行测试，部署系统，解释输出。
这样就构成了一种AI“增强工程师能力”的新结构，而非“取代工程师”的结构。他称这种模式为：“Software development as collaborative dialog.”，即“将编程转变为一场人与AI之间的协同对话”。
关键障碍
但同时，Karpathy明确指出了当前AI编程范式面临的关键障碍，也就是所谓的“AI-人类接口不匹配问题”--虽然AI模型在代码生成方面已经表现出色，但在代码部署、运行、集成以及验证的阶段，仍然严重依赖人类工程师来完成诸多环节。这一结构性矛盾正成为阻碍 Software 3.0（智能体协作型软件）全面落地的关键瓶颈。
即便是先进的AI编程系统（如Devin或GPT-4+）能生成完整、可工作的程序，但这段程序最终要变成一个正在运行的系统，仍需以下复杂流程：设置权限和身份认证系统（OAuth、API tokens），配置数据库连接、环境变量、云服务账户，构建前端组件的 UI 交互逻辑，与老旧系统或第三方库进行接口适配，通过多平台（如 Docker, AWS, CI/CD）部署，以及对接浏览器插件、本地文件系统或CLI工具等非代码交互界面等。
而这些“交互接口和配置机制”绝大多数都是为人类工程师而非AI设计的。
未来系统要主动适配AI智能体
Karpathy认为，与其让 AI 去适应旧的工程系统结构，不如主动重构系统，面向智能体进行设计，包括：提供结构化部署API、agent友好接口，提供AI友好的权限说明文档与简化授权方式，以及agent可读的审批规则、测试反馈格式等。AI 正在改变软件，但我们必须也改变软件本身，以便 AI能更好地与之协作。
大型语言模型像电，也像操作系统
最有，我们看一下Karpathy是怎么定位大语言模型的。
Karpathy提出了一个极具启发性的类比，将大语言模型（LLMs）比作电网（power grid）和操作系统（operating system）。
“LLMs are like electricity. But they’re also like operating systems”，这个比喻不仅是一种语言表达技巧，更深刻地传达了Karpathy对AI基础设施未来双重角色作用的宏大理解。
LLMs将成为泛在的“智能基础设施”，一 如电力之于现代工业
LLM能像电一样嵌入到各个应用场景（办公、客服、设计、教育）应用开发者不再需要“自己训练模型”，就像用户不再自己发电未来每一个软件系统都可能内置LLM调用接口，成为“智能即服务（Intelligence-as-a-Service）”的终端
未来的软件系统将以LLM为中台，以多agent为用户态，以自然语言为总线接口
LLM在多agent、复杂任务、多工具协作中将扮演“中枢调度器”角色LLM可以像OS一样，协调多个并发的子任务（sub-goals），管理运行状态LLM驱动的系统可能不再基于“硬件驱动层”，而是基于“语言理解和任务协调”的新一代middleware
写在最后
AI近两年的快速普及极大地提升了社会生产效率，创造了显著的经济价值，但同时也对就业市场和教育选择带来了直接冲击。最典型的例子就是一些基础编程岗位被AI工具取代，导致部分程序员面临失业风险，这也让许多学生在选择专业时感到困惑：在AI时代，大学生是否还需要学习编程？
Karpathy的演讲一定程度上提供了这个问题的答案。
页:
[1]