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.
Top comments (1)
From my experience building a foundry, the only way to guarantee an output, is to take the agent out of the final stage. Deterministic generated tests, integration, fuzzer and unit tests. That covers all the inaccuracy issues and while they run, they can save snapshots for you to browse through and highlight any visual issues. But generally speaking, a MoE MoA setup works best for that. Having a specialist model in a specialist role, with specialist skills, helps the model perform well above it's weight class, because it's not trying to be a generalist and with practically all models being MoE these days, that lets them isolate hot-path experts and execute cleaner and faster code. Take Kimi K2.7 Code for instance, with a frontend skill and a system instruction, it produces pretty astonishing GUI.
The other part is a physical live-test. MCP-driven GUI, with a vision capable model, like qwen 3.8 flash, to just run through the systems and flag anomalies to a backlog, then iterate until all GUI panels come up clean. the Deterministic generated tests make sure that everything is properly constrained and scoped, so you know everything is fully guarded and working, regardless of what the user enters and the integration test running a full migration on the mock db, means anything buggy gets flagged and fixed fast.
That's all stuff I learned back when I made the foundry, which was a prompt to binary process, since then, I've been doing more work developing an agentic IDE, that's main goal is to solve the multi-concurrency issue. Simply put, Git merge isnt enough. Agents need to be able to flag and resolve conflicts at write-time, before an edit is ever made. Else you've got polluted code that isnt guaranteed to work.