GitHub: Kostnaden ved å si ja til kode har endret seg

Det skjer nå

GitHub-ingeniør Dalia Abuadas skriver 17. juli 2026 at den dyreste delen av en «liten» funksjonsforespørsel ikke lenger er å skrive koden. Det er ofte møtet om hvorvidt koden i det hele tatt skal skrives.

Det høres ut som en elegant observasjon fra Copilot-verdenen. For norske CTO-er, utviklingsledere og CISO-er er det en operativ advarsel: AI har senket prisen på å produsere en patch. Den har ikke senket prisen på å eie den.

Hva GitHub egentlig argumenterer for

Artikkelen «The cost of saying yes has changed» setter opp et nytt beslutningsrammeverk for AI-assistert utvikling:

• Debatten kan koste mer enn patchen. Et team kan bruke 40 minutter i tråd på om last_active_at skal vises i innstillinger – mens en agent kan produsere et første utkast i samme tidsrom.
• Første patch er en prissjekk, ikke leveransen. Den genererte diffen er et sonderingsverktøy: Hvilke filer treffes? Er testene åpenbare? Bevares abstraksjonene? Kreves en skjult produktbeslutning? Vil noen eie dette om seks måneder?
• Billig å skrive ≠ billig å eie. En tusenlinjers diff som «passerer» men som ingen vil ta ansvar for, er utsatt kostnad – ikke en billig seier.
• Flytt scopedisiplin nærmere evidens. Be om et begrenset forsøk: minste mulige patch, bak eksisterende feature flag, uten å endre offentlig kontrakt, med tester, med liste over berørte filer og eksplisitt risiko.
• Den nye ferdigheten er å prise usikkerhet fort. Beste ingeniører sier verken ja til alt eller nei til alt. De skiller produktbeslutninger fra implementasjonskost, og vet når review er dyrere enn skriving.

Poenget er ikke å la AI bestemme. Poenget er å gjøre menneskelig vurdering billigere og mer evidensbasert.

Hvor skillet går i praksis

GitHub trekker en skarp linje som ledere bør gjøre til policy:

• Ofte billig: Vise et felt som allerede finnes i backend; refaktorere en godt testet helper.
• Ikke billig – uansett ren diff: Endre autorisasjon, personvern, billing, compliance eller datalagrings-semantikk.
• Hardt nei fortsatt gyldig: Alt som flytter produktkontrakten, skaper supportbyrde eller rører personvern/betaling/compliance.

Det er her mange organisasjoner snubler. De måler AI-gevinst i «linjer generert» eller «PRs åpnet», mens den reelle balansen er eierskapstid: review, incident-risiko, teknisk gjeld og menneskelig ansvar.

Hvorfor dette er lederstoff, ikke bare utviklerblogg

CIO/CTO: Porteføljen av «små ting» endrer seg

Når førsteutkast er billig, bør backlog-styring slutte å bruke «for dyrt å prøve» som standardargument. Samtidig må arkitektur- og produktgrenser beskyttes hardere – nettopp fordi det er lettere å krysse dem ved et uhell.

CISO/DevSecOps: Review blir sikkerhetskontrollen

Autorisasjon, secrets, dataflyt og compliance blir ikke tryggere av at en agent skrev koden fort. Hvis scopedisiplin flyttes til review, må review være ekte: eierskap, tester, logging og stoppregler – ikke rubber-stamping av grønne CI-kjøringer.

CFO/FinOps: Tokenpris er ikke eierpris

Å generere en kandidatpatch koster tokens. Å eie feil patch koster hendelser, rollback, support og omdømme. Budsjetter bør skille eksperimentkost fra produksjonskost.

Styre/risiko: Ansvar forblir menneskelig

«Agenten skrev det» er ikke en ansvarsmodell. Når endringer går raskere, trenger styret å høre hvordan organisasjonen priser usikkerhet, ikke bare hvor mange agenter som kjører.

Et praktisk rammeverk norske team kan innføre denne uken

1. Klassifiser forespørsler før agenten får jobb

• A: Lokalt UI/visning, ingen kontraktendring
• B: Intern refaktor med god testdekning
• C: Tverrgående plattform, auth, data, penger, personvern
• D: Uklar produktbeslutning forkledd som «liten fix»

Bare A/B skal normalt få «try first»-sporet.

2. Sett harde constraints på agentforsøket Minste patch. Feature flag. Ingen API-/kontraktendring. Tester påkrevd. Eksplisitt filliste. Eksplisitt risikoliste. Ingen stille avhengighetsoppgraderinger.

3. Gjør review til eierskapsbeslutning Reviewerens jobb er ikke «ser greit ut». Jobben er: Kan jeg forklare dette om seks måneder, og vil jeg bli vekket om natten for det?

4. Mål det som betyr noe Ikke bare velocity. Mål: tid til evidens (første gyldige diff), review-tid, revert-rate, andel endringer som treffer auth/data, og hvor ofte «liten sak» viste seg å være stor.

5. Hold hard nei for kontrakt og compliance AI endrer ikke at personvern, bilag, tilgang og regulatoriske løfter krever menneskelig produkt- og risikovurdering først.

Typiske feil å unngå

• Å behandle agentdiffen som ferdig produkt. Den er en prissjekk.
• Å si ja fordi genereringen var billig. Eierskap kan være dyrt.
• Å si nei fordi all ny kode «alltid er dyr». Det argumentet er svekket for avgrensede endringer.
• Å la alle team finne opp egen policy. Da får du kaos i tilgang, kostnad og kvalitet.
• Å glemme at møtet selv er en kostnad. Når usikkerheten kan prises på 30 minutter med et begrenset forsøk, er to dagers scope-debatt ofte sløsing.

Lederens bunnlinje

GitHubs poeng er enkelt og ubehagelig: kostnaden ved å si ja har endret seg – kostnaden ved å si nei bør følge etter.

AI gjør det billigere å finne ut hva en endring faktisk koster. Den gjør det ikke billigere å leve med feil eierskap. Organisasjoner som vinner, bygger en kultur der små, avgrensede ting probes raskt – og der auth, data, penger og compliance fortsatt møter et hardt, menneskelig nei til evidensen finnes.

Det er ikke en prompt-triks. Det er driftsmodell for programvare i agentæraen.

Kilder og medier

• Primærkilde: GitHub Blog – Dalia Abuadas, «The cost of saying yes has changed», 17. juli 2026 – https://github.blog/engineering/the-cost-of-saying-yes-has-changed/
• Thumbnail: OpenAI Image 2 / hogby.ai