“Agentic coding capability is bottlenecked by training infrastructure rather than model scale.” It is about time someone said it. For two years, the industry has been obsessed with the “scaling laws” religion, acting as if we can just throw ten thousand H100s at a problem and the model will suddenly figure out how to debug a race condition in a legacy C++ repo. It is a lazy approach to intelligence, assuming that more data—regardless of quality—always equals more reasoning. We have spent a fortune on brute force, only to realize that a model that has read every line of code on GitHub still can’t actually build a simple project without tripping over its own feet.
The KwaiKAT team is arguing that the real problem isn’t the number of parameters, but the fact that most models are trained on static snapshots of code. They aren’t interacting with the code; they’re just guessing the next character based on a massive pile of GitHub scrapes. The KAT-Coder-V2.5 technical report focuses on the “verifiable repository environment,” which is a fancy way of saying they actually built a place where the code can be executed and tested. This is a critical distinction. Most training sets are essentially graveyards of code—snapshots of projects that might not even compile in the environment they were written in. Training on that is like trying to learn to drive by looking at photographs of cars.
They used a system called AutoBuilder to create over 100,000 of these environments. Now, here is where the real-world friction kicks in: their success rate for constructing these environments went from 16.5% to 57.2%. Let’s be clear—that means nearly half of their attempts to build a verifiable environment still failed. (The sheer amount of compute wasted on failed environment setups is probably staggering). But the jump is significant. Why are we still pretending that more tokens equals better logic? If a model can’t actually run the code it writes, it is just a very expensive autocomplete. It’s just predicting what a correct answer looks like, not understanding why it is correct.
This is the difference between a student who memorizes the answers to a math test and a student who actually understands how to use a calculator. It is like training a chef by letting them actually burn things in a real kitchen instead of just reading five hundred cookbooks. The “agentic” part of the model comes from this feedback loop. If the environment fails, the model learns why. If it passes, it learns what works. This is the only way to get past the “hallucination” phase of AI coding, where the model suggests a library that doesn’t exist or a function that was deprecated in 2014. We’ve seen this loop in RLHF for chat, but applying it to the actual execution of code is where the real utility lies.
Most labs are too scared to admit that their data is noisy and their evaluation benchmarks are basically theater. They would rather talk about “emergent properties” than the boring, grinding work of building a reliable sandbox. By focusing on the infrastructure, the KwaiKAT team is admitting that the intelligence isn’t just in the weights, but in the quality of the interaction loop. It is a shift from passive learning to active experimentation. Or maybe not—maybe this is just another way to inflate benchmarks by controlling the environment. But the logic holds: you cannot have a reliable agent without a reliable way to verify its actions.
I suspect we are seeing the beginning of a pivot. By Q4, the conversation around coding models will stop being about parameter counts and start being about the percentage of the training set that was actually executed in a verifiable environment. The “vibe check” era of coding assistants is dying, and it should. We don’t need models that sound like senior engineers; we need models that actually commit code that compiles on the first try.
Infrastructure is the new frontier.
