Først brugte de ChatGPT til at reducere omkostningerne. Så hyrede de os til at rydde op i AI's tekniske gæld.

Philip Tihonovich

29 maj 2025 10 min læsning

Du vil blive overrasket over, hvor mange virksomheder der gør det nu.

Som rapporter fra hele branchen viser, er der nu en voksende specialiseret sektor for ingeniører, der fokuserer på at rette AI-genererede kodefejl.

Mønsteret er blevet bemærkelsesværdigt konsekvent. Virksomheder henvender sig til ChatGPT for at generere migreringsscripts, integrationer eller hele funktioner i håb om at spare tid og reducere omkostningerne. Når alt kommer til alt, virker teknologien hurtig og tilgængelig.

Så svigter systemerne.

Og de ringer til os.

På det seneste har vi fået flere og flere af disse forespørgsler. Ikke for at sende et nyt produkt, men for at løse op for det rod, der blev efterladt, efter at nogen stolede på en sprogmodel med deres produktionskode.

På dette tidspunkt begynder det at ligne sin egen nicheindustri. At rette AI-genererede fejl er nu en fakturerbar service. Og i nogle tilfælde en meget dyr en af slagsen.

GitClear's 2024-rapport bekræfter, hvad vi har set hos kunderne: AI-kodningsværktøjer fremskynder levering, men fremmer også duplikering, reducerer genbrug og øger de langsigtede vedligeholdelsesomkostninger.

I et tilfælde kom en kunde til os, efter at en AI-genereret migrering havde tabt kritiske kundedata. Vi brugte 30 timer på at genskabe det tabte, omskrive logikken fra bunden og rydde op i pipelinen. Det ironiske er, at det ville have været billigere at få en seniorudvikler til at skrive det på den gammeldags måde.

Men lad os gøre det klart, at vi ikke er "imod AI". Vi bruger den også. Og det er nyttigt i den rigtige sammenhæng, med de rigtige sikkerhedsforanstaltninger. Men det, der frustrerer mig ved den overdrevne afhængighed af AI og dens udbredte konsekvenser - og sikkert også dig - er den magiske tankegang. Ideen om, at en sprogmodel kan erstatte rigtigt ingeniørarbejde.

Det kan den ikke. Og som man siger: Beviset ligger i buddingen. Når virksomheder foregiver noget andet, ender de med at betale nogen som os for at rydde op.

Så hvordan ser et af disse oprydningsjobs ud? Her er, hvad AI-afficionados ikke fortæller dig, når det drejer sig om tabt tid og spildte penge.

Sådan ser en typisk anmodning ud

Beskeden kommer som regel sådan her:

"Hej, kan du tage et kig på en mikroservice, vi har bygget? Vi brugte ChatGPT til at generere den første version. Vi skubbede den til staging, og nu er vores RabbitMQ-kø helt oversvømmet."

Det starter altid i det små. En opgave, der virkede for kedelig eller tidskrævende. Noget som at parse en CSV, omskrive et cron-job eller tilslutte en simpel webhook. Så de overlader det til en sprogmodel og håber på det bedste.

Men sagen er, at symptomerne viser sig meget senere. Nogle gange flere dage senere. Og når de gør det, er det sjældent indlysende, at den grundlæggende årsag var AI-genereret kode. Det ser bare ud som om... noget er galt.

"Man kan ikke outsource arkitektonisk tænkning til en sprogmodel. AI kan fremskynde tingene, men det kræver stadig ingeniører at bygge systemer, der ikke falder fra hinanden under pres."

Dmitry Nazarevich

Teknisk chef

Efter et dusin af disse tilfælde begynder der at tegne sig et mønster:

Ingen test. Overhovedet ikke. Ikke engang en hello-world assert. Bare rå, spekulativ kode, som aldrig er blevet trænet ordentligt.
Ingen bevidsthed om systemgrænser. Vi har set ChatGPT-scripts, der forespørger tre mikrotjenester synkront, ignorerer timeouts og sprænger hele opkaldskæden i luften ved den første fejl.
Misbrug af transaktioner. En kunde brugte AI-genereret SQL med indlejrede transaktioner i en Node.js-service ved hjælp af Knex. Det virkede, indtil det ikke gjorde, og halvdelen af skrivningerne mislykkedes lydløst.
Subtile løbsbetingelser. Især i flertrådede eller async-tunge kodebaser. Den slags fejl, som ikke dukker op i udviklingsafdelingen, men som ødelægger produktionen i stor skala.

Og når alting kollapser, efterlader AI dig selvfølgelig ikke en kommentar, hvor der står: "Forresten, jeg gætter her."

Den del er dit ansvar.

Case 1: Migreringsscriptet, der stille og roligt tabte kundedata

Denne kom fra en hurtigtvoksende fintech-virksomhed.

De var i gang med at udrulle en ny version af deres kundedatamodel, som opdelte et stort JSONB-felt i Postgres i flere normaliserede tabeller. Ganske almindelige ting. Men med stramme deadlines og ikke nok hænder besluttede en af udviklerne at "fremskynde tingene" ved at bede ChatGPT om at generere et migrationsscript.

Det så godt ud på overfladen. Scriptet analyserede JSON, udtrak kontaktoplysninger og indsatte dem i en ny user_contacts bord.

Så de kørte det.

Ingen prøvekørsel. Ingen backup. Direkte ind i staging, som, viste det sig, delte data med produktionen gennem en replika.

Et par timer senere begyndte kundesupporten at få e-mails. Brugere modtog ikke betalingsmeddelelser. Andre manglede telefonnumre i deres profiler. Så ringede de til os.

Hvad der gik galt

Vi sporede problemet til scriptet. Det lavede det grundlæggende udtræk, men det gjorde tre fatale antagelser:

Den håndterede ikke NULL værdier eller manglende nøgler i JSON-strukturen.
Den indsatte delvise poster uden validering.
Den brugte ON CONFLICT DO NOTHING, så alle mislykkede indsættelser blev ignoreret.

Resultat: om 18% af kontaktdataene var enten tabt eller beskadiget. Ingen logfiler. Ingen fejlmeddelelser. Bare et stille datatab.

Hvad der skulle til for at fikse det

Vi satte et lille team til at rede trådene ud. Her er, hvad vi gjorde:

Diagnose og replikation (4 timer) Vi genskabte scriptet i et sandkassemiljø og kørte det mod et snapshot af databasen. På den måde bekræftede vi problemet og kortlagde præcist, hvad der manglede.
Retsmedicinsk datarevision (8 timer) Vi sammenlignede den ødelagte tilstand med sikkerhedskopier, identificerede alle poster med manglende eller delvise data og matchede dem med hændelseslogfiler for at spore, hvilke indsættelser der mislykkedes, og hvorfor.
Omskrivning af migrationslogikken (12 timer) Vi omskrev hele scriptet i Python, tilføjede fuld valideringslogik, byggede en rollback-mekanisme og integrerede det i kundens CI-pipeline. Denne gang inkluderede det tests og understøttelse af dry-run.
Manuel datagendannelse (6 timer) Nogle poster kunne ikke genskabes fra sikkerhedskopier. Vi hentede manglende felter fra eksterne systemer (deres CRM- og e-mailudbyder-API'er) og gendannede resten manuelt.

Samlet tid: 30 ingeniørtimer

To ingeniører, tre dage. Omkostninger for kunden: omkring $4,500 i servicegebyrer.

Men det største tab kom fra kunderne. Mislykkede notifikationer førte til manglende betalinger og kundeafgang. Kunden fortalte os, at de brugte mindst $10,000 på supportbilletter, SLA-kompensation og goodwill-kreditter på grund af det ene kiksede script.

Det ironiske er, at en seniorudvikler kunne have skrevet den korrekte migrering på måske fire timer. Men løftet om AI-hastighed endte med at koste dem to ugers oprydning og skade på omdømmet.

Vi reparerer det, som ChatGPT ødelagde - og bygger det, som det ikke kunne.

Case 2: API-klienten, der ignorerede hastighedsgrænser og ødelagde produktionen

Denne kom fra en legal tech-startup, der bygger en dokumenthåndteringsplatform til advokatfirmaer. En af deres kernefunktioner var at integrere med en offentlig e-notifikationstjeneste - en tredjeparts REST API med OAuth 2.0 og streng hastighedsbegrænsning: 50 anmodninger pr. minut, ingen undtagelser.

I stedet for at overlade integrationen til en erfaren backend-udvikler besluttede nogen i teamet at "prototype" den ved hjælp af ChatGPT. De indtastede OpenAPI-specifikationen, bad om en Python-klient og fik et rent script med requests, genforsøgslogik ved hjælp af tenacity, og opdatering af token.

Det så solidt ud på papiret. Så de sendte den af sted.

Hvad der gik galt

Til at begynde med virkede alt fint. Klienten håndterede individuelle anmodninger korrekt, klarede autentificering og forsøgte endda igen ved fejl. Men under brug i den virkelige verden, især under belastning, begyndte platformen at opføre sig uforudsigeligt.

Her er, hvad der faktisk skete:

Ingen respekt for takstgrænser. Den genererede kode læste eller fortolkede ikke X-RateLimit-Remaining eller Retry-After overskrifter. Den blev bare ved med at sende forespørgsler i blinde.
Nye forsøg gjorde tingene værre. Da der begyndte at komme 429 fejl tilbage, prøvede tenacity-dekoratoren dem automatisk igen. Ingen jitter. Ingen kø. Bare en strøm af opfølgningsanmodninger.
API-udbyderen blokerede midlertidigt deres IP. I tre timer kunne ingen på platformen synkronisere dokumenter. Ingen logs, ingen advarsler. Bare en stille fejl.

Det var ikke et one-line fix. Det var en misforståelse af, hvordan produktionssystemer opfører sig. Og det er et godt eksempel på, hvad LLM'er ikke ved; ikke fordi de er i stykker, men fordi de ikke har runtime awareness.

Stop med at patche AI-genereret kode i prod - bring os ind, før det går i stykker.

Sådan har vi løst det

Spor og isoler fejlen (6 timer) Vi tilføjede middleware til at inspicere udgående trafik og bekræftede oversvømmelsen af anmodninger under spidsbelastning. Vi genskabte også fejlen i staging for fuldt ud at forstå det udløsende mønster.
Genopbyg API-klienten (10 timer) Vi omskrev klienten ved hjælp af httpx.AsyncClient, implementerede en semaforbaseret throttle, tilføjede eksponentiel backoff med jitter og håndterede korrekt Retry-After og rate-limit headers.
Stresstest og validering (6 timer) Vi simulerede brug i den virkelige verden med tusindvis af samtidige anmodninger ved hjælp af Locust, testede hastighedsdæmpning under forskellige burst-scenarier og bekræftede nul 429'ere under vedvarende belastning.
Tilføj overvågning og alarmering (4 timer) Vi opsatte brugerdefinerede Prometheus-målinger for at spore API-brug pr. minut og tilføjede advarsler for at underrette teamet, hvis de nærmede sig tærskler for hastighed.

Samlet tid: 26 timer

To ingeniører, fordelt på to en halv dag. Omkostninger for kunden: omkring $3,900.

Det største problem er, at deres største kunde - et advokatfirma med tidsfølsomme ansøgninger - gik glip af to vinduer til indsendelse til retten på grund af nedbruddet. Kunden var nødt til at begrænse skaden og tilbyde en rabat for at beholde kontoen.

Alt sammen fordi en sprogmodel ikke forstod forskellen mellem "arbejdskode" og "produktionsklar kode". Og lige pludselig blev endnu et lag af AI teknisk gæld stille og roligt føjet til stakken.

Hvorfor det bliver ved med at ske

Det skræmmende er ikke, at disse ting går galt. Det er, hvor forudsigeligt det hele er blevet.

Hver eneste af disse hændelser følger det samme mønster. En udvikler beder ChatGPT om en kodestump. Den returnerer noget, der fungerer lige godt nok til ikke at give fejl. De sætter det ind i systemet, rydder måske lidt op i det og sender det ud i den tro, at hvis det kompilerer og kører, må det være sikkert.

Men der er en hage ved det: Store sprogmodeller kender ikke dit system.
De ved ikke, hvordan dine tjenester spiller sammen.
De kender ikke dit latency-budget, din implementerings-pipeline, din observationsopsætning eller dine trafikmønstre i produktionen.

De genererer den kode, der ser mest sandsynlig ud, baseret på mønstre i deres træningsdata. Det er det hele. Der er ingen bevidsthed. Ingen garantier. Ingen intuition for systemdesign.

Og det afspejler sig ofte i resultatet:

Kode, der virker én gang, men fejler under belastning
Ingen defensiv programmering, ingen fejlsikringer
Dårlig forståelse af begrænsninger i den virkelige verden som hastighedsbegrænsninger, timeouts eller eventuel konsistens
Absolut ingen fornemmelse af arkitektonisk hensigt

Det værste er, at koden ser korrekt ud. Den er syntaktisk ren. Den består linters. Den er måske endda dækket af en grundlæggende test. Men den mangler den ene ting, der rent faktisk betyder noget: kontekst.

Det er derfor, disse fejl ikke dukker op med det samme. De venter på udrulning fredag aften, på vinduer med meget trafik, på sjældne tilfælde. Sådan er den tekniske gæld i AI - den er usynlig, indtil den ødelægger noget kritisk.

Når AI faktisk hjælper

Som vi nævnte tidligere, bruger vi også AI. Stort set alle ingeniører i vores team har en Copilot-lignende opsætning kørende lokalt. Det er hurtigt, hjælpsomt og helt ærligt en god måde at springe de kedelige dele over på.

Men her er forskellen: Intet kommer ind i hovedgrenen uden at gå gennem en senioringeniør og i de fleste tilfælde en CI-pipeline, der ved, hvad den skal kigge efter.

LLM'er er gode til det:

stillads-boilerplate til nye tjenester eller API-slutpunkter,
generere testdækning for eksisterende logik,
hjælpe med gentagen refaktorering på tværs af store kodebaser,
oversætter simple shell-scripts til infrastruktur-som-kode-skabeloner,
eller endda sammenligne algoritmiske tilgange, som vi allerede kender.

Hvad de er ikke god til, er design. Eller kontekst. Eller sikre standardindstillinger.

Derfor har vi bygget vores workflows til at behandle LLM-output som forslag, ikke som en kilde til sandhed. Sådan ser det ud i praksis:

Vi tagger alle AI-genererede commits, så de er nemme at spore og gennemgå.
Vores redaktører har inline-prompter, men med tvungne pre-commit hooks, der blokerer alt uden test eller dokumentation.
Vores CI indeholder regler for statisk analyse, der markerer usikre mønstre, som vi har set før fra LLM'er: ting som ubeskyttede gentagelser, uskadeliggjorte timeouts, naiv JSON-parsing eller usikker SQL-håndtering.
Hver pull-anmodning med LLM-genereret kode gennemgår en obligatorisk menneskelig gennemgang, som regel af en senior, der forstår domænelogikken og risikooverfladen.

Brugt rigtigt er det tidsbesparende. Brugt i blinde er det en tidsindstillet bombe.

Hvad vi anbefaler til CTO'er

Vi er her ikke for at fortælle dig, at du skal forbyde AI-værktøjer. Det skib er sejlet.

Men at give en sprogmodel commit-adgang? Det er bare at bede om problemer.

Her er, hvad vi anbefaler i stedet:

1. Behandl LLM'er som værktøjer, ikke som ingeniører

Lad dem hjælpe med gentagen kode. Lad dem foreslå løsninger. Men Stol ikke på dem med kritiske beslutninger. Enhver kode, der genereres af AI, skal gennemgås af en senioringeniør, ingen undtagelser.

2. Gør LLM-genereret kode sporbar

Uanset om det er commit-tags, metadata eller kommentarer i koden, gør det klart, hvilke dele der kom fra AI. Det gør det lettere at revidere, fejlfinde og forstå risikoprofilen senere.

3. Definér en generationspolitik

Beslut som et team, hvor det er acceptabelt at bruge LLM'er, og hvor det ikke er. Standardtekst? Selvfølgelig. Auth-flow? Ja, måske. Transaktionelle systemer? Absolut ikke uden gennemgang. Gør politikken eksplicit og en del af dine tekniske standarder.

4. Tilføj overvågning på DevOps-niveau

Hvis du lader AI-genereret kode komme i kontakt med produktionen, er du nødt til at antage, at noget vil gå i stykker på et tidspunkt. Tilføj syntetiske kontroller. Overvågning af hastighedsbegrænsning. Sporing af afhængigheder. Gør det usynlige synligt, især når den oprindelige forfatter ikke er et menneske.

5. Byg med henblik på genoprettelse

De største AI-drevne fejl, vi har set, kom ikke fra "dårlig" kode. De kom fra stille fejl - manglende data, ødelagte køer, genforsøgsstorme - som ikke blev opdaget i timevis. Invester i observerbarhed, fallback-logik og rollbacks. Især hvis du lader ChatGPT skrive migreringer.

Kort sagt kan AI spare dit team for tid, men den kan ikke tage ansvar.

Det er stadig et menneskeligt job.

Afsluttende tanker: AI ≠ softwareingeniører

AI kan hjælpe dig med at bevæge dig hurtigere. Men den kan ikke tænke for dig.

Den forstår ikke din arkitektur. Den ved ikke, hvad "færdig" betyder i din sammenhæng. Og den er helt sikkert ligeglad med, om din datapipeline stille og roligt går i stykker en fredag aften.

Derfor skal vi som CTO'er holde fokus på systemets modstandsdygtighed, ikke bare på hastighed.

Det er fristende at lade AI håndtere de kedelige dele. Og nogle gange er det fint. Men alle genveje kommer med en ulempe. Når AI-genereret kode slipper ukontrolleret igennem, bliver det ofte til AI-teknisk gæld. Den slags, du ikke ser, før dit ops-team er i gang med brandslukning i produktionen.

Hvis du allerede er løbet ind i den mur, er du ikke alene. Vi har hjulpet teams med at komme sig over alt fra ødelagte migreringer til API-katastrofer. Vi refaktoriserer ikke bare koden. Vi hjælper med at refaktorere tankegangen bag den.

For i sidste ende er det faktisk det, der gør systemerne pålidelige.

Philip Tikhanovich

Leder af afdelingen for Python, Big Data, ML/DS/AI

Philip bringer skarpt fokus på alt, hvad der har med data og AI at gøre. Det er ham, der stiller de rigtige spørgsmål tidligt, opstiller en stærk teknisk vision og sørger for, at vi ikke bare bygger smarte systemer - vi bygger de rigtige, så de giver reel forretningsværdi.

Læs mere om det

Indholdsfortegnelse

Kontakt os

Book et opkald eller udfyld formularen nedenfor, så vender vi tilbage til dig, når vi har behandlet din anmodning.

Navn

Virksomhed

E-mail

Telefon

Besked

Send os en talebesked

Vedhæft dokumenter

Upload fil

Du kan vedhæfte 1 fil på op til 2 MB. Gyldige filformater: pdf, jpg, jpeg, png.

Ved at klikke på Send accepterer du, at Innowise behandler dine personlige data i henhold til vores Politik for beskyttelse af personlige oplysninger for at give dig relevante oplysninger. Ved at indsende dit telefonnummer accepterer du, at vi kan kontakte dig via taleopkald, sms og beskedapps. Opkalds-, besked- og datatakster kan være gældende.

Du kan også sende os din anmodning
til contact@innowise.com

Hvad sker der nu?

Når vi har modtaget og behandlet din anmodning, vender vi tilbage til dig for at beskrive dine projektbehov og underskriver en NDA for at sikre fortrolighed.

Når vi har undersøgt dine ønsker, behov og forventninger, udarbejder vores team et projektforslag med forslag med arbejdets omfang, teamstørrelse, tids- og omkostningsoverslag.

Vi arrangerer et møde med dig for at diskutere tilbuddet og få detaljerne på plads.

Til sidst underskriver vi en kontrakt og begynder at arbejde på dit projekt med det samme.