Почему формулировка решает почти всё
В вайбкодинге ты не пишешь код построчно, но именно поэтому формулировка задачи становится главным инструментом. Она заменяет и код, и техническое задание одновременно.
Расплывчатая задача даёт агенту слишком много свободы додумывать. Он не спрашивает уточнений сам, если явно не попросить, а просто выбирает самый вероятный вариант и делает его. Если вариант оказался не тем, что нужно, переделка стоит времени, а иногда и денег, если работа идёт через API.
Из чего состоит хорошая задача
Три части, которые почти всегда стоит проговаривать явно, а не оставлять «по умолчанию».
- Что должно получиться. Конечный результат, а не процесс: «кнопка, которая открывает окно оплаты», а не «сделай оплату как-нибудь»
- Контекст. Что уже есть в проекте, какие файлы или части кода это затрагивает, на чём написан проект
- Ограничения. Что трогать не нужно, какой стиль или библиотека уже используется, есть ли жёсткие требования (например, бесплатный хостинг)
Не обязательно писать это тремя пунктами каждый раз. Но если задача сложнее одной строчки, полезно проговорить хотя бы контекст: агент не помнит то, что не видел, и не читает твои мысли.
Плохо и хорошо рядом
Один и тот же результат, но с разным шансом получить его с первого раза.
«Сделай сайт для бота»
Неясно: одна страница или несколько, какой стиль, какие тексты, куда деплоить.
«Одна страница-лендинг под наш Telegram-бот»
С кнопкой перехода в бот, в тёплой светлой палитре, деплой на Cloudflare Pages, без форм и оплаты на самой странице.
«Почини баг»
Какой именно баг, где он проявляется, что должно происходить вместо этого.
«При оплате меньше 100₽ бот не присылает чек»
Должен присылать всегда, файл webhook.py, логика фискализации там же.
Частая ошибка новичка
Пытаться описать сразу всё одним огромным сообщением на старте проекта.
Лучше двигаться маленькими шагами: одна задача, проверка результата, следующая задача. Это медленнее по количеству сообщений, но сильно надёжнее и дешевле по итоговым переделкам.