AI Native Conf: освоение ИИ продолжается

Во вторник 20.10 был на конференции AI Native Conf – это уже третья конференция ontico в этом году, посвященная AI. В апреле был AI conf (мой отчет), в июле прошел Agentic Dev Conf, и сейчас – снова сфокусированная конференция. Это не удивительно – ИИ сильно меняет и разработку софта и мир в целом, и сейчас идет процесс интенсивных изменений. На открытие конференции Олег Бунин сказал, что происходящее напоминает ему 2007 год, когда массовое распространение интернета тоже сильно меняло мир и породило интенсивную разработку. Тогда появился новый сегмент public web, технологии которого сейчас уже стали мейнстримом. А в кулуарах я слышал мнение, что появление ИИ даже круче, его сравнивали с появлением персональных компьютеров. О масштабах можно спорить, но изменения реально значительные.

Общие впечатления: корпорации – это не фронтир, но они движутся

Теперь о содержании конференции. Много выступлений крупных корпораций: Сбер, Райффайзен и другие. Я уже писал в отчете с Saint Highload, что крупные корпорации не дают фронтира отрасли, и эта конференция подтверждает мой тезис. Корпорации зажаты корпоративной организацией, и потому пытаются внедрить ИИ, не меняя процессы, а главное – не меняя устоявшуюся организационную границу между ИТ и бизнесом. Именно поэтому там так популярно SDD, которая является очередной инкарнацией водопада: его не получилось сделать на людях – так сделаем на ИИ-агентах! И концепт Disrupt PDCL от Сбера – тоже инкарнация старой идеи CASE-средства: пусть бизнес сам вайбкодит свои приложения, а мы сделаем для этого платформу. Помимо разработки, постепенно осваивается область discovery, но тоже в логике обеспечения платформы, с помощью которой бизнесе сможет решать эти задачи. Речи об изменении процессов – не идет, хотя мантра о том, что «процессы будут меняться» – звучит.

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

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

На мой взгляд, все эти проблемы корпораций носят системный характер, я об этом полторы недели назад рассказывал на Joker в Питере. На AInative, кстати, это выступление не взяли – и я вполне понимаю, что оно было бы неуместно на этой конференции. Я это обсуждал в кулуарах, мне возражали, что корпорации иначе не могут, потому что когда у тебя 290 тысяч сотрудников, то даже пилот на 1% – это уже 3000 пользователей, инфраструктуру не собрать «на коленке». Этот фактор, конечно, есть. Но это все равно не повод делать понятное в той области, где необходимо новое. И начинать бороться за косты там, где пока надо обеспечить результативность, которую пока даже не поняли, как измерять. При том, что затраты на ИИ-разработку все равно реально много меньше зарплат разработчиков.

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

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

А еще было интересное выступление Никиты Худова. Он рассказывал о том, как два сооснователя компании за три месяца навайбкодили и запустили новый продукт, что обошлось в 100-300 тысяч вместо 6-8 млн, а когда пошли первые продажи – создали для продукта компанию поддержки и развития, в которой агентов тоже больше, чем людей.

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

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

Олег Бартунов. Архитектура данных будущего: что такое данные в эпоху ИИ

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

Postgres – везде, это совершенная oltp-машина. Microsoft купил команды специалистов, и не только он. Значит все придут за данными в postgres, точка правды – там. Все хотят olap + oltp вместе. Postgres хорошо расширяем, но в ядре изменений нет – потому что очень большая цена ошибки. И это – проблема, 19 релиз отложили на несколько месяцев – потому что много багов. А багов много не потому, что они вдруг появились. Просто ИИ превратился в хороший микроскоп, он видит гораздо больше багов, чем раньше видел челвоек. И ревьюеры сейчас их лечат.

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

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

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

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

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

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

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

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

Нам надо общаться. Мы оффлоадим себя, компрессия. Наблюдение – жесты – речь – письменность – числа – формулы – алгоритм – программа – бит. И дальше в обратную сторону, возвращаем возможности, учим БИТ передавать смыслы: интернет – данные – программы – ИИ – исследовать – намерение (не отдаем).

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

Зачем мы отдаем наши мозги агенту? Мы хотим, чтобы деятели выросли созидателями, а не потребителями. Чтобы наша цивилизация продолжалась, чтобы мы передавали знания дальше. Мы учились друг у друга. Теперь появляется умная машина. Будет еще умнее. Что нас ждет в будущем?

Лейбниц – двоичная запись, Буль логика, Шенон – реле компьютеры и бит – способ измерения и передачи информации. Данные – различия, зафиксированные наблюдателем в определенном контексте. Данные → информация → знание (модель) → новый вопрос (сравнение модели с наблюдением) → новые данные.

Сейчас делает ranked GIN – BM25 и top-K – чтобы выполнять запросы агентов. Делает с агентами. Но так, чтобы владеть кодом.

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

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

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

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

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

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

Сергей Рябов Сбер. AI Native трансформация

В выступлении – рассказ о направлениях деятельности Сбера по AI-трансформации. Мне в нем не хватило конкретики. Представьте себе, что выступает бегун, который позиционирует себя как одного из лидеров. Но он не рассказывает о своих достижениях, он рассказывает, какие рекорды показывают чемпионы на международных соревнованиях, и какими методами тренируется о сам. Так и здесь, в выступлении – ссылки на материалы OpenAI, отчеты Гартнера и МакКинзи, и слова о том, что Сбер движется, развивая клиентский сервис, enterprise-платформу, улучшая модели, включая GigaChat и GigaCode. Но без конкретных достижений и маркеров продвижения.

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

Ну а теперь – конспект выступления.

OpenAI говорит, что ИИ решает 80% задач. И тут было еще несколько ссылок на на Гартнера и МакКинзи. Рождается агентная экономика – взаимодействие между компаниями через своих агентов, и к этому надо готовиться, потому что механики бренди и лояльности будут работать меньше.

Я тут отмечу, что есть картина будущего, в которой они не просто будут будут работать меньше, а умрут, потому что агенты не будут искать информацию в интернете обычным образом, попадая на рекламу, а будут обращаться к базам данных реального клиентского опыта, данные в которые сами и будут поставлять, наблюдая за реальным использованием продуктов в жизни своих хозяев. Об этом есть интересные выступления у Гарретта Джонстона (мои конспекты: Живая компания-2025 (там есть ссылки на запись), ПИР-2024, ПИР-2025, ПИР-2026). Впрочем, пока этого нет, а вот услуги по GEO-оптимизации как новый этап после SEO – уже появилось. В любом случае, тема агентной экономики дальше в выступлении не проявлялась.

Направления работ Сбера.

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

• Агентная платформа – enterprise harness – переиспользуемые агенты всеми командами. skills, tools, LLM-модели…

• ИТ-контур: все, что связано с информационными системами. Взаимодействие, когда будет доступно.

В портфеле 1600+ AI-инициатив на 1000 команд. GigaVoice – оператор, система принятия решений, включая управление рисками и финансы, рекомендательные системы, которые вышли за пределы ML. И важно не чуть-чуть улучшить существующие процессы, а переизобрести элементы: не нужно поддерживать старые функции, надо построить новое.

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

Дальше речь шла о платформе. Создают Harness, улучшают и компенсируют проблемы моделей, обеспечивают переиспользование – enterprise harness. А также FinOps для GenAI решений – динамический роутинг запросов и расчет затрат. Это как раз та забота об эффективности до того, как достигли результативности. Потому что результативность внедрения ИИ не измеряется, в вопросах об этом спрашивали ответ был, что это – дело команд, а наше дело – предоставить им платформу и взять за услуги.

Агентский цикл, оркестрация – GigaAgent и Enterprise Harness. Они смотрят на мировые банки, включая китайские страховые и банки. Управление контекстом и навыками. Команды выводят продукты в каналы – skill hub, фреймворк создания и эволюции навыков. Среда безопасного создания агентов, риски, безопасные ограничения – guardrails. GenAI Lifecycle 360. Идентификаторы, трейсинг. Автономные проверки безопасности, рисков, надежности. И есть отдельное направление рисков GenAI. Посмотрели решения рынка, и сгруппировали в направления.

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

Дмитрий Антипов. Конкуренция в эпоху дизрапта PDLC: какие продукты мы будем создавать?

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

А теперь – про выступление подробнее.

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

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

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

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

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

На каждый доллар софта будет 6$ услуг. SalesForce – экспериментируют с ценами. Выкатили 4 типа цены и не откатили ни один: за пользователя, за объем, за действия, за решенное обращение – никто не понимает, как правильно. С моей точки зрения, это – логичная ситуация, потому что все покупатели – в разных ситуациях и потому готовы по-разному платить. Никто же не удивляется многообразию тарифных планов у телеком-операторов.

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

Есть стандартное, и ИИ начинает с ней конкурировать – с софтом, с сотрудниками, из инструмента становится чем-то большим. Процессы выстроены – отчеты, звонки, переписки, за них платят (несут затраты), но технологии готовы заменить. Все целиком – не переделаешь. Заменяешь кубики. Можно ли все – вопрос. Нужна платформа inference, grafana. ИИ не полезет туда, где нужна ответственность – не понятно, как ее передавать. Я тут замечу, что с человеком тоже непонятно, если он накосячил, нанес убыток – его, конечно, можно уволить, но редко больше. Так и ИИ можно уволить, отписаться от этой модели, нанять другую.

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

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

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

Я бы так на это не смотрел. Даже до эпохи ИИ корпорации запросто погибали – есть много статей о том, сколько из тех, кто входил в индекс SP-500 или SP-100 20 или 50 лет назад живут сейчас. Очень мало. Пока игра идет на поле услуг и легкой промышленности: Uber и Яндекс возят пассажиров без парка автомобилей, booking и airbnb размещают путешественников без помещений, Temu закрыло собой 20 тысяч мелких швейных фабрик и дизайнеров, при этом у них от успешной идеи новой модели до выпуска проходит 5-7 дней, а при успехе – обеспечивается масштабирование. Да, есть инфраструктура, как РЖД – она останется объективно. А про все остальное – вопрос организационно-политический и как именно повлияет ИИ – не ясно. А что до конкуренции, то Тинькофф послужил сильнейшим драйвером банковской отрасли России как раз тем, что небольшой банк создал реальную конкуренцию корпорациям. Ну и сейчас неплохо работает.

Шиномонтажки – мы выберем ту, которая рядом. И минисофт становится рентабельным, хотя никогда не станет единорогом. Отличная модель, чтобы строить то, что нужно. Код – дешевый, остальное – дороже. Интерфейс может пересобираться под человека. Но нужна надежная платформа, много 9. Discovery ускоряется. Но менять интерфейс каждый день – пользователи этого не любят, будет снижаться любовь к приложению. Эксперимент на два дня – ничего не даст. Софт привязан к физическому миру – доставка, обучение – процесс длиться долго. Часть софта невидима. Купи кроссовки – система пошла, поискала, поторговалась – дала варианты. Меньше экранов – не значит что много софта. Часть процесса – за кадром, но не значит, что его не делают. Часть программ – для агентов, не только для людей. Софта больше, но видеть будем меньше. Будет расти автоматизация за результат, будет развиваться маленький софт, будет расти платформы и инфраструктура. Софт будет разным – несколько рынков.

И в конце – таблица смены эпох.

• Мейнфреймы дали железо

• ПК дали стандарты и форматы, железо уже commodity

• Облако дали данные и процессы

• Мобилки дали дистрибуцию функционала

• ИИ – функциональность становится commodity, а что будет преимуществом – пока неясно.

Сергей Паращенко. Когда Delivery перестаёт быть узким местом: агентная архитектура продуктовой работы

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

Хотя Сергей сказал, что некоторый вариант harness для решения задачи у них сделан. А они – консультанты. Так что идея выступления может быть в другом: задача – сложная, не пытайтесь сделать самостоятельно, а идите за готовым решением. Но характеристики решения при этом не предъявлены, заявлена лишь сложность задачи. Впрочем, могу ошибаться.

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

Есть попытки ответа. AI disrupt PDLC. Петля намерения: что делаем, для кого делаем и зачем. А потом – реализация, это решено. Цикл: возможность → гипотеза, сделать ее smart → решение: дорабатываем или реинжиниринг → агенты или copilot → проверка шаблонов → валидация человеком.

Как агенты поймут, что discovery успешно?

• Цикл верификации проблем – там много проверок. Есть точка принятия решения: размер клиентского сегмента достаточен и богат, или нет?

• Дальше – цикл верификации решения, как закрываем рыночную потребность. Решает ли решение проблему клиента, выгодно ли нам как бизнесу такое решение создавать?

Итак, есть рыночный сигнал (тренды, клиенты в поддержке, конкуренты куда-то пошли или выпустили и так далее). Дальше – гипотезы о проблеме, потом гипотезы о решении. Сигнал → Наблюдение → Интерпретация → Гипотеза → Эксперимент → Решение → Передача в реализацию. Впрочем, отмечу, что прототип реализации может быть быстрее и дешевле исследования, тут тоже ветвление.

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

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

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

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

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

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

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

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

Никита Худов. Агенты как часть штата с первого дня: роли, найм и управление при запуске продукта

Это история о том, как два основателя компании strategai навайбкодили с помощью агентов отдельный спинофф – Geo-оптимизацию и успешно запустили как продукт. История, на мой взгляд, очень характерна для нашего времени, как сказал один из участников круглого стола по вайбкодингу на Merge-2026: «Легче сделать за выходные самому, чем две недели объяснять команде разработки, что ты хочешь. Агент – он лучше понимает и не сопротивляется, когда просишь исправить». Впрочем, у Никита указывал на другие основания: идея – актуальная, но вся команда занята, отвлекать они не хотели. Самое ценное в выступлении – оценка эффекта: подобная разработка стоила бы 6-8 млн, а они вывели продукт меньше, чем за 3 месяца, и обошлось это в 100-300 тысяч – то есть многократно меньше. По оценке большой разброс, так как сложно оценить часы, которые они потратили (40-80), а также стоимость использованной инфраструктуры компании.

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

А теперь – подробности.

Кто такой агент в контексте выступления? Это не закреленный чат, не проект в LLM и не разовый коворк-агент или их рой. Агент – работает автономно и проактивно и выполняет какую-то функцию. В идеале агент отчуждаем от сотрудника, который его создал. МакКинзи говорит, что на 40к сотрудников будет 25к агентов.

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

Исследовательская работа заняла 2 месяца, и это упиралась во время человека – разобраться в том, что выдают агенты. Когда решение было приняло то разработка первого mvp заняло неделю, и еще две недели – первые продажи. Итого чуть меньше 3 месяцев – b2b. В b2c быстрее. Стоимость – гораздо дешевле человека. Подобная работа стоила 6-8 млн, а сейчас 100-300 тр (в них 40-80 часов основателей).

Продукт – доступен. Как они убедились в качестве? Есть процесс качества – проверка на скорость и много других параметров. Так что есть уверенность, что 10 клиентов mvp обслужат. 100 – нет, но для mvp 10 достаточно, а по результатам – все равно дорабатывать.

Раз продукт взлетел – надо сопровождать и развивать. И они начали выстраивать процессы компании, которая будет этим заниматься. Попытка по-максимуму использовать ИИ, а людей – только там, где ИИ не справится. В компании 5 человек: аутрич-менеджер, geo-менеджер, BizDev, Разработчик, CTO-консльтант. И добавилось еще 3 агента – smm, sales-ассистент и кто-то еще. Инфраструктура: база знаний, над ней – модель, сверху подключены все системы через интеграции: таск-трекер, amoCRM, GooleDocs и таблицы, запись встреч – все в общем контуре знаний, smm-агент и sales-ассистент с этим работают. Они думают, что такого штата компании хватит на 10-12 первых клиентов.

Были косяки. Агенты косячат, люди тоже.

• Расхождения в отчетах. geo-отчет – сложная штука, много промптов через разные llm и много статистической обработки – пришлось вычищать.

• Веб-поиск. Когда спрашиваешь LLM, она иногда идет в поиск, иногда – не идет. Оказалось моделька часто в поиск не идет, пришлось исследовать.

• Генерация промптов. Есть клиент, надо сделать аналитику – надо по названию клиента сгенерить промпты. Иногда генератор включает название бренда – а это не корректно.

• Получилось ограничение 5-7 параллельных компаний для статистики – над этим начали работать проактивно, но уже после продаж mvp.

Уроки.

• Workflow: Цель и критерии → задание с контекстом → результат → проверка человеком. У каждого агента – свой список прав и свой бюджет.

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

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

• Оценка токенов. Когда агента спрашиваешь – он выдает оценки для человека, а не для себя. Как тогда планировать? Надо обучать на собственном опыте. ADR – все решения фиксируем в документах: решили то. И если там добавить, сколько времени и токенов ушло на задачи – и по ним агенты хорошо оценивают будущие задачи.

Что не с работало?

• Агенты без ролей. Агентам нужна иерархия и оркестрация, плоская структура работает плохо, приводит к неэффктивности.

• Один большой файл правил – он сильно растет с развитием проекта. Поэтому вместо него граф знаний.

• Надо ограничивать инструменты, было 17 инструментов для SQL-запросов – агент путается в выборе, оставили 2.

Три уровня доверия агенту.

• Решает сам, если результат можно проверить или быстро откатить

• Human in the loop – когда откат сложен.

• Человек – когда откат невозможен или сильно дорог. Общение с клиентами b2b – люди. Деньги, доступы, юридические риски – тоже на них. Но движение к автономии происходит.

Агента, распределяющего задачи нет. Агенты ставят новые задачи, и если задачи в пределах их прав – сами берут. А вот если появляется непонятная задача – распределяет человек .

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

Цена geoboost – по правилам saas, идем от маржи и костов. Консалтинг – проекты кастомные, и они выбирают куда идти и цену ставят. Их специализация – финэффект от внедрения ИИ, трансформация процессов с финэффектом. И там больше заходит ML, а не ИИ – пока так.

Андрей Усенко из Райффайзен. Не ускорять старую организацию, а построить новую: опыт AI-native трансформации бизнес-юнита

Это рассказ об организации агентской разработки в бизнес-юните работы с кредитами в Райффайзен. Если кратко, то все роли заменены на одну – product engineer, задание которой дает продукт. И дальше он дает задания агентам на разработку, добиваясь того, чтобы сначала была получена приемлемая спецификация, а затем – код. Если агенты не справились, то он их направляет, а при необходимости – разбирается, что в harness им не хватило и дорабатывает. Сам он результат работы агентов не правит. То есть он может, но это отрицательно повлияет на его KPI – это сделано специально, чтобы побудить инженера разбираться с harness, а не править результат. В целом – так решается 70% задач, из них 31% принимаются с первого раза, и эта доля растет, а хвост ошибок все меньше.

Кстати, летом Летом на Saint Highload я слушал выступление Андрея Неведина из Райффайзен про управление контекстом. И, как я понимаю, это был рассказ о том же бизнес-юните, но тогда был этап построения harness, чтобы агенты успешно работали. А теперь уже про использование, включая те изменения, которые это обеспечили.

Бизнес-юнит 170 человек, код писали годами – кредитный процесс корпоративного финансирования: выпуск доверенности ,сертификация и так далее. И агент все это делает.

Дальше – подробности.

Harness работы агента описывает процесс: кто ставит цель, какие границы автономности, где DoD, как реагируем на инциденты. Продукт говорит, какую метрику подвинуть, product engineer делает спецификацию и решение – осталась только одна роль. Раньше инженер был как сборщик с электроинструментом на конвейере, который сам с ИИ-помощником делал задачу, а сейчас делает конвейер, а инженер контролирует и работает с harness.

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

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

Слои: агентный слой, остановка задач, исполнение задач, refine-агент – улучшения на историческом пласте. И большой питон-слой: проверяет, что агент прошел все гейты, восстанавливает после ошибок и так далее. Агенту не велят на слово: ci/cd проверит, и контроллер тоже.

И в конце – ревью изменений. Делать ревью в виде diff merge request – невозможно. Инженер проверяет набор принятых решений, визуализируется в виде набора решений, и человек проверяет именно их, хотя при необходимости может спуститься вниз.

Это внедрили в августе, решено более 1000 задач, из них 70% успех, 31% приемка с первого раза. Эта доля растет.

Ключевые изменения.

• Все в одном репозитории, раньше было в разных и оркестрация merge. Теперь для продуктового контекста сервисы, фронт, вики и все остальное в одном репозитории – это позволяет агенту исследовать и доставлять. Вместо 200+ сервисных репозиториев стало 10 монореп.

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

• Как привить разработчику mindset, чтобы он не делал работу агента, если тот – не справился. Особенно актуально для простых задач. Инстинкт тут не конструктивен. Правильный вопрос: что изменить в продуктовом контексте, чтобы агент размышлял также, как я, и принял правильное решение.

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

Фокусы, обеспечивающие расширение автономности агентов.

• Качество постановки в upstream – важно устранить значимую неопределенность

• Стабильная среда проверок – чтобы инфраструктура не моргала, мок зависимостей

• Агент не читает мысли, договоренности – в промптах, скиллах и так далее.

• Все проверки, которые можно – надо встроить в процесс. И принципы: DDD, покрытие тестами, статический анализ.

Пробуксовка – в человеке: «я люблю писать код и не отдаю агенту». Способ полечить – работать с майндсетом в команде.

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

Основные рекомендации.

• Цель как outcome для клиента, амбиция, которая недостижима для старой системы разработки.

• Пересмотреть систему ролей – без передачи между этапами.

• Устранить ловушку демо – когда агента показывают, но работают по-старому.

• Главную метрику вынести на дашбоард.

Именно команда определяет, как придет к цели.

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

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

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

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

Екатерина Фирсова. Проблема сопротивления сотрудников внедрению AI: почему AI-трансформация буксует

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

А теперь – подробнее, в виде отдельных тезисов.

• Мешает mindset: «Что, агенты серьезно заменят людей? Какую ответственность может брать агент? Агент – инструмент, и у сотрудника с ответственностью плохо». В нем – логическая дырка: у сотрудников тоже нет ответственности, но она не смущает.

• Безопасники. У них нет представления, что внутри, им страшновато – они блокируют непонятное. Тем более, что в статьях пишут разное, видно что сами разработчики клода и openai подноготную не знают. Они с безопасниками работали, присоединили к процессу в начале и включили в политику безопасности можно-нельзя: какого агента можно использовать для чего.

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

• А еще инженеры плохо думают о будущем, горизонт планирования ограничена. Она это поняла 10 лет назад, когда в компании начинали митапы – инженеры не ходили на свои темы, сидели в своей коробочке.

• Эффективные менеджеры, которые говорят:« Мы внедряем ИИ, сокращаем 20% инженеров». Инженеры слушают и думают «Классный план! Сейчас разберемся, чтобы он точно не сработал».

• Есть компании, которые ставят KPI: 50% кода делает ИИ. И тогда инженер смотрит на код ИИ, который его не устраивает, и у него дилемма: или правишь и бонус уходит, или не правишь, и код уходит в прод. При этом добиваться, чтобы ИИ исправил не всегда позволяет время. Плюс некоторые компании вешают бюджет токенов в довеску к такому KPI по коду.

• А kpi разработчика о числу строк кода – раньше было смешно, а теперь еще больше.

• Бывает, менеджер внедряет сам, чтобы показать, как должно работать. В одной компании СТО обещал внедрить ИИ, чтобы армия джунов заменила сеньоров. Потом его агент начал ставить, принимать и отказывать встречи произвольно, и резюме тоже кандидатов обрабатывал непонятно. СТО уволили.

• Бюджетный процесс – как объяснить финансистам? У них стоимость ИИ 2 мидла в год (в компании 260 челвоек), планируют на 4-5, в процентах расход невелик, но сумма не маленькая и финансисты задают вопросы.

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

• Нельзя автоматизировать кашу. Все говорят: если не настроены процессы – ИИ не поможет. Но у кого есть нормальные-идеальные процессы и инструкции? Ни у кого. Что делать? Разбираться с сутью, а потом делать ИИ. Получается каша из топора: приходят, просят ИИ – начинаешь разбираться в процессах – и все улучшается, ИИ там не при чем, он просто рядом присутствует.

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

• Появилось такое явление – волки: они устроились на несколько работ параллельно, получают 3-4 зарплаты, делают по минимуму. Уволить по закону сложно, и ИИ помогает ему работать.

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

• Если оставили старый процесс – разработка фигачит бесконечное количество кода без особого эффекта – бутылочное горло просто сместилось.

• Слишком сильно доверяем ИИ. Компания запустила проект, в доке – принципиальная ошибка. Ответ аналитика: «это написал LLM – я что, проверять буду?»

• Знает прекрасную историю, когда купили лицензии, их использовали 15% – сотрудникам повесили штрафы за неиспользуемые токены.

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

• Наоборот, менеджеры отдают решения ИИ и вообще не проверяют результат.

• Многие сотрудники, когда перешли на удаленку, решили, что теперь будут работать 20 часов вместо 40. А с внедрением ИИ решили, что теперь хватит 10. И это разбивается про реальный мир.

Ловушки внедрения.

• Терминологический хаос. AI, BI, ML. Но дальше подробности – агенты, субагенты, харнесс – отвечают разное. У разных людей разные представления, и это влечет проблемы.

• «Надо найти чемпионов – они все внедрят». В этот момент чемпионы переживают – ответственность. А остальные делают ставки, получится или нет.

• Декларативный разрыв. AI-hands.

• CV-driven approach – внедрять новое, чтобы получить строчку в резюме, а не пользу бизнесу.

Что делать?

• Владелец процесса. ИИ-тимлид, которые управляет этим как проектом

• Аудит выявиться группы сопротивления, договориться

• Договриться с безопасниками. Официально по почте. Однажды менеджер по ИИ обучал HR-команды. И объяснял, как клево развернуть n8n на своем сервере – HR-команде. Провалил.

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

• Найти чемпионов, в это jtf верит. Но не перекладывать на них супер-ответственность. И определить рамки и границы вменяемости. Один тимлид классно настроил агентов, показал всем. Ему сказали «настрой и нам» – а он не планировал, он хотел показать, и пусть сами сделают.

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

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

• Релевантное обучение. На полном серьезе один из потенциальных учителей говорит: «у нас же у всех цель ,чтобы 100% кода были написаны ИИ?» – нет, у них другая цель.

• Актуализировать процессы под ИИ. По честному. В том числе – что будет с неэффективными.

Из ответов на вопросы.

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

• Как получить инструкции? Клода натравливаем на конфлюенс, даем шаблон документации – и получается инструкция. Раньше это делали очень долго. И это надо сделать до внедрения ИИ.

• Метрик по ИИ нет. В начале года провели аудит, и выяснили, что можно автоматизировать ИИ. И сделали роадмап. По продвижению по нему метрики есть.

• Разработчики боятся деградации. Что делать? Ответ – индивидуальный план развития. Когда ты прописываешь, каким будешь через 5 лет. И индикаторы и вектора развития. Если ИИ для него не развитие – то выясняешь, что будет для него развитие, надо определиться конкретно. А потом – выделить время. У них кто-то вкладывается в джунов. Или митапы организуют. Это не совсем про бизнес-результат, от работы сбоку. Но самореализацию – дает.