关于coding agent与实际软件开发的一点思考

实习已有一个半月之久，得益于公司提供的不错的开发环境，让我在这个疯狂的ai时代下搭上了顺风车。现在我的团队倡导业务代码百分百ai率，无论是理解成本，还是时间上，效率都相较传统开发有了较大的提升，在实习期间也对于大模型以及其衍生的业务范围有了更深的了解，现在想专门写一个blog来表达一下自己的想法，对近期的学习与工作做一个总结和更深层次的思考（第一次写blog，很值得纪念）。

ps：以下内容均为博主古法手写，使用ai调整格式，保证原汁原味。

coding agent确实降低了开发门槛

实习第一天，我的mentor就告诉我，我们的开发工作要完全使用coding agent工具，包括业务功能设计方案，代码实现，测试，修bug等等。当我听到公司token管够，开发配mac电脑，我觉得我应该留下，来试一试这种被狂热裹挟的开发模式。

我在接手实习工作之前，也接触过coding agent工具来辅助自己的学习工作了，包括cursor，trae，opencode等，没用claude code的原因还是账号，网络和中转站花费的问题，也尝试过国产模型厂商推出的coding plan的方法来辅助自己使用ai工具，但出师未捷身先死（让mimo token plan独特的计费方式给坑了一把），这里有机会也会开个贴来讲述一下自己在这方面遇到的一些坑。

但好在公司的运维部门与外部合作，会为每一个员工开一个api key，这样就claude，gpt模型就随便用了，借此我也能使用claude code，codex这种行业前沿的coding工具。

这一段时间使用下来，让我体会最深的就是对于软件开发人员来说，这类coding agent降低了他们的开发难度与时间成本，尤其对于应届生刚参与到公司的工作流程来说，理解成本往往是接入公司业务过程中最大的阻碍所在。对于一个中大型项目来说，新人往往需要一个月左右的时间来熟悉项目代码，业务架构，中间件接入方式，数据表等等，但有了大模型加持的coding agent，开发人员只需要自己写好提示词，使用网络上他人已经写好的skill，公司自己开发的mcp，你就可以在不到几小时的时间就对你负责的项目了解个大概，这在2025年之前貌似还是个天方夜谭的事，25年之前可能我们还是在慢慢将业务核心代码放到chat界面，问大模型“这段代码实现了个啥”，而在当下，我们只需要在vscode中，终端启动claude，codex，问一句“阅读项目代码，为我讲清这个项目”，这貌似比一个专门的mentor给你讲个一下午要舒服得多，毕竟你也只需掌握个——大概，就好了。

第二个开发门槛体现在中间件的学习成本上。传统开发在入职前，你尽管可能都完全没掌握，甚至没接触过你岗位jd上要求的“docker，k8s，nacos”等等乱七八糟的中间件要求，找工作的同学也大多就是背背八股有些基本概念就好了，毕竟谁会记那一大长串不通用的命令行命令和语言呢，真的有人会使用redis时候去学习他那个破烂语句吗？至少我觉得，在现在，这些成本我们都不必去承担了，大模型都可以帮我们做了，开发人员现在要做的只是搞懂某个中间件的原理和特性，在什么样的业务场景下能做什么样的事，引进来预计会给业务带来多大的便利和提升，至于实施细节，现在看完全不必关注了。

降低了开发门槛，那解放了开发人员吗？未必

如果说软件开发的本质就是人类经过思考后开始敲键盘，编辑文本，那么现在coding agent介入到开发流程中，我想没有对这种范式带来根本上的转变。唯一不同的是原来开发人员在写代码，现在在敲prompt，写skill，就是这么简单。

在使用coding agent的过程中，不可避免地会踩一些坑，以我自身举例：

1. 功能实现漂移——由于模型上下文能力以及自身能力有限，不能做到很好的指令遵循效果，在实现的过程中会与开发人员的意图相违背
2. “70%困境”仍然存在——至少在我看来，现在的coding agent，确实可以满足项目要求的70%，甚至80%的开发要求，但不管怎么样还是或多或少有bug突然冒出来恶心你一下，这时候我能做的也就是将这个错误从业务场景拆成文字来喂给agent，写成提示词，在这个过程中，我或许成了ai的多模态转换器吧
3. 时间效率是提升了，但并不是对开发人员的解放——单位时间内开发人员借助coding agent工具，确实较原来完成工作要多，原本三周从需求评审到正式上线的功能，现在可能只缩短到了一周。对于经验丰富，对项目熟悉的老员工来说，这个速度只会更快。但在团体下的软件开发工作，仍逃不掉“人月神话”的魔咒，甚至由于coding agent的漂移行为，你可能会顺手将你同事原本负责的工作给干完了，这给现在的团队分工也留下了极大的困难。分给谁，分多少，这也体现出这个团队中产品经理的水平，合理分配自然万事大吉，但你的产品经历如果是二把刀，那将会给整个团队的开发流程带来灾难。
4. 开发人员实际更累了——在实际体验过程中，我发现更费神了，使用coding agent确实能够完成大部分的工作，在ai写代码的时候，我通常给ai最大的权限，让他自己去运行，我会刷点短视频或者干一些自己的事儿，但干自己的事儿也不太踏实，偶尔出现的漂移现象是我们不能接受的，这个时候只好直接打断ai，之后看他都干了什么，看别人的代码是一件很痛苦的事，看ai的也不例外，有些时候vibe coding的过程对于我们来说就是黑盒，我们不知道某个功能他采用了什么思路来实现的这个功能，导致他自己写的单元测试他自己都能通过，但是真去实际使用，或者部署到了生产环境，总会出现这样那样的错误，bug就像打地鼠一样，修完了一个来另一个，这个过程其实对于开发人员来说就更费神了。

如何看待现阶段的coding agent？

无论是ai巨头们提出的harness engineering，memory，skill等等怎样的概念，基于transformer架构变体的这些大模型，其本质工作机理——自回归模型，逐token进行输出这个事情，目前来看短时间内无法被颠覆，这其实不太符合我们人类平常的思考方式，离真正的类人效果我认为还是一定的距离。

因此一些不太重要，用户容忍度高或者数据出错也不耽误正常运行的业务，这类用coding agent工具一点问题都没有，极大地解决了开发人员深处crud泥淖的烦恼。那对应的，业务重要，容忍度低，如自动化交易，金融，用户身份信息等业务，这类的业务代码需要人类专家进行逐行review，才能保证上线。

coding agent开发确实是极大地帮助了开发人员，提升了他们的工作效率，但本质上的开发范式没有改变：原来可能是在敲业务代码，现在可能是在编写自然语言，实际上都是通过人类在产生字符，但这种逐token生成的大模型范式我觉得在以后还是要被取代的，人类的思考方式以及输出完全不是这种方式，人类在说一些话时，分为本能输出和思考后输出，本能输出或许是需要将前一个token作为信息，加入到上下文中来参与下一个token的生成。但人类再经过思考，脑海中会列一个大纲或蓝图，真正输出出来是依靠这个大纲来填补内容的，至少我的直觉是这样，没有经过任何论文或者是生物生理学上的知识验证，仅供大家参考，看一乐。

所以我觉得

大模型能力是足够强了，但不是某些巨头说的，真的强到只要注意harness，只要注意其他的配套工程就好了，至少在我的实际体验中，不是这样的，真正的AGI也不应该沦为prompt工程，让每个人都变为prompt工程师。我想象中的ai，应该是，“去，把我要干的事情全替我干了。”，他如果真的干好了，我觉得这才是我想象中的真正意义上的人工智能