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

Philip Tihonovich

29 maj 2025 10 min läsning

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 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 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

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:

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

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:

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

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. 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 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

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.