Executive Summary:
A BairesDev Fellow shares early findings from piloting AWS’s AI-DLC methodology. The biggest speed gains came from eliminating coordination overhead. Standups, sprint planning, and grooming quietly disappeared once small teams began working in real time with AI. The article examines what those rituals were actually for, what remains, and what’s still unknown.
AI-DLC is AWS’s methodology for spec-first, AI software development at scale. A few weeks into piloting it, someone on the team asked when we were going to start doing standups again. I went looking for the moment we’d decided to stop, and there wasn’t one. Nobody killed it in a retro, nobody sent an email. It just quietly stopped happening after the second week, and nobody noticed until someone asked.
Before the pilot, standups stood for something real. They were the fifteen minutes where you found out someone else was blocked on the exact thing you’d just finished, or that two people were quietly building the same thing from opposite ends of the codebase. It felt necessary, and for years it was.
So we asked the obvious follow-up: what broke while nobody was checking in on everyone else’s status? Nothing did. The work still shipped, and everyone on the team could tell you exactly what everyone else was doing. Not because they’d read a status update, but because they’d been sitting in the same working session with an AI, watching it happen in real time.
That surprised me more than it probably should have. The easy explanation for why a team using AI coding tools moves faster is that the model writes code faster than a person does. We definitely see that effect. But the speed isn’t all coming from what the AI started doing. A lot of it is coming from what we stopped doing.
Sprint Planning, Standups, and Grooming Are Gone. Code Review Is Still Here
Sprint planning, backlog grooming, standups. They all stopped, and nobody ever sat down and decided to cut them. The one thing we kept was code review. Someone still has to look at the work before it ships, AI-written or not, and I don’t think that should change.
What disappeared were the ceremonies that exist purely to keep people in sync with each other, as opposed to the ones that check the work itself. Once the team started working the way AI-DLC has them working, those syncing rituals mostly just stopped mattering.
To break it down:
- Stopped: Sprint planning, backlog grooming, standups, status-syncing portions of retros
- Stayed: Code review, architectural decisions, product-level prioritization
The dividing line turned out to be simple. If a ceremony existed to align people on what’s happening, it became unnecessary. If it existed to evaluate whether the work is good, it stayed.
I’ve started calling the first category coordination cost: the overhead a team carries just to keep everyone’s picture of the work aligned, separate from the cost of doing the work itself. It’s usually invisible, because it’s baked into the rhythm of a sprint and nobody itemizes it. You don’t notice how much of a meeting is status-syncing versus actual decision-making until the status-syncing part disappears and the meeting turns out not to have been necessary at all.
What Those Rituals Were Actually For
None of those rituals were invented for no reason. Standups, grooming, and sprint planning solve a real problem. They keep people aligned when they can’t be in the same room, working on the same thing, at the same time. If I had to put a rough number on it, I’d guess a typical engineer was spending something like half a day a week, maybe more, just staying in sync. Not writing code, not designing anything, just making sure their understanding of the work matched everyone else’s.
Multiply that across a team and it adds up to a meaningful chunk of a sprint that never touches the product.
And that’s not a knock on Agile, or on frameworks like SAFe or Shape Up. They’re all different answers to the same underlying question of how do you keep humans aligned when they can’t literally watch each other work. Agile’s answer is frequent, structured check-ins, and for a normal-sized team spread across a normal amount of context, that’s a reasonable answer. It wasn’t free, though. We just never had a way to measure the cost, because there was nothing to compare it to.
Why AI-DLC Sidesteps the Problem Instead of Solving It
When you put two or three people in a room working with an AI in real time on the same piece of work, there’s no gap between what one person is doing and what the team knows they’re doing. Everyone is watching it happen. You don’t need a standup to broadcast status when the status was never hidden in the first place.
Part of it is that review stops being a separate event. On a traditional team, code review happens after the work is done, which means it doubles as the moment someone finds out what you’ve been doing for the last two days. On a team working this way, everyone already knows what was done, because they watched it get built. The review that’s left is about whether the work is good, not about catching everyone up on what it is.
AI-DLC didn’t make coordination unnecessary. It shrank the team down to a size and mode of working where the coordination problem barely exists.
What AI-DLC Can’t Touch: The Dependencies Outside Your Team
I want to be careful here, because it would be easy to overreach. Coordination cost hasn’t gone away. It’s concentrated in different places now.
Deciding what to build next hasn’t gotten any easier. That’s a product-management problem, and it existed long before AI-DLC. And the moment one team’s work touches another team’s code or another team’s roadmap, the old coordination cost is right back. There’s a person who’s not in the room, working on a different problem, on their own schedule. A team can be moving fast in isolation and still lose a week waiting on someone else’s API, or on a decision that lives two levels up the org chart. None of that has anything to do with whether the team itself still needs a standup.
AI-DLC eliminated the coordination we needed to stay in sync with ourselves. It didn’t touch the coordination we need to stay in sync with everyone else.
What This Means for How You Build a Team with External Partners
If this holds up, I think it changes what you look for in an external development partner more than it changes whether you use one at all.
For years, the pitch from an outside team was some version of “we know Agile: sprint cadences, ceremonies, story points.” That expertise gets a lot less relevant if the ceremonies themselves turn out to be optional.
What I’d actually want from a development partner now is people who are comfortable not having a fixed process yet. Flexible, curious, willing to work in a way that’s still being figured out in real time alongside you, instead of falling back on a playbook because it’s familiar. That’s a different hiring bar than deep Agile experience.
This is counterintuitive. “Years of Agile delivery experience” has been a genuine credential for a long time, and I’m not dismissing the people who built that expertise. But if the ceremonies that expertise was built around become optional, the expertise stops being the differentiator. What differentiates a team now is whether they can think critically about a process and actively work to improve it, not just execute the one they were trained on.
Weeks of Pilots Vs. A Decade of Agile: What We Can’t Claim Yet
Is this a real efficiency gain, or a relocation of the cost to another part of the process? I don’t know yet.
Small teams can manage informal coordination themselves, because so little of it is left. But I don’t know if that holds once we’ve been at this longer. Agile had years, across thousands of teams, to find where it broke and fix itself. That’s part of what a retro is for. We’ve only had a handful of pilots for a few weeks.
My guess is that coordination cost doesn’t vanish so much as it moves into bigger PRs, harder-to-trace decisions, and less of a paper trail when something goes sideways. We haven’t put in the time yet to find out.
Key Takeaways
- Much of the speed gain from AI-DLC came from cutting process steps, not from faster code generation.
- Agile ceremonies like standups and sprint planning primarily solved a coordination problem that shrinks when teams are small enough to work in real time.
- The distinction between coordination cost (keeping people aligned) and quality cost (checking the work) determines which rituals survive AI-native development.
- Cross-team coordination, product prioritization, and architectural decisions don’t get easier under AI-DLC.
- What differentiates a development partner now is process adaptability, not years of Agile delivery experience.
