Izdelek sem ustvaril z umetno inteligenco: kako ga izboljševati, ne da bi pokvaril, kar deluje

Več o delu z modeli preberite v dokumentaciji Ailoot.

Zakaj se najdražje delo začne po uvedbi?#

V enem večeru ste izdelali aplikacijo, objavili povezavo in jo poslali prijateljem. Deluje. Nato se teden dni pozneje pojavi prvi resnični uporabnik, nekaj klikne na napačen način in polovica funkcij preneha delovati. Prosite Clauda, naj to popravi—eno stvar popravi, drugo pa pokvari. Se sliši znano?

In tu se pojavi glavno vprašanje: kaj storiti po uvedbi izdelka, ko je evforija ob prvem delujočem prototipu minila, izdelek pa morate še vedno nekako vzdrževati? Temu bi lahko rekli vibe coding za odrasle. Izdelava je vznemirljiva in hitra. Vzdrževanje zahteva trezno glavo: razumeti morate, kaj spreminjate, in ohraniti nadzor. Večina ljudi pri tem drugem delu odpove, ker jih nihče ne pripravi nanj.

Panožna raziskava je analizirala več kot milijon sprememb kode 2.444 ekip in izračunala, kam dejansko gre denar, porabljen za razvoj umetne inteligence. Takole je videti:

Vodnik »Skriti stroški vibe codinga« te številke pojasni podrobneje. Tam je bilo vprašanje, kaj plačujete. Tu je vprašanje drugačno: 44 centov od vsakega dolarja gre za odpravljanje napak—in ves ta članek govori o tem, kako preprečiti, da bi se ta delež povečal. Delo, s katerim ga ohranjamo pod nadzorom, se imenuje vzdrževanje.

Razlika med nekom, ki uporablja vibe coding za odrasle, in nekom, ki zgolj varuje nevronsko mrežo, se pokaže po uvedbi. Prvemu raste kodna zbirka, izboljšuje jo in nič se ne pokvari. Mesec dni pozneje se je izdelek drugega spremenil v luknjast zmazek, ki se ga ta boji dotakniti. V nadaljevanju bom pojasnil, kako se uvrstiti v prvo skupino.

Kaj se dejansko pokvari: 5 katastrof po uvedbi#

To so javno objavljene analize resničnih izdelkov, ustvarjenih z umetno inteligenco, s številkami in datumi. Predstavljajte si jih kot zemljevid minskega polja—vsaka mina je nekomu že eksplodirala, način, kako se ji izogniti, pa je znan.

Vseh pet primerov ima enak temeljni vzrok. Umetna inteligenca privzeto poskrbi, da stvari delujejo zdaj, ne pa varno čez mesec dni ob obremenitvi. Razlike ne morete videti, ko razvijate na svojem računalniku. Pokaže se, ko se pojavi prvi neznanec s slabimi nameni.

Težava ni v tem, da kode ne pišete ročno—tako dela veliko ljudi. Težava je, če nihče ne vpraša: »Ali je zbirka podatkov zaščitena?« V nadaljevanju vam bom pokazal poziv, ki to vprašanje zastavi namesto vas.

Prva varnostna mreža sta git in vrnitev na stanje »kot včeraj«#

Ko Claude nekaj pokvari, potrebujete gumb »vrni nazaj, kot je bilo včeraj«. Tehnično se ta gumb imenuje git in je preprostejši, kot se sliši.

Trije izrazi, ki jih mora razumeti nekdo, ki ni programer:

1. Repozitorij — mapa vašega projekta, shranjena v oblaku (običajno na GitHubu). Kopija vse vaše kode, ki ni samo na vašem računalniku.
2. Commit — točka, na katero se lahko vrnete. Kodi pravzaprav poveste: »shrani jo v tem stanju«. Vsak commit je oznaka, na katero se lahko vrnete.
3. Deploy — premik. Koda je bila lokalna, na vašem računalniku, in je delovala samo za vas. Deploy jo pošlje na zunanji strežnik, kjer deluje za vse.

Dokler imate nedavne točke commit, lahko vsako okvaro povrnete z enim stavkom. Dobesedno.

Nekaj sem pokvaril—včeraj je vse delovalo, danes pa ne. Poišči zadnji commit, ko je bilo vse v redu, pokaži mi, kaj se je od takrat spremenilo, in povrni projekt v to stanje.

Dve pravili, ki ju uvedite takoj, preden izdelek vidijo drugi:

• Repozitorij mora biti zaseben. Ne javen. V nasprotnem primeru lahko vsakdo prebere vašo kodo in vse, kar vsebuje.
• Datoteko s skrivnostmi dodajte na seznam prezrtih datotek. Ključi, gesla in poverilnice za dostop do zbirke podatkov so v ločeni datoteki (običajno .env), ki nikoli ne gre v repozitorij. V .gitignore dodajte vrstico za .env, skrivnosti pa ostanejo pri vas.

O varnem povračanju sprememb v Claude Code obstaja ločen vodnik: Kako povrniti spremembe v Claude Code. Brez povratnih točk hodite po vrvi brez varnostne mreže in prej ali slej boste padli.

Kaj /rewind povrne in česa ne?#

Claude Code pred vsako spremembo, ki jo izvede, naredi posnetek stanja. Ukaz /rewind (ali dvakratni pritisk na Esc) povrne datoteke in pogovor na izbrano točko. To je priročno: če ste pred petimi minutami pokvarili funkcijo, se lahko vrnete pet minut nazaj.

Vendar obstaja past, zaradi katere začetniki izgubijo podatke. /rewind ne povrne vsega:

Anthropic to pove naravnost: posnetki so lokalni gumb »razveljavi«, git pa je trajna zgodovina. Posnetki dopolnjujejo nadzor različic, vendar ga ne nadomeščajo.

Praktični nauk za nekoga, ki ni programer: /rewind vas bo rešil, ko »je Claude pravkar pokvaril funkcijo«. Če pa mu je uspelo izbrisati vrstico v zbirki podatkov ali prenesti kodo v oblak, jo lahko povrneta samo git in varnostna kopija zbirke podatkov. Ohranite obe plasti: posnetke za hitre povrnitve in commite za trajno zgodovino projekta.

Kako izboljševati, ne da bi pokvarili, kar že deluje?#

Vsak drugi človek se ujame v ta krog. Umetno inteligenco prosite, naj odpravi majhno napako. Predlaga smiselno spremembo. Ta sprememba pokvari nekaj drugega. Prosite jo, naj odpravi novo težavo, pojavita pa se še dve. In tako naprej.

Do tega kroga pride, ker vibe coding ni determinističen. Isti poziv dvakrat ustvari različno kodo. Zato lahko vsaka sprememba potiho premakne okoliško logiko: prag za popust se spremeni z 10 na 12 odstotkov ali pa se spremeni delovanje pravila za preverjanje—ne da bi karkoli preverili ali dobili eno samo opozorilo. Temu pravimo logični odklon; potiho škoduje prav stvarem, ki prinašajo denar: cenam, dostopu in plačilom.

Obstaja eno pravilo za zaščito pred odklonom, ki je dovolj preprosto, da ga obesite na steno: ne delajte commita kode, ki je ne bi mogli drugi osebi razložiti besedo za besedo.

V praksi to postane pripravljen okvir, ki ga uporabite pred vsako spremembo delujoče kode. Umetno inteligenco spodbudi, da dela majhne korake in vam natančno pokaže, kaj se je spremenilo.

Preden spremeniš kodo, naredi naslednje:

Shrani trenutno delujoče stanje kot ločeno povratno točko (commit).

Z besedami natančno opiši, kaj nameravaš spremeniti in v katerih datotekah.

Izvedi najmanjšo možno spremembo—samo tisto, ki reši mojo nalogo, ničesar dodatnega.

Pokaži mi, kaj se je spremenilo, in razloži vsako spremembo tako, da jo bom lahko razložil drugi osebi.
Ne posegaj v logiko cen, dostopa ali plačil, razen če sem te za to prosil.

Še eno načelo, ki prihrani tedne, je disciplina pri omejevanju nalog. Ena težava, ena sprememba, hitra izvedba. Ne prosite umetne inteligence, naj z enim pozivom prepiše polovico projekta. Poklicni razvijalci včasih začnejo graditi celoten Uber, čeprav potrebujejo samo en gumb—in delo raztegnejo na več mesecev. Tega ne potrebujete.

Vse, kar opisujem, temelji na eni stvari: upravljanju konteksta. Da umetna inteligenca ne pokvari sosednje logike, si mora zapomniti pravila vašega projekta.

Kako preveriti spremembo pred objavo?#

Med »pri meni na računalniku deluje« in »deluje za vse« je vmesni korak, ki ga začetniki preskočijo: testna kopija. To je ločen posnetek vašega produkcijskega okolja, kjer preverite spremembo, preden jo vidijo resnični ljudje. Delovni cikel je videti takole:

1. Spremembo izdelajte in preverite sami (razvoj).
2. Deployajte jo v staging—kopijo produkcije brez resničnih uporabnikov.
3. Izvedite ključne scenarije in se prepričajte, da se ni nič spremenilo.
4. Šele zdaj jo deployajte v produkcijo.

Zakaj je to pomembno po uvedbi: vsaka izdaja prinaša tveganje. Majhna sprememba kode lahko pokvari prijavo v račun. Ena manjkajoča nastavitev lahko ustavi celoten izdelek. Staging odkrije te težave brez posledic; v produkciji izgubite stranke.

Da vam ne bo treba vsakič ročno preveriti vsega, umetni inteligenci dajte poziv za primerjavo vedenja nove različice s staro na ključnih področjih.

Preden deployam spremembo, zaporedno preveri ključne scenarije izdelka in se prepričaj, da vsak še vedno deluje kot prej:

Registracija in prijava novega uporabnika.

Plačilo in dodelitev dostopa po plačilu.

Pravice dostopa—navaden uporabnik ne more videti podatkov drugih ali skrbniškega območja.

Ključne številke poslovne logike (cene, popusti, omejitve) se niso spremenile.
Če se karkoli vede drugače kot v prejšnji različici, se ustavi in mi natančno pokaži, kaj se je spremenilo.

Kje so vaše skrivnosti? Največja vrzel za začetnike#

Podrobno bom razložil največjo mino, saj onesposobi več izdelkov kot katera koli druga. Ko umetna inteligenca piše kodo, je najlažje ključ postaviti tja, kjer bo takoj deloval—neposredno v kodo strani, ki se odpre v brskalniku. Med razvojem ne boste opazili razlike. Toda vsakdo lahko odpre razvijalska orodja in prebere vse, kar pride do brskalnika.

Ustanovitelj, čigar stranke so bremenili za $87,500, je pozneje dejal, da bi to preprečil že en sam poziv. Breme­nitev so nazadnje razveljavili, nepovratne provizije in izgubljeni mir pa so ostali. Takole se glasi poziv.

Preveri celoten projekt in se prepričaj, da noben skrivni ključ ne pride v brskalnik:

Poišči vse ključe za zbirko podatkov, plačilni sistem in zunanje storitve.

Prepričaj se, da je vsak shranjen samo na strežniku, v okoljskih spremenljivkah, ne pa v kodi strani.

Preveri zgodovino projekta—ali je kakšen ključ po nesreči prišel vanjo že prej?
Pokaži mi seznam vseh mest, kjer si našel skrivnosti, in kaj je treba narediti glede vsakega.

Naslednja bližnja mina je preverjanje pravic dostopa samo na strani brskalnika. Če vaš izdelek v kodi strani odloča, ali naj »prikaže skrbniško območje«, lahko vsakdo to odločitev zaobide. Pravice dostopa je treba vedno preverjati na strežniku. Zbirka podatkov mora podatke vrniti samo tistim, ki so do njih upravičeni—za to skrbi row-level security (RLS), ki jo je treba omogočiti v vsaki tabeli.

Preden začnete prodajati dostop ali spustite druge noter, opravite splošni varnostni pregled izdelka.

Preišči projekt kot napadalec in poišči varnostne vrzeli:

Ali so v kodi, ki gre v brskalnik, ali v zgodovini projekta shranjeni skrivni ključi?

Je row-level security (RLS) omogočena v vsaki tabeli zbirke podatkov in se pravice dostopa preverjajo na strežniku, ne samo v brskalniku?

Je nastavljena samodejna varnostna kopija zbirke podatkov in sem že preveril, ali jo lahko obnovim?

Je produkcijska zbirka podatkov ločena od okolja, v katerem deluje agent umetne inteligence?
Za vsako točko mi povej, ali je vse v redu, ali pa natančno, kaj je treba popraviti.

O varnosti vibe codinga obstaja ločen, celovit vodnik: Kako zavarovati aplikacijo, ustvarjeno z vibe codingom. Pravilo je preprosto: vse, kar je umetna inteligenca naredila privzeto, obravnavajte kot nezaščiteno, dokler ne preverite nasprotnega.

Kje gostiti izdelek: lestvica gostovanja#

Ni vam treba takoj najeti lastnega strežnika in ga ročno nastaviti—na začetku je to zapletena naloga, ki vam bo vzela čas. Obstaja lestvica, po kateri se lahko vzpenjate, ko izdelek raste:

1. Brezplačno gostovanje (na primer Vercel)—za vas, preizkuse in majhne projekte. Deluje, če je platforma na voljo vašemu občinstvu in ne shranjujete osebnih podatkov ljudi.
2. Platforma z deployem z enim ukazom (Railway)—ko imate zaledni sistem in zbirko podatkov. Deploy opravite z enim ukazom, strežnika pa vam ni treba nastavljati. Začetna ovira je minimalna.
3. Lasten namenski strežnik—ko je obremenitev velika in potrebujete popoln nadzor. Nanj preidite pozneje, ko dosežete omejitev platforme.

Za nekoga, ki ni programer in je pravkar uvedel izdelek, je najpreprostejša možnost platforma z deployem z enim ukazom in brez ročne nastavitve strežnika. Na lasten strežnik preidite pozneje. Če želite to pot prehoditi s konkretnim primerom, si oglejte vodnik za deploy projekta, ustvarjenega z vibe codingom, na lastni strežnik s Coolifyjem.

Kdaj ločiti aplikacijo, zbirko podatkov in varnostne kopije?#

Treh stvari ne smemo hraniti v isti košari: aplikacije, zbirke podatkov in varnostnih kopij. Dokler je uporabnikov malo, je vse skupaj, in to je v redu. Obstaja pa jasen znak, kdaj jih je treba ločiti.

• Aplikacijo in zbirko podatkov postavite na različna računalnika. Znak: ob največji obremenitvi CPU in pomnilnik vztrajata nad 70–80 odstotki, zahteve se upočasnijo, aplikacija in zbirka podatkov pa tekmujeta za iste vire. Ko ju ločite, lahko okrepite zbirko podatkov, ne da bi se dotaknili aplikacije, in obratno.
• Upoštevajte pravilo varnostnih kopij 3-2-1. Tri kopije podatkov na dveh različnih vrstah nosilcev, ena pa na drugi lokaciji. To ščiti pred odpovedjo strojne opreme in izsiljevalsko programsko opremo. Ključno je, da so varnostne kopije samodejne.

Pogostost varnostnih kopij je odvisna od tega, kako draga je izguba podatkov za nekaj ur. Pri spletni naročniški storitvi, kjer izguba ene ure zapisov plačil ni sprejemljiva, mora biti interval varnostnih kopij krajši od ure ali pa potrebujete preverjene dnevnike transakcij in obnovitev na časovno točko (PITR). Interval izberite glede na največjo dopustno izgubo podatkov, čas obnove storitve pa preizkusite posebej. Za blog zadostuje enkrat na dan. Logika je preprosta: določite, koliko podatkov si lahko privoščite izgubiti, in ustrezno nastavite varnostne kopije.

Pomagaj mi odločiti, ali je čas, da moj izdelek preide na resnejšo infrastrukturo. Preveri in vprašaj me o vsaki točki:

Kako obremenjena sta CPU in pomnilnik ob konicah—ali uporaba vztraja nad 70–80 odstotki ali ne?

Ali sta zbirka podatkov in aplikacija na istem računalniku ali na različnih?

Je nastavljena samodejna varnostna kopija zbirke podatkov in sem preizkusil njeno obnovitev?

Ali obstaja ločena kopija okolja (staging) za preverjanje pred deployem?
Na podlagi rezultatov mi jasno priporočaj: kaj naj ostane, kaj naj najprej ločim in zakaj.

Obstaja še ločeno vprašanje: upravljana zbirka podatkov ali lastna. Za majhno ekipo je upravljana skoraj vedno boljša: lastna je glede strojne opreme cenejša, vendar porabi ure za vzdrževanje. Če ste sami in vaš izdelek ni infrastruktura, te ure stanejo več kot razlika v ceni strežnika.

Kako vzdrževanje prepustiti samodejnemu delovanju?#

Ročno vzdrževanje je naporno. Lahko si ga olajšate na dva načina: z nadzorom in patruljnim agentom.

Nadzor uporablja dve različni orodji za dve različni nalogi:

1. »Ali spletno mesto deluje?«—nadzornik dosegljivosti (na primer UptimeRobot). Izdelek preverja vsakih nekaj minut in pošlje opozorilo, če preneha delovati. Na voljo je brezplačen paket.
2. »Kaj točno se je pokvarilo?«—sledilnik napak (na primer Sentry). Zbira napake znotraj aplikacije in pokaže, kje in zakaj je prišlo do napake.

Prvo orodje zazna, da je izdelek prenehal delovati. Drugo pokaže, katera funkcija je odpovedala in zakaj. Skupaj odgovorita na vprašanje: »Bom za napako izvedel, preden stranka piše podpori?«

Druga stopnja samodejnega delovanja je patruljni agent. Predstavljajte si nepremičninsko agencijo: ob sedmih zjutraj agent umetne inteligence prebere povpraševanja na spletnem mestu, ugotovi, da obrazec za rezervacijo ne deluje, poišče vzrok v kodi in prinese pripravljen popravek z razlago. Pregledate ga in rečete »da«—popravek se deploya. Vrstni red je pomemben: najprej rešite uporabnikovo težavo (dodelite dostop, se opravičite), nato raziščite vzrok in denar.

Še eno pravilo glede dostopa umetne inteligence do produkcijske zbirke podatkov: dodelite ji uporabnika samo za branje, osebne podatke pa skrijte za posredniško plast, da agent vidi »ime« namesto pravega imena osebe. Tako tudi ob napaki fizično ne bo mogel izbrisati ali poškodovati produkcijskih podatkov. Incident iz zgornje tabele, v katerem je agent izbrisal produkcijsko zbirko podatkov, govori prav o pomanjkanju te omejitve. Vodnik Kaj storiti, če je umetna inteligenca izbrisala vašo zbirko podatkov pojasnjuje, kaj storiti, če je do katastrofe že prišlo.

Kdaj je čas za zaustavitev izdelka?#

Najbolj podcenjen del vzdrževanja je vedeti, kdaj ga prenehati izvajati. Vsakdo, ki veliko ustvarja, ima pokopališče projektov: enega je zgradil, se z njim ukvarjal, nato pa ga opustil. To je normalno in ni neuspeh. Neuspeh je več mesecev vleči za seboj nekaj, česar nihče ne uporablja, ker vam je žal porabljenega časa.

Pragovi, ki vam lahko pomagajo pri odločitvi:

1. Dva tedna—dovolj, da ugotovite, ali zamisel deluje. Če se prvi resnični uporabniki vrnejo, nadaljujte. Molk je odgovor.
2. Trije meseci—trda meja. Če se izdelek v treh mesecih ne uveljavi, ga zaustavite. Glede na hitrost vibe codinga je šest mesecev testiranja ene zamisli predolgo.

Zapreti projekt je psihološko težko, zato to obravnavajte kot odločitev, ne kot občutek. Opustiti projekt, v katerega ste vlagali, je kot odpustiti zaposlenega, ki ne zmore opravljati dela: neprijetno, vendar njegovo obdržanje stane več kot odpustitev.

Vzdrževanje je delo, s katerim izdelek ostane živ in uporaben za ljudi. Vse drugo—git, varnostne kopije, nadzor—so samo orodja, ki vam pomagajo doseči točko, ko vam izdelek začne vsak dan služiti.

Izdelava izdelka z umetno inteligenco v enem večeru je polovica dela. Ohraniti ga živega in varnega, ko raste—to pomeni vibe coding za odrasle.

Naslednji korak—Ailoot.