Jira Is Turing-Complete
seriot.chJira is popular and has good API wrappers for your favorite language. I'm surprised corporate programmers with the hacker spirit haven't automated most of the things they are asked to do in Jira with Python command line scripts or whatever.
If you can make Jira an order of magnitude easier to use for yourself than for the people pushing it, suddenly the script flips and Jira is something you push to protect yourself. I've used Jira to almost a malicious extent at times, and it's a great tool to cover your ass. If you ever get in trouble for something you just point out "this was all made clear in the hundreds of Jira updates I've written, you've been reading those, right?". What are they going to do? Ask you to use Jira less?
We have AI now. Hook it all together with a custom script and have the AI do all the Jira crap for you.
Quite a few have, the issue is that every Jira instance is a fractal shit snowflake of custom properties several layers deep through old failed migrations to new organization strategies.
And many times the API can do stuff that the UI doesn't allow, and everyone's relying on the UI to drive things, so you end up in weirdly broken corners because you didn't notice that you need custom_field_5537 to be paired with custom_field_442 or it doesn't appear on anyone else's dashboard. Also it claims custom_field_10995 is an integer type field, and returns as integers in the XML, but there's a pile of undocumented magic constant strings that you have to use instead when creating (but not updating!) a task or you get useless error messages. The web UI doesn't do this though (it's just integers in html and the request), and only 80% of the strings match the display text in the dropdown.
Automating Jira is the absolute worst programming experience I've ever had. I can completely believe that simpler setups exist and they're probably quite easy, but omfg.
Sadly it's still completely worth the effort. Highly recommended.
A dysfunctional organization will project its failures to everything it touches. I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process. Nowadays, I opt in for Atlassian because it works fine out of the box, I avoid heavy customization (which would mean tool lock-in), and Claude can move the tickets itself anyway - no scripting required.
A colleague of mine said it even better, its like an old blanket filled with patches, small fixes and workarounds, so much that no one even remembers to how the patching was done ages ago!
Simpler setup is perhaps - have a the pm-informed list of req of what your teams' needs and habits, and implement from scratch. Perhaps would take less than customizing JIRA. With history and all.
Sure, just gather all requirements upfront and hope they never change. Customers know what they want /s
If it was about the ticket system, it'd be solved already. But it isn't.
Yeah I had the exact same experience. What values does `custom_field_836` need when creating an issue? It seems to be required in the API but not in the UI, and feeding a value returned from an existing issue doesn't work!
It's the API equivalent of formatting a document in MS Word.
> Quite a few have, the issue is that every Jira instance is a fractal shit snowflake of custom properties several layers deep through old failed migrations to new organization strategies.
This is key, Jira is fantastic so long as you have an angry commissar enforcing discipline, otherwise its a total free for all wasteland.
I just had a thought: is there some API so obscenely baroque and painful to use that even AIs would flatly refuse to work with them?
It would be an interesting exercise to keep feeding a coding agent ever crazier interface designs until it cracks.
“The base64 of the rot13 encrypted EBCDIC string has to be included in a JSON in the XML SOAP request, but both the JSON and XML escaping is manual and incorrect...”
"...but first split the string into chunks no bigger than 64 bytes and spread the request amongst HTTP headers instead of the POST body. Reassemble by trying every possible ordering until one passes the decoding steps."
AIs can barely handle PKCE OAuth flow. It’s not very hard to confuse them.
Sounds like the IOCCC[0] of APIs
[0] https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod...
>I just had a thought: is there some API so obscenely baroque and painful to use that even AIs would flatly refuse to work with them?
Copilot Studio. It's painful to try to set up any sort of logic within Copilot Studio. Worse if you're not on the most bleed-edging-new machine with overkill levels of ram. So I had a thought... why am I doing this when I have Claude with absolutely no quotas?
Turns out, there's just no way to drive it from Claude. It first started with the pac command line tool, but that's agonizingly broken. Tried to use Chrome next, but even it can't navigate that UI from the browser (neither could I, you'd click and sometimes the response occurs 10 seconds later). Copilot Studio is the quintessential Microsoft technology. Shortly after, Claude began experiencing what I can only call schizophrenic symptoms. It imagined that every time I queried it that there were embedded hacking attempts in my reply and that soon spread to every conversation I had with it even in new chats.
It is kind of ironic that the AI building tool is so hostile to AI. Copilot studio really is a hot mess, at least for me.
I am not using JIRA anymore but I guess in 2026 you could write AI wrapper around clicking on UI elements?
> I'm surprised corporate programmers with the hacker spirit haven't automated most of the things they are asked to do in Jira with Python command line scripts or whatever.
Not a single of the many organisations that I worked for which used JIRA would give the credentials to do anything of this sort.
nowadays you can vibecode some half-ass headless browser automation using your email-password or even weird corporate sso.
Our main problem is only that they are hijacking the prices incredibly.. Lately we had to cut the number of licences and users, since it was incredibly expensive.
I particularly like the hike between 10 users and 11, some startups begin with 5 people and when they reach more than 10 employees they are hit with the licence costs
moved to Jetbrains YouTrack many many years ago, and this is what we do via its APIs. It's quite versatile. With AI, it unlocked it even more.
Our entire company is basically ran through Jira. Most processes rely on Jira and certain transitions fire of webhooks for automation.
One of the first things we did when we got access to AI was make a Jira MCP. I try not to touch Jira anymore. I get Claude to just create the Jira issues, write comments, create subtasks, link issues together, etc.
I used to dread having to investigate how to implement something and break it down into tasks because the more granular I broke things down, the more Jira issues I had to create to capture each task. Now I can just write everything up in a file and send an LLM to do all the Jira crap.
This sounds so dystopian. I mean of course it does, we are talking about Jira here, an Atlassian product. But what I mean is the constant plastering over. This is how Jira became so astonishingly bad in the first place. But imagine people plastering over these idiotic tools, Jira, Slack, Confluence with LLMs. And at some point in the future someone gets fed up with having to instruct the LLMs and writes their own tool on top of the LLM, that you use to use Jira. And the stack of crutches continues to grow endlessly, just because some suits have heard some pseudo wisdom at some point in their lives that rewrites are expensive. Well guess what's even more expensive than rewrites ... the mindset to never rewrite. This one will literally destroy the fucking planet with ever higher compute demand and requirement.
> Hook it all together with a custom script and have the AI do all the Jira crap for you.
As if the bloat on Jira isn't big enough already. Adding more text will make it even slower since it will somehow automatically run everything over all that text all the time. If you need heating at your company, use Jira.
See, it goes perfectly together with using Jira through LLMs. LLMs also need more time the fuller their context window is.
> I'm surprised corporate programmers with the hacker spirit haven't automated most of the things they are asked to do in Jira with Python command line scripts or whatever.
That's because corporate IT makes the tokens expire every 2 seconds so scripting becomes useless.
Seriously we have some tokens that expire every 1 hour.
You have the script auto-renew the token. It's in the spec.
I can see very naive points here:
* "Corporate hackers" is a... not a very common thing. In the corporate world most programmers do what they are told to do and nothing more. Initiative is punishable.
* API wrappers aren't actually good. Not to mention that the API itself is very poor. JIRA has a tradition of arbitrary changing things, especially removing things, or not exposing the useful functionality. It's not a well-designed or well-executed product.
* AI is too immature and too non-deterministic to be useful for most of the things you want from a bug tracker. Also, for most companies, it's going to be too expensive to do it this way.
* QA is usually an afterthought, unless... we are talking about budget cuts and cutting corners, then it's left, right and center. Most companies see QA as a liability. They don't see it as producing value. They just have to pretend to have QA so that they can tell their customer they have it. When it comes to making QA do meaningful things, that require hiring good engineers, allocating development time, allocating compute resources... well, good luck with all that! Most QA I've seen, especially in international huge corporations was all for show, to produce appearance of work while following the same, mostly useless and mostly manual process.
I had a bunch of ideas about how QA can be made more efficient, both in terms of resource use and in terms of problem space it tries to address. Doing things like RCA automation or exploratory dynamic* testing... and after trying to see if any of such ideas would have any luck of becoming an actual successful product, I realized that nobody wants to improve QA. If a product made the "certification" (the ability to claim to have tested the product) cheaper, then it could be viable... but this is neither the direction I wanted to go, nor is it really all that feasible to improve a bug tracker in this direction.
----
* What I mean by exploratory testing is a sort of "fuzzing", however one that's more structured. Fuzzing, typically, is applied to the input, which then tries to explore all possible ways through the program under test. Exploratory testing is a test made up of modules that can be combined to produce longer tests. This addresses the problem of difficult to reach "corner" cases in the program, also the problem of reaching code paths that aren't directly (or at all) dependent on input.
> corporate programmers with the hacker spirit
that thing does not exists
I came back to a workplace, that still used JIRA. Obviously during the interview I was like oh JIRA yeah yeah yeah you still use that? I can use that.
Anyway yes, I can use JIRA. But it was a real shock to see the latest version of JIRA. It has a thousand papercuts, one of the worst is double clicking on text select stuff suddenly kicks fields into editor mode.
What I was remembering was JIRA Server 4.0, you can walk down memory lane here* - zoom in enough and you'll see each issue has a title, type, fix version, affects version, and so on, and then you end up going straight to the comments. Very straightforward.
* https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
About the double click into edit mode: Yes!! So much this! So annoying. Even basic text stuff they get wrong! But you know what a project manager told me ... They _like_ that, because they never use double click drag to select whole words ... ugh. Like always more proficient computer users are dragged down by the convenience for people barely able to use a computer.
> Obviously during the interview I was like oh JIRA yeah yeah yeah you still use that? I can use that.
Hold up, did I miss something? Fall into a time hole? Why are we talking about Jira like it’s Visicalc? Not currently working for an IT company, so maybe I missed something cataclysmic in the past two years…
My day job doesn't require using Jira or similar tools any more, so from a perspective of genuine curiosity: what's the consensus among entire project teams (not just the nerds) for a better alternative?
Linear
That version of JIRA could still easily be configured to be awful. That's the main problem with JIRA - the power to actually configure it to be sane is always reserved by a few people who don't want to bother, don't have time and don't care because they aren't really using it every day.
Well one of the problems anyway. It's also unimaginably slow, and has weird limitations like issues can't be parents of other issues.
The non-existence or non-availability of recursive features, like an issue being parent of an issue, or in Slack a thread being started inside a thread and so on, to me usually indicates, that the developers of the tool are afraid of recursion, and have never learned how to implement this easily in a database, used a programming language that easily deals with recursion, and don't know how to deal with it in other languages. They tend to think "it's too complicated". It's usually just a silly lazy excuse, but here we are, with tons of inflexible shitty tools.
Alternatively, it is a conscious decision to help prevent users from causing complicated situations.
Given a highly configurable system, users will find ways to (unintentionally) tie it into knots, so adding some guardrails can help reduce complexity demons down the line (both in the technical implementation and the user experience).
I guess I prefer to give people making things the benefit of the doubt.
Jira is completely awful and thus has the potential to take on any other form of awfulness.
Or is it Awfully-Complete? :)
Jira is the ultimate example of the concept of alienation. If Marx knew about Atlassian the Grundrisse would have been insanely lit.
The worst part is that every company with a tasks product works right towards Jira. Compare what GitHub issues were in 2014 to what they are today: https://github.com/features/issues
and they keep. adding. redundant. features
The engineer is not the target user
> The engineer is not the target user
yes, but:
1. not anymore
2. That's the price you have to pay if you want the tool you like to have corporate buy-in
Jira is the best way to destroy morale.
Woof. JIRA is so slow, and managers never seemed to set it up correctly. I have trauma from using it!
You see, it's not the tool's fault. There is simply no one on this planet, who can set up the tool correctly... Surely we cannot hold the tool responsible for human incompetence. For whom it is built then, you ask? Well, that's an entirely different question, that shall not be discussed at this point.
All workflow and orchestration engines are Turing complete, the whole purpose is to automate execution flows.
How many of them can run infinitely? Or be re-triggered by humans to continue where they left off?
Depends on how you code the workflow and transition state triggers.
I don't think so. First, JIRA is not orchestration. Second, all workflow needs to do is associate some status with external information, and make it easy to manipulate those. You need triggers and rules, some thing like infinite counters, two stacks, a bidirectional tape, etc.
Prove me wrong!
Yes, and the rules engine is there when creating custom workflows.
https://developer.atlassian.com/server/jira/platform/creatin...
I also explicitly mentioned workflows on my comment.
You implied all workflows, not just Jira.
And I stand by it, naturally it depends on the specific workflow engine how those features are exposed.
Then we can split hairs about which one don't really support it, so that you want win Internet discussions about all not being all.
Well, you did say all. Is there a minimal set of exposed features that must be exposed for a workflow engine to be included?
That explains why it's impossible to tell whether any given Jira operation is going to halt or not.
Underrated comment this !
Does that count as "you can play Doom on Jira"? Does Jira supply the pump action shotgun required to kill the resulting demons?
I love Jira automations. Whenever I start on a new team using Jira, I go in and set up automations that do things like auto-count the subtask story points to fill the parent task's story points, or automatically move tickets to backlog if they don't have fully refined properties (missing user assignment, missing story points, missing priority, missing description, etc). In one sprint the team has a more organized board. Dunno why they're not the defaults, but easy enough to fix with automations.
Why would tickets need to have a user assignment to be considered refined? It should be up to whomever picks it to work to get assigned to, not a part of the refinement.
I think at least 60% companies that use Jira could do better with just Trello. I dont know how it is possible to create such a horrible mess with task manager and some reports. But it probably keeps the managers and POs bussy so :D
I'm sure Atlassian knows this as well. When you setup a basic Kanban board in Jira, it is basically a Trello board. It is offered as one of the default options.
I was actually surprised they offered such simple options. Of course the complexity is there, the moment you start wanting an extra column, you're in the rabbit hole.
This is true because Trello uses simplicity as a constraint, so users can't make quite as big a mess. They can still make a mess though and as a source of truth it still requires people to move things properly, so it isn't really any better. All project tracking applications suffer from the same ultimate root cause of problems: users.
Not surprising if you've worked with their automation flows in-depth before. What's surprising is how awful their automation flow tools are to work with. Feels like programming in assembly to accomplish what you want.
What annoys me about Atlassian products (Jira, Confluence) is the long load times and terrible layout shifts:
you never know if the layout is about to shift ever so slightly more causing another in a series of misclicks.
Oh how many times I've accidentally assigned a newly created ticket to some poor fella I'd never even seen before...
Can't wait to run DOOM on it
Even more nauseating than https://brainfuck.org
in before every project manager on planet earth makes a "guess we don't need you devs anymore haha" joke during morning standup
Any good alternatives to Jira, locally hosted without a huge licence cost?
https://www.openproject.org/blog/open-source-jira-alternativ...
I haven‘t used it myself, though
Redmine, maybe? With or without Redmine X.
Honestly the best issue tracker I've used so far is Phabricator (now Phorge). It would be a bit weird to use it just for issues though, and tbh I'm not sure I would recommend it as a forge because it has approximately no CI support.
please reply to this comment with a link once they implement Doom in Jira
it's actually easy to be turing complete. it's a feat for a system to be non-turing complete and be "complex".
When would it be better to write software as Jira state transitions, instead of using python (with its large software ecosystem) or Rust or Go (type safety, etc)?
But can it?
Oh no, that means someone will port Doom to run on Jira.
It can’t be because in order to administer Turing test the system has to be usable straight away. This system requires extensive training and specific knowledge and steps for that.
The Turing test is to test whether a programme exhibits intelligence.
Turning complete is a measure of whether something can be used as a programming language to run as a universal Turing machine.
Jira is the one product I feel needs to be AI native.
AI native in the sense that it papers over the pain points.
New JIRA admin? AI will set it up to do what you want (after all, Atlassian has a great training set as they can see which Cloud installs work well)
Need to set up a workflow? Bam, AI to do that.
Need to onboard a user or manage permissions? Again, have a chatbot to do it (as a time-to-time Jira standin Admin, changing permissions always needs doing in 2+ places and devolves into a "Can you see this yet?" round of questions)
Jira has an AI feature called Rovo. It's terrible.
Giving an API key to Claude however gets you exactly what you need. Albeit in quite a risky way though.
Russain roulette.
Definitely, that's the issue with legacy tools and just plugging AI agents on top of existing API capabilities that were designed for human in the first place. Retrofitting agent-safety onto APIs that predate agents is harder than it looks (guardrails, permissions scopes etc.)
Disclosure: I'm CTO of an ITSM product in this space (Siit), so I think about this a lot.