Vibe codingin varjopuoli: kun koodi toimii, mutta ei oikeasti

Olen tunnustettava: vibe coding on mullistavaa. Kuvaat mitä haluat, katsot agentin rakentavan sen, näet testien menevän läpi, ja julkaiset. Se tuntuu taikuudelta — kunnes lakkaa tuntumasta.

Se "kunnes" saapuu yleensä kello kolmelta yöllä. Sovellussi käynnistyy, käsittelee muutaman pyynnön tyylikkäästi, ja sitten OOM-reaper murhaa sen elegantisti. Tai se avaa kymmenen tuhatta tiedostokuvaajaa ja romahtaa. Tai se pyörii täydellisesti testidatalla ja hajoaa, kun oikeat käyttäjät ilmestyvät.

Koodi oli oikein. Se ratkaisi ongelman täsmälleen annettujen spesifikaatioiden mukaan. Se vain oletti, että muisti ja tiedostokuvaajat ovat äärettömiä — koska promptissasi ei sanottu muuta.

Hiljainen tappaja: piilossa olevat oletukset

Tämä on se vibe codingin osa, josta kukaan ei puhu konferensseissa. Kun kirjoitat koodin itse, kannat mentaalisia malleja rajoitteista kaikkialla. Tiedät, että kannettavassasi on 16 gigatavua RAM-muistia. Tiedät, että tuotantopalvelimella on tiedostokuvaajarajoituksia. Tiedät, että se 400 gigatavun CSV-tiedosto ei ole jotain, jonka voi ladata kokonaan muistiin.

Mutta kun tekoäly kirjoittaa koodisi, noita rajoitteita ei ole olemassa. Tekoäly näkee "lataa tiedosto, lajittele se, kirjoita tulos" ja ajattelee: loistavaa, lataan koko roskan. Se toimii täydellisesti testauksessa. Testitiedosto on 50 kilotavua.

Koodikatselmuksetkaan eivät huomaa tätä. Ongelmalliset rivit näyttävät täysin järkeviltä. Mikään ei herätä punalippua, kun etsit logiikkavirheitä — koska niitä ei ole. Bugi ei ole logiikassa; se on näkymättömässä laatikossa, jonka sisälle logiikka suunniteltiin sopimaan.

Entä jos kääntäjä todella tietäisi?

Tässä kohtaa asiat alkavat kiinnostaa. Nicolas Grislain-niminen kehittäjä on kokeillut ajatusta, joka on sekä provosoiva että kiehtova: entä jos resurssirajoitteet olisivat tyyppejä, eivät kommentteja?

Sen sijaan että toivotaan tekoälyn huomioivan muistirajoitukset, entä jos kääntäjä kieltäytyisi kääntämästä koodia, joka rikkoo niitä? Entä jos "tämä funktio ei koskaan pidä muistissa enempää kuin 100 tietuetta" ja "tämä ohjelma ei koskaan avaa samanaikaisesti enempää kuin kolmea tiedostoa" olisivat kääntäjän todistettavissa olevia faktoja, eivät toiveajatuksia koodikatselmoinnin aikana?

Tämä ei ole pelkkää teoreettista hympylöintiä. Kokeilu käyttää Lean 4:ää — samaa Lean 4:ää, joka on tehnyt vaikutuksen formaalissa matematiikassa — resurssibudjettien koodaamiseen suoraan funktiotyyppeihin. Kääntäjästä tulee resurssitilintarkastaja, joka tarkistaa automaattisesti, että koodisi pysyy rajojen sisällä ennen kuin se koskaan suoritetaan.

Resurssien laskeminen tyyppijärjestelmässä

Ydinmekanismi on yllättävän tyylikäs: vedä resurssimäärät läpi tyyppijärjestelmän. Sen sijaan että seurattaisiin "kuinka monta tiedostoa on auki" suoritusaikaisena muuttujana, joka saatetaan sivuuttaa, tyyppijärjestelmä seuraa sitä faktoomparametrina, jonka täytyy tasapainottua.

Kun avaat tiedoston, tyyppiallekirjoitus heijastaa muutosta: menet funktioon N tiedostoa auki ja poistut N+1 tiedostolla. Kun suljet sen, palaat N+1:stä takaisin N:ään. Kääntäjä seuraa tätä jokaisessa vaiheessa, etkä voi kirjaimellisesti kääntää koodia, joka avaa tiedoston sulkematta sitä tai avaa tiedostoja määritetyn rajan yli.

Muisti toimii samankaltaisesti, mutta kierteellä. Tietueet eivät leijailleet vapaasti muistissa — ne asuvat rajatussa poolissa, jossa on kiinteä määrä paikkoja. Et pidä Event-oliota; pidät viittausta tuohon pooliin. Tyyppi seuraa, kuinka monta elävää viittausta on olemassa milloin tahansa, ja allokaatio vaatii todisteen siitä, että tilaa on.

Taika tapahtuu sisääntulokohdassa: ohjelman täytyy alkaa nollalla käytössä olevia resursseja ja päättyä nollaan. Et voi vuotaa kahvoja tai viittauksia. Et voi ylittää rajoja. Kääntäjä ei yksinkertaisesti anna periksi.

Miksi tämä on tärkeää vibe codingille

Tämä lähestymistapa muuttaa tapaa, jolla ajattelemme tekoälyavustajien promptausta. Tänään saatat lisätä muistiinpanon kuten "ole varovainen muistikäytön kanssa" tai "sulje kaikki tiedostokahvat" — toivoen että tekoäly kiinnittää huomiota. Resurssitietuisten tyyppien kanssa määrität rajoitteet formaalisti, ja toteutuksen täytyy järjestäytyä uudelleen tyydyttääkseen ne.

Tekoäly saa ensin rajoitteettoman version. Testit menevät läpi. Sitten otat rajat käyttöön. Kääntäjä hylkää toteutuksen välittömästi. Tekoälyn täytyy rakentaa lähestymistapansa uudelleen — kenties käsittelemällä tiedostoa palasina kerrallaan eikä lataamalla kaikkea kerralla, tai käyttämällä yhteyspoolia tiedostojen suoran avaamisen sijaan.

Toteutus ei vain sattumalta toimi; se toimii todistettavasti budjetin puitteissa.

Käytännön todellisuus

Ollaan selkeitä: tämä ei ole vielä valmis tuotantotyökalu useimmille tiimeille. Lean 4 -lähestymistapa vaatii merkittävää säätöä, ja indeksoitujen tyyppien kanssa ajatteleminen tuo oman yleiskustannuksensa. Mutta taustalla oleva oivallus on arvokas riippumatta toteutuksesta.

Vibe codingia tehdessäsi et ulkoista vain koodin kirjoittamista vaan myös järjestelmäsi mentaalimallia. Tekoälyavustajasi ei tiedä tuotantoympäristöäsi. Se ei tiedä, että kontainerissasi on 512 megatavua RAM-muistia. Se ei tiedä, että Linux-ytimesi rajoittaa tiedostokuvaajat 1024:ään.

Kunnes meillä on parempia tapoja koodata nämä rajoitteet, meillä on muutamia käytännöllisiä vaihtoehtoja:

1. Ole eksplisiittinen prompteissa — "Syötetiedosto voi sisältää enintään 10 miljoonaa riviä" on parempi kuin "käsittele suuria tiedostoja tehokkaasti"

2. Testaa tuotannon kokoisella datalla — Jos koulutusdatasi on pientä, tekoälysi ei opi resurssimalleja

3. Käytä rajattuja API-rajapintoja — Arkkitehtuuri, joka luontaisesti rajoittaa resurssien käyttöä (yhteyspoolit, streaming kokonaan lataamisen sijaan) on vaikeampi käyttää väärin

4. Pidä silmällä resurssitietuista työkalukehitystä — Teollisuus alkaa tutkia tapoja tehdä rajoitteista eksplisiittisiä tekoälyn tuottamassa koodissa

Lopuksi

Vibe codingin likainen salaisuus ei ole, että se kirjoittaa buginen koodia — se on, että se kirjoittaa koodia, joka on oikein näkymättömässä rajoitusavaruudessa. Se avaruus sattuu sisältämään kannettavasi, testiympäristösi ja ehkä ensimmäiset tuhat käyttäjääsi. Se ei todellakaan sisällä "tuotantoa mittakaavassa."

Resurssitietuiset tyyppijärjestelmät, kuten tämä Lean 4 -kokeilu, osoittavat kohti tulevaisuutta, jossa "oikea" tarkoittaa enemmän kuin "logiikaltaan oikea." Se tarkoittaa "todistettavasti rajojen sisällä, jotka todella ovat olemassa."

Se on tulevaisuus, jota kohti kannattaa rakentaa. Sillä välin pidä testidatasi lähellä tuotannon kokoa, ja ehkä lisää ylimääräinen muistiinpano prompteihisi tiedostokuvaajarajoituksista.

Sinun tuleva päivystäjä-itsesi kiittää.