Comment by mindwok

How much effort do you put into prompting it? Are you asking it one shot with a simple prompt? Are you giving it to multiple agents and giving them a workspace to collaborate in? You might give it to a trusted colleague who does not know the solution along with an agreement to jointly publish, ask them to go through the process of solving it with agentic support, and then compare your solutions.

Edit: to be clear, I completely believe your experience - just pointing out that it might be interesting for you to actually “try” to solve it thoroughly with the tools, though it is obviously hard to do that in a fair way when you know the solution.

Iirc some of the prior math discoveries involved very very very heavy handed guidance to force the AI to discard prior assumptions, and to try many avenues with MAX effort. So ya models don’t behave like ground breaking theoreticians by default.

Ha, I had a similar little test problem, but the frontier models are now smart enough to read enough online of what I posted here and there to piece together the answer. And someone else has written the paper in the meantime and got it accepted for publishing.

Definitely. It will let some smooth-talker with a vibe-coded website raise billions for "Nuclear Fusion AI". Then they can use AI to squeeze your team with lawsuits until you agree to sell cheap, and maybe keep you on as an employee to build it.

How about swarm of agents controling a fleet of humanoids and automated construction vehicles?

I mean, you never know. If we could have simulation models with excellent fidelity, then AI could do all the research and iterations and come up with something very plausible. Cutting down physical world experimental iterations/prototyping.

So effectively, you would spend the first 1000 experiments inside a computer simulation and move to the physical world only when you had enough confidence.

Nothing could go wrong

The thing that I've not fully groked here (might be relevant) is that OAI is generating "paper" proofs first, and only then formalizes them in Lean as a separate step. They've as far as I'm aware not said anywhere how many write ups failed formalization due to a bug in the proof. If we assume that number is low, models would be quite good at one-shotting math proofs. Then it depends if you can replicate the math RL training for chemistry/biology/medicine. Is there enough data out there for that? No idea.

Exactly my thoughts.

I find that unless the outcome I'm looking for from the model is almost binary and easily verifiable, it is basically faster to do the work myself.

Assumptions made by the models multiply and by the non-deterministic nature (dbf, similar to work by humans) I'll have something end up light years away from where it should be. During a normal workflow, I have to contend with every line I write forcing a very tight feedback loop... I suppose I could also sit there and spend 9 hours writing out a "perfect spec" but we've already tried that with waterfall development!

So, not sure if its the models, rather the class of problems I'm applying them to... but it is a bit ironic they are allegedly able to solve these conjectures but not stop to ask about assumptions.

1. This has not been my experience

2. We dont have the actual frontier models

internal unpublished models + large swarm of agents (>2000)

I don't understand this dialogue, which seems to repeat with every result of this sort. Of course this is interesting! And of course the answer tells us something! And of course we also want to understand where it came from! None of this is in contradiction!

Knowing the answer to Fermat’s Last Theorem wasn’t valuable. But the pursuit of it led to many developments in other fields of mathematics that were valuable (where value is measured in terms of $).

I disagree. We climb mountains for the sake of it, and the rest of the world benefits because the gear improves and makes adjacent, non-for-the-sake-of-it activities safer.

We chase open problems for the sake of it, and others sometimes support us in doing so because the paths we pave along the way end up being useful for them for adjacent purposes. If you get the answer for free, you might have scratched the itch, but nothing was built for others to use, no fodder was found for the next great question.

Nobody pays mathematicians for solving famous problems. Famous problems are how mathematicians orient themselves while they do the other things that they're paid for (maintaining a useful community, mostly). All this does is deprive them of a navigational tool.

> Imagine a programmer telling their boss it’s not about working software it’s about the journey of writing the code. Good luck getting hired.

Your formulation is a little bit exaggerated, but I (and many, though far from all, programmers) would agree with the following more "tame" formulation:

Getting software to solve a business problem in an elegant and maintainable way means that we got the abstractions right. Similarly, if a software can easily and elegantly be modified to cope with new business problems, it is also a strong sign that we got the abstractions right. In this sense, the business problems that the software solves are indeed just waypoints on the journey of finding the proper elegant abstractions for putting the business problems into code.

Turning these novel insights about "good" abstractions into code and programming languages enables the team to iterate faster and generate business value faster. So, appreciating that it indeed all about the journey means a commitment towards an approach to accelerate the rate with which the team can turn business insights into code and code into business value.

I know that many managers do hate such a formulation, but I stand behind it.

This is such a short sighted take. Number theory was considered beautifully useless for centuries, and now it’s the backbone of the cryptography that secures every bank transaction. We don't know where the pursuit of knowledge will take us.

Thinking in such a utilitarian way feels like a flavor of Meditations on Moloch.[1] Just look at how short-term, quarter-to-quarter thinking is affecting the economy and the lived experience of every human on earth. It’s horrible.

[1] https://slatestarcodex.com/2014/07/30/meditations-on-moloch/

Completely wrong.

Often a problem is important because we have no idea how to solve it, which means we need to develop new machinery to solve it. That new machinery can then be used to do things we couldn't do before. Stimulating the development of that machinery is the most important part of the problem.

You should remember that mathematicians and programmers working for a company have different jobs with very different goals.

"Knowing the answer" means more than knowing the value of a single yes/no bit.

Knowing the answer is valuable, but it's not everything. We also want to understand why. The four-color theorem has a computer proof, so we know it's true, but we learned much less from that than we do from a human-understandable proof.

Many of the OpenAI results can be made human-understandable, so it's better than the four-color theorem example.

If you were a math grad student, would you rather your advisor be telling you to LLM maxx your ideas or working with you and giving you ideas on your thesis personally? I know my answer.

> If knowing the answer is not valuable then asking the question wasn’t valuable to begin with.

Let's say it's possible to know an alien civilization exists 100 million light years away from their waste heat. But that's all we know and it's unlikely we'll ever interact with them.

Was the question of whether we're alone still "valuable"? Wouldn't a lot of philosophy and even some physics fail to meet your definition of valuable?

> Imagine a programmer telling their boss it’s not about working software it’s about the journey of writing the code. Good luck getting hired.

Imagine the next version of Claude Code or Codex no longer hands you source code and instead turns a natural language prompt directly into a compiled binary that passes the test suite. Would this programmer's boss ship the binary straight to production and dispense with the company's git repo altogether? After all, the goal at the end of the day is shipped software that produces value, not human-readable source code.