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

Дајте им простор на луѓето да создаваат

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

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

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

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

Vibe coding обично почнува со опис на софтверот што го сакате. Го прифаќате генерираниот код и го користите видливиот резултат за да ја насочите следната промена. Терминот има различни значења. Во овој водич, лицето што ја насочува работата не мора да ја разбира секоја одлука за имплементацијата.

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

Прво, поставете прашање со одговор што може да се набљудува. На пример: „Дали раководител на тим може да го разбере овој процес на одобрување?“ Ова прашање има јасен опфат. Барањето да се создаде систем за трошоци вклучува и заштита на податоци, контрола на пристап, работење и одговорност.

Банкарскиот прототип од вторник

Разгледајте измислен пример. Во вторник, колега од финансии користи Lovable за да направи контролна табла со измислени банкарски трансакции. Таа ги групира трошоците и ги прикажува неплатените фактури. Тимот сега може да разговара за корисен работен тек.

Некој предлага да се поврзе банкарската сметка на компанијата. Тоа ги менува последиците, дури и ако апликацијата сè уште ја носи ознаката „прототип“.

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

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

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

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

Проверете го пристапот пред да поврзете вистински системи

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

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

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

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

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

1. Назначете одговорно лице.
2. Одредете кои корисници и податоци се дозволени.
3. Одредете како ќе се одговори при проблем.
4. Чувајте ги изворниот код и конфигурацијата во репозиториум.
5. Проверете дали друго лице може да го испита и повторно да го создаде системот.

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

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

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

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

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

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

Направете ја следната промена лесна за преглед

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

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