Штучний інтелект змінив підхід розробників до написання коду. Інструменти на кшталт GitHub Copilot, ChatGPT і Claude здатні генерувати функціональний код із природномовних запитів, що призвело до появи нового стилю програмування — так званого vibe coding. Проте ця технологічна революція принесла з собою несподівану загрозу кібербезпеці, яку дослідники назвали слопсквоттингом.

Що таке слопсквоттинг

Слопсквоттинг (slopsquatting) — це новий тип атаки на ланцюг постачання програмного забезпечення, який використовує схильність великих мовних моделей до галюцинацій. Термін вперше запропонував Сет Ларсон, дослідник безпеки та резидент Python Software Foundation, у 2025 році. Назва походить від поєднання слів “slop” (низькоякісний вихід штучного інтелекту) та “squatting” (захоплення).

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

Масштаб проблеми: дані дослідження

Команда дослідників з Університету Техасу в Сан-Антоніо, Університету Оклахоми та Технологічного інституту Вірджинії провела найбільше на сьогодні дослідження галюцинацій пакетів у AI-генерованому коді. Результати виявилися тривожними.

Науковці протестували 16 провідних AI-моделей для генерації коду, включаючи комерційні рішення (GPT-4, GPT-3.5, Claude) та моделі з відкритим вихідним кодом (CodeLlama, DeepSeek, WizardCoder, Mistral). Використовуючи два набори промптів, вони згенерували 576 000 зразків коду мовами Python та JavaScript.

Результати дослідження показали, що близько 20% рекомендованих пакетів виявилися неіснуючими — загалом 205 000 унікальних вигаданих назв пакетів. Моделі з відкритим вихідним кодом демонстрували вищий рівень галюцинацій (21,7% у середньому) порівняно з комерційними інструментами (5,2%).

Особливо тривожним виявився факт, що ці галюцинації не є випадковими. При повторному виконанні того самого промпту 10 разів 43% вигаданих пакетів повторювалися кожного разу, а 58% з’являлися більше одного разу. Лише 39% галюцинацій ніколи не повторювалися. Як зазначають аналітики з Socket, ця послідовність робить слопсквоттинг життєздатною стратегією атаки — зловмисникам не потрібно аналізувати величезні обсяги логів або вгадувати можливі назви.

Анатомія галюцинованих назв пакетів

Дослідники виявили цікаві закономірності в назвах пакетів, які галюцинують AI-моделі. Аналіз показав, що 13% були простими помилками на один символ (типовими друкарськими помилками), 9% становили назви пакетів, запозичені з інших мов програмування (наприклад, пакети npm у коді Python), а 38% мали помірну схожість із реальними пакетами, що свідчить про схожу структуру найменування.

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

Як працює атака слопсквоттингу

Механізм атаки відносно простий, але потенційно дуже ефективний. Зловмисник запускає популярні AI-моделі для генерації коду, виявляє назви пакетів, які повторюються в згенерованому коді, а потім публікує реальні — але шкідливі — бібліотеки з цими самими назвами в публічних репозиторіях на кшталт PyPI чи npm.

Коли розробник, керований AI-асистентом, автоматично встановлює всі пакети, згадані в згенерованому коді, або коли AI-інструмент сам встановлює пакети без перевірки, шкідлива залежність потрапляє в кодову базу. Як пояснюють дослідники з FOSSA, ця компрометація може потім поширитися через весь код або ланцюг залежностей програмного забезпечення, заражаючи будь-який код, що покладається на шкідливий пакет.

Реальний експеримент з huggingface-cli

Дослідник безпеки Бар Ланядо продемонстрував уразливість цієї загрози у 2024 році практичним експериментом. Він завантажив порожній пакет під назвою huggingface-cli — назву, яку великі мовні моделі часто галюцинували, плутаючи команду, що використовується для CLI HuggingFace Hub, з реальною назвою пакета.

Результати виявилися приголомшливими. Лише за три місяці цей порожній пакет отримав понад 15 000 завантажень. Більше того, він навіть був згаданий у файлі README дослідницького репозиторію, створеного компанією Alibaba. Цей експеримент наочно продемонстрував, наскільки легко розробники, керовані рекомендаціями штучного інтелекту, можуть бути введені в оману і завантажити неіснуючі пакети.

Vibe coding — ідеальне середовище для слопсквоттингу

Термін vibe coding, запропонований дослідником AI Андрієм Карпати в лютому 2025 року, описує техніку програмування, де розробники значною мірою покладаються на штучний інтелект для генерації коду. Цей підхід передбачає, що програміст описує бажаний результат природною мовою, а AI обробляє деталі реалізації.

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

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

Чому слопсквоттинг особливо небезпечний

Експерти з кібербезпеки виділяють кілька факторів, які роблять слопсквоттинг особливо серйозною загрозою.

По-перше, ця атака експлуатує довірчі відносини між розробниками та AI-інструментами. Коли програміст використовує vibe coding, він фактично передає своє технічне судження AI-системам, які можуть галюцинувати з упевненістю.

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

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

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

Поточний стан загрози

Станом на грудень 2025 року дослідники не зафіксували широкомасштабних експлуатацій слопсквоттингу в реальних умовах. Проте це не означає, що загроза є чисто теоретичною. Як повідомляє Infosecurity Magazine, з огляду на те, що минулого року в репозиторіях з відкритим вихідним кодом було виявлено близько 20 000 шкідливих бібліотек, експерти впевнені, що хтось спробує конвеєризувати цей новий тип атаки.

Цей сценарій особливо небезпечний для програмістів-аматорів, а також для корпоративних IT-відділів, які вирішують деякі завдання автоматизації внутрішньо. Саме ці категорії користувачів найімовірніше покладатимуться на AI-рекомендації без належної перевірки.

Заходи захисту від слопсквоттингу

Експерти з кібербезпеки розробили комплекс рекомендацій для захисту від загрози слопсквоттингу. Ці заходи поєднують технічний контроль і культурні практики розробки.

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

Налаштування AI-моделей. Дослідження показали, що зниження налаштування temperature (рівня випадковості) у AI-моделях значно зменшує кількість галюцинованих пакетів. Деякі комерційні асистенти для написання коду також мають вбудовані захисні механізми — новіші LLM іноді можуть розпізнати власні галюціновані пропозиції пакетів і попередити про них.

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

Інтеграція безпеки в конвеєр розробки. Зробіть сканування вихідного коду та статичне тестування безпеки частиною конвеєра розробки. Весь код, включаючи згенерований AI, повинен відповідати чітким критеріям: відсутність вбудованих токенів чи інших секретів, використання правильних версій бібліотек та інших залежностей. Ці завдання добре інтегруються в цикл CI/CD.

Використання SBOM. Software Bill of Materials (SBOM) — це список усіх компонентів (бібліотек, модулів тощо) у вашому програмному забезпеченні разом з їхніми версіями та джерелами. Актуальні SBOM можуть стати важливими інструментами, які допомагають командам швидко виявляти несподівані або несанкціоновані залежності.

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

Використання попередньо створених баз даних та RAG. Використання попередньо створеної бази даних популярних бібліотек для точного налаштування моделі та забезпечення генерації з розширеним пошуком (Retrieval Augmented Generation, RAG) також зменшує кількість помилок.

Дослідники змогли скоротити кількість галюцинованих пакетів до 2,4% для DeepSeek і 9,3% для CodeLlama, поєднуючи всі ці методи. На жаль, обидва показники занадто далекі від нуля, щоб цих заходів було достатньо.

Роль платформ та індустрії

Компанії, що розробляють AI-інструменти для програмування, також працюють над вирішенням проблеми. Як зазначають аналітики Trend Micro, передові асистенти для написання коду, такі як Claude Code CLI, OpenAI Codex CLI та Cursor AI з валідацією на основі MCP, допомагають зменшити — але не повністю усунути — ризик фантомних залежностей, оскільки навіть валідація в реальному часі не може виявити кожен крайній випадок.

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

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

Висновки та перспективи

Слопсквоттинг ілюструє, що навіть наші AI-помічники можуть створювати нові вектори атак. Ланцюг постачання програмного забезпечення вже перебував під облогою з боку тих, хто намагається експлуатувати будь-яку слабкість — галюцинації штучного інтелекту представляють новий тип тріщини, яку потрібно усунути, перш ніж вона розшириться.

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

Зрештою, поєднання технології (як-от сканери вразливостей, SBOM та безпечні AI-інструменти) та культури (навчання, політики та пильні практики) може значно зменшити загрози на кшталт слопсквоттингу в майбутньому. Проте розробники повинні пам’ятати золоте правило: довіряй, але перевіряй — особливо коли довіра надається штучному інтелекту.

Ця стаття Слопсквоттинг: як помилки ШІ створюють нові можливості для кіберзлочинців раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Штучний інтелект змінив підхід до розробки програмного забезпечення. Інструменти на кшталт GitHub Copilot і ChatGPT дозволяють писати код простою англійською, без глибоких знань синтаксису. Це явище отримало назву vibe coding — програмування “на відчутті”, коли розробник формулює завдання природною мовою, а AI генерує код. Але те, що спочатку здається магією, може перетворитися на кошмар для бізнесу.

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

Що таке vibe coding і чому він такий популярний

Vibe coding — це підхід до розробки, коли програміст або навіть людина без технічної освіти описує бажаний результат природною мовою, а AI-асистент генерує відповідний код. Замість того, щоб вивчати документацію, розбиратися в нюансах фреймворків і дебажити помилки, розробник просто “спілкується” з ШІ.

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

Саме тому vibe coding стрімко набирає популярності серед менеджерів проєктів і керівників, які хочуть прискорити розробку та зменшити витрати на технічний персонал. Проте експерти попереджають: те, що починається як “рухайся швидко і ламай речі” (move fast and break things), занадто часто перетворюється на “рухайся швидко і зламай все, а потім витрачай статки на відбудову”.

Приховані ризики для бізнесу

Головна проблема vibe coding полягає не в самих AI-інструментах, а в тому, як їх використовують. Код, згенерований ШІ, може працювати “тут і зараз”, але часто не відповідає промисловим стандартам якості, безпеки та масштабованості.

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

Безпека опиняється під загрозою. AI-моделі навчалися на публічному коді, включно з небезпечними практиками. Згенерований код може містити вразливості: SQL-ін’єкції, небезпечну десеріалізацію, відсутність валідації вхідних даних. Без ретельного код-рев’ю ці проблеми потрапляють прямо в продакшн.

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

Коли магія закінчується: реальні наслідки

Компанії, які активно впроваджували vibe coding без належного контролю, стикаються з передбачуваними наслідками. Проєкти, що спочатку розроблялися за тижні, потребують місяців на рефакторинг. Системи, які “просто працювали”, раптово падають під навантаженням або стають об’єктами успішних кібератак.

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

Особливо небезпечний vibe coding у сферах, де на першому місці стоять безпека та надійність: фінтех, медичне ПЗ, інфраструктурні системи. Помилка, яку AI “не помітив”, може коштувати не лише грошей, а й репутації компанії.

Як використовувати AI в розробці без ризиків

Це не означає, що від AI-асистентів потрібно відмовитися. GitHub Copilot, ChatGPT та інші інструменти можуть значно підвищити продуктивність — але тільки за умови правильного використання.

• Код-рев’ю обов’язкове. Кожен фрагмент згенерованого коду має перевірятися досвідченим розробником, який розуміє архітектуру системи та потенційні ризики.
• AI як помічник, не замінник. Використовуйте ШІ для автодоповнення, генерації шаблонного коду, пошуку рішень — але не для прийняття архітектурних рішень.
• Тестування та безпека. Впроваджуйте автоматизоване тестування, статичний аналіз коду та інструменти пошуку вразливостей. AI-код потребує цього навіть більше, ніж традиційний.
• Документація. Якщо ви використовуєте згенерований код, документуйте логіку та рішення. Це врятує наступну команду від днів розбору незрозумілих конструкцій.
• Навчання команди. Розробники мають розуміти принципи роботи коду, навіть якщо його згенерував AI. Без базових знань неможливо оцінити якість результату.

Vibe coding — потужний інструмент, але він вимагає відповідального підходу. Магія швидкої розробки може обернутися катастрофою, якщо бізнес забуває про фундаментальні принципи якісного програмного забезпечення. Рухайтеся швидко — але не ламайте все на своєму шляху.

Ця стаття Чому vibe coding може зруйнувати ваш бізнес раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Швидкість vibe coding створює ризики вразливостей без людської відповідальності та ретельного аналізу. Спосіб написання програмного забезпечення змінюється набагато швидше, ніж розробники могли передбачити. У центрі цих змін знаходиться “vibe coding” – техніка, коли програмісти використовують генеративний ШІ для швидшого створення коду.

Що таке vibe coding і чому це важливо

Vibe coding представляє собою підхід до розробки, де розробники покладаються на інструменти штучного інтелекту для генерації коду на основі загальних описів або “відчуттів” того, що потрібно зробити. Замість детального планування та написання кожного рядка коду вручну, програмісти описують бажаний результат, а ШІ генерує відповідний код.

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

Від vibe coding до vibe hacking

Паралельно з розвитком vibe coding з’являється концепція “vibe hacking” – використання тих самих ШІ-інструментів зловмисниками для пошуку та експлуатації вразливостей у коді, створеному за допомогою штучного інтелекту.

Хакери можуть використовувати ШІ для аналізу патернів у коді, згенерованому популярними інструментами, та виявлення типових помилок або вразливостей, які часто з’являються в автоматично створеному коді. Це створює своєрідну “гонку озброєнь” між розробниками та кіберзлочинцями.

Основні ризики безпеки vibe coding

Експерти з кібербезпеки виділяють кілька ключових проблем, пов’язаних з vibe coding:

• Відсутність контексту безпеки: ШІ може генерувати функціональний код, але не завжди враховує аспекти безпеки
• Повторювані патерни вразливостей: Якщо ШІ навчався на коді з вразливостями, він може їх відтворювати
• Зменшення людського контролю: Розробники можуть не повністю розуміти згенерований код
• Швидкість над безпекою: Тиск на швидку розробку може призвести до пропуску перевірок безпеки

Стратегії захисту в епоху ШІ-розробки

Для забезпечення безпеки програмного забезпечення в умовах широкого використання vibe coding експерти рекомендують наступні підходи:

Гібридний підхід до розробки

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

Автоматизовані перевірки безпеки

Впровадження автоматизованих інструментів аналізу коду, які можуть виявляти типові вразливості в ШІ-згенерованому коді. Ці інструменти повинні бути інтегровані в процес розробки та запускатися автоматично при кожному коміті.

Навчання та підвищення кваліфікації

Розробники повинні розуміти не лише як використовувати ШІ-інструменти, але й як аналізувати згенерований код на предмет потенційних проблем безпеки. Це вимагає постійного навчання та оновлення знань.

Майбутнє безпечної розробки з ШІ

Індустрія програмного забезпечення знаходиться на перехресті, де необхідно знайти баланс між швидкістю розробки, яку забезпечує vibe coding, та безпекою кінцевого продукту. Компанії, які зможуть успішно інтегрувати ШІ-інструменти з надійними практиками безпеки, матимуть конкурентну перевагу.

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

Успішне впровадження vibe coding вимагає не лише технічних рішень, але й культурних змін в організаціях. Команди повинні розвивати нове розуміння відповідальності та підзвітності в умовах, коли частина коду створюється штучним інтелектом.

Ця стаття Vibe coding та vibe hacking: як захистити програмне забезпечення в епоху ШІ раніше була опублікована на сайті CyberCalm, її автор — Олена Кожухар

Оскільки штучний інтелект робить розробку програмного забезпечення доступною для всіх, команди безпеки стикаються з новим викликом: захистом додатків, створених не-розробниками з безпрецедентною швидкістю та масштабом.

Що таке Vibe Coding?

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

Андрей Карпати, співзасновник OpenAI та колишній керівник напрямку ШІ в Tesla, запровадив термін “vibe coding” у твіті від 3 лютого 2025 року. “Існує новий вид програмування, який я називаю ‘vibe coding’, де ти повністю віддаєшся відчуттям, приймаєш експоненціальність і забуваєш, що код взагалі існує.” Він переважно висловлював емоційну реакцію на використання ШІ для автоматизації певного процесу, але термін прижився і тепер універсально використовується як загальна назва для програмування, створеного або підтримуваного штучним інтелектом.

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

Vibe coding є підмножиною контекстної інженерії. Якщо ви зробите контекст повним і точним, має бути можливо прокласти шлях через контекст для забезпечення точного програмування. Контекст складається з деталей, необхідних для готового коду. Це надається програмістом. Інтерфейс між програмістом і ШІ – природна мова (зазвичай англійська, але не обов’язково).

ШІ використовує можливості великих мовних моделей (LLM) у цьому інтерфейсі, тому vibe coding зазвичай використовує існуючі базові моделі, такі як новіші моделі GPT, Claude або Gemini Pro. Іноді LLM можуть бути інтегровані зі спеціалізованими IDE, такими як VS Code, Cursor та Windsurf. Проте, зрештою, всі проблеми, які досі впливають на LLM (такі як галюцинації та упередженість), також можуть впливати на точність vibe coding.

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

“Vibe coding – це коли ви говорите ШІ, як чат-бот, що ви хочете, щоб ваше програмне забезпечення робило, використовуючи звичайні слова, і він пише код за вас”, – каже Дж. Стівен Ковскі, польовий технічний директор SlashNext. “Це означає, що вам не потрібно знати, як програмувати; ви просто описуєте свою ідею, і ШІ перетворює її на робоче програмне забезпечення.”

Але якщо ви хочете складні або унікальні функції, або якщо ви не перевіряєте роботу ШІ двічі, ви можете зіткнутися з проблемами.

Сильні та слабкі сторони

Найбільша очевидна сила – швидкість. “Vibe coding дає вам масове прискорення при прототипуванні веб-додатків, особливо з простими відомими додатками з низькою до помірної складністю”, – пояснює Джонатан Райн, співзасновник і генеральний директор Nutrient.

Це демократизує процес створення програмного забезпечення. Будь-хто з ідеєю та розумінням того, як ця ідея повинна працювати, може створити робочу програму. Вам більше не потрібно знати мову програмування, вам лише потрібно знати, як використовувати ШІ – що само по собі є непростим завданням.

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

Проблема в тому, що ці сильні сторони несуть власні слабкості. “Демократизація” є потенційною слабкістю. “Існують спільноти та проекти з відкритим кодом, присвячені наданню vibe-кодерам файлів конфігурації, які можуть покращити ефективність їхніх інструментів ШІ”, – пояснює Каушик Девіредді, старший менеджер продукту в Deepwatch.

“Vibe-кодери, які можуть бути з нетехнічних ролей, постійно шукають нові файли конфігурації. Результатом є можливість для зловмисників публікувати та сприяти прийняттю шкідливих конфігураційних файлів. Це створює абсолютно новий вектор атак, що проявляється на рівні логіки додатків – що є особливо складною областю для захисту.”

Швидкість також може бути слабкістю. “З негативного боку”, – каже Елліс, – “ШІ досить добре справляється з отриманням ‘90% нормального’ рішення – але погані речі, як правило, трапляються в 10%. Уразливості існують як імовірнісна функція від кількості рядків коду. Ми виробляємо все більш високу швидкість рядків коду – і більше коду означає більше уразливостей. На додаток до цього, швидкість є природним ворогом якості, а безпека є дитиною якості.”

Ніколь Каріньян, віце-президент стратегії безпеки та ШІ та польовий CISO в Darktrace, також стурбована тим, що швидкість і легкість можуть коштувати безпеки. “Vibe coding дозволяє неекспертним професіоналам розробляти та створювати прототипи, але код, який він виробляє, не буде за своєю суттю безпечним і може внести уразливості в системи.”

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

Інті Де Сьокелер, головний хакер-офіцер краудсорсингової фірми Intigriti, підтверджує цю комбінацію сильних і слабких сторін у поточному vibe coding. “Vibe coding корисний, але це не магічне рішення”, – каже він. “Я використовував його для створення невеликого хакерського інструменту всього за один день, на що у мене пішли б тижні самостійно. Це також було чудово для виправлення простих помилок або створення швидких прототипів. Але коли проект стає більшим і складнішим, ШІ починає робити більше помилок. У цьому моменті може знадобитися стільки ж часу, щоб направляти та виправляти ШІ, скільки потрібно було б для програмування з нуля.”

Робота з vibe coding

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

Є ті, хто визнає і приймає цю реальність. “Ви можете робити речі швидше. Ви можете бути більш амбітними щодо речей, які можете створити, і можете створити їх самостійно та отримувати більше задоволення від цього. Ви можете робити речі, які потребували б команди або команди команд розробників”, – коментує Джин Кім, автор і колишній незалежний директор Energy Sector Security Consortium. “Є щось настільки магічне в цьому, і для мене це дивовижний час, щоб бути живим. Я безумовно, і я не думаю, що це повністю наївно, оптимістичний щодо того, що це робить з нашою професією.”

Це не означає, що будь-хто може негайно отримати хороші результати коду через vibe coding. Якість вихідних даних прямо пропорційна якості вхідних підказок, пояснює Пукар Хамал, засновник і генеральний директор SecurityPal.AI.

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

Якщо ви не розумієте, як програмне забезпечення принципово працює, продовжує він, “є ймовірність, що коли ви попросите LLM написати додаток для генерації номерів лотереї, він, швидше за все, буде дуже багатослівним і потенційно матиме 150 рядків коду або більше. У нас є термін, який описує цю переважну кількість низькоякісного згенерованого виводу, який зазвичай походить від відсутності суворості введення: ‘AI slop’.”

Але ви можете бути досвідченим у програмуванні і все одно не впоратися з vibe coding. Джонатан Ренде, директор з продукту в Checkmarx, описує внутрішній експеримент, проведений одним із його керівників інженерії. “Він обійшов усіх різних керівників в організації і поставив їм завдання, виконання якого передбачало vibe coding. Через 45 хвилин він повернувся. Ті, хто розумів загальну картину того, як певні речі в vibe coding повинні поєднуватися, зробили величезну роботу. Ті, хто просто намагався застосувати свої старі методи програмування, не дуже.”

Це були всі інженери та розробники. Деякі прийняли майбутнє, інші просто намагалися повторити минуле, але швидше. “Ті, хто використовував vibe coding як новий інструмент для використання новим способом, будуть добре справлятися, але інші стануть менш релевантними.” Це виклик для всіх програмістів сьогодні – навчитися використовувати vibe coding як новий інструмент зі своїми правилами взаємодії, або залишитися осторонь, оскільки буде менший попит на програмістів просто через чисту швидкість vibe coding, використовуваного ефективно.

Ми перебуваємо в цій перехідній фазі. Vibe coding все ще потребує багато ручного втручання для мінімізації властивих проблем з LLM, таких як галюцинації та упередженість. “Є властиві проблеми”, – каже Кім. “Це робота розробника – переконатися, що ШІ не викликає функції, які не існують – що може статися. Ті ж інженерні навички, які ми завжди використовували, тепер ще більш важливі, тому що ШІ посилює сильні та слабкі сторони, які ми вже маємо.”

Ренде погоджується. “LLM стануть кращими з часом, і буде менше галюцинацій і більше автоматизованої валідації.” Але зараз найкращий спосіб запобігти або обмежити галюцинації – через більш точні підказки. “Чим краще питання, тим краща відповідь; а потім можливість перевіряти та валідувати якнайкраще. Це ключі прямо зараз: як ви запитуєте і як ви валідуєте.”

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

Кібербезпека додатків, створених через Vibe coding

Основні загрози безпеки

Швидке поширення vibe coding створює унікальні виклики для кібербезпеки. Коли створення коду стає доступним для широкого кола користувачів без глибоких технічних знань, ризики безпеки зростають експоненціально.

Найпоширеніші уразливості:

• Небезпечні практики аутентифікації та авторизації. ШІ може генерувати код з жорстко закодованими паролями, слабкими алгоритмами хешування або неправильною реалізацією сесій. Наприклад, LLM може запропонувати простий MD5 для хешування паролів замість сучасних bcrypt або Argon2.
• SQL-ін’єкції та NoSQL-ін’єкції. Vibe coding часто генерує динамічні запити до баз даних без належної валідації вхідних даних. ШІ може створити код, який безпосередньо вставляє користувацький ввід у SQL-запити, відкриваючи шлях для атак ін’єкцій.
• Небезпечне управління залежностями. ШІ може рекомендувати застарілі або скомпрометовані бібліотеки, особливо коли треба швидко вирішити конкретну задачу. Користувачі без досвіду можуть не перевіряти безпеку підключених компонентів.
• Недостатня валідація даних. Код, згенерований ШІ, часто не включає належну перевірку вхідних даних, що може призвести до XSS-атак, переповнення буферів або інших атак через маніпулювання даними.
• Проблеми з конфігурацією безпеки. ШІ може генерувати код з небезпечними налаштуваннями за замовчуванням – відкритими портами, надмірними дозволами або неправильно налаштованими заголовками безпеки.

Читайте також: ТОП-10 найбільш небезпечних помилок програмування

Специфічні ризики vibe coding

• “Копіпаст-культура” стає ще небезпечнішою, коли ШІ генерує код на основі непевних джерел або застарілих патернів безпеки. Користувачі можуть не розуміти, що саме робить згенерований код.
• Відсутність контексту безпеки – ШІ може не враховувати специфічні вимоги безпеки конкретної організації або галузі, створюючи код, який не відповідає корпоративним стандартам або регуляторним вимогам.
• Хибне відчуття безпеки виникає, коли команди покладаються на ШІ як на експерта з безпеки, не розуміючи обмежень моделей і необхідності додаткової перевірки.

Стратегії захисту

• Автоматизоване сканування безпеки має стати обов’язковим для всього коду, згенерованого через vibe coding. Інструменти статичного аналізу коду (SAST) та динамічного тестування безпеки (DAST) повинні інтегруватися в процес розробки з самого початку.
• Шаблони безпечного коду. Організації повинні створити внутрішні шаблони та конфігурації для ШІ, які включають кращі практики безпеки за замовчуванням. Це може включати предналаштовані промпти з вимогами безпеки.
• Освіта користувачів стає критично важливою. Навіть якщо співробітники не є професійними розробниками, вони повинні розуміти базові принципи безпеки та розпізнавати потенційно небезпечний код.
• Багаторівневий огляд коду. Кожен додаток, створений через vibe coding, повинен проходити обов’язковий огляд від експертів з безпеки перед розгортанням у продакшні.
• Принцип мінімальних привілеїв має застосовуватися до всіх додатків, незалежно від способу їх створення. Код, згенерований ШІ, не повинен автоматично отримувати широкі дозволи.

Рекомендації для організацій

• Створіть політики безпеки для vibe coding, які включають обов’язкові перевірки безпеки, затверджені конфігурації ШІ та процедури для огляду згенерованого коду.
• Інвестуйте в інструменти автоматизації безпеки, які можуть інтегруватися з популярними платформами vibe coding та надавати миттєвий зворотний зв’язок про потенційні проблеми безпеки.
• Розробіть внутрішні “безпечні промпти” – набори інструкцій для ШІ, які автоматично включають вимоги безпеки в процес генерації коду.
• Створіть команди гібридної безпеки, які поєднують експертів з кібербезпеки та фахівців з ШІ для кращого розуміння ризиків та можливостей vibe coding.

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

Підсумок

Чи буде менше програмістів у майбутньому vibe coding? Так і ні. В одному сенсі, кожен стане розробником, тому їх буде більше. Співробітники більше не будуть залежати від подачі невеликого запиту до інженерії з подальшим невизначеним очікуванням відповіді – вони створюватимуть власний код за хвилини, а не чекатимуть тижнями. Це справді захоплюючий елемент vibe coding.

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

Бізнес існує для створення прибутку, а не для працевлаштування людей. Творчість буде зведена до визначення результатів, тоді як ШІ виконуватиме створення.

Сьогоднішні творці повинні будуть зробити цей перехід або залишитися осторонь. Це застосується в відносно короткостроковій перспективі до всіх поточних “творців” (включаючи програмістів через vibe coding, журналістів через створення контенту та графічних художників через генерацію зображень), і навіть бариста через поєднання робототехніки та ШІ в довгостроковій перспективі. Це станеться через чисту рушійну силу бізнес-економіки. Любіть це чи ненавидьте, але переборіть це. Або бігти з вітром, або боротися з ним і зазнати невдачі.

Ця стаття Vibe Coding: коли кожен стає розробником, хто захищає код? раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня