Dear Reader,

For a long time, discussions in the QC community have felt a bit like there are two camps. I used to think this was just the NISQ vs FTQC debate. However, during this year’s IEEE Quantum Week in Toronto, I still had that two-camps feeling, even when talking with people who also work on FTQC topics. I think I have finally figured out where the discrepancy lies, so I thought I’d share it with you!

On NISQ

Most of what follows focuses on FTQC, but I thought it would be useful to give an update on the NISQ side of the discussion as well. One observation from this year’s conference is that people are much more willing to say publicly that working on certain NISQ-related areas is a waste of time, and that it would be better if people spent their effort elsewhere. I’ve heard this in various conversations over the last two years, but this year the sentiment seems to have changed enough that more people say it in public.

I’m not saying that all NISQ-related work is useless. There are still interesting research directions there worth exploring. However, there is also a lot of work whose goal is to make incremental improvements in technology that will become obsolete in the next couple of years. If it’s something that will pay off in the long term, then we should keep doing it. If no clear path for such payoff exists, why do we bother?

Also, to be clear — if someone found real-world applications for NISQ devices tomorrow, I’d be really happy. It’s not like I discard that possibility entirely, I just don’t think it’s very likely.

And with that cleared, let’s jump into the main topic!

Core distinction

Something I have realized, which helped me organize a lot of what I see and hear, is that many people I talked to seem to be in one of two mindsets — either focusing on production or demonstration.

The production mindset is one where your goal is to build a production-grade fault-tolerant quantum computer. By production-grade, I mean roughly:

• capable of running calculations that are meaningfully¹ beyond the reach of classical computers
• doing it in a reliable and reproducible manner

The demonstration mindset is one where we focus on what can be done with the hardware today or tomorrow, rather than in 5–10 years. This mindset seems mostly inherited from the NISQ space, but it can be applied to FTQC demonstrations as well.

There is also a third mindset: the research mindset. This one focuses on long-term, blue-sky research, exploring interesting ideas, and not necessarily worrying about the limitations of anything we can build in the next 10 years. It is important for the long-term prospects of the field, but we’ll leave it mostly out of the discussion, as it’s not causing any issues.

Here is a table comparing the production and demonstration mindsets:

	Demonstration mindset	Production mindset
Main goal	Show what can be done with the hardware we have now or will have soon.	Build a system capable of running useful calculations reliably.
Value of intermediate results	Intermediate research results have intrinsic value.	Intermediate results matter mostly when they move us toward a production-grade system.
Useful scale	10 logical qubits can be a valuable demonstration of error correction.	We need enough logical qubits to run calculations that matter.
Progress model	Build the next generation, incrementally better than the previous one.	Incremental machines are useful only if they are on a plausible path to production scale.

I think the tension between the production and demonstration mindsets is the same core tension as in the NISQ vs FTQC debate. The issue is not that NISQ is inherently useless, or that every intermediate technology necessarily won’t scale. The crucial problem is how much of the knowledge, insight, infrastructure, and technology can be reused in future production-grade systems. My concern is that if too large a share of the field works primarily with the demonstration mindset, whether for NISQ or FTQC, a lot of effort will simply go to waste. I hope the examples below make my position clearer.

Examples

Let’s take a look at some examples from the conference that made me think about this.

QEC

The first one is access to the error-correction layer. This question was always a bit surprising to me — if someone builds a quantum computer capable of solving great problems, why would anyone bother running QEC experiments on it?

If we consider this from the perspective of the two mindsets, the picture becomes clearer.

From the demonstration mindset, having access to a machine that allows you to (finally!) test ideas that have only been theoretical for years is great! You get to see how different codes work in practice, and maybe come up with ideas for better ones. If the device is still not production-grade, the downside of wasting useful runtime is non-existent.

From the production mindset, you want to be much more cautious with allowing people from outside your organization to play with the QEC layer. First, being effective there might require a lot of familiarity with the particular hardware modality. Second, there is the opportunity cost of useful calculations that could be executed at the same time. Third, there is the cost of having an interface for outside users to access this layer of abstraction. Maybe in the short term it’s worth considering in some cases, but in the long term I don’t think anyone will be willing to do it.

Abstraction layers

Another example is the discussion about abstraction layers. For years I’ve been hearing that if we want to get performance out of the machines, we need to break through the abstraction layers and tune all the knobs at the same time. I see the point of that for NISQ devices, but it was always surprising to me why you would do that for FTQC ones. It doesn’t make sense in a production mindset, where your goal is to run useful calculations 364 days a year. In such an environment, all the layers below the algorithmic one are assumed to work properly and give you a clean interface. The whole model breaks if this condition is not met. Therefore, driving toward defining these abstractions is crucial — you can’t have a production-grade system without well-defined abstractions.

On the other hand, if you approach it from a demonstration mindset, then you probably want to break those layers, as this gives you more flexibility to get the most out of the hardware you have. It also allows you to get around the limitations of existing devices.

The difference I see is that, for the demonstration mindset, abstractions are just tools that are either useful or should be discarded. Spending months developing better abstractions doesn’t seem worth the effort.

For the production mindset, they are essential components of the future system. The complexity present in the FTQC stack requires well-defined abstractions and interfaces.

At the same time, I agree with the “it’s too early to lock into specific abstractions” argument that Josh Izaac made at one of the panels. We need to adopt new abstractions, test them in practice, throw them away, and try new ones. But only doing it with the production mindset will lead to solutions that are not over-optimized for what’s available today — and therefore useful in the long term.

Choosing problems to work on

I think this also shows up in the types of applications people decide to work on.

Let’s take optimization problems as an example.

From the research mindset, it’s a great thing to work on. There are many open questions, e.g. can we beat quadratic speedup? There may also be interesting real-world problems it will help us solve one day. I personally find it a very interesting topic and would love to get back to it someday.

From the production perspective, there’s not much evidence, if any, that it makes sense to run optimization problems on quantum computers we can imagine having in the next 10 years. After that, I expect other applications to have much higher value than optimization algorithms, so it will still not be economically viable to run them unless there’s some algorithmic breakthrough. That’s why most leading FTQC applications groups focus on chemistry and differential equations, not optimization.

A combination of these two approaches is a sensible strategy: let some researchers explore the topic and see what they come up with in a couple of years. At the same time, the majority of the field that focuses on making QC useful in the near or medium term should focus on different topics.

However, from the perspective of what’s good for the field, I don’t see any value in near-term demonstrations of running optimization algorithms on real hardware. It doesn’t provide long-term value, and only serves as a short-term demonstration of an application that, given our current understanding, we know doesn’t scale.

I think this is a good example of where the demonstration mindset can be harmful. When people with decision-making power hear about optimization use cases, they cannot always discern whether the context is more production or demonstration. It doesn’t even have to be a matter of malevolence (though it could be!) When we’re not clear about what’s demonstration-oriented and what’s production-oriented, it’s easy for non-experts to get confused and think that the real application is closer than it actually is.

I think once we are closer to useful, production-grade hardware, running such demonstrations will start making sense again, but we are not in that regime yet.

Logical qubits

Something that annoys me is when people say things like “We will have 20 logical qubits next year” and then it turns out that what they mean is actually “20 qubits with error correction and error rate of 10^{-4}”. OK, calling that “logical qubits” is technically correct, but to me it muddles the discussion a bit.

While having 20 error-corrected qubits would be great feat from the demonstration perspective, it’s useless from the production perspective – the error rate is too high and 20 qubits is something I can simulate on my laptop.

Part of the problem is that if you assume a demonstration mindset, then such a thing is truly valuable to you. Because of that, you might use language that overplays the importance of such a feat, even though for someone with a production mindset it’s just a necessary stepping stone.

Making grandiose and misleading claims is something I think we all got used to in our field, but I think it’s worth pointing out that the fact that someone claims to have X “logical qubits”, “algorithmic qubits”, or “useful qubits” doesn’t mean anything by itself. You always need to read the fine print. This is actually detrimental to research: the research community can no longer use some perfectly good words once they get appropriated by their marketing meaning.

Maybe in the demonstration mindset it’s somewhat justifiable, but it is clearly wrong in the production mindset. Though in the end, it’s probably more of a marketing vs science tension than what’s our main topic for today.

Who is right?

Today we only have research-grade systems, which causes many people to be in the demonstration mindset. However, it’s much harder to get to production-grade systems without adopting a production mindset. When you focus on the long term and scalability, you develop different technology. Today the balance is off and we have an overrepresentation of people with the demonstration mindset.

I think we would be in a much better place if we, as a community, spent less time trying to prove what our systems will be able to do in the short term, and more time thinking about what the foundations of this technology should be and trying to build them.

Perverse incentives

Another thing that I’ve been hearing for a couple of years now is some version of the following:

“I know that what I currently work on is not very productive in the long term, but that’s what I got funding for, so I try to make the best of it.”

I’ve heard versions of this from people at universities and companies, from Europe, the US, and Canada. I personally don’t have much experience with funding agencies, but there seem to be several issues with how they operate:

• The agencies can’t keep up with what’s going on in the field, so they still give out grants to work on things that the community has already deemed a dead end.
• Some projects are so long that the topic of the project is almost guaranteed to be obsolete by the end of it.
• There are not enough people in those agencies who have a broad overview of the field and a strategic view of what they’re trying to achieve. From the outside, it sometimes looks a bit like: “We have X millions of dollars, let’s just give it out to people working on QC and this way we will not fall behind other players in QC.”

For example, I once reviewed a project proposal for a four-year grant to work on VQE applications, and it was already at a time when there were serious doubts about the sensibility of using VQE for anything. Someone else had a requirement, coming from funding, to “run programs on real hardware” during their PhD. This seriously limited the utility of what they were doing, as they basically couldn’t work on any FTQC-related topics.

This quote illustrates the issue pretty well:

This is one of the most damaging requirements I’ve ever seen and has caused untold wasted time and potential for absolutely no gains whatsoever. I have never spoken to anyone who genuinely believed running things on real hardware has improved the quality of their research (notably, experimentalists aren’t expected to do this because their research area is hardware itself). As a personal anecdote, my PhD research is now ( years on) entirely useless because it was required to work with hardware that is now outdated.

For less academic examples: I have talked to people working on NISQ-y hardware who admit they think it’s a dead end, but also say that their bosses want this because they need to show progress to investors. I’ve also seen software companies struggling to create great products, as they are torn between supporting researchers who work on NISQ today and building tools for people who can push the production boundaries tomorrow.

I bet this is nothing new to people who either work in these places or apply for this funding, but for God’s sake, this leads to a terrible waste of people’s time and taxpayers’ money! If anyone reading this is in a position to do something about it, please do!

To be fair – I think it’s also worth mentioning that DARPA is doing a great service to the field with its programs! I had the pleasure to be part of the Quantum Benchmarking program in 2022–2023, and I think they really helped to push many organizations more toward the production mindset.

Obviously, it is much easier to focus on the long term when you have more financial stability. And indeed, some of the best results in FTQC application and algorithm research come from organizations with deep pockets, e.g. Google, Microsoft, and PsiQuantum. I don’t expect small startups that can barely survive to suddenly work on problems with a 10-year horizon. But we need more intellectual honesty and courage to point out incentives that don’t make sense.

On PsiQuantum bias

Given that I spent over three years working at PsiQuantum, it’s not surprising that the production mindset I describe here is close to the mindset of people at PsiQuantum.

I’m no expert on PsiQuantum’s hardware, but as far as I understand it, it is pretty hard to build this type of photonic quantum computer without achieving massive scale first. In this technology, you basically either achieve some level of fault tolerance or your device doesn’t work at all.

Therefore, the sole fact of working with such technology creates a preference for the production mindset. However, as I hope I have argued in this article, having one or the other mindset is not just a matter of the underlying hardware platform.

Please keep in mind that none of what I’m writing here represents the position of PsiQuantum. These are all my personal thoughts!

Conclusion

I’m curious what other people think about this and whether they have similar observations. Or on the contrary, whether most people disagree?

I feel like a lot of discussions about HPC integrations and early fault tolerance are repeating the same pattern we had in the NISQ vs FTQC debate. However, I don’t understand these topics well enough to have a strong opinion. For now it’s just a hunch.

It would be great to read your perspective in the comments :)

While I don’t write regularly on the blog, together with my friend Konrad we write a weekly newsletter about quantum software in the QSEN newsletter, so I recommend checking it out!

I also want to thank Sean Greenaway, who helped me a lot with honing the arguments presented here and reviewing the draft :) And Peter Johnson for his feedback on the draft!

Have a nice day!

Michał

Footnotes:

---

• All Posts (31) ,
• Quantum computing (21) ,
• Events (3)