Först använde de ChatGPT för att sänka kostnaderna. Sedan anlitade de oss för att städa upp den tekniska skulden AI

5 augusti 2025 10 min läsning

Sammanfatta artikeln med AI

Du skulle bli förvånad över hur många företag som gör detta nu.

Som rapporter från hela branschen visar finns det nu en växande specialiserad sektor för ingenjörer som fokuserar på att korrigera AI-genererade kodfel.

Mönstret har blivit anmärkningsvärt konsekvent. Företag vänder sig till ChatGPT för att generera migreringsskript, integrationer eller hela funktioner, i hopp om att spara tid och sänka kostnaderna. Tekniken verkar trots allt vara snabb och tillgänglig.

Då fallerar systemen.

Och de ringer oss.

På senare tid har vi fått fler och fler sådana förfrågningar. Inte för att leverera en ny produkt, utan för att reda ut den röra som blev kvar efter att någon litade på en språkmodell med sin produktionskod.

Vid det här laget börjar det se ut som en egen nischindustri. Att åtgärda AI-genererade buggar är nu en fakturerbar tjänst. Och i vissa fall en mycket dyr sådan.

GitClears rapport för 2024 bekräftar vad vi har sett hos kunder: AI-kodningsverktyg snabbar upp leveranserna, men driver också på duplicering, minskar återanvändningen och ökar de långsiktiga underhållskostnaderna.

I ett fall kom en kund till oss efter att en AI-genererad migrering tappat kritisk kunddata. Vi spenderade 30 timmar för att återställa det som gått förlorat, skriva om logiken från grunden och städa upp i pipelinen. Det ironiska är att det skulle ha varit billigare att låta en senior utvecklare skriva det på det gamla hederliga sättet.

Låt oss dock vara tydliga, vi är inte "emot AI". Vi använder det också. Och det är till hjälp i rätt sammanhang, med rätt skyddsräcken. Men det som frustrerar mig med övertro på AI och dess utbredda konsekvenser - och förmodligen dig också - är det magiska tänkandet. Tanken att en språkmodell kan ersätta verkligt ingenjörsarbete.

Det kan den inte. Och som ordspråket säger, beviset ligger i pudding. När företag låtsas något annat, slutar det med att de betalar någon som oss för att städa upp det.

Så, hur ser ett av dessa saneringsjobb ut? Det här är vad AI-afficionados inte berättar för dig när det gäller förlorad tid och bortkastade pengar.

Så här ser en typisk förfrågan ut

Meddelandet brukar komma in så här:

"Hej, kan du ta en titt på en mikrotjänst som vi byggt? Vi använde ChatGPT för att generera den första versionen. Vi skickade den till staging, och nu är vår RabbitMQ-kö helt översvämmad."

Det börjar alltid i det lilla. En uppgift som verkade för tråkig eller tidskrävande. Något som att analysera en CSV, skriva om ett cron-jobb eller koppla upp en enkel webhook. Så de överlämnar det till en språkmodell och hoppas på det bästa.

Men så här är det: symptomen dyker upp mycket senare. Ibland dagar senare. Och när de gör det är det sällan uppenbart att grundorsaken var AI-genererad kod. Det ser bara ut som om... något är fel.

"Man kan inte outsourca arkitektoniskt tänkande till en språkmodell. AI kan snabba upp saker och ting, men det krävs fortfarande ingenjörer för att bygga system som inte faller sönder under press."

Dmitry Nazarevich

Chief Technical Officer

Efter ett dussintal av dessa fall börjar mönster framträda:

Inga tester. Överhuvudtaget. Inte ens en hello-world assert. Bara rå, spekulativ kod som aldrig övades ordentligt.
Ingen medvetenhet om systemgränser. Vi har sett ChatGPT-skript som ställer frågor till tre mikrotjänster synkront, ignorerar timeouts och spränger hela anropskedjan vid första felet.
Missbruk av transaktioner. En kund använde AI-genererad SQL med nästlade transaktioner i en Node.js-tjänst med Knex. Det fungerade, tills det inte gjorde det, och hälften av skrivningarna misslyckades tyst.
Subtila tävlingsförhållanden. Speciellt i flertrådade eller async-tunga kodbaser. Den typ av buggar som inte dyker upp i utvecklingsavdelningen men som förstör produktionen i stor skala.

Och när allt kollapsar lämnar naturligtvis inte AI en kommentar där det står: "Förresten, jag gissar här."

Den biten är ditt fel.

Fall 1: Migrationsskriptet som i tysthet tappade bort kunddata

Den här kom från ett snabbväxande fintechbolag.

De rullade ut en ny version av sin kunddatamodell och delade upp ett stort JSONB-fält i Postgres i flera normaliserade tabeller. Ganska vanliga saker. Men med snäva tidsfrister och inte tillräckligt med händer bestämde sig en av utvecklarna för att "påskynda saker" genom att be ChatGPT att generera ett migreringsskript.

Det såg bra ut på ytan. Skriptet analyserade JSON, extraherade kontaktinformation och infogade den i en ny user_contacts bord.

Så de körde det.

Ingen provkörning. Ingen backup. Direkt in i staging, som visade sig dela data med produktionen via en replika.

Några timmar senare började kundsupporten få e-postmeddelanden. Användare fick inte betalningsmeddelanden. Andra saknade telefonnummer i sina profiler. Det var då de ringde oss.

Vad gick fel?

Vi spårade problemet till skriptet. Det gjorde den grundläggande extraktionen, men det gjorde tre fatala antaganden:

Den hanterade inte NULL värden eller saknade nycklar i JSON-strukturen.
Den infogade partiella poster utan validering.
Den använde ON CONFLICT DO NOTHING, så alla misslyckade inmatningar ignorerades i tysthet.

Resultat: om 18% av kontaktuppgifterna var antingen förlorad eller skadad. Inga loggar. Inga felmeddelanden. Bara tyst dataförlust.

Vad som krävdes för att åtgärda

Vi gav ett litet team i uppdrag att reda ut röran. Här är vad vi gjorde:

Diagnos och replikering (4 timmar) Vi återskapade skriptet i en sandlåde-miljö och körde det mot en ögonblicksbild av databasen. På så sätt bekräftade vi problemet och kartlade exakt vad som saknades.
Forensisk datagranskning (8 timmar) Vi jämförde det trasiga tillståndet med säkerhetskopior, identifierade alla poster med saknade eller partiella data och matchade dem mot händelseloggar för att spåra vilka inmatningar som misslyckades och varför.
Omskrivning av migrationslogiken (12 timmar) Vi skrev om hela skriptet i Python, lade till fullständig valideringslogik, byggde en rollback-mekanism och integrerade det i kundens CI-pipeline. Den här gången inkluderade det tester och stöd för torrkörning.
Manuell dataåterställning (6 timmar) Vissa poster gick inte att återskapa från säkerhetskopior. Vi hämtade saknade fält från externa system (deras CRM och e-postleverantörens API:er) och återställde resten manuellt.

Total tidsåtgång: 30 ingenjörstimmar

Två ingenjörer, tre dagar. Kostnad för kunden: cirka $4,500 i serviceavgifter.

Men den största smällen kom från kunderna. Misslyckade aviseringar ledde till uteblivna betalningar och kundbortfall. Kunden berättade för oss att de spenderade minst $10,000 på supportärenden, SLA-kompensation och goodwillkrediter på grund av det där enda misslyckade skriptet.

Det ironiska är att en senior utvecklare kunde ha skrivit den korrekta migreringen på kanske fyra timmar. Men löftet om AI-hastighet kostade dem i slutändan två veckors uppstädning och skadat rykte.

Vi fixar det som ChatGPT förstörde - och bygger det som det inte kunde.

Fall 2: API-klienten som ignorerade hastighetsbegränsningar och förstörde produktionen

Den här kom från ett nystartat företag inom legal tech som bygger en plattform för dokumenthantering för advokatbyråer. En av deras kärnfunktioner var att integrera med en statlig e-aviseringstjänst - ett tredjeparts REST API med OAuth 2.0 och strikt hastighetsbegränsning: 50 förfrågningar per minut, inga undantag.

Istället för att ge integrationen till en erfaren backend-utvecklare bestämde sig någon i teamet för att "prototypa den" med ChatGPT. De släppte in OpenAPI-specifikationen, bad om en Python-klient och fick ett snyggt skript med requests, försök igen logik med hjälp av tenacity, och uppdatering av token.

Såg bra ut på pappret. Så de skickade den.

Vad gick fel?

Till en början verkade allt bra. Klienten hanterade enskilda förfrågningar korrekt, klarade autentisering och försökte till och med på nytt vid fel. Men under verklig användning, särskilt under belastning, började plattformen bete sig oförutsägbart.

Så här gick det faktiskt till:

Ingen respekt för prisgränser. Den genererade koden läste eller tolkade inte X-RateLimit-Remaining eller Retry-After rubriker. Den fortsatte bara att skicka förfrågningar i blindo.
Nya försök gjorde saken värre. När 429 fel började komma tillbaka, försökte tenacity-dekoratorn om dem automatiskt. Ingen jitter. Ingen köbildning. Bara en flod av uppföljningsförfrågningar.
API-leverantören blockerade tillfälligt deras IP. Under 3 timmar kunde ingen på plattformen synkronisera dokument. Inga loggar, inga varningar. Bara ett tyst misslyckande.

Det här var inte en fix på en rad. Det var ett missförstånd av hur produktionssystem beter sig. Och det är ett bra exempel på vad LLM:er inte vet; inte för att de är trasiga, utan för att de inte har runtime awareness.

Sluta patcha AI-genererad kod i prod - ta in oss innan den går sönder.

Hur vi löste det

Spåra och isolera felet (6 timmar) Vi lade till middleware för att inspektera utgående trafik och bekräftade översvämningen av förfrågningar under toppanvändning. Vi återskapade också felet i staging för att fullt ut förstå det utlösande mönstret.
Återuppbyggnad av API-klienten (10 timmar) Vi skrev om klienten med hjälp av httpx.AsyncKlient, implementerade en semaforbaserad throttle, lade till exponentiell backoff med jitter och hanterade Retry-After och hastighetsbegränsningsrubriker.
Stresstest och validering (6 timmar) Vi simulerade verklig användning med tusentals samtidiga förfrågningar med hjälp av Locust, testade hastighetsbegränsning under olika burstscenarier och bekräftade noll 429 under ihållande belastning.
Lägg till övervakning och varning (4 timmar) Vi skapade anpassade Prometheus-mätvärden för att spåra API-användningen per minut och lade till varningar för att meddela teamet om de närmade sig tröskelvärdena.

Total tid: 26 timmar

Två ingenjörer, fördelat på två och en halv dag. Kostnad för kunden: cirka $3,900.

Det största problemet var att deras största kund - en advokatbyrå med tidskänsliga ansökningar - missade två inlämningsfönster i domstolarna på grund av avbrottet. Kunden var tvungen att begränsa skadan och erbjuda en rabatt för att behålla kontot.

Allt för att en språkmodell inte förstod skillnaden mellan "arbetskod" och "produktionsfärdig kod". Och bara så där, ett annat lager av AI teknisk skuld lades tyst till i stacken.

Varför detta fortsätter att hända

Det skrämmande är inte att saker och ting går fel. Det är hur förutsägbart det börjar bli.

Var och en av dessa incidenter följer samma mönster. En utvecklare ber ChatGPT om en kodsnutt. Den returnerar något som fungerar precis tillräckligt bra för att inte kasta fel. De kopplar in det i systemet, kanske rensar upp det lite och skickar det, förutsatt att om det kompileras och körs måste det vara säkert.

Men här är haken: Stora språkmodeller känner inte till ditt system.
De vet inte hur dina tjänster samverkar.
De känner inte till din latensbudget, din distributionspipeline, din observerbarhetskonfiguration eller dina trafikmönster i produktionen.

De genererar den kod som ser mest sannolik ut baserat på mönster i deras utbildningsdata. Det är allt. Det finns ingen medvetenhet. Inga garantier. Ingen intuition för systemdesign.

Och resultatet avspeglar ofta detta:

Kod som fungerar en gång, men misslyckas under belastning
Ingen defensiv programmering, inga säkerhetslösningar
Dålig förståelse för begränsningar i den verkliga världen, t.ex. hastighetsbegränsningar, timeouts eller eventuell konsekvens
Absolut noll känsla för arkitektonisk avsikt

Vad som är värre är att koden ser korrekt ut. Den är syntaktiskt ren. Den passerar linters. Den kanske till och med täcks av ett grundläggande test. Men den saknar det enda som faktiskt betyder något: sammanhanget.

Det är därför de här buggarna inte dyker upp direkt. De väntar på fredagskvällsdriftsättningar, för högtrafikerade fönster, för sällsynta kantfall. Det är så den tekniska skulden AI ser ut - den är osynlig tills den förstör något kritiskt.

När AI faktiskt hjälper

Som vi nämnde tidigare använder vi AI också. I stort sett alla ingenjörer i vårt team har en Copilot-liknande installation som körs lokalt. Det är snabbt, hjälpsamt och ärligt talat ett bra sätt att hoppa över de tråkiga delarna.

Men här är skillnaden: ingenting kommer in i huvudgrenen utan att gå igenom en senior ingenjör, och i de flesta fall en CI-pipeline som vet vad den ska leta efter.

LLM är bra på:

byggnadsställning för nya tjänster eller API-slutpunkter,
generera testtäckning för befintlig logik,
hjälpa till med repetitiv refaktorisering över stora kodbaser,
översättning av enkla shell-skript till infrastruktur-som-kod-mallar,
eller till och med jämföra algoritmiska metoder som vi redan förstår.

Vad de är inte bra på är design. Eller sammanhang. Eller säkra standardinställningar.

Det är därför vi har byggt våra arbetsflöden för att behandla LLM-utdata som förslag, inte som sanningskällor. Så här ser det ut i praktiken:

Vi taggar alla AI-genererade commits så att de är lätta att spåra och granska.
Våra redaktörer har inbyggda uppmaningar, men med tvingande krokar som blockerar allt utan tester eller dokumentation.
Vår CI innehåller regler för statisk analys som flaggar för osäkra mönster som vi har sett tidigare från LLM:er: saker som oskyddade retries, oscopade timeouts, naiv JSON-parsning eller osäker SQL-hantering.
Varje pull request med LLM-genererad kod genomgår en obligatorisk mänsklig granskning, vanligtvis av en senior person som förstår domänlogiken och riskytan.

Rätt använt är det en tidsbesparing. Används det i blindo är det en tidsinställd bomb.

Vad vi rekommenderar till CTO:er

Vi är inte här för att säga att du ska förbjuda AI-verktyg. Det skeppet har seglat.

Men att ge en språkmodell commit access? Det är bara att be om problem.

Här är vad vi rekommenderar istället:

1. Behandla civilingenjörer som verktyg, inte som ingenjörer

Låt dem hjälpa till med repetitiv kod. Låt dem föreslå lösningar. Men inte anförtro dem kritiska beslut. Alla koder som genereras av AI ska granskas av en senior ingenjör, inga undantag.

2. Gör LLM-genererad kod spårbar

Oavsett om det är commit-taggar, metadata eller kommentarer i koden, klargöra vilka delar som kommer från AI. Det gör det lättare att granska, felsöka och förstå riskprofilen i ett senare skede.

3. Definiera en generationspolicy

Bestäm tillsammans i teamet var det är acceptabelt att använda LLM:er och var det inte är det. Boilerplate? Visst. Auth-flöden? Ja, kanske. Transaktionella system? Absolut inte utan granskning. Gör policyn tydlig och en del av dina tekniska standarder.

4. Lägg till övervakning på DevOps-nivå

Om du låter AI-genererad kod röra produktionen måste du anta att något så småningom kommer att gå sönder. Lägg till syntetiska kontroller. Övervakare för hastighetsbegränsning. Spårning av beroenden. Gör det osynliga synligt, särskilt när den ursprungliga författaren inte är mänsklig.

5. Bygg för återställbarhet

De största AI-drivna misslyckanden vi har sett kom inte från "dålig" kod. De kom från tysta fel - saknade data, trasiga köer, omprövningsstormar - som inte upptäcktes på flera timmar. Investera i observerbarhet, reservlogik och rollbacks. Speciellt om du låter ChatGPT skriva migreringar.

Kort sagt, AI kan spara ditt team tid, men det kan inte ta ansvar.

Det är fortfarande ett mänskligt jobb.

Avslutande tankar: AI ≠ mjukvaruingenjörer

AI kan hjälpa dig att röra dig snabbare. Men den kan inte tänka åt dig.

Den förstår inte din arkitektur. Den vet inte vad "klar" betyder i ditt sammanhang. Och den bryr sig definitivt inte om din datapipeline tyst går sönder en fredagskväll.

Det är därför vi som CTO:er måste fokusera på systemets motståndskraft, inte bara på hastighet.

Det är frestande att låta AI ta hand om de tråkiga delarna. Och ibland är det bra. Men varje genväg kommer med en avvägning. När AI-genererad kod slinker igenom okontrollerad blir den ofta AI teknisk skuld. Den typ du inte ser förrän ditt ops-team är brandbekämpande i produktionen.

Om du redan har gått in i väggen är du inte ensam. Vi har hjälpt team att återhämta sig från allt från trasiga migreringar till API-katastrofer. Vi refaktoriserar inte bara kod. Vi hjälper till att refaktorisera tänkandet bakom den.

För i slutändan är det faktiskt det som gör systemen tillförlitliga.

Philip Tikhanovich

Chef för avdelningen Python, Big Data, ML/DS/AI

Philip ger skarpt fokus på allt som har med data och AI att göra. Han är den som ställer rätt frågor tidigt, skapar en stark teknisk vision och ser till att vi inte bara bygger smarta system - vi bygger rätt system, för verkligt affärsvärde.

Läs mer

Innehållsförteckning

Kontakta oss

Boka ett samtal eller fyll i formuläret nedan så återkommer vi till dig när vi har behandlat din förfrågan.

Namn

Företag

E-post

Telefon

Meddelande

Skicka ett röstmeddelande till oss

Bifoga dokument

Ladda upp filen

Du kan bifoga 1 fil på upp till 2 MB. Giltiga filformat: pdf, jpg, jpeg, png.

Genom att klicka på Skicka samtycker du till att Innowise behandlar dina personuppgifter enligt våra Integritetspolicy för att förse dig med relevant information. Genom att lämna ditt telefonnummer samtycker du till att vi kan kontakta dig via röstsamtal, SMS och meddelandeappar. Samtals-, meddelande- och datataxor kan gälla.

Du kan också skicka oss din förfrågan
till contact@innowise.com

Vad händer härnäst?

När vi har tagit emot och behandlat din förfrågan återkommer vi till dig för att beskriva dina projektbehov och undertecknar en NDA för att säkerställa sekretess.

Efter att ha undersökt dina önskemål, behov och förväntningar kommer vårt team att ta fram ett projektförslag förslag med arbetsomfattning, teamstorlek, tids- och kostnadsberäkningar.

Vi ordnar ett möte med dig för att diskutera erbjudandet och fastställa detaljerna.

Slutligen undertecknar vi ett kontrakt och börjar arbeta med ditt projekt direkt.