Agentic Software Development Created New Friction Points—Where to Find Them, How to Fix Them

TL;DR

AI is making software development faster than ever — but speed without alignment just moves the slowdown somewhere else. AppDirect's SVP of Engineering and Technology identifies the four friction points that emerge when coding gets cheap, explains why three already have practical solutions teams can act on today, and maps out where the real frontier lies. A clear-eyed read for engineering leaders, business executives, and anyone trying to get more out of their AI investment.

Coding got faster, creating new bottlenecks

Over the past year, our engineering teams have been adopting agentic development at real scale.

The surprising part wasn’t that engineers could produce more code. We expected that.

The surprising part was where the friction moved.

For decades, one of the major constraints in software engineering was writing code. AI has started changing that. If you’ve adopted agentic development at any meaningful scale, you’ve probably seen the first half of this story already: output goes up. More PRs merge. The same engineer can ship much more than before.

That gain is real.

But the work doesn’t become frictionless. The friction relocates.

Bottlenecks don’t disappear. They move. And when coding gets faster, the drag tends to pile up on either side of it: before the code is written and after the code is produced.

I’ve started calling this agentic friction: the new strain that shows up precisely because the code part got fast.

Many engineering organizations adopting AI are starting to hit the same four walls, whether they’ve named them or not.

The shape of the problem

Picture the development lifecycle as a line:

The middle part — coding — is what got faster.

That means the constraint moves outward to the steps around it. Two are upstream of the code. Two are downstream.

Four friction points slowing down AI-powered dev teams 

Requirements

Cheap code makes vague requirements more expensive, not less. When implementation was slow, ambiguity often got clarified naturally. An engineer hit a confusing part, asked questions, and the spec firmed up over days of work.

Now the agent doesn’t slow down at ambiguity. It generates the wrong thing quickly and confidently.

The cost of unclear thinking used to be paid in friction. Now it is paid in throwaway output.

Ambiguity has become a defect.

UI/UX design (upstream)

When engineers can implement a feature in an afternoon, design can become the pacing function for the whole feature. That is a sign of how much design matters, not how little.

The scarce resource is no longer just the build. It is a well-considered interface to build.

Teams that scaled engineering throughput with AI without giving designers similar leverage are now watching some of the most valuable work stall in a queue that did not previously exist.

PR review

This one surprised us. If you merge twice as many PRs, someone still has to review twice as many PRs.

Review latency quickly becomes the new cycle-time killer. All the velocity you bought upstream can back up behind a scarce, tired human at the end.

You can ship code in hours and still wait two days for someone to look at it.

UAT and validation

More features shipping faster means more to validate before release. The volume can quickly outpace what any team can cover by hand.

The constraint is not QA/QE talent. It is that the manual, repetitive part of validation did not get the same leverage that building did.

So the same bottleneck shows up again: a scarce, high-judgment human step swamped by upstream volume.

That is the shape of agentic friction.

Requirements and design pile up before the code. Review and validation pile up after it. The middle got fast, and the two ends became the constraint.

Three of these are already solvable

These are not theoretical problems we are bracing for. They are here now. And in our experience, three of the four already have practical answers.

For the design bottleneck, we gave our designers the same leverage AI gave our engineers.

When design becomes the pacing function, the question is not “how do we need fewer designers?” It is “how do we let designers operate at the speed the rest of the pipeline now moves?”

For one internal product, we built a repeatable, principle-grounded way to generate and iterate on strong design options quickly. Agents proposed data-visualization-grounded layouts, while designers and engineers steered, critiqued, and refined them.

We leaned on Edward Tufte’s principles, including concepts like data-ink ratio and chartjunk, to create a shared vocabulary between design and engineering for what “good” looked like.

The result was practical: we were able to explore and converge on a redesigned application interface in about a day of focused work — the kind of effort that previously might have waited weeks for an open design slot and then stretched across many development iterations.

The bottleneck was never design talent. It was the absence of tooling that let that talent scale the way agentic coding let engineering scale.

For PR review, automate the mechanical pass.

Start with the real question: what do you want a review to achieve?

Catch real defects. Protect the architecture. Transfer context. Preserve accountability.

Not rubber-stamp changes. Not nitpick formatting a linter should catch.

Automated reviewers, now increasingly built into modern AI development tooling, can run on every PR before a human looks. They can catch a whole class of issues first: security findings, missing edge cases, schema changes with unexpected ripple effects.

By the time a person reviews, the mechanical pass is done, and their scarce attention goes to judgment, not mechanics.

But there is an important nuance: review and approval are not the same thing.

The hard part is not only catching issues. Automation can help a lot there. The harder question is which PRs actually need human accountability before they merge.

The answer we landed on is risk-based gating.

Automated reviewers can tag changes by risk level. Low-risk changes can move through with automated approval. Medium- and high-risk changes route to a human.

That distinction matters, especially in regulated environments. Compliance obligations may still require human accountability for certain classes of change. Your automation strategy has to respect that, not paper over it.

Done right, human review attention is reserved for the PRs that warrant it. Review latency comes down without dropping the bar, and without pretending a machine can own accountability it cannot.

For validation, we let agents do the repetitive first pass so QE can focus on the judgment.

The point of validation was never the mechanical clicking through. It is deciding what “working” means, spotting subtle regressions, and knowing where a feature is most likely to break.

That is QA/QE expertise.

And it gets buried when a tester spends the day manually walking happy paths on staging.

So we point an agent at the real application. It drives the app, records video, captures screenshots, and returns a structured list of findings: bugs, friction points, and suggested improvements.

QA/QE engineers review findings, not raw screens. They spend their time on test strategy, edge cases, and the calls only an experienced eye can make.

The agent does the legwork. The judgment stays where it belongs.

The pattern is the same in all three cases: the bottleneck was a scarce, high-judgment human step. We inserted a tool that handles the mechanical majority so the human can focus on the part that actually requires a human.

Requirements are the frontier—solutions are emerging

That leaves requirements, the highest-leverage bottleneck still in front of us.

Cheap code makes vague requirements more expensive because the agent does not slow down at ambiguity the way a human implementer often would. A vague, one-sentence epic can now translate directly into wasted spend and rework.

The team that does for the front of the pipeline what automated review did for the back — turning a one-sentence epic into a clear spec, fast — captures one of the biggest remaining gains in the lifecycle.

I do not think there is a single tool that solves this yet. But the practices that work are already emerging:

Pre-plan for clarity before the build starts

PMs and EMs need to engage early enough to refine an epic to roughly 80% clarity before development begins, so the team can execute without stalling halfway through.

Prototype earlier

Cheap implementation cuts both ways. Instead of waiting for a polished final spec, deliver a small proof of concept early. Make the outcome visible. Pull product feedback forward. The thing you could not afford to throw away before may now be cheap enough to use as a conversation starter.

Decide who owns the spec

This one is genuinely worth debating. Is a clear epic the responsibility of the EM and PM? Should engineers use their own product instincts to propose an initial design before the spec is fully baked? There is no universal answer, but ambiguity about ownership becomes its own bottleneck on top of ambiguity in the requirements.

Pair these practices with the right tooling as it arrives, and requirements can stop being the wall they are for many teams today.

This is where I would point some of your sharpest people next.

The person in the middle

There is another piece leaders should not miss.

The engineer producing all this extra output — running multiple agents in parallel, shipping far more than before — may also be your most exhausted person.

The impact and the strain are often sitting in the same human.

Your highest-leverage people may be both your biggest win and your biggest retention risk right now.

The fix is not only protecting their time. It is protecting their context.

Concretely: fewer parallel threads, not more. Batch reviews instead of context-switching into them all day. Protect uninterrupted bandwidth for the genuinely hard tasks. Set clearer priorities. Give explicit permission not to absorb every interrupt.

Leverage without boundaries is a faster way to lose good people.

Documentation runs through everything

One more thing connects almost every point above: documentation.

Documentation is context for your agents.

Bad or missing docs used to slow down onboarding. Now they directly degrade the output of every AI agent on your team.

That reframes documentation from “hygiene we will get to later” into a direct input to productivity. It changes whose job it is and how much it matters.

The practical move is to treat docs as a first-class deliverable. Functional documentation should be part of shipping, the same way technical design is. Documentation quality should show up inside your existing engineering metrics.

It is not a separate initiative. It is the substrate that makes requirements, design, review, and validation compound.

What to do this week

If you lead an engineering team, here is the exercise I would run:

Ask where the scarce thing moved now that writing code is getting cheaper.

It is probably one of these:

• Unclear requirements
• A design queue
• A review backlog
• A validation bottleneck
• The cognitive load on the people generating all the output

More and more, the leverage is not only in the code. It is in the work around the code.

The bottleneck moved.

The only question is whether you have looked closely enough to see where it went.

I lead global engineering at AppDirect, where we have spent the past year adopting agentic development across a distributed team. We have learned — sometimes the hard way — that once coding stops being the constraint, the friction does not disappear. It moves.

If your team is seeing the same pattern, I would love to compare notes.

Where has the bottleneck moved for you?

This article was reprinted from Mathew Spolin’s article on LinkedIn. Read his recent blog, How to Adopt AI Development at Scale: AppDirect’s Leap from 0% to Over 90% AI-generated Code, for more insights on AppDirect's move to AI-assisted development at scale.

Ready to try your hand at AI coding?

Are you or your customers looking for the right platform to build apps, AI agents, or get access to all the top LLMs? Devs.ai by AppDirect just launched a major expansion of its enterprise AI platform, including the new App Builder. Any team can now build production-ready, branded AI apps on their own data in days—without touching infrastructure or waiting on engineering. Free to start.

Read our blog, The Three Reasons Enterprise AI Stalls, and How Devs.ai Clears All of Them, for more details about using AI to create what your organization needs.