S0ER

await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() }) this.analyticsService.track("lesson_started", { userId, lessonId }) .catch(err => this.logger.error("Analytics failed", err)) } ` Стал ли код лучше? И да, и нет. Первый вариант по-прежнему остается самым читаемым, понятным и простым. Но на перспективу иметь разделение обязанностей и четкие границы между слоями - это очевидный плюс. Получается три разных варианта, все рабочие. Но какой из них подойдет в конкретной ситуации - это решение, которое должен принять разработчик. Реальное программирование - это всегда компромисс между надёжностью, универсальностью и простотой. Важно помнить, что как программисты, мы всегда можем объяснить, какие проблемы есть в коде, какие опасности они создают. Но насколько эти "проблемы" реальны - сказать сложно. И никто не знает, какой выбор нужно сделать. Знаю только, что через год-два открою этот код и не вспомню, почему выбрал именно так. И, скорее всего, нужно будет объяснять проблемы и переписывать... Опять.

Три варианта. Один выбор. Допустим, у нас есть задача реализовать user story:

Как пользователь платформы, я хочу начать урок, чтобы продолжить обучение и потратить накопленные токены.

Наивная реализация на TypeScript + NestJS могла бы выглядеть как-то так:

async startLesson(userId: string, lessonId: string) {
    const user = await this.userRepository.findById(userId)
    const lesson = await this.lessonRepository.findById(lessonId)
    
    const subscription = await this.subscriptionRepository.findActiveByUser(userId)
    if (!subscription || subscription.expiresAt < new Date()) {
        throw new Error("No active subscription")
    }
    
    if (user.tokens < lesson.tokensCost) {
        throw new Error("Not enough tokens")
    }
    
    await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost })
    await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
    await this.analyticsService.track("lesson_started", { userId, lessonId })
}

Код рабочий и простой. Но насколько он хорош? Остановитесь на секунду и назовите 2-3 потенциальные проблемы этого кода. Я нашел сразу пять: - Проверка подписки здесь, хотя должна быть в отдельном слое доступа. - Списание токенов не атомарное - между проверкой и обновлением токены может списать другой запрос. - Нет транзакции - если сервер упал между update и create, токены списались, а прогресс не создался. - Аналитика блокирует основной поток. - Нет уникального индекса на прогресс. Учитывая эти моменты, можно сделать более надёжную реализацию:

async startLesson(userId: string, lessonId: string) {
    return this.unitOfWork.execute(async (uow) => {
        const user = await uow.users.findById(userId)
        const lesson = await uow.lessons.findById(lessonId)
        
        if (!user || !lesson) {
            throw new Error("User or lesson not found")
        }
        
        const accessResult = await this.accessService.checkAccess(user, lesson)
        if (!accessResult.allowed) {
            throw new Error(accessResult.reason)
        }
        
        const updateResult = await uow.users.updateOne(
            { _id: userId, tokens: { $gte: lesson.tokensCost } },
            { $inc: { tokens: -lesson.tokensCost } }
        )
        
        if (updateResult.modifiedCount === 0) {
            throw new Error("Not enough tokens")
        }
        
        return await uow.progress.create({
            userId,
            lessonId,
            status: "started",
            startedAt: new Date()
        })
    })
}

Код стал сложнее и надёжнее: транзакция, атомарность, разделение ответственности. Но суть в том, что для небольшого проекта с десятком активных пользователей эта сложность чаще всего не нужна. Вероятность race condition стремится к нулю. Если транзакция зависнет - техподдержка поправит токены за пять минут, а вы потратили кучу времени на Unit of Work. Поэтому из перечисленных проблем, наверное, единственное, что достаточно универсально - это разделение обязанностей. Всё остальное - преждевременная оптимизация. Итоговый вариант кода с разделением обязанностей выглядел бы так: `typescript async startLesson(userId: string, lessonId: string) { const user = await this.userRepository.findById(userId) const lesson = await this.lessonRepository.findById(lessonId) if (!user || !lesson) { throw new Error("User or lesson not found") } const accessResult = await this.accessService.checkAccess(user, lesson) if (!accessResult.allowed) { throw new Error(accessResult.reason) } if (user.tokens < lesson.tokensCost) { throw new Error("Not enough tokens") } await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost })

ИИ база Ну что, дожили до того светлого будущего, когда все больше работодателей интересуются, умеет ли соискатель работать с ИИ. Сразу успокою, пока — это далеко ни каждый первый и даже ни каждый второй, поэтому есть время подготовиться и понять, что вообще могут спросить и как отвечать. Почему стали проверять знания ИИ? Тут все просто — строили, строили и наконец построили процессы, которые включают работу агентов как дополнительный инструмент для решения рабочих задач. Раньше джун мог выехать на одном языке и фреймворке, а теперь даже на старте ждут, что ты не просто пишешь код, а понимаешь, как подключить к этому делу LLM. Лично мне положение дел скорее радует, чем огорчает. Для инженеров (соеров) — это дополнительная возможность карьерного роста, да, снова надо учиться новому и уходить в сторону M-shape, но так было всегда — учись лавировать или уходи из профессии. Для джунов ситуация стала сложнее — кроме обязательного System Design, появляется "покажи, как ты умеешь с агентами работать". И если по системному дизайну еще можно измерить нагрузку городами и как-то проскочить со словами "ну что вы от меня хотите, я ж только учусь", то по ИИ нужно показать хотя бы базовые практические навыки, и здесь все зависит от желания развиваться, так что шансы есть, особенно если подкачать базу. Сейчас в приоритете агенты (с постепенным переходом к командам агентов и оркестрации), нужно уметь: Теория: - промпт-инжениринг — нужно рассказать про принципы, подходы, техники рассуждений и т.д. - контекст-инжениринг — нужно объяснить, что такое контекстные окна, «загнивание» контекста, управление вниманием, RAG и т.д. - обосновать выбор модели под задачу (например, тебя просят разработать небольшую фичу за разумное время и потребление токенов — тут главное не гонять дорогую модельку на задачах, а показать, что ты понимаешь, где проходят «границы возможностей»); - архитектура агентов (включая команды агентов) Практика Например, задача на 20–30 минут, где нужно показать основные моменты разработки с агентами. На собеседовании дается живой кейс с уже настроенным агентом (либо можно взять свой привычный инструмент) и нужно: - построить структуру проекта c учетом spec-driven development, ADR и т.д.; - подобрать набор инструментов (в том числе MCP) и скиллов; - разбить задачу на этапы (планирование, проектирование, реализация, контроль); - решить проблемы галлюцинаций и в завершение сделать качественное ревью результата (т.е. показать, что именно «вы» будете делать и почему human in the loop так важен). И для общей статистики предлагаю поставить 💡 если в твоей компании уже просят использовать ИИ или на собесах задают вопросы по ИИ.

Курс по микросервисам стартует 20.04.2026. Продолжаю создание курсов по теме архитектуры. Ранее в сообществе были созданы коллекции материалов по сервисам и монолитам, и вот настала очередь микросервисов. О курсе: ❗️ приоритет на проектирование, документирование и анализ (будем разбираться, как проводить границы, формировать требования, распределять обязанности и т.д.) ❗️ изучать можно индивидуально или общаясь в группе ❗️ еженедельные семинары с разбором проблем и консультациями (только для Подписки №3) ❗️ часть созвонов предполагает интерактивный формат круглого стола (например, общая Event Storming сессия) Важно! Это не формат обучения. Нет никаких обязательных лабораторных работ, программы обучения и прочих вещей. Вместо этого — набор материалов, доступных по подписке, и обмен реальным опытом. Можно просто смотреть лекции (для этого нужна Подписка №1), можно дополнительно смотреть мастер-классы (подписка №2), а для обратной связи приходить на семинары (подписка №3). Наибольшая польза достигается за счет участия в семинарах: у нас собрана команда из 10 человек — это специалисты разного уровня, от архитекторов до новичков.  Мы обсуждаем не только информацию из курсов, но и практические вопросы, которые есть у ребят. Поэтому встречи — это отличный способ обменяться опытом, задать вопросы, получить информацию, которая выходит за пределы курса. Количество участников на семинарах ограничено, сейчас есть 4 места, которые доступны, если вы приобрели подписку №3. Важный момент! Подписка предусматривает доступ ко всем имеющимся материалам, встречам, созвонам и т.д., в общем, всему тому, что входит в подписку. Поэтому не надо думать, что подписка идет на курс: курс — лишь часть того, что есть в подписке. Мы реализуем идею поэтапного развития (движения к цели короткими шагами), постоянно шлифуем свои навыки, собираем актуальную информацию, которую можно применять на практике, обмениваемся опытом и т.д., а подписка определяет уровень доступа. Например, после курса по микросервисам планирую курс по архитектуре агентных систем, дополнительные созвоны, публикацию материалов в ИИ-лаборатории и т.д. В общем, приобретая подписку, вы получаете не только курс, а участие в нашем сообществе и его активностях.

Последнее видео по промпт-инженерии далось с особой болью, раньше я бездумно использовал советы из интернета, которые определяли, что нормальный промпт - это когда ты задаешь роль, контекст, задачу, пример (строго в таком порядке) и добавляешь конкретные измеряемые критрии качества. Я использовал и мне казалось, что "Вау! Это работает". А потом я решил сделать ролик в котором показать "плохие" и "хорошие" промпты. Оказалось, что "плохие" промпты работают ничуть не хуже чем "хорошие", т.е. все это время я делал промпты не понимая, что делаю "шляпу". В итоге я собрал те моменты, которые реально дают изменения, перестал писать портянки текста, больше фокуса на примеры и техники размышления и вот здесь уже удалось показать разницу. А знаменитое "представь что ты программист" оказалась не такой полезной штукой, как я думал.

Сделал видео по созданию промптов, идея была в том, чтобы рассмотреть разные варианты текстов и выделить общие правила, которые опубликовать на soerdev.space в картах знаний. В итоге получилось очень плотное информативное видео, смотреть можно тут: YouTube | Vk | RuTube

Отвечаю на вопрос из комментариев к видео:

вы говорите о важности умения проектировать ПО, умения писать архитектурные доки, умения подбора стека-технологий и т.п., а в чем проблема так же отдавать эту работу на плечи LLM и относится к итоговому коду и архитектуре, которая генерирует LLM - как к чему-то низкоуровневому?

Проблем несколько: 🔴Недостаточно материала для обучения. Для кода — куча информации для датасета, для архитектуры — мало. Поэтому ИИ выдает довольно сомнительные по качеству решения. Он легко может логику засунуть в инфраструктурный слой, не провести границы между разными модулями, упустить важные требования. 🔴Проблемы с контекстным окном и вниманием. LLM теряет и искажает существенные моменты по мере заполнения контекстного окна, причем современные LLM, которые имеют окно 1 млн токенов, по субъективным ощущениям вместо улучшения качества проработки решений, наоборот, ухудшают их. 🔴Неравномерность результата — проект собирается из частей. Иногда LLM делает довольно хорошо какую-то часть, а потом сваливается в галлюцинации для другой части. В целом стратегия «разделяй и властвуй» в LLM пока плохо реализуема. В будущем, скорее всего, LLM сможет создавать и качественную архитектуру проекта, но пока до этого далеко.

На Хабре вышла статья о развитии отечественной модели GigaChat 3.1. У меня по этому поводу какие-то двоякие чувства. С одной стороны, GigaChat — это, ИМХО, единственная "честная" отечественная модель, которая более-менее может решать прикладные задачи, не связанные с кодом. С другой стороны, описанные в статье сравнения с DeepSeek-V3-0324 и Qwen3-235B-A22B-Non-Thinking подтверждают факт приличного отставания в гонке ИИ. Модели годовалой давности, по современным меркам — это много. Сейчас счет на месяцы идет. Если взять Gemini 3.0 и 3.1, там огромный разрыв в результатах за короткий срок. Но тем не менее есть и позитивные моменты — ребята нарабатывают опыт, что, пожалуй, самое важное. Судя по статье, Сбер не стал изобретать что-то радикально новое, а использовал проверенные инженерные наработки (например, DeepGEMM и подходы к FP8), сосредоточившись на качестве данных, пост-тренинге и инженерной доводке. Это более разумно, чем колупаться со своими решениями и отставать еще больше. Поэтому держу кулачки и надеюсь, что у ребят все получится. Пока огромный минус — цена вопроса при доступе через API. Вот тут надо сильно переосмысливать.

Продолжаю размышлять о том как работать в условиях, когда ИИ бурно развивается. Сегодня решил поговорить о том, как архитектура программного обеспечения помогает при создании ИИ агентов и новых проектов. YouTube | VK | RuTube

На канале вышло видео о том как конкурировать с ИИ. Кажется, что ИИ становится настолько умным, что уже куда не кинься, а там нет места человеку. Многие рутинные вещи уже неплохо делает машина, а что делать человеку - большой вопрос. Далеко ходит не надо, даже монтаж этого видео на 60% сделан ИИ. Но если присмотреться, есть несколько вещей, которые пока нас защищают от тотальной замены: вопрос ответственности (ее по-прежнему несут люди), скорость внедрения новых технологий, абстракции и инфраструктурные вопросы. Подробнее смотрим в видео: YouTube | VK | RuTube

Привет, можешь дать рекомендации по литературе, где можно получит/улучшить такие навыки

Хороших книг не знаю, сейчас все изучают просто по наборам тем, так как быстро все изменяется. У меня есть бесплатные карты знаний, где подобрал темы для изучения (они пополняются и развиваются), там есть краткая справка, ну и дальше можно просто искать ролики на эти темы и собирать информацию. • Основы ИИ • Инженерия контекста Если собирать самому не хочется, то могу предложить свои платные коллекции знаний: • на следующей неделе стартует интенсив Архитектура ИИ-агентов • Дополнительно есть записи видео по архитектуре Монолитная архитектура и Сервисная архитектура (это к вопросу как строить проекты, чтобы их мог поддерживать ИИ)

Как и обещал делюсь своими наработками по теме архитектуры мультиагентных систем. Сегодня опубликовал видео в котором описал основные моменты фреймворка для построения агента. Видео опубликовано и доступно на всех основных полщадках: YouTube | VK | RuTube

Мы вчера обсуждали, что далеко не каждая кодовая база готова к тому, чтобы ее смог сопровождать ИИ, вот статья, где больше конкретики Коротко: Проблема в том, что ИИ не умеет накапливать контекст. Все, что он получает на вход, он счтает достаточным для принятия решения. Причем, даже если ему дать инструкцию проверить хватает ли данных в контексте, он с высокой вероятностью не сможет качественно отличить ситуацию от "минимально достаточного" и "реально необходимого". Люди в силу способности к самообучению, накоплению знаний и прочим когнетивным способностям, не так остро чувствуют эту проблему. Поэтому справляются даже со сложными кодовыми базами намного лучше. Что можно сделать? Чтобы ИИ начал лучше работать с кодом, в статье прделагается следующее: - Перестраивайте компоненты так, чтобы они заканчивали работу, а не запускали цепную реакцию. В статье сказано дословно сказано "Sinks, Not Pipes" идея в том, что каждая функция должна завершать свою работу,а не порождать цепочку вызовов после себя. От себя добавлю, что это классическое разделение на main и утилитарные функции. - Используйте разделение на модули, с понятным и непротиворечивым интерфейсом. Здест тоже все по классие - границы и обязанности - Используйте "глубокие" модули, модуль может содержать сложную логику, но она должна быть полностью инкапсулирована и скрыта за небольшим интерфейсом, не надо делать кучу "мелких" зависимостей вокруг модуля. - Файловая структура должна соответствовать модульной декомпозиции или принцип "честной архитектуры". Тут важно чтобы нейминг и логика были прозрачные и понятные. Чтобы облегчить работу ИИ можно использовать тесты, как источник правды: тесты проходят, значит все ок. Резюме: • Организуйте папки так, чтобы архитектура читалась с первого взгляда • Сделайте тесты границами - проходят, значитможно не лезть внутрь • Проектируйте интерфейсы честно - никаких скрытых эффектов • Регулярно проверяйте зависимости - отлавливайте "скрытые связи" • Внедряйте прогрессивное раскрытие - от общего к частному

Развитие систем разработки с помощью ИИ идет не только за счет увеличения мощности LLM. Одно из направлений — создание мультиагентных систем. Я запустил небольшой эксперимент, в рамках которого создаю небольшую LMS (это аналог NarisApp). Задача — проверить, можно ли доверить разработку небольших проектов искусственному интеллекту. Первые результаты — в видео ниже. YouTube | VK | RuTube

Выпустил ролик "Чему учиться программисту в первую очередь". Это ответ на вопросы подписчика о том как совместить изучение базовой теории, технички и новых реалий, связанных с изучением ИИ. YouTube | VK | RuTube

Использование ADR в качестве источника правды при архитектурном ревью - идея отличная. Были споры, что это сработает, поэтому провели исследование: Evaluating Large Language Models for Detecting Architectural Decision Violations, которое подтвердило, что идея рабочая. Стоит отметить что не все архитектурные задачи ИИ делает хорошо, но в целом с контролем решений он справляется. Коротко:взяли около 100 репозиторев и почти 1000 adr, построили пайплайн из моделей, которые проводят анализ и оценивают результаты, используя ADR. Проверку поручили людям. Оказалось, что оценка людей в большинстве случаев совпадает с ИИ. Нюансы: ADR были написаны людьми, код тоже людьми. Способность контролировать не значит, что ИИ смог бы грамотно спроектировать и поддерживать базу решений. Что это значит? Скорее всего ревью кода и архитектуры в будущем будет делать ИИ, а архитекторам поручат исправление.

21.02.2026 10:00 Мск Проведу архитектурный стрим (только для платных подписчиков soer.pro) В рамках встречи поговорим о том какое влияние ИИ оказывает на архитектуру программного обеспечения и как это в свою очередь влияет на нас программистов. Темы: - Разберём разницу между AI Ready и AI First с позиции архитектуры - Поговорим про принципы построения новых систем: → Токены - Контекст - Оркестрация (три кита современных ИИ систем) → Почему SOLID и другие принципы уже не так важны. - Токены - новое золото → Проблемы долгосрочной памяти - как их решать → Контекстное окно - как его правильно использовать - OpenClaw → Общая архитектура → Оркестрация, память, контекст и агент Формат: доклад + круглый стол. Пока не определился с площадкой, будет зависеть от того сколько человек решит подключиться. У нас есть группа Лаборатория ИИ подключайтесь, там будет голосование и примем решение где провести трансляцию.

Выпустил ролик "Движение к цели короткими шагами". Сейчас часто стал слышать, что появление ИИ сильно изменило профессию и объемы новой заметно выросли, активно развиваются идеи, подходы, появляется новый софт и т.д. и т.п. из-за этого люди чувствуют себя в состоянии гонки и постоянного напряжения. Мне кажется, что это важная тема для разговора, поэтому решил снять короткое видео где изложил свои мысли как можно и нужно справляться с информационным потоком. Надеюсь вы найдете для себя что-то полезное, обсудить можно в комментариях к этому посту. Youtube | VK | RuTube

Напоминаю, что у меня есть канал в Max