Three things worth knowing
- Fields Medalist Terence Tao used a coding agent to port roughly two dozen Java 1.0 applets from 1999 to JavaScript in a matter of hours; all of them are live again on his GitHub Pages site.
- The agent found one minor bug in the ported code, and two bugs in Tao's original hand-written Java that he did not know existed, which he describes as "a net wash as far as code quality was concerned."
- He published edited conversation transcripts for two of the new apps, a rare look at what agent-assisted legacy migration actually looks like from the inside.
Legacy interactive code sits dead in a lot of places. Flash widgets, Java applets, Silverlight panels: the plugin disappeared, nobody had time to rewrite them, and the content they carried became inaccessible. The standard options have been manual rewrites, which take real time, or mechanical transpilation, which preserves bugs and produces unidiomatic output.
Terence Tao tried a third option. He asked a coding agent to handle the porting, gave it the original source and the surrounding HTML as context, and got working JavaScript out the other side. Then he wrote up exactly what happened, including the bug counts, and published the conversation transcripts.
The Agentic SDLC
How teams like Stripe, Ramp, and Uber move from solo coding agents to a coordinated, team-level system.
What happened
Tao posted a detailed account on July 11, 2026, documenting an agent-assisted migration of his old web page, including roughly two dozen Java 1.0 applets he had written between 1999 and the mid-2000s. Those applets had been dead since 2008 when browsers dropped the Java plugin.
He had begun migrating his web presence to a maintainable GitHub Pages repository and asked an agent to handle the applet porting as part of that project. The agent received the original Java source code and the HTML page that embeds each applet, and produced working JavaScript versions without any formal specification.
Across all the ported applets, Tao found one minor bug in the output, a drag-event issue in a complex analysis applet. The agent also flagged two bugs in his original 1999 code that he had not known about. He describes the result as a net wash on code quality.
He then went further. A special relativity visualization he had sketched in 1999 and abandoned because "the code complexity became too much for me" is now live in alpha. A Gilbreath conjecture visualization went from concept to working app in a few hours, timed to accompany a paper he posted the same day.
Key features
- No spec required: The agent worked solely from the original Java source and its embedded HTML page. Tao notes it "understood the code structure just from inspecting it" and produced faithful ports without a formal specification document.
- Staged builds for complex apps: His only structural guidance was to build in stages, for instance, the math engine first, test it, then build the GUI on top. He notes the agent "largely handled on its own" even at that level of sequencing.
- Bug detection during porting: Two latent bugs in the original hand-written Java surfaced during the migration. They were not in the ported code; the agent identified them in the source.
- Published making-of transcripts: Tao shared edited conversation logs for the spacetime diagram app and the Gilbreath tool. These are worth reading directly: they show the actual back-and-forth, not a cleaned-up summary.
- Colorization on top of migration: The Besicovitch set applet came back colorized rather than monochrome, an improvement the agent added during the port.
- The hard case works too: the honeycomb visualization, co-written with Allen Knutson and singled out by Tao as "particularly tricky to code by hand," was successfully ported.
Why it matters
The most quotable line from Tao's comments section is also the most practically useful one: "the precise language or spec that a given piece of software is written in has become far less relevant now that the friction and cost of porting from one language to another has gone down to nearly zero."
He is equally direct about the conditions that made this work. His programming background and domain knowledge were, in his words, "essential to being able to get useful code from the agent, and to be able to detect and diagnose issues." High-level design decisions stayed with him: in the relativity app, he made the call to separate the data model from the user interface. The agent handled the lower-level implementation work.
His risk framing is worth adopting directly. He accepts agent-generated code for visualizations because they are "secondary visual aids rather than critical components of a mathematical argument." Match the level of agent autonomy you grant to the blast radius of a bug in that code. That is a practical heuristic, not a philosophical position.
Example use case
The honeycomb applet is the cleanest instance. Written by hand in Java 1.0 in 1999, tricky enough that Tao singles it out, unused for nearly two decades after the Java plugin died. The agent received the original Java source and the HTML embedding it, extracted the intent, and produced a working JavaScript version now hosted on GitHub Pages. No formal spec, no manual rewrite.
For teams sitting on Flash-era, applet-era, or Silverlight-era interactive content, the workflow transfers directly: provide the legacy source plus its surrounding context, build in stages with the core logic before the UI, and verify each layer before the next. The one condition is that someone on the team understands the domain well enough to catch a bug when the agent introduces one.
Competitive context
A commenter on the post raised a third model worth noting: shipping apps as Markdown specification files that an agent regenerates on demand, citing OpenAI Symphony as an example. Tao's response was that well-structured code plus companion context may already serve as that specification, which is consistent with what he observed during the porting work.
The alternatives for legacy interactive code have historically been manual rewrites (expensive, slow) or mechanical transpilation (preserves bugs, produces unidiomatic output). Agent-based porting sits between them: it reconstructs intent from source and context rather than translating syntax line by line, and, in Tao's case, it caught defects that the original author did not know existed. Whether that consistently beats mechanical translation depends on the quality of the context the agent can access.
My take
The transcript links are the most useful part of this whole case study. Tao's account of what the agent did is credible and specific, but reading the actual conversation logs for the spacetime diagram reveals the friction points, the back-and-forth over the data model, and where his domain expertise actually intervened. That is harder to fake and more useful than a polished write-up.
The question I keep returning to: how much of this generalizes beyond Tao specifically? He is not a typical agent user. His domain expertise in the code he was migrating is unusually deep, his ability to detect bugs in ported mathematical visualization code is rare, and his prior attempt at the relativity app in 1999 gave him a mental model of what correct output should look like. Strip any of those conditions out, and the one-bug defect rate probably no longer holds.
Written by
Paula Hingel
Technical Writer
Paula writes about the patterns that make AI coding agents actually work — spec-driven development, multi-agent orchestration, and the context engineering layer most teams skip. Her guides draw on real build examples and focus on what changes when you move from a single AI assistant to a full agentic codebase.