Daniel Volz (RhymeQ): Quantum’s next bottleneck is who writes the code

Published research suggests that 150 to 200 logical qubits could make quantum chemistry useful, and several hardware roadmaps aim for that range within a few years. Daniel Volz argues that the bottleneck then shifts to software. His team at BASF found 130-something use cases, and by his rough estimate only 1,000 to 2,000 people worldwide can program quantum circuits. He explains why he thinks coding agents won't close that gap in the near term. Circuits, he says, are 'almost assembler level,' so domain experts need an abstraction layer above them.

Transcript

Yuval Boger: Hey, Daniel. Thank you for making time for me today.

Daniel Volz: Hi, Yuval. Always a pleasure to talk to you.

Yuval: Likewise. So who are you and what do you do?

Daniel: I'm Daniel. I'm a chemist who somehow found his way into quantum computing 10 years ago, and I'm now launching my next quantum software startup, called RhymQ.

So that's essentially who I am and what I'm doing. I've been in quantum now for about 10 years, with my 10-year anniversary at the end of this year, and I've seen many different sides. I started while I was at McKinsey, led quantum computing at BASF for a while, co-founded Kipu Quantum, and I'm now on to my next journey at RhymQ.

Yuval: So what is the problem that RhymQ is aiming to solve?

Daniel: I'm talking a little bit like an old man since I've been in this industry so long. But if I reflect a little bit on where I'm coming from: when I started, essentially when IBM made very few noisy qubits available in the cloud via the IBM Quantum Experience, we were happy to have qubits at all.

When I founded Kipu five years ago or so, we had more qubits, but we felt that we needed to develop some really specific algorithms to be able to derive more potential. And if I look at where quantum is right now, things have really changed, because hardware is about to allow really useful stuff to happen.

So hardware made a lot of progress, but if I look back at what happened on the software side, not that much, to be honest. Back then everything was running on quantum circuit packages, used by people who liked to fiddle around with individual qubits. People typically had a physics degree, master's level at the very least, and many of them were physicists.

And I feel that this is no longer the right play to really make quantum accessible for everybody. At RhymQ, we want to make quantum accessible for everybody by making it programmable for people who do not know or understand what a quantum circuit is, and do not want to learn what a quantum circuit is.

So that's essentially what we are doing in a nutshell. And what I like is, I don't know if it was the CEO of NVIDIA or the CEO of Microsoft, but one of these gentlemen said that quantum is essentially where AI was four or five years ago. And this was about one year before ChatGPT launched.

And I think we are very far away, as a quantum community, from everybody using quantum as easily as they could use ChatGPT four or five years ago. This is what we want to change.

Yuval: When you were working at Kipu, the message was, "We need to do things that are super hardware-optimized. We have ways to get the maximum performance out of the system." Do you think that's changed now that we are really in a world where software can be generically applied across multiple platforms?

Daniel: The value proposition of Kipu, from my perspective, is still relevant and still valid. What has changed is that we are now at a point where, let's say in the next couple of years, it's no longer about providing individual POCs and individual demonstrations of the things that quantum could do.

We had quantum advantage claims left and right about many different nitty-gritty use cases. But I feel that for these applications to really be used by industrial players, they really need to get their hands on them. And then it's no longer about doing one deep algorithm, with everything else done by quantum physicists.

I think we need to move to a point where you can hand it over to the domain experts who are responsible for the nitty-gritty of certain applications. Then, if you're already at that point, it's no longer about finding fundamental algorithms. It's about, "Okay, for my risk modeling routine in a bank, I need to twiddle and adjust certain minor things." You could give that to a quantum physicist, but they would be bored out of their mind, and they would probably have to make these minor adjustments 12 times a day.

So that is the reality of running some of these use cases in production. And I feel that we will not come to the takeoff point of quantum if everything needs to be micromanaged by PhD-level physicists all the way into the future. So there has to be a handover point. And if you really want to make it available to the people doing risk modeling, or clinical trial modeling in pharma, or computational chemistry in the chemical industry day in and day out, you need to come to a different abstraction level than quantum circuits, because that is too deep.

It's too low, almost assembler level, essentially. So you need a higher abstraction for these kinds of things.

Yuval: Help me position RhymQ. There are several different software approaches, right? There's the approach by, say, Horizon Quantum or Classiq, which try to create middleware, maybe hardware-aware compilation.

There is the approach by companies like QC Ware, Algorithmiq, or maybe Zapata that say, "We work at the application level, and we'll create something that's specifically for DFT or something else." And then there's the NVIDIA approach: "You've been working with HPC, and now we're just going to give you an API that achieves the same results, except better, on quantum."

Where do you place RhymQ?

Daniel: I would say it's fairly high in the software stack, not at the top of the pyramid, but close to the end users. And I think it's fundamentally valid to say, "I'm doing individual applications." But if you do that, then the burden of doing the integration work all the way to the end users, who are not going to be quantum physicists, essentially falls on the shoulders of the software providers.

And if the addressable market of that individual application is large enough, then of course it could be a valuable business case. Something that I found striking when I started in quantum, not a decade ago but about seven years ago while I was at BASF, is the sheer number of applications that these large organizations have.

At BASF, for instance, we even wrote a book chapter about this, so I'm not spilling any company secrets. I think the chapter was in German, though, so now I'm disclosing this to the English-speaking world. But we essentially found 130-something use cases within BASF. So let's say the overall value of quantum is split into 130 buckets.

And if you're an application provider that, in the worst case, has to do back-end and front-end integration 130 times, it's not going to be economic anymore, unless you are looking at some very concentrated, huge use cases. But I think lots of these applications are cases where the industry users have certain knowledge and may be able to adjust the parameters of these use cases themselves.

So I think that's the sweet spot of the applications that RhymQ is essentially developing and facilitating. Besides that, we are a highly collaborative company. We are going to compile into lower-level languages like CUDA, for example. So we have no plans of reinventing the wheel.

We will also work with hardware companies, and with lower-level quantum software companies that take our output into their hardware-aware compilation, for instance, to provide access to quantum for large groups of people in cases where it's not economic for individual software companies to be vertically integrated.

So that's our somewhat convoluted positioning in the overall ecosystem.

Yuval: You mentioned 130 buckets. They're not equally sized, and they're not equally present. Some are probably farther away than others.

Daniel: Yes.

Yuval: Can you share the initial applications that you focus on at RhymQ?

Daniel: When we last spoke, I was talking about chemistry, optimization, and machine learning as the applications that I think are closest. If I put those in order, I would say it's chemistry, machine learning, and then optimization. And there will be smaller applications, especially in chemicals, where you will probably soon have some really interesting things going on.

I'm not going to weigh in too deeply on the NISQ versus FTQC discussion. I just want to point out that there is enough scientific evidence out there to suggest that with something like 150 to 200 logical qubits, you could do some really interesting things in chemicals, materials, and so on.

So there's enough research that suggests that. And if I triangulate that with hardware roadmaps, there are several very credible players that have said they will have 200 logical qubits in the next 12, 24, 36, 48 months or so. So if some of them are correct, then chemistry will essentially be unlocked.

And lots of the 130 use cases that we identified in this big team effort at BASF are chemistry-related. But the issue is that it's not super generic. Before my 10-year quantum journey, I was actually a materials scientist in a small startup developing materials for organic light-emitting diodes.

And what I recall vividly is that we actually had several workflows that would benefit from theoretical chemistry with quantum. They are super specific, so I think it's not very likely that one quantum software player is going to build a comprehensive suite of solutions that are relevant for all of these chemistry applications.

So we need this to be accessible to the end users — materials scientists, chemists from other disciplines of chemistry, and maybe pharmaceuticals, for instance — to really tap into this potential. If not, we will create additional overhead, which will push the whole timeline further into the future, because additional overhead means that instead of 200 logical qubits, you might need 500 or 800, which is not as near-term if I look at the roadmaps from the hardware side of things.

Yuval: In your answers, you mentioned the word "integration" several times, including when describing the problem: how a customer doesn't want to worry about integrating with front-end or back-end systems.

Daniel: Yes.

Yuval: To what extent does your solution integrate with classical systems beyond the quantum computers?

Daniel: The problem we are tackling with our abstraction is essentially the quantum part of things. But of course, you can tackle this with agentic approaches that look at a problem and pull it apart to say, "Okay, this piece is classical, and this piece is quantum." So from that perspective, it's fully integratable, but we really shine on the quantum part of things with our technology.

Yuval: Since you brought up AI, do you feel that future applications will be written by AI? Why is there a need for companies writing quantum solutions when, some people say, in the not-too-distant future AI will be able to do that?

Daniel: The question is, when is this not-so-distant future going to be here?

I would say the closest proxy to quantum these days is high-performance computing. And I think it's worthwhile to look at how people are using coding agents when running workflows on HPC clusters. I'm not an HPC expert myself, but I've spoken with a lot of people who do this in industry, and what they've been telling me is that folks are playing with agents and coding agents for HPC.

But at the end of the day, they're using them for rapid prototyping, and then a person who knows the problem and knows the HPC cluster takes over and does some manual optimization work. And folks are estimating that maybe in the next two, three, four years, this is going to change for HPC.

And keep in mind, HPC is about two to three orders of magnitude larger in market size than quantum, at least right now. So if I were OpenAI or Anthropic, I would probably focus on the bigger piece, HPC, and make that work before I turned to quantum. And that means to me that coding agents for quantum are probably not going to be available in the very near term.

There will probably be a case for using coding agents for rapid prototyping, but if you're not able to do what folks are doing right now in HPC, and that is manual adjustment, especially from a use case perspective, you will not be able to put stuff into production like this. And the big issue is that, again coming back to the 130 use cases, which essentially belong to 130 domain experts with different educational backgrounds, these people will not be able to understand Qiskit or quantum circuits.

And this is not just about Qiskit. You could replace Qiskit with any low-level, quantum-circuit-based language you like. They would not be able to understand it. And if a coding agent outputs code that is a quantum circuit, you will never be able to get from prototyping and playing around, to optimizing, going the last mile, and putting stuff into production.

And this is why I think agents are, of course, the future of software and also of quantum software, but this is not a near-term solution in the next X years, with X probably being larger than six or seven or so.

Yuval: Let's assume I represent Dow Chemical. You mentioned BASF, so let's take another company.

Daniel: Sure.

Yuval: And I want to work with you. What is the right expectation in terms of timeline? What does the process of working with RhymQ look like, and how long should I expect between engaging with you and getting value?

Daniel: I would say you could start engaging with us right now. We've recently released the pilot version of our product, and you can actually test it for free. And of course, there's also an enterprise offering that you could test. Of course, I will not say that with us you can make 200 logical qubits appear faster.

That's not what we're doing. I'm confident that the hardware ecosystem is delivering this. But the question is, once we have 200 logical qubits, are you going to lose several years doing onboarding, or trying to hire quantum physicists whom you may not get? Or can your existing team get busy right away?

And I think with us, the theoretical time to value is essentially identical to the timeline on which we get something like 200 logical qubits available through AWS. So I think that's a drastic acceleration, especially given what you would need to do to sidestep what we are offering.

You would either have to hire PhD-grade physicists — and right now we have probably something like 1,000 to 2,000 folks on the planet who can code using quantum circuits. That's not going to be enough for all of these enterprises, especially when everybody starts hiring the way some of the front-runners have, building up teams of 25 to 50 or maybe even 100 PhD physicists.

Your pool of 1,000 people is going to shrink down to nothing very soon. So hiring is maybe not the silver bullet solution. Upskilling takes a very long time; that could be a two-year timeline if somebody who is, say, a computer scientist starts to learn how a quantum circuit is to be coded.

So I would say the time to value is as short as it can get with us. Besides what we are offering at RhymQ, you would either need to hire lots of quantum physicists yourself, or work with consulting companies and maybe disclose your company's deepest secrets around workflows to them, or upskill your own team, which could take two years per person, essentially.

So that's the answer, I would say.

Yuval: So essentially you would be a quantum translator. On one hand you understand chemistry, and on the other hand you certainly have deep experience in quantum computing, so you help bridge the gap between the physics, the qubits, and the business problem with your platform or product.

Is that about right?

Daniel: Yes. I think that's a fair way to position it. We really make it accessible to people who don't understand these quantum circuits. And just to put this into perspective, I said that we have about 1,000 to 2,000 people — if you just look at unique contributors on GitHub, for example, folks who used Qiskit and put stuff there, the number's between 1,000 and 2,000.

And for our product launch, we got about 1,500 sign-ups on our wait list. And who are these people? Essentially folks who say they are very interested in quantum but don't know where to start, have no physics expertise, and find the prospect of learning quantum circuits very frightening, to say the least.

And I think that just shows the order of magnitude of the overall problem.

Yuval: Could you share a little bit about the origin story of RhymQ? Is it based on technology that you developed, or is it licensed from someplace? What is the background of the founders, if there are other founders besides you?

How many people? How are you funded? Anything you can share with us.

Daniel: Yes. So it's not my technology. I'm just a chemist. I know many things, but I'm not a computer scientist, of course. I have two co-founders. One is a computer science PhD with a postdoc in machine learning, and I think the most valuable thing he brings is about 15 years of enterprise developer experience.

My co-founder and CTO, Tomas Zwager, used to work in the Swiss financial industry, at companies like Swiss Re, which is a reinsurance company, and UBS, which is a bank, and especially worked on risk modeling in these organizations. So he would have been the guy tasked with putting stuff into production if somebody brought a quantum-advantage-level solution for risk modeling.

And like myself, Tomas started to learn quantum about a decade ago. Of course, he's more technical than I am, so his motivation was not to figure out the value and apply it to chemistry. He was like, "Okay, I'm a reasonably smart developer, maybe nerdier than average, and it shouldn't be that hard for me to learn how to code quantum." That's essentially what Tomas said.

And it actually took him a while, more than a year. He had to read Nielsen and Chuang, this very smart but not-so-easy textbook that many people have to go through when they learn quantum information science. He found that his linear algebra skills, despite being a PhD computer scientist, were not sufficient to use these low-level languages.

And of course, he had to learn the quantum physics baseline that you need if you really want to work at the individual qubit level. This took him quite a while. Nowadays he knows how it works, but his conclusion after going through that gauntlet was that no enterprise is going to be as foolish or as stubborn as he was. So he invented this abstraction layer to make it really easy for people who have a deep understanding of a problem they would like to solve, and maybe Python skills, to make quantum usable without becoming quantum physicists themselves.

And I have a second co-founder, Christina, who is also based in Switzerland. She's essentially an operations person, with a lot of business operations expertise from various start-ups and scale-ups as chief operating officer. She essentially makes sure that the trains run on time, and that all the business operations as well as business development are running smoothly.

Yuval: What do you see in the quantum ecosystem in Europe in terms of quantum sovereignty, quantum nationalism? I think there's been a lot of focus on hardware. Do you think there should be an equal focus on software development and building local capability to actually deliver algorithms and applications?

Daniel: This is ultimately a necessity. I'm not so sure the governments in Europe are going to play as big a role as they play on the hardware side of things, where lots of governments buy quantum computers to support local quantum hardware companies. And maybe it's not even necessary, because — of course, I would like to be paid well and so on — the truth is that developing quantum software is orders of magnitude less expensive than developing quantum hardware, so maybe we are just fine.

But let me wear my old hat again, coming from the end-user side of things, from industry. For industrial players globally, and also in Europe, the question is maybe less "Is the hardware made in Europe?" The question is, "Can we get access to hardware, and can we get access to software to solve our problems?"

And if both of these questions are answered with a yes, then they have a shot at tapping into the value of quantum. People, maybe rightfully, take a lot of care to secure sources of hardware, but software access also needs to be provided. That's essentially what has to happen, I would say.

Yuval: Daniel, you're a repeat guest on this podcast. You were wearing a different hat last time. So let me ask you my favorite hypothetical question: if you could have dinner with one of the quantum greats, dead or alive, who would it be this time around?

Daniel: Oh, I really want to meet Peter Shor at some point.

I'd go even deeper on the software side, and I say this because what we are doing is, of course, making quantum software accessible, making libraries accessible. And I think most enterprises won't do algorithm development. But I would also say that part of what led to Peter Shor being, I don't know, a solitaire or monolith in the history of quantum information science is that it used to be so difficult for people to get access to that.

And I'm wondering, is it possible that more people who are maybe not as smart as Peter Shor could find algorithms if the entry barrier is lower and the required math skills are reduced? That would be an interesting thing to discuss with Peter, maybe over a nice dinner or a nice glass of wine.

I'm really curious about what he would say about that.

Yuval: Excellent. Daniel, thank you so much for being here today.

Daniel: Thanks, Yuval.

Yuval Boger is the Chief Commercial Officer of QuEra Computing.