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

Уооо Горбушка, стоит на месте, всё нормульдик

Скоро снова будем тут диски/флешки покупать, будет снова тут центр цифровой движухи, как в 90х-нулевых

Накопители с незапиканной музыкой, незаблюренными сериальчиками, с дистрибутивами винды, весами LLM и новыми пакетами с гитхаб

«Лучшие Python и Nodejs библиотеки 2026»
«Полный набор ИИ май 2026»
«Брейкинг Бэд в переводе Гоблина все сезоны»
«Гуф золотые шлягеры»

Хорошо так, тепло:)

Отказываюсь от использования 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, использование ролей (определяет скилы и инструменты), запуск агентов, использование пайплайнов.

Результат устраивает более чем: адекватная цена и нормальный результат, без «сюрпризов» в виде скрытого тех. долга. Проблема одна: требует внешнего наблюдателя и продуманной архитектуры, но это и с Клодом так, выбора особо нет.

Наш курс по микросервисам выходит на финишную прямую. Мы с ребятами много сил и внимания уделили этапу проектирования и командной работе.

Наверное, было бы проще каждому участнику дать небольшое задание, которое он выполнил бы в соло, но тогда весь смысл микросервисов теряется. Если вы изучаете микросервисы, то обязаны делать это в команде, так как основная причина внедрения этого паттерна - масштабирование команды. В противном случае вы быстро начнете находить признаки распределенного монолита в своем коде.

В процессе обсуждения дошли до обзора ADR, и тут выяснилось, что мы как-то пропустили тему про то, как отличить хорошие ADR от плохих и почему LLM-ки тут не помогут.

В рамках курса эту тему рассматривать не будем. Вместо этого будет мастер-класс для всех участников с подпиской №2. О дате мастер-класса сообщу позже, пока планирую провести его в середине июля.

Периодически задают вопрос: «Ну что есть такого в вашем клубе, что я сам за пару вечеров не выучу?»

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

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

Так что если вы медийное лицо, и обязуетесь дать честный отзыв на нашу работу, то просто свяжитесь со мной и договоримся о приглашении на наши созвоны.

Как прошла встреча в прошлый раз, можно посмотреть тут.

Все было хорошо и тут сокращение...

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

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

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

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

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

Бриф

Ну что, господа соеры, время летит быстро, мы за последние месяцы продуктивно поработали и прокачались по теме микросервисов. В этом посте расскажу какие материалы пополнили нашу платформу soerdev.space

Без подписки (публичные материалы)

Карты знаний:
- Промпт инженерия


Материалы по подписке

Подписка №1

Для тех кто хочет подтянуть теорию, подготовили целый набор толковых видео, которые закрывают значительную часть "базы" по Микросервисной архитектуре:

- Введение в микросервисы
- Документирование в рамках микросервисного подхода
- API дизайн
- Основы коммуникации микросервисов
- API-шлюз
- Управление данными
- Контейнеризация
- Оркестрация микросервисов
- Наблюдаемость (Observability)

Так же не забыли про старые стримы, которые перенесли на новую платформу в фокусе Чистая архитектура:

- Введение в чистую архитектуру
- Основные строительные элементы "Чистой архитектуры"
- Архитектурные границы приложения
- Границы и зависимости на уровне кода
- Инверсия управления и инверсия зависимостей

Подписка №2:

Для тех кто хочет к теории добавить практику пробуйте делать задания из мастер-классов по микросервисной архитектуре:

- Event storming
- Создание репозитория для микросервиса
- Создание OpenApi спецификации
- Проектирование взаимодействия сервисов
- Настройка API-gateway
- Проектирование данных
- Настройка контейнера
- Настройка MicroK8S
- Настройка Grafana для микросервисов

Подписка №3

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

• Введение в микросервисы
• Документирование в рамках микросервисного подхода
• API дизайн
• Основы коммуникации микросервисов
• API-шлюз
• Управление данными
• Оркестрация микросервисов


p.s. по каждой теме у нас был созвон где мы подробно все разобрали и обсудили вопросы. Так что мы не просто поверхностно прошли этот материал, а отлично проработали нюансы.

Следующий вызов "Агентные оркестрируемые системы", где будем разбираться как устроены оркестраторы. Стартуем примерно в сентябре. Напоминаю, что места на подписке №3 ограничены, так что думайте заранее.

Что-то у меня накопилась куча примеров того как ИИ не вывез поставленную перед ним задачу или вывез, но совсем не так, как ожидалось.

Думаю, таких примеров накопилось не только у меня и будет интересно сделать видео на канале по этому вопросу. Это поможет снять напряжение и немного успокоить тех, кто сильно переживает на тему "нас всех заменят".

Так что если у тебя есть история, то пиши в комментарии или в личку на @soerdev.

Надеюсь на твою активность!

Дублирование на уровне кода - один из основных источников технического долга. Говоришь себе "ну сейчас быстро сделаю копи-паст, а потом на этапе рефакторинга раскидаю как надо".

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

Хуже всего то, что спустя время ты успешно забываешь, какие правки нужно было сделать, дополнительно успеваешь накидать на старый код еще пяток другой патчей, которые усложняют рефакторинг и тем самым закрепляют плохие практики, превращая кодовую базу в дремучее легаси.

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

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

Воистину, лень оказалась лучшей инвестицией, которая поможет нам конкурировать с ИИ.

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

Полностью избежать зависимости сервисов невозможно, поэтому для разработки и сопровождения требуется общая инфраструктура и унификация.

У локальной разработки микросервисов есть три основные проблемы, которые должны быть решены:

- Окружение должно помещаться в ресурсы ноутбука разработчика;

- Зависимости между сервисами не должны блокировать работу над конкретной задачей;

- Конфигурация окружения должна быть единой для всей команды и воспроизводимой.

На семинаре по микросервисной архитектуре мы с ребятами поделились опытом как выстраивается работа по разработке сервисов, я взял основные моменты и свел в статью (нужна Подписка №1 или выше).

❗️ Встреча клуба.

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

Одно из основных достоинств нашего клуба - регулярные онлайн встречи на которых мы обмениваемся опытом или разбираем практические вопросы.

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

Сейчас очень много историй успеха в которых LLM пишет небольшие приложения. Но очень мало информации о том как грамотно внедрить ИИ в цикл разработки реального приложения (SDLC).

На встрече я рассказал о результатах использования ИИ в собственных проектах, поделился проблемами, которые очень сильно мешают. Это и излишняя генерация кода, когда вместо использования библиотечных решений LLM делает собственные велосипеды с кучей лишних деталей, плодит новые абстракции, содает дублирование и т.д. И проблема - "провалов" инкрементальных улучшений, когда модель должна дополнить проект новой фичей не нарушив имеющиеся инварианты и соглашения. И проблемы "фронтир" моделей. И многие другие вопросы.

В общем, вопросов много, а ответов почти нет, поэтому если тебе надоело слушать восторженные отзывы "как хорошо жить с ИИ" и хочется послушать, что на реальной практике, то вот запись с нашей встречи, где содержится моя часть доклада (нужна подписка №2).

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

Первый: сидеть в инженерии, но уже не как программист, а как человек, который использует ИИ как инструмент.

Второй: двинуться в сторону от программирования. Сейчас очень популярна идея массово переходить в аналитику. Потому что "не надо так много кодить", "там проще", "можно быстро вкатиться".

Между тем, аналитика - это область в которой ясности еще меньше, чем в разработке. На входе гора данных, половина из которых - мусор, который никак не влияет на результат. По этим данным бизнес ожидает конкретный ответ на свои вопросы (желательно еще вчера), а не абстрактное "наверное сезонность".

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

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

С недавних пор мода на создание сообществ дополнилась желанием непременно делать свой продукт, сейчас приложения растут как грибы после дождя - создаются свои LMS, лендинги, приложения для проведения мок-собеседований, даже информационные ленты и блоги снова набирают обороты.

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

Но если на старте творить с помощью LLM весело и задорно, то со временем наступает проблема, о которой я рассказывал на последней встрече клуба - инкрементальные обновления накапливают ошибку. В итоге LLM делает улучшение в одном месте, и забывает сделать правки везде, где нужно, в результате старые сценарии отваливаются.

Раньше как было? Есть несколько популярных OpenSource решений, есть авторы этих решений, есть комьюнити, все вместе устраняют баги, выпускают новые версии, чтобы в конечном итоге мы с вами могли поставить готовый софт себе на проект и не ломать голову над проблемами и ошибками. Нет, конечно, запрошенных проектов на GitHub всегда хватало, но они часто не доживали до стадии MVP и поэтому были не так заметны.

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

Год назад я поставил себе масштабную цель - обобщить свой опыт построения сложных программных систем и выпустить три курса: монолиты, сервисы, микросервисы.

Какие у меня были цели?

Я сторонник идеи, что знания, которые мы приобретаем, должны приносить конкретные практические результаты. Лекции должны быть связаны с проектированием и написанием рабочих систем, которые затем разворачиваются на реальной инфраструктуре. Меньше персональных заданий, больше командной работы.

Чего добились?

Во-первых, научились проводить полноценные групповые семинары с интерактивным взаимодействием на большом white board.

Во-вторых, смогли собрать команду с разным уровнем и опытом, в результате обмен опытом шел не только между мной и ребятами, но и между друг другом.

В-третьих, от индивидуального формата перешли к командной работе, которая включает проектирование и реализацию проектов.

Если на монолитах каждый делал свой монорепозиторий со своим проектом, то на микросервисах уже совместный проект, где у каждого свой микросервис и общая инфраструктура (включая репозитории на gitlab).

Что это дало участникам?

- Опыт разработки проектов с документацией: требования, ограничения, пользовательские истории, ADR. Важно, что у нас документация стала частью процесса, а не отдельной задачей под конец.

- На практике попробовали разные варианты проектирования - C4, Event Storming, DDD и т.д. Обкатали каждый подход на реальных задачах, поняли, что применимо, а что нет.

- Научились проводить границы приложения, разделять обязанности. Много копий было сломано вокруг деления по зонам ответственности, и это тоже было очень полезно.

- Научились формулировать свои мысли, отстаивать и защищать своё решение. Я всегда фокусировал внимание на том, что нужно учиться объяснять, *почему* мы принимаем то или иное решение, а не просто отмахиваться общими фразами.

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

Какие планы на будущее?

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

Это, кстати, последний набор материалов в формате "курс", далее я хочу попробовать более легкий формат клубной работы - регулярные практические семинары, интенсивы и обмен опытом по небольшим темам. Чтобы не грузить людей объемом информации, а брать отдельные темы и рассматривать их в течение 3-4 недель, затем перерыв и новая тема (примеры тем: observability, создание своего VPC, работа с требованиями и ограничениями и т.д.). Таким образом подписка начнёт по-настоящему работать, позволяя двигаться к цели короткими шагами, без затяжных изматывающих курсов, но с хорошим ритмом "работа/отдых".

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

Так что спасибо всем участникам, продолжаем работу.