Don't Outsource the Thinking

Two founders sat down for coffee. One had spent eighteen months scaling an offshore team to fifteen developers. The other had spent six months ramping Claude Code and Cursor across a four-person in-house team. They had spent very different amounts of money. They had the same problem.

Neither understood their own codebase. Both had shipped features nobody used. Both had a bug list that grew faster than it shrank. Both kept paying for tooling — humans in one case, models in the other — and watching the cleanup cost outrun the savings.

The mistake was identical. Both founders had outsourced the thinking. They got faster execution and slower learning, more code and less understanding, and a maintenance bill that compounded against them.

The Failure Mode Is the Same in Both Directions

DORA's 2024 and 2025 reports both flag this directly. AI usage correlates with throughput gains and stability losses. The 2024 report introduced the Rework Rate metric — alongside a broader move away from the older Elite / High / Medium / Low framing — to capture what was happening inside teams that were shipping more but learning less. The 2024 cluster analysis grouped teams into seven archetypes, and the archetypes that adopted AI without disciplined practices showed the same pattern that's been documented in heavily-outsourced organisations for years: more output, more rework, less code health, more time spent fixing what was just shipped.

GitClear's 2024 study on AI-assisted coding pointed at the same pattern through a different lens — code churn, the percentage of code rewritten or deleted within two weeks of being committed, roughly doubled in heavily-AI-augmented codebases. Code reuse dropped. The shape of the work changed: more first-drafts, fewer second-thoughts, more code with no obvious owner.

This is what outsourcing the thinking looks like at scale. It does not matter whether the executor is human or a model. The failure mode is missing thinking, not missing talent.

What "The Thinking" Actually Is

Engineering thinking has four components that don't compress, no matter who or what is doing the typing.

1. Specification. Turning ambiguous human intent — "users should be able to upgrade their plan" — into a list of concrete, testable behaviours. What counts as an upgrade. Who's allowed to do one. What happens to a prorated charge. How the system behaves when payment fails halfway through. These are the dozen questions the PM didn't think to answer. Asking them is the work. Writing them down is the contract. Without the contract, no executor — agent or human — knows what they're building.

2. Architecture. Choosing the boundaries. Every system has a dozen reasonable ways to be cut into modules, and the choice you make determines which kinds of change are easy six months from now and which kinds will require a rewrite. This is a judgment call that depends on knowing where the product is going, which is hard to brief into a contractor and harder to brief into a model. Clean architecture in the age of AI isn't a stylistic preference — it's the substrate that determines whether your executors can act safely.

3. Test design. Deciding what "correct" looks like before the code exists. The TDD practitioners have been saying this for twenty years: TDD is a design tool, not a testing strategy. The act of writing the test first forces the spec to be specific. It forces the architecture to be testable. It is, in itself, an act of thinking. When you skip it, you're hoping the executor will fill in the missing thinking through good taste — and good taste is exactly what neither offshore teams nor AI agents reliably have without context they don't have access to.

4. Critical review. Looking at the output — regardless of who produced it — and judging whether it meets the bar. This is the activity that closes the loop. It's also the activity that breaks first under volume. A team that's shipping ten PRs a day from a model or from a vendor and reviewing each one in three minutes is not reviewing. It is rubber-stamping. The thinking is gone, and what's left is a moving belt.

These four activities determine most of the outcome. They are also exactly the activities that scale poorly to executors who lack your context — and "your context" is the part that does not fit in a brief.

Figure 1: The delegation matrix. The left column is irreducible thinking work. The right column is delegable typing work. The line between them — the harness — is what makes the right side safe to delegate.

Why Outsourcing the Thinking Always Fails

Three reasons, and they're the same whether the executor is a person or a model.

Context doesn't transfer. The reason your senior engineer makes a different decision than your offshore vendor on the same ticket is that the senior engineer has the last eighteen months of incidents, retros, customer calls, and product pivots compressed into their judgment. None of that fits in the ticket. None of that fits in a prompt either. You can document some of it, but documentation is a lossy compression of context, not a substitute. When the executor lacks the context, the output is plausible — and plausible is the most dangerous failure mode in software, because it ships.

Judgment is invisible from outside. Reviewing whether someone else's spec is good requires understanding the problem at least as deeply as the person who wrote it. If your team isn't doing the spec, your team can't review the spec — they can only check whether it parses. The same thing applies to AI-generated specs. The agent will produce a spec; whether it's the right spec for your product, your customers, and your roadmap is a judgment call your team has to make. If your team isn't doing that judgment work, nobody is.

Accountability decays under delegation. When something breaks in a system the executor designed, nobody on the in-house team knows enough to fix it quickly. Mean time to restore climbs. The cost of the next incident climbs with it. Worse, the team loses the muscle to catch the next bad design before it ships, because the muscle was never built. This is the long-term failure mode that the cost-arbitrage models for outsourcing — and the productivity-arbitrage models for AI — both miss. You get cheaper code production. You get more expensive ownership.

The Harness Pattern: Encoded Thinking

The fix isn't "do everything in-house." That throws away the throughput leverage that AI agents and skilled execution partners both genuinely offer. The fix is to encode your thinking so that execution can be safely delegated to anyone — or anything — that can read the encoding.

This is the harness pattern, and we've written about it before in the context of AI agents. The pattern generalises. A harness is the set of constraints — executable specs, architectural fitness functions, test suites, CI gates, review checklists — that make it safe to delegate execution because the constraints catch the kinds of mistakes that delegated executors reliably make.

The harness is your thinking, written down as code. The spec is encoded as tests. The architecture is encoded as fitness functions and dependency rules. The definition of done is encoded as CI gates. The review judgment is encoded as automated checks for the patterns you don't want to see.

Once the harness exists, an AI agent can execute against it. So can an offshore engineer. So can a junior on your in-house team. The harness doesn't replace the thinking — it preserves it, in a form that other executors can act inside without re-doing it. The teams that get throughput leverage from AI agents are doing exactly this. The teams that struggle have skipped the harness and are still hoping the executor will fill in the missing thinking by good taste.

Figure 2: The harness pattern. Intent flows through encoded thinking — specs, tests, fitness functions, gates — before any executor touches it. Any executor can sit in the bottom row; the harness is what makes the delegation safe.

Monday Morning: A Four-Step Audit

You can run this on your own team in a single afternoon.

Step 1: List the last ten features you shipped. For each one, write down where the spec came from. If the answer is "the PR description" or "the Linear ticket," circle it — those are tickets, not specs. A spec is what the executor would need to be told to produce the right thing. If the executor on your team was the spec author, your team is keeping the thinking. If the spec was assumed and the executor filled it in as they went, your team is leaking thinking into execution.

Step 2: Look at the test suites. Are tests being written before the code or after? After-the-fact tests document what the code happens to do; before-the-fact tests document what the code is supposed to do. The difference is exactly the difference between executing without thinking and executing with encoded thinking. Decorative tests are the visible symptom of the test-after pattern.

Step 3: Audit your recent reviews. Pull the last twenty merged PRs. For each one, count the substantive review comments — questions about the spec, the architecture, the test design — versus stylistic or nit comments. If the ratio tilts toward nits, your review process has stopped reviewing thinking and started reviewing surface. That's a leading indicator that thinking is being outsourced inside your own team.

Step 4: Map where your harness has holes. Where is the spec encoded? Where is the architecture encoded? Where is "done" encoded? If the answers are "in our heads" or "in a doc nobody reads," your harness is verbal — which means it's not portable, which means it doesn't survive delegation. Anywhere the harness is verbal, you cannot safely delegate execution.

The audit is uncomfortable on purpose. It surfaces the exact gap that AI agents and offshore teams both exploit when they fail.

The Bottom Line

The arbitrage that made offshore teams attractive — execution at a discount — is the same arbitrage that makes AI agents attractive. Neither arbitrage works if you outsource the thinking, because the thinking is the work. Outsource the typing. Encode the thinking into a harness. Then any executor — model, partner, junior, senior — can sit inside the harness and produce work you can trust. That's what AI-native engineering looks like in 2026. It's also what disciplined offshore engineering has always looked like. The principle is older than the tooling.