Jeg sjekket hver eneste lenke før publisering. Sju av dem fantes ikke.

Sju lenker i tekstene mine pekte på artikler som ikke finnes noe sted. Ingen av dem kom på trykk – jeg fant dem med en kommando, ikke ved å lese. Gjennomlesning er ikke lenger review, heller ikke for PR-ene dine.

Jeg har vært tech lead i snart sju år, og jeg holder på med et skriveprosjekt som heter «Det tause ansvaret» – om den delen av rollen som ikke synes. Jeg bruker AI når jeg skriver: til utkast, til motforestillinger, til opprydding. En kveld kjørte jeg denne kommandoen i stedet for å lese teksten:

Sju adresser svarte med noe annet enn 200. Verken flyttet eller feilstavet: de pekte på tekster som ikke finnes noe sted. Sjekken kjører nå før hver tekst går ut, ikke etter.

Jeg kjørte den også mot en adresse som skulle gi 404, for å være sikker på at det ikke var måleren som var ødelagt. Det var en nyttig vane, for den første versjonen min var ødelagt: den sendte adressene gjennom xargs, og xargs tolker apostrofer. Den første URL-en med en apostrof i seg stoppet hele kjøringen med unterminated quote og exit-kode 1. Resten ble aldri sjekket. Siden kommandoen bare skriver ut det som ikkesvarer med 200, så en død kjøring ut som en kjøring uten funn.

Feilen ligger ikke i setningen

Hvert avsnitt tålte en gjennomlesning. En lenke med en troverdig tittel bak seg ser riktig ut i den setningen den står i. Først når du samler alle lenkene i én liste og sjekker dem maskinelt, kommer hullet fram.

Tenk deg en kodebase der ingen enkelt PR ser gal ut. Det er den 200. som avslører at ingen har skrevet en test som kan feile, at samme hjelpefunksjon nå finnes i fire varianter, og at alle feilmeldingene har blitt like høflige og like innholdsløse.

Volumet har flyttet flaskehalsen dit gjennomlesningen ikke rekker. Velg derfor noen få tall du kan hente ut med én kommando, og se på dem jevnlig. Jeg har ikke kjørt disse lenge nok til å påstå noe om effekten, men det er de tre jeg begynte med:

• Testfiler uten en eneste assertion. grep -rLE 'assert|expect' --include='*test*' src – juster mønsteret etter språk, ellers teller du med alt som bruker Assert.That eller tabelldrevne tester. Generert kode kommer med tester som går grønt. Det er ikke det samme som tester som fanger noe.
• Duplisering i kodebasen. jscpd finner kopiert kode, ikke omskrevet kode – og kopiering er det volumet består av.GitClears egen måling av 211 millioner endrede linjer fant at andelen kopierte linjer steg fra 8,3 % i 2021 til 12,3 % i 2024. Husk å sette en --threshold; uten den avslutter jscpd med kode 0 uansett hva den finner.
• Nye direkte avhengigheter, rett ut av lockfilen. Modeller finner på pakkenavn. I en studie fra USENIX Security av 576 000 kodesnutter fra 16 modeller var andelen hallusinerte pakker minst 5,2 % for de kommersielle modellene og 21,7 % for de åpne.

Da jeg faktasjekket meg selv

To påstander var gale, og den tredje var riktig, men belagt med feil kilde. Ingen av dem hadde jeg tvilt på. Lenkene under er kildene, sjekket 25. august 2026:

• Jeg skrev at GitHubs push protection er gratis. Den står på som standard for din egen konto, men bare mot offentlige repoer (docs). Slår du den på for et helt repo, krever den GitHub Secret Protection – som må kjøpes for private og interne repoer (docs). Et team kunne ha innrettet seg etter en kontroll det ikke har.
• Jeg brukte nummereringen fra 2021 i OWASP Top 10. I 2025-utgaven gikk Security Misconfiguration fra A05 til A02, to nye kategorier kom til, og SSRF ble innlemmet i Broken Access Control.
• Jeg brukte FIRSTs EPSS-forside som kilde for et tall om utnyttede sårbarheter. Tallet står ikke der. Det står i FAQ-en, og det sier noe langt mer avgrenset enn jeg gjenga: EPSS observerer forsøk på utnyttelse av omtrent 2,5–3 % av publiserte CVE-er i et gitt 30-dagersvindu. En leser som fulgte lenken min, ville verken ha funnet tallet eller forbeholdet.

Skriver du om et rammeverk, en rangering eller en prisplan: sjekk den uka du publiserer, ikke uka du skrev.

Og hver rettelse skapte nye feil

Jeg gikk flere runder. I runde tre fant jeg åtte problemer, og to av dem kom fra rettelsene i runde to – samme feil som runden før hadde ryddet opp i. Du griper etter en kilde som nesten dekker påstanden, og sjekker ikke hvor godt den faktisk dekker. Så gjør du det på nytt, i selve rettelsen av forrige feil.

Rettelsen av generert kode skrives ofte på samme måte som feilen den retter.

Så en verifiseringsrunde er ikke ferdig fordi den fant noe. Den er ferdig når en runde ikke finner noe nytt.

Ingen ser den jobben

Kontrollen som fanget de sju adressene, ble aldri til en commit eller en demo. Den er bare grunnen til at noe ikke sprakk et halvår senere. Den står ikke i noen stillingsbeskrivelse. Belønningen er fravær av bråk.

Det er den samme jobben du gjør når du lander en beslutning ingen andre orket å ta, eller stiller det ubehagelige spørsmålet i en review klokka halv fem.

Misha Tryndiuk er tech lead. «Det tause ansvaret» starter tirsdag 1. september på tauseansvaret.no – to tekster i uka om den delen av tech lead-jobben som ikke synes, på norsk og engelsk.

‍