Problemet med AI-genererade falska buggrapporter är numera hanterbart. Å andra sidan är det nu en ström av goda AI-rapporter som tvingar utvecklare att offra helgerna. Det rapporterar den svenska maintainern för kodbiblioteket Curl.
Numera får Daniel Stenberg in klart fler korrekta än falska AI-genererade buggrapporter. Det har vägt över så mycket att Daniel Stenberg deklarerat problemet löst.
Du känner kanske till problemet med AI-bottar som söker efter buggar i programvara? Problemet är att AI-bottar ofta är usla programmerare.
Sedan ett par år skickar amatörer in buggrapporter skapade av AI till olika öppenkodsprojekt – kanske på jakt efter de prispengar som delas ut till felfinnare. Det är enkelt att be AI hitta en bugg. Det tar betydligt längre tid för projektens ansvariga att konstatera att buggen är – hallucinerad.
Men för ett halvår sedan skedde en dramatisk vändning. Slaskrapporterna fick sällskap av korrekta AI-genererade rapporter – i stora volymer.
Andelen slaskrapporter har sedan dess krympt.
Å andra sidan har antalet goda felrapporter ökat. Så projekten kan inte koppla av. Även korrekta buggrapporter måste hanteras. Och den totala volymen buggrapporter ökar i stadig takt.
![]() |
| Daniel Stenberg |
– Den senaste tiden har den legat på ungefär dubbelt så hög takt som vi hade genom hela 2025, vilket i sin tur redan var mer än dubbelt från tidigare år, skriver Daniel Stenberg på sin blogg.
Under 2025 landade en felrapport i inkorgen i snitt var 50:e timme. Idag är det ett dygn.
Nästan alla säkerhetsrapporter är numera skapade med hjälp av AI.
– Skillnaden nu jämfört med tidigare är dock att de för det mesta håller mycket hög kvalitet.
Andelen bekräftade sårbarheter bland felrapporterna ligger just nu på 15–16 procent. Till detta kommer mindre allvarliga buggar – 30 procent. Daniel Stenberg väntar sig att Curl kommer att sätta rekord i funna sårbarheter i år.
Han tror att lavinen av rapporter kommer att fortsätta och öka projektens överbelastning.
Många andra öppenkodsprojekt ser samma utveckling.*
– En del projekt kommer att få svårt att hantera den här typen av backlog-expansion utan att fler underhållare tillkommer som hjälp.
Vilken hjälp behöver Curl?
– Framför allt behöver jag kunder som betalar för Curl så att vi får intäkter nog att betala folk, inklusive mig själv, för att arbeta mer med Curl, säger Daniel Stenberg till Elektroniktidningen.
– Arbetet i Curls säkerhetsteam sker främst privat eftersom det kan vara säkerhetskänsligt. Därför behöver vi personer i teamet som kan lägga tid och energi på frågorna, och eftersom teamet är begränsat är det svårt att skala upp. Det krävs en särskild uppsättning mycket avancerade kompetenser för att göra ett bra jobb i teamet.
– Jag förväntar mig inte eller kräver att någon ska lägga timmar av sin fritid och sina helger på detta arbete på samma sätt som jag gör, men flera av mina teamkamrater gör det ändå.
FOTNOT
* Följande projekt har bekräftat för Daniel Stenberg att de ser samma trend: Apache httpd, BIND, curl, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, Linux kernel, OpenLDAP, PowerDNS, python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark och wolfSSL
