Scott Breitenother, Co-founder and CEO of Kilo Code.
Many engineering teams still organize work the same way they did a decade ago: Someone identifies a problem or improvement, logs it as a ticket, and it waits in the backlog for triage and eventually a sprint slot. Team meetings, user feedback and dogfooding surface an endless stream of small but meaningful improvements: fixing UI papercuts, enabling server changes directly through the interface or synchronizing settings across environments (all real examples lingering in our backlog). By the time an engineer picks them up, if they get picked up at all, the original context may be weeks or months old.
Cloud agents have made that queue optional. Take a common affliction for engineering teams: conflicts from upstream dependency changes. Resolving these typically disrupts work, forcing an engineer to switch branches. During an engineering call, one engineer suggested that most of the offending library might not actually be necessary. They kicked off the work via a cloud agent, and a short time later, the team had resolved the conflicts and reduced the size of the package they were shipping. The idea-to-execution gap, which used to be measured in sprints, now runs in hours. Several platforms offer this kind of cloud agent infrastructure.
Why The To-Do List Is The Wrong Unit Of Work
For most of software development’s history, execution was the constraint. Shipping was expensive, and coordination was hard, which made mistakes costly. Organizations built a structure that reflected those constraints: Product managers filtered ideas upstream, engineers implemented downstream and the whole system was optimized for not wasting engineering time.
Code generation has made individual tasks faster, but cloud agents go further. The kind of small improvements that once required logging a ticket, waiting for triage and consuming an engineer’s full attention can now be kicked off asynchronously and reviewed in minutes. The overhead of managing the backlog doesn’t just shrink; for a growing category of work, it can disappear entirely.
Now that shipping is close to free, the constraint has moved from whether you can build something to whether what you built actually worked.
Delegating Execution, Retaining Judgment
The people in this model still have to think. They decide what’s worth doing, evaluate whether it worked and cut things that aren’t moving the number. An agent has no taste for whether a feature is worth keeping—that judgment stays with the person who prompted it, who is accountable for the output as if they’d written the code themselves. At our company, if you prompt the agent, you’re the author. Prompting something into existence and hoping for the best is not ownership.
The other side of shipping faster is killing faster, and most organizations are much less prepared for that. It’s been argued that being bottlenecked by code generation was a good thing. As one developer put it, “Your org rarely has good ideas. Ideas being expensive to implement was actually helping.”
It’s true that when shipping was expensive, the filtering happened before you built anything. That’s what specs and prioritization were for. But the incentives reinforced it: By the time something reached an engineer, specs had been written, stakeholders had weighed in and sunk cost made killing it feel like failure.
When shipping is cheap, you can run far more experiments—but you have to learn from them. The cost of keeping bad ideas doesn’t fall with the cost of shipping them. Maintenance, complexity and user experience debt accumulate regardless of how quickly something was built. The discipline this model requires is defining success criteria before you ship, running a short feedback loop (we do this weekly) and letting the metric decide without politics or attachment. The filter didn’t disappear; it moved to after you have data.
Product Thinking Doesn’t Go Away; It Gets Redistributed
That shift has consequences for team structure. Some companies will have engineers wear the full product hat: owning customer conversations, metrics and road map decisions alongside their technical work. That requires a rare profile and works best with tightly scoped product areas. Others will find that product managers now have a different role: less about writing specs to hand off, more about market discovery and commercial strategy. The judgment about what to build, for whom and why is still a human job: it’s the translation layer between spec and code that’s collapsing.
Faster tooling alone doesn’t solve this. Tools accelerate whatever structure you already have, and if ownership is unclear—if nobody is actually accountable for whether something works—faster shipping produces more waste faster.
Prerequisites For Shipping At The Speed Of Ideas
First, the tooling needs to run in the cloud, not locally—the reason the Slack-to-PR workflow that we see so heavily used on our own team is practical is that the agent runs asynchronously, without anyone watching it. You don’t have to be at your computer to kick one off, and you get pinged when it’s ready.
Your codebase and CI process also need to be in good enough shape that an agent can operate reliably inside them: that means clear guidelines and strong automated checks—the kind of guardrails that let an agent take an action without going off the rails.
Most importantly, the cultural norm has to be explicit: The person who prompts the agent is the author, responsible for reviewing the output before anyone else reviews it. Without that, faster shipping just means faster accumulation of code nobody has actually owned.
Working this way isn’t about shipping faster just for the sake of it. The point is that speed allows you to validate (or invalidate) ideas faster. But the thing you can’t delegate to an agent is taste: knowing whether something is worth keeping, whether it’s moving the right number for the right reasons, and whether it’s making the product better or just bigger. When the people building the product own that judgment alongside the outcome, a lot of coordination overhead disappears on its own, and the pace of shipping only makes that judgment more valuable.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
