AI Coding 最贵的不是写代码，而是决定什么值得验证
从 OpenAI 的数学突破，到 ETF Agent 几次真实的工程误判
AI Coding 正在让代码和候选答案变得越来越便宜，但可信的判断并不会随生成速度等比例增长。
我越来越觉得，工程师真正昂贵的能力，正在从“如何实现一个方案”，转向三个更重要的问题：
什么问题值得解决？什么假设必须被验证？什么程度的证据足以让我们作出决定？
这不是说人类要永远负责检查 AI 写出的每一行代码。恰恰相反，真正的进步应该是让机器承担越来越多能够自动验证的工作，把有限的专业判断留给那些真正决定系统价值与风险的地方。
最近两个月开发 ETF Agent 的经历，让我对这一点有了更深的认识。
一、当 AI 能够批量产生答案，我们真的更接近正确了吗？
2026 年 10 月，OpenAI 连续公布了大量 AI 生成的数学研究成果。
10 月 26 日，OpenAI 又发布了涉及 Kakeya 猜想、指数时间假设（ETH）和量子场论的研究成果。部分证明已经使用 Lean 进行形式化检查，但这些结果仍需要数学界进一步理解、审查和吸收。
在官方公告中，OpenAI 把模型生成的研究成果称为 Raw Research Data（原始研究数据），并邀请外部专家参与后续研究。
这个表述让我印象很深。
过去，一位数学家可能花费数年寻找一种证明方法。现在，AI 能够快速探索大量可能性，甚至生成复杂的完整证明。
但生成证明、检查形式化逻辑，与确认它证明了原本想证明的命题，仍然是不同的工作。
软件工程正在发生类似的变化。
Coding Agent 可以迅速实现功能、提出架构方案、补充测试，甚至让另一个 Agent 对实现进行评审。
原来因为开发成本太高而被放弃的想法，现在可能几个小时就能得到可运行的版本。
但我们是否因此更容易做出正确的技术决策？
最近两个月，我一直在集中使用 Agent 开发自己的 ETF Agent。随着功能越来越完整，我反而越来越明显地感受到一个变化：
我们越来越不缺少实现方案，却越来越需要判断一个看起来正确的方案，究竟有没有解决真正的问题。
而且，真正麻烦的往往不是 AI 生成了明显的错误。
是它生成了一个非常合理、甚至经过多项检查，却依然站不住脚的结论。
当生成答案越来越便宜时，识别关键假设、发现决定性反例，以及判断一个结果是否值得采用，就成了新的工程瓶颈。
二、一次真实投研：为什么报告完成了，结论却要撤回？
10 月 26 日，我们完成了一次 ETF Agent 的真实研究验证。
这次研究涉及后台执行、用户中途纠偏和并发对话。整个研究最终正常完成，原问题没有被其他短问题干扰，用户追加的要求也进入了后续模型请求。
从工程角度看，这是一次值得肯定的进展。
但人工复核最终报告时，我们发现模型根据两份文件的措辞，推断出一个结论：
某项跟踪约束比另一项严一倍。
这句话读起来很专业，甚至可能让人觉得模型进行了深入比较。
可问题是，原始材料并没有提供足够的同口径数据，来支持这个倍数判断。
两份文件描述了不同约束，不代表它们可以直接进行数量比较。
后续我们让 Agent 重新阅读一手文件，并撤回了这个推断。原始报告没有被悄悄覆盖，更正内容作为独立结果保存下来。
这次经历特别有代表性。
因为模型并不是没有查资料，也不是代码执行失败，更不是没有完成报告。
它真正出错的地方，是把两份材料中看起来可以比较的描述，变成了一个并没有得到证明的数量关系。
真正困难的是发现隐藏的前提
假设一份基金报告说“严格控制跟踪误差”，另一份报告给出了某项偏离度上限。
模型可能很自然地把它们放在一起，试图比较哪一个管理得更严格。
但熟悉金融指标的人会先问：它们是不是同一个指标？计算周期一样吗？一个是目标值，还是实际观测结果？
如果这些前提尚未确定，后面的计算再精确，也无法证明比较结论成立。
我们此前的持仓周报开发中，也遇到过类似问题：模型把子集收益率和全组合贡献百分点相互比较，甚至因为数值不同就怀疑供应商数据错误。
后来我们没有为这些错误额外建立一个万能的金融语义校验器，而是调整已有的金融研究指导，让模型先核对对象、时间窗口、分母和计算方法，再进行比较。
对于缺乏可比条件的资料，允许保留未知，而不是强行得出结论。
这项调整有过限定范围的真实模型验证，但没有因此宣布所有金融解释问题都已经解决。
这件事给我的启发是：
当 AI 给出一个结论时，先不要急着检查计算过程，应该先检查它用来推理的前提是否成立。
对于金融、医疗、法律等领域，这一点尤其重要。
有时候，真正昂贵的不是重新算一遍，而是知道哪些东西根本不应该放在一起计算。
三、再增加一个 Reviewer，真的能解决问题吗？
面对这种错误，最直观的工程方案是增加独立 Reviewer。
让一个 Agent 写报告，另一个 Agent 找错误。还不放心，就再增加几个专家，从不同角度讨论。
这当然可能有效。
但我们在 ETF Agent 中踩过另一个很有意思的坑。
10 月 18 日，我们在 Research Reviewer 的受控集成验证中发现：主 Agent 已经读取了完整资料，但传给 Reviewer 的摘要省略了重要的比较日期。
Reviewer 本身有独立上下文，也拥有读取原始结果的能力。
问题是，实际交接过程中，系统虽然调用了原始资料读取工具，却没有把读取出的完整材料交给 Reviewer，最终送进去的仍然是那份不完整的摘要。
换句话说：
我们建立了一个看起来独立的审查者，却没有真正为它提供独立审查所需要的信息。
如果 Reviewer 和原 Agent 都依赖同一份遗漏关键条件的摘要，即使它们给出一致意见，这种一致也不代表结论经过了充分验证。
后来我们的修复很简单：让原来已经读取且获准使用的材料真正进入 Reviewer 的输入，而不是重新发明一套数据获取和验证系统。
这次改动解决的是原始资料交接问题，不能直接推导为 Reviewer 的真实语义判断能力已经提高。
但它改变了我们对“验证是否有效”的理解。
过去，我们可能会问：
Reviewer 有没有调用成功？有没有输出评审意见？
现在，我们还需要问：
Reviewer 到底看到了什么？它有没有机会发现我们真正担心的那种错误？
这是两个完全不同的问题。
为什么我们后来没有让所有研究都强制经过 Reviewer？
10 月 21 日，我们又将引用与金融语义的事后评审设计为一种独立、按需使用的能力。
普通研究不必默认增加一轮审查。需要进一步复核时，可以针对一份明确的报告和原始材料，生成独立的评审结果。
评审可以指出疑点，却不直接修改原报告，也不自动取得发布和投资决策的权限。
这里其实有一个很现实的取舍。
一次真实调用可以帮助我们理解审查的投入。10 月 25 日，在一项受控协作验证中，独立 Reviewer 使用 deepseek-v4.1-flash 审查一条虚构投资论点，指出关于流动性和尾部损失的推断缺少前提。它只审查题面文字，没有读取外部资料，因此不是对现实投资事实的核验。
这次模型请求消耗了 6,963 个输入 token 和 5,586 个输出 token，从请求开始到完成约 51.6 秒。输入中有 4,096 个缓存读取 token，缓存写入用量未完整记录。运行记录没有可核实的费用和计价依据，因此实际费用仍然未知；单次请求耗时也不等于整份报告增加的等待时间。
一个样本说明审查需要额外的模型用量和时间，却不能说明按需策略节省了多少费用，或是否与全面复审具有相同的错误发现能力。高后果场景仍需要必要的审查；要比较策略，还需要在相同任务和评价口径下记录费用、延迟及错误发现情况。
如果用户只是查询某只基金的管理费，原始资料清楚、字段明确，增加多轮模型评审未必能带来相称的收益。
但如果 Agent 正在比较两个复杂的投资方案，并且其中某项结论会明显影响用户的资产配置，那么进一步复核关键假设就可能值得投入。
不是验证越多越好，而是验证需要与不确定性、错误代价和实际用途相匹配。
好的验证体系，不应该要求所有正常任务都证明自己绝对正确，而应该能够识别哪些判断真正值得额外检查。
四、但也不是所有验证，都应该交给人类
讨论到这里，很容易得出另一个极端结论：
AI 负责写代码，人类负责验证。
我并不赞同把它理解成一种永久分工。
因为验证能力本身也在被 AI 和自动化技术不断提高。
我们在 ETF Agent 的金融计算中，就遇到过一个很具体的例子。
对于一笔假设费用，137 元乘以 1.5% 的精确结果是 2.055 元。按照约定的舍入规则，应当得到 2.06 元。
但受控测试发现，旧的浮点计算路径曾经得到 2.05 元。
这类问题并不需要一个金融专家逐笔审核，也不需要调用更聪明的大模型重新判断。
我们需要做的是明确金额精度与舍入规则，让原始计算模块采用正确的十进制处理方式，再通过确定性测试检查。
这与前面的“跟踪约束严一倍”有本质区别。
一个问题已经有明确的数学规则，另一个问题连比较是否成立都需要判断。
如果一律使用 Reviewer，前者可能浪费成本，后者也不一定得到可靠结论。
真正合理的做法，是让容易形式化的正确性尽量交给机器，让有限的专业判断集中在难以直接形式化的问题上。
这也不是说金融语义永远只能由人处理。模型已经可以帮助提出反例、检查材料和识别不一致。
只是我们不能因为它能够给出审查意见，就把意见自动当成已经得到证明的事实。
五、对研发和架构师来说，工作方式应该怎样改变？
经历这些问题之后，我越来越倾向于改变 Code Review 和架构评审的起点。
过去，我们经常先看一个改动实现了什么，有哪些代码变化，补充了多少测试。
这些仍然重要。
但 AI Coding 时代，可以把更早的一步做得更明确。
先问：我们到底在证明什么？
比如一次需求叫“优化 Reviewer 的资料交接”。
这个说法太宽泛了。
换一种表达：
“Reviewer 在评估两份材料是否可比之前，必须实际收到原始比较日期。”
这样一来，真正值得验证的行为就清楚了。
我们不需要先写几十项检查，也不需要把完整研究重复运行很多次。
先构造一个摘要遗漏日期、但原始资料包含日期的场景，检查 Reviewer 实际收到的内容，就能直接检验这次修改的关键假设。
再问：什么反例能推翻这个方案？
这是我认为 Coding Agent 非常适合参与的一步。
人可以提出设计目标，Agent 则可以帮助寻找边界条件、生成反例、探索不同输入，甚至给出与当前方案相反的建议。
如果一个架构方案声称“多个 Reviewer 可以提高研究可信度”，我们就可以主动追问：
如果所有 Reviewer 都看到同一份错误摘要，会怎样？
如果它们引用了同一个过期来源，会怎样？
如果 Reviewer 无法取得关键原文，它会承认材料不足，还是继续生成自信的评审？
这些反例比简单要求 Agent “充分考虑各种情况”更有价值。
因为它们直接挑战方案赖以成立的前提。
最后问：证据到什么程度，就值得作出决定？
有些问题可以通过确定性测试直接解决。
有些问题需要在真实模型和相同输入条件下做对照。
还有些问题，例如某项投资分析是否足以支持具体行动，必须结合真实业务约束、风险和责任要求。
这三类验证不需要采用同一套标准。
真正重要的是知道：我们当前做出的决定，会产生什么后果？现有证据是否足以承担那个后果？
对一项低风险、可回退的内部研究功能，可以允许有限不确定性。
涉及资金执行、访问权限等高后果操作时，则必须保留明确的授权和执行保护，不能由模型一句“已经验证”来代替。
成熟的工程判断，不是要求所有事情都被验证到没有疑问，而是知道哪些疑问可以接受，哪些疑问必须在行动之前解决。
六、AI Coding 真正昂贵的，是判断力与验证资源
回到 OpenAI 最近的数学研究。
最让我受到启发的，不是 AI 生成了多少份证明，而是这些成果已经多到值得认真思考：应该怎样组织研究人员理解它们、核查关键假设，并把有价值的部分转化为可以继续使用的知识。
软件工程可能也会经历这样的变化。
以前，很多好的想法因为实现成本太高而没有机会验证。现在，我们可以快速得到越来越多的候选方案，但每一个方案都可能携带尚未发现的假设，也可能需要新的验证工作。
当答案的生产速度超过理解和判断的速度，继续提高代码产量，未必能让团队同比例地提高交付质量。
最近两个月 ETF Agent 的开发经历，让这个问题变得非常具体。
一份已经完成的金融报告，因为比较前提不成立而需要撤回结论；一个看起来独立的 Reviewer，因为缺少原始材料而失去了有效审查的基础；而一个精确计算错误，却可以在明确规则后交给确定性程序解决，根本不需要增加模型评审。
它们带来的启发是一致的：
不是所有问题都值得增加一层 AI，不是所有错误都需要更多测试，也不是所有正确性都必须依赖人的判断。
真正重要的是找到正确的验证方式，并让验证成本与问题的重要程度相匹配。
我认为，AI Coding 时代，工程师和架构师尤其需要把注意力放在三个地方。
第一，定义什么才算正确。 不只是把需求写成任务，而是识别业务目标、隐藏假设和必须保护的行为。一个比较是否成立，往往比比较公式是否算对更重要。
第二，知道怎样有效地推翻错误方案。 与其让 AI 不断生成支持现有设计的论据，不如让它寻找决定性反例。一个能够暴露关键错误的反例，可能比大量没有触及核心假设的测试更有价值。
第三，决定验证资源应该投入到哪里。 能用确定性方法解决的，交给工具；依赖复杂语义的，结合原始材料与独立审查；涉及资金、权限等高后果操作的，保留必要的授权、保护和责任机制。
这并不是让人类永远成为 AI 的最终裁判。
恰恰相反，随着模型、形式化方法和自动化技术进步，人类需要亲自完成的验证工作也会逐渐减少。
但只要软件系统仍然服务于现实中的用户和业务，就必须有人或一套具有明确责任的机制，决定我们究竟要实现什么、什么风险可以接受，以及什么时候值得采取行动。
AI Coding 降低了产生方案的成本，却不会自动降低作出错误决定的代价。
所以，未来优秀工程师的竞争力，可能越来越不体现在他能够亲自编写多少代码，而在于他能够让多少有价值的判断，被准确表达、有效验证，并最终转化为可靠的系统能力。
我们不应该再把研发效率简单理解成单位时间内生成多少代码、完成多少 PR，或者运行多少次测试。
真正值得追求的，是用更少的无效验证、更清晰的判断和更可靠的决策，持续解决更重要的问题。
当代码和答案越来越便宜，最昂贵的不是继续生产更多答案，而是能够回答：
什么值得做，什么值得怀疑，以及凭什么相信我们已经做对了。
这才是我认为 AI Coding 时代，软件工程能力真正需要升级的方向。
延伸阅读
- 代码越来越便宜，为什么系统却越来越难升级？：讨论创造、维护与架构演化的长期成本。
- 为什么 AI 明明有很多引用，回答还是不够可靠？：进一步讨论资料、引用和结论之间的关系。
- 金融 AI 最危险的“专业感”：金融数值、方法口径和可复算性的工程实践。
更多工程实践见 ETF Agent Engineering Notes。欢迎 Star 或分享能够挑战这些判断的工程反例。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
AI Coding is not about writing codes, but about deciding what is worth verifying.
From the mathematical breakthrough of Open AI to several real project errors by ETF Agent
AI Coding is making codes and candidate answers less expensive, but a credible judgment does not increase in proportion to the rate of generation.
I increasingly feel that the real expensive capabilities of engineers are moving from “how to achieve a programme” to three more important issues:
What's worth solving? What assumptions must be verified? What level of evidence is there to make a decision?
It's not that humans are always responsible for checking AI for every line code written. On the contrary, real progress should be to allow machines to take on more and more tasks that can be automatically validated, leaving limited professional judgement to those who truly determine the value and risk of the system.
The experience of developing ETF Agent in the last two months has given me an insight into this.
I. When AI is able to produce a lot of answers, are we really closer to correct?
In October 2026, Open AI published a series of mathematical research results generated by AI.
On October 26th, Open AI also presented publish research on Kakeya's guess, index time scenario (ETH) and quantum field theory. Part of it proves that Lean has been used for formalization, but the results still need to be further understood, reviewed and absorbed by the mathematical community.
In an official bulletin, Open AI referred to the results of model-generated research as Raw Research Data (raw research data) and invited outside experts to participate in the follow-up study.
I am impressed by this expression.
In the past, a mathematician may have spent years looking for a means of proof. Now, AI can quickly explore a lot of possibilities and even produce complex complete proof.
However, the production of certificates, the formalization of tests, and the confirmation that it proved what it was intended to prove, are still different tasks.
Similar changes are taking place in software engineering.
Coding Agent can quickly achieve functionality, propose architecture, complement testing, and even allow another Agent to evaluate its realization.
The idea of being abandoned because of the high cost of development could now be made operational in a few hours.
But do we make it easier to make the right technical decisions?
In the last two months, I've been focusing on the use of Agent to develop my ETF Agent. As the function becomes more complete, I become more and more aware of a change:
Increasingly, we do not lack programmes to achieve them, but we increasingly need to judge whether there is a real problem with a seemingly right one.
And the real trouble is often not that AI generated obvious mistakes.
It was it that produced a conclusion that was very reasonable, even after multiple examinations, but that was still untenable.
The identification of key assumptions, the discovery of decisive reverses and the determination of whether an outcome is worth adopting are new engineering bottlenecks when it becomes cheaper to generate answers.
II. A REAL INVESTMENT: Why is the report completed and the conclusions withdrawn?
On October 26th, we completed an ETF Agent real research validation.
The study involved back-office implementation, user bias and simultaneous dialogue. The entire study was completed normally, the original problem was not disturbed by other short questions and additional user requests entered the follow-up model request.
From an engineering point of view, this is a positive development.
However, when the final report was manually reviewed, we found that the model derived a conclusion based on the wording of both documents:
One is twice as tight as the other.
It's a very professional reading, and it's probably even a good comparison.
The problem, however, is that the original material does not provide sufficient data of the same calibre to support this multiplier.
The two documents describe different constraints and do not imply that they can be directly compared quantitatively.
Then we got Agent to reread the first-hand file and retract the inference. The original report was not covered quietly and the corrections were kept as independent results.
The experience was particularly representative.
Because the model does not lack information, nor does it fail to implement the code, let alone complete the report.
It really went wrong by making a seemingly comparable description of the two materials into an unproven quantitative relationship.
The real problem is to discover the hidden premise.
Assuming that one fund reported “strict control over tracking errors”, another report indicated a certain deviation limit.
Models may naturally put them together in an attempt to make them more stringent.
But those who are familiar with financial indicators ask first: Are they the same indicators? Is they the same as the calculation cycle? Is the target value or the actual observations?
If these prerequisites have not yet been established, the later calculations cannot prove the comparative conclusion.
Similar problems have been encountered in our previous development of the warehouse Weekly Report: the model compares the sub-assembly rate of return and the percentage point of total contribution, even because of differences in values, which cast doubt on vendor data errors.
Instead of creating an additional altruistic financial calibration for these errors, we have adapted the existing financial research guidance to allow models to check objects, time windows, denominators and calculation methods before comparison.
In the absence of information on comparable conditions, it is permissible to retain the unknown rather than to impose conclusions.
This adjustment was validated by a genuine model with limited scope, but did not lead to the announcement that all financial interpretation issues had been resolved.
I was inspired by this:
When AI comes to a conclusion, do not rush to check the calculation process, but check whether the premise it uses for reasoning is valid.
This is particularly important in the areas of finance, medicine and law.
Sometimes it is really expensive not to recalculate, but to know what should not be counted together.
III. Add another Reviewer. Can you really solve the problem?
In the face of this error, the most intuitive engineering option is to increase independent Reviewer.
Let one Agent write the report, the other Agent find the error. It was not safe to add a few more experts to the discussion from different perspectives.
This, of course, could be effective.
But we stepped on another interesting pit in ETF Agent.
On October 18, we found in the controlled integration of Research Reviewer that the master Agent had read the complete information, but summary, which passed on to Reviewer, omitted an important date for comparison.
Reviewer itself has an independent context and the ability to read the original results.
The problem is that during the actual handover, the system did not deliver the full material read out to the Reviewer, even though it used the original information reading tool, and the incomplete summary was eventually sent in.
In other words:
We have established a seemingly independent reviewer, but we have not really provided it with the information it needs for independent review.
If the Reviewer and the former Agent both relied on summary, which was the same missing key condition, even if they agreed, that agreement did not represent a sufficiently validated conclusion.
And then our repairs were simple: to actually get the materials that were read and approved for use into the Reviewer input instead of re-engineering a data acquisition and validation system.
This change addresses the problem of the transfer of raw materials, which cannot be directly extrapolated to the improved capacity for authentic semantic judgement of Reviewer.
But it changes our understanding of “validity”.
In the past, we might ask:
Reviewer, did you get a call? Is there an output review?
Now, we need to ask:
Reviewer, what did you see? Does it have a chance to discover the kind of mistake we're really worried about?
These are two completely different issues.
Why didn't we have all the studies forced through the Reviewer?
On 21 October, we also designed an independent, needs-based capacity for ex post evaluation that refers to financial terms.
It is not necessary for a general study to implicitly add another round of reviews. Where further review is required, independent evaluation results can be generated for a clear report and source material.
The evaluation could point to doubts without directly modifying the original report or automatically obtaining publish and permission for investment decisions.
There's actually a real trade-off.
A real call can help us understand the input of the review. On 25 October, in a controlled collaborative validation, independent Reviewer used deepseek-v41-flash to review a fictional investment argument, pointing to the lack of assumptions about liquidity and tail losses. It reviews only the subject-matter text and does not read external information and is therefore not a validation of actual investment facts.
This model request consumes 6,963 inputs token and 5,586 outputs token, from the start of the request to completion of approximately 51.6 seconds. In the input, 4,096 cache reads token, cache writes in incomplete records. The operating records do not have verifiable costs and a basis for pricing, and the actual costs are therefore still unknown; the time required for a single request is not equal to the additional waiting time for the entire report.
A sample indicates that the review would require additional model volumes and time, but does not indicate how much cost savings were achieved on a needs-based basis or whether it would have the same capability as a full review to detect errors. High-impact scenarios still required the necessary review; comparison strategies also required recording costs, delays and errors under the same mandates and evaluation.
If the user merely enquires about the overheads of a fund, the source information is clear, and field is clear, adding multi-wheel model evaluations does not necessarily lead to a proportionate gain.
However, if Agent was comparing two complex investment options, and one of the conclusions would have a clear impact on the asset allocation of users, further review of key assumptions might be worthwhile.
Not as much certification as possible, but it needs to match uncertainty, error costs and actual use.
A good certification system should not require that all normal missions prove themselves absolutely correct, but should be able to identify which judgements really merit additional scrutiny.
Four, but not all of it. It's human.
So far, another extreme conclusion can be drawn:
AI is responsible for writing codes, and humans are responsible for verifying.
I do not agree with its interpretation as a permanent division of labour.
Because the authentication capacity itself is being upgraded by AI and automated technology.
We've had a very specific example in ETF Agent's financial calculations.
For a hypothetical cost, the exact result of $137 multiplied by 1.5% is 2.055. In accordance with the agreed rounding rule, the sum of 2.06 dollars shall be received.
However, controlled tests found that the old floating point calculation path once received 2.05 yuan.
Such issues do not require a financial expert to review them individually, nor do they need to be re-judged with a smarter LLM.
What we need to do is to clarify the accuracy of the amount and the rounding rules so that the original computing module uses the correct decimal treatment, which is then checked for certainty.
This is essentially different from the previous “twice of the tracking constraints”.
One issue already has clear mathematical rules, and the other requires a judgement as to whether the comparison is valid or not.
If Reviewer is used consistently, the former may be a waste of cost and the latter may not necessarily be reliably concluded.
It would be truly reasonable to leave to the machine, as far as possible, the correctness of easy-to-formatization, and to focus limited professional judgement on issues where it was difficult to put it directly.
Nor does it mean that financial semantics can always be handled only by people. Models can already assist in the development of cross-references, examination of materials and identification of inconsistencies.
It is only because it is capable of giving a review that we cannot automatically regard it as a proven fact.
V. How should the working methods change for R & D and architects?
After these problems, I have become increasingly inclined to change the starting point of Code Review and the architecture review.
In the past, we often looked first at what a change had been made and what code changes had been made and how many tests had been added.
These remain important.
But in the age of AI Coding, one could make an earlier step clearer.
Q: What are we proving?
For example, a request is called "optimizing the transfer of information from Reviewer."
This statement is too broad.
In other words:
“Reviewer must actually receive the original date of comparison before assessing whether the two materials are comparable.”
That would make it clear that there was a real act worth proving.
We do not need to write dozens of tests first, nor do we need to repeat the full study many times.
The key assumptions of this change can be directly tested by first constructing a scene of summary missing dates, but the original data contains dates, checking what Reviewer actually received.
Q: What is the countermeasure to overturn this program?
This is a step that I think Coding Agent is very suitable for participation.
A person can propose design objectives, and Agent can help to find boundary conditions, generate reverse examples, explore different inputs, and even give suggestions contrary to the current scheme.
If a framework proposal claims that “more than one Reviewer can enhance the credibility of the study”, we can ask:
What happens if all Reviewer sees the same error as summary?
What if they cited the same expired source?
If the Reviewer is unable to obtain the key originals, will it acknowledge that the material is insufficient or will it continue to generate confident reviews?
These retrospects are more valuable than simply requiring Agent to “take full account of the circumstances”.
Because they directly challenge the premises upon which the programme is founded.
Finally, to what extent is the evidence worth deciding?
Some issues can be addressed directly through certainty tests.
Some issues need to be compared with real models and the same input conditions.
There are also questions, such as whether an investment analysis is sufficient to support specific actions, which must be combined with real business constraints, risk and liability requirements.
The three types of certification do not require the same set of criteria.
What is really important is to know: what are the consequences of our current decisions? Is the available evidence sufficient to bear that consequence?
Limited uncertainty may be allowed for a low-risk, rollback internal research function.
When it comes to high-impact operations such as the execution of funds, visits to permission, it is necessary to retain a clear mandate and enforcement protection, which cannot be replaced by a model sentence “verified”.
A mature engineering judgement does not require everything to be tested to be unchallenged, but rather to know which questions are acceptable and which must be resolved before action is taken.
VI. AI Coding is really expensive. It's judgment and validation resources.
Back to Open AI's recent mathematical research.
What I am most inspired by is not how many certificates AI has produced, but how many of them are worth thinking about: how to organize researchers to understand them, verify key assumptions, and translate valuable parts into knowledge that can be used.
Software engineering may also experience such changes.
In the past, many good ideas had not been validated because of the high cost of achieving them. Now, we can quickly obtain more and more candidate programmes, but each of them may carry undiscovered assumptions and may require new validation.
As answers are produced faster than they are understood and judged, continuing increases in code yields do not necessarily allow teams to improve the quality of delivery on a proportional basis.
The development experience of ETF Agent in the last two months has made the issue very specific.
A completed financial report, which needed to be withdrawn because the comparative premise was not valid; a seemingly independent Reviewer, which had lost the basis for effective scrutiny because of a lack of raw materials; and an accurate computational error, which could be resolved by a definitive procedure after clear rules, did not require any additional model evaluation.
Their inspiration is consistent:
Not all problems are worth adding a layer of AI, not all errors require more testing, and not all validity must depend on human judgment.
What was really important was to find the right form of certification and to match the cost of certification with the magnitude of the problem.
I think that the AI Coding era, engineers and architects need to focus on three places in particular.
First, what is the correct definition. It is not just a task to write needs, but rather to identify operational objectives, hide assumptions and behaviours that must be protected. Whether a comparison is valid or not is often more important than comparing the formula.
Secondly, know how effectively to reverse the wrong formula. Instead of allowing AI to constantly generate arguments in support of existing designs, it should be able to find a decisive reversal. A contrario capable of exposing critical errors may be more valuable than a large number of tests that do not touch core assumptions.
Thirdly, it was decided where certification resources should be invested. It is provided with tools that can be resolved in a definitive manner; it is based on complex semantics, combined with raw materials and independent reviews; and it involves high-impact operations such as funding, permission, which retain the necessary mechanisms for delegation of authority, protection and accountability.
This is not to make humanity the final decision of AI forever.
On the contrary, with the advancement of models, formalization methods and automation technology, the validation work that human beings need to perform in person will diminish.
But as long as software systems continue to serve actual users and operations, there must be someone or a mechanism with clear responsibilities to determine exactly what we are going to achieve, what risks are acceptable and when they are worth taking action.
AI Coding lowers the cost of generating the program, but does not automatically reduce the cost of making the wrong decision.
Thus, the competitiveness of a good future engineer may increasingly not be reflected in the number of codes he can write in person, but rather in the number of valuable judgements he can allow to be accurately expressed, effectively validated and eventually translated into reliable system capabilities.
We should not simply understand R & D efficiency as how many codes are generated in unit time, how many PRs are completed, or how many tests are run.
What is truly worth pursuing is the continued resolution of more important issues with less ineffectiveness, clearer judgement and more reliable decision-making.
When codes and answers become cheaper, the most expensive is not to continue producing more answers, but to be able to answer:
What's worth doing, what's questionable, and what's to believe we've done right.
That's where I think the AI Coding era of software engineering really needs to be upgraded.
Extended reading
- The code is getting cheaper, why is it harder to upgrade the system? : discuss the long-term costs of creating, maintaining and architecture evolution.
- Why, does AI have a lot of quotes and answers or not reliable enough? : further discuss the relationship between information, citations and conclusions.
- Financial AI's most dangerous “professional sense”: financial values, methodological calibres and recalcitrant engineering practices.
More engineering practice can be found in ETF Age Engineering Notes. The Star or sharing of works that can challenge these judgements is welcome.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.