最新资讯
dev.to 我们在 DolphinBench 上测试记忆检索:纯关键词搜索暴露了自身回归 dev.to 别再把 Agent 写成 while 循环,把它建模为状态机 bloomberg.com Rightmove 与 Scout24 借 AI 产品应对低迷房市并上调展望 stackoverflow.blog 欢迎来到芯片时代:半导体制造、AI 数据中心与芯片设计的未来 www.youtube.com AI Agent 总犯同样的错:CentralAgent AI 将记忆重构为经验系统 pub.towardsai.net Netflix 科学家建议重采样 LLM 评判:5 次仅将误差棒缩小 13% pub.towardsai.net Jev 作为 LLM 前的静默层:构建提示感知的模型路由器 reddit.com OpenAI 称 Astra 仅满足 10% 安全任务标准 dev.to FreeToken:在自有 GPU 上运行前沿 MoE 模型及其内存需求 dev.to 当 AI Agent 说“完成”时,究竟完成了什么? dev.to 部署 Underdog Bark 3.0 Pro:逐字转写、自定义后端与分块设置 dev.to 为艰难对话构建 AI:五个 Agent、一条安全正则与一位盲评监督者
多元动态
登录 注册
智能体 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.

来源报道 · 1 篇 · 以下链接均前往原始媒体

Kent Alstad Agentic 开发中的最后一公里问题 09-27 · 原文发布
← 返回精选动态 原文

更多内容