Scott Breitenother, Co-founder and CEO of Kilo Code.
Pull request volume is up, cycle times are down and engineers are shipping more in a week than they used to manage in a month. Our engineers ship an average of 10 PRs a week, with each often larger in scope than before.
The instinct is to call this a productivity revolution, and in a narrow sense, it is. AI coding tools have dramatically compressed the time between “engineer starts writing” and “code is merged.” But unless you’ve moved to a shorter work week or have engineers with spare cycles looking for more to do, all that saved time goes somewhere.
Time Shifts, It Doesn’t Disappear
Writing code has become faster, but debugging the code that agents write has become harder. Agent-produced code tends to handle the common case well. It covers the scenarios that appear frequently in training data, follows established patterns and produces workable output for the majority of inputs.
But edge cases—the complex, unusual or product-specific scenarios that don’t fit the common pattern—are where it struggles. AI-generated code is often reliable for common, well-specified patterns, but it degrades on the long tail of edge cases, security-sensitive logic and system-level context. Benchmark work increasingly evaluates models on “realistic” developer tasks, reflecting the fact that success on routine patterns doesn’t necessarily transfer to production-style edge cases.
This creates a new kind of debugging challenge. When something breaks in code that an engineer wrote themselves, they carry the context. They remember the decision they made and why, they know which functions are doing what, and they can usually form a hypothesis quickly. When something breaks in agent-generated code, that context often isn’t there—even for engineers who reviewed the PR at the time. Debugging now requires coming up to speed on code that is, in a meaningful sense, someone else’s work.
The time saved in the writing phase doesn’t disappear, it gets redistributed: some of it is recovered as productivity, but some of it reappears downstream, in slower debugging cycles and harder root-cause analysis.
Edge Cases Multiply Along With Your User Base
For teams building MVPs or validating early product decisions, this is a fair trade-off. If you need to ship quickly and your primary goal is learning whether something works, covering the majority of cases well and handling the edge cases later is a sound strategy. Speed matters more than completeness at that stage.
As a product matures and a user base grows, more users means more edge cases encountered in production, which means more debugging of complex scenarios. And because each of those debugging sessions now starts with the engineer less familiar with the code than they would have been before AI tooling, each one takes longer than it used to.
A codebase built substantially by agents is a codebase where no single engineer has deep familiarity with every function. That’s always been true to some extent on large teams, but AI tooling accelerates it. As Mario Zechner put it, there are “only so many booboos [a human] can add to your codebase on a daily basis.” With AI-generated code, it’s not just the number of bugs that increases, but the expected debugging time on a gnarly issue. That cost scales with the size and complexity of what you’re building.
Where To Put The Time You’ve Recovered
The teams navigating this well are more deliberate about where human attention goes.
The most effective intervention happens before the agent writes a line of code. Investing time in the planning and specification phase—particularly in defining edge cases and non-obvious requirements explicitly—improves the output quality. If the spec is thorough enough to describe the unusual scenarios, the agent has a better chance of handling them. Gaps in the spec tend to get filled with the average-case behavior the model was trained on, which is often not what you want for your specific product.
Teams also benefit from establishing clear protocols for when things go wrong. Who is responsible for a failure in agent-generated code? How do you escalate when a root-cause investigation is taking longer than expected? These questions feel premature until they’re suddenly urgent.
The harder organizational question is what to do with the speed dividend. Moving faster on routine work creates capacity—but that capacity needs to be directed deliberately. There’s an opportunity to advance beyond simply shipping more code. Use the time recovered from common-case implementation to do more rigorous work on the parts that require real human judgment: edge cases, product decisions that don’t have a clear right answer and user experience details that make your product a pleasure to use.
A More Complete Picture Of Productivity
The AI coding productivity story is largely being told through what’s easy to measure: pull requests merged, lines of code shipped, cycle time. Those numbers are a place to start, but they don’t capture the full picture of where engineering time is going.
The teams that will get the most durable value from AI coding tools are the ones treating this as a workflow redesign, not just an acceleration. That means being honest about what agents do well and where they don’t, investing in the planning work that improves their output and making deliberate choices about where human expertise gets applied. That includes the choice to slow down when the work actually warrants it.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
