The Coached Witness

Green tests tell you which checks passed. A clear README tells you someone, or something, can describe the system. Neither establishes who can handle a failure those checks never exercised. The investment case needs evidence of that capability, even when the code looks good.

Typing less code doesn’t settle that question either. In a March 2025 discussion, Y Combinator’s hosts reported that a quarter of surveyed founders in its then-current batch estimated that more than 95% of their codebase was AI-generated. They described the measure as code produced by humans versus models, excluding imported libraries.

The hosts also described those founders as technically capable of building their products from scratch. Both parts matter. A self-reported figure from one startup batch gives no failure rate for acquisition targets. It does show why the amount of code someone typed is a poor substitute for examining what they understand.

When the answers agree

In its May 2025 Codex launch announcement, OpenAI described using the agent to write features, write and run tests, and draft documentation. The same announcement said manual review and validation of agent-generated code remained essential.

That creates a specific diligence trap. The implementation, its tests, and its explanation can all come from the same workflow. Treat their agreement as independent confirmation and you may count one unchecked assumption several times.

An over-coached witness can give clean, fluent answers whether they understand what happened or have learned the account by heart. The polish makes the two harder to distinguish. An AI-generated codebase can be that kind of coached witness, even with an entirely honest founder presenting it.

Take the payment path. Stripe’s 2017 engineering account explains a failure that happens between a successful operation and its acknowledgement: the server completes the request, but the connection breaks before the client receives the response. The client has to decide whether retrying is safe. Stripe describes reusing an idempotency key, an identifier for the same operation, so a retry can return the earlier result without charging the customer again.

Consider a product that should charge once for a purchase. A test that submits one payment and checks one successful result leaves the lost-response case untested. The code could satisfy that test, and the documentation could describe it accurately, while the application generates a fresh key on every attempt. In the mechanism Stripe describes, the server would then have no shared identifier by which to recognize the retry. If an agent generated all three from that narrow requirement, their agreement wouldn’t settle the missing case.

Humans can make the same mistake. The inference for diligence is to check the requirement independently, rather than mistake agreement among generated artifacts for proof that someone reviewed it. Whether that gap exists in the company you’re buying remains a question to investigate.

Ask the people to show their work

Call the missing evidence answerability: a named person’s demonstrated ability to explain a system’s behavior, investigate a failure, and verify a change. Keep examining the software too. Madewithlove’s acquisition-diligence guide treats team dependency, architecture, delivery processes, and security as separate areas of review. A capable team and a sound technical asset each need evidence.

The payment example gives the conversation somewhere concrete to go. Agree the required outcome before looking at the code: the same purchase should produce a single charge, with the application recording the payment against that purchase. Ask the responsible engineer to predict how the current implementation handles a lost response, including what happens on retry.

Then exercise that case in a safe test environment, arranging for the provider to accept the test payment before the response is lost. Retry through the application and compare the provider’s payment record with the application’s stored purchase after its recovery process runs. Replaying requests directly to the provider with a hand-picked key would bypass the application’s responsibility for preserving that key. A success message alone leaves both a duplicate charge and an unrecorded payment possible.

If the exercise exposes a defect, watch the engineer trace the cause, explain the repair, and demonstrate that the test fails against the broken version and passes after the fix. If they can do that, keep the findings separate: the asset needed a repair, and the engineer demonstrated how to investigate and verify it. Finding a bug, by itself, tells you little about the team’s ability to handle one.

The demonstration can also be coached. Choose the path because it matters to the deal, rather than letting the seller’s best demo set the scope. Change a relevant condition, such as restarting the application between the lost response and the retry. Ask how the operation’s identity survives, then check that prediction through the same records. If the review doesn’t reach that case, leave it marked untested.

Other useful probes stay close to the work:

• Separate development tools from production dependencies. Losing an AI coding assistant differs from losing a model API that serves customer requests. Ask which features depend on each, and exercise any fallback the team claims to have.
• Choose a risky component and ask its owner to explain it with the code, logs, and documentation open. Have them trace their answer to evidence another engineer could use. Then ask who could take over if that person left.
• Ask what the team deliberately chose not to build, which requirement justified that choice, and what would make them reconsider. Look for the constraint in customer requirements or decision records rather than accepting an elegant retrospective answer.

Let people use their normal tools, including AI, and involve the engineers who actually own the work. A founder needn’t be the best debugger in the company. A slow explanation can still lead to a correct diagnosis; an immediate, confident answer still needs checking. Where a session leaves capability uncertain, examine a real incident record or arrange another demonstration before turning uncertainty into a verdict.

An acquirer’s own engineers can run these exercises if they understand the system’s domain and can challenge the deal assumptions independently. Specialist help earns its place where that knowledge or independence is missing. A paid review that merely restates the team’s explanations would reproduce the same problem in a new document. Neither route makes a sampled exercise a guarantee about the whole system.

If the acquisition case assumes the team can maintain the product after closing, put the evidence beside that assumption: who demonstrated the work, what they established, and what remains untested. If only one person can do it, the next question is whether that person is staying and whether someone else can take over. A beautiful codebase can’t negotiate that part of the deal.