Cheap AI Output With Costly Checking Is Still Expensive Work
Census data puts U.S. business AI use at 17-20%. An implementation founder argues verification cost, not model quality, will decide the next wave of adoption.
By Daniel Okafor
4 min read
What's News
- U.S. Census Bureau data from late 2025 through early 2026 puts business AI use at 17% to 20%.
- The author founded Main & Machine, an AI implementation firm for small and mid-size businesses.
- Core principle: cheap output with expensive verification is still expensive work.
- The author teaches management and entrepreneurship at Arizona State University's W.P. Carey School of Business.
Only 17% to 20% of U.S. businesses used AI in late 2025 through early 2026, according to U.S. Census Bureau data, and the next wave of adoption will stall not on model quality but on verification cost. That is the core argument made by an AI implementation founder who says owners systematically underprice the work of checking machine output.
The author, who founded Main & Machine, an AI implementation firm for small and mid-size businesses, and teaches management and entrepreneurship at Arizona State University's W.P. Carey School of Business, wrote in a first-person essay that he keeps seeing the same pattern across his roles: "owners celebrate generation and underbuild verification." He disclosed a financial relationship with Main & Machine.
What is the core principle?
The essay's central line: "Cheap output with expensive verification is still expensive work."
The author describes his own first encounter with a finished-looking machine draft. The language was clean and the structure made sense. He then tried to check three claims against source material and, in his words, "burned more time reconstructing the case than the draft had saved." Speed moved. The cost did not disappear. "It had just changed rooms."
The mechanism is simple. Generation reduces first-draft cost. Uncertain output creates a checking obligation. When verification is fast and error is reversible, the gain survives. When checking requires scarce expertise, reconstructing evidence or absorbing liability, the apparent speed just moves cost downstream.
He also dismisses a common shortcut. "I used to treat a second click as proof of judgment. Wrong." A second click still leaves one judgment if the reviewer never saw the underlying case on independent terms.
How should owners price the review path?
His first recommendation: before automating any deliverable, write down three things.
- Who will check the output
- How long that check should take
- What happens when the check fails
He suggests a test this week. Pick one workflow, skip the polished demo, and estimate minutes to generate versus minutes to verify on a hard case. He gives two concrete examples: a restaurant owner might let a tool draft the weekly schedule but still needs a manager who can read labor rules and walk the floor; a clinic owner might let a tool summarize intake notes but still needs a clinician who can open the raw chart. If the hard-case check cannot fit the day, the automation is not ready.
Why do reviewers need an independent route to the facts?
The essay identifies a structural problem in automated review. A reviewer cannot meaningfully check a recommendation when the system is also the only account of the underlying case. When evidence, framing and conclusion arrive through one interface, disagreement requires reconstructing information the reviewer never independently saw. Time pressure then makes rubber-stamping rational.
His principle: "Review needs an independent path to the facts." For high-stakes work, he advises keeping a sampled set of raw inputs beside the machine's summary, and asking the reviewer to name the decisive evidence and the uncertainty before the recommendation appears. He notes the approach applies to customer-complaint drafts for a franchisee, estimate language for a contractor, and client memos for a professional-services owner.
He adds a warning about false confidence: "Agreement alone proves little. Shared framing can produce shared error." What matters is whether disagreement can change the action and survive in the record.
How do teams keep the override usable?
An override that exists only as a policy or a button is not a reliable safeguard, he argues. Automation filters out routine cases, so the exceptions that remain are ambiguous, rare and consequential. Teams that only see clean demos lose the skill needed when a hard case appears.
His principle: "Practice the no until it is usable." He prescribes a drill this month: take three recent outputs the team almost shipped, hide the machine's confidence language, and ask a named owner to reject one with a written reason and an alternate next step. Then watch whether the rejection sticks or gets smoothed over because the draft sounded finished.
What should owners do first?
His starting instruction is narrow: pick one AI-assisted workflow, write the review minutes and the independent evidence route on a single page, and run one override drill with the person who actually owns the outcome — before expanding the tool's reach. The checking cost, he concludes, is the real product.
Original: mainandmachine.com
More from Daniel Okafor
Show full bio
Correspondent covering money, funding and market shifts around entrepreneurship, startups and venture funding at Business Bearings.
1,358 articles