Laravel's new rule landed like a slap: no more issues, Pull Requests only. The reaction I saw was pretty much what you'd expect. How is a user supposed to report a problem if they can't open an issue?
Are you really telling everyone to read the source and fix it themselves?
But sit with it for a minute and the logic holds up. The argument running around tech circles is that this cuts the junk, because anyone willing to spend time on a PR actually cares about the problem, while bots and drive-by complainers won't bother. A maintainer gets far more signal from a PR than from a one-line issue, so they understand and fix things faster. And it doesn't really raise the bar for users either, since in the AI era you can describe a problem to a model and have it draft the PR for you. The deeper reason behind the ban is blunt: open-source projects don't have the resources to absorb a flood of low-effort issues.
I don't think the interesting part is the ban. The interesting part is the thing the ban is a proxy for: forcing a complete, reproducible report instead of a vague "it's broken." That discipline is worth rebuilding even if you never want to turn off issues on your own repo.
The signal underneath the headline
There's a second piece of evidence worth putting next to it. Someone shipped after letting AI test repeatedly and confirm it was safe to publish, then found a big bug the moment they tested by hand. Their takeaway was simple: you can hand off a lot of the building, but testing still needs a human at the keyboard.
Put those two together and you get the shape of the tool. Reproducibility is the thing that makes a report useful, and human review is the thing that keeps you honest about what's actually fixed. A good intake tool should push hard on the first and never pretend to replace the second.
What you can actually build on VicroCode
So here's the project: a hosted bug intake tool that refuses vague submissions, structures what it gets, drafts a candidate fix you still read with your own eyes, and keeps a triage ledger a maintainer can correct by hand.
Start with the front door. You build an HTML form and run HTML online so contributors have a real URL to hit, no local setup. The form isn't friendly on purpose. It won't let a submission through without the pieces that make a report reproducible: exact version, environment, the steps to trigger it, what you expected, what actually happened, and a minimal snippet. Empty "steps to reproduce" field?
The submit button stays dead. This is the Laravel instinct ported to a form instead of a policy, you're raising the floor on effort before anything reaches you.
The backend is where the rambling gets turned into something you can act on. You run Python online behind an API endpoint hosted in-platform, and that Python layer does two jobs. First, it takes the messy prose a reporter pastes in and normalizes it into a structured reproduction spec, consistent fields, consistent shape, so every report reads the same way on your end. Second, using a model available through the Model Center, it drafts a candidate diff: a guess at the fix, framed as a suggestion. Not a merge, not a commit, a draft. You read it, you throw out the half that's wrong, you keep the part that saved you ten minutes of staring.
Every submission lands in a SQLite triage ledger. Report, structured spec, candidate diff, status, your notes. When you need to reclassify something, close a duplicate, or fix the model's bad guess, you open the SQLite editor and correct the row yourself. That hand-correction loop matters. The model is drafting, you're deciding, and the ledger is the record of what you decided.
The boundary, said plainly
Here's where I'd stop you if you were about to oversell this to your team. VicroCode can host the form, run the Python, call the model, and keep the ledger. It cannot open a Pull Request, run git, or touch your repository. There's no git integration in the capabilities I'm working with, so the "candidate diff" is text you review and apply yourself, through your own tooling, on your own machine.
That's not a workaround-shaped gap. It's the right place for the line to sit, and it lines up with the testing lesson from the evidence: the final judgment stays human. You get a tool that collects reproducible reports and does the boring structuring work, and you keep the part where a person actually decides what ships.
Whether this cuts your triage time or improves fix quality is unverified. I haven't measured it and I'd be making it up if I told you a number. What I can say is that the design matches the two things the market evidence actually supports: complete reports beat noisy ones, and a human still has to test. Build to those two truths and the tool earns its keep even before you'd dare turn issues off.
Where to take it next
If the intake tool works for your own project, the same shape generalizes. A small team maintaining several libraries could run one hosted form per project, share the triage ledger across maintainers, and publish the whole thing as a tool other people pay to use. The capabilities are there for that, hosting, sharing, and monetization are part of the platform. Just keep the boundary honest when you describe it to anyone else: it structures and drafts, it does not merge.