代码是你的，但你不真正拥有它们
如果你只在乎端到端的可用性，或者你永远都不打算自己对代码做大幅的修改，那么这没问题。如果不是，你最好再想想清楚。机器改的每一行代码我都audit, 目前发现有这么些特性。
a. 他生成的代码会过度包装，比如：
let condition1 = xxx
let condition2 = xxx
我们自己写，在代码里就会写if condition1 and condition2, 但机器帮你写，他会给你再声明一个变量
let condition3 = condition1 and condition2
代码里就会写成 if condition3 …
这造成的问题是人在阅读的时候多了一次look up，这种情况一多，你就晕了。
函数也类似，本来50行能解决的事情，他要给你拆开，调来调去。
b. 匪夷所思的变量名。机器自己“理解“你的业务生成的变量名往往让你完全莫不着头脑。你要去查代码，想象一下，如果很多变量名字都这样，你怎么维护？如果对业务理解不是100%透彻的同事，他需要花多少时间能看懂？
举例：我有个最新样本时标，机器给我取个名字叫watermark，我想这tm什么玩意儿，我制定了一个规则，让机器不准给我发明terminology，这他才给我改成newest sample timestamp，这make sense, 但机器为什么第一次给我搞个那么fancy的名字。
c. 我给他增加各种规范来约束上面的问题。
问题是，约束不要钱的吗？我现在问一个问题（一次代码audit会对机器的修改提出5-10点意见和质疑）就能消耗900 credits。 这没法在真实生产环境下使用。一方面是费用，另一方面是这拖累了整个推理的速度。
d. 代码质量
端到端的功能实现并不糟糕，已经达到了可用。但业务pipeline比较长时，是不如一流模型的。他不是不能帮你解决，是要花好几个turn/human verification才能帮你解决。
举例：我一个数据处理的pipeline，大概3,4个流程，机器发现问题跑了1个小时没找到问题。我提示：从数据源开始，核对每个unit in pipeline’s input/expected output， 他就找到了。
所以和一流模型的差距会在好几个地方体现。除了大家诟病的挣着人民币花着美元的收入差距外，
- 一流模型解决问题消耗的算力更少，速度更快，即使token定价完全相同，依然是一流模型更便宜，而且这种便宜可能不是小幅度的8/9折能解决的，真实差距可能在1折-5折之间。
e. c实际上引入了真实的系统性风险
机器的代码，看起来注释很多，实际上是为机器优化的，并不是为人audit优化的。这意味着如果你做了一个项目，也不用很大，10万行的规模吧，你已经失去的实际的掌控。如果项目是一次性的，这没有问题。但如果是一个有延续性的产品，那么你实际上失去了不少维护能力，credit的价格不管涨到多少，你都得给，除非你打算重新配置足够的人天数来重构这些机器生成的代码。一定会有不少公司踩坑。
Solution
我觉得这也不能算是一个bug吧，甚至都不能叫做产品质量问题，应该算是产品的理念。你要做什么样的事情。
在真实生产环境中，我相信99%的用户都不会花这个时间去对机器改的每一行代码都audit，这是无法计入KPI的事情，保证输出符合spec就够了。所以屎山粪海依然，只不过差在是是谁拉的。
Use Case
When would you use this?
Priority
-
High - Blocking issue -
Medium - Important improvement -
Low - Nice to have
Additional Info
(Optional: screenshots, examples, links)