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

Пока мы обсуждаем как защититься от 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 сентября.

Давайте завайбкодим аналог Reddit r/place. Так как я большой адепт вайб-кодинга, у меня есть цель сделать так, чтобы максимально большое число людей осознало, что можно делать сложные вещи, не написав ни единой строчки кода. Рано или поздно эти инструменты перерастут из нишевых «можно быстро собрать прототип на коленке» в enterprise-среды больших компаний. Провёл на днях воркшоп, который получился настолько эпичным, что решил принести его сюда. Пятнично. Знаете ли вы, что такое Reddit r/place? В 2017 году, Reddit запустил социальный эксперимент: — огромное онлайн-полотно — каждый пользователь редактирует его по пикселям — из миллионов точек складывается общая картина в реальном времени В чём состоял феномен r/place? — r/place стал цифровым зеркалом, культурным кодом: мемы, флаги, бренды и искусство. — люди объединялись в группы, чтобы «отвоёвывать территории» или защищать рисунки. — в реальном времени возникали альянсы, войны и дипломатия — как в миниатюрном мире. — 2022: 6+ млн участников, 160 млн пикселей (!). Воркшоп. Я предварительно завайбкодил серверную часть — онлайн-полотно: https://place.skogorev.com По ссылке доступен UI, и по ней же доступен REST API. (если вы всё ещё не верите в вайбкодинг, только вдумайтесь — целый сервис с одного промпта). Теперь ваша очередь — на нём что-то нарисовать! Давайте завайбкодим клиентскую часть. 1) Логинимся в любой инструмент вайбкодинга: Lovable, Replit или, например, в Cursor. 2) Берём промпт отсюда, редактируем его как-нибудь (или берём как есть) и вставляем в выбранный инструмент. 3) Запускаем и смотрим. Присылайте в комментарии, что получилось. Посмотрим, какой культурный код у этого канала.

Давно хотел поделиться тем, что происходит под капотом 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, мы всё ещё размышляем и экспериментируем.

Как избежать кризиса архитектуры 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.