Соер.Клуб

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

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

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

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

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

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

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

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

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

Есть один момент, который, кажется, неправильно воспринимают. Если у вас есть идея, что "я сейчас научусь промптить и вайбкодить, а бизнес снова меня наймет", то это очень сомнительный вариант. Бизнесу не нужны вайбкодеры, можете послушать Корпатого, он прямо говорит, что будущее за системами, которые будут сами создавать проекты, а работа человека будет заключаться только в построении архитектуры этих систем. Причем не факт, что эти системы будут создавать код, вполне могут быть иные промежуточные представления, для решения поставленных задач.Кажется, что это далекое будущее, но если посмореть на скорость последних лет, то это горизонт 2-3 лет.Проще говоря, если вы планируете работать в АйТи, то забудьте о том, что вы найдете какой-то новый хитрый способ перекладывать код, полученный от LLM, в рабочую систему. Все простые задачи будет делать LLM, человеку останутся только сложные высокоуровневые вещи.

Вот я постоянно рекламирую наше сообщество "наш клуб дает то", "наш клуб делает это", а чем он так хорошо этот "наш клуб"?Для меня это вопрос ответ на который дает мотивацию и силы для дальнейшего движения вперед. Ну правда, клуб ради чего? Чтобы денег заработать? Какой-то сомнительный стимул, есть другие способы заработать, реализовать которые проще (например, консультации).Мне важно показать как я вижу мир разработки, продвинуть свою "вселенную", если хотите. Мне интересно заниматься клубом потому что он приносит нематериальные результаты - клуб как работающая система, помогающая развиваться его участникам. Очень кайфово видеть результаты и отзывы на проделанную работу. Обычный подход в подобного рода объединениях - это обучение. Сделал курс, собрал людей, курс закончился и все. Мне же нравится идея "совместного развития", т.е. клуб для меня - способ найти единомышленников и развиваться с ним вместе. Мы уходим от идеи "обучения" к идеи "просветительской деятельности" (это в законе такой термин, так что извиняйте, если сильно пафосно звучит). Постоянный обмен опытом не по принципу "я даю тебе знания", а по принципу "разбираемся с тем, что можно использовать на практике и делимся опытом".Поэтому для меня клуб - это достойное продолжение канала SOER + попытка собрать все в работающую систему, которая помогает участникам развиваться, а не просто накапливать знания.

Чтобы советы не звучали абстрактно, расскажу, как мы строим работу в нашем клубе. Год назад мы запустили три курса — монолиты, сервисы и микросервисы. Это три кита любой современной архитектуры, поэтому сосредоточились на них. В рамках курсов рассматриваем архитектурные подходы: принципы построения софта в современных реалиях, коммуникацию и декомпозицию. Для закрепления теории проводим регулярные семинары, где учимся выражать мысли, критикуем решения друг друга, формируем инженерную базу. Практическая часть каждого курса — мини-проект. Практика помогает прояснить проблемные места в теории, подсвечивает ошибки и способы их устранения.Если честно, мне кажется, что индивидуально такой объем сегодня не потянуть. При современных скоростях обмен опытом — самый лучший способ развития. Главное — искать людей, которые реально разбираются в теме и могут помочь.После архитектуры перейдем к ИИ-инжинирингу. Следующий курс планирую сделать по оркестрируемым агентским системам с детерминированными валидаторами и явными контрактами между агентами. В итоге получится инженерный минимум по тому, как строить софт в мире, где LLM пишет код, а человек проектирует систему. Мне кажется, что в будущем функция человека будет сводиться не столько к «контролю» того, что делает LLM, сколько к построению процессов и архитектуры разработки. Поэтому ИИ-инженерия — очень перспективная вещь.Стратегия ближайших лет: кодинг как основная специализация не спасёт от ИИ-агентов. Архитектура, работа с требованиями и умение проектировать систему — вот наша новая «валюта».

У многих разработчиков появилось беспокойство за свое будущее. Это связано с тем, что сейчас люди выполняют роль конвейера между LLM и реальным проектом. Типичный цикл: получил таск, скопировал в LLM, результат скопировал в проект. Закономерно, что ценности в таком труде нет, и бизнес хочет автоматизировать эти процессы, передав «перекладывание кода» ИИ-агентам.Бизнесу интересно нанимать людей для задач, которые ИИ пока не решает. В ближайшем будущем такие задачи будут связаны не со способностью генерировать код (LLM неплохо справляется с изолированными фрагментами уже сейчас), а с умением анализировать и понимать проект, корректно выполнять декомпозицию, разбивать задачи для ИИ, владеть технологическим стеком, работать с инфраструктурой и проводить границы между компонентами. Это коротко называют «инженерный стек».Отсюда появился термин «ИИ-инжиниринг» — направление, в рамках которого инженеры-программисты ведут разработку проекта, используя LLM и агентские системы. Процессы автоматизируются с помощью оркестрируемых агентов, а люди выполняют роль валидаторов результатов и аналитиков требований.Разрыв между навыками написания кода и полноценными инженерными навыками оказался огромным. Проблема даже не в знаниях, которые нужны для ИИ-инжиниринга, а в неумении декомпозировать задачу до уровня, где LLM не теряет контекст, составлять проверяемые требования, исключать противоречия. Сложно менять привычки, уходить от I-shape подходов, перестать ждать от LLM архитектурных решений.Так как наш клуб изначально заточен на инженерный стек, нам немного проще объяснить и помочь разработчикам скорректировать навыки.Что нужно делать:1. Нарабатывать архитектурные паттерны — то есть видеть задачу с позиции требований, разделения ответственности и проведения границ, определять способы коммуникации между компонентами, убирать зацепление и увеличивать когезию. Есть много книг на эту тему, но главное — практика. Набивая шишки на проектах, созданных с помощью LLM, и продумывая архитектуру

Инженеры которых мы заслужили:Масштабирование как процесс включает в себя процесс деплояНавсякий случай напомню, что согласно Вики: "Software deployment is all of the activities that make a software system available for use"

Удивляет, что многие воспринимают ИИ как конкурента и потенциальную угрозу для своего трудоустройства.На мой взгляд ИИ наоборот — огромное окно возможностей, которое возвращает нас во времена, когда можно было в соло создавать крутые проекты.Если у вас есть пара друзей и свободный гараж, то сегодня вы снова можете создавать продукты, о которых заговорит весь мир. И это не преувеличение. Например, самый «звёздный» репозиторий на GitHub — OpenClaw, его создал один человек и получил огромный успех. Ещё пример — Hermes, который создан Nous Research, которая в свою очередь началась с небольшой группы энтузиастов в онлайн-дискорд-сообществе.Да, ИИ скорее всего изменит фронтенд как самостоятельную отрасль и заставит фронтендеров уходить в «fullstack разработчиков» или даже в «инженеров-разработчиков». Но это та цена, которую придётся заплатить за новые задачи — непаханые поля для новых решений.Особо я благодарен ИИ за то, что он вдохнул жизнь в робототехнику. Думаю, скоро мы увидим огромное количество стартапов, которые будут менять нашу реальную, а не виртуальную жизнь.Так что одна дверь закрылась, но взамен открылась тысяча других