Gosub
AI is a touchy subject in open source right now, and for good reason. A lot of projects are drowning in low-effort contributions: issues that were clearly generated by asking a chatbot to “find bugs in this repo”, and pull requests that look plausible but fall apart the moment you actually read them. So let me be clear about where we stand: we use AI in Gosub, we think it’s a genuinely useful tool, and we’re not going to pretend otherwise. But there’s a big difference between using a tool and letting it run loose on your codebase.
What we don’t want
We don’t want AI slop. The most tiring version of this is the flood of unverified issues. Someone points a model at the repository, it dumps a list of “problems”, and those get opened as issues without anyone checking whether they’re real. Each one then costs us time to investigate, only to find out half of them are hallucinated, already handled, or based on a misreading of the code. That’s not a contribution, that’s offloading your work onto the maintainers.
The same goes for pull requests. A PR that amounts to “ChatGPT, fix this issue” pasted into a diff is not something we can work with. If the person who opened it can’t explain what the code does or why it’s the right fix, then reviewing it means reverse-engineering both the problem and the solution from scratch. At that point it would have been faster to write it ourselves.
What we do want
We’re happy to accept PRs written with AI. What we care about is that a human understood, checked, and verified what came out of it. There has to be actual effort behind it.
That means discussing and planning: what is the issue, really? What’s the best solution? How should it be implemented, and how does it fit with the rest of the engine? AI is great at helping you explore those questions and at doing the mechanical work once you’ve answered them. It’s terrible as a substitute for answering them at all, especially in a browser engine, where a lot of the code has to be spec-compliant and confidently-wrong output is exactly the kind of thing that slips through if nobody’s really paying attention.
So use it as a tool. Use it to scaffold, to draft, to rubber-duck a design, to write the boilerplate you’d have written anyway. Don’t use it as a junior developer that you let loose on the codebase unsupervised and whose work you never read. The line isn’t “did AI touch this?”, it’s “does a human stand behind it and understand it?”
Why this matters to us
We want to keep ownership of the Gosub codebase. That means every part of it should be something a maintainer can reason about, explain, and maintain. AI doesn’t change that requirement; it just changes how the code gets written. A contribution where a person used AI well and stands behind the result is welcome. A contribution where AI did the thinking and nobody did the checking is not.
This is where we stand for now
One last thing worth saying: this is a decision and an opinion, and it’s the one we hold right now. The wider ecosystem is all over the place on this. Some projects are completely against AI in any form, others welcome it with open arms. We’ve landed somewhere in the middle, and we think it’s the right place for Gosub today.
But we’re not treating it as settled doctrine. As more developers join, as we gain more experience with these tools and figure out what actually works and what doesn’t, our position may well shift. That’s fine. We’d rather have a clear, honest stance now that we’re willing to revisit than pretend we have the final word on something the whole industry is still working out.
A tool is not your enemy. But it’s not a replacement for you either.