mrtnv | prism

🤖 From Prompts to Context: почему это важно для AI-агентов Несколько лет мы фокусировались на идеальных промптах – подбирали правильные слова и формулировки. Но сейчас фокус сместился: важнее не конструкция промпта, а набор контекста, который даст модели нужное поведение. Разберем, как эффективно управлять контекстом и почему это ключ к надежным агентам 🙂 Кстати, еще в июле я упоминал Context Engineering как один из ключевых трендов 2025 – и вот сейчас самое время разобрать его подробнее. TL;DR ➡️Контекст-инжиниринг – это эволюция промпт-инжиниринга: управление всем набором токенов (инструкции, инструменты, история, данные), а не только текстом промпта ➡️У LLM есть "бюджет внимания" – чем больше токенов, тем хуже модель извлекает информацию (context rot). Контекст = конечный ресурс ➡️Эффективный контекст – это минимальный набор токенов с высокой информационной ценностью. Системные промпты должны быть на оптимальном кровне абстракции ➡️ Агентский поиск: вместо загрузки всех данных заранее, агенты используют "just-in-time" стратегию – динамическая загрузка через инструменты Почему контекст-инжиниринг критичен Раньше промпт-инжиниринг работал для one-shot задач – классификация, генерация текста. Но современные агенты работают в циклах, на длинных горизонтах, накапливая все больше данных. И тут появляется проблема: context rot – чем больше токенов в окне контекста, тем хуже модель достает нужную информацию. Исследования и здравый смыслпоказывают: модели теряют точность при росте контекста (некоторые деградируют плавнее). Причина – в архитектуре трансформеров: каждый токен "смотрит" на все остальные, создавая n² связей. Чем больше n, тем меньше внимания приходится на каждый отдельный токен. Плюс модели обучались на коротких последовательностях – у них меньше опыта с длинным контекстом. Анатомия эффективного контекста Задача: найти минимальный набор токенов с высокой информативностью, который максимизирует вероятность нужного результата. 1️⃣Системные промпты: "оптим

Интересно 👀 Фактически это шаг к унификации экосистемы 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 перестала существовать для всего, кто к ней

LLM-кэширование без Exact Match: архитектура семантического кэша В традиционных детерминированных системах кэширование по ключу – это просто: key=user_123. Совпало байт-в-байт, отдали. В мире LLM Exact Match практически бесполезен. Его Hit Rate обычно очень низкий (часто единицы процентов). Пользователи креативны: «Как сменить пин-код?», «Хочу поменять пароль от карты», «Забыл пин, что делать?». Для обычного кэша это три разных ключа. Вы трижды платите за генерацию и трижды заставляете юзера ждать. Хотя интент один. Решение – Semantic Caching. Кэшируем не текст, а вектор намерения. TL;DR ➡️Семантический кэш сравнивает векторы (embeddings) запросов. ➡️Если сходство выше порога, то отдаем сохраненный ответ. ➡️Latency: падает с секунд до десятков миллисекунд. ➡️Cost: в сценариях типа FAQ/Helpdesk можно срезать косты на 30–50% (зависит от домена). ➡️Риск: устаревание (Data Staleness) требует обязательной инвалидации по версии промпта/модели. ▶️ Как это работает под капотом: вместо текста ключом становится вектор. 🔵Прогоняем запрос через легкую модель, например text-embedding-3-small. 🔵Ищем семантически похожие запросы в векторной базе (Redis VSS, Qdrant). 🔵Если нашли запись с similarity > 0.98+ (в критичных доменах, порог подбирается строго на валидации), отдаем кэш. Мы меняем дорогую генерацию на дешевый поиск (Retrieval). ▶️ Экономика наглядно: 🔵Без кэша: Входящий запрос + Генерация GPT-4o ≈ $0.005 + 2–3 секунды. 🔵С кэшем: Эмбеддинг (копейки) + Поиск в Redis ≈ $0.00001 + 50–100 мс. 🔴Ловушка №1: Контекст и PII Семантический кэш – это прямминное поле. Если один пользователь спросил «Какой у меня баланс?», а вы это закэшировали… следующий увидит чужие деньги. Решение: – Не кэшировать запросы с PII (перед записью нужен PII-фильтр/классификатор). – Сегментировать кэш: ключ должен включать Vector + Tenant_ID + User_ID (или Session_ID). Ответы для разных клиентов, каналов и ролей должны храниться изолированно. 🔴Ловушка №2: Уставревание (Staleness) Кэш мо

⚡️ NVLink и InfiniBand: Нервная система AI-кластера Мы привыкли оценивать мощность AI в флопсах. Но когда вы строите кластер для обучения LLM (будь то 8 карт в сервере или 1000 карт в стойках), узким местом становится не вычисление, а коммуникация. Если H100 ждет данные, вы сжигаете бюджет впустую. Чтобы масштабировать обучение, индустрия построила поверх стандартного x86 отдельную высокоскоростную фабрику. TL;DR ➡️Обучение требует постоянной синхронизации градиентов. Классический стек (TCP/IP + PCIe) слишком медленный и вносит джиттер. ➡️NVLink (Intra-node): снимает ограничения PCIe внутри узла. Превращает 8 GPU в единый fabric с пропускной способностью 900 ГБ/с. ➡️InfiniBand / RoCE: использует GPUDirect RDMA, чтобы писать данные из памяти одной GPU в память другой, минуя CPU и ОС (в data path). ➡️Программный клей: библиотека NCCL использует эти каналы для эффективных коллективных операций. ✈️Уровень 1: NVLink (внутри сервера) В стандартной архитектуре GPU общаются через PCIe. Даже Gen5 x16 дает лишь ~64 ГБ/с (на направление). Этого мало для современных топологий Model Parallelism. NVLink 4-го поколения до 900 ГБ/с (агрегированно, в обе стороны) на GPU. – Роль NVSwitch: внутри серверов (типа HGX H100) коммутатор NVSwitch позволяет каждой карте обращаться к HBM-памяти соседа с небольшой и предсказуемой задержкой. – Результат: это еще не физически общая память, но доступ к remote-HBM становится настолько быстрым, что для алгоритмов распределения узел выглядит как единое вычислительное поле. ✈️Уровень 2: InfiniBand и RDMA (между серверами) Когда нужно соединить стойки, обычный TCP/IP становится проблемой из-за накладных расходов ядра ОС и непредсказуемых задержек (джиттера). Решение – RDMA (Remote Direct Memory Access). Самый популярный стандарт здесь InfiniBand (например, NDR 400 Gb/s), хотя в дата-центрах используют и RoCE (RDMA over Converged Ethernet). – GPUDirect RDMA: это «киллер-фича». Сетевая карта (NIC) пересылает данные напрямую из памяти GPU в сеть

💻 OpenAI запустили Prism. Название отличное, осталось проверить, как это работает в полевых условиях ➡️Давайте честно: написание научной работы – это обычно хаос из открытых вкладок, борьбы с оформлением и бесконечных правок от соавторов. В OpenAI решили упростить этот процесс и представили Prism. Если коротко: это рабочее пространство для учёных и исследователей на базе GPT-5.2. ↗️Минутку, а что такое LaTeX и зачем он нужен? Если вы не из мира науки, слово «Латекс» может вызвать не те ассоциации. На самом деле: LaTeX – это стандарт оформления научных текстов. В отличие от обычного Word, где вы просто печатаете текст, в LaTeX вы используете специальные команды (похоже на код), чтобы формулы, графики и таблицы выглядели идеально. Это супер-удобно, но сложно: обычно ученым приходится устанавливать дополнительный софт и мучиться с настройкой. Prism должен сделать LaTeX чуть более «человечным»: вы просто пишете, а AI и облачная платформа берут всю техническую головную боль на себя. ↗️Что умеет Prism? – Cloud-native LaTeX-среда Не нужно разворачивать локальные дистрибутивы (привет, TeX Live) и мучиться с конфигурацией компиляторов и шрифтов. Весь рендеринг и управление зависимостями уходят в облако. – Контекст через GPT-5.2 Фишка в том, что модель видит всю работу целиком. Это помогает следить за логикой: чтобы переменные в формулах на 2-й и 20-й страницах не противоречили друг другу.. – Работа с источниками Встроенный менеджер ссылок. По идее, должен избавить от ручного вбивания библиографии, что всегда было самой нудной частью. – Коллаборация По сути, это Google Docs, но адаптированный под формулы и сложную верстку. Больше не нужно париться с версиями. ↗️Почему это круто? Обычно научный процесс – это «зоопарк» из инструментов: расчеты в одном месте, черновик в другом, верстка в третьем. Prism пытается собрать этот стек в одном окне. По аналогии с тем, как в 2025-м AI-ассистенты только начали менять подход к разработке ПО, здесь мы видим попытку оптимизировать ру

💳 Немного апдейтов по команде и вакансиям Помните мой пост про сбор команды в Альфу? С того момента мы не просто продвинулись – мы знатно замасштабировались. Платформа обрастает новыми фичами, пользователями и кейсами быстрее, чем мы успеваем обновлять роадмап. Поэтому мы снова усиливаемся! Кого ищем: ➡️Senior Python Developer (Core/Backend) – проектирование «движка» платформы. В планах: высоконагруженная оркестрация, работа со стабильностью LLM-пайплайнов и создание гибкой инфраструктуры под агентские сценарии. ➡️Senior Frontend Developer (React/Flow-based UI) – развитие сложного визуального конструктора. Нужно проектировать flow-интерфейсы (ноды, связи, визуализация графов), делая лучший UX для тех, кто создает AI-решения. ➡️Senior System Analyst – мозг, который свяжет AI-сценарии и ограничения банковской инфры в четкую архитектуру. Нужно понимать, как реально ходят данные в RAG и как вписать агентов в огромный ИТ-ландшафт. Команда сильная, и мы ищем тех, кто готов поднять планку еще выше. У нас нет жестких рамок в выборе подходов: мы сами проектируем среду, в которой нам профессионально интересно развивать AI-технологии. Это про ответственность за результат, современный стек и возможность создать по-настоящему значимую инженерную систему ➡️Подробности в личке: @dmrtnv. Присоединяйтесь! За репост или рекомендацию в личку – лучи добра и +10 к карме. Давайте поможем крутым инженерам и крутому продукту встретиться 🥰 #AI #AlfaGen #Hiring #Python #Frontend #SystemAnalyst #MCP

🤔 Observability в агентных системах: масштабирование начинается с трейсов В агентных системах инцидент (нестабильность поведения) – это не дефект кода, а штатная характеристика среды. ➡️Когда логика исполнения выносится в runtime, вопрос «почему это упало?» становится критическим. ➡️Observability (наблюдаемость) здесь перестает быть приятным дополнением – это базовое условие выживания, отделяющее управляемый продукт от непредсказуемого хаоса. ▶️ Проблема causal chain: почему агенты стохастичны LLM – это системы с высоким уровнем энтропии. В агентной обвязке их риски (hallucinations, context drift) усиливаются за счет вероятностного наслоения: – Архитектурная сложность: tool calling, итеративное планирование и кросс-агентные зависимости перемножают неопределенность модели на нестабильность среды. – Инфраструктурный хаос: таймауты внешних API, сайд-эффекты инструментов и изменяемый стейт делают систему невозможной для детерминированного описания. Спроектировать такую конструкцию «без сбоев» нельзя. Критический провал здесь не ошибка как таковая, а отсутствие прозрачного causal chain: возможности мгновенно восстановить цепочку причинно-следственных связей и понять, где именно «поплыла» логика. ▶️ Почему код больше не источник правды В классическом софте все линейно: код → поведение, стек-трейс → конкретная причина. В агентных системах эта связка рвется. Код лишь задает границы маневра, а реальное поведение рождается в runtime – через взаимодействие модели с контекстом и инструментами. Теперь источник правды не main.py, а динамическая история исполнения: входные данные, шаги рассуждений (CoT), вызовы инструментов и мутации стейта. ▶️ Из чего состоит observability агентов (LLMOps stack) – Distributed Tracing (obs-фундамент): каждый запуск упаковывается в trace_id. Мы используем стандарты вроде OpenTelemetry или готовые решения (LangFuse, LangSmith, Arize Phoenix), чтобы превратить блэк бокс в прозрачную иерархию вызовов. – Глубокое логирование инструментов: I/O и

🍎 WebKit → dyld: анатомия системной exploit-chain ➡️Apple выпустила экстренное обновление для закрытия CVE-2026-20700. Это первый критический zero-day года, затрагивающий dyld (Dynamic Link Editor). ➡️Разбираем, почему это технически изящно и крайне опасно для тех, кто работает с чувствительными данными. ⚙️ dyld: точка, где начинается выполнение кода dyld – это динамический компоновщик. В иерархии macOS и iOS он стоит у основания: когда вы запускаете любое приложение, первым просыпается именно он. Его задача – собрать исполняемый файл и системные библиотеки (.dylib) в единое целое в памяти. В чем критичность? dyld обладает огромными привилегиями. Ошибка управления памятью (memory corruption) здесь позволяет атакующему подменить адреса. Система вместо доверенной библиотеки Apple подгружает вредоносный код. Это происходит до того, как сработают основные уровни защиты. ➡️Как это эксплуатируется: логика цепочки Злоумышленники не используют этот баг сам по себе. Это финальный аккорд в сложной цепочке (Exploit Chain): – Entry Point: через уязвимости в WebKit (декабрьские CVE-2025-14174 и 43529). Пользователю достаточно просто зайти на подготовленную страницу. Браузер спотыкается, позволяя атакующему записать данные в ограниченную область памяти. – Escalation: обычного доступа браузера атакующему мало – он заперт внутри процесса Safari. Чтобы получить доступ к сообщениям, камере или паролям, нужно выпрыгнуть в систему. – The dyld Flip: здесь вступает новый zero-day. Атакующий через поврежденную память заставляет dyld при запуске любого системного процесса подгрузить не родную библиотеку Apple, а вредоносный код. – Full Control: поскольку dyld доверяет загружаемым модулям, вредоносный код исполняется в контексте более привилегированного процесса. ➡️При чем здесь ИИ? ИИ все чаще используется в исследовании уязвимостей. – Автоматизация поиска: AI-агенты и LLM помогают находить аномалии в бинарном коде и нетривиальные паттерны управления памятью быстрее, чем при пол

Replication vs Partitioning vs Sharding: три разных ответа на рост данных Сегодня чуть отойдем от AI, хотя для AI/LLM-систем это тоже основа. Меня часто спрашивают про базы данных, и здесь часто возникает путаница: репликация, партиционирование и шардирование – это не одно и то же «масштабирование базы», а три разных подхода под три разных узких места системы. TL;DR ➡️Replication (Репликация) – копируем одни и те же данные на несколько узлов. Нужно для доступности, отказоустойчивости и масштабирования чтений. ➡️Partitioning (Партиционирование) – делим большую таблицу на части внутри одного сервера. Нужно для ускорения запросов, управления хранением данных и обслуживания. ➡️Sharding (Шардирование) – делим данные и распределяем по разным серверам. Нужно для горизонтального масштабирования, когда один узел уже физически не справляется. Важно понимать, что эти подходы не взаимоисключающие. В реальных системах данные часто партиционируются, шардируются по узлам, а каждый шард еще и реплицируется. 1️⃣ Replication: копии ради доступности Репликация – это один и тот же набор данных в нескольких экземплярах. Обычно есть основной узел (primary), куда идет запись, и реплики, которые получают эти изменения. Что дает: 🟢устойчивость к сбоям 🟢бóльшую пропускную способность на чтение 🟢возможность быстрого переключения (failover) Что важно под капотом: появляется лаг репликации, т.е. запись уже есть на primary, но реплика может еще отдавать старое состояние; failover – это не магия, а выбор нового мастера, риск проблемы split-brain и операционная сложность. Репликация отлично подходит для нагрузок на чтение и обеспечения отказоустойчивости. Но она не масштабирует бесконечно запись и не убирает физические лимиты одного узла по диску, CPU или памяти. 2️⃣ Партиционирование: логически делим большую таблицу на части по правилу Партиционирование – это когда таблица делится на секции (партиции) по правилу: диапазону, хэшу, списку или дате. Например: логи по месяцам, транзакции по д

SreGPT: как Яндекс научил AI-агентов тушить инциденты в проде Вчера был на AI Dev Day – кейсов было много хороших, но рассказать решил про этот, потому что тема важная и для многих SRE-команд пока неочевидная. Ребята из Яндекса показали SreGPT – AI Copilot для команд надежности. Не очередной чат-бот поверх документации, а ансамбль специализированных AI-агентов под управлением центрального оркестратора. Контекст: Яндекс Go, около 1000 микросервисов. ➡️Какую проблему решают 1️⃣Снижение MTTR / MTTRC – время до восстановления и до нахождения root cause. Каждая минута инцидента – это деньги, репутация и нервы. 2️⃣Дефицит квалифицированных кадров – людей с нужной экспертизой не хватает, а инцидент не будет ждать, пока вы наймете и онбордите сеньора. AI-агент восполняет этот разрыв, давая дежурному контекст и подсказки, которые раньше были только в голове у конкретного человека. 3️⃣Повышение аптайма до 99,99, сокращение налога на дежурство и высвобождение времени команды на проактивную работу вместо тушения пожаров. ➡️Что умеет SreGPT Каждый агент отвечает за свой блок процесса, оркестратор координирует их по фазам Горячая фаза (инцидент прямо сейчас): – автозаполнение карточки инцидента – агент собирает контекст из алертов, логов и метрик, пока дежурный еще читает первый алерт – автостатусы – система сама генерирует апдейты для стейкхолдеров, дежурный не отвлекается на "написать в канал что происходит" – поиск похожих инцидентов – моментальный поиск по истории: было ли такое, что помогло, какой был root cause – призыв релевантных людей – агент анализирует тип инцидента, затронутые сервисы и историю, и зовет тех, кто реально нужен Холодная фаза: – root cause analysis – таймлайн, корреляция событий, гипотезы по первопричине – подготовка постмортема с ключевыми точками и рекомендациями ➡️Что нужно, чтобы такое построить SreGPT – это не модель, которую можно просто подключить. Это верхушка айсберга, а под ней - необходимые условия, без которых ничего не взлетит – Инфра

Rules, Skills, Modes: как команды перестают изобретать промпты Тема, которая за последние полгода из нишевой стала обязательной: как организовать работу команды с AI-инструментами разработки так, чтобы знания можно было масштабировать на всю команду. Проблема знакомая: в команде из 10 разработчиков каждый настраивает AI под себя. Один нашел рабочий промпт для код-ревью, другой – для генерации тестов, третий – для миграций. Классический tribal knowledge, только теперь не про код, а про то, как правильно взаимодействовать с AI. ➡️ Что уже есть: три слоя кастомизации 1️⃣ Rules – статичные инструкции, которые AI читает перед каждым ответом. Cursor (.cursor/rules/), Claude Code (CLAUDE. md), Windsurf (.windsurf/rules/) – у всех свой формат, но идея одна: положи файл в репозиторий, закоммить, и вся команда получает одинаковое поведение AI. Это как .eslintrc, только для AI-ассистента. Один настроил – все используют. 2️⃣ Skills – переиспользуемые рабочие процессы. Не просто «веди себя так», а полноценные инструкции с шаблонами, скриптами и примерами. Папка со скиллами, которую AI загружает когда задача подходит. Команда может собрать библиотеку: deploy, review-pr, setup-dev, create-feature – и новый разработчик в первый день работает по тем же стандартам, что и сеньор. В декабре 2025 Anthropic вывела формат Skills в открытый стандарт (agentskills.io), и его подхватили ключевые игроки: GitHub Copilot, OpenAI Codex, Gemini CLI, Cursor. Тут идея reusable workflow. Написал скилл один раз – перенес без изменения. Простая аналогия: MCP дает агенту доступ к внешним инструментам и данным. Skills учат агента, что с этими инструментами делать. Уже появились каталоги – можно устанавливать одной командой, можно публиковать свои. 3️⃣ Modes и Subagents – управление автономностью и специализацией. Modes = сколько агенту разрешено. Например, в Claude Code это permission modes (plan-only / auto-accept edits). Subagents = кому делегирована подзадача. Отдельный агент со своим контексто

Самая сложная машина в мире: как обманули физику, чтобы у нас был современный AI Мы здесь часто обсуждаем архитектуру AI-агентов, RAG, MCP, графы и тп. Но все это было бы невозможно без физического фундамента. Посмотрел отличный разбор от Veritasium про ASML – единственную компанию в мире, которая продает установки экстремальной ультрафиолетовой литографии (EUV). TL;DR ➡️Когда старые методы производства чипов начали упираться в физические пределы, эта голландская компания создала устройство нового поколения (High NA) за $400 млн, состоящее из сотен тысяч деталей. Это один из самых сложных коммерческих продуктов за всю историю человечества, который спас закон Мура. ➡️ Как это работает (без сложной физики, но с инженерной магией) 1️⃣ Искусственное солнце в коробке (или 50 000 RPS расплавленным оловом). Чтобы печатать микроскопические транзисторы, нужен свет с экстремально короткой длиной волны (13,5 нм). Как его получить? Машина выстреливает крошечными каплями расплавленного олова. По каждой капле прямо в полете бьют лазером трижды: первый импульс расплющивает каплю в плоский «блинчик», второй снижает ее плотность, а третий, сверхмощный, превращает ее в плазму, которая почти в 40 раз горячее поверхности Солнца. И так 50 000 раз в секунду. Представьте себе систему, которая должна без единого промаха держать такой физический RPS. 2️⃣ Самые гладкие объекты во Вселенной. Этот EUV-свет поглощается абсолютно всем – даже воздухом. Поэтому внутри машины строгий вакуум, а свет фокусируют не линзами, а системой специальных многослойных зеркал. Они отполированы настолько идеально, что если бы самое большое зеркало в системе было размером с Землю, максимальная неровность на нем была бы не толще игральной карты. 3️⃣ Водородное торнадо (Garbage Collection на максималках). Когда вы взрываете олово 50 000 раз в секунду, во все стороны летят микрочастицы, которые могут моментально уничтожить те самые идеальные зеркала. Как решили проблему? Внутри камеры создали направленный пото

Reverse Proxy vs API Gateway vs Load Balancer: три стража, которых все путают Отвлечемся от сложных концепций и вернемся к железобетонному фундаменту. Все три компонента стоят перед вашими сервисами. Все три принимают входящий трафик. Кажется, что разница между ними очевидна, но на практике их регулярно смешивают в кучу даже опытные инженеры. Разберем, кто есть кто :) TL;DR ➡️Reverse Proxy – прячет инфраструктуру и оптимизирует доставку ➡️Load Balancer – распределяет трафик, чтобы ничего не упало ➡️API Gateway – управляет доступом и бизнес-логикой API Важно понимать, что в серьезных системах эти подходы не взаимоисключающие. Они работают слоями. 1️⃣ Reverse Proxy: телохранитель бэкенда Принимает запросы от клиентов и пробрасывает их на внутренние серверы. Клиент общается с одним адресом и понятия не имеет, что за ним живут десятки сервисов. Что дает: – полную изоляцию внутренней инфраструктуры от внешнего мира – берет на себя тяжелую работу: TLS-терминацию, сжатие и кеширование Примеры: NGINX, Envoy, Apache HTTP Server 2️⃣ Load Balancer: диспетчер нагрузки Задача максимально конкретная: распределить входящий трафик между несколькими инстансами, чтобы ни один не захлебнулся. Это про доступность. Что дает: – горизонтальное масштабирование – отказоустойчивость (мониторит health check серверов и отключает упавшие ноды) – умную маршрутизацию по алгоритмам (round-robin, least connections, weighted) Примеры: HAProxy, AWS ALB, Azure Load Balancer 3️⃣ API Gateway: единый вход в ваш API Здесь начинается бизнес-логика маршрутизации. Это не просто труба для трафика, а полноценный контроллер доступа. Что дает: – единую точку входа (аутентификация, авторизация, rate limiting) – трансформацию запросов на лету – агрегацию (может собрать ответы от нескольких микросервисов в один) Примеры: AWS API Gateway, Kong, Apigee 🔥 Где чаще всего ошибаются Проблема в том, что современные инструменты стирают границы. NGINX умеет балансировать. Kong работает и как gateway, и как прокс

AI Agent vs Agentic AI: и почему это вопрос про архитектурные паттерны, а не про маркетинг Сейчас каждый второй продукт объявляет себя «agentic». Но за одним и тем же словом скрываются совершенно разные архитектуры – от одного tool call до многоагентной системы с памятью и саморефлексией. Разница не в наличии LLM, а в паттерне исполнения. TL;DR ➡️AI Agent автономно решает локальную задачу через инструменты («найди отчет, вытащи цифры, посчитай метрику») ➡️Agentic System планирует, исполняет, проверяет себя и адаптируется под цель ➡️Ключевая разница не в LLM, а в паттерне взаимодействия внутри системы 1️⃣ Паттерны исполнения, которые реально работают – ReAct (Think → Act → Check → Repeat). Классика. Агент рассуждает, дергает инструмент, смотрит результат, решает следующий шаг. База для большинства single-agent сценариев. – Plan & Execute. Сначала планировщик строит полный план, потом исполнитель идет по шагам. Лучше ReAct на длинных задачах — меньше дрейфует контекст. – Hierarchical (супервизор + сабагенты). Супервизор раздает подзадачи специализированным агентам. Нужен, когда задача распадается на независимые куски (research → analysis → writing). – Author-Critic. Один агент делает, другой критикует и возвращает на доработку. Резко повышает качество на креативных задачах и коде. – Reflection Loop. Агент сам проверяет свой вывод и исправляет ошибки до того, как отдать результат. Самый дешевый способ поднять accuracy без смены модели. 2️⃣ Уровни зрелости (фреймворк для честной самооценки) – L0: прямой вызов модели (prompt-response без инструментов) – L1: ассистирует пошагово (copilot-режим) – L2: выполняет небольшие задачи сам через tool use – L3: несколько агентов кооперируются – L4: самокоррекция через память – L5: полная автономия и self-improving Большинство агентных продуктов на рынке – L1–L2. L3+ встречается редко и стоит дорого в эксплуатации. 3️⃣ Что выбирать под задачу – Разовая/простая задача → function calling, базовые assistant-API, простые графы

MCP vs CLI: половина MCP-серверов написана там, где хватало shell-команды Часто вижу сравнение «MCP vs Skills», и это сравнение с ошибкой в постановке. Skills – это уровень способностей агента, инструкция «что делать». MCP – это механизм вызова, способ обратиться к внешней системе. Они на разных слоях стека и не конкурируют. Корректное сравнение на одном слое – MCP vs CLI. Оба отвечают на вопрос «как агент взаимодействует с внешним миром». TL;DR ➡️Skills – уровень workflow (что делать) ➡️MCP и CLI – механизм интеграции (как взаимодействовать с внешним миром) ➡️Skill внутри использует либо MCP, либо CLI – большинство задач закрывается CLI 1️⃣Где на самом деле проходит граница Skill – это директория с инструкциями (или Tool / Action в терминологии LangChain, CrewAI, AutoGen, нейминг плавает, суть одна). Сама по себе она ничего не делает: внутри она вызывает инструменты. – CLI как механизм: скилл запускает git, docker, psql, kubectl через shell в окружении агента. Никакой дополнительной инфры, все, что есть в PATH, доступно. – MCP как механизм: скилл вызывает MCP-инструмент с типизированными параметрами и схемой. Сервер живет отдельно – со своим рантаймом, секретами, сетью. Внутри одного Skill вы делаете архитектурный выбор: пойти через CLI или через MCP. И именно здесь чаще всего ошибаются – берут MCP по умолчанию, хотя задача чистая под CLI. 2️⃣ Когда CLI – правильный выбор – Инструмент уже есть в виде CLI и стабилен (git, docker, kubectl, terraform). Зачем оборачивать в MCP то, что 20 лет работает как CLI? – Вызовы редкие или разовые. Отдельный сервис под «раз в спринт собрать релиз» – оверкилл по стоимости владения. – Действие в контексте агента, без разделяемого состояния. Skill с scripts/run. sh, это не кандидат на MCP, это финальная архитектура. – Креды уже на уровне окружения агента (ENV, kubeconfig). MCP добавил бы второй слой управления секретами там, где первый уже работает. 3️⃣Когда MCP – правильный выбор – Несколько агентов ходят в одну систему с

Иллюзия автономности: почему в бизнес-процессах максимальный ROI приносят агенты, которые ничего за вас не решают Когда на рынке обсуждают внедрение агентов в бизнес-процессы, по умолчанию представляют автономию: поставил цель – система сама все e2e сделала. Но самый ценный кейс, который я видел за последнее время, устроен ровно наоборот. Агент там ничего не решает за человека. Он держит то, что человек не может удержать руками на каждой итерации. Сегодня опираюсь на разбор Anthropic о том, как их finance-команда работает с Claude. Кейс хорош тем, что это не демо и не лендинг, это рутина человека, который закрывает квартальный board deck. TL;DR ➡️Ценность агента в реальной работе ≠ автономность. Ценность в слое проверки, который не масштабируется руками. ➡️Один агент с reflection-петлей на живой задаче часто полезнее агентной системы. ➡️Кейс работает не из-за модели, а из-за контекста: память, коннекторы к почте/мастер-системам/доке. ➡️Это L1–L2 по шкале зрелости. И именно здесь сейчас лежит почти весь практический ROI. ↗️ Что за задача Квартальная презентация для CFO и совета директоров. Боль не в том, чтобы посчитать цифры, боль в том, что цифры обновляются до утра отправки, документ собирают несколько человек параллельно, и при каждом обновлении надо заново проверять: коммент на слайде x все еще бьется с цифрой на слайде n? Кто-то не вкинул новую метрику? Человек физически перечитывает все на каждой итерации. Это и есть та работа, которая съедает время, но не требует когнитивной нагрузки. ↗️ Что реально делает агент Не «собери мне презу». А: проверь, что каждая цифра и каждое утверждение сходятся к единому источнику правды, и прочитай нарратив глазами члена совета директоров – где он противоречит себе, где предполагает контекст, которого у читателя нет. Это в чистом виде reflection-петля. Агент не генерит результат с нуля и не действует автономно. Он берет готовый артефакт и проверяет его на консистентность – каждый раз, когда цифры поехали, а не один ра

Давно сюда ничего не писал – исправляюсь :) За последние несколько месяцев я снова успел сходить в горы, вернуться и почти сразу погрузиться в работу! Мы сильно докрутили AlfaGen Flow и сейчас строим на его базе большой AI-продукт для клиентов Альфа-Банка. Про продукт отдельно расскажу чуть позже: архитектура агентной системы, контекст, MCP, runtime, observability, ограничения LLM в проде, стоимость и все, что начинает вылезать при переходе от прототипа к большому клиентскому продукту. Думаю, материала там хватит надолго 😎 А пока расширяю команду AlfaGen Flow и ищу: ➡️ Senior Python Developer ➡️ Senior System Analyst AlfaGen Flow – платформа для разработки и исполнения AI-агентов и LLM-сценариев. Под капотом много классического бэка: distributed runtime, очереди, API, интеграции, отказоустойчивость, observability. Поверх этого – LLM, agents, MCP, RAG, память и инструменты. Задачи обычно начинаются с технической проблемы, которую сначала нужно нормально раскопать: понять ограничения существующих решений, выбрать архитектуру и довести до прода. 👉 Python Нужен сильный бэкендер: Python, архитектура, concurrency, performance, базы, очереди, API, production reliability. 👉 System Analysis Нужен SA, который сам любит разбираться, как все работает: может спроектировать контракт или интеграцию, сходить в архитектуру, руками потыкать LLM/agent stack, при необходимости навайбкодить прототип и проверить гипотезу до того, как она превратится в полноценную разработку. Если интересно – пишите напрямую @dmrtnv. Расскажу, что сейчас строим и какие задачи лежат в родмапе. Ну и репосты очень приветствуются ❤️ #Hiring #Python #SystemAnalysis #AIEngineering #AgenticAI #LLMOps