Код на вайбах

Ты каждый раз объясняешь ИИ, как должна выглядеть кнопка. А можно один раз - и забыть Знакомая история. Просишь ИИ сделать экран - он рисует кнопку. Просишь следующий экран - рисует похожую, но другую. Цвета чуть-чуть отличаются. Отступы гуляют. Шрифт вроде тот же, а вроде и нет. Ты ничего не менял. Но приложение выглядит так, будто его три разных человека делали в разные дни недели. И ты сидишь, поправляешь руками. «Вайбкодинг» - говорили они. «Быстро» - твердили они. Проблема не в ИИ. У него просто нет шпаргалки. Представь, что ты каждый раз заказываешь ремонт в квартире, но не показываешь мастеру образец. «Ну, покрась стену... красиво». Результат будет каждый раз разный. А теперь представь, что ты один раз собрал альбом: вот эти цвета, вот такие кнопки, вот так выглядит текст, вот такие отступы. И каждый раз просто открываешь альбом и говоришь - делай как тут.

Это и есть дизайн система. Набор готовых «кубиков Лего» для интерфейса твоего приложения.

Что конкретно меняется, когда она есть? Хочешь тёмную тему? Не проходишься по каждому экрану. Добавил новые цвета в систему - всё приложение подхватило само. Надо поменять стиль кнопок? Меняешь в одном месте - обновляется везде. Новый экран? Не объясняешь ИИ с нуля, как всё должно выглядеть. Говоришь «возьми мои готовые элементы» - и он берёт.

Разница - как диктовать адрес голосом каждый раз против просто скинуть геолокацию.

Как собрать дизайн систему? Рассказываю: Шаг 1. Даёшь ИИ задачу: «Изучи лучшие практики дизайн систем, вдохновись 3-5 примерами и предложи мне стиль». Можешь уточнить, что нравится. Мне, например, зашёл стиль Apple - минимализм, чистота, ничего лишнего. Шаг 2. Описываешь, что хочешь. Не «сделай красиво» - это ни о чём. А конкретнее: «светлый, минималистичный, скруглённые углы, спокойные цвета». Чем точнее скажешь - тем меньше переделок. Шаг 3. Смотришь результат, корректируешь. «Кнопку сделай поярче», «текст помельче», «отступы побольше». Это нормально, за 3-5 попыток дойдёшь до того, что тебе нравится. Шаг 4. Просишь разложить всё по полочкам: цвета - отдельно, шрифты - отдельно, кнопки и остальные элементы - отдельно. Шаг 5. Просишь сделать «витрину» - один экран, где видно все элементы рядом. Открыл - и сразу понятно, как выглядит вся система.

Всё. Дизайн система готова.

«У меня простое приложение, мне это зачем?» Как раз для простых - профит ощутимый. Вместо того чтобы каждый раз тратить запросы к ИИ на одни и те же кнопки-поля-карточки - берёшь готовое и вставляешь. Экономишь время, запросы и нервы. А если проект вырастет - добавить новый блок, акцию, баннер - не придётся изобретать визуал с нуля. Расширяешь то, что уже работает. Пока кто-то объясняет ИИ цвет кнопки в сотый раз — ты собираешь готовый интерфейс и отправляешь в стор. Во продолжении ниже - как всё это перенести в Figma, чтобы твоя система всегда была перед глазами. Там пара граблей, на которые я уже наступил за тебя.

Обновил code-review агента Опубликовал агента в виде репозитория, теперь можно будет ещё легче обновляться и еще лучше изучить. Для установки / обновления, просто скорми ссылку для своего ИИ и он сам всё скачает и установит. Буду рад каждому, кто поставит звезду, спасибо большое! Раньше наш агент работал по трёхбалльной шкале: 1. Критическая ошибка 2. Стоит исправить 3. Мелочь. Проблема в том, что «стоит исправить» - это огромная серая зона. Туда попадало всё: и баг, который может сломаться у каждого десятого пользователя, и просто неаккуратный код, который никому не навредит. Теперь шкала четырёхбалльная: 1. критично 2. предупреждение 3. рекомендация 4. мелочь. Главный вопрос для пограничных случаев простой - «можешь описать конкретную ситуацию, где пострадает реальный пользователь?»

• Если да - это предупреждение. • Если нет - рекомендация.

Появился структурированный процесс для ситуаций, когда код удаляют, а не добавляют. Теперь он проходит три шага: сначала находит всё, что удалено - каждую функцию, каждый тип, каждый экспорт. Потом по каждому удалению определяет, безопасно ли это, нужна ли миграция, или удаление ломает что-то критическое. И в конце проверяет по чеклисту - удалены ли связанные тесты, типы, зависимости, не остались ли мёртвые импорты.

Это важно, потому что удаление кода - один из самых частых источников поломок, которые не ловят обычные тесты.

В области безопасности появилось два новых блока: 1. Первый - безопасность зависимостей. Когда добавляется новая библиотека, ревьюер теперь проверяет шесть вещей: не установлена ли версия «плавающая», не подменён ли файл с зависимостями, нет ли путаницы между внутренними и публичными пакетами, нет ли опечатки в имени пакета, есть ли проверка целостности для CDN-скриптов. 2. Второй блок - проверка HTTP-заголовков безопасности: правильно ли настроена защита от перехвата трафика, не открыт ли доступ к API со всех сайтов, не утекают ли внутренние данные через заголовки ответов. Раньше, когда ревьюер находил повторяющийся или запутанный код, он мог предложить его переписать. Но не всякий код стоит переписывать. Теперь есть восемь правил, которые помогают решить - рекомендовать рефакторинг или нет. Например: если код продублирован только один раз - не трогай, подожди третьего повтора. Если код давно не менялся - зачем его улучшать, он стабилен. Если на этот код нет тестов - сначала напиши тесты, потом переписывай.

Это экономит время и защищает от ненужных переделок.

Проверка архитектуры стала умнее. Вместо абстрактного «соблюдай SOLID» теперь для каждого из пяти принципов есть диагностический вопрос. После каждого ревью теперь предлагаются варианты действий. Раньше ревьюер выдавал отчёт - и дальше разработчик сам решал, что делать. Теперь есть четыре опции: • исправить всё автоматически • исправить только критичное • исправить конкретные пункты по номерам • просто взять отчёт как ориентир. И для каждого вердикта ревью есть рекомендованный вариант - чтобы не тратить время на выбор. Агента планирую улучшать и дальше. Если есть какие-то вопросы или предложения, с радостью отвечу в комментариях! 👍

9 AI-Агентов для Claude Code У Claude Code есть суперсила - субагенты. Это специализированные помощники, каждый из которых натренирован на одну конкретную задачу. Представь команду из 9 экспертов, каждый из которых мастер в своём деле: • один ревьюит код • другой ищет баги • третий анализирует производительность • четвёртый следит за текстами в интерфейсе Все 9 агентов, которыми я делюсь - это готовые .md-файлы. Ты просто кладёшь их в папку проекта, и они начинают работать. Никаких дополнительных настроек, плагинов или зависимостей. Как установить: Шаг 1: Скачай все 9 файлов:

code-reviewer.md
test-runner.md
test-analyst.md
debugger.md
performance-profiler.md
software-architect.md
design-team.md
content-team.md
text-polisher.md

Шаг 2: Создай папку в проекте В корне проекта, там, где лежит package.json или другие главные файлы, создай папку:

.claude/agents/

Claude Code автоматически подхватывает агентов из папки .claude/agents/. Никаких дополнительных настроек не нужно. Как вызывать агентов Просто напиши в Claude Code, что тебе нужно, и упомяни агента. Claude сам поймёт, какого агента запустить по контексту запроса.

Используй test-runner субагент чтобы прогнать тесты

Можно и без явного упоминания агента - Claude Code сам матчит запрос по описанию каждого агента и запускает нужного. Например, если ты напишешь "проверь код перед пушем", он сам вызовет code-reviewer. P.S. Я так же добавил тригеры для вызова от житейского текста:"звучит как чатгпт, перепиши" или "на телефоне кнопка мелкая".

Потрать 10 минут и изучи каждого агента: тригеры и функционал, чтобы точно не упустить лишнее.

Важные принципы работы агентов 1. Агенты - ревьюеры, не редакторы. Каждый агент находит проблемы и пишет структурированный отчёт. Код правит основной Claude Code, он называется "оркестратор". Это сделано специально для безопасности - агент анализирует, а решение о правках принимаешь ты. P.S. не забудь проверить на возможность корректной оркестрации! 2. Агенты работают в связке. В отчёте каждого агента есть секция "Next Steps", где он рекомендует, каких ещё агентов вызвать. Например, performance-profiler после анализа скажет: "запустите test-runner для проверки" и "вызовите code-reviewer для ревью кэширования". Это создаёт цепочку проверок. 3. Memory - память между сессиями. Все 9 агентов используют persistent memory - память, которая сохраняется между вызовами. Чем больше ты используешь агента на проекте, тем умнее он становится: • code-reviewer запоминает конвенции команды • test-runner запоминает нестабильные тесты • debugger запоминает типичные баги проекта • content-team накапливает глоссарий терминов Память хранится в папке .claude/ и переживает сессии. 4. Быстрые и мощные - выбирай по ситуации. Агенты используют разные модели Claude в зависимости от сложности задачи: • Haiku: test-runner, design-team, content-team. Их можно гонять часто, не переживая за бюджет. • Sonnet: code-reviewer, debugger, test-analyst, performance-profiler, software-architect, text-polisher. Более глубокий анализ, но чуть дороже. В зависимости от своих возможностей и предполагаемых расходов токенов ты можешь поменять, всё по своим нуждам. 5. CLAUDE.md усиливает агентов. Если в корне проекта есть файл CLAUDE.md с конвенциями и правилами проекта, агенты будут его учитывать. Это стандартный файл Claude Code, где описываются стандарты кодирования, архитектурные решения, стек технологий. Без него агенты тоже работают, просто без проектного контекста. Советую прочитать / скормить своей LLM эту статейку для реализации CLAUDE.md Так же учел переполнение контекстного окна и другие угловые моменты, чтобы агенты вели себя корректно. На своём приложении использовал похожие давно - но этих прямо таки улучшал последнюю неделю и тренировал на самых разных ситуациях. —— Я буду дополнять этот пост по мере времени и улучшения агентов. Вопросы? Пожелания? Уточнения? Буду рад прочитать в комментариях. Всех агентов прикрепил в первом комментарии к этому посту —- UPD 11.02: Обновил code-review агента

Сегодня OpenAI запустила Frontier - платформу, где компании могут создавать, деплоить и менеджить AI-агентов. Не ботов. Не ассистентов. Именно «AI coworkers» - так написано в официальном блоге. Посмотрел, почитал и выглядит интересным. У каждого агента будет своя идеентичность, разрешения, компетенции и т.д. Прям как у настоящего работника, обещает OpenAI. По сути, OpenAI строит операционную систему для enterprise, куда втыкаются любые AI-агенты. Единый контекст бизнеса, единый execution environment, единая система оценки и оптимизации. Цен или детальных подробностей нет, да и доступ ограниченный, но направление интересно, что AI агенты - будущие сотрудники. Поглядим. • Introducing OpenAI Frontier • OpenAI Frontier

400 часов вайбкодинга: инструменты, ошибки, деплой за $5 https://www.youtube.com/watch?v=lRGxl6uA72g В первой части я объяснил, что такое вайбкодинг. Теперь покажу, как я реально работаю: мой стек, мои инструменты, мои ошибки. Всё из Telegram Mini App, который я собирал 400 часов в Claude Code. Что внутри: — Мой стек и почему именно он. Объясняю каждый выбор простым языком. — Дизайн-система и готовые блоки. 5 модулей = 70% любого проекта готово. Собрал один раз - использую в каждом новом проекте. — Тестирование с AI. Пирамида: unit, integration, e2e. AI генерирует 10 тестов за секунды. Час на тесты = 10 часов сэкономленного дебага. — MCP-плагины: Serena, Context7, Sentry, Playwright. Мой конфиг + как подключить. — Skills - модули знаний для Claude: superpowers, blader. Как создать свой skill. Мои грабли и советы. — Railway - деплой за $5/мес. 650+ темплейтов, логи, работа с окружениями и домен с БД из коробки. — Реальность vs Ожидания. Сколько времени реально нужно. Почему вайбкодер, который не понимает код - потратит неделю там, где опытный починит за час. Каждый инструмент объяснён так, чтобы понял человек без опыта. Аналогии, сравнения, конкретные шаги. Без воды. Смотри до конца, чтобы понять где и как LLM тебя обманывает и пишет код с багами. 🫢 P.S. Презентация из видео в первом комментарии

Привет, сегодня в 18:15 на Youtube будет прямая трансляция - особенно подойдет под вопросы и уточнения по материалу трансляции. Если-что запись и всё всё будет самособой. На скриншоте кусочек из презентации, по которой сегодня будем идти, буду ждать и до встречи! :)

Моя кухня вайбкодера: 400 часов опыта | MCP, Skills, AI-команда Первое видео было "что такое вайбкодинг". Это - "как я его готовлю". После 400 часов в Claude Code у меня сформировался сетап, но не тот, что в красивых демках, а тот, что реально работает. Про стек: • Почему Zustand, а не Redux. Почему эти технологии. Не потому что модно - потому что AI с ними дружит лучше. Про переиспользуемость • Что тащить из проекта в проект. Компоненты, хуки, конфиги. Один раз сделал - везде работает. Про тесты • Claude любит "улучшать" код. Без тестов это русская рулетка. С тестами - спокойный сон. Про MCP-плагины • Моя шестёрка: Serena, Playwright, Context7, Sentry, Brave Search, Supabase. Что делает каждый и для чего мне они? Про "день сурка" • Каждый чат - Claude забывает кто ты. Надоело писать "веди себя как X разработчик". Projects, CLAUDE.md, Subagents - как настроить один раз и забыть. Про Skills • Папка, которую Claude читает до ответа. Мало кто знает. Меняет всё. Кому смотреть: 1. Уже пробовал AI для кода, хочешь глубже 2. Слышал про MCP, но не понимаешь зачем 3. Устал копипастить одни и те же промпты 4. Хочешь понять как выглядит "прокачанный" вайбкодинг 🗓️ Когда: 4 февраля в 18:15 по МСК ⏳ Продолжительность: Порядка 70 минут 📍 Где: Youtube 🔋 Запись будет

Стек, который AI понимает с полуслова Опыт в программировании научил меня одному, половина успеха проекта - правильный стек. Не модный. Не хайповый. А для наших нужд тот, на котором AI обучен лучше всего.

Если слово "стек" пока не знакомое - не страшно. Это просто набор инструментов, которыми ты собираешь проект. Как конструктор: база данных + сервер + интерфейс + всякое между ними. Запомни слово и спроси у Claude "что такое технический стек и зачем он нужен" - он объяснит под твой уровень.

1. React 18 - №1 по популярности. Claude и GPT видели миллионы примеров. Я просто пишу "сделай компонент карточки" и получаю рабочий код, а не франкенштейна. 2. TypeScript - AI видит типы и меньше галлюцинирует. Лично у меня показал себя лучше аналогов, т.к. П1 - много примеров. 3. Vite - Hot Module Replacement. Написал промпт, получил код, увидел результат. Быстрый фидбек-луп = быстрый вайбкодинг. 4. Tailwind - стили прямо в разметке. AI не надо прыгать между файлами. Один контекст = меньше ошибок. Настоящее сокровище и лучше, чем просто CSS. 5. Zustand - 10 строк стейт-менеджмента против 50 на Redux. Меньше бойлерплейта = меньше места для багов AI. 6. Framer Motion - декларативные анимации. Описываешь что хочешь, а не как. Идеально для промптов. 7. NestJS - структура из коробки. AI любит паттерны, аут их много и они консистентные. 8. Prisma - type-safe ORM. Схема как единый источник правды. AI точно знает, какие поля есть, чтобы не было галлюцинаций и лишних полей. 9. PostgreSQL - классика. Документации море, примеров море, мой AI справляется отлично. 10. Railway - git push и в проде, деплой не должен быть дл тебя отдельным квестом. Плачу в месяц по 5$ из-под капота логи, быстрое подключение любых шаблонов: от БД до админок. Чем больше примеров видел AI, тем лучше код. Чем строже типы, тем меньше галлюцинаций. Чем декларативнее синтаксис, тем проще объяснить промптом. У кого-то совпал стек со мной? 🤔

4 месяца работы, 400+ юзеров и ноль крашей. Но сегодня открываю комментарий на YouTube - и бац, комментарий про краш... И что самое обидное - это был старый рефакторинг. Как оказалось из логов, моя система онбординга имела одну ахиллесову пяту, которая ждала своего часа. И дождалась :D Краш в приложении - это не просто красный экран. Это слетевшие сохранения. Товары в корзине, которых больше нет. Пользователь, который может не вернуться. У нас в разработке чёрным по белому документация всегда говорит:"Краш для пользователей - это самый негативный опыт. Не допускайте этого". Спасибо этой ситуации, для себя я урок вынес - тесты на этот функционал написал за 10 минут. Больше краша не будет. Можно улучшать разработческий процесс и чтобы самому не забыть - прописать за правило для работяжки покрывать тестами.

Хотел бы поделиться опытом, как минимизировать краши: • Тесты - не паранойя, а гигиена. Можно не гонять всё подряд. Попроси Claude сделать умную систему: перед пушем - только задетый функционал, по ночам - полный прогон. Экономит время, ловит баги. • Критичные фичи - на отдельной ветке. Пока не убедился, что всё ок - юзеры этого не видят. • Большой функционал раскатывай постепенно. Выкатил - смотришь метрики. Всё чисто - катишь дальше.

—— Если для вас критично отсутствие критичных багов и крашей - лучше пишите тесты, гоняйте их - чтобы не терять пользователей :)

Пилю фичу неделю. Уверен, что будет круто. Показываю девушке - "ну прикольно". Начинаю выкатывать в про - ноль реакции. А что не так? [pepe-thinking-face.jpg] А не так то, что фидбек "прикольно" - это не фидбек. Это вежливость. Близкие люди склонны относиться к нам лояльно. Но мне нужен кто-то, кто скажет: "Слушай, а вот тут я вообще не понял, куда тыкать". Если раньше я звал друзей-разработчиков. Но у них свои проекты, свои дедлайны. Просить неудобно, а ждать долго. Поэтому я собрал команду из клод работяг. Их у меня много, но я хочу остановиться на трёх AI-ролях пользователей. Они смотрят на каждую фичу с разных сторон

1. Скептик. Его работа - сомневаться. "А кому это надо?", "А почему юзер будет этим пользоваться?", "А что если он просто закроет приложение?". Неприятный помощник. Но после него фича либо становится крепче, либо летит в корзину. И это хорошо - лучше узнать сейчас, чем после релиза. 2. Новичок. Ничего не знает про тематику мини апы, про ЯП, про моё приложение. Тыкает куда не надо. Не читает подсказки. Спрашивает очевидное. Как по мне - это идеальный краш-тест на UX - если новичок разобрался, разберётся любой. 3. Фанат

Любит продукт. Готов терпеть баги. Но даже он иногда говорит: "Вот тут бесит". И это самый ценный фидбек - если даже лояльный юзер морщится, значит проблема реальная.

Вот пример. Делаю табу прогресса [cм. скриншот] - там статистика, метрики, уровни мастерства и сравнения с другими пользователями. Решил, что хочу узнать, а точно ли уровень мастерства вообще нужен? Какую цель он преследует? Прогнал через скептика, а от него первый вопрос:"Зачем юзеру знать свой уровень мастерства, если он не понимает, как этот уровень считается?". И понимаю, что ведь он прав. Необходимо добавить нужный функционал. Эту штуку с ролями я подсмотрел в СММ ещё в 2015 году. Там есть практика - прописывать портреты клиентов. Не абстрактных "пользователей", а конкретных людей. С возрастом, привычками, страхами. Иногда даже с именами и фотками. Возможно звучит как перебор? Может быть, но когда ты спрашиваешь "А зайдёт ли фича?" - одно дело гадать, другое - спросить у "Васи, 28 лет, джун, учит Swift по вечерам после работы". Я просто перенёс этот подход в свой вайбкодинг. Прописал каждую роль детально: кто он, как думает, что его бесит, чего хочет. Скриншоты промптов - на картинках. Если-что это не серебряная пуля. Иногда роли несут херню. Но чаще - они ловят косяки, которые я сам не вижу. Потому что я слишком близко к продукту. А они - нет. Попробуй собрать свою команду. Не обязательно три роли - может хватит одной. Не обязательно для всего приложения - можно для одного экрана или флоу. В комментарии залью скриншоты, сорри, забыл к посту прикрепить… —- Прикрепил для общего понимания, энивей LLM'ка поможет с реализацией. Завтра распишу про свой стек, спасибо за внимание! [pepe-happy.jpg] Целевая Аудитория 🎯| Как составить портрет ВАШЕГО клиента?