Agile - В С Е. Сбер технохаб СПб, о перспективе ИИ в РФ

Раньше я был лидером компетенции, я инженер с 19-летним опытом, я с 2007 года — активный разработчик в Сбербанк Онлайн, Сберинвестах, лидировал команды и сам разрабатывал. До этого я лидировал Казанский технохаб и Сбер в Санкт-Петербурге.

Давайте начнем с истории, которую обязательно надо рассказать. Я нашел в интернете такую фотку, она такого спорного качества, но вообще в каждой Agile-презентации должна быть эта фотография, поэтому я чуть-чуть вот так вот уложу. Смотрите, кто на этой картинке. Знаете, что в горах собралось 17 человек — Роберт Мартин, Фаулер и другие — и сказали: «Долой водопад». Слышали про водопадную разработку (Waterfall)? Бюрократия, шаг за шагом, валидировать и так далее, и так далее. Они сказали: «Мы за свободу в разработке, мы еще договоримся, как правила игры должны строиться». И так родился Agile Manifesto.

Есть три важных термина — три кита, на которых всё разрабатывают, и многие не знают, что есть такие конкретные принципы:

1. Ценность нужно доставлять быстро.
2. Команде нужно дать автономию. Помните, у нас Agile-команды — они сами могут принимать решения, как выпустить продукт.
3. Нужно постоянно действовать итеративно. Знаете, как по болоту ходить? Там, здесь, например, потрогали, сделали шаг, назад идем там, где устойчиво.

То есть сама разработка стала дороже, но у водопада есть один большой минус: если в начале ошиблись, то стоимость ошибки становится дороже. И еще есть такой прикол, что можно не угадать: пришли, сделали, а заказчики говорят: «Я платить не буду, сделали всё не так». Agile за счет итераций с работы с бизнесом позволяет от этого уйти, шанс такой ошибки отсутствует, но разработка становится дороже за счет количества итераций.

И четвертый пункт, на самом деле, должен был быть первым: Люди важнее процесса. Люди — я прямо выделил, да, — это самое ключевое.

Но следом появились другие вещи, Agile-книги, Agile-сертификации, то есть, по сути, это уже превратилось в некую индустрию.

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

Главной проблемой становится чрезмерная вязкость модели церемоний: в команде из двадцати человек ежедневные встречи (дейли) могут идти по часу, спринт-планирование занимает четыре часа, ретроспективу также растягивают на четыре часа. И это все приходится поддерживать постоянно, ежедневно или еженедельно, при участии сертифицированных специалистов. В итоге возникает ситуация, когда на выполнение самой задачи по «Agile-церемониям» у команды уходит до 50% рабочего времени. Люди приходят на работу, чтобы «просто пообщаться» о процессах, а не для выполнения конкретных задач. Важно понимать, что в продуктовой команде, согласно манифесту, «люди важнее процессов», но в реальности часто получается наоборот — процессы становятся важнее людей.

В продуктовой команде, где люди важнее процессов, появился новый тренд. Важно обратить внимание на компанию Atlassian, которая сделала Jira — систему, которой многие пользуются. Если посмотреть на показатели, в начале года акции компании упали на 70-74%. При такой просадке в 20% многие компании уже «захолдили» процессы, закрыли найм и полностью переавтоматизируют бизнес. Та же ситуация наблюдается у Monday.com — компании, которая специализируется на Agile-софте. Там зафиксирована просадка по акциям на 75-80%. Это означает, что инвесторы вытащили деньги из этих компаний. Только в марте было выведено 270 миллиардов долларов из подобных софтверных компаний, и у всех у них одна и та же проблема: они продают «места» в компании.

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

Показателен пример Stack Overflow: он практически умер в своем старом виде. Сейчас ресурс запустил новую версию, которая содержит ответы не для людей, а для агентов. То есть агент подключается к Stack Overflow, находит там ранее решенные другими агентами задачи и использует это как базу знаний. Безусловно, Stack Overflow стал для людей бесполезным, потому что все теперь спрашивают у AI — они стали AI-native.

Atlassian, если не успеет до конца этого года стать AI-native, просто не будет иметь денег на трансформацию и на второй путь. Скорее всего, к концу года Jira как таковая умрет, потому что физически SaaS-based экономика больше не работает. На смену приходит экономика, построенная на AI-инфраструктуре, на использовании токенов. Jira умирает не потому, что я хейтер, а потому, что физически в Америке этой модели больше не существует.

Физически в Америке Agile больше нет. В Китае физически Agile тоже больше нет. Из-за того, что у нас в России существует временной лаг от 12 до 18 месяцев, у нас сформировался такой менталитет: если у нас в моменте что-то не случилось, значит, у нас никогда это и не случится. Однако через 12 месяцев нас «накрывает», и мы реагируем эмоционально: «О боже, у нас трансформация, мы не готовы, как так?»

Чтобы вы понимали: так как в Америке компании уже отказались от Agile, а мы в свое время очень качественно скопировали его из США, Китая и Европы, то не будет другого варианта, кроме как скопировать и отказ от Agile. Просто не будет шансов, что мы этого не сделаем. Это произошло, например, в марте. В марте 2027 года в России Agile не будет. Вообще не будет, сто процентов, никакого чуда не случится, потому что в Америке это уже стало реальностью. Назад пути уже нет.

Пытаться продолжать Agile и пробовать поддерживать в этой системе AI-агентов бессмысленно, потому что работа человека совместно с AI-агентом уже не равна классическому Agile. Есть такой нюанс: ты можешь AI-агента с помощью [неясный фрагмент: возможно, упоминание автора технологии или инструмента] и других подходов — например, концепции Dark Factory — загрузить на работу ночью. Представьте: три человека работают днем, а три агента работают ночью. Производительность при этом составляет 200%. Это не заложено в механику модели обычного Agile.

При внедрении искусственного интеллекта в команды разработки возникает важный нюанс. Если разработчику дать инструмент на базе ИИ (агент), он может выполнять задачи в 10 раз быстрее. Однако возникает проблема: если такой инструмент не дать тестировщику, DevOps-инженеру или аналитику, то в условиях Agile, где мы обязаны коммуницировать между собой и распределять нагрузку равномерно, происходит рассинхронизация. Если разработчик сделал свою работу за 5 минут, а тестировщик, не имея соответствующего инструмента, вынужден работать по-старому 3–4 дня, то «узкое горлышко» процесса просто перемещается.

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

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

Нами были проведены замеры, которые показали, что если отказаться от классического Agile и изменить численность команды разработки на 60–80%, можно получить значительный прирост производительности. В США этот подход даже имеет свое название.

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

Агенты стали сильнее, что привело к появлению узких мест в процессах. Если рассматривать привычный состав команды, возникает вопрос: кто «умер»? Классические разработчики и тестировщики изменились. В текущих условиях, согласно рекомендациям McKinsey, на пять разработчиков должен приходиться один тестировщик, но сама структура команды трансформируется, а численность персонала сокращается.

Если рассматривать команду из десяти человек и внедрять интерактивное программирование (или подход Iterative Development), можно увидеть, как сокращается потребность в специалистах. Компенсация нагрузки происходит не за счет людей, а за счет агентов, выполняющих специфические роли.

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

Продуктовый хакер (Product Hacker или Product Builder)

Продуктовый хакер — это специалист, который создает документ, описывающий продукт (обычно файл формата .json, лежащий в корне проекта). В этом документе фиксируется подробное описание того, как сделать телеграм-бота или веб-сайт именно так, как хочет заказчик. Внутри этого документа прописаны требования к качеству, метрики и правила запуска. Специалист задает необходимые вопросы заказчику, формирует документ, объединяющий бизнес-часть и продуктовую часть, на основе которого затем нарезаются задачи для других исполнителей.

Лид-билдер (Lead Builder)

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

Фул-стек билдеры (Full Stack Builders)

В Microsoft этих специалистов называют Full Stack Builders. Они понимают сквозной процесс: у них есть описание продукта, задачи и обязанности.

Взаимодействие ролей выглядит следующим образом:

• Лид-билдер настраивает требования платформы, компании и технические ограничения, чтобы «продуктовый билдер» не тратил время на раздумья о правилах, регламентах и безопасности.
• Продуктовый билдер выполняет задачу, а задача лид-билдера — проконтролировать, чтобы агент выполнил свою работу правильно.

Существует фундаментальная разница между чат-кодингом и агентным подходом в разработке программного обеспечения. При использовании типичного чат-кодинга (например, через редактор Cursor) взаимодействие с моделью чаще всего строится по принципу «одной кнопки»: пользователь дает команду «сделай», и модель, обладая некоторым объемом контекста (например, миллионом токенов), пытается выполнить запрос. Модель самостоятельно выстраивает план работы, проводит анализ, реализует фронтенд-часть или подготавливает данные.

Однако при работе с большими объемами данных, когда контекст превышает критический порог (например, 400 тысяч токенов), у модели начинает «гнить» контекст. Это приводит к тому, что модель забывает исходные требования или суть задачи. Если объем контекста переваливает за 500 тысяч токенов, модель может формально «закрыть» задачу, чтобы просто выдать какой-либо ответ, не решая проблему по существу. Именно поэтому при использовании подхода «чат-кодинга» результат редко получается качественным с первого раза, и часто требуется дополнительные итерации, чтобы исправить сделанное «неправильно».

Альтернативой является агентное кодирование. В рамках этого подхода задача разбивается на части: вы либо делегируете её отдельным агентам, либо создаете отдельные проекты, каждый из которых специализируется на чем-то одном (например, один проект содержит только логику верстки). Важным принципом здесь является изоляция выполнения задач, а также четкая постановка требований и критериев приемки (acceptance criteria).

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

Ключевые принципы Intent Driven Development меняют подход к работе с требованиями. Если раньше в разработке использовали пользовательские истории, то теперь мы определяем намерение — это четкое описание того, что требуется, на передний план выдвигается контекст.

Далее следует подход, который можно обозначить как SDD-подход (Specification Driven Development). В репозитории должны быть полностью описаны спецификации продукта, спецификации вашей платформы, архитектурные требования, требования аналитики и так далее. Это необходимо для того, чтобы агент мог получить всю базу знаний, необходимую для работы. Уменьшение численности команды также снижает нагрузку на коммуникацию, и, естественно, спринты становятся быстрее.

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

Существует также понятие Continuous Planning. Ранее бэклог пересматривали раз в спринт, теперь же мы пересматриваем бэклог раз в день, анализируя, что сделали агенты, а что — люди, и доставляем фичи по мере готовности.

Далее следует принцип Human-on-the-Loop. Это означает, что человека нужно вытаскивать из процесса. Агентная разработка подразумевает, что человека в самом процессе разработки нет, за исключением этапа валидации того, что сделал агент. Если вы что-то много раз пишете, вы находитесь внутри цикла разработки, как Human-in-the-Loop, то есть вы находитесь в обходе, а до сих пор пытаетесь [участвовать].

Роли в IT трансформируются, и важно понимать, какие из них перестают существовать в прежнем виде и во что они меняются. В первую очередь, разработчик становится агентом. Существуют статьи на Habr, описывающие, как за счет взаимодействия с AI-агентом процесс начинает напоминать работу с обычным разработчиком. Ранее вы ставили задачу разработчику, он делал её, вы смотрели, что он что-то сделал «не то», просили переделать, внести правки, например, «покрасить» или «поиграться со шрифтами». Ровно то же самое сейчас происходит при взаимодействии с агентом.

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

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

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

Что касается Product Owner, он становится Product Architect (продуктовым архитектором). Здесь все просто: существует PRD-документ (Product Requirements Document), содержащий все намерения, критерии приемки. Если разработчик или архитектор жестко задал этот документ, описав, как должен выглядеть продукт и как его принять, на основе этих данных генерируются спеки (спецификации) для задач, и, собственно, Product Builder берет это в работу.

Нас всех ждет болезненная трансформация. Это нужно было пройти еще в 2024 году, а сейчас уже 2026. Мы долгое время были догоняющими: не смотрели на опыт Америки, а ждали, когда нам предложат эксперимент, который даст возможность работать по принципу No mistakes, как говорили в Америке в свое время. Это когда перед разработчиками ставили задачу выполнить работу исключительно качественно и с первого раза. Но эта трансформация болезненна, так как мы повторяем те же ошибки и те же грани, что были ранее. Я не понимаю, почему так происходит.

В качестве примера можно привести случай, когда в Facebook обсуждали концепцию token limit (ограничение по токенам). У всех разработчиков стояла метрика: использовать максимум токенов. При этом 90% задач, которые они «кидали» в систему, оценивались по простому принципу: чем больше используешь токенов, тот ты «power user» и молодец. В России происходило то же самое. Но суть в том, что в Америке перешли к другому подходу, когда увидели, чем занимались разработчики: они открывали по 5–10 окон с кодовыми плагинами одновременно. В каждом из этих окон они «нарезали» задачи, писали, что это всё отдельные приложения, чтобы просто «накрутить» токены и показать активность. А «power user» уволить нельзя.

У нас в России, из-за того что задачи ставят с реальными сроками, человек сидит и мониторит 5 открытых окон или какие-то внутренние инструменты — это напоминает экран матрицы. Ты сидишь и мониторишь каждый «геном» (инструмент), становишься «узким» местом, сам при этом не пишешь код, а лишь «выговариваешь» системе принятия решений, как Product Owner или менеджер, но не как технический специалист.

В США этот путь уже прошли, поняли, что он не работает, переформатировали навыки и перешли на реальную эффективность. За счет использования инструментов типа Dark Factory или Harness, один агент, механизм которого расширяется, может выполнять то, что раньше требовало кучи вкладок и кучи приложений. Нам тоже нужно принять, что агент теперь должен быть внутри цикла, мы не должны его контролировать, а «надутые» KPI должны в принципе уйти. Есть еще такая история, которую тоже никто почему-то не замечает, касающаяся навыков: все говорят, что нужно просто добавлять скиллы.

Рассуждая о создании и монетизации коммерческих навыков (скиллов) для ИИ-агентов, стоит отметить важный аспект, на который часто не обращают внимания. Многие говорят, что добавление скиллов радикально улучшает работу больших языковых моделей (LLM), но забывают о самой сути. По сути, скилл в базе — это просто текстовый документ, где описано, что должен делать агент; это обычная инструкция. Однако, если мы возьмем что-то посложнее, например, создание или редактирование презентаций, внутри скилла мы уже увидим полноценную структуру: папку со скриптами, общие скрипты, настройки того, как этот скилл должен работать. Там описана куча программ для парсинга, обработки, генерации и редактирования. Это уже не просто текстовая инструкция, а полноценная программа. Вы можете написать инструкцию, но можете к ней написать и код — а это уже не простая задача.

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

Если посмотреть на маркетплейсы агентов, казалось бы, в чем проблема: создавали, генерировали скиллы, выложили в интернет, люди скачивают — и всё. Но есть нюанс. Если нажать на скилл, созданный человеком, у которого несколько тысяч скачиваний, можно увидеть, что он стоит, например, 100 кредитов. Появились скиллы, которые стоят денег. Я посчитал, что в этих кредитах один автор заработал около 6000 долларов.

Формула успеха выглядит так: скиллы плюс субагенты равно эксперты. И эти «эксперты» могут зарабатывать тысячи долларов. Ваша задача — сделать таких экспертов, которые, например, умеют создавать красивые презентации с дизайном, и эти навыки уже стоят денег. Сейчас скиллы — это, по сути, новое золото. Субагенты, упакованные скиллами, стоят денег. Это прямые аналоги экспертов, которые могут помочь бизнесу. Вы можете назначать цену: 1000 кредитов, 2000 кредитов. То есть, если вы научитесь создавать коммерческие скиллы, вы «позолотитесь». У OpenCore (OpenClaw) появилось достаточно много механизмов и «мастерских» по созданию этих скиллов.

Представьте ситуацию: есть руководитель ресторана, у которого много работы, и ему нужен ассистент, который поможет справляться с задачами и масштабироваться. Он ищет работника за 50 тысяч рублей уже два года, но бизнесу нужно расти и все успевать. Он берет, скачивает OpenClaw, наращивает 50–60 скиллов, и они реально начинают ему помогать, закрывая задачи и снимая всю рутину. Когда этот руководитель приходит к другому директору и говорит, что у него есть набор скиллов, которые реально помогают расти, он может продать их, скажем, за миллион рублей. Потом он еще два месяца накопит 60–80 скиллов и скажет: «Обновление за 500 тысяч». Такое решение можно продать каждому, тем самым улучшая бизнес, потому что бизнес растет, когда есть инструменты (или люди), которые могут выполнять работу за небольшие деньги.

Сегодня существуют инструменты, позволяющие за небольшую стоимость выполнять значительный объем работы. Существует паттерн Chain of Thought, который позволяет строить полноценные компании из ИИ-агентов. По факту, вы создаете «села» (вероятно, имелось в виду «целое» или «бизнес-единицу»), подключаете агенту специальные навыки (скиллы), определяете ему миссию и конкретную задачу, выделяете бюджет, и он начинает нанимать других агентов, формируя отчетность для директора.

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

В любом вопросе, касающемся внедрения технологий, неизбежно встает экономический аспект. Актуален вопрос: как сегодня распределяются расходы на искусственный интеллект? Всем известно, что крупные компании тратят колоссальные средства — сжигают сотни миллионов долларов — на развитие этой сферы. В любом случае, работа вычислительных мощностей и потребление электроэнергии требуют значительных денег. Как именно будет реализовано финансирование в текущих реалиях — это вопрос, который может быть вынесен даже на экзамен.

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

Однако здесь возникает критический вопрос: как быть с аппаратной составляющей («железом»)? Компаний, которые производят современные мощные чипы, не так много, а лидер рынка — Nvidia — за последний год совершила огромный скачок в своем развитии. У нас своего производства чипов практически нет, в основном их изготавливают на Тайване. В связи с этим остро стоит проблема внедрения ИИ-технологий в условиях отсутствия собственного производства аппаратного обеспечения.

Начнем с того, что OpenAI и Anthropic — это просто стартапы. Для того чтобы стоить триллион, как они подали заявку на IPO, они с каждого угла заявляли, что OpenAI — это круто, чтобы получить инвесторов. Например, у OpenAI курочка (капитализация) 10-15 миллиардов, а обязательства они набрали на триллион четыреста. Они скинули 40, это их обязательства на 800 миллиардов. Возникает закономерный вопрос: где они взяли эти деньги? Сейчас они конкурируют с Anthropic. Можно сказать, что для снижения стоимости на IPO и для того, чтобы побольше инвесторов перетекло в OpenAI, их оценочная стоимость достигла триллиона долларов. Когда они зарабатывают триллион, можно расплатить свои обязательства перед инвесторами. Компания становится публичной, и из-за того, что она публичная, её нельзя скрывать, её жестко можно отчитывать. Как только OpenAI станет публичной, всё, что вкладывалось в рынок, в один капитал, это всё уйдет на стоимость покупки, и вся эта стратегия с дешевыми ценами изменится.

Я могу привести пример: Minimax предлагает 1,7 миллиарда токенов за 20 долларов. Если взять подписку GPT-4, GPT-4 Pro, то я высчитывал, что вместо 20 долларов за 1,7 миллиарда токенов пришлось бы отдать порядка 9 миллионов рублей. То есть там разница в цене просто жесткая. И это всё пройдет, потому что бизнес не будет работать на переплате.

Но в Китае есть нюанс: он субсидирует 70-80 процентов развития искусственного интеллекта в стране. За счет этого 30-40 процентов всех стартапов с AI-моделями вынуждены снижать цены, иначе они потеряют долю рынка и вообще никогда не окупятся. В данный момент их покупают только на разработку, можно не думать про окупаемость, можно делать через дотации. Поэтому сейчас основная задача — сделать железо, электричество, всё это «затосовывать».

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

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

Вопрос о том, замедлится ли развитие технологий из-за перехода на импортозамещение, не имеет однозначно негативного ответа. Компания уже давно отвязалась от зависимости исключительно от GigaChat: используются различные модели, как кодовые, так и аналитические. В компании применяют современный инструментарий, и это никак не блокирует развитие. Отсутствует так называемый «proprietary lock-in» (привязка к проприетарному программному обеспечению конкретного вендора). В организации понимают, что технологии развиваются с разной скоростью, и это не должно становиться «узким горлышком» для трансформации. Более того, наличие собственной индустриальной базы и вычислительных мощностей, в частности суперкомпьютеров, позволяет компании разворачивать полноценные LLM (Large Language Models) самостоятельно. Это дает возможность использовать защищенные и open-source решения внутри собственного контура.

За счет использования специальной обвязки можно оптимизировать затраты ресурсов системы. Например, если вы используете стеллы (stills) и загружаете их в процесс, срабатывает кэш контекста. Если одна и та же последовательность токенов или данных (тот самый «стелл») повторяется, она сохраняется в кэше. Благодаря этому не расходуются лишние токены и не создается избыточная нагрузка на железо, что позволяет работать эффективнее. Грубо говоря, вы формируете определенный workflow, решаете задачу и в конце фиксируете этот процесс как «стелл» — то есть сохраняете состояние, которое затем будет находиться в кэше и использоваться повторно.

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

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