AI-Assisted SDLC: The Lifecycle Isn't Being Assisted Anymore. It's Being Delegated.

For about three years, the AI coding story was a keystroke story. The tool guessed the end of your line, saved you a trip to the docs, wrote a test you would have written anyway. It was useful and it was legible — you were still holding the plan, and the AI was filling in around you.

That is not what is happening now. The tools have moved from finishing your sentences to taking a goal and executing against it: planning an approach, writing across several files, running the test suite, reading its own failures, fixing them, and opening a pull request — largely unsupervised until it hits a checkpoint you defined. The word for that is not assistance. It is delegation.

And the interesting consequence is not that code gets written faster. It is that engineering work is quietly reorganizing around supervision, review, and system design rather than line-by-line implementation. That reorganization — not the productivity headline — is the thing a technical leader actually has to plan around.

The reframe: assistance became delegation

It is worth being precise about the distinction, because vendors blur it and the two things demand completely different management.

Assistance is autocomplete and suggestion. You decide what to build, you hold the plan, the AI reduces the typing between your intent and the code. If it suggests something wrong you notice immediately, because you were already thinking about that exact line.

Delegation is handing over a goal. “Add rate limiting to the public API.” The agent decides the approach, touches whatever files it decides to touch, runs the tests, interprets what broke, tries again, and comes back with a pull request. You were not thinking about those lines. You are now reviewing a plan you did not make, executed in ways you did not watch.

That is a different activity with a different failure mode. Assistance fails visibly and cheaply. Delegation fails plausibly — the pull request looks reasonable, the tests pass, and whether it is right depends on whether someone genuinely reviewed it or just saw green.

The evidence it actually shifted

This is not a vibe. There is a concrete signal, and it is a good one because it measures trust rather than opinion.

Anthropic’s 2026 Agentic Coding Trends Report found average agent session length grew from around 4 minutes in early 2025 to roughly 23 minutes in early 2026, with a typical session now involving about 47 tool calls — reading files, writing code, running commands, iterating. Worth noting that this is Anthropic reporting on usage of its own tooling rather than a neutral survey, so read it as directional. But the direction is hard to argue with: a four-minute session is a suggestion. A twenty-three-minute, 47-tool-call session is a chunk of work someone handed over and walked away from.

Nobody let agents run for twenty-three minutes in early 2025, because they were not worth trusting for twenty-three minutes. That number is a trust curve, and it went up roughly six-fold in a year.

The job is changing, and it is an operational problem

Here is the part that belongs on a planning document rather than a think piece. As agents take more of the build-and-fix cycle, engineering time moves toward orchestration, review, and system design.

This gets written about as though it were a philosophical question about the future of the profession. It is not. It is a staffing and process question with a deadline, and it looks like this:

• Review capacity becomes the bottleneck. If agents open three times the pull requests, and review was already the slow step, you have not sped up delivery. You have moved the queue.
• Review quality matters more than it used to. Reviewing code a colleague wrote means reading a plan a human held in their head and can explain. Reviewing agent output means reconstructing intent from the diff alone. Those are different skills and the second one is harder.
• Juniors lose their apprenticeship. The routine implementation work that taught people the codebase is exactly the work being delegated. Nobody has a good answer to this yet, and pretending otherwise is dishonest.
• System design gets more leverage. An agent working inside a well-factored system with clear boundaries does dramatically better than one loose in a tangle. The design work now compounds through everything the agents do.

The practical question is not “will AI replace engineers.” It is “our review process was built for the volume humans produce — what happens at three times the volume?” That question has an answer, and it is worth having before the volume arrives.

The number everyone quotes, and why to distrust it

You will be shown a capability curve. It usually runs from around 2% to nearly 80% on SWE-bench, and it is genuinely startling. It is also, as a factual claim about current capability, wrong in a way worth understanding — because someone will quote it at you in a vendor meeting.

There is a second, quieter problem with the curve. The ~2% starting point comes from the original SWE-bench paper in late 2023 — Claude 2 scored 1.96% in one retrieval setting. SWE-bench Verified did not exist until August 2024. So the famous curve splices two different benchmarks together and presents the join as growth.

None of which means capability did not improve. It improved enormously, and anyone who has watched an agent work through a real bug knows it. But the honest number is roughly a third of the headline one, and the gap between those two numbers is exactly the gap between what you will be sold and what you will get. If your plan is built on 80%, rebuild it on 23% and see whether it still makes sense. That is not pessimism. That is the number.

What it actually saves, honestly

Productivity studies land all over the map, and the spread is more informative than any single figure.

McKinsey reported developers completing common tasks — generation, refactoring, documentation — 20–50% faster. Harvard Business School found 17–43% across knowledge work more broadly. Both are meaningfully positive and neither is nothing.

But look at the two ends. A GitHub study measured 55% faster — on a self-contained JavaScript HTTP-server task. A randomized controlled trial with 96 Google engineers on a complex, enterprise-grade task measured roughly 21%.

Same technology. Two-and-a-half times the difference. The variable is not the model — it is whether the task looks like a tutorial or like your actual codebase. Greenfield, self- contained, well-represented in training data: large gains. Tangled, legacy, full of local convention and undocumented reasons: much smaller. When a vendor quotes you 55%, the useful follow-up is: on what task?

Where delegation clearly works: review

It would be a strange piece that only listed caveats, and there is a case where the evidence is genuinely encouraging.

Qodo’s State of AI Code Quality report found 81% of teams using AI for code review saw quality improvements, against 55% of comparably fast-moving teams without it — and that teams with AI review saw roughly double the quality gains even without any speed increase. Qodo sells AI code review, so treat it as interested rather than neutral. But the finding is plausible precisely because of the shape of the task.

Review is bounded: here is a diff, what is wrong with it. There is a verification step built in — a human decides whether to act on the comment. And a wrong suggestion costs about ten seconds of attention rather than an incident. That is the profile where delegation reliably pays: a task with edges, and a check before the output matters.

That is the pattern worth generalizing across your SDLC. Not “where can we use AI” but “which of our tasks have clear edges and a real verification step?” Those are the ones to delegate first, and they are usually not the ones on the vendor slide.

The study that should make you measure

Now the uncomfortable one, which almost nobody in this market will show you.

In 2025, METR ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks in repositories they knew well. Developers with AI tools available took 19% longer.

Two honest caveats before anyone weaponizes that. It is a small study in a specific setting — expert developers, mature codebases, tooling from early 2025. And METR itself has since said it believes developers are likely more sped up with current tools, while noting that widespread AI adoption now makes this genuinely hard to measure. Do not treat 19% as a live number.

The practical implication is not “AI makes people slower.” It is: do not survey your team about whether it helped. They will tell you yes, and they may be right, and you will not have learned anything either way. Measure cycle time, defect escape rate, review latency, change failure rate. This is also why only about a third of engineering leaders report significant ROI — Gartner’s read is that teams measure adoption (seats filled, suggestions accepted) instead of outcomes. Adoption is not a result.

Where Macrosol fits

The useful question is not whether to adopt agentic development — that argument is over — but which parts of your particular lifecycle have the shape that makes delegation pay: clear edges, a real verification step, a failure that costs attention rather than an incident. That answer is different for a team on a mature monolith than for one starting fresh, and it is not something a vendor can answer for you. At Macrosol Technologies we help teams work out where in their own SDLC delegation makes sense and where it does not, and just as importantly, how to measure whether it worked once it ships — because the perception gap is real and it does not respect seniority. That work sits alongside our product development and DevOps & cloud practices.

What to plan around

Strip out the benchmark theatre and the productivity numbers, and what is left is genuinely significant: agents are being trusted with substantially longer chunks of real work than they were a year ago, and that trust is mostly earning out. The delegation is real.

But the thing to plan around is not how much faster code gets written. It is that your team’s centre of gravity is moving toward reviewing and designing, that review capacity is about to become your constraint, that the tasks worth delegating are the ones with edges and a check, and that your engineers’ sense of whether this is working is not evidence. Get those four right and the productivity takes care of itself. Get them wrong and you will have a very fast pipeline producing code nobody has genuinely read — which is a problem the pipeline itself inherits next.