Terence Tao Builds Apps With Coding Agents

Old and new apps, via modern coding agents is a July 2026 post by mathematician Terence Tao about rebuilding and creating small math apps with modern coding agents. It deals with a very practical question: when can AI coding agents help a domain expert make useful software without pretending the software is the proof? The useful answer is not a top 10 ai coding agents 2026 ranking; it is a fit test for bounded, inspectable work. Agentic coding is software work where a model plans or edits code across steps while a human sets the goal, checks the result, and decides what ships.

Read Tao’s post as a boundary story

Tao’s post is not a benchmark, a launch, or a manifesto. It is a working mathematician describing old applets, new interactive apps, and the changed cost of making small visual tools.

That matters because he is unusually well-positioned to separate the math from the scaffolding. If a visualization is wrong, he can often tell. If a proof is wrong, the agent does not get a vote.

The older thread in the post goes back to Java 1.0 applets Tao wrote for complex analysis and linear algebra teaching. Those were hand-built visual aids for mathematical objects. The newer thread is that modern coding agents can now help produce similar interactive supplements faster, especially when the author can guide the goal and inspect the output.

The trap is to read the post as “a Fields Medalist says agents can code, therefore agents can do serious math.” That is too broad. The more interesting claim is smaller: coding agents can lower the activation energy for domain-specific tools when the output is not mission-critical and the expert can judge it.

Notice what the agent is not trusted to do

The most important line in the story is the boundary around risk. Tao treats LLM-coded interactive material as supplemental to the core work, not as the core mathematical claim.

That is the part developers should keep. The lesson is not “never use agents for serious work.” It is “match autonomy to blast radius.”

In a repo, that might mean letting Claude Code, Anthropic’s coding agent, generate a small visualization page, a fixture builder, or a one-off data explorer. It does not mean letting it silently change auth, migrations, or billing paths because the demo looked nice.

A concrete Claude Code boundary could look like this:

Allowed:
- Edit files under apps/math-viz/**
- Add tests under apps/math-viz/tests/**
- Run npm test -- --runInBand apps/math-viz

Ask first:
- Add dependencies
- Touch shared UI primitives
- Change API routes

Blocked:
- Edit database migrations
- Edit auth middleware
- Push directly to main

That is not bureaucracy. It is the software version of Tao’s distinction between a helpful visualization and the paper itself.

Use rankings to ask a fit question

A list of the top 10 ai coding agents 2026 can help you discover tools, but it will not tell you whether a tool fits this kind of work. Tao’s post points to a better question: can the agent produce a small, reviewable artifact whose correctness can be checked by the person asking for it?

The same fit question applies whether you are using Claude, Anysphere’s AI code editor, an AI IDE with a built-in agent, or a terminal agent. Look less at the demo path and more at the review path.

For example, a good agent task is: “Build a small browser visualization for this recurrence, with controls for n and a snapshot test for the renderer.” The output has a visible behavior, a small file boundary, and a testable shape.

A poor agent task is: “Refactor our scientific computing stack so it is cleaner.” That might be useful work eventually, but it has no crisp stopping point. The agent can produce a lot of plausible motion before anyone knows whether it helped.

If you run an ai coding workshop or collect notes on agentic coding guardrails, this is the story worth teaching first. Not because Tao’s workflow is universal, but because his boundary is legible.

Keep the experiment small enough to throw away

The Hacker News reaction around the post had a familiar split. Some readers enjoyed watching a domain expert have fun with AI. Others pointed out that hobby projects are not the same as production systems.

Both sides are right enough. Small tools are where many useful engineering practices start. They are also where people fool themselves, because a polished demo can hide weak assumptions.

A good middle path is to treat the first agent-built app as disposable. Ask the model for a working version. Then ask a human to decide whether the result deserves to become maintained code.

In Claude Code, I would make that explicit with a slash-command workflow rather than a long chat:

/visualize-math
Goal: Build one small interactive visualization from the current note.
Scope: Only create or edit files under apps/experiments/<slug>/.
Evidence: Include a README with the mathematical assumption, how to run it, and one screenshot command.
Stop: Do not add dependencies or touch shared packages without asking.

The trap is keeping every successful experiment. Some generated apps should stay as notebooks, teaching aids, or paper supplements. Not every useful artifact needs to become platform code.

This is also where MCP matters, but only a little. If an experiment needs outside context, make the first MCP server read-only and narrow. That is a different shape from integration-heavy work like searxng-ai-kit Packages SearXNG for MCP, where the integration itself is the product surface.

Copy this Tao-style fit check

Use this starter checklist before you hand a coding agent a domain-specific app idea. It is intentionally small. The point is to decide whether the task belongs in an agent session at all.

A small Claude Code handoff receipt can be even shorter:

Agent task receipt

Artifact: apps/experiments/fourier-spiral/
Purpose: Visual supplement for a math note, not source-of-truth logic.
Run: npm run dev --workspace apps/experiments/fourier-spiral
Check: npm test -- fourier-spiral
Human review needed: formula mapping, edge cases, dependency choice.
Do not promote until: README explains assumptions and reviewer confirms behavior.

The trap is asking for “confidence.” Ask for evidence instead. Confidence is a chat feeling; a run command, a failing case, and a reviewer note are engineering objects.

Common questions

• Should I use a top 10 ai coding agents 2026 list to pick a tool for this kind of work?

  Use those lists for discovery, not decision-making. For Tao-style app experiments, the better selector is whether the agent can stay inside a narrow folder, explain its assumptions, run the app, and leave evidence a human can check. A lower-ranked tool with better boundaries may beat a flashier one.

• Is this coding agents news actually relevant to production engineers?

  Yes, but not because a math app is the same as a production service. It is relevant because it shows a clean risk boundary: supplemental software, expert review, and low blast radius. Production engineers can reuse that boundary for internal tools, migrations previews, test generators, and debugging aids.

• Does Tao’s post prove agentic coding is safe?

  No. It shows one careful use case where the downside risk is limited and the domain expert remains in control. That is very different from delegating security-sensitive or user-facing changes to an agent without review. The citable lesson is bounded use, not blanket trust.

• Where does Claude Code fit in this workflow?

  Claude Code fits well when you can describe the goal, constrain the files, and ask for runnable evidence. A concise command, a scoped project note, and a permission boundary are usually enough for a first experiment. Keep durable repo rules short; put task-specific detail in the prompt or command.

• Can coding agents help with real math, not just visualizations?

  They may help with exploration, examples, computation, and exposition, but the proof burden remains human. Tao’s post is careful because interactive supplements are not the core mathematical claim. Treat agent output as a prompt for inspection, not as mathematical authority.

Best ways to use this research

• Best for: deciding whether a coding-agent task is a bounded experiment or a risky production change.
• Best first artifact: a small app, script, or visualization with one run command and one human-readable assumptions note.
• Best comparison angle: compare agents by reviewability, permission boundaries, and evidence left behind, not only by benchmark scores.
• Best Claude Code habit: turn repeatable experiments into slash commands, but keep the command scoped to a folder and a visible success condition.
• Best limitation to remember: a strong domain expert can catch errors that a general reviewer may miss; do not copy the workflow without copying the review standard.

Further reading

• Old and new apps, via modern coding agents — source
• Claude Code — Overview
• Claude — Agent
• OWASP — Top 10 for Large Language Model Applications

Try one bounded app

Pick one small visualization, script, or internal explainer that you could delete tomorrow. Give the agent a folder boundary, a run command, and a receipt format before you ask it to write code.

One methodology lens

One useful way to read this through our 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.