On August 18, 2026, Yuyuan Ouyang, Daniel Spector, and Cody Stockdale posted a paper to arXiv settling a problem Elias Stein posed at the 1986 International Congress of Mathematicians: the best constant in the weak-type (1,1) bound for the vector Riesz transform on R^n is at most 2, independent of dimension. Forty years of open status, closed in twelve pages.
Two days later, a second paper appeared: a generalization of the result to Riesz transforms on stratified Lie groups, a setting with genuinely more complicated geometry, no simple Fourier multiplier structure, and none of the flat-space tools the first proof leans on.
I’m not going to comment on the correctness of either paper here; that’s for referees, and frankly for time, to settle. What I want to sit with is the speed, because I think it’s a preview of something structural, not a one-off curiosity.
The actual number
arXiv timestamps are easy to misread. The date shown on an abstract page is when the paper was submitted, not when it became visible to anyone else. arXiv batches announcements: anything submitted before 14:00 ET on a business day goes out that evening at 20:00 ET; anything submitted after rolls to the next business day.
Working through the actual schedule:
- Paper 1 was submitted at 13:56 ET on Tuesday, Aug 18, four minutes before that day’s cutoff, and went public at 00:00 UTC Wednesday.
- Paper 2 was submitted at 13:06 ET on Thursday, Aug 20, and went public at 00:00 UTC Friday.
So the window in which the second group could have read the first paper and then produced, wrote, and submitted their own is not the ~47 hours you’d get from subtracting raw timestamps. It’s closer to 41 hours. And the gap between when each paper actually became readable by anyone, the number that matters if you’re asking “how fast did the field turn this around,” is a clean 48 hours, an artifact of both teams squeaking in just under the same daily cutoff a day apart.
Whatever the real mechanics behind paper 2, and its authors do disclose using an LLM as a brainstorming and editing tool, not as a proof engine, a day and a half is the outer bound on how long a nontrivial generalization of a landmark result took to reach arXiv. That number is the thing worth thinking about, independent of whether this particular pair of papers turns out to be a clean example of it or a messier one.
Where this pushes the field
A few effects seem likely to compound as this becomes normal rather than notable:
Verification becomes the bottleneck, not generation. When the rate-limiting step was “find the idea,” referee time was mostly spent checking whether an idea, once found, actually worked, a process that moved at roughly the same speed as the original discovery. If generation gets fast and verification doesn’t, the queue backs up on the verification side. Math doesn’t have a scalable way to referee faster; it has a fixed, slow-growing supply of people qualified to check hard proofs. A field that can produce candidate results in days but can only verify them in months has a growing gap between “posted” and “known to be true.”
Disclosure norms will need more granularity. Right now, “we used an LLM for brainstorming” and “we ran agentic numerical searches over candidate constructions” get flattened into the same boilerplate paragraph. Those are different epistemic situations. A reader trying to calibrate how much scrutiny a result needs benefits from knowing not just that AI was used, but what kind of use it was: idea suggestion, computational exploration, proof drafting, or editing. Journals and arXiv moderators will likely be pushed toward something more structured than a single disclosure sentence.
Priority and credit get harder to reason about. Generalizing a hard result to a new setting has traditionally been real, credit-worthy work, often the kind that took months and was a paper in its own right precisely because it required deep, independent understanding of both the original result and the new setting. If that gap collapses to days, “what was the contribution” becomes a genuinely different question. It’s not that the generalization is worthless, sub-Laplacian, non-commutative settings are hard, but the community’s intuitions about how much originality a fast-follow paper represents were built for a world where fast-follow took a year, not a weekend.
There’s pressure toward defensive over-generalization. If you know your hard, narrow result will likely be generalized within days of posting, you have an incentive to publish the general version yourself, even if the narrow case was the actual insight and the general case is comparatively mechanical. That can produce longer, more hedged papers, and it can also mean authors rush a general statement with less care than the special case that took real work to find.
It changes which problems look worth working on. If a hard special case is known to be “generalizable in 48 hours by someone else,” some people will skip straight to the general problem rather than doing the cleaner, narrower work that often unlocks the general case in the first place. That’s not obviously bad, but it’s a different research culture than one where solving the hard core case is itself the valuable, citable unit of work.
None of this requires either Riesz transform paper to be flawless or flawed. It’s a statement about incentives and infrastructure, and those shift regardless of how any one example holds up.
What this means if you want to use AI for your own research
This is the part I think is actually actionable, and where I’d distinguish two very different modes of AI use that tend to get lumped together.
Consultative use — chatting with a model, asking “what approaches might work here,” having it suggest relevant literature or techniques is essentially talking to a very well-read colleague. It’s useful, low-risk, and not that different in kind from what mathematicians have always done by reading widely and talking to people. The catch is that it produces no artifact. The suggestion is just prose; you still have to do all the actual mathematical work to find out whether it’s any good.
Agentic, exploratory use — turning something like Claude Code or Codex loose to run numerical experiments, search over parameter spaces, test candidate inequalities for counterexamples, try symbolic substitutions, or check whether a conjectured bound holds across a range of cases is a different mode. It produces something checkable: code, output, a table of computed values that can be independently rerun. This is much closer to a long-standing and well-respected tradition in mathematics, experimental mathematics, computer-assisted search, the kind of work that goes back to Borwein and Bailey and beyond, except the tool is now choosing what to compute as well as executing it.
If you’re deciding whether to move from the first mode to the second, I think the case for doing so is genuinely strong:
- It’s falsifiable in a way brainstorming isn’t. “The search found no counterexample after checking N cases” or “the substitution made this integral tractable” is a concrete, reproducible claim.
- It fits into existing epistemic norms rather than fighting them. Framing the work as “we used computational search to explore the space of decompositions” sits comfortably in a tradition referees already know how to evaluate, rather than raising the more fraught question of whether an AI wrote your proof.
- It gives you something substantive to say in a disclosure statement, which matters more than it might seem, “we used Codex to numerically test candidate constants before pursuing the fractional Laplacian approach,” tells a reader where your intuition came from and what got ruled out.
The caveats are real, though, and worth taking seriously if you go this route:
- The failure mode shifts from “bad idea” to “confidently wrong evidence.” A brainstormed suggestion that’s bad just gets discarded. A numerical experiment run through a subtly buggy script produces something that looks like verification and isn’t. That means you now need to audit the tool’s code and methodology with the same rigor you’d apply to a human collaborator’s; arguably more, since there’s no one to ask “wait, why did you set it up this way.”
- There’s a meaningful line between exploration (using the tool to build intuition, which you then formalize and prove by hand) and delegation (asking the tool to produce a proof, which you then check). The first is safe. The second inherits all the verification burden of checking someone else’s work, except the “someone else” doesn’t understand what it did or why in any accountable sense.
- Document the class of task, not just the tool. “We used Claude Code” tells a reader almost nothing. “We used it to run a brute-force search over decompositions of the input data, testing roughly N candidate constants against the target inequality” tells them exactly how much weight to put on that part of the process.
The honest version of the advice is probably: yes, if you’re comfortable treating the tool the way you’d treat a fast, tireless research assistant who’s good at computation and bad at judgment, use it to search, to compute, to rule things out, to try things at a scale you couldn’t by hand. Just don’t let the speed of the output outpace the speed of your own verification. That’s the same discipline mathematics has always demanded of computer-assisted proof; the tools just got a lot more capable, which means the discipline matters more, not less.