Vibe coding: магчымасці і абмежаванні

Дайце людзям магчымасць ствараць

CTO прадпрыемства можа дапамагчы большай колькасці людзей ператварыць свае веды ў ідэі для праграм. Запрашайце супрацоўнікаў фінансавага аддзела, аперацыйных падраздзяленняў, продажаў і распрацоўкі. Дайце ім час, сінтэтычныя даныя, API пясочніцы і падтрымку.

Дазвольце людзям даследаваць ідэі з рознымі інструментамі. Вызначце выразныя межы для ўсталявання, уліковых запісаў і дазволеных уваходных даных. Браўзерны канструктар, памочнік для напісання кода або лакальны агент могуць дапамагчы праверыць ідэю. Выбар інструмента не дае дазволу загружаць інфармацыю кампаніі або падключаць рэальную сістэму.

Апублікуйце просты парадак перадачы карыснага прататыпа камандзе распрацоўкі або платформы. Аўтар перадае апісанне праблемы, прыклад працоўнага працэсу і назіраную карысць. Яму не трэба станавіцца камандай бяспекі і эксплуатацыі гэтага сэрвісу.

Вызначце, што трэба высветліць

Vibe coding звычайна пачынаецца з апісання патрэбнай праграмы. Вы прымаеце згенераваны код і па бачным выніку вызначаеце наступную змену. Тэрмін мае розныя значэнні. У гэтым дапаможніку чалавек, які кіруе працай, не абавязкова разумее кожнае рашэнне аб рэалізацыі.

Гэты метад можа дапамагчы вам атрымаць новыя веды. Просты інтэрфейс можа паказаць, што працэс узгаднення мае занадта шмат крокаў. Часовы скрыпт можа дапамагчы ацаніць фармат файла. Прататып дае людзям канкрэтны варыянт для абмеркавання. Атрыманыя веды можна захаваць, нават калі вы адмовіцеся ад кода.

Спачатку сфармулюйце пытанне, адказ на якое можна назіраць. Напрыклад: «Ці можа кіраўнік каманды зразумець гэты працэс узгаднення?» Гэтае пытанне мае выразныя межы. Запыт на стварэнне сістэмы ўліку выдаткаў таксама ахоплівае абарону даных, кантроль доступу, эксплуатацыю і адказнасць.

Банкаўскі прататып, створаны ў аўторак

Разгледзім выдуманы прыклад. У аўторак калега з фінансавага аддзела выкарыстоўвае Lovable, каб стварыць панэль на аснове выдуманых банкаўскіх транзакцый. Яна групуе выдаткі і паказвае неаплачаныя рахункі-фактуры. Цяпер каманда можа абмеркаваць карысны працоўны працэс.

Хтосьці прапануе падключыць банкаўскі рахунак кампаніі. Гэта змяняе наступствы, нават калі праграма па-ранейшаму мае пазнаку «прататып».

У залежнасці ад API, доступ для чытання можа раскрыць рэшткі на рахунках, гісторыю транзакцый, імёны ці назвы кліентаў або прызначэнне плацяжоў. Калі падключэнне таксама дазваляе плацяжы, памылкі могуць перамясціць рэальныя грошы. Пацвердзіце фактычны абсяг дазволаў: падключэнне да банка не заўсёды ўключае права рабіць плацяжы.

Дэманстрацыя не пацвярджае, што карыстальнік бачыць толькі дазволеныя яму рахункі. Схаваная кнопка не забяспечвае выкананне правіл доступу. OWASP апісвае, як адсутнасць праверак рахунку або запісу можа раскрыць даныя іншага карыстальніка.

Для плацежных API ідэмпатэнтнасць азначае, што паўторны запыт не паўтарае задуманы эфект. Stripe дакументуе адну рэалізацыю. Праверце паводзіны канкрэтнага пастаўшчыка, абмежаванні і правілы паўторных спроб. Адкат праграмы не адмяняе плацёж, які банк ужо апрацаваў.

Гэты прыклад не сведчыць пра дэфект Lovable. Уласныя рэкамендацыі Lovable па бяспецы патрабуюць абароны сакрэтаў, серверных праверак, пратэставаных палітык даных і пастаяннага перагляду. Ужывайце аднолькавыя патрабаванні да доказаў для любога канструктара, агента або праграмы, напісанай уручную.

Праверце доступ перад падключэннем рэальных сістэм

Працягвайце тэставаць працоўны працэс з сінтэтычнымі данымі і ўліковымі запісамі пясочніцы. Перад доступам да рэальнай сістэмы адказныя за сэрвіс, бяспеку і платформу павінны праверыць праграму і яе асяроддзе працы.

Выкарыстоўвайце парадак падключэння, ухвалены банкам або пастаўшчыком. Давайце доступ толькі да патрэбных рахункаў і толькі неабходныя дазволы. Захоўвайце сакрэтныя ўліковыя даныя ва ўхваленым сховішчы сакрэтаў, па-за запытамі да мадэлі і браўзерным кодам. Калі патрэбныя плацяжы, вызначце іх узгадненне і ліміты. Праверце, як адклікаць доступ, расследаваць збоі і рэагаваць на падазроную дзейнасць.

Гэтыя рашэнні трэба прыняць да таго, як у сістэму трапяць канфідэнцыяльныя ўваходныя даныя або ўліковыя даныя рэальных сістэм. Чакаць фармальнага выпуску ў production можа быць позна. Працягвайце з урокамі пра межы даных і карпаратыўную інфраструктуру.

Вызначце абавязкі перад пашырэннем выкарыстання

Эксперымент з выдуманымі данымі можа быць кароткачасовым і мець невялікую аўдыторыю. Калі іншыя людзі пачынаюць залежаць ад праграмы, вызначце абавязкі, звязаныя з яе выкарыстаннем.

1. Назавіце адказнага.
2. Вызначце дазволеных карыстальнікаў і даныя.
3. Вызначце парадак рэагавання на збой.
4. Захоўвайце зыходны код і канфігурацыю ў рэпазіторыі.
5. Праверце, што іншы чалавек можа вывучыць і ўзнавіць сістэму.

Не кожнаму скрыпту патрэбная карпаратыўная платформа. Асабісты сродак фарматавання без канфідэнцыяльных даных патрабуе менш мер кантролю, чым праграма ўзгаднення плацяжоў. Ацаніце наступствы памылкі. Праверце, ці можна выявіць памылку і адмяніць яе наступствы.

Перад пашырэннем прататыпа аддзяліце веды пра праблему ад доказаў, якія датычацца рэалізацыі. Можна захаваць інтэрфейс і замяніць унутраны код. Можна абмежаваць прадугледжанае выкарыстанне. Таксама можна пакінуць прататып часовым эксперыментам.

Плануйце працу з уразлівасцямі пасля дэманстрацыі

Паспяховая дэманстрацыя можа хаваць сур’ёзны прабел у суправаджэнні. Новае паведамленне пра ўразлівасць залежнасці можа з’явіцца без якіх-небудзь змен у вашым кодзе. Сканаванне падчас выпуску апісвае толькі адзін момант часу.

Калі праграма застаецца ў выкарыстанні, хтосьці павінен пастаянна знаходзіць, ацэньваць і выпраўляць уразлівасці. Выпраўленне павінна трапіць у production і прайсці праверку. Сканер без такога працэсу рэагавання пакідае рызыку нявырашанай.

Праверце, што забяспечваюць ваш канкрэтны інструмент і канфігурацыя. Пазней урок пра пастаяннае кіраванне ўразлівасцямі тлумачыць увесь працэс, у тым ліку збоі сканавання і разгорнутыя версіі.

Зрабіце наступную змену зручнай для праверкі

Даручыце агенту адну невялікую змену з выразнымі крытэрыямі прыёмкі. Пакажыце, якія дзеянні яму дазволены. Праверце атрыманы diff. Выканайце праверкі, якія могуць адхіліць няправільную рэалізацыю. Пакіньце разгортванне асобным рашэннем, пакуль абавязкі пры выпуску не стануць зразумелымі.

NIST Secure Software Development Framework апісвае больш шырокія практыкі бяспечнай распрацоўкі. Карыстайцеся ім як даведнікам пры ацэнцы адсутных мер кантролю. Не трэба завучваць увесь framework. Трэба вызначыць, якіх доказаў не хапае, да таго, як праграма паўплывае на іншых людзей.