8 июня 2026 года InfoQ выпустил подкаст с Birgitta Böckeler, Distinguished Engineer в Thoughtworks, о том, как AI-разработка за один год успела сменить и инструменты, и уровень риска. Если в 2025-м все обсуждали vibe coding и быстрые прототипы, то теперь разговор сместился к более автономным агентам, которым уже недостаточно просто «дать промпт и посмотреть, что выйдет». Для русскоязычной IT-аудитории это важный сдвиг: ставка теперь не на вау-эффект от генерации кода, а на то, как встроить AI-разработку в реальную инженерную практику без лишнего героизма.
Как пишет InfoQ, Böckeler вернулась к теме спустя примерно год после предыдущего разговора и зафиксировала довольно резкую смену акцентов. Тогда в центре внимания были так называемые agentic modes, которые еще не тянули на полноценных агентов, и свежий термин vibe coding, появившийся буквально за пару месяцев до той дискуссии. По ее словам, в тот момент одним из главных ориентиров на рынке был Cursor, а Claude Code еще не занял столь заметное место в публичной повестке. Сейчас картина иная: терминальные агенты стали мейнстримом, CLI-режимы появились у крупных игроков, а сама конкуренция идет уже не вокруг автодополнения, а вокруг того, насколько далеко системе можно делегировать работу.
Отдельно Böckeler разбирает спор, который за пределами инженерных команд выглядит почти религиозным: терминал против IDE. Ее позиция довольно трезвая. Популярность Claude Code, по ее мнению, не сводится к тому, что разработчикам внезапно захотелось жить в терминале. Скорее дело в том, что инструмент хорошо работает «под капотом», а интерфейс выбирается по задаче. Терминальные агенты удобны там, где нужен headless-сценарий: пайплайны, фоновое выполнение, автоматизация без визуального слоя. IDE-инструменты вроде Cursor выигрывают в другом: когда нужно наблюдать за действиями агента, разбирать сложную логику, откатываться к предыдущему состоянию диалога или просто дебажить не вслепую. Для команд это хороший сигнал: не стоит объявлять один формат «правильным». Скорее всего, в зрелой AI-разработке будут сосуществовать оба режима.
Еще один заметный разворот касается работы с контекстом. Год назад одним из самых обсуждаемых механизмов были MCP-серверы, но за это время, по словам Böckeler, энтузиазм вокруг них заметно остыл: команды на практике столкнулись с ограничениями подхода. Вместо попытки затолкать все знание о проекте в один жирный контекст или монолитный файл рынок двинулся к более экономной схеме. Контекст все чаще подают порциями через lazy-loaded skills, CLI-утилиты и специализированные скрипты. Логика здесь простая и довольно земная: окно контекста не резиновое, а автономность агента зависит не только от мощности модели, но и от того, насколько аккуратно ей выдают нужную информацию. Если перевести это на язык повседневной разработки, речь идет о нормальной инженерной дисциплине: договоренности, явная архитектура, понятные инструменты и минимум магии в стиле «агент сам разберется».
Самый интересный тезис подкаста — переход от разговора про скорость к разговору про страховку. Böckeler использует для этого термин harness engineering. Идея в том, что автономному агенту нужен «страховочный контур», который не просто ограничивает его, а помогает работать лучше с меньшим участием человека. В этот контур входят два класса механизмов. Первый — feed forward: соглашения, архитектурный контекст, локальные правила и инструменты, которые заранее направляют агента в нужную сторону. Второй — feedback: статический анализ, результаты тестов и другие сигналы, по которым система может скорректировать собственные действия. То есть речь не о волшебной кнопке «пусть ИИ пишет код сам», а о попытке собрать среду, где агент умеет ошибаться дешевле и исправляться быстрее.
Это важный поворот для бизнеса и техлидов, потому что рост автономности почти автоматически поднимает ставку ошибки. Böckeler прямо говорит: больше скорости — значит и больше риска. Поэтому supervision, то есть степень человеческого контроля, нельзя выбирать по настроению или по моде на очередной AI-инструмент. Она предлагает смотреть минимум на три вещи: какова вероятность, что система вообще справится с задачей; насколько критичны последствия провала; и насколько легко заметить ошибку. В сущности, это уже не разговор о «нравится ли команде агент», а о нормальной модели управления риском. Для внутренних скриптов и рутинных задач можно позволить больше свободы. Для критичного продакшн-кода, безопасности или инфраструктуры цена эксперимента быстро становится слишком высокой.
На этом фоне особенно показательно, как быстро меняется само определение продуктивности. Еще недавно рынок был увлечен «вибовым» программированием: быстро нагенерировать куски, сшить их вместе, показать демо, а дальше разберемся. В каком-то смысле это действительно напоминало ускоренную версию копипаста, только без прыжков между браузером и IDE. Но по мере того как AI-разработка начала просачиваться в реальные процессы поставки ПО, стало ясно, что одной скорости мало. Если агент производит много кода, который потом требует дорогостоящей ручной проверки, исправлений и расследований, выигрыш выглядит уже не так впечатляюще. Отсюда и смещение фокуса: не «сколько строк сгенерировали», а «какой объем работы удалось передать системе без потери управляемости».
Для российских разработчиков, продактов и IT-руководителей из этого следует довольно практичный вывод. Выигрывать будут не те команды, которые первыми включили модный агент, а те, кто сумел обвязать его правилами, тестами, архитектурным контекстом и понятной зоной ответственности. Иначе AI-разработка быстро превращается в дорогой аттракцион: демо получается бодрое, а в поставке и сопровождении начинается знакомый цирк с расследованием побочных эффектов. Судя по рассуждениям Böckeler, отрасль все еще находится в стадии формирования. Главный вопрос уже не в том, могут ли агенты писать код, а в том, насколько аккуратно компании научатся проектировать среду, в которой этим агентам можно доверить что-то важнее красивого прототипа.