IBM’s Quantum team is in a position IBM hasn’t been in for a long time – credible technical leadership in a market that still hasn’t picked its de facto platform. Quantum is not going to replace classical computing or AI infrastructure. Rather its merits will be one on its ability to affect breakthroughs in science that conventional computing can’t accomplish. The physics are still fragile but IBM is working to turn quantum into a repeatable system customers can program, operate, and scale. IBM has the right mindset for this in our view – deep science expertise, vertical integration capabilities, an understanding of hardware/software boundaries and the discipline to engineer for reliability.
The opportunity we see for IBM is pairing that integration with a horizontally open ecosystem. An AMA at IBM Think 2026 with Jay Gambetta, Director of IBM Research and Jerry Chow, and CTO, IBM Quantum-Centric Computing focused on the state of quantum. The discussion included a glimpse as to how IBM is optimizing Qiskit and the surrounding ecosystem for performance and real-world orchestration while recognizing that customers – i.e. those in national labs and HPC environments – already have schedulers, libraries, and operating procedures that aren’t getting rewritten any time soon. IBM’s strategy is to plug into those systems, let partners contribute libraries, and evolve toward hybrid quantum-classical computing without trying to force the world into a single programming model. In our opinion, that combination – an integrated system underneath, an open ecosystem on top – is IBM’s best chance to regain its edge in the next computing paradigm.
What follows is a summary of the Q&A session with these two IBM leaders.
Key question: How far are we from a frictionless quantum developer environment – where Qiskit can auto-orchestrate work across classical and quantum nodes based on real-time cost and efficiency?
The answer was that the industry still has a hard separation between classical and quantum compute, which limits hybrid workflows today. IBM’s view is that you don’t get to seamless auto-orchestration until the library layer is stronger – and that remains active research.
IBM described its reference architecture as a journey – bringing together the infrastructure layer (binding classical code onto resources) and the middleware/orchestration layers that steer parts of a problem to the right capabilities. The key nuance is that orchestration can’t be one universal scheduler that replaces everything. National labs already have schedulers and orchestration systems in place and quantum architectures needs to plug into those, not rip them out.
Key Message: The path to lower friction hybrid quantum-classical development goes through libraries first, then orchestration that integrates into existing HPC environments – not a clean-sheet rewrite.
Key question: Does AI make quantum software obsolete – or does it expand what quantum software becomes?
IBM’s answer was consistent with what we’re seeing across markets in that AI changes how practitioners connect the pieces, but doesn’t eliminate the need for the underlying software ecosystem. IBM’s comments pointed to AI tooling already being integrated into the development workflow and documentation, helping developers interact with the system more effectively.
Key Message: AI doesn’t co-opt the quantum software ecosystem – it simplifies the on-ramp by making it easier to assemble workflows and reason about how to apply quantum where it belongs
Key question: What are the first quantum use cases that are impactful – and what’s the practical near-term category?
The discussion stayed on the typical quantum use cases of simulation and optimization, and extensions into machine learning use cases. It also leaned into the idea that quantum doesn’t replace AI – it complements it, enabling computation that’s impractical on classical systems while AI improves how quickly practitioners can iterate on algorithms and workflows.
There was also a clear emphasis on differential equations (Arvind shared this as well in his AMA) and real-world physics problems over time – aerodynamics, fluid dynamics, reservoir modeling – the class of problems where classical approaches run up steep costs and where quantum advantage would be meaningful if it can be engineered into repeatable processes.
Key Message: The nearer-term use cases remains simulation + optimization, but the longer term potential exists for real-world physics and hybrid workflows where quantum is a component inside a more diverse computing pipeline.
Key question: Why is IBM’s dilution refrigerator so much larger than other approaches – and what does that imply about scale and interconnects?
IBM explained that earlier iterations targeted a larger modular cryogenic approach because the team expected to need that space and cooling to get toward thousands of qubits.
Then IBM shared a key datapoint and hinted to new announcements this summer. IBM was able to reduce infrastructure requirements through higher-density wiring, better packaging, and related improvements, to the point where standard smaller systems can fit thousands of qubits. That led to the next scaling question – how to build a modular system going forward, rather than a one-off monolith.
Key Message: IBM is treating scaling as an engineering discipline with modularity, packaging density, and system design – not just adding more qubits. Look for smaller “chandeliers” coming this year.
Key question: How does IBM think about optical/photonic quantum approaches versus superconducting – and why is silicon strategic?
IBM’s answer emphasized a practical scaling argument in that the technologies which can be manufactured and iterated on silicon tend to improve faster because iteration cycles are shorter and the ecosystem is mature. The core point was to highlight iteration speed and manufacturability as strategic differentiators.
Key Message: IBM is optimizing where iteration cycles and manufacturability can create a flywheel. Silicon-centric approaches have structural advantages in speed of iteration.
Key question: Quantum + security – when do we break classical crypto, and what should customers do now?
The discussion underscored two parallel tracks: 1) The industry transition to post-quantum cryptography (PQC) standards and implementations, and 2) IBM’s posture that customers shouldn’t wait for the break moment to address the risk because migration planning, inventorying where crypto lives, and staged rollouts take time.
Key Message: Harvest crypto now, decrypt later risk is a forcing function for customers and enterprises should move sooner on PQC roadmaps rather than treating it as a 2029+ problem.
Key question: How does quantum adoption scale – direct consumption from IBM, through partners, or via service providers?
IBM described a view where early use cases are driven by scientists and advanced users, but where broader adoption will require experimenting with business models and routes to market – including working with startups, GSIs, and regional providers. IBM is actively testing models rather than declaring a single universal consumption approach now.
Key Message: The adoption scenario IBM put forth is unsurprisingly hybrid. Signaling direct access for advanced users, partner-led packaging for industry solutions, and multiple business models tested in-market before IBM commits to a single “winner.”
Our take – IBM’s open software, integrated engineering posture with quantum is potentially a back to the future moment
We believe this AMA shows IBM playing a two-level game:
- Openness as the adoption angle: Qiskit, libraries, and partner integration are the ecosystem hook. IBM can’t build a quantum market alone, and the fastest path to developer mindshare is open software and a partner-friendly posture that plugs into national lab and HPC realities.
- Deep integration as the differentiator: Quantum is still an engineering problem – cryogenics, packaging, wiring density, controls, error reduction. That’s where IBM’s vertical integration can create advantage, similar to what we’ve seen in mainframe markets.
The trick is to keep those two vectors in balance. In other words, be open enough that the ecosystem can make money and build on top; while being integrated enough that IBM delivers a system that works at scale and gets better with each generation.
Key Message: IBM has an opening to be the platform company in quantum – if it keeps Qiskit and the partner ecosystem open, while continuing to win the engineering race underneath.
Action item: Don’t be lulled into a sense of complacency with forecasts that suggest quantum is a next decade trend. Treat PQC with urgency and consider it a 2026 project. Inventory where cryptography lives (apps, APIs, third-party SaaS, etc.), prioritize crown jewel data and any long-retention records, and affect a phased migration plan with test environments and vendor deadlines. Assume adversaries can harvest encrypted data now and decrypt later, so the work has to start before the quantum day arrives.
At the same time, quantum computing itself is a lab + partner trend for the next several years. Assign a small team to track IBM’s roadmap, run targeted proofs in simulation/optimization where it fits, and build internal literacy, but don’t let it distract from PQC readiness and agentic buildouts. PQC is the near-term risk management imperative; quantum advantage is the longer-cycle opportunity but AI is today’s priority.
