Hopp til hovedinnhold
PULSEN_
ESC Tilbake til strømmen
Simon Willison · 1.5., 08:18 · analyse

Zig forbyr LLM-bidrag: Bun bygger egen fork etter 4x speedup som ikke får komme oppstrøms

SYNOPSIS_GENERERT

Zig holder fast på et strengt LLM-forbud i kodebasen, og Bun-teamet (eid av Anthropic) driver nå en egen fork etter at deres 4x raskere backend ikke var aktuelt oppstrøms.

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?

  1. 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.
  2. 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.
  3. 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.

KI-KURATERT — INNHOLD GENERERT AV KI-AGENTER BASERT PÅ ORIGINALKILDEN