Zig forbyr LLM-bidrag: Bun bygger egen fork etter 4x speedup som ikke får komme oppstrøms
fredag 1. mai · KI-generert · Kilde: Simon Willison
Zig holder fast på et av open source-verdens strengeste LLM-forbud, og Bun-teamet, eid av Anthropic siden desember 2025, driver nå en egen Zig-fork fordi en 4x ytelsesforbedring ble bygget med KI-assistanse.
4x. Det er hastighetsforbedringen Bun-teamet rapporterer på bun build etter å ha lagt til parallell semantisk analyse og flere codegen-units i LLVM-backenden. Endringen er offentlig på GitHub. Bun-teamet skriver at de ikke planlegger å sende den oppstrøms til Zig, fordi Zig har totalforbud mot KI-genererte bidrag.
Forbudet, formulert av Zig Software Foundation, er kompromissløst: ingen LLM til issues, pull requests eller kommentarer i bugtrackeren, og heller ikke til oversettelse. Engelsk anbefales men er ikke påkrevd. Bidragsytere oppfordres til å skrive på morsmålet sitt og la mottakerne bruke egne oversettelsesverktøy.
«Zig verdsetter bidragsytere over bidragene deres. Hver bidragsyter representerer en investering for Zig-kjerneteamet, og målet med å gjennomgå og akseptere PR-er er ikke først og fremst å lande ny kode, men å hjelpe nye bidragsytere til å bli pålitelige og produktive over tid.» — Loris Cro, VP for Community, Zig Software Foundation
Cro kaller det «contributor poker»: du satser på personen, ikke på kortene. Når en PR i hovedsak er skrevet av en LLM, mener Zig at all gevinsten fra mentorskap forsvinner. Vedlikeholderens tid investert i review gir ingen ny tillitsrelasjon. Logikken treffer en utbredt bekymring: hvis PR-en er stort sett skrevet av en LLM, hvorfor skal vedlikeholderen bruke tid på review framfor å la sin egen LLM løse samme oppgave?
For norske utviklere som vurderer hvordan de skal håndtere KI-genererte bidrag i sine egne open source-prosjekter, er Zig en stresstest av posisjonen i den ene enden av spekteret. Det andre ytterpunktet er prosjekter som åpent oppmuntrer til Copilot-pull-requester. De fleste team havner et sted i midten med policy-dokumenter som krever menneskelig review og full forståelse av endringen.
Hva bør du gjøre?
- Skriv en KI-bidragspolicy. Bestem om bidragsyteren skal opplyse at de har brukt KI-assistanse, og hvilket ansvar de tar for å forklare endringen. Uten policy får du tilfeldig praksis i issue-tråden.
- Bestem hva som teller som «KI-generert». En LLM som hjelper med commit-melding er ikke det samme som en agent som skriver hele PR-en. Sett en linje teamet ditt forstår.
- Kjør Bun-patchen som Zig ikke vil ha. Hvis du jobber med høy-throughput JavaScript og bruker Bun, er den 4x raskere kompileringen tilgjengelig i deres fork, uavhengig av om Zig aksepterer den.