upvote
On the other hand, most issues rot due to process overhead, not because the ticket is hard.

For example, why are you working on a four-year-old issue, and a trivial one at that, when you're already behind schedule on the tasks assigned to you? Now someone else who has their own things to get done has to review it? And even trivial changes can be annoying to truly review beyond a blind LGTM.

Just one of the many ways that pressure builds against the utopia of burning through old tickets.

Aside, watch out for the double standard we have for AI on forums like this. AI is expected to be so good that it can magically overcome the forces that keep engineers from working on old tickets (which were never related to engineer productivity) and, when AI can't, well of course it couldn't because AI sucks.

reply
And who knows the fix to some of these issues might be a hell of a lot more worked now that the bug has been baked in and the "real" fix is herculean now.
reply
The reason for this is: the only way to show productivity gains enabled by AI is to lay off people and pretend you are doing the same amount of work (while in reality you are severely dropping quality and accumulating technical debt).
reply
I think that in these cases, what they need more than more engineering or AI productivity, is good management. Close issues that get shuffled around too much as "yeah this is too vague", or "nah we can't fix this", or "you know what, fuck you I'm not doing it".

Productivity gains can also be achieved by reducing scope. The coming issues will be that because of increased productivity (idea -> working code) that software is too bloated, does too much, that product managers will and can say "yes" to everything. Until it becomes unmanageable.

And that's not a new problem, it's what basically every programming adage / wisdom going back 70 years is about.

reply
Also, when most work is unproductive, like managers shuffling around and relabeling issues, you can remove those managers without affecting output.
reply
Quite possibly while improving output. Managers that are gone will not require attention from developers.
reply
Dunno how it is these days, but that reads like Android roughly 2012-2020.

I once found a looooong bug report thread on their issue tracker 7ish years old that had all the usual waves of promises that a fix might make the next release, then silence, then repeat, and the usual challenges to the bug’s status every time a release happened, plus it saw community members correctly diagnose the problem in the first couple years, then by like year 5 there’s was a (small!) patch posted by a community member with multiple posters confirming it was good and fixed the issue, that the author and others had been begging Google to apply and get in a release for a couple years. There’d been no responses from Google folks for a while.

That might be the worst one I saw, but encountering something like that was a few-times-per-year thing in my android app dev years.

reply
I'm certain that if they would start doing that, without a proper strategy / workflow when it comes to QA, it will be GitHub reloaded. You'll be able to watch the decline in real-time.
reply
But that’s the issue the parent is highlighting, you can’t just throw AI at these problems because the bottleneck is decision making, it always is, and AI is bad at that.

So nothing really changes in terms of product development velocity, it’s just headcount reduction.

But that’s not what their own marketing strategy communicates.

reply
I think what OP means is that these companies keep promising AI is exceptional for one thing but for some reason it's never used for that. The only visible outcome of AI in these companies is that they spend so much on it they end up laying off employees.

Has any of the companies who went all in on AI gotten better at their job because they went all in on AI?

reply
> I have never interacted with a piece of software that, for every single problem I found, there was an open issue always at least 4-7 years old

You have never interacted with Jira?

reply
I'm going to be honest with you, I never even considered that the pinnacle of enterprise software would have a public issue tracker (do they?). If something doesn't work the way I expect I just accept it and move on.
reply
Jira bugs celebrate being old enough to drink.
reply
Honest question, why don't they just close the issue if they don't intend to fix them?
reply
Because an enterprise customer might decide it’s a needed fix tomorrow. I’ve seen it happen - 20 year old bug on the backlog and suddenly it jumps to the front of the line.
reply
Someone should make a browser plugin for that.
reply
Even slop-maker-makers themselves struggle: https://github.com/anthropics/claude-code/issues

What hope slop-maker-users have then?

reply
To be fair, any LLM project gets a lot of stupid tickets, by virtue of a) marketing to users who aren't really developers and b) bad developers being more likely to use LLMs. Both of these groups are more likely to write bogus or non-reproducible bug tickets, as well as feature requests that don't make any sense. My guess is 10% of those 10,000 open issues are actual bugs or sensible requests.

On the other hand, LLMs seem perfect for triage and finding duplicates, so it's still surprising that they've let it get this bad.

reply
The number is much higher than 10%. They already have a quite aggressive system of closing/duplicating issues, automatically or manually.

(Source: I build tooling around Claude Code and have spent hours swimming in the GitHub issues based on downstream user feedback)

reply