¿Cómo se programa un computador cuántico hoy?

Estado al 26 de septiembre de 2026. Un computador cuántico se programa en Python corriente, desde un laptop, sin ser dueño de un solo qubit. Cuatro SDKs de código abierto dominan la pila pública — Qiskit, usado por el 69,1% de los desarrolladores encuestados, PennyLane (30,8%), Cirq (17,5%) y el Braket SDK de Amazon (12,1%), según la encuesta open-source 2025 de la Unitary Foundation con 1.400+ practicantes — y los cuatro tienen licencia Apache-2.0 (PyPI), instalación gratis y simulador gratis incluido. Lo que cuesta dinero es el minuto de hardware, no el software (nuestra guía de proveedores). Este es el mapa de Rosetta Quantum de la pila, capa por capa, con cada número de versión verificado hoy contra el registro público.

¿Qué significa en la práctica “programar un computador cuántico”?

Significa escribir un programa clásico que construye, compila y envía un circuito, y después lee miles de resultados de medición probabilísticos. Nada en el editor se ve exótico: es Python llamando a una librería. El ciclo es el mismo en todos los SDKs:

1. Construir. Describes un circuito — qubits más una secuencia de compuertas. En esta etapa es una estructura de datos, portable y neutral al vendor (OpenQASM 3 es el formato de intercambio común).
2. Transpilar. Un compilador reescribe tu circuito idealizado al set de compuertas nativas y al layout de qubits de un target concreto. Aquí vive la mayor parte de la ingeniería — ver el mapa de capas abajo.
3. Ejecutar. El circuito corre en un simulador (gratis, clásico — un statevector de n qubits guarda 2^n amplitudes, así que el costo se duplica por qubit agregado; nuestro explicador del qubit cubre el porqué) o en una QPU vía la API de runtime del vendor (facturada; mecánica de costos).
4. Medir. No recibes “la respuesta”: recibes shots — miles de corridas repetidas resumidas en un histograma, porque la medición es probabilística por física, no por bug.

Los circuitos dinámicos — bifurcar según una medición a mitad de circuito — son frontera actual, no default resuelto: Qiskit v2.5 (14 de julio de 2026) todavía lista como feature de cabecera exponer el control de flujo clásico (if/else, while, for) fuera de Python.

¿Qué SDKs existen y quién usa cuál?

Cuatro SDKs cubren casi todo el campo abierto, y la brecha entre el primero y el segundo es ancha. En la encuesta 2025 de la Unitary Foundation (997 encuestados respondieron esta pregunta; selección múltiple permitida) Qiskit lidera con 69,1%, PennyLane sigue con 30,8%, Cirq con 17,5%, CUDA-Q de NVIDIA con 16,2%, el Braket SDK con 12,1% y Q# de Microsoft con 8,3%. Dos motores de simulación rankean tan alto como los propios SDKs — Qiskit Aer con 47,7% y PennyLane Lightning con 17,3% (misma encuesta) — lo que dice dónde ocurre el trabajo diario: en simuladores clásicos, no en QPUs. Del lado de la nube gestionada, el 65,5% de 852 encuestados usa la IBM Quantum Platform.

Disciplina de lectura antes de citar estos números en cualquier parte: la encuesta muestrea a la comunidad open-source que responde encuestas, y las cuotas son de selección múltiple — no suman 100. El uso mide atención, no calidad. Ver “Qué no sabemos”.

¿Qué hace cada capa de la pila?

Todo SDK es la misma máquina de cuatro capas: una librería de circuitos arriba, un transpiler debajo, un runtime que habla con los backends, y el backend mismo. En 2026 el movimiento que vale la pena seguir está en las dos capas del medio.

El transpiler es donde ocurre la ingeniería. Qiskit v2.4 (20 de abril de 2026) hizo de gridsynth la síntesis RZ por defecto, que según IBM “produce T counts sustancialmente menores”; la v2.5 (14 de julio de 2026) agregó pipelines dedicados Clifford+T y de computación basada en Pauli, con benchmarks propios de IBM mostrando “algunas cargas compilando en aproximadamente la mitad del tiempo” de la v2.4. Ambas cifras son del vendor — no existe en el registro público un benchmark de compiladores cross-SDK independiente y pre-registrado que pudiéramos citar hoy.

El runtime es la puerta facturada al hardware. IBM renombró Qiskit Runtime Service a IBM Quantum Compute Service junto con la v2.5 — misma API, separación más clara entre el SDK abierto y el servicio pago. La frontera aquí es la latencia: Backline, anunciado por Xanadu y AMD el 10 de septiembre de 2026, es una suite open-source de PennyLane que apunta a lazos clásico-cuánticos “por debajo de 3 microsegundos” — cifra declarada por el vendor, y la que más importará cuando la corrección de errores corra dentro del lazo.

¿Qué se puede correr gratis y dónde empieza el cobro?

Todo hasta la QPU cuesta $0. Los cuatro SDKs son Apache-2.0 (PyPI) y cada uno incluye un simulador local que corre en tu propia máquina — la propia página de precios de AWS manda a los principiantes al “simulador local gratuito del Amazon Braket SDK” (AWS). En hardware gestionado, lo gratis se mide en minutos: el Open Plan de IBM incluye hasta 10 minutos de QPU por ventana móvil de 28 días, solo en la región us-east, y desde el 16 de marzo de 2026 los usuarios activos del Open Plan pueden optar por 180 minutos adicionales a lo largo de 12 meses; el Free Tier de AWS cubre 1 hora al mes de simulador on-demand durante los primeros 12 meses.

Pasado lo gratis, la QPU se factura por tarea más por shot, y la dispersión entre máquinas es la verdadera lección: en la propia página de precios de AWS, un job de 10.000 shots en el Cepheus de Rigetti cuesta $4,55 ($0,30 por tarea + $0,000425 por shot), mientras 2.500 shots en IonQ Forte con mitigación de errores cuestan $200,30 ($0,30 + $0,08 por shot, mínimo de 2.500 shots). Por qué esos números no son comparables entre vendors — unidades distintas, mínimos distintos — es el tema completo de nuestra guía de proveedores; la regla de la casa sigue en pie: un piloto que arranca en QPU está quemando presupuesto que no necesitaba quemar.

¿Cómo empezar sin casarse con un vendor?

Elige cualquiera de los cuatro y sostén dos disciplinas. Primero, circuitos portables: OpenQASM 3 y QIR existen precisamente para que un circuito sobreviva a su SDK, y el lock-in real son los créditos prepagos y los modelos de costo no transferibles, no el software. Segundo, abstracción delgada abajo: PennyLane trata los backends como plugins — un programa, muchos dispositivos — y desde el 24 de febrero de 2026 su capa de compilación también se conecta al Munich Quantum Toolkit, una pila de compilación académica. Y dota el equipo en consecuencia: el primer perfil que necesita un proyecto cuántico es un ingeniero de software junto a un baseline clásico de optimización fuerte, no un físico residente.

Qué no sabemos

• Si las cuotas de la encuesta generalizan. La encuesta de la UF muestrea una comunidad open-source autoseleccionada, reclutada en parte por los canales de los propios vendors de SDK; las cuotas multiselección no suman 100. El uso mide atención, no calidad.
• Qué transpiler gana de verdad. Las mejoras de tiempo de compilación y T counts de arriba son benchmarks del propio IBM; no hay en el registro público una comparación de compiladores cross-SDK independiente y pre-registrada que pudiéramos citar hoy.
• La capa cerrada. Las toolchains internas de los vendors son invisibles para una encuesta open-source; el registro público sobre su uso real es delgado.
• Si algo de esto mueve el marcador. Un SDK es un volante, no un motor: el conteo de advantaged solves del ledger de Rosetta sigue en 0 instales el que instales.
• Nuestro propio alcance. Rosetta Quantum no ha corrido en casa un benchmark cabeza a cabeza de SDKs; toda cifra de arriba viene del registro público enlazado.

Rosetta Quantum publica veredictos con datos crudos reproducibles. Esto es contenido educativo, no un claim de producto.