Terence Tao Only Let AI Write the Code That Couldn't Hurt Him. Which Parts of Your YC F26 Product Did You Actually Read?
Terence Tao used coding agents only where bugs were cheap. YC F26 partners won't ask if you wrote the code. They'll ask what breaks when it's wrong.

Tao let agents write only what couldn't hurt him. YC F26 partners won't ask if you wrote the code, but what breaks when it's wrong.
YC Roaster
Terence Tao published a post on July 11 about porting his old Java applets to JavaScript with a coding agent. It hit the Hacker News front page the next day, and most people read it as another "look how good the agents got" story: a Fields Medalist ports two dozen dead Java applets to JavaScript in a matter of hours, then spends a couple more building the special-relativity tool he abandoned in 1999 because, in his words, "the code complexity became too much for me."
That is not the interesting part.
The interesting part is the sentence where he explains why he was willing to do it at all. The applets, he writes, "are meant to be secondary visual aids rather than critical components of a mathematical argument," so "the downside risk of such bugs is relatively low." He uses the phrase "downside risk" twice in a short post. He is not saying agents are safe. He is saying they are safe here, in this tier, where a bug is embarrassing and nothing more.
He tiered by blast radius. Almost nobody applying to YC F26 does, and it is going to cost some of you an interview.
The question you think you're being asked, and the one you actually are
Founders walk into the 10-minute interview braced for "did you build this yourself?" They have an answer ready: some version of AI writes most of our code now, and that's fine, YC funds people not code.
That answer is true and it is useless, because it is not the question.
The question a partner actually asks is: what happens when it's wrong?
Your product will produce a wrong output. The agent will have written the code path that produces it. The partner wants to know whether you have thought about which wrong outputs are survivable and which ones end the company, and whether you spent your scarce human attention accordingly. That is a judgment question, not a coding question. It is answerable by a non-technical founder. It is also completely unanswerable if you have never looked.
Note what Tao does not claim. He does not say the agent's code is clean. Across the two dozen ports he says he "could only find one minor bug" — but of the new relativity app he says he is "sure… there are still some bugs and rough edges." He shipped anyway, because he had already decided that in this tier, unfound bugs are affordable. That is the posture. Not confidence in the tool, clarity about the cost of it failing.
What a blast-radius audit actually looks like
Take an hour before you submit. Split your codebase into three tiers.
Tier 0: a bug here hurts a person or is unrecoverable. Anything touching money, health data, auth and permissions, deletion, or a model output a professional will act on without checking. If you are building the legal-AI or clinical tools YC keeps funding, your core inference path is Tier 0 by definition.
Tier 1: a bug here costs you a customer. Onboarding, billing display, the thing your best user does every morning. Recoverable, expensive.
Tier 2: a bug here is embarrassing. Marketing site, admin dashboard, internal scripts, the chart on your landing page. This is where Tao's applets live, and it is where he was right to let the agent run unsupervised.
Now the audit: how much of your Tier 0 have you personally read, line by line?
If the answer is "all of it," say that in the application, in one sentence, and you have just separated yourself from most of the pool. If the answer is "none of it," you do not have a code problem. You have an eight-hour problem, and you should go fix it before you submit rather than discover it live on a Zoom call.
The sentence to put in your F26 application
Not this:
We use AI coding agents throughout our stack and ship 10x faster than a traditional team.
Every applicant says this. It reads as a claim about tooling, which is now worth nothing.
Something closer to this:
The agent wrote roughly 90% of our code. We hand-audited the dosage-calculation path and the permissions layer, because a bug in either one hurts a patient. Everything else we let it run.
The second version tells a partner three things the first one cannot: you know where your product's risk actually sits, you can prioritize under scarcity, and you have a working relationship with the tool rather than a dependence on it. It costs you two sentences.
"But doesn't YC just fund people, not code?"
Yes, and that cuts in favor of the audit, not against it.
Paul Graham's June 2026 essay is blunt about what he screens on: "when I meet a founder, the first thing I ask about is their growth rate." He also recounts that YC "funded Airbnb, and we thought the idea was bad. The reason we funded them was just that we liked the founders." The artifact was never the signal. The judgment was.
Look at who YC just promoted. In June 2026 it named Christopher Golda and Grey Baker General Partners. Golda co-founded BackType (YC S08), acquired by Twitter, then ran the Ad Center product there past $1B in revenue. Baker co-founded Dependabot, acquired by GitHub in 2019, after joining GoCardless (YC S11) when it was six people and leading product and engineering as it grew past a hundred; he later co-founded Pincites (YC S23), acquired by Filevine. Dependabot is, of all things, a tool whose entire purpose is knowing which of your dependencies can hurt you.
These are not partners who will be impressed that you can generate code. They are partners who will notice, in about four seconds, whether you know what you shipped.
The uncomfortable version
Shipping is no longer the hard part, so it is no longer the proof. What replaced it is narrower and harder to fake: knowing exactly where you are exposed, and having spent your one scarce resource, attention, on that and nothing else.
Tao spent 27 years unable to build an app he wanted. He built it in a couple of hours, and the noteworthy thing he did was decide, first, that it was allowed to be a little broken.
Decide the same thing about your own product, on purpose, before a partner decides it for you. If you want a read on whether your F26 application survives that question, YC Roaster is where YC alumni will tell you which of your claims a partner will stop on.
Ready to get your YC application roasted?
Get free AI feedback + a review from a YC alumni.
Submit Your Application