Først brukte de ChatGPT for å kutte kostnader. Så hyret de oss til å rydde opp i den tekniske gjelden AI

Philip Tihonovich

29 mai 2025 10 min lesing

Du vil bli overrasket over hvor mange selskaper som gjør dette nå.

Rapporter fra hele bransjen tyder på at det nå finnes en voksende spesialisert sektor for ingeniører som fokuserer på å korrigere AI-genererte kodefeil.

Mønsteret har blitt bemerkelsesverdig konsekvent. Bedrifter henvender seg til ChatGPT for å generere migreringsskript, integrasjoner eller hele funksjoner, i håp om å spare tid og kutte kostnader. Teknologien virker tross alt rask og tilgjengelig.

Da svikter systemene.

Og de ringer oss.

I det siste har vi fått flere og flere slike forespørsler. Ikke for å levere et nytt produkt, men for å rydde opp i rotet som ble etterlatt etter at noen stolte på en språkmodell med produksjonskoden sin.

Nå begynner det å se ut som en egen nisjebransje. Å fikse AI-genererte feil er nå en fakturerbar tjeneste. Og i noen tilfeller en svært kostbar en.

GitClears rapport for 2024 bekrefter det vi har sett hos kundene: AI-kodingsverktøyene gjør det raskere å levere, men de bidrar også til duplisering, reduserer gjenbruk og øker de langsiktige vedlikeholdskostnadene.

I ett tilfelle kom en kunde til oss etter at en AI-generert migrering hadde ført til at kritiske kundedata gikk tapt. Vi brukte 30 timer med å gjenopprette det som gikk tapt, skrive om logikken fra bunnen av og rydde opp i pipelinen. Det ironiske er at det hadde vært billigere å få en seniorutvikler til å skrive det på den gammeldagse måten.

Men la det være klart: Vi er ikke "mot AI". Vi bruker det også. Og det er nyttig i riktig sammenheng, med de rette sikkerhetsreglene. Men det som frustrerer meg - og sannsynligvis deg også - er den magiske tankegangen som ligger bak den overdrevne tiltroen til AI og dens utbredte implikasjoner. Ideen om at en språkmodell kan erstatte ekte ingeniørarbeid.

Det kan det ikke. Og som man sier, beviset ligger i puddingen. Når selskaper later som noe annet, ender de opp med å betale noen som oss for å rydde opp.

Hvordan ser en av disse oppryddingsjobbene ut? Dette er hva AI-afficionados ikke forteller deg når det gjelder tapt tid og bortkastede penger.

Slik ser en typisk forespørsel ut

Meldingen kommer vanligvis inn slik:

"Hei, kan du ta en titt på en mikrotjeneste vi har bygget? Vi brukte ChatGPT til å generere den første versjonen. Vi sendte den til staging, og nå er RabbitMQ-køen vår helt oversvømt."

Det begynner alltid i det små. En oppgave som virker for kjedelig eller tidkrevende. Som å analysere en CSV-fil, omskrive en cron-jobb eller koble opp en enkel webhook. Så de overlater det til en språkmodell og håper på det beste.

Men her er saken: Symptomene dukker opp mye senere. Noen ganger flere dager senere. Og når de gjør det, er det sjelden åpenbart at årsaken er AI-genererte koder. Det ser bare ut som... noe er galt.

"Du kan ikke outsource arkitektonisk tenkning til en språkmodell. AI kan gjøre ting raskere, men det kreves fortsatt ingeniører for å bygge systemer som ikke faller fra hverandre under press."

Dmitry Nazarevich

Teknisk sjef

Etter et dusin av disse tilfellene begynner det å avtegne seg et mønster:

Ingen tester. I det hele tatt. Ikke engang en "hallo verden"-bekreftelse. Bare rå, spekulativ kode som aldri ble brukt skikkelig.
Ingen bevissthet om systemgrenser. Vi har sett ChatGPT-skript som spør tre mikrotjenester synkront, ignorerer tidsavbrudd og sprenger hele anropskjeden ved første feil.
Misbruk av transaksjoner. En klient brukte AI-generert SQL med nestede transaksjoner i en Node.js-tjeneste ved hjelp av Knex. Det fungerte, helt til det ikke gjorde det, og halvparten av skrivingene mislyktes i det stille.
Subtile løpsbetingelser. Spesielt i flertrådede eller asynk-tunge kodebaser. Den typen feil som ikke dukker opp under utvikling, men som ødelegger produksjonen i stor skala.

Og når alt kollapser, legger selvfølgelig ikke AI igjen en kommentar som sier: "Forresten, jeg gjetter her."

Det er ditt ansvar.

Case 1: Migreringsskriptet som i all stillhet mistet kundedata

Denne kom fra et raskt voksende fintech-selskap.

De var i ferd med å lansere en ny versjon av kundedatamodellen sin, der ett stort JSONB-felt i Postgres ble delt opp i flere normaliserte tabeller. Ganske vanlige greier. Men med stramme tidsfrister og ikke nok hender, bestemte en av utviklerne seg for å "fremskynde ting" ved å be ChatGPT om å generere et migreringsskript.

Det så bra ut på overflaten. Skriptet analyserte JSON, hentet ut kontaktinformasjon og satte den inn i en ny user_contacts bord.

Så de kjørte det.

Ingen prøvekjøring. Ingen backup. Rett inn i staging, som viste seg å dele data med produksjonen gjennom en replika.

Noen timer senere begynte kundeservice å få e-poster. Brukere mottok ikke betalingsvarsler. Andre manglet telefonnummer i profilene sine. Det var da de ringte oss.

Hva som gikk galt

Vi sporet problemet til skriptet. Det gjorde det grunnleggende uttrekket, men det gjorde tre fatale antakelser:

Den taklet ikke NULL verdier eller manglende nøkler i JSON-strukturen.
Den satte inn delvise poster uten validering.
Den brukte ON CONFLICT DO NOTHING, så alle mislykkede innsettinger ble ignorert.

Resultat: om 18% av kontaktdataene var enten tapt eller ødelagt. Ingen logger. Ingen feilmeldinger. Bare stille tap av data.

Hva som måtte til for å fikse

Vi satte ned et lite team for å rydde opp i rotet. Her er hva vi gjorde:

Diagnostisering og replikasjon (4 timer) Vi gjenskapte skriptet i et sandkassemiljø og kjørte det mot et øyeblikksbilde av databasen. Slik fikk vi bekreftet problemet og kartlagt nøyaktig hva som manglet.
Kriminalteknisk datarevisjon (8 timer) Vi sammenlignet den ødelagte tilstanden med sikkerhetskopier, identifiserte alle poster med manglende eller ufullstendige data og matchet dem mot hendelseslogger for å spore hvilke innsettinger som mislyktes og hvorfor.
Omskriving av migreringslogikken (12 timer) Vi skrev om hele skriptet i Python, la til full valideringslogikk, bygget en tilbakeføringsmekanisme og integrerte det i kundens CI-pipeline. Denne gangen inkluderte det tester og støtte for tørrkjøring.
Manuell gjenoppretting av data (6 timer) Noen poster kunne ikke gjenopprettes fra sikkerhetskopier. Vi hentet manglende felt fra eksterne systemer (CRM- og e-postleverandør-API-er) og gjenopprettet resten manuelt.

Total tid: 30 ingeniørtimer

To ingeniører, tre dager. Kostnad for kunden: ca. $4,500 in service fees.

But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.

The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.

Vi fikser det ChatGPT ødela - og bygger det den ikke kunne.

Case 2: API-klienten som ignorerte hastighetsbegrensninger og ødela produksjonen

Denne kom fra en oppstartsbedrift innen juridisk teknologi som bygger en dokumenthåndteringsplattform for advokatfirmaer. En av kjernefunksjonene deres var å integrere med en statlig e-varslingstjeneste - et tredjeparts REST API med OAuth 2.0 og streng hastighetsbegrensning: 50 forespørsler per minutt, uten unntak.

I stedet for å overlate integrasjonen til en erfaren backend-utvikler, bestemte noen i teamet seg for å lage en "prototype" ved hjelp av ChatGPT. De la inn OpenAPI-spesifikasjonen, ba om en Python-klient og fikk et rent skript med requests, prøv på nytt-logikk ved hjelp av tenacity, og tokenoppdatering.

Så solid ut på papiret. Så de sendte det.

Hva som gikk galt

Til å begynne med virket alt bra. Klienten håndterte individuelle forespørsler korrekt, godkjente autentisering og prøvde til og med på nytt ved feil. Men under reell bruk, spesielt under belastning, begynte plattformen å oppføre seg uforutsigbart.

Her er hva som faktisk skjedde:

Ingen respekt for takstgrenser. Den genererte koden leste eller tolket ikke X-RateLimit-Remaining eller Retry-After overskrifter. Den fortsatte bare å sende forespørsler i blinde.
Nye forsøk gjorde ting verre. Da 429-feilene begynte å komme tilbake, prøvde tenacity-dekoratoren dem automatisk på nytt. Ingen jitter. Ingen kø. Bare en flom av oppfølgingsforespørsler.
API-leverandøren blokkerte IP-en deres midlertidig. I tre timer kunne ingen på plattformen synkronisere dokumenter. Ingen logger, ingen varsler. Bare en stille feil.

Dette var ikke en enkel løsning. Det var en misforståelse av hvordan produksjonssystemer oppfører seg. Og det er et godt eksempel på hva LLM-er ikke vet; ikke fordi de er ødelagte, men fordi de ikke har kjøretidsbevissthet.

Slutt å lappe AI-generert kode i prod - ta oss med før den går i stykker.

Slik fikset vi det

Spore og isolere feilen (6 timer) Vi la til mellomvare for å inspisere utgående trafikk og fikk bekreftet flommen av forespørsler under toppbelastning. Vi gjenskapte også feilen i staging for å forstå det utløsende mønsteret fullt ut.
Gjenoppbygge API-klienten (10 timer) Vi skrev om klienten ved hjelp av httpx.AsyncClient, implementerte en semaforbasert struping, la til eksponentiell backoff med jitter, og håndterte Retry-After og hastighetsbegrensningshoder.
Stresstest og validering (6 timer) Vi simulerte virkelig bruk med tusenvis av samtidige forespørsler ved hjelp av Locust, testet hastighetsbegrensning under ulike burst-scenarioer og bekreftet null 429s under vedvarende belastning.
Legg til overvåking og varsling (4 timer) Vi satte opp egendefinerte Prometheus-beregninger for å spore API-bruk per minutt, og la til varsler for å varsle teamet hvis de nærmet seg terskelverdiene.

Total tid: 26 timer

To ingeniører, fordelt på to og en halv dag. Kostnad for kunden: ca. $3,900.

Det største problemet var at deres største kunde - et advokatfirma med tidssensitive innleveringer - gikk glipp av to innsendingsvinduer på grunn av strømbruddet. Kunden måtte begrense skaden og tilby en rabatt for å beholde kontoen.

Alt fordi en språkmodell ikke forsto forskjellen mellom "fungerende kode" og "produksjonsklar kode". Og vips, så ble enda et lag med AI-teknisk gjeld lagt til i det stille.

Hvorfor dette fortsetter å skje

The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.

Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.

But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.

They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.

And the output often reflects that:

Kode som fungerer én gang, men som feiler under belastning
Ingen defensiv programmering, ingen feilsikringer
Dårlig forståelse av begrensninger i den virkelige verden, som f.eks. hastighetsbegrensninger, tidsavbrudd eller eventuell konsistens
Absolutt null sans for arkitektonisk intensjon

Det verste er at koden ser korrekt ut. Den er syntaktisk ren. Den passerer linters. Den kan til og med være dekket av en grunnleggende test. Men den mangler det eneste som faktisk betyr noe: kontekst.

Det er derfor disse feilene ikke dukker opp med en gang. De venter til fredagskvelder, til vinduer med høy trafikk, til sjeldne tilfeller. Det er slik AI teknisk gjeld er - den er usynlig helt til den ødelegger noe kritisk.

Når AI faktisk hjelper

As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.

But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.

LLMs are great at:

stillasbygging for nye tjenester eller API-endepunkter,
generere testdekning for eksisterende logikk,
hjelper til med repeterende refaktorisering på tvers av store kodebaser,
oversetter enkle skallskript til infrastruktur-som-kode-maler,
eller til og med sammenligne algoritmiske tilnærminger vi allerede forstår.

Hva de er ikke er god på er design. Eller kontekst. Eller trygge standardinnstillinger.

Derfor har vi bygget opp arbeidsflytene våre slik at de behandler LLM-resultatene som forslag, ikke som en sannhetskilde. Slik ser det ut i praksis:

Vi tagger alle AI-genererte kommitteringer slik at de er enkle å spore og gjennomgå.
Redaktørene våre har innebygde ledetekster, men med påtvungne pre-commit-kroker som blokkerer alt uten tester eller dokumentasjon.
Vår CI inneholder regler for statisk analyse som flagger usikre mønstre vi har sett før fra LLM-er: ting som ubeskyttede gjentakelser, tidsavbrudd uten omfang, naiv JSON-parsing eller usikker SQL-håndtering.
Alle pull-forespørsler med LLM-generert kode går gjennom en obligatorisk menneskelig gjennomgang, vanligvis av en overordnet som forstår domenelogikken og risikooverflaten.

Brukt riktig er det tidsbesparende. Brukt i blinde er det en tidsinnstilt bombe.

Hva vi anbefaler til CTO-er

We’re not here to tell you to ban AI tools. That ship has sailed.

But giving a language model commit access? That’s just asking for trouble.

Here’s what we recommend instead:

1. Behandle LLM-er som verktøy, ikke som ingeniører

La dem hjelpe til med repeterende kode. La dem foreslå løsninger. Men ikke overlate kritiske beslutninger til dem. All kode som genereres av AI, skal gjennomgås av en senioringeniør, uten unntak.

2. Gjør LLM-generert kode sporbar

Enten det er commit-tagger, metadata eller kommentarer i koden, gjør det tydelig hvilke deler som kommer fra AI. Det gjør det enklere å revidere, feilsøke og forstå risikoprofilen i ettertid.

3. Definere en generasjonspolicy

Bestem i fellesskap hvor det er akseptabelt å bruke LLM-er, og hvor det ikke er det. Boilerplate? Ja visst. Autentiseringsflyt? Kanskje. Transaksjonssystemer? Absolutt ikke uten gjennomgang. Gjør retningslinjene eksplisitte og en del av dine tekniske standarder.

4. Legg til overvåking på DevOps-nivå

Hvis du lar AI-generert kode komme i kontakt med produksjon, må du anta at noe til slutt vil gå i stykker. Legg til syntetiske kontroller. Overvåk hastighetsbegrensninger. Avhengighetssporing. Gjør det usynlige synlig, spesielt når den opprinnelige forfatteren ikke er et menneske.

5. Bygg for gjenopprettbarhet

De største AI-drevne feilene vi har sett, kom ikke fra "dårlig" kode. De kom av stille feil - manglende data, ødelagte køer, stormer av nye forsøk - som ikke ble oppdaget på flere timer. Invester i observerbarhet, reservelogikk og tilbakeføringer. Spesielt hvis du lar ChatGPT skrive migreringer.

Kort sagt kan AI spare teamet ditt for tid, men den kan ikke ta ansvar.

Det er fortsatt en menneskelig jobb.

Avsluttende tanker: AI ≠ programvareingeniører

AI can help you move faster. But it can’t think for you.

It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.

That’s why, as CTOs, we need to stay focused on system resilience, not just speed.

It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.

If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.

Because in the end, that’s what actually makes systems reliable.

Philip Tikhanovich

Avdelingsleder for Python, Big Data, ML/DS/AI

Philip har et skarpt fokus på alt som har med data og AI å gjøre. Han er den som stiller de riktige spørsmålene tidlig, setter en sterk teknisk visjon og sørger for at vi ikke bare bygger smarte systemer - vi bygger de riktige, for å skape reell forretningsverdi.

Les mer

Innholdsfortegnelse

Kontakt oss

Bestill en samtale eller fyll ut skjemaet nedenfor, så kontakter vi deg når vi har behandlet forespørselen din.

Navn

Selskap

E-post

Telefon

Melding

Send oss en talemelding

Legg ved dokumenter

Last opp fil

Du kan legge ved én fil på opptil 2 MB. Gyldige filformater: pdf, jpg, jpeg, png.

Ved å klikke på Send, samtykker du til at Innowise behandler dine personopplysninger i henhold til våre Retningslinjer for personvern for å gi deg relevant informasjon. Ved å oppgi telefonnummeret ditt samtykker du i at vi kan kontakte deg via taleanrop, SMS og meldingsapper. Priser for samtaler, meldinger og data kan gjelde.

Du kan også sende oss en forespørsel
til contact@innowise.com

Hva skjer videre?

Når vi har mottatt og behandlet forespørselen din, tar vi kontakt med deg for å beskrive prosjektbehov og signerer en taushetserklæring for å sikre konfidensialitet.

Etter å ha undersøkt dine ønsker, behov og forventninger, utarbeider teamet vårt et prosjektforslag forslag med arbeidsomfang, teamstørrelse, tids- og kostnadsestimater.

Vi avtaler et møte med deg for å diskutere tilbudet og spikre detaljene.

Til slutt signerer vi en kontrakt og begynner å jobbe med prosjektet ditt med en gang.