AI会写代码了，让项目一直改得动才是难题
Chavdar Yotov：这是过去40年里，软件工程师遇到的最大机会。 说这句话的是Chavdar Yotov。他自己做了15年软件开发，其中12年在Arm，从初级工程师做到高级经理，后来还担任过AI总监。
在Arm时，他一直觉得自己走在前面。直到出来找工作，招聘信息上出现了一串他看不懂的技术名词。 熟悉的工具在以前的公司里仍然好用，外面的软件行业却已经换了样子。如今AI又把开发工具改了一轮，但他反而觉得开发者的机会来了。 Yotov说的机会，就在“做出来”与“继续做下去”之间。 Agent能写代码，但它未必知道旧需求藏在哪份工单里、哪些模块不能随意改、交出的结果该怎样验收。这些问题还没有现成答案。 Yotov接触过一位独立开发者。他借助AI，一个人把项目做到了很大的规模。但是麻烦出现了：以前几秒钟能完成的小修改，现在可能要花几个小时；这处修好了，另一处又坏了。AI能帮一个人迅速做出软件，但是后续的修改和维护是一个很大的问题。 更让人好奇的是Yotov自己的做法。 他说，自己现在已经很少逐行读代码。一个见过AI把项目越改越乱的工程师，为什么敢减少亲自看代码的时间？他花了几个月搭起一套工作流程：让Agent先弄清项目背景，再限定各自能改的范围，最后检查实际运行的结果。 它让“程序员迎来机会”不再只是一句口号：代码写得更快之后，怎样让一个项目在下一次需求到来时仍然可以修改？Yotov用自己的经历，讲了他正在尝试的办法。
Yotov称，软件工程师正遇到“过去40年里最大的机会” 以下是按照视频内容进行整理。 在Arm一路晋升，出门找工作却被技术栈难住 他在Arm待了12年。职位从初级工程师一路升上去，技术也一直围绕手头的工作更新。 换工作时，他才发现和以前并不是一回事：公司内部仍在使用的语言和工具，在外面的招聘市场可能已经不再吃香；Web应用和JavaScript生态，他也得重新学习。 Yotov：在Arm的那12年，我觉得自己一直处于最好的状态。等我开始找下一份工作，才意识到外面的技术已经走了很远。有些招聘要求上的名词，我甚至得先去搜索它是什么意思。
Yotov回忆在Arm工作12年后，求职时发现自己与外部技术变化脱节 这段经历并不是说明“资深工程师没用了”。 在他看来，AI带来的新问题还没有成熟的标准答案。你很难像过去排查常见报错那样，打开Stack Overflow就找到一篇完全对口的解决方案。先把新问题摸透、做出可用办法的人，会有机会。 他接下来讲的客户项目，说明了问题究竟是什么样。 一个人把项目做大了，小改动却越来越难 他正在接触的一位客户，以独立开发者的身份做出了一个规模不小的项目。Yotov用自己所在的20多人团队作比较，形容这个项目已经相当庞大。 可项目越往后做，问题越多，过去很快能改完的地方，现在可能要花几小时；改好了这一处，另一处又坏了。 Yotov：以前几秒钟就能做的小修改，现在会花上几个小时，而且常常把系统里别的地方弄坏。
Yotov描述一位独立开发者的项目越做越大，后续修改却愈发困难 他把其中一个原因称为“上下文腐烂”：任务越长，塞给模型的代码、日志和要求越多，模型越可能抓不住当下真正相关的约束。 开发者不必记这个术语，想想接手陌生仓库时的情形就明白了：只看眼前的函数，你不知道旧接口为什么还在，也不知道隔壁服务是否依赖它；把整个仓库一股脑交给Agent，它也未必能自己找准重点。 他先让一个Agent找资料，再让别的Agent改代码 Yotov没有靠写一份更长的提示词解决问题。他把工单、Confluence文档、会议记录，以及过去处理任务时发现的约束收进项目知识库。需要动手时，一个被他称为“scout agent”的Agent先去找相关资料，执行任务的模型再据此判断要改什么。 Yotov：我做了一个侦察Agent。它会从工单、Confluence等资料里找出当前任务需要的信息，在模型需要更多背景时把这些内容取回来。
Yotov讲述如何用侦察Agent从项目知识库中取回相关信息 他还尽量把项目拆成边界清楚、通过简单接口协作的服务，并限定不同Agent各自负责的部分。假设四个模块都要适配一次接口变化，模型为了尽快让测试通过，可能在中间塞一层“大家都能用”的捷径，最后反倒打乱原来的分工。他不想让一个Agent同时捧着整个仓库、替所有模块作决定。 Yotov：参与构建的每个Agent，都有自己负责的代码区域；它们不去碰彼此的工作。
Yotov介绍把代码库分成相对独立的部分，再给Agent划定工作范围 这也是为什么“测试通过”在他这里还不够：测试能检查这次修改有没有满足写出来的要求，却不会替团队判断一个模块是不是被改得越来越难维护。 少看代码的代价，是需要花更多精力检查结果 说完这些，他抛出了视频里最容易引起争论的一句：自己现在已经很少去读Agent写下的代码。 Yotov：我现在大体上已经不怎么读代码了。我花了几个月搭建工具和流程，才慢慢对它们的输出建立信心。
Yotov谈自己的代码阅读习惯变化，并解释这份信任来自逐步搭建的工作流程 他举了一个正在做的界面项目：给Agent安排专门的流程，让它打开Chrome检查页面，发现错误后继续修，再交出PR。 起初他会亲自检查结果；连续看到几次符合预期后，就不再逐个重复相同的手工检查。 这里仍有一个需要开发者们自己掂量的地方：前三次符合预期，不能证明后续每次都可靠。尤其当代码会处理真实用户数据、支付或权限时，浏览器里看起来正常，但也不能代替必要的审查与上线验证。Yotov展示了这一做法，同时也留下了它尚未证明的边界。
Yotov讲述让Agent用Chrome检查界面、发现问题后继续修改的流程 机会不在多生成几页代码，而在解决自己项目里的难题 讲到最后，Yotov把“机会”落回到工程师手上。他建议开发者建立针对自己任务的评测：同一个工具，在你的项目里能否找对资料、守住模块边界、交出能用的改动？通用榜单不会替你回答这些问题。 Yotov：比什么都重要的，是建立自己的评测，看看工具交出的结果是不是你真正需要的结果，而不只看别人做的通用评测。
Yotov建议开发者用自身工作中的任务评估工具，而非只依赖通用结果 他也看好能改造的开源Agent工具，以及服务具体行业、具体团队的工作流程。这是他根据个人项目和客户经历作出的判断。对仍在团队里工作的开发者，一个更小的起点也成立：挑出反复出现、又总要人补背景的任务，看看资料缺在哪里、Agent容易越过哪条边界、结果该怎样验收。 他在Arm的那次求职，提醒他一家公司内部的熟练，不等于了解整个行业。现在他提出“40年一遇”，原因恰好是许多办法还没定型。会用工具的人越来越多；谁能让它在一个真实项目里持续把事情做好，仍需要有人亲自试出来。 开发者：机会是有了，岗位和兴趣怎么办 视频下方，有网友认同他所说的新机会，却问了一句很实在的话：机会很多，谁会付钱让工程师去追？也有人说，工程师担心的未必是AI本身，而是管理层不懂技术，却急着拿AI替换人。 另一位开发者提到，自己喜欢编程、打磨代码；如果连代码都不看，工作里最喜欢的部分也可能消失。
写在最后 Yotov说自己现在很少读代码，最容易被记住的是这半句话。但他花了几个月搭流程、检查结果，才敢把一部分工作交给Agent。省下逐行看代码的时间，不等于省掉判断。 他在Arm工作12年后才发现，自己熟悉的技术和外面的需求已经有了距离。今天用Agent也可能如此：代码生成得很快，开发者却未必知道它改动了哪些约束，下一次需求来了还能不能接着改。 “40年一遇”的机会是否属于每个人，现在没人能保证。至少可以从手上的项目开始试：找一项反复出现的任务，看看Agent在哪里找错资料、改错范围，或者交出了能运行却难以维护的代码。把这些问题弄明白，比多生成几页代码更接近Yotov说的那种机会。