Agile in the Age of AI
Whatever you think about Agile (the capital-A kind, certifications and sticky notes), the core insight was always simple: build communication loops between the people who want software and the people who make it. Short cycles. Frequent check-ins. Shared context. The manifesto was about humans talking to humans, and the best teams took that seriously.
AI hasn’t changed that insight. But it has changed who’s in the room.
A new kind of author
In the original Agile model, stakeholders described what they needed and authors, human developers, built it. The feedback loop between them was the whole game. Daily standups, sprint reviews, retros. All of it existed to keep those two groups aligned.
Today, a coding agent is often the author. The human developer has shifted from author to something more like an editor or director. You describe the intent, the agent produces the work, and you review it. The stakeholder-author loop still exists, but now there’s a new loop nested inside it: human and AI, going back and forth on implementation.
This is still Agile. It’s still about communication, context, and short feedback cycles. The principles haven’t changed. The participants have, and we need to be honest about what that means.
Sync points matter more than ever
Agile always emphasized sync points: moments where everyone stops, looks at what’s been done, and agrees on what comes next. Standups, sprint reviews, PR reviews. These checkpoints existed because humans lose the thread when too much changes at once.
That hasn’t changed. What’s changed is how fast things can change between sync points.
An AI agent can produce a thousand-line diff in minutes. If you let that land as a single PR, you’ve created the equivalent of a meeting where a hundred topics are on the agenda. Nobody can meaningfully engage with all of it. In practice, reviewers skim, focus on maybe 5% of the changes, and approve the rest on faith.
So now the discipline is: a unit of work is what you’d want to discuss at a single meeting. Not a sentence, a meeting. That’s a meaningful chunk of work. You can talk about a new feature, walk through the design decisions, discuss tradeoffs. But if you showed up to a meeting with a hundred unrelated changes, nobody would track all of it. People would latch onto the five things they understood and wave through the rest.
The same thing happens with PRs. When the amount of change between sync points is too large, the review becomes shallow by necessity. Not because the reviewer is lazy, but because that’s how human attention works.
The review problem
Here’s what I keep hearing from other teams: PRs are churning so fast that there’s no ability for a human to actually review them. The AI generates, the human rubber-stamps, and the cycle repeats. The review step becomes theater.
At Miren, we believe human-driven review is still required. Not because it’s the only way to get quality — AI reviewers are getting genuinely good — but because review forces the process into something repeatable and comfortable for the team. It creates a shared understanding of what was built and why. It’s a sync point.
Software has never been a solo activity, even when one person writes all the code. It lives in a system, it gets maintained by a team, it serves users who weren’t in the room. Review isn’t about catching bugs. It’s about shared understanding. Even when your collaborator is an AI, you should optimize the process for that collaboration, not just for raw output.
The cognitive ceiling
I can comfortably manage about three AI agents working in parallel. Beyond that, I start losing the thread: which agent is doing what, what state each piece of work is in, whether the output from one conflicts with another. I get stressed. I make worse decisions.
I’ve seen people talk about managing ten, fifteen, twenty-five agents at once as if it’s a goal to aspire to. I can’t imagine sustaining that. Not because the tools can’t handle it, but because I can’t. There’s a real cognitive ceiling to how much concurrent work a human can meaningfully direct, and pretending otherwise doesn’t make you more productive. It makes you a bottleneck that doesn’t know it’s a bottleneck.
And there’s a related question that nobody seems to be asking: just because you can throw $2,000 in tokens at evolving a solution to a problem, was it worth it? Output isn’t value. Effort isn’t progress. The work still has to be worth doing.
Work can’t be 24/7
All of this connects to something bigger. There’s a growing expectation, sometimes quiet, sometimes not, that because AI can work around the clock, the humans directing it should too. That every saved hour should be filled with more work. That if the tools made you five times faster, you should be producing five times as much.
I believe we should push back on this.
Better tools should mean better outcomes, not more hours at the desk. Agile understood this, even if the industry forgot. Short iterations weren’t just about shipping faster. They were about sustainable pace. The original manifesto literally calls it out: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Indefinitely. Not “until the next sprint.” Not “until we ship.” Indefinitely.
After 25-plus years of doing this, here’s what I know about myself: if I keep my effort at about 70-80%, I can sustain that every day, all day. I’m productive, I’m present, I do good work. But when something demands I jump to 100% — a deadline, a crisis, a launch — a clock starts. I can hold that for about two weeks. Then there’s an obvious crash, and I need weeks to mentally recover before I’m back to that sustainable baseline.
I don’t think I’m unusual in this. Everyone has their own version of those numbers, but the shape is the same: there’s a pace you can hold and a pace you can’t, and the gap between them isn’t something you can willpower your way through.
AI tools make it dangerously easy to run at 100% without realizing it. The work moves so fast that it feels sustainable right up until it isn’t. Identifying a sustainable pace, not just for each person but for the whole team, matters more than ever. The tools are faster but the humans aren’t. The cognitive load of directing AI work is real and new. And the culture that says “the machines never sleep so neither should you” is just the old overwork culture wearing a new hat.
What we’re doing about it
At Miren, we’re small enough to choose how we work. Here’s what that looks like in practice:
- Define done before you start. Every piece of work is anchored to a Linear issue. Even if it’s only a sentence, we have to write down what the change is meant to do. That anchors the work. It gives you a definition of done before anyone starts, and a reason to stop when you get there.
- Right-size the work. A PR should be what you’d want to discuss at a single meeting, substantial but coherent. If a reviewer can’t hold the whole change in their head, it’s too big.
- Review is non-negotiable. Every change gets human eyes. Not as a gate, but as a collaboration point.
- Pace over output. We ask: what pace can we keep up for a month? If the day’s work is done by noon, the day is done.
The principles that made Agile work haven’t expired. Communication loops, shared context, sustainable pace, right-sized units of work. We just need to apply them to a world where one of the participants in the loop is an AI that never gets tired — and remember that the other one does.