I diligence AI companies from the terminal, not the deck

A founder sent me a pre-seed deck on a Tuesday. Fourteen slides, clean, a tidy hockey stick, the usual benchmark table on slide nine. By Wednesday afternoon I had spun up their product, put it to work inside my own daily workflow, and seen enough to know the deck was describing a different company than the one I was looking at. Not a dishonest founder. Just the gap that always exists between the pitch and the thing.

I wrote them a term sheet anyway. The reason I wrote it had almost nothing to do with the deck.

I do most of my early-stage diligence from a terminal now. Not from the data room, not from the deck, not from the warm intro chain. I sign up for the product like a customer, I run the thing against my own daily work, and I read whatever is public: the code, the changelogs, the docs, the logs it shows me. The deck tells me what the founder wants me to believe. The product, the repo, and the logs tell me what is actually true. For an AI company at pre-seed, those two stories diverge more than in any category I have ever invested in, and the divergence is the signal.

Here is the process, because people keep asking how a check-writer ends up with a command line open.

Why the deck stopped being enough

A deck was a reasonable proxy when building a product was slow. If a team had a working demo and six months of traction, that demo cost real engineering, and the deck was a fair summary of hard-won progress. You could read the slides and trust that the underlying work existed.

That is no longer true. A competent team can stand up a convincing AI demo in a weekend. The demo is no longer evidence of anything except that the team can wire a frontier model to a UI, which everyone can now do. The benchmark table on slide nine is run by the founder, on the founder's eval set, under the founder's lighting. I have never once seen a deck where the company's own benchmark showed it losing.

So the slides have inflated in exactly the places that used to carry information, and the only way to deflate them is to go look myself. The terminal is where the air comes out.

What I actually do

It is less dramatic than it sounds. Five passes, in order.

I become a user before I become an investor. I sign up with my own email and run the product the way an unhappy customer would. I give it the messy input, the half-formed request, the file in the wrong format, the question that sits one inch outside the happy path. Demos are choreographed to stay on the path. Real work never does. How a product behaves the first time it is surprised tells me more than an hour with the founder.

I read whatever code is open. A lot of these companies have public repos, SDKs, CLI tools, or open-source cores. I read them. Not to judge style. I am looking for one thing: where the real work happens. If the entire product is a thin call to a model with a long prompt and some retries, the repo says so in about ten minutes. If there is genuine machinery, an actual data pipeline, a real eval harness, careful handling of the cases where the model is wrong, the repo says that too. Code does not have a sales incentive.

I give it a seat in my own workflow. I use AI tools every day, on real work, and any product I am evaluating gets a seat next to the ones I already run. It has to earn that seat. I feed it the same messy inputs I feed the tools I trust, and I keep notes on what comes back. I ask the same question five different ways across the week: do I get five compatible answers or five different companies. This is the closest I get to an honest benchmark, because the eval set is my own work, and the founder does not know which week it is happening.

I read the logs, mine and theirs. When I run the product, I watch latency, failure modes, and what it does on a heavy day of real use. Where I have access, I look at the company's own operational metrics rather than the curated dashboard in the deck. The deck shows me a number going up. The logs show me whether the number is going up for a reason that compounds or a reason that reverses next quarter.

I instrument the cost. I want to know what one unit of this product actually costs to deliver today, in inference and tooling, not in the founder's projection. Then I want to know what happens to that cost when the model underneath gets cheaper, which it will, and whether cheaper helps this company or hollows it out. That single question has killed more of my would-be investments than any other, and you cannot answer it from a slide. You answer it from a bill.

What the terminal tells me that the founder cannot

Three things, and they are the three I weight most.

The first is honesty about where the work is. Some founders describe their product as ninety percent proprietary engineering and ten percent model. The repo says the reverse. That mismatch is not always disqualifying, but it tells me how the founder thinks, and whether they understand their own product. The founders whose self-description matches their codebase are a small and excellent minority. I back them at a higher rate than I back anyone else, and it is not close.

The second is how the product fails. Every AI product fails. The question is whether it fails loudly and safely or quietly and confidently. A product that says "I am not sure, here is what I would check" when it hits its limit is built by a team that respects the limit. A product that hallucinates a confident wrong answer and moves on is built by a team that has not yet been hurt by their own model. I would rather back the first team at any valuation than the second team at a discount.

The third is whether usage compounds. I run the product on Monday and again two weeks later, on the same inputs. Did it get measurably better at my specific case because the team's loop is learning from how it is used, or is it exactly the same product with a new coat of paint on the landing page. Most pre-seed AI products are static and do not know it. The few that are quietly compounding feel different by the second session, and that feeling shows up in the logs before it shows up in the revenue.

The objection, and my answer

The obvious objection is that this does not scale. A partner at a large fund cannot spend a day in the terminal on every deal, and they do not. They look at a hundred companies a month and triage on the deck.

I look at far fewer, and I go far deeper on each. That is the whole bet. At pre-seed, before the revenue line is long enough to mean anything, the deck and the references are nearly content-free, because everyone's deck is good and everyone's references are friends. The thing itself is the only honest witness in the room. I would rather see one company truly, at the level of how it behaves when surprised and what it costs when stressed, than skim forty companies through a deck that was written to be skimmed.

There is a second answer, which is that the terminal is the same place the work gets done. I run my own agents in production, I ship my own code, and I diligence from the same command line. When I sit down across from a founder, we are not an investor and a supplicant passing a document back and forth. We are two people who have both run the thing, comparing notes on what broke. That conversation is worth more than the deck ever was, and it only happens because I went and looked first.

The founder from that Tuesday turned out to have built something the deck undersold. The slides led with a feature that did not matter and buried the part that did, a quiet little engine that got better every time someone used it. I only found it because I ran the thing twice, two weeks apart, and the second run was better than the first. No slide told me that. The terminal did.