Joker-2026
Выступление на сайте конференции 

Весна этого года принесла переход от использования ИИ-агентов в качестве ИИ-помощников к встраиванию их в пайплайн обработки задач в конкретных ролях и созданию гибридной команды (agentic engineering). При этом инженеры пробуют реализовать давние мечты об идеальном процессе разработки без принципиального изменения подходов. Это породило концепции Spec Driven Development и AI-Disrupt-PDLC от Сбера. Однако ИИ-агенты обладают уникальными особенностями: с одной стороны – знания любых языков и технологий и способность быстрого обучения за счет описания компетенций, инструкций и передачи контекста, с другой – склонность фантазировать, выдавать поверхностные и ложные ответы. Поэтому встройка ИИ-агента – задача повышенной сложности.

Кроме того, возможность быстрого вайбкодинга прототипов и ускорение этапа написания кода во много раз, для некоторых задач – на порядок, а также существенные отличия агентов от людей по компетенциям, требует принципиально новой сборки процесса разработки в целом. Поэтому есть смысл подняться на теоретический уровень, посмотреть концепции разделение труда Адама Смита, Петра Щедровицкого, принципы бережливого производства (Lean), а также на сложившиеся практики изменения организации работы команды и выделения в ИТ в переломные периоды: появление персоналок, приход web-разработки и мобильных приложений. Это позволяет ориентироваться при планировании экспериментов, а не вести их вслепую.

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

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

1. SDD – это старый известный водопад. Его не получилось реализовать на людях, и теперь попытались сделать на агентах.
   1. Не работает по тем же причинам: агенты делают не то и не так, в ответ идет наращивание подробностей в спецификации, как делают аналитики при разборках с разработчиками о том, кто виноват, в результате спецификация быстро становится не читаемой и не проверяемой. Причины известны с 1990-х.
   2. Третья – спецификацию невозможно обсуждать с бизнесом, он ее не понимает.
   3. Проверка спецификации по характеру работы сильно отличается от написания кода, это – другая компетенция. Когда разработчикам это навязывают, теряется мотивация.
2. Есть ограниченный класс задач, которые решаются хорошо – когда есть типовые решения: сайт-визитка, типовой интернет-магазин, типовой документооборот, типовая CRM небольшого бизнеса. Раньше делали платформу с точками расширения, теперь можно сделать harness для скелета решения и чек-лист для проверки спецификации.
3. Есть способы несколько облегчить проблемы SDD.
   1. Возложить проверку на ИИ, а разработчики пусть пишут чек-лист и архитектурные принципы.
   2. Проверяем не спецификацию, а точки принятия решений, в которых ИИ делал выбор из альтернатив – это ближе и проще.
   3. В спецификации пишем не способ решения, а краткую архитектуру и набор тест-кейсов – это получается не SDD, а TDD/BDD, хотя формат OpenSpec это позволяет.
4. Можно работать через прототипы. Тем более, что бизнес сам с удовольствием вайбкодит прототипы. Правда, он потом требует их поставить в прод, а разработка не может понятно объяснить, почему не может это сделать. Это направление точно будет развиваться. При этом описание архитектуры, тест-кейсы и другая документация таким приложениям нужны, но может появляться позже, по мере того, как прототип стабилизируется.
5. Но вот сделать harness-платформу, на которой бизнес будет вайбкодить все, что ему нужно, как предлагает Disrupt-PDCL от Сбера – точно не получится, как 25 лет назад не получилось обеспечить разработку приложений за счет создания CASE-средств. Причины – те же, платформа не обеспечит сложные случаи, для которых нужна совместная работа бизнеса и разработчиков над поиском решений, приемлемых по сложности и решающих проблемы бизнеса. Надо уметь включать в эту команду ИИ-агентов.
6. ИИ-агенты хорошо делают частные задачи. При этом процесс разработки расщепляется на более мелкие операции. Это уже было – когда вместо программиста появилась команда из аналитика, разработчика и тестировщика, а позднее веб-мастер превратился в дизайнера и фронт-разработчика. И есть обратные процессы, когда специализации объединяются – как было с кроссфункциональными командами вместо отделов и происходит сейчас с tiny-team. Можно использовать те же схемы для проектирования процесса, в презентации у меня была схема Акта деятельности из СМД-методологии, поверх которой нарисовано конкретное разделение труда.
7. Важно помнить, что недостаточно разделить на операции, необходимо обеспечить компетенцию исполнителей, снабдить их знаниями. Даже когда это ИИ-агенты. Это – вертикальное измерение разделения труда. Если у вас агент проверяет архитектуру или качество кода по чек-листу, то надо поверх запускать HADI-цикл, в котором ведется мониторинг текущего качества, выявляются проблемные типы задач и решаются доработкой harness. Об этом забывают, не ставят доработку harness как процесс. При этом можно перераспределять задачи между ИИ и человеком: ставишь ИИ-агента, который делит задачи на простые и сложные по каким-то критериям, простые отдает ИИ (их может быть несколько с разными моделями), а сложные – человеку. И поверх – мониторинг и совершенствование.
8. В целом тут большое поле деятельности, ИИ-агенты сейчас позволяют сделать то, до чего не доходили руки: покрыть тестами, актуализировать документацию, написать скрипты, чтобы создавать тестовые стенды на основе боевых и так далее.
9. ИИ меняет не только разработку, но и бизнес. Если гипотеза проверяется за 3-5 дней вместо 2-3 месяцев, надо перестраивать весь процесс и роль ИТ в нем. Раньше бизнес говорил: «куча идей, разработка не успевает», теперь вопрос к качеству идей. Работа владельца продукта стала новым ограничением.
10. Внедрять ИИ по площади бессмысленно. Теория ограничений Голдратта говорит: ускорение в конкретном месте только тогда дает бизнес-эффект, когда это место является ограничением для бизнеса. Внедрение по площади приводит к тому, что ИИ в точках ограничений появляется позднее, чем в других местах – там операционка зашкаливает. Поэтому проекты массового внедрения ИИ не дают бизнес-эффекта. Правильный подход – фокусировка: пилоты для апробирования, точечные внедрения в критических участках с ожидаемым результатом, и лишь затем – распространение. Распространять – необходимо: ИИ – инфраструктура, как электричество или интернет: освоить необходимо, применять надо там, где уместно. ИИ не даст конкурентного преимущества, потому что будет у всех.
11. Работа с ИИ дает лог работы сотрудника, подробнее, чем таск-трекер. Это можно использовать для анализа и совершенствования работы. Хотя понятно, что сначала попробуют использовать для контроля. Это пока практически не прорабатывается, а по сути тут – тоже HADI-цикл.
12. И в заключении была пара слайдов про те изменения, которые ИИ принесет в жизнь – когда у каждого из нас будут свои ИИ-помощники, организующие жизнь. И роботы – Китай активно работает в эту сторону, в том числе снижая стоимость, да и у нас разработки ведутся, на конференции было выступление Сбера с впечатляющими результатами.

Скачать весь pdf