Jira Is Turing-Complete (And You've Been Coding in It)

You didn't realize it, but the last time you built a Jira workflow, you wrote a program. A bad one, probably — no version control, no tests, no linter — but a program nonetheless.

The Uncomfortable Truth About Jira

Jira started as a bug tracker. A humble list of things that were broken, assigned to people who would fix them. That was 2002. Fast-forward to today and Jira is a sprawling automation engine with conditional branching, state machines, persistent storage, and event-driven triggers. It has, without anyone really intending it to, crossed the threshold into Turing completeness.

This isn't a hot take for engagement. Nicolas Seriot actually explored this — demonstrating that Jira's workflow and automation system is expressive enough to simulate computation. And once you see it, you can't unsee it.

The implications are weird and worth unpacking.

What Turing Completeness Actually Means (Briefly)

A system is Turing complete if it can simulate any computation given enough time and memory. The classic examples are Rule 110, Conway's Game of Life, and — now, apparently — your company's sprint board.

The key ingredients: conditional logic, state that persists, and the ability to loop. Jira has all three:

Workflows are finite state machines. Statuses are states. Transitions are edges. Guards on transitions are conditionals.
Custom fields are persistent memory. You can read them, write them, and branch on their values.
Automations are event-driven triggers with branching logic, field updates, and the ability to create or modify issues — including triggering further automations.

That last point is the kicker. Automations can trigger automations. You have recursion. Or at least iteration. You're cooked.

You've Already Written Jira Programs

Here's a concrete example. Say you build a workflow where:

A ticket enters In Review
An automation checks a custom field review_pass_count (integer)
If it's less than 2, it increments the field and transitions the ticket back to In Progress with a comment
If it's 2 or more, it transitions to Done

That's a loop with a counter. That's a while loop. In Jira.

In pseudocode:

review_pass_count = 0

while review_pass_count < 2:
    status = "In Progress"
    review_pass_count += 1

status = "Done"

The Jira automation that implements this looks roughly like the following when exported as JSON (Jira Cloud lets you import/export automation rules as JSON):

{
  "trigger": {
    "type": "FIELD_VALUE_CHANGED",
    "configuration": {
      "fields": ["status"],
      "toStatus": "In Review"
    }
  },
  "conditions": [
    {
      "type": "ISSUE_FIELDS_CONDITION",
      "configuration": {
        "conditions": [
          {
            "field": "cf[10042]",
            "operator": "LESS_THAN",
            "value": "2"
          }
        ]
      }
    }
  ],
  "actions": [
    {
      "type": "EDIT_ISSUE",
      "configuration": {
        "fields": [
          {
            "fieldId": "cf[10042]",
            "value": "{{issue.cf[10042] + 1}}"
          }
        ]
      }
    },
    {
      "type": "TRANSITION_ISSUE",
      "configuration": {
        "transitionId": "11"
      }
    }
  ]
}

This is real. This works. You just programmed a loop in a project management tool.

The State Machine Is Already There

Workflows are the part of Jira most developers ignore because they're "an admin thing." They shouldn't be. A Jira workflow is literally a directed graph — statuses as nodes, transitions as edges. That's a state machine, which is the foundation of a huge portion of real software: parsers, network protocols, UI components, game logic.

Here's a simple TypeScript representation of what your Jira workflow actually is under the hood:

type Status = "Backlog" | "In Progress" | "In Review" | "Done" | "Blocked";

type Transition = {
  from: Status;
  to: Status;
  guard?: (fields: Record<string, unknown>) => boolean;
  action?: (fields: Record<string, unknown>) => Record<string, unknown>;
};

const workflowTransitions: Transition[] = [
  { from: "Backlog", to: "In Progress" },
  { from: "In Progress", to: "In Review" },
  {
    from: "In Review",
    to: "Done",
    guard: (fields) => Number(fields["review_pass_count"]) >= 2,
  },
  {
    from: "In Review",
    to: "In Progress",
    guard: (fields) => Number(fields["review_pass_count"]) < 2,
    action: (fields) => ({
      ...fields,
      review_pass_count: Number(fields["review_pass_count"]) + 1,
    }),
  },
  { from: "In Progress", to: "Blocked" },
  { from: "Blocked", to: "In Progress" },
];

function transition(
  current: Status,
  target: Status,
  fields: Record<string, unknown>
): { status: Status; fields: Record<string, unknown> } | null {
  const match = workflowTransitions.find(
    (t) =>
      t.from === current &&
      t.to === target &&
      (t.guard ? t.guard(fields) : true)
  );

  if (!match) return null;

  return {
    status: target,
    fields: match.action ? match.action(fields) : fields,
  };
}

This is exactly what Jira is doing internally. Your workflow configuration is this code. It's just stored in a database and executed by their engine instead of a JavaScript runtime.

So What Do We Do With This Information?

A few things, practically speaking:

1. Version control your Jira automations.
If you accept that automations are code, they deserve version control. Export automation JSON regularly and commit it to a repo. Yes, this is tedious. So is debugging a production automation that someone silently changed three months ago.

2. Document your workflow logic like you'd document code.
Workflow screens in Jira are visual but not readable. Screenshot them, export them, and write a README explaining the intent. Future-you (or a new teammate) will need it.

3. Resist the urge to build complex logic inside Jira.
Just because you can build a loop counter in Jira doesn't mean you should. If your automation JSON exceeds ~50 lines, consider whether a real webhook + a small serverless function is more maintainable. It almost certainly is. Use Jira for state, use code for logic.

4. Use the API to inspect what you've built.
Jira's REST API lets you pull workflow schemes and automation rules programmatically. If you're inheriting a Jira instance, this is how you audit it without clicking through 47 admin screens.

curl -u your@email.com:YOUR_API_TOKEN \
  -X GET \
  -H "Content-Type: application/json" \
  "https://your-domain.atlassian.net/rest/api/3/workflowscheme" \
  | jq '.[].name'

This returns the names of all workflow schemes in your instance. A starting point for understanding what kind of program you've accidentally inherited.

The Deeper Point

Jira being Turing complete isn't a party trick. It's a symptom of a broader pattern: the tools we use to manage software are becoming as complex as the software they manage. Notion has formulas. Airtable has scripts. GitHub Actions is clearly a programming language (a bad one). The line between "configuration" and "code" has dissolved.

This means two things. First, developers should stop delegating tool configuration entirely to project managers and admins — there is code in there, and it deserves engineering attention. Second, the next time someone asks why your sprint velocity is down, you can honestly say you've been debugging a distributed state machine with no observability tooling.

That's a real answer.

BLN Craft builds developer tools for people who want to ship faster and think more clearly about their systems. If that sounds like you, check out what we're working on at blncraft.com.

推荐订阅源

DEV Community