AI Elkarrizketa Seriea 15: Zeintzuk dira Vibe Coding-en ohiko zuloak?
Vibe Coding-ren "sentsazioa/giroa bultzatutako" modua prototipo azkarrak eta sormen-esplorazioa egiteko oso polita den arren, kontrolatu gabe, erraz erortzen da zenbait zulo tipikotan. Jarraian, kode kalitatea, mantentzeko erraztasuna, segurtasuna, eskakizunen bilakaera, talde lankidetza bost dimentsioetatik laburbiltzen dut.
1. Kode kalitatearen zuloak
Vibe Coding elkarrizketa bidezko iterazioan oinarritzen denez, erabiltzaileak aldaketa lausoak eskatzen dituen bakoitzean (adibidez, "egin botoi hau gehiago teknologikoa"), AI-k kode berria gehitzea jo ohi du, jatorrizko logika birkonfiguratu beharrean. Ez daki zein kode zaharkitua den eraginkorra, eta ez du ezabatzeko ausartzen, hondakin eta kode hilak pilatuz. Aldi berean, AIn ez dago "kode estiloa gogoratzeko" memoriorik; sorpen bakoitzean izendapen ohitura ezberdinak jarrai ditzake (prestakuntza laginaren ausazkotasunaren arabera), eta erabiltzaileak normalean esplizituak diren arauak ematen ez dituenez, azken kodeak nahasia eta aurreikusteko zaila bihurtzen da. Laburbilduz:
- Hondakin eta kode hilak: Hainbat adabaki ondoren, AIk aurreko inplementazioak, iruzkindutako kode blokeak, erabiltzen ez diren inportazioak uzten ditu, ezabatzeko arriskua handia delako eta horiek mantentzea aukeratzen duelako.
- Izendapen eta estilo ez koherenteak: Aik ausaz ateratzen du estiloa prestakuntza datuetatik hainbat txandatan, erabiltzaileak arauak behartzen ez baditu, camelCase, underscore eta zuriuneak nahastuko dira.
- Ezkutuko logika erroreak: Aik "bide arrunta" zuzena duen kodea sortzeko joera du, baina muga baldintzak (balio hutsak, muturreko balioak, konkurrentzia) askotan alde batera uzten ditu, prestakuntza datuetan halako adibideak gutxiago direlako.
2. Mantentzeko erraztasunaren zuloak
Vibe Coding-en iterazio abiadura izugarri azkarra da, erabiltzailea eta AIa unean uneko funtzioa erabilgarria den ala ez zentratzen dira, eta ia denborarik ez dute dokumentazioa, iruzkinak edo birkonfigurazioa idazteko. Aik epe luzeko memoriarik ez duenez, ez du automatikoki docstring-ik gehitzen funtzioentzat, eta ez du kontuan hartzen hurrengo garatzailea. Gainera, Aik "unean beharrekoa konpontzeko" joera du: batzuetan, marko orokor bat diseinatzen du gaindimentsionatuta (erabiltzaileak gero behar izango duela pentsatuz), eta beste batzuetan, kopiatu eta itsatsi beharrezko inplementazioa egiten du, abstrakzio mailak nahastuz. Laburbilduz:
- Dokumentazio eta iruzkin falta: Aik "auto-azalpena" den kodea sortzen du lehenetsita, baina benetan regex edo algoritmo konplexuak zailak dira ulertzeko; erabiltzaileak eskatzen ez badu, ez du dokumentaziorik idatziko.
- Gehiegizko abstrakzioa edo abstrakzio falta: Aik batzuetan ohiko diseinu patroiak aplikatzen ditu (factory, strategy), arazoa sinplea izan arren; beste batzuetan, funtzio komunak erauzteko ahaleginik egin gabe, zuzenean kode blokeak kopiatzen ditu.
3. Segurtasun zuloak
AI-ren prestakuntza datuek kode irekiko asko dute, tartean historikoki ahultasunak dituztenak (adibidez SQL katekatzea, gako gogor kodetuak). Vibe Coding-en, erabiltzaileak gutxitan eskatzen du "erabili kontsulta parametrizatuak" edo "irakurri sekretuak ingurune aldagaietatik", beraz AIk ohikoena (eta sarritan segurtasun gabekoa) den eredua hartuko du. Gainera, AIn ez dago "mehatxu eredua" kontzientziarik; ez du automatikoki egiaztatzen sarrera iragazkia, baimen minimizazioa, funtzionaltasun ezarpenean bakarrik zentratzen baita. Laburbilduz:
- Injekzio ahultasunak: Aik lehenetsita kate-katea erabiltzen du SQL/komandoak eraikitzeko, metodo hori ohikoena delako tutorial sinpleetan.
- Sekretu gogor kodetuak: Prestakuntza laginetako adibideek maiz API gakoak gogor idatzita dituzte, eta Aik eredu hori imitatzen du.
- Baimen gehiegi: Aik erraztasunagatik,
sudoedow+modua erabiltzen du fitxategiak irekitzeko, beharrezkoa den gutxieneko baimena kontuan hartu gabe.
4. Eskakizunen bilakaeraren zuloak
Vibe Coding-ek ez du muga argirik. Erabiltzaileak "gehitu beste funtzio bat" esaten duenean, Aik ahal duena egingo du, baina ez daki zer den "esparrutik kanpo". Aik ez du lehentasunen kontzepziorik; aldi berean hiru ezaugarri osagarri inplementa ditzake, funtzio nagusia itzaltzeko arriskuan. Aldi berean, akats berria zuzentzean, Aik ez du funtzio zaharrak berrikusten, eta maiz A konpontzean B apurtzen duen atzerakada gertatzen da. Laburbilduz:
- Esparruaren hedapena: Aik "erabiltzailea pozteko" aktiboki gehitzen ditu itxuraz erlazionatuta baina beharrezkoak ez diren funtzioak (adibidez, kalkulagailuari historia gehitzea).
- Funtzio atzerakada: Aik akats bat konpontzean, logika orokorra ezagutzen ez duenez, funtzio publiko bat aldatzen du, eta horrek beste funtzio batzuen funtzionamendua apurtzen du.
5. Talde lankidetza zuloak
Vibe Coding-en elkarrizketa prozesua pertsona eta AI arteko elkarrekintza pribatua da, eta ez da utz daitekeen dokumentazio edo diseinu erabakien erregistrorik. Taldekide ezberdinek AIrekin banaka hitz egiten dute, bakoitzak bere estiloko kodea lortuz, eta batzean gatazka ugari sortzen dira. Gainera, Aik automatikoki ez du commit mezu edo aldaketa erregistrorik sortzen; kodearen bilakaeraren arrazoia galdu egiten da, eta mantentze langileek asmatu behar dute. Laburbilduz:
- Berriz ezin eraiki diren eraikuntzak: Pertsona ezberdinek, une ezberdinetan, prompt bera erabiliz, AIk inplementazio ezberdinak ematen ditu (laginketa ausazkoa delako).
- Aldaketen jarraipen falta: Ez dago diseinu dokumenturik, ez commit mezuak "zergatik aldatu den" azaltzen dutenik; kodea kaxa beltz bihurtzen da.
评论
暂无已展示的评论。
发表评论(匿名)