Old and new apps via modern coding agents (Tao)
- title
- Old and new apps via modern coding agents (Tao)
- type
- summary
- summary
- Terence Tao ports his 1999 math applets and vibe-codes new visualizations with coding agents, and draws a clear line at where the bugs are tolerable
- tags
- llm, mathematics, vibe-coding, case-study
- sources
- tao-apps-coding-agents
- created
- 2026-07-18
- updated
- 2026-07-18
In July 2026 Terence Tao spent a few days moving his old web page and blog data to a maintainable repository with the help of a coding agent. Along the way he ran two experiments: porting a set of interactive math applets he first wrote in Java 1.0 back in 1999, and building a few new visualizations from scratch. The post is his report on how both went.
The applets had been dead for years โ the Java version they relied on stopped being supported by browsers, and Tao had already noted their decay back in 2008. He asked the agent to port them to a supported language (they settled on JavaScript), and about two dozen applets came back to life in a matter of hours. Some got small upgrades: the Besicovitch set applet is now colorized rather than monochrome, and the honeycomb applet he wrote with Allen Knutson in 1999 โ hard to code by hand the first time โ works again.
Then he built new things. A special-relativity visualization he had abandoned in 1999 because the code got too complex โ his description was "Inkscape, but in Minkowski space" โ came together after a couple of hours of vibe coding. And after writing up a paper on the Gilbreath conjecture the same day, he had the agent produce an interactive visualization to accompany it. He plans to keep adding such supplements to future papers.
The bug accounting
Tao is specific about defects, which is what makes the post useful rather than a testimonial. Across the two dozen ported applets he found exactly one minor bug: a drag event in one of the complex analysis applets misbehaved when the pointer left the main box. In the other direction, the agent found two bugs in his original 1999 code that he hadn't known about. His summary: a net wash on code quality.
That accounting only holds because of what the code is for. These are secondary visual aids, not steps in a proof. A subtle bug in a colorized Besicovitch applet costs almost nothing; a subtle bug in a verification argument would be a different matter. He repeats the same reasoning for the new visualizations โ they are supplements, not "mission-critical to the core of the paper," so the downside risk of guided LLM generation is acceptable. He also flags the relativity app as an "alpha" and asks for feedback precisely because it is LLM-generated and probably still has rough edges.
Where this sits
This is a disciplined-use data point, not a proof-of-power one. Tao is careful to scope where he trusts the output: low-stakes, checkable, non-load-bearing code, with a human who can eyeball whether the honeycomb renders correctly. That is the same structure Gowers describes for research math in chatgpt-5-5-pro-mathematical-research โ high-skill human keeps the judgment, the model does the labor that used to be the barrier โ and it fits the skill-leverage reading in average-is-all-you-need, where the scarce part is knowing what "correct" looks like. It belongs alongside llm-mathematical-research as the applied, teaching-and-exposition cousin of the research-bar discussion.
It also reads as a calmer version of the cult-of-vibe-coding worry. Bram Cohen's objection is to not reading AI-generated code as a point of principle; Tao does something narrower โ he lets the code go partly unreviewed, but only in a domain he has explicitly decided can absorb the bugs. simonw-vibe-coding-agentic is the adjacent honest-practitioner note. The common thread across all three is that the interesting question is no longer "can it write the code" but "where is it safe to stop checking."
Interesting from the discussion
The Hacker News thread circled a few points worth keeping.
Several commenters read Tao's closing line as the actual thesis and approved of it: he trusts the tool for supplements he has judged non-critical, and nowhere claims more. One noted the tension in "generally not to be trusted" language โ you still have to check every output, yet "trust" in these tools has been rising as workflows improve, so the useful advice is less "don't trust it" and more "expect to spend more time planning and reviewing."
A recurring skeptical note: it's always a hobby or teaching project, never something load-bearing. The counter that got the most traction is that teaching material and paper supplements are core to a professor's job, and that public blog posts rarely show production code for boring reasons (policy, proprietary code, NDAs) rather than because the tools can't do it. Someone also pointed out Tao has separately written about using LLMs for serious formally-verified math, so this softer post isn't the whole of his stance.
The economic tangent split between "SaaS is dead, everything gets brought in-house" and the reminder that outsourcing waves reverse once the quality bill comes due โ vibe-coded apps often don't survive production, so treat them as prototypes. And a nice historical footnote: Fields medalist Martin Hairer wrote and sold professional audio software (Amadeus) long before any of this, so a top mathematician shipping code isn't new.
Cross-references
- Author: terry-tao
- Research-math analogue: chatgpt-5-5-pro-mathematical-research, llm-mathematical-research, gowers-blog
- Vibe-coding practice and critique: cult-of-vibe-coding, simonw-vibe-coding-agentic
- Skill-leverage framing: average-is-all-you-need
- Discourse map: anti-llm-discourse (the reconciliation / disciplined-use slot)