S0ER

Как же больно использовать API вызовы для Fable 5. Это стата из OpenCode Zen, у меня для ревью спеки используется Fable, а для написании спеки в части программных интерфейсов Kimi 2.7, на то чтобы Fable дал несколько замечаний улетает 4-5$ (по сути это один промпт).

Для того чтобы погонять Fable 5, пришлось вернуть подписку на Клода. В целом чувствуется, что модель сильнее Opus 4.8 (это проявляется в мелких деталях, подробнее писал в ИИ-лаборатории нашего клуба), но глобально ничего не меняется. Но вот что меня поразило, так это мои ощущения от использования Claude Code: как же я отвык от human in the loop, сидеть и постоянно контролировать - это не мое. У меня сейчас для работы сделано два оркестратора. Один реализует проектный SDLC, второй - общего назначения. Они связаны друг с другом и могут обмениваться заданиями и статусом выполнения, в общем агенте есть общий чат куда прилетают отчеты о выполнении. Развиваю проекты инкрементами, которые выглядят примерно так:

$soerdev add spec "Новая фича"
$soerdev refine spec
$soerdev plan
$soerdev run

Это реализация цикла Human ON the loop. Логика такая: добавляем драфт спеки, обсуждаем детали, фиксируем план, запускаем цикл до выполнения критериев останова. В работу не вмешиваюсь, но вижу в чате и телеграм боте что происходит. И знаете что? Это реально удобно! Теоретически что-то подобное можно настроить и в CLI-агентах, но все равно придется допиливать харнес для отправки сообщений в телеграм, делать свой аналог гейтов, делать скилы и промпты. А так все зашито в оркестратор soerdev.

В своих выступлениях Андрей Карпаты рассказывает о том, что он начал разрабатывать программы, выстраивая агентный цикл (Loop Engineering). Это интересная механика, которую я примерно полгода назад пытался использовать в своем оркестраторе. Идея в том, чтобы не говорить ИИ, что делать конкретно, а вместо этого выстроить цикл постепенного написания и улучшения кода. Эдакий эволюционный подход. На самом деле все, кто серьезно занимаются разработкой с помощью ИИ, рано или поздно приходят к этой идее, так как ИИ довольно специфично работает с механизмом внимания (attention) и страдает от разных "эффектов" - потеря информации в середине контекста (lost-in-the-middle), ослабление фокуса на ранних инструкциях, излишнее якорение (anchoring bias) и накопление ошибок (error accumulation), когда модель достраивает решение вокруг уже сгенерированного кода, даже если там есть проблема. Из-за этого модель может пропускать важные детали, даже если указать на них явно. При этом ИИ способен находить отклонения и ошибки если запустить его повторно. Поэтому запуская модель в цикле можно получить нормальный результат. Но есть несколько проблем. Во-первых, большое потребление токенов. Например, средний цикл на 8-10 часов использует от 30 до 60 млн токенов. Если брать токены через API, то получается довольно дорого. Во-вторых, в длинных циклах агент начинает "дрейфовать", постепенно уходя в сторону от поставленной задачи. Проблема в том, что критерии приемки сложно сформулировать так, чтобы они покрывали все детали - сосредоточившись на одном аспекте, упускаешь другие. Даже если проводить многоступенчатые проверки, остается проблема "2 из 3" - когда ты не можешь закрыть все требования одновременно и вынужден идти на компромисс. Чем длиннее цикл, тем сильнее этот эффект. Поэтому я пошел другим путем: вместо того чтобы отказываться от циклов, я делаю их максимально короткими. Плюс ограничиваю количество итераций, а для вариативности решений запускаю несколько агентов с разными системными промптами параллельно, оркестрируя их через общий чат для сбора и сравнения результатов. Коммуникация в чате помогает понять не только "что" делают агенты, но и "почему" они это делают. Кроме чата каждый агент производит артефакты, которые далее могут использовать другими агентами. Если интересно, напишу отдельный пост про агентный харнес, который я использую. Понятно, что с позиции OpenAI, Anthropic и других разработчиков LLM методы, которые способствуют большему потреблению токенов, имеют большую привлекательность - в конце концов, их бизнес-модель строится на продаже токенов. Но для небольших исследований и малого бизнеса подходы с дроблением задач и короткими циклами - куда более эффективный метод, позволяющий сохранить качество кода, не сжигая бюджет и не допуская дрейфа агентов. Мне кажется, что сейчас ключевой навык инженера - не просто умение писать промпты, а способность декомпозировать задачу и настраивать агентную оркестрацию с короткими циклами так, чтобы каждый шаг давал предсказуемый результат. Это и есть та инженерия, которая нужна бизнесу. Но это на словах, на практике доверять агентам пока рано.

ИИ должен был помочь людям выполнять их работу лучше, а вместо этого приводит к усталости и выгоранию.

Очень хорошо прочувствовал эту проблему на себе. Работаю с ИИ каждый день: формирую пул заданий, загоняю в оркестратор (это моя агентная система), через несколько часов проверяю сделанное, собираю список правок, снова запускаю агентную систему - и так по кругу. Проблема в том, что циклов исправления очень много. Причем это не моя личная проблема, появился даже новый термин - "ботситтинг" - это когда человек "нянчится" с LLM, чтобы получить результат. По статистике, на такие проверки и исправления у сотрудников уходит в среднем 6.4 часа в неделю, то есть почти целый рабочий день. Ситуация усугубляется тем, что сначала кажется, будто человек делает меньшую часть работы - просто правит результат ИИ, а потом ждет. Но на самом деле цикл довольно плотный, а сам момент "принятия решения" сильно выматывает психологически (делать рутинный код на порядок проще, чем быстро анализировать, находить проблемы, указывать, что нужно переделать). Если посмотреть на историю коммитов, кажется, что проект растет, но если смотреть на качество - значительная часть кода - это сплошные исправления. Причем я не могу назвать это "рефакторингом". Рефакторинг - это улучшение структуры без изменения функциональности. В моем случае каждое исправление - это изменение поведения, которое ИИ изначально реализовал неправильно. В итоге стал замечать, что устаю от принятия решений. Даже правильнее сказать от "скорости" принятия решений. Выматывает, что нельзя ни в чем быть уверенным, нужно все проверять и перепроверять, либо рискушь скатиться в "ботшитинг". Такое состояние называется "AI brain fry" - это когда нужно принимать бесконечные микро-решения истощают когнитивные ресурсы. В результате падает КПД и возникает разрыв между тем, что я обсуждаю, и тем, что в итоге получаю. Пишут, что ИИ не только не сокращает объем задач, но и делает работу еще более интенсивной и сложной для человека. Можно возразить, что с людьми примерно так же - они ошибаются, переделывают и дорабатывают код. Но есть важнейший нюанс: люди делают это совсем в другом ритме. Машина же никогда не устает ошибаться. В итоге статистика удручающая: 48% разработчиков сообщают о ментальной усталости от работы с ИИ, 44% периодически чувствуют себя измотанными, а 19% уже вышли на уровень постоянного выгорания. При этом компании, уволившие сотрудников в надежде заменить их ИИ, вынуждены нанимать их обратно, так как модели не закрывают весь цикл разработки. Получается, я работаю не с кодом. Я работаю с системой, которая генерирует мне работу. И этой работы становится только больше. А вы говорите "ИИ скоро всех заменит". Сильно сомневаюсь.

А как у вас обстоят дела с агентами? Привет, испугался? Не бойся, я друг! Потрать пять минут, пройди опросник и расскажи про свое отношение, опыт и эффект от использования агентов. И поделись со своими друзьями, пусть они тоже прокликают. Я хочу собрать картинку, как покажет статус внедрения агентных практик в индустрии. С одной стороны когда ты общаешься с друзьями, кажется — ну вот оно, всё. Будущее безвозвратно наступило! Все себе чёто вайбкодят, внедрили в команды\процессы, у людей меняются профессиональные паттерны, а структура организации со всеми процессами рискует быть пересмотренной, выкинутой за борт и выстроенной по-новой с нуля А с другой, выходишь в народ, а там, либо все отрицают, либо называют использование веб-интерфейса чатгпт внедрением агентной разработки 🫣 Короче, давай вместе разберемся — пройди опрос! П.С. И конечно шерьте шерьте шерьте. Надо собрать со всей айтишки, а не только с моего маленького пузыря П.П.С. Итоги исследования и интересные находки обязательно опубликую у себя в канале и буду использовать при подготовке нашей конференции

Говорить, что ИИ заменит человека, так же как говорить, что калькулятор заменит математика

Суть метафоры понятна, но ирония в том, что сама метафора подтверждает мысль, что придется конкурировать с ИИ на уровне кода, но не архитектуры. 1. Математик не конкурирует с калькулятором, просто потому что математик - это скорее архитектор, а не кодер. Он работает с теоремами, абстракциями, доказательствами, а не считает, что-то на калькуляторе. 2. Была такая профессия "вычислитель", вот у этих ребят как раз возникли проблемы с появлением вычислительной техники, им пришлось конкурировать со способностью быстро и точно считать, и по итогу победили машины. Любые метафоры неточны, важно понимать, что конкуренция возникает когда возникают общие функции, у хороших инженеров много функций, которые не пересекаются с ИИ, а вот у чисто кодеров пересечений много.

На мой взгляд видео уже устарело. Могу согласиться, что большинство моделей не могут в хорошую архитектуру. Но стоит попробовать новейшие модели - GLM-5.2 или топовые Клода, как понимаешь, что архитектуру он делает лучше, чем большинство разработчиков.

Это очень опасное заблуждение, которое возникает из-за того, что на уровне кода (одного приложения) ИИ может выдавать результат, который работатет (проходит тесты). Архитектура системы - это другой разговор. Первое: архитектура оценивается не в моменте, а на дистанции. Хорошая архитектура позволяет сопровождать и развивать систему в течение длительного времени. Проблема в том, что даже самые сильные ИИ-модели принимают решения, которые накапливают техдолг - неверные границы доменов, жесткое зацепление, слабая связность, дублирования и т.д. На дистанции 2–3 месяцев (без человеческих корректировок) внесение изменений в проект порождает эффект домино и кучу побочек. ИИ не "видит", какие части системы меняются синхронно, какие требуют унификации в виде общих интерфейсов и абстракций, часто LLM создаёт распределённый монолит, вместо микросервисов и т.д. Второй момент — есть разница между архитектурой приложения (архитектура на уровне кода) и системной архитектурой. По приложению довольно много типовых схем, которые ИИ может воспроизвести и под контролем человека даже более-менее сопровождать. Системная архитектура - это всегда компромисс между стоимостью, рисками и конкретными ограничениями: бюджетом инфраструктуры, легаси, требованиями регуляторов, реальной командой, которая будет это развивать. ИИ выдаёт архитектуру которая не учитывает нюансов, эта архитектура некая средняя температура по полате, которая получиалась из кучи схем, используемых в обучении, В результате решения не соответствуют конкретной ситуации и не решают проблем системы.

Сейчас куча проблем наложились друг на друга и получился глобальный кризис в АйТи - с одной стороны поджимает ИИ, который забирает часть привычной работы, с другой кризис найма. Вопрос "Что делать и как быть?" волнует многих, поэтому я решил выпустить видео, которое подсвечивает возможности, которые можно использовать, чтобы в будущем не остаться без работы. Ожидаемо, что несмотря на то, что в видео я постарался разложить все четко, многие находятся в глубоком заблуждении, что ИИ - это волшебная таблетка, которая может решить все проблемы разработки. На самом деле это не так, есть задачи, которые ИИ может решать, есть те, которые не может. Что за задачи смотрите в видео. P.S. ниже скину разбор типовых возражений, которые разобрал в клубе SOERDEV. YouTube | VK | RuTube

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

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

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