Соер.Клуб

С недавних пор мода на создание сообществ дополнилась желанием непременно делать свой продукт, сейчас приложения растут как грибы после дождя - создаются свои LMS, лендинги, приложения для проведения мок-собеседований, даже информационные ленты и блоги снова набирают обороты. Все потому что создавать приложения стало "дешево". Я уверен, что большая часть новых решений почти полностью созданы ИИ. Все что нужно - один вечер и десяток другой промптов с уточнениями и исправлениями. Но если на старте творить с помощью LLM весело и задорно, то со временем наступает проблема, о которой я рассказывал на последней встрече клуба - инкрементальные обновления накапливают ошибку. В итоге LLM делает улучшение в одном месте, и забывает сделать правки везде, где нужно, в результате старые сценарии отваливаются. Раньше как было? Есть несколько популярных OpenSource решений, есть авторы этих решений, есть комьюнити, все вместе устраняют баги, выпускают новые версии, чтобы в конечном итоге мы с вами могли поставить готовый софт себе на проект и не ломать голову над проблемами и ошибками. Нет, конечно, запрошенных проектов на GitHub всегда хватало, но они часто не доживали до стадии MVP и поэтому были не так заметны. Думаю, что эйфория закончится быстро, постепенно созданные приложения (которые теперь многие именуют не иначе как "свой бизнес") перестанут обновляться, развиваться и постепенно сойдут на нет. В итоге останутся единицы, которые будут действительно нести пользу и предлагать что-то уникальное, в первую очередь за счет содержания, а не формы. Потому что форму теперь за копейки скопирует любой, а уникальный опыт, знания или экспертизу - нет.

Сейчас многие переживают, что если остаться в разработке, то через некоторое время можно остаться совсем без работы, поэтому рассматривают два варианта. Первый: сидеть в инженерии, но уже не как программист, а как человек, который использует ИИ как инструмент. Второй: двинуться в сторону от программирования. Сейчас очень популярна идея массово переходить в аналитику. Потому что "не надо так много кодить", "там проще", "можно быстро вкатиться". Между тем, аналитика - это область в которой ясности еще меньше, чем в разработке. На входе гора данных, половина из которых - мусор, который никак не влияет на результат. По этим данным бизнес ожидает конкретный ответ на свои вопросы (желательно еще вчера), а не абстрактное "наверное сезонность". Нужно иметь профессиональную интуицию и аналитический склад ума, чтобы генерировать качественные гипотезы, искать закономерности, находить решение для поставленных задач. И если ты ошибся - ответственность на тебе, тут не получится выехать на "программирование - это сложно, баги неизбежны". В конечном итоге хороший аналитик - это точно такая же редкость, как хороший инженер, а плохие аналитики никому не нужны. Так что не надо бежать туда, потому что "а куда еще?". Легче не станет. Просто сложность будет другой. Если нет любви именно к анализу данных, то разбираться в сомнительных данных, выяснять, почему одна цифра не бьется с другой, и объяснять менеджерам, что два плюс два не всегда четыре - это прямой путь к выгоранию. На мой взгляд куда лучше остаться в разработке и сместиться в архитектуру. Это понятный и рабочий вариант, который является логичным продолжением развития для разработчика.

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

❗️ Встреча клуба. Напоминаю, что у нас в 10:00 по Москве состоится он-лайн встреча, подключиться можно по ссылке. Для доступа нужна подписка №2 или №3.

Современный кризис в IT вынуждает разработчиков быстро адаптироваться к двум вещам: изменению процессов и изменению технологий. Появление нового тренда очевидно, но важно не только его заметить, но и понять, насколько он зрелый. Зайти слишком рано - так же опасно, как и слишком поздно. Есть две фундаментальные работы, которые помогают правильно принять решение: модель Роджерса, которая описывает развитие инноваций в обществе, и книга Crossing the Chasm Джеффри Мура, которая показывает, что в модели Роджерса есть проблемное место. Коротко. Роджерс делит общество на пять групп: 2,5% новаторов, которые пишут на языке без документации и чьи эксперименты на 90% умрут; 13,5% ранние последователи - готовы рисковать и терпеть сырой продукт; 34% раннее большинство - заходят, когда технология созрела, им нужны гарантии и референсы; оставшиеся 50% - позднее большинство, которые учат технологию, когда деваться уже некуда. Проблема в том, что между ранними последователями и ранним большинством есть разрыв (пропасть). Эти группы по-разному относятся к комфорту: первые готовы сами решать проблемы и внедрять сырые решения, вторые хотят гарантий. Мур говорит о том, что ранние последователи и раннее большинство мыслят по-разному. Первым интересна сама возможность сделать то, что раньше было нельзя. Вторым нужно, чтобы всё работало предсказуемо и с понятным результатом. Это и есть "пропасть": продукт уже есть, энтузиасты его активно используют, а обычный рынок ещё не готов, потому что нет ни нормальной документации, ни поддержки, ни опыта внедрения. Чтобы этот разрыв преодолеть, надо перестать продавать идею и начать продавать готовый инструмент под конкретную задачу. Таким образом, основная проблема не в том, чтобы найти новый тренд, а в том, чтобы оценить его зрелость. И в этом смысле внедрение ИИ как раз находится на стадии преодоления пропасти по Муру. Мы ещё не имеем готовых решений, проверенных временем и способных гарантированно давать результат, но уже прошли стадию чистого хайпа. Поэтому сейчас тот самый момент, когда пора. Как говорится, "ошибка джуна - учить когда рано, ошибка сеньора - учить когда поздно". Соеры не совершают ошибок, поэтому учат когда нужно.

При обсуждении достоинств микросервисной архитектуры часто упускают важный момент - локальная разработка микросервисов в разы сложнее, чем работа над монолитом, поэтому требует грамотных решений буквально на самом старте. Полностью избежать зависимости сервисов невозможно, поэтому для разработки и сопровождения требуется общая инфраструктура и унификация. У локальной разработки микросервисов есть три основные проблемы, которые должны быть решены: - Окружение должно помещаться в ресурсы ноутбука разработчика; - Зависимости между сервисами не должны блокировать работу над конкретной задачей; - Конфигурация окружения должна быть единой для всей команды и воспроизводимой. На семинаре по микросервисной архитектуре мы с ребятами поделились опытом как выстраивается работа по разработке сервисов, я взял основные моменты и свел в статью (нужна Подписка №1 или выше).

👥Круглый стол в субботу 27.06.2026 10:00 В эту субботу пройдет онлайн встреча клуба на которой обменяемся опытом по использованию ИИ в работе. 🔴Кто может принять участие? Все участники клуба с подпиской №2 и №3 🔴Какие темы рассмотрим - проблемы, возникающие в коде, сгенерированном ИИ - мой опыт замены сота моделей от Антропика на китайские LLM - помогает ли оркестрация или агенты вполне норм - секция вопросов и ответов 🔴Формат встречи - Созвон в Yandex Telemost (ссылка появится на soerdev.space) - Мой небольшой доклад (20-30 минут) - Круглый стол (или вопрос/ответ) Запись доклада позже появится в записи, но часть с обсуждением будет только на самой встречи.

Дублирование на уровне кода - один из основных источников технического долга. Говоришь себе "ну сейчас быстро сделаю копи-паст, а потом на этапе рефакторинга раскидаю как надо". Обычно этап рефакторинга так и не наступает, поэтому в коде остается несколько источников правды, которые в будущем создают проблемы. Хуже всего то, что спустя время ты успешно забываешь, какие правки нужно было сделать, дополнительно успеваешь накидать на старый код еще пяток другой патчей, которые усложняют рефакторинг и тем самым закрепляют плохие практики, превращая кодовую базу в дремучее легаси. Легаси неизбежно, поэтому хорошего кода в мире очень мало, а плохого сколько угодно много. Получается, что с большой вероятностью код, который был использован при обучении LLM, был не самого лучшего качества, а значит, это мы с вами, ленясь выполнять своевременный рефакторинг, научили ИИ "плохому". Может быть, это и к лучшему, потому что мы с вами еще можем научиться красиво и грамотно писать код, проектировать и продумывать наши системы, а ИИ будет продолжать плодить легаси. Воистину, лень оказалась лучшей инвестицией, которая поможет нам конкурировать с ИИ.

Что-то у меня накопилось куча примеров того как ИИ не вывез поставленную перед ним задачу или вывез, но совсем не так, как ожидалось. Думаю, таких примеров накопилось не только у меня и будет интересно сделать видео на эту тему. Это поможет снять напряжение и немного успокоить тех, кто сильно переживает на тему "нас всех заменит". Так что если у тебя есть история, то пиши в комментарии или в личку на @soerdev. Надеюсь на твою активность!

Бриф Ну что, господа соеры, время летит быстро, мы за последние месяцы продуктивно поработали и прокачались по теме микросервисов. В этом посте расскажу какие материалы пополнили нашу платформу soerdev.space Без подписки (публичные материалы) Карты знаний: - Промпт инженерия Материалы по подписке Подписка №1 Для тех кто хочет подтянуть теорию, подготовили целый набор толковых видео, которые закрывают значительную часть "базы" по Микросервисной архитектуре: - Введение в микросервисы - Документирование в рамках микросервисного подхода - API дизайн - Основы коммуникации микросервисов - API-шлюз - Управление данными - Контейнеризация - Оркестрация микросервисов - Наблюдаемость (Observability) Так же не забыли про старые стримы, которые перенесли на новую платформу в фокусе Чистая архитектура: - Введение в чистую архитектуру - Основные строительные элементы "Чистой архитектуры" - Архитектурные границы приложения - Границы и зависимости на уровне кода - Инверсия управления и инверсия зависимостей Подписка №2: Для тех кто хочет к теории добавить практику пробуйте делать задания из мастер-классов по микросервисной архитектуре: - Event storming - Создание репозитория для микросервиса - Создание OpenApi спецификации - Проектирование взаимодействия сервисов - Настройка API-gateway - Проектирование данных - Настройка контейнера - Настройка MicroK8S - Настройка Grafana для микросервисов Подписка №3

Часто просят публиковать не только видео, но и те конспекты, которые я показываю в качестве презентации, это бывает удобно, чтобы вспомнить основные моменты..

• Введение в микросервисы • Документирование в рамках микросервисного подхода • API дизайн • Основы коммуникации микросервисов • API-шлюз • Управление данными • Оркестрация микросервисов p.s. по каждой теме у нас был созвон где мы подробно все разобрали и обсудили вопросы. Так что мы не просто поверхностно прошли этот материал, а отлично проработали нюансы. Следующий вызов "Агентные оркестрируемые системы", где будем разбираться как устроены оркестраторы. Стартуем примерно в сентябре. Напоминаю, что места на подписке №3 ограничены, так что думайте заранее.

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

Все было хорошо и тут сокращение... Не хочется давить на больную мозоль, но игнорировать реалии рынка - уже просто опасно. Люди до сих пор не могут понять, что единственная страховка от увольнения - это умение решать необходимые бизнесу задачи. И почти все эти задачи лежат в области практического опыта. Нюанс в том, что сегодня из-за ИИ происходит переосмысление тех требований, которые предъявляются к кандидатам. Поэтому ориентироваться на свой старый надежный стек - это большой риск. Если хочешь работать в айти, нужно привыкать к мысли, что постоянно придется учиться новому и быть готовым поменять свой рабочий стек. Миф, что менять стек "это очень сложно" - это отговорка, соеры постоянно меняют стек и в среднем делают это за 6-12 месяцев. И пока ничего более эффективного для сохранения позиции на рынке придумать не получается.

И да, я не шучу когда говорю "приходите и посмотрите как мы работаем". Во-первых, мы открыты к крититке, если она конструктивная, конечно же, а во-вторых я знаю что предлагают мои оппоненты и это дает мне понимание насколько уникален наш клуб. Так что если вы мидийное лицо, и обязуетесь дать честный отзыв на нашу работу, то просто свяжитесь со мной и договоримся о приглашении на нашу встречу. Как прошла встреча в прошлый раз, можно посмотреть тут.

Наш курс по микросервисам выходит на финишную прямую. Мы с ребятами много сил и внимания уделили этапу проектирования и командной работе. Наверное, было бы проще каждому участнику дать небольшое задание, которое он выполнил бы в соло, но тогда весь смысл микросервисов теряется. Если вы изучаете микросервисы, то обязаны делать это в команде, так как основная причина внедрения этого паттерна - масштабирование команды. В противном случае вы быстро начнете находить признаки распределенного монолита в своем коде. В процессе обсуждения дошли до обзора ADR, и тут выяснилось, что мы как-то пропустили тему про то, как отличить хорошие ADR от плохих и почему LLM-ки тут не помогут. В рамках курса эту тему рассматривать не будем. Вместо этого будет мастер-класс для всех участников с подпиской №2. О дате мастер-класса сообщу позже, пока планирую провести его в середине июля. Периодически задают вопрос: «Ну что есть такого в вашем клубе, что я сам за пару вечеров не выучу?» Вот такие моменты, которые я только что описал, выучить нельзя. Я считаю, что сильное окружение - лучший способ получить опыт и эффективно прокачаться, видел много разных предложений на рынке, но такого формата как у нас (работа в группе максимально приближенно к реальному проектированию) не встречал. Сегодня на рынке без хороших технических знаний делать нечего, убеждаюсь в этом все больше.

Отказываюсь от использования Claude и вот почему. Anthropic делает одни из лучших моделей — это факт. Я в полном восторге от Opus 4.7, новая модель Opus 4.8 на проверочных задачах выглядит ещё лучше. И казалось бы, нужно пользоваться лучшим инструментом, чтобы получать лучший результат. Но нет, на практике всё упирается в «цена/качество». И здесь выясняется самое неприятное: Opus отлично справляется с простыми задачами по разработке, но на сложных задачах его мощности не хватает. Я делаю несколько пет-проектов, которые полностью разрабатывает ИИ, показательны два примера: 1. Простой сайт (soerdev.space) с типовыми веб-элементами, Angular и разделением на модули. Claude разрабатывает модули и делает это на изи. На выходе вполне читаемый код, но требует отдельно создавать модули и отдельно их интегрировать в проект. 2. Самописный оркестратор для команды агентов. Здесь Клод отвечал не только за код, но и за архитектуру проекта (было всего три версии, которые полностью писал ИИ и пробовал реализовать). Итог плачевный — первый месяц активно набираем фичи, обсуждаем, планируем, кажется, что всё хорошо, затем технический долг начинает поджимать, регулярный рефакторинг не спасает и начинаем работать только на устранение тех. долга, при этом приходится самому лезть в код, чтобы понять, в чём проблема. В какой-то момент принимаешь решение: «Стоп! Хватит!», делаем новую версию и учитываем все проблемы в планировании и описании архитектуры. В итоге описание с каждой версией всё лучше, а проект всё так же затыкается через 1–2 месяца разработки. Сначала я списывал неудачи второго варианта на неправильный подход, но после третьей попытки решил отказаться от идеи «ИИ на всех этапах работы». Проблема в том, что ИИ постоянно пытается решить задачу кратчайшим путём, игнорируя абстракции и ограничения. В итоге спустя месяц ты лезешь в код и удивляешься: «Да зачем ты это сюда засунул?». Начинаешь анализировать и видишь, что в проекте есть куча частных решений, нет чётких интерфейсов и непонятно, как это вообще работает. Если ткнуть ИИ в конкретные АДР, то он видит, понимает и даже говорит «сейчас всё исправлю», а в итоге становится только хуже. Последний вариант оркестратора я собрал на своей архитектуре, которую разработал сам (включая структуру проекта). ИИ делает только конкретные небольшие модули, для которых уже созданы и описаны интерфейсы, прописаны ограничения, есть АДР и т.д. Клод справляется с этим на ура... Есть только одно «но» — китайские модели — MiniMax, Kimi, GLM тоже выдают при таком подходе нормальный результат. Сейчас Anthropic в своего «сжигателя токенов» (Claude Code) добавил динамический воркфлоу, который сделал процесс уничтожения токенов ещё быстрее, но описанные выше проблемы это не решает (возможно, если лимиты будут в 100 раз больше, то ситуация исправится, но у меня нет таких денег). Сейчас за пару минут (и это не преувеличение) можно спалить все лимиты подписки и никуда не сдвинуться (вспоминается Алиса: нужно быстро бежать, чтобы просто оставаться на месте). Поэтому я решил переехать на китайские модели + свой оркестратор. Функции оркестратора: подбор LLM, использование ролей (определяет скилы и инструменты), запуск агентов, использование пайплайнов. Результат устраивает более чем: адекватная цена и нормальный результат, без «сюрпризов» в виде скрытого тех. долга. Проблема одна: требует внешнего наблюдателя и продуманной архитектуры, но это и с Клодом так, так что выбора особо нет.

Уооо Горбушка, стоит на месте, всё нормульдик Скоро снова будем тут диски/флешки покупать, будет снова тут центр цифровой движухи, как в 90х-нулевых Накопители с незапиканной музыкой, незаблюренными сериальчиками, с дистрибутивами винды, весами LLM и новыми пакетами с гитхаб «Лучшие Python и Nodejs библиотеки 2026» «Полный набор ИИ май 2026» «Брейкинг Бэд в переводе Гоблина все сезоны» «Гуф золотые шлягеры» Хорошо так, тепло:)

Какая же жизаааа 👇👇👇

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

По пабликам гуляет новость, что Mythos нашел за месяц более 10к багов. Нюанс в том, что новостей о таком же количестве багфиксов от ИИ как-то не наблюдается. Проблема в том, что искать баги - это одно, а исправлять их - совсем другое. Казалось бы, что мешает тому же Mythos направить MR в открыте проекты и помочь закрыть проблемы? Ответ простой: ИИ этого пока не может. Сам поиск анамалий - это довольно простой процесс, если сравнивать его с процессами разработки, сопровождения и развертывания. Допустим нашел баг? Теперь нужно найти причину, выработать решение, унифицировать решение, проверить на соответствие требованиям и ограничениям, провести тестирование, выпустить релиз. Получается, что без инженеров опять никуда, даже самые мощны модели пока не способны рулить процессами (по необходимости создавая их на лету), чтобы быстро устранять баги. Известная проблема "щита и меча", меч сейчас сильно опережает щит, так что, господа инженеры, у вас, кажется, намечается много работы.

Попросил клода посмотреть на мой сайт soerdev.space глазами дизайнера, он сказал, что использовать темную тему для чтения текстов - издевательство над пользователями и переделал все нафиг. А потом я посмотрел на все это дело и заодно попросил его докрутить отображение memrmaidjs диаграмм, перекроить кое-какие блоки. И знаете, что? Мне понравилось как получилось!