In July 2026, Fields Medalist Terence Tao quietly posted an entry on his blog. He'd pulled out some twenty Java 1.0 applets he'd written by hand back in 1999 — code that only ran in the days when web browsers still supported Java. Porting them to modern JavaScript took, in his words, "a few hours." And it produced exactly one bug, a minor one at that.

What's more striking than the numbers is how Tao described the process. He called it "guided interaction with an LLM agent." He didn't type out the code himself, and he didn't hand it off to a contractor. He steered the conversation; the agent filled in the implementation. That division of labor turns out to apply well beyond software development.

Why Dig Up 27-Year-Old Code

Among the applets was one that visualized special relativity, and another — an interactive tool — for exploring the Gilbreath conjecture. Tao revived them to build supplementary material that would let readers explore a paper of his hands-on, rather than just read about it.

The special-relativity app, Tao wrote, came together after "a few hours of vibe coding." The Gilbreath conjecture visualizer emerged the same way, after "another few hours of conversation." Along the way, the AI caught two bugs that had been hiding in the original code, on its own. Tao rated the overall code quality as "a wash" — a phrase worth sitting with. It means there was barely any quality gap between the code a human had written and the code the agent had converted.

It's worth breaking down exactly what Tao did here. He made the high-level design calls himself — how to split the data model from the user interface, which reference points to fix in the backend. The AI filled in "low-level syntax and implementation issues." Tao handled the design; the agent handled the grammar. He stressed that this distinction mattered.

What Changes When an Expert Picks Up the Tool

Read this story as "AI replaces developers" and you miss the point. Tao brought decades of mathematical research experience and his own 1999-era programming background to the table. The quality of his conversation with the agent doesn't happen without that foundation. When he wrote that "programming experience and domain expertise were essential," that wasn't modesty — it was closer to a statement of the precondition for the whole exercise.

This is where the counterargument deserves an honest hearing. It's premature to conclude that anyone with a coding agent can now build an app in a few hours the way Tao did. Someone with zero programming background, giving an agent vague instructions, is likely to get a very different result. The agent won't supply the judgment to know what needs verifying, where to look when a bug shows up, or when to change course because the design has gone wrong. That judgment matters even more for tools that fold in complex domain knowledge.

Does that mean the case holds no lesson at all? Not quite. A coding agent becomes an entirely different tool depending on where your expertise sits. What Tao lacked was fluency in modern JavaScript syntax, so that's exactly what he handed to the agent. The decades of accumulated math knowledge, and the grasp of how his own 1999 code was structured, stayed with him. That division of labor is what made it work.

That same division of labor is available well outside pure software development. Take someone who's spent years in a particular industry and wants to turn their own workflow into a tool. What they lack is code syntax, not the logical structure of the work itself. It's the same setup as Tao's.

Three Things Planners and Solo Founders Should Check

There are two different starting points for thinking about coding agents right now: seeing them as a replacement for outsourced development, or seeing them as a way to convert your own expertise into something you can execute on. The first measures success by how much the agent does for you. The second measures it by what you already know.

Here's what's practically applicable from Tao's example.

First, find one point in your recurring work where you've thought "I wish I had a tool for this" — how you organize data, the format of reports you send clients, how you track inventory or scheduling. Before you take that to an agent, check whether you can explain it in your own words. If you can't explain it, the agent can't build it.

Second, calibrate your time expectations. The fact that Tao finished in a few hours is misleading without context. He'd written the original code himself, had studied the domain for decades, and knew exactly what the end result should look like. Without those conditions, you may not get the same quality in the same time. Even so, it's still likely to be faster than commissioning outside work and cycling through revisions — provided you know, at each step, what decision needs to be made.

Third, imagine the failure points in advance. If you have no way to check what's wrong in code an agent hands you, using the output as-is is risky. Tao was able to catch "one bug" precisely because he was equipped to verify the result. In a domain where you can't verify the output, you can't hand the agent responsibility for it.

Business strategy books have long made a related point: if you don't distinguish what you actually know from what you don't, more tools just mean more confusion. Coding agents are no exception to that rule.

Tao dug up his 1999 code to deliver an old idea to readers using today's tools. The purpose was clear, and so was what he already knew. The agent filled in the gap between the two. For a solo founder or planner to do the same, you first need to sort out which gaps are yours to fill and which ones belong to the agent. Without drawing that line first, even the most powerful agent will struggle to actually save you time.