Rakensin tuotteen tekoälyn avulla – näin teet parannuksia rikkomatta sitä, mikä toimii

Lue lisää mallien kanssa työskentelystä Ailoot-dokumentaatiosta.

Miksi kallein työ alkaa julkaisun jälkeen?#

Rakensit sovelluksen yhdessä illassa, julkaisit linkin ja lähetit sen ystävillesi. Se toimii. Sitten viikkoa myöhemmin ensimmäinen oikea käyttäjä saapuu, napsauttaa jotakin väärällä tavalla, ja puolet ominaisuuksista lakkaa toimimasta. Pyydät Claudea korjaamaan ongelman – se korjaa yhden asian ja rikkoo toisen. Kuulostaako tutulta?

Tässä nousee esiin pääkysymys: mitä teet tuotteen julkaisun jälkeen, kun ensimmäisen toimivan prototyypin aiheuttama innostus on laantunut ja tuotetta pitää silti jotenkin ylläpitää? Tätä voisi kutsua aikuisten vibe codingiksi. Rakentaminen on jännitystä ja vauhtia. Ylläpito vaatii malttia: ymmärrät, mitä muutat, ja pidät muutokset hallinnassa. Useimmat epäonnistuvat tässä toisessa osassa, koska kukaan ei valmenna heitä siihen.

Eräs alan tutkimus analysoi yli miljoona koodimuutosta 2,444 tiimiltä ja laski, mihin tekoälykehitykseen käytetyt rahat todella menevät. Tässä tulos:

Opas ”Vibe codingin piilokustannus” selittää nämä luvut tarkemmin. Siinä kysymys oli siitä, mistä maksat. Tässä kysymys on toinen: jokaisesta dollarista 44 senttiä kuluu bugien korjaamiseen – ja koko tämän artikkelin tarkoitus on estää tuota osuutta kasvamasta. Sen kurissa pitämistä kutsutaan ylläpidoksi.

Aikuisten vibe codingia tekevän ja hermoverkkoa vain paimentavan ihmisen ero näkyy julkaisun jälkeen. Ensimmäisen koodikanta kasvaa, hän tekee parannuksia eikä mikään rikkoudu. Kuukautta myöhemmin toisen tuote on muuttunut vuotavaksi viritelmäksi, johon hän ei uskalla koskea. Seuraavaksi selitän, miten pääset ensimmäiseen ryhmään.

Mikä oikeasti hajoaa: 5 julkaisun jälkeistä katastrofia#

Nämä ovat julkisia jälkianalyysejä oikeista tekoälyllä rakennetuista tuotteista, mukana luvut ja päivämäärät. Ajattele niitä miinakentän karttana: jokainen miina on jo räjähtänyt jonkun kohdalla, ja tiedossa on tapa kiertää se.

Kaikilla viidellä tapauksella on sama perimmäinen syy. Oletusarvoisesti tekoäly saa asiat toimimaan nyt, ei turvallisesti kuukauden päästä kuormituksen alla. Et näe eroa, kun kehität omalla tietokoneellasi. Se tulee näkyviin, kun ensimmäinen pahantahtoinen tuntematon ilmestyy paikalle.

Ongelma ei ole se, ettei koodia kirjoiteta käsin – monet toimivat näin. Ongelma on se, ettei kukaan kysy: ”Onko tietokanta suojattu?” Seuraavaksi näytän kehotteen, joka esittää tämän kysymyksen puolestasi.

Ensimmäinen turvaverkko on git ja paluu ”eiliseen toimivaan tilaan”#

Kun Claude rikkoo jotakin, tarvitset painikkeen, jolla voit ”palauttaa sen eilisen kaltaiseksi”. Teknisesti painikkeen nimi on git, ja se on yksinkertaisempi kuin miltä kuulostaa.

Kolme termiä, jotka ei-ohjelmoijan on hyvä ymmärtää:

1. Repositorio – projektikansio, joka on tallennettu pilveen (yleensä GitHubiin). Kopio kaikesta koodistasi, joka ei ole vain omalla tietokoneellasi.
2. Commit – palautuspiste. Käytännössä sanot koodille: ”tallenna tässä tilassa”. Jokainen commit on merkki, johon voit palata.
3. Deploy – siirto. Koodi oli paikallisesti tietokoneellasi ja toimi vain sinulle. Deploy lähettää sen ulkoiselle palvelimelle, jotta se toimii kaikille.

Niin kauan kuin sinulla on tuoreita commit-pisteitä, voit palauttaa minkä tahansa rikkoutumisen yhdellä lauseella. Aivan kirjaimellisesti.

Rikoin jotakin – kaikki toimi eilen, mutta tänään ei. Etsi viimeisin commit, jossa kaikki toimi, näytä minulle, mitä sen jälkeen on muuttunut, ja palauta projekti siihen tilaan.

Ota heti käyttöön kaksi sääntöä, ennen kuin muut näkevät tuotteen:

• Repositorion on oltava yksityinen. Ei julkinen. Muuten kuka tahansa voi lukea koodisi ja kaiken sen sisältämän.
• Lisää salaisuustiedosto ohituslistalle. Avaimet, salasanat ja tietokannan käyttöoikeustiedot ovat erillisessä tiedostossa (yleensä .env), eikä sitä tiedostoa koskaan lisätä repositorioon. Lisää .env-rivi .gitignore-tiedostoon, niin salaisuudet pysyvät sinulla.

Claude Coden muutosten turvalliseen palauttamiseen on oma oppaansa: Näin palautat muutokset Claude Codessa. Ilman palautuspisteitä kävelet nuoralla ilman turvaverkkoa, ja ennemmin tai myöhemmin putoat.

Mitä /rewind palauttaa ja mitä se ei palauta?#

Claude Code ottaa tilannevedoksen tilasta ennen jokaista tekemäänsä muutosta. /rewind-komento (tai Esc-näppäimen painaminen kahdesti) palauttaa sekä tiedostot että keskustelun valittuun kohtaan. Se on kätevää: jos rikoit ominaisuuden viisi minuuttia sitten, voit palata viisi minuuttia taaksepäin.

Mutta tässä on ansa, jonka vuoksi aloittelijat menettävät tietoja. /rewind ei palauta kaikkea:

Anthropic sanoo asian suoraan: tilannevedokset ovat paikallinen kumoa-painike, kun taas git on pysyvä historia. Tilannevedokset täydentävät versionhallintaa, mutta eivät korvaa sitä.

Käytännön opetus ei-ohjelmoijalle: /rewind pelastaa sinut tilanteelta ”Claude rikkoi juuri ominaisuuden”. Mutta jos se ehti poistaa tietokantarivin tai ladata koodin pilveen, vain git ja tietokannan varmuuskopio voivat palauttaa sen. Pidä siis molemmat kerrokset: tilannevedokset nopeisiin palautuksiin ja commitit projektin pysyvään historiaan.

Miten teet parannuksia rikkomatta jo toimivia asioita?#

Joka toinen ihminen jää tähän kierteeseen. Pyydät tekoälyä korjaamaan pienen bugin. Se ehdottaa järkevää muutosta. Muutos rikkoo jotakin muuta. Pyydät sitä korjaamaan uuden ongelman, ja kaksi ongelmaa lisää ilmestyy. Ja niin edelleen.

Kierre syntyy, koska vibe coding ei ole determinististä. Sama kehote tuottaa kahdella kerralla erilaista koodia. Siksi jokainen muokkaus voi huomaamatta siirtää ympäröivää logiikkaa: alennusraja muuttuu 10 prosentista 12 prosenttiin tai validointisääntö muuttaa toimintaansa – ilman että tarkistat mitään tai saat yhtäkään varoitusta. Tätä kutsutaan loogiseksi ajautumiseksi, ja se vahingoittaa huomaamatta juuri niitä asioita, jotka tuovat rahaa: hintoja, käyttöoikeuksia ja maksuja.

Ajautumista ehkäisee yksi sääntö, joka on niin yksinkertainen, että sen voi ripustaa seinälle: älä tee commitia koodista, jota et pysty selittämään toiselle ihmiselle sana sanalta.

Käytännössä tästä tulee valmis ohje, jota käytät ennen mitä tahansa toimivan koodin muutosta. Se saa tekoälyn etenemään pienin askelin ja näyttämään tarkasti, mikä muuttui.

Tee seuraavat asiat ennen koodin muuttamista:

Tallenna nykyinen toimiva tila erilliseksi palautuspisteeksi (commit).

Kuvaile sanoin tarkasti, mitä aiot muuttaa ja missä tiedostoissa.

Tee pienin mahdollinen muutos – vain se, mikä ratkaisee tehtäväni, ei mitään ylimääräistä.

Näytä, mikä muuttui, ja selitä jokainen muutos niin, että voisin selittää sen toiselle ihmiselle.
Älä koske hinnoittelu-, käyttöoikeus- tai maksulogiikkaan, ellen pyydä sitä.

Toinen viikkoja säästävä periaate on tehtävän rajojen noudattaminen. Yksi ongelma, yksi muutos, nopea toteutus. Älä pyydä tekoälyä kirjoittamaan puolta projektia uudelleen yhdellä kehotteella. Ammattikehittäjät aloittavat joskus kokonaisen Uberin rakentamisen, vaikka tarvitsivat vain yhden painikkeen – ja venyttävät työn kuukausiin. Sinun ei tarvitse tehdä niin.

Kaiken kuvaamani perustana on yksi asia: kontekstin hallinta. Jotta tekoäly ei rikkoisi viereistä logiikkaa, sen on muistettava projektisi säännöt.

Miten tarkistat muutoksen ennen julkaisua?#

”Se toimii minun tietokoneellani” ja ”se toimii kaikille” -tilojen välissä on välivaihe, jonka aloittelijat ohittavat: testikopio. Se on erillinen tilannevedos tuotantoympäristöstä, jossa tarkistat muutoksen ennen kuin oikeat ihmiset näkevät sen. Työkierto näyttää tältä:

1. Rakenna ja tarkista muutos itse (kehitys).
2. Vie se staging-ympäristöön – tuotannon kopioon, jossa ei ole oikeita käyttäjiä.
3. Käy tärkeimmät käyttötapaukset läpi ja varmista, ettei mikään ole muuttunut.
4. Vie se tuotantoon vasta nyt.

Miksi tämä on tärkeää julkaisun jälkeen? Jokainen julkaisu sisältää riskin. Pieni koodimuutos voi rikkoa kirjautumisen. Yksi puuttuva asetus voi kaataa koko tuotteen. Staging löytää nämä ongelmat ilman seurauksia; tuotannossa menetät asiakkaita.

Jotta sinun ei tarvitse tarkistaa kaikkea joka kerta käsin, anna tekoälylle kehote, joka vertaa uuden version toimintaa vanhaan kriittisillä alueilla.

Olen aikeissa julkaista muutoksen. Käy tuotteen tärkeimmät käyttötapaukset läpi järjestyksessä ja tarkista, että jokainen toimii edelleen kuten ennen:

Uuden käyttäjän rekisteröityminen ja kirjautuminen.

Maksu ja käyttöoikeuden myöntäminen maksun jälkeen.

Käyttöoikeudet – tavallinen käyttäjä ei voi nähdä muiden tietoja tai ylläpitoaluetta.

Tärkeät liiketoimintalogiikan luvut (hinnat, alennukset, rajat) eivät ole muuttuneet.
Jos jokin toimii eri tavalla kuin edellisessä versiossa, pysähdy ja näytä täsmälleen, mikä muuttui.

Missä salaisuutesi ovat? Aloittelijan suurin tietoturva-aukko#

Selitän suurimman miinakentän yksityiskohtaisesti, koska se tuhoaa tuotteita enemmän kuin mikään muu. Kun tekoäly kirjoittaa koodia, helpointa on laittaa avain paikkaan, jossa se toimii heti – suoraan selaimessa avautuvan sivun koodiin. Et huomaa eroa kehityksen aikana. Mutta kuka tahansa voi lukea kaiken, mikä päätyy selaimeen, avaamalla kehittäjätyökalut.

Perustaja, jonka asiakkailta veloitettiin $87,500, sanoi myöhemmin, että yksi kehote olisi voinut estää sen. Veloitukset kumottiin lopulta, mutta palautuskelvottomat maksut ja menetetty mielenrauha jäivät. Tässä on kyseinen kehote.

Tarkista koko projekti ja varmista, ettei yksikään salainen avain päädy selaimeen:

Etsi kaikki tietokannan, maksujärjestelmän ja ulkoisten palveluiden avaimet.

Varmista, että jokainen niistä on tallennettu vain palvelimelle ympäristömuuttujiin eikä sivun koodiin.

Tarkista projektin historia – onko jokin avain vahingossa päätynyt sinne aiemmin?
Näytä luettelo kaikista paikoista, joista löysit salaisuuksia, ja kerro, mitä kullekin niistä pitää tehdä.

Seuraava läheinen miina on käyttöoikeuksien tarkistaminen vain selaimen puolella. Jos tuotteesi päättää sivun koodissa, ”näytetäänkö ylläpitoalue”, kuka tahansa voi kiertää päätöksen. Käyttöoikeudet on aina tarkistettava palvelimella. Tietokannan pitää palauttaa tietoja vain niille, joilla on niihin oikeus – tätä varten on rivitason tietoturva (RLS), ja se on otettava käyttöön jokaisessa taulussa.

Ennen kuin myyt käyttöoikeuksia tai päästät muita sisään, tee tuotteelle yleinen tietoturvatarkastus.

Käy projekti läpi hyökkääjän näkökulmasta ja etsi tietoturva-aukkoja:

Onko salaisia avaimia koodissa, joka päätyy selaimeen, tai projektin historiassa?

Onko rivitason tietoturva (RLS) käytössä jokaisessa tietokantataulussa, ja tarkistetaanko käyttöoikeudet palvelimella eikä vain selaimessa?

Onko tietokannan automaattinen varmuuskopiointi määritetty, ja olenko koskaan tarkistanut, että pystyn palauttamaan tiedot siitä?

Onko tuotantotietokanta eristetty ympäristöstä, jossa tekoälyagentti toimii?
Kerro jokaisen kohdan osalta, onko kaikki kunnossa vai mitä täsmälleen pitää korjata.

Vibe codingin tietoturvasta on erillinen kattava opas: Näin suojaat vibe codingilla rakennetun sovelluksen. Sääntö on yksinkertainen: pidä kaikkea tekoälyn tekemää oletusarvoisesti suojaamattomana, kunnes olet varmistanut muuta.

Missä tuotetta kannattaa hostata: hosting-portaat#

Sinun ei tarvitse heti vuokrata omaa palvelinta ja määrittää sitä käsin – se on alkuun monimutkainen tehtävä ja vie aikaa. Tuotteen kasvaessa voit edetä portaita pitkin:

1. Ilmainen hosting (esimerkiksi Vercel) – omaan käyttöön, testeihin ja pieniin projekteihin. Se toimii, jos alusta on yleisösi käytettävissä etkä tallenna ihmisten henkilötietoja.
2. Alusta, jossa käyttöönotto tapahtuu yhdellä komennolla (Railway) – kun sinulla on backend ja tietokanta. Otat sen käyttöön yhdellä komennolla ilman palvelimen määrittämistä. Aloituskynnys on hyvin matala.
3. Oma erillispalvelin – kun kuormitus on suuri ja tarvitset täyden hallinnan. Siirry siihen myöhemmin, kun olet saavuttanut alustan rajan.

Juuri julkaisseelle ei-ohjelmoijalle helpoin vaihtoehto on alusta, jossa käyttöönotto tapahtuu yhdellä komennolla ilman palvelimen manuaalista määrittämistä. Siirry omalle palvelimelle myöhemmin. Jos haluat seurata tätä polkua konkreettisen esimerkin avulla, lue opas siitä, kuinka vibe codingilla rakennettu projekti otetaan käyttöön omalla palvelimella Coolifyn avulla.

Milloin sovellus, tietokanta ja varmuuskopiot kannattaa erottaa?#

Kolmea asiaa ei pitäisi säilyttää samassa korissa: sovellusta, tietokantaa ja varmuuskopioita. Kun käyttäjiä on vähän, kaikki on yhdessä, ja se on ihan hyvä. On kuitenkin selkeä merkki siitä, milloin ne kannattaa erottaa.

• Sijoita sovellus ja tietokanta eri koneille. Merkki: huippukuormituksessa suorittimen ja muistin käyttö pysyy yli 70–80 prosentissa, pyynnöt hidastuvat ja sovellus ja tietokanta kilpailevat samoista resursseista. Erottamisen jälkeen voit vahvistaa tietokantaa koskematta sovellukseen ja päinvastoin.
• Noudata 3-2-1-varmuuskopiointisääntöä. Kolme kopiota tiedoista, kahdella erityyppisellä medialla, joista yksi säilytetään muualla. Tämä suojaa laitteistovioilta ja kiristyshaittaohjelmilta. Olennaista on, että varmuuskopiot tehdään automaattisesti.

Varmuuskopioinnin tiheys riippuu siitä, kuinka kalliiksi usean tunnin tietojen menetys tulee. Verkkopohjaisessa tilauspalvelussa, jossa tunnin maksutietojen menetystä ei hyväksytä, varmuuskopiointivälin pitää olla alle tunti tai käytössä on oltava todennetut tapahtumalokit ja tiettyyn ajanhetkeen palautus (PITR). Valitse väli suurimmasta siedetystä tietohäviöstä ja testaa palvelun palautumiseen kuluva aika erikseen. Blogille riittää kerran päivässä. Logiikka on yksinkertainen: päätä, kuinka paljon tietoja sinulla on varaa menettää, ja määritä varmuuskopiointi sen mukaan.

Auta minua päättämään, onko tuotteeni aika siirtää vakavampaan infrastruktuuriin. Tarkista jokainen kohta ja kysy siitä minulta:

Kuinka kuormittuneita suoritin ja muisti ovat huippukuormituksessa – pysyykö käyttö yli 70–80 prosentissa vai ei?

Ovatko tietokanta ja sovellus samalla koneella vai eri koneilla?

Onko tietokannan automaattinen varmuuskopiointi määritetty, ja olenko testannut siitä palauttamista?

Onko ympäristöstä erillinen kopio (staging), jossa muutokset voidaan tarkistaa ennen käyttöönottoa?
Anna tulosten perusteella selkeä suositus: mikä kannattaa jättää ennalleen, mikä erottaa ensin ja miksi.

Erikseen on kysymys siitä, käytätkö hallinnoitua tietokantaa vai omaa. Pienelle tiimille hallinnoitu on melkein aina parempi: oma on laitteistokustannuksiltaan halvempi, mutta vie tunteja ylläpitoon. Jos olet yksin eikä tuotteesi ole infrastruktuuri, nuo tunnit maksavat enemmän kuin palvelimen hinnan erotus.

Miten automatisoit ylläpidon?#

Manuaalinen ylläpito on uuvuttavaa. Voit vähentää sitä kahdella tavalla: valvonnalla ja partioivalla agentilla.

Valvontaan käytetään kahta eri työkalua kahteen eri tehtävään:

1. ”Onko sivusto toiminnassa?” – käytettävyysvalvonta (esimerkiksi UptimeRobot). Se pingaa tuotetta muutaman minuutin välein ja lähettää hälytyksen, jos palvelu kaatuu. Saatavilla on maksuton paketti.
2. ”Mikä tarkalleen meni rikki?” – virheseuranta (esimerkiksi Sentry). Se kerää sovelluksen sisäisiä virheitä ja näyttää, missä ja miksi jokin epäonnistui.

Ensimmäinen havaitsee, että tuote kaatui. Toinen kertoo, mikä ominaisuus epäonnistui ja miksi. Yhdessä ne vastaavat kysymykseen: ”Saanko tietää virheestä ennen kuin asiakas kirjoittaa tukeen?”

Toinen automaation taso on partioiva agentti. Kuvittele kiinteistönvälitystoimisto: aamuseitsemältä tekoälyagentti lukee verkkosivuston yhteydenotot, huomaa varauslomakkeen olevan rikki, löytää syyn koodista ja tuo valmiin korjauksen selityksineen. Tarkistat sen ja sanot ”kyllä” – se otetaan käyttöön. Järjestyksellä on väliä: ratkaise ensin käyttäjän ongelma (myönnä käyttöoikeus, pyydä anteeksi), tutki vasta sitten syy ja rahat.

Vielä yksi sääntö tekoälyn tuotantotietokantaan pääsystä: anna sille vain lukuoikeuksilla varustettu käyttäjä ja piilota henkilötiedot välityskerroksen taakse, jotta agentti näkee ”nimi” eikä henkilön oikeaa nimeä. Näin se ei fyysisesti pysty poistamaan tai turmelemaan tuotantotietoja, vaikka tekisi virheen. Yllä olevan taulukon tapaus, jossa agentti tyhjensi tuotantotietokannan, kertoo juuri tämän rajoituksen puuttumisesta. Oppaassa Mitä tehdä, jos tekoäly poisti tietokantasi kerrotaan, miten toimia, jos katastrofi on jo tapahtunut.

Milloin tuote kannattaa sulkea?#

Ylläpidon aliarvostetuin osa on tietää, milloin ylläpito kannattaa lopettaa. Kaikilla, jotka rakentavat paljon, on projektihautausmaa: yksi rakennettiin, sen kanssa puuhattiin ja se sitten hylättiin. Se on normaalia, eikä se ole epäonnistuminen. Epäonnistuminen on roikottaa kuukausia mukana jotakin, jota kukaan ei käytä, koska harmittelet siihen käyttämääsi aikaa.

Päätöksenteossa voi käyttää näitä rajoja:

1. Kaksi viikkoa – riittää sen näkemiseen, toimiiko idea. Jos ensimmäiset oikeat käyttäjät palaavat, jatka. Hiljaisuus on vastaus.
2. Kolme kuukautta – ehdoton raja. Jos se ei ole lähtenyt lentoon kolmessa kuukaudessa, sulje se. Vibe codingin vauhdilla kuuden kuukauden käyttäminen yhden idean testaamiseen on liian pitkä aika.

Projektin sulkeminen on henkisesti vaikeaa, joten käsittele sitä päätöksenä, älä tunteena. Sijoittamastasi projektista luopuminen on kuin sellaisen työntekijän irtisanominen, joka ei pysty tekemään työtään: epämiellyttävää, mutta hänen pitämisensä maksaa enemmän kuin hänen päästämisensä lähtemään.

Ylläpito on työtä, jolla tuote pidetään elossa ja ihmisille hyödyllisenä. Kaikki muu – git, varmuuskopiot ja valvonta – on vain välineitä, joiden avulla pääset pisteeseen, jossa tuote alkaa tehdä työtä puolestasi joka päivä.

Tuotteen rakentaminen tekoälyn avulla yhdessä illassa on puolet työstä. Sen pitäminen elossa ja turvallisena sen kasvaessa – sitä aikuisten vibe coding tarkoittaa.

Seuraavaksi – Ailoot.