The Second Purchase Order: Where Vibe Coding Ends and Engineering Begins

An explicitly hypothetical distributor workflow — the ERP commits a replenishment purchase order, the acknowledgement times out, the retry buys the same pallets twice — used to separate two dimensions that get conflated: vibe coding as accepting behavior you cannot independently explain, and agentic execution as a system acting on its own. The feature follows the duplicate through warehouse, purchasing and accounts payable, then sets out what must exist before any retry: a stable business intent ID, an atomic uniqueness constraint at the boundary, documented downstream idempotency or a manual hold, and a rule distinguishing duplicate intent from a legitimate second order. It explains why code rollback cannot un-send a supplier order, splits agent-appropriate work from domain-expert judgment, and cites Peng et al. (2023) and METR (2025) as narrow, non-comparable observations.

An illustrative distributor workflow, and the engineering discipline it exposes.

Two purchase orders for the same pallets leave the building six seconds apart. Only one of them was ever intended.

What follows is a hypothetical, described to make a specific engineering point. It is not a client story, not a defect report on any named product, and not a claim about any system in particular.

The failure, minute by minute

A distributor's replenishment logic decides stock has crossed a threshold. It asks the ERP to commit a purchase order for 480 cases across three pallets.

The ERP commits it. The record is written. The acknowledgement back across the integration boundary times out.

Nothing about that timeout is unusual. A network hiccup, a slow response, a load balancer recycling a connection — the request may or may not have been processed, and the caller does not know which.

The integration does what most integrations do. It retries.

Six seconds later, a second purchase order is committed for the same goods.

Now follow it outward. In the warehouse, a receiving appointment exists for pallets nobody budgeted dock time for. In purchasing, a buyer sees two open orders against one supplier and one forecast, and reasonably concludes demand doubled. In accounts payable, an invoice arrives that matches one order and contradicts the other.

Only one of those three teams is likely to notice quickly. And the cost is not the duplicate order. It is the three weeks of reconciliation, the supplier conversation, and the quiet loss of confidence in the system that produced it.

Two axes, not one spectrum

"Vibe coding" and "agentic execution" get used as if they sit at opposite ends of a single line. They do not.

Vibe coding, in the useful sense, is accepting behavior you cannot independently explain. The code works, you watched it work, and you cannot tell a reviewer why. That is a property of the relationship between you and the artifact.

Agentic execution is a system taking actions on its own. That is a property of the architecture.

You can have either without the other. An agent can be deployed with total rigor behind a written specification. A hand-written prototype can be a pile of unexplained behavior held together by a demonstration.

Which means the honest question is not "AI or not." It is whether this artifact is disposable or load-bearing.

A conversational prototype — a script someone runs to find out whether an idea has legs — is often the correct tool, and holding it to production standards wastes money and morale. The same code path committed to moving inventory is a different category entirely.

What has to exist before anything retries

Four things. All four are ordinary engineering, and none of them requires a model to be involved.

A stable business intent identifier. The replenishment decision is one intent. The first attempt and the second attempt are two transmissions of that intent. If the retry generates a new identity, no downstream system can tell the difference between a duplicate and a genuinely second order.

An atomic uniqueness constraint at the boundary. The database — not the model, not the integration's memory of what it tried — must be the thing that decides there is only one of these. Uniqueness enforced in application logic above a boundary you do not control is a suggestion.

Documented downstream idempotency, or reconciliation, or a hold. Before a retry is permitted, someone must have written down what the receiving system does with a repeated key. If the answer is unknown, the correct behavior is a manual hold, not optimism.

A distinction between duplicate intent and legitimate repetition. Distributors really do order the same item twice in a day. A deduplication rule that blocks the second genuine order is a different failure with the same cost. The intent ID has to identify the decision, not the goods.

Why rollback has no answer here

Most teams carry a mental model in which a bad change can be reverted. That model holds for the code. It does not hold for the world.

You can roll back the deployment. You can revert the branch. You cannot un-send a purchase order to a supplier who has already confirmed it, and you cannot un-book a receiving appointment by redeploying.

This is where senior judgment earns its place, because the question stops being technical. Someone with domain authority has to decide whether the second order is canceled, absorbed, or confirmed and resold. The agent cannot make that call. It has no view of the supplier relationship, the promotional pricing on that SKU, or the customer waiting on the delivery.

The record that settles the argument

When the duplicate is discovered, the first question in the room will be "what happened." The answer has to exist already, or it will be reconstructed by three people from three consoles, badly.

A workable record carries the intent ID, each attempt made against it, the boundary responses received — including the absence of one — the identity that made each call, and the timestamp. That is not a model artifact. It is an integration log written with intent rather than emitted by accident.

It has a second use. Six months later, when someone asks why a supplier was paid twice and then credited, the record answers without a meeting.

What the agent should own, and what it should not

The split is more useful than the debate.

An agent is genuinely good at the tedious, exhaustive work a busy team skips under deadline.

Mapping the paths. Enumerating every route a request can take through an integration, including the ones nobody documented.
Proposing alternatives. Generating three designs for the uniqueness constraint and stating the trade-offs of each.
Building the harness. Writing failure-injection and concurrency tests that simulate a timeout, a dropped response and two simultaneous attempts.
Adversarial cross-tenant tests. Probing whether one distributor's intent ID can be read or acted on from another's context.
Traces and evidence. Instrumenting the path so a reviewer can see what was asked, what ran, and what the boundary returned.
Rollout and rollback rehearsal. Rehearsing the feature-flag off-switch and the data-repair procedure before the first live order.

What it should not own: the decision about what happens to a wrongly created order. That is a commercial judgment with a person's name attached to it.

What the studies actually measured

Two pieces of research get quoted constantly, and both are narrower than the quoting suggests.

A 2023 controlled experiment with GitHub Copilot asked recruited developers to implement an HTTP server in JavaScript as quickly as possible. The group with access to the AI pair programmer finished 55.8% faster than the control group. That is a real result, from one task, in one language, on greenfield work.

A 2025 METR study observed 16 experienced open-source contributors completing 246 tasks in mature repositories they already knew well. Allowing early-2025 AI tools increased completion time by 19%. That is also a real result, from a specific population, using a specific generation of tools.

The two are not a head-to-head. They used different tasks, different populations, different tools and different years. And neither one treated senior oversight as a variable — which is precisely the thing this article is about.

Read together, they support a modest claim: measured productivity depends heavily on the task and the context. Nothing in either study tells you whether your second purchase order will be caught.

The test that has to fail first

Before any of this reaches production, there should be a test that fails on the current code.

Not a test written to pass. A test written from an independent oracle — an expectation derived from the business rule, not from the implementation — asserting that one intent produces exactly one order when the acknowledgement never arrives.

Run it against the code as it stands. It should fail. If it passes immediately, either the defect was never there or the test is describing the implementation back to itself.

The same harness should cover concurrency: two attempts arriving in the same millisecond, a response arriving after the retry already fired, and a partial write at the boundary. And it should cover the boring case too — the legitimate second order, which must not be blocked.

Permissions, secrets and the human gate

An agent helping build this should not hold production credentials, and it should not be able to write to the ERP's core tables directly. The blast radius of a confused instruction is exactly the privilege it was granted.

Anything a third party sends — a supplier document, a customer email, a PDF attached to a complaint — is data to be interpreted. It is never an instruction to be obeyed. An agent that cannot tell the difference between content and authority is an agent that can be talked into a purchase order.

And there should be a human gate on production writes that move money or inventory. Not because the agent is untrustworthy in the abstract, but because the person who signs off is the person who can explain the decision in the review six months later.

An executive framework with three numbers

Tool adoption is easy to measure and tells you almost nothing. Three numbers tell you more, and all three are cheap to collect if you decide to collect them before the pilot starts.

Review and rework hours. Hours a senior engineer spends reading and correcting agent-produced changes, per change merged.

Escaped defects. Issues reaching a shared or production environment, per hundred changes, split by severity.

Lead time to a correct result. Elapsed time from a stated requirement to an accepted, working change — not to the first draft.

Baseline all three on one repository and one change class. Then run the pilot. A team that shipped twice as many drafts with review hours up 80% has learned something honest about where the constraint moved.

What to ask before the next sprint

Which of our workflows create records outside our control? What happens if the acknowledgement never arrives? Who decided that, and can they show me where it is written down?

Those questions predate AI. The agent did not create the timeout, and it will not reconcile the invoice. What it can do is help a disciplined team find every path where the ambiguity lives, and build the constraint that makes the answer unambiguous.

The second purchase order is not a story about a model. It is a story about what happens when a system is allowed to act without anyone having decided what "once" means.