➡️Как начать вайбкодить лучше?
Группа ИТ/ИИ мудрецов на стриме обсуждала разработку с ИИ-агентами.
Я вытащил с ЖПТ из него несколько вещей, которые можно довольно быстро применить у себя. Текст очистил от всякой бесовщины типа "эвалы", "целевые функции", "проекции" и прочих терминов, после употребления которых нужно мыть рот с мылом😄 Итак, как вайбкодить лучше: 1️⃣ Проверять описание скилла.
Именно по нему агент понимает, какой скилл подходит под задачу. Если описание неудачное, нужный скилл может просто не найтись или вместо него вызовется другой. Проверять на 2-3 примерах недостаточно. Можно взять 15-30 реальных формулировок своих задач и посмотреть: находит ли агент нужный скилл каждый раз, когда должен, и не вызывает ли его там, где не надо.
2️⃣ Перед задачей спросить: "А как автоматически понять, что агент сделал все хорошо?"
Можно самому придумать критерий или прямо спросить об этом агента до начала работы.
Например: должны пройти определённые тесты, API должен вернуть конкретную структуру, в БД должны появиться нужные записи, старый функционал не должен сломаться.
Чем лучше результат можно проверить автоматически, тем спокойнее агенту можно отдавать длинные задачи. Если после каждого его захода нужно полчаса вручную разбираться, хорошо он сделал или плохо, — автономность получается довольно условная.
3️⃣ Важные правила переносить из инструкций в автоматические проверки.
Можно десять раз написать в CLAUDE.md: "никогда не делай X". Агент все равно иногда решит, что конкретно сейчас можно. Если нарушение правила может дорого обойтись, лучше сделать так, чтобы нарушить его технически было сложно: тест, lint, hook, проверка в CI, архитектурный тест.
То есть CLAUDE.md объясняет правило, а код проверяет, что агент действительно его соблюдает.
4️⃣ Иногда специально ломать код и смотреть, заметят ли это тесты.
Особенно если код и тесты к нему написал один и тот же агент. Получить 143 tests passed приятно, но это ещё не означает, что эти 143 теста что-то реально ловят.
Для важных мест можно сделать очень простую проверку: намеренно сломать реализацию → запустить тесты → убедиться, что они покраснели.
Если после поломки всё по-прежнему GREEN, у нас не тест, а зелёная лампочка для успокоения.
5️⃣ Дать агенту КОМПАКТНУЮ карту проекта.
На больших проектах значительная часть работы агента — вообще не кодинг, а попытка понять: где лежит нужный код, откуда сюда приходят данные и что сломается, если это поменять.
Поэтому полезен отдельный слой документации: основные модули, связи между ними, точки входа, потоки данных, важные ограничения.
Но есть ловушка: если «краткая карта проекта» разрастается в 70 КБ Markdown, к которому потом нужен ещё один индекс, мы просто создали второй проект. Карта должна действительно сокращать пространство поиска, а не добавлять новое.
6️⃣ Научить агента говорить: "Стоп, тут проблема больше, чем задача".
Послали исправить маленький баг. В процессе выяснилось, что под ним архитектурная проблема. Разработчик может вернуться и сказать: "Я бы пока не фиксил, тут надо сначала решить другую вещь".
Агент по умолчанию скорее продолжит старательно выполнять исходную задачу. Поэтому в скилл разработки стоит прямо добавить правило: если найденное существенно меняет архитектуру, объём задачи или исходные предположения - не маскировать проблему локальным фиксом, а вынести её пользователю и предложить варианты.
Все эти мудрости не обязательно держать в голове. Передайте этот пост агенту, пусть сам создаст скилл с подобными навыками:
Например, чтобы перед началом работы спрашивал: ➖ Как будем проверять результат? ➖ Какие ограничения здесь критичны? ➖ Можно ли проверить их автоматически?
А после работы: ➖ Действительно ли тесты ловят ошибку? ➖ Не обнаружилось ли что-то, что меняет исходную постановку? ➖ Не нужно ли обновить карту проекта?
Как-то так❤️
