Fermat's Theorem Machine-Verified: Where Should Founders Look?

Last Wednesday around 9 PM, I was reviewing cash flow statements in the office when a product colleague threw me a message: Anthropic said Claude ran autonomously for 11 days, completing the first end-to-end, computer-checked formal proof of Fermat's Last Theorem. I read it twice. Instead of discussing math first, I asked: Can this be applied to contract review?

This direction is worth watching, but execution is key.

Fermat's Last Theorem is far removed from startups. Wiles solved it in 1995 with a 129-page paper, after it had puzzled the mathematical community for three and a half centuries. This time, AI didn't reinvent the theorem; it translated an existing proof into code verifiable step-by-step by Lean. Reportedly, the entire process generated about 13 million lines of code. The point isn't that AI can do math, but that it compressed an ultra-long, fragmented engineering task requiring strict verification into 11 days.

This resembles what we've recently done with Claude. I've used it for about a month, mainly not for chatting, but for legacy code migration, converting docs to schemas, and filling in test cases. I haven't seen anything as extreme as the model running itself for 11 days, but long tasks have indeed emerged: previously split into dozens of small requirements, now we can give a goal and let it iterate within boundaries. The problem is, once long tasks go out of control, they burn GPU resources, manpower, and customer trust.

So I don't want to write this as another breakthrough for general AI. A more practical comparison is between two routes.

Route	What it solves	How startups view it
End-to-end formalization by model	Converts existing complex materials into machine-verifiable structures	Suitable for long tasks with clear acceptance criteria, e.g., testing, migration, clause extraction
Human + rule engine	Solidifies expert experience into stable systems	Suitable for high-risk, low-tolerance scenarios requiring accountability, but slow to start and heavy to maintain

The beauty of the first route is that it connects material understanding with material verification. Humans write proofs, machines check them; humans write business rules, machines execute them. The stability of the second route lies in human sign-off at every step, so you know who to blame if errors occur. Startups shouldn't just look at the speed of the first route, nor cling to the slowness of the second. What really needs calculating is gross margin, collections, and error costs.

I wrote a piece before saying to build the verification loop first, then buy AI compute. The reason formalization works this time isn't because the model is great at generating, but because Lean provided a hard checker. Without a checker, 13 million lines of code are just noise. It's the same in enterprises: AI can generate a pile of stuff, but if the client says it's wrong, how do we prove it's right? Unit tests, schemas, compilers, audit logs, and rollback records are the foundation of AI products.

Many teams building Agents tend to mistake demos for deliverables. Actual implementation encounters edge cases, permissions, dirty data, and responsibility attribution. In my testing, handling structured data is indeed easier, provided the data itself is clean. If the data is dirty, you can't save a single bit of effort on upfront cleaning.

From a business model perspective, industry-specific verification suites might be more valuable. For example, contract extraction isn't just about generating clauses, but also annotating sources, outputting difference tables, and allowing human review. Whoever can turn AI generation into an auditable process holds the pricing power.

In my third year of entrepreneurship, leading a team of 30, I wouldn't recommend going all-in on autonomous Agents immediately. First find internal tasks: clear inputs and outputs; results partially checkable by machines; failures reversible; saving repetitive labor rather than replacing critical judgment. For example, for legacy system migration, let the model list dependencies, generate patches, and run tests. For contract review, let the model extract fields, the rule engine check conflicts, and humans only look at anomalies.

Costs must also be calculated. Behind the 11 days are compute, scheduling, and model calls. We previously used cloud GPUs for four weeks and found significant cost differences between daytime online tasks and nighttime batch processing. Autonomous long tasks should ideally have token budgets, time budgets, and maximum retry counts. Stop and hand over to humans if thresholds are exceeded.

Teams need at least three types of people: those who understand the business, those who understand verification engineering, and those who understand customers. Startups often rely on the boss to explain the business and temporary scripts to support engineering; such teams can't handle long-task AI.

Looking at this news, I treat it as an engineering signal, not a mathematical miracle. The boundary of AI is changing, specifically the duration it can continuously process complex materials. Whether it makes money depends not on whether it can generate, but on whether we have ways to make results checkable, accountable, and deliverable.

Here's an action item. Tomorrow when you return to the office, don't hold a big LLM strategy meeting first. Pick an internal task, write out the acceptance criteria, and let AI run a small sample. If its output can be judged correct or incorrect by a machine, then talk about automation; if it can't be judged, don't buy compute yet. Build the verification loop first, then talk about Agents.