Laravel News broke this last week: Taylor Otwell turned off GitHub Issues on most of Laravel's official packages. Cashier, Socialite, Horizon, the stuff a huge share of Laravel apps quietly run on top of. Found a bug now? Taylor's own words: describe it to a coding agent, open a PR. Rough code is fine. It documents the problem, and a real fix can follow.

The news side of this is covered. I want to talk about the part nobody's really sitting with.

I run a Laravel shop. Half our stack is built on packages Taylor and his team maintain for free. My gut reaction wasn't anger. It was something closer to yeah, that tracks. I've triaged enough half-written bug reports at 11pm to understand the appeal.

But I don't think most business owners running on Laravel have any idea this happened. And they should.

Why a maintainer would do this

Open-source maintenance runs on invisible labor. Someone files a bug, someone else reproduces it, decides if it's real, and eventually fixes it. That triage step eats maintainers alive, and almost nobody outside the project ever sees it happen.

Other PHP projects are betting the opposite way right now, according to that same Laravel News piece: keep issues open, but have the team (or their own AI) write the fixes. Same underlying cost. Different guess about who should absorb it.

Taylor's bet is simpler. A bug report with no fix attached used to take real effort to write. Now anyone can hand a stack trace to an agent and get something back in thirty seconds. So he's just asking for the something.

Makes sense on paper. It's also a transfer of labor, whether he frames it that way or not. The maintainer used to eat the triage cost. Now whoever hit the bug does. Fine if that's your dev team. Rough if you're a solo founder who's never opened a pull request and just lost a support channel without noticing.

What changes for a business that didn't write this code

Nothing changes about the packages today. Cashier still runs your subscriptions exactly the way it did last week.

What changes is the next time something breaks.

Old path: file an issue, a maintainer with years of context on the codebase looks at it, a fix ships from someone who actually understands the internals.

New path: you (or an AI agent standing in for you) write a PR. That agent has never seen Taylor's design tradeoffs or the three adjacent things your fix might quietly break. He still reviews it, obviously. But the first draft, the part most likely to hide a plausible-looking mistake, now comes from someone with less context than the person who used to write it.

I don't think that makes the average fix worse. A documented bug with a rough patch genuinely beats a two-line complaint with nothing attached. What it changes is who's on the hook for catching the subtle stuff. That's whoever merges the PR now, not whoever wrote it. Some review sessions will be sharp. Some Friday afternoon reviews won't be, and something will slide through because the diff looked plausible and the maintainer was tired.

Here's what actually bugs me about it

Running a business on custom software already means depending on code you didn't write and can't fully audit.

What's new is the connective tissue between "someone found a bug" and "someone with real context fixed it" just picked up a layer of AI-generated first drafts. At scale. Across an ecosystem a lot of small businesses run on without ever thinking about it.

I'm not worried about Laravel specifically. Taylor's earned enough trust over a decade that I'd bet this settles out fine. What I'd actually ask is the question you should've been asking before any of this and that is, "who is reading the code your app depends on before it ships to your customers?" If the honest answer is nobody, you just trust the green checkmark, that's a hole in your process worth handling for regardless of what any one maintainer does with an issue tracker.

We touch this exact problem when we handle ongoing maintenance and support for clients. Someone actually reads the dependency changes. Not just watches the build turn green.

A couple weeks back we wrote about what happens when the company behind your AI vendor gets acquired. Same underlying risk but a different trigger and most of the people running those apps won't notice until something breaks.

What I'd actually do about it

If you're not a developer: this isn't a reason for alarm. It's a reason to ask whoever builds your software, in-house or a custom development partner, the question of, "When a dependency has a problem, who reviews the fix before it touches the app?"

Not "does the test suite pass?" Who, specifically, read the change and understood what it does?

If you're a developer, especially one that works with Laravel like we are, view this as an indicator of things to come. Taylor said it plainly: "I suspect this will soon be how most open-source libraries operate." If he's right, the bottleneck stops being who writes the fix and becomes who catches the fix that looks correct but isn't. It's a much harder role to work, and its worth thinking about now, while it's still one maintainer's experiment and not the default sitting quietly in your composer.json.