Kun tekoäly epäonnistuu tyhmästä syystä

On tietynlainen turhautuminen, joka tulee siitä, kun katsoo älykkään järjestelmän mokaa jotain täysin typerää. Kohtasin tämän hiljattain kokeillessani paikallisia AI-koodausagentteja – ilmiö, joka on kasvattamassa suosiotaan kun avoimet mallit paranevat ja yksityisyys tietokoneilla kiinnostaa yhä enemmän.

Kokeilu oli yksinkertainen: voiko täysin omalla raudalla pyörivä koodausagentti rakentaa toimivan pelin? Ei mitään yksinkertaista demoa, vaan jotain jossa on oikeaa tilanhallintaa, renderöintilogiikkaa, syötteiden käsittelyä ja pelattava käyttöliittymä. Vastaus, melkoisen päänraapimisen jälkeen, oli kyllä – mutta sinne päästäkseen jouduin kohtaamaan ongelmia, joihin AI-työkalujen ekosysteemi ei osaa reagoida kunnolla.

Ympäristö, jonka piti toimia

Käytössä oli kolme komponenttia, jotka edustavat paikallisen AI-kehityksen kärkeä: provider-agnostinen koodausagentin CLI, Ollama joka tarjoaa OpenAI-yhteensopivaa API:a localhostissa, ja Qwen3.8 27B pyörimässä omalla koneella. Kyseessä ei ollut alitehoinen kokoonpano – 27B-malli 17 gigalla mahtuu mukavasti 32 gigatavun muistiin ja tukee tool callingia kohtuullisen päättelykyvyn kera.

Alkutulokset olivat lupaavia. Vartissa agentti oli tuottanut täydellisen HTML-rakenteen ja lähes 200 riviä NES-tyylistä CSS:ää viistotuilla reunoilla ja oikealla värimaailmalla. Vielä vaikuttavampaa: agentti huomasi itse tekemänsä virheen kesken kaiken. Se kirjoitti tiedoston, luki sen takaisin, huomasi eron aikeidensa ja levylle päätyneen sisällön välillä, ja korjasi tilanteen ilman pyyntöä. Tämä on aitoa agenttimaista käyttäytymistä, ja se lupasi hyvää.

Sitten agentti yritti kirjoittaa pelilogiikkatiedostoa, ja kaikki pysähtyi.

Kuolemakierre

Seuraavaksi tapahtui jotain, minkä jokainen AI-työkalujen kanssa paininut tunnistaa. Kolmetoista peräkkäistä yritystä kirjoittaa pelimoottoritiedosto, joista jokainen katkesi kesken generaation. Virtaus vain lakkasi, ilman virhettä, ilman selitystä, ilman käyttökelpoista tulosta.

Kurjin osuus ei ollut epäonnistuminen itsessään – vaan agentin päättelyprosessin seuraaminen. Koska jokainen yritys alkoi alusta, malli johti samat suunnittelupäätökset alusta asti, päätyen erilaisiin pistetaulukkoihin ja toteutustapoihin joka kerta. Kolme yritystä, kolme eri vastausta samaan arkkitehtuurikysymykseen. Agentti käytti tunnin ajatteluun ja tuotti tyhjää.

Ilmeinen syyllinen vaikutti olevan muistipaine. Suljin välilehtiä ja vapautin useita gigatavuja RAMia, ja tilanne parani hieman – mikä näytti vahvistavan diagnoosin. Mutta tästä päätelmästä piti ottaa opiksi toisin.

Mitä lokit oikeasti kertoivat

Palatessaani palvelinlokeihin tarina olikin toinen. Yhtään muistivirhettä ei löytynyt yhdestäkään niistä. Vapaata muistia oli koko ajan 21–27 gigatavun välillä, kun malli vei 17 gigatavua. Muisti ei koskaan ollut ongelma.

Todellinen syy oli konfiguraatiomonikko, joka ei tuottanut näkyvää virhettä. Agentin konfiguraatio mainosti 32 768 tokenin konteksti-ikkunaa. Mutta Ollama-palvelin oli käynnistetty uudelleen 8 192 tokenin katolla, ja tämä ristiriita jäi huomaamatta. Agentti suunnitteli onnellisesti 800 rivin tiedoston kirjoittamista yhdellä kertaa, koska sen mukaan tilaa oli 32k. Kun generaatio osui 8k-seinään kesken tool callin, yhteys katkaistiin ilman virheilmoitusta, josta agentti voisi päätellä mitään.

Toinen komplikaatio piileskeli käynnistyslogeissa: Ollama oli käynnistetty context shifting päällä, mikä olisi sallinut ikkunan liukumisen kun tila loppui, uhraamalla vanhempia tokeneita uusien tieltä. Mutta mallin arkkitehtuuri ei tukenut tätä ominaisuutta, joten se oli hiljaisesti poistettu käytöstä. Sen sijaan että olisi tullut pehmeä raja, tuli kova seinä.

DevOps-kuria tekoälykehitys vaatii

Tämä kokemus kiteyttää jotain tärkeää paikallisesta tekoälykehityksestä, jonka avointen mallien innostus usein peittää alleen. Kun ajat malleja omalla raudalla, et ole vain kirjoittamassa koodia – operoit infrastruktuuria. Ja infrastruktuuri vaatii samaa diagnostiikkadispliiniä, konfiguraationhallintaa ja huomiota operatiivisiin parametreihin kuin tuotantoympäristöt.

Konteksti-ikkunat eivät ole abstrakteja malliominaisuuksia, jotka asetetaan ja unohdetaan. Ne ovat operatiivisia parametreja, jotka vuorovaikuttavat työkalujen kanssa ei-ilmeisillä tavoilla. Kun agentin konfiguroitu konteksti ei vastaa palvelimen todellista kattoa, varoitusta ei tule – tulee hiljaisia epäonnistumisia, jotka näyttävät mallin epäpätevyydeltä, vaikka kyseessä on operatiivinen virhekonfiguraatio.

Käytännön opetus kehittäjille, jotka tutkivat paikallisia AI-koodausagentteja, on suoraviivainen: validoi ympäristösi yhtä perusteellisesti kuin validoisit tuotantoympäristön. Tarkista että agenttisi konfiguraatio vastaa ajonaikaisia parametrejasi. Lue palvelinlogit, älä vain agentin tulostetta. Ymmärrä mitä ominaisuuksia mallisi arkkitehtuuri oikeasti tukee versus mitä työkalut yrittävät mahdollistaa.

Mallit paranevat. Työkalut kypsyvät. Mutta rako "demossa toimii" ja "toimii luotettavasti päivittäisessä käytössä" vaatii edelleen ihmisen harkintaa – ja se harkinta näyttää paljon perinteiseltä DevOps-displiiniltä, sovellettuna uudenlaiseen infrastruktuuriin.

Tetris-buildi lopulta onnistui. Siihen meni neljä ja puoli tuntia kahdessa päivässä, tuotettiin puhdasta koodia kolmeen tiedostoon, ja kaikki toimii oikein. Mutta opit tulivat ei onnistumisesta, vaan ymmärtämällä miksi epäonnistumiset tapahtuivat – ja tunnistamalla, että joskus kalleimmat ongelmat eivät liity älykkyyteen lainkaan.