The Coached Witness

Now it settles almost nothing, and the sharpest people in the room already know it. They keep asking questions anyway, but they’ve stopped believing the screen.

For most of software’s history, reading the code was the diligence. You opened the repo and the repo talked. Duplicated logic, functions doing six things, no tests around the revenue path, one engineer who understood the database and the deploy and nothing written down: every one of those was a tell, and every tell moved the number. The classic acquirer’s checklist is still full of them, from dependency risk and weak secrets management to a single engineer holding the whole system in their head. The point of that checklist was never the code itself. It was that the code testified about the people who wrote it. Messy code meant a messy team, and a messy team was the actual risk you were pricing.

The Tells Went Quiet

Then the model got good, and it got good all at once.

When a quarter of a YC batch ships codebases that are almost entirely AI-generated, the tells you were trained to read stop meaning what they used to. Consistent patterns? That’s the model’s default, not a discipline the team earned. Tests present and passing? The model wrote them too, often against the same misunderstanding the code encodes. Thorough docs? Generated in the same pass. Every surface signal that used to correlate with a careful team now generates for free, in the same afternoon, whether the team is careful or completely lost.

The risks didn’t leave. Only the signals did. The GPL dependency linked into the proprietary core is still there, under a clean import list. The provider dependency that kills half your features if a model gets deprecated or repriced is still there, invisible behind a tidy wrapper. The single point of failure is still there, except now it isn’t even a person you can interview. As the newsletter Developer-First put it in its read on post-AI diligence, the uncomfortable new default is that “founders can’t fully explain their codebases. They haven’t written, or even deeply reviewed, most of it.” The repo still passes the surface tests. It just stopped confessing.

What You’re Actually Looking At

Here’s the shape of the problem, and it’s worth naming, because once you see it you can’t unsee it on a call.

Depose a witness who’s been over-coached and you get clean, fluent, uniform answers to everything, and you learn nothing, because the same polished testimony comes back whether the person is telling you the truth or hiding the body. The polish didn’t make them honest, only unreadable. That’s what an AI-generated codebase is on a diligence call: a coached witness. It answers every question the same confident way, and cross-examining the artifact, the move that carried technical diligence for thirty years, has quietly stopped working.

The trap is that the polish reads as competence. A stressed diligence team, short on time and long on deals, sees the green tests and the clean structure and lets the technical workstream go quiet so the commercial one can run. That’s exactly backwards. The cleaner the codebase looks and the less anyone can tell you about why it’s shaped that way, the harder you should be listening for the thing the artifact will never say on its own.

The Question the Repo Can’t Answer

So change what you’re diligencing.

You were never really buying the code. You were buying the proxy the code gave you for the team’s judgment, and AI just commoditized the proxy. It commoditized the code too, which is its own quiet repricing: if a competitor’s model can regenerate an equivalent system in a weekend, the system was never the moat, and a beautiful AI-built codebase is closer to a commodity than a defensible asset. What survives as the asset is the thing the model can’t hand you: a team that understands what it shipped well enough to operate it, debug it, and change it under load.

Call the axis answerability. Not “is this code good,” which the artifact will always answer yes. The question is “who here can answer for it,” which the artifact can’t fake, because it routes straight to a person or to silence. YC’s own partners drew the same line about their AI-heavy founders: Jared Friedman noted every one of them is still “completely capable of building their own products from scratch,” and Diana Hu stressed that founders still need “taste and knowledge to judge good versus bad.” That capability is the asset. The generated code is just its shadow.

Answerability is something you test on people, live, not something you read in a repo:

• Hand the founder a failing test on a revenue-critical path and watch them debug it in front of you. Fluency here is the whole signal.
• Ask what breaks if the model provider deprecates the API, bans the use case, or triples the price, and whether there’s a fallback anyone has actually built.
• Point at the riskiest few hundred lines in the system and ask who, today, could explain them without opening the file.
• Ask what they deliberately chose not to build, and why. A team with judgment has a real answer. A team steering a copilot usually doesn’t.

We’ve sat on the far side of that call, brought in to read a system before a term sheet closes, and the pattern is consistent: the codebase almost never fails the technical read anymore, and the team fails the answerability read all the time. The deal risk moved off the screen and into the room, and the diligence that still stares at the screen is looking at the one place the risk no longer lives.

Go back to that beautiful repo on the shared screen. It isn’t lying to you. It just can’t testify to the only thing you actually need to know, which is whether anyone in that company still owns what the machine built. That’s a judgment question, and reading it well before you wire the money is precisely the defined-scope diligence work we do: we cross-examine the team the artifact can no longer indict, and tell you whether you’re buying an asset or a very well-lit liability.