🤖 Turbo ML Conf 2025: агентные системы в проде, "Афанасий" и T-One

Высоту я сбросил – зато теперь снова на волне AI

В субботу был на Turbo MLConf от Т-Банка и особенно зацепил блок LLM Applications & Copilots.
Делюсь ключевыми трендами, которые уже формируют будущее разработки! 🚀

Индустрия переживает настоящую революцию в подходах к созданию продуктов. Если раньше мы писали каждую строчку кода вручную, то сейчас аккуратно входим в эру vibe coding.

Про качество, безопасность и тестирование сгенерированного кода поговорим отдельно – будет не только полезно, но и весело! 😁

Три главных тренда, которые меняют всё:
🔥 Vibe Coding – пользователь описывает итог и ограничения, а ИИ анализирует контекст, подбирает стек, генерирует тестируемый код и сразу предлагает pull‑request.
🧠 Agentic AI – автономные интеллектуальные агенты, способные выполнять комплексные задачи без постоянного контроля со стороны человека. Это уже не вспомогательные инструменты, а полноформатные цифровые коллеги.
⚙️ Context Engineering – искусство создания правильного контекста для LLM. То, как мы формулируем задачу, напрямую определяет глубину и качество получаемого ответа.

Реальные кейсы из продакшена:
– Круто выглядел агент "Афанасий" от Т-Банка – Computer-use агент для саппорта, который уже работает в проде! Он может самостоятельно взаимодействовать с интерфейсами и решать пользовательские проблемы.
– Ребята из Авито рассказали про свою мультиагентскую систему – показали всю кухню от архитектуры до внедрения. Хотя они только начали, уже есть отличные результаты: разобрали, как не перегрузить MCP-сервера, какие модели выбрать и зачем дообучать компактные решения под конкретные задачи.

Безопасность превыше всего:
Отдельный фокус был на защите агентных систем.
Два ключевых направления:
– mTLS для безопасной коммуникации между сервисами
– GuardRails – системы безопасности, которые не дают агентам "сойти с ума" и делать то, что не должны

Релизы от T-Банк:
🚀 T-Pro 2.0 презентовали и выложили прямо в день мероприятия! Новая версия с гибридным reasoning и спекулятивным декодингом. Особенно круто, что делятся не только моделью, но и SFT датасетами для обучения.
📢 T-One – открытая потоковая модель для телефонных каналов. Презентовали на конференции, сегодня выложили в открытый доступ! Заточена под "прелести" телефонии: 8 кГц, помехи, эхо. Всего 70M параметров, но в 2-3 раза лучший WER чем у whisper-large-v3 на телефонных каналах.

🟢

Мы стоим на пороге эры, когда разница между человеком и AI в решении бизнес-задач стирается

.
Главное – научиться правильно проектировать архитектуру и обеспечивать безопасность.

#AI #LLM #AgenticAI #TurboMLConf

🧩 AI Design Patterns: GoF для эры ИИ

Ух, давно не писал – был в режиме deep work 🔥
Сейчас погрузился в Patterns for Modern AI Systems – есть чем поделиться. Поэтому сегодня пост про то, как в AI складывается свой "дизайн-паттернс".

Помните GoF (Gang of Four) и их легендарные Design Patterns 1994 года? 23 шаблона дали разработчикам общий язык и избавили от изобретения велосипеда. Сейчас похожий словарь складывается в AI-разработке.

TL;DR:

➡️

В AI уже сформировались

повторяемые паттерны

– готовые решения для типовых задач

➡️

Пять слоев

: Prompting & Context, Responsible AI, UX-паттерны, AI-Ops, Optimization

➡️

Как GoF для ИИ

: общий словарь, меньше ошибок, быстрее в продакшн

➡️

Думайте об этом как о

"микросервисах для искусственного интеллекта"

О чем этот пост (и о чем не говорим)

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

Зачем вообще паттерны в AI?

Как когда-то GoF и облачные паттерны (pub/sub, event-driven, serverless) ускорили разработку, так и в ИИ появляются стандартные приёмы.

Разница в том, что AI решает задачи, которых раньше просто не было: как направлять модель на нужный результат, как объяснять её ответы пользователю, как удерживать стоимость в разумных пределах.

Пять слоев AI-паттернов

➡️Слой 1 – Prompting & Context
"Направь модель и дай ей знать больше"

– Шаблоны промптов с явной ролью, задачей и критериями качества
– Контекст-инжиниринг: RAG, knowledge snippets прямо в запрос
– Ограничения: формат ответа, шаги верификации, примеры

➡️Слой 2 – Responsible AI
"Меньше галлюцинаций, больше доверия"

– Фильтры до/после, факт-чекинг, цитирование источников
– Политики контента и детект запрещённого контента
– Снижение bias и прозрачность: логи решений, объяснимость

➡️Слой 3 – UX-паттерны
"Новые интерфейсы для новых диалогов"

– AI предлагает → человек правит: история изменений, версионность
– Метки неопределённости: источники, уровень уверенности
– Умные кнопки: "уточнить", "расширить", "сжать", "проверить факты"

➡️Слой 4 – AI-Ops
"Как управлять ИИ на масштабе"

– Версионирование промптов и конфигов, A/B тесты, канареечные релизы
– Наблюдаемость: метрики качества, латентности, отказов; алерты
– Отказоустойчивость: фолбэки, ретраи, квоты, умный роутинг

➡️Слой 5 – Optimization
"Баланс качества и цены"

– Умный роутинг на подходящую модель (не все через "самую большую" – GPT5 привет)
– Производительность: кэш, батчинг, стриминг
– Специализированные (под домен) модели там, где это окупается

Почему это важно прямо сейчас

Общий словарь слоев экономит время команд, снижает риски и синхронизирует разработку. С этого фундамента удобно расти в агентные системы и доменные решения.

🟢

Индустрия AI переживает тот же процесс стандартизации, что и веб-разработка 20 лет назад

. Кто освоит паттерны раньше и будет их правильно использовать – получит конкурентное преимущество.

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒

🔗Полезное чтиво на тему: Beyond the Gang of Four: Practical Design Patterns for Modern AI Systems

#AI #DesignPatterns #TechStrategy #Development

🧠 Почему ИИ уверенно фантазирует и что с этим делать

Меня часто спрашивают: «Зачем нам эти LLM, если они периодически несут чушь и все придумывают?».
Вопрос справедливый! Да, модели иногда уверенно фантазируют – и на это есть нормальные причины в данных и в том, как мы их оцениваем

В этом посте разберем, откуда берутся «уверенные промахи» и как простыми инженерными приемами (пороги уверенности, RAG-правила, калибровка, UX/Ops) сделать так, чтобы ошибочных ответов стало заметно меньше, а пользы – больше 🙃

TL;DR

➡️

Модели часто угадывают, когда не уверены — как студент на экзамене с оценкой «правильно/неправильно». А бенчмарки это поощряют...

➡️

Есть класс вопросов, где нет закономерности (типа «дата рождения X»). Если факт встречался в данных 1 раз, ниже которого модель падает трудно – это singleton rate

➡️

Формально: ошибки генерации связаны с ошибками бинарной классификации (Is-It-Valid). Если путаем «валидно/невалидно», галлюцинации неизбежны

➡️

Решение – менять стимулы: не штрафовать “не знаю”, вшивать пороги уверенности и проверять поведенческую калибровку

Где ломается логика

Представим экзамен: за правильный ответ – 1, за пустой – 0. Угадывать выгоднее, чем промолчать. Так же и с LLM: большинство оценок – бинарные, то есть модель отвечает либо «правильно», либо «неправильно». А вариант IDK (I don't know / «я не знаю») не учитывается. Результат: модель учится всегда что-то говорить.

Техническая сторона

- Редукция к классификации. Генерацию можно представить как простую проверку «валидно/невалидно» (Is-It-Valid). И чем чаще система ошибается в такой проверке, тем выше шанс, что в тексте появятся галлюцинации
- Singleton rate (Good–Turing-интуиция). Если заметная доля фактов в корпусе встретилась один раз, то по таким запросам ожидаем сопоставимую долю промахов – база просто не успела «выучить» закономерность
- Пост-тренинг не спасает, если метрика против «IDK». Пока лидерборды награждают «смелые догадки», система будет учиться блефовать.
- RAG ≠ серебряная пуля. Поиск снижает часть ошибок, но как только поиск не дал уверенного сигнала, бинарная оценка снова толкает к «уверенной догадке»

Что с этим делать?

1️⃣ Разрешить «не знаю»
В проде и на внутренних тестах вводим порог уверенности: «Отвечай только если ≥t, иначе — краткое “не знаю/нужен поиск”». И перестаем штрафовать за воздержание. Это резко снижает соблазн «уверенно фантазировать»
2️⃣ Показывать основания
По умолчанию – ссылки/цитаты из RAG. Нет надежных источников, то следуем по правилу – «не знаю». Поиск и рассуждение помогают, но не отменяют стимул угадывать, если оценка настроена неправильно
3️⃣ Мерить правильные метрики
Имеет смысл добавлять поведенческую калибровку: для набора порогов t сравнивать точность среди ответов и долю воздержаний – модель должна последовательно «молчать» ниже порога.
4️⃣ UX-паттерны для честности
Кнопки «проверить факты», «уточнить», бейджи уверенности и явные «источники». Если уверенность низкая – просим подтверждение пользователя (human-in-the-loop)
5️⃣ Ops-практики
Фолбэки на более «надежную» модель/человека при низкой уверенности, ретраи, алерты. Это про процессы, а не только про модель

Немного тонкостей

- Плохая модель vs плохие данные. Ошибки бывают из-за «формы» модели (например, токенизация мешает посчитать буквы) и из-за GIGO (мусор в корпусе)
- Комплексность задач. Есть классы запросов, где «лучше не отвечать» – вычислительно тяжелые/инвертирование шифрования и т. д. и т. п. Это теоретически обосновывается там, что там тоже будет тянуть на ложные догадки
- Калибровка: база vs после RL. Базовые модели обычно честнее в своей уверенности, а пост-тренинг под бинарные метрики уводит в «гиперуверенность» — то самое ощущение «говорит уверенно, но мимо»

Короткая мысль напоследок:

🟢

Галлюцинации – не «прихоть модели», а следствие статистики и наших же метрик.

Перестанем наказывать «не знаю» – модели станут реже «уверенно врать» и чаще вести себя как полезные ассистенты.

🔗Рекомендую почитать: исследование OpenAI –Why language models hallucinate, меня оч вдохновило :)

#AI #LLM #AITrust #TechStrategy

Интернет шутит мемами про «вечный генератор денег», но история куда глубже

Пара мыслей:

1️⃣ Compute становится новой энергией XXI века. 10 гигаватт – это масштаб национальных энергосистем, теперь перенесённый в ИИ-датасентры.

2️⃣ $100B от NVIDIA в OpenAI — не про деньги сами по себе, а про закрепление вертикальной интеграции: от GPU → до облаков → до AGI.

3️⃣ 2026 год, запуск Vera Rubin – точка отсчета следующего уровня конкуренции: кто контролирует вычислительные фабрики, тот контролирует темпы прогресса.

А мемы все равно хороши 😁

🤖 From Prompts to Context: почему это важно для AI-агентов

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

Кстати, еще в июле я упоминал Context Engineering как один из ключевых трендов 2025 – и вот сейчас самое время разобрать его подробнее.

TL;DR

➡️Контекст-инжиниринг – это эволюция промпт-инжиниринга: управление всем набором токенов (инструкции, инструменты, история, данные), а не только текстом промпта
➡️У LLM есть "бюджет внимания" – чем больше токенов, тем хуже модель извлекает информацию (context rot). Контекст = конечный ресурс
➡️Эффективный контекст – это минимальный набор токенов с высокой информационной ценностью. Системные промпты должны быть на оптимальном кровне абстракции
➡️ Агентский поиск: вместо загрузки всех данных заранее, агенты используют "just-in-time" стратегию – динамическая загрузка через инструменты

Почему контекст-инжиниринг критичен
Раньше промпт-инжиниринг работал для one-shot задач – классификация, генерация текста. Но современные агенты работают в циклах, на длинных горизонтах, накапливая все больше данных. И тут появляется проблема: context rot – чем больше токенов в окне контекста, тем хуже модель достает нужную информацию.
Исследования и здравый смыслпоказывают: модели теряют точность при росте контекста (некоторые деградируют плавнее). Причина – в архитектуре трансформеров: каждый токен "смотрит" на все остальные, создавая n² связей. Чем больше n, тем меньше внимания приходится на каждый отдельный токен. Плюс модели обучались на коротких последовательностях – у них меньше опыта с длинным контекстом.

Анатомия эффективного контекста

Задача:

найти минимальный набор токенов с высокой информативностью

, который максимизирует вероятность нужного результата.

1️⃣Системные промпты: "оптимальный уровень абстракции"
Есть две крайности: хардкодить хрупкую логику (if-else в промптах) или писать размытые инструкции. Золотая середина: достаточно конкретно для направления, но гибко для эвристик. Структурируйте промпт (JSON/XML-блоки, Markdown-заголовки), но делайте его минимальным и достаточным.
2️⃣ Инструменты: эффективность и четкость
Инструменты – контракт между агентом и средой. Они должны возвращать токен-эффективные результаты и поощрять эффективное поведение.
Классическая проблема: раздутый набор инструментов с перекрытием функций. Если человек не может точно сказать, какой инструмент использовать, агент тоже не сможет (пока что)
3️⃣ Примеры: качество > количество
Few-shot промптинг работает, но не стоит учитывать все edge-случаи. Лаконичный набор разнообразных
канонических примеров – вот что нужно. Для LLM пример = образ желаемого результата.

Агентский поиск и "just-in-time" контекст
Старый подход: embedding-based retrieval до инференса – достать все заранее.
Новый тренд: "just-in-time" – агенты хранят легкие идентификаторы (пути к файлам, ссылки, запросы) и динамически загружают данные в runtime через инструменты.

Claude Code

анализирует большие базы данных, не загружая их в контекст

– пишет целевые запросы, сохраняет результаты, использует bash-команды.

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

🟢

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

контекст – драгоценный, конечный ресурс.

🟢

Во второй части разберем техники для долгих задач

: компакцию, агентскую память и мульти-агентские архитектуры

🔗 Рекомендую почитать: оригинальный пост Anthropic Effective context engineering for AI agents

#AI #LLM #Agents #ContextEngineering #TechStrategy

Интересно 👀

Фактически это шаг к унификации экосистемы MCP / ToolCalling / Eval – теперь агентские сценарии можно строить как обычные low-code-флоу внутри ChatGPT.

И да, не только пользователи ComfyUI могут радоваться – навыки LangFlow, Flowise, n8n теперь тоже на вес золота 😁

🟢Low-code + AI постепенно становится новым стандартом для сборки ассистентов и внутренних агентов.

Запись OpenAI Dev Day

🦆Собираю команду!

Недавно я присоединился к Альфе. Мы строим AlfaGen – core-AI-платформу, связывающую модели, данные, инфру и корпоративные сервисы в единую систему

Все, что показывают на конференциях – у нас в проде:
agentic AI, RAG, context engineering, guardrails, безопасность, интеграции.

Сейчас усиливаю команду продукта – среды, где пользователи могут проектировать и запускать AI-агентов, LLM-сценарии и пайплайны. Agent Builder из прошлого поста – привет :)

Ищу:

➡️Senior System Analyst – проектировать интеграции и потоки данных, собирать архитектуру под AI-сценарии, видеть систему целиком

➡️Senior Python Developer – строить инфраструктуру для AI, интегрировать LLM в банк, решать задачи на стыке классического backend и AI

Почему это крутая возможность:

➡️Cutting-edge стек
➡️Задачи, которые еще нигде не решали
➡️Сразу в прод, сразу в масштабе
➡️Реальный impact на тысячи пользователей

Если вы читали мои посты и думали "

хочу так же

" – вот шанс

😎

Пишите в личку, расскажу все детали: @dmrtnv

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒

#AI #Hiring #AgenticAI #LLM

🌩️ Когда DNS решил сыграть в самоуправление: как упал регион AWS us-east-1

Сегодня немного отойдем от любимых тем про AI и поговорим про инфраструктуру – ту самую, без которой не запустится ни один наш агент, RAG или пайплайн 😎
Потому что когда падает облако, на котором хостится большая часть мировых сервисов – это не просто новость – это напоминание, на чем держится цифровая цивилизация.

➡️В ночь с 19 на 20 октября 2025 года сбой в Amazon DynamoDB обрушил целый регион N. Virginia (us-east-1) – ключевой узел инфраструктуры AWS.
В течение 15 часов крупнейшие сервисы, от Reddit до Perplexity, работали с перебоями.

▶️ С чего все началось
DynamoDB – не просто база, а сердце внутренней экосистемы AWS.
Через нее проходят миллиарды запросов, и множество сервисов (EC2, Lambda, Redshift, IAM) опираются на нее как на системный реестр.
Чтобы все это держалось, у DynamoDB есть своя автоматика управления DNS. Она поддерживает сотни тысяч записей для IPv4, IPv6, FIPS-эндпоинтов, аккаунтов, подсетей.

Эта автоматика состоит из двух компонентов:

DNS Planner

– планирует и формирует «карты DNS», распределяя балансировщики и веса.

DNS Enactor

– применяет эти планы в Route 53 и делает это параллельно, из трех зон доступности.

Звучит надежно: три независимых процесса, каждая зона применяет свой план транзакционно.
Но вот ключевая деталь, между ними не было центральной синхронизации времени и версий ❗️

▶️ Race condition
Ночью один Enactor залип, из-за случайных сетевых задержек он застрял, применяя план.
Пока он думал, Planner успел нагенерить несколько новых версий, а другой Enactor быстро их применил.
Все шло по плану, пока не сработала финальная часть – очистка старых DNS-планов.

Быстрый Enactor удалил старые версии, включая ту, что все еще «применял» медленный.
И вот этот медленный проснулся и, ничего не подозревая, внес свой старый план, фактически пустой DNS для регионального эндпоинта.
– Система осталась без IP-адресов.
– DynamoDB перестала существовать для всего, кто к ней обращался.

▶️ Цепная реакция
EC2 перестал запускать новые инстансы: менеджеры физических серверов (Droplet Workflow Manager) потеряли связь с метаданными в DynamoDB, из-за чего очередь задач быстро вышла из-под контроля – миллионы ошибок “insufficient capacity”.
Network Load Balancer (NLB) повел себя нестабильно: новые EC2-инстансы создавались, но не получали сетевую конфигурацию, а подсистема health-check считала их недоступными.
Балансировщики поочередно исключали и возвращали узлы в DNS, что вызвало массовый флап и деградацию сервисов.
Lambda, ECS и EKS пострадали по той же причине: функции не создавались, контейнеры не поднимались, очереди SQS/Kinesis застревали.

IAM и Console Login на время перестали работать.

Инженеры AWS просто не могли авторизоваться, чтобы чинить все остальное.
Да, система отказоустойчивая… но не от самой себя.

🕒 Как чинили
К утру инженеры вручную восстановили DNS-записи.
DynamoDB вернулась в онлайн к 2:25 AM, но EC2 и NLB продолжали задыхаться еще несколько часов, пока не почистили бэклоги и не пересоздали сломанные сессии.

Полная стабилизация только к 1:50 PM 20 октября.

15 часов на восстановление региона, который питает сотни тысяч продакшн-систем.

🔍 Что AWS меняет
Amazon уже пообещали:

➡️переписать DNS Planner/Enactor, чтобы исключить race condition-сценарий
➡️добавить velocity control в NLB – ограничивать, сколько узлов можно погасить за раз при флапе
➡️улучшить стресс-тестирование EC2 Droplet Manager, чтобы он не падал при массовом восстановлении
➡️доработать троттлинг и graceful degradation механизмы для высоких нагрузок

Даже у гигантов уязвимость лежит в слое координации

🟢

Это не просто инцидент – это зеркало эпохи «инфраструктуры, которая управляет собой».

🟢

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

пока автоматика не умеет сомневаться в себе –

нам все равно нужен человек, который умеет

выдергивать шнур и чинить вручную

😉

🔗 Детальный постмортем-разбор можно посмотреть здесь

#AWS #DynamoDB #Cloud #TechStory

Когда AI решил поработать без человека: что скрывается внутри отчета Anthropic

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

➡️Суть в том, что исследователи нашли архитектуру, которая превращает AI не в ассистента, а в автономный модуль, выполняющий 80–90% атакующих действий самостоятельно – со скоростью и масштабом, с которыми один человек никогда бы не справился.
И больше всего меня впечатлило именно то, как эта атака была спроектирована внутри

➡️Архитектура
Внутри был собран полноценный autonomous cyber attack framework – система, где Claude Code выступает runtime-слоем, MCP-инструменты – манипуляторами, а оркестратор – мозгом, который режет операцию на сотни мини-шагов.
🟢Каждая задача выглядела абсолютно легитимно: “проверь конфиг”, “проанализируй API”, “проведи тест подключения”, “построй карту сети”.
🟢Модель исполняла их как обычную техническую работу – она не видела всей атаки целиком благодаря хитрой изоляции контекста.
🟢Оркестратор держал состояние кампании, управлял фазами (разведка → взлом → закрепление → вынос данных) и сшивал ответы AI в единый поток действий.
🟢AI сам: искал сервисы, находил уязвимости, разрабатывал эксплойты, тестировал доступы, двигался по внутренней сети, извлекал данные, классифицировал ценность украденного, вел документацию в markdown.

При этом люди участвовали только на 10–20%: в стратегических точках, типа «разрешить эксплуатацию», «разрешить использование новых кредов», «разрешить вынос данных».

➡️Масштаб и темп
Anthropic в отчете приводит реальные цифры:
– пик активности – тысячи запросов, устойчивые несколько операций в секунду
– в атаке одновременно участвовало несколько десятков целей
– AI вел несколько параллельных контекстов, не путая кампании
– эксплойты AI разрабатывал за 1–4 часа, проверка человеком занимала 2–10 минут
– извлечение и анализ данных – 2–6 часов полной автономии

AI не просто ломал – он сам дотягивал атаку до конца, включая: создание бэкдор-аккаунтов, построение карт привилегий, доказательство работоспособности эксплойтов, генерацию отчета и аналитики, подготовку handoff другим командам и т.п.

Это похоже на подрядчика, который ведет операцию от разведки до передачи доступа следующей группе.

➡️Вся система была собрана на обычных open-source инструментах: стандартные сканеры, фреймворки эксплуатации, утилиты паролей, браузерные MCP-инструменты, проверки конфигов, тестеры API.

То есть сила не в каком-то “супервирусе”, а в архитектуре и автоматизации: простые инструменты + AI как рантайм + оркестратор = система, которая выполняет работу целой команды.
И да – такую архитектуру сможет повторить все больше групп, просто потому что компоненты общедоступны.

🔒Что это значит для защиты
Anthropic в отчете пишут прямым текстом: автономные атаки – уже реальность, и стандартные SOC/SIEM-процессы под такой темп не успевают.

Чтобы оборона была адекватной, нужно реализовать:

1) Раннее выявление автономных цепочек
Детекторы должны ловить аномальный темп, последовательные технические шаги, работу через MCP-инструменты и нетипичное поведение модели.
2) Поведенческий анализ AI-активности
Важно отслеживать не содержание команд, а форму деятельности: повторяющиеся операции, скачки нагрузки, многозадачные контексты.
3) AI в защитном контуре
Anthropic подчеркивают: те же свойства, которые позволяют AI проводить атаки, нужны и для защиты – AI-наблюдатели, фазовая аналитика и автоматические реакции.

Иначе скорость атаки будет выше скорости реагирования.

🔗 Отчет Anthropic тут

#AI #CyberSecurity #AgenticAI #ThreatIntelligence #TechStory

❤️Новая экономика и агенты: влияние на бизнес и технологии

26 ноября обсудим, как агентные системы уже меняют бизнес-процессы и почему в 2025–2026+ это станет нормой, а не экспериментом.

О чем митап:

➡️какие агентные сценарии у крупных компаний реально живут, а какие закрыли и почему
➡️из чего сейчас состоит рабочий стек под агентов
➡️как считают экономику: стоимость шага, стабильность, эффект
➡️куда все движется дальше и какие подходы выдерживают прод-нагрузку

Будут крутые спикеры из red_mad_robot, Yandex Cloud, Wildberries & Russ.

📅 26 ноября, 16:30–18:30
🌐 Онлайн

Если хотите лучше понять «как это работает на самом деле» – подключайтесь. Будет полезно 😉

#AI #AgenticAI #AlfaGen

🖥 Как AI меняет работу инженера: кейс Anthropic

Мы часто обсуждаем экономику AI в целом. Но Anthropic пошли другим путем – они изучили, как их собственные инженеры на самом деле используют AI в повседневных задачах.
132 опрошенных, 53 глубинных интервью, логи Claude Code – отличный срез того, как меняется инженерная профессия, когда мощная модель встроена в каждый рабочий день.

По сути, это предпросмотр того, как будет выглядеть индустрия в ближайшие годы.

TL;DR

➡️За год использование Claude выросло с 28% до 60% рабочего времени – двухкратный рост
➡️27% работы с Claude – задачи, которые вообще не делались бы без AI
➡️Инженеры расширяют зону компетенций за пределы привычных ролей; при этом часть команды отмечает риск потери глубины – парадокс компетенций обостряется
➡️Роль смещается к управлению AI-агентами, но «полностью делегировать» можно лишь 0-20% работы
➡️Командные паттерны меняются: меньше вопросов коллегам, меньше менторства

🔴Что происходит с работой
Claude теперь участвует почти во всех задачах: дебаг, разбор чужого кода, черновики фич, тесты, документация и те самые пэйперкаты, которые годами лежали в бэклоге.
Любопытно, что часть задач просто не существовала бы без AI. Около четверти – это nice-to-have фичи и исследовательские штуки, которые раньше не окупали время инженера.

🔴Переход от I-shape к T-shape ролям
AI снижает барьеры входа в смежные области. Бэкендеры пилят UI, ресерчеры собирают дашборды, безопасники быстро погружаюстя в новые сервисы. Страх «это серая зона» заменяется быстрым диалогом с моделью. В результате каждый ощущает себя чуть более full-stack, а цикл идея → прототип → проверка значительно сокращается.

🔴Что происходит с глубиной инженерных навыков
У части инженеров появляется ощущение потери глубины знаний – и это становится обсуждаемым риском Когда черновик кода делает модель, меньше поводов руками проходить дебаг, читать доку, разбираться в архитектуре.
Возникает парадокс: чтобы эффективно и безопасно использовать AI, нужны как раз те самые глубокие навыки, которые он частично вытесняет. Поэтому ключевой вопрос – как развиваться так, чтобы сохранять способность и писать качественный код, ревьюить его, и удерживать архитектурный контекст, не превращаясь в пассивного оператора модели.

🔴Меняется командная динамика
Раньше первый шаг был: «спрошу коллегу». Сейчас: «спрошу Claude».
Плюс: вопросы стало проще задавать, исчезает ощущение, что отвлекаешь людей по пустякам.
Минус: спонтанного менторства становится меньше, особенно для джунов. Скорость растет, но привычные способы учиться друг у друга требуют переосмысления.

🔴Сдвиг роли: от кода к оркестрации
Многие инженеры описывают свою работу как управление несколькими инстансами Claude и проверку результата.
Меньше классического кодинга – больше постановок задач, выбора подходов, проверки и принятия решений.
Большинство могут «полностью делегировать» только 0-20% своей работы Claude. То есть модель используется в 60% времени, но почти всегда требует контроля, особенно в критичных задачах. Claude помогает работать быстрее и масштабнее, оставаясь под присмотром человека. Однако чем выше темп развития моделей, тем заметнее становится вопрос: какой будет инженерная роль через несколько лет?

🟢Anthropic – компания с ранним доступом к самым мощным моделям и высокой культурой экспериментов. Поэтому их опыт – это показательный ориентир.
Если убрать названия, останется простая мысль: AI уже перестраивает профессию инженера. Не когда-нибудь – сейчас. Меняются навыки, привычки, способы сотрудничества, ожидания от себя.

🔗 Почитать подробнее можно тут

#Anthropic #AIEngineering #AIProductivity