Vibe coding: примена и ограничења

Дајте људима простор да стварају

CTO у великој организацији може да помогне већем броју људи да своје знање претворе у идеје за софтвер. Позовите колеге из финансија, оперативних тимова, продаје и инжењерских тимова. Обезбедите им време, синтетичке податке, API интерфејсе у изолованом пробном окружењу и подршку.

Омогућите људима да истражују различитим алатима уз јасна правила за инсталацију, налоге и дозвољене улазне податке. Алат за израду апликација у прегледачу, асистент за програмирање или локални агент може да им помогне да испитају идеју. Избор алата не даје дозволу за отпремање података компаније или повезивање стварног система.

Објавите једноставан поступак за предају корисног прототипа инжењерском тиму или тиму за платформу. Аутор доноси опис проблема, пример тока рада и уочену вредност. Не мора да преузме улогу тима за безбедност и оперативни рад сервиса.

Одредите шта треба да научите

Vibe coding обично почиње описом жељеног софтвера. Прихватате генерисани код и на основу видљивог резултата усмеравате следећу промену. Израз има различита значења. У овом водичу особа која усмерава рад не мора да разуме сваку одлуку о имплементацији.

Овај метод може да вам помогне да учите. Једноставан интерфејс може да покаже да поступак одобравања има превише корака. Привремена скрипта може да вам помогне да процените формат датотеке. Прототип људима даје конкретан дизајн за разговор. Стечено знање можете да задржите и када одбаците код.

Прво поставите питање на које можете да добијете проверљив одговор. На пример: „Може ли руководилац тима да разуме овај поступак одобравања?” Ово питање има јасан опсег. Захтев за израду система за трошкове обухвата и заштиту података, контролу приступа, оперативни рад и одговорност за систем.

Банкарски прототип направљен у уторак

Размотримо измишљен пример. У уторак колега из финансија користи Lovable да од измишљених банковних трансакција направи контролну таблу. Она групише трошкове и приказује неплаћене фактуре. Тим сада може да разговара о корисном току рада.

Неко предлаже да се повеже банковни рачун компаније. То мења последице, чак и ако апликација и даље има ознаку „прототип”.

Приступ за читање може да открије стање рачуна, историју трансакција, имена или називе клијената или позиве на број, зависно од API интерфејса. Ако веза дозвољава и плаћања, грешке могу да пренесу стварни новац. Потврдите стварни опсег дозвола: веза са банком не обухвата увек право на плаћање.

Демонстрација не доказује да корисник може да види само рачуне за које има овлашћење. Скривено дугме не спроводи контролу дозвола. OWASP описује како недостатак провера рачуна или записа може да изложи податке другог корисника.

За API интерфејсе за плаћање, идемпотентност значи да поновљени захтев не понавља намеравани ефекат. Stripe документује једну имплементацију. Проверите стварно понашање добављача, ограничења и правила поновних покушаја. Враћање претходне верзије апликације не поништава плаћање које је банка обрадила.

Овај пример није доказ грешке у алату Lovable. Смернице за безбедност самог алата Lovable захтевају заштићене тајне, серверске провере, тестиране политике за податке и стални преглед. Примените исти критеријум доказа на сваки алат за израду апликација, сваког агента или сваку ручно написану апликацију.

Проверите приступ пре повезивања стварних система

Наставите да тестирате ток рада са синтетичким подацима и пробним налозима. Пре стварног приступа нека особе одговорне за сервис, безбедност и платформу провере апликацију и њено оперативно окружење.

Користите поступак повезивања који је одобрила банка или добављач. Одобрите само потребне рачуне и дозволе. Чувајте приватне акредитиве у одобреном складишту тајни, ван упита моделу и кода прегледача. Ако су плаћања потребна, одредите ко их одобрава и која ограничења важе. Проверите како се укида приступ, истражују откази и реагује на сумњиве активности.

Ове одлуке морате да донесете пре него што поверљиви улазни подаци или стварни акредитиви уђу у систем. Чекање формалног објављивања у продукцији може да буде прекасно. Наставите са лекцијама о границама поступања са подацима и инфраструктури великих организација.

Одредите одговорности пре шире употребе

Експеримент са измишљеним подацима може кратко да траје и има малу публику. Када други људи почну да зависе од апликације, одредите одговорности за њену употребу.

1. Именујте одговорну особу.
2. Одредите дозвољене кориснике и податке.
3. Дефинишите реаговање на отказ.
4. Чувајте изворни код и конфигурацију у репозиторијуму.
5. Проверите да ли друга особа може да испита и поново успостави систем.

Није свакој скрипти потребна платформа за велике организације. Личном алату за форматирање без осетљивих података треба мање контрола него апликацији за одобравање плаћања. Процените последице грешке. Проверите да ли можете да је откријете и поништите њене ефекте.

Пре него што проширите прототип, раздвојите оно што сте научили о проблему од доказа о имплементацији. Можете да задржите интерфејс и замените унутрашњи код. Можете да ограничите намеравану употребу. Можете и да задржите прототип као привремени експеримент.

Планирајте рад са рањивостима после демонстрације

Успешна демонстрација може да сакрије озбиљан недостатак у одржавању. За зависност може да се појави ново обавештење о рањивости без икакве промене вашег кода. Скенирање приликом објављивања описује само један тренутак.

Ако апликација остане у употреби, неко мора стално да проналази, процењује и отклања рањивости. Исправка мора да стигне до продукције и прође проверу. Скенер без овог поступка реаговања оставља изложеност нерешеном.

Проверите шта обезбеђују ваш конкретан алат и конфигурација. Каснија лекција о непрекидном управљању рањивостима објашњава цео поступак, укључујући неуспела скенирања и постављене верзије.

Олакшајте преглед следеће промене

Задајте агенту једну малу промену са изричитим критеријумима прихватања. Наведите које радње сме да изврши. Испитајте добијени diff. Спроведите провере које могу да одбаце погрешну имплементацију. Одлуку о постављању у окружење држите одвојено док одговорности за објављивање не буду јасне.

NIST Secure Software Development Framework описује ширу праксу безбедног развоја. Користите га као референцу када процењујете контроле које недостају. Не морате да научите цео оквир напамет. Морате да утврдите који докази недостају пре него што софтвер почне да утиче на друге људе.