查看: 27589| 回复: 97
跳转到指定楼层
上一主题 下一主题
收起左侧

[职场感言] AI 把代码越写越好,瓶颈去哪了?兼聊聊 infra 人的焦虑

   
全局:

注册一亩三分地论坛,查看更多干货!

您需要 登录 才可以下载或查看附件。没有帐号?注册账号

x
这两年在版面上明显感觉到一种情绪:做 OS、编译器、runtime、性能调优的同学有点茫然。AI 把应用层的代码越写越好,连带着很多人怀疑:自己搞了十几年的底层功夫,是不是也快被吃掉了?隔三差五就有帖子问"infra 还值得做吗"。. Waral dи,
最近刷到 Dario Amodei(Anthropic CEO)访谈里的一段【https://x.com/MilkRoadAI/status/2054244274045382773?lang=en】,他引用 Amdahl's Law 谈 AI 的影响:当你把系统里快的部分大幅加速之后,原来"无关紧要"的部分会变成新的瓶颈——旧的优势消失,新的优势从想不到的地方长出来。. check 1point3acres for more.

这不是抽象理论,数据已经出来了。同一个帖子里引了几组 2026 年的统计:. check 1point3acres for more.
  • 重度使用 AI coding 的团队,merge 的 PR 数量涨了 98%——但 PR review 时间也涨了 91%,实际部署速度几乎没变;
  • 96% 的开发者表示,不完全信任 AI 生成的代码进 production;
  • Veracode《2026 State of Software Security》:82% 的组织背着 security debt(同比 +11%),critical 级一年暴涨 36%——报告直接归因于 AI 生成代码进入 production 的速度,超过了安全团队的处理能力。
把这几个数字连起来读,就是 Amdahl's Law 在生产环境里的实时上演:"写代码"这一步被加速了几十倍,端到端的吞吐却没涨——瓶颈整体平移到了验证、review 和诊断。加速不了的那一段,现在成了整个系统的定价权所在。

说个自己的体会。我以前做 AI compiler 的时候,感觉一天的大部分时间其实都花在 debug 上——写代码从来不是瓶颈,搞清楚"为什么错"才是。现在有了 AI 帮忙,体感反而更微妙:简单的问题它秒解,但难一点的,经常烧半天 token 也定位不到。原因想想也直白——它在盲猜。模型看不见执行:不知道内存实际怎么用的,不知道为什么 crash,不知道两次运行为什么结果不一样。它只能靠读代码反复假设,我就看着 token 表一路狂转。我个人一个月 $200 的 token 预算现在都守不住了,回头一算,大半烧在"让模型猜为什么错"这件事上。
所以我的判断和主流焦虑正好相反:AI 越能写代码,runtime 的 ground truth 越值钱。 AI coding 本质上是个开环系统,生成的代码量越大,验证和诊断的缺口就越大。谁来给这个开环系统闭环?只能是对执行层有真正理解的系统——和造这些系统的人。做底层的同学,你们手里的功夫不是快被淘汰的东西,是即将被重新定价的东西。

我在 UMass 做了小二十年 systems research,前两年辞掉了 tenure,中间在 ByteDance 和 XPeng 带过训练基础设施,亲眼看着这些问题每天烧掉 GPU-months。现在我全职创业做的就是这个方向——等于把自己的钱和职业生涯都押在了上面这个判断上。

抛几个问题,想听听大家的一线情况:
  • Debug 占你开发时间的比例有多少? AI 生成代码出了 production 问题,最后是谁、用什么手段兜的底?
  • 上面那组数据——PR 翻倍、review 时间也接近翻倍——和你们组的体感一致吗?
  • 你让 AI debug 的战绩如何? 是秒解居多,还是像我一样经常看着它烧 token 转圈?你一个月花在"让 AI 猜错误原因"上的 token 钱大概多少?
  • 做底层的同学:你觉得自己哪部分功夫是 AI 五年内吃不掉的?反方观点也欢迎——执行层的验证和诊断,会不会最终也被端到端模型解决?
  • 开个脑洞:如果有办法让 AI 直接拿到执行层的 ground truth——crash 现场、真实内存行为、可复现的执行轨迹——把 debug 时间和 token 浪费砍掉一大半,你觉得这东西值多少钱?该个人掏、组里的工具预算掏,还是算在平台费里?
利益相关声明:如上所说我在创业,方向就是给 AI 基础设施补这个 feedback loop——所以问题 5 不是纯脑洞,我是真想听真话,泼冷水的尤其欢迎。具体做什么、找什么人,创业组有帖【https://www.1point3acres.com/bbs/thread-1184330-1-1.html】,这里不展开,免得变成广告贴。

评分

参与人数 8大米 +32 收起 理由
SakuraSpar + 1 谢谢分享!
Rye_mo + 1 赞一个
lintc + 1 谢谢分享!
chuqixiaozhu + 1 给你点个赞!
erma318 + 1 给你点个赞!

查看全部评分


上一篇:ng还能再谈薪吗?
下一篇:5年多时间从不卷组变成地狱组
地里匿名用户
推荐
匿名用户-TY1YF  | 添加认证 | 2026-8-2 12:29:24
说一个楼主可能没注意到的点。

可能大部分人的开发场景并没有那么复杂,估计就是 CRUD 来 CRUD 去、增删改查更新这些事情,有的时候 Ground Truth 也就在 Log 里面....

而且我觉得,判断大家对 Code Review 的认真程度是跟公司有关系的:
* 有的公司真的是慢慢一行一行看,
* 有的公司现在已经魔幻到 Code Review 的 Approve 按钮成为一个摆设了,因为每一个 Code Merge 都是上千行、几十上百个文件,毫无 Review 的价值和意义...

评分

参与人数 1大米 +1 收起 理由
tongpingliu + 1 赞一个

查看全部评分

回复

使用道具 举报

地里匿名用户
推荐
匿名用户-R4JJ0  | 添加认证 | 2026-8-2 11:50:45 来自APP
➕ 7
我个人这一年来是越来越相信AI了,前半年组里确实在讨论有些junior用ai生产的内容(pr,design doc),太耗费时间去review了,之后部门要求所有人要对自己用ai生产的东西负责,再加上最近几个月claude不断更新,说实话review的时间没感觉是bottleneck,只能说大家效率提升都巨大。

你之后说的验证、debug、重现、log什么的,我们org里之前就build了很多类似的工具,今年再把这些工具套上Claude skill,效率更是起飞。
.--
我同意你的看法,但是我第一反应是第三方公司想去做这个是不是太难了?大公司里面每个org,甚至每个组,因为系统负责的东西不同,都需要自己的tool或者process去debug,真的能做出来什么统一解法吗?
回复

使用道具 举报

地里匿名用户
推荐
匿名用户-YA9I4  | 添加认证 | 2026-8-3 02:26:42 来自APP
💯 22
🍗 5
🐂 13
匿名用户 发表于 2026-08-02 09:21:31
“模型看不见执行:不知道内存实际怎么用的,不知道为什么 crash,不知道两次运行为什么结果不一样。它只能靠读代码反复假设。。。”

Are you kid
但是看起来你也没接触过复杂系统或者是稍微有点难度的debug。坐标大厂分布式query engine组,给两个真实案例:

(1) 四十万CPU左右部署规模的一个专用instance,大概每两天在几十亿条query中有一条结果会随机出错,具体症状是string类型的column结果出现了其他内存地址的数据。就这隔三差五一条query的出错让下游产品组的oncall苦不堪言,因为每次都要花大量时间追踪错误结果的影响范围以及相关客户。

出错的query也相当复杂,数据量大且有很多join/aggregate/analytic functions,分布式execution plan大概使用了10000个计算节点。考虑到其出错概率,几乎不可能简单复现。-baidu 1point3acres

. .и最后debug出来的方法类似于刑侦手段,root cause推测是集群中有一台机器由于硬件故障有极小概率在特定条件下在执行__builtin_clz()操作时会出现一个bit的错误。而这台机器corrupt后的数据很多时候在分布式框架下被发送到其他机器后才导致可见的错误结果,使得诊断过程相当反常识。最后把这台机器拉黑后故障解决。. check 1point3acres for more.

(2) 800万CPU部署量的一个大型instance,有少量不确定用户的query会不确定地造成coordinator上的memory corruption crash并且呈现出类似的stacktrace。找了一些用户试图复现,偶尔能复现成功,但是在小一点test instance就不行,而且出于数据安全/合规我们没法拿到原数据访问权限做local debugging。问题在那搁置了半年多,但是每天都有crash并且一个coordinator崩了会导致其他用户在上面运行的query也全部失败,所以只能一直高priority挂着。. 1point 3 acres

期间很多人试图用AI agent诊断,AI给出的解释五花八门,但是基本都不靠谱。而且这方面有意思的一点在于,如果你不是对复杂系统有足够的经验,就会觉得AI给出的每一种解释都像那么回事,而这样的解释由于系统复杂性可以胡诌出上百种。

最后debug手段是结合系统architecture在coredump上做了非常深入的分析,root cause是protobuf descriptor的lifetime问题,但是crash的地方其实距离allocate/free的地方非常遥远,而且触发条件比较苛刻,所以AI基本不可能猜到root cause。

评分

参与人数 5大米 +7 收起 理由
CobraManeuver + 2 楼主/层主请继续!
匿名用户-LTLHZ + 1 给你点个赞!
wrwwctb + 1 给你点个赞!
fmxs + 1 赞一个
tongpingliu + 2 很有用的信息!

查看全部评分

回复

使用道具 举报

🔗
godducklist 2026-8-2 11:54:37 | 只看该作者
全局:
pr数量暴增,但是感觉没有几个人认真review。感觉如果skill写的够好的话,其实review也不需要那么精力。
回复

使用道具 举报

🔗
 楼主| tongpingliu 2026-8-2 11:59:14 | 只看该作者
全局:
匿名用户 发表于 2026-8-1 20:50
我个人这一年来是越来越相信AI了,前半年组里确实在讨论有些junior用ai生产的内容(pr,design doc),太耗 ...

谢谢,很好的实际观察。 对于程序Crash,我们做的东西是基于第一性原理,和产品种类无关,只和语言有关系。当然,我们现在不能解决semantic bug,因此我们想着给AI提供一些获取ground truth的API,让AI能够更快的debug。
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-8PBRF  | 添加认证 | 2026-8-2 12:22:36 来自APP
匿名用户 发表于 2026-08-01 20:50:45. From 1point 3acres bbs
我个人这一年来是越来越相信AI了,前半年组里确实在讨论有些junior用ai生产的内容(pr,design doc),太耗费时间去review了,之后部门要求所
你是做infra的吗?感觉ai拿来写general backend或者tools很好用,一般follow已有的code pattern就行。
拿来写low level code 即使fable5的产出其实也一般
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-DKZ9W  | 添加认证 | 2026-8-2 12:28:22 来自APP
是的,我觉得infra,系统设计才是AI时代的价值所在
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-27WDE  | 添加认证 | 2026-8-2 12:43:06
我觉得楼主咋说 本来创业就高风险的事
你职业生涯钱赌上去 也不能代表着什么
回复

使用道具 举报

地里匿名用户
🔗
匿名用户-ZC5M3  | 添加认证 | 2026-8-2 13:10:28 来自APP
写得好吗?ai现在真是每天产生成吨垃圾
回复

使用道具 举报

全局:
我刚 ng 毕业,目前在一个技术流的公司上班,做一个 library 的开发。想什么时候有空了上手一下 compiler。请问楼主有什么宝贵建议吗?
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册账号
职场达人
  • ↑ 本版用于讨论职场各种干货话题,闲聊请去🔗聊聊或者🔗匿名版
  • ❌ 本版严禁水贴,引战,发布广告,拉群,贴个人联系方式,扣分无警告
  • ☑ 求职、面经等去 🔗北美求职和 🔗回国求职大区,刷题和学习请去 🔗终身学习大区
  • ☑ 请去专版发布 🔗内推, 🔗招聘信息,和讨论 🔗创业内容
  • ☑ PIP / DevList/ Need Support 等话题也已开设 🔗专版

本版积分规则

>
快速回复 返回顶部 返回列表