# Инструменты для вайб-программирования требуют границ

> Практическая карта инструментов для вайб-программирования по автономности, владению кодом, контролю развертывания и готовности к продакшену.

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

Я видел, как команды покупали автономность и считали, что вместе с ней получили инженерную дисциплину. Они ее не получили. Конструктор может превратить абзац текста в рабочее приложение и при этом скрыть решения, которые опытный инженер захотел бы проверить. Агент может изменить пятьдесят файлов и успешно пройти тесты, неверно поняв бизнес-правило. IDE может показывать каждое изменение и все равно позволить уставшему разработчику одобрить ерунду. Выбирайте модель взаимодействия под конкретную работу, а затем стройте вокруг нее границу продакшена.

## Сначала определите автономность, потом сравнивайте продукты

Автономность показывает расстояние между инструкцией и завершенным изменением. О качестве этого изменения она ничего не говорит. Это различие устраняет большую часть путаницы при сравнении конструкторов, IDE и агентов.

На первом уровне помощник предлагает строку, функцию или объяснение, а человек управляет работой. На втором агент в редакторе меняет несколько файлов, ищет по репозиторию и выполняет команды в активной сессии. На третьем агент для задач получает ожидаемый результат, работает по плану, запускает тесты и возвращает diff или pull request. На четвертом конструктор контролирует значительную часть среды вместе с кодом: создает интерфейс, подключает данные, показывает предварительный результат и публикует его.

Эти уровни не образуют рейтинг зрелости. Инструмент с меньшей автономностью может лучше подходить для продакшена, потому что вписывается в существующий репозиторий, набор тестов, правила ревью и путь развертывания. Высокоавтономный конструктор может оказаться правильным выбором для внутренней формы приема заявок, ведь неделя обычной разработки обойдется дороже связанного с ним риска. Но тот же конструктор может не подойти для биллингового сервиса, где правила повторных попыток и сверки платежей формировались годами.

Я задаю пять вопросов, чтобы поместить любой инструмент на эту карту:

- Он работает в сгенерированном проекте, существующем репозитории или в обоих вариантах?
- Может ли он выполнять команды и читать их вывод без отдельного промпта на каждое действие?
- Может ли он менять инфраструктуру, данные, секреты или состояние развертывания?
- Он возвращает редактируемый исходный код, проверяемый diff или только опубликованный результат?
- Может ли команда ограничить его инструменты и требовать одобрения человека на рискованных границах?

Поставщик может уже на следующей неделе добавить новую модель или режим, а эти вопросы останутся прежними. Поэтому карта долговечнее любого рейтинга. Она также показывает цену, скрытую за удобством. Чем дальше может пройти агент, тем больше контекста, разрешений и приемочных тестов ему нужно.

## Конструкторы быстрее начинают с нуля, но первыми теряют контекст

ИИ-конструкторы приложений особенно сильны, когда продукт можно с самого начала вписать в их допущения. Они объединяют настройку, работу над интерфейсом, подключение бэкенда, предпросмотр и хостинг в одном диалоге. Lovable, Bolt, Replit Agent и v0 относятся к этой широкой категории, хотя каждый по-своему проводит границу между кодом, хостингом и интеграциями.

Эта категория хорошо подходит для одноразового прототипа, первой интерактивной спецификации от основателя, инструмента для рекламной кампании, простого внутреннего процесса или нового веб-продукта с обычными схемами данных. Она гораздо слабее выглядит, когда работа начинается со зрелого монорепозитория, закрытого графа пакетов, необычной инфраструктуры или поведения, в котором накопились годы инцидентов и обходных решений. На пустой странице нет старого контекста, который можно упустить. В существующей системе он есть.

Готовность к продакшену не определяется наличием кнопки Publish. Публикация доказывает, что платформа способна разместить артефакт по некоторому адресу. Она не доказывает, что ваша команда может воспроизвести сборку, проверить изменения зависимостей, безопасно перенести данные, восстановить состояние продакшена или поддержать сервис во время сбоя у поставщика. Документация Lovable четко описывает одну границу: публикация развертывает снимок, а последующие правки не выходят в продакшен, пока кто-то снова не запустит публикацию. Интеграция с GitHub дает еще один важный выход, синхронизируя редактируемый исходный код и позволяя работать в обычной IDE. Это полезные механизмы контроля, но команда все равно должна решить, какая система хранит единственный источник истины и управляет развертыванием.

Документация Replit по контрольным точкам не менее показательна. Контрольные точки Agent могут сохранять файлы проекта, контекст диалога, конфигурацию и состояние подключенной базы данных. Поведение, описанное в том же руководстве, предупреждает: восстановление контрольной точки среды разработки не равно восстановлению продакшен-базы. Это различие существенно. Откат исходного кода, откат схемы и восстановление данных остаются тремя отдельными операциями, даже если один интерфейс показывает их рядом.

Конструктор готов к продакшену только в пределах четко ограниченного типа продукта. Экспортируйте исходный код до того, как приложение станет значимым. Подчините его правилам корпоративного репозитория. Добавьте независимый мониторинг, резервные копии, проверку доступа и испытанный путь восстановления. Если конструктор не поддерживает эти действия, называйте результат прототипом и заранее закладывайте бюджет на замену, а не объявляйте его продакшеном без лишнего шума.

## Агенты в IDE меняют часть скорости на контроль

Агентные IDE подходят по умолчанию командам, которые уже владеют кодовой базой и хотят оставить инженера внутри контура обратной связи. Cursor, Windsurf, GitHub Copilot в редакторе и похожие инструменты умеют искать по файлам, предлагать план, редактировать рабочее дерево, выполнять команды терминала и реагировать на ошибки компилятора или тестов. Инженер видит репозиторий, diff, терминал и диагностику в одном месте.

Такая схема дает агенту гораздо больше возможностей, чем автодополнение, но не передает ему весь процесс поставки. Например, документация Cursor описывает Agent как систему, способную редактировать код и выполнять команды терминала, а правила проекта хранят стандарты программирования и повторяющийся контекст. Одобрение команд в CLI задает явную точку контроля. Режимы редактора GitHub Copilot теперь охватывают вопросы, правки, агентные сессии и делегирование, но единицей работы остается репозиторий.

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

Слабое место этой схемы в усталости от подтверждений. После десяти безобидных запросов на выполнение команды люди одобряют одиннадцатый, не читая. Окно разрешения не может нести на себе всю модель безопасности. Храните секреты вне рабочего дерева, запускайте агента с минимально необходимым доступом операционной системы, а необратимые действия защищайте отдельными учетными данными или отдельным процессом. Если сессия редактора умеет читать продакшен-токены и обращаться к панели управления продакшеном, опасное решение уже принято до появления любого запроса.

Агенты в IDE также подталкивают команды путать видимость с ревью. Когда файлы меняются перед глазами, кажется, что вы понимаете изменения, но быстро прокрученный код никто не проверил. Требуйте чистый diff, успешные проверки и вторую пару глаз для тех же классов изменений, где это требовалось до появления ИИ в редакторе.

## Агенты для задач заслуживают автономность проверяемой передачей работы

Агенты для задач приносят больше всего пользы, когда получают ограниченный результат и возвращают ветку, патч или pull request со свидетельствами проверки. Claude Code и Codex могут локально работать с репозиторием и терминалом. Облачные системы вроде coding agent в GitHub Copilot получают issue, работают асинхронно и готовят pull request к ревью. Вместо постоянной парной работы вы делегируете отдельный пакет.

Это дает хороший результат при миграциях, обновлении зависимостей, починке тестов, повторяющихся рефакторингах, изменениях документации вместе с кодом и четко описанных функциях. Метод плохо работает, если в задаче скрыто продуктовое решение, она зависит от знаний в головах сотрудников или нет исполняемого способа отличить правильный результат от правдоподобного. Подробное issue не заменит отсутствующее решение по политике продукта.

Полномочия определяют, принесет дополнительная автономность пользу или риск. Документация Anthropic по Claude Code разделяет доступ на чтение, команды оболочки и изменение файлов, а также позволяет командам распространять правила разрешений. Хуки могут проверять вызовы инструментов до выполнения. Здесь нужна важная оговорка: хук выполняется внутри рабочей среды агента, поэтому команда не должна считать правило на уровне промпта границей безопасности операционной системы. Настоящую изоляцию по-прежнему обеспечивают песочница и ограниченные учетные данные.

Документация GitHub дает понятный пример границы ревью. Coding agent работает над задачей и открывает pull request, а правила репозитория и проверка человеком контролируют слияние. До создания pull request агент может исследовать репозиторий, составлять план и дорабатывать изменения. Для продакшена такой подход лучше прямого доступа агента к развертыванию, потому что передача работы использует артефакты, которые команда уже умеет проверять.

Агент для задач становится надежнее, когда репозиторий умеет механически объяснить, что значит успех. Дайте ему команды форматирования, проверки типов, модульных и интеграционных тестов, а также точечной сквозной проверки. Укажите запрещенные файлы, интерфейсы, которые обязаны сохранить совместимость, и свидетельства, которые должны войти в результат. Автономность без приемочного контракта лишь создает ошибки быстрее и дальше от человека, который запросил работу.

## Качество контекста задает настоящий предел

Агент может действовать только на основе знаний о продукте, которые попали в его контекст, поэтому подготовка репозитория часто важнее смены модели. Код показывает, что система делает сейчас. Он редко объясняет, почему странное поведение надо сохранить, какой клиент от него зависит или какое на вид неиспользуемое поле поддерживает ежемесячную сверку.

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

Большинство команд совершает одну из двух ошибок. Одни пишут огромный файл инструкций с общими инженерными советами, который отнимает внимание и не разрешает локальные вопросы. Другие не дают никаких инструкций и ждут, что агент поймет архитектуру, прочитав тысячи файлов. Делайте постоянные указания короткими, конкретными и проверяемыми. Фраза «Используй существующий объект значения Money и никогда не передавай суммы с плавающей точкой через границу биллинга» помогает. Фраза «Пиши чистый, поддерживаемый код» не добавляет ничего.

Представим сервис подписки с endpoint для отмены. В видимом запросе сказано немедленно остановить будущие продления. В репозитории есть на вид лишнее состояние `pending_cancel`, и агент упрощает поток, удаляя его. Модульные тесты проходят, потому что проверяют конечное состояние. В продакшене платежный провайдер присылает с задержкой успешный callback для уже начатого продления. Без промежуточного состояния обработчик снова активирует отмененную подписку и отправляет неверную квитанцию.

Причиной сбоя стали не плохой синтаксис и не слабая модель. Бизнес-инвариант существовал только в голове инженера, который разбирал исходный инцидент. Правильное исправление фиксирует этот инвариант рядом с машиной состояний, добавляет тест на отложенный callback и прямо указывает в задаче, что отмена должна иметь приоритет над более поздними событиями продления. После этого у конструкторов, IDE-агентов и агентов задач больше шансов сохранить правило.

У контекста также есть цена доступа. Если дать агенту все документы, тикеты, базы и сообщения, он может лучше находить информацию, но заодно увидит секреты и ненужные персональные данные. Ограничивайте поиск рамками задачи и предпочитайте отобранные технические записи неограниченному поиску по компании. Агенту, который реализует истечение срока приглашений, могут понадобиться контракт API и правила авторизации. Ему не нужны зарплатные файлы или таблица продакшен-клиентов.

Следите за деградацией контекста в длинных сессиях. Агенты сворачивают ранние материалы, чтобы продолжить работу, и важные исключения могут затеряться за более новыми инструкциями. Делите крупные результаты на проверяемые изменения и повторяйте критерии приемки в артефакте, который управляет каждым изменением. Если агент начинает редактировать посторонние области или оправдывать проваленный тест, остановите сессию и сузьте задачу. Продолжение обычно дает больший diff с тем же неверным пониманием.

Максимальный уровень автономности команды зависит от того, какая часть ее намерений записана явно. Хорошо подготовленный репозиторий позволяет агенту задач завершать значимую работу без постоянных поправок. Репозиторий, построенный на устных знаниях, требует контроля опытного инженера на каждом шаге, независимо от возможностей, показанных на демо. Прежде чем винить инструмент, проверьте, смог бы новый инженер-человек обнаружить то же правило в предоставленных материалах.

Контекст репозитория должен пережить смену инструмента. Храните команды в обычных скриптах, ограничения в простом тексте, а решения рядом с кодом, которым они управляют, вместо того чтобы записывать все знания в формате одного поставщика. Специальные правила продукта могут ссылаться на эти источники, но не должны оставаться их единственной копией. Тогда экспорт из конструктора продолжит работать в IDE, а локальный и облачный агенты смогут опираться на один контракт.

Считайте сгенерированные объяснения зацепками, а не записями для будущего. Когда агент находит реальную зависимость или неожиданное ограничение развертывания, проверьте находку и обновите документацию репозитория или тест. Не рассчитывайте, что следующая сессия восстановит открытие из истории диалога. Накопительный эффект работы с ИИ появляется, когда кодовую базу становится легче понять следующему исполнителю, человеку или другому агенту.

## Готовность к продакшену лежит на отдельной оси

Готовность к продакшену показывает, может ли команда понять получившуюся систему, контролировать ее и восстановить после сбоя. Ее нужно отделять от автономности: высокоавтономный инструмент способен выдать пригодное к эксплуатации изменение, а осторожный помощник все равно может помочь создать конструкцию, которую невозможно нормально проверить.

Я оцениваю готовность по шести рубежам. Владение показывает, есть ли у компании исходный код, описание сборки, lock-файлы зависимостей и юридическое право эксплуатировать результат. Воспроизводимость отвечает на вопрос, может ли чистая среда собрать и проверить его. Проверяемость показывает, могут ли люди изучить ограниченный diff и связать его с требованием. Эксплуатация охватывает логи, метрики, оповещения, лимиты расходов и ответственность за поддержку. Безопасность включает идентификацию, работу с секретами, проверку зависимостей, доступ к данным и объем полномочий. Восстановление включает откат приложения, совместимость схемы, возврат из резервной копии и человека с правом действовать.

Инструменту не обязательно самому обеспечивать каждый рубеж. На практике зрелые команды обычно собирают их из правил репозитория, непрерывной интеграции, облачных политик, наблюдаемости и практики работы с инцидентами. Инструмент программирования должен вписываться в эти механизмы и не обходить их. Конструктор с экспортом исходников и обычным конвейером развертывания может получить высокую оценку. Агент в IDE с неограниченными учетными данными и без тестов может получить низкую.

Используйте четыре состояния готовности вместо выдуманной числовой оценки. «Прототип» означает, что ошибка стоит дешево, а данные можно выбросить. «Внутренний под наблюдением» означает известных пользователей, ограниченные данные и владельца, который может допустить ручное восстановление. «Для клиентов» требует воспроизводимой поставки, мониторинга, проверки безопасности и испытанного восстановления. «Регулируемый или с высокими последствиями» добавляет хранение свидетельств, разделение обязанностей, управление доступом и проверку по правилам конкретной отрасли.

На неудобный вопрос «Безопасно ли вайб-программирование для продакшена?» есть точный ответ: сам стиль взаимодействия не бывает безопасным или опасным. Безопасность появляется, когда последствия сбоя соответствуют механизмам вокруг сгенерированного изменения. Маркетинговый калькулятор и сервис расчета дозировки лекарств не должны подчиняться одной политике одобрения, даже если один агент способен построить оба.

## Подбирайте инструмент под цену ошибки

Лучший инструмент остается самым простым из тех, что способны выполнить работу внутри необходимых ограничений. Команды часто выбирают самый автономный продукт, потому что на демо он выглядит дешевле. Затем они тратят сэкономленное время на восстановление контекста, ревью слишком больших diff и исправление неверных допущений о развертывании.

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

Для существующего продукта начните с IDE или агента репозитория. Существующий код, тесты, история ревью и конвейер поставки дают преимущество. Не переносите работу в закрытый проект только ради более красивого поля для промпта. Используйте агента задач, если критерии приемки можно исполнить, а diff возвращается через обычный pull request. Используйте агента в IDE, если инженер должен принимать продуктовые или архитектурные решения во время реализации.

Для инфраструктуры, аутентификации, биллинга, приватности и разрушительных изменений данных сокращайте автономный охват. Агент может исследовать задачу, подготовить черновик, провести тесты в изолированной среде и составить план. Человек должен одобрить точное изменение, а применять его должна отдельная система развертывания. Дело не в оценке интеллекта модели. У этих областей высокая цена ошибки, и им часто нужна информация, которой нет в репозитории.

Выбор инструмента меняется даже в пределах одного проекта. Основатель может собрать поток в конструкторе, экспортировать код, перейти в IDE для развития продукта и делегировать ограниченные задачи обслуживания облачному агенту. Относитесь к категориям как к рабочим режимам, а не лагерям. Переход при изменении риска показывает, что команда понимает характер работы.

## Граница продакшена должна находиться в CI

Непрерывная интеграция должна решать, может ли написанный агентом код двигаться дальше, потому что CI применяет одинаковые проверки независимо от автора изменения. Инструкции в промпте направляют поведение. Защита веток, изолированные сборки, обязательные проверки и разрешения на развертывание обеспечивают соблюдение правил.

Поместите приемочный контракт в репозиторий, где его прочитают и люди, и агенты. Небольшой файл задачи не позволит длинному диалогу уйти в сторону:

```yaml
change:
  goal: "Reject expired invitations without changing valid invite behavior"
  allowed_paths:
    - src/invitations/**
    - tests/invitations/**
  forbidden_paths:
    - migrations/**
    - deploy/**
acceptance:
  commands:
    - npm run typecheck
    - npm test -- invitations
  evidence:
    - failing test before fix
    - passing test after fix
  rollback: "Revert one pull request; no schema change"
```

Этот артефакт делает видимыми четыре решения: рамки работы, запрещенные области, исполняемые проверки и восстановление. Агент все еще может неверно реализовать бизнес-правило, но уже не сможет убедительно заявить о завершении после правки файлов развертывания или пропуска тестов приглашений. Ревьюер сравнит diff с компактным контрактом, вместо того чтобы восстанавливать намерение по стенограмме чата.

CI должен работать в чистой среде с учетными данными, которые не позволяют развертывание. Сгенерированные тем же агентом тесты требуют ревью, потому что агент способен заставить пройти слабую проверку. По возможности требуйте существующий регрессионный тест, затем добавляйте новый, который показывает сбой до исправления. Для работы с базой проверяйте прямую миграцию и совместимость с предыдущей версией приложения. Откат, который зависит от обратного выполнения разрушительной команды для схемы, нельзя считать планом отката.

Уберите развертывание из стандартного набора инструментов агента программирования. Пусть агент подготовит артефакт, а система релизов продвинет его после одобрений. Если команда хочет автоматическое развертывание для сервисов с низким риском, зафиксируйте исключение в политике репозитория. Не выдавайте широкий доступ к продакшену только потому, что постоянные подтверждения начали раздражать.

## Оплачиваемая рабочая проба полезнее списка функций

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

Выберите задачу, которую компетентный инженер способен закончить, но которая затрагивает больше одного файла. Добавьте небольшую неоднозначность, которую хороший инструмент должен обнаружить, существующий тест, который обязан продолжить проходить, и одну запрещенную область. Дайте всем кандидатам одинаковое состояние репозитория и один приемочный контракт. Не используйте игрушечную задачу, решение которой встречается в публичных примерах.

Запишите пять результатов: затраченное внимание человека, полное календарное время, число циклов исправлений, размер итогового diff и свидетельства, переданные вместе с работой. Затем проверьте путь отказа. Остановите агента посередине, отклоните предложенную команду, добавьте падающий тест и откатите нежелательное изменение. Инструмент, который впечатляет только при идеальном ходе событий, не готов войти в процесс поставки.

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

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

## Одна рабочая модель может объединить все три категории

Небольшая инженерная команда с ИИ может вместе использовать конструкторы, агентов в IDE и агентов задач, если всеми управляет одна система поставки. Конструкторы исследуют новые части продукта. Агенты в IDE выполняют изменения, где нужны решения по ходу работы. Агенты для задач забирают ограниченное обслуживание и реализацию. Каждое долговечное изменение в итоге попадает в принадлежащий компании репозиторий, проходит одинаковые проверки, получает ревью с учетом риска и движется через контролируемый релиз.

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

Не начинайте с покупки одного инструмента каждому разработчику. Сначала составьте перечень работы: эксперименты с нуля, изменения продукта, очереди обслуживания, исправления инцидентов, инфраструктура и регулируемые области. Назначьте каждому классу потолок автономности. Затем проверьте по одному инструменту в каждом режиме на общей границе продакшена.

Здесь опытный fractional CTO может избавить от дорогих проб и ошибок. Team & AI Audit должен определить, какую работу можно передать агентам, каких механизмов не хватает и выдерживает ли обещанная экономия на зарплатах столкновение с реальным репозиторием и процессом релизов. Инструмент купить легко. Рабочая модель решает, превратится ли очередь для десяти человек в работу одного-двух хорошо оснащенных инженеров или просто станет более быстрой очередью непроверенных изменений.

Сохраняйте категории гибкими, а границу твердой. Разрешайте конструктору далеко заходить в одноразовой работе. Позволяйте агенту в IDE быстро двигаться внутри ветки разработчика. Давайте агенту задач возвращать готовый pull request. Но продакшен по-прежнему должен требовать исходники в собственности компании, исполняемые свидетельства, ревью соразмерно цене ошибки и путь восстановления, который кто-то действительно испытал.