Lenguajes de programación cuántica con los que construimos

Si hoy quieres programar un computador cuántico, lo más probable es que lo hagas en Python. Qiskit, Cirq y PennyLane son los tres SDK con los que casi todos empiezan; Q# y CUDA-Q cubren lo que Python hace peor, y OpenQASM 3 y QIR son los formatos que permiten mover un programa de una herramienta a otra. En esta guía comparamos los lenguajes de programación cuántica con los que construimos en AndesQubit: quién los mantiene, a qué hardware llegan y cuándo elegimos cada uno.

Antes, dos advertencias. Ninguna de estas herramientas hace que una computadora cuántica le gane hoy a un buen solver clásico en un problema de negocio, y el lenguaje casi nunca es lo que frena un proyecto. Además, todo cambia rápido: Qiskit eliminó APIs antiguas en sus versiones 1.0 y 2.0. Revisamos cada versión y cada estado contra las fuentes oficiales en septiembre de 2026.

Comparación de lenguajes y SDK cuánticos

La columna “nivel” indica qué tan cerca del hardware trabajas. Un SDK arma circuitos desde otro lenguaje (casi siempre Python), un lenguaje tiene su propio compilador y una representación intermedia (IR) es un formato que se pasan las herramientas entre sí.

¿Qué lenguaje de programación cuántica usar en 2026?

Para la mayoría, Python con Qiskit. Es el que tiene más comunidad, más tutoriales y el camino más corto a hardware real, los procesadores de IBM. El segundo paso es aprender a leer OpenQASM 3, porque todos los SDK grandes lo exportan y te deja ver qué hay de verdad dentro de un circuito.

Lo siguiente depende de tu rol. Desde ciencia de datos, suma PennyLane, que conecta los circuitos con PyTorch y JAX. Si tu equipo ya escribe CUDA, CUDA-Q. Si te interesa calcular qué tamaño de máquina necesita un algoritmo, Q# y el estimador de recursos de Microsoft, gratuito y sin cuenta de Azure.

Lo que más se transfiere entre herramientas no es la sintaxis sino los conceptos: el cúbit (qubit, en la literatura en inglés), las compuertas, la medición, el ruido y el ciclo híbrido. Por ahí empieza nuestra formación en computación cuántica para equipos, y luego suma el SDK del hardware que tu empresa probablemente use. Los términos de esta página están definidos en el glosario.

Qiskit, Cirq o PennyLane: ¿cuál conviene?

Qiskit si quieres hardware de IBM o más ejemplos; Cirq si necesitas controlar al detalle un dispositivo o haces investigación; PennyLane si el problema es de machine learning o necesitas gradientes. Los tres son gratuitos, Apache 2.0 y con versiones frecuentes.

Qiskit llegó a la versión 2.5.2 en agosto de 2026. IBM lo rodea con Qiskit Runtime, una API en C y un catálogo de Qiskit Functions de socios. El precio de ese ritmo: un código escrito para Qiskit 0.x necesita trabajo para correr hoy.

Cirq (1.7.0, junio de 2026) lo mantiene Google Quantum AI, se integra con el simulador qsim y trae módulos para hardware de Google, IonQ, AQT y Pasqal.

PennyLane (0.45.1, junio de 2026) es de Xanadu. Trata los circuitos como funciones diferenciables y llega a dispositivos superconductores, de iones atrapados, de átomos neutros y fotónicos mediante plugins. Su compilador Catalyst está construido sobre MLIR y baja los programas a LLVM y QIR, algo que importa cuando un ciclo híbrido tiene que correr rápido.

¿Qué otros SDK de Python vale la pena conocer?

El SDK de Amazon Braket, pytket y Guppy de Quantinuum, Qrisp y Qibo resuelven bien problemas más acotados. Los elegimos cuando el hardware o la infraestructura de tu equipo apuntan hacia ellos.

Para un banco en Santiago o una aseguradora en Lima que ya vive en AWS, Braket es la forma más simple de comparar hardware de AQT, IonQ, IQM, QuEra y Rigetti con una sola factura. pytket es el compilador de circuitos de Quantinuum: importa circuitos de Qiskit u OpenQASM, los optimiza y los traduce a las compuertas nativas de cada equipo. Guppy, también de Quantinuum, es un lenguaje embebido en Python para programas con control clásico real, por ejemplo medir un cúbit a mitad del circuito y decidir según el resultado. Compila a HUGR, la representación intermedia abierta de Quantinuum.

Qrisp, hoy un proyecto de la Eclipse Foundation con licencia EPL-2.0, trabaja con variables cuánticas tipadas, reserva y libera cúbits por ti y corre en cualquier backend que acepte QASM. Qibo, con el Technology Innovation Institute de Abu Dabi como patrocinador principal, simula rápido en CPU y GPU y trae drivers para controlar hardware de laboratorio, útil para universidades que construyen sus propios cúbits.

¿Todavía se usa Q#?

Sí, y con desarrollo activo. Microsoft reconstruyó el Quantum Development Kit como código abierto en el repositorio microsoft/qdk, publicó la versión 1.32 en septiembre de 2026 y hoy lo distribuye como el paquete qdk de Python, con extras para Azure Quantum, Qiskit, Cirq y Jupyter.

A diferencia de Qiskit, Q# es un lenguaje con su propio compilador. Su mejor carta es el estimador de recursos, que te dice cuántos cúbits físicos y cuánto tiempo necesitaría un algoritmo en una computadora cuántica tolerante a fallos. Por Azure Quantum llega a IonQ, Pasqal, Quantinuum y Rigetti. El QDK también simula y compila OpenQASM, así que usarlo no obliga a escribir todo en Q#.

Elegimos Q# cuando hay que dimensionar un algoritmo tolerante a fallos, por ejemplo para estimar cuándo un tamaño de llave dejaría de ser seguro, o cuando el equipo ya trabaja con herramientas de Microsoft.

Un estado de Bell en Qiskit, Q# y OpenQASM 3

Un estado de Bell (dos cúbits entrelazados que siempre dan el mismo resultado) es el “hola mundo” cuántico. Corrimos los dos fragmentos con Qiskit 2.5.2 y qdk 1.32.3.

from qiskit import QuantumCircuit
from qiskit.primitives import StatevectorSampler

qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()

result = StatevectorSampler().run([qc], shots=1000).result()
print(result[0].data.meas.get_counts())  # mitad '00', mitad '11', aprox.

operation Main() : (Result, Result) {
    use (q1, q2) = (Qubit(), Qubit());
    H(q1);
    CNOT(q1, q2);
    let results = (M(q1), M(q2));
    ResetAll([q1, q2]);
    return results;
}

Si exportas el circuito de Qiskit con qiskit.qasm3.dumps obtienes esta versión en OpenQASM 3, legible para pytket, el QDK, Braket y casi cualquier herramienta:

OPENQASM 3.0;
include "stdgates.inc";
bit[2] meas;
qubit[2] q;
h q[0];
cx q[0], q[1];
barrier q[0], q[1];
meas[0] = measure q[0];
meas[1] = measure q[1];

Lenguajes fuera de Python

CUDA-Q es el único de este grupo que muchas empresas van a usar. Los demás son lenguajes de investigación o plataformas especializadas, rara vez la base de un proyecto empresarial.

CUDA-Q (versión 0.16.0, septiembre de 2026) es el modelo de programación de NVIDIA para aplicaciones híbridas en C++ y Python. Corre simuladores de vector de estado y de redes tensoriales en una o varias GPU y llega a hardware de una decena de fabricantes, entre ellos IonQ, Quantinuum, IQM, Pasqal y QuEra. Su compilador usa dialectos propios de MLIR, llamados Quake. Lo elegimos cuando manda la velocidad de simulación o un código de HPC existente, como en un centro de cómputo universitario en México o Brasil que ya tiene GPU.

Qmod, de Classiq, trabaja a un nivel más alto: describes qué debe hacer el algoritmo y el motor de Classiq sintetiza un circuito optimizado para tus restricciones de hardware. Es propietario. Silq, del SRI Lab de ETH Zúrich, es un lenguaje de investigación conocido por la descomputación automática segura. Quipper, embebido en Haskell, no publica versión desde la 0.9.0.0 de diciembre de 2019; lo tratamos como referencia académica.

En Julia, Yao.jl (Apache 2.0, todavía en beta según sus autores) sirve para simular y diseñar algoritmos. Bloqade, de QuEra, nació en Julia, pero el trabajo nuevo va al paquete bloqade de Python y Bloqade.jl queda estable, abierto a correcciones.

Recocido, átomos neutros y fotónica: ¿con qué se programan?

Con sus propios SDK: Ocean de D-Wave para recocido cuántico, Pulser y Bloqade para átomos neutros a nivel de pulsos o en modo analógico, y Perceval para fotónica. Strawberry Fields, la antigua biblioteca fotónica de Xanadu, está archivada desde el 16 de enero de 2026 y no la usamos en proyectos nuevos.

Ocean (9.5.0, septiembre de 2026) expresa problemas de optimización como modelos cuadráticos y los envía a los equipos de recocido de D-Wave o a sus solvers híbridos. Es la vía más directa para probar en hardware cuántico, por ejemplo, la programación de despachos de una empresa de logística en Bogotá. Pulser, de Pasqal, compone secuencias de pulsos para dispositivos de átomos neutros y sirve tanto para circuitos digitales como para simulación analógica. Perceval, de Quandela, arma circuitos de óptica lineal y los corre en los procesadores fotónicos de Quandela en su nube.

¿Qué son OpenQASM y QIR, y para qué sirven?

Son los dos formatos que evitan que un programa cuántico quede amarrado a un solo proveedor. OpenQASM es un lenguaje de texto legible para describir circuitos; QIR mete los programas cuánticos dentro de LLVM IR para que un compilador optimice junto el código cuántico y el clásico.

OpenQASM describe circuitos, control clásico, subrutinas y tiempos a nivel de pulsos; su especificación va en la versión 3.1. En la práctica, “exportar a OpenQASM e importar en otra herramienta” es como viajan los circuitos entre Qiskit, pytket, el QDK, Braket y Qrisp.

QIR lo mantiene la QIR Alliance. Su especificación define un Base Profile y un Adaptive Profile, y QIR 2.0 exige LLVM 16 o posterior. Casi nadie lo escribe a mano: aparece cuando Catalyst, el QDK u otro compilador baja tu programa a ese formato. La otra tendencia es MLIR, sobre el que están construidos Catalyst y CUDA-Q; HUGR cumple un papel parecido en el stack de Quantinuum.

Cómo elegimos el stack en AndesQubit

Partimos del problema y del hardware que podría correrlo, con el menor número de herramientas posible. La meta es un código que tus ingenieros puedan probar hoy en un portátil y llevar a otro proveedor mañana sin reescribirlo.

1. El problema no conoce el hardware. El modelo de negocio, los datos y el objetivo viven en Python sin importar ningún SDK. Solo un adaptador delgado sabe de Qiskit, CUDA-Q o Braket.
2. Formatos abiertos en las fronteras. Los circuitos pasan por OpenQASM 3 cuando cambian de herramienta, y preferimos cadenas que compilan a QIR cuando el control clásico importa.
3. Primero simuladores. Casi todo se desarrolla en simuladores de CPU o GPU con modelos de ruido; el hardware real pagado queda para calibrar y para los benchmarks finales.
4. Siempre una línea base clásica. Cada ruta cuántica corre al lado del mejor método clásico o de inspiración cuántica que podamos construir, y el benchmark decide qué pasa a producción.
5. Elegir para el equipo que se queda. Si tus ingenieros saben CUDA, nos inclinamos por CUDA-Q; si saben PyTorch, por PennyLane. El código tiene que sobrevivirnos.

En la práctica construimos sobre todo con Qiskit, PennyLane, CUDA-Q, Cirq y el SDK de Braket, y elegimos Q# para estimar recursos, Ocean para experimentos de recocido y Pulser o Bloqade para trabajo analógico con átomos neutros. Así se ve en un proyecto de desarrollo de software cuántico o en una prueba de concepto cuántica híbrida con alcance cerrado. AndesQubit está abriendo sus primeros proyectos por etapas, así que esto describe cómo trabajamos, no una lista de casos pasados.

Las bibliotecas de criptografía poscuántica son otra caja de herramientas

La criptografía poscuántica corre en los servidores y celulares que ya tienes, no en computadoras cuánticas, a través de bibliotecas normales que ahora implementan ML-KEM, ML-DSA y SLH-DSA, los estándares del NIST. Con ellas trabajamos cuando migramos cifrado.

OpenSSL 3.5, publicada el 8 de abril de 2025, agregó ML-KEM, ML-DSA y SLH-DSA y dejó el grupo híbrido X25519MLKEM768 como opción preferida por defecto para el intercambio de llaves en TLS. Es una versión LTS, con soporte hasta el 8 de abril de 2030. AWS-LC, que mantiene el equipo de criptografía de AWS, soporta ML-KEM y ML-DSA. BoringSSL, la bifurcación de Google, implementa ML-KEM-768 y ML-KEM-1024. Bouncy Castle ofrece ML-KEM, ML-DSA y SLH-DSA para Java y C#, con una distribución aparte certificada FIPS.

liboqs, del proyecto Open Quantum Safe dentro de la Post-Quantum Cryptography Alliance de la Linux Foundation, sirve para probar muchos algoritmos, incluso algunos que aún no son estándar. Su propio README advierte que no se use en producción ni para proteger datos sensibles, así que la usamos para prototipos y pruebas de interoperabilidad; el camino a producción pasa por las bibliotecas anteriores. El inventario y el despliegue están en nuestro servicio de migración a criptografía poscuántica.