智能体
dev.to ·
@Kent Alstad
Agentic 开发中的最后一公里问题
文章指出,agent 已让软件开发的前 80% 变得很快,但最后 10% 到 20% 的收尾工作——边界情况、集成接缝、失败模式,以及从“demo 能跑”到“真正可用”的差距——仍然依赖人类评审、验证和判断。当数百个 agent 同时产出时,少量人类难以完成对应的收尾工作,形成规模上的不匹配。
AI推荐理由 文章聚焦 agentic development 中一个具体痛点:agent 能快速完成前 80% 的工作,但最后 10% 到 20% 的收尾——边界情况、集成接缝、失败模式、从 demo 可用到真正可用——仍依赖人工评审与判断,导致数百个 agent 的产出与少量人类收尾能力之间出现规模失衡。属于经验性观察与观点,没有给出量化证据,但问题定义清晰,对 Agent 工程落地有参考意义。
64
正文
Agents have made the first 80% of building software fast. Point enough of them at a well-defined problem, and you get working code, passing tests, and a system that looks almost done, sometimes in hours.
Then you hit the last 10 to 20%.
That's where I think the biggest problem facing agentic developers lives today: getting from 80 or 90% done to 100%. Not generating code, but hardening an idea all the way to completion. Edge cases, integration seams, failure modes, the gap between "it works in the demo" and "it works."
The math stops working
Here's the trouble. When hundreds of agents are building your system, they produce work at a scale no human can match. That's the point. But the last mile has traditionally been human work: review, verification, judgment about what "done" actually means.
So you end up with hundreds of agents producing output and one person, or a small team, trying to do the finishing work for all of them. You don't have the time to do the work of the hundreds. The bottleneck isn't building anymore. It's completing.
I hit this wall at KandiForge. Our agents had produced millions of lines of code across 20 repos, and I needed to ship. But how?
It wasn't a knowledge problem. I understood the requirements. I understood the architecture. What I couldn't do was work through every final detail across a codebase that size. There were simply too many of them, and each one needed the kind of attention that doesn't scale with the number of agents producing the code.
The agents had made building fast. They hadn't made finishing any faster.
Why "just review more" doesn't fully solve it
My first move was the obvious one. I added more reviewers and more testers, both agents and people.
The testers used agents to write tests, but generally after the code was already integrated. So the change gates weren't in the right place. By the time a test caught something, the change was already in.
I don't think anyone has fully solved this yet, myself included. We're all still working on it. That's part of why I'm writing this series: to share what we're trying at KandiForge, and to hear what's working for others.
What comes next
Over the next few posts, I'll share behind-the-scenes notes from how we're tackling this at KandiForge, where we build with an agent factory that follows an evidence-based SDLC across multiple repos. Some of it has worked. Some of it hasn't. I'll share both.
This series leads up to my talk at #BuildStuff15 in Vilnius this December (@buildstuffconf, buildstuff.events).
If you're building with agents: where does your last mile break down? I'd like to hear how others are handling it.