Desarrollo de software cuántico

Un programa cuántico que cabe en el hardware de hoy suele ser corto, a veces unas decenas de líneas. Lo difícil del desarrollo de software cuántico está alrededor: el optimizador clásico que llama al circuito miles de veces, los datos que entran, las pruebas que te dicen si una respuesta con ruido es correcta y el camino desde un notebook hasta algo que tu equipo de operaciones pueda correr un martes a medianoche.

Ese código de alrededor es el que construimos. Lo escribimos para que tus ingenieros lo entiendan, lo prueben en simuladores y lo puedan apuntar a otro proveedor cuántico sin reescribirlo.

¿Cómo funciona un programa cuántico híbrido?

Un programa cuántico híbrido reparte el trabajo entre dos máquinas. Una computadora clásica prepara el problema, envía circuitos cortos a un procesador cuántico o a un simulador, lee las mediciones y decide qué probar después. El ciclo se repite miles de veces, y casi todo programa cuántico útil hoy funciona así.

Así funcionan los algoritmos variacionales como QAOA para optimización o VQE para química, y también la mayoría de experimentos de machine learning cuántico.

Pensemos en una empresa de distribución en Bogotá o Monterrey que quiere probar QAOA para asignar vehículos a rutas. El flujo tiene cinco piezas: un codificador que traduce los pedidos y la flota a un Hamiltoniano, el circuito parametrizado, una capa de ejecución que manda trabajos al simulador o a la nube y maneja colas, reintentos y número de disparos (shots), un optimizador clásico y una comparación contra el solver que la empresa ya usa, registrada en cada corrida.

Solo la segunda pieza es cuántica. Las otras cuatro son software normal, y son las que definen si el proyecto se puede mantener.

Frameworks para el desarrollo de software cuántico

Escogemos según el problema y el hardware. Más allá de eso no tenemos una preferencia fuerte.

Qiskit, el SDK abierto de IBM, tiene la comunidad más grande y el acceso más directo a los procesadores de IBM. En abril de 2025 pasó a la versión 2.0, que según el anuncio de IBM eliminó todo lo que se había marcado como obsoleto desde la 1.0, módulos enteros incluidos. Es un buen recordatorio de que las herramientas cuánticas todavía cambian rápido.

CUDA-Q, de NVIDIA, está hecho para programas híbridos que necesitan simulación acelerada en GPU o que viven junto a código de HPC. Si tu equipo ya trabaja con CUDA, encaja sin esfuerzo.

PennyLane, de Xanadu, trata los circuitos como funciones diferenciables y se conecta con PyTorch y JAX. Es nuestra opción habitual para machine learning cuántico.

Cirq, de Google, aparece mucho en código de investigación y da control fino sobre los circuitos y las restricciones de cada dispositivo.

El acceso a hardware real suele pasar por IBM Quantum Platform, Amazon Braket (con equipos de IonQ, IQM, Rigetti, QuEra y AQT) o Azure Quantum (con IonQ, Quantinuum, Rigetti y Pasqal), según los procesadores que quieras comparar.

¿Cómo evitar quedar amarrado a un proveedor?

Para evitar quedar amarrado a un proveedor cuántico, el código se separa en tres capas y solo una de ellas conoce el hardware: la definición del problema, el método expresado en circuitos y un adaptador de backend. Cambiar de fabricante o de simulador significa escribir otro adaptador y volver a correr los benchmarks, sin tocar lo demás.

Importa porque los fabricantes van a cambiar mucho antes de 2030. IBM planea su sistema tolerante a fallos Starling para 2029, y Google escribió en marzo de 2026 que espera computadoras cuánticas superconductoras comercialmente relevantes antes de que termine la década. El código pegado a la API actual de un solo proveedor envejece mal.

La primera capa es la definición del problema: tus datos, tu objetivo, tus restricciones. No sabe nada de cúbits. La segunda expresa el método en términos de circuitos u operadores. La tercera es un adaptador de backend, el único lugar que conoce un SDK, un dispositivo, una configuración del transpilador o una cuenta en la nube. Pasar de IBM a IonQ, o de un simulador en GPU a un equipo real, solo toca esta última capa.

Cuando ayuda, usamos formatos de intercambio como OpenQASM para que los circuitos pasen de una herramienta a otra.

¿Cómo se prueba el software cuántico?

El software cuántico se prueba en simuladores y en tres niveles, porque sus resultados son probabilísticos y una prueba no puede comparar una salida con un valor esperado y ya. Primero van pruebas exactas en instancias pequeñas, luego pruebas estadísticas con tolerancias y al final pruebas con modelos de ruido de los equipos objetivo.

El hardware real se usa poco, para calibrar y para los benchmarks finales. Casi todo el presupuesto de desarrollo se queda en tus propias CPU y GPU.

Integración con tu stack clásico y MLOps

El módulo cuántico se entrega como un paquete de Python o un contenedor con una interfaz documentada, y se versiona, registra y monitorea como cualquier otro modelo. Si usas MLflow, Kubeflow, Airflow o su equivalente en la nube, el trabajo híbrido se vuelve un paso más del pipeline, con el backend, los parámetros, los disparos y la comparación contra la línea base guardados en cada corrida.

Las credenciales de las cuentas cuánticas se quedan en tu gestor de secretos. Registramos el costo de cada corrida, porque en algunos proveedores el tiempo de hardware sube rápido.

Cuando lo clásico gana: la alternativa de inspiración cuántica

En muchos problemas, el resultado honesto de un proyecto es que por ahora gana un método clásico. Lo planeamos desde el principio.

Cada proyecto incluye una línea base clásica y, con frecuencia, una de inspiración cuántica: redes tensoriales, recocido simulado o parallel tempering en GPU, o solvers comerciales construidos con esas ideas. Estos algoritmos toman un truco de la física cuántica pero corren en hardware normal. A veces capturan buena parte de la mejora que buscabas y pueden salir a producción de inmediato. Hay empresas enteras construidas sobre esa idea: la española Multiverse Computing levantó 189 millones de euros en junio de 2025 para escalar CompactifAI, que usa redes tensoriales de inspiración cuántica para comprimir modelos de lenguaje.

El módulo cuántico queda en el repositorio con sus pruebas, listo para medirse de nuevo cuando llegue otra generación de hardware. Eso vale más que una diapositiva que diga “probamos cuántica en 2026”.

¿Cuándo tiene sentido contratar desarrollo de software cuántico?

Contratar desarrollo de software cuántico tiene sentido cuando ya tienes un problema concreto y evidencia de que tiene estructura aprovechable por un algoritmo cuántico, normalmente después de un descubrimiento de casos de uso o de una prueba de concepto. Sin esa evidencia, el riesgo es construir código de calidad de producción para un problema que no lo necesita.

Es un servicio de corto plazo, no de hoy mismo para todos. Si todavía no tienes esa evidencia, el paso previo es un descubrimiento de casos de uso cuánticos o una prueba de concepto híbrida.

También funciona bien si tienes ingenieros que quieren quedarse con el código. Trabajamos en pareja con ellos durante el desarrollo, y la formación en computación cuántica puede correr en paralelo.

Estamos abriendo proyectos por etapas. Si tienes un problema en mente, cuéntanos y te diremos si el desarrollo de software es el paso correcto o si conviene empezar por algo más pequeño.