> I don't think researchers in math/TCS will be made obsolete, but I think it will instead no longer make sense to work on any low-hanging, or even medium-hanging (you know what I mean) fruit. We'll be needed for problems where actual novel approaches are needed.
I wonder how this compares to what we see happening with "juniors" in software development? In math research, do you also get the training for the profession from working on the low hanging fruits for a while, to then move to the medium-hanging, and later go on to work on previously unsolved stuff?
Around here AI isn't really more of a threat to juniors than it is to seniors. It's a threat to the people who have been taught "recipies" rather than applied computer science. You can have excellent seniors who can do TDD, DRY, SOLID and so on, who also happen to have no idea what a L1 cache miss is. The current AI models know all of those things, but they struggle applying them correctly without someone piloting them. Even in the energy industry where I work, where you'd think it would be obvious from the context that you should prioritize runtime safety over debug safety, the current AI models struggle to do so. As far as seniority goes, though. If we can find a young developer with little experience who actually knows computer science, we're much more likely to hire them... Since they are cheaper.
This isn't something which is unique to software development though. We're currently building enterprise AI apps that we can deploy into the AI agents working for anyone of our employees. The key thing we're currently seeing is that the people in a team who are the ones that everyone turn to for advice, are the only people who aren't in "danger". Even people who are great at their jobs are being outperformed by AI in many cases.
I think it'll be a massive challenge for our society in the coming years. Maybe we're even going to get to the point where the AI will also be capable of replacing a lot of the "domain experts". Right now that seems far out, but then, if you had asked me about AI four months ago I would've told you it was all hype.
AI is a threat to everyone. People who claim that AI will never be able to do X have consistently been proven wrong.
The only people who are safe are those whose jobs depend in some way on their humanity. e.g. yoga teachers, bouncers, etc
Nobody knows.
It's not a zero sum game. You can have AI "senior engineers" working under humans building bigger things than we've been able to.
We also don't know where the capabilities of current AIs will plateau. The benchmarks aren't really telling the entire story. From my perspective of using the models there are certain axis where they're not making a lot of progress, like being able to have large accurate context on the scale that humans can. There are other dimensions where there is still a large gap between human capabilities and LLMs. It's true that relative to other areas (lessay chess) LLMs are more generalized but they are still not fully generalized (back to the chess example, LLMs are not good at chess).
> It's not a zero sum game.
Resources are, though. The planet cannot support a race of digital super-people, and us, and an continually growing economy.
It's the height of folly to think that, as things are going, we are going anywhere "good".
I was arguing with a friend about this point today. I'd posit that our economy has been growing in a way where goods that require more human time and natural resources to produce are giving way to goods that are intangible.
Once we've met our basic material needs, we're tending to consume things that are replicable with low marginal costs, and which do not interfere with the production of other goods. So maybe we can actually support a continually growing digital and entertainment economy, at least for a few more generations.
Maybe these mathematical contributions will also impact the efficiency and capabilities of our material production systems as well, which is another way to keep the economy growing.
I'm optimistic that we'll do more with our resources rather than trying to optimize for doing the same more efficiently with less resources.
Economic growth doesn't mean using up resources faster, it means trading things faster.
This was sort of what I wanted to say, but I guess I should have worded it differently. I certainly didn't mean to say that I thought AI would stop improving. If anything I'm surprised at how much we have to fight the AI models to do what NASA has been doing for 60(?) years.
Your first two sentences were correct. The last one is already being proven false.
It's a threat to everyone. UBI is the only way.
Productivity improvements tend to increase employment. AI will not reduce employment.
(Also, the US budget deficit is way too high to afford a UBI.)
i'd take a yoga class from a bot
I'm now imagining Bender's Yoga class. I suspect it would hurt.
would prove that robots were subject to nominative determinism too, if nothing else!
How would this be different from taking a yoga class from a video?
I would be willing to be proven wrong, but I doubt the ability of LLMs to give useful corrections in yoga much more than their ability to write useful code.
Probably that you'd be doing it in a group, which is a lot less lonely than doing it from home.
I think there's a lot of opportunity for computer vision in exercise coaching.
Interesting, thanks. I don't know where "around here" is, but the signals I've seen in a lot of articles is that the demand for junior software people has taken a dive since a year or two back, with student programs etc getting cancelled. One googler said they were getting a junior to their team and that was kind of a big deal because it hadn't happened in that whole department for a long time.
In relation to that, I guess my question becomes: if the same thing will happen in math research, who will write the ten page math proof prompts in the future?
There is definitely the effect of less or de-growth in the industry, which started before the current AI hype. And now there's the additional effect of companies hoping AI will replace their need for (junior) devs. Nobody knows if or to what degree this will work out (yes, we all have opinions, but no crystal balls), but they are holding back the hiring until they know how all this pans out.
I'm from Denmark and I've been an external examiner for various CS educations for the previous 13 years now. Some of them teach you a lot about how the hardware works, others mainly teach you design patterns. Five years ago the latter was in high demand, because a lot of software development frankly doesn't need computer science (until it does). Now there is almost no demand for them.
Honestly, i've received a formal MSc education in the hardware aspects, including for designing embedded electronics products. Spent the most part ofy career in the software industry designing enterprise software and feel like i never needed to use them, except maybe early in my career when i was reviewing tech stacks and determined that .NET would be among the winning horses, precisely because it'd take care of that for me almost all the time.
What i see today is the opposite of what you see : product owners not knowing a thing about software engineering but being able to vibe code prototypes handed over to the dev team are rock stars.
They are closely followed by senior software developers having more of an architecture & design background than a low-level computer science background. Most businesses are looking for builders these days.
Where what you say may converge with my observation is that to be able to do to things such as proper database query optimization, even using AI assistance, you need to be able to understand the concepts of working memory set, cache misses etc...
I've found huge problems, like database servers being grossly underprovisioned (like, 60% cache hit, 4gb RAM server for a 700gb dataset with an 50gb circa hot data set). SSD were used and only latency was measured, so no one realized how problematic the situation was (including a consulting shop they hired to help them manage their DBs - backup, maintenance etc...).
However, having a high affinity with hardware is not a driver / computer science of hiring decisions from what i can see in the enterprise software world. But it would make sense for it to become the case within 10 years. I suspect that you work in a niche where performance optimization matters a lot.
It's funny how you applied on your own argument several logical fallacies about why ai is only a threat to people who have been taught "recipies" versus who know what L1 cache miss is.
Actually it's sad there are people out there dumb enough to believe knowing L1 cache is any different than knowing recipies when it comes to the story which jobs AI will take. I'm convinced by now it will be the jobs of those people believing such crap.
So... The AIs with no model of the world are replacing software developers that have no model of the world?
Unless you’re claiming that AIs will suddenly (and very soon) stop improving, they are obviously a threat to everyone’s job.
Calling notable conjectures that have been open for decades “low-hanging fruit” is an act of desperation. Most professional mathematicians couldn’t have proved those conjectures if their lives depended on it.
I wouldn’t call it “low hanging fruit” but it’s easy to think of problems that seem harder. Apparently solving notable math conjectures is easier than building a practical robot to deliver a package to someone’s porch?
So, yes, AI is a big deal and we don’t know what it’s going to affect, but the goal of replacing everyone’s job is extremely ambitious and there’s a long way to go.
This has to be assessed separately for each kind of job.
Moravec's Paradox strikes again!
Moravec must be at some level gratified things are arriving close to his predicted timeline.
The thought that anything could improve without bounds would be absurd. We are living in the physical world after all. The (open, interesting) question is how close we are to the limit.
It’s safe to assume that after less than a decade of LLM development, we’re nowhere close to the limit yet. In fact, progress still seems to be accelerating at the moment.
If anything, it should be safe to assume by now that capabilities don't scale linearly with model size.
Types of technology - of which we can include intelligence - move along S curves, but it's more absurd to think that humans are near the top of that curve rather than right at the bottom.
There might be a thing beyond intelligence that we can't even conceive of.
> more absurd to think that humans are near the top of that curve rather than right at the bottom
The “absurd” dimension does not enter. This is a situation where you have no evidence at all.
In the absence of any information, the average (mean or median) is your best guess. Now where that average is, you have no idea.
> There might be a thing beyond intelligence that we can't even conceive of.
This statement already supposes there is a thing called “intelligence”. People have been pretending to measure this for more than a century. Modern thinking at least says what we call intelligence is not a single concept.
>Unless you’re claiming that AIs will suddenly (and very soon) stop improving
Most technologies level off sharply after bouts of boundless improvements.
In 1968 they thought we'd be flying to the moon by now but instead we're flying across the ocean in planes not that different from the 747 that existed back then.
They sometimes start improving again. In the context of your comment, look how the cost/kg to LEO has suddenly dropped radically. This was mostly due to institutional change that allowed previous non-technological barriers to improvement to be bypassed.
[flagged]
Wow. That literally has nothing to do with what I wrote.
Even if AI stops merely at solving Erdos problems (merely...), metabolizing it would take decades.
> COUNTEREXAMPLE TO EULER'S CONJECTURE ON SUMS OF LIKE POWERS
> BY L. J. LANDER AND T. R. PARKIN
> A direct search on the CDC 6600 yielded:
> as the smallest instance in which four fifth powers sum to a fifth power. This is a counterexample to a conjecture by Euler that at least n nth powers are required to sum to an nth power, n>2.https://www.ams.org/journals/bull/1966-72-06/S0002-9904-1966...
It is a conjecture whether grinding it out on Lean is a difference in kind, rather than degree. I say degree. But it remains to be seen.
I was trained as a mathematician and worked as a math researcher for a little while (now working as a private tutor), and based on my experience I'd say this description is basically right, with one extra wrinkle.
In order to get a Ph.D., you have to do some sort of original research, so in that sense you're working on "previously unsolved stuff" basically right from the start. But that doesn't entail doing anything all that ground-breaking; most Ph.D. dissertations (very much including mine!) contain work that a more senior researcher in the same subfield could probably have produced without too much difficulty. The software development analogy is a pretty good one: a lot of the point of getting junior researchers to do research is to help train them to one day become senior researchers, and often the work itself is nothing all that special.
Given the trajectory of these LLM proofs, this seems like it's going to have to change pretty soon, and to be honest I'm pretty grateful that I'm not in charge of deciding what that's going to look like, because I don't have any good ideas! I'm actually pretty worried about the future of the field.
> In order to get a Ph.D., you have to do some sort of original research,
China has now introduced "practical PhDs" where you have to build some practical machine instead.
Indeed. Perhaps my article here will be of interest to some: https://blog.oberbrunner.com/blog/ai-math-as-humanities/
My experience may not be entirely representative because to be entirely honest I’m not exactly a great researcher and there are brilliant PhD students. That said it indeed was my experience that in the pre-PhD / early PhD period ( or even longer … ) your advisor proposes (gives) you pretty low hanging stuff that he mostly already knows how to solve, at least at a high level, with the expectation that it will teach you to use the mathematical tools you need.
This apparently required a 10-page prompt. It seems like someone needs to know enough to write it?
The author also used GPT-5.6 to write the prompt. This did involve giving GPT-5.6 access to his previous work and a back and forth process (so definitely still used the author's expertise to some degree), but the prompt itself is also largely AI generated.
What's the difference between using GPT to write the prompt to GPT, and "thinking"? The LLM uses the first tokens to predict more tokens, and then uses those tokens to predict even more tokens.
Roughly speaking it is the difference between having a contractor go out and do some work and having that same contractor first come up with a plan to do some work, run that by you, and then go out to do that work.
Part of it is as a another comment in this chain mentions the chance to review the prompt. Part of it is that it forces the AI system to plan things in a certain order, in much the same way that forcing the contractor to write the plan out first forces the contractor to proceed in a certain predefined order that may (or may not!) be better at getting to a final answer.
The ability to correct the plan/prompt.
Certainly. This feels similar, to me, to how building complex software with LLMs works today in practice. You need to know a lot to set up goals and guardrails and verify outputs. For me, making the bits change was always the fun part, not tangling with text in my editor, though that had its moments.
Yeah, back to the gold-in-gold out use of LLMs.
I was thinking this past week I have gotten so lazy w my prompting via CLIs.
Back in the before I had put such discipline into my prompting and supporting context.
Now I’m like, “look here and here and here are some tools, and /skill /skill okay go.”
Or “restate this request in your own words and enrich it as appropriate handling any gaps. Okay go”
We're also at the point where you can roll out context to your entire organisation. I created an app for our m365 Cowork and deployed it to everyone who develops software. It does a couple of things, but it main knows our compliance policies and can guide developers through writing the documentation needed for NIS2 compliance. It also guardrails against non-approved packages, and helps developers find alternatives, or if none can be reasonably found, how to get a new package/dependency approved (or rejected).
A few months back this would be something every developer kind of did on their own. Maybe they shared skills, we certainly encouraged it and tried to do all the change management things, but nobody really had the same versions of the skills. Which was horrible in the deployment pipelines, something like the compliance documentation often had to go back and forth several times before it could be approved. Now it's just there, for everyone.
In a year or two, I expect a lot of these things to have become even more standardized. So that we don't even really have to build our own apps, but can simply use the ones in the catalog with minimal configuration (and that config will likely only be necessary because I'm from a tiny country that nobody will maintain standards for).
Yes. I worked on two large monorepos, about one quarter per project. Maybe 80+ devs on first, maybe 40+ on second. Both were not sure how to describe this but ultra-high-velocity agentic driven development efforts.
On the first, there were ~no shared skills. There were some requirements set up but they were not minded properly and became stale / ate context for little gain. The hardest hit was in E2E tests which would flake and create long running, too-often failing CI. People would disable them, because they were not reliable and velocity was so high, no one was happy w them.
I maintained my own set of skills and CLIs to back them. I'd share them if they came up but it was like the old days of manage your own stuff. Not much credit for building and sharing devex tooling to the team.
But then on the second one we were in better shape--we had vendoring set up to distro skills automatically.
Before the project was well underway, I put time into understanding how all of our tests aught to be written. Finding the forbidden things, etc, getting review from our best test folks and ultimately landed on a `/test` that routed across all possible test types.
Like night and day. Instead of finding out while trying to get a release out the door that some corner of the project had a handful of flakes, tests were written the right way from the start.
Like, it was beautiful. And I don't think devs noted difference while building. Only that there was an absence of BS in CI.
Hard to quantify the lack of pain, but it was big!
This made me chuckle because it's so true. So much detailed steering and finagling in the past, now I point the agent to a bunch of information sources, skills, similar repositories that might hold useful input and tell it very roughly what I need and off it goes, I'll grab coffee.
Have you tried this:
?It is an ultra-lite way to plan, I suppose.
I like the format because:
I think the models are doing this anyway, but I find the words "enrich" and "gap" are well understood by models and they demonstrate it in the response to the above pattern.Anyhow, to get back to the point, there are still prompt-level tricks--but ultimately if repeated, should probably also be built into skills themselves!
I would agree with your take. I (author of the post & paper) learned a ton from working on small parts of problems my PhD advisor was doing a lot of the heavy lifting on, and later also from getting some results that were essentially putting together the right pieces that already existed followed by some deep-in-the-weeds analysis.
Math is way more automatable than programming.
In math, a proof is a proof. We don't know if we can get there and so getting there is the hard part.
In software, we always know that we can solve the problem. So HOW to solve the problem is the hard part. Because the type of solution involves maintainability, which involves planning, LLMs suck at it. This leads to "LLM slop code" whereby the LLM creates ad-hoc convoluted logic with redundancies and no reuse of existing standard library batteries.
Unless you're a Grothendieck who gets mad at Deligne for not solving the Weil's conjecture "THE RIGHT WAY", software is fundamentally different than math in this respect.
So I'll say it again, AI will win a fields medal for before managing a McDonald's simply because there are enough big problems within arms reach than their current capacity to plan over time
I've spent some time working both as a math researcher and as a software engineer, and I think this comment actually underrates the similarity between the two fields as they're actually practiced.
Some math research does involve grabbing a single, fully specified conjecture off the shelf and hunting for a proof of it, and it's true that if you manage to solve a long-standing open problem, other mathematicians will be interested no matter how you did it.
But this isn't all of what they do, probably not even most of what they do. Like in software engineering, it's not always obvious which question would be the most useful one to ask. A lot of mathematical work also goes into what we call "theory-building", where you could say that primary work goes into coming up with definitions rather than theorems. Mathematicians also care a great deal about how something is proved; a lot of them are some of the most aesthetically picky people I've ever met. Words like "ugly", "beautiful", "creative", and "boring" are used to describe both definitions and proofs all the time.
From the outside, it can look like all they're doing is pumping out proofs at any cost. But I promise you that when I talk to mathematicians who don't have any experience building software, they have a similarly narrow view of that field as well! Both fields, from the inside, look a lot more human than you might expect.
I think that your take is quite optimistic. Having published in top tier journals my only experience is that mathematicians care about what other mathematicians worked on and failed to solve. Theory building papers are dime a dozen and don't get published in high tier journals unless they solve a problem.
Math is such that most theories are built after solving a problem and actually don't solve a larger class of problems. Etale Cohomology is an example of a rare exception. Grothendieck was mad that Deligne used adhoc complex analysis techniques to prove Weil. But everyone else was thrilled.
Whereas in CS, a good theory (library) solves a large class of problems. The reason being is that CS tackles general problems while math specific ones. Math on average solves problems that don't lead to solutions to other problems.
To me at least, math is more of a game like chess and coding is more of an art. There are aspects which are a game, like performance engineering but I'm pretty sure that LLMs will become superhuman at that soon
If your complaint is about the type of work that gets you published in a fancy math journal, then I'll happily join you on the barricades. Sure, getting a paper into Annals of Mathematics or whatever is more game than art in the sense I think you mean here.
But "what mathematicians care about" is much, much broader than what gets you published in a fancy journal. Mathematics as a human activity is millennia old, much older than the concept of journals or even universities, and that activity is, to me, very beautiful, worth preserving, and more of an art than a game. The incentive structure of academia for the past few decades has done a pretty bad job at preserving that art form, but that doesn't mean mathematicians as actual human beings don't care about it --- if they didn't, they probably would have chosen a different career.
Very fair. But when you say "What mathematicians care about", you are taking about mathematicians today, who really care mostly about politics
It seems to me you hooked onto the wrong part of proofs vs software compared to what OP meant. The difference OP cares about isn’t how much one cares about style. Instead the important difference lies in validation. A proof can be validated as either correct or wrong. That type of hard feedback really helps combat the optimism and desire for shortcuts of modern models.
Now, that still doesn’t help an LLM distinguish between good and bad correct proofs. But it still really helps a lot. On top of that, taste in proofs is a lot more uniform than taste in coding. That helps LLMs be better at judging the quality of a proof, because there’s less disagreement in the wider world.
The standards of proof are different from the fundamental operation of "OK, cool, you solved this problem. Why does this problem matter? Isn't it useless? Senseless? Meaningless?" You have this same question whether or not you're in an a priori discipline (mathematics), scientific fields proper, or engineering. "Absolute certainty" has nothing to do with it. I can assure you, people on the job are not looking for The Absolute Truth when doing their jobs, yet they still can question at a solution by asking: are we solving the right problem?
(Although in general, there's no true difference between "I answered the question correctly, but the question was mapped to this thing we call 'reality' wrong", and "I answered the question incorrectly", because you can (try) adding the constraints that you really wanted targeted in case A, to case B, and boom, suddenly a question/answer pair that was "Answered correctly, but question doesn't map to reality" now becomes, "You answered this question wrong". However, individuals generally tend to have some breakpoint to differentiate between the two).
No, what I'm saying is that I don't agree that taste in mathematics is more uniform than taste in coding! Mathematicians argue about taste all the time. Just as you might look at a piece of code and agree that it compiles and doesn't have any fatal bugs but still think it's badly written, hard to follow, hard to modify, or whatever else, mathematicians judge mathematical work using very similar criteria.
Maybe a subset of mathematicians, but if someone proved that RH was undecidable we would still give them the millennium prize.
The types who do ugly proofs, when they write code, produce spaghetti code. It's the same thought process going into how to approach something.
I think the difference is in math the problem is fully specified and easily verifiable and in programming it's not. I don't agree that we always know we can solve the problem.
Not always, sure but 90% of the time yes.
For example, create a DFA for a regex, not too bad just use Thompson's algorithm and then NFA->DFA. But now we have to care about efficiency, user API, maintainability of definitions etc.
Coding is more of a human problem than math
> So I'll say it again, AI will win a fields medal for before managing a McDonald's simply because there are enough big problems within arms reach than their current capacity to plan over time
AI can manage a McDonald’s already. If manage means directing humans to do something to ensure the store is running. If manage means running robots, then yes maybe that is 5 years away but just directing humans to run a store, that is possible right now.
No it can't. Show me a business which uses in context learning to manage a McDonald's
Well that’s a problem of incentives. Why would a manager outsource their own job to an AI?
It's not a problem of incentives. Every executive wants to inject LLMs everywhere these days. If they haven't somewhere it means that it does not work.
Have you not seen vend bench?