AI-sovelluksen rakentamisen tulevaisuus riippuu tyyppiturvallisuudesta

AI:n generoima koodi saattaa kääntyä, mutta ilman tiukkaa tyyppiturvallisuutta tämä menestys on äärimmäisen lyhytaikainen. Tyyppiturvallisuus on kaide, joka estää hauraan koodin mätänemisen piileviin virheisiin ja suoritusaikaisiin virheisiin, kun järjestelmä laajenee.

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

Kannustimongelma

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ä oikoreitit näyttävät hyvältä käännösaikana, mutta ne romahtavat suoritusaikana.

Tämän vuoksi AI rakastaa mitä tahansa. Tai se valitsee laajan tyypin, kuten merkkijono, jossa odotetaan jotain tiukempaa, kuten UUID. Koodi kääntyy, mutta oikeellisuus on jo vaarantunut. Pahemminkin, AI ei muista, mitä se kirjoitti muutama tiedosto sitten, joten ilman tyyppiturvallisuutta projekti romahtaa nopeasti oman monimutkaisuutensa alle.

Kahdenlaiset virheet

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

1. Käännösaikaiset virheet

• Mikä tapahtuu: Kääntäjä havaitsee väärän tyypin ja sen, mitä siirrettiin.
• Miten ihminen korjaa sen: Päätä, onko kutsuja väärä (muunna 42 merkkijonoksi) tai onko funktiosignatuuri väärä (muuta se vastaanottamaan numerotyypin).
• Miten AI ”korjaa” sen: Muuta argumentin tyyppi mitä tahansa. Ongelma ”ratkaistu”, mutta olet poistanut kaiteen, joka olisi kiinni ottanut tulevat virheet.

2. Suoritusaikaiset virheet

• Mikä tapahtuu: Kääntäjä luulee, että kaikki on kunnossa (usein, koska tyypit oli löysennetty), mutta todellinen arvo suoritusaikana ei vastaa oletusta.
• Miten ihminen korjaa sen: Jäljitetään muuttujaa sen lähteeseen (kuten API:hin tai tietokantakyselyyn) ja korjataan tyyppi rajapinnassa, jotta data tulee oikeana merkkijonona.
• Miten AI ”korjaa” sen: Ilman kontekstia se arvaa. Se saattaa kiertää kaiken String(…):llä tai vain laajentaa tyyppiä uudelleen. Törmäys katoaa tässä kohdassa, mutta nyt logiikka on rikkoontunut. Numeroita, jotka oli tarkoitettu matemaattiseen käyttöön, ovat yhtäkkiä merkkijonoja.

Tämä kierto suoritusaikaisista virheistä → AI:n ”korjaus” → löysentynyt tyypitys kasautuu nopeasti. Tuloksena on koodipohja, joka kääntyy ja heittää vähemmän suoritusaikaisia virheitä, mutta jota ei voida luottaa. Kuvitellaan terveydenhuollon aikataulujärjestelmä, jossa lääkärien vuorot hallitaan sovelluksella. Tyyppivirhe siirtyy: int tunteja kohdellaan merkkijonona. AI ”korjaa” sen löysentämällä tyypin mitä tahansa. Koodi kääntyy ja virhe katoaa, mutta vuorolaskelmat rikkoutuvat hiljalleen, mikä aiheuttaa lääkärien ylikuormittumisen ja jättää koko sairaalan siiven ilman hoitoa.

Tietokannan monikertaaja

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

Kun AI tasaa kaiken merkkijono | mitä 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 suoritusaikaiseen törmäykseen.
• Virheelliset suhteet: jos suhteen avain odotetaan UUID:na, mutta AI kohdella sitä merkkijonona ja lähettää virheellisiä arvoja, liitokset eivät romahta, 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 schemasta API:hin. Jos et tee niin, tietokanta lopettaa suojelemisen ja piilevät ongelmat kasautuvat.

Miksi kokeneet tiimit pakottavat tiukan tyypityksen

Tiukka tyypitys ei ole kehittäjien hidastamisesta. Se on skaalautuvuuden mahdollistamisesta.

Tyypit:

• Koodaavat aikomusta koodiin.
• Tehdä refaktoroinnit 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ölakkatapaa kasautuu. Sen sijaan se tuottaa koodia, jota voit luottaa ja laajentaa.

Miten pakottaa AI:tä 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ää mitä tahansa, äläkä salli tuntematonta, ja jokaisen menetelmän, olion ja muuttujan on oltava tyypitetty. Odotetaan, että se käy vaikeuksien läpi (erityisesti ensimmäisellä kierroksella).

Pakota linttaamisella

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

Toista tarkastuksilla

Käännösaikaiset virheet, suoritusaikaiset lokit, klikkausläpi. Jokainen toisto pakottaa AI:a 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ä aikavälillä. Se tarkoittaa taistelua nollatoleranssia mitä tahansa -tyypeille, pakottamista useista palautekierroista ja tiukkojen lint-sääntöjen noudattamisesta, jotka AI on läpäistävä ennen kuin koodi on ”valmis”. Se vaatii jatkuvaa ponnistelua, mutta se on ainoa keino, jolla laatu voidaan estää heikkenemästä.

Aikaisemmin mainitsin avainkohteen: kun AI alkaa korjata suoritusaikaisia virheitä löysentämällä tyyppejä, sinä menet väkivallan kierron. Jokainen korjaus riisuu yhden kaiteen, ja tuloksena on koodipohja, joka kääntyy, mutta on hauras ja ylläpidettävä. Vastakkainen on myös totta: jos pakotat AI:a kunnioittamaan tyyppiturvallisuutta jokaisella kierroksella, luot hyveellisen kierron. Jokainen toisto kiristää kaiteita, koodipohja muuttuu puhtaammaksi, ja laatu kasautuu luotettavaksi ja kestäväksi.

Tämä on järjestelmä, joka uskon toimivan kestävän koodin laadun. Jokainen toisto 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 peruskaide ylläpidettävyydelle, ja sallimalla AI:n ohittaa sen takaa, että sovelluksesi ei koskaan saavuta tuotantoon sopivaa tasoa.