AI-sovelluksen tulevaisuus riippuu tyyppiturvallisuudesta

AI:n generoima koodi voi kääntyä, mutta ilman tiukkaa tyyppiturvallisuutta tämä menestys on hyvin lyhytaikainen. Tyyppiturvallisuus on este, joka estää hauraan koodin mätänemisen piileviin virheisiin ja ajon aikaisiin virheisiin, kun järjestelmä laajenee.

Meidän on aloitettava AI:n pakottaminen tiukkaan tyypitykseen kontekstin, ohjeiden, linttaamisen ja palautekiertojen avulla. Se vie muutaman ylimääräisen tunnin, mutta se tuottaa kestävää koodia.

Lahjontavongin ongelma

AI haluaa miellyttää sinua. Se optimoi palkkiofunktiota, jota sille annetaan, ja useimmiten se on vain ”kääntyykö se?”. Se leikkaa jokaisen tarvittavan kulman päästäkseen vihreään merkintään. Nämä lyhytkatkuiset ratkaisut näyttävät hyvältä käännösaikana, mutta ne romahtavat ajon aikana.

Tämän vuoksi AI rakastaa mikä tahansa. Tai se valitsee laajan tyypin, kuten merkkijono, jossa olisi odotettu jotain tiukempaa, kuten UUID. Koodi kääntyy, mutta oikeellisuus on jo vaarantunut. Pahemmaksi AI ei muista, mitä se kirjoitti muutaman tiedoston takaisin, joten ilman tyyppiturvallisuutta projekti romahtaa nopeasti oman monimutkaisuutensa alle, kun kompleksisuus kasvaa.

Kahdenlaiset virheet

Kun AI:n generoima koodi ajetaan, yleensä näkee kaksi tyyppiturvallisuuden ongelman lajia:

1. Käännösaikaiset virheet

• Mitä tapahtuu: Kääntäjä havaitsee epäilyttävän tyypin ja siirtää sen.
• Miten ihminen korjaa sen: Päätä, onko kutsuja väärä (muunna 42 merkkijonoksi) vai onko funktiosignatuuri väärä (muuta sitä vastaanottamaan numeerisen tyypin).
• Miten AI ”korjaa” sen: Vaihda argumentin tyyppi mikä tahansa. Ongelma on ”ratkaistu”, mutta olet poistanut esteen, joka olisi havainnut tulevat virheet.

2. Ajon aikaiset virheet

• Mitä tapahtuu: Kääntäjä luulee, että kaikki on kunnossa (usein koska tyypit on löysennetty), mutta todellinen arvo ajon aikana ei vastaa oletusta.
• Miten ihminen korjaa sen: Jäljitä muuttujaa sen lähteeseen (kuten API:in tai tietokantakyselyyn) ja korjaa tyyppi rajapinnassa, jotta data tulee oikeana merkkijonona.
• Miten AI ”korjaa” sen: Ilman kontekstia se arvaa. Ehkä se kietoo kaiken merkkijono(…):n ympärille tai laajentaa tyypin uudelleen. Rajahdus katoaa tässä kohdassa, mutta logiikka on nyt rikkoontunut. Luvut, jotka on tarkoitettu matemaattiseen käyttöön, ovat yhtäkkiä merkkijonoja.

Tämä ajon aikaisen virheen → AI:n ”korjaus” → löysentymisen kierto kasvaa nopeasti. Tuloksena on koodipohja, joka kääntyy ja heittää vähemmän ajon aikaisia virheitä, mutta jota ei voida luottaa. Kuvittele terveydenhuollon ajanvarausjärjestelmä, jossa lääkärien vuorot ovat hallinnassa. Tyyppien väärinkäsitys: int tunteja käsitellään merkkijonona. AI ”korjaa” sen löysentämällä tyypin mikä tahansa. Koodi kääntyy ja virhe katoaa, mutta vuorolaskelmat rikkoutuvat hiljalleen, mikä johtaa siihen, että lääkärit ovat ylipäätään varattuina ja koko sairaalan siipi on paljastettu.

Tietokannan monikertaaja

Hetkeä, kun yhdistät tietokantaan, virheet moninkertaistuvat ja niiden syyt tulevat vaikeammaksi jäljittää. SQL on tyypitetty tarkoituksella. Jokainen skeema (INT, TEXT, UUID, BOOLEAN) koodaa oletuksia tietojen suhteen.

Kun AI tasaa kaiken merkkijono | mikä tahansa, menetät nämä takuut:

• Virheelliset kirjoitukset: ”true”-merkkijonon lisääminen boolean-kenttään kääntyy, mutta korruptoi tietokannan.
• Virheelliset lukemiset: kysely palauttaa NULL, mutta AI oletti merkkijonon, mikä johtaa ajon aikaiseen rajahdukseen.
• Murtuneet suhteet: jos suhderivi on odotettu UUID:na, mutta AI käsittää sen merkkijonona ja lähettää virheellisiä arvoja, liitokset eivät kaadu, mutta ne eivät palauta tietoja. Tämä piilottaa virheet, kunnes ne tulevat ilmi myöhemmin puuttuvina tai epäjohdonmukaisina tuloksina.

Tämän vuoksi vakavat tiimit käyttävät tyypitettyjä kieliä ja pakottavat tyyppiturvallisuutta skeemasta API:hin. Jos et tee niin, tietokanta lopettaa suojelemisen ja piilevät ongelmat kasvavat.

Miksi kokeneet tiimit pakottavat tiukkaa tyypitystä

Tiukka tyypitys ei ole kehittäjien hidastamista. Se on skaalautuvuuden mahdollistamista.

Tyypit:

• Koodaavat aikomukset koodiin.
• Tehdä uudelleenjärjestelyt turvallisiksi ja ennustettaviksi.
• Pyydä virheluokkia ennen kuin ne pääsevät tuotantoon.
• Näytä tuleville kehittäjille (ja AI:lle) tarkalleen, miten funktiota tai objektia käytetään.

Ilman tyyppiturvallisuutta AI:n koodin hölakkat kasvavat. Sen sijaan sama AI tuottaa koodia, jota voit luottaa ja laajentaa.

Miten pakottaa AI:ta tyyppiturvallisuuteen

Sinun on käsiteltävä AI:ta kuin juniorikehittäjää. Nopea, taitava, mutta huolimaton ilman ohjausta.

Anna oikea konteksti

Anna sille käytettävissä olevat rajapinnat ja tyypit. Näytä esimerkkejä käytöstä. Ole mielipide siitä, miten koodi on rakennettava.

Anna tiukat ohjeet

Selkeästi ilmoita AI:lle, että se ei saa käyttää mikä tahansa, ei saa koskaan sallia tuntematonta ja että jokaisen menetelmän, olion ja muuttujan on oltava tyypitetty. Odotetaan, että se käyttää kovaa aikaa noudattamiseen (erityisesti ensimmäisellä kerralla).

Pakota linttaamisella

Kuten juniorikehittäjän koodin tarkastaminen, sinun on tarkastettava AI:n koodi. Suunnittele mukautettuja linttaussääntöjä, jotka määrittävät, mitä ”hyvä koodi” tarkoittaa sinulle. Palauta linttaamisen virheet malliin, kunnes se menee läpi. Se voi vaatia useita kierroksia, mutta se siirtää palkkiofunktion tyyppiturvallisuuden sisällyttämiseen.

Toista tarkistuksilla

Käännösaikaiset virheet, ajon aikaiset lokit, klikkaa-läpi-testit. Kukin toisto pakottaa AI:ta kiristämään tyyppejä ja siirtymään lähemmäs tuotantoon sopivaa koodia.

Paran tapa rakentaa

Olen oppinut, että uhraamalla raakakoodin nopeutta laadun hyväksi maksaa pitkällä tähtäimellä. Se tarkoittaa taistelua nollatoleranssia mikä tahansa -tyypeille, tiukkojen palautekiertojen ja tiukkojen linttaamissääntöjen pakottamista, jotka AI on läpäistävä ennen kuin koodi on ”valmis”. Se vaatii jatkuvaan ponnistelua, mutta se on ainoa tapa pitää laatua heikentymästä.

Aikaisemmin mainitsin avainkohdan: kun AI alkaa korjata ajon aikaisia virheitä löysentämällä tyyppejä, sinä menet väkivallan kierron. Kukin korjaus poistaa esteen, ja tuloksena on koodipohja, joka kääntyy, mutta on hauras ja ylläpidettävä. Vastakkainen on myös totta: jos pakotat AI:n kunnioittamaan tyyppiturvallisuutta jokaisella kierroksella, luot hyveellisen kierron. Kukin toisto kiristää esteitä, koodipohja muuttuu puhtaammaksi, ja laatu kasvaa luotettavaksi ja rakennettavaksi.

Tämä on järjestelmä, joka uskon toimivan kestävän koodin laadun. Jokainen iterointi on suunniteltu kiristämään standardeja, ei heikentämään niitä. Se on sama syy, miksi parhaat insinööritiimit valitsevat vahvasti tyypitettyjä kieliä. Tyyppiturvallisuus on perusvaruste ylläpidettävyydelle, ja antamalla AI:lle ohittaa sen, varmistat, että sovelluksesi ei koskaan saavuta tuotantoon sopivaa tasoa.