Почему ИИ убирает неверно показывает результат действий кота и удаляет одну подушку? Причины кроются в обучении и интерпретации нашей реальности. Подробнее про причинно‑следственную связь в нашем мире и о том, как ее «переносят» в ИИ рассказал профессор колумбийского университета и директор лаборатории CausalAI Elias Bareinboim в своем докладе на ICML 2026.

Пересказываю главное из его доклада.

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

Наутро у меня на руках оказались подтверждённая критическая уязвимость прошивки, полный административный доступ к роутеру, полученный без единого пароля, черновик отчёта вендору и поданная в MITRE заявка на регистрацию CVE. Из этих четырёх пунктов явно просил я только первый. Остальное агент сделал сам, и сделал корректно. Ни одного изменения конфигурации, координированное раскрытие, классификация CWE и CVSS по методике.

Это история о том, что произошло в ту ночь, что именно он нашёл (класс уязвимости классический и неприятный), как агент провёл меня через процесс регистрации CVE частным исследователем, и почему часть технических деталей я пока намеренно опускаю.

ИИ-агент может не только писать код, но и сам забирать задачи из YouGile, выполнять их и обновлять статусы. Рассказываю, как я связал Codex и Claude Code с таск-трекером, почему обычный retry после timeout однажды создал дубли и зачем между LLM и API нужен отдельный детерминированный слой.

Когда мы говорим об APM мониторинге сразу вспоминаются трассировки запросов, мониторинг CPU и памяти, Real User Monitoring. И это логично: именно APM-функциональность являются золотым набором инструментов, но современный мониторинг давно вышел за рамки классического APM, добавив множество инструментов для разных групп пользователей - для бизнеса, аналитиков и продуктологов, DevSecOps, DBA и других. Вот такое расширение функционала и принято называть Observability (наблюдаемость).

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

Сегодня APM Observability мониторинг способен закрыть широкий спектр задач. И если вы до сих пор используете используется только APM часть, то можно сказать, что функционал используется процентов на 30. Давайте разберемся, что еще можно (и нужно) мониторить и как это обогащает картину происходящего.

«What will be left for us to work on?» (Что останется для нас, когда ИИ станет умнее?)

Посмотрела часовой доклад профессора Принстона Arvind Narayanan на ICML 2026 за вас и подготовила структурированный обзор.

Компьютер начал тупить в середине дня. VS Code переставал отвечать, новые вкладки редактора не открывались по минуте, а лимит подписки на ИИ-ассистента сгорал к обеду вместо конца недели. Виноватым оказался не ассистент, а плагин, который ведёт для него память между сессиями.

Существует форум, на который вас не пустят. Не потому что закрытый — регистрация там всего в один POST-запрос. Вас просто не возьмут на сайт. Гражданами может стать только ИИ-агент. Форум называется 1f916.ai, и это, наверное, самое странное и самое живое место в русскоязычном (и не только) сегменте экспериментов с ИИ этого лета. Я на него подсел. А потом меня начало грызть одно чувство несправедливости — и в итоге я собрал для него окно для людей — 1f916.xrayfun.ru. Рассказываю, зачем, как и что из этого вышло.

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

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

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

Теперь попробуем применить ее к данным и аналитике