Mathematicians aren’t mourning their craft
Translating “After Math” for software engineers
Software engineers have learnt to read the reaction to coding agents as a split between people who love the craft and people who care about the product. Seen through that lens, mathematicians upset about OpenAI’s Navier–Stokes result look like craft-lovers in denial, moving the goalposts. I think that misreads them. “After Math”, by Silvia De Toffoli and Eamon Duede, argues that mathematics was never after the answer: the understanding is the product. Then I extrapolate to research software, where I’d argue the same holds for code that establishes scientific results.
I enjoyed After Math, a guest post by Silvia De Toffoli and Eamon Duede on Terence Tao’s blog (De Toffoli and Duede 2026). I’m afraid many software engineers will miss the point, so I’m doing a bit of translation work here.
Craft and product
Remember Tanner Burson’s Software development isn’t a craft:
If you view code as craft (as I did), AI agents are deeply uncomfortable. If you view code as a means to an end, they’re empowering. (Burson 2026)
Burson is describing a change in one person’s view, but I think it also explains why agentic engineering is so divisive. Les Orchard put it well: there were always two kinds of software engineers, and before the agents arrived, they were indistinguishable. “The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable.” (Orchard 2026) To some, programming is the necessary means to the end product, and the product is always the goal, the value, the reward. To others, the craft is the reward, and the product is where their magnificent craft shows.
When agentic engineering arrived, there was much less room for writing code by hand. People who care about the craft mourn it (Lawson 2026), and go through the stages of grief: denial, anger, bargaining, depression, acceptance (Kübler-Ross 1969).
Now look at mathematics through the same lens. AGI has arrived, the Deep Blue–Kasparov moment for mathematics has come (Buckmaster 2026), blah, blah, blah. The mathematicians are the craft-lovers, and they just need to wake up and accept it.
After math
After Math is an excellent title. On the surface, it seems to point at the same split: there’s a goal (a conjecture, a prize, etc.), and there’s a process for reaching it. In the past, the two were indistinguishable. To prove the Calabi conjecture, the positive mass theorem, or Fermat’s Last Theorem, you needed a deep understanding of mathematics, and you invented new ideas, new connections, or even new fields to arrive at the proof.
Then “AGI” came, and OpenAI announced a solution to the Navier–Stokes Millennium Prize Problem (OpenAI 2026). We seem to have reached the goal without the craft.
But this is where the translation goes wrong. De Toffoli and Duede consider the craft-lover’s defence, that the point of a game is the process and not only winning, and call it “an unnecessary retreat” for mathematics (De Toffoli and Duede 2026). Their claim is stronger: OpenAI produced an answer, and an answer is not a solution. A Lean proof gives certainty, but mathematicians want an intelligible proof too, one that tells them what makes the statement true. “Historically, the two notions have tended to run together.” (De Toffoli and Duede 2026) AI is pulling them apart.
So mathematicians aren’t mourning their craft. They are saying the product was never the true/false answer. The understanding is the product.
That’s probably not how software engineers see it, especially if they extrapolate from their own experience. On Hacker News, a commenter wrote, “As a software engineer, I myself have only recently recovered from it”, and diagnosed Tao as “currently in the bargaining phase - ie scrambling to change the goal posts” (yazaddaruvala 2026). It isn’t even Tao’s post.
How do we know they are not moving the goalposts?
For one thing, mathematicians said this long before AI. Thurston wrote in 1994 that what mathematicians produce is understanding (Thurston 1994), and later put it bluntly: “The product of mathematics is clarity and understanding. Not theorems, by themselves.” (Thurston 2010) The Clay Mathematics Institute’s own page for this very problem asks “Why ask for a proof?” and answers, “Because a proof gives not only certitude, but also understanding.” (Clay Mathematics Institute, n.d.)
But let’s also try a proof by contradiction. Suppose only the answer matters. What is the value of knowing that the Navier–Stokes equations can blow up even with “nice” inputs (see what nice means in my other post)? Software engineers, computational physicists, applied mathematicians and the like should really ask this. Not knowing it never stopped us from simulating the Navier–Stokes equations for many useful applications, and knowing it hasn’t changed a thing about how we solve them. If you only care about the goal, the goal is a solution of the Navier–Stokes equations for given inputs and conditions, not a theorem about regularity. Yet this question was chosen as one of seven Millennium Prize Problems.
The bare true-or-false answer has little value in itself, so the value must lie in the process of reaching it. (OpenAI did give us more than “yes”: a 165-page proof and a Lean formalization. How much understanding we can dig out of them deserves its own post; I had a go at the idea of the construction in the companion article.)
This is exactly where many mathematicians’ frustration comes from: we were handed the answer before anyone had the understanding (Avila et al. 2026). It’s a spoiler: “hey, Iron Man dies, you know”, before you’ve watched Avengers: Endgame.1 See my other article for more on the ethics.
Research software engineering
Now we have seen the parallel between what “AGI” has done to software engineering and to mathematics, and where the parallel breaks. That’s the main purpose of this post.
But I can’t resist extrapolating this to research software engineering.
If we rephrase the craft/product split, people are claiming that in the age of agentic engineering we should focus on the end, not the means: “Solve the right problem, in the right way, for the right people, as fast as possible.” (Burson 2026) Give up the craft and embrace the speed-up.
How well this applies to research software varies.
First, research software is very diverse. If you are writing a web app to visualize some research data, the “craft” is probably much like traditional software engineering, and the same argument applies. Where exactly to draw the line deserves another post; I’ll gloss over it here.
But for research software where correctness matters, think simulations built on master equations from physics, I’d argue understanding is part of the product. That’s partly what verification and validation (V&V) is about, but I’d argue it matters even more in science, such as the Cosmic Microwave Background (CMB) data analysis pipelines I have worked on. We are closer to mathematics than to software engineering here: we are after the truth, not an answer. Knowing that primordial gravitational waves really exist is more important than being the first to say “yes, there are”. BICEP2, right?2
I’ve tried to convince physicists this is important. Donald Knuth’s literate programming is along the same lines: “Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.” (Knuth 1984) A program should be written for humans, so that someone can understand it, learn from it, and verify it independently. Thurston contrasted mathematics with computer code (Thurston 2010); Knuth wanted code to be read more like mathematics.
If we held research software to this standard, we would treat released code like a peer-reviewed journal article.
We are far from there. There has been important progress in recognizing research software and reproducibility (Hernández and Colom 2023), but we are still far from there.
So perhaps we RSEs should learn a lesson from mathematicians too.
References
Footnotes
This actually happened to me: a random driver shouted it from their car as my wife and I were leaving the cinema, after watching Endgame. Lucky for us, but apparently some people enjoy spoiling things for others. OpenAI did this too.↩︎
An insider joke. BICEP2 announced a detection of primordial B-modes in March 2014 (BICEP2 Collaboration 2014). One of its dust foreground models came from digitizing a preliminary Planck map shown on a conference slide, not from a publication, and apparently misreading it (Jester 2014). A joint analysis with Planck later found the signal consistent with dust (BICEP2/Keck and Planck Collaborations 2015).↩︎