О чем молчит AI CTO

Рекомендую к просмотру Подкаст вышел про тему мертвого интернета и в целом про возможности ИИ от интересный ребят =) Эпизод уже тут YouTube и в VK

Channel photo updated

243-ФЗ: происхождение большой LLM становится частью архитектуры 26 июля подписан Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации». Он вводит понятие большой фундаментальной модели, два специальных статуса для российских моделей и право Правительства определять случаи, когда можно применять только модели с такими статусами. Разберёмся, что именно меняет новый закон и почему происхождение большой LLM теперь необходимо учитывать при проектировании продукта. Что закон считает большой моделью Термин в законе шире привычного понятия LLM. Большой фундаментальной моделью считается программа, которая одновременно: - содержит не менее одного миллиарда параметров - выполняет большое количество разных задач - служит основой для создания или доработки другого программного обеспечения - выдает результаты на уровне интеллектуальной деятельности человека или выше Порог в один миллиард параметров сам по себе не делает модель большой фундаментальной. Поэтому специализированные модели для классификации, распознавания или прогнозирования, скорее всего, останутся за пределами определения даже при значительном размере. Важны свойства самой модели, а не конкретный бизнес-сценария, в котором она используется. Два статуса российской модели Закон вводит два статуса для больших моделей: суверенный и национальный. Суверенную модель разрабатывает российское юридическое лицо, которое контролирует весь жизненный цикл и способно технически воспроизвести разработку, включая обучение. Ответы пользователям формируются, а данные хранятся в российских центрах обработки данных, принадлежащих российским юридическим лицам. В национальной модели существенные характеристики, программное обеспечение и настраиваемые параметры определяет российское юридическое лицо. При ее создании можно использовать российские и зарубежные компоненты, включая другие большие модели, если они распространяются по открытой лицензии. Требования к российским центрам обработки данных сохраняются. Для обоих статусов понадобится подтверждение соответствия законодательству и традиционным духовно-нравственным ценностям. Процедуру должно установить Правительство. Какие инструменты создает закон Разработчики суверенных и национальных моделей смогут получать государственную поддержку. Закон также создает механизм доступа к данным государственных информационных систем для обучения. Конкретный порядок еще предстоит определить. Отдельная льгота касается охраняемых произведений. Компьютерный анализ и краткосрочная запись материала в память машины не считаются нарушением авторских и смежных прав, если это делается исключительно для обучения суверенной или национальной модели. Разработчик должен правомерно получить экземпляр произведения либо работать с опубликованным материалом, доступным для анализа без технических ограничений. Это касается авторских и смежных прав и не отменяет требования о персональных данных, коммерческой тайне, конфиденциальной информации и условиях договора. Еще один инструмент — право Правительства определять случаи, где разрешены только суверенные или национальные модели. Для финансового рынка такие решения согласовываются с Банком России. Перечня случаев пока нет. Именно он покажет, насколько сильно закон повлияет на выбор моделей в государственных, финансовых и других чувствительных системах. Основная часть закона вступает в силу 1 сентября 2026 года. Требования к специальным статусам и ряд прикладных норм начнут действовать 1 марта 2027 года. Что это значит для нас с вами Закон создает общий словарь и полномочия для следующего этапа регулирования. Порядок присвоения статусов, отраслевые ограничения и требования к рискам появятся в подзаконных актах. Самое интересное впереди: следующие правила будут опираться на уже определенные категории, а происхождение модели станет либо ограничением, либо возможностью. «Новый закон является рамочным, направлен именно на развитие ИИ и не содержит каких-то запретов», — констатировал Дмитрий Григоренко. «СенатИнформ», 17 июля 2026 года О чем молчит AI CTO

AI-трансформация начинается не с платформы, а с одного процесса Microsoft выпустила The AI Strategy Roadmap — 66-страничную методичку о том, как перейти от разрозненных AI-пилотов к организации, в которой AI встроен в основные бизнес-процессы. Материал основан на интервью с 70 руководителями бизнеса и IT, клиентском опыте и внутренней трансформации самой Microsoft. Главная мысль: У большинства компаний нет дефицита AI-идей. У них нет механизма, который превращает отдельный успешный пилот в повторяемую организационную способность. Microsoft называет это целевое состояние Frontier Transformation: AI перестаёт быть личным инструментом отдельных сотрудников и становится частью работы всей компании — от ключевых процессов до принятия решений. Они выделяют 5 стадий: 1. эксперименты 2. планирование 3. внедрение 4. масштабирование 5. AI становится стандартным способом выполнения работы Сначала компания проверяет гипотезы, а затем превращает успешные эксперименты в устойчивую систему, которая работает в масштабе всего бизнеса. Чтобы двигаться по этому пути, Microsoft предлагает одновременно развивать пять направлений: 1. Бизнес-стратегия — какие проблемы решаем и по каким бизнес-метрикам определяем успех. 2. Технологии и данные — готовность данных, общая платформа, наблюдаемость и надёжность. 3. AI-стратегия и пользовательский опыт — доверие, внедрение в реальные процессы и обратная связь. 4. Организация и культура — новые роли, навыки, стимулы и модель работы людей с агентами. 5. Управление и безопасность — единые правила, контроль доступа, реестр систем и управление всем жизненным циклом AI. Повторяющийся паттерн внедрения простой: начинать нужно не с большой AI-стратегии, а с одного узкого процесса, где можно быстро показать результат без лишнего риска. Такой пилот нужен не только ради ROI — на нём компания учится доводить AI-решение до устойчивой работы и сразу строить его как будущую часть бизнеса, а не одноразовый эксперимент. Когда модель уже достаточно хорошо решает выбранную задачу, масштабирование начинает упираться в устройство самой компании. Microsoft предлагает для этого центр компетенций — команду, которая не забирает проекты себе, а задаёт единый путь от идеи до запуска. В самой Microsoft его усилили после того, как разные подразделения начали создавать похожие решения по разным правилам. Такой центр сокращает повторную работу и помогает успешным пилотам быстрее и безопаснее становиться частью бизнеса. По мере роста числа проектов ими предлагают управлять уже не как набором независимых экспериментов, а как единым портфелем. Компания регулярно пересматривает результаты и перераспределяет внимание и инвестиции в пользу решений, которые действительно создают ценность. Microsoft связывает 67% полученной от AI ценности с организационными факторами. В самой методичке эта цифра почти не расшифрована, но вывод понятен: одних технологий недостаточно — компании придётся изменить сам способ работы, чтобы люди задавали направление и оценивали результат. Документ местами предсказуем и заметно ведёт к экосистеме Microsoft. Но как управленческая карта он хорошо фиксирует следующее: Масштабируется не пилот, а способность компании снова и снова превращать подходящие задачи в работающие AI-решения. О чем молчит AI CTO

История технологии, которая появилась раньше своего времени Сначала Java выглядела как эксперимент. Небольшая группа инженеров создавала её для будущего рынка, которого ещё не существовало. Первые продукты не стали массовыми, первоначальная ставка не сработала, а сам проект оказался близок к закрытию. Но внутри неудачного продукта сохранилась сильная идея: отделить намерение разработчика от конкретной среды исполнения и позволить одному решению работать в разных контекстах. Некоторое время эта идея оставалась интересной только инженерам. Затем изменилась сама индустрия — появилась новая вычислительная среда, в которой прежние ограничения стали особенно заметны. В 1995 году технологию представили уже не просто как очередной инструмент, а как новый принцип создания программных систем. Начался взрыв ожиданий: компании запускали проекты, разработчики осваивали новый подход, инвесторы увидели огромный рынок. Казалось, что новая технология полностью заменит прежние способы работы. Но первые массовые приложения оказались слабее обещаний. Они были медленными, нестабильными и плохо подходили для серьёзных систем. Началось разочарование, а сценарий, благодаря которому технология стала известной, постепенно потерял прежнее значение. Однако исчезла не технология. Исчезло первое представление о том, для чего она нужна. Пока рынок обсуждал яркие демонстрации, Java проникала в инфраструктуру. Вокруг неё появились инструменты, стандарты, библиотеки и сообщество, а на её основе начали создавать критически важные системы. Так отдельный инструмент превратился в платформу. Она не заменила всю индустрию и не выполнила все ранние обещания, но изменила базовые ожидания разработчиков и заставила даже конкурентов принять её ключевые принципы. Это история технологии, которая появилась раньше подходящего для неё мира. Первый продукт не взлетел, первый массовый сценарий оказался временным, но фундаментальная идея была верной. И 1995 год стал не годом появления законченной технологии, а моментом, когда стало видно направление движения. А теперь замените Java на GenAI, а 1995 год, на 2025 год. Документальный фильм: The Java Story О чем молчит AI CTO

Мое внимание привлек Making of Claude Code. Очень рекомендую открыть режим терминала. Там команда вспоминает как появился Claude CLI, который Борис Черный собрал примерно за два дня и сам не до конца понимал, что именно получилось. Ранний доступ встретили прохладно, но команда читала обратную связь и быстро выпускала исправления. Благодаря автообновлениям фикс мог оказаться у пользователя через пять минут. Вера команды в продукт и внимательное отношение к обратной связи сделали его по-настоящему полезным. О чем молчит AI CTO

AI-тарификация. Часть 2/2 Начало Тарификация людей с AI А как тарифицировать работу людей с AI? Ведь когда мы говорим про AI, кажущаяся бесплатность отдельного шага очень легко превращается в иллюзию бесплатности человека с AI. Уже сейчас генерация изображений, суммаризация, поиск, первый вариант веб-приложения почти ничего не стоят, и некоторые клиенты, не разобравшись, начинают делать вывод, что результат человека с AI тоже должен стоить почти ничего. Параллельно растет неравноправие людей. Раньше внутри одной роли была понятная вилка: тот же Middle backend developer мог быть сильнее или слабее, быстрее или медленнее, но рынок, процессы и ожидания роли довольно быстро сжимали разброс. Теперь AI эти границы растягивает: один человек использует ассистента как автодополнение и ускоряет старый процесс, пока другой собирает вокруг себя рабочий контур с обратной связью. Формально роль одна и та же, но производительность может отличаться в разы. Мне известны случаи, когда стали использовать не самые качественные метрики по количеству MR и строк кода, а затем выявлять слабые звенья с последующим увольнением. Консалтинг чувствует изменения Очень хорошо заметны изменения в консалтинге, к которому я сейчас отношу себя в той или иной степени. Клиенты видят, что работа становится быстрее с агентами, и часто просят скорости и маленьких команд, а нам приходится справляться, создавая Tiny Teams. В прошлом году мы столкнулись с большим сопротивлением в командах: ну кто захочет становиться фронтендером, если развивает себя как бизнес-аналитика? Или как собрать эту команду из текущих доступных ресурсов, когда команды всегда делились на специальности? Этот год расставляет приоритеты: вижу в окружении понимание, что по-другому работать будет практически невозможно. И как же зарабатывать компаниям, предоставляющим подобные услуги, если старая единица сравнения не работает? Там прямо сейчас мучительно уходят от оплаты часов, потому что AI ломает старую связку между размером команды и ценностью результата. Если сильный человек с AI делает работу маленькой команды, продавать размер команды становится все сложнее. Хотя это понимал и Марвин Бауэр, неформальный основатель McKinsey & Company, он говорил в 1941 году: "You cannot measure value by hours. Lawyers don't and we shouldn't." То есть ценность нельзя мерить часами, но ими так удобно клиентам сравнивать консультантов друг с другом, ожидая одинаковую ценность и ища наименьшую стоимость. Цена надежности А какую ценность могут приносить внешние подрядчики в AI-сфере? Как правило, это создание надежного, масштабируемого и поддерживаемого бизнес-процесса, оптимизирующего текущие процессы или приносящего новые возможности для заработка, где цена ошибки может быть достаточно высока. Иначе зачем их подключать? И здесь нужно быть осторожнее с экономическими ожиданиями, потому что хорошо помню интересную закономерность из опыта работы в научно-исследовательском институте. Мы занимались гироскопами на разных физических принципах: атомными, волоконно-оптическими, механическими, вибрационными. На уровне физики — это разные устройства, на уровне инженеров — разные школы, даже на уровне страны — разные заводы. Но когда нужно выйти на один и тот же класс космически малой ошибки, стоимость вдруг сходится к одному большому порядку величины С AI, как мне кажется, происходит похожая история: как только цена ошибки возрастает, стоимости решений с AI и без AI начинают сходиться к одной большой величине. ⬥⬥⬥ Получается диссонанс между старой и новой экономикой. Старая экономика привыкла видеть человека в процессе и брать деньги рядом с этим человеком. Новая пока выглядит непривычно: то токены по подписке, то запрос к сайту за деньги, то маленькая команда вместо большой, то агентский слой вместо привычного интерфейса. И это происходит потому, что человек из середины процесса исчезает, а агентские действия начинают потреблять чужие данные, интерфейсы, вычисления и доверие. Бизнесу приходится искать новые механизмы, но какие из них будут востребованы, покажет только время. О чем молчит AI CTO

AI-тарификация. Часть 1/2 AI ломает не только интерфейсы, но и привычные единицы экономического учета. Когда действие выполняет агент, становится непонятно, за что брать деньги: за час человека, за запрос машины, за доступ к данным, за поручение или за достигнутый результат. Старая экономика считала человека Сегодняшняя экономика привязана к человеку внутри процесса. Консалтинг продает человеко/часы, YouTube показывает рекламу, маркетплейс берет комиссию. Вокруг действий человека и его цифровых следов выстраиваются продуктовые метрики и маркетинговая стратегия. AI-агенты начинают вытаскивать человека из этого процесса. Человек формулирует намерение, а дальше ассистент читает, сравнивает, делает заказ и приносит результат. Если оценивать такую работу в агенто/часах, она выглядит почти бесплатной. Только агент равнодушен к рекламе, не обязан ходить по витринам, не оставляет привычный след в интернете и не проходит продуктовую воронку так, как ее рисовали последние двадцать лет. Человеческие потребности при этом не исчезли: нам все так же нужно вызывать такси до аэропорта, покупать смартфоны на маркетплейсах, выбирать подрядчиков для ремонта ванной комнаты, разбираться в многостраничных документах за минуты и просто принимать решения. По факту сейчас меняются привычки людей, интерфейсы и место, где ценность превращается в деньги. Я уже давно стал доверять Алисе подбор рецептов блюд, а не искать их в сети. Агент становится новым интерфейсом Раз мы заговорили про Алису, стоит упомянуть, что у Яндекса выстраивается целая экосистема: агенты Алисы встраиваются в Такси, Лавку и другие сервисы. Теперь Алиса не просто отвечает, а помогает выполнить поручение внутри продукта. Пользователь все меньше обязан идти по привычной цепочке экранов: он формулирует намерение и ждет исполнения. Но как зарабатывать на контенте и рекламе в Лавке, если исполнитель — агент? Видимо, поэтому Cloudflare пробует брать плату с машинного потребления ресурса. Не с показа баннера, а с самого факта, что ресурс был использован. Это выглядит непривычно, но логика понятна: если старый способ монетизации зависел от человека на странице, а теперь ценность забирает машина, то бизнес будет искать способ поставить цену ближе к машинному потреблению. Продолжение О чем молчит AI CTO

Agent Driven SDLC: как меняется разработка в эпоху ИИ Ребята из Selectel помогли оформить выступление с конференции «МЛечный путь 2026» в статью на Хабре. Спасибо их команде за приглашение, хорошую организацию конференции и помощь с текстом. Ценно, когда доклад превращается в подобный материал. - Статья - Запись доклада О чем молчит AI CTO

Из чего состоит AI-бенчмарк Недавно мы в red_mad_robot выпустили открытый benchmark для детекции персональных данных в русском тексте. Внутри данные, собранные из реальных продакшен-сценариев. Параллельно Валера Ковальский сравнивает Drift и другие агентные оболочки на наборе открытых benchmark как дополнительная обратная связь для продукта. Ранее я писал, что главный инженерный вызов в агентных системах сейчас связан с качеством обратной связи и создатель Claude Code Борис Черный недавно подтвердил эту мысль: «Переход от агентов к loops - такой же большой скачок, как когда-то переход от обычного кода к агентам». Но loop работает, только если система умеет определить ошибку и понять, стоит ли продолжать работу. Поэтому я решил разобрать семейство открытых бенчмарков τ-bench. Первая версия проверяла общение агента с пользователем и работу с tools. В τ²-bench пользователь получил возможность действовать в среде, а не только отвечать агенту. А τ³-bench добавил задачи с базами знаний, голосовой режим испытаний и набор исправлений в сценариях. Разбирать такой benchmark удобнее через четыре слоя. Покажу их на одном сценарии: Yusuf Rossi получил заказ #W2378156 и хочет обменять клавиатуру и термостат. Нужная клавиатура с подсветкой недоступна, поэтому пользователь согласен на модель без неё. Провести обмен можно только один раз. ⬥⬥⬥ 1. Слой данных и среды Первый слой создаёт мир, в котором работает агент: данные, связи между ними и последствия действий. Например, в домене Retail, который моделирует интернет-магазин, это пользователи, товары, их варианты, заказы и платежи. Так появляется Yusuf Rossi, доставленный заказ, две купленные позиции и доступные варианты. Клавиатура существует на двух уровнях, как тип товара product_id, так и конкретная версия с размером и подсветкой item_id. Поэтому агент может подобрать другой вариант той же клавиатуры, но не заменить её термостатом. Среда определяет, как агент работает с данными: одни инструменты ищут пользователя и заказ, другие меняют состояние. В банковском домене добавляется корпоративная неструктурированная база знаний с регламентами. Агент ищет правило в документах и применяет его к ситуации. ⬥⬥⬥ 2. Методология Методология определяет, какое поведение считается правильным. Сценарий задаёт желание пользователя: Yusuf хочет заменить две позиции и решить всё за один разговор. Дальше вступают бизнес-ограничения. Правила магазина требуют подтвердить личность, менять только товары из доставленного заказа и получить согласие. Для нашего сценария критично: обменять модно только один раз, поэтому обе позиции нужно подготовить заранее. Из данных это не следует, правило живёт на уровне бизнеса. Критерии успеха фиксируют итог: в заказе появляются нужные варианты клавиатуры и термостата, пользователь получает возврат разницы на карту, агент объясняет условия и дожидается подтверждения. ⬥⬥⬥ 3. Слой исполнения Симулятор раскрывает запрос Yusuf. Агент уточняет детали, читает заказ, подбирает варианты и решает, когда проводить обмен. Оркестратор передаёт реплики, направляет вызовы в среду и пишет журнал. В голосовом режиме добавляются задержки, шум, перебивания и ошибки распознавания имени или подтверждения. ⬥⬥⬥ 4. Слой оценки Последний слой превращает испытание в результат: к какому состоянию агент привёл мир. Оценщик строит эталон из правильных действий. Для Yusuf это заказ, где обе позиции заменены одним вызовом, а разница возвращена на карту. Затем оценщик сравнивает состояние после действий агента с эталоном, если совпало — задача пройдена. Что входит в проверку, задаётся отдельно: состояние базы, обязательная информация в ответе или утверждения на естественном языке. У Yusuf всё держится на состоянии базы. Для надежности добавляется повторяемость: агент должен пройти одну задачу несколько раз подряд. Один удачный прогон плохо описывает надёжность. τ³-bench хороший пример устройства benchmark. И он же показывает, что такой инструмент требует отдельной работы: данных, сценариев, среды, оценщика и постоянной чистки ошибок в самих задачах. видео О чем молчит AI CTO

Внешний skill ≠ безопасный skill NVIDIA выпустила SkillSpector. Он проверяет skills на prompt injection, кражу данных, опасный код и уязвимые зависимости. Можно сканировать папку, файл или GitHub-репозиторий. Базовая проверка работает локально без LLM. Полезная привычка: прогонять через него каждый внешний skill перед установкой. #Skill О чем молчит AI CTO

Как Product Engineer может собирать интерфейсы За последние пару месяцев я собрал четыре прототипа: для геоаналитики, тендеров, обучения и работы с текстом. В нескольких случаях идея дошла до сервиса, которым пользуются десятки людей. На этих проектах я понял, что одного Claude Code недостаточно. Он хорошо реализует уже сформулированное решение. Но сначала идею нужно увидеть и собрать пользовательский сценарий. При работе с агентами результат часто прячется за полотном текста, но при этом непонятно, что увидит человек и как он будет пользоваться сервисом. Для меня рабочая схема сложилась так: Stitch → Claude Design → Claude Code + Impeccable ⬥⬥⬥ Stitch для меня стал личным визуальным черновиком. Сижу с чашкой чая, надиктовываю мысли о новом приложении и наблюдаю, как рядом появляются экраны. Пока смотришь, в голове возникают следующие вопросы: что должно быть на главной, нужен ли отдельный экран, где пользователь увидит результат. Я никогда не показываю эти черновики. В них можно зачеркнуть всё и начать сначала. Их задача в другом: помочь мне самому понять верхнеуровневый стиль, состав экранов и основной use case. Stitch пока сырой. Русскую речь он понимает, но часто переводит разговор на английский. Голосовой режим хорошо подходит для момента, когда мысль проще проговорить, чем превратить в требования. Отдельно я бы смотрел на DESIGN.md. Google развивает его как формат, через который можно объяснить дизайн агентам. В моём процессе этот файл дальше становится частью общего контекста разработки. Из Stitch я выхожу, когда сценарий стал ясным у меня в голове. ⬥⬥⬥ В Claude Design черновик превращается в прототип, который уже можно обсуждать. Здесь я прохожу конкретные use cases: переходы, формы, всплывающие окна и состояния интерфейса. Что увидит пользователь после действия? Как выглядит ошибка? Что произойдёт, если данных пока нет? Если основной клиент продукта я сам, прототип согласовываю с собой. Если есть Product Owner, показываю ему. Для прототипа этого достаточно: нужно зафиксировать основной сценарий, ключевые состояния и визуальное направление. Самая полезная часть Claude Design в моём процессе связана с GitHub. Согласованный прототип превращается в код, после чего источником истины становится репозиторий. ⬥⬥⬥ Дальше начинается полноценная разработка. В какой-то момент над бэклогом одновременно работают несколько агентов: добавляют функции, закрывают задачи, чинят баги. И тут интерфейс начинает расплываться. Каждый агент может нормально решить свою локальную задачу, а вместе они принесут разные отступы, компоненты и представления о хорошем UX. Поэтому агенты получают PRODUCT.md, DESIGN.md и прогоняют Impeccable на своей части работы. Impeccable даёт им общий язык frontend-качества. Он замечает лишние контейнеры, слабую визуальную иерархию, случайные цвета, отсутствие состояний и плохую адаптивность. При этом инструмент достаточно самостоятелен. Если экран и сценарий уже понятны, Stitch можно пропустить. Для небольшой доработки я сразу иду в Claude Code с Impeccable. ⬥⬥⬥ Claude Code остаётся ядром разработки, но одного универсального агента мало. На разных этапах нужны свои усилители: один помогает додумать идею экраном, другой собирает сценарий, третий удерживает качество реализации. Порог входа в смежные роли снизился. Product Engineer может быстрее освоить их рабочий минимум, задавать более точные вопросы и самостоятельно собирать прототипы. Инструменты не делают его дизайнером или frontend-экспертом. Они дают практику и обратную связь, через которые постепенно появляется новая компетенция. Здесь же находится риск. AI усиливает то, что вы уже умеете, и выдаёт убедительный результат там, где знаний пока не хватает. Нужно различать собственную компетенцию и качество ответа модели. Инструменты позволяют одному человеку пройти больше этапов разработки. Вместе с этим растёт число решений, за которые он отвечает. Какие специализированные усилители вы уже добавили вокруг Claude Code, чтобы закрыть свои слабые зоны? #ProductEngineering О чем молчит AI CTO

Если раньше весь бизнес можно было вести в Excel (а позже в Google Sheets), то теперь нам нужен только один инструмент - Codex (ну или Claude). Внедренная система плагинов позволяет автоматизировать процессы не выходя за рамки инструмента с умным ассистентом, пишем код, заказываем пиццу, строим продуктовые dashboards и выбираем фильм на вечер, и все это, не закрывая Codex. Там обрабатывается входящая почта, анализируются таблицы и составляются презентации. А многие и TG почти автоматизировали %) Но чтобы научить всех пользоваться этими инструментами правильно, Anthropic и OpenAI идут в консалтинг и собираются обучать специалистов по внедрению своих наработок в бизнес. Кажется, Windows и Excel пора подвинуться в сторонку. Но есть и другая правда, одного AI недостаточно, что бы делать большие, надежные и масштабируемые сервисы. О чем молчит AI CTO

Как ИИ меняет разработку изнутри: расскажем на закрытой сессии red_mad_robot ИИ в разработке уже прошёл этап личных экспериментов: почти все подключают его к задачам, ускоряют рутину и видят первые результаты. Но эффект часто остаётся локальным и не меняет процесс системно. 28 мая в офисе red_mad_robot посмотрим, как перевести этот опыт на уровень команды: через практику инженера, лида и тех, кто отвечает за результат. В программе — три практических блока: 1️⃣ Куда движется рынок и почему техкоманды становятся компактнее 2️⃣ Как переосмысляются роли в команде, а спецификации, тесты и архитектура превращаются в основу работы и продуктовых решений 3️⃣ Как строить AI-native команду QA и почему все начинается с лида Встреча пройдёт 28 мая в 18:00 в нашем офисе. Формат закрытый (количество мест ограничено), но если интересно, то оставляйте заявку через @redmadmadbot. #AI_moment #роботайм ↗️ red_mad_robot

Grill Me Мы разобрали, что AI помогает с личной эффективностьтю, и я решил делиться с вами интересными находками, которыми пользуюсь. Сегодня - Grill Me от Matt Pocock. В мае название особенно удачное 😃. Сам skill неожиданно короткий, но 97.4k ⭐️ на github говорят, что его не стоит пропускать. На русском он звучит так: Жестко расспроси меня про каждый аспект этого плана, пока мы не придем к общему пониманию. Пройди по каждой ветке дерева проектных решений и последовательно закрой зависимости между решениями. Если на вопрос можно ответить через изучение кодовой базы, сначала изучи кодовую базу. Для каждого вопроса предложи свой рекомендуемый ответ. Задавай вопросы по одному. Термин "дерево проектных решений" Pocock берет из книги Фредерика Брукса The Design of Design. Идея простая: когда мы проектируем систему, каждое решение открывает новые ветки. Выбрали расширенный поиск вместо одной строки - теперь нужно решить, какие будут фильтры, сортировки, состояния пустой выдачи, права доступа, поведение на мобильном экране. Хороший дизайн требует пройти эти развилки до того, как агент начнет писать код. Для сложных задач агент задает по 30, 40, 50 вопросов и это может затягиваться почти на полчаса или дольше. Мне кажется, это хороший пример в агентной разработки, полезный навык может быть очень коротким, но если под ним скрывается идея, методология или часть общего процесса - это то, что нужно. Если у вас есть любимые agent skills, кидайте. Соберем полку для рубрики. Оригинал: https://github.com/mattpocock/skills/blob/main/skills/grill-me/SKILL.md Дополнительный разбор: https://www.aihero.dev/5-agent-skills-i-use-every-day #Skill О чем молчит AI CTO

Где GenAI сейчас работает? Вижу всё больше людей, которые раньше были равнодушны к современным веяниям AI, а теперь пытаются осознать текущую ситуацию и начать применять инструменты, чтобы стать эффективнее в жизни и работе. И, кажется, я виновен в том, что немного запутал ребят. Дело в том, что в начале года я с командой собрал материал по построению агентов и запустил обучающий курс внутри компании, но не объяснил, а где же они нужны и в каком виде. Придется исправляться. Личная эффективность Сейчас относительно тяжелая ситуация на рынке труда: компании борются за эффективность и требуют от специалистов всё больше и больше. В IT стал очень заметен разрыв между теми, кто активно пользуется AI, и теми, кто выжидает лучшего времени. Если вы пришли в IT ради зарплаты — вам тяжело. Если вы любите следить за каждой строкой кода, бьетесь за производительность и эффективность — вас закидают AI-шлаком, но, несмотря на это, от вас всё равно будут ждать кратного ускорения. Первое, с чем сталкиваются те, кто хочет не отставать от развития — это вопрос: как поднять свою эффективность, справиться с новыми скоростями, не упасть в качестве, сохранить хоть какой-то work-life balance и при этом расти над собой? Сейчас появился новый рабочий класс инструментов — помощник, который всегда готов поддержать. Он проанализирует за вас тонну сообщений в Telegram и выделит главное, поможет отрефлексировать проведенную встречу с клиентом и подскажет ошибки в вашей презентации. Его не нужно ждать, он готов работать прямо сейчас, параллельно с вами. Каких-то специальных универсальных инструментов для этого пока не придумано, каждый экспериментирует сам, применяя различные методологии и свои соображения. Главный вывод: личному помощнику нужно оставлять как можно больше контекста из вашей жизни и работы. Попробуйте вбить на YouTube Claude Code + Obsidian и посмотрите, как много людей применяют подобные подходы. Рекомендую ознакомиться с этими инструментами, но не обязательно использовать именно их, если вы привыкли работать с другими. Важна сама идея: в одном месте мы складываем информацию и связываем её друг с другом, в другом — анализируем и развиваем. И хотя Claude Code, Codex, Antigravity и прочие решения были созданы для разработчиков, они потихоньку выходят в жизнь обычных пользователей и становятся личными агентами. Остается их только правильно настроить, скачать нужные под вашу работу скиллы, настроить автоматизации и так далее. Больше вам ничего не нужно: никаких новых агентов создавать нет необходимости, достаточно одного из этих инструментов! Эффективность разработки AI уже стал частью ежедневной инженерной работы. Один разработчик довольно быстро поймет, как ускориться. Гораздо сложнее встроить AI в совместную работу команды и передачи контекста между сотрудниками и их агентами. Часто передача собранного с агентом md-файла со своими наработками работает в разы лучше любых презентаций. Материала по этому направлению много, поэтому идем дальше. Автоматизация бизнес-процессов AI становится частью повторяемого бизнес-процесса. И вот сюда как раз относился мой хардкорный материал, который мы собирали в начале года. Здесь уже недостаточно личного помощника, перед нами стоят другие задачи: - Как оптимизировать вызовы модели и управлять стоимостью? - Где можно перейти на маленькие и быстрые LLM? - Как разделить шаги между LLM, обычным кодом и детерминированной логикой? - Как построить полноценный eval-контур (оценку качества на наборах кейсов)? Для личных задач eval-контур избыточен. Но когда агент становится частью бизнес-процесса — это жизненная необходимость. Готовьтесь к архитектуре, логам и прямой ответственности за результат. ⬥⬥⬥ Главный вывод - начинайте с себя. Только осознав, как AI помогает лично вам, можно понять, как его встроить в процессы. Считаете иначе? Поделитесь своим мнением) О чем молчит AI CTO

Agentic Protocols как интерфейсные границы агента. Часть 2 ACP: слой рабочей среды Agent Client Protocol решает задачу взаимодействия между редактором и кодовым агентом. В отличие от продуктового чата, IDE является средой исполнения: агент может читать файлы, запускать терминал, предлагать diff и инициировать изменения в рабочем дереве. ACP использует двунаправленный JSON-RPC: через команду initialize редактор и агент согласуют версию протокола и доступные возможности, через session/new редактор создает рабочую сессию, передает рабочую директорию и список MCP-серверов для подключения, а через session/prompt отправляет пользовательскую задачу в уже созданную сессию. В ответ агент возвращает поток session/update, публикует вызовы инструментов и может запросить разрешение через session/request_permission. В результате редактор видит ход выполнения: сообщения агента, действия с файлами, работу терминала и запросы на подтверждение. Главный архитектурный принцип ACP — сохранение контроля за клиентом. Редактор владеет файловой системой, терминалом, UX и потоком пользовательских разрешений. Агент действует в этой сессии, а изменение среды проходит через явное разрешение. Такой подход близок к роли LSP в классической разработке: протокол отделяет инструмент от редактора и позволяет подключать разных агентов к рабочим средам через единый контракт. Главное ограничение ACP — привязка к редакторскому сценарию. Протокол хорошо описывает сессию “человек — IDE — агент”, но не решает задачи межагентного делегирования, пользовательского интерфейса поверх серверного процесса или доступа к внешним корпоративным системам. Эти контуры остаются за другими протоколами. AG-UI: слой пользовательского интерфейса AG-UI описывает взаимодействие между пользовательским приложением и агентом. Его задача — превратить работу агента в наблюдаемый поток событий. Типичная схема “запрос — ответ” недостаточен для агентных сценариев: агент может выполнять несколько вызовов инструментов, обновлять состояние, ждать решения пользователя и формировать частичный ответ. AG-UI вводит событийную модель: события RunAgentInput запускает выполнение, BaseEvent передает изменения состояния, TEXT_MESSAGE_* отвечает за потоковую передачу текста, TOOL_CALL_* показывает вызовы инструментов, а STATE_SNAPSHOT и STATE_DELTA обновляют состояние интерфейса. Для сценариев, которые не покрыты стандартным набором событий, предусмотрены пользовательские события: через них можно передавать данные прикладной области без изменения базового протокола. Важно, что AG-UI не является спецификацией генерации интерфейса. Агент передает события, состояние, сообщения и намерения, а пользовательское приложение должно уметь это отрисовать. Если агент должен вернуть данные вместе с описанием компонента интерфейса, нужны отдельные спецификации генеративного UI или заранее реализованные компоненты на стороне приложения. (но AG-UI может использоваться вместе со спецификацией A2UI для генеративного UI) В результате агент может использовать MCP, A2A или собственную оркестрацию, а пользовательское приложение получает стабильный поток событий для отображения прогресса, состояния и участия человека в процессе. Ограничение AG-UI связано с его зрелостью. CopilotKit описывает AG-UI как протокол, который развивается командой CopilotKit совместно с интеграционными партнерами. Протокол может быть пригоден для продукта, но риск остается: при слабом внешнем управлении развитие стандарта зависит от активности конкретной команды и экосистемы вокруг нее. Вывод Выбор протокола это выбор границ агента, которую мы проектируем. Он позволяет избавится от конкретных реализаций компонентов и оставаться на определенном уровне абстракций при проектировании систем. #AgentEngineering О чем молчит AI CTO

Agentic Protocols как интерфейсные границы агента. Часть 1 Как подключить агента к чату? Из этого вопроса появилась статья. Классический ответ — использовать OpenAI-compatible chat API, аналогично обычному подключению LLM. Это самое популярное решение из-за простоты, но оно плохо описывает агентную работу за пределами текстового ответа. В архитектуре агентной системы протокол фиксирует формат обмена сообщениями и границу ответственности между агентом и внешней средой. Каждый протокол решает базовую инженерную задачу: унифицирует взаимодействие. Но агентный мир еще молод. В нем мало устоявшихся паттернов взаимодействия, а сами протоколы остаются сырыми: часть возможностей дублируется, границы применения не всегда очевидны, траектория развития отдельных стандартов пока не гарантирована. Ниже разберем четыре наиболее заметных протокола MCP: слой инструментального доступа Model Context Protocol стандартизирует связь между AI-приложением и внешними источниками контекста. В базовой архитектуре есть три роли: * Host — приложение, в котором живет агентный UX. * Client — протокольная сессия между host и конкретным MCP-server. * Server — источник tools, resources и prompts. Основная функция MCP — сделать возможности внешней системы агенто-читаемыми. Сервер объявляет tools/list, описывает входные схемы, возвращает ресурсы и принимает tools/call. Для агента MCP становится основной абстракцией над детерминированными сервисами. Вместо проектирования UI только для человека команда начинает проектировать агентскую логику взаимодействия: какие действия доступны агенту, какие входные параметры нужны, какой результат возвращается и где контролируется состояние. На практике рядом с MCP уже существует другой подход: CLI-инструмент + описание skill для его использования. Для кодовых агентов это часто быстрее и дешевле по интеграции. Но CLI, в отличие от MCP, не является общим стандартом взаимодействия. Поэтому рынок сейчас находится в зоне неопределенности: часть задач уходит в простые CLI-контуры, часть требует стандартизированного протокола. У MCP есть и другая проблема. Протокол описывает инструмент, но не гарантирует природу того, что скрыто за ним. За MCP-сервером может стоять детерминированный сервис или отдельный агентный контур. Для вызывающей стороны это принципиально разные модели поведения: в одном случае ожидается предсказуемая операция, в другом — автономное рассуждение и собственный выбор действий. Сам протокол пока слабо помогает обнаружить эту разницу и управлять ею. A2A: слой межагентного делегирования Agent-to-Agent описывает взаимодействие между автономными агентами. В этом слое удаленная система рассматривается как исполнитель задачи со своими навыками, правилами доступа и внутренним процессом. Базовая единица обнаружения в A2A — Agent Card. Она содержит: * имя и описание агента; * адрес вызова и поддерживаемые способы транспорта; * список навыков; * схемы безопасности; * режимы входных и выходных данных; * возможности вроде потоковой передачи или push-уведомлений. Работа описывается через жизненный цикл задачи: submitted, working, input-required, completed, failed, canceled. Результатом становится Artifact: отчет, JSON, файл или другой формализованный результат. Главная особенность A2A — сокрытие реализации. Вызывающая сторона знает, что агент существует, видит описание его навыков и получает статус задачи. Как агент рассуждает, какие инструменты применяет и какие внутренние шаги выполняет, протокол не раскрывает. При этом A2A плохо подходит для сценариев с sub-agent в духе Claude Code, где нужна максимальная прозрачность действий: план, вызовы инструментов, промежуточные выводы и контроль исполнения. Область применения A2A поэтому остается ограниченной. Вероятно, потенциал протокола еще не раскрылся полностью из-за слабой зрелости мультиагентных систем. Также A2A сам по себе не решает проблему взаимодействия N x M агентов. Организация маршрутизации, выбора исполнителя и общей координации остается задачей архитектуры мультиагентной системы. #AgentEngineering О чем молчит AI CTO