Staff Augmentation When AI Writes the Code: You're Buying Judgement, Not Headcount

If coding agents now write code inside Xcode and Android Studio, why would you pay for another engineer? It is a fair question for a founder, CTO or product owner weighing staff augmentation in late 2026, and it deserves a better answer than a sales pitch.

Here is ours. The agents made writing code cheap. They did not make reviewing it, integrating it or shipping it cheap, and that is the work an augmented engineer has to own. So stop judging an engagement by how many seats it fills, and start judging it by how much judgement it adds: review, architecture and ownership of a part of your product.

We sell staff augmentation, so weigh this accordingly. Every figure below carries its scope, and near the end is a list of what no study has measured.

What changed in 2026

On Apple's side, Xcode 26.3, announced in February, added agentic coding with Anthropic's Claude Agent and OpenAI's Codex. On June 8 Apple announced Xcode 27, which lets developers bring in tools through the Model Context Protocol and, in Apple's words, "connect any agent compatible with the Agent Client Protocol". Xcode 27 shipped on September 14.

The Agent Client Protocol (ACP) is an open protocol between an editor and a coding agent, created by Zed and since adopted by JetBrains. An editor that speaks it can host any agent that does. It is plumbing, not a permission system: which agents may connect to your code, and with what data, is still your decision.

Apple Newsroom: Apple aids app development with new intelligence frameworks and advanced tools

On Google's side, Android Studio ships its own Agent Mode and lets you pick the model: Gemini, Claude, GPT or a local one, plus remote MCP servers. Google also offers an Android CLI, previewed on April 16, so outside agents such as Claude Code and Codex can drive Android builds. We found no statement from Google that Android Studio speaks ACP, so we do not claim it.

On both platforms the agent is now standard equipment, and typing is the part of an engineer's day most exposed to it.

What the evidence actually says

Google Cloud's 2025 DORA report surveyed nearly 5,000 technology professionals: 90% use AI at work, and 30% report little or no trust in AI-generated code. AI adoption correlated with higher delivery throughput and with lower delivery stability. The report's own line is that "AI doesn't fix a team; it amplifies what's already there." All of it is self-reported and correlational, and it is the widest current picture of teams that have already adopted the tools.

Google Cloud: Announcing the 2025 DORA Report

Stack Overflow's 2025 developer survey names the cost of that throughput. The biggest single frustration, cited by 66% of developers, is dealing with AI solutions that are "almost right, but not quite". Almost-right code is precisely what costs review time.

Stack Overflow Developer Survey 2025: AI

The most useful recent study for this decision is an NBER working paper by Demirer, Musolff and Yang (w35275, revised in September 2026). Across three generations of tools, from autocomplete to autonomous agents, GitHub data show coding activity rising sharply while the gains shrink at every step towards a release. The authors name review, integration, testing and release as the binding constraints. Versions of the paper disagree on the headline percentages, so we quote the shape and not the numbers: writing is cheap, shipping is not.

One widely cited trial belongs in the caveat, and METR now marks it out of date. In July 2025 METR ran a randomised trial with 16 experienced open-source developers on 246 issues in large, mature repositories they knew well. With early-2025 AI tools allowed, they took 19% longer. Before starting they had forecast a 24% speed-up, and afterwards they still believed AI had made them about 20% faster. The study page says those results are out of date, and that METR believes they no longer reflect the current impact of AI models on open-source developer productivity. Its February 2026 follow-up, with late-2025 tools, 57 developers and over 800 tasks, pointed towards speed-ups that METR itself calls an unreliable signal: developers who would not work without AI declined to take part, and many avoided the tasks where AI would help most. No clean, current measurement exists for experienced developers on their own codebases, so anyone quoting a percentage speed-up for your team is guessing.

METR: Measuring the impact of early-2025 AI on experienced open-source developer productivity

One gap matters more than any of these numbers: nothing we found compares augmented engineers with in-house hires under AI tooling. Everything below about structure is our practice and our inference, labelled as such.

The counter-argument, taken seriously

The case against renting engineers has support. ISG's Q2 2026 index reported application development and maintenance services under pressure, with pricing deflation, and its leadership said "traditional labor-intensive work is increasingly displaced by LLMs". That is large-enterprise outsourcing, not a two-person augmentation, but the direction is clear. And US payroll data analysed by Stanford's Digital Economy Lab shows employment of 22 to 25-year-olds in AI-exposed occupations such as software development falling relative to less-exposed peers, with no comparable gap for experienced workers. The authors stress that this is correlation, not causation.

We concede the core of it. If what you would buy is extra hands for routine, well-specified tickets, an agent supervised by your own team may now be the cheaper option. Pure headcount is the weak product. But the evidence that weakens headcount (output is cheap, review is the constraint) strengthens the case for people who can review.

That does not make junior engineers useless. In an Anthropic trial with 52 mostly junior engineers learning an unfamiliar library, those using AI scored 50% on a comprehension quiz against 67% for those coding by hand. Anthropic sells coding AI and published the unfavourable result anyway; the study says nothing about long-term skills. Our reading: a junior with an agent needs a senior reading their work, which is why our Junior tier says "Guided by senior team members".

What you are buying now

Strip out the typing and five things remain that an agent does not supply:

• Review capacity. Someone who reads every agent-written diff, understands it, and has the standing to say no.
• Architectural judgement. Deciding where the boundaries go so that several contributors, human or agent, can work without colliding.
• Ownership of an area. One named person accountable for a module or feature end to end, including what breaks after release.
• Platform knowledge that is not in your repository: App Store review, Google Play policy, signing, release timing, and the ways a release gets rejected.
• Tests that act as the oracle. Agent-written code is only as trustworthy as the tests that check it, and someone has to decide what those tests prove.

Scaling Swift projects with modular packages

Where UI tests belong in a SwiftUI app

Structuring a staff augmentation engagement

What follows is how we would set one up. It is practice, not data.

Seniority mix

Start with judgement and add capacity around it: at least one person with explicit review authority, then medior engineers for feature delivery, then juniors under guidance. Our own tiers are written that way: Senior covers "Architecture & technical leadership" and "Mentorship & code review", Medior covers "Independent feature delivery", Junior is "Guided by senior team members". No study gives a right ratio.

Our Junior, Medior and Senior engagement tiers

An AI-tool policy, in writing

The question is not "AI, yes or no". It is which agents may touch your repository, through whose account, under which data terms. As read on October 4, 2026, Anthropic's documentation says consumer plans can have data used for training when that setting is on, while Team, Enterprise and API accounts are not trained on. Cursor lets an organisation enforce Privacy Mode, but use with your own API key falls outside its zero-retention commitments. The risky case is an engineer on a personal consumer subscription. Write down the approved tools, who provisions the accounts, and what may never be pasted into a prompt: secrets, customer data, credentials.

The AI inside your product deserves the same scrutiny, especially if it is locked to one vendor.

Multi-provider AI architecture for apps

Who owns agent-written code

Two facts make it worth asking. The US Copyright Office concluded in January 2025 that prompts alone do not give enough human control for the output to be copyrightable, while human-authored expression and sufficiently creative modification can be protected. And the EU software directive gives an employer the rights in programs written by an employee in the course of their duties "unless otherwise provided by contract". An augmented engineer is not your employee. So ownership has to be assigned in the contract, and a review trail that shows human decisions on the code is worth keeping.

Code review responsibility

Write down who approves a merge, on which side, for which parts of the codebase, and let branch protection enforce it. Decide too whether whoever prompted an agent may approve its output. We would say no.

Timezone overlap as a handover

We have offices in Antwerp and Davao. Davao runs on UTC+8 all year, so it is 7 hours ahead of Belgium in winter (as on the day this is published) and 6 hours ahead in summer. A morning in Antwerp from 09:00 to 12:00 is 16:00 to 19:00 in Davao.

That suits pull-request-based work: a change finished in Davao waits for review when Europe starts its day, and the comments wait for Davao's next morning. It suits pairing-heavy or incident-heavy work less. We do not publish a fixed overlap policy, so agree the shared window explicitly at the start.

Onboarding checklist

• Repository access through your own identity provider, scoped to what the engineer needs.
• A clean checkout that builds and runs the tests, documented in the repository.
• Architecture notes: module boundaries and where the risky code lives.
• Review rules and branch protection, agreed before the first pull request.
• The AI-tool policy, read and accepted.
• A first ticket that is small but real, so the review loop is tested early.
• A named owner on your side who answers questions in the shared window.

No study we found has measured onboarding time with AI tools, so we give no ramp-up figure.

How to evaluate a partner

Ask these of anyone selling you engineers, including us:

1. Who reviews agent-written code, and can they walk you through a review they wrote?
2. Which AI tools do your engineers use on client code, through whose accounts, under what data terms?
3. Does the contract assign the IP in the work, including AI-assisted output?
4. Which senior engineer is accountable for architecture, and how much of their time is on our project?
5. Who on the team has handled an App Store or Google Play rejection, and what did they change?
6. What are the overlap hours, in writing?
7. How is it billed (hourly, daily or monthly), and what happens if we scale down?

A partner who answers with seat counts and velocity claims has not noticed how the work changed.

What this cannot tell you

• No study compares augmented engineers, in-house hires and fixed-scope projects under AI tooling.
• There is no evidence-based team size, seniority ratio, ramp-up time or engagement length. We gave none on purpose.
• The productivity evidence is narrow: DORA is self-reported, Stack Overflow records a frustration rather than a speed-up, METR's July 2025 study of 16 developers on early-2025 tools is marked out of date by METR and METR calls its follow-up unreliable, and the NBER paper's versions disagree on magnitudes.
• The legal points are questions, not answers, and the tool terms quoted were read on October 4, 2026. Both change.

A practical checklist

1. Decide what you are short of: review, architecture, platform knowledge or plain capacity. Only the last is about headcount.
2. Put at least one person with review authority in the engagement before adding anyone else.
3. Give that person ownership of a named area of the codebase.
4. Write an AI-tool policy: approved tools, provisioned accounts, forbidden data.
5. Have counsel check that the contract assigns IP in AI-assisted work.
6. Agree merge approval rules and enforce them in branch protection.
7. Agree the overlap window and use it for handover review.
8. Judge the engagement after a few weeks by what was reviewed and shipped, not by what was written.