[Buttons840]

Jira 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.

[Groxx]

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.

[ivan_gammel]

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.

[vjvjvjvjghv]

“ 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”

I work in medical devices and our Jira is a mess too. Seems a lot of people try to solve process problems by customizing Jira.

[ivan_gammel]

„Every organization thinks that they are unique, yet they all are doing the same thing“ (a quote I heard last time from an SAP consultant, which is probably a common knowledge or some named law).

This is the funniest thing about customization of enterprise products. They spent hundreds of years on user research and product development, so chances are high that their standard solution is sufficient for your problem, and you don‘t need anything else. Yet too many people are tripping on the hard problem of enterprise products: the custom fields, which they hardly even need.

[l72]

I find the problem is that engineering wants one work flow, product wants another, another department wants theirs, and so on.

As a CTO I have declared that Jira is owned by engineering and it is our developers’ process.

[ivan_gammel]

Sounds… political. You have cross-functional teams interfacing via a tool. It would be reasonable to co-design this interface, so that all user goals are taken into account. When engineering owns the tool, do they approach the configuration of JIRA the same way as they build the product?

[l72]

We approach tickets that match with our development strategy. A ticket is tied to and represents a branch of code. When that code is merged the ticket is done. It cannot be reopened, you open a new ticket and link it and there will be a new branch.

I know everything that is in our main branch by looking at jira.

Product mangers and executives often want a very different view or workflow and it is hard to bend jira to work for everyone. Jira would need to have things like parallel workflows on a ticket and that would just get confusing and complicated.

[ivan_gammel]

> it is hard to bend jira to work for everyone

it is not, as long as focus is on goals rather than on solutions (applies to everything). Nobody needs a view or a workflow. Everybody has jobs to be done. That is the starting point in process design.

[IshKebab]

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.

[Groxx]

"Lemme just add +1 point to that task estimate..."

https://youtube.com/shorts/zLoGGJPF2sk

[jiggawatts]

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."

[wwalexander]

AIs can barely handle PKCE OAuth flow. It’s not very hard to confuse them.

[NoMoreNicksLeft]

>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.

[Atiscant]

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.

[irishcoffee]

I’ve been trying for the last few weeks to get a really solid local model workflow going, and every single tool I use feels hostile af, whereas the stuff work pays for, it all “just works” together. It really irritates me.

[borski]

Sounds like the IOCCC[0] of APIs

[0] https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod...

[lq9AJ8yrfs]

that's nearly a requirement for anti-bot things. turnstile etc.

[LazyGooze]

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!

[jdgoesmarching]

The funny thing is that Atlassian themselves uses “custom fields” so it’s not even clear which are actually org-specific. The new JSM uses a lot of them, for example. It smells like things got so convoluted internally that even first party features are just velcro’d on top.

[Devasta]

> 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.

[larodi]

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.

[stephbook]

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.

[karel-3d]

I am not using JIRA anymore but I guess in 2026 you could write AI wrapper around clicking on UI elements?

[dijit]

The Jira API is less fragile than this, you will still have to change major things to your script when someone adds a field.

[_boffin_]

Reminds me of automating FiServ in VBA. Omfg, but still worth it.

[homeonthemtn]

"fractal shit snowflake of custom properties several layers deep through old failed migrations to new organization strategies."

Couldn't have said it better

[consp]

> 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.

[zelphirkalt]

See, it goes perfectly together with using Jira through LLMs. LLMs also need more time the fuller their context window is.

[nickjj]

Yep, at a place I used to do work for I used their API to build a number of time saving things, all of which were tiny shell scripts.

Like adding a custom text field to each ticket with a human description of what a ticket did which someone would fill out along with a timestamp that got auto-filled out when a release shipped (deploy script). We'd release 1 ticket at a time as a line of work (many tickets per day). This combined with custom filters resulted in Jira providing us a human readable changelog for each board and the whole company. These messages were Slacked to the business so everyone had a pulse on what was going live. It was also a searchable audit log of all releases, tying back to a code change.

The deploy process also transitioned Jira tickets so a developer never had to do anything more than merge a ticket to main to have it get deployed and completed on Jira.

Lots of little scripts that automatically created tickets for routine tasks, etc..

It was super solid for years and I'm going to guess it's still running today. The naming conventions of the custom fields were lame but if your team is in control of setting up Jira, it wasn't hard to keep everything on the same page.

I started off not liking Jira and it had a lot of issues many years ago but it's actually not that bad nowadays once you set it up. I wouldn't choose it for my own company but as a developer and someone who has administrated it, used it as an end user and developed against it for internal tools, it mostly gets out of your way once it's configured and working.

[keithnz]

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.

[Philip-J-Fry]

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.

[zelphirkalt]

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.

[madduci]

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.

[wolfi1]

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

[crabbone]

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.

[chuckadams]

I've worked for a few Fortune 50 companies, and they all had "shadow IT" that would crank out scripts and tools with no official sanction to work around the cumbersomeness of the official tools (or sometimes their complete lack). That's what corporate hackers are.

[crabbone]

Well, where I work, "automation" is part of my job title. And if I ever even suggest that I've done some work outside of the tasks assigned to me that has something to do with my job, I'd be sent into disciplinary hearing. Any work I do for the company must be sanctioned by my boss, otherwise it's treated as dereliction of duty (under the pretext, that I should've been using that time to work on my tasks given me by my boss, or, if I had no such tasks, I should've informed my boss about the situation).

And, in my specific case, my boss is not very good at programming, and doesn't like anything I do on that count. So, anything I've done so far was mired in pointless PR reviews and discussions, stalled for many months or simply never made it after more than a year of PRs waiting. Ironically, my boss had to order the cancellation of some CI tests because he didn't accept my PR fixing those tests. And it's been like that for something like three years now.

I wish this situation was exceptional, but it happened more than once, and, by far, I'm not the only one experiencing this. That's what I mean by "initiative is punishable."

[hibikir]

You know your company has made it when shadow IT has been merged into central IT after a tough political fight, and as they try to make the old shadow IT less responsive and more standard, a new wave of real shadow IT gets hired. That new, real shadow IT might even be paid more, because they are often hidden in CapEx somewhere, instead of having to go with HR standards for leveling and job descriptions. I've seen the biggest things come out of said shadow IT groups, precisely because their management is uninterested in the glacial procedures of real IT.

[malfist]

My other half is one of those. Works in setting up hospital pharmacies for new hospitals and he's the "excel and VBA guy" to all his coworkers.

It's amazing how far just a little bit of programming can

[hibikir]

AI is the only way to reasonable interact with my employer's Jira board. The form for ticket creation had 206 fields across the tabs last time I checked. 10 are mandatory, including freetext that isn't really free, as the ticket goes to the shadow realm if you didn't match your team's valid values.

So it's a world where it's not just that one wants simple automation for ticket creation, but you might want to ask an LLM to update it. Dear Claude, I need to put a request with team X. I know John Doe works there. Please figure out what the hell their intake looks like, and what we have to fill out for the last few sprints and write it down, because I sure don't have time for this.

[LtWorf]

> 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.

[fragmede]

You have the script auto-renew the token. It's in the spec.

[LtWorf]

Along with the auto TOTP?

[michaelt]

OCR with a webcam pointing at the RSA token, of course.

[Tade0]

> 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.

[codesnik]

nowadays you can vibecode some half-ass headless browser automation using your email-password or even weird corporate sso.

[taybin]

That is exactly what i did last week. Got praised for it.

[_ZeD_]

> corporate programmers with the hacker spirit

that thing does not exists