# Как строится устойчивая к ИИ карьера в разработке

> Устойчивая к ИИ карьера строится на ответственности за решения, ограничения и продакшен, а не на написании кода, который уже создают агенты.

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

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

Много лет я видел, как инженерные организации нанимали людей ради косвенных признаков результата: закрытых задач, story points, pull request и знания фреймворков. Из-за агентов такие показатели дешевеют и хуже отражают реальную пользу. Основателям стоит перестроить роли вокруг результатов. Инженерам стоит строить карьеру вокруг тех частей результата, где ошибка по-прежнему дорого обходится.

## Защита карьеры находится выше генерации кода

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

Часто специальности сравнивают по тому, способен ли агент написать фронтенд-код, Terraform, SQL или модель угроз. Это неверный уровень анализа. В каждой специальности есть разные задачи, и модели осваивают их с разной скоростью. Полезное сравнение опирается на четыре параметра:

- Насколько полно задачу можно описать до начала работы?
- Насколько быстро и дешево машина может проверить результат?
- Сколько закрытого внутреннего контекста требуется для хорошего решения?
- Насколько дорогой и необратимой окажется ошибка?

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

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

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

## Первой дешевеет ограниченная реализация

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

В 2025 году Anthropic проанализировала 500 000 диалогов о программировании для Economic Index и обнаружила, что взаимодействие с Claude Code в основном было автоматизацией, а веб-языки и задачи с пользовательским интерфейсом встречались особенно часто. Отчет не доказал, что рабочие места во фронтенде исчезнут. Он показал, какие задачи пользователи уже готовы полностью делегировать, и простые клиентские приложения оказались под заметным давлением.

Больше всего рискует исполнитель тикетов. Такой человек получает уже принятое требование, работает по известному шаблону и считает задачу завершенной, когда pull request проходит готовые проверки. Агентства, которые продают взаимозаменяемые лендинги, простые интеграции или перенос между фреймворками, столкнутся с ценовым давлением, потому что один сильный инженер сможет контролировать гораздо больший объем. Внутренние команды начнут спрашивать, зачем пять человек передвигают почти одинаковые карточки по доске.

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

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

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

## Рост числа изменений усиливает платформенных инженеров

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

Исследование DORA за 2025 год называет ИИ усилителем окружающей его организации. В AI Capabilities Model лучшие результаты связаны с небольшими порциями работы, хорошей дисциплиной контроля версий, ориентацией на пользователя, доступными внутренними данными и качественной внутренней платформой. Я согласен с идеей усилителя, но для карьеры ее стоит сформулировать жестче: организация без подготовленных путей поставки платит интеграционный налог за каждую дополнительную строку, созданную агентом.

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

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

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

## Безопасность переходит от ревью к устройству системы

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

Агентная разработка расширяет поверхность атаки вполне конкретно: в одном сеансе модель может читать недоверенный текст, хранить учетные данные, вызывать инструменты, менять файлы и запускать внешние действия. OWASP Top 10 for Agentic Applications разделяет перехват цели, неправильное использование инструментов, злоупотребление идентификаторами, риски цепочки поставок, неожиданное выполнение кода и отравление памяти. Эта классификация важна, потому что команда не исправит такие проблемы обычным улучшением промптов. Контроль должен находиться в архитектуре и эксплуатации.

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

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

Secure Software Development Framework от NIST рассматривает безопасность как часть жизненного цикла разработки, а не как финальную проверку. С агентами эта позиция становится еще полезнее. Объем сгенерированного кода снижает надежность ручного ревью, поэтому политики в коде, происхождение артефактов, изоляция секретов и воспроизводимые доказательства входят в основную инженерную работу. Специалисты по безопасности, которые умеют строить такие механизмы, не останутся без дела.

## Ответственность за надежность все труднее изображать

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

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

Специалистам по надежности стоит ожидать исчезновения рутинного выполнения runbook. Если реакцию можно описать словами «когда сработает оповещение A, запусти команду B, сравни метрику C и перезапусти D», агент, скорее всего, выполнит ее в рамках политики. Карьерная возможность состоит в том, чтобы превратить неформальные знания о восстановлении в безопасную автоматизацию, а внимание людей оставить новым или опасным состояниям.

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

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

## Продуктовое мышление отделяет инженеров от исполнителей

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

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

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

Здесь есть ловушка для так называемых full-stack-универсалов. Широта помогает, только если позволяет замкнуть цикл результата. Поверхностное знание шести фреймворков стало менее полезным, потому что у агента уже есть широкий запас сведений. Устойчивый универсал достаточно хорошо связывает поведение клиентов, устройство приложения, данные, развертывание и экономику, чтобы принять цельное решение.

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

## В инфраструктуре данных и ИИ ценится знание границ

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

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

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

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

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

## Ценность архитектуры создают ограничения

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

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

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

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

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

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

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

## Роли начинающих меняются, но лестница должна сохраниться

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

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

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

Полезная последовательность ученичества выглядит так:

1. Воспроизвести дефект и написать падающий тест до обращения к агенту за исправлением.
2. Провести ревью сгенерированного агентом патча и найти одно скрытое допущение или пропущенный случай.
3. Выпустить небольшое изменение с телеметрией и планом отката.
4. Отвечать за один сервис во время учебного или настоящего инцидента под наблюдением наставника.
5. Записать решение, связывающее потребность клиента с техническим компромиссом.

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

## Оценивайте задачи, а не названия должностей

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

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

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

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

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

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

Рандомизированное исследование METR с опытными разработчиками открытого ПО хорошо предостерегает от примитивной оценки. В испытании начала 2025 года 16 разработчиков выполнили 246 задач в хорошо знакомых репозиториях и с проверенными инструментами ИИ потратили на 19 процентов больше времени, хотя ожидали ускорения. Результат не доказывает, что агенты всегда снижают продуктивность. Он показывает, что знакомство с репозиторием, сложность задачи, неудобство инструмента и стоимость ревью могут перевесить скорость генерации. Измеряйте полный цикл в своей среде.

## Стройте карьеру вокруг более широкого цикла результата

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

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

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

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

Team & AI Audit в oleg.is разбирает такую работу на уровне задач и циклов поставки, а затем определяет, где меньшая команда с ИИ может ответственно обеспечить тот же результат. Цель не в том, чтобы объявить специальность безопасной. Нужно перестроить работу до того, как ценовое давление и уход сотрудников перестроят ее за вас.

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