Hi Douglas, On Fri, Jul 10, 2026 at 05:59:20AM -0300, Douglas Fischer wrote:
This has become a common occurrence across various open-source projects.
Well yes, and we've been seeing this for some time. I have even touched this topic in [my last blogpost](https://en.blog.nic.cz/2026/06/10/the-spring-2026-of-security-vulnerabilitie...).
It seems like there’s a massive investment in tokens—a desperate scramble to find any opening to shoehorn a patch into the codebase, just to post about it on LinkedIn.
I’ve seen a range of attitudes toward this: from code maintainers fully embracing it (which is actually a bit unsettling) to outright blocking anything AI-generated (sometimes discarding potentially interesting contributions in the process).
It's hard. On one hand, the quality of the contributions has been miserable, see what Daniel Stenberg writes on his blog, and one inclines to waste no more time on garbage. On the other hand, especially if the project is not an infrastructure thing, people don't really care too much about occassional crashes or performance issues, and the maintainers are feeling pressured to accept the LLM-generated contributions because they look good and do the things.
I think the best suggestion I’ve seen is a middle-ground approach. Projects could build the necessary infrastructure internally to support AI-driven activities, treating them as native to the project rather than the work of an external entity simply scouring for opportunities. This would allow interested individuals to contribute their tokens to run whatever tests they deem appropriate.
Is there any easy way where we could register and say "please, users, send us some tokens so that we can run commercial models in our CI and automatically assess things"? There are also other experiments running quietly under the hood but mostly in testing and actual text processing instead of generating code. We also keep resisting LLM-assisted code reviews, as with LLM assistance, one tends to believe that if LLM found one problem of some category, it found all of these. Not that it would be too dumb, but one must not run LLM before reading the code humanly. And while certain companies have allegedly already totally switched to auto-merging changes by LLMs, just today I spoke with a big network operator and got a clear statement that they do not support this approach at all.
I don't believe the current volume justifies the effort. But once it starts to become excessive, that idea might be worth considering.
The current volume of the reports has already greatly exceeded the capacity of the team. Every single report, if repeated, is 15 minutes of work, and if new and not outright bonkers, 4 hours of senior work, beginning with the context switch, reading the report, checking relevant code, coding, and most importantly, assessing whether the fix makes sense in the context of whole BIRD. I myself vibed 5 different corner-case bugs in EVPN just last week, and fixing them will require probably half a week. Also only seeing the bugreport in the list is kinda nerd-sniping. It's hard to not switch contexts when it arrives. Even just filling the backlog is time-consuming, as one still has to do the triaging. Leŧ's see where the future is. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.