Meldingen din er sendt.
Vi behandler forespørselen din og kontakter deg så snart som mulig.
Skjemaet har blitt sendt inn.
Mer informasjon finner du i postkassen din.
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.
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.
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."
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."
Teknisk sjef
Etter et dusin av disse tilfellene begynner det å avtegne seg et mønster:
Og når alt kollapser, legger selvfølgelig ikke AI igjen en kommentar som sier: "Forresten, jeg gjetter her."
Det er ditt ansvar.
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.
Vi sporet problemet til skriptet. Det gjorde det grunnleggende uttrekket, men det gjorde tre fatale antakelser:
NULL
verdier eller manglende nøkler i JSON-strukturen.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.
Vi satte ned et lite team for å rydde opp i rotet. Her er hva vi gjorde:
To ingeniører, tre dager. Kostnad for kunden: ca. $4,500 i serviceavgifter.
Men det største tapet kom fra kundene. Manglende varslinger førte til tapte betalinger og kundefrafall. Kunden fortalte oss at de brukte minst $10,000 på supporthenvendelser, SLA-kompensasjon og goodwill-kreditter på grunn av det ene feilslåtte skriptet.
Det ironiske er at en seniorutvikler kunne ha skrevet den riktige migreringen på kanskje fire timer. Men løftet om AI-hastighet endte opp med å koste dem to uker med opprydding og skade på omdømmet.
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.
Her er hva som faktisk skjedde:
X-RateLimit-Remaining
eller Retry-After
overskrifter. Den fortsatte bare å sende forespørsler i blinde.httpx.AsyncClient
, implementerte en semaforbasert struping, la til eksponentiell backoff med jitter, og håndterte Retry-After
og hastighetsbegrensningshoder.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.
Det skremmende er ikke at disse tingene går galt. Det er hvor forutsigbart det begynner å bli.
Alle disse hendelsene følger det samme mønsteret. En utvikler ber ChatGPT om en kodesnutt. Den returnerer noe som fungerer akkurat godt nok til ikke å gi feil. De kobler det inn i systemet, rydder kanskje litt opp i det, og sender det ut i den tro at hvis det kompilerer og kjører, må det være trygt.
Men her er haken: Store språkmodeller kjenner ikke systemet ditt.
De vet ikke hvordan tjenestene dine samhandler.
De kjenner ikke latensbudsjettet ditt, distribusjonspipelinen din, observasjonsoppsettet ditt eller trafikkmønstrene dine i produksjonen.
De genererer den koden som ser mest sannsynlig ut, basert på mønstre i opplæringsdataene. Det er alt. Det er ingen bevissthet. Ingen garantier. Ingen intuisjon for systemdesign.
Og det gjenspeiler seg ofte i resultatet:
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.
Som vi nevnte tidligere, bruker vi også AI. Så godt som alle ingeniørene i teamet vårt har et Copilot-lignende oppsett som kjører lokalt. Det er raskt, nyttig og ærlig talt en flott måte å hoppe over de kjedelige delene på.
Men her er forskjellen: Ingenting kommer inn i hovedgrenen uten å gå gjennom en senioringeniør, og i de fleste tilfeller en CI-pipeline som vet hva den skal se etter.
LLM-er er gode til:
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:
Brukt riktig er det tidsbesparende. Brukt i blinde er det en tidsinnstilt bombe.
Vi er ikke her for å be deg om å forby AI-verktøy. Det skipet har seilt.
Men å gi en språkmodell commit-tilgang? Det er bare å be om problemer.
Her er hva vi anbefaler i stedet:
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.
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.
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.
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.
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.
AI kan hjelpe deg med å bevege deg raskere. Men den kan ikke tenke for deg.
Den forstår ikke arkitekturen din. Den vet ikke hva "ferdig" betyr i din kontekst. Og den bryr seg definitivt ikke om datapipelinen din går i stykker en fredag kveld.
Derfor må vi som teknologidirektører fokusere på systemets robusthet, ikke bare på hastighet.
Det er fristende å la AI ta seg av de kjedelige delene. Og noen ganger er det helt greit. Men alle snarveier kommer med en ulempe. Når AI-generert kode slipper gjennom uten å bli kontrollert, blir den ofte til AI-teknisk gjeld. Den typen du ikke ser før driftsteamet ditt er i gang med brannslukking i produksjonen.
Hvis du allerede har møtt veggen, er du ikke alene. Vi har hjulpet team med å komme seg etter alt fra ødelagte migreringer til API-katastrofer. Vi refaktoriserer ikke bare kode. Vi hjelper med å refaktorere tankegangen bak den.
For til syvende og sist er det det som gjør systemene pålitelige.
Meldingen din er sendt.
Vi behandler forespørselen din og kontakter deg så snart som mulig.
Ved å registrere deg godtar du vår Retningslinjer for personvern, inkludert bruk av informasjonskapsler og overføring av dine personopplysninger.