我已经差不多两年没亲手写过真正的代码了。我不介意。总体是赚的。但我确实觉得,比起老一套的手工做法,我在烂主意和坏掉的想法上折腾的时间变长了。手工的试错过程,还有那一整套排障。
新做法带来一个相当严肃的问题:智能体要么不知道你的想法坏掉了,要么知道了也不说。你可能早点发现,也可能发现不了。
但少了人工流程里的那些试错,你确实冒着高得多的风险,撞上那种只能把应用大段大段推倒才能解决的架构问题——因为你在一开始就把前提假设错了。
关于智能体编码,一个常见的抱怨是:「智能体能带你走完80%的路。然后你要花一辈子才能把它弄对。」
顺带一提,上面说的就是原因。
TDD 确实有用。
但流程本身的变化已经足够大,生出了这些新的问题类别。
有一点我要说:估算项目这事儿比过去难多了。在老日子里,我对自己速度的手感相当准。而且我知道,把我的直觉乘以 1.241,结果通常距我的估时只有三小时上下。
今天,我的速度变得飘忽,因为智能体会犯大错。而我永远不知道错会出在哪儿。
拿今天来说。我在搭一套新的工单系统。有个依赖是项目一开始就画好的。它依赖 Java 25,这就出了问题,因为我系统里只装了 Java 21 的工具链。
好吧,知道了。
新问题:我的智能体们确实注意到了。但它们没在项目一开始就来找我,而是决定绕开这个问题写代码——弄出一堆冗余的基建,害我现在得钻进去,按原始需求把它们合并掉。
这事就这么发生了,尽管我明确提示过、明确吩咐过,不许智能体们干这种事。
是我的错吗?
是,百分之百。我该更懂的。
这类事,大多数其实都算某种程度的用户错误。
但我确实觉得,它们本该提一嘴的。
「嘿,我们已经在绕着它写了,因为你给我们的系统没法编译这条需求。」
说一声就好了。
这玩意儿后头的收尾,能给我省下好几个小时。
有时候,我觉得自己的 QA 技能用得比老系统时代更狠、更勤。
但就是这样。既然你永远不知道混乱什么时候、从哪儿砸下来,基于你当前速度的简单估时,已经不像从前那样靠得住了。
这个问题,我还没想出解法。