Against the co-pilot metaphor

Every enterprise AI product right now is a co-pilot.

Microsoft Copilot. GitHub Copilot. Salesforce Einstein Copilot. “Your AI co-pilot for finance.” The metaphor has won the naming contest, and it is shaping the products being built.

It is the wrong metaphor for finance. And the products it is producing show it.

What the co-pilot metaphor implies

The aviation co-pilot exists for one specific reason: to take the controls if the pilot is incapacitated or overwhelmed. The co-pilot is trained to full pilot competency. The entire value of the role is the ability to execute without the primary operator when the primary operator cannot.

This is the metaphor’s load-bearing assumption: there are emergency conditions where handing off to the AI is the right move.

In aviation, that is true. In finance, it is not.

Why “handoff in an emergency” is exactly wrong for accounting

There is no accounting emergency where the right answer is “the AI takes over, outputs ship without human review.”

The close-day crunch is not that emergency. Running late on the reporting pack is not that emergency. A controller being sick, overwhelmed, or unavailable is not that emergency.

In those conditions, the right answer is: bring in another qualified human. Escalate. Request an extension. Hold the pack.

The answer is never: ship the AI’s output unreviewed, because we ran out of time.

The reason is not distrust of AI capability. The reason is audit reality. An output that was not reviewed by a named, authorised human reviewer is not a defensible output. It does not matter how accurate the AI was. The output is not signed. The controller cannot stake their professional judgment on a number they did not review. The auditor cannot sign off on a process with no human gate.

The co-pilot metaphor normalises removing the human gate. In finance, that gate is the product.

What the metaphor produces

Software built on the co-pilot frame optimises for the moment when handoff happens. It becomes a complete output generator. It is rewarded for looking capable and looking certain. Its uncertainty is a weakness to hide, because a co-pilot that says “I’m not sure” in an emergency is useless.

This is precisely the opposite of what finance teams need.

Finance teams need a system that is rigorously uncertain about the things it cannot know, never hands off without a gate, and produces outputs that are incomplete until a human completes them. The incompleteness is a feature. It is how the reviewer knows where to focus.

A co-pilot that never achieves full competency is a defective co-pilot. A drafting assistant that never achieves full autonomy is a correctly designed drafting assistant.

A better metaphor: the drafter

A drafter — in the original sense, a technical drafter who produces engineering drawings — produces the document that the engineer reviews, annotates, corrects, and signs.

The drafter is highly competent. The work the drafter does is real work. Without the drafter, the engineer would do it more slowly and with more errors.

But the document the drafter produces is a draft until the engineer’s signature is on it. That is not a limitation of the drafter. It is the definition of the role. The drafter produces material for review. The engineer exercises judgment. The signature is the engineer’s, not the drafter’s.

This is the correct model for finance AI.

• The agent reads source data, builds schedules, populates templates, and produces a structured draft.
• The controller reviews the draft, applies judgment, resolves flags, and approves.
• The output carries the controller’s authority, not the agent’s.

The drafter metaphor does not imply that the agent is less capable. It implies that the agent’s role in the workflow is correctly bounded. It produces material for human judgment to act on.

That is a different design target than a co-pilot. And it produces a different product.

The metaphor you choose determines the product

If your product is a co-pilot, your product roadmap leads toward autonomy. Each version is more capable, hands off more, removes more friction. The vision state is the AI closing the books without you.

If your product is a drafter, your product roadmap leads toward speed and precision. Each version drafts better material, flags uncertainty more accurately, and surfaces the right things for review. The vision state is a controller who reviews faster, flags less, and signs with higher confidence.

The second roadmap produces a finance team that understands its numbers better every cycle. The first produces a finance team that accepts AI outputs with decreasing scrutiny.

We are building the second product. The metaphor is intentional.

What this means for how we talk about Yig

We do not say “co-pilot.” We do not say “autopilot.” We do not say “automates your close.”

We say: you drive, Yig drafts.

Not because it is a better slogan, but because it is accurate. The controller is always driving. The agent is always drafting. The gate is always a human being with a name and a timestamp. That is not the fallback mode — it is the only mode.

If a future version of Yig removes that gate in some context, that context will be designed explicitly and announced clearly, and the rationale will be filed in /docs/security before the version ships.

Until then: you drive. Yig drafts.