AI-агент может сэкономить часы работы. А может за те же часы аккуратно переписать лишние файлы, сломать тесты и уверенно объяснить, что «так было лучше». Поэтому главный навык сейчас — не просто просить агента сделать задачу, а уметь ставить ему рамки.
В прошлых заметках я уже писал про то, как я пришел к вайбкодингу и что AI реально даёт разработчику в 2026 году. Если коротко: инструмент стал мощным, быстрым и местами пугающе самостоятельным. Он умеет читать проект, менять файлы, запускать команды, чинить свои же ошибки и идти по циклу до результата.
Звучит удобно. И это действительно удобно. Но чем больше свободы получает агент, тем сильнее меняется роль человека. Раньше мы в основном проверяли сгенерированный кусок кода. Теперь нужно проверять ещё и саму траекторию: куда агент полез, какие решения принял, что посчитал «очевидным» и какие допущения спрятал внутри изменений.
Я всё чаще думаю об AI-агенте не как о волшебном автопилоте, а как о очень быстром исполнителе без полного контекста. Он может сделать много полезного, если задача хорошо ограничена. Но если сказать ему «приведи проект в порядок», он может понять это слишком буквально.
Почему рамки важнее промпта
Промптинг часто продают как главный навык работы с AI. Отчасти это правда: если плохо поставить задачу, результат будет случайным. Но с агентами одного красивого промпта уже мало.
Обычная LLM в чате ошиблась — ты получил плохой текст или кусок кода. Неприятно, но обычно не страшно. Агент с доступом к проекту ошибся — он уже может изменить файлы, удалить временно важный код, переписать форматирование, запустить не ту команду или потратить час на решение проблемы, которую никто не просил решать.
Поэтому вопрос не только в том, что попросить. Вопрос ещё и в том, что агенту можно делать, куда ему можно смотреть и где он обязан остановиться и спросить.
Для меня хорошая постановка задачи агенту состоит из трёх частей:
цель: какой результат нужен;
границы: какие файлы, команды и решения допустимы;
проверка: как мы поймём, что задача действительно выполнена.
Если одной из частей нет, агент начинает достраивать её сам. Иногда удачно. Иногда так, что потом сидишь и разбираешь diff'ы с лёгким внутренним вопросом: «А зачем ты вообще это трогал?»
Плохая задача звучит слишком широко
Самый опасный формат запроса — что-то вроде «улучши», «оптимизируй», «почини всё», «сделай красиво», «приведи к best practices». Для человека это тоже неидеальная постановка, но человек хотя бы немного, но может понять социальный контекст и не надо переписывать полпроекта без спроса.
AI-агент такого здравого смысла не имеет. Он будет искать работу. И, что особенно забавно, почти всегда её найдёт.
Например, просишь поправить баг в форме, а агент заодно меняет структуру компонента, переименовывает переменные, трогает стили, обновляет пару соседних утилит и радостно сообщает, что код стал чище. Возможно, стал. Но задача была не в этом. Теперь ревью сложнее, риск выше, а реальная причина бага потерялась среди косметики.
Хорошая задача звучит скучнее, зато безопаснее:
Нужно исправить баг с пустым email в форме регистрации. Меняй только файлы, связанные с этой формой и её валидацией. Не меняй стили и общие утилиты без отдельного согласования. Сначала найди причину, потом предложи короткий план, после этого внеси правку и запусти релевантные тесты.
В таком запросе меньше магии, зато больше управляемости. Агент понимает не только цель, но и коридор движения.
Что стоит проговаривать явно
Я заметил простое правило: если что-то кажется очевидным человеку, это как раз стоит написать агенту явно. Особенно если цена ошибки высока.
1. Что нельзя трогать
Запреты иногда важнее инструкций. Если в проекте есть миграции, конфиги деплоя, сгенерированные файлы, секреты, схемы базы или хрупкие legacy-модули, лучше сказать об этом заранее.
Не «аккуратно поправь проект», а «не меняй схемы, миграции, env-файлы и CI-конфиги». Это звучит избыточно, пока агент однажды не решит, что для маленькой задачи ему нужно «немного обновить структуру базы».
2. Какой масштаб изменений допустим
Иногда нужен хирургический фикс. Иногда можно спокойно рефакторить. Агент не угадает это сам.
Если задача маленькая, я прямо пишу: «минимальный diff», «без рефакторинга», «не меняй публичный API», «не форматируй соседние файлы». Если задача исследовательская, наоборот, можно дать больше свободы: «предложи варианты, но ничего не меняй без согласования».
3. Когда нужно остановиться
Это особенно полезно для сложных задач. Агент может уйти в длинный цикл: чинит одно, ломает другое, потом чинит второе, случайно ломает третье. В какой-то момент он уже не решает задачу, а обслуживает собственные последствия.
Хорошая рамка: «если после двух попыток тесты всё ещё падают, остановись и покажи гипотезы». Или: «если нужно менять больше трёх файлов, сначала согласуй план». Это не бюрократия. Это защита от бесконтрольного расползания задачи.
4. Чем подтверждать результат
Фраза «сделай, чтобы работало» слишком расплывчата. Лучше заранее указать проверку: конкретный тест, сценарий, линтер, сборка, ручной чек, воспроизведение бага.
Агенту полезно дать не только задачу, но и финишную черту. Иначе он может остановиться там, где код выглядит правдоподобно, но не там, где проблема действительно решена.
Мой базовый шаблон запроса
Когда задача не совсем тривиальная, я обычно формулирую её примерно так:
Нужно сделать [цель]. Сначала изучи [область проекта] и коротко опиши причину/подход. Не меняй [запретные зоны]. Держи изменения в рамках [масштаб]. Если потребуется более широкий рефакторинг, остановись и спроси. После изменений проверь [команда или сценарий] и кратко объясни, что изменилось.
Это не универсальная формула, но она хорошо дисциплинирует. В ней есть цель, контекст, ограничения, стоп-сигналы и проверка. Даже если агент ошибётся, вероятность большой самодеятельности становится ниже.
Для маленьких задач можно короче:
Исправь только эту ошибку. Минимальный diff. Не трогай соседний код. После правки запусти релевантный тест или объясни, почему его нельзя запустить.
На первый взгляд это выглядит слишком строго. Но на практике такие рамки экономят время и агенту, и человеку на ревью.
Агент должен объяснять свои допущения
Одна из лучших привычек — просить агента сначала назвать допущения. Не писать код сразу, а сказать: «я понял задачу так-то, предполагаю вот это, риски такие-то».
Это особенно важно в задачах, где есть неоднозначность: экспорт данных, авторизация, миграции, платежи, тестовые данные, нагрузочное тестирование, работа с пользовательским вводом. Там ошибка часто появляется не в коде, а на уровне неправильно понятой задачи.
Если агент сразу бросается в реализацию, он может выбрать первый правдоподобный путь. А потом ты обнаружишь, что он экспортировал не те поля, сделал синхронную операцию вместо фоновой, не учёл объём данных или решил, что email не считается чувствительной информацией.
Поэтому простой вопрос «какие допущения ты делаешь?» иногда полезнее, чем ещё пять строк промпта.
Не надо принимать diff на доверии
Самая соблазнительная кнопка в AI-разработке — принять всё. Особенно когда агент пишет уверенно, тесты зелёные, а diff выглядит не слишком страшно. Но именно здесь легко пропустить лишнее.
Я стараюсь смотреть diff не как формальность, а как отдельный этап работы. И задаю себе несколько вопросов:
каждая изменённая строка относится к задаче?
не поменялся ли публичный контракт?
нет ли «улучшений», которые никто не просил?
понятно ли, почему тесты должны защищать именно этот сценарий?
смогу ли я объяснить это изменение?
Если на последний вопрос ответ «ну агент так сделал» — это плохой знак. После принятия diff это уже не код агента. Это мой код.
Где агентам можно дать больше свободы
При всём этом я не считаю, что AI-агентов нужно держать на коротком поводке всегда. Есть задачи, где им можно и нужно давать простор.
Например, черновые исследования, поиск по проекту, первичный анализ логов, генерация вариантов, подготовка документации, набросок тестовых данных, локальные прототипы. Там цена ошибки ниже, а польза от скорости большая.
Но чем ближе задача к данным, инфраструктуре, безопасности, деньгам и публичным контрактам, тем жёстче должны быть рамки. Это нормальная инженерная логика. Мы же не даём junior-разработчику сразу доступ к production-базе со словами «посмотри, что можно улучшить».
Главный вывод
AI-агент — это не просто более умный autocomplete. Это исполнитель, которому мы всё чаще даём инструменты. А инструменты без правил превращаются в источник случайности.
Поэтому хороший инженерный навык в 2026 году — уметь не только писать код и не только промптить. Нужно уметь проектировать безопасный рабочий коридор для AI: поставить цель, обозначить границы, заранее определить проверку и вовремя остановить процесс, если он уехал не туда.
Мне нравится работать с агентами. Они реально ускоряют рутину, помогают быстрее разбираться в коде и иногда приятно удивляют качеством решений. Но я не хочу, чтобы агент был «главным инженером» в моём проекте. Пусть он будет быстрым напарником. А за руль всё равно лучше садиться человеку.
Практический чеклист
Сформулируй цель одной фразой.
Укажи область проекта, где можно работать.
Явно напиши, какие файлы и решения нельзя трогать.
Определи допустимый масштаб изменений.
Попроси сначала назвать допущения или план, если задача неоднозначная.
Задай стоп-условие: когда агент должен остановиться и спросить.
Укажи проверку результата.
Перед принятием diff проверь, что каждое изменение относится к задаче.
В итоге всё сводится к простой мысли: AI-агенту можно доверять работу, но нельзя отдавать ответственность. Ответственность всё ещё наша.
Обсуждение
Комментариев пока нет — начните тему.