Когда нужен инструмент для тестирования VPN и прокси, я обычно пишу скрипт на Python за час. Но на этот раз решил проверить, может ли Claude Code с промптами создать React dashboard, который будет не только работать, но ещё и хорошо выглядеть.
Результат: проект proxy-analyzer с тёмной темой, 50+ прокси в параллельных тестах, три варианта дизайна и ровно 62 промпта от пустой папки до рабочего инструмента.
Что такое вайб-кодинг и почему я вообще это попробовал
Термин придумал Andrej Karpathy в начале 2025-го: “полностью отдаться вайбам, принять экспоненты и забыть, что код вообще существует”. Звучит как маркетинг, но за этим есть реальная идея - разрабатывать через описание намерения, а не через написание строк вручную.
Я относился к этому скептически. Сделать туториальный CRUD - это одно. Сделать что-то, где реально важна корректность - тестирование прокси, латенс, геолокация IP - совсем другое.
Скептицизм был до того, как я попробовал. Скрипт на Python занял бы день. Dashboard с UI, real-time обновлениями и нормальным дизайном - неделю минимум. Вайб-кодинг занял день и 62 промпта.
Задача: что именно нужно было сделать
Требования были конкретные. React приложение, которое принимает список прокси, тестирует их параллельно, показывает латенс, статус соединения, IP геолокацию. HTTP, HTTPS, SOCKS5. Real-time обновления, чтобы видеть прогресс по мере тестирования.
Обычно я решал это скриптом и смотрел в терминал. На этот раз захотелось веб-интерфейс - во-первых, удобнее делиться, во-вторых, интереснее визуализировать данные.
Один момент оказался неожиданным. У меня был скриншот чужого dashboard с похожим функционалом - хотел понять, какие метрики там отображаются. Claude Code вместе с exa.ai нашёл этот проект, его GitHub репозиторий и техническую документацию буквально по скриншоту. Быстрее, чем я бы погуглил сам. Я рассчитывал потратить на это исследование час - ушло минут десять.
Три варианта дизайна: glassmorphism, cyberpunk, минимализм
Первый крупный выбор был стилистический. Попросил Claude Code сгенерировать три разных варианта дизайна для одного и того же функционала.
Glassmorphism - frosted glass эффект, backdrop blur, полупрозрачные карточки. Выглядит как что-то между macOS и современным SaaS. Есть готовые библиотеки - shadcn-glass-ui с несколькими десятками компонентов, всё уже стилизовано. Красиво на скриншотах. Но когда начинаешь выводить большие таблицы с данными по сотням прокси - читаемость падает. Glassmorphism плохо работает с плотными данными: это уже не героическая картинка, а мешанина слоёв.
Cyberpunk - неоновые цвета, scanlines, glitch эффекты. CYBERCORE CSS framework, вдохновлённый Cyberpunk 2077 и Blade Runner. Выглядит агрессивно и неплохо, если ты делаешь security dashboard или что-то gaming. Для прокси-тестера немного избыточно эстетически, но работает.
Минимализм - shadcn/ui плюс Tailwind dark mode, ничего лишнего. Максимальная читаемость данных, никаких декоративных элементов. Выглядит как профессиональный инструмент, а не как демо.
В итоге выбрал glassmorphism - но с компромиссом. Карточки верхнего уровня получили стеклянный эффект, таблица с данными по прокси - плоский тёмный фон без размытия. Этот гибрид и выглядит, и читается нормально. Выбор был мой: AI предложил три варианта, я сравнил на реальных данных и решил.
62 промпта: как устроен процесс
Число выглядит большим, но это не 62 раза “напиши мне код”. Это 62 итерации диалога.
Начинал с RTCF структуры - Role, Task, Context, Format. Не потому что это какая-то магия, а потому что это помогает AI не угадывать. Конкретно для первого компонента это звучало примерно так: ты старший React-разработчик, специализируешься на data dashboard, нужен компонент для отображения статуса прокси, контекст - тестируем одновременно больше пятидесяти HTTP/HTTPS/SOCKS5 соединений, формат - TypeScript, Tailwind.
Первые пять-семь промптов дали скелет: компоненты, структуру данных, базовую логику. Следующие десять-пятнадцать - итерации по дизайну. Здесь работала конкретика: “убери drop shadows”, “карточки должны выглядеть как у Stripe”, “латенс показывай цветом - зелёный меньше двухсот, жёлтый до пятисот, красный выше”. Абстрактное “сделай красиво” не работает. Конкретная критика или референс - работает.
Потом пошла интеграция с реальными прокси. Параллельный fetch, обработка таймаутов, edge cases вроде “прокси отвечает, но возвращает не тот IP”. Это заняло большую часть промптов - примерно треть всего.
Два момента, где AI справился лучше, чем я ожидал: retry логика с axios и WebSocket для real-time обновлений. Я уже готовился руками писать - не пришлось. Один момент, где пришлось вмешаться вручную: специфическая обработка SOCKS5 аутентификации с нестандартным форматом. AI предложил три варианта, все три были неточными в одном месте. Поправил сам, занял от силы двадцать минут.
Что удалось и что нет
Удалось: рабочий dashboard с мониторингом, три дизайна за один день, real-time обновления без проблем, параллельное тестирование большого числа прокси.
Не всё было гладко. Glassmorphism с плотными таблицами - проблема, которую я увидел только на реальных данных, не на моках. Пришлось переделывать часть layout. Некоторые edge cases в обработке ошибок AI написал неаккуратно - нашёл при тестировании, исправил.
Важный урок про version control. На середине проекта сломал анимации, пытаясь добавить новый компонент. Откатился через git к предыдущему чекпоинту за две минуты. Без регулярных коммитов это был бы ручной разбор на сорок минут. Вайб-кодинг без дисциплинированного git превращается в хаос быстрее, чем кажется.
Вайб-кодинг как процесс, а не инструмент
Главное, что я понял: это не “дал промпт и получил код”. Это workflow с дисциплиной.
Быстрые итерации работают только если ты чётко видишь, что пошло не так. Нужно проверять каждый increment на реальных данных, а не на заглушках. Нужна структура промптов - не потому что AI тупой без неё, а потому что структура заставляет тебя самого думать о требованиях.
Среди профессиональных разработчиков уже значительная доля использует вайб-кодинг для части задач. Я был скептиком. Теперь нет. Не потому что AI написал идеальный код - он не написал. А потому что feedback loop реально быстрый, и это меняет то, какие проекты вообще имеет смысл начинать.
proxy-analyzer работает. Тестирует прокси. Выглядит нормально. 62 промпта - это не много и не мало, это просто количество шагов в диалоге от идеи до результата.
Если хочешь проверить, как это работает на реальном проекте - начни с RTCF, сделай три варианта дизайна, выбери один и итерируй. Не надо планировать идеально. Нужна дисциплина в feedback loop и регулярные коммиты.