“Is agile dead?” It’s a question Rob Zuber, CTO of CircleCI, has been fielding lately.
His answer: not even close. In fact, it’s finally arrived. The core promise of agile (working software over documentation, responding to change over following a plan) was always the right idea. We just couldn’t execute on it fast enough to make it feel true.
AI changed the math.
On this episode of the Confident Commit podcast, Rob sat down with Chris Kelly, Head of Product at Augment Code, to dig into what’s actually shifting in how software gets built and delivered. Chris is unusually positioned to see both sides of this: he’s a product leader who recently built the first version of Augment’s CLI himself, over a weekend, to prove a point. Did he prove it? Read on for the takeaways.
1. Prototypes beat specs now. This changes everything upstream.
Chris built the Augment CLI because he was tired of spending time in meetings convincing people of an idea in the abstract, so he just built it.
“In order to make it happen, I just prototyped the first version over a weekend... Everyone’s like, this is great. Which is like, especially as a product person, I don’t have to spend countless hours in meetings trying to convince you of an idea in the abstract. I can actually just show it to you.”
Chris Kelly, Head of Product, Augment Code
This isn’t new advice. Danish programmer David Heinemeier Hansson said “code wins arguments” years ago. What’s new is that it’s now accessible to more people, faster, at lower cost. The threshold for “just build it” has dropped so far that it’s starting to break how we think about planning cycles, design reviews, and requirements docs.
If you can build the thing faster than you can finish the meeting about the thing, the meeting needs to change.
2. The real savings isn’t faster code. It’s less coordination.
A lot of the ROI conversation around AI tools focuses on lines of code per hour. That’s the wrong unit. The underappreciated savings, as Chris framed it, is coordination cost: the energy that goes into aligning people, running standups, writing meeting notes, keeping everyone in sync.
“It’s not just can I write code faster? But can I decide what to build and build it faster because I have less human beings that I have to collaborate with. So then you just get smaller pods of people doing a lot more work. That I think is the unappreciated cost that we’re actually saving.”
Chris Kelly, Head of Product, Augment Code
Smaller teams with less coordination overhead have always outperformed larger teams with more. The ROI question gets reframed entirely. It’s not “are my engineers using tokens efficiently?” It’s “what would it have cost me to coordinate the team required to do this work before?”
3. Any IC engineer now has signing authority to increase engineering capacity.
In the old model, scaling up engineering capacity meant a long conversation about hiring budgets, ramp time, and headcount. It was slow by design.
“Any IC engineer right now has the signing authority because all they do is run more prompts. They have the signing authority to increase the capacity of the engineering organization. It really puts us in a really bizarre state.”
Rob Zuber, CTO, CircleCI
That’s not an exaggeration. The gates that used to govern capacity growth (budget approvals, hiring pipelines, onboarding time) don’t apply to agents. An engineer who decides to spin up additional agents for a project has effectively made a capacity decision unilaterally.
That’s either terrifying or exciting depending on how you’re set up. The engineering leaders figuring it out now are the ones who will be ahead when everyone else catches up.
4. Think of agents like dynamic cloud compute, not additional headcount.
Chris offered what might be the clearest mental model for the current moment: the shift from provisioning racks of servers to dynamic cloud compute.
Before the cloud, you provisioned for peak. You either had too much capacity or not enough, and both were expensive. The cloud let you pay for what you actually used and scale in real time. Agents do the same thing for engineering output.
“Do agents allow us to keep our staffing levels and our teams the right size and then be able to respond when things change? Do we get closer to that in a healthier way?”
Chris Kelly, Head of Product, Augment Code
This maps onto the over-hiring cycles we’ve seen at large companies too. If you can scale capacity dynamically with agents, you don’t need to staff up for a product that might not take off. You prototype it cheaply, validate the bet, and hire when you know it’s working, not before.
The question isn’t “how many engineers do I need for this project?” It’s “what’s the right human baseline, and what can I run dynamically on top of it?”
5. Senior engineers are high-leverage (but only if they get invested).
Rob and Chris both circled back to a tension that comes up in almost every conversation about AI adoption: senior engineers often get the best results from AI tools, but they’re not always the first to reach for them. They already know how to do the work. Why hand it off?
The problem is what they leave on the table when they don’t.
“It was always more valuable that a senior engineer was mentoring and helping five junior engineers than having them handwrite a bunch of code on their own. And so now, how do we do this? Make everything shareable in that way. If I build an agent that does a specific task and it’s really good at it, it turns into an institutional agent that we run on all of our PRs now.”
Chris Kelly, Head of Product, Augment Code
When a senior engineer builds a skill, a prompt, or an agent workflow that solves a recurring problem, they’re encoding institutional knowledge in a form the whole team can run. That’s leverage in a way that handwriting code never was.
The engineering cultures that thrive will be the ones that treat those artifacts the same way they’ve always treated scripts that became services: write it once, get it into the shared system, and stop making the same decision twice.
6. Agents need to get better on their own. Most aren’t designed to yet.
The last thread Rob and Chris pulled on was the one furthest out on the horizon: self-improving agents. Right now, most agent workflows are designed as static patterns: trigger an action, get an output, repeat. That’s useful, but it’s leaving something significant on the table.
“I want my agents to always be improving their own prompts, their own systems and having their own memory. And that’s really where we’re focused a lot. And it’s been really exciting to see what’s possible when that comes true.”
Chris Kelly, Head of Product, Augment Code
The analogy Rob reached for is incident response. The most valuable engineer in a production incident isn’t necessarily the best coder. It’s the one who’s been around long enough to say “I’ve seen this before, it’s probably that.” That knowledge lives in their head, and it walks out the door when they leave.
The teams that are ahead are already asking: how do we design agents that write their own memories? How does a fix in one agent make every future agent smarter? That’s where teams should be heading right now.
Want more on how software delivery is actually changing? Subscribe to Confident Commit and join Rob for conversations with the people building through it.
