当LLM开始做那些“本来不该存在”的事:软件范式的隐性革命
从让应用完全由LLM驱动,到把安装脚本写成自然语言,Karpathy在Sequoia上的发言揭示了一个深层趋势:LLM正在创造‘本来不该存在’的功能。这不是速度之争,而是范式更替的开始。
核心观点:LLM的价值核心并非更快地完成旧任务,而是催生了此前根本不存在或不可能实现的新型应用,这正被忽视且将重塑整个软件生态。
关于大语言模型(LLM)的讨论,在过去一年里几乎形成了一个令人厌倦的叙事闭环:它让程序员写代码更快了,它让客服回复更智能了,它让文档总结更高效了。这些描述并非错误,但它们共同塑造了一个危险而狭隘的认知——LLM是“现有流程的加速器”。这个框架极大地低估了正在发生的事情。真正值得警觉的,不是LLM跑得有多快,而是它正在打开一扇通往新功能类型的门,那些功能在旧范式中要么显得荒诞,要么根本不可能存在。
Andrej Karpathy最近在Sequoia Ascent 2026上的分享,无意中击中了这个问题的核心。他提出了三个例子,每一个都试图说明同一件事:LLM的价值坐标不应该建立在“取代什么”上,而应该建立在“创造出什么全新事物”上。第一个例子是一个叫menugen的应用,它的输入是一张图片,输出也是一张图片,而整个逻辑完全由LLM驱动,没有一行传统意义上的经典代码。这不是“用AI写代码生成图片”,而是“应用本身就是一个LLM的对话流”。第二个例子更具挑衅性:用“.md技能”取代“.sh脚本”。想象一下,安装一个软件不再需要写一堆复杂的bash脚本,而是用自然语言写一个Markdown文件,告诉LLM“你想怎么装”,让LLM去理解你的系统环境、处理依赖、调试错误。这在旧范式中是荒谬的——一个脚本不能“理解”你的意图,它只能机械执行。但LLM可以。第三个例子则指向了更宏大的层面:LLM知识库。这是经典代码几乎无法处理的任务,因为它需要对来自任意来源、任意格式的非结构化数据进行计算。知识本身是混沌的,而LLM恰好擅长在这种混沌中找到秩序。
这三个例子共同指向一个颠覆性的结论:我们正在进入一个应用可以“由语言定义”的时代。过去,一个软件的功能是由代码的结构决定的;现在,一个软件的功能可以由一段自然语言描述来动态生成。这不仅仅是开发效率的提升,而是功能创造方式的根本改变。当一个应用可以被“说”出来,而不是“写”出来时,软件的门槛、形态和边界都会发生漂移。那些曾经因为成本过高或技术过于复杂而被放弃的功能,现在可能因为LLM的介入而变得可行。
然而,这个结论遭遇的第一重挑战是“劣质化”的怀疑。批评者会指出,目前LLM生成的代码质量参差不齐,安全漏洞频发,且缺乏可维护性。用自然语言“描述”一个应用,听起来很美,但实际运行时往往充满了不可预测的“幻觉”和逻辑漏洞。这确实是现实,但问题在于,这个批评预设了一个不合理的完美标准。传统软件开发也充满了缺陷、漏洞和不可维护的代码,只是我们已经习惯了用“补丁”和“版本迭代”来掩盖。LLM生成的应用并非天生更差,而是它的缺陷模式不同。更重要的是,当我们谈论“创造新功能类型”时,我们谈论的是那些在旧范式中根本没有存在可能性的东西。比如一个能根据用户当天阅读的新闻动态调整工作流程的应用——这在传统代码中需要复杂的推荐算法和规则引擎,而在LLM范式中,只需要一句“根据我今天的阅读内容,安排优先级”。即使这个安排有时是错的,它存在本身就已经改变了人机协作的基线。
第二重挑战更为隐蔽:经济性。Karpathy在同一个分享中提到了一个关于LLM能力“锯齿状”的洞见。他观察到,同一个LLM可以同时做到两件看似矛盾的事:一边连贯地重构一个10万行代码的库,一边告诉你“开车去洗车店洗车”。他给出的解释是,能力的分布取决于领域是否被包含在强化学习的训练数据分布中,而数据分布的选择又受制于收入和市场总量。简单说,LLM更擅长解决那些“有市场”的问题。这听起来像是商业常识,但它揭示了一个残酷的现实:LLM创造的新功能类型,一开始可能只集中在那些能产生直接经济回报的领域,比如代码生成、客服、内容创作。而那些真正“本来不该存在”的、小众的、实验性的功能,可能会因为缺乏商业激励而被忽视。
但这恰恰是“agent经济”最令人兴奋的部分。Karpathy提到的第三个主题——agent原生经济——正在改变这一格局。当一个产品和服务被分解为传感器、执行器和逻辑,并且这些组件可以跨计算范式(经典代码、神经网络、传统系统)自由组合时,创造新功能的成本已经大幅下降。一个独立开发者可以借助LLM和开源框架,在几个小时内搭建出一个以前需要团队开发数月的应用。menugen这样的应用,就是最好的例证。它不是大公司的产品,而是个人或小团队对LLM能力的一次实验性探索。经济性不再决定一切,可探索性正在成为新的驱动力。
当然,我们也不必过于乐观。LLM创造新功能类型的能力,仍然受制于其核心缺陷:不可靠的推理、对上下文的敏感性、以及难以自我修正的“锯齿”能力。这正是为什么我认为,与其争论LLM是“泡沫”还是“革命”,不如关注一个更具体的问题:我们是否愿意接受一个功能不完全可靠但极其便宜且快速迭代的软件世界?如果答案是肯定的,那么“本来不该存在”的功能将如雨后春笋般涌现,它们粗糙、偶尔出错,但提供了前所未有的灵活性。如果答案是否定的,那么LLM将始终停留在“加速器”的角色,永远无法迈入创造者的行列。
这场转变的深远影响,可能远远超出技术的范畴。当软件的功能可以由自然语言定义,当安装脚本变成一篇博客文章,当知识库不再需要数据库而只需要一个LLM的上下文窗口,我们所理解的“开发”和“使用”之间的界限正在模糊。用户不再是功能的被动消费者,而是功能的共同创造者。Karpathy所说的“.md技能”如果普及,那么发布一个新功能就像写一篇文章一样简单。这不是一个渐进的变化,而是一次软件范式的隐性革命。它没有轰轰烈烈的发布会,没有明确的版本号,但它正在每一个能够用自然语言描述一个任务并得到执行结果的瞬间悄然发生。
参考来源
- Built an AI agent SaaS for 5 months, launched on Microsoft Store, free users coming in — but how do I actually convert anyone to paying? - https://www.reddit.com/r/micro_saas/comments/1t7c2lc/built_an_ai_agent_saas_for_5_months_launched_on/
- Fireside chat at Sequoia Ascent 2026 from a ~week ago. Some highlights:
- The first theme I tried to push on is that LLMs are about a lot more than just speeding up what existed before (e.g. coding). Three examples of new horizons:
- 1. menugen: an app that can be fully engulfed by LLMs, with no classical code needed: input an image, output an image and an LLM can natively do the thing.
- 2. install .md skills instead of install .sh scripts. Why create a complex Software 1.0 bash script for e.g. installing a piece of software if you can write the installation out in words and say "just show this to your LLM". The LLM is an advanced interpreter of English and can intelligently target installation to your setup, debug everything inline, etc.
- 3. LLM knowledge bases as an example of something that was *impossible* with classical code because it's computation over unstructured data (knowledge) from arbitrary sources and in arbitrary formats, including simply text articles etc.
- I pushed on these because in every new paradigm change, the obvious things are always in the realm of speeding up or somehow improving what existed, but here we have examples of functionality that either suddenly perhaps shouldn't even exist (1,2), or was fundamentally not possible before (3).
- The second (ongoing) theme is trying to explain the pattern of jaggedness in LLMs. How it can be true that a single artifact will simultaneously 1) coherently refactor a 100,000-line code base *and* 2) tell you to walk to the car wash to wash your car. I previously wrote about the source of this as having to do with verifiability of a domain, here I expand on this as having to also do with economics because revenue/TAM dictates what the frontier labs choose to package into training data distributions during RL. You're either in the data distribution (on the rails of the RL circuits) and flying or you're off-roading in the jungle with a machete, in relative terms. Still not 100% satisfied with this, but it's an ongoing struggle to build an accurate model of LLM capabilities if you wish to practically take advantage of their power while avoiding their pitfalls, which brings me to...
- Last theme is the agent-native economy. The decomposition of products and services into sensors, actuators and logic (split up across all of 1.0/2.0/3.0 computing paradigms), how we can make information maximally legible to LLMs, some words on the quickly emerging agentic engineering and its skill set, related hiring practices, etc., possibly even hints/dreams of fully neural computing handling the vast majority of computation with some help from (classical) CPU coprocessors. - https://nitter.net/karpathy/status/2049903821095354523#m
- Reducing IT Infrastructure Costs with Proactive AI Agent Management - https://www.reddit.com/r/secops_solution/comments/1t6ep5w/reducing_it_infrastructure_costs_with_proactive/