Other Handoff Situations: Getting What You Need From Others

The handoff isn't always tool-to-tool

Last time, this series covered handoffs between AI tools — one session's decisions becoming another session's input. But not every handoff starts with AI. Sometimes it starts with a person who understands the domain better than any model does, and the question becomes: what do they need to hand over for the AI dev process to actually work?

A recent example made the difference between a good handoff and a bad one impossible to ignore.

A diagram that left nothing to guess

The requirement was a specific e-commerce deferred revenue posting flow implemented correctly — three stages: prepay deferred revenue GJ entry, sales order invoice, and payment settlement that relieves the deferral. Instead of describing the behavior in a meeting or a paragraph of prose, they handed over a diagram: each stage broken into exact debit/credit rows, with account numbers — 260128-9XX-0000 (Ecom Deferral), 105068-9XX-0000 (Tender), 105085-9XX-0000 (Retail/Ecom Clearing), 503000-9XX-0000 (Revenue) — and a dollar amount ($150) traced through every leg.

There was no ambiguity to resolve. The diagram didn't describe intent — it stated fact: this account, debited this amount, at this stage. Nothing needed interpreting, only checking.

What came back was checkable, not arguable

The validated output lined up four legs directly against the consultant's diagram: Prepay (Tender → Deferral), partial invoice (Clearing → Revenue), payment (Deferral → Clearing), settlement (open balance $0.00). Each row got checked against the corresponding diagram leg, with full dollar figures ($227.11 prepay, $41.73 partial invoice) and the underlying specifics traced alongside it.

That's the part worth noticing: validating the fix wasn't a judgment call about whether the behavior "seemed right." It was a mechanical comparison — does this row match that row. The confidence in "full flow matches the finance diagram" came directly from the shape of the original spec, not from extra scrutiny after the fact.

The contrast: specs that don't survive contact with AI

Compare that to the handoff that's actually more common: "it should work the way it used to," relayed secondhand from a meeting nobody wrote down, with the real requirements living in someone's head. There's no ground truth to check output against — just a vague sense of "does this feel right." Troubleshooting turns into re-litigating what was actually meant, one round trip at a time, because there was never a fact to verify against in the first place.

AI dev processes don't struggle with complexity so much as they struggle with unverifiable requirements. A model can implement a five-stage posting flow with total confidence if every stage has a checkable answer. It cannot reliably guess what "should work like before" means.

Takeaway

The best thing a domain expert can hand over isn't a longer explanation — it's less ambiguity. A table beats a paragraph. Exact account numbers beat "the usual accounts." A number that's either right or wrong beats a description that's open to interpretation. If the people who actually understand the business rules can hand over something shaped like ground truth, the AI development and troubleshooting process gets dramatically more reliable — not because the model got smarter, but because there was finally something concrete to check its work against.

❯ deploy(code) ✓