If I rent an excavator to dig a hole for a swimming pool, I do not suddenly become a professional.
I become a person with a very powerful tool and a very real chance of making a much bigger mess. I will probably hit something I should not hit. The hole will not be level. The shape will be wrong. And after a few hours of pretending I know what I am doing, someone who actually knows this stuff has to come in and fix my garden. 🙈
That is how I think about AI-assisted software contributions right now.
AI is a tool. A powerful one. In the hands of a good developer, it can amplify output in genuinely useful ways. It can help explore code, write tests, spot patterns, draft boring glue, explain unfamiliar APIs, and remove a lot of friction. I use it that way myself.
But a powerful tool does not replace understanding. It amplifies whatever is already there. If there is judgment, it amplifies judgment. If there is confusion, it amplifies confusion. If there is no ownership, it creates work for someone else.
Open source is now feeling that very hard.
The pull request is not the finish line
I want to be very clear about one thing first: contributions are good. That is the whole point of open source. Someone taking the time to report a bug, improve documentation, fix an integration, or add support for a device is a good thing. A pull request usually means someone cared enough to try.
That part matters. I never want maintainers, including myself, to forget it.
But a contribution is not finished when the pull request is opened. That is where a different kind of work starts. Someone has to understand the change, review the code, check the behavior, think about the edge cases, look at the user impact, verify tests, consider long-term maintenance, and eventually own the result after it is merged.
AI changes the cost of creating the first version. It does not make that second part disappear.
That is the asymmetry we are dealing with. Contributors are being amplified. Maintainers are still the verification bottleneck.
Security is already showing the shape of this
Anthropic published an initial update on Project Glasswing, their effort around AI-assisted vulnerability discovery. The headline number is huge: more than 10,000 high- or critical-severity vulnerabilities found across important software stacks.
That number gets attention, of course. Big numbers always do. But the more interesting line is this one:
“Progress on software security used to be limited by how quickly we could find new vulnerabilities. Now it’s limited by how quickly we can verify, disclose, and patch the large numbers of vulnerabilities found by AI”.
That is the whole problem in one sentence.
Finding work got faster. Verifying work did not become free. Patching did not become instant. Coordinated disclosure did not become easier. Maintainers did not suddenly get more hours in a day.
The open-source part of that update is especially interesting. Anthropic says they scanned more than 1,000 open-source projects and identified thousands of potential high- or critical-severity vulnerabilities. At the time of their update, only a much smaller number had been patched. Some of that is expected because disclosure windows exist, and not every patch is public immediately. Still, the shape is obvious: AI can create a huge amount of legitimate-looking work faster than the ecosystem can absorb it.
And that is with an organized program that includes verification steps. Now imagine the same dynamic spread across normal issue trackers, pull requests, vulnerability reports, and well-meaning contributors who have access to increasingly capable tools.
curl has been living this in public
Daniel Stenberg, a fellow GitHub Star and curl’s long-time maintainer, has written a lot about this from the maintainer side, and I think those posts should be required reading for anyone who thinks this is a simple “AI good” or “AI bad” discussion.
In Death by a thousand slops, he described the flood of low-quality AI-generated security reports hitting curl. The problem was not just that the reports were wrong. The problem was that every report still needed human attention. Security reports cannot simply be ignored because they look annoying. Someone has to check. Someone has to spend the time.
curl eventually ended its bug bounty program. That changed the incentives and reduced the worst of the slop. But then Daniel wrote High-Quality Chaos, which is a much more interesting phase of the story. The obvious junk went down. The quality went up. Almost every report seemed to use AI in some way. The reports were better.
But the volume was still a problem.
That is the part I keep coming back to. Better AI-assisted work is still work. Higher-quality reports are much better than slop, obviously, but they still need triage, discussion, patches, releases, advisories, and judgment.
A few weeks later, Daniel wrote another post with the very direct title The pressure. That one is harder to read because it is not really about tools anymore. It is about people. About work hours, responsibility, health, and a project that is installed almost everywhere trying to keep up with an avalanche of security work. That is the part the “AI found more bugs” headline usually misses. Finding more is only useful if the humans on the other side can still verify, fix, disclose, release, and breathe.
Open source has spent years optimizing for getting more people to contribute. That was the right goal. But now we are entering a phase where “more” is not automatically the answer. We need better paths from contribution to maintainable outcome.
The answer is not banning AI
Some projects have responded by restricting or banning AI-generated contributions. I understand why they get there. When a project is drowning in questionable contributions, the fastest visible lever is to say “no AI”.
NetBSD’s commit guidelines say LLM-generated code is presumed tainted and must not be committed without prior written approval. Gentoo’s AI policy forbids contributions created with the assistance of natural language processing AI tools, citing copyright, ethical, and quality concerns.
Those are not silly concerns. But I do not think trying to detect AI use, police it, and fight contributors over whether a tool touched their work is where open source should spend its limited maintainer energy.
That energy is better spent on the thing we actually need anyway: clear contribution paths, stronger review boundaries, better tests, reproducible reports, smaller changes, and maintainers feeling safe to say “no” when something is not ready.
AI-assisted work is not one thing. A drive-by contributor asking an agent to “fix this issue” and pasting the result is very different from an experienced developer using AI to write tests for code they understand. A security report generated by a model and never verified is very different from a report where the researcher used AI as part of their workflow and then reproduced the issue properly. A maintainer using AI to find repeated review feedback and turn it into a lint rule is different again.
The useful question is not “did AI touch this?”. The useful question is: does the person submitting this understand it, validate it, and take responsibility for it?
That is the professional line. Not whether an excavator was used, but whether the person operating it knows how to dig the hole without destroying the garden.
Home Assistant will likely adopt an AI policy soon as well. Not to ban AI, but to give maintainers the tools and the permission to say “no” when someone shows up after absolutely obliterating their garden with that machinery.
That is the point for me. A policy should not become an AI detector game. It should make the expectations clear: if you submit the work, you own the work.
Home Assistant is feeling this too
At Home Assistant, we are not watching this from a distance. We are in it.
The number of pull requests is high. The number of merged contributions is high too, and that part is genuinely good news. Every release includes more work from people who cared enough to contribute. New integrations, fixes, cleanups, documentation improvements, tests, translations, small quality-of-life improvements. That is open source working.
But the queue is growing. And that is the hard part.
We are not winning yet.
That does not mean contributions are bad. It means the system around contributions has to evolve. If contributors are amplified, the project needs to amplify the path around them as well: the docs, the checks, the review process, the feedback loops, and yes, the AI instructions that shape what people and agents produce.
This is an important distinction: these improvements do not only help humans. AI uses them too.
When we improve documentation, humans read it, but AI tools also retrieve it, summarize it, and use it as context. When we tune AI instructions because we notice weird repeated patterns, we are not just helping the next person. We are shaping the next generated contribution. When human reviewers keep leaving the same comments, that is a signal. Maybe the documentation is unclear. Maybe a static check should catch it. Maybe a linter rule should exist. Maybe our own tooling needs to become more opinionated.
That is where I think the real adaptation happens.
Not by pretending AI is not part of software development now. Not by accepting every AI-shaped pile of code because “contributions are good”. And not by believing AI review can fully replace human judgment, because verification is the slower, more careful part for a reason.
The path forward is to turn repeated human judgment into better systems.
Maintainers need leverage too
Developers are getting leverage from AI. Maintainers need leverage as well.
Some of that leverage is boring, which usually means it is useful. Better documentation. Clearer contribution guidelines. Stronger tests. More static checks. Linters that encode project-specific expectations. CI that catches common mistakes before a reviewer spends time on them. Templates that ask for the right information. Review tooling that summarizes the risk areas instead of pretending to make the decision.
Some of it can be AI-assisted too. AI can help analyze review history and find repeated patterns. It can help draft documentation for common mistakes. It can suggest where a check might replace a repeated review comment. It can help maintainers navigate a large queue and group similar problems together.
But the goal is not “let AI review AI”. That sounds neat until you remember that review is not only pattern matching. Review is judgment. It is taste. It is understanding the project’s direction. It is knowing why something that works technically may still be wrong for the project.
AI can help prepare the review. It cannot be the maintainer.
That is why I do not think the battle is won by fighting AI. It also will not be won by surrendering to it. Open source has to become more explicit about what good contribution looks like, more automated around the parts that should not require human attention, and more protective of the scarce human judgment that remains.
Open source has to adapt
Open source was not ready for AI-speed contributions. Honestly, I am not sure any of us were.
We built a lot of our workflows around a world where creating a pull request took effort. That effort acted as a filter. Not a perfect one, but a real one. If someone had to understand the code, write the change, run the tests, and explain the result, there was some friction before the maintainer ever saw it.
AI removes a lot of that friction. Sometimes that is wonderful. Sometimes it means a good contributor can do more good work. Sometimes it means a confused contributor can produce a much larger confused contribution. Sometimes it means a maintainer gets a useful report. Sometimes it means they lose an afternoon proving that a confident report is nonsense.
The answer cannot be nostalgia for the old friction. That world is not coming back. The answer is to build better friction in the right places.
Make the easy path the good path. Make the repeated mistakes fail before review. Make the documentation good enough for humans and machines. Make AI instructions part of the project’s contribution surface. Make tooling catch what tooling can catch. Save human attention for the parts that actually need humans.
The best open-source contribution is not the one that arrives fastest. It is the one that can be merged, maintained, and trusted.
AI can help us get there. But only if we stop treating it as magic and start treating it like the excavator it is.
Very useful. Very powerful. Very capable of making a massive hole in the garden.
../Frenck
