Tao reports that even though he is fully capable of writing the code for his small mathematical utilities himself, delegating implementation to Claude and Codex produced faster, better-tested, and more maintainable results. His time is now spent writing specifications, crafting test cases, reviewing diffs, and pushing back on suspicious outputs — a workflow shift he considers the central lesson of his experiment.
Tao explicitly distances his workflow from the 'agent goes off and builds a startup' fantasy that dominates vendor marketing. He stays in the loop throughout — the agent handles implementation, but Tao owns the specification, verification, and correctness judgment, which he treats as non-negotiable given that his apps solve problems where correctness is objectively checkable.
The editorial argues that most current commentary on coding agents comes from either vendors selling the tools or engineers watching them fail on production codebases, both of which have obvious biases. Tao — a Fields Medalist applying agents to problems with objective correctness criteria and no commercial interest in the outcome — provides a rare third data point whose endorsement carries different weight.
Terence Tao — Fields Medalist, one of the most cited living mathematicians, and an unusually candid blogger about his own tooling — published a post on July 11 titled *"Old and new apps, via modern coding agents."* It hit the Hacker News front page and stuck there, clearing 340 points in a few hours. The post walks through roughly a dozen small utilities he has built or rebuilt over the last several months using Claude and Codex as the primary authors of the code.
The apps themselves are not the point. They are the kind of tools a working mathematician actually wants: an estimate-tracker for inequalities, a symbolic manipulator for a specific class of PDE bounds, a LaTeX-to-something-else converter, a small proof-of-concept for a paper he was writing. Several are rewrites of scripts he originally wrote by hand years ago. What is new is that Tao, who is entirely capable of writing this code himself, chose not to — and reports that the agent-driven version was faster, better tested, and easier to maintain.
He is careful to distinguish this from autonomous "agent goes and builds a startup" fantasies. He is in the loop the entire time. But the shape of the loop has changed: he spends his time writing specifications and test cases, reviewing diffs, and pushing back on suspicious outputs, rather than typing implementation code.
There are a lot of takes on coding agents right now. Most of them come from either vendors selling the tools or engineers whose day job is watching agents fail on production codebases. Tao is a useful third data point: a domain expert in a different field who has no financial interest in the outcome, and who is applying the tools to problems where correctness is not a matter of opinion.
His central claim is that the bottleneck has shifted from writing code to specifying and verifying it. That is not a novel observation — Fred Brooks was making a version of it in 1975 — but Tao's version has teeth because he is a professional specifier. He points out that the failure modes of coding agents look a lot like the failure modes of a strong but inexperienced graduate student: they will confidently produce something that compiles, passes a superficial check, and is wrong in a subtle way. His countermeasure is the same one he uses with grad students: force the work to satisfy an explicit, testable contract before you accept it.
Concretely, this means he writes unit tests before or alongside the prompt, uses type signatures aggressively (his stack is largely Python with type hints and occasionally Lean for the actually-mathematical parts), and treats the agent's output as a candidate solution that has to clear the tests, not as finished work. When the agent gets stuck, his tell is that it starts "solving" the tests rather than the underlying problem — patching the assertion instead of the logic — which he flags as the single most common pathology.
He is also honest about where it breaks. Anything requiring genuine mathematical insight — the actual research part of research math — the agents cannot do. They are useful for the scaffolding around the insight: the tooling, the visualization, the tedious algebraic manipulation, the plumbing between a proof and a paper. This maps almost perfectly onto what senior engineers report in software: agents are good at the boilerplate and the well-specified transformations, and bad at the parts that require taste or a novel model of the problem.
The community reaction on Hacker News was notably less cynical than the usual thread on this topic. The top comments are from people who ship code for a living, agreeing that the specification-and-verification framing matches their experience, and pushing back gently on Tao's implicit assumption that everyone has his level of discipline about writing tests first. That is the honest caveat: Tao's workflow works because Tao already thinks like a formal verifier. Dropping the same tools on a team that doesn't write tests will not produce the same results — it will produce more untested code, faster.
If you are evaluating coding agents for your team, Tao's post is worth reading as a description of the *working* end state, not as an endorsement. The pattern he describes — spec first, tests as the contract, agent as the implementer, human as the reviewer — is the version of agent-assisted development that actually holds up under load. The version where you type "build me a dashboard" and merge whatever comes out is the version that generates the horror stories.
A few practical takeaways that fall out of his workflow:
- Invest in your test harness before you invest in agent seats. If your codebase is hard to test, agents make the problem worse, not better, because they will happily generate code that is also hard to test. Tao's leverage comes from the fact that his problems have cheap, decisive verifiers. - Treat the prompt and the tests as one artifact. He iterates on both together. When the agent goes off the rails, the fix is usually a sharper spec, not a longer prompt. - Watch for the assertion-patching failure mode. If your agent's PRs keep loosening tests to make them pass, you don't have a coding agent problem, you have a review problem — and it will bite you the same way a cargo-culting junior would. - Pick the right shape of work. The apps Tao built are small, self-contained, and have clear success criteria. That is the sweet spot. Long-lived services with fuzzy requirements are still the hard case.
None of this is new advice for anyone who has been paying attention. What is new is that a specific, credible, non-vendor voice has now written it down in one place, with worked examples, from a domain where being wrong is not a matter of taste.
The interesting second-order question is what happens when the specification layer itself starts getting agent assistance. Tao hints at this — he mentions using Lean for the parts where he wants machine-checkable guarantees, and there is an obvious trajectory where the agent proposes both the spec and the implementation and a separate verifier checks them against each other. That is the version of this story that stops being about "coding agents" and starts being about a different discipline entirely. For now, the practical read is narrower and more useful: the people getting real work out of these tools are the ones who already knew how to write down what they wanted. If you don't, that is the skill to build first.
Terry Tao using coding agents to build apps means we're one step away from a Fields Medalist asking an LLM why his Docker container won't start, just like the rest of us.
There is infinite latent demand for software, most especially outside the traditionally software-focused spaces. If LLMs stopped improving today it would take us 10 years to catch up to the new software-writing abilities that have become available. This is a great illustration of that fact.
Nice balanced perspective there at the end:"as such [LLM-coded interactive] supplements are not mission-critical to the core of the paper, I again feel that the downside risk of using guided interaction with LLM agents to generate such visualizations is acceptable."It's a tool. Good f
Terry Tao using coding agents feels like watching a Michelin-starred chef discover microwave dinners and get genuinely excited about them.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Building visualizations with LLMs has been a major boost for my CS classes:https://htmx.org/essays/universities-and-ai/#demos-visualiza...Many visualizations that I have always wanted but just didn't have the time to build, I now have.To give an example, I wanted a simp