Продолжаю перенос материалов сообщества на новую платформу.

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

Сегодня собрал коллекцию Технология разработки ПО

Часто замечаю, что в АйТи успешный продукт порождает обещания, которые превращаются в завышенные ожидания. Рано или поздно "пузырь", конечно, лопается, но осадочек остается.

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

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

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

Если перестать гнаться за "автономностью" и надеждой сэкономить на инженерах, то по-прежнему остаются циклы, использующие идею "Human ON the loop" (т.е. человек проектирует цикл, а затем он выполняется самостоятельно) - это куда более реалистичный сценарий, который, правда, тоже сыроват, но хотя бы можно собрать рабочий прототип и посмотреть на вопрос с позиции практики.

Чего сейчас не хватает рынку? Как всегда - не хватает хороших примеров. Вместо тысячи слов и красивых презентаций нужно создать git-репозиторий, который на практике покажет как работают SDLC-циклы. Без такого примера все остальное - вода.

Кто бы мог подумать, что спустя 20 лет после окончания ВУЗа буду вспоминать темы по философии и делать это с таким удовольствием.

"Мыслю - следовательно, существую" - это явно не про LLM, поэтому мыслить за машину должны мы.

Ища ответ на вопрос "Как заставить ИИ мыслить?", оказывается, что эти вопросы уже имеют ответы в учебниках по философии, если совсем упрощенно: Платоновская диалектика - это готовая методика, помогающая составлять промпты, а Аристотелевская логика - это прямой набор требований к тому, как должен быть построен ответ, чтобы не содержать противоречий.

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

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

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

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

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

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

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

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

Интересно разобрать на конкретном примере как архитектура может повлиять на развитие продукта. Опытные ребята помнят взлет и падение замечательного фреймворка Ruby on Rails (RoR). Изначально ставка была на быстрый старт, небольшой размер, быструю разработку (за счет высокой связанности модулей внутри фреймворка), работать с ним было легко и приятно за счет удобной консоли, позволяющие генерировать код по шаблону.

Как водится, проблемы архитектуры проявляются не на старте, а на этапе бурного роста. Со временем сильное зацепление стало мешать внедрению новых фич. Я как-то пытался вытянуть код отвечающий за Active Record и не смог этого сделать потому что связи были "всего со всем". При таком зацеплении нельзя не только "выделить" нужный код, но и заменить один подход на другой, например, хочется использовать гибкую ORM, но сделать это нельзя, так как все "прибито гвоздями". В итоге решения, принятые на ранней стадии, определили ограничения на более поздних стадиях.

Долгое время ROR сохранял позиции по популярности и активно применялся для MVP, но со временем стал сдавать позиции, особенно на фоне более модульного конкурента Merb. В 2008 году было принято стратегическое решение объединить усилия с Merb, чтобы использовать в Rails модульную архитектуру. Разработчикам ядра фреймворка пришлось пойти на тяжелый шаг - в третьей версии они начали рефакторинг в сторону модульности (во многом благодаря наследию Merb, в частности через Railties), но из-за того же исторического жесткого зацепления внутри кодовой базы полностью перестроить архитектуру не удалось, Active Record так и остался глубоко вплетен в ядро. Связанность на уровне сборки ослабла, но на уровне публичных API и привычек экосистемы глобально ситуация не поменялась.

Усугубило ситуацию то, что время было упущено, после 2010 года мир веба стал стремительно разворачиваться в сторону SPA и реактивных фронтенд-фреймворков, ROR со своей завязкой на MVC попытался переориентироваться на API бэкенд и тоже неудачно, тут свою роль сыграл не столько медленный Ruby (в API узким местом обычно является БД), сколько тяжелая модель параллелизма и высокое потребление памяти, из-за которых горизонтальное масштабирование обходилось дороже, чем у конкурентов (даже не самый лучший Node.js выигрывал у Ruby), поэтому в итоге архитектурные ошибки и сложности их устранения привели к потере популярности и превращению ROR в нишевый продукт.

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

Стоит столкнуться с реальностью – и былая уверенность «если надо, выучу за одну ночь» куда-то испаряется, а вместо неё приходит понимание: без качественных хардов успешной карьеры в IT не построить.

Решил собрать топ заблуждений, которые умножают на ноль любые усилия по созданию карьеры в IT.

Главное получить первую работу, а там уже всё пойдёт само собой.

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

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

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

Чем больше резюме я разошлю, тем быстрее найду работу

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

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

На самом деле ИИ не способен заменить инженера. Все достижения ИИ сегодня лежат в области кода, и даже там не все задачи закрываются полноценно. Сегодня ИИ может с натяжкой заменить кодера, привыкшего копировать решения со StackOverflow, – инженерный стек пока остаётся за инженерами.

Попробуйте, вы ничего не теряете.

На самом деле теряете, причём теряете самое дорогое – время. Чем раньше человек осознает, что волшебные таблетки – это сомнительный товар, включит критическое мышление, посмотрит вокруг и посмотрит на тех, кто реально чего-то добился в IT, тем быстрее заметит: типаж успешных айтишников – это профессиональный инженер с хорошими техническими скилами и опытом решения сложных задач.
Посмотрите на их профили повнимательнее: у них за плечами не просмотр роликов «JavaScript за 2 часа», а глубокое понимание архитектуры, технической базы и, самое главное, идеи того, как помочь бизнесу и продукту. Это нарабатывается не за одну ночь перед собеседованием, и к этому нужно стремиться.

Кем быть – «темщиком» или «инженером», решать, конечно, вам, но помните: результат всегда зависит от того, что вы выберете.
Если выбираете инженерию – учите не фреймворки и языки программирования, а архитектуру, устройство процессов, теорию разработки. Если выбираете быть темщиком – то не зацикливайтесь только на резюме, ищите реферальные программы, общайтесь с инженерами, возьмите ответственность за свою жизнь на себя. Как известно, выход есть всегда, даже если вас съели.

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

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

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

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

На эти выходные открываю видео Введение в сервисную архитектуру.

Мне кажется, что если кто-то искренне верит, будто его «айти» кто-то разрушил, - этот человек никогда не имел "своего" айти.

Да, на рынке много слабых разработчиков, в индустрии куча откровенного шлака, а ИИ-ка пишет код лучше среднего разраба. Но это не разрушение IT. Напротив, сегодня как никогда много свободы для творчества и реализации идей.

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

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

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

Задали вопрос в комментариях - думаю, полезно ответить здесь.

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

2. Действительно, есть путаница: в микросервисной архитектуре «сервисы» и «микросервисы» часто одно и то же, хотя это не совсем так.

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

Также очень надеюсь, что наша оппозиция даст критику на мой материал. Они обычно утверждают, что соеры ничего не умеют и не знают, что за одну ночь выучат то же самое. Что ж, теперь у них есть возможность бесплатно получить доступ и «разъебать по фактам». Буду ждать.

ingress-nginx: как маленький API оброс собственным языком (Рубрика #PlatformEngineering)

Разбирался с закрытием ingress-nginx. Эту историю можно пересказать как драму open source: компонент примерно для половины cloud-native окружений, по внутренним данным Datadog, годами поддерживали один-два человека в свободное время. Но мне интереснее механизм, сделавший его несопровождаемым.

Ingress API намеренно оставили маленьким: host, path, backend, TLS. В production быстро понадобились таймауты, повторные попытки, canary, внешняя авторизация, заголовки и WAF. ingress-nginx добавлял всё это аннотациями - к июлю 2026 года документация насчитывала около 130 уникальных ключей. Snippet-аннотации позволяли вставлять произвольные фрагменты NGINX-конфига.

Так обходной путь превратился в неформальный DSL. API выглядел простым, но реальный контракт жил в строках metadata, зависел от контроллера, плохо валидировался и расширял поверхность атаки. В 2025 году Wiz раскрыл IngressNightmare - цепочку уязвимостей с неаутентифицированным RCE.

В марте 2026 года поддержка ingress-nginx закончилась: больше нет релизов, исправлений ошибок и security-патчей. Существующие установки продолжают работать - просто без будущих исправлений. Сам Ingress API не закрыт и не deprecated: он заморожен, а развитие ушло в Gateway API.

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

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

#PlatformEngineering #Kubernetes #Architecture #DevOps #Security

Внимание, скам!
Появился бот который выдает себя за бота моего канала. Я НИЧЕГО ЧЕРЕЗ БОТОВ НИКОМУ НЕ ПРОДАЮ. Жалуйтесь на скам если вам прелитит предложение на скидку от бота в телеге.

Но в целом, непонятно, что там можно кодить целую ночь? Что за проект? ИИ пишет код не как человек, а сильно быстрее.
А так же сильно быстрее уходить в неправильную сторону и в целом не способен долго продуктивно работать на большой задачей. То есть даже если он реально работал 8ч, то результат такой работы скорее всего будет хуже, чем если бы он работал 1ч

Забавно наблюдать, как меняется восприятие идей. Еще в феврале, когда я рассказывал о своем оркестраторе и длинных циклах (до 18 часов), меня упрекали в маркетинговом булшите: мол, агенты работают быстро, и если давать им долго работать, профита не будет. Сейчас разговоры о многочасовых циклах и агентном харнесе стали привычным делом, и мой сетап на этом фоне уже не выглядит радикальным.

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

В итоге я пришел к связке: максимально конкретная постановка задачи, собственная архитектура, принцип Human on the loop, оркестрация и простой SDLC.

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

Наверное, ничто так не обесценивает хайп вокруг ИИ, как придумывание очередной «инженерии»: мы уже видели «промпт-инженерию», «контекст-инженерию», «харнес», «инженерию циклов» и вот теперь — «граф-инженерию».

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

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

Но почему-то вместо того, чтобы честно сказать: «Да, не работает, пока модели могут работать на уровне кода, для решения рутинных задач», — начинается: «Ну раз не работает одно, то сейчас придумаем другое».

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

Пост одного из участников клуба, в котором он довольно трезво разложил ситуацию с агентным кодингом. Смотри ниже 👇👇👇

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

Приведу пример, я не перечитываю код, который пишет llm для моего сайт soerdev.space. Недавно, проводя рефакторинг, LLM перелопатила кучу кода и оставила "хвостов", из-за этого не проходили тесты. Я заглянул в код, пробежался по диагонали, понял, что вычитывать смысла нет. Проблема в том, что код - не книга, если ты не в контексте проекта, то читай не читай, а пока не разберешься со всеми нюансами полную картинку не получишь. Держат весь контекст в голове - это значит терять профит от быстрого ИИ, так как ты становишься узким местом (проект развивается с той скоростью, с которой ты можешь делать ревью).

В результате попросил LLM составить описание интересующей фичи с примерами кода, который его реализует, и графом зависимостей. По описанию сказал что и куда поставить, чтобы было норм.

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

Сегодня поговорим про LLM-модели и ИИ Агентов. Описал в статье своё видение проблем, когда ИИ агентов пытаются использовать в качестве автономных работников, когда пытаются полностью реализовать фичу по бизнес-логике, а получается какая-то фигня.

https://vc.ru/ai/3051778-problemy-ii-agentov-s-bolshoy-kodovoy-bazoy-i-puti-resheniya

Как итог: ии агенты - ещё один инструмент, но в целом, сыроватый.

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

Контролировать, безусловно, надо. Вопрос в том, "как контролировать?", причём так, чтобы не убивать весь профит от использования LLM. Узкое место — это скорость проверки. Если у вас на входе копится куча PR-ов, которые проверяются вручную и в половине случаев возвращаются на доработку, то это делает использование LLM бессмысленным, общая скорость разработки не только не растет, а наоборот падает.

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