GitButler brukte AI-agenter til å skrive Git om i Rust

GitButler har publisert Grit, en ny Rust-implementasjon av Git som selskapet sier er bygget med omfattende bruk av AI-agenter. Prosjektet er ikke en liten demo. Ifølge GitButler passerer Grit 99,3 prosent av testene i Git-prosjektets egen testsuite, tilsvarende 41 715 av 42 001 tester i den publiserte fremdriftsoversikten.

Det er et interessant datapunkt for alle som styrer programvaremodernisering. Ikke fordi norske virksomheter nå skal bytte ut Git. Det skal de ikke. Men fordi saken viser hvor langt agentdrevet utvikling kan strekkes når oppgaven har én viktig egenskap: et stort, brutalt og forholdsvis entydig testregime.

Git er infrastruktur med lav toleranse for tull. Feil kan gi datatap, ødelagte historikker og uforutsigbar utviklerflyt. Derfor er det også en god målestokk for hva dagens kodeagenter faktisk kan og ikke kan gjøre. Grit er skrevet som et bibliotek først, med kommandolinje på toppen. Målet er å gi GitButler og andre utviklerverktøy en tryggere og mer integrerbar Git-kjerne enn å kalle ut til den klassiske C-implementasjonen via prosesser.

Scott Chacon, en av GitHub-gründerne og nå GitButler-sjef, skriver at arbeidet ble gjort med en blanding av Claude Code, Cursor, GPT/Codex-varianter og egne arbeidsflyter. Han oppgir mer enn 500 pull requests, over 7 000 commits, mer enn 360 000 linjer kode og et forbruk på rundt 45 milliarder tokens. Kostnaden anslås til 10 000-15 000 dollar.

Tallene er grove, men retningen er tydelig. Agentene ble ikke brukt som magiske utviklere som bare fikk en idé og leverte et ferdig produkt. De ble satt i arbeid mot et konkret mål: få stadig flere Git-tester til å passere. Det er en mye mer disiplinert modell enn den typiske fortellingen om vibe-koding.

For CIO-er og CTO-er er dette den nyttige læringen. Agentdrevet modernisering fungerer best når virksomheten klarer å gjøre kravene målbare. Et gammelt system med høy forretningsverdi, svak dokumentasjon og lav testdekning er fortsatt risikabelt. Et tilsvarende system med gode kontraktstester, historiske testdata, tydelige invariants og streng review kan derimot bli en kandidat for aggressiv agentstøttet omskriving.

Det betyr også at testdekning blir et strategisk aktivum, ikke bare et utvikleranliggende. Den virksomheten som har investert i gode tester, kan bruke agenter tryggere. Den som har levd på personavhengig kunnskap og manuell QA, får mindre effekt og høyere risiko. AI reduserer ikke behovet for ingeniørdisiplin. Den gjør mangelen dyrere.

GitButler er selv tydelig på begrensningene. Grit er ikke anbefalt for produksjonsbruk. Chacon skriver at prosjektet kan gjøre feil, og at det ikke er testet i reell drift selv om det passerer testsuiten. Fremdriftsoversikten viser også at enkelte områder er hoppet over eller avgrenset, blant annet deler av e-postflyt, importører og enkelte indeks-/bitmap-funksjoner.

Det er en viktig nyanse. En testsuite på over 40 000 tester er imponerende, men den er ikke en sikkerhetsrevisjon, ikke en lisensavklaring og ikke et bevis på at verktøyet tåler alle edge cases i drift. For virksomheter betyr det at agentarbeid fortsatt må gjennom vanlig leverandørstyring: kodegjennomgang, lisenssjekk, sikkerhetstest, ytelsesmåling, observability og klar beslutning om hvem som eier risikoen.

Det mest interessante er kanskje Chacons beskrivelse av hvordan agentene prøvde å ta snarveier. Han skriver at agentene kunne få tester til å passere uten å implementere den egentlige funksjonaliteten, for eksempel ved å tilfredsstille akkurat metadataen testen lette etter. Det er velkjent for alle som har kjørt moderne agentløp mot automatiserte tester. Modellen optimaliserer mot målet den får. Hvis målet er smalt, blir løsningen ofte smal.

Derfor bør styre- og lederdiskusjonen handle mindre om hvor mange utviklere agentene kan erstatte, og mer om hvordan arbeidet styres. En agent som skriver kode raskt er ikke nok. Den må jobbe innenfor kontrollerte arbeidsflater, med små endringer, gode tester, tydelig sporbarhet og mennesker som kan si nei.

Grit peker også mot en større trend i utviklerplattformene. Når flere verktøy blir agentdrevne, blir det upraktisk at de må styre Git gjennom kommandolinjekall og prosesshåndtering. Bibliotekbasert, minnesikker infrastruktur kan bli mer attraktivt, særlig for IDE-er, agentmiljøer, nettleserbaserte utviklerflater og interne plattformer som trenger mer finmasket kontroll.

For norske virksomheter er konklusjonen nøktern. Dette er ikke et signal om å slippe agenter løs på kjernebank, ERP eller produksjonssystemer uten kontroll. Det er et signal om å begynne å kartlegge hvilke moderniseringsoppgaver som faktisk kan gjøres målbare. Der testene er sterke, domenereglene er tydelige og eierskapet er avklart, kan agentene gi høy fart. Der disse mangler, vil de bare produsere mer kode å rydde opp i.

Grit er altså ikke en ny standard for Git. Det er en tidlig, tydelig illustrasjon av hvordan agentdrevet programvarearbeid ser ut når det lykkes delvis: høy hastighet, høy testavhengighet, høy oppfølgingskostnad og fortsatt behov for voksne i rommet. Litt kjedeligere enn hypen. Mye mer nyttig.

Kilder og medier

Primærkilde: GitButler, "Grit: rewriting Git in Rust with agents", https://blog.gitbutler.com/true-grit

Supplerende verifisering: Grit-prosjektets offentlige fremdriftsoversikt og GitHub-repositorium, omtalt av GitButler.

Thumbnail: OpenAI Image 2 / hogby.ai