S0ER - архитектура и кодинг

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

Сделал видео по созданию промптов, идея была в том, чтобы рассмотреть разные варианты текстов и выделить общие правила, которые опубликовать на 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

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

Многие написали про большое исследование Anthropic, где лейтмотивом прошла мысль, что существующие возможности ИИ сильно превышают реальное использование. Для программистов предел возможностей находится на уровне 75%. По идее это говорит о том, что программисты наиболее подвержены замене (причем это один из самых высоких показателей), но на практике резкой замены не происходит. На изображении красным помечено насколько используется ИИ в реальных задачах, а синим - это возможный максимум. Возникает вопрос: Почему такой разрыв? 1. Вопрос ответственности. LLM регулярно делают вещи, которые могут привести к серьезным последствиям. Например, недавно писал как ИИ выложил приватные ключи доступа в репозиторий, слава богу это была тестовая песочница, а не реальный проект. Для реального бизнеса в первую очередь нужна оценка рисков и минимизация их последствий, без этого ни один серьезный бизнес кардиальных изменений в рабочих процессах делать не будет. Реалии состоят в том, сегодня нет способа существенно снизить риски использования ИИ, а значит без человека не обойтись. 2. Вопрос контроля Из-за необходимости постоянного контроля возникает паттерн Human in the loop. Поэтому человек по-прежнему нужен и важен практически во всех процессах, в том числе и разработке. 3. Юридические неопределенности. Пока законодательство не особо регулирует сферу ИИ, но, например, недавно в РФ появилась инициатива обязать компании предоставлять пользователю возможность отключить ИИ и работать с человеком, что существенно ограничивает возможность использования ИИ. 4. Недостаток инструментов и технологий. У ИИ есть только возможность принимать решения, но для полноценного цикла этого мало, кроме этого как минимум нужна "Память" и "Контекст" и базовое критическое мышление, чтобы не допускать совсем уж тупых промахов. Поэтому развитие ИИ в ближайшее время будет идти по пути усовершенствования инструментов и законодательства, а о массовой замене программистов пока речи не идет. Что реально может измениться для нас? Так как человек в цикле разработки с помощью ИИ - обязательное звено, то для нас изменятся инструменты, могут измениться обязанности, от нас будут требовать понимаени работы ИИ и архитектуры. Т.е. фокус внимания сместится с уровня кода, на уровень системного дизайна, валидацию решений принятых ИИ и тому подобных вещей. Отсюда неплохо прокачать свои знания по озвученным вопросам, это позволит не только конкурировать с ИИ, но в первую очередь с другими людьми!

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