Every conversation I have about AI coding agents seems to land in the same place: speed.
"I shipped a feature in a weekend that would've taken two weeks."
"We're moving 3x faster."
"Our cycle times are collapsing."
And honestly, that's fair. Agents do make us faster. I've felt it too.
But lately I've been sitting with a different thought, and I wanted to share it before I forget what it felt like to land on it.
The speed story is only half the story
The framing I keep hearing goes something like this: agents let us do the same work in a fraction of the time. Two weeks becomes two days. A quarter's worth of features lands in a month.
Nothing wrong with that. Speed is real, and speed matters.
But I think we might be leaving something on the table when that's the only story we tell ourselves. Because there's a second option, and it's the one I've been quietly falling in love with:
What if we kept the pace we had before, and used the new capacity to go deeper?
Let me show you what I mean with an example I keep coming back to.
The CRUD API, two ways
Imagine you're a mid-to-senior engineer building a new set of API routes. Nothing exotic, just a CRUD resource with some real business logic in the handlers. The kind of work that, pre-AI, would have taken about two weeks to get to production.
Today, with a decent agent in the loop, most people would ship it in a few days. And that's probably true. You'd end up with something solid:
- Routes that follow REST conventions
- Versioning in place
- Rate limiting, with values that are, let's be honest, more or less guesses
- Basic logging and error handling
- The happy path of the business logic, working
- AuthN, authZ, and input validation
- Maybe a quick caching win where it's obvious
- A handful of unit and integration tests
Ship it, get a review, address the feedback, done. Two weeks of work in three days. A clear win, and for a lot of situations, the right call. Not everything needs to be gold-plated.
But here's what I've started doing instead when the work matters.
What the other week and a half buys you
Instead of pocketing the time savings, I spend them. I stay in the two-week window and use the extra room to have a different kind of conversation with the agent. The kind I used to skip because there was never quite enough time.
Conversations about things like:
- Idempotency and retries. What actually happens if this request lands twice? Three times? Is the client expected to retry? Are we safe if they do?
- Failure modes and load. What breaks first under pressure? What does graceful degradation look like here? Have we actually put load on this, or are we guessing?
- Caching, picked on purpose. Not "let's cache this because caching is good," but "given how this data is read, written, and invalidated, here's the strategy that actually fits."
- Tests for the ugly paths. The happy path is table stakes. What about the partial failures, the timeouts, the malformed inputs, the race conditions, the states no one thought to draw on the whiteboard?
- Observability you'd actually want at 2 a.m. Logs that tell you what happened and why. Metrics that matter. Alerts that fire before users notice, not after.
Written out as a bulleted list, it doesn't look like much. But if you've ever seriously gone down any one of these, you know each line is a rabbit hole with real depth. And agents are remarkably good companions down those rabbit holes, because a lot of that work is about asking the right questions and methodically working through answers, which is exactly the loop they shine in.
Same feature, sturdier software
The part that clicked for me is this: at the end of both paths, your users get the same feature. From the outside, the API looks identical.
But on the inside, one version is quietly more resilient than the other. It fails in better ways. It tells you when something's off. It holds up when traffic spikes or a dependency hiccups. It doesn't leave users stranded in weird broken states that are expensive to debug and even more expensive to rebuild trust around.
That difference rarely shows up in a demo. It shows up six months later, when the feature either ages gracefully or starts bleeding incidents.
And I think this is the real shift agents are offering us, if we want it. Not "ship the same thing faster," but "ship something sturdier in the same amount of time."
Speed is the obvious read. Depth is the one I suspect we'll look back on and wish we'd taken more often.
If you want to try this
A few things that have helped me actually do this in practice, instead of just nodding at the idea:
- Write down what "done" usually looks like for you. Then ask: if I had another week, what would I want to add to this list? That's your depth backlog.
- Pick one dimension per feature. You don't need to go deep on everything. This week it's observability. Next time it's failure modes. Rotate.
- Use the agent as a sparring partner, not a typist. The value isn't in it writing the retry logic faster. The value is in talking through whether your retry logic is actually correct for this workload.
- Re-budget your time, don't just take the savings. If a feature used to take two weeks, keep booking two weeks. Spend the reclaimed days on depth, not on squeezing in another ticket.
That last one is the hardest, for me at least. There's a strong pull to use the time savings to do more. Sometimes that's the right move. But sometimes the better one is to do the same thing, better.