Несколько дней читаю "12‑Factor Agents" — понравился инженерный фреймворк из 12 практических пунктов, адаптированный для создания надёжных, масштабируемых и управляемых AI-агентов.

Система предлагает воспринимать LLM-агентов не как магические фреймворки, а как хорошо инженерно спроектированные сервисы с контролируемым потоком, состоянием и надёжным взаимодействием с пользователем.

Кликабельные пункты:
— How We Got Here: A Brief History of Software
— Factor 1: Natural Language to Tool Calls
— Factor 2: Own your prompts
— Factor 3: Own your context window
— Factor 4: Tools are just structured outputs
— Factor 5: Unify execution state and business state
— Factor 6: Launch/Pause/Resume with simple APIs
— Factor 7: Contact humans with tool calls
— Factor 8: Own your control flow
— Factor 9: Compact Errors into Context Window
— Factor 10: Small, Focused Agents
— Factor 11: Trigger from anywhere, meet users where they are
— Factor 12: Make your agent a stateless reducer

Как избежать кризиса архитектуры AI.
Avoiding a Future AI Architecture Crisis; What the 2025 Numbers Mean for Enterprise AI Strategy

Отличная статья про будущие риски корпоративных AI-архитектур. Интересно, что её выводы сильно совпадают с нашими — хотя мы пришли к ним своим путём. Принёс вам краткие тезисы, но рекомендую прочитать статью полностью.

Проблемы:
— Крупнейшие AI-компании не являются устойчивыми бизнесами (например, OpenAI — убытки на 50% выручки).
— Цены на AI-сервисы занижены субсидиями. Пример: Doubao от ByteDance — $0.0001 за 1k токенов (на 99.8% дешевле GPT‑4).
— Потенциальный вендор-лок: архитектура, промпты, пайплайны и данные часто «зашиваются» под конкретную модель.
— Энергопотребление — слон в комнате. Один запрос в ChatGPT ≈ 0.34 Вт*ч. Общий суточный расход — ~340 МВт*ч (как у небольшого государства).

Что делать:
— Архитектурная независимость: Проектируйте с учётом независимости от конкретной модели с самого начала. Тестируйте критичные запросы на разных провайдерах.
— Гибридный подход: используйте open-source модели локально для ключевых функций, а внешние API — для некритичных задач. Это позволяет объединить преимущества обоих подходов и одновременно управлять рисками.
— Инфраструктура контроля: встраивайте гейтвеи для мониторинга нагрузки, затрат и энергопотребления. Это станет важным параметром SLO.

Давно хотел поделиться тем, что происходит под капотом LLM Platform, которую мы строим внутри ТБанка.
Пост на грани NDA.

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

Из чего он состоит на высоком уровне:

— LLM API Gateway — единая точка доступа до внутренних (qwen?) и внешних (deepseek?) моделей,
— RAG Platform — конвейер для превращения любых данных в пайплайн Retrieval-Augmented Generation,
— Observability Platform — прозрачность всех LLM-процессов в реальном времени,
— Orchestration & automation — набор инструментов построения произвольных GenAI-пайплайнов с минимум кода,
— LLM Sec — модули безопасности, политик и аудирования,
— Assistant Runtime Platform — среда выполнения произвольных AI-ассистентов.

И если LLM Gateway — это нифига себе высоконагруженный модуль, на базе которого построены как внутренние, так и внешние продукты, то вот как конкретно построить единый Tools Registry, мы всё ещё размышляем и экспериментируем.

Если вдруг вы в Питере — приходите на нашу хардкорную конфу про архитектуру, надежность, данные и вот это все. Сезон кода 6 и 7 сентября.

Действительно ли AI повышает производительность разработчиков?
Does AI Actually Boost Developer Productivity?

Стендфорд провел эксперимент на эффективности 100к разработчиков с AI-копайлотами, результаты очень показательные:
— +15–20% к продуктивности в среднем.
— На простых или новых задачах прирост достигает 30–40%.
— На сложных и legacy-задачах эффект может быть нулевым или даже отрицательным.
— На популярных языках (Python, Java) AI помогает значительно сильнее, чем на редких.

Мой коллега, Игорь, поделился пару дней назад важной мыслью — с помощью LLM эффективные люди будут становиться еще более эффективными, а остальные будут терять конкурентоспособность еще быстрее, чем раньше. Игорь советует быть в первом лагере.

@startup_architecture

Запускаем AI-агента для разработки от Т-Технологий!

Агент заточен на работу с большими проектами. Сила таких решений в интеграции и правильном создании контекста, а не в моделях.
Context Engineering

Model-agnostic подход: не выпендриваемся и используем лучшие модели, сейчас это Qwen3-Coder

Внутри работает уже вовсю 💅

Форбс тут
Подробности тут

AI в SDLC от IT One и Сколково.

Мой коллега, Саша Поломодов разобрал недавнее исследование IT One и Сколково про внедрение AI в SDLC (Software Development Life Cycle).
Цитирую небольшой отрывок результатов с очень интересными цифрами, но советую почитать пост целиком.

Начнем в этом посте с общемировой практики
- Рынку AI-инструментов для разработки : $6,9 млрд → $29,6 млрд к 2032 (х4). Наибольший эффект на этапах разработки и тестирования. Источник Spherical Insights
- 62% разработчиков уже используют ИИ; ещё 13,8% — в планах (по данным 2024 года). Менеджеры оценивают проникновение ниже, но тренд ускоряется. Источник StackOverflow 2024 (я разбирал этот отчет 2024 года, а также разбирал и новый отчет 2025 года)
- Ценность смещается от личной эффективности (быстрее пишет код) к командной: сейчас +10% к скорости кодинга, в горизонте нескольких лет +25–30% к продуктивности команд при работе "ИИ-на-уровне-команд" (чтобы это ни значило). Источник Mia Platform
- Ускорение SDLC: уже 15–20% сейчас (источник: Forrester), потенциал 30–50% на среднесрочном горизонте (источник: medium статья от Сатиш Рама, Director Gen AI @ Paypal)
- Горизонт трансформации процессов - 1–3 года; у 32% техлидеров фактический эффект уже превзошёл ожидания (Источник: MIT, но конкретной ссылки на статью нет)

AI-хайп тихо свернул в копилотные сценарии.

Я тут готовил доклад про то, как развиваются когнитивные архитектуры. Рефлексировал над своим же выступлением «Системный дизайн будущего» полугодовой давности.

Тогда казалось, что вот-вот в проде появятся агенты, которые оркестируют межсервисные и межагентские вызовы по какому-нибудь MCP. Мир, где разработчики микросервисов становятся разработчиками «смыслов».

Случилось ли это? Скорее — нет.

Индустрия и хайп вокруг уехали в более приземлённый сценарий: ускоряем конкретный рабочий процесс, а ответственность оставляем за человеком. Хайп съехал из «AI вместо» в «AI рядом». Добро пожаловать в копилотный мир:

— McKinsey публикует отчёты о том, как компании внедряя LLM ускоряют сотрудников
— Самые громкие LLM-стартапы фокусируются на ускорении конкретных рабочих сценариев (см Cursor raises $2.3 billion funding round)
— Компании «соревнуются», сколько процентов кода написано AI (сколько у вас, кстати?)

Почему так произошло?

— Сервисы без детерминизма опасны (кто бы мог подумать?). Никто не готов отдавать бизнес-решения LLM. Поэтому human-in-the-loop выигрывает: AI подсказывает, но человек жмёт «отправить».
— Смена парадигмы «AI вместо» к «AI рядом». Продакшен с агентами слишком сложный, а тулы вокруг рабочего места сотрудника — управление и решения у человека — понятны.
— Дорого строить продакшен-инфраструктуру: GenAI требует инструментов MLOps / LLMOps, pipelines, observability, retraining и проч.
— ROI копилотов проще объяснить. «–30% времени на ответ в саппорте» понятнее CFO, чем «автономный агент оптимизирует операционную нагрузку».

Что сейчас заслуживает внимания почитать:

— Schema-Guided Reasoning — популярный топик о том, как сделать LLM более детерминированными. Путь к тем самым агентам, но контролируемым.
— Проект NANDA — ребята из MIT делают «интернет будущего» на основе общающихся агентов в распределённой архитектуре. Как IoT, только IoA (Internet of Agents).

А как у вас? Используете агентов?

Advanced Context Engineering for Conding Agents.

Тысячу раз слышал "Мы попробовали [вставь_сюда_любой_ai_инструмент], ничего хорошего не генерирует". Знакомо?

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

Один кривой TODO в середине кода может сломать всего агента: 1 ошибка приводит к 100 строчкам неправильного кода, а это ломает контекст следующей задачи и всю дальнейшую цепочку.
И потом на Reddit — куча комментариев: "я попробовал на своей кодовой базе, у меня не взлетело".

Для таких инструментов важны далеко не промпты, а управляемый контекст на каждом шаге. “Context engineering” фактически становится задачей №1 при построении надёжных агентов.

Context тут — это ограниченный ресурс, "оперативная память" агента: окно ограничено, а длинные траектории (много ходов + выводы инструментов) быстро переполняют его, что бьёт по качеству, цене и задержкам.

По мере роста контекста возникает "context rot": модели хуже извлекают нужные факты — у трансформеров бюджет внимания конечен (парные связи ~n²), значит каждый лишний токен ухудшает фокус. Отсюда требование: минимальный, но максимально полезный набор токенов. Лишняя тысяча токенов может стереть суть. Поэтому контекст нужно сжимать, резюмировать, обновлять и очищать.

Новая работа инженера, который бустит свою работу с помощью AI — это не писать идеальные промпты, а проектировать рабочее пространство модели: что она знает, что должна забыть и что именно ей показать на следующем шаге.

Попробуйте вот такой промпт для своего проекта:

Сформируй структуру проекта [описание проекта] так, чтобы она была оптимальна для работы LLM-агентов: минимум шума, чёткое разделение ролей, управляемый контекст на каждом шаге, детерминированная логика действий. Используй принципы context engineering.

Ссылки на почитать:

https://youtu.be/IS_y40zY-hc?si=sk3AXg84iC_9aBtd
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Немного бэкстейджа про канал.

Пошёл я тут на профи.ру, нашёл специалиста по продвижению канала.
Показал статистику: посты читают хорошо — 2к+ (иногда залетают на 10к), хорошо шарят (последний пост — 46 репостов).

Но подписчики почти не растут: с каждого поста приходит 5–10 человек.
При том что каждый текст занимает у меня много времени и сил — и это, мягко говоря, демотивирует.

И вот пришёл специалист и говорит: «Сложный у тебя канал, Антон».

Предложил два пути: нужно либо упрощать контент (рубрика «промпт дня»!), либо больше писать о себе.

Надеюсь, вы подписались сюда не ради лёгкого контента.
Выбираю второй вариант.
Ну и если хотите поддержать — буду благодарен за репост ссылки на канал. Это правда помогает. https://news.1rj.ru/str/startup_architecture

C-Connect от Яндекса.

Сходил на CTO/CPO Connect — камерный эвент от Яндекса для C-level руководителей.
Главная тема — AI.

Было несколько действительно интересных рассказов.

— Physical AI (роверы, грузовики, роботакси). Интересно было посмотреть на архитектуру AI-решений из реального мира. Любопытно, что там под капотом чаще используются такие же трансформеры, как и в ChatGPT. Генерировать следующий токен — популярная задача не только в чатботах.

— Про обучение в эпоху AI. Как будут появляться сильные инженеры с опытом и насмотренностью, если AI снимает необходимость «набивать шишки» и закрывает пробелы знаниями «из коробки»? (P.S. а вы знаете как?)

И дискуссии: экономия времени, внедрение AI в продукты и разработку. Хорошо показывают, что сейчас в фокусе у C-level Яндекса.

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

Yauza Place - лайк.