过去两年，如果你去翻翻现代数据平台的提交记录，会发现一个极其残酷的事实。
写代码的摩擦力，已经无限趋近于零。
Cursor、Claude Code 这些工具直接住进了你的 IDE 和 Docker 容器里。用大白话描述一个 Kafka 到 Iceberg 的映射，AI 瞬间就能给你吐出一个能跑的初版代码。
说实话，这场景看着挺爽，但细想有点慌。
如果 AI 成了写代码的主力，软件工程师还剩什么活干？难道我们都要沦为给 AI 疯狂点“Approve”的无情盖章机器？
Data Engineering Weekly 的作者 Ananth Packkildurai 给出了一个极其硬核的答案。个人觉得，这个视角比市面上那些“AI 取代程序员”的陈词滥调，要犀利太多。
把 AI 当成一台会“发疯”的热机
我们先把 AI 那些拟人化的滤镜摘掉。
剥开外壳，它本质上就是一台计算热机。你给它一个 Prompt、一个业务需求，它就把这些意图转化成代码、工具调用和系统变更。
但只要是热机，就会有损耗。
经常用 AI 写复杂代码的人肯定深有体会。一开始它思路清晰，跑着跑着就开始“幻觉”了。它可能会抓住一个过时的假设不放，去修补表面症状，甚至把几年前的旧迁移脚本当成现在的正常逻辑。
这在工程上叫“操作熵”。
过时的假设、分支的上下文、没解决的依赖，全在它的循环里堆积。如果没有人类强行打断，或者没有一个失败的测试用例来给它一巴掌，这台热机就会在错误的道路上狂奔，越跑越偏。
AI 确实能产生巨大的动能。但真正的问题是，你周围的系统能不能把这些动能转化成有用的功。
企业级开发是个无解的“三体问题”
有人可能会拿“无限猴子定理”来反驳。说现在的 AI 是带着编译器、测试套件的聪明猴子，只要不断试错，总能写出莎士比亚。
在边界清晰的小任务里，这话没毛病。输入输出明确，测试用例齐全，AI 跑个循环就能收敛出正确答案。
但老实讲，真实的企业系统里，根本没有这种岁月静好。
一个实时定价引擎，背后牵扯着多变的运营状态、第三方 API、延迟到达的事件，还有一堆只存在于某个老员工脑子里的业务规则。
素材里提到了一个特别绝的比喻：企业逻辑的“三体问题”。
两个天体运动，用干净的数学公式就能预测。加进第三个天体，系统直接走向混沌，牵一发而动全身。
现代数据平台就是这个德行。点击流在变，操作数据库在变，API 在限流，Schema 在演进，遗留系统里还埋着没人敢动的祖传代码。
环境一直在变，而 AI 这只猴子还在键盘上瞎敲。
真正值钱的，是给 AI 修一堵“墙”
这里有个极其经典的翻车案例。
假设你让 AI 给营收模型加一个 customer_tier（客户等级）字段。AI 很聪明，它在操作数据库里找了个 status（状态）字段，做了个映射，然后跑通了所有现有的类型和空值测试。
代码很干净，流水线全绿。但答案完全是错的。
为什么？
因为语义数据契约规定，customer_tier 必须基于过去 12 个月的消费额来计算，而且得有专门的业务负责人，绝对不能直接拿账户状态来凑数。如果有这层契约在，AI 的修改在到达仪表盘之前就会被直接拦截。
看出里面的门道没？
在这个场景里，工程师的核心贡献根本不是写那段转换代码。 工程师的真正价值，是设计了那个让 AI 的错误变得可见、具体且可恢复的“边界”。
这点我不太认同很多自媒体说的“程序员要转型做 AI 提示词工程师”。真正的转型，是去设计系统的“平衡态”。
代码越来越廉价，规矩越来越贵
说白了，当业务需求的变化速度，超过了 AI 吸收反馈的速度，工程师就必须去建隔离场。
严格的语义层、不可变的事件日志、数据契约、幂等 API。这些东西以前可能只是“最佳实践”，现在它们是保命的底线。
它们能大幅减少 AI 需要同时处理的假设，把一个混沌的耦合问题，降维成一个输入清晰、规则明确的有界领域。
一旦这个领域建好了，AI 才会真正变成你的超级外挂。它能自己写转换、跑测试、修 Bug、发版本，完全不需要去猜那些没写在文档里的历史包袱。
代码生成的成本正在无限趋近于零，但软件工程的价值反而变得更刺眼了。
自治系统会写出越来越多的软件。但决定这些软件是平稳运行，还是直接崩溃成一场灾难的契约、反馈循环和边界，依然得靠人类工程师来设计。
当写代码不再是一门手艺，定义“什么代码不能写”，会不会成为下一代程序员最核心的护城河？
【锐评】：AI 负责踩油门狂飙，程序员负责修护栏和踩刹车，这大概就是未来研发团队的真实生态了。
参考链接：
https://venturebeat.com/orchestration/software-engineers-new-job-isnt-writing-code-its-designing-the-boundaries-ai-agents-cant-break