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

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

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

Концепция разделения труда

Тема разделения труда в экономике пошла с Адама Смита. Он там приводит пример из французской энциклопедии Дидро и Даламбера: один ремесленник делает до 20 булавок для шляпы в день, но если разделить процесс на 18 операций в цепочке, то 10 человек делают 48 тысяч булавок – в 240 раз больше на одного человека. В Энциклопедии – множество разных примеров описания технологий, Адам Смит из них взял один, и сказал «это – самое главное».

Если расширить рамку, то получается следующее: мы можем поделить сложный процесс на операции, для каждой – выработать технологичные приемы, и тем самым повысить производительность труда, а еще – снизить затраты за счет того, что часть операций – простые, для их выполнения не требуется высокой квалификации исполнителя. И этот подход используется повсеместно. Если мы перенесемся в современность и посмотрим на историю ИТ-отрасли, то 30+ лет назад там программы разрабатывали программисты, никаких специализаций не было. Хотя этапы разработки уже были выделены, это сделал еще Ройс в статье 1970 года, где описал концепцию водопада. Правда, смысл статьи был в том, что «так не работает», потому что на последующих этапах будут вскрываться проблемы, которые не учли при проектировании в силу технической сложности отрасли. Однако, пока этим занимался один человек, программист, он мог на этапе проектирования «заглянуть вперед», и часть проблем снять. А вот когда в 1980-е и позднее попробовали устроить реальное разделение труда с выделением гейтов и специализаций, то проблема проектирования решений, которые оказываются чрезмерно сложными и потому дорогими в реализации, многократно возросла. Развитие шло в несколько этапов, последний из них – RUP (2003), в котором специализаций было очень много. Но это оно не взлетело, хотя из него и вырос PMBOK. Как ответ – появился Scrum и другие Agile-методы, которые ставят на кроссфункциональную команду, а, главное, активно применяют ревью специалистами и другие формы коллективной работы на разных стадиях.

Теперь важный момент: почему оно не взлетело, и что именно должно было взлететь? Тут мы подходим к вопросу, а как создать эффективное разделение труда? Если посмотреть на тот пример из Энциклопедии, то там не прояснен важный вопрос: кто придумал именно такое разделение на операции, при этом еще и распределил их между людьми (18 операций, а человек – 10), так что получился описанный эффект. В статье этого нет, там просто описан конкретный способ работы, а не история его возникновения. А именно это имеет принципиальное значение, из-за которого одни способы организации бизнес-процессов взлетают и дают эффект, а другие – нет.

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

В СМД-методологии для описания разделения труда была разработана схема акта деятельности, представленная на рисунке. Внизу схемы – преобразование исходного материала в конечный продукт, разложенный на отдельные операции-действия с использованием орудий, машин, инструментов и других средств, а в верхней половине – организатор этого процесса, который проектирует этот процесс на табло сознания, последовательно переходя от целей к проблемам и задачам решения и опираясь на свои ценности, способности и внутренние средства, а также на знания. Это – пунктиром, хороший рассказ этой схемы с разворачиванием от тройки (Цель – Объект – Средства) есть в лекции Петра Георгиевича Щедровицкого в МИСИС, которая доступна в виде статьи в html и в pdf, а видео: на vk и youtube.

Но там – объяснение самой схемы. А вот как именно конструировать систему разделения труда в производстве было фокусом науки управления очень давно, в 1930-е годы. На ПИР-2025 Аркадий Цукер рассказывал хороший ретроспективный анализ – чему были посвящены учебники управления в разные годы. Если кому интересно – у меня есть конспект. И поэтому вертикальную систему труда обычно не видят: люди берут готовые методики, не задумываясь о том, откуда они появились.

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

Отмечу, что не все было сделано в 1930-е. В 1950-е в Японии был еще один подход – система Тойоты, которая была осмыслена на Западе в 1990-х и появился Lean – концепция бережливого производства. В ней была концепция цепочек создания ценности, в рамках которой все операции поделили на добавляющие ценность и пустые, и выделен отдельный процесс оптимизации за счет сокращения числа операций, которые не дают ценность. В 2003 Lean был перенесен в разработку софта, то есть на процессы умственного труда, где отличаются типы лишней работы.

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

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

Разделение труда в современном ИТ

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

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

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

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

Разделение труда в разработке связано с технологиями, которые обуславливают, что задачу должно выполнять несколько разработчиков, владеющих разными технологиями, например, фронт и бэк-разработчик. Отметим, что разделение технологий далеко не всегда влечет разделение одной задачи. Например, интерфейс могут делать в технологии naked objects, когда его работа полностью определяется тем, что поставляет сервер. Эта технология может применяться не только в браузере, но и в клиентском приложении, и тогда содержательное решение задачи остается за разработчиком бэка, а фронт просто делает платформу, реализующую naked objects. Однако, платформа – это сложно, чаще ограничиваются фреймворками типа Vue или React, а с ними разделение задачи на несколько сохраняется.

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

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

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

ИИ требует перестройки системы разделения труда

Что же происходит сейчас, с использованием ИИ в процессе разработки? Первым этапом было использование ИИ как личного помощника, повышающего скорость работы отдельного сотрудника – вайбкодинг, если говорить о разработке кода. Система разделения труда при этом изменялась слабо, хотя и возникали дисбалансы, из-за того, что одни задачи ускорялись сильнее других. А вот теперь – следующий этап, использование ИИ-агентов – agentic engineering. Это возможно в двух существенно разных подходах: в одном случае мы просто выделяем определенные типы задач, иногда очень узкие, например, контроль орфографии или соблюдение style guide для кода, а иногда и более масштабные, вплоть до попыток полностью заменить человека в какой-то роли, и поручаем их ИИ-агенту, встраивая его работу в общий конвейер обработки задачи. В другом случае мы пользуемся тем, что ИИ может не только делать определенную работу, но и критиковать сделанное другими, и устраиваем внутренний цикл взаимодействия между несколькими ИИ-агентами: один пишет, другой – критикует, после чего первый дорабатывает.

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

Кстати, в выступлениях о встройке ИИ-агентов я зафиксировал еще и смену терминологии: если раньше было принято говорить про workflow обработки задачи, то теперь говорят про pipelline. Термин пришел из devops, где он используется для конвейера поставки, но распространен на весь путь от начального вброса идеи, потому что с появлением ИИ-агентов в любом месте могут появляться автоматизированные шаги или фрагменты процесса.

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

Компетенции ИИ-агента

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

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

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

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

О надежности результата

Отдельное внимание надо обратить на обеспечение надежности результата, получаемого от ИИ-агентов. Для начала надо преодолеть желание получить абсолютную надежность. Казалось бы, что тут преодолевать? Ведь ясно, что ни от какого сотрудника, тем более новичка, абсолютной надежности ожидать не приходится. Однако, в публичном инфополе тема абсолютной надежности активно присутствует еще с начала 2010-х, когда IBM создал Watson – систему, способную вести коммуникацию на уровне человека и профессионально обсуждать вопросы. Профессиональные лобби почувствовали опасность, и попробовали закрыть доступ, отказавшись признавать его равным человеку, несмотря на сдачу квалификационных экзаменов. А потом еще свалили на него вину за неверные решения консилиумов или советы, хотя окончательные решения были за людьми-профи. Потом тему унаследовали, когда обсуждали роботакси, а сейчас она применяется к ИИ-агентам.

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

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

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

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

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

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

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

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

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

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

Включаем ИИ в рабочий процесс

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

Первое. Выделяем фрагмент пайплайна работы над задачей, на котором мы предполагаем использовать ИИ-агента. Как легко догадаться, для этого сам пайплайн должен быть предварительно нарисован, но в большинстве случаев с этим нет проблемы – можно использовать путь задачи в таск-трекере.

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

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

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

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

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

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

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

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

Например, если вы начинаете использовать ИИ-агента для первичного контроля технического описания протокола API, которое ранее делали разработчики, а проверяли и публиковали, встраивая в весь массив документации, технические писатели, то интересно именно общее время выполнения и трудоемкость фрагмента пайплайн. Формально пайплайн не упрощается, а усложняется: между шагами по написанию документации разработчиком и проверкой с дальнейшей публикацией техническим писателем, появляется новый шаг – проверка ИИ-агентом. Спрашивается, зачем это делать? Эффект – многофакторный. Во-первых, может снижаться время проверки техническим писателем, который может не фокусироваться на тех проблемах, которые ИИ хорошо ловит, например, на проверке формального соответствия между описания и спецификации или выполнения style guide. Во-вторых, результат проверки ИИ-агентом разработчик получает немедленно, а не отложено, когда технический писатель доберется до задачи. Тут эффект аналогичен выполнению системы автотестов сразу после commit вместо ежедневного прогона: разработчик не переключается на другую задачу и ему не надо вспоминать контекст, поэтому исправления он внесет быстрее. Есть исследования, что переключения контекста могут занимать 10-20 минут и более. И так далее.

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

Тут непростая конструкция. Очень давно известен «эффект отладки»: если сборка проекта и тест идет сложно, то разработчик внимательнее смотрит код до запуска, проверяет сначала глазами, а если проверка быстрая, то начинается запуск «по живому», в глупой надежде, что очередная ошибка точно будет последней и все полетит. Здесь мы будем ловить тот же самый эффект, и не только на прохождении ревью от ИИ, но и на выполнение задач создания кода, документов или диаграмм самим ИИ. Когда мы ставим задачу новичку, мы понимаем, что он принесет результат не мгновенно, и объясняем с учетом этого. А ИИ-агент выдает результат мгновенно. Стоит ли думать заранее, или можно отдать ему сырую задачу?

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

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

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

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

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

Еще одна важная составляющая – эффективная коммуникация между агентами и человеком, и также агентов между собой. Например, если ставить агенту задачу «проверь и улучши документ (или код) по такому-то чек-листу», то на выходе получается новая редакция, где наряду с конкретными замечаниями изменено много другого, при этом возможны искажения смысла. Поэтому реальный способ: сделать список замечаний, желательно с указаниями конкретного места в тексте, потом по каждому замечанию предложить исправления как список изменений, потом их оценить и принять. В этом случае все логи сохраняются, логика изменений понятна и проверяема. На начальном этапе акцепт замечания и изменения смотрит человек, дальше это возлагается на агентов.

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

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

Пятое. Мониторинг и совершенствование. А далее наступает период эксплуатации, когда мы наблюдаем за текущим процессом и его совершенствуем. Здесь надо понимать, что любое совершенствование – эксперимент, проверка гипотезы. И выигрыш на одних типах задач вполне может дать провал на других. Поэтому в процесс стоит встраивать возможности для организации A/B тестирования, когда новому варианту ИИ-агента направляются не все задачи, а лишь некоторые. Кроме того, в отличие от реального процесса, мы можем легко размножить поток, направив одну задачу сразу нескольким версиям агента и сравнив результат. Оценку результата тоже можно возлагать на ИИ-агентов, однако, часть оценок точно будут давать люди.

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

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

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

Для совершенствования регламентов рабочего процесса тоже можно использовать ИИ. Он разбирается в организации процессов, ему можно ставить задачи на анализ по логам, просить проанализировать чек-листы, промпты и инструкции и предложить усовершенствования. При этом ему свойственны те же ошибки, что и человеку. За деталями я тут отошлю к опыту Анатолия Левенчука, который с февраля строит мультиагентскую систему для развития First Principle Framework (FPF) – описание системного подхода для ИИ. Анатолий плотно документирует свою работу, и в этом посте – описание устройства мультиагентной схемы. Здесь – про старт работы и первый подход к организации. А вот это – очень интересный пост, где Анатолий описывает типичные ошибки агентов, которые надо учитывать в ходе работы. Они – те же самые, что свойственны человеческим командам. Например, стремление создать много регламентов так, что большая часть токенов начинает уходить на административную, а не на содержательную работу, или упрощение задачи так, что теряется суть, и так далее. Это уже не просто обобщенное описание «ИИ-агент – новичок, не знающий контекста вашего проекта», ИИ-агент получает понятные поведенческие характеристики, которые надо учитывать при построении процесса.

Кейсы – обзор выступлений

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

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

И я понимаю, что список устаревает, тем более, что я участвую не во всех конференциях. Я уверен, что на AnalystDays, ЛАФ и Saint Highload будут новые выступления, тем более, что Highload на днях приоткрыл прием заявок именно на эту тему.

SQAdays осень 2025 (мой конспект), на ней речь шла о создании агентов без встройки в процесс. Видео и презентации – на сайте конференции.

Иван Степнов. Автоматизация регресса без стресса: от классики и BDD до ИИ-агентов под контролем QA. – агент, который берет тест-кейс для UI E2E тестирования, написанный на естественном языке, и превращает его в автотест. Агента используют ручные тестировщики, тут пока не дошло до включения в pipeline.
Vadim Nikitenko. Генерация автотестов с помощью MCP + LLM – про конструирование агента, создающего автотесты и интегрированного в контекст разработки.

Highload осень 2025 (мой конспект). В начале конспекта – мое обобщение опыта ИИ-агентов. Презентации – на сайте конференции, видео – для купивших.

Николай Пономаренко из Яндекса. GPT в службе поддержки: автоматизация, оптимизация и инновации – включение ИИ-агентов в службу поддержки Яндекса.
Вячеслав Кудряшов из Сбера. Как сохранить высокую надежность при GenAI-трансформации – создание инфраструктуры для ИИ-агентов, включенных в рабочий процесс

ArchDays осень 2025 (мой конспект), видео выступлений youtube, VK-video.

Александр Войновский и Олег Зоткин из Газпром нефть. Эффективная архитектура ИИ для цифровизации производства. Это не про разработку, а про архитектуру ИТ-ландшафта, в которую активно включены ИИ-агенты.
Руслан Серкин из МТС Web Services. Архитектор и ИИ: Управляем старым техдолгом и создаем новый. Как видно из названия, речь шла про использование ИИ-агента для работы с архитектурой и техдолгом.

Teamlead осень 2025 (мой конспект)

Алексей Рахманов из FUN&SUN. AI на службе техлида – рассказ про разнообразные эксперименты по использованию ИИ, которые принесли такой результат, что это уже правильно рассматривать не как эксперименты, а как изменения рабочего процесса. Например, у них получилось с помощью ИИ за неделю сделать MVP сложного проекта с множеством легаси-интеграций.

AnalystDays осень 2025 (мой конспект)

Дмитрий Безуглый. От техписа к архитектору: ренессанс системного аналитика. В выступлении не рассказ об опыте, а попытка осмысления – как ИТ-отрасль реструктурируется с массовым переходом на ИИ-агентов.
Дарья Рассказова. Как с помощью ИИ провести обследование и сбор требований в новой предметной области. Включение ИИ-агента в рабочий процесс подготовки требований для проектов на 1С.
Елизавета Французяк из Гринатом. От идеи до эффекта: как аналитики превращают гипотезы в ИИ-продукты. Это рассказ о проектах внедрения ИИ-агентов в рабочие процессы заказчика через последовательное создание прототипов вместо традиционного водопада.
Еще я слушал выступления Reydan Yasar и Анны Гуровой, но они были о возможностях ИИ-агента, а не о его встройке в процессы.

TechWriterDays-2026 (мой конспект) Важный урок выступлений: не давать агенту переписывать, а просить предложить изменения – тогда можно нормально проверить.

Камила Мазаева из Альфа-Банк. Кому доверить ревью API — техпису или искусственному интеллекту – о выносе части задачи по ревью описания API с технического писателя на ИИ-агента. У них в компании описание делают разработчики, а технические писатели далее делают ревью оформляют и публикуют. И внедрение агента прошло полный цикл: определили компетенции и встроили в процесс как промежуточный этап, сократив время первичной обратной связи и уменьшив число итераций подготовки описания.
Александр Яковлев. Масштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex Cloud – рассказ о том, как делали агента, помогающего писать документацию, и об архитектуре конструкции агента – тем, что лежит между системным промптом и промптом, который пишет пользователь, и снабжает агента необходимым контекстом для эффективного применения в рамках конкретного проекта.
Никита Авилов. Сам себе редактор: ИИ для вычитки текста и локализации – об использовании ИИ для вычитки текстов и локализации: агенту недостаточно просто передать текст на вычитку, пусть даже с промптом, для адекватной работы ему нужен контекст, который относится к документу.

Merge-2026 (мой конспект)

Круглый стол секции маркетинга: Вайбкодинг для всех: вымрут ли разработчики как динозавры. На круглом столе про встраивание в процессы было немного. Самое главное – был взгляд на разработку со стороны заказчика. Они очень устали от того, что ИТ работает медленно и от него сложно доиться результата. Вайбкодинг позволяет заказчику для большого количества задач обойтись без разработчиков, и собравшиеся делились практическим опытом. При этом у них ИИ решает задачи быстрее и качественнее, чем разработчики, за меньшее количество итераций. Для части задач потом отдают на ревью разработчиком, для других – обходятся без этого. Для сложных задач ИИ работает под руководством сеньора, и проект, который аутсорс-команда делала за год теперь один сеньор делает за пару месяцев.
Просто кейс. На круглом столе по ИИ у аналитиков один из участников, владелец аутсорсиговой компании, сказал, что он сильно сократил разработчиков: из 10 проектов они остались только на двух, а остальные 8 вайбкодят аналитики вместе с ним самим – он ставит процесс, разбирается с граблями и учит аналитиков их обходить.
Игорь Рыбаков. Как мы перестраивали работу аналитика с AI – рассказ о включении ИИ-агента в работу аналитика. Одно из достижений – смерирование будущего проекта под тендер они успешно делают тандемом аналитика и ИИ-агента, раньше это была гораздо более сложная задача. И кликабельные прототипы тоже успешно делают.
Сергей Бурцев. ИИ убьёт видеопродакшен? Мы проверили — и наняли вдвое больше людей – это не про разработку, компания Сергея создает видео. ИИ тут сильно расширил рынок для компании и снизил трудоемкость. Стоимость видео для корпораций не уменьшилась, но ИИ позволяет делать то, что раньше было невозможно, так как требовало больших затрат. И сделал рынок глобальным – компания начала успешно работать на английском рынке без нативных актеров.
Андрей Бровко из Авито. Spec driven AI. Как обеспечить качество? Рассказ про pipeline разработки с участием ИИ-агентов и человека в Авито, включая фреймворки, использованные для ее организации.

AIconf-2026 (мой конспект).

Основные впечатления были не на выступлениях, а из обсуждений в кулуарах. Из них ясно, что отношение к копилотам окончательно изменилось: их использование – обязательно. Правда, это среди руководителей разработки и активно интересующихся технологиями, а что касается основной массы разработчиков, то ситуация, как с любыми новыми технологиями: энтузиастов 10-15%, остальных надо драйвить. В компании до 150 человек драйв можно передать передается за счет того, что люди друг друга знают и активные объединяются, специальной организации не требуется, и достаточно поддерживать процесс, и то когда их разработчиков 1500 и более, то уже надо специально организовывать пилотные зоны и демонстрировать в них эффективность другим. И это меняет требования к разработчикам: они должны уметь работать с копилотом. Правда, в описание компетенции это пока не преобразовано. Впрочем, это – достаточно общая вещь про soft skill компетенции, что такое «хорошая коммуникация» тоже раскрывают редко.
Панель «От хайпа к прибыли – встройка ИИ в продукт» – подтверждает впечатления в целом: там где раньше была нужна команда 20 бэков и 10 фронтов, теперь достаточно 2-3 разработчиков, руководящих агентами – идет переход от вайбкодинг к agentic engineering.
Дарья Шатько. Как мы внедрили LLM-судей в автоматизациях клиентского сервиса: подход, грабли, уроки – внедрение ИИ-агентов в работу службы поддержки, с многоуровневой системой оценки качества и выявления проблемных мест – мониторинг системы с ИИ-агентами на этапе эксплуатации и развития.

SQAdays весна 2026 (мой конспект)

Александр Ткачев. No-code/Low-code в тестировании: ускоряем процессы с помощью n8n. Встройка ИИ в процессы потребовала большего уровня их формализации: доски уже недостаточно, нужны системы типа n8n.
Ариадна Букатина из Райффайзен. AI для коробочного решения – использование ИИ-агентов для тестирования коробочного решения: генерация тестовых данных, загрузка данных через API на Lua вместо UI (решена без знания Lua), агенты для написания автотестов и анализа результатов.

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

Об организации труда ИИ-агентов