AI for development agencies.

Where AI for development agencies actually pays off.

Development agencies have a more structured delivery pipeline than most service businesses: ticket, branch, PR, review, QA, release. That structure is good news, because the highest-value AI applications attach to specific stages of it rather than floating around as a vague instruction to use ChatGPT more. Across the dev shops we've audited, four keep coming up:

The productivity numbers are messier than the demos.

Adoption is nearly universal while trust falls. In the 2025 Stack Overflow developer survey, 84% of developers said they use or plan to use AI tools, up from 76% the year before, yet 46% said they distrust the accuracy of the output, against 33% who trust it. Everyone uses it, half don't trust it: a fair summary of the current state.

The strongest single argument against a vibes-based rollout is METR's 2025 randomized trial. Experienced open-source developers, working on real issues in mature repositories they knew deeply (mostly using Cursor with Claude models), took 19% longer when allowed to use AI, then estimated afterwards that AI had made them about 20% faster. The setting matters: experts inside codebases they know well is precisely where AI's context advantage is smallest. But the perception gap is the lesson for agency owners, because your team's self-reports will look exactly like that.

The delivery-level evidence points the same way. Google's DORA research in 2024 found that each 25% increase in AI adoption was associated with a roughly 1.5% dip in delivery throughput and a 7.2% drop in delivery stability. By the 2025 report the throughput effect had turned positive, but the instability had not gone away, and DORA's framing settled on AI as an amplifier of whatever delivery culture already exists. Disciplined teams got faster. Undisciplined teams shipped mistakes faster.

The delivery pipeline, stage by stage.

The useful question is never whether to use AI but which stage gets it and under what supervision. Our default map for a dev agency:

Where it does not help, and pretending costs you.

The honest half of the vertical picture, and the half the tool vendors skip:

• Novel architecture and hard tradeoffs. The model has seen a thousand generic answers to your question and zero versions of this client's actual constraints. Use it to enumerate options, never to pick one.
• Almost-right code in mature codebases. Plausible-but-wrong changes are the most expensive output a model produces, because they pass a tired reviewer. This is the failure mode behind the METR slowdown, and it gets worse as a codebase gets older and more particular.
• Large unattended changes. DORA's stability findings have a mechanical cause: AI makes big batches cheap to produce, and big batches are exactly what reliable delivery avoids. If AI is tempting your team into thousand-line PRs, it is making you worse.
• Anything a client contract restricts. Some MSAs now carry explicit AI clauses; many older ones are silent, which is not the same as permissive. Where code and data may be sent is a legal question before it's a tooling one.

Client work changes the calculus.

An in-house product team lives in one codebase for years. That's where METR's subjects were, and where AI's context advantage is smallest. Agency reality is the opposite: a developer might touch three client codebases in a week, and every rotation, every handover, every request to pick up where a departed colleague left off pays a context tax. AI is unusually good at exactly that tax, which is why we expect development agencies to see better returns than the in-house studies suggest, concentrated in onboarding and re-entry rather than raw code output.

The billing model matters too. If you sell hours and AI compresses them, you have a pricing conversation coming, not just a tooling one. And every tool decision has to survive contact with client agreements: what can leave your machines, which vendor tiers train on inputs, who indemnifies whom. Boring questions, decisive answers, worth settling once in writing before the team standardizes on anything.

Rolling it out without wrecking review discipline.

The rollout pattern that works is unglamorous: measure, constrain, standardize. One asset carries a surprising share of the value: a short written conventions file in every client repo (stack, commands, patterns, gotchas) so the model stops guessing. If your team works with Claude, skills are the packaged version of the same idea: process the model applies automatically instead of process a developer has to remember to paste in.

1. 01:

   Baseline before tools

   Pull a month of cycle time, review time, and change-failure data from the PM and CI tools you already run. Without a baseline you are managing on self-reports, and the METR result shows what those are worth.

2. 02:

   Pick two pipeline stages, not a platform

   Context reconstruction and review prep are the usual first picks: high frequency, small blast radius, no client-facing output. Resist the everything-everywhere rollout.

3. 03:

   Write the conventions down

   One page per client repo: stack, build and test commands, patterns to follow, known traps. Half an hour per repo, and it improves every AI interaction that touches the code afterwards.

4. 04:

   Standardize one stack

   One assistant with a shared configuration, one review-assist step, then stop adding. A tool per developer preference means no shared conventions and no comparable numbers.

5. 05:

   Keep PRs small on purpose

   Add a batch-size norm at the same time as the tools, not after the first incident. This is the cheapest available defense against the instability pattern DORA keeps measuring.

6. 06:

   Re-measure at 90 days

   Compare against the baseline and drop what didn't move it. Renewal decisions belong to the numbers, not to whoever likes the tool most.

Do it yourself, or bring us in.

Everything above is doable internally. The measurement comes from tools you already run, the conventions files are an afternoon of writing, and the batch-size rule is management, not technology. The failure mode we actually see is different: the rollout happens tool-first, nobody baselines, and six months later the only evidence is a stack of subscriptions and a feeling of speed that may or may not be real. Our stack guide exists partly because of how often that stack has quietly doubled by then.

We run AI workflow audits with development agencies to find which pipeline stages are worth automating and in what order, and when the answer involves building something, our AI engineers build it inside your team rather than around it.

Frequently asked questions.

Keep reading.