a16z合伙人 Arianna Simpson：AI能写代码，但写不出“公司这门生意”
a16z合伙人Arianna Simpson指出，软件最难的从来不是技术本身，而是如何把混乱的商业现实抽象成一套可执行的标准化流程与业务流，这才是写软件真正的难度所在。
她强调，这并不意味着技术创始人不再重要：当前AI在复杂编排和系统性设计上仍然很弱，哪怕Claude之类模型能写大量代码，依然需要优秀工程师去监督、架构与集成，才能构建真正有意义的产品。
Arianna最后泼了一盆冷水：智能体可以帮你把App堆出来，但公司剩下的部分——找需求、做产品、搭团队、跑运营、拿收入——依旧要你亲自去做。
资料来源：公开信息
ABAB AI Insight
1）一句话结论：这条信息真正想提醒什么？
提醒是：AI降低的是“写代码”的门槛，但真正决定成败的“把业务抽象成软件”和“把软件变成公司”这两件事，一点都没变简单。
底层机制一是抽象难度：好的软件，本质是把模糊的用户需求、线下流程、组织权限和商业规则，压缩成清晰的状态机和业务流，AI可以生成函数，却难以自动理解“这家公司到底怎么赚钱、谁对谁错、出了问题谁负责”。
底层机制二是编排难度：复杂系统需要跨模块的架构设计、优先级决策、性能/成本权衡，这些都要求人类工程师和创始人主导，AI更像是高效“码农”和助手，而不是能独立做系统设计与战略决策的总工程师。
2）历史同构案例
案例A：（云计算和PaaS普及期，约2008–2020）发生了什么？Heroku、AWS、Firebase等把部署与运维门槛大幅拉低，但真正跑出来的公司并不是“谁会点几下控制台”，而是那些能把SaaS精细化到某个垂直场景、深刻理解业务流程并写进产品的团队；赢家是会用云工具重构行业工作流的人，输家是只会“把旧系统搬到云上”的团队。它和本新闻的对应点是：那一轮大家以为“有云就人人能创业”，结果发现难的是“怎么把行业变成软件”；今天大家以为“有AI就能自动写App”，现实是难的仍然是“怎么把业务抽象对”。
案例B：（低代码/无代码浪潮，约2015–至今）发生了什么？大量平台承诺“业务人员拖拖拽拽也能做应用”，但真正复杂、持续演化的核心系统，仍然需要专业工程团队维护；赢家是把低代码当原型工具、然后在理解业务的基础上做真正产品化的公司，输家是幻想“点点鼠标就能替代产品和工程”的人。它和本新闻的对应点是：AI写代码只是把“低代码”推到新高度，却没有消灭需求发现、产品定义、组织建设这些最难的部分。
3）认知模型：给读者一个可迁移的判断框架
一句话模型：工具越强，代码越不稀缺，“抽象业务 + 组织执行”才是真正护城河。
以后看到“AI自动写App”“智能体自动创业”这类新闻，可以先问：这个系统要解决的真实业务问题是什么，涉及哪些角色、激励和约束，这些复杂性是否被创始团队真正吃透，还是停留在“把流程画成几个按钮”的表层。
再问：AI在这个场景里具体降低的是哪块成本——编码、测试、运维，还是内容生成——以及剩下哪些需要高度人类判断和协作的环节（销售、合规、线下履约、品牌与信任），这决定了“AI能自动做完多少生意”，以及剩下的人类工作量到底在哪里。
4）行动清单
普通人：
选一个你熟悉的工作流（比如自己所在公司的审批、销售或客服流程），尝试用白板把关键角色、输入输出、异常情况画成流程图，再用任意AI工具帮你把它转成“软件需要的状态与接口”，训练自己从“做事的人”变成“能抽象流程的人”。
系统学习1–2门“产品+工程思维”的免费英文资源（如软件设计、系统思考、SaaS案例），理解用户故事、用例、边界条件这些概念，再去用AI写小工具，而不是一上来就期待“智能体帮你自动完成一切”。
创业者：
把AI和智能体视为“编程乘数”，重心放在深入一个具体行业：用实地访谈、跟班观察、数据分析，搞清楚这个行业真实的痛点与权力结构，再用AI加速迭代解决方案，而不是从“我有一个能写代码的AI”倒推要做什么产品。
在组织层面，明确区分“AI可以自动化的工程任务”和“必须由高级工程师把关的架构与安全决策”，设计一套代码审查、测试和上线流程，让AI生成代码成为你的工程流水线一部分，而不是让项目沦为一堆无人负责的自动生成脚本。