Посты канала Заканчиваем коллекцию по оркестрируемым агентным системам

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

Забавно, что люди спорят с тем, что мол творчество — это удел человека, бездушный нейрослоп не способен заменить «думающих» людей, а потом идут смотреть видео, построенные по типовому сценарию, с типовыми фактами, сопровождающиеся типовой инфографикой. Даже скилл, который может сделать такой сценарий, можно накидать за один промпт: «Создай скилл, который будет писать сценарии для видео на ютубе, возьми за основу следующую структуру: введение (5-10 секунд), отсылка к мировой статистике (Gartner, IDC, Forrester), приведи инфографику на 3-4 скрина, содержащую "график растущий вверх", "юзерпики" и стрелки между ними (30-40 секунд), затем сделай "живой пример" из новостей, где разбери один конкретный кейс (30 секунд), далее сделай предположение, основанное на статистике и обобщающий вывод (40 секунд)». Дополните этот скилл хорошим превью в стиле «ИХ точное не заменят» или «Те кто ВЫЖИВУТ в АйТи» и собирайте просмотры. Не благодарите.

Сегодня у бизнеса сильно изменилось представление о технически грамотном специалисте. Оно, кстати, изменилось не за один день: уже много лет специалист — это тот, кто «решает проблемы бизнеса», а не зубрит техничку до потери пульса. Но если раньше техничку всё же надо было закрывать и нужны были люди, то теперь техничку стали закрывать с помощью ИИ. Сейчас чтобы хорошо чувствовать на рынке нужно больше ориентироваться на более высокие "уровни абстракции", но так как обычно люди не понимают, что это за уровни, то вот конкретный список: ## Харды 1. Архитектурное проектирование и системное мышление 2. Ревью и верификация сгенерированного кода 3. Владение ИИ-инструментами с пониманием их ограничений 4. Отладка и диагностика кода, написанного не тобой 5. Комплаенс и безопасность на техническом уровне 6. Продуктово-техническая грамотность (метрики, unit-экономика) ## Софты 1. Декомпозиция размытых требований 2. Инженерное суждение (когда сказать «нет») 3. Коммуникация компромиссов бизнесу 4. Ответственность за результат (ownership) 5. Обучаемость и адаптивность 6. Кросс-функциональность и эмпатия

Почему из всех известных паттернов и принципов больше всего негатива достаётся бедному «SOLID»? Кажется, что уже и сам Дядюшка Боб сильно поменял свои взгляды на кодинг и активно использует ИИ для работы, а из критических заметок, объясняющих, почему SOLID плохо работает на практике, можно сложить вторую китайскую стену. Но по-прежнему слышу, что если ты не знаешь SOLID, то ты не специалист. Откуда этот бред берётся?

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

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

Есть популярное мнение, что оферты никто не читает, а значит написать можно все что угодно. Но по факту, мне кажется, что общая грамотность и ответственноть среди айтишников растет, и возможно такое "мнение" уже не соответствует действительности. Поэтому вопрос к вам - "Читаете ли вы оферты, прежде чем регистрироваться на сайте?". Да - 👍, Нет 👎. Ну а если читали оферту soerdev, то 👌.

Заметил, что перестал использовать средства мониторинга как основной источник информации, теперь анализ логов делает агент, формирует отчет и присылает результат мне в мессенджер. Недавно из-за сбоя у провайдера упал веб-сервер, ИИ не только понял, в чем проблема, но и нашел репорт на инфраструктуре провайдера, скинул мне ссылку, чтобы я принял решение, что делать дальше. По сути, раньше средства мониторинга помогали решать две задачи: аналитическую — цель в поиске «корневой причины» и оперативную — цель найти отклонения или деградацию сервиса в реальном времени. Сейчас смысл этой прослойки отпал, нужна централизованная база хранения метрик, логов и трейсов, плюс ИИ-агент (или система агентов), которые мониторят данные в реальном времени. Визуализация остается только для проверки.

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

Скоро финиш коллекции по оркестрируемым агентным системам, а у меня уже накопился материал для версии 2.0. Область оркестрируемых систем развивается с бешеной скоростью: есть варианты архитектуры для локальных LLM, для облачных, решения для шлюзов, оптимизаторов, реализации наблюдаемости, много вещей по безопасности и т.д. Стартапы в качестве основы для бизнеса выбирают AI-native подход, работающие компании стремятся закрыть AI-ready уровень. И это тоже сильно влияет на требования к инженерам. Что будет буквально через год — непонятно, но безумно интересно, поэтому продолжаю собирать новый материал и готовлю обновление коллекции на следующий год. P.S. возможно стоит уходить в формат регулярных семинаров, которые помогут гибко учитывать изменения, а то сейчас пока все отснимешь и выпустишь уже половина устарела.

На выходных обновил интерфейс основной страницы soerdev.space, идея в том, чтобы было удобно отслеживать выбранные материалы и определять направление для дальнейших шагов. Использовал DeepSeek Harness и DeepSeekFlash v.4

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

На выходных выкатил супер сложное обновление, и нет, не технически сложное, а просто прокачали один юридический момент. Теперь платформа soerdev.space помогает собирать согласия на запись и публикацию мероприятий (созвоны, семинары и т.д.), это очень важная механика, так как именно на встречах обсуждаем очень много полезных вопросов и без этих согласий публиковать записи нельзя. Вместе с юристами прокачал свои документы, посмотрел, как другие команды решают вопросы персональных данных, доработал платформу, и вот вчера поставил финальную точку - выкатил все обновления. Еще один небольшой шаг к большой цели сделан.

он зашёл к Архитектору Соеру, который славился тем, что любую задачу оборачивал в три слоя абстракций Ирония засчитана, но для тех кто в теме, 3 слоя абстракции - это как-то малова-то будет, я тут навскидку выделил 33 уровня от процессора до веб-морды: Аппаратный уровень 1. Физика полупроводников 2. Логические вентили 3. Комбинационные схемы 4. АЛУ и регистры 5. Микроархитектура 6. Архитектура набора команд (ISA) Системный уровень 7. Ассемблер 8. Языки системного программирования 9. Ядро ОС 10. Системные вызовы и системные библиотеки 11. Пользовательские процессы и файловая система Сетевой уровень 12. Сетевой стек 13. Прикладные протоколы 14. Инфраструктура Серверный уровень 15. Веб-сервер 16. Серверный фреймворк 17. СУБД и кэши 18. Бэкенд-приложение Клиентский (браузерный) уровень 19. Получение ресурсов 20. HTML-парсер 21. DOM 22. CSS-парсер и CSSOM 23. Render tree 24. Layout (reflow) 25. Paint 26. Compositing 27. JavaScript-движок 28. Web API браузера Фронтенд 29. Фреймворк/библиотека 30. Слой состояния 31. Компонентный слой 32. Стилевой слой 33. Веб-интерфейс Так что да, любят soer-ы оборачивать все в уровни абстракции.

идите к соеру чтобы обсуждать программирование , я пришел деградировать Мне кажется, что даже soer-ам просто обсуждать программирование быстро надоедает, бесконечные споры о том, что лучше ООП или ФП, был ли прав дядюшка Боб, раньше было лучше и тому подобное - быстро изматывает. Куда интереснее делать что-то свое, развивать свой проект, решать какую-то практическую задачу. Мне кажется, что наше сообщество как раз про это, мы встречаемся не просто чтобы потрещать, а чтобы обменяться опытом, рассказать что делали, что получилось, что нет. Например, в субботу на семинаре один из участников показал как у него организован SDLC с использованием клода и кодекс, какие подводные камни попались, какие роли у агентов и как они взаимодействуют. Лично мне такие штуки помогают лучше разобраться в том, что происходит в АйТи с появлением ИИ, как можно улучшить свою команду агентов и тому подобные вещи. Программирование - это увлекательная вещь, но теперь оно выглядит совсем иначе, чем даже пять лет назад. Смотреть надо в будущее, а не жить прошлым. Ну или "деградировать", как предложим автор из комментария.

Принцип "Чем меньше, тем лучше" Наше сообщество отличается тем, что мы не пытаемся завалить людей кучей ненужной информации, которую легко получить с помощью LLM или даже дедовским способом через поиск в интернете. 🛻📌 Принцип "Чем меньше, тем лучше" говорит о том, что действительно важную информацию нельзя просто так пропустить, потому что весь словесный мусор всегда строится вокруг одной или двух сильных мыслей, а остальное - это бесконечное обсуждение деталей, которые в каждом конкретном случае свои. Думать, что кто-то заранее узнает, как будет именно у вас, - весьма наивно. Возьмём популярные тейки: "Качай личный бренд", "Веди публичные каналы", "Прокачивай нетворкинг". Вы сами верите, что могли бы их пропустить, с учётом что буквально из каждого утюга говорят одно и то же? 📌 В нашем сообществе мы фокусируемся на практических моментах - не просто "что нужно знать" (знания сегодня более чем доступны), а как на практике работают знания и какие подводные камни встречаются. На созвонах мы не обсуждаем абстрактные советы, а вместо этого конкретно говорим, что и как используем. Например, обсуждаем скилы - перечисляем, какие именно, как и почему не другие. Обсуждаем MCP - показываем по факту, какие именно, объясняем, почему MCP в конкретном случае лучше скилов. Если говорим про ограничения и контроль агента, то опять же делаем это с демонстрацией экрана, показываем: вот так работают ограничения через ОС, вот так можно делать сбор состояния экрана в TMUX, вот так передавать управление через агента и т.д. При этом всегда действует ограничение - одна встреча в неделю. Тратить время друг друга на частые созвоны с тоннами воды - это тратить бесценное время впустую. Зачем я написал этот пост? Вижу, как многие люди гонятся за циферками вместо результатов, набирают в закладки кучу видео, составляют списки книг которые никогда не прочтут и т.д. Люди боятся пропустить что-то важное, какой-то секретный секрет, который знают только айти-гуру. Но на самом деле возьмите за правило выписывать те мысли, которые показались интересными. Спустя время увидите, что эти мысли повторяются из раза в раз. Мы в книжном клубе сейчас читаем про высоконагруженные приложения, и почти каждую неделю я пишу о том, что очередная глава более чем наполовину состоит из типовой базы - устройство СУБД, репликация, права доступа, управление ошибками. Много повторяющейся теории и почти ноль практики, советов, которые подскажут, что именно было выбрано в конкретном случае и почему, а не "минимизируйте задержки, увеличивайте производительность". Поэтому рекомендую взять за основу принцип "чем меньше, тем лучше": не гнаться за всеми знаниями мира, а фиксировать для себя главное. Завести небольшой блокнотик, куда выписывать одну-две мысли, смотреть, что повторяется, и фокусироваться лишь на том, что встретили хотя бы несколько раз, а не пытаться ловить каждый новый тренд.

Сегодня снова растёт интерес к проектированию ПО — потому что качество кода, который генерирует ИИ, почти неизменно, и чтобы на выходе получить нормальный результат, нужно компенсировать проблемы кода общей архитектурой системы. Проблема в том, что большая часть информации в открытом доступе ничего общего с проектированием не имеет. Проблем много. Одна из самых частых — неумение анализировать требования и сопоставлять их с реальными ограничениями. Простой пример. Человек разрабатывает систему с требованием «Задержки обработки платежа не более 5 сек в 99,9%», а решение собирает на облачных лямбдах, у которых фаза холодного старта легко сожрёт весь бюджет времени. Человек буквально не видит связь между требованием, ограничением и реализацией. Почему так происходит? В основном это проблема насмотренности. Чтобы научиться видеть такие штуки, нужно учиться анализировать, обосновывать и защищать свой проект. Базово нужно научиться выделять хотя бы основные эвристики по типу «лямбды медленно стартуют на холодную». Это поможет видеть совсем дырявые решения. Если есть требование, оно всегда порождает ограничения и существует в определённых границах. Проектирование — это и есть процесс поиска решения, которое соответствует ограничениям и требованиям. Значит, процесс проектирования всегда включает анализ и сопоставление требований с решением. Для этого нужно знать методы сопоставления — экспертные оценки, бюджетирование, прототипирование и т.д. Если требования есть, а оценки нет — это не проектирование. Говорить красивые фразы по типу «Вследствие CAP-теоремы у нас есть требование консистентности» — это здорово. Жаль только, что это просто набор красивых слов, за которыми ноль смысла. Лучше вообще отказаться от требований, которые не можете проверить, чем пытаться закрыть их бессмысленными фразами. Хорошо проектировать так же сложно, как писать хороший код. Поэтому если реально хочется разобраться — начните с разбора конкретных случаев: где требование, где ограничение, где решение и как обоснована согласованность.

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

Прошла регистрация еще одного товарного знака, теперь я официально владею двумя обозначениями: SOERDEV, SOER. Тема регистрация собственного бренда - это довольно запутанная история, поэтому поясню для чего я зарегистрировал сразу два. 1) В первую очередь - это защита доменных имен, названий каналов и право использовать английские названия на вывесках и публичном пространстве. По сути чисто утилитарная функция, чтобы соответствовать требовниям закона. 2) Любой товарный знак - это средство индивидуализации товара или услуги, есть целый классификатор, который определяет какие товары можно маркировать (это делается при выборе класса МКТУ), в моем случае два знака - две группы товаров. Я решил выделить два направления, которые планирую развивать в будущем: - SOER - это в первую очередь все что касается производства видео, частных консультаций, рекламы и прочих услуг связанных с деятельностью основного канала. Под этим брендом я планирую и далее выпускать ролики для инженеров, которые хотят разбираться в программировании лучше. - SOERDEV - это подход для развития знаний и навыков инженеров программистов, в рамках этого бренда я буду проводить встречи, выпускать просветительские материалы по теме развития и продвижения по карьере. Т.е. по факту, SOER - останется техническим каналом и сообществом, а SOERDEV - это отдельная ветка о саморазвитии и карьерном росте. Можно было бы ограничиться только брендом SOER, но там были высокие риски, что регистрация затянется или вообще не пройдет. Поэтому разделение было самым быстрым способом получить рабочий знак в моменте. Повезло, что патентный поверенный грамотно составил заявку и отбил потенциальные вопросы противопоставления знаков. Насколько сложно и дорого зарегистрироваьт свой знак - в моем случае все было просто - обратился к патентному поверенному, заплатил пошлины и через 9 месяцев получил свидетельство о регистрации. Цена вопроса вышла в районе 160 т.р. за все.

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

❗️На платформе soerdev.space опубликовал новые материалы в рамках наполнения коллекции "Оркестрируемые агентные системы". Так же у нас подходит к концу 6 неделя чтения книги "Высоконагруженные приложения", на этой неделе читали главу про шардинг (секционирование).

Вышла GPT-6 Astra, и пошла волна разговоров о том, что AGI стал на шаг ближе. Нам показывают различные варианты успешных генераций по разным направлениям — игры, 3D, видео и т.д. Но есть нюанс — мы не знаем, сколько неудачных генераций осталось за кадром. Безусловно, качество моделей растёт, но в своей практике я регулярно сталкиваюсь с разочарованием от того, что делают llm. У меня тоже есть примеры, когда фронтир модели, тот же Fable 5, давали классные результаты, но на один удачный кейс приходятся десятки, если не сотни моментов, когда модель делала не то, что надо, или не так, как надо. Так что да, вроде горизонт возможностей стал шире, но теперь очень хочется стабильности, а не сюрпризов в виде удалённых файлов, опубликованных секретных ключей, кучи копипаста в коде и т.д.

Без текста

Без текста

Без текста

Без текста

По мотивам подкаста с Никитой Пастуховым. Если ещё не посмотрели, то очень рекомендую не пропускать 😄

Фраза "АйТи - это просто работа" всегда вызывает у меня отторжение. В начале карьеры я 7 лет прожил в этой парадигме, ходя на неинтересную работу ради стабильного дохода, и по итогу понял — это не для меня. Проблема в том, что работа занимает значительную часть жизни, особенно если работаешь в офисе. И если приходишь на работу, чтобы просто отработать часы, выполнить какие-то задания, которые не дают никаких позитивных эмоций, то "просто работа" превращается в каторгу. Когда на работе нет позитива, мозг перестаёт вырабатывать дофамин, а вместо него зашкаливает кортизол, который превращает тебя в вялую амебу. Я так семь лет проработал на месте, где хорошо платили (в полтора раза выше рынка), но значительная часть работы заключалась в бесконечном составлении планов, отчетов, предписаний, согласований и прочих бюрократических вещах. Себя я успокаивал тем, что после работы, благодаря заработанным деньгам, я могу пойти в бар с друзьями, накопить на квартиру, поехать отдохнуть в отпуск. Вот только желания что-либо делать улетучивалось, и после работы хотелось просто упасть на диван и посмотреть очередной сериальчик. Гедонизм оказался так себе "лекарством" от бессмысленности труда. Возможно, для кого-то выполнять рутинные операции и "просто работать" — вполне нормальная концепция жизни. Но для меня, чтобы жизнь была полноценной, нужно, чтобы всё находилось в балансе. Согласно теории самодетерминации, человеку жизненно необходимы три вещи: - автономия (чувство, что ты сам принимаешь решения); - компетентность (ощущение роста); - связанность с результатом. Работа должна удовлетворять всем трем — не только давать доход, но и заряжать психологически, давать возможность придумывать интересные решения, видеть, что твои идеи влияют на результат, позволять создавать интересный/полезный софт и т.д. Лучшее — это когда попадаешь в "состояние потока" — единственное, что компенсирует физическую усталость. В результате получаешь заряд на всё остальное: на выходных заняться хайкингом, вечером после работы поиграть с детьми или помочь с домашкой, провести время с друзьями, а не за очередным сериалом. В общем, важно помнить, что люди — не биороботы, для нас важно психологическое состояние. Лично я черпаю много энергии через развитие и изучение нового — мне кажется, это лучший способ не закиснуть и максимально полно прожить жизнь. Казалось бы, буквально меняешь отношение в малом: вместо "это просто работа" приходишь к "это интересная работа", а эффект домино кардинально влияет на всё остальное. Что касается денег, то мысль "за интересную работу много не платят" — это не более чем миф, который к рельности не имеет никакого отношения. Здесь все зависит от того насколько востребованны твои компетенции и насколько ты сам ценишь свое время. Поэтому на практике можно совместить "интересное" с "прибыльным", все зависит только от тебя.

Через неделю начинаем знакомиться с темой оркестрируемых агентных систем. У нас есть ограничение на количество участников на созвоне (осталось одно место), поэтому на Подписке №3 скоро будет увеличение цены в два раза, это стандартный пэйвол, в прошлом году было так же.

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