Командам приходится убираться за собой после того, как сгенерированный искусственным интеллектом код, который выглядел хорошо, не сработал под давлением, пишет на портале The New Stack Таммуз Дубнов, основатель и технический директор AutonomyAI.

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

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

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

Вайб-кодинг доставляет удовольствие — до поры до времени

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

И все работает — до тех пор, пока не перестает.

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

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

Это не редкость — это предсказуемый результат приоритета скорости без структуры.

«Сдвиг влево» в сторону вайб-инжиниринга

Решение заключается не в отказе от ИИ. Нужно изменить то, как мы его используем.

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

Вместо того чтобы предлагать «написать функцию выставления счетов», разработчики направляют ИИ: «Расширьте существующую логику processInvoice() для поддержки уровней, основанных на использовании. Используйте formatCurrency() из utils. Примените те же проверки доступа, что и в subscriptions.ts».

Теперь ИИ не работает на фрилансе. Он работает в рамках границ, с контекстом и ответственностью.

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

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

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

Меняющаяся роль разработчика: от автора к оркестратору

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

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

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

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

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

3. Ориентируйте ИИ на повторное использование — и проактивное улучшение. Направляйте ИИ на актуальные и чистые части вашей кодовой базы, исключая унаследованный или устаревший код. Явно указывайте на компоненты, полезные функции и сервисы, которые можно использовать повторно. Цель состоит в том, чтобы развивать кодовую базу, опираясь на самые прочные основы, и поддерживать принципы DRY (не повторяйтесь). В то время как некоторые платформы могут обнаруживать эти возможности повторного использования автоматически, другие требуют контекста, определяемого разработчиком. В любом случае от ваших указаний зависит, укрепит или разрушит агент систему.

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

  • Определите, какие части кодовой базы являются «источником истины» для общей логики — и активно ссылайтесь на них в подсказках, не заставляйте ИИ просто догадываться.
  • Попросите ИИ предлагать улучшения при повторном использовании кода: «Если эта утилита кажется устаревшей или имеет пробелы, рефакторьте ее для согласованности с X».

4. Применяйте практики, которые раскрывают недосказанное для достижения истинного согласования. Воспользуйтесь разработкой через тестирование (TDD). Теперь, когда ИИ может генерировать тесты с минимальным трением, вы должны по умолчанию использовать рабочие процессы, ориентированные на тесты. Речь идет не только о том, чтобы отлавливать ошибки постфактум, но и о выявлении несоответствий еще до начала реализации. Попросив ИИ сначала написать тесты на основе ваших намерений, вы выявите любые предположения, противоречия или нечеткую логику на ранней стадии процесса.

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

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

5. Следите за развитием кодовой базы. Используйте инструменты ИИ, которые обобщают запросы на изменения (PR) и отслеживают развитие кода. Активно изучайте эти сводки. Агенты всегда в курсе всех изменений, а люди — нет. Вам нужно вкладывать усилия в поддержание архитектурной осведомленности, особенно когда ИИ ускоряет разработку. Понимание того, что меняется в системе, очень важно для принятия обоснованных решений и предотвращения дрейфа.

  • Подпишитесь на сводки объединенных PR и выделите немного времени для их ежедневного изучения, оно того стоит.

Эти методы определяют современного оркестратора ПО: тот, кто мыслит системно, определяет намерения, использует ИИ в качестве сотрудника, а не просто производителя кода, и строит с перспективой на будущее.