Terry Tao’s Old and New Coding-Agent Apps

Old and new apps, via modern coding agents is a July 2026 blog post by mathematician Terence “Terry” Tao about rebuilding old Java teaching applets and making new mathematical visualizations with modern coding agents. It deals with a practical question developers recognize: when is agent-written code useful enough to keep, but not important enough to trust blindly? The answer is not “pick the smartest AI IDE”; it is to keep the scope small, make the output inspectable, and reserve judgment for the human domain expert. For anyone skimming top 10 ai coding agents 2026 lists, Tao’s post is the better signal: the workflow matters more than the leaderboard.

Read the post as a risk boundary, not a demo

A coding agent is software that can plan, edit, run, and revise code with some autonomy, usually inside a repo or connected development environment.

Tao’s post is interesting because the apps are not presented as a replacement for mathematical judgment. They are small interactive supplements: old teaching applets from his earlier Java work, and newer visual tools that help explore mathematical objects. The code matters, but it is not the theorem.

That boundary is the whole story. The agent can help build an applet-shaped thing faster than a busy domain expert might want to do by hand. The expert still decides whether the visualization is mathematically meaningful, misleading, or merely pretty.

The trap is to read the post as “a Fields Medalist used AI, therefore agentic coding is solved.” A more useful reading is narrower: when the artifact is optional, inspectable, and easy to discard, the downside risk is much easier to manage.

Notice what the expert still owns

The developer reaction around the post had a funny, human edge: even Terry Tao may now be one Docker error away from the same coding-agent loop as everyone else. That joke lands because the post does not make the work look magical. It makes it look ordinary.

That is why developers cared. The compelling part is not that an AI coding agent produced code. It is that a world-class domain expert used the agent for a bounded task where he could evaluate the result better than the model could.

There is also a real objection here: these are hobby-scale or supplement-scale apps, not mission-critical systems. That is not a dismissal. It is the lesson. A visualization that accompanies a paper has a different risk profile than a payment flow, a migration script, or a medical triage system.

Codex, Anysphere’s AI code editor, and Codex, OpenAI’s coding agent, both make it easier to move from prompt to patch. Tao’s example reminds us that faster patch creation is only half the loop. The other half is choosing a problem where a human can review the output without replaying the agent’s whole chat transcript.

For a closely related note on the same source signal, see Terence Tao Builds Apps With Coding Agents. For the broader practice area, keep the related training topic handy.

Try one bounded app before trusting a bigger agent

Skip the top 10 ai coding agents 2026 spreadsheet for one afternoon and run a smaller test: ask an agent to build a disposable visualization, then judge the workflow by the review burden. The point is not whether the model impresses you. The point is whether you can tell what changed, why it changed, and whether it is safe to keep.

A good Codex-style experiment has three fences.

First, fence the files. Put the work under src/visualizations/demo-name/ or examples/agent-demo/, not next to core business logic.

Second, fence the permissions. If you connect external context through the Model Context Protocol, keep the first MCP server read-only. Let the agent fetch docs or issues before you let it mutate tickets, databases, or cloud resources.

Third, fence the definition of done. The agent must leave you with a diff, a local command, and a short explanation. If it only leaves a chat transcript, you have a story, not a reviewable artifact.

A simple verification loop can look like this:

# Ask for the smallest useful artifact, not the whole product.
codex "Create a small interactive visualization under src/visualizations/orbit-demo. Do not edit core logic."

# Run the same checks a human patch would face.
npm test
npm run lint
npm run typecheck

# Review the artifact, not the conversation.
git diff -- src/visualizations/orbit-demo

The trap is to expand the experiment as soon as the first patch looks good. Resist that. One boring, reviewable diff teaches more than five impressive branches nobody has time to inspect.

Copy this small “try it safely” note

Use this when you want to test a coding agent on a Tao-shaped task: a small app, a visual explanation, or a repo-local teaching aid.

# AGENTS.md

## Coding-agent boundary for visual demos

- You may edit files only under `src/visualizations/<demo-name>/`.
- Do not change theorem statements, generated datasets, auth code, migrations, or billing logic.
- Prefer simple, inspectable code over clever abstractions.
- If external context is needed through MCP, use read-only sources first.
- Every patch must include:
  - the files changed,
  - the local command used to verify it,
  - one sentence explaining what a human should inspect.

## Verification

Run:

```bash
npm test
npm run lint
npm run typecheck

Stop if any command fails. Do not “fix forward” outside the allowed directory without asking.

This is not a universal safety policy. It is a small starter checklist for one class of task: useful, bounded, non-core artifacts where review is realistic.

## Common questions

- **Does Tao’s post mean coding agents are ready for serious engineering work?**

  No, it shows they can be useful when the task is bounded and the reviewer has strong domain judgment. The important number is not model score or app size; it is the blast radius. A non-critical visualization is a much safer target than auth, payments, migrations, or production infrastructure.

- **What does top 10 ai coding agents 2026 miss about this story?**

  It misses the operating condition that made the work reasonable. Tao’s example is less about which agent ranks first and more about whether the artifact is optional, inspectable, and easy to throw away. A ranked list can help you choose tools, but it cannot choose the right risk boundary.

- **How should I review agentic coding output without reading the whole chat?**

  Review the diff, the tests, and the stated intent, just as you would with a human patch. Ask the agent to leave a handoff receipt: changed files, verification commands, known gaps, and one sentence about what deserves human attention. If that receipt is missing, the patch is not ready.

- **Where does MCP fit in a small experiment like this?**

  MCP fits when the agent needs outside context, such as docs, issues, design files, or repo knowledge. Start with read-only access because it gives the agent better inputs without giving it write power. The first useful boundary is simple: fetch is allowed, mutation requires a separate human decision.

## Best ways to use this research

- **Best for:** deciding whether a coding-agent task is a safe supplement or a risky core change. Tao’s app notes are strongest when read as a boundary-setting example, not as a claim that agents can own the whole workflow.
- **Best first artifact:** a small `AGENTS.md` rule that limits file paths, commands, and MCP permissions. Keep it boring enough that a reviewer can enforce it in one pass.
- **Best comparison angle:** compare AI coding agents by review burden, not only by benchmark claims. Ask which tool leaves the cleanest diff, the clearest command trail, and the smallest number of unexplained edits.
- **Best workshop prompt:** rebuild one old internal demo or visualization with Codex, then measure how long review takes. If review takes longer than hand-coding, the task was not bounded enough.

## Further reading

- [OpenAI Codex](https://developers.openai.com/codex/)
- [Codex — Agent](https://cursor.com/docs/agent/overview)
- [Model Context Protocol — specification](https://modelcontextprotocol.io/specification/2025-11-25)
- [Old and new apps, via modern coding agents — source](https://terrytao.wordpress.com/2026/07/11/old-and-new-apps-via-modern-coding-agents/)
- [OWASP — Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)

## Next step

Pick one non-critical visual or teaching artifact in a repo and give it a tight agent boundary. Keep the result only if the diff is easier to review than the chat was to enjoy.

## One methodology lens

One useful way to read this through our [methodology](/methodology) is the **Plan** step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.