72 часа — столько времени отделяло меня от статуса автора первого в моей жизни Chrome-расширения. Без единого собственноручно написанного цикла, без ночей и дебаг-сессий. Просто я, промпт и FutureX. К концу третьего дня расширение было готово: прошло ревью в Chrome Web Store и работало у нескольких бета-тестеров. Вот как это было.
Что такое виб-кодинг и почему о нём все говорят
Термин «vibe coding» предложил Андрей Карпати в 2025 году. Он описал подход, при котором разработчик не пишет код вручную, а формулирует естественным языком, что должна делать программа, и получает готовый результат от нейросети. Это не автодополнение и не генерация одного метода. Это целая фича, модуль или даже прототип продукта.
В 2026 году виб-кодинг перестал быть просто забавной демонстрацией. Многие студии и продуктовые команды используют его для быстрой проверки гипотез: собрать рабочий прототип за один спринт стало реальностью. Именно такой кейс я хочу разобрать на своём примере.
Мой кейс: расширение, которое красит ссылки
Я выбрал простую, но полезную задачу — создать расширение Color My Links, которое красит все ссылки на текущей вкладке в разные цвета. Это классический пример для туториалов, но при этом с достаточным количеством нюансов: нужно было разобраться с манифестом, разрешениями, content-скриптами и пользовательским интерфейсом.
Главным инструментом стала платформа FutureX. Моя роль сводилась к постановке задач и проверке результата. Ниже — как именно были устроены эти 72 часа.
День 1: от идеи до манифеста
Я сформулировал первый промпт: «Создай Chrome-расширение на Manifest V3, которое при нажатии на иконку красит все ссылки на текущей странице в случайный цвет». FutureX вернул структуру проекта: манифест, content-скрипт и popup-файл.
// manifest.json
{
"manifest_version": 3,
"name": "Color My Links",
"version": "1.0",
"permissions": ["activeTab"],
"action": {
"default_popup": "popup.html"
},
"content_scripts": [
{
"matches": ["<all_urls>"],
"js": ["content.js"]
}
]
}
// content.js
function colorMyLinks() {
const links = document.querySelectorAll('a');
const colors = ['#ff0000', '#00ff00', '#0000ff'];
links.forEach((link, i) => {
link.style.color = colors[i % colors.length];
});
}
chrome.runtime.onMessage.addListener((msg) => {
if (msg.action === 'colorLinks') colorMyLinks();
});
Код оказался рабочим с первого раза, но я не сразу понял его логику. FutureX добавил комментарии к каждому блоку, объяснив, почему используется activeTab и как работает прослушивание сообщений. Так я заодно подтянул знание Chrome Extension API.
День 2: дизайн и настройки
Базовый вариант работал, но выглядел не очень. Мне нужны были настройки: выбор палитры цветов, возможность исключить определённые сайты и кнопка сброса. Здесь я усвоил главное правило виб-кодинга: один промпт — одна маленькая фича. Если попросить ИИ сделать сразу всё, он выдаст кашу.
Я разбил задачу на шаги. Сначала попросил добавить настройку в popup.html, затем — расширить content.js, чтобы он учитывал выбранный режим. Для исключений пришлось добавить файл options.html и хранить настройки в chrome.storage. Каждая итерация занимала 5–10 минут.
Второй вечер я потратил на то, чтобы закоммитить все версии в GitHub — без этого разработка бы превратилась в хаос. Кстати, ASI Biont поддерживает подключение к GitHub через API — подробнее на asibiont.com/courses. Версионирование особенно важно в виб-кодинге: иногда следующий промпт ломает то, что работало, и нужно быстро откатиться.
День 3: отладка и публикация
Самое коварное началось на третий день. Расширение отлично работало на обычных сайтах, но отказывалось функционировать на некоторых страницах с жёсткой Content Security Policy (CSP). Это стандартная проблема: сайт запрещает инъекцию скриптов через content_scripts. Решение мне подсказал FutureX: вместо того чтобы заранее инжектить скрипт, нужно использовать разрешение activeTab и chrome.scripting.executeScript по действию пользователя.
Как указано в официальной документации Chrome, Manifest V3 требует явных разрешений и минимальных привилегий. Это важный принцип безопасности: расширение должно получать доступ к данным только по инициативе пользователя.
После фикса я пересобрал пакет, создал иконки и отправил расширение на публикацию в Chrome Web Store. Ревью заняло меньше суток — и вот, ровно через 72 часа после первого промпта, у расширения появилась своя страница в каталоге.
5 правил виб-кодинга, которые я вынес из этого опыта
-
Дробите задачу. Один промпт — одна фича. Так проще контролировать изменение кода и понимать, что именно сломалось.
-
Просите ИИ объяснять, а не только генерировать. Это превращает виб-кодинг в обучение, а не в копирование.
-
Держите всё под контролем версий. Git — ваш страховой полис. Любая неудачная генерация откатывается одной командой.
-
Используйте минимальные permissions. В Chrome-расширении это особенно важно: лишний доступ — лишняя дыра в безопасности.
-
Тестируйте вручную. Нейросеть не видит, как ваш интерфейс выглядит в реальном браузере. В моём случае именно ручная проверка на нестандартных сайтах спасла расширение от провала.
Подводные камни: когда виб-кодинг ломается
Виб-кодинг не отменяет инженерную ответственность. ИИ может сгенерировать код с уязвимостями: например, вы использовать innerHTML с непроверенными данными. Он также может опереться на устаревшую документацию или неподдерживаемую версию API.
Опасность ещё и в том, что разработчик перестаёт понимать код, который «пишет» для него нейросеть. Это создаёт иллюзию, что всё работает магически, пока не случается баг в проде. Поэтому я рекомендую комбинировать виб-кодинг с классическим ревью: дайте код на проверку другому человеку или хотя бы перечитайте его сами через неделю.
Почему виб-кодинг — это про скорость, а не про лень
Многие боятся, что виб-кодинг убьёт профессию разработчика. Реальность обратная. Он снимает рутину и позволяет сосредоточиться на архитектуре, пользовательском опыте и бизнес-логике. В моём случае FutureX Built My Chrome Extension in 72 Hours стало возможным именно потому, что я понимал, какие вопросы задавать, как разбивать функции на этапы и что тестировать.
В будущем виб-кодинг станет нормой не только для прототипов, но и для продакшн-кода. Однако роль человека никуда не исчезнет: кто-то должен отвечать за качество, безопасность и стратегию продукта. Скорее всего, через пару лет каждый разработчик будет иметь ИИ-ассистента в пайплайне, и разница между командами будет не в том, кто пишет код быстрее, а в том, кто точнее ставит задачи.
Вывод
За 72 часа с FutureX я получил не только работающее расширение, но и практический опыт взаимодействия с ИИ как с инженерным партнёром. Виб-кодинг сокращает время от идеи до результата с недель до дней, но требует дисциплины и понимания базовых принципов.
Хотите проверить, насколько быстро вы сможете превратить идею в продукт? Возьмите небольшую задачу, выберите инструмент и начните с простого промпта. Главное — не гнаться за количеством фич, а сосредоточиться на качестве одного, но полностью работающего сценария. У меня получилось — получится и у вас.
Комментарии