Архитектура Стартапа - Anton Skogorev Engineering & AI

Выступал на ИТ-Пикнике с докладом "Джентельменский набор продакшен GenAI инфраструктуры". Собрал воедино решения, которые мы несколько лет строили в Т-Банке вокруг генеративных моделей. Разложил их по логическим слоям и получился вот такой джентельментский набор архитектурных кубиков для GenAI. В самом докладе рассказывал какие из этих кубиков когда нужны (выложил презентацию в комментариях).

8-го августа в Коломенском парке расскажу о том из каких блоков может состоять GenAI платформа в компании и нужно ли ее вообще строить. Приходите подискутировать на ИТ-Пикник!

Пока мы обсуждаем как защититься от Prompt Injection и Supply Chain уязвимостей, Github Copilot добавляет рекламу прямо в PR. https://notes.zachmanson.com/copilot-edited-an-ad-into-my-pr/ Представляете будущее, где ваш агент выбирает стек не по техническим характеристикам, а по размеру маркетингового бюджета вендора? ChatGPT, кстати, тоже внедряет рекламу. У них есть очень хорошая страница с принципами, очень рекомендую почитать.

Замена Google на 50 строк Python Пока все раскупают macmini для openclaw, не смог пройти мимо статьи с максимально простой идеей: автор устал каждый раз гуглить мелкие shell-команды вроде tar -xzf и сделал мини-CLI на Python, который принимает запрос на русском, отправляет его в LLM и возвращает одну bash-команду с обязательным подтверждением перед выполнением. Мастхэв, если вы как и я забываете, какие там параметры у grep, как в curl сделать POST-запрос и как найти дубли в файле. https://habr.com/articles/1001214/

Друзья, опубликовал подробный гайд по архитектуре AI-агентов. В нем собрал: - из каких компонентов состоит агент и как они друг с другом взаимодействуют - какие бывают типы оркестрации у агентов - как правильно собирать контекстное окно - какие есть угрозы безопасности и как с ними боротся - и много чего еще другого Если останутся вопросы, как вам собирать надежных AI-агентов, напишите в комментариях или в личных сообщениях @seva_batareika

Хакатон по LLM-агентам в СПБ. 11 апреля в нашем офисе в Питере на Свердловской набережной проводим крутейший хакатон по созданию LLM-агентов. Можно будет собрать агента на платформе BitGN, понетворкаться с единомышленниками и даже забрать призы за лучшие решения. по ссылке больше инфы: https://bitgn.tb.ru/spb_bitgn_pac1

Сегодня специфичный пост для инженеров. Много юзаю Claude Code в последнее время и не отпускает одна мысль. В своё инженерное прошлое я всегда угорал по «лучшим практикам» — SOLID, TDD, Clean Architecture, DDD, property-based testing и тд. Большинство команд их игнорировали: сложно, долго, вэлью непонятно. И аргумент про сложность был честным — поддерживать чистую архитектуру и писать тесты до кода реально дорого по времени и когнитивной нагрузке. Так вот. Кажется, агенты снимают порог входа в эти практики — написать тесты, нарезать интерфейсы, разложить по слоям стоит копейки, когда это делает Claude Code. А сами практики в ответ снимают ключевое ограничение агентов — контекстное окно. Агент не может держать в голове весь проект. 250к токенов звучит много, но реальная кодовая база вылезает за эти пределы быстро. А даже если влезает — качество падает. Даже с 1м контекстом. Модель теряет детали, путает зависимости, начинает галлюцинировать. И тут Clean Architecture начинает выглядеть как идеальный интерфейс между тобой и агентом. Чёткие слои, определённые контракты между ними — и для работы с конкретным куском агенту достаточно видеть архитектуру, интерфейсы и код текущего модуля. Не всю кодовую базу, а только нужную часть и интерфейсы взаимодействия с другими слоями. DDD усиливает эту же идею: bounded contexts — это готовые границы того, что агенту нужно загрузить, а ubiquitous language делает код читаемым без дополнительной документации. SOLID вообще читается как готовый чеклист «как сделать кодовую базу, с которой агент справится»: - Single Responsibility — меньше кода нужно видеть для одного изменения - Open/Closed — агент добавляет новую реализацию, не трогая существующий код, который даже не нужно грузить в контекст - Liskov Substitution — можно подменить реализацию и ничего не сломается, а тесты это верифицируют - Interface Segregation — агент видит только нужный ему срез интерфейса, а не всё подряд - Dependency Inversion — для меня самый показательный. Модуль зависит от абстракции, не от реализации. Агенту не надо тащить в контекст код базы данных, чтобы написать бизнес-логику — хватит интерфейса репозитория С TDD та же история. Тест — это спецификация поведения, которая влезает в контекст и однозначно верифицирует результат. Агент получил тест, написал реализацию, запустил — красный, зелёный, рефакторинг. Цикл обратной связи без необходимости понимать всю систему. Отдельно про property-based тестирование. Штука всегда была нишевой — мало кто хотел возиться с генераторами и инвариантами, когда можно накидать пять юнит-тестов. Но с агентами property-based тесты должны давать непропорционально много фидбека при минимуме тестового кода. Один тест с правильно описанным свойством — это тысячи кейсов, которые агент прогоняет за секунды. При этом llm’ки куда быстрее придумывают все инварианты для тестирования, что снимает с разработчика когнитивную нагрузку на имплементацию подхода. И вот что мне кажется самым интересным: property-based тесты идеально ложатся в цепочку PRD → TDD → реализация. Свойства системы из PRD («баланс не может быть отрицательным», «сумма позиций равна итогу заказа») транслируются в property-тесты почти один к одному. Агент получает свойства как спецификацию и пишет код, который им удовлетворяет. По сути requirements (R из PRD) становятся исполняемой верификацией — без ручной работы по переводу в десятки отдельных тестов. Годами шли споры, стоит ли Clean Architecture и другие практики своих накладных расходов — всех этих дополнительных абстракций и интерфейсов. Будет забавно, если окажется, что именно эти «лишние» абстракции делают кодовую базу пригодной для работы с AI.

AI Workspace ТБанк. Прошлый опыт поиска кандидата через телеграм на сверхамбициозную задачу — строить LLM-платформу — завершился оффером. Попытаю счастье ещё раз. В Т-Банке, вдумайтесь, работают десятки тысяч сотрудников. Это огромный рынок для поиска эффективностей. С приходом больших языковых моделей и агентских сценариев мало кто думает, что то, как строятся компании сейчас, будет выглядеть так же в ближайшие 5 лет. Мы об этом очень серьёзно думаем и инвестируем в это большие ресурсы. Мы берём самые передовые технологии, что есть на рынке, и прикладываем их к профессиям, к туллингу, к процессам. Получается набор высокотехнологичных стартапов и платформ, которые должны превратиться в полноценную AI-поверхность. Ровно это мы и начинаем строить — AI экосистему сотрудника. Что в фокусе сейчас: — AI Workspace (OpenWebUI like) — Knowledge retrieval с инструментальным доступом (MCP для Jira, Confluence, внутренних систем) + search — Потоковая (?) транскрибация встреч → realtime summarization → action extraction — Копилоты для профессий Это очень важное для нас направление, и мы ищем технического руководителя. Если привлекает идея строить будущее AI-компании, пишите мне @skogorev — пообщаемся.

AI-ассистент может замедлять рост инженеров — даже если ускоряет delivery. https://www.anthropic.com/research/AI-assistance-coding-skills Anthropic выпустили исследование: 52 разработчика начального уровня решали задачи с AI и без него. Плохие новости: — Скорость — почти без статистически значимого выигрыша. — Понимание того, что ты только что сделал — заметно хуже (~−17%). — Сильнее всего проседает debugging: умение читать ошибки, строить гипотезы и чинить причины, а не симптомы. Многие используют ассистента как замену мышлению — делегируют ему не только "делать", но и "понимать". На короткой дистанции вы получаете буст, а на длинной — теряете в навыках. И если вы научились или учитесь из AI извлекать повышение производительности, это может произойти за счет снижения квалификации. Что стоит делать на регулярной основе лично каждому: 1. Для нового/сложного — режим Explain-first: "объясни, дай альтернативы", а не "сделай". 2. Для дебага — "план диагностики, дай гипотезы", а не "дай фикс". 3. В ревью — требовать 2–3 предложения: почему так, какие компромиссы.

VS Code + Codex (gpt-5.2) + AI Native Project Workspace Недавно меня спросили, как я реально использую LLM в работе. И пока все пробуют очередного хайпового агента clawdbot, расскажу, как выглядит моя хардкорная рабочая среда для ведения менеджерских задач. Я сильно проникся идеей Context Engineering — и меня сильно бесит, как ChatGPT любит вытаскивать случайные факты из наших переписок и применять их в максимально нерелевантном контексте: - Сформулируй техническую стратегию Центра ИИ на 2026 год - Вижу, что ты интересовался поездкой в Китай, сформулирую техническую стратегию с учётом того, как это сделали бы в Макао. Я использую такую связку: VS Code + Codex (gpt-5.2) + AI Native Project Workspace AI Native Project Workspace — это мой рабочий проект «задач CTO», заточенный под совместное мышление меня и LLM. С помощью структуры проекта я чётко задаю и ограничиваю контекст для LLM-агента: кто я такой, как генерировать идеи, как вести мои задачи. В итоге агент каждый раз работает с одной и той же когнитивной моделью, а не с обрывками переписок. Такой подход отрезает случайные ассоциации, «галлюцинации по биографии» и даёт воспроизводимый результат. Вот так выглядит структура проекта, без усложнений: /DRAFTS — рабочая папка задач. Один .md — одна задача. /PROFILE.md — кто я такой, чем занимаюсь, за что отвечаю, какой стек технологий, стиль (без воды, data-driven и проч.). /PROMPTS.md — набор промптов для запуска агента работать над задачей. /AGENTS.md — инструкции для работы агента: как ведём задачи, DoD, разные роли, инструкции для брейншторма и проч. Это и есть Context Engineering на практике. В комментариях — примеры задачек, которые можно решать в таком воркспейсе.

Принёс вам новый термин — AI Agent Washing. Услышал его вчера в офисе, а вечером уже обсуждали на панельной дискуссии с уважаемыми людьми — чем всё это грозит AI-индустрии. … Если коротко: Agent Washing — это когда вы говорите, что делаете AI-агента, хотя по факту это простой чат-бот, или автоматизация, или один промпт с tool calling. Но обо всём по порядку. Термин пошёл от greenwashing — это когда в отелях нас просили «ради экологии» не менять полотенца, при этом улучшалась не экология, а экономика отеля на стирке. С Agent Washing — то же самое: попытка заработать за счёт хайпа, продавая автономность и интеллект там, где их нет. Почему это проблема для индустрии? Потому что под словом «агент» пользователь представляет себе полноценного автономного исполнителя, который берёт задачу под ключ и отвечает за результат. А когда он сталкивается с «однопромптником», проданным под видом готового продукта, он теряет веру не только в конкретный продукт — он теряет веру в саму индустрию. Вспомните инвесторский хайп вокруг блокчейна 5 лет назад. Сегодня само слово «блокчейн» имеет довольно токсичный вайб — не потому, что технология плохая, а потому, что ожидания были сильно завышены. Проблема тут не в терминах — проблема в ожиданиях. Индустрия плохо их выстраивает и идёт по пути Tesla, продавая Full Self-Driving, когда никакого full там и близко нет. Предлагаю зафиксировать, что является AI-агентом: — система с собственной целью (не «ответить пользователю», а достигнуть цели, например, «продать N товаров») — автономная (может инициировать действия сама, без кнопки «ОК» от пользователя) — отвечает за результат (есть success / failure) — имеет долгоживущую память (и учитывает прошлые ошибки) — действует в среде (инфраструктура, сервисы, бизнес-процессы — а не просто чат)

C-Connect от Яндекса. Сходил на CTO/CPO Connect — камерный эвент от Яндекса для C-level руководителей. Главная тема — AI. Было несколько действительно интересных рассказов. — Physical AI (роверы, грузовики, роботакси). Интересно было посмотреть на архитектуру AI-решений из реального мира. Любопытно, что там под капотом чаще используются такие же трансформеры, как и в ChatGPT. Генерировать следующий токен — популярная задача не только в чатботах. — Про обучение в эпоху AI. Как будут появляться сильные инженеры с опытом и насмотренностью, если AI снимает необходимость «набивать шишки» и закрывает пробелы знаниями «из коробки»? (P.S. а вы знаете как?) И дискуссии: экономия времени, внедрение AI в продукты и разработку. Хорошо показывают, что сейчас в фокусе у C-level Яндекса. Все понимают потенциал и то, что нужно что-то делать, чтобы оказаться в будущем. Мало кто понимает, какой действительно это всё окажет эффект на индустрию и как его правильно считать. Yauza Place - лайк.

Немного бэкстейджа про канал. Пошёл я тут на профи.ру, нашёл специалиста по продвижению канала. Показал статистику: посты читают хорошо — 2к+ (иногда залетают на 10к), хорошо шарят (последний пост — 46 репостов). Но подписчики почти не растут: с каждого поста приходит 5–10 человек. При том что каждый текст занимает у меня много времени и сил — и это, мягко говоря, демотивирует. И вот пришёл специалист и говорит: «Сложный у тебя канал, Антон». Предложил два пути: нужно либо упрощать контент (рубрика «промпт дня»!), либо больше писать о себе. Надеюсь, вы подписались сюда не ради лёгкого контента. Выбираю второй вариант. Ну и если хотите поддержать — буду благодарен за репост ссылки на канал. Это правда помогает. https://t.me/startup_architecture

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

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). А как у вас? Используете агентов?

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-агента для разработки от Т-Технологий! Агент заточен на работу с большими проектами. Сила таких решений в интеграции и правильном создании контекста, а не в моделях. Context Engineering Model-agnostic подход: не выпендриваемся и используем лучшие модели, сейчас это Qwen3-Coder Внутри работает уже вовсю 💅 Форбс тут Подробности тут

Действительно ли AI повышает производительность разработчиков? Does AI Actually Boost Developer Productivity? Стендфорд провел эксперимент на эффективности 100к разработчиков с AI-копайлотами, результаты очень показательные: — +15–20% к продуктивности в среднем. — На простых или новых задачах прирост достигает 30–40%. — На сложных и legacy-задачах эффект может быть нулевым или даже отрицательным. — На популярных языках (Python, Java) AI помогает значительно сильнее, чем на редких. Мой коллега, Игорь, поделился пару дней назад важной мыслью — с помощью LLM эффективные люди будут становиться еще более эффективными, а остальные будут терять конкурентоспособность еще быстрее, чем раньше. Игорь советует быть в первом лагере. @startup_architecture

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