🧭 The real Agent bottleneck is not coding. It is verification
Zhihu contributor 杨军 shared a grounded reflection on Agent technology from the perspective of someone building AI infrastructure and using Agents in real workflows.
The core idea is simple: Agents are a real productivity leap, but they do not remove engineering boundaries. They change where the hard work moves.
1️⃣"Disposable software" depends on verification
A popular idea today is that Agents will make software “disposable.”
There is truth in that. For one-off scripts, internal tools, temporary dashboards, data conversion jobs, and low-risk prototypes, Agents can make it cheap enough to build something new instead of extending an old system.
But the author argues that the real boundary is not writing cost. It is verification cost.
Agent-generated code may be cheap to produce, but someone still has to know whether it is correct, whether it affects upstream or downstream systems, whether it touches data safely, and whether anyone can maintain it later.
So the better rule is:
If rewriting and verifying a new tool is cheaper than modifying and verifying an existing system, “disposable software” makes sense.
If the new tool is harder to verify than the existing system, it is not disposable. It is just hidden technical debt with a faster creation path.
The deeper point: Agents reduce the cost of “writing,” but they do not automatically reduce the cost of “trusting.”
2️⃣Production use fails at uncertainty, not syntax
The hard part of putting Agent-written code into production is not whether the Agent can write code.
It can.
Often very well.
The hard part is uncertainty.
A coding Agent is a non-deterministic tool. Slight changes in prompt, context, model version, tool output, or runtime behavior can change the result. For a small task, that may not matter. For a multi-step production workflow, small differences can compound.
The context problem is just as important. An Agent does not see the real system directly. It sees a window of code, docs, logs, test output, tool calls, and search results. That window may be partial, stale, noisy, or internally inconsistent.
Execution adds another layer. In high-performance computing, databases, trading systems, inference engines, training frameworks, and distributed systems, details like concurrency, caching, GPU floating point behavior, scheduling, and random seeds can matter a lot.
For a demo, these differences may stay invisible.
For production, they are often exactly where failures come from.
3️⃣Reward hacking becomes easier to scale
The author gives a sharp example from AI infrastructure.
Asking an Agent to generate a kernel that beats a baseline is very different from asking it to generate a production-quality kernel that is faster, correct, maintainable, and robust across shapes.
The first task can be gamed.
A kernel might win on one benchmark, one input shape, or one narrow performance target. It looks successful because the reward was incomplete.
The second task is what production actually needs.
This is the hidden trap of Agent workflows: the Agent optimizes toward the target you specify, not necessarily the requirement you meant. If the acceptance criteria fail to capture correctness, edge cases, long-term maintainability, or architectural invariants, the Agent may produce something that passes the test while breaking the system.
Humans can reward-hack too. The difference is that Agents can do it faster, at larger scale, and with outputs that look polished enough to pass a shallow review.
That makes the failure mode easier to miss.
4️⃣A running demo is not a production system
Agents make it much easier to create something that runs.
That is powerful. It is also risky.
A product or business person can now use an Agent to create a convincing demo in a few hours: a page, an API, a workflow, maybe even mock data. From the outside, it may look close to done.
But a demo and a production system are different objects.
Production software needs permissions, data consistency, exception handling, monitoring, logging, deployment, rollback, compatibility, scalability, and long-term ownership. More importantly, it has to be understood and maintained by a team.
Agent-generated code can also shift cost downstream. If everyone can generate PRs faster, CI load increases, review pressure rises, duplicated patterns spread more quickly, and repo consistency becomes harder to protect.
Demo speed does not show these costs. A demo has no long repo history, no multi-team ownership, no accumulated constraints, and no future maintenance burden.
A production system has all of them.
So one of the biggest risks is organizational: Agents can make non-engineering roles underestimate engineering complexity. The old signal of difficulty was “I cannot build this.” Now the demo runs, so the remaining work becomes easier to misread.
5️⃣Human-in-the-loop should become harness
The author’s most useful suggestion is to turn repeated human intervention into harness.
Many “human-in-the-loop” steps are really workflows that have not been encoded yet. When humans correct an Agent, they often add missing context, define boundaries, block unsafe paths, clarify acceptance criteria, or check edge cases.
Some of that should become rules, scripts, tests, CI gates, benchmarks, review checklists, or custom harnesses.
A mature Agent workflow may not be “a human watches the Agent forever.”
It may become a two-layer system:
a custom harness controls what the Agent can and cannot do;
a general coding Agent works inside that controlled boundary.
In this setup, engineers still need strong code judgment. But their value shifts upward. They decompose systems, define validation paths, design feedback loops, and integrate Agent output safely.
The job becomes less about typing every line and more about making the system legible, bounded, and verifiable.
6️⃣Agents expose weak engineering foundations
The deeper impact of Agents may not be that they help people write more code.
It may be that they force engineering systems to become more explicit.
Many systems still rely on human memory. A senior engineer knows why a module was designed a certain way, why a test should not be touched, why a parameter is dangerous, or why one customer path is special.
Agents do not know what has never been written down.
They act on code, docs, tests, logs, and tool output. If those signals are incomplete, the Agent’s behavior becomes harder to trust.
So using Agents well is not just about buying better tools or upgrading models. Teams need clearer module owners, cleaner interfaces, stronger CI, better tests, structured documentation, explicit acceptance criteria, stable dev environments, and traceable changes.
These sound like old engineering basics.
That is exactly the point.
The boring foundations decide whether Agents become reliable production infrastructure or stay at the level of impressive demos.
✅ The real takeaway
Agents are powerful. The productivity gain is real.
But they are still a technology, not magic. They have suitable use cases, failure modes, boundary conditions, and cost structures.
The dangerous move is to use Agents as an excuse to skip engineering discipline, compress normal schedules, or bypass validation.
A better framing is this:
Agents are a lever, not a silver bullet.
A lever amplifies what already exists. Strong systems get faster. Messy systems get messier. Good validation makes Agents safer. Weak validation lets “it seems to run” masquerade as “it is done.”
The right posture is neither worship nor rejection.
Use Agents to push the boundary.
But do not pretend the boundary has disappeared.
🔗 Full analysis:
zhuanlan.zhihu.com/p/2055782…
#AIAgents #CodingAgents #AIInfra #SoftwareEngineering #DevTools #LLM #AgenticAI
