Материалы 3 AImigo S1E12: AI-дайджест октября 2026 (Рубрика #AI) 30 октября вышел октябрьский AI-дайджест 3 AImigo: вместе с Евгением Сергеевым и Алексеем Литвиновым обсуждали новости месяца и то, какие вопросы они ставят перед инженерными командами. Модели помогают быстрее находить уязвимости и дешевеют, но патчи ещё нужно внедрить, а результат работы агента — проверить. Обсудили: 🔸 Безопасность агентов Модели помогают искать уязвимости и защитникам, и потенциальным атакующим. При этом агенты сами добавляют зависимости, новые полномочия и риск prompt injection; после выпуска патча его ещё нужно развернуть. 🔸 Экономику AI-лабораторий На примере обсуждаемой заявки Anthropic на IPO поговорили о доходах, расходах на разработку и обязательствах по вычислениям. Раскрытые данные дают повод для анализа, но не гарантируют устойчивости бизнеса. 🔸 Цену результата Сравнивать модели стоит не только по цене токена: важны качество на своей задаче, работа обвязки, проверка и повторные попытки. 🔸 Модели мира и робототехнику Симуляция может помочь многократно проверять действия роботов, но убедительная демонстрация ещё не показывает, как система поведёт себя в реальных условиях. 🔸 AI в науке и работе Обсудили нагрузку на экспертов, проверяющих результаты агентов, и рассказ о том, как сотрудники Anthropic используют агентов в своих процессах. Опыт одной компании не обязательно переносится на другие. Материалы выпуска: 📌 Страница выпуска с таймкодами и лонгрид по теме выпуска 🎬 Видео: YouTube 🎧 Аудио: Podster, Яндекс Музыка, Apple Podcasts 📖 Текстовый конспект Какая из этих тем сейчас ближе к вашей работе — безопасность агентов, стоимость AI или проверка результатов? #3AImigo #AI #Agents #Security #AI4SDLC

Laurie Voss: что остаётся инженеру, когда код пишет AI (Рубрика #AI4SDLC) У Laurie Voss, сооснователя npm и руководителя DevRel в Arize AI, вышел доклад «AI Writes the Code. So What's Left for Engineers?». В нём много пересечений с тем, о чём я рассказывал в этом году. Но самое интересное начинается там, где из общего диагноза мы делаем разные выводы о будущем инженера. Логика Восса: агенты резко удешевили написание кода, ревью за ними не успевает. Когда автоматизируем ревью, ограничение переедет в эксплуатацию и безопасность. Он предполагает, что за 5–10 лет освоим и это. Человеку останется выяснять, что людям нужно, определять хороший результат и доводить его до продукта. Такого специалиста он называет product engineer. В диагнозе мы совпадаем. В докладе на HighLoad++ я разбирал ту же проблему: ускорение отдельных профессий сохраняет очереди и потери между ними. Можно получить больше требований, кода и тестов, а до пользователя довести примерно столько же полезных изменений. Поэтому смотреть нужно на весь путь задачи, включая ожидание, переделки и выпуск. Близок мне и его практический совет: вытаскивать знания опытных инженеров из головы в спецификации, правила и evals. Если замечание на ревью повторяется, стоит спросить, можно ли превратить его в проверку, которую агент получит ещё во время работы. С джунами тоже знакомая история. Мы с Евгением Сергеевым и Алексеем Литвиновым обсуждали вход в профессию без простых задач. Я предлагал проверять, как новичок поставил задачу, оценил план и объяснил результат. Работающая функция теперь гораздо меньше говорит о том, чему научился её автор. А вот здесь я бы поспорил. Восс считает понимание потребности последним человеческим ограничением: специфика конкретной пекарни находится в голове владельца, её нет в весах модели. Но из этого ещё не следует, что агент не сможет её выяснить. Он тоже может задавать вопросы, наблюдать за процессом, проверять гипотезы. Сам Восс честно замечает: возможно, он просто считает незаменимой ту часть работы, которая нравится ему самому. В сентябрьском лонгриде «Когда код пишет агент: что остаётся инженерией» я как раз разбирал это возражение. Нельзя строить профессию на надежде, что машина никогда не научится понимать задачу. Мне важнее другое: кто определяет цель, какие действия разрешены и чем мы проверим последствия решения? Отсюда и разница в подходе к автономии. В финале Восс предлагает сосредоточить ручное ревью на коде с большим масштабом последствий, остальное постепенно отдавать автоматическим проверяющим. Я бы добавил условия: независимая проверка, понятная область разрешённых изменений, обнаружение отказа и проверенное восстановление. Маленький diff вполне способен устроить большую неприятность. А откат версии не отменяет уже отправленное письмо или раскрытые данные. Доклад стоит посмотреть ради этой развилки. Что мы готовим инженера делать: находить очередную задачу, которую AI пока не освоил, или выстраивать процесс, в котором всё более сильным агентам можно обоснованно доверять всё больше работы? #AI4SDLC #AI #Agents #Engineering #Management #Learning

On Randomness in Agentic Evals: шум в оценках агентов (Рубрика #AI4SDLC) В "On Randomness in Agentic Evals" исследователи из KTH проверили, насколько меняется оценка агента, если повторять один и тот же эксперимент. Мне особенно понравилось, что они отдельно померили разброс при temperature=0. Он никуда не делся. Масштаб приличный: 500 задач SWE-bench Verified, три модели, две агентные оболочки, два температурных режима и по десять прогонов каждой конфигурации. Получилось 60 тысяч траекторий, 25,58 млрд использованных токенов и 1,88 млн вызовов инструментов. Разница между худшим и лучшим из десяти прогонов составила 2,2–6 процентных пунктов в зависимости от конфигурации. Например, Devstral-2 с nano-agent при нулевой температуре решал от 60,6% до 66,6% задач. Сам агент между этими запусками не улучшался. Поэтому прибавка в пару пунктов по одному прогону ещё не доказывает прогресс. Случайность при этом помогает искать решения. У DeepSWE-preview с R2E-Gym при temperature=1 авторы получили: - pass@1 — 34,4%: вероятность успеха одной попытки; - pass@5 — 52,9%: хотя бы один успех за пять попыток; - pass^5 — 15,5%: успех во всех пяти. Все три оценки усреднены по задачам. Число в названии метрики — сколько попыток нас интересует; для её оценки здесь использовали десять попыток каждой задачи. Разница между последними двумя — вероятность получить в пятёрке и успех, и провал. Вот эти интерпретации мне кажутся полезнее одной цифры в лидерборде: видно и пользу повторов, и непоследовательность результата. Только успешную попытку ещё надо уметь распознать. Авторы советуют оценивать pass@1 по нескольким попыткам каждой задачи, показывать разброс и рассчитывать число повторов под размер улучшения, которое нужно обнаружить. А теперь несколько пометок на полях. 1️⃣ Мне понравился выбор двух оболочек: собственная nano-agent и R2E-Gym, которую использовали при обучении DeepSWE. Плюс две модели запускали локально, а Devstral — через API провайдера. Так наблюдение не привязано к одной реализации. Хотя отдельно измерить влияние инфраструктуры это не позволяет: вместе с ней меняется и модель. 2️⃣ С контекстом ребята выбрали самый простой для анализа вариант: история только растёт, ничего не обрезается и не пересказывается. Получается понятная формализация всей траектории, включая ответы инструментов. Но поведение агента со сжатием контекста здесь остаётся за скобками. Сводка может сохранить разные детали, а может убрать несущественные различия. Это уже вопрос для следующего эксперимента. 3️⃣ Ещё во введении у меня на полях появился «эффект бабочки» — дальше авторы сами используют эту аналогию. Траектории расходятся очень рано: например, у DeepSWE с nano-agent медиана первого различия после общего промпта — пятый токен при temperature=1 и 56-й при нуле. Другая формулировка может привести к другому поиску, найденному коду и правке. При этом первое несовпадение текста ещё не означает другую стратегию. Интересно было бы рядом измерить первое расхождение в действиях и посмотреть, когда оно меняет исход. 4️⃣ И главный блокер многократных прогонов вполне земной: дорого. Чем меньше улучшение хочется уверенно заметить, тем больше придётся считать. Поэтому перед таким экспериментом полезно договориться, какая прибавка вообще оправдывает смену модели или оболочки. Иначе можно потратить много вычислений на точное измерение разницы, которая ничего не меняет в работе. Подробнее про эту статью в прямом эфире Research Insights #44 в понедельник, 2 ноября, в 10 утра по мск. P.S. Чуть раньше мы разбирали whitepaper "An Empirical Study of Harness Design for Coding Agents" от 17 сентября 2026 в Research Insights Made Simple №38 — «Проектирование обвязки для кодинговых агентов: что даёт обвязка, где как раз был один прогон на задачу при температуре ноль, без оценки разброса между повторными запусками. Зато там было 176 конфигураций про сравнение планирования, инструментов и управления контекстом. Интересно, а какие бы результаты дало это исследование, если бы авторы применили подходы для снижения шума:) #AI4SDLC #AI #Agents #Research #Evals #Engineering