The latest articles on DEV Community by Kent Alstad (@kentkandiforge). https://dev.to/kentkandiforge https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4145211%2F258f89d4-0a51-400e-bc3d-b91f7e7f512f.png https://dev.to/kentkandiforge en Kent Alstad Sun, 27 Sep 2026 08:21:01 +0000 https://dev.to/kentkandiforge/the-last-mile-problem-in-agentic-development-5768 https://dev.to/kentkandiforge/the-last-mile-problem-in-agentic-development-5768 <p>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.</p> <p>Then you hit the last 10 to 20%.</p> <p>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."</p> <h2> The math stops working </h2> <p>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.</p> <p>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.</p> <p>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?</p> <p>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.</p> <p>The agents had made building fast. They hadn't made finishing any faster.</p> <h2> Why "just review more" doesn't fully solve it </h2> <p>My first move was the obvious one. I added more reviewers and more testers, both agents and people.</p> <p>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.</p> <p>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.</p> <h2> What comes next </h2> <p>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.</p> <p>This series leads up to my talk at #BuildStuff15 in Vilnius this December (<a href="https://x.com/BuildStuffConf" rel="noopener noreferrer">@buildstuffconf</a>, <a href="https://buildstuff.events" rel="noopener noreferrer">buildstuff.events</a>).</p> <p><strong>If you're building with agents: where does your last mile break down?</strong> I'd like to hear how others are handling it.</p> ai agents softwareengineering discuss