Ever since the invention of the computer, coders have been working in the medium of 1s and 0s, creating the modern world by directly or indirectly manipulating binary computing bits that can be in one of two possible states. Now, real quantum computers are looming on the horizon with promises of speeds anywhere from thousands to hundreds of millions of times faster than classical computers, and so that binary state of affairs may be about to change. Yet how will mere mortal coders manage to take advantage of all that potential speed, when programming for quantum computers has been described as “a task as baffling as quantum mechanics itself”?

According to Simon Devitt, a quantum computing researcher at Japan’s RIKEN Center for Emergent Matter Science, the answer is: with lots and lots of help. Quantum coding may be among the most complex tasks ever undertaken, and so coders are starting to pool their resources and create the tools they need to progress the field as a whole.

On the most basic hardware level, quantum computers differ from classical computers because they are not binary — rather than working with bits that are in one of two states, quantum processors work with “qubits” that are in both of two states simultaneously. A true quantum computer would keep all of its qubits in a “superposition of states,” meaning that the entire array would literally be in all possible combinations of states at once. Speaking in 2013 about his company’s work in quantum computers, D-Wave Systems’ Geordie Rose famously made the true insanity of this idea clear by describing his machine’s calculations as being coordinated across the multiverse.

Yet most classical software engineers aren’t writing their programs in the raw bits of binary machine code, so why would quantum programmers write directly in the medium of qubits? Companies all over the world are developing tools to allow coders to step right over the most mind-boggling aspects of quantum physics. Microsoft is developing its LIQUi|> initiative (pronounced “liquid”), in part to translate appropriate algorithms from well-known coding languages to quantum machine code for execution on a quantum computer.

And just what constitutes an “appropriate algorithm” for execution across the multiverse? It’s a little bit complicated.

First, regardless of the coding language used, all math executed on a quantum computer must be “reversible.” What this means is that all outputs have to contain enough information that the entire process of creating them can be run backwards to regenerate the input. So right off, 1 + 1 = 2 is out, since the raw number 2 cannot on its own be used to derive the two 1s that went into it. Luckily there is a reversible version of every possible computable function, including 1 + 1 — but they’re much more complex to actually use. Translating complicated regular programs into a reversible form is possible, but often makes the code so inefficient that it’s not worth the effort.

Another problem has to do with decoherence, or the fact that the superposition that is critical to quantum computing is only possible when the computer itself is completely, totally cut off from the outside world. LIQUi|>’s Dave Wecker wrote in an email to Inverse that this means even just extracting an output from a quantum computer can become a problem. “When you ask for an answer, you tend to have to start all over to get another one,” he writes. “This makes you choose carefully what you really want.”

Quantum computers are thus “black boxes” in which even the programmers themselves can’t observe the path their data takes from input to output, making bug-checking extremely labor-intensive. Jorge Cham of PHD Comics coined the term “quanfidential” to describe this regime of quantum secrecy.

Perhaps all this difficulty could be surmounted with mass testing and error correction, but there’s an even bigger problem that makes any such brute force solution impossible: the absence of truly robust quantum computers on which to test the code itself. Though D-Wave Systems claims to be selling the world’s first commercial quantum computers, these machines are limited in terms of which quantum algorithms they can execute and, in any case, newly affordable models still come in at a whopping $15 million.

Devitt says this is one of the biggest difficulties with the modern development process for quantum code. “How does a classical software developer or coder actually construct quantum code?” he wrote in an email to Inverse. “The classical community certainly doesn’t sit down with pen and paper to develop an algorithm, but with quantum algorithms that is still the norm.” Back of the napkin calculations may be romantic, but they’ll never change the world if they can’t be tested.

Right now, the absolute cutting edge generalized quantum computers (those that theoretically should not have the limitations of D-Wave’s 2000 qubit devices) come from Microsoft, IBM, and soon Google, but even these are mostly useful as proofs of concept since they don’t incorporate enough qubits to have hit the steep part of the exponential curve of quantum computing power. Though they are almost certainly the prototypes from which world-changing quantum computers will be born, they are not themselves such revolutionary machines, just yet.

IBM is making its prototype quantum computer available over the cloud, so it can be used to start testing quantum code, though the limited number of qubits means that it’s still too slow for useful for more than computing research. To supplement this, teams from around the world, most notably at LIQUi|> itself, are learning how to model quantum computation on normal computer hardware. These quantum simulators don’t provide the incalculable speed benefits of quantum hardware, but in exchange for that they can do their work without requiring real entanglement of quantum particles. As a result, not only do these simulators exist for active development right now, but they allow observation of their own processes, meaning they are not black boxes. In principle, the workflow would be to get a quantum algorithm working in the transparent but slow-motion context of a simulated quantum environment, and only then port it over to the opaque but much speedier context of an actual quantum computer.

Unfortunately, every additional simulated qubit doubles the requirement for the simulating computer’s RAM; simulating 30 qubits in superposition takes around 32 GB of memory, while 31 qubits takes around 64 GB. By the time you hit 45 simulated qubits, the classical computer already needs well over a petabyte of memory to keep everything straight. Larger quantum computers than that will be needed to do useful calculation, meaning that right now the most potentially important pieces of quantum code can’t be tested in either a real or simulated quantum environment.

Devitt believes that progressing these tools for facilitating quantum coding will be absolutely essential to realizing that code’s potential — even before the computers themselves hit the wider market. “The most astonishing and impactful quantum algorithms and programs,” he writes, “will not be discovered or invented by physicists or quantum computing engineers.”

In that way, at least, the development of quantum programming may look a little like the classical code that came before it.