Vibe coding: можливості та обмеження

Дайте людям змогу створювати

Технічний директор підприємства може допомогти більшій кількості людей перетворити свої знання на ідеї програмного забезпечення. Запросіть працівників фінансів, операційної діяльності, продажів і розробки. Надайте їм час, синтетичні дані, API пісочниці та підтримку.

Дозвольте людям досліджувати ідеї за допомогою різних інструментів у чітких межах щодо встановлення, облікових записів і дозволених вхідних даних. Конструктор у браузері, асистент програмування або локальний агент можуть допомогти перевірити ідею. Вибір інструмента не дає дозволу завантажувати інформацію компанії чи підключати реальну систему.

Опублікуйте простий порядок передавання корисного прототипу команді розробки або платформній команді. Автор надає опис проблеми, приклад робочого процесу та спостережувану цінність. Йому не потрібно ставати командою безпеки й експлуатації сервісу.

Визначте, що потрібно з’ясувати

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

Цей метод може допомогти отримати знання. Простий інтерфейс може показати, що процес погодження має забагато кроків. Тимчасовий скрипт може допомогти оцінити формат файлу. Прототип дає людям конкретний дизайн для обговорення. Ці знання можна зберегти, навіть якщо відмовитися від коду.

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

Банківський прототип, створений у вівторок

Розгляньмо вигаданий приклад. У вівторок колега з фінансового відділу використовує Lovable, щоб створити панель із вигаданими банківськими транзакціями. Вона групує витрати та показує неоплачені рахунки. Тепер команда може обговорити корисний робочий процес.

Хтось пропонує підключити банківський рахунок компанії. Це змінює можливі наслідки, навіть якщо застосунок досі називають «прототипом».

Доступ для читання може розкрити залишки на рахунках, історію транзакцій, імена або назви клієнтів чи призначення платежів залежно від API. Якщо підключення також дозволяє платежі, помилки можуть призвести до переказу реальних грошей. Підтвердьте фактичний обсяг прав: підключення до банку не завжди включає право здійснювати платежі.

Демонстрація не доводить, що користувач бачить лише ті рахунки, до яких має право доступу. Прихована кнопка не забезпечує дотримання прав. OWASP пояснює, як відсутність перевірок доступу до рахунків або записів може розкрити дані іншого користувача.

Для платіжних API ідемпотентність означає, що повторний запит не повторює запланованого ефекту. Stripe описує одну реалізацію. Перевірте фактичну поведінку провайдера, обмеження та правила повторних спроб. Відкат застосунку не скасовує платіж, який банк уже обробив.

Цей приклад не є доказом дефекту Lovable. Власні рекомендації Lovable щодо безпеки вимагають захищати секрети, виконувати серверні перевірки, тестувати політики доступу до даних і регулярно проводити перегляд. Застосовуйте однакові вимоги до доказів для будь-якого конструктора, агента або застосунку, написаного вручну.

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

Продовжуйте тестувати робочий процес із синтетичними даними та обліковими записами пісочниці. Перед наданням реального доступу відповідальні за сервіс, безпеку та платформу мають перевірити застосунок і його робоче середовище.

Використовуйте схвалений банком або провайдером процес підключення. Надавайте доступ лише до потрібних рахунків і лише потрібні права. Зберігайте секретні облікові дані в погодженому сховищі секретів, поза промптами та кодом браузера. Якщо потрібні платежі, визначте порядок їх погодження та ліміти. Перевірте, як відкликати доступ, розслідувати збої та реагувати на підозрілу активність.

Ці рішення потрібно прийняти до потрапляння конфіденційних даних або реальних облікових даних у систему. Очікування формального випуску в продуктивне середовище може бути запізнілим. Продовжте з уроків про межі даних та корпоративну інфраструктуру.

Визначте обов’язки перед розширенням використання

Експеримент із вигаданими даними може бути короткочасним і мати невелику аудиторію. Коли інші люди залежать від застосунку, визначте обов’язки щодо його використання.

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

Не кожному скрипту потрібна корпоративна платформа. Особистий інструмент форматування без чутливих даних потребує менше засобів контролю, ніж застосунок погодження платежів. Оцініть наслідки помилки. Перевірте, чи можете ви виявити помилку та скасувати її наслідки.

Перш ніж розширювати прототип, відокремте знання про проблему від доказів щодо реалізації. Можна зберегти інтерфейс і замінити внутрішній код. Можна обмежити заплановане використання. Також можна залишити прототип тимчасовим експериментом.

Плануйте роботу з вразливостями після демонстрації

Успішна демонстрація може приховати серйозну прогалину в обслуговуванні. Нове повідомлення про вразливість залежності може з’явитися без жодної зміни вашого коду. Сканування під час випуску описує стан лише в один момент часу.

Якщо застосунок залишається у використанні, хтось має постійно виявляти, оцінювати та виправляти вразливості. Виправлення повинне потрапити в продуктивне середовище та пройти перевірку. Сканер без такого процесу реагування залишає ризик невирішеним.

Перевірте, що забезпечують саме ваш інструмент і конфігурація. Далі урок про безперервне керування вразливостями пояснює весь процес, зокрема збої сканування та розгорнуті версії.

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

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

NIST Secure Software Development Framework описує ширші практики безпечної розробки. Використовуйте його як джерело під час оцінювання відсутніх засобів контролю. Не потрібно запам’ятовувати весь фреймворк. Потрібно визначити відсутні докази до того, як програмне забезпечення вплине на інших людей.