Jira es Turing-completo: prueba formal con máquina de Minsky

⏱️ Lectura: 12 min

Nicolas Seriot publicó esta semana algo que cada equipo de software ha sospechado en silencio: Jira no es solo un sistema de tickets, es un lenguaje de programación. Su prueba no es una broma sobre product managers que diseñan workflows imposibles, sino una reducción formal de Atlassian Automation a una máquina de Minsky de dos contadores, modelo que Marvin Minsky demostró Turing-completo en 1967.

📑 En este artículo

1. TL;DR
2. Qué pasó
3. La máquina de Minsky en 60 segundos
4. La traducción a Jira: el mapeo
5. Sumar 2 + 3 dentro de Jira
6. Fibonacci en tres estados
7. ¿Y los límites finitos de Jira Cloud?
8. Por qué esto importa para los desarrolladores
9. Implicaciones para LATAM y gobierno de plataforma
10. Preguntas frecuentes
    1. ¿Esto significa que Jira es un buen lenguaje de programación?
    2. ¿Sirve esto para algo más allá de un meme técnico?
    3. ¿La construcción funciona en cualquier instancia de Jira?
    4. ¿Qué pasa cuando la cadena de Automation alcanza el límite de 10 triggers?
    5. ¿Hay riesgo real de explotación por esto?
    6. ¿Otras herramientas SaaS son Turing-completas también?
11. Referencias

La consecuencia es directa: cualquier función computable puede ejecutarse dentro de Jira usando Bugs y Tasks vinculados como registros y el estado de un Epic como contador de programa. El folclore de ingeniería se volvió teorema, con una instancia funcionando sobre un *.atlassian.net real.

TL;DR

• Nicolas Seriot publicó el 22 de mayo de 2026 una prueba formal de que Jira es Turing-completo vía reducción a máquina de Minsky.
• La reducción usa conteos de Bugs y Tasks vinculados como registros, y el status de un Epic como contador de programa.
• Las reglas de Automation implementan INC, DEC y branching condicional usando JQL como guarda.
• El autor demuestra suma (2+3=5) con un Epic, 5 issues vinculados y dos reglas de Automation.
• Fibonacci se reduce a tres estados usando Convert Issue Type (Bug → Task → Story) como atajo.
• Las cuotas finitas de Jira Cloud no refutan la construcción: ninguna computadora física es infinita.
• El límite de chain-depth de 10 triggers se sortea con un re-disparo manual; en Jira Data Center es configurable.

Qué pasó

El 22 de mayo de 2026, Nicolas Seriot, ingeniero suizo conocido por sus análisis técnicos rigurosos, publicó en seriot.ch una entrada titulada Jira is Turing-Complete. El texto cierra una vieja discusión de café entre desarrolladores: la sospecha de que Jira, la herramienta de gestión de proyectos de Atlassian, esconde un motor de cómputo de propósito general.

La afirmación no es nueva. Existía como meme técnico durante años, pero nadie había exhibido la reducción explícita. Seriot la aporta, con instrucciones de configuración, capturas de pantalla del workflow y trazas de ejecución sobre una instancia real de Jira Cloud. La prueba se sostiene porque demuestra que Atlassian Automation puede simular una máquina de Minsky, y Minsky probó en 1967 que ese modelo de dos contadores es Turing-completo.

💭 Clave: “Turing-completo” no significa “útil” ni “ergonómico”. Significa que el sistema puede, en principio, computar cualquier función que una máquina de Turing pueda computar. Es el listón más bajo de capacidad de cómputo general, no el más alto.

La máquina de Minsky en 60 segundos

Marvin Minsky introdujo en 1967 un modelo de cómputo extremadamente minimalista: dos registros que guardan números naturales sin cota superior, y un programa finito de instrucciones etiquetadas. Solo existen dos operaciones:

INC r; goto S
DEC r; if r == 0 goto S else goto S'

Es decir: incrementar un registro y saltar a un estado, o decrementar un registro y saltar a un estado distinto dependiendo de si el registro quedó en cero. Con eso es suficiente. Cualquier programa que una máquina de Turing puede ejecutar, una máquina de Minsky también, posiblemente con un número distinto de pasos. La elegancia del modelo es que reduce el cómputo a la operación más primitiva imaginable: incrementar, decrementar, ramificar.

Sumar A + B en una máquina de Minsky se ve así:

1. DEC A; if A == 0 goto 3 else goto 2
2. INC B; goto 1
3. HALT

Esto vacía el registro A transfiriendo cada unidad a B. Cuando A llega a cero, B contiene la suma original. Esa es la herramienta matemática que Seriot va a traducir.

La traducción a Jira: el mapeo

Aquí está el núcleo del paper. Seriot define una correspondencia uno a uno entre los componentes de una máquina de Minsky y los objetos primitivos de Jira:

• Registro A → cantidad de issues vinculados de tipo Bug.
• Registro B → cantidad de issues vinculados de tipo Task.
• Contador de programa → status del Epic principal.
• Tabla de despacho → reglas de Jira Automation, una por estado.
• Reloj → transiciones disparadas por Automation; cuando se agota la cadena, el operador re-dispara.

El status del Epic codifica la instrucción actual. Las reglas de Automation inspeccionan los conteos de issues vinculados con JQL y deciden la próxima transición. INC y DEC se materializan como creación y eliminación de issues vinculados del tipo correspondiente. El branching condicional se resuelve con una condición JQL en la regla.

💡 Tip: Si tu workflow de Jira ya tiene reglas que crean issues hijos al cambiar de estado, técnicamente estás escribiendo instrucciones INC en una máquina de Minsky disfrazada. Solo te falta una rama DEC para entrar en territorio Turing-completo.

Sumar 2 + 3 dentro de Jira

La implementación mínima requiere un Epic, cinco issues vinculados y dos reglas de Automation. Seriot la describe paso a paso:

1. Crear un workflow con los estados BACKLOG, TODO, DEV y PROD, todos interconectables.
2. Crear el Epic en estado BACKLOG.
3. Configurar la regla para TODO: si hay al menos un Bug vinculado, eliminar uno y transicionar a DEV; si no, transicionar a PROD (halt).
4. Configurar la regla para DEV: crear una nueva Task vinculada al Epic y transicionar a TODO.
5. Vincular 2 Bugs (A=2) y 3 Tasks (B=3) al Epic.
6. Transicionar el Epic a TODO para arrancar la cascada.

Ambas reglas tienen activada la opción Allow rule to trigger other rules. Sin eso, no hay cascada. La traza de ejecución que reportó Seriot sobre una instancia real es esta:

(2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD

El Epic aterriza en PROD con 0 Bugs y 5 Tasks vinculados. Es decir: 2 + 3 = 5. Calculado por Jira, sin código humano, solo configuración de Automation. El diagrama de estados completo:

graph LR
 S([Start]) --> BL[BACKLOG]
 BL --> TD[TODO]
 TD -->|"A mayor a 0, DEC A"| DV[DEV]
 TD -->|"A igual a 0, HALT"| PR[PROD]
 DV -->|"INC B"| TD
 PR --> H([Halt])

Fibonacci en tres estados

La reducción a suma ya basta para probar Turing-completitud, pero Seriot sube la apuesta. Jira tiene una operación nativa llamada Convert Issue Type que transforma un Bug en Task, una Task en Story, etc., de forma instantánea y sin perder vínculos.

Esa operación no agrega poder computacional (es expresable como DEC seguido de INC), pero reduce drásticamente el tamaño de la tabla de despacho. Eso permite implementar Fibonacci en solo tres estados con tres registros: A = Bug, B = Task, C = Story.

TODO:
  if exists linked Task:
    CONVERT Task → Story
    INC Bug
    goto TODO
  else:
    goto QA

QA:
  if exists linked Bug:
    CONVERT Bug → Task
    goto QA
  else:
    goto DEV

DEV:
  if exists linked Story:
    CONVERT Story → Bug
    goto DEV
  else:
    goto TODO

Con condiciones iniciales A=1, B=1, C=0, el conteo de Tasks recorre la sucesión 1, 1, 2, 3, 5, 8, 13… A diferencia del sumador, esta máquina no tiene estado de halt: corre hasta que Jira Cloud golpea el tope de profundidad de cadenas. El operador entonces dispara manualmente otra transición y el cómputo continúa.

¿Y los límites finitos de Jira Cloud?

Aquí entra el argumento más interesante del paper, porque es donde la mayoría de la gente quiere objetar. Jira Cloud impone cuotas reales: cada cadena de automatización se corta a 10 triggers, hay límites de issues por proyecto, de reglas activas y de ejecuciones mensuales por organización.

Seriot responde con un punto que ya es clásico en teoría de la computabilidad: ninguna computadora física es infinita. Tu MacBook tiene 16 GB de RAM y aún así decimos que C, Python o Rust son Turing-completos. La definición habla del modelo abstracto del lenguaje, no de la implementación concreta corriendo en una máquina con memoria finita.

📌 Nota: Jira Data Center expone propiedades configurables como automation.rule.execution.timeout, lo que permite ajustar las cuotas. Pero ni siquiera eso es necesario para sostener la prueba: basta con que el modelo permita, en principio, ejecutar la máquina dada memoria suficiente.

Bajo esa convención estándar, Jira es Turing-completo. Punto.

Por qué esto importa para los desarrolladores

Es tentador leer este artículo como una curiosidad académica, pero hay implicaciones prácticas serias para cualquier equipo que use Jira de forma intensiva en su día a día.

Primero: si Jira Automation es Turing-completo, entonces verificar formalmente que una regla nueva no rompe el sistema es indecidible en el caso general. El problema de la detención (¿esta regla termina?) no tiene solución algorítmica general. En la práctica esto se materializa en bugs reales: reglas que se disparan en cascada infinita, automatizaciones que crean miles de issues en minutos, cuentas de Atlassian suspendidas por consumo desbocado.

Segundo: cualquier sistema configurable lo suficientemente expresivo termina convirtiéndose en lenguaje de programación. Es la Ley de Greenspun en versión SaaS. Cuando un equipo construye una herramienta para automatizar tareas simples y le agrega condicionales, loops y composición, lo que obtiene es un lenguaje. Mal documentado, sin debugger, sin tipos, sin tests, pero lenguaje al fin.

Tercero: la consecuencia de seguridad. Si un usuario con permisos limitados puede configurar reglas de Automation, en principio puede ejecutar cómputo arbitrario sobre la base de datos de Jira. Eso no es necesariamente un agujero (las reglas operan dentro del modelo de permisos), pero amplía la superficie de auditoría más allá del código fuente del proyecto.

Implicaciones para LATAM y gobierno de plataforma

En empresas latinoamericanas que estandarizan Jira como única plataforma de gestión —algo común en banca, gobierno y telcos— este resultado debería disparar revisiones de gobernanza. No es exagerado: si tu equipo de Operaciones tiene permiso para crear reglas de Automation, ese equipo tiene acceso a un entorno de programación dentro de la plataforma. Sin code review, sin pipeline de CI, sin tests automatizados.

El control mínimo razonable es tratar las reglas de Automation como código: revisión en pull request del export JSON de las reglas, ambiente de staging separado del de producción, alertas sobre cascadas profundas y monitoreo de consumo de operaciones. Algunos equipos en la región ya lo hacen para terraform o SSO; las reglas de Jira merecen el mismo trato.

El otro frente es de costos. Atlassian factura por ejecuciones de Automation en planes superiores. Una regla mal diseñada que entra en cascada puede generar facturas inesperadas en ciclos de cierre mensual. El paper de Seriot debería servir de recordatorio explícito de que cualquier regla de Automation, en el caso general, podría no terminar.

⚠️ Ojo: Si tu organización audita configuraciones de infraestructura como código pero deja las reglas de Jira fuera del alcance, tenés un punto ciego de gobernanza. Cualquiera con permiso de admin sobre un proyecto puede desplegar cómputo arbitrario sin pasar por ningún pipeline.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Esto significa que Jira es un buen lenguaje de programación?

No. Turing-completo no es un cumplido sobre ergonomía. PowerPoint también es Turing-completo (Tom Wildenhain, 2017) y nadie sugiere reescribir su backend en slides. La prueba habla de capacidad teórica, no de utilidad práctica.

¿Sirve esto para algo más allá de un meme técnico?

Sí. Implica que verificar formalmente que un conjunto de reglas de Automation termina es indecidible en el caso general, lo que tiene impacto directo en gobernanza, seguridad y costos. También es un argumento sólido para tratar la configuración de Automation como código versionado y revisado.

¿La construcción funciona en cualquier instancia de Jira?

Seriot la verificó sobre una instancia *.atlassian.net (Jira Cloud) en mayo de 2026. La mecánica básica (Automation, JQL, creación y borrado de issues, conversión de tipo) está disponible en planes Premium y Enterprise. En el plan gratuito hay cuotas más agresivas que dificultan llegar a cascadas profundas, pero el modelo aplica igual.

¿Qué pasa cuando la cadena de Automation alcanza el límite de 10 triggers?

El cómputo se pausa. El operador humano debe re-disparar manualmente el Epic (por ejemplo cambiándole el estado) para que la cascada continúe. Seriot lo llama “el humano suministra el siguiente tick de reloj”. La reducción matemática se mantiene; solo cambia quién provee la energía del cómputo.

¿Hay riesgo real de explotación por esto?

En sí, no. La construcción opera dentro del modelo de permisos de Jira; un usuario sin acceso a Automation no puede explotarlo. Pero sí es un recordatorio de que delegar capacidad de configuración avanzada equivale a delegar capacidad de programación. Eso debería reflejarse en auditorías SOC 2 y revisiones de seguridad internas.

¿Otras herramientas SaaS son Turing-completas también?

Probablemente muchas. Excel con LAMBDA (introducido en 2021) lo es. Notion con bases de datos relacionales y fórmulas se acerca peligrosamente. Cualquier herramienta de no-code suficientemente expresiva acaba en el mismo lugar. La paradoja es que más expresividad significa más casos donde no podés verificar nada formalmente.

Referencias

• Jira is Turing-Complete — Nicolas Seriot — Paper original con la construcción completa, capturas de pantalla y trazas de ejecución.
• Counter machine — Wikipedia — Definición formal del modelo de Minsky y su equivalencia con la máquina de Turing.
• Turing completeness — Wikipedia — Concepto general de Turing-completitud y ejemplos de sistemas inesperadamente Turing-completos.
• Atlassian Cloud Automation — Documentación oficial — Referencia de reglas, triggers y condiciones JQL en Automation.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.