7 ms·

GitLab could be the perfect case study on AI-powered efficiency improvements. I have never interacted with a piece of software that, for every single problem I

by vultour 4mo ago

GitLab could be the perfect case study on AI-powered efficiency improvements. 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 that was just being shuffled around by managers adding and removing random labels. Surely with all of these ridiculous developer productivity gains enabled by AI, they should finally be able to fix all of these ancient issues quickly and clean up the backlog. Nope, “workforce reduction” thanks to AI again. This charade is getting boring.

denvrede 4mo ago
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.
- close04 4mo ago
  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?
- stingraycharles 4mo ago
  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.
dude250711 4mo ago
Even slop-maker-makers themselves struggle: https://github.com/anthropics/claude-code/issues https://github.com/anthropics/claude-code/issues What hope slop-maker-users have then?
- morningsam 4mo ago
  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.
  - fg137 4mo ago
    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)
siva7 4mo ago
> 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?
- vultour 4mo ago
  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.
  - bombcar 4mo ago
    Jira bugs celebrate being old enough to drink.
    - spwa4 4mo ago
      Someone should make a browser plugin for that.
    - Cthulhu_ 4mo ago
      Honest question, why don't they just close the issue if they don't intend to fix them?
      - bombcar 4mo ago
        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.
sesm 4mo ago
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).
- DeusExMachina 4mo ago
  Also, when most work is unproductive, like managers shuffling around and relabeling issues, you can remove those managers without affecting output.
  - Someone 4mo ago
    Quite possibly while improving output. Managers that are gone will not require attention from developers.
    - l4n 4mo ago
      Fully agree with this. Some companies just take the chance to modernize and remove the manager-bloatwere shit ...
- Cthulhu_ 4mo ago
  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.
- e_i_pi_2 4mo ago
  I don't think this is literally true, but as an example an employee might not justify their wage in a single quarter but have a huge impact over time. In the short term firing them makes the company more profitable, but that's definitely not a good way to run a business. Everything is gambling now :/
funimpoded 4mo ago
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.
- pjmlp 4mo ago
  I no longer care, thankfully, however for several years the Android NDK felt like it was a 20% project from someone on the team.
- earthdeity 4mo ago
  On a similar note, Firefox doesn't support <input type="month">, which I was surprised to see (chrome landed it in 2012). I checked their issue tracker and... as you describe. Browsers are complex, of course, but they do stand out as a really glacial corner of the software world.
hombre_fatal 4mo ago
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.
- duxup 4mo ago
  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.
  - hombre_fatal 4mo ago
    Good point. Related: a lot of what seem like simple tickets require a real conversation about "well, how should this work?"
    - darkwater 4mo ago
      Yes, there are plenty of those tickets in GitLab public tracker, for example the "Allow defining scheduled pipelines triggers as yaml" [1] one is a good example. But still, it's a 6 year old ticket that has been clearly shuffled around with nobody taking full ownership of it, probably because it was never deemed important by higher level product management. And this is for a "feature" and it's the first that came into my mind for $REASON, but there are similar tickets for very annoying bugs. [1] https://gitlab.com/gitlab-org/gitlab/-/work_items/296630 https://gitlab.com/gitlab-org/gitlab/-/work_items/296630
    - duxup 4mo ago
      That’s been my last couple months. “Yes this is a bug / not optimal, but all the imagined paths / solutions are not great or a mountain of new code / requirements …”
dzonga 4mo ago
maybe the 'microservices' approach + agentic coding (self directed agents) that have agency to pick up old tickets, open merge requests with maybe a human in the loop will fix all that. that's the story being sold. I don't buy it.
delfinom 4mo ago
GitLab is American corporate bureaucracy out in the open for everyone to see. It's why large American corporations acquire to innovate because they otherwise are too bloated with unqualified middle management to do anything.
porknbeans00 4mo ago
Apparently you never worked with Atlassian. They have active issue tickets that are highest priority and have been open for 20 years. That's not hyperbole. Actually 20 years.

by vultour 4mo ago

denvrede 4mo ago

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.

close04 4mo ago
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?
stingraycharles 4mo ago
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.

dude250711 4mo ago

Even slop-maker-makers themselves struggle: https://github.com/anthropics/claude-code/issues https://github.com/anthropics/claude-code/issues What hope slop-maker-users have then?

morningsam 4mo ago
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.
- fg137 4mo ago
  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)

siva7 4mo ago

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

vultour 4mo ago
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.
- bombcar 4mo ago
  Jira bugs celebrate being old enough to drink.
  - spwa4 4mo ago
    Someone should make a browser plugin for that.
  - Cthulhu_ 4mo ago
    Honest question, why don't they just close the issue if they don't intend to fix them?
    - bombcar 4mo ago
      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.

sesm 4mo ago

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

DeusExMachina 4mo ago
Also, when most work is unproductive, like managers shuffling around and relabeling issues, you can remove those managers without affecting output.
- Someone 4mo ago
  Quite possibly while improving output. Managers that are gone will not require attention from developers.
  - l4n 4mo ago
    Fully agree with this. Some companies just take the chance to modernize and remove the manager-bloatwere shit ...
Cthulhu_ 4mo ago
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.
e_i_pi_2 4mo ago
I don't think this is literally true, but as an example an employee might not justify their wage in a single quarter but have a huge impact over time. In the short term firing them makes the company more profitable, but that's definitely not a good way to run a business. Everything is gambling now :/

funimpoded 4mo ago

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.

pjmlp 4mo ago
I no longer care, thankfully, however for several years the Android NDK felt like it was a 20% project from someone on the team.
earthdeity 4mo ago
On a similar note, Firefox doesn't support <input type="month">, which I was surprised to see (chrome landed it in 2012). I checked their issue tracker and... as you describe. Browsers are complex, of course, but they do stand out as a really glacial corner of the software world.

hombre_fatal 4mo ago

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.

duxup 4mo ago
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.
- hombre_fatal 4mo ago
  Good point. Related: a lot of what seem like simple tickets require a real conversation about "well, how should this work?"
  - darkwater 4mo ago
    Yes, there are plenty of those tickets in GitLab public tracker, for example the "Allow defining scheduled pipelines triggers as yaml" [1] one is a good example. But still, it's a 6 year old ticket that has been clearly shuffled around with nobody taking full ownership of it, probably because it was never deemed important by higher level product management. And this is for a "feature" and it's the first that came into my mind for $REASON, but there are similar tickets for very annoying bugs. [1] https://gitlab.com/gitlab-org/gitlab/-/work_items/296630 https://gitlab.com/gitlab-org/gitlab/-/work_items/296630
  - duxup 4mo ago
    That’s been my last couple months. “Yes this is a bug / not optimal, but all the imagined paths / solutions are not great or a mountain of new code / requirements …”

dzonga 4mo ago

maybe the 'microservices' approach + agentic coding (self directed agents) that have agency to pick up old tickets, open merge requests with maybe a human in the loop will fix all that. that's the story being sold. I don't buy it.

delfinom 4mo ago

GitLab is American corporate bureaucracy out in the open for everyone to see. It's why large American corporations acquire to innovate because they otherwise are too bloated with unqualified middle management to do anything.

porknbeans00 4mo ago

Apparently you never worked with Atlassian. They have active issue tickets that are highest priority and have been open for 20 years. That's not hyperbole. Actually 20 years.