NB: This is literally just my 2¢. If you don’t agree, that’s okay.
Recently, Taylor Otwell, the lead maintainer behind the Laravel framework announced that their open source libraries would be closing their GitHub issues on almost all of their repositories. (Though seemingly excluding the main framework, for now)
I can’t put into words how shortsighted I think this is. Otwell’s argument is that any developer can just use their AI agent to spin up a fix to any issue they encounter. He argues that it might not be perfect but still it documents the problem and that a proper fix can follow… you know, like an issue.
I don’t like the precedence this sets that every programmer is obligated to start spending tokens (or indeed, use generative AI in the first place) to resolve an issue with code that isn’t theirs. Furthermore, how does said developer know upfront whether what they’ve encountered is actually a bug, a misunderstanding, or something that behaves that way for a reason? Are they expected to spend the time and resources building a fix to something they might not fully understand, hoping that a) nobody beats them to it and b) the maintainers agree there’s an issue worth fixing in the first place? Yes, existing pull requests can be searched, but that doesn’t explain why a bug report needs a proposed fix attached to it.
Open-source packages have maintainers for a reason: they understand their code and the decisions behind it. It’s great when people can contribute, and I understand that the burden of maintenance can be heavy, particularly for unpaid volunteers. I’m not suggesting that opening an issue should entitle anyone to free support or a guaranteed fix. I think it makes significantly more sense to be able to open an issue, discuss it with the community, and then work on a fix once there’s some understanding of what actually needs to change. I don’t see how attaching speculative code to that initial conversation necessarily makes anyone’s job easier.
The first step to fixing a problem should be understanding it, rather than immediately producing code – it’s literally software engineering 101. If you remember Code Complete: “Understand the problem before you fix it.” That doesn’t mean every small change needs a committee meeting obviously, but being able to ask the people maintaining a package whether you’ve found a genuine issue seems like a fairly reasonable starting point.
Even if AI makes producing a patch quicker and easier, there is still a cost. Someone still has to understand the proposed change, test it, and decide whether it belongs in the project. In my view, encouraging people to generate fixes before they’ve established what needs fixing risks creating more work for the very maintainers this is supposed to help.
I know not all issues are perfect, but I’d much rather receive a description of a problem than have to work backwards through Claude’s attempt to solve it.
Leave a Reply