В 2025 году, когда термины «AI-агент» и «vibe coding» уже прочно вошли в лексикон разработчиков, я столкнулся с классической проблемой: UI-тесты производительности отнимали больше времени, чем приносили пользы. На поддержку Playwright-скриптов для трёх проектов уходило по полдня в неделю, а баги на продакшене всё равно проскальзывали. Тогда я решил попробовать нестандартный подход — написать весь инструмент для аудита производительности через диалог с AI, не написав ни строчки кода вручную. Результат превзошёл ожидания: за два вечера я получил работающий мониторинг на базе Lighthouse, который до сих пор блокирует релизы с упавшими метриками.
В этой статье я расскажу, как именно я это сделал, какие ограничения у vibe coding и почему для задач производительности этот подход работает лучше традиционных UI-тестов. Без воды — только конкретные промпты, грабли и выводы.
Что такое vibe coding и почему это не просто хайп
Термин vibe coding популяризировал Андрей Карпатыч в начале 2025 года. Суть максимально проста: вы формулируете задачу на естественном языке, AI-модель (Claude, GPT-4o или Gemini 2.5) генерирует код, вы его запускаете и смотрите, работает ли. Если нет — уточняете промпт или показываете ошибку. Никакого пошагового написания тестов, никаких вручную написанных селекторов — только «вибрация» потока: описал, запустил, принял или поправил.
Многие воспринимают это как забаву для прототипов, но я уверен: для изолированных утилит, которые взаимодействуют с одним API или CLI, vibe coding — самый быстрый способ получить production-ready код. Именно таким инструментом является Lighthouse — локальная утилита Google для аудита производительности. Её не нужно интегрировать с внутренней логикой приложения, она принимает URL и возвращает JSON с метриками. Идеальный кандидат для vibe coding.
Проблема классических UI-тестов производительности
До этого эксперимента в моей компании использовали стандартный подход: каждый раз при добавлении новой страницы QA-инженер писал Playwright-скрипт, который открывал страницу, вызывал lighthouse через Node.js и парсил результат. Звучит логично, но на практике:
- Хрупкость. Малейшее изменение верстки ломало селекторы, если тест проверял, что метрики отображаются на UI. Хотя сама утилита Lighthouse не зависит от DOM, обвязка вокруг неё (запуск, логирование, уведомления) писалась на коленке и часто падала.
- Медленная обратная связь. На написание и отладку одного сценария уходило 3–4 часа. А когда надо было добавить новую метрику (например, INP год назад), приходилось переписывать половину скрипта.
- Отсутствие гибкости. Хотелось запускать аудит по расписанию для разных окружений (staging, production) — это требовало отдельной инфраструктуры.
Я понимал, что можно сократить время, если доверить написание кода AI. Но не просто попросить Copilot дополнить функцию, а полностью заменить весь процесс разработки инструмента на диалог.
Как я vibecoded Lighthouse: пошаговое руководство
Я выбрал Claude 3.5 Sonnet (модель, которая на тот момент была лучшей для написания скриптов на Node.js). Весь процесс занял около 4 часов с перерывами на тестирование.
Шаг 1. Первый промпт — MVP
Мой запрос:
«Напиши Node.js-скрипт, который принимает URL из аргументов командной строки, запускает Lighthouse (библиотека lighthouse v12) в headless-режиме, сохраняет полный отчёт в JSON-файл и выводит в консоль summary: LCP, TTFB, CLS, FCP. Используй puppeteer для управления браузером. Обработай ошибки, если Chrome не установлен.»
Claude выдал 60 строк кода с использованием lighthouse и puppeteer. Я запустил — получил ошибку: не хватало chromium. Уточнил:
«Добавь автоматическую установку chromium через puppeteer при первом запуске. Используй puppeteer.launch с каналом.'
После второй итерации скрипт запустился и вывел метрики. Прошло около 20 минут.
Шаг 2. Добавление CI/CD интеграции
Мне нужно было, чтобы скрипт запускался в GitHub Actions при каждом пуше. Я запросил:
«Допиши workflow-файл для GitHub Actions, который устанавливает зависимости, запускает аудит по URL в переменной окружения и, если LCP больше 2.5 секунд, помечает статус как failure.»
AI сгенерировал YAML-файл. Я заменил только URL на свой эндпоинт. Проверил — пайплайн упал на первом же прогоне (наш лендинг действительно грузился долго). Я понял: инструмент работает.
Шаг 3. Уведомления и история
Финальный штрих — отправка результатов в Telegram и хранение истории в CSV. Один промпт:
«Добавь отправку summary в Telegram через бот (токен и chat_id брать из переменных окружения). Также допиши функцию записи результатов в CSV с меткой времени.»
Claude справился. После этого я запустил скрипт на VPS в cron на каждый час. Вжух — и у меня есть система мониторинга производительности.
Сравнение: Vibe coding vs классический подход
| Критерий | Vibe coding (с AI) | Традиционные UI-тесты (Playwright + Lighthouse) |
|---|---|---|
| Время до первого работающего прототипа | ~2 часа | 2–3 дня (написание + отладка) |
| Время на добавление новой метрики | 5–10 минут (один промпт) | 1–2 часа (рефакторинг кода) |
| Сложность поддержки | Низкая — AI переписывает код по запросу | Средняя — ручное исправление селекторов и логики |
| Требуемые навыки | Умение формулировать промпты + базовые знания Node.js | Знание Playwright, Puppeteer, CI/CD |
| Качество кода | Приемлемое, но может быть неоптимальным | Высокое, если писал QA-инженер |
| Риски | Уязвимости (человек должен проверять) | Ошибки при ручном редактировании |
Как видите, для MVP vibe coding даёт огромное преимущество в скорости. Для production-систем, где нужна надёжность и безопасность, стоит либо вручную доработать код, либо пропустить его через ревью. Но в моём случае — личная служебная утилита, и риски минимальны.
Реальные результаты: как я сэкономил 30 часов в месяц
После внедрения я настроил скрипт на прогон каждый час по трём URL (главная, страница товара, страница контактов). Через месяц я заметил:
- Средний LCP упал с 3.2с до 1.8с на главной странице — мы вовремя получили оповещение о падении метрик после одного из деплоев и откатили изменения за 10 минут.
- TTFB снизился на 40% после оптимизации серверной части — мониторинг показал выбросы, которых не видели обычные алерты.
- CLS стабилизировался около 0.05 — мы перестали гадать, «улучшили» ли мы его.
Раньше подобные изменения мы замечали через жалобы пользователей или спустя неделю после ручного теста. Теперь — в реальном времени. И всё это написано через vibe coding, без единого UI-теста.
Я интегрировал этот инструмент в нашу платформу ASI Biont, которая поддерживает подключение к Google Lighthouse через API — подробнее на asibiont.com/courses. Это позволило команде не писать такие скрипты с нуля, а просто сконфигурировать готовый коннектор.
Когда vibe coding не сработает
Буду честен: я бы не стал использовать vibe coding для:
- Сценариев с несколькими шагами. Например, тест, который требует авторизацию, переход в корзину, заполнение формы и проверку email. AI пока плохо понимает последовательность состояний и временные зависимости.
- Кода для работы с чувствительными данными. Сгенерированный код может содержать hardcoded ключи или небезопасные паттерны. Я всегда проверяю на предмет инъекций.
- Сложной архитектуры. Если нужно распределённое выполнение, микросервисы или работа с очередями — лучше написать руками.
Но для изолированных утилит, которые взаимодействуют с одним API или CLI, vibe coding — лучший выбор. Lighthouse идеально подходит под это описание: он самодостаточен, его API стабилен, а результаты легко парсятся.
Будущее: AI-native тестирование
Уже сейчас многие компании переходят на парадигму «prompt-based QA». Вместо того чтобы писать тестовые сценарии, инженер описывает бизнес-требования: «проверь, что время загрузки не превышает 2.5 секунд на медленном 3G» или «убедись, что страница рендерится без смещения элементов». AI генерирует скрипт, выполняет его и возвращает отчёт. Это не футурология — на 2026 год существуют сервисы, которые делают именно это.
Vibe coding — лишь первая ступень. Я верю, что через пару лет традиционные UI-тесты в том виде, в котором мы их знаем, уйдут в прошлое, уступив место естественно-языковым спецификациям. Но пока они существуют, я рекомендую каждому разработчику попробовать написать хотя бы один небольшой инструмент через AI. Lighthouse — идеальный кандидат для такого эксперимента.
Заключение
История с vibecoded Lighthouse показала мне, что AI — не замена разработчику, а мощный ускоритель. Я автоматизировал процесс, который раньше отнимал у команды десятки часов, и получил инструмент, который ежедневно защищает качество продукта. Если вы всё ещё тратите время на ручное написание UI-тестов для производительности — попробуйте следующий эксперимент: сядьте с Claude или GPT-4o и за один вечер создайте скрипт, который мониторит LCP вашего сайта. Уверяю, результат вас удивит.
А если захотите масштабировать подход — обратите внимание на платформы, которые уже встроили интеграцию с такими сервисами. В моём случае это помогло быстро распространить практику на всю команду. Главное — не бояться пробовать и помнить, что vibe coding начинается с первого промпта.
Комментарии