AI Panayam Serye 15: Ano ang mga Karaniwang Pitfalls ng Vibe Coding?

Ang modelong "pakiramdam/atmosphere-driven" ng Vibe Coding ay talagang kasiya-siya para sa mabilisang prototyping at pag-explore ng ideya, ngunit kung hindi kontrolado, madaling mahulog sa ilang tipikal na pitfalls. Nasa ibaba ang buod mula sa limang dimensyon: kalidad ng code, pagpapanatili, seguridad, ebolusyon ng pangangailangan, at pakikipagtulungan ng koponan

Una: Pitfalls sa Kalidad ng Code

Dahil ang Vibe Coding ay umaasa sa diyalogong pag-ulit, kapag ang user ay nagbigay ng malabong kahilingan sa pagbabago (hal. "gawing mas techy ang button na ito"), ang AI ay malamang na magdagdag ng bagong code sa halip na i-refactor ang orihinal na lohika. Hindi nito alam kung aling lumang code ang hindi na epektibo, at hindi ito basta-basta tatanggalin, na nagdudulot ng patuloy na pag-ipon ng redundancy at patay na code. Kasabay nito, walang "memorya ng estilo ng code" ang AI, kaya ang bawat pagbuo ay maaaring sumunod sa iba't ibang kombensiyon ng pagpapangalan (depende sa randomness ng training samples), at dahil bihira ang user na magbigay ng malinaw na mga pamantayan, ang code ay nagiging magulo at mahirap hulaan. Sa kabuuan:

Redundancy at Patay na Code: Pagkatapos ng maraming pag-ayos, ang AI ay mag-iiwan ng mga lumang implementasyon, naka-comment na code blocks, at hindi ginamit na import, dahil mataas ang panganib ng pagtanggal at pinipili nitong panatilihin ang mga ito.
Hindi Pare-parehong Pagpapangalan at Estilo: Ang AI ay random na kumukuha ng estilo mula sa training data sa iba't ibang round, at kung hindi pilitin ng user ang pamantayan, maghahalo ito ng camelCase, underscore, at espasyo.
Nakatagong Lohikal na Error: Ang AI ay may posibilidad na gumawa ng code na tama sa "karaniwang landas", ngunit ang mga kondisyon sa hangganan (null values, extreme values, concurrency) ay madalas na hindi pinapansin, dahil kakaunti ang ganitong halimbawa sa training data.

Dalawa: Pitfalls sa Pagpapanatili

Ang bilis ng pag-ulit ng Vibe Coding ay napakataas, at parehong nakatuon ang user at AI sa "gumagana ba ang kasalukuyang feature", na halos walang oras para magsulat ng dokumentasyon, komento, o mag-refactor. Walang pangmatagalang memorya ang AI, at hindi ito kusang magdaragdag ng docstring para sa mga function, o isaalang-alang ang susunod na developer na tatanggap ng code. Bukod dito, ang AI ay may gawi na "ayusin ang agarang pangangailangan", na maaaring magresulta sa sobrang disenyo ng isang generic na framework (akala na kailangan ito ng user sa hinaharap) o sa mabilisang copy-paste na implementasyon, na nagdudulot ng magulong antas ng abstraction. Sa kabuuan:

Kakulangan ng Dokumentasyon at Komento: Default na output ng AI ay "self-explanatory" na code, ngunit ang mga kumplikadong regex o algorithm ay mahirap maintindihan; kung hindi hihilingin ng user, hindi ito magsusulat ng dokumentasyon.
Sobra o Kulang na Abstraksiyon: Minsan ay ginagamit ng AI ang mga karaniwang design patterns (tulad ng Factory, Strategy) kahit simple ang problema; minsan naman ay dahil tamad itong kumuha ng common function, direktang kinokopya ang code block.

Tatlo: Pitfalls sa Seguridad

Ang training data ng AI ay naglalaman ng maraming open-source code, kung saan may mga historical vulnerabilities (tulad ng SQL concatenation, hardcoded keys). Sa Vibe Coding, bihira ang user na humiling na "gumamit ng parameterized query" o "magbasa ng key mula sa environment variable", kaya gagamitin ng AI ang pinakakaraniwan (at kadalasang hindi ligtas) na pattern. Bukod pa rito, walang "threat model" ang AI, at hindi nito kusang susuriin ang input filtering o least privilege, dahil focus lang nito ang functional implementation. Sa kabuuan:

Injection Vulnerabilities: Default na gumamit ang AI ng string concatenation para sa SQL/command, dahil ito ang pinakakaraniwan sa mga simpleng tutorial.
Hardcoded Sensitive Information: Ang mga halimbawa sa training data ay madalas na may hardcoded na API Key, at gagayahin ng AI ang pattern na ito.
Labis na Pahintulot: Para sa kaginhawahan, madalas gumamit ang AI ng sudo o w+ mode sa pagbukas ng file, nang hindi isinasaalang-alang ang minimum na kinakailangang pahintulot.

Apat: Pitfalls sa Ebolusyon ng Pangangailangan

Ang Vibe Coding ay walang malinaw na hangganan. Kapag sinabi ng user na "magdagdag pa ng feature", susubukan ng AI na tuparin ito, ngunit hindi nito alam kung ano ang "labas sa saklaw". Wala ring konsepto ng prayoridad ang AI, at maaaring sabay-sabay na ipatupad ang tatlong karagdagang feature, na magdulot ng pagkalunod ng core functionality. Kasabay nito, sa bawat pag-aayos ng bagong bug, hindi babalikan ng AI ang lumang feature, na nagreresulta sa regression kung saan naayos ang A pero nasira ang B. Sa kabuuan:

Paglawak ng Saklaw: Para "mapaligaya ang user", kusang magdadagdag ang AI ng mga feature na tila nauugnay ngunit hindi kinakailangan (hal. calculator na may history).
Pagbaba ng Feature: Kapag nag-aayos ng bug, dahil hindi nito alam ang kabuuang lohika, binabago ng AI ang isang shared function, na nagdudulot ng error sa ibang feature na umaasa dito.

Lima: Pitfalls sa Pakikipagtulungan ng Koponan

Ang proseso ng diyalogo sa Vibe Coding ay pribadong interaksyon sa pagitan ng indibidwal at AI, na hindi nag-iiwan ng naililipat na dokumento ng specs o tala ng desisyon sa disenyo. Iba't ibang miyembro ng koponan ang nakikipag-usap sa AI, at nakakakuha ng kani-kaniyang istilo ng code, na nagdudulot ng maraming conflict kapag pinagsama. Bukod pa rito, hindi kusang bubuo ang AI ng commit message o changelog, kaya nawawala ang dahilan ng ebolusyon ng code, at ang susunod na maintenance ay hula na lang. Sa kabuuan:

Hindi Maaaring Kopyahin na Build: Iba't ibang tao, iba't ibang oras na gumagamit ng parehong prompt ay magbubunga ng iba't ibang implementasyon (dahil sa randomness ng sampling).
Kakulangan ng Pagsubaybay sa Pagbabago: Walang design document, walang commit message na nagpapaliwanag "bakit ito binago", kaya ang code ay nagiging itim na kahon.