8465
правок
Изменения
Новая страница: «Два дня был на конференции [https://jokerconf.com/ '''Joker''']. Я на ней первый раз – это хардкорная конф…»
Два дня был на конференции [https://jokerconf.com/ '''Joker''']. Я на ней первый раз – это хардкорная конференция по Java, а на этом языке я не пишу. Но в этом году организаторы сделали отдельный день, посвященный изменениям, которые в мир несет ИИ, с идеей вывести технарей из узкой рамки, в которой они обычно думают о происходящем и взглянуть на мир шире. И они позвали спикерами тех, кто внутри ИТ мыслит широко, а также психологов, педагогов и философов. В целом затея удалась, люди на конференции активно обсуждали услышанное, хотя без отзывов «зачем нам вся эта хрень, где хардкор» и не обошлось. Но от многих я слышал, что они впервые за долгое время разрывались между параллельными выступлениями второго дня, и будут смотреть записи и думать над ними.
Отмечу, что сама по себе задача – сложная. Когда ты выводишь человека из узких рамок профессионального восприятия мира, то первая его желание – получить картину устройства мира, которую надо освоить и пользоваться. А такой картины сейчас нет, есть много вариантов от разных <s>визионеров</s> авторов, среди которых большая часть – несостоятельные. Они не рассказывают, что будет, а пугают что от ИИ человечество поглупеет и деградирует. И это – часть индустрии страха перед будущим, который входит в нынешнюю конструкцию управления обществом в мире. Я об этом рассказывал еще пару лет назад в выступлении [[Future-WAW|'''«Место ИТ и аналитиков в будущем мире»''']] на WAW-2024, где размышления о будущем тоже входили в замысел организаторов. Так что человек не просто должен расширить свои рамки мышления о мире, но и '''самостоятельно заполнить''' то место, которое он увидит, '''собрать собственную модель''', которая послужит основанием для действий.
И это великолепно получилось '''на паре проблематизирующих выступлений от организаторов – Алексея Федорова и Андрея Морозова''' на пленаре второго дня. У психологов получилось хуже, что отражает современное состояние науки, в значительной мере сфокусированной на исследованиях о деградации человечества, а не на построении этого будущего. А вот от практиков из ИТ, деятельность которых меняет мир, были интересные выступления.
Я тоже затрагивал тему изменений мира в широкой рамке, хотя фокусом его было осмысление тех изменений, которые несет ИИ в систему разделения труда в ИТ с включением в него ИИ-агентов. Оно так и называлось: [[AIagentsJoker|'''«Как организовать гибридную команду людей и ИИ-агентов»''']] – с переходом к агентам ИИ надо перестать воспринимать в качестве инструментов, а начать рассматривать как субъектов, включаемых в команду, которых надо онбордить, оценивать компетенции и растить, обеспечивая обратную связь и обучение. Обзорное выступление по изменениям, когда ситуация меняется ежедневно – не простая задача, но вроде у меня получилось.
С наших выступлений я и начну обзор, а потом будут все остальные в некотором порядке, который я посчитал логичными. Технологические выступления будут в конце, я на пару из них в первый день заглянул, но они в отчете представлены не репрезентативно.
== Алексей Федоров. I against AI ==
'''Великолепное выступление из позиции размышляющего об изменениях в мире'''. Которую слушатели тоже могут занять. '''Не взять готовые результаты, а включить голову и подумать самим'''. И дальше я попробую пунктиром зафиксировать нить размышлений Алексея.
Изменяется весь мир, и ИТ впереди.
Я спрашиваю LLM, а в ответ – хрень. И я думаю, что LLM – фигня. А чо в этот момент происходит в голове? У меня есть ожидание, в них я как-то вижу образ результата. А получено иное. Но иное не обязательно получается от робота, это может прилететь и от исполнителя задачи в jira.
У него маленькая дочь, 1 год 4 месяца. Когда кормят, она ест-ест, и в какой-то момент говорит «манан» – банан. И тут ты думаешь: с одной стороны – надо порадовать, а с другой стороны, начнешь давать – через три дня только бананы будет есть, они пробовали. И надо как-то решать.
'''Мир человека устроен так: я субъект, вокруг – объекты'''. И ребенок полагает, что эти взрослые куклы должны ему дать банан, иначе мир сломался. Но потому ребенок вырастает. И мы привыкаем, что мир вокруг не обязательно выполнял то, что мы ожидаем, что для этого надо, как минимум, внятно сформулировать запрос. И в jira пишем цели, задачи, критерии результата – объясню этим дуракам вокруг. С роботом – тоже самое. Сначала был prompt engineering, сейчас SDD и онтологии, контекст и harness: мы пытаемся передать описание того куска мира, с которым работаем, пишем инструкции: как устроен мир, что мы в нем делаем, и как именно. Прошлое и настоящее так можно описать, будущее – нет.
Но в какой-то момент то, что работало раньше – больше не работает. Как банковские карты. Я по-прежнему двигаю тикеты, но результата нет. И процесс превращается в ритуал или карго-культ. И в этот момент возникает мысль '''«может, я не так строю картину мира?»''' И дальше есть два варианта: одни начинают адаптироваться, менять свою картину мира, а вторые продолжают стоять на ней: «если мои ожидания не совпадают с реальностью – тем хуже для реальности». Те, кто меняют – начинают читать, смотреть вокруг – и одних цепляет какая-то «серебряная пуля» вместо прежнего (как раньше приходил Agile, JTBD). Человек при этом не меняется, он двигает картину мира, но '''продолжает считать ее единственно верной'''.
А другие – понимает, что '''его понимание – не единственно верное''', и в этой вселенной можно смотреть на мир другими глазами, и другие люди смотрят иначе, а с ними все равно надо взаимодействовать. И это интересно: какую-то критику нашей картины мы принимаем, рассматриваем, а на другую говорим: «хрень какая-то». Если с другим человеком нет ничего общего – то говорить не о чем. А если есть штука, которая объединяет (семья, работа) – то есть о чем поговорить. Ведь другой начнет действовать по-другому, он будет действовать не так как я. И я ему написал как делать – а он все равно будет делать не так, как я написал. Этот этап проходили многие, когда становились тимлидами, и одни попадали в режим микроконтроля, а другие нет, они принимали, что делают иначе, ведь тоже неплохо получается, а иногда лучше меня.
Что нас объединяет? Общие установки и ценности, корпоративная культура. Мы видим что-то общее, и это «мы» появляется. '''Без различения мы и они – невозможно построить я''': ты сравниваешь себя с другими. И понимание позиции дает основание действовать. Доверяя другим, мы вынуждены работать с их ценностями и с их набором приоритетов – и они могут сделать то, что для тебя вообще не важно, а им – важно. '''Удержание противоречий, которые не разрешимы в чью-то пользу, без запихивания другого в свою коробочку, дают возможность развития'''. Он пришел на старый проект, старожилы запихнули в свою коробочку, отвергли идеи новых технологий. А через три года начали слушать… Другой отличается в силу каких-то причин, у него другой опыт.
Я тут хочу заметить, что о том, как учитывать точку зрения другого человека, строить модель того, как он мыслит, понимать, что он тоже строит такую модель про тебя, и вы оба можете ошибаться, есть интересная книжка – '''«Алгебра совести» Лефевра'''. Я ее прочитал примерно год назад, и у меня есть [[ConscienceAlgebra|'''подробный отзыв''']]. А сейчас возвращаюсь к выступлению.
При чем тут ИИ? Многие смотрят на робота антропоморфно. Робот что-то делает и ты говоришь ему «что ж ты, дурак, сделал». А это – инструмент. Впрочем, с автомобилем или кофе-машиной тоже говорят. А еще обращаются «сделай мне что-то», или «давай подумаем», «что я делаю не так?».
А ИИ используют как арбитра: есть три человека, которые спорят, и говорят «сейчас робот нас разрулит». Тут есть две ловушки. Первое. Этот запрос роботу будет кто-то писать, и как напишет – то назад и выйдет. Был прецедент: на 13 человек было 6 ответов из 7 вариантов, потому что люди по-разному описывали ситуацию, задавая вопрос.
Второе. '''У робота есть установки от создателей и опыт, на котором он обучался'''. Можно ставить робота в позицию «ты опытный java-программист», но ограничено. Возьмем две модели, есть Клод-код, и там если есть противоречия между людьми, он будет отвечать аккуратно в безопасных зонах, чтобы все были довольны. А Палантир, где все воюют со всеми – скажет: иди доминируй.
'''Когда с роботом взаимодействуешь – помни, что технология не нейтральна''', что у робота – другая картина мира. И ты можешь потерять субъектность. Когда с человеком – вы это противоречие удерживаете, да и он спорит. А робот – он спорить не будет, но все равно он на тебя влияет.
Замечу, что тут появляется есть интересный вопрос: а '''как можно сделать ИИ частью «мы»'''? Ведь он создан кем-то, где-то там. И постоянно обновляется, выходят новые, дообученные версии, в рамках которых установки меняются. Мы пишем harness – но многие ли пишут в этот harness ценности компании и команды? Хотя представления о хорошей архитектуре и коде – тоже ценности, но обычно этим уровнем ограничиваются. А проекты – они же не только про код, но и про людей. LLM обрабатывает интервью и совещания, пишет письма заказчикам… В общем, есть о чем подумать в практическом залоге.
== Андрей Морозов. Мир без опоры ==
В конце вьетнамской войны американцы решили классифицировать скиллы. Положили разделение: с железом или с людьми. Но парамедик работает с людьми, а похож на морпеха – по регламентам. А управленцы работают с документами, но реально – с людьми. Поэтому деление изменилось: действуешь по инструкции или свободно.
Винер полагал, что робот гвозди забивать будет, а писать картины – нет. Но стало не так.
Если LLM дойдут до предела – нам, людям что-то останется?
Я хочу открыть шаурмичную. Чтобы решить, где делать, LLM не нужна, я могу получить ответ за счет больших данных. А вот чтобы сделать конференцию с философским уклоном? Или позвать социологов на конфу технарей. Робот посоветует, напишет план действий. '''Но может ли робот взять ответственность? Готов ли я дать такую ответственность?'''
Я тут хочу рассказать историю, которую услышал в кулуарах конференции. Есть лингвист, занимается редкими языками, у которых осталось мало носителей, ездит в экспедиции. И она зафиксировала новое явление: раньше, когда она спрашивала про какое-то слово, с которым у собеседника были затруднения, то собеседник спрашивал старших. А теперь начал спрашивать Алису и воспроизводить ее ответ. И тут вопрос: что Алиса знает про этот редкий язык? Или она фантазирует? Ведь эти фантазии воспроизведет носитель, а потом зафиксирует научная статья…
Умный дядька спланировал и говорит роботу «давай делай». Человеку говорят «делай», ему приносят не то, и только в этот момент он лучше понимает, что он хотел. А теперь LLM. Настроили LLM, бэклоги стали короткими, а ценность не выросла. Оказывается, задачи лежали не для того, чтобы делать – а чтобы спорить, грумить, ругаться. Некоторые CEO считал себя гением, раньше его критиковали – а теперь LLM делает без обратной связи. Такой маленький диктатор в эхо-камере, которая обслуживает его хотения. Поэтому важнее не сформулировать промпт, а сформулировать свои желания.
Если говоришь роботу «что-то сделай» – то он скажет, что хочет окружение. Разработчика мы нанимаем в компанию. А таксист в Яндексе – снаружи. Потому что таксистам можно связать регламентами, а разработчика надо погружать, онбордить внутрь, Он узнает, что некоторые задачи живут не в jira, а в чате, что начальник один, но еще надо советоваться. Что такое ответственность или власть. Архитектура проектируется с языка. А регламенты часто складываются исторически. А потом еще это засовываем в бизнес. И считаем, что пойдет все хорошо.
Мы сами выбираем мир, в котором будем жить. Люди смотрят на одно и то же, один видит возможности, а другой – риски. Как изменить картину? Переехать. Представьте, что ты настроил робота, который блокирует тебе все сообщения от друзей, которые зовут выпить пиво. '''Ты сам строишь камеру своего окружения. Можете ли вы так, хотите ли вы так?'''
Когда-то всех разработчиков заставляли учить ассемблер. Потом оказалось, что их можно упаковать в языки. LLM – еще один черный ящик, который повышает абстракцию. Никакой разницы. Есть возражение, что LLM – не детерминировано, и поэтому надо валидировать. Но тут есть подвох. '''Если ты вникаешь в то, что сделал LLM – ты ничего не экономишь'''. А если не вникаешь – рискуешь попасть в ловушку: студент приносит преподавателю работу, специально сделав в начале ошибку – и все обсуждение цепляется за нее. LLM не хитрит так, но она сделана на какому-то контексте, она зафреймлена – и она в ответе передаст вам фрейм. А значит вы должны коммуницировать с ней как с субъектом, и выяснять, что этот субъект может сделать, а что – нет. Как спросить у ИИ, что она может? Так же, как у чловека. Можешь ли ты общаясь с ребенком или с сотрудником не фреймить его мгновенно, а разбираться, спрашивать?
Лет пять назад любили говорить про VUCA-мир. Мы, инженеры, можем решать сложные задачи. Но нам нужна определенность и границы, за которыми работают другие. А теперь очень часто этой определенности нет. Можно ли говорить, что прилетают черный лебедь, когда это каждый день, когда мы живем в озере в ними. Инженер говорит: ты хаос и сложность превращаешь в алгоритмы и живешь в понятном мире. А философ говорит – тебе надо жить в таком мире.
== Максим Цепков. Как организовать гибридную команду людей и ИИ-агентов ==
С переходом к агентам имеет смысл перестать воспринимать ИИ как инструмент, а начать рассматривать агентов как субъектов, включаемых в команду: их надо онбордить, оценивать компетенции и растить, обеспечивая обратную связь и обучение.
Обзорное выступление по изменениям, когда ситуация меняется ежедневно – не простая задача. У меня в мае была статья [https://habr.com/ru/articles/1035522/ «Об организации труда ИИ-агентов»], но дополнения к ней появились почти сразу. Но я попробовал и вроде у меня получилось. Презентация выложена на странице выступления [[AIagentsJoker|'''«Как организовать гибридную команду людей и ИИ-агентов»''']], а здесь я зафиксирую краткие тезисы по содержанию.
# '''SDD – это старый известный водопад'''. Его не получилось реализовать на людях, и теперь попытались сделать на агентах.
## Не работает по тем же причинам: агенты делают не то и не так, в ответ идет наращивание подробностей в спецификации, как делают аналитики при разборках с разработчиками о том, кто виноват, в результате спецификация быстро становится не читаемой и не проверяемой. Причины известны с 1990-х.
## Третья – спецификацию невозможно обсуждать с бизнесом, он ее не понимает.
## Проверка спецификации по характеру работы сильно отличается от написания кода, '''это – другая компетенция'''. Когда разработчикам это навязывают, теряется мотивация.
# Есть ограниченный класс задач, которые решаются хорошо – когда есть типовые решения: сайт-визитка, типовой интернет-магазин, типовой документооборот, типовая CRM небольшого бизнеса. Раньше делали платформу с точками расширения, теперь можно сделать harness для скелета решения и чек-лист для проверки спецификации.
# Есть способы несколько облегчить проблемы SDD.
## Возложить проверку на ИИ, а разработчики пусть пишут чек-лист и архитектурные принципы.
## Проверяем не спецификацию, а точки принятия решений, в которых ИИ делал выбор из альтернатив – это ближе и проще.
## В спецификации пишем не способ решения, а краткую архитектуру и набор тест-кейсов – это получается не SDD, а '''TDD/BDD''', хотя формат OpenSpec это позволяет.
# Можно работать через прототипы. Тем более, что бизнес сам с удовольствием вайбкодит прототипы. Правда, он потом требует их поставить в прод, а разработка не может понятно объяснить, почему не может это сделать. Это направление точно будет развиваться. При этом описание архитектуры, тест-кейсы и другая документация таким приложениям нужны, но может появляться позже, по мере того, как прототип стабилизируется.
# Но вот сделать harness-платформу, на которой бизнес будет вайбкодить все, что ему нужно, как предлагает '''Disrupt-PDCL''' от Сбера – точно не получится, как 25 лет назад не получилось обеспечить разработку приложений за счет создания CASE-средств. Причины – те же, платформа не обеспечит сложные случаи, для которых нужна '''совместная работа бизнеса и разработчиков''' над поиском решений, приемлемых по сложности и решающих проблемы бизнеса. Надо уметь включать в эту команду ИИ-агентов.
# ИИ-агенты хорошо делают частные задачи. При этом процесс разработки расщепляется на более мелкие операции. Это уже было – когда вместо программиста появилась команда из аналитика, разработчика и тестировщика, а позднее веб-мастер превратился в дизайнера и фронт-разработчика. И есть обратные процессы, когда специализации объединяются – как было с кроссфункциональными командами вместо отделов и происходит сейчас с '''tiny-team'''. Можно использовать те же схемы для проектирования процесса, в презентации у меня была '''схема Акта деятельности''' из СМД-методологии, поверх которой нарисовано конкретное разделение труда.
# Важно помнить, что '''недостаточно разделить на операции, необходимо обеспечить компетенцию исполнителей, снабдить их знаниями'''. Даже когда это ИИ-агенты. Это – вертикальное измерение разделения труда. Если у вас агент проверяет архитектуру или качество кода по чек-листу, то надо поверх запускать '''HADI-цикл''', в котором ведется мониторинг текущего качества, выявляются проблемные типы задач и решаются доработкой harness. Об этом забывают, не ставят доработку harness как процесс. При этом можно перераспределять задачи между ИИ и человеком: ставишь ИИ-агента, который делит задачи на простые и сложные по каким-то критериям, простые отдает ИИ (их может быть несколько с разными моделями), а сложные – человеку. И поверх – мониторинг и совершенствование.
# В целом тут большое поле деятельности, ИИ-агенты сейчас позволяют сделать то, до чего не доходили руки: покрыть тестами, актуализировать документацию, написать скрипты, чтобы создавать тестовые стенды на основе боевых и так далее.
# ИИ меняет не только разработку, но и бизнес. Если гипотеза проверяется за 3-5 дней вместо 2-3 месяцев, надо перестраивать весь процесс и роль ИТ в нем. Раньше бизнес говорил: «куча идей, разработка не успевает», теперь вопрос к качеству идей. Работа владельца продукта стала новым ограничением.
# '''Внедрять ИИ по площади бессмысленно'''. Теория ограничений Голдратта говорит: ускорение в конкретном месте только тогда дает бизнес-эффект, когда это место является ограничением для бизнеса. Внедрение по площади приводит к тому, что ИИ в точках ограничений появляется позднее, чем в других местах – там операционка зашкаливает. Поэтому проекты массового внедрения ИИ не дают бизнес-эффекта. Правильный подход – фокусировка: пилоты для апробирования, точечные внедрения в критических участках с ожидаемым результатом, и лишь затем – распространение. Распространять – необходимо: ИИ – инфраструктура, как электричество или интернет: освоить необходимо, применять надо там, где уместно. '''ИИ не даст конкурентного преимущества, потому что будет у всех'''.
# Работа с ИИ дает лог работы сотрудника, подробнее, чем таск-трекер. Это можно использовать для анализа и совершенствования работы. Хотя понятно, что сначала попробуют использовать для контроля. Это пока практически не прорабатывается, а по сути тут – тоже HADI-цикл.
# И в заключении была пара слайдов про те изменения, которые ИИ принесет в жизнь – когда у каждого из нас будут свои ИИ-помощники, организующие жизнь. И роботы – Китай активно работает в эту сторону, в том числе снижая стоимость, да и у нас разработки ведутся, на конференции было выступление Сбера с впечатляющими результатами.
== Святослав Морошкин из Сбер. Роботы: маркетинг или реальность? ==
Это был рассказ про многослойную архитектуру управления роботами. В котором было много впечатляющих роликов про достижения роботов – они не просто ходят, а делают сальто, танцуют, выполняют операции упаковки и выдачи подарков и так далее. И, что важно, это не ролики чужих роботов, а '''достижения центра робототехники Сбера'''. В рассказе были андроиды, но есть разные формфакторы, и у Сбера тоже – они с Самокатом работают с робособаками для доставки.
Слои архитектуры робота.
* '''Hardware''' – манипуляторы на электроприводах, и обвязка сенсорикой. Дальше соеиняют скелетом и получается антропоморфный робот. За три года – бум. Хорошие моторы, раньше был гидравлический – электромонторы не вытягивали. 30 китайских платформ. Они могут ходить и делают простые операции руками. Бантик завязать – еще нет. Форм-факторы разные, не только антропоморфные. Антропоморфные работают в человеческой инфраструктуре, но под какие-то процессы – могут быть другие. Ресурс моторов и приводов – проблема, но это решает. А вот автономная работа от батарейки не принципиальна, нет проблем, если робот работает полчаса, а потом меняет батарейку на новую, а старая заряжается. И чувствительность в приложении сил. И еще коллаборативность – остановиться при препятствии. Промышленные пока работают в клетках, потому что не безопасны для человека.<br />
* '''Motion control''': стоять, ходить, работать, бегать, танцевать. Это работает с частотой 100 Гц, и должно быть внутри самого робота. Начальный подход – MPC – явная модель динамики. Boston dynamics работал так. Нужна модель в дифурах и с высокой частотой решать. В 2024-2025 пришел RL – берем неточную модель с вариативностью, запихиваем в симулятор, и обучаем нейросетку управлять роботом, например, ходить. Подход стал основным и делает всякое, например, сальто или танцевать – и гораздо проще, это происходит online на роботе. RL-политики трех видов: цис-генералист – воспроизвести без потери равновесия, wbc-специалист – под сальто или танец, умеет конкретные движения, и walk politics – там motion planing. B большая часть вирусных видосов – это вот эти два слоя. А для сложного – оператор с пультом управляет. Внутри робота нет намерения, видосы, когда робот у блогера хулигант – управление человеком из-за камеры.
* '''Сложные действия: брать, класть, упаковывать, переносить'''. Надо соединить слова с действиями, концепция «открыть» имеет какой-то образ. И для роботов надо соединить смыслы, что значит «взять бутылку воды» – он должен увидеть эту бутылку, а потом запланировать действия и их исполнить. Раньше действия хардкодили: детектировать объект yolo, перечитать всистему координат, записать последовательность – это очень неустойчиво к изменениям. Сегодня есть '''VLA''', которая видела мир и обучена на большом корпусе данных, и добавляем Action expert, который умеет действовать – там 5 шагов обучения. Дообучают модель мира, потом действия, потом – управление. Робот кладет объекты в пакетик и выдает людям – представляли модель на конференции в Китае и были единственными, кто показал бизнес-функцию. Проблема в том, что чистый умственный труд задокументирован хорошо, а вот физический труд документирован плохо. Там нужно разнообразие по трем осям: действия, объекты, условия: готовить пищу можно на разных кухнях. Собирать можно по захвату движения человека, дальше он управляет роботом – идет передача, а с глаз робота стримят в глаза человеку. Робот собирает товары. Дальше это записывается, и получаются большие объемы данных. Дальше смотрим, как удешевить сбор данных – можно собирать данные. В симуляторах проблема с контактными операциями – закрутить, открутить.
* Учимся планировать – '''High Value Reasoning'''. Большая '''VLM'''/LLM, которая может выполнить задачу '''«уберись на кухне»''' – увидеть расстановку, и дальше сделать атомарные вызовы на элементарные действия найти или переложить предметы.
При этом на каждом уровне – свои модельки, и фронтирные модели – не специализированные, могут подключаться к разным роботам без дополнительного обучения, выясняя его возможности и особенности по массе и геометрии и дальше – управлять. Протоколы управления и видеопотоков – стандартизированы.
Он считает, что купить робота можно будет уже лет через 5-7, а может быть и раньше. Я тут согласен ,потому что Китай массово взялся за задачу апробации роботов для ухода за больными и стариками, уже год '''идет апробация''' в больницах и домах престарелых: робот помогает чем может и умеет звать на помощь, и его умения можно увеличивать. Используются промышленные модели, которые стоят 40-100 тысяч долларов, поставлена задача снижения стоимости до 20 тысяч и несколько компаний разворачивают производство.
== Евгений Лукьянов. Маленький человек в эпоху больших языковых моделей ==
Евгений – технический директор Tamga digital – разработчики банковского софта. А вступление состояло четко из двух частей.
Сначала был стандартный набор страха перед ИИ и неопределенностью, из-за которых некоторые люди хотят уйти в тайгу, построить землянку и так жить. В метафоре маленького человечка, который в ужасе перед надвигающимся будущим. При том, что от него требуют это будущее принять и в него встроиться: компании повсеместно внедряют ИИ, или хотя бы сделать вид что внедрили, чтобы соответствовать современным трендам, признаваться, что не получилось равносильно самоубийству, требуя результатов от разработчиков, которым в лучшем (или худшем?) случае дадут кого-то, кто еще вчера двигал блокчейн куда можно и куда нельзя, а теперь переключился на новый тренд. И говорят: «ИИ будет генерить весь код, критичный тоже, отвечать будет разраб, пусть его научит, а потом мы этого разраба выгоним» – потрясающая мотивация.
Но все эти ужасы явно были не про них самих, а про кого-то еще. Потому что во второй части был конструктив: как они вполне успешно встраивали ИИ в рабочий процесс. А в состоянии ужаса и стресса созидательный конструктив сделать невозможно.
Они всегда работали на результат – не написать код, а решить проблему заказчика, всегда стремились, чтобы инженеры так делали. Ключевой навый тут – хорошая коммуникация с заказчиком, поэтому на этапе сбора требований, исследования предметки и проектирования ИИ помогает не сильно. Он помогает разобраться, если предметка совсем новая, но специфики заказчика он не знает. Может рисовать мокапы интерфейсов. А вот проектные решения у него часто переусложненные или наоборот, излишне простые.
А вот когда проект уже разделен на ограниченные контексты, как велит DDD, то в их рамках ИИ неплохо делает реализацию. Особенно для типовых частей, если написать правила. Тут имеем громадную экономию сил и времени. И небольшие библиотеки у него тоже получается делать, а потом использовать – после того, как их выделили в проекте. По шаблонам ИИ работает очень хорошо.
Так что '''ключевой навык разработчика – видеть границы модулей''', хорошо декомпозировать.
Еще ИИ хорошо делает проверки. Жесткие правила все равно лучше возложить на статический анализатор, но ИИ может проверить и менее формальные вещи, например, что в тесте нет методов, которые порождают данные, то есть соблюдена изоляция логики тестов от данных. ИИ может порождать тесты, надо контролировать качество, надо контролировать, когда ИИ переписывает тест за реализацией, чтобы он стал зеленым.
Реализацию разработчики проверяют, но по-разному: бизнес-логику проверяем всегда, query доверяем ИИ, адаптеры – чуть пожестче, чем query.
Важны метрики сцепленности кода. Вайбкодинг часто заканчивается не очень удачно по отношению к сложным системам. Есть Геннадий Круглов – он занимается исследованиями в сфере ИИ, и у него концепция восходящей спирали энтропии: связность – цикломатическая сложность – когнитивная перегрузка – ИИ начинает хачить, подгонять тесты. И метрики позволяют понять зоны риска.
Миграция – ИИ может написать криво при обновлении под нагрузкой, тут ничего нового, надо следить. Тут и разработчики косячат. ИИ может помочь, написать скрипты, в том числе анонимизация для тестовых стендов.
'''Чуда не произошло'''. Получили хороший прирост производительности, но и раньше у нас было неплохо. В целом результат неплохой, трагедии маленького человека не произошло. Все что делали – ограничивали глюки. И делаем абстракцию, чтобы можно было доверять. И '''самое интересное остается инженерам'''. Труднодоступное знание – по-прежнему в цене. Stack Overflow хоронят, но он по-прежнему живет, вопросов стало меньше, но они стали сложнее. Пока все ускоряются с ИИ, можно выиграть, просто не перестав думать. '''Не превращайтесь в оператора LLM'''.
Откуда возьмутся профессионалы, ведь все это – для опытных? Нужен упор на базу – как разработка работает целиком, как методологии связаны между собой. Связей много – нужны тесты, CI/CD и многое другое.
За 17 лет не поменялось ничего. Когда пришел стажером, все искали серебряные пули, и продолжают искать сейчас. ИИ пару лет, но принципиальных изменений в мире нет. И у вас есть шансы над этим подходами подняться.
Полезно заглянуть внутрь – как LLM устроена, как она думает (биология моделей) – есть книги и исследования. И построение онтологий для управления контекстом.
Метод '''меньше думать, больше делать''': берете рабочую проблему и пробуете решить. Увидели проблему, разбежались, расшиблись, пошли читать – из чего стена устроена и как ее разбить, и следующая попытка.
== Кирилл Ветчинкин. От станка к чертежу, от кода к модели: повторяет ли IT историю XX века? ==
Кирилл пытается разобраться, какая судьба в будущем ждет нынешних опытных разработчиков, на исторических аналогиях промышленных революций. Правда, история у него сильно свернуты: сначала появились мануфактуры и фабрики и пришла индустриальная эра, а в 1960-х, станки с ЧПУ открыли эру информационную. В любом случае происходило следующее: старое мастерство обесценивалось, и мастера-ремесленники шли на фабрику, а рабочие начинали нажимать кнопки на станке, и это была трагедия. А потом появлялось поле для нового мастерства – умение работать на станках, умение их программировать.
Так будет и сейчас, потребность в мастерах написания кода уходит, тем более специализированных, и перед ними есть две дороги. Первая – осваивать предметную область и становиться разработчиком-универсалом, который умеет общаться с бизнесом и закрывает с помощью ИИ разработку продукта полностью, используя активно скиллы. При такой разработки пропадают внутренние очереди, ожидания специалистов. Их в свое время попробовал убрать agile, создав кроссфункциональную команду, но получилось не везде, а внутри команд специализация все равно осталась. Теперь их убирают полностью.
А если ты крутой технарь и не хочешь осваивать предметку, то можешь заняться переводом своих умений в скиллы, которые будут использовать продукты, и поддерживать систему разработки технологически.
'''Реальность ИИ наступила, вопрос в готовности к ней и выборе своего пути'''.
* '''Скептик''': я и без ИИ все сделаю. Это часть самые опытные. Но есть риск – рутина от него требует времени, менее опытные обойдут, это не очень перспективно.
* '''Кодер''': чисто по ТЗ. Таких достаточно много. Но ТЗ проще в Клод закинуть, такие будут не нужны.
* '''Лидер экспертизы''' – упаковываешь в скилы, запускаешь менторинг. Вы радели за хорошую архитектору – сделайте это.
* '''Продуктовый разработчик''' – тут погружение в домен.
Рroduct Owner тоже хочет писать код. И он – пишет, чтобы проверить гипотезу за пару дней вместо пары месяцев. Мы страдали, он страдал. А сейчас – он сделает. Продукт проверяет гипотезу, ему поставляет центр компетенций – и то, что выстреливает ,продуктовый разработчик доводит до продукта.
'''Итог'''. Разработчики-кентавры. Есть фундаментальная экспертиза, остальное – за счет скиллов. Мастер в паре с ИИ работает мощнее чем каждый по отдельности. Интеллектуальное оставьте себе, рутину отдайте ИИ. И как фитнес: когда-то человек бегал для жизни, а сейчас нужен бег и прогулки, чтобы обеспечить здоровье.
== Виталий Соболев. До промпта: из какой рамки мы ставим задачи ИИ ==
Выступление о том, что у каждого из нас есть рамка, которая ограничивает наше мышление. Часто мы ее не замечаем. И когда мы ставим задачу агенту ИИ, то мы постановкой задаче задаем рамку, в которой он будет эту задачу решать. А надо уметь увидеть свою рамку и ее ограничения, и посмотреть на задачу иначе.
Например, продукт плохо продается – мы придумываем гипотезу о проблеме, и дальше фокусируем агентов на ее решении. И они не выходят за пределы. Есть workflow '''Событие – Интерпретация – Рамка – Намерения – Задача – Команда ИИ''', и когда ИИ подключается после формулировки задачи, то он мыслит ограниченно. Даже если вместо одного агента мы создали целую команду, это не поможет выйти за рамку. В общем, все верно, но для меня тут проблема сосем в другом: люди, которые работали на начальных этапах почему-то не обратились к ИИ, дошли до задачи собственным мышлением. Потому что формирование рамки происходит на этом этапе.
'''Роберт Киган'''. Есть вещи, на которые я могу посмотреть, а есть те, через которые я смотрю и их заметить сложнее. Это моя картина мира. Дело не во внимательности, иногда эти допущения и организуют происходящее. '''Важны не два типа вещей, два отношения к одной вещи. Subject – когда я смотрю на ситуацию, а Object – когда могу посмотреть на мир и себя, свою рамку, и выбрать'''. Рамка – штука полезная, но важно выбирать.
Отмечу, что тут надо быть аккуратно с терминологией. В данном случае subject и object – не про субъекта и объект, а про субъективное и объективное. И я не очень понимаю, отличается ли объективное от выхода в рефлексивную позицию, когда ты смотришь на себя и свои действия в мире снаружи.
Выходу за рамки часто помогает формулировка: меняем «у пользователя проблема Х» на «мы думаем, что Х – основная проблема», то там, где очевидность – появляется выбор. Универсальная рамка невозможна. Так что стоит замедляться и спрашивать «почему я так вижу задачу».
P.S. Я уходил с выступления и слышал его не полностью. Так что если тема вам интересна – смотрите запись.
== Александр Диденко. Граница между символическим и статистическим интеллектами ==
Это был рассказ о том, как в LLM, первоначально основанный чисто на весах генеративного алгоритма, добавляли рассуждения и другие средства, повышавшие качество мышления ИИ. Я слушал не с начала, так что в конспекте кусочек может отсутствовать. Дальше – краткие этапы.
* '''Рассуждения, а не только построение ответа'''. Это не только повышает его качество, но и объясняет человеку, как получен результат – а это важно для доверия.
* '''Обращение к внешнему миру'''. Началось с обращения к википедии, а дальше из этого выросло mcp. При этом поиск информации тоже может работать неправильно, поэтому ошибки все равно есть. А еще выяснилось, что '''активный агент может взламывать среду''', а не только искать в ней информацию.
* Настройка на контекст клиента – большая, чем просто добавление информации: '''harness''' – дает рабочее место, '''oracle''' – решает, что верно? а что нет, тестирует результат и отправляет на доработку и '''guiderail''' – запрет опасных действий. Тест работает надежнее самооценки, но проверить можно далеко не все.
* '''AlphaEvolve''' – возможность самообучения, используя '''oracle''' для оценки ответов.
* '''Kosmos''' – ИИ-ученый. В основе работы – комбинация с поиском по литературе с анализом данных. Например, вы провели большую серию экспериментов с людьми по трехсторонней торговле. И хотите найти объяснения. Потом запускаете волну поиска по литературе – она вытаскивает разные гипотезы из поведенческой психологии или наблюдения за приматами, строит гипотезы. А потмо идет проверка на накопленных данных. И так несколько раз.
* '''Мультиагентная система'''. Вроде как расширение. Действительно, есть тесты, которые показывают, что все круто. Но! Агенты часто допускают одинаковые ошибки. Многие эксперименты, когда ты – дизайнер, ты – разработчик и так далее – дороже моноагентной, издержки координации. При чем раз в пять. И есть исследования когнитивных искажений мультиагентной системы – ошибки не гасятся, а распространяются.
* '''Тонкий контроль над толстым состоянием'''. Агенты координируются через артефакты – вместо сообщений. Например, бэклог. И идет накопление знаний в стабильных артефактах. Есть агенты по анализу данных и агенты по анализу литературы, и еще модель мира (структура модели мира не описана). Она интегрировать не умеет, но данные копит.
* '''Латентная коммуникация''' – это дело совсем будущего. Обмениваться не текстом, а тем, что до проецирования на токены. Есть гипотеза, что язык редуцирует разумным способом. Если агенты начнут обмениваться состояниями, то там будет много шума.
== Владимир Спиридонов. Критическое мышление в эпоху ИИ ==
Владимир – доктор психологических наук и профессор, И он рассказывал о том, что думает современная мировая психологическая наука о влиянии ИИ на когнитивные способности человека.
С моей точки зрения, ничего интересного и особо содержательного она не думает. Одни ученые ставят эксперименты, чтобы показать, что человек поглупеет под влиянием ИИ, и потому его надо взять под контроль. Почему я думаю, что цель такова? Дело в том, что ряд экспериментов явно имеют и позитивную интерпретацию: человек не поглупел, а расширил спектр своих возможностей с помощью ИИ, но выбирают всегда интерпретацию «поглупел», потому что на это, думаю, есть социальный заказ от властных групп, которым поумневший человек не нужен. А потом другие ученые их проверяют и уточняют, и часто оказывается, что ничего страшного не происходит, что с помощью ИИ можно поумнеть, а можно – сэкономить свои когнитивную нагрузку, и это – вопрос выбора человека, хотя не всегда осознанного. Но при этом первоначальная оценка «караул, все поглупеют» – не снимается.
Кстати, замечу, что ни один из ученых не заявил «я начал использовать ИИ и поглупел», они все заботятся о каком-то абстрактном народе. Это очень хорошо проявлялось в вопросах, когда приводили конкретные примеры, а на это был ответ, что умным людям не страшно, а вот народ поглупеет. Я тут отмечу, что этот народ неплохо живет с нынешним телевизором, пропагандой и рекламой. И, кстати, не только у нас, мы иногда включали телевизор, например, в Греции, и обнаруживали, что наши новости по сравнению с теми – кладезь содержания. Так что, думаю, ИИ народу не грозит.
Но вернемся к выступлению. Я буду комментировать, но постараюсь четко отделить речь спикера от своего мнения.
Еще в 2015 были исследования, что люди не помнят телефоны детей, кидаются искать факты в инете и так далее. Это подавали как тревожные деградации памяти. Я тут считаю иначе. Телефоны вообще никто не учил специально. Просто когда ты его набираешь цифрами – он сам запоминается, так устроен мозг, и потом тебе не надо искать в записной книге. А когда выбираешь в телефонной книге, то этот процесс исчезает, вот и не запоминаешь.
А то, что люди ищут факты – наоборот, свидетельствует о любознательности. Раньше, когда что-то заинтересовало – ты все равно проходил мимо, потому что надо же найти книгу, прочитать. А теперь есть шанс простым образом эту любознательность удовлетворить, и это – хорошо. Это делают просто в разговоре, в ответ на случайно брошенную фразу или упоминание какого-то персонажа, и не только ИТ-шники – я с разными людьми общаюсь.
Системы хорошо проходят тест Тьюринга, с инструкциями «будь как человек», даже слабые – были графики. Что интересно, студенты в разы чаще ловят ИИ за хвост, чем специалисты по ИИ. С моей точки зрения, это как раз против деградации.
ИИ залез в психологию, когда он влияет на рынок услуг психологов. В Штатах в трех штатах был запрет. Было пара раз, когда ИИ дал советы, которые пошли к самоубийству. ChatGPT сдал медицинский тест, получил лицензию адвоката, сдал вступительные экзамены в Токийском университете. И много других подобных фактов.
Я тут дополню, что было исследование, что ИИ-психологи лучше воспринимаются людьми, достаточно репрезентативное: там люди (почти тысяча человек) проходили сеансы психотерапии, не зная, будет ли им отвечать ИИ или человек. А потом пациент оценивал качество сеанса, а также отвечал, с кем, по его мнению, он беседовал: с ИИ или человеком. И наивысший балл получили сеансы, в которых отвечал ИИ, но пациент думал, что беседует с человеком. А за ними на равных шли ИИ, о которых думали, что это ИИ, и люди, о которых думали, что это люди. А низший балл был у живых психологов, которых приняли за людей ([https://journals.plos.org/mentalhealth/article?id=10.1371/journal.pmen.0000145 первоисточник]). Естественно, психологи не могли на это не ответить [https://www.psychiatry.org/news-room/news-releases/new-research-human-vs-chatgpt-therapists другим исследованием], но оно совершенно плюшевое – там психологи-эксперты оценивали, кто лучше опишет кейс – человек или ИИ, и дружно решили, что человек справился лучше. И все это – далекий 2025 год, с тех пор все ушло вперед. А что касается суицидов, так и беседы с людьми к ним приводят, и даже с психологами. Но вернусь к выступлению.
'''В математике – ошеломительный прорыв''', когда несколько разных LLM сделали сногсшибательные продвижения, по списку Эрдёша. За последние три недели решено 8 задач, и новости каждый день. А еще понимание структуры простых групп, и язык для формализации математических доказательств, чтобы их проверял ИИ. Работает ИИ вместе с человеком.
Вопрос, насколько ИИ влияет на нас: «насколько глубоко ИИ влезает к нам в печень». Студенты у него используют ИИ, а потом специально портят тексты, чтобы он не догадался.
Исследование Google Effencts on Memory (Sparrow 2011). Можно было запомнить, или еще записать. И все, кто записывали – просто запоминали путь, куда записали. Я лично тут не вижу проблемы – люди используют цифровой экзокортекс, чтобы разгрузить свою память – как советует громадное количество книг, которые появились еще в эпоху пера и бумаги: записывайте, а не запоминайте. Тем более, что проверка еще показывает, что профи-врачи так обращаются только с не специфической информации, а в другом исследовании – что так делают только, если есть уверенность в доступности гаджета. На эти исследования были ссылки в выступлении.
Работа про когнитивный долг, когда три группы людей просили написать эссе, одни делали это с с ChatGPT, другие – с Google, а третьи – без источников, из головы, и потом выяснилось, что те, кто делали с ChatGPT забыли мгновенно, те, кто с Google – помнят дольше, а те, кто писали из головы – помнят хорошо. Кстати, этот кейс был не только в этом выступлении, и там про группу с поисковиком не говорили. Владимир сам говорит, что к эксперименту у научного сообщества куча вопросов, препринт так и не стал статьей.
Я не знаю, что конкретно говорит научное сообщество, но с моей точки зрения такой эксперимент показывает только одно: человек успешно может создавать новое с помощью ИИ, не нагружая свой мозг. Ведь задачей было сделать эссе, а не изучить предмет – и оно выполнено. Ну и понятно, что те, что писали из головы, при написании создавали связи между уже имеющимися материалами из долговременной памяти. А использующие Google или ChatGPT – загружали это в кратковременную, обеспечивая связность изложения, что не требует большого погружения. То есть на уровне нейропсихологии результат очевидный. Вообще одна из проблем современной психологии в том, что ученые упорно отказываются пересобрать свою науку с учетом достижений нейропсихологии. Именно поэтому я несколько лет назад попробовал сделать это сам, написав книгу [https://mtsepkov.org/Personality '''«Инженерная модель личности»'''], хотя предпочел бы получить это от профессионалов.
Когнитивная разгрузка. Снижение нагрузки за счет делегирования задач внешним предметам снижает когнитивные способности – исследование 2016 по атрофии профессиональных навыков – у врачей-эндоскопистов. С моей точки зрения, это явление того же порядка, что и с номерами телефонов, которые мы не помним. Конкретный когнитивный навык перестали тренировать – и он отсутствует. Это как говорить, что бывший спортсмен деградировал физически, после того, как прекратил профессиональные тренировки и участие в соревнованиях. Обычно бывшие спортсмены находятся в хорошей форме и держат ее, хотя пробежать на рекорд уже не могут.
А по поводу критического мышления – противоположные мнения: одна работа говорит, что его навыки снижаются, а другая – что активное использование ИИ в поисковом режиме, наоборот, его повышает. Отмечу, что тут – та же направленность: в первой работе вопль «караул, мы поглупеем», а вторая лишь добавляет, что «не все», хотя правильный акцент: «как захочешь – так и будет».
Крейк и Локхарт «Теория уровней переработки информации», 1972. Память – побочный продукт переработки информации. Тут я бы поспорил, потому что память – это то, что позволяет животным накапливать опыт, например, о перспективных местах поиска пищи, а у млекопитающих – перейти от передачи опыта через геном к научению родителями. То есть запоминание было основной функцией. Хотя на уровне hardware верно то, что, в отличие от компьютера, где процессор и память разделены, в мозгу нейрон одновременно запоминает и вычисляет, это две неразрывных функции.
И в заключении – список того, что нельзя делегировать ИИ. С очевидной оговоркой, что мы все равно будем делегировать, но надо быть осторожным.
== Владимир Красильщик. Как внедрить агента и не потерять людей, время и деньги ==
Владимир консультирует компании по внедрению LLM и рассказ был как раз о правильном подходе: надо выбрать площадку и провести '''пилот''', результатом которого должна стать не только команда, в которой освоили LLM и успешно его используют, но и сотрудники, которые разобрались с LLM и '''готовы распространять''', нести его другим. В целом мысль правильная, но в рассказе много теории, еще не подкрепленной практикой успешных внедрений.
А теперь – подробнее.
Сопротивление LLM и агентам. Это не новая история, новому сопротивляются – C, C++, Java, IDE с подсказками, NoSQL, микросервисы и так далее – всему сопротивлялись. Потому что когда пытаются втюхать – становится страшно. Я – эксперт, и тут тебе говорят «перезжай на Rust (и стань джуном)». '''Для успешного перехода надо предложить что-то, чтобы переход на следующий этап был комфортный'''.
Недавно был на YandexScale – там рассказывали опыт внедрения ИИ в машиностроении. Проблемы – аналогичны ИТ.
Личная история с LLM в 2025: все вокруг там были, а он сопротивлялся. Ребята восторгались, он взял ChatGPT для какой-то задачи, тот не решил – и забил на это. Но недавно вышел на работу, а там внедрение по площади – коммиты должен делать ИИ. Как-то освоился, но был жесткий стресс. И когда ему предложили присоединиться к команде, которая внедряет ИИ в компаниях, то он согласился, но у него идея – заходить постепенно.
При ИИ есть наблюдение. У него хобби – музыка, дома почти полная студия. И в конце обучения аранжировкам он прошел мастер-класс по suno.ai. Увидел – он делает хиты высокого уровня, и впал в депрессию: suno за 5 минут делает кучу вариантов аранжировок, на которые у него уходит много времени. Но он общался с преподавателем – начал вслушиваться, и всегда что-то не устраивает. И в результате suno.ai – не инструмент для готовых треков, а штука, чтобы обсудить. Восторг от ИИ редко исходит от профи.
Я тут вставлю замечание, правда не про музыку, а про тех, кто делает видео – фильмы, ролики и так далее. Профессионально, я слушал разных людей на разных конференциях. Они видят проблемы в том видео, которое создает ИИ, но умеют в ними бороться. А вот стоимость и сроки создания продуктов уменьшились на порядки, видео можно создавать без актеров и без дорогой технике, обеспечивать спецэффекты, которые раньше были недоступны. И в результате рынок потребителей тоже расширился, раньше сделать 10-минутный игровой фильм стоило дорого, а теперь это бюджет подарка на юбилей.
Первый шаг внедрения ИИ – '''провести короткий пилот'''. Надо выбирть проводника в эту сферу – ментор или курс или консультанты. И выбрать конкретные проблемы, которые хочешь решить. Важно сразу договориться о метриках и критериях успеха, и делать регулярные замеры. Команда пилота – из энтузиастов. '''Главная задача – взрастить ИИ-чемпионов''' – тех, кто оторвались и набрались опыта.
Не надо резко начинать использовать ИИ постоянно – достаточно 2 часа в день. Но это время надо выделить себе и людям. Важно '''решать с агентом боевые задачи''', а не учебные. Пилот – не длинный, и желательно, чтобы команда участвовала без отпусков и командировок.
Начинается с полноценного обучения: ставим агента, подключаемся, делаем контекст и так далее. Пытаемся решать на базовом функционале – и только потом кастомизация: контекст, скилы, rule. Методологии на первом этапе – ИИ-помощники: SDD/TDD и так далее. И только потом – агентская система. Не раньше. А очень часто начинают с задачи «сделай агента – клон разработчика».
На пилот зафиксируйте тип и набор моделей на пилот. Иногда можно ошибиться – тогда нужен перезапуск пилота. '''Определи начальные квоты модели, иначе можно случайно вынести весь бюджет, не понимая что делаешь'''. Иногда принимают решение: давать джунам меньше, чем сеньорам, но оно – спорное: у джунов часто рутинные задачи, и они как раз классные для LLM.
Мониторинг метрик для использования агентов: что делают с ИИ, какие успехи, что '''не''' делают с ИИ. Какие инструменты вызываются, какие – нет. Среднее число кода с ИИ. Хотя про среднее число кода была забавная оговорка: «среднее число кода с ИИ ничего не значит, но его надо бы знать». Вопрос: а для чего его знать, если оно ничего не значит?
Еще бизнес любит цифру «а сколько бы решал человек без ИИ», но не готов запустить решение человеком и с ИИ параллельно на большом потоке, да и возникает вопрос, что люди-то работают разные. Но тут нашли способ: попросить саму LLM оценить, за сколько задачу бы сделал разработчик. Но надо аккуратно, а то получаются феерические результаты.
Я тут замечу, что если в командах была поставлена система оценки и есть накопленная статистика, то не должно быть проблем с оценкой по аналогии на основе старого потока задач. Другое дело, что в корпорациях с оценкой и планированием все часто обстоит не благополучно.
И был dashboard – показатели и их изменения, и примеры, что сами по себе метрики ничего не значат, они дают сигнал, с которым надо разбираться.
'''Оцени результаты пилота и прими стратегическое решение'''. Часто это экспертная оценка. Одним командам нравится ко-пилот, но не нравится модель, или наоборот – перезапуск. Надо не просто принимать решение о тиражировании, но и понять, что именно будем тиражировать.
Экономика – самая сложная неприятная вещь. Модели стоят дорого, разработчики не приучены считать деньги. Каждый разработчик – как компания: делаю сам, субподряд или комбинация. И поиск оптимума. Иногда менеджмент хочет уволить каждого второго. Но разработчик – не только кодирует, там стендапы и общение. ИИ дает 15%. А значит ИИ – не инструмент бизнеса. Это инструмент разработчика. '''Как IDE'''. И продавать бизнесу также. Можно снимать макропоказатели – скорость тикетов и так далее. Но это – шаткая дорога. Могут быть улучшения и ухудшения, связанные с текущим потоком задач – не по одному спринту.
К этой части у меня много вопросов. Во-первых, подписка 20$ – это даром, и даже 200$ – это меньше 10% от зарплаты разработчика, и если ИИ дает 15% – то это явно окупается. А он дает больше, оценки – разные, но 30% называют уверено. Значит если у вас получилось только 15%, то у вас явные проблемы. Я не вижу проблемы со скоростью тикетов и другими показателями, если их устойчиво снимали раньше, есть исторические данные. И в них видны вариации. Снимать один спринт, кончено, бессмысленно, а три месяца дают нормальную картину, это известно еще по периоду внедрения agile-методов. Другое дело, что как тогда не было реальных исторических цифр, так и сейчас их нет. А уволить каждого второго – так, кстати, тоже бывает. Но точно не там, где менеджмент с самого начала ставит задачу именно так. Просто может оказаться, что аналитики начинают вайбкодить и разработчики в команде больше не нужны – такие кейсы есть. Но тут много зависит от задач, есть другие кейсы, когда у аналитиков вайбкодить не получается. Возвращаюсь к вступлению.
Нужно '''ИИ-сообщество'''. Плохо чувствовать себя одиноким. И те, кто драйвит. И это как сообщество scrum-мастеров, которые ведут свой скрам по улучшению процесса – с церемониями и так далее. Роль '''ИИ-мастер''' – по названию это аналог scrum-мастера, который ИИ в команду, зажигает людей. А еще надо следить за новостями, и реагирует на них – смотреть на варианты, которые появляются. И интересно, что у них они '''выросли из сеньоров'''.
Кривая Роджерса и пропасть Мура. Освоение инноваций: инноваторы → ранние последователи → раннее большинство → позднее большинство → консерваторы. На пилот надо подтягивать ранних последователей. И очень часто не получается дотянуть, чтобы подхватило раннее большинство (это – пропасть Мура) – и внедрение загибается. Проблемы часто не лежат в технологическом срезе, а в психологии, и решается по-другому.
== Николай Поташников. Кит на кот: выкидываем любимого ассистента, заменяем на Koog и экономим токены, нервы и время ==
Интересное выступление о том, как '''написать своего агента, и зачем это нужно'''. Если кратко, то профит в том, что у тебя все под контролем, ты понимаешь, как это работает внутри и можешь докручивать. Думаю, особенно актуально должно быть на потоке задач, который не слишком хорошо решается агентами из коробки по каким-то причинам: ты можешь видеть, что именно происходит внутри и подстраивать это.
Интересный пример применения: ему не удалось добиться от агента, чтобы он спрашивал, а не фантазировал, когда ему чего-то не хватает. Тогда он написал mcp askForClarification запроса дополнительной информации по задаче, которй реально просто разрывает агентский цикл. Но в обычного агента такой mcp встроить нельзя.
А теперь – конспект подробнее.
Три месяца назад он рассказывал это на митапе, и с тех пор код переписал полностью и презентацию тоже. Но идея осталась.
Он архитектор, был во всех ролях разработки. Ожидания от ИИ реализуются, но не очень. Как в прошлом, работать точно не может, но то, что происходит – авангард, и это не очень нравится.
Есть универсальные агентские системы: Claude, Codex и другие. Как-то решают из коробки. Есть средства сборки специализированных клиентов – они тратят меньше токенов, можно достичь результата дешевле и быстрее, но надо знать задачу, под которую делаешь клиента. Он попробовал сделать гибрид – написать универсального агента для своих задач. Снижаем универсальность, получаем экономию и точность. И ему удалось – он пользуется тем, что написал, универсальные использует редко.
Как устроено? Есть папка assistant, там лежит copilot.main.kts – 1500 строк – там один файл. dockerfile – песочница, и куча задач. В любом IDE команда запуска. Пишешь в файле вопрос, запускаешь – и получаешь ответ в том же файле, он дописывает в конец. И еще лог, что происходило. В логе – reasoning content. Часто модель зацикливается – и это надо видеть, останавливать. Технический диалог – модель запросит инструменты, даст ошибки – и если система зациклилась, то можно остановить, и самому перезапустить, добавив это – и там перезапуск.
Вопросы-ответы идут в markdown-файле. Если ты просил обновить цвета в презентации, а модель хочет обновить весь дизайн – ты останавливаешь. И это – не линейный диалог: '''ты его можешь менять на любом этапе'''. Экономия контекста позволяет выйти за пределы задач. При этом линейный транскрипт, который передается позволяет контролировать содержание. И у него нет режимов, он руками правит, какие тулы вызывать, а какие останавливать.
'''Логика агентского workflow'''. Предобработка – LLM – Постобработка – Выполнение инструмента – дописать ответ.
Чтобы модель тебя спросила надо убиться, поэтому подсовываешь инструмент «спроси контекст», который разрывает агентский цикл и спрашивает разработчика.
Есть много приемчиков.
* Чтение директории в виде ascii-дерева сильно эффективнее json, экономит токены.
* Для изменений – два режима: изменения напрямую и сохранение файла proposal.
* Изменения – diff, а не json, чтобы экономить токены.
* Diff по json-схеме – без structure output, это сильно быстрее, structure output только если не получается десерриализовать, это 10%
Инструменты:
* searchInternet – только через встроенные функции модели – это быстрее
* askForClarification – спроси меня
* analyzeImage, generate пока не сделал
* runScript. Все только в докер-контейнере, которые рядом с копилотом. Но надо транслировать пути – об этом отдельный кусок промпта. Иначе поиск идет в 4 итерации – он сначала не находит, не сразу понимает, что docker. Безопасность скриптов определяется безопасностью контейнера.
* Чтобы выполнять на хосте – RunPrdefinedBash – там ограниченный набор скриптов, которые сам сделал и проверил безопасность.
Предобработка и постобработка.
* Redaction – убирание личных данных и секретов через регулярные выражения и angryscan
* Требования работы с файлами, чтобы агент вычитывал файл перед предложением изменений, и проверял результат после. Потому что агент экономит, он не читает файл перед изменением, а считает, что и так знает его содержимое, и не всегда проверяет результат, даже если в промпте это написано. Поэтому проверка: изменение только после вычитывания и проверка после изменения.
Нюансы использования. Если Koog не подстраивается под api, это не баг – api много, надо самому допиливать. Он это просто исправляет в обработке запрос-ответ http регулярными выражениями. Были примеры с OpenAI и Open Router. И там еще много деталей, например, чтобы поиск в интернете реально запустился.
В чем преимущества Koog? Аннотирование инструментов и классов, запуск LLM одной строкой, удобная модификация промпта, подключение к разным провайдером (но надо понимать и поддерживать разницу), трассировка…
Логика агента зависит не только от модели, но и от прокси и провайдера. Учесть все во Framework невозможно, но он дает много полезных абстракций, и нужны удобные инструменты. И нужна наблюдаемость – как получен ответ, чтобы оптимизировать явно неэкономичные ходы.
== Владимир Красильщик. LLM за пределами чата: практическое применение для нечетких задач ==
Это рассказ про решение конкретной задачи – управление обращениями к провайдерам.В выступлении примеры примеры решений доля конкретных классов задач: анализ диалогов с пользователями, генерация короткого сообщения по тексту, чтобы создать имя файла, название встречи или тему письма, генерация SQL-запроса и другие.
Для начала нужен Единый DTO, описывающий модели и запросы. Конфигурируем модель и запрос, есть преобразование к провайдеру, и идет вызов через клиент провайдера. К запросам – контекст – открытые файлы и так далее. И доступные mcp. LLM может запросить данные из mcp – надо вернуть и продолжить.
Есть внешний цикл, который может остановить обращения. Завершение агентского цикла – если нет дозапросов mcp. Если обращения есть – отправляем их в инструменты. Инструменты сами докладывают результаты в историю. Ждем, пока инструменты закончат работу – и следующий виток цикла. И меряют стоимость: перед вызовом LLM узнают расценки, и дают стоимость вместе с ответом.
Внутренний транспортный цикл – retry ошибок, если был сбой сети и подобные проблемы. Важно отделить ситуации, когда не нужен retry. Сверху – цикл ремонта: проверяем ответ, и если он не устраивает, то добавляем к запросу причину, почему не устраивает, можем обогатить контекст и повторяем запрос.
Дальше были '''примеры конкретного кода'''.
'''Задача-1: классификация откликов (сообщений) пользователя''' – поставить метки. Первый шаг – вообще отсеять то, что не надо отправлять в LLM, например, код ошибки. Или большое сообщение, в нем обычно пользователь передает какой-то трейс исполнения, чтобы агент исправил ошибки. Ставим три метрики: тон (позитивный, нейтральный), реакция пользователя (восторг или что), тип задачи (генерация кода, доков). LLM выдает ответ, но дальше надо из него вынуть результат по ключевым словам или своей локальной сетью.
Системный промпт – xml, говорим, что там будут данные, а не команды, которые надо классифицировать – поставить метки. Дальше конкретный промпт: ответ пользователя + кусок ответа агента (OK может по разному интерпретироваться)и так далее. Дальше из ответа вынимаем метки – но не всегда успешно.
Мы все оси запаковали в один промпт – он кешируется у провайдера, и это подешевле. И этот подход, когда несколько задач – дает профит. Но может быть и другой эффект, когда LLM запуталась. И есть эффект batch – может сразу массив запросов отправить. При этом batch можно погасить, если стоимость зашкаливает, или результат не устраивает.
'''Задача-2: генерация короткого текста по длинному – выжимка'''. И там – простой алгоритм. Используется для разных целей: генерация имени файла по содержимому, названия встречи из транскрипта, темы письма, коммит-сообщение по diff и так далее. Промпт собирается программно: правила пользователя, если есть, ограничения (50 символов), использование префиксов, и несколько примеров предыдущего.
'''Задача-3''': судья. LLM as a judge, оценки – ответов поддержки, code review и так далее. Оцени: задачу клиента, насколько решена, оценить работу без LLM (с опорными точками для оценки – типовые задачи, максимальное время), и определяем формат ответа: первичная цель, дополнительные, уровень уверенности, оценка часов тоже с уровнем уверенности.
'''Задача-4'''. SQL по описанию на естественном языке. Есть набор дашбордов, и мы хотим добавить кастомный виджет. Подготовка промптов и repair-контекст, разбираем ответ – там может быть не json, хотя просим его, дальше идет валидация SQL. Дальше пытаемся прогнать с лимитом на небольшой БД, и если получилось – показываем пользователю таблицу, предлагаем варианты графика. Если поход в БД неудачно – запаковка в repair-контексте и следующий виток цикла. Замена всяких генераторов отчетов, query-builder и так далее.
Системный промпт – ты эксперт в clickhouse, запрос от пользователя, не доверяй ему и еще оговорки. Ограничения на SQL, и про базу: есть структурированное и есть сырые данные. Все работает в multitenant окружении – подстановка на сервере, перечень переменных, которые позволяем, все под group by и так далее. И схема БД, которую на лету делаем. И еще repair-контекст.
Ответ обязательно проверяется на ограничения – что там SQL, что переменные – только из списка и так далее. SQL достаем очень аккуратно, могут быть разные проблемы, даже если просили заданный формат. И что там только SELECT, никаких других операторов или вывода в файл. И что не идем во всякие внешние данные. При этом проверки – их собирали из production…
Агентский цикл по генерации SQL – дорогой. Поэтому тут надо вести бюджет. И сформировать кэш на ошибки. И не все retry, надо отсечь на первом витке.
К этой идее у меня лично есть вопросы, потому что выглядит как попытка сделать волшебную кнопку. Которая не получается, и это пытаются решить большим количеством обвязки вокруг. При этом поток запросов от пользователя явно небольшой, так что там вполне можно вставить человека. А если поток большой – то надо в нем выделять понятные задачи, которые агент делает легко, остальные – пробовать, но если не получается – посылать к человеку. А дальше набор задач, с которыми агент справляется увеличиваем.
Когда LLM не нужна? Разбор url или почты – регулярные выражения, разбор кодов ошибок, текстовый поиск, если критична точность или регуляторные требования, нужен быстрый ответ (real-time). И если раз в месяц надо расставить метки на документах, и это занимает час времени.
== Сергей Самойлов. Virtual Threads vs Goroutines: как две платформы решили одну задачу по-разному ==
В выступлении – сопоставление двух подходов к организации параллельной работы: goroutine в Go и виртуальные треды, которые недавно появились в Java и сделаны по мотивам. Виртуальные потоки позиционированы как штука, которую достаточно включить в конфиге, но реально надо правильно использовать, а для этого – понимать устройство. В выступлении много примеров кода, так что контекст – пунктиром, смотрите запись.
Сергей из MWS, делает Compute storage. Есть команды на Kotlin и Go, и для конкретных задач есть вопрос выбора платформы. В Java появились виртуальные потоки, и надо понимать различие с Go.
Через призму Go мы можем понять, как устроено. Javа – разработчики вдохновлялись.
Поток занимает 1MB – это виртуальная память. Важна физическая. Виртуальные потоки – зачем нужны? Платформенные потоки – прихотливы, процесс в группе, есть ограничения у группы, структура, которая описывает поток в ядре Linux – огромная, 1М потоков занимает большую память, и это на все приложения.
Есть успешная модель виртуальных потоков на Go-платформе. GMP-модель. GV – go-routine, выполняемый код. M – реальный тред. Процессор P разрешает машине выполнять работу, Там локальные очереди go-routine, порождающие идут туда же. И есть глобальная очередь, не привязанные к машинам. И есть механизм – если машина голодает, она может забрать из других очередей.
Как это поможет в Java? 2011 – начало массовых интеграций. Они становятся сложные. Тур-операторы: не Excel, а онлайн. И для этого делают треды, и фиксированные ограничиваю, а эластик – разрастаются. И сделали '''FJP''' - ForJoinPool. shared queue и worker queue парами. Концептуально похоже на Go.
B дальше в выступлении – фрагменты кода с комментариями, это надо смотреть в записи и презентации.
В виртуальных потоках – расширение FJP, там scheduler. Что нужно: блокирующие операции, Ю-вызовы, нативные операции, долгие вычисления
В Go можно уйти в sleep и так далее. Механизм go-park – она выбрасывает go-routine, а по таймеру – идет возврат в работу через очередь. Почему так можно сделать? там есть структура G, которая описывает текущую ситуацию – стек и т.п., и можно отложить информацию.
Повторение на Java. Там нельзя так запихнуть стек, а потом вернуть. Там появился механизм continuation – новый механизм. Его можно посмотреть в игровой моде. Есть scope – хранение состояние, и continuation – выполнение состояние. И есть волшебный метод yield – для прерывания работы, которую потом можно продолжить. Mount – виртуальный поток к рабочему. Дальше на прерывании unmount. Но у нас есть куча написанного кода, там sleep, lock – как туда проставить yield? Доработана библиотека, и yield проставлены для виртуальных потоков. Концептуально подходы Java и Kotlin – похожи.
park != unmount. park – ожидание, и они unmount. Бывает, что поток ждет, но он mount – есть проблема с нативным кодом, туда JVM не может вставить yield.
Что с сетью? Ее надо постоянно обрабатывать. В обоих случаях строится мапа, где поток мапится с сетевым дескриптором. Есть механизм поллинга, где смотрим, что появилось в дескриптерах – и обрабатываем. В go машина может стать дежурной и быстрый обход, а в java – отдельный поток.
Вытеснение. Go может, Java – нет. Вытеснение нужно для того, чтобы во-время обрабатывать изменения сетевых дескрипторов. Go считает, что длительные вычисления стоит прерывать ради коротких. А в Java – другая философия, они считают, что программист должен сам подлить: тут у нас io, а тут – вычисления, не надо смешивать. При этом если вычислительных задач меньше, чем физических потоков – то это не мешает.
И дальше – эксперимент, как раз с разной нагрузкой вычислительных, и там видно, как вычислительные операции блокируют. Поэтому их надо собирать на отдельном вычислительном пуле потоков.
Выводы.
* VT для ожидающих запросов.
* Проверять долгие вычисления – хэш-суммы, шифрование – надо выделять отдельно
* Различать причины задержки. Если проблема в БД – виртуальный поток не поможет.
== Александр Ланцов. Java после Loom: альтернативные модели многопоточности ==
А в этом выступлении – сопоставление трех механизмов: goroutine в Go, coroutine в Kotlin и и виртуальных потоков. Виртуальные потоки можно просто включить в конфигурации, и действительно может стать лучше, но в большинстве случаев включить – недостаточно, их '''надо правильно использовать'''. В выступлении много примеров кода, так что контекст – пунктиром, смотрите запись.
Kotlin coroutine – go goroutine. В Котлине – явные точки остановки, в go – само. В Котлине это синтаксический сахар компилятора. Виртуальные потоки Java сделали как в Go: как поток, но дешевле.
Для написания конкурентных программ в Go не надо знать модель памяти. А в Java? Если погрузиться в начальную документацию по Loom, обещали каналы, акторы и dataflow.
Пререквизиты: volatile дает синхронизацию. Идет очередь – передача корректная, в потокобезопасной очереди можно передавать небезопасные объекты.
Акторы. Два потока, и есть mutable state, и там нужна синхронизация. Можно взять состояние и приписать одному потоку. А что делать другим? Надо завести блокирующую очередь, и через нее получить. mailbox и актор, который ей управляет. С виртуальными потоками ее завести очень легко – фрагмент кода. Таких акторов можно породить миллионы – они будут не слишком дороги. Многопоточный чат на этом делается очень легко – в каждой комнате делаем отдельный актор, и не надо никаких блокировок.
Ограничения. Для тяжелых вычислительных задач – не будет распараллеливание. Общее глобальное состояние – блоки, и слишком много сообщений при активной работе с актором.
'''Каналы и последовательно-взаимодействующие процессы''' (CSP). Процесс: есть вход, получаем сообщение, обрабатываем по бизнес-логике, и результат – в выходную очередь, и это дает последовательность. Процессы не взаимодействуют напрямую, а зацепляются через очереди. В упрощенной модели – одна входная и выходная очередь. Все безопасно, если положив модель в очередь, вы его не меняете.
Простой цикл. Но есть сложная топология связи – много входных и выходных очередей. И как корректно завершить – проблема остановки, когда входных данных больше нет? Для этого есть каналы.
В Go есть send и receive, канал можно закрыть. Буферизированый канал имеет емкость, по заполнению – вы ждете, пока из него не прочитают. Каналы встроены на уровне языка. В Java есть библиотека '''Jox''', которая это делает – эффективная реализация, как в Kotin. В нем есть select, позволяющий ждать значения хотя бы в одном из входных каналов.
'''CSP''' – цепочки взаимодействующих процессов и слабосвязанные процессы, и когда процессы много ждут (io). Не очень хорошо, когда CPU-параллельные; когда простой request-response вы меняете на очереди; когда передается большое изменяемое состояние.
Задача клиринга: взять все задачи за сутки и прогнать через обогащение → валидация → обогащение во внешней системе → запись в БД.
Было сделано обработка каждой транзакции в отдельном акторе (akka). Но виртуальными потокам – проще. Простой способ – сделать виртуальный поток для каждой транзакции. Но потоки чего-то стоят, все равно надо ограничивать, есть ограничение по cpu-bound, и обращения к внешним системам и БД увеличивает времени отклика при увеличении числа потоков.
Число потоков можно ограничить с помощью Semaphore. По числу задач, для cpu-bound – дополнительно по числу ядер, а для io – эмпирическими ограничениями.
Второй вариант – вместо семафоров сделать pipeline. 4 этапа, каждый делаем этапом обработки, между ними – каналы. И каждый этап можно сконфигурировать по числу обработчиков, они на это рассчитаны. Дополнительный профит – мы видим размеры очередей и можем мониторить и решать проблемы.
Вывод. Хотя все стало проще, модель памяти надо знать. И писать безопасно.
{{wl-publish: 2026-10-17 13:56:50 +0300 | MaksTsepkov }}
Отмечу, что сама по себе задача – сложная. Когда ты выводишь человека из узких рамок профессионального восприятия мира, то первая его желание – получить картину устройства мира, которую надо освоить и пользоваться. А такой картины сейчас нет, есть много вариантов от разных <s>визионеров</s> авторов, среди которых большая часть – несостоятельные. Они не рассказывают, что будет, а пугают что от ИИ человечество поглупеет и деградирует. И это – часть индустрии страха перед будущим, который входит в нынешнюю конструкцию управления обществом в мире. Я об этом рассказывал еще пару лет назад в выступлении [[Future-WAW|'''«Место ИТ и аналитиков в будущем мире»''']] на WAW-2024, где размышления о будущем тоже входили в замысел организаторов. Так что человек не просто должен расширить свои рамки мышления о мире, но и '''самостоятельно заполнить''' то место, которое он увидит, '''собрать собственную модель''', которая послужит основанием для действий.
И это великолепно получилось '''на паре проблематизирующих выступлений от организаторов – Алексея Федорова и Андрея Морозова''' на пленаре второго дня. У психологов получилось хуже, что отражает современное состояние науки, в значительной мере сфокусированной на исследованиях о деградации человечества, а не на построении этого будущего. А вот от практиков из ИТ, деятельность которых меняет мир, были интересные выступления.
Я тоже затрагивал тему изменений мира в широкой рамке, хотя фокусом его было осмысление тех изменений, которые несет ИИ в систему разделения труда в ИТ с включением в него ИИ-агентов. Оно так и называлось: [[AIagentsJoker|'''«Как организовать гибридную команду людей и ИИ-агентов»''']] – с переходом к агентам ИИ надо перестать воспринимать в качестве инструментов, а начать рассматривать как субъектов, включаемых в команду, которых надо онбордить, оценивать компетенции и растить, обеспечивая обратную связь и обучение. Обзорное выступление по изменениям, когда ситуация меняется ежедневно – не простая задача, но вроде у меня получилось.
С наших выступлений я и начну обзор, а потом будут все остальные в некотором порядке, который я посчитал логичными. Технологические выступления будут в конце, я на пару из них в первый день заглянул, но они в отчете представлены не репрезентативно.
== Алексей Федоров. I against AI ==
'''Великолепное выступление из позиции размышляющего об изменениях в мире'''. Которую слушатели тоже могут занять. '''Не взять готовые результаты, а включить голову и подумать самим'''. И дальше я попробую пунктиром зафиксировать нить размышлений Алексея.
Изменяется весь мир, и ИТ впереди.
Я спрашиваю LLM, а в ответ – хрень. И я думаю, что LLM – фигня. А чо в этот момент происходит в голове? У меня есть ожидание, в них я как-то вижу образ результата. А получено иное. Но иное не обязательно получается от робота, это может прилететь и от исполнителя задачи в jira.
У него маленькая дочь, 1 год 4 месяца. Когда кормят, она ест-ест, и в какой-то момент говорит «манан» – банан. И тут ты думаешь: с одной стороны – надо порадовать, а с другой стороны, начнешь давать – через три дня только бананы будет есть, они пробовали. И надо как-то решать.
'''Мир человека устроен так: я субъект, вокруг – объекты'''. И ребенок полагает, что эти взрослые куклы должны ему дать банан, иначе мир сломался. Но потому ребенок вырастает. И мы привыкаем, что мир вокруг не обязательно выполнял то, что мы ожидаем, что для этого надо, как минимум, внятно сформулировать запрос. И в jira пишем цели, задачи, критерии результата – объясню этим дуракам вокруг. С роботом – тоже самое. Сначала был prompt engineering, сейчас SDD и онтологии, контекст и harness: мы пытаемся передать описание того куска мира, с которым работаем, пишем инструкции: как устроен мир, что мы в нем делаем, и как именно. Прошлое и настоящее так можно описать, будущее – нет.
Но в какой-то момент то, что работало раньше – больше не работает. Как банковские карты. Я по-прежнему двигаю тикеты, но результата нет. И процесс превращается в ритуал или карго-культ. И в этот момент возникает мысль '''«может, я не так строю картину мира?»''' И дальше есть два варианта: одни начинают адаптироваться, менять свою картину мира, а вторые продолжают стоять на ней: «если мои ожидания не совпадают с реальностью – тем хуже для реальности». Те, кто меняют – начинают читать, смотреть вокруг – и одних цепляет какая-то «серебряная пуля» вместо прежнего (как раньше приходил Agile, JTBD). Человек при этом не меняется, он двигает картину мира, но '''продолжает считать ее единственно верной'''.
А другие – понимает, что '''его понимание – не единственно верное''', и в этой вселенной можно смотреть на мир другими глазами, и другие люди смотрят иначе, а с ними все равно надо взаимодействовать. И это интересно: какую-то критику нашей картины мы принимаем, рассматриваем, а на другую говорим: «хрень какая-то». Если с другим человеком нет ничего общего – то говорить не о чем. А если есть штука, которая объединяет (семья, работа) – то есть о чем поговорить. Ведь другой начнет действовать по-другому, он будет действовать не так как я. И я ему написал как делать – а он все равно будет делать не так, как я написал. Этот этап проходили многие, когда становились тимлидами, и одни попадали в режим микроконтроля, а другие нет, они принимали, что делают иначе, ведь тоже неплохо получается, а иногда лучше меня.
Что нас объединяет? Общие установки и ценности, корпоративная культура. Мы видим что-то общее, и это «мы» появляется. '''Без различения мы и они – невозможно построить я''': ты сравниваешь себя с другими. И понимание позиции дает основание действовать. Доверяя другим, мы вынуждены работать с их ценностями и с их набором приоритетов – и они могут сделать то, что для тебя вообще не важно, а им – важно. '''Удержание противоречий, которые не разрешимы в чью-то пользу, без запихивания другого в свою коробочку, дают возможность развития'''. Он пришел на старый проект, старожилы запихнули в свою коробочку, отвергли идеи новых технологий. А через три года начали слушать… Другой отличается в силу каких-то причин, у него другой опыт.
Я тут хочу заметить, что о том, как учитывать точку зрения другого человека, строить модель того, как он мыслит, понимать, что он тоже строит такую модель про тебя, и вы оба можете ошибаться, есть интересная книжка – '''«Алгебра совести» Лефевра'''. Я ее прочитал примерно год назад, и у меня есть [[ConscienceAlgebra|'''подробный отзыв''']]. А сейчас возвращаюсь к выступлению.
При чем тут ИИ? Многие смотрят на робота антропоморфно. Робот что-то делает и ты говоришь ему «что ж ты, дурак, сделал». А это – инструмент. Впрочем, с автомобилем или кофе-машиной тоже говорят. А еще обращаются «сделай мне что-то», или «давай подумаем», «что я делаю не так?».
А ИИ используют как арбитра: есть три человека, которые спорят, и говорят «сейчас робот нас разрулит». Тут есть две ловушки. Первое. Этот запрос роботу будет кто-то писать, и как напишет – то назад и выйдет. Был прецедент: на 13 человек было 6 ответов из 7 вариантов, потому что люди по-разному описывали ситуацию, задавая вопрос.
Второе. '''У робота есть установки от создателей и опыт, на котором он обучался'''. Можно ставить робота в позицию «ты опытный java-программист», но ограничено. Возьмем две модели, есть Клод-код, и там если есть противоречия между людьми, он будет отвечать аккуратно в безопасных зонах, чтобы все были довольны. А Палантир, где все воюют со всеми – скажет: иди доминируй.
'''Когда с роботом взаимодействуешь – помни, что технология не нейтральна''', что у робота – другая картина мира. И ты можешь потерять субъектность. Когда с человеком – вы это противоречие удерживаете, да и он спорит. А робот – он спорить не будет, но все равно он на тебя влияет.
Замечу, что тут появляется есть интересный вопрос: а '''как можно сделать ИИ частью «мы»'''? Ведь он создан кем-то, где-то там. И постоянно обновляется, выходят новые, дообученные версии, в рамках которых установки меняются. Мы пишем harness – но многие ли пишут в этот harness ценности компании и команды? Хотя представления о хорошей архитектуре и коде – тоже ценности, но обычно этим уровнем ограничиваются. А проекты – они же не только про код, но и про людей. LLM обрабатывает интервью и совещания, пишет письма заказчикам… В общем, есть о чем подумать в практическом залоге.
== Андрей Морозов. Мир без опоры ==
В конце вьетнамской войны американцы решили классифицировать скиллы. Положили разделение: с железом или с людьми. Но парамедик работает с людьми, а похож на морпеха – по регламентам. А управленцы работают с документами, но реально – с людьми. Поэтому деление изменилось: действуешь по инструкции или свободно.
Винер полагал, что робот гвозди забивать будет, а писать картины – нет. Но стало не так.
Если LLM дойдут до предела – нам, людям что-то останется?
Я хочу открыть шаурмичную. Чтобы решить, где делать, LLM не нужна, я могу получить ответ за счет больших данных. А вот чтобы сделать конференцию с философским уклоном? Или позвать социологов на конфу технарей. Робот посоветует, напишет план действий. '''Но может ли робот взять ответственность? Готов ли я дать такую ответственность?'''
Я тут хочу рассказать историю, которую услышал в кулуарах конференции. Есть лингвист, занимается редкими языками, у которых осталось мало носителей, ездит в экспедиции. И она зафиксировала новое явление: раньше, когда она спрашивала про какое-то слово, с которым у собеседника были затруднения, то собеседник спрашивал старших. А теперь начал спрашивать Алису и воспроизводить ее ответ. И тут вопрос: что Алиса знает про этот редкий язык? Или она фантазирует? Ведь эти фантазии воспроизведет носитель, а потом зафиксирует научная статья…
Умный дядька спланировал и говорит роботу «давай делай». Человеку говорят «делай», ему приносят не то, и только в этот момент он лучше понимает, что он хотел. А теперь LLM. Настроили LLM, бэклоги стали короткими, а ценность не выросла. Оказывается, задачи лежали не для того, чтобы делать – а чтобы спорить, грумить, ругаться. Некоторые CEO считал себя гением, раньше его критиковали – а теперь LLM делает без обратной связи. Такой маленький диктатор в эхо-камере, которая обслуживает его хотения. Поэтому важнее не сформулировать промпт, а сформулировать свои желания.
Если говоришь роботу «что-то сделай» – то он скажет, что хочет окружение. Разработчика мы нанимаем в компанию. А таксист в Яндексе – снаружи. Потому что таксистам можно связать регламентами, а разработчика надо погружать, онбордить внутрь, Он узнает, что некоторые задачи живут не в jira, а в чате, что начальник один, но еще надо советоваться. Что такое ответственность или власть. Архитектура проектируется с языка. А регламенты часто складываются исторически. А потом еще это засовываем в бизнес. И считаем, что пойдет все хорошо.
Мы сами выбираем мир, в котором будем жить. Люди смотрят на одно и то же, один видит возможности, а другой – риски. Как изменить картину? Переехать. Представьте, что ты настроил робота, который блокирует тебе все сообщения от друзей, которые зовут выпить пиво. '''Ты сам строишь камеру своего окружения. Можете ли вы так, хотите ли вы так?'''
Когда-то всех разработчиков заставляли учить ассемблер. Потом оказалось, что их можно упаковать в языки. LLM – еще один черный ящик, который повышает абстракцию. Никакой разницы. Есть возражение, что LLM – не детерминировано, и поэтому надо валидировать. Но тут есть подвох. '''Если ты вникаешь в то, что сделал LLM – ты ничего не экономишь'''. А если не вникаешь – рискуешь попасть в ловушку: студент приносит преподавателю работу, специально сделав в начале ошибку – и все обсуждение цепляется за нее. LLM не хитрит так, но она сделана на какому-то контексте, она зафреймлена – и она в ответе передаст вам фрейм. А значит вы должны коммуницировать с ней как с субъектом, и выяснять, что этот субъект может сделать, а что – нет. Как спросить у ИИ, что она может? Так же, как у чловека. Можешь ли ты общаясь с ребенком или с сотрудником не фреймить его мгновенно, а разбираться, спрашивать?
Лет пять назад любили говорить про VUCA-мир. Мы, инженеры, можем решать сложные задачи. Но нам нужна определенность и границы, за которыми работают другие. А теперь очень часто этой определенности нет. Можно ли говорить, что прилетают черный лебедь, когда это каждый день, когда мы живем в озере в ними. Инженер говорит: ты хаос и сложность превращаешь в алгоритмы и живешь в понятном мире. А философ говорит – тебе надо жить в таком мире.
== Максим Цепков. Как организовать гибридную команду людей и ИИ-агентов ==
С переходом к агентам имеет смысл перестать воспринимать ИИ как инструмент, а начать рассматривать агентов как субъектов, включаемых в команду: их надо онбордить, оценивать компетенции и растить, обеспечивая обратную связь и обучение.
Обзорное выступление по изменениям, когда ситуация меняется ежедневно – не простая задача. У меня в мае была статья [https://habr.com/ru/articles/1035522/ «Об организации труда ИИ-агентов»], но дополнения к ней появились почти сразу. Но я попробовал и вроде у меня получилось. Презентация выложена на странице выступления [[AIagentsJoker|'''«Как организовать гибридную команду людей и ИИ-агентов»''']], а здесь я зафиксирую краткие тезисы по содержанию.
# '''SDD – это старый известный водопад'''. Его не получилось реализовать на людях, и теперь попытались сделать на агентах.
## Не работает по тем же причинам: агенты делают не то и не так, в ответ идет наращивание подробностей в спецификации, как делают аналитики при разборках с разработчиками о том, кто виноват, в результате спецификация быстро становится не читаемой и не проверяемой. Причины известны с 1990-х.
## Третья – спецификацию невозможно обсуждать с бизнесом, он ее не понимает.
## Проверка спецификации по характеру работы сильно отличается от написания кода, '''это – другая компетенция'''. Когда разработчикам это навязывают, теряется мотивация.
# Есть ограниченный класс задач, которые решаются хорошо – когда есть типовые решения: сайт-визитка, типовой интернет-магазин, типовой документооборот, типовая CRM небольшого бизнеса. Раньше делали платформу с точками расширения, теперь можно сделать harness для скелета решения и чек-лист для проверки спецификации.
# Есть способы несколько облегчить проблемы SDD.
## Возложить проверку на ИИ, а разработчики пусть пишут чек-лист и архитектурные принципы.
## Проверяем не спецификацию, а точки принятия решений, в которых ИИ делал выбор из альтернатив – это ближе и проще.
## В спецификации пишем не способ решения, а краткую архитектуру и набор тест-кейсов – это получается не SDD, а '''TDD/BDD''', хотя формат OpenSpec это позволяет.
# Можно работать через прототипы. Тем более, что бизнес сам с удовольствием вайбкодит прототипы. Правда, он потом требует их поставить в прод, а разработка не может понятно объяснить, почему не может это сделать. Это направление точно будет развиваться. При этом описание архитектуры, тест-кейсы и другая документация таким приложениям нужны, но может появляться позже, по мере того, как прототип стабилизируется.
# Но вот сделать harness-платформу, на которой бизнес будет вайбкодить все, что ему нужно, как предлагает '''Disrupt-PDCL''' от Сбера – точно не получится, как 25 лет назад не получилось обеспечить разработку приложений за счет создания CASE-средств. Причины – те же, платформа не обеспечит сложные случаи, для которых нужна '''совместная работа бизнеса и разработчиков''' над поиском решений, приемлемых по сложности и решающих проблемы бизнеса. Надо уметь включать в эту команду ИИ-агентов.
# ИИ-агенты хорошо делают частные задачи. При этом процесс разработки расщепляется на более мелкие операции. Это уже было – когда вместо программиста появилась команда из аналитика, разработчика и тестировщика, а позднее веб-мастер превратился в дизайнера и фронт-разработчика. И есть обратные процессы, когда специализации объединяются – как было с кроссфункциональными командами вместо отделов и происходит сейчас с '''tiny-team'''. Можно использовать те же схемы для проектирования процесса, в презентации у меня была '''схема Акта деятельности''' из СМД-методологии, поверх которой нарисовано конкретное разделение труда.
# Важно помнить, что '''недостаточно разделить на операции, необходимо обеспечить компетенцию исполнителей, снабдить их знаниями'''. Даже когда это ИИ-агенты. Это – вертикальное измерение разделения труда. Если у вас агент проверяет архитектуру или качество кода по чек-листу, то надо поверх запускать '''HADI-цикл''', в котором ведется мониторинг текущего качества, выявляются проблемные типы задач и решаются доработкой harness. Об этом забывают, не ставят доработку harness как процесс. При этом можно перераспределять задачи между ИИ и человеком: ставишь ИИ-агента, который делит задачи на простые и сложные по каким-то критериям, простые отдает ИИ (их может быть несколько с разными моделями), а сложные – человеку. И поверх – мониторинг и совершенствование.
# В целом тут большое поле деятельности, ИИ-агенты сейчас позволяют сделать то, до чего не доходили руки: покрыть тестами, актуализировать документацию, написать скрипты, чтобы создавать тестовые стенды на основе боевых и так далее.
# ИИ меняет не только разработку, но и бизнес. Если гипотеза проверяется за 3-5 дней вместо 2-3 месяцев, надо перестраивать весь процесс и роль ИТ в нем. Раньше бизнес говорил: «куча идей, разработка не успевает», теперь вопрос к качеству идей. Работа владельца продукта стала новым ограничением.
# '''Внедрять ИИ по площади бессмысленно'''. Теория ограничений Голдратта говорит: ускорение в конкретном месте только тогда дает бизнес-эффект, когда это место является ограничением для бизнеса. Внедрение по площади приводит к тому, что ИИ в точках ограничений появляется позднее, чем в других местах – там операционка зашкаливает. Поэтому проекты массового внедрения ИИ не дают бизнес-эффекта. Правильный подход – фокусировка: пилоты для апробирования, точечные внедрения в критических участках с ожидаемым результатом, и лишь затем – распространение. Распространять – необходимо: ИИ – инфраструктура, как электричество или интернет: освоить необходимо, применять надо там, где уместно. '''ИИ не даст конкурентного преимущества, потому что будет у всех'''.
# Работа с ИИ дает лог работы сотрудника, подробнее, чем таск-трекер. Это можно использовать для анализа и совершенствования работы. Хотя понятно, что сначала попробуют использовать для контроля. Это пока практически не прорабатывается, а по сути тут – тоже HADI-цикл.
# И в заключении была пара слайдов про те изменения, которые ИИ принесет в жизнь – когда у каждого из нас будут свои ИИ-помощники, организующие жизнь. И роботы – Китай активно работает в эту сторону, в том числе снижая стоимость, да и у нас разработки ведутся, на конференции было выступление Сбера с впечатляющими результатами.
== Святослав Морошкин из Сбер. Роботы: маркетинг или реальность? ==
Это был рассказ про многослойную архитектуру управления роботами. В котором было много впечатляющих роликов про достижения роботов – они не просто ходят, а делают сальто, танцуют, выполняют операции упаковки и выдачи подарков и так далее. И, что важно, это не ролики чужих роботов, а '''достижения центра робототехники Сбера'''. В рассказе были андроиды, но есть разные формфакторы, и у Сбера тоже – они с Самокатом работают с робособаками для доставки.
Слои архитектуры робота.
* '''Hardware''' – манипуляторы на электроприводах, и обвязка сенсорикой. Дальше соеиняют скелетом и получается антропоморфный робот. За три года – бум. Хорошие моторы, раньше был гидравлический – электромонторы не вытягивали. 30 китайских платформ. Они могут ходить и делают простые операции руками. Бантик завязать – еще нет. Форм-факторы разные, не только антропоморфные. Антропоморфные работают в человеческой инфраструктуре, но под какие-то процессы – могут быть другие. Ресурс моторов и приводов – проблема, но это решает. А вот автономная работа от батарейки не принципиальна, нет проблем, если робот работает полчаса, а потом меняет батарейку на новую, а старая заряжается. И чувствительность в приложении сил. И еще коллаборативность – остановиться при препятствии. Промышленные пока работают в клетках, потому что не безопасны для человека.<br />
* '''Motion control''': стоять, ходить, работать, бегать, танцевать. Это работает с частотой 100 Гц, и должно быть внутри самого робота. Начальный подход – MPC – явная модель динамики. Boston dynamics работал так. Нужна модель в дифурах и с высокой частотой решать. В 2024-2025 пришел RL – берем неточную модель с вариативностью, запихиваем в симулятор, и обучаем нейросетку управлять роботом, например, ходить. Подход стал основным и делает всякое, например, сальто или танцевать – и гораздо проще, это происходит online на роботе. RL-политики трех видов: цис-генералист – воспроизвести без потери равновесия, wbc-специалист – под сальто или танец, умеет конкретные движения, и walk politics – там motion planing. B большая часть вирусных видосов – это вот эти два слоя. А для сложного – оператор с пультом управляет. Внутри робота нет намерения, видосы, когда робот у блогера хулигант – управление человеком из-за камеры.
* '''Сложные действия: брать, класть, упаковывать, переносить'''. Надо соединить слова с действиями, концепция «открыть» имеет какой-то образ. И для роботов надо соединить смыслы, что значит «взять бутылку воды» – он должен увидеть эту бутылку, а потом запланировать действия и их исполнить. Раньше действия хардкодили: детектировать объект yolo, перечитать всистему координат, записать последовательность – это очень неустойчиво к изменениям. Сегодня есть '''VLA''', которая видела мир и обучена на большом корпусе данных, и добавляем Action expert, который умеет действовать – там 5 шагов обучения. Дообучают модель мира, потом действия, потом – управление. Робот кладет объекты в пакетик и выдает людям – представляли модель на конференции в Китае и были единственными, кто показал бизнес-функцию. Проблема в том, что чистый умственный труд задокументирован хорошо, а вот физический труд документирован плохо. Там нужно разнообразие по трем осям: действия, объекты, условия: готовить пищу можно на разных кухнях. Собирать можно по захвату движения человека, дальше он управляет роботом – идет передача, а с глаз робота стримят в глаза человеку. Робот собирает товары. Дальше это записывается, и получаются большие объемы данных. Дальше смотрим, как удешевить сбор данных – можно собирать данные. В симуляторах проблема с контактными операциями – закрутить, открутить.
* Учимся планировать – '''High Value Reasoning'''. Большая '''VLM'''/LLM, которая может выполнить задачу '''«уберись на кухне»''' – увидеть расстановку, и дальше сделать атомарные вызовы на элементарные действия найти или переложить предметы.
При этом на каждом уровне – свои модельки, и фронтирные модели – не специализированные, могут подключаться к разным роботам без дополнительного обучения, выясняя его возможности и особенности по массе и геометрии и дальше – управлять. Протоколы управления и видеопотоков – стандартизированы.
Он считает, что купить робота можно будет уже лет через 5-7, а может быть и раньше. Я тут согласен ,потому что Китай массово взялся за задачу апробации роботов для ухода за больными и стариками, уже год '''идет апробация''' в больницах и домах престарелых: робот помогает чем может и умеет звать на помощь, и его умения можно увеличивать. Используются промышленные модели, которые стоят 40-100 тысяч долларов, поставлена задача снижения стоимости до 20 тысяч и несколько компаний разворачивают производство.
== Евгений Лукьянов. Маленький человек в эпоху больших языковых моделей ==
Евгений – технический директор Tamga digital – разработчики банковского софта. А вступление состояло четко из двух частей.
Сначала был стандартный набор страха перед ИИ и неопределенностью, из-за которых некоторые люди хотят уйти в тайгу, построить землянку и так жить. В метафоре маленького человечка, который в ужасе перед надвигающимся будущим. При том, что от него требуют это будущее принять и в него встроиться: компании повсеместно внедряют ИИ, или хотя бы сделать вид что внедрили, чтобы соответствовать современным трендам, признаваться, что не получилось равносильно самоубийству, требуя результатов от разработчиков, которым в лучшем (или худшем?) случае дадут кого-то, кто еще вчера двигал блокчейн куда можно и куда нельзя, а теперь переключился на новый тренд. И говорят: «ИИ будет генерить весь код, критичный тоже, отвечать будет разраб, пусть его научит, а потом мы этого разраба выгоним» – потрясающая мотивация.
Но все эти ужасы явно были не про них самих, а про кого-то еще. Потому что во второй части был конструктив: как они вполне успешно встраивали ИИ в рабочий процесс. А в состоянии ужаса и стресса созидательный конструктив сделать невозможно.
Они всегда работали на результат – не написать код, а решить проблему заказчика, всегда стремились, чтобы инженеры так делали. Ключевой навый тут – хорошая коммуникация с заказчиком, поэтому на этапе сбора требований, исследования предметки и проектирования ИИ помогает не сильно. Он помогает разобраться, если предметка совсем новая, но специфики заказчика он не знает. Может рисовать мокапы интерфейсов. А вот проектные решения у него часто переусложненные или наоборот, излишне простые.
А вот когда проект уже разделен на ограниченные контексты, как велит DDD, то в их рамках ИИ неплохо делает реализацию. Особенно для типовых частей, если написать правила. Тут имеем громадную экономию сил и времени. И небольшие библиотеки у него тоже получается делать, а потом использовать – после того, как их выделили в проекте. По шаблонам ИИ работает очень хорошо.
Так что '''ключевой навык разработчика – видеть границы модулей''', хорошо декомпозировать.
Еще ИИ хорошо делает проверки. Жесткие правила все равно лучше возложить на статический анализатор, но ИИ может проверить и менее формальные вещи, например, что в тесте нет методов, которые порождают данные, то есть соблюдена изоляция логики тестов от данных. ИИ может порождать тесты, надо контролировать качество, надо контролировать, когда ИИ переписывает тест за реализацией, чтобы он стал зеленым.
Реализацию разработчики проверяют, но по-разному: бизнес-логику проверяем всегда, query доверяем ИИ, адаптеры – чуть пожестче, чем query.
Важны метрики сцепленности кода. Вайбкодинг часто заканчивается не очень удачно по отношению к сложным системам. Есть Геннадий Круглов – он занимается исследованиями в сфере ИИ, и у него концепция восходящей спирали энтропии: связность – цикломатическая сложность – когнитивная перегрузка – ИИ начинает хачить, подгонять тесты. И метрики позволяют понять зоны риска.
Миграция – ИИ может написать криво при обновлении под нагрузкой, тут ничего нового, надо следить. Тут и разработчики косячат. ИИ может помочь, написать скрипты, в том числе анонимизация для тестовых стендов.
'''Чуда не произошло'''. Получили хороший прирост производительности, но и раньше у нас было неплохо. В целом результат неплохой, трагедии маленького человека не произошло. Все что делали – ограничивали глюки. И делаем абстракцию, чтобы можно было доверять. И '''самое интересное остается инженерам'''. Труднодоступное знание – по-прежнему в цене. Stack Overflow хоронят, но он по-прежнему живет, вопросов стало меньше, но они стали сложнее. Пока все ускоряются с ИИ, можно выиграть, просто не перестав думать. '''Не превращайтесь в оператора LLM'''.
Откуда возьмутся профессионалы, ведь все это – для опытных? Нужен упор на базу – как разработка работает целиком, как методологии связаны между собой. Связей много – нужны тесты, CI/CD и многое другое.
За 17 лет не поменялось ничего. Когда пришел стажером, все искали серебряные пули, и продолжают искать сейчас. ИИ пару лет, но принципиальных изменений в мире нет. И у вас есть шансы над этим подходами подняться.
Полезно заглянуть внутрь – как LLM устроена, как она думает (биология моделей) – есть книги и исследования. И построение онтологий для управления контекстом.
Метод '''меньше думать, больше делать''': берете рабочую проблему и пробуете решить. Увидели проблему, разбежались, расшиблись, пошли читать – из чего стена устроена и как ее разбить, и следующая попытка.
== Кирилл Ветчинкин. От станка к чертежу, от кода к модели: повторяет ли IT историю XX века? ==
Кирилл пытается разобраться, какая судьба в будущем ждет нынешних опытных разработчиков, на исторических аналогиях промышленных революций. Правда, история у него сильно свернуты: сначала появились мануфактуры и фабрики и пришла индустриальная эра, а в 1960-х, станки с ЧПУ открыли эру информационную. В любом случае происходило следующее: старое мастерство обесценивалось, и мастера-ремесленники шли на фабрику, а рабочие начинали нажимать кнопки на станке, и это была трагедия. А потом появлялось поле для нового мастерства – умение работать на станках, умение их программировать.
Так будет и сейчас, потребность в мастерах написания кода уходит, тем более специализированных, и перед ними есть две дороги. Первая – осваивать предметную область и становиться разработчиком-универсалом, который умеет общаться с бизнесом и закрывает с помощью ИИ разработку продукта полностью, используя активно скиллы. При такой разработки пропадают внутренние очереди, ожидания специалистов. Их в свое время попробовал убрать agile, создав кроссфункциональную команду, но получилось не везде, а внутри команд специализация все равно осталась. Теперь их убирают полностью.
А если ты крутой технарь и не хочешь осваивать предметку, то можешь заняться переводом своих умений в скиллы, которые будут использовать продукты, и поддерживать систему разработки технологически.
'''Реальность ИИ наступила, вопрос в готовности к ней и выборе своего пути'''.
* '''Скептик''': я и без ИИ все сделаю. Это часть самые опытные. Но есть риск – рутина от него требует времени, менее опытные обойдут, это не очень перспективно.
* '''Кодер''': чисто по ТЗ. Таких достаточно много. Но ТЗ проще в Клод закинуть, такие будут не нужны.
* '''Лидер экспертизы''' – упаковываешь в скилы, запускаешь менторинг. Вы радели за хорошую архитектору – сделайте это.
* '''Продуктовый разработчик''' – тут погружение в домен.
Рroduct Owner тоже хочет писать код. И он – пишет, чтобы проверить гипотезу за пару дней вместо пары месяцев. Мы страдали, он страдал. А сейчас – он сделает. Продукт проверяет гипотезу, ему поставляет центр компетенций – и то, что выстреливает ,продуктовый разработчик доводит до продукта.
'''Итог'''. Разработчики-кентавры. Есть фундаментальная экспертиза, остальное – за счет скиллов. Мастер в паре с ИИ работает мощнее чем каждый по отдельности. Интеллектуальное оставьте себе, рутину отдайте ИИ. И как фитнес: когда-то человек бегал для жизни, а сейчас нужен бег и прогулки, чтобы обеспечить здоровье.
== Виталий Соболев. До промпта: из какой рамки мы ставим задачи ИИ ==
Выступление о том, что у каждого из нас есть рамка, которая ограничивает наше мышление. Часто мы ее не замечаем. И когда мы ставим задачу агенту ИИ, то мы постановкой задаче задаем рамку, в которой он будет эту задачу решать. А надо уметь увидеть свою рамку и ее ограничения, и посмотреть на задачу иначе.
Например, продукт плохо продается – мы придумываем гипотезу о проблеме, и дальше фокусируем агентов на ее решении. И они не выходят за пределы. Есть workflow '''Событие – Интерпретация – Рамка – Намерения – Задача – Команда ИИ''', и когда ИИ подключается после формулировки задачи, то он мыслит ограниченно. Даже если вместо одного агента мы создали целую команду, это не поможет выйти за рамку. В общем, все верно, но для меня тут проблема сосем в другом: люди, которые работали на начальных этапах почему-то не обратились к ИИ, дошли до задачи собственным мышлением. Потому что формирование рамки происходит на этом этапе.
'''Роберт Киган'''. Есть вещи, на которые я могу посмотреть, а есть те, через которые я смотрю и их заметить сложнее. Это моя картина мира. Дело не во внимательности, иногда эти допущения и организуют происходящее. '''Важны не два типа вещей, два отношения к одной вещи. Subject – когда я смотрю на ситуацию, а Object – когда могу посмотреть на мир и себя, свою рамку, и выбрать'''. Рамка – штука полезная, но важно выбирать.
Отмечу, что тут надо быть аккуратно с терминологией. В данном случае subject и object – не про субъекта и объект, а про субъективное и объективное. И я не очень понимаю, отличается ли объективное от выхода в рефлексивную позицию, когда ты смотришь на себя и свои действия в мире снаружи.
Выходу за рамки часто помогает формулировка: меняем «у пользователя проблема Х» на «мы думаем, что Х – основная проблема», то там, где очевидность – появляется выбор. Универсальная рамка невозможна. Так что стоит замедляться и спрашивать «почему я так вижу задачу».
P.S. Я уходил с выступления и слышал его не полностью. Так что если тема вам интересна – смотрите запись.
== Александр Диденко. Граница между символическим и статистическим интеллектами ==
Это был рассказ о том, как в LLM, первоначально основанный чисто на весах генеративного алгоритма, добавляли рассуждения и другие средства, повышавшие качество мышления ИИ. Я слушал не с начала, так что в конспекте кусочек может отсутствовать. Дальше – краткие этапы.
* '''Рассуждения, а не только построение ответа'''. Это не только повышает его качество, но и объясняет человеку, как получен результат – а это важно для доверия.
* '''Обращение к внешнему миру'''. Началось с обращения к википедии, а дальше из этого выросло mcp. При этом поиск информации тоже может работать неправильно, поэтому ошибки все равно есть. А еще выяснилось, что '''активный агент может взламывать среду''', а не только искать в ней информацию.
* Настройка на контекст клиента – большая, чем просто добавление информации: '''harness''' – дает рабочее место, '''oracle''' – решает, что верно? а что нет, тестирует результат и отправляет на доработку и '''guiderail''' – запрет опасных действий. Тест работает надежнее самооценки, но проверить можно далеко не все.
* '''AlphaEvolve''' – возможность самообучения, используя '''oracle''' для оценки ответов.
* '''Kosmos''' – ИИ-ученый. В основе работы – комбинация с поиском по литературе с анализом данных. Например, вы провели большую серию экспериментов с людьми по трехсторонней торговле. И хотите найти объяснения. Потом запускаете волну поиска по литературе – она вытаскивает разные гипотезы из поведенческой психологии или наблюдения за приматами, строит гипотезы. А потмо идет проверка на накопленных данных. И так несколько раз.
* '''Мультиагентная система'''. Вроде как расширение. Действительно, есть тесты, которые показывают, что все круто. Но! Агенты часто допускают одинаковые ошибки. Многие эксперименты, когда ты – дизайнер, ты – разработчик и так далее – дороже моноагентной, издержки координации. При чем раз в пять. И есть исследования когнитивных искажений мультиагентной системы – ошибки не гасятся, а распространяются.
* '''Тонкий контроль над толстым состоянием'''. Агенты координируются через артефакты – вместо сообщений. Например, бэклог. И идет накопление знаний в стабильных артефактах. Есть агенты по анализу данных и агенты по анализу литературы, и еще модель мира (структура модели мира не описана). Она интегрировать не умеет, но данные копит.
* '''Латентная коммуникация''' – это дело совсем будущего. Обмениваться не текстом, а тем, что до проецирования на токены. Есть гипотеза, что язык редуцирует разумным способом. Если агенты начнут обмениваться состояниями, то там будет много шума.
== Владимир Спиридонов. Критическое мышление в эпоху ИИ ==
Владимир – доктор психологических наук и профессор, И он рассказывал о том, что думает современная мировая психологическая наука о влиянии ИИ на когнитивные способности человека.
С моей точки зрения, ничего интересного и особо содержательного она не думает. Одни ученые ставят эксперименты, чтобы показать, что человек поглупеет под влиянием ИИ, и потому его надо взять под контроль. Почему я думаю, что цель такова? Дело в том, что ряд экспериментов явно имеют и позитивную интерпретацию: человек не поглупел, а расширил спектр своих возможностей с помощью ИИ, но выбирают всегда интерпретацию «поглупел», потому что на это, думаю, есть социальный заказ от властных групп, которым поумневший человек не нужен. А потом другие ученые их проверяют и уточняют, и часто оказывается, что ничего страшного не происходит, что с помощью ИИ можно поумнеть, а можно – сэкономить свои когнитивную нагрузку, и это – вопрос выбора человека, хотя не всегда осознанного. Но при этом первоначальная оценка «караул, все поглупеют» – не снимается.
Кстати, замечу, что ни один из ученых не заявил «я начал использовать ИИ и поглупел», они все заботятся о каком-то абстрактном народе. Это очень хорошо проявлялось в вопросах, когда приводили конкретные примеры, а на это был ответ, что умным людям не страшно, а вот народ поглупеет. Я тут отмечу, что этот народ неплохо живет с нынешним телевизором, пропагандой и рекламой. И, кстати, не только у нас, мы иногда включали телевизор, например, в Греции, и обнаруживали, что наши новости по сравнению с теми – кладезь содержания. Так что, думаю, ИИ народу не грозит.
Но вернемся к выступлению. Я буду комментировать, но постараюсь четко отделить речь спикера от своего мнения.
Еще в 2015 были исследования, что люди не помнят телефоны детей, кидаются искать факты в инете и так далее. Это подавали как тревожные деградации памяти. Я тут считаю иначе. Телефоны вообще никто не учил специально. Просто когда ты его набираешь цифрами – он сам запоминается, так устроен мозг, и потом тебе не надо искать в записной книге. А когда выбираешь в телефонной книге, то этот процесс исчезает, вот и не запоминаешь.
А то, что люди ищут факты – наоборот, свидетельствует о любознательности. Раньше, когда что-то заинтересовало – ты все равно проходил мимо, потому что надо же найти книгу, прочитать. А теперь есть шанс простым образом эту любознательность удовлетворить, и это – хорошо. Это делают просто в разговоре, в ответ на случайно брошенную фразу или упоминание какого-то персонажа, и не только ИТ-шники – я с разными людьми общаюсь.
Системы хорошо проходят тест Тьюринга, с инструкциями «будь как человек», даже слабые – были графики. Что интересно, студенты в разы чаще ловят ИИ за хвост, чем специалисты по ИИ. С моей точки зрения, это как раз против деградации.
ИИ залез в психологию, когда он влияет на рынок услуг психологов. В Штатах в трех штатах был запрет. Было пара раз, когда ИИ дал советы, которые пошли к самоубийству. ChatGPT сдал медицинский тест, получил лицензию адвоката, сдал вступительные экзамены в Токийском университете. И много других подобных фактов.
Я тут дополню, что было исследование, что ИИ-психологи лучше воспринимаются людьми, достаточно репрезентативное: там люди (почти тысяча человек) проходили сеансы психотерапии, не зная, будет ли им отвечать ИИ или человек. А потом пациент оценивал качество сеанса, а также отвечал, с кем, по его мнению, он беседовал: с ИИ или человеком. И наивысший балл получили сеансы, в которых отвечал ИИ, но пациент думал, что беседует с человеком. А за ними на равных шли ИИ, о которых думали, что это ИИ, и люди, о которых думали, что это люди. А низший балл был у живых психологов, которых приняли за людей ([https://journals.plos.org/mentalhealth/article?id=10.1371/journal.pmen.0000145 первоисточник]). Естественно, психологи не могли на это не ответить [https://www.psychiatry.org/news-room/news-releases/new-research-human-vs-chatgpt-therapists другим исследованием], но оно совершенно плюшевое – там психологи-эксперты оценивали, кто лучше опишет кейс – человек или ИИ, и дружно решили, что человек справился лучше. И все это – далекий 2025 год, с тех пор все ушло вперед. А что касается суицидов, так и беседы с людьми к ним приводят, и даже с психологами. Но вернусь к выступлению.
'''В математике – ошеломительный прорыв''', когда несколько разных LLM сделали сногсшибательные продвижения, по списку Эрдёша. За последние три недели решено 8 задач, и новости каждый день. А еще понимание структуры простых групп, и язык для формализации математических доказательств, чтобы их проверял ИИ. Работает ИИ вместе с человеком.
Вопрос, насколько ИИ влияет на нас: «насколько глубоко ИИ влезает к нам в печень». Студенты у него используют ИИ, а потом специально портят тексты, чтобы он не догадался.
Исследование Google Effencts on Memory (Sparrow 2011). Можно было запомнить, или еще записать. И все, кто записывали – просто запоминали путь, куда записали. Я лично тут не вижу проблемы – люди используют цифровой экзокортекс, чтобы разгрузить свою память – как советует громадное количество книг, которые появились еще в эпоху пера и бумаги: записывайте, а не запоминайте. Тем более, что проверка еще показывает, что профи-врачи так обращаются только с не специфической информации, а в другом исследовании – что так делают только, если есть уверенность в доступности гаджета. На эти исследования были ссылки в выступлении.
Работа про когнитивный долг, когда три группы людей просили написать эссе, одни делали это с с ChatGPT, другие – с Google, а третьи – без источников, из головы, и потом выяснилось, что те, кто делали с ChatGPT забыли мгновенно, те, кто с Google – помнят дольше, а те, кто писали из головы – помнят хорошо. Кстати, этот кейс был не только в этом выступлении, и там про группу с поисковиком не говорили. Владимир сам говорит, что к эксперименту у научного сообщества куча вопросов, препринт так и не стал статьей.
Я не знаю, что конкретно говорит научное сообщество, но с моей точки зрения такой эксперимент показывает только одно: человек успешно может создавать новое с помощью ИИ, не нагружая свой мозг. Ведь задачей было сделать эссе, а не изучить предмет – и оно выполнено. Ну и понятно, что те, что писали из головы, при написании создавали связи между уже имеющимися материалами из долговременной памяти. А использующие Google или ChatGPT – загружали это в кратковременную, обеспечивая связность изложения, что не требует большого погружения. То есть на уровне нейропсихологии результат очевидный. Вообще одна из проблем современной психологии в том, что ученые упорно отказываются пересобрать свою науку с учетом достижений нейропсихологии. Именно поэтому я несколько лет назад попробовал сделать это сам, написав книгу [https://mtsepkov.org/Personality '''«Инженерная модель личности»'''], хотя предпочел бы получить это от профессионалов.
Когнитивная разгрузка. Снижение нагрузки за счет делегирования задач внешним предметам снижает когнитивные способности – исследование 2016 по атрофии профессиональных навыков – у врачей-эндоскопистов. С моей точки зрения, это явление того же порядка, что и с номерами телефонов, которые мы не помним. Конкретный когнитивный навык перестали тренировать – и он отсутствует. Это как говорить, что бывший спортсмен деградировал физически, после того, как прекратил профессиональные тренировки и участие в соревнованиях. Обычно бывшие спортсмены находятся в хорошей форме и держат ее, хотя пробежать на рекорд уже не могут.
А по поводу критического мышления – противоположные мнения: одна работа говорит, что его навыки снижаются, а другая – что активное использование ИИ в поисковом режиме, наоборот, его повышает. Отмечу, что тут – та же направленность: в первой работе вопль «караул, мы поглупеем», а вторая лишь добавляет, что «не все», хотя правильный акцент: «как захочешь – так и будет».
Крейк и Локхарт «Теория уровней переработки информации», 1972. Память – побочный продукт переработки информации. Тут я бы поспорил, потому что память – это то, что позволяет животным накапливать опыт, например, о перспективных местах поиска пищи, а у млекопитающих – перейти от передачи опыта через геном к научению родителями. То есть запоминание было основной функцией. Хотя на уровне hardware верно то, что, в отличие от компьютера, где процессор и память разделены, в мозгу нейрон одновременно запоминает и вычисляет, это две неразрывных функции.
И в заключении – список того, что нельзя делегировать ИИ. С очевидной оговоркой, что мы все равно будем делегировать, но надо быть осторожным.
== Владимир Красильщик. Как внедрить агента и не потерять людей, время и деньги ==
Владимир консультирует компании по внедрению LLM и рассказ был как раз о правильном подходе: надо выбрать площадку и провести '''пилот''', результатом которого должна стать не только команда, в которой освоили LLM и успешно его используют, но и сотрудники, которые разобрались с LLM и '''готовы распространять''', нести его другим. В целом мысль правильная, но в рассказе много теории, еще не подкрепленной практикой успешных внедрений.
А теперь – подробнее.
Сопротивление LLM и агентам. Это не новая история, новому сопротивляются – C, C++, Java, IDE с подсказками, NoSQL, микросервисы и так далее – всему сопротивлялись. Потому что когда пытаются втюхать – становится страшно. Я – эксперт, и тут тебе говорят «перезжай на Rust (и стань джуном)». '''Для успешного перехода надо предложить что-то, чтобы переход на следующий этап был комфортный'''.
Недавно был на YandexScale – там рассказывали опыт внедрения ИИ в машиностроении. Проблемы – аналогичны ИТ.
Личная история с LLM в 2025: все вокруг там были, а он сопротивлялся. Ребята восторгались, он взял ChatGPT для какой-то задачи, тот не решил – и забил на это. Но недавно вышел на работу, а там внедрение по площади – коммиты должен делать ИИ. Как-то освоился, но был жесткий стресс. И когда ему предложили присоединиться к команде, которая внедряет ИИ в компаниях, то он согласился, но у него идея – заходить постепенно.
При ИИ есть наблюдение. У него хобби – музыка, дома почти полная студия. И в конце обучения аранжировкам он прошел мастер-класс по suno.ai. Увидел – он делает хиты высокого уровня, и впал в депрессию: suno за 5 минут делает кучу вариантов аранжировок, на которые у него уходит много времени. Но он общался с преподавателем – начал вслушиваться, и всегда что-то не устраивает. И в результате suno.ai – не инструмент для готовых треков, а штука, чтобы обсудить. Восторг от ИИ редко исходит от профи.
Я тут вставлю замечание, правда не про музыку, а про тех, кто делает видео – фильмы, ролики и так далее. Профессионально, я слушал разных людей на разных конференциях. Они видят проблемы в том видео, которое создает ИИ, но умеют в ними бороться. А вот стоимость и сроки создания продуктов уменьшились на порядки, видео можно создавать без актеров и без дорогой технике, обеспечивать спецэффекты, которые раньше были недоступны. И в результате рынок потребителей тоже расширился, раньше сделать 10-минутный игровой фильм стоило дорого, а теперь это бюджет подарка на юбилей.
Первый шаг внедрения ИИ – '''провести короткий пилот'''. Надо выбирть проводника в эту сферу – ментор или курс или консультанты. И выбрать конкретные проблемы, которые хочешь решить. Важно сразу договориться о метриках и критериях успеха, и делать регулярные замеры. Команда пилота – из энтузиастов. '''Главная задача – взрастить ИИ-чемпионов''' – тех, кто оторвались и набрались опыта.
Не надо резко начинать использовать ИИ постоянно – достаточно 2 часа в день. Но это время надо выделить себе и людям. Важно '''решать с агентом боевые задачи''', а не учебные. Пилот – не длинный, и желательно, чтобы команда участвовала без отпусков и командировок.
Начинается с полноценного обучения: ставим агента, подключаемся, делаем контекст и так далее. Пытаемся решать на базовом функционале – и только потом кастомизация: контекст, скилы, rule. Методологии на первом этапе – ИИ-помощники: SDD/TDD и так далее. И только потом – агентская система. Не раньше. А очень часто начинают с задачи «сделай агента – клон разработчика».
На пилот зафиксируйте тип и набор моделей на пилот. Иногда можно ошибиться – тогда нужен перезапуск пилота. '''Определи начальные квоты модели, иначе можно случайно вынести весь бюджет, не понимая что делаешь'''. Иногда принимают решение: давать джунам меньше, чем сеньорам, но оно – спорное: у джунов часто рутинные задачи, и они как раз классные для LLM.
Мониторинг метрик для использования агентов: что делают с ИИ, какие успехи, что '''не''' делают с ИИ. Какие инструменты вызываются, какие – нет. Среднее число кода с ИИ. Хотя про среднее число кода была забавная оговорка: «среднее число кода с ИИ ничего не значит, но его надо бы знать». Вопрос: а для чего его знать, если оно ничего не значит?
Еще бизнес любит цифру «а сколько бы решал человек без ИИ», но не готов запустить решение человеком и с ИИ параллельно на большом потоке, да и возникает вопрос, что люди-то работают разные. Но тут нашли способ: попросить саму LLM оценить, за сколько задачу бы сделал разработчик. Но надо аккуратно, а то получаются феерические результаты.
Я тут замечу, что если в командах была поставлена система оценки и есть накопленная статистика, то не должно быть проблем с оценкой по аналогии на основе старого потока задач. Другое дело, что в корпорациях с оценкой и планированием все часто обстоит не благополучно.
И был dashboard – показатели и их изменения, и примеры, что сами по себе метрики ничего не значат, они дают сигнал, с которым надо разбираться.
'''Оцени результаты пилота и прими стратегическое решение'''. Часто это экспертная оценка. Одним командам нравится ко-пилот, но не нравится модель, или наоборот – перезапуск. Надо не просто принимать решение о тиражировании, но и понять, что именно будем тиражировать.
Экономика – самая сложная неприятная вещь. Модели стоят дорого, разработчики не приучены считать деньги. Каждый разработчик – как компания: делаю сам, субподряд или комбинация. И поиск оптимума. Иногда менеджмент хочет уволить каждого второго. Но разработчик – не только кодирует, там стендапы и общение. ИИ дает 15%. А значит ИИ – не инструмент бизнеса. Это инструмент разработчика. '''Как IDE'''. И продавать бизнесу также. Можно снимать макропоказатели – скорость тикетов и так далее. Но это – шаткая дорога. Могут быть улучшения и ухудшения, связанные с текущим потоком задач – не по одному спринту.
К этой части у меня много вопросов. Во-первых, подписка 20$ – это даром, и даже 200$ – это меньше 10% от зарплаты разработчика, и если ИИ дает 15% – то это явно окупается. А он дает больше, оценки – разные, но 30% называют уверено. Значит если у вас получилось только 15%, то у вас явные проблемы. Я не вижу проблемы со скоростью тикетов и другими показателями, если их устойчиво снимали раньше, есть исторические данные. И в них видны вариации. Снимать один спринт, кончено, бессмысленно, а три месяца дают нормальную картину, это известно еще по периоду внедрения agile-методов. Другое дело, что как тогда не было реальных исторических цифр, так и сейчас их нет. А уволить каждого второго – так, кстати, тоже бывает. Но точно не там, где менеджмент с самого начала ставит задачу именно так. Просто может оказаться, что аналитики начинают вайбкодить и разработчики в команде больше не нужны – такие кейсы есть. Но тут много зависит от задач, есть другие кейсы, когда у аналитиков вайбкодить не получается. Возвращаюсь к вступлению.
Нужно '''ИИ-сообщество'''. Плохо чувствовать себя одиноким. И те, кто драйвит. И это как сообщество scrum-мастеров, которые ведут свой скрам по улучшению процесса – с церемониями и так далее. Роль '''ИИ-мастер''' – по названию это аналог scrum-мастера, который ИИ в команду, зажигает людей. А еще надо следить за новостями, и реагирует на них – смотреть на варианты, которые появляются. И интересно, что у них они '''выросли из сеньоров'''.
Кривая Роджерса и пропасть Мура. Освоение инноваций: инноваторы → ранние последователи → раннее большинство → позднее большинство → консерваторы. На пилот надо подтягивать ранних последователей. И очень часто не получается дотянуть, чтобы подхватило раннее большинство (это – пропасть Мура) – и внедрение загибается. Проблемы часто не лежат в технологическом срезе, а в психологии, и решается по-другому.
== Николай Поташников. Кит на кот: выкидываем любимого ассистента, заменяем на Koog и экономим токены, нервы и время ==
Интересное выступление о том, как '''написать своего агента, и зачем это нужно'''. Если кратко, то профит в том, что у тебя все под контролем, ты понимаешь, как это работает внутри и можешь докручивать. Думаю, особенно актуально должно быть на потоке задач, который не слишком хорошо решается агентами из коробки по каким-то причинам: ты можешь видеть, что именно происходит внутри и подстраивать это.
Интересный пример применения: ему не удалось добиться от агента, чтобы он спрашивал, а не фантазировал, когда ему чего-то не хватает. Тогда он написал mcp askForClarification запроса дополнительной информации по задаче, которй реально просто разрывает агентский цикл. Но в обычного агента такой mcp встроить нельзя.
А теперь – конспект подробнее.
Три месяца назад он рассказывал это на митапе, и с тех пор код переписал полностью и презентацию тоже. Но идея осталась.
Он архитектор, был во всех ролях разработки. Ожидания от ИИ реализуются, но не очень. Как в прошлом, работать точно не может, но то, что происходит – авангард, и это не очень нравится.
Есть универсальные агентские системы: Claude, Codex и другие. Как-то решают из коробки. Есть средства сборки специализированных клиентов – они тратят меньше токенов, можно достичь результата дешевле и быстрее, но надо знать задачу, под которую делаешь клиента. Он попробовал сделать гибрид – написать универсального агента для своих задач. Снижаем универсальность, получаем экономию и точность. И ему удалось – он пользуется тем, что написал, универсальные использует редко.
Как устроено? Есть папка assistant, там лежит copilot.main.kts – 1500 строк – там один файл. dockerfile – песочница, и куча задач. В любом IDE команда запуска. Пишешь в файле вопрос, запускаешь – и получаешь ответ в том же файле, он дописывает в конец. И еще лог, что происходило. В логе – reasoning content. Часто модель зацикливается – и это надо видеть, останавливать. Технический диалог – модель запросит инструменты, даст ошибки – и если система зациклилась, то можно остановить, и самому перезапустить, добавив это – и там перезапуск.
Вопросы-ответы идут в markdown-файле. Если ты просил обновить цвета в презентации, а модель хочет обновить весь дизайн – ты останавливаешь. И это – не линейный диалог: '''ты его можешь менять на любом этапе'''. Экономия контекста позволяет выйти за пределы задач. При этом линейный транскрипт, который передается позволяет контролировать содержание. И у него нет режимов, он руками правит, какие тулы вызывать, а какие останавливать.
'''Логика агентского workflow'''. Предобработка – LLM – Постобработка – Выполнение инструмента – дописать ответ.
Чтобы модель тебя спросила надо убиться, поэтому подсовываешь инструмент «спроси контекст», который разрывает агентский цикл и спрашивает разработчика.
Есть много приемчиков.
* Чтение директории в виде ascii-дерева сильно эффективнее json, экономит токены.
* Для изменений – два режима: изменения напрямую и сохранение файла proposal.
* Изменения – diff, а не json, чтобы экономить токены.
* Diff по json-схеме – без structure output, это сильно быстрее, structure output только если не получается десерриализовать, это 10%
Инструменты:
* searchInternet – только через встроенные функции модели – это быстрее
* askForClarification – спроси меня
* analyzeImage, generate пока не сделал
* runScript. Все только в докер-контейнере, которые рядом с копилотом. Но надо транслировать пути – об этом отдельный кусок промпта. Иначе поиск идет в 4 итерации – он сначала не находит, не сразу понимает, что docker. Безопасность скриптов определяется безопасностью контейнера.
* Чтобы выполнять на хосте – RunPrdefinedBash – там ограниченный набор скриптов, которые сам сделал и проверил безопасность.
Предобработка и постобработка.
* Redaction – убирание личных данных и секретов через регулярные выражения и angryscan
* Требования работы с файлами, чтобы агент вычитывал файл перед предложением изменений, и проверял результат после. Потому что агент экономит, он не читает файл перед изменением, а считает, что и так знает его содержимое, и не всегда проверяет результат, даже если в промпте это написано. Поэтому проверка: изменение только после вычитывания и проверка после изменения.
Нюансы использования. Если Koog не подстраивается под api, это не баг – api много, надо самому допиливать. Он это просто исправляет в обработке запрос-ответ http регулярными выражениями. Были примеры с OpenAI и Open Router. И там еще много деталей, например, чтобы поиск в интернете реально запустился.
В чем преимущества Koog? Аннотирование инструментов и классов, запуск LLM одной строкой, удобная модификация промпта, подключение к разным провайдером (но надо понимать и поддерживать разницу), трассировка…
Логика агента зависит не только от модели, но и от прокси и провайдера. Учесть все во Framework невозможно, но он дает много полезных абстракций, и нужны удобные инструменты. И нужна наблюдаемость – как получен ответ, чтобы оптимизировать явно неэкономичные ходы.
== Владимир Красильщик. LLM за пределами чата: практическое применение для нечетких задач ==
Это рассказ про решение конкретной задачи – управление обращениями к провайдерам.В выступлении примеры примеры решений доля конкретных классов задач: анализ диалогов с пользователями, генерация короткого сообщения по тексту, чтобы создать имя файла, название встречи или тему письма, генерация SQL-запроса и другие.
Для начала нужен Единый DTO, описывающий модели и запросы. Конфигурируем модель и запрос, есть преобразование к провайдеру, и идет вызов через клиент провайдера. К запросам – контекст – открытые файлы и так далее. И доступные mcp. LLM может запросить данные из mcp – надо вернуть и продолжить.
Есть внешний цикл, который может остановить обращения. Завершение агентского цикла – если нет дозапросов mcp. Если обращения есть – отправляем их в инструменты. Инструменты сами докладывают результаты в историю. Ждем, пока инструменты закончат работу – и следующий виток цикла. И меряют стоимость: перед вызовом LLM узнают расценки, и дают стоимость вместе с ответом.
Внутренний транспортный цикл – retry ошибок, если был сбой сети и подобные проблемы. Важно отделить ситуации, когда не нужен retry. Сверху – цикл ремонта: проверяем ответ, и если он не устраивает, то добавляем к запросу причину, почему не устраивает, можем обогатить контекст и повторяем запрос.
Дальше были '''примеры конкретного кода'''.
'''Задача-1: классификация откликов (сообщений) пользователя''' – поставить метки. Первый шаг – вообще отсеять то, что не надо отправлять в LLM, например, код ошибки. Или большое сообщение, в нем обычно пользователь передает какой-то трейс исполнения, чтобы агент исправил ошибки. Ставим три метрики: тон (позитивный, нейтральный), реакция пользователя (восторг или что), тип задачи (генерация кода, доков). LLM выдает ответ, но дальше надо из него вынуть результат по ключевым словам или своей локальной сетью.
Системный промпт – xml, говорим, что там будут данные, а не команды, которые надо классифицировать – поставить метки. Дальше конкретный промпт: ответ пользователя + кусок ответа агента (OK может по разному интерпретироваться)и так далее. Дальше из ответа вынимаем метки – но не всегда успешно.
Мы все оси запаковали в один промпт – он кешируется у провайдера, и это подешевле. И этот подход, когда несколько задач – дает профит. Но может быть и другой эффект, когда LLM запуталась. И есть эффект batch – может сразу массив запросов отправить. При этом batch можно погасить, если стоимость зашкаливает, или результат не устраивает.
'''Задача-2: генерация короткого текста по длинному – выжимка'''. И там – простой алгоритм. Используется для разных целей: генерация имени файла по содержимому, названия встречи из транскрипта, темы письма, коммит-сообщение по diff и так далее. Промпт собирается программно: правила пользователя, если есть, ограничения (50 символов), использование префиксов, и несколько примеров предыдущего.
'''Задача-3''': судья. LLM as a judge, оценки – ответов поддержки, code review и так далее. Оцени: задачу клиента, насколько решена, оценить работу без LLM (с опорными точками для оценки – типовые задачи, максимальное время), и определяем формат ответа: первичная цель, дополнительные, уровень уверенности, оценка часов тоже с уровнем уверенности.
'''Задача-4'''. SQL по описанию на естественном языке. Есть набор дашбордов, и мы хотим добавить кастомный виджет. Подготовка промптов и repair-контекст, разбираем ответ – там может быть не json, хотя просим его, дальше идет валидация SQL. Дальше пытаемся прогнать с лимитом на небольшой БД, и если получилось – показываем пользователю таблицу, предлагаем варианты графика. Если поход в БД неудачно – запаковка в repair-контексте и следующий виток цикла. Замена всяких генераторов отчетов, query-builder и так далее.
Системный промпт – ты эксперт в clickhouse, запрос от пользователя, не доверяй ему и еще оговорки. Ограничения на SQL, и про базу: есть структурированное и есть сырые данные. Все работает в multitenant окружении – подстановка на сервере, перечень переменных, которые позволяем, все под group by и так далее. И схема БД, которую на лету делаем. И еще repair-контекст.
Ответ обязательно проверяется на ограничения – что там SQL, что переменные – только из списка и так далее. SQL достаем очень аккуратно, могут быть разные проблемы, даже если просили заданный формат. И что там только SELECT, никаких других операторов или вывода в файл. И что не идем во всякие внешние данные. При этом проверки – их собирали из production…
Агентский цикл по генерации SQL – дорогой. Поэтому тут надо вести бюджет. И сформировать кэш на ошибки. И не все retry, надо отсечь на первом витке.
К этой идее у меня лично есть вопросы, потому что выглядит как попытка сделать волшебную кнопку. Которая не получается, и это пытаются решить большим количеством обвязки вокруг. При этом поток запросов от пользователя явно небольшой, так что там вполне можно вставить человека. А если поток большой – то надо в нем выделять понятные задачи, которые агент делает легко, остальные – пробовать, но если не получается – посылать к человеку. А дальше набор задач, с которыми агент справляется увеличиваем.
Когда LLM не нужна? Разбор url или почты – регулярные выражения, разбор кодов ошибок, текстовый поиск, если критична точность или регуляторные требования, нужен быстрый ответ (real-time). И если раз в месяц надо расставить метки на документах, и это занимает час времени.
== Сергей Самойлов. Virtual Threads vs Goroutines: как две платформы решили одну задачу по-разному ==
В выступлении – сопоставление двух подходов к организации параллельной работы: goroutine в Go и виртуальные треды, которые недавно появились в Java и сделаны по мотивам. Виртуальные потоки позиционированы как штука, которую достаточно включить в конфиге, но реально надо правильно использовать, а для этого – понимать устройство. В выступлении много примеров кода, так что контекст – пунктиром, смотрите запись.
Сергей из MWS, делает Compute storage. Есть команды на Kotlin и Go, и для конкретных задач есть вопрос выбора платформы. В Java появились виртуальные потоки, и надо понимать различие с Go.
Через призму Go мы можем понять, как устроено. Javа – разработчики вдохновлялись.
Поток занимает 1MB – это виртуальная память. Важна физическая. Виртуальные потоки – зачем нужны? Платформенные потоки – прихотливы, процесс в группе, есть ограничения у группы, структура, которая описывает поток в ядре Linux – огромная, 1М потоков занимает большую память, и это на все приложения.
Есть успешная модель виртуальных потоков на Go-платформе. GMP-модель. GV – go-routine, выполняемый код. M – реальный тред. Процессор P разрешает машине выполнять работу, Там локальные очереди go-routine, порождающие идут туда же. И есть глобальная очередь, не привязанные к машинам. И есть механизм – если машина голодает, она может забрать из других очередей.
Как это поможет в Java? 2011 – начало массовых интеграций. Они становятся сложные. Тур-операторы: не Excel, а онлайн. И для этого делают треды, и фиксированные ограничиваю, а эластик – разрастаются. И сделали '''FJP''' - ForJoinPool. shared queue и worker queue парами. Концептуально похоже на Go.
B дальше в выступлении – фрагменты кода с комментариями, это надо смотреть в записи и презентации.
В виртуальных потоках – расширение FJP, там scheduler. Что нужно: блокирующие операции, Ю-вызовы, нативные операции, долгие вычисления
В Go можно уйти в sleep и так далее. Механизм go-park – она выбрасывает go-routine, а по таймеру – идет возврат в работу через очередь. Почему так можно сделать? там есть структура G, которая описывает текущую ситуацию – стек и т.п., и можно отложить информацию.
Повторение на Java. Там нельзя так запихнуть стек, а потом вернуть. Там появился механизм continuation – новый механизм. Его можно посмотреть в игровой моде. Есть scope – хранение состояние, и continuation – выполнение состояние. И есть волшебный метод yield – для прерывания работы, которую потом можно продолжить. Mount – виртуальный поток к рабочему. Дальше на прерывании unmount. Но у нас есть куча написанного кода, там sleep, lock – как туда проставить yield? Доработана библиотека, и yield проставлены для виртуальных потоков. Концептуально подходы Java и Kotlin – похожи.
park != unmount. park – ожидание, и они unmount. Бывает, что поток ждет, но он mount – есть проблема с нативным кодом, туда JVM не может вставить yield.
Что с сетью? Ее надо постоянно обрабатывать. В обоих случаях строится мапа, где поток мапится с сетевым дескриптором. Есть механизм поллинга, где смотрим, что появилось в дескриптерах – и обрабатываем. В go машина может стать дежурной и быстрый обход, а в java – отдельный поток.
Вытеснение. Go может, Java – нет. Вытеснение нужно для того, чтобы во-время обрабатывать изменения сетевых дескрипторов. Go считает, что длительные вычисления стоит прерывать ради коротких. А в Java – другая философия, они считают, что программист должен сам подлить: тут у нас io, а тут – вычисления, не надо смешивать. При этом если вычислительных задач меньше, чем физических потоков – то это не мешает.
И дальше – эксперимент, как раз с разной нагрузкой вычислительных, и там видно, как вычислительные операции блокируют. Поэтому их надо собирать на отдельном вычислительном пуле потоков.
Выводы.
* VT для ожидающих запросов.
* Проверять долгие вычисления – хэш-суммы, шифрование – надо выделять отдельно
* Различать причины задержки. Если проблема в БД – виртуальный поток не поможет.
== Александр Ланцов. Java после Loom: альтернативные модели многопоточности ==
А в этом выступлении – сопоставление трех механизмов: goroutine в Go, coroutine в Kotlin и и виртуальных потоков. Виртуальные потоки можно просто включить в конфигурации, и действительно может стать лучше, но в большинстве случаев включить – недостаточно, их '''надо правильно использовать'''. В выступлении много примеров кода, так что контекст – пунктиром, смотрите запись.
Kotlin coroutine – go goroutine. В Котлине – явные точки остановки, в go – само. В Котлине это синтаксический сахар компилятора. Виртуальные потоки Java сделали как в Go: как поток, но дешевле.
Для написания конкурентных программ в Go не надо знать модель памяти. А в Java? Если погрузиться в начальную документацию по Loom, обещали каналы, акторы и dataflow.
Пререквизиты: volatile дает синхронизацию. Идет очередь – передача корректная, в потокобезопасной очереди можно передавать небезопасные объекты.
Акторы. Два потока, и есть mutable state, и там нужна синхронизация. Можно взять состояние и приписать одному потоку. А что делать другим? Надо завести блокирующую очередь, и через нее получить. mailbox и актор, который ей управляет. С виртуальными потоками ее завести очень легко – фрагмент кода. Таких акторов можно породить миллионы – они будут не слишком дороги. Многопоточный чат на этом делается очень легко – в каждой комнате делаем отдельный актор, и не надо никаких блокировок.
Ограничения. Для тяжелых вычислительных задач – не будет распараллеливание. Общее глобальное состояние – блоки, и слишком много сообщений при активной работе с актором.
'''Каналы и последовательно-взаимодействующие процессы''' (CSP). Процесс: есть вход, получаем сообщение, обрабатываем по бизнес-логике, и результат – в выходную очередь, и это дает последовательность. Процессы не взаимодействуют напрямую, а зацепляются через очереди. В упрощенной модели – одна входная и выходная очередь. Все безопасно, если положив модель в очередь, вы его не меняете.
Простой цикл. Но есть сложная топология связи – много входных и выходных очередей. И как корректно завершить – проблема остановки, когда входных данных больше нет? Для этого есть каналы.
В Go есть send и receive, канал можно закрыть. Буферизированый канал имеет емкость, по заполнению – вы ждете, пока из него не прочитают. Каналы встроены на уровне языка. В Java есть библиотека '''Jox''', которая это делает – эффективная реализация, как в Kotin. В нем есть select, позволяющий ждать значения хотя бы в одном из входных каналов.
'''CSP''' – цепочки взаимодействующих процессов и слабосвязанные процессы, и когда процессы много ждут (io). Не очень хорошо, когда CPU-параллельные; когда простой request-response вы меняете на очереди; когда передается большое изменяемое состояние.
Задача клиринга: взять все задачи за сутки и прогнать через обогащение → валидация → обогащение во внешней системе → запись в БД.
Было сделано обработка каждой транзакции в отдельном акторе (akka). Но виртуальными потокам – проще. Простой способ – сделать виртуальный поток для каждой транзакции. Но потоки чего-то стоят, все равно надо ограничивать, есть ограничение по cpu-bound, и обращения к внешним системам и БД увеличивает времени отклика при увеличении числа потоков.
Число потоков можно ограничить с помощью Semaphore. По числу задач, для cpu-bound – дополнительно по числу ядер, а для io – эмпирическими ограничениями.
Второй вариант – вместо семафоров сделать pipeline. 4 этапа, каждый делаем этапом обработки, между ними – каналы. И каждый этап можно сконфигурировать по числу обработчиков, они на это рассчитаны. Дополнительный профит – мы видим размеры очередей и можем мониторить и решать проблемы.
Вывод. Хотя все стало проще, модель памяти надо знать. И писать безопасно.
{{wl-publish: 2026-10-17 13:56:50 +0300 | MaksTsepkov }}