AI-DLC: why agent licenses alone don't speed up delivery, and what to do about it
When Playrix rolled out AI coding agents, activation climbed fast, but the time to get a feature in front of users moved less than the tools alone might suggest. Looking closer, the bottleneck had shifted from writing code to describing what to build, so delivery now depends more on how clearly a task is specified than on raw coding speed. Playrix is working on this with AI-DLC, a lightweight process that has the agent gather requirements and get a plan approved, so delivery times is starting to narrow.
Mikhail Ishenin , Solutions Architect, AWS — with Yuriy Trufanov , Executive Technical Director, Playrix
Over the past year, plenty of teams have rolled out AI agents: Copilot, Cursor, Claude, Kiro. The licenses are paid for, activation numbers look healthy, and developers genuinely use them. But the speed at which a team gets features in front of users has barely changed.
We've seen this on several teams that have nothing to do with each other. Leadership tracks how long it takes a real feature to reach users rather than how many times a day we ship to prod, and a big release that once took six months to prepare is supposed to get faster and stay that way. Handing out licenses didn't move that number, even though an "AI speedup of X percent" is easy to put on a slide and reads well. The gap between that cheerful percentage and the flat dashboard is what this piece is about.
We're writing this from two perspectives. Yuriy leads AI-Driven Development at Playrix and hears the engineers' feedback firsthand, while Mikhail helps companies set up the same kind of process from the AWS side and keeps seeing the same problems come up, team after team. In what follows we look at why a deployed tool doesn't speed up delivery on its own, what we did about it, and where the process still gets stuck.
The numbers that mislead and the number that matters
The first trap is the adoption metric itself. It's easy to show success as a percentage of activations or the number of tokens spent, and easy perceive the rollout worked and people are using it. But activation isn't delivery. Those numbers say almost nothing about how fast a real change reaches users, so they don't answer the question leadership actually cares about.
At the team level the other half of the problem shows up: the results are wildly uneven. The same developer ships one feature in half a day and then spends three days on ten lines for the next one. The spread between people widens as well, because some got several times faster, some saw no change, and a few actually got slower once you count the hours lost to experimenting. Average all of that into a single "AI speedup" figure and the effect disappears before it ever reaches the release pipeline.
That points at a different question. "How much faster did we get" turns out to be the wrong thing to ask, because any answer comes with a spread so wide the average stops meaning anything. The question worth chasing is why the results are so uneven, and once we started watching the spread instead of the average, that's what the rest of this article is about.
It's the same tool and the same team, yet the outcomes are opposite from one person to the next, which tells you the spread comes from how the work around the tool is set up rather than from the tool itself.
The bottleneck moved from writing code to describing it
Writing code by hand used to be the bottleneck, and the standard team is shaped around that fact. A couple of analysts and architects, one of each if you're lucky, and a large pool of programmers turning tickets into working code.
Agents take that bottleneck away. You can spin up as many as you like and run them in parallel, and the code itself is nearly free. A different job moves to the front: saying precisely what needs to be built, capturing the requirements, the design, and the plan as a checkable artifact before anyone writes a line. The people who do that part well are now in higher demand, not lower.
With agents, the slow step moves from writing code to describing the task.
This is the source of the spread from the last section, and it's an asymmetry nobody plans for: programmers have spent years learning to write code, not to describe a problem, and so the team splits in two. Those who think a solution through before they start do well in the new cycle, since the agent gets a clear intent and hands back what they asked for. Those who prefer to work it out as they go tend to get stuck, because the agent confidently produces something that looks like working code while actually solving the wrong problem, and that's easy to miss. None of this depends on seniority; the skill of describing the work simply never mattered much before.
Two old habits make it worse. The first is splitting a task into tiny pieces, with a data repository here, controllers there, and a logic layer, each one its own ticket with its own estimate. Pushing every micro-ticket independently through the cycle costs too much, and worse, none of them produces a result you can check at the feature level. The second is treating the agent like a fancier IDE, prompting, checking, fixing, and prompting again all day, which runs about as fast as typing it yourself and somehow leaves you more drained.
Both have the same fix: make the task end-to-end, from a user's intent to behavior you can verify, and keep the split into layers inside the plan rather than in your issue tracker.
What we did about it: AI-DLC
Naming that fix is the easy part. The hard part is getting a team to apply it consistently, not just when someone remembers, so we turned it into something concrete: AI-DLC, the AI-Driven Development Life Cycle . It's a set of rules you drop into the project, and from then on the agent stops spitting out code from a single prompt and walks the developer through stages instead. It works on top of whatever tool you already use, whether that's Kiro, Cursor, Claude Code, or Copilot. Two stages today, a third on the way.
One thing to set straight up front: AI-DLC is built for big tasks, the kind with enough requirements and moving parts to get badly wrong. Smaller, self-contained work is already handled well enough by the lighter spec-driven development built into tools like Kiro, and pushing it through the full cycle mostly adds friction. So the rest of this piece is about the big tasks.
The whole thing runs in the same order every time: think the idea through, write it down, and only then hand it to the agent. If you already think before you write, the process barely slows you down. If you don't, it gives you a clear path to follow.
The AI-DLC cycle
Inception, what we're building and why. The agent reads the request, asks clarifying questions, and gathers requirements. When the task is big enough to justify it, the agent also adds user stories, a rough architecture, and a breakdown into units of work that can run in parallel. Every step leaves an artifact behind, and the agent drafts it while the developer reviews and corrects.
Construction, how we build it. For each unit of work the agent writes a detailed design first and then a generation plan, which the developer signs off on before anything starts. Only after that approval does the agent touch code and tests, and until the plan is approved there is no code.
None of this is rigid: a lighter task skips through most of the steps and reaches code almost right away, while a hairy one runs the whole cycle, with the agent deciding how deep to go based on complexity and risk.
So far engineers feel very differently about this, and the deciding factor is the person, not the tool: how natural it already is for them to describe a task before writing it. When that comes naturally:
"No time goes into mechanically typing code. And context switching stops being a problem: you step out for a meeting, come back, and in the gap before the next call you can review the plan for the next step, approve it, kick off generation, and check what came out."
Here's what a good run looks like in practice.
Example: payment history
The job was to improve how payment history shows up. The data lives in two places at once, the monolith and a newer service, and it's duplicated across them, so you have to stitch it into one history page to serve through the API. It's a small feature, but exactly the kind of messy spot where hacks usually sneak in. The developer wrote up the task and called out the edge cases separately. From their feedback:
"The agent located the spot that needed changing on its own, proposed a solution, and collected its clarifying questions. One round of answers later, it was ready to build. What came out was correct, with no hacks."
The point isn't this one feature; it's that by the time the agent reached code, there was barely any uncertainty left, so the result stopped depending on luck. What that adds up to across a team is what the next section is about.
What it gives the business
On its own, one clean run like that is just an anecdote. The shift happens when the process becomes the default across the whole team: predictable runs stop being the lucky exception and turn into the normal case, task after task. Do that across enough tasks, and the gains start showing up in the numbers leadership tracks.
Delivery gets more predictable. The gap between developers narrows, so does the gap between one person's good and bad weeks, and delivery times flatten out. That's the spread we set out to close, and it's the number leadership is staring at.
Same team, same features: the spread in delivery time narrows (illustrative)
The middle of the team catches up. AI without a process tends to play out one way: the stars sprint ahead, everyone else stands still, and the gap only grows. With a process it goes differently, because the middle of the team starts catching up, and that middle, not a handful of champions, is where most of the business value sits.
Handoffs get easier. When an up-to-date description of intent sits right beside the code, a new engineer can get into a project without weeks of digging to understand it. The old trap fades, the one where a single person understands a service and nobody else dares touch it. We can already see the difference: anything built under AI-DLC changes hands far more smoothly.
Style lines up. Feed the agent a style guide and a few examples of your internal libraries, and at the design stage it reaches for what already exists instead of reinventing it. The engineers asked for this one themselves.
For the developer it all comes down to one thing, and it's worth saying out loud, because the pushback usually starts there: it looks like paperwork. In practice it pays off in three ways, since context comes back in seconds, review finally means something because you're checking the intent and not just the code, and the agent helps turn a half-formed idea into a clear one. The skill people were missing turns out to be built into the tool.
One last note on metrics: track how long it takes to deliver features that matter, rather than activation rates or token spend. The first is something the business can feel, while the second is easy to chart and tells you nothing.
Where it still gets stuck
Not every engineer is convinced, and the doubts point at something real:
"I wouldn't say development got several times faster. I got about the same result with plain vibe coding. Even when I knew the whole context and spelled out a clear plan, almost down to the code, the agent still pushed the task through the entire cycle, and I ended up spending a lot of time for a handful of lines."
There's no point hiding them, so here are the limitations, plainly. There are three of them.
The full cycle is overkill for small tasks. AI-DLC is a process for big tasks. Something small that needs to ship within the hour is better off with plain spec-driven development, or even vibe coding; pushed through the whole cycle it's more friction than help. The hard part is the boundary. AI-DLC doesn't yet scale down cleanly when a task turns out to be small, which we're fixing, and the old habit of slicing work into tiny pieces makes tasks look smaller than they are, which is culture, not tooling.
Tokens cost money. Running the whole cycle on top-tier models gets expensive fast. You can push the routine steps, like subagent runs and first-pass code generation, onto cheaper models, and the tooling lets you, but the output gets noticeably less consistent. So if you want to roughly guarantee a consistent result, you end up keeping everything on the expensive ones. It's a tradeoff between cost and consistency, not a tooling gap that will fix itself.
Someone still has to read the artifacts. We run automatic review, but without careful context it misses things, so a human pass is still mandatory. This is where most of the developer frustration collects, and it's the one job AI hasn't removed for them yet.
Where to start
You don't have to invent the process. AI-DLC is open source — drop the v2 workflows into your repo and run on top of the agent you already use, whether that's Kiro, Claude Code, or Codex. Installing it is the easy part, and it's also where most teams stall: the rules are sitting in the project and nothing has changed yet. The process only starts paying off on the first real task you push through it.
So push one through. The shortest path that actually moves the number:
- Pick one big, messy task — the kind with enough requirements to get wrong. Leave the small stuff to plain spec-driven work; the full cycle just adds friction there.
- Let the agent run Inception first. It reads the task, asks its questions, and writes down the requirements, the edge cases, and a breakdown into units — and it doesn't touch code until you approve. You review the artifact on disk, not the chat.
- Load a style guide and a few examples of your internal libraries before it designs anything, so it reaches for what you already have instead of inventing it.
- Run it with the team watching, not solo. The point isn't one clean feature; it's that the people in the room become the ones who run it next.
- Track how long that feature took to reach users — not activations, not tokens.
Do that once and you've got one predictable run. Do it across enough tasks and the spread we've been chasing starts to close.
What's next
The role of the developer shifts with all this — what starts mattering, what stops, and why the job moves toward product and analysis rather than code generation. That one deserves its own piece, and we'll write it.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article