Code agents recreate the offshore specification problem at machine speed

A pull request arrives too early, and something in your chest goes tight.

The diff is tidy. The tests are green. The agent has even left a small note explaining what it changed.

And you haven’t yet decided what the customer should see when the warehouse has already picked the order. Or what happens when the carrier takes too long to answer.

The change looks finished before the decision does.

You’re not slow because you want to understand it before it goes live.

You’ve got a release to protect, a colleague waiting for an answer, a queue that won’t get less real because the code appeared quickly, and a life after the laptop closes.

Reading the patch isn’t nostalgia for the old way of working.

It’s part of the work.

Understanding was always part of the work.

This has nothing to do with the machine being clever. The problem is older and it has a name.

Code agents recreate the offshore specification problem at machine speed.

The cheap hour could write exactly what it was told. The agent writes it before the person asking has finished discovering what they meant.

2007 — You write a requirement for a team in another time zone.

2015 — A pull request arrives with questions in the comments.

2024 — The assistant writes the first version of the patch.

2026 — The patch is ready before the decision behind it is.

Work before its boundary

The offshore precedent was never really about distance.

It was about a missing conversation, made visible by distance.

Your buyer wanted customers to correct a delivery address before dispatch. That sentence sounds complete until the warehouse has picked the order, or a carrier can’t accept the change, or you have to tell the customer what happened.

“Address-change feature” was never a specification. It was a name for the part nobody had decided.

The usable version is smaller and much more demanding.

It names your eligible order states, the countries or carriers that can’t change, the required confirmation, the audit record, the customer wording, and a manual exception route.

You pick an outcome measure — fewer support contacts, fewer failed deliveries — and record a baseline.

Then you turn the decision into user flows, an API contract, a state diagram, acceptance examples, telemetry events, and a list of questions still open.

None of that invites you to write a bigger requirements document.

The Agile principles describe working-software delivery in a range of about two weeks to two months, and prefer the shorter one.

A vertical slice exposes a bad assumption about an order state before it becomes a six-month packet labelled complete.

Your old distributed team needed that shared surface because the engineer receiving the task hadn’t heard every half-sentence in the meeting.

Your agent needs it because it will confidently fill the silence.

That’s the correction.

You’re not competing with faster code.

You’re protecting the context that tells faster code what it’s allowed to mean.

“The agent can just take a look” hides exactly the same boundary.

You still have to decide whether an address change belongs behind the existing order-service interface, or whether it leaks warehouse detail into the portal.

You still have to say whether a carrier-validation timeout blocks the change or sends it to the manual queue.

Those aren’t coding choices in the narrow sense.

They’re product decisions with a code-shaped consequence.

The handoff was the product

Offshore delivery discovered something faintly embarrassing about meetings.

The daily stand-up is formally time-boxed at fifteen minutes.

That discipline isn’t a belief that a quarter of an hour settles architecture. It keeps your status short while decisions move into records that survive the next shift.

A current backlog. Reviewed code. Interface tests. Visible build status.

A decision log.

A question that blocks your live work gets a named owner and a due time. A non-blocking discovery goes into the design log with enough context for the next overlap window.

Your handoff is a bundle. Pull-request link, current test result, affected contract version, open decision, and the first action you expect from whoever picks it up.

“Please continue” isn’t a handoff. It’s a request to reconstruct the last person’s mind.

And that reconstruction gets expensive faster than you’d think.

Eight engineers on your team create twenty-eight potential one-to-one coordination links.

The remedy isn’t a calendar full of calls. It’s artifacts that stop the same question arriving twice.

A strong interface, a clear owner and an automated test don’t make people less necessary. They make the necessary conversation about the decision rather than about where the last answer went.

Now put the code agent beside that.

A prompt is a beautiful way to produce a change without producing a durable handoff.

It carries the immediate instruction and omits the state diagram, the contract version, the rejected alternative, the manual route.

It gives the next agent a confident summary, and gives you no way to discover whether the summary is wrong.

That’s faster than the old clarification loop. It’s also the old clarification loop, compressed until it surfaces as a release defect.

Some rules are fixed enough for a deterministic workflow. An agent earns its place where it has to interpret documents or choose among tools across a changing case.

That distinction isn’t anti-agent. It’s the point of using one without letting it turn uncertainty into an unrecorded decision.

A rate card for a missing decision

Offshore development also taught companies that the invoice was only the visible labour layer.

Three supplier engineers at 160 hours a month and US$45 an hour produce an invoice of US$21,600.

That buys 480 booked hours. Not a product boundary, not a resolved architectural question, not a maintained release.

Your bill carries on through discovery, domain explanation, account setup, environment preparation, backlog shaping, architecture orientation and test data.

Then through refinement, review, demonstration, incident response and supplier management.

Your effort sits in product, security, procurement or platform budgets rather than the development purchase order. Which is exactly why the cheap rate acquires such strange authority.

It’s the number everybody can see.

The record from 210 software-development outsourcing contracts separates safeguarding, coordination and adaptability, rather than treating contract detail as one thing.

That’s a useful restraint.

Up-front specification can prevent later coordination cost. A large document that fails to identify interfaces, exceptions and observable acceptance is just more material to misunderstand.

Your aim is the lowest-cost sufficient shared understanding. Not maximal documentation, and not maximal improvisation.

Code agents make the first half of that arithmetic feel obsolete.

The draft is instantaneous, so the specification must have been the delay.

But your forty-five-minute design meeting with five people consumes nearly four person-hours before anybody prepares or follows up. Because a decision is being made across boundaries.

Generating the patch doesn’t remove that decision. It creates an attractive object around which the decision can be deferred.

You can hear the deferral in “we’ll review it in the PR.”

Your review is real work. So is prevention through design review and secure tooling. So is appraisal through testing and acceptance. So is internal failure through pre-release rework, and external failure through incidents, customer remedy, lost revenue, penalties, emergency support.

Those aren’t penalties for failing to trust the machine. They’re the cost of making a change answerable to the service it enters.

At 99% availability, a time-based measure permits 7.2 hours of downtime a month.

Which is why your release path with no credible rollback can cost more than a cheaper build rate saves.

The newer delivery frame is no gentler. DORA names four linked measures. Deployment frequency, lead time for changes, change failure rate, time to restore service.

Story completion by a supplier, or a green final message from an agent, can look fast while releases stay slow and incidents take longer to recover.

The finished-looking thing

A code agent turns your specification into tool-mediated work.

It retrieves your repository issue, inspects a service contract, creates a branch, writes tests, proposes a patch.

Your system should expose what the agent may do. It shouldn’t infer authority from the quality of the explanation.

Because reading, drafting and committing are different effects.

A read can leak. A branch can be deleted. A deploy cannot be unthought.

The ordinary translation is blunt. Don’t give the patch-writing system the production action just because it wrote a persuasive patch.

Governance isn’t the meeting that happened before the agent was switched on.

It stays present while your agent picks a tool, waits for approval, and meets a system that changed underneath it.

That’s the digital form of the old buyer-controlled delivery surface. Authority stays attached to the work instead of being assumed at the handoff.

An approval, then, isn’t somebody visible in a Slack thread. It applies to one decision. Not to the agent in general.

And the final message isn’t the final evidence.

A timeout is not an excuse to guess.

A system that calls every failure “the agent failed” hands you the same problem as a vague offshore requirement.

A finished-looking statement, without the state anybody needs to continue.

The service after the patch

Generated code doesn’t become a maintained service when it merges.

It becomes one when you can demonstrate behaviour against agreed examples. When automated checks pass. When security and accessibility obligations are addressed. When operational signals exist. When configuration and feature-flag status are known. When the deployed version and its limitations are recorded. When dashboards are owned, alerts are routed, and you can roll it back.

A 99.9% target permits a thousand errors per million requests over four weeks.

That isn’t a demand to turn every code review into a compliance ceremony.

It’s a reminder that a feature’s life continues past its most convincing screen.

The production service, not the patch, is where your customer meets the decision.

There’s an old temptation to call all of this friction.

The rate card called it overhead. The prompt calls it hesitation.

But specification, evidence, review and ownership aren’t what’s left over after the useful work is done.

They’re how a distributed team — and now a distributed arrangement of people, tools and agents — keeps a fast change from becoming somebody else’s unexplained emergency.

The patch will keep arriving earlier. That part is real. It may even give you back an afternoon that used to vanish into boilerplate.

But it can’t answer alone the question that made offshore development hard in the first place.

What, exactly, is this allowed to mean once it reaches the world?