Viestisi on lähetetty.
Käsittelemme pyyntösi ja otamme sinuun yhteyttä mahdollisimman pian.
Lomake on lähetetty onnistuneesti.
Lisätietoja on postilaatikossasi.
Kuten eri puolilta alaa saadut raportit osoittavat, AI:n tuottamien koodivirheiden korjaamiseen keskittyville insinööreille on nyt kasvava erikoisala.
Kaavasta on tullut huomattavan johdonmukainen. Yritykset kääntyvät ChatGPT:n puoleen luodakseen migraatioskriptejä, integraatioita tai kokonaisia ominaisuuksia toivoen säästävänsä aikaa ja leikkaavansa kustannuksia. Teknologia vaikuttaa loppujen lopuksi nopealta ja helppokäyttöiseltä.
Sitten järjestelmät epäonnistuvat.
Ja he soittavat meille.
Viime aikoina olemme saaneet yhä enemmän tällaisia pyyntöjä. Emme ole toimittaneet uutta tuotetta, vaan pyrkineet purkamaan sotkun, joka on jäänyt jäljelle sen jälkeen, kun joku on luottanut kielimalliin ja tuotantokoodiinsa.
Tässä vaiheessa se alkaa näyttää omalta kapealta toimialaltaan. AI:n tuottamien virheiden korjaaminen on nyt laskutettava palvelu. Ja joissakin tapauksissa erittäin kallis sellainen.
GitClearin vuoden 2024 raportti vahvistaa sen, mitä olemme havainneet asiakkaidemme kanssa: AI-koodaustyökalut nopeuttavat toimituksia, mutta myös lisäävät päällekkäisyyksiä, vähentävät uudelleenkäyttöä ja kasvattavat pitkän aikavälin ylläpitokustannuksia.
Tehdään kuitenkin selväksi, ettemme ole "AI:tä vastaan". Me käytämme sitä myös. Ja se on hyödyllinen oikeassa yhteydessä, oikeiden suojakaiteiden kanssa. Mutta se, mikä minua turhauttaa AI:hen liiallisessa luottamisessa ja sen laajalle levinneissä vaikutuksissa - ja luultavasti sinuakin - on maaginen ajattelu. Ajatus siitä, että kielimalli voi korvata todellisen insinöörityön.
Se ei voi. Ja kuten sanonta kuuluu, todiste on vanukkaassa. Kun yritykset teeskentelevät muuta, ne joutuvat lopulta maksamaan meidän kaltaisillemme siivoamisesta.
Miltä tällainen siivoustyö näyttää? Seuraavassa kerrotaan, mitä AI-afficionados eivät kerro sinulle menetetystä ajasta ja hukkaan heitetyistä rahoista.
Viesti tulee yleensä näin:
"Hei, voisitko vilkaista rakentamaamme mikropalvelua?". Käytimme ChatGPT:tä ensimmäisen version luomiseen. Työnsimme sen stagingiin, ja nyt RabbitMQ-jonomme on täysin täynnä."
Mutta asia on näin: oireet ilmenevät paljon myöhemmin. Joskus päiviä myöhemmin. Ja kun ne ilmenevät, on harvoin selvää, että perussyy oli AI:n tuottama koodi. Se vain näyttää siltä, että jokin on pielessä.
Kymmenen tällaisen tapauksen jälkeen kuvioita alkaa hahmottua:
Ja tietenkin, kun kaikki romahtaa, AI ei jätä sinulle kommenttia, jossa sanotaan: "Muuten, arvelen tässä".
Se on sinun vastuullasi.
Tämä tuli nopeasti kasvavalta fintech-yritykseltä.
He olivat ottamassa käyttöön uutta versiota asiakastietomallistaan jakamalla yhden suuren JSONB-kentän Postgresissä useisiin normalisoituihin taulukoihin. Aika tavallista tavaraa. Mutta koska aikataulu oli tiukka ja käsiä ei ollut tarpeeksi, yksi kehittäjistä päätti "nopeuttaa asioita" pyytämällä ChatGPT:tä luomaan siirtoskriptin.
Se näytti päällisin puolin hyvältä. Skripti purki JSON-tiedot, poimi yhteystiedot ja lisäsi ne uuteen user_contacts
pöytä.
Niinpä he juoksuttivat sitä.
Ei kuivaharjoittelua. Ei varmuuskopiointia. Suoraan stagingiin, joka, kuten kävi ilmi, jakoi tietoja tuotannon kanssa kopion kautta.
Muutamaa tuntia myöhemmin asiakastuki alkoi saada sähköposteja. Käyttäjät eivät saaneet maksuilmoituksia. Toisten profiileista puuttui puhelinnumeroita. Silloin he soittivat meille.
NULL
arvoja tai puuttuvia avaimia JSON-rakenteen sisällä.KONFLIKTISTA EI TEHDÄ MITÄÄN
, joten kaikki epäonnistuneet lisäykset jätettiin hiljaisesti huomiotta.Tämä tuli lakiasiainteknologian alan startup-yritykseltä, joka kehittää asiakirjojen hallintaympäristöä asianajotoimistoille. Yksi heidän keskeisistä ominaisuuksistaan oli integroituminen hallituksen sähköisen ilmoituspalvelun kanssa - kolmannen osapuolen REST API OAuth 2.0:lla ja tiukalla nopeusrajoituksella: 50 pyyntöä minuutissa, ei poikkeuksia.
Sen sijaan, että integraatio olisi annettu kokeneen backend-palvelun kehittäjän tehtäväksi, joku tiimin jäsenistä päätti "prototyypittää" sen ChatGPT:n avulla. He lisäsivät OpenAPI-spesifikaation, pyysivät Python-asiakasta ja saivat siistin näköisen skriptin, jossa oli seuraavat ominaisuudet pyynnöt
, uusintalogiikka käyttäen sitkeys
ja tokenin päivitys.
Näytti paperilla vakaalta. Joten he lähettivät sen.
Näin todella tapahtui:
X-RateLimit-Remaining
tai Retry-After
otsikot. Se vain jatkoi pyyntöjen lähettämistä sokeasti.httpx.AsyncClient
, toteutti semafooripohjaisen kuristimen, lisäsi eksponentiaalisen backoffin ja jitterin ja käsitteli asianmukaisesti seuraavia asioita. Retry-After
ja nopeusrajoitusotsikot.Kaksi insinööriä kahden ja puolen päivän aikana. Kustannukset asiakkaalle: noin $3,900.
Suurempi ongelma on se, että heidän suurin asiakkaansa - lakiasiaintoimisto, jonka arkistoinnille on tärkeää aikaa - ei päässyt kahteen oikeuteen jättämisikkunaan katkoksen vuoksi. Asiakkaan oli tehtävä vahinkojen torjuntaa ja tarjottava alennusta säilyttääkseen asiakkaan.
Kaikki tämä siksi, että kielimalli ei ymmärtänyt eroa "toimivan koodin" ja "tuotantokelpoisen koodin" välillä. Ja aivan kuten siinä kävi, pinoon lisättiin hiljaa toinen kerros AI:n teknistä velkaa.
Vielä pahempaa on se, että koodi näyttää oikealta. Se on syntaktisesti puhdas. Se läpäisee linterit. Se saattaa jopa kuulua perustestin piiriin. Mutta siitä puuttuu se yksi asia, jolla on oikeasti merkitystä: konteksti.
Siksi nämä viat eivät näy heti. Ne odottavat perjantai-illan käyttöönottoja, vilkkaasti liikennöityjä ikkunoita ja harvinaisia ääritapauksia. Tämä on AI:n teknisen velan luonne - se on näkymätöntä, kunnes se rikkoo jotain kriittistä.
Mitä he ovat ei hyvä suunnittelussa. Tai kontekstissa. Tai turvallisissa oletusarvoissa.
Siksi olemme rakentaneet työnkulut siten, että LLM-tuloksia käsitellään ehdotuksina, ei totuuden lähteenä. Seuraavassa on, miltä se näyttää käytännössä:
Oikein käytettynä se säästää aikaa. Sokeasti käytettynä se on aikapommi.
Anna heidän auttaa toistuvan koodin kanssa. Anna heidän ehdottaa ratkaisuja. Mutta älä luota heihin kriittisiä päätöksiä. Kaiken AI:n tuottaman koodin on oltava vanhemman insinöörin tarkistama, ei poikkeuksia.
Olipa kyse sitten commit-tagista, metatiedoista tai koodin kommenteista, tehdään selväksi, mitkä osat ovat peräisin AI:stä.. Tämä helpottaa tarkastusta, virheenkorjausta ja riskiprofiilin ymmärtämistä myöhemmin.
Päättäkää tiiminä, missä LLM:n käyttö on hyväksyttävää ja missä ei. Boilerplate? Toki. Auth flows? Ehkä. Transaktiojärjestelmät? Ei missään nimessä ilman tarkistusta. Tehdään politiikasta selkeä ja osa teknisiä standardeja.
Jos annat AI:n tuottaman koodin koskettaa tuotantoa, sinun on oletettava, että jokin menee lopulta rikki. Lisää synteettisiä tarkistuksia. Nopeusrajoitusvalvontalaitteet. Riippuvuuksien seuranta. Tee näkymätön näkyväksivarsinkin kun alkuperäinen kirjoittaja ei ole ihminen.
Suurimmat näkemämme AI:n aiheuttamat epäonnistumiset eivät johtuneet "huonosta" koodista. Ne johtuivat hiljaisista virheistä - puuttuvista tiedoista, rikkoutuneista jonoista, uusintakokeilumyrskyistä - jotka jäivät tuntikausia havaitsematta. Panosta tarkkailtavuuteen, varalogiikkaan ja palautuksiin. Varsinkin jos annat ChatGPT:n kirjoittaa siirtymiä.
Lyhyesti sanottuna AI voi säästää tiimisi aikaa, mutta se ei voi ottaa vastuuta.
Se on edelleen ihmisen työtä.
Viestisi on lähetetty.
Käsittelemme pyyntösi ja otamme sinuun yhteyttä mahdollisimman pian.
Rekisteröitymällä hyväksyt Tietosuojakäytäntö, mukaan lukien evästeiden käyttö ja henkilötietojesi siirto.