AI in software development: why agency size is no longer an argument

There is one line that has worked in agency pitches for twenty years: "We have 120 employees." The number itself is never the point. The point is a promise — resilience, speed, scalability. If someone falls ill, the next person takes over. If things get tight, we put two more people on it.

That promise came from a world in which output was tied fairly directly to person-hours. Anyone who wanted to deliver twice as much needed roughly twice as many hands. In that world, size genuinely was an argument.

That world is gone — at least at the point where it used to make the difference. AI has changed the pace of software development less than the marketing slides claim and more than the sceptics admit. Above all, it has moved the bottleneck: away from writing code, towards judging code. And that shift affects large and small service providers in completely different ways.

What the data says — and what it doesn't

Let's start with the uncomfortable number. In 2025, METR ran a randomised controlled trial with 16 experienced open-source developers across 246 real issues in their own, familiar repositories. The expectation was a 24 percent speedup. What was measured was the opposite: with AI tools, the developers took 19 percent longer. More remarkable still is the self-assessment afterwards — the participants believed they had been 20 percent faster (METR).

That gap between perception and measurement is the most important finding of the past two years. It explains why almost every developer reports massive productivity gains while project timelines in many companies have not moved. AI feels fast because the phase of staring at an empty file disappears. What comes after it — reading, checking, discarding, adjusting — does not feel like work on the task, but that is exactly what it is.

Twelve months later the picture changes

Anyone quoting those 19 percent today as evidence against AI is quoting stale data — METR itself now flags the study as out of date. In February 2026 the team published a continuation with 57 developers, 143 repositories and more than 800 tasks. For the ten developers who also took part in the first round, the sign flips: an estimated 18 percent faster, with a confidence interval running from 38 percent faster to 9 percent slower. Among newly recruited participants the effect stays in the noise at 4 percent (METR, February 2026).

That comes with the caveat METR itself emphasises: the study now suffers from selection effects. Developers decline to participate because they do not want to work without AI, and between 30 and 50 percent reported deliberately not submitting tasks — precisely the tasks where AI would have had the biggest leverage. The real effect may therefore be larger than the measured one.

Two things hold up regardless. First: within twelve months the tools moved from "slows experienced developers down" to "helps those who have mastered them". Second: the gain sits with the person, not the tool. Same models, same tasks — and the difference between regression and progress came down to who operates them and how much practice they have.

The verification tax

Google Cloud's DORA research provides the wide-angle picture: 90 percent of technology professionals now use AI at work, and over 80 percent believe it has made them more productive. At the same time, higher AI adoption correlates not only with higher throughput but also with higher delivery instability (DORA). More changes per week, more of them going wrong.

DORA calls the mechanism behind this the verification tax: the time saved writing moves into reviewing. Review turns from a quality ritual into the bottleneck, and the cognitive load shifts from whoever produces to whoever reads it back. Teams without a solid verification system pay that tax not in time but in production incidents.

The Stack Overflow Developer Survey 2026 shows that developers themselves work exactly that way: 48 percent trust AI output only when they can easily verify it. A full 6.6 percent would trust it for important decisions (Stack Overflow 2026). That is not technophobia, it is a working method: let it generate, then decide yourself.

AI is an amplifier, not a leveller

The sentence worth keeping from DORA's work is this: in software development, AI is primarily an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones.

That is the opposite of what many expected. The expectation was levelling — if the model writes the code, it no longer matters who is sitting in front of it. What actually happens is the reverse. Where clean architecture, clear interfaces, real test coverage and a functioning review process exist, the amplifier turns into speed. Where they are missing, it turns into technical debt — at the same pace.

And this is where the actual subject of this article begins: none of what makes the amplifier usable is a function of headcount. Clean domain modelling does not emerge from more people working on it. A good stack decision does not improve because a committee makes it. Test coverage is a question of discipline, not capacity.

Why headcount was never speed

In 1975, Fred Brooks described in The Mythical Man-Month why adding developers makes a late project later: communication overhead grows not linearly with team size but quadratically. Six people have 15 possible coordination pairs, twenty people have 190. Every one of those connections is a place where context gets lost.

In agencies, a second layer is added that has nothing to do with communication and everything to do with the business model. The larger the organisation, the more likely it is that whoever sells the project is not whoever builds it. In between sit handovers: from sales to consulting, from consulting to concept, from concept to development. At every handover a document gets written instead of a decision getting made.

Those handover costs were always there. They used to be offset by the fact that real capacity stood on the other side: ten developers simply wrote more lines in a week than two. That offset is exactly what disappears. The leverage of raw writing capacity has fallen, the handover costs have stayed. What remains is a structural disadvantage.

This is not an argument against large service providers as such. For multi-country rollouts with parallel teams, 24/7 operating models, or projects in which ten specialist disciplines have to work simultaneously, size remains the right answer. It is an argument against reading headcount as a promise of quality or speed. For the typical commerce project — one shop, one ERP, a handful of interfaces, clear processes — it no longer says anything.

The four decisions that make the difference now

If writing capacity is no longer the bottleneck, then the bottleneck sits with the decisions. Four of them, specifically. Each one is either made by an experienced person in hours or missed by an inexperienced one over weeks — and from the outside the two are indistinguishable at first, because in both cases code appears and the code works.

1. Standard or custom code

AI has dramatically lowered the cost of the first version of custom development. That is the most dangerous change of all, because it appears to shift the build-or-buy trade-off towards "build". Appears — because generated code is an asset with running costs. It has to be read, updated, migrated and dragged along through every major release of the surrounding system.

In Shopware terms: if a requirement can be solved through the official extension points, that is where it is solved update-safely. If a model produces a working core modification in twenty minutes, the requirement is met today and becomes a problem at the next major release. Shopware's own plugin guide names exactly the properties that make the difference later — idempotent migrations, minimal lifecycle logic, encapsulated domain logic (Shopware Developer Docs). Being able to make that distinction is experience. The model does not make it; it implements what it is told.

2. Where the logic lives

Pricing logic in the theme or in domain code. Discount rules in the ERP or in the shop. Catalog transformation in the pipeline or in the frontend. These decisions determine whether a system is extensible in two years or whether every change touches three places.

This is where the amplifier shows most clearly. An AI agent let loose on a clean domain boundary delivers surprisingly consistent results, because the structure constrains the solution space. The same agent in a system without clear boundaries produces plausible code in the wrong place — a great deal of it, very quickly.

3. The verification system

If the verification tax is real, then the verification system is the actual productivity factor. That means automated tests that protect behavior rather than implementation, a CI that genuinely blocks when it is red, staging environments that match production, monitoring from day one — and a human review that does not wave things through.

This is where most AI expectations fail. A team that produces three times as many changes while keeping the same review bottleneck has not gained throughput, it has built a queue. So every discussion about AI speed has to include the question of who reads it back and against which standard. How we organise that is described in Development; what operations look like afterwards is in maintenance and continuous development.

4. What does not get built

The most effective decision is still the deletion. The cheaper implementation becomes, the weaker the natural brake that effort used to provide. Features that previously died on budget now get built — and every one of them has to be maintained permanently.

An agency that says no here saves more money than any efficiency gain in implementation. That does, however, require a business model that does not depend on filling hours. Anyone who has to keep capacity on the bench has a structural interest in using it.

The new risk profile

AI has not reduced project risk, it has relocated it. Four risks are larger today than they were two years ago:

Plausible code that does not hold. Generated code almost always looks right. It names variables sensibly, has a structure and produces no syntax errors. The errors sit in edge cases, side effects and assumptions — exactly where a superficial code review does not look.

Accelerated technical debt. The DORA data shows the link between AI adoption and delivery instability. A system that receives twice as much code in six months as planned is not twice as far along; it is twice as hard to reason about.

Loss of handover readiness. Code nobody on the team can explain is not an asset, it is a dependency. The question "could another team take this over?" is the most honest quality check there is — and it becomes more important with generated code, not less.

Security. More code, faster cycles and dependencies added in passing all enlarge the attack surface. How quickly that turns into an acute incident is something we described in the case of the PHP vulnerability PHP2Shell.

None of these risks scales down with agency size. Two of them — technical debt and handover readiness — are structurally more likely in large teams, because nobody holds the whole system in their head.

How to evaluate an agency today

Headcount appears in every pitch deck because it is easy to state. These eight questions are harder to answer and say considerably more:

1. Does the person I am talking to build? If the answer involves a role that does not work in the code, there is a handover — and with it the first place where context gets lost.
2. Which decision would you make against the standard in our project, and why? An agency that cannot offer a concrete trade-off here has not yet worked through it.
3. Who reads generated code back? And in what ratio to the volume produced? Review is the limiting factor, not generation.
4. What do your projects test — behavior or implementation? Tests against implementation break with every refactoring and therefore get switched off.
5. Does your CI block? A pipeline status that is allowed to stay red is decoration.
6. How long does an architecture decision take with you? "Hours" is an answer; "we'll clarify that internally" is a description of an org chart.
7. What would you cut from our requirements list? Anyone who cuts nothing is selling implementation rather than outcomes.
8. Could another team take over this system in six months? And how would one recognise that before placing the order — documentation, tests, architecture description?

None of these questions has anything to do with size. All eight can be answered just as well by a two-person team as by an agency with 120 people — and in our experience often better, because the answer does not have to be fetched internally first.

What this means for budget and timeline

Three things that have genuinely changed in projects:

Prototypes have become almost free. A contested question — configurator or not, this checkout flow or that one — can now be answered in days as a working piece of software instead of in weeks as a concept paper. That moves decisions from opinion to evidence. The numbers from a measurable strategy are the foundation for exactly this: without a defined metric, the prototype is just a new opinion.

The stack decision weighs more than it used to. When implementation is fast, the choice of platform becomes the dominant cost factor over the lifetime. Licence model, fee structure, extensibility and upgrade path decide things for years — and are hard to correct. We worked that trade-off through in detail for two platforms: Shopware or Shopify.

The outcome share of the budget rises. If less budget goes into implementation, more can go into analysis, measurement and iteration — or it gets spent on additional features. That is a decision, not a consequence. It is made during prioritisation, and that is exactly where the difference lies between a project that delivers and one that contains a lot.

What has not changed: a project does not become half as expensive because the models got better. The effort moves from production into judgement — and judgement is senior work.

How we hold this line

We are two founders, and for us that is not a growth stage but a decision: output per head instead of heads per project. Whoever advises also builds. There is no handover between the conversation and the code, and architecture decisions are made in hours rather than through approval chains.

Five years ago that structure was a capacity risk. With AI tools compressing the implementation share, it turns into an advantage — but only together with the part that remains work: tests that protect behavior, a CI that blocks, monitoring from day one, documentation another team could take over with. We use AI daily, and we use it where it holds: accelerating implementation, not replacing decisions. Which decision gets made is owned by a person with a name.

How that fits together methodically is described in F.O.C.U.S. — Facts before Objectives, Constraints before Execution. With AI, the order has become more important, not more optional: anyone who can build faster can also build the wrong thing faster.

The next step

Three checks you do not need a pitch for:

1. Ask your current provider who reads generated code back. The answer tells you more about your risk than any reference list.
2. Take the last three rejected features and recalculate them. If implementation now costs a fraction, that changes prioritisation — or it shows they were rejected for good reasons.
3. Check whether your system is handover-ready. Not because you want to switch, but because the answer is the best indicator of its condition.

If you would rather not make the stack and implementation decisions alone: that is exactly what we do in consulting, and in development we implement them. Get in touch — a conversation with the people who also build.

Sources and further reading

• DORA (Google Cloud): Balancing AI tensions — Moving from AI adoption to effective SDLC use
• DORA: State of AI-assisted Software Development 2025 (PDF)
• DORA: ROI of AI-assisted Software Development
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR: We are Changing our Developer Productivity Experiment Design (February 2026)
• Stack Overflow Developer Survey 2026: Trust in AI tools
• Shopware Developer Docs: Plugin Base Guide

Read on

• Shopware or Shopify: platform comparison 2026
• Maintenance, retainers and continuous development
• Measurable strategy in e-commerce
• F.O.C.U.S. — the methodology behind our projects
• Development: build, don't discuss