Архитектура распределённых систем

[начало выше]

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

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

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

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

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

Сравнивать стоит:
🛑 затраты человека на управление;
🛑 стоимость токенов и общее время;
🛑 количество ручных вмешательств;
🛑 нарушения архитектурных ограничений;
🛑 прохождение функциональных тестов;
🛑 объём переделок после изменения требований.

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

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

Получается, книга о доказательной архитектуре и архитектурных гипотезах и средовой подход всё же пересеклись в одной точке: эту гипотезу тоже придётся проверять об практику. Пока она опирается на интуицию, аналогии и уже существующие практики вокруг SDD, обвязки (harness'а), архитектурных тестов и формальных правил.

Получается, что описанный эксперимент — ещё один кейс в копилку практики применения описанных в книге подходов 📒

И, кажется, я уже знаю какие части в себя будет включать моя следующая книга 🙂
I. Проектирование среды создания детерминированной системы
II. Проектирование среды, в которой работает система
III. Проектирование среды создания среды
🧸

Очень много всего сейчас происходит параллельно... Голова кипит. Из основного творческого — это 2 отдельных почти непересекающихся направления: конечно же, книга «Доказательная архитектура» и средовой подход. Сегодня ночью очередь второго ⚗️

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

Тут есть пробел в рассуждении — «в какой-то момент», а в какой? При каких условиях? Есть наблюдаемый тренд: код дешевеет, компонентов и изменений становится больше. А дальше я делаю скачок к выводу, что средовой подход обязательно окажется выгоднее. Но это пока именно гипотеза, причём гипотеза про будущее.

Знал бы прикуп.. 🃏

В моем предлагаемом средовом подходе есть важная развилка его применения. Можно проектировать
🛑 среду, в которой работает система;
🛑 среду, в которой система создаётся.

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

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

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

Если ждать от нейросети одинакового ответа на одинаковый запрос — противоречит. Побитовой воспроизводимости тут может не быть, но и от методологии она не требуется — методология не опускается до уровня супер-конкретных советов. Для LLM и средового подхода можно воспроизвести такой эксперимент: зафиксировать модель, контекст, инструменты и правила, выполнить много прогонов и смотреть на распределение результатов. Траектории создания системы могут различаться, но результат должен оставаться в заданных границах и с приемлемой вероятностью проходить критерии приёмки.

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

Теперь хочется конкретизировать и провести эксперимент. 🧪

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

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

[продолжение ниже]

Всем привет! Сегодня у меня день рождения, и я сделал себе к нему подарок — закончил работать над черновиком своей книги "Доказательная архитектура" 😊
🎞️🎞️🎞️🎞️🎞️🎞️🎞️

«Ну ты же архитектор, тебе виднее».

Эту фразу слышал, кажется, каждый в профессии, и говорят её обычно с уважением. Только вот с чего виднее? За решением стоит опыт — сколько-то похожих систем, сколько-то прочитанных книг, сколько-то шишек. У коллеги, который предлагает сделать наоборот, найдётся не менее убедительная история. Оба опираются на опыт и оба звучат уверенно, а выбрать в итоге нужно какой-то один вариант.

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

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

Что внутри, если коротко:

➡️ лестница силы аргументов — от интуиции до эксплуатационных наблюдений: чтобы прямо на архсовете понимать, сколько весит прозвучавший аргумент;

➡️ архитектурная гипотеза: как превратить мнение архитектора в проверяемую запись с механизмом эффекта, метриками и условиями пересмотра, зафиксированными до внедрения;

➡️ принцип каскадного снижения связанности, доведённый до проверяемого неравенства;

➡️ Architecture as Code с тестами: как ловить расхождение схемы и реальности на CI, а не на инциденте;

➡️ метрики архитектуры и способы не обмануть себя ими же;

➡️ как проверять отказоустойчивость, когда начинать архитектурный рефакторинг и что изменится, если приложить тот же аппарат к платформам, процессам и оргструктурам;

➡️ и отдельная глава про то, что со всем этим делает ИИ.

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

Сейчас это черновик. Сейчас хочу собрать небольшую группу коллег по цеху желающих прочесть черновик для проверки.

Если чувствуете в себе силы осилить и дать фидбэк — пишите в личку @razonrus 😎

В качестве обратной связи по черновику мне нужны минимум две вещи:

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

На верстку, стиль картинок, мелкие опечатки и пунктуацию пока можно не обращать внимания. Мне важно именно содержание.

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

Планирую собрать обратную связь за месяца полтора.

Спасибо 🙏

Вычислительная техника десятилетиями приучала нас, программистов, к абсолютному детерминизму: написал инструкцию — машина выполнила ровно её, миллиард раз подряд одинаково. Кажется, мы единственные инженеры, которым достались настолько тепличные условия. Строитель никогда не знал точной прочности конкретного замеса бетона — только распределение, и надёжность в ГОСТах до сих пор считается через вероятность отказа. Инженерный мир всегда жил с допусками. Софт был исключением.

Ещё в школе, когда я только изучал Паскаль, мне казалось, что настоящий искусственный интеллект наступит тогда, когда программы начнут ошибаться (как и мы, люди — в этом одна из главных наших сильных способностей). Тогда бесило, что "if" всегда работает одинаково, что 2+2 — всегда 4 (про javascript я тогда ещё не знал 😂). И казалось, что ошибки программ (именно ошибки, не баги) — какой-то недостижимый уровень, до которого я вряд ли успею дожить как и до колонизации Марса. Получается, что до первого дожил, чему я несказанно рад ))

Да, недетерминизм и у нас встречался — те же гонки в многопоточке или «плавающие» баги. Но мы его именно лечили: мьютексами и транзакциями загоняли случайность в клетку, возвращали себе привычную определённость. С ИИ этот трюк уже не проходит: стохастика перебралась с краёв системы в самый центр процесса разработки.

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

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

Как эта перестройка ощущается изнутри, человеком — хорошо описал Андрей Шапиро в свежей статье на Хабре про усталость от работы с ИИ-код-агентами: ошибки прилетают в произвольных местах процесса («радиация внимания» — точный образ), а код на глазах превращается в чужое легаси. Рекомендую целиком: https://habr.com/ru/articles/1057716/ — этот пост, собственно, и вырос из моего комментария под ней.

С ИИ-агентами рецепт, видимо, тот же, что и у квантов. Требовать от стохастической модели детерминизма бесполезно. Зато можно обложить её инженерным контуром, который эту стохастичность переваривает, — весь новый harness-инжиниринг по сути, об этом. Проверяем сейчас и об собственный SDD-фреймворк — местами уже работает.

А архитекторам к такому вообще не привыкать — мы в неопределённости жили всегда. Заранее предугадать все сценарии невозможно, проверить архитектуру до того, как система построена, — тоже. Какая архитектура хорошая, а какая плохая, выясняется только при встрече с реальностью, иногда годы спустя. Как я недавно писал:

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

Да и классическая задача распределённых систем из той же серии: собрать надёжную систему из ненадёжных компонентов. И многое-многое другое..

В шахматах, кстати, ты принимаешь решения в условиях полной определённости, я их за это всю жизнь и любил, и ненавидел. Наверное поэтому меня сейчас так привлекают шахматы с кубиками (dicechess — вероятностная версия шахмат, я аж даже движок для них иногда пишу по ночам 😅). Видимо, с определённостью наигрался 🙂

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

Нужны ли джуниоры в ИТ, когда есть ИИ?

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

Смотрите: технологии сменились настолько, что опыта в новом нет ни у кого. ИИ-агенты, SDD, harness-инжиниринг — этим дисциплинам ноль лет, а приёмы в них устаревают быстрее, чем успеваешь их документировать (вышла новая модель — половина наработок в корзину). В этом смысле сейчас джуниоры — все. И вчерашний выпускник, и синьор с 15 годами стажа.

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

Тем, кто уверен, что синьоры справятся сами, — два факта:

➡️ Фристайл-шахматы, 2005 год: турнир с разрешённой компьютерной помощью выиграли два любителя с рейтингами 1398 и 1685. Гроссмейстеры с движками остались позади. Вывод Каспарова: слабый игрок + машина + хороший процесс сильнее сильного игрока + машины + плохого процесса.

➡️ Исследование METR, 2025: опытные разработчики с ИИ решали задачи на 19% медленнее, при этом были уверены, что ускорились на 20%. Стаж копания не конвертируется в управление экскаватором автоматически 🏗

Оговорюсь: обнулился навык владения инструментом, а не инженерное суждение. Экскаватор копает глубже лопаты — и геология (ну или хотя бы понимание состава грунта чуть глубже чем верхние пара метров) стала нужнее, чем была. А ещё ковш одним движением может порвать газовую трубу, которую лопатой ты бы точно не пропустил. Цена ошибки выросла вместе с мощностью инструмента.

Карьерная лестница в ИТ всегда шла через середину — годы CRUD-ремесла, json-оперекладывания и смузихлёбства, на которых суждение и выращивалось. ИИ эту середину выжег 🔥. Своих ошибок в проде новичку теперь не дадут (агент ошибается дешевле), а как растить суждение без собственных ошибок — не знает пока никто. Я тоже не знаю.

Что бы я делал, входя в ИТ сегодня: фундамент с длинным периодом полураспада (математика, архитектура распределённых систем, вероятности, английский китайский) + сразу в кабину экскаватора — реальные проекты с агентами вместо стажа, письменные спеки, привычка проверять каждый слоп выхлоп нейросети. И чужие постмортемы вместо собственных шишек.

🔜 Подробный разбор — какие компетенции девальвировались, какие остались, какие стали фундаментом только что, и что делать джуниорам и школьникам — скоро напишу в статье на Хабре

А вы сейчас нанимаете джуниоров?

В прошлых постах и докладах, и статьях (😅) про будущее ИТ я говорил о важности формулирования новых вызовов в индустрии:

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

И там же постарался такой вызов сформулировать:

На мой взгляд, следующий этап развития ИТ — это переход от системного подхода к средовому.

Теперь настало время хотя бы начать задумываться об ответе. А кому этим заняться, если не мне? 😎

Сел набрасывать методологию: как проектировать ИТ-продукт, когда ты больше не специфицируешь 300 микросервисов поштучно, а задаёшь среду — законы, стимулы, ниши, отбор, — а продукт внутри взращивается сам или руками ИИ-агентов. По сути садоводство вместо сборки.

И тут вылезло забавное. Сам же писал «лет через 10-15» — а пока собирался отвечать на вызов из будущего, выяснилось, что мы в эту сторону давно идём и частично уже пришли. Просто не звали это средовым подходом.

О чём в статье:
— чем средовой подход отличается от системного (и при чём тут садовник, вода и муравьи);
— примитивы среды, её паттерны и принципы проектирования;
— почему harness для ИИ — это и есть среда, а контекст-инженер скоро станет средовым инженером.

👉 https://habr.com/ru/articles/1051722/
Буду рад вашим ➕ и 💬

Копаем дальше 🧑‍🎓

🎙 На CodeFest я не только был в команде ПК, но ещё и немножко выступил сам — поучаствовал в публичных дебатах на интересную тему:

Есть ли будущее у языков программирования в том виде, в котором мы их знаем?
(видео дебатов)

Самое забавное, что по жребию мне досталась защита позиции

«да, языки останутся примерно такими же»

Хотя моя настоящая позиция почти противоположная. Я уже писал об этом отдельный провокационный пост и статью

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

1️⃣. Всё, что сейчас умеют LLM, — это в огромной степени наш человеческий опыт.

Они обучены на нашем коде, библиотеках, паттернах, ошибках и костылях. Они пишут на Python, C# и JavaScript не потому, что это «правильные» языки, а потому что на них человечество накопило огромный слой опыта.

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

2️⃣. Ответственность.

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

Одно дело — сгенерировать CRUD. Другое — автопилот, ракета, АЭС или любая система, где ошибка проявляется не красным логом в CI, а железом в реальном мире.

Тесты и симуляции — хорошо. Но если под капотом лежит нечитаемая лапша, которую никто не понимает, то в какой-то момент мы просто верим, что оно работает.. вера — так себе метод.

На дебатах я сформулировал это чуть грубее: будет серия катастроф, а потом мы вернёмся к Python :)

___________

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

Вопрос, на мой взгляд, в другом: язык программирования будущего будет человеческим или нет?

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

Зачем ему(ей) человекочитаемый синтаксис, красивые имена переменных и вся эта церемония, если основной потребитель слоя кодирования — уже не человек?

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

У AI тоже есть ресурс: токены, контекст, вычисления. И человекочитаемый код может оказаться таким же избыточным форматом, как XML там, где нужен компактный бинарный протокол.

Python будущего может быть не «любимым языком ИИ», а дорогой промежуточной упаковкой для нас. Чтобы мы видели знакомые слова и думали, что всё ещё контролируем процесс. Так зачем тратить лишние токены на написание кода на Python? 🤩

Хорошая аналогия — Google Translate. Когда перевод идёт через внутреннее представление модели, качество может резко вырасти. Внутренний язык не обязан быть красивым. Ему нужно быть эффективным.

Похожая история с AlphaZero: пока система училась на человеческих шахтматных партиях, она наследовала и человеческие ограничения. Когда её отпустили от этого слоя, произошёл скачок.

Сейчас у нас примерно так:

задача → человеческий язык → Python/Java/C# → машинный код

Но это может оказаться переходной стадией.

А может стать так:

цель → внутреннее представление модели → исполняемая система

А привычный код останется рядом. Как слой аудита, отладки и верификации. Как ассемблер, в который иногда всё ещё нужно уметь смотреть.

Это главное уточнение к старому тезису.

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

Код перестаёт быть центром профессии.

А проверка, смысл, контекст и ответственность — наоборот, становятся ещё важнее.

Полное видео дебатов: https://rutube.ru/video/a857f6892d4c005ece54508387c2e396

🎙 Codefest, дебаты и провокация про языки программирования ⚔️

В этом году я снова в программном комитете Codefest — и помимо привычных дел с архитектурным/Future/бэкенд треками в этот раз мне выпало участвовать ещё и в самих дебатах в качестве одного из спикеров. Тема дебатов прямо в десятку моих недавних провокаций:

«Есть ли будущее у языков программирования в том виде, в котором мы их знаем и привыкли видеть?»

Формат для конференции свежий: прямо на сцене нас поделят на две команды — За и Против — и попросят аргументировать каждую позицию. Зал сможет подключаться вопросами, а в конце каждый спикер раскроет, на чьей стороне он на самом деле 😏

Свою настоящую позицию я в канале уже размашисто проговаривал (https://t.me/rsa_enc/382), коротко напомню 👇

Код — это костыль. Языки придумали не потому, что они нужны машине, а потому что они нужны человеку. Python, Java, C#, SQL — это интерфейсы для нашего белкового мозга, чтобы хоть как-то упаковать сложность. Машине всё это не нужно. Ей не нужен Python. Ей не нужен C++. Ей вообще не нужен язык как таковой 🧠

Сейчас LLM получает задачу на человеческом языке, обрабатывает её в своей внутренней математике — векторах, коэффициентах, абстрактных представлениях — и только ради нас переводит результат обратно в «человеческий» Python:

смотри, узнаёшь?

🗿

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

Тут полная аналогия с шахматами: пока AlphaGo училась на миллионах человеческих партий — была сильнейшей в своём классе. А когда AlphaZero освободили от всего человеческого опыта — она разнесла AlphaGo в пух и прах. Стереотипы, накопленные веками, начали мешать, а не помогать.

Так и с программированием: переход «задача → Python → машинный код» рано или поздно превратится в «задача → внутренний язык модели → машинный код». Без посредников и лишнего синтаксиса. И это отличная новость — потому что вместе с языками уходит и рутина, а человеку остаются по-настоящему человеческие задачи: постановка целей, поиск решений, творчество и ответственность 🤩

Чуть подробнее эти и смежные идеи — про сдвиг архитектора на уровень выше, про границы применимости ИИ, про средовой подход — в моей свежей статье на Хабре (постом выше).

Какую сторону мне выпадет защищать на сцене — За или Против — узнаем уже в Новосибирске 😎 А моя личная позиция, кажется, и так очевидна.

И пару слов про сам Codefest, раз уж всё равно пить клюковку 🍷:
Конференция пройдёт 30—31 мая в Новосибирске уже в 16-й раз. Мы собрали 15 треков, заметно прибавили практики на мастер-классах, добавили новые форматы — те самые дебаты и разборошные, где можно не только слушать, но и участвовать. Ну и квартирники с неформальными дискуссиями на горячие темы — святое 😇
Программа получилась такая, что сам бы пошёл слушать, но придётся спорить: https://16.codefest.ru/lecture/3558 🤩

Программа: https://16.codefest.ru/program
Регистрация: https://16.codefest.ru/reg

Прилетайте — будет жарко 🔥
Ну и приходите спорить со мной на дебатах: планирую разнести оппонентов в пух и прах, как AlphaZero — AlphaGo 😏🌟

Неделя выдалась плодотворная ) очередной пост ))

Уже почти становится традицией — третью весну подряд у меня выходит статья на Хабре ☀️

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

Если раньше я в основном писал про вполне прикладные вещи (гранулярность микросервисов, проектирование отказоустойчивости, покрытие архитектуры тестами, каскадное снижение связанности) — то здесь попробовал замахнуться на горизонт пошире:
- что вообще происходит с ИТ,
- что меняется из-за ИИ,
- зачем в новом мире по-прежнему нужна архитектура,
- и что со всем этим делать разработчику уже сейчас.

Ключевая мысль для меня такая: человеческая ценность всё меньше в самом написании кода и всё больше — в борьбе со сложностью, в проектировании, в постановке задач, в выборе ограничений и в проверке результата.
То есть не “меньше инженерии”, а скорее инженерия следующего уровня.

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

https://habr.com/ru/articles/1027144/

Ставим огонёчки 🔥 (или чо там на хабре?)),
зарабатываем плюсики в карму ☯️

🔮 Стратегия айтишника в эпоху ИИ: как остаться востребованным

Всем привет! Последние месяцы я активно думаю, пишу и выступаю о будущем ИТ — доклады про ИИ, посты про настоящие компетенции, на подходе — объёмная статья для Хабра..

И наконец-то я довёл все эти рассуждения до конкретного прикладного результата — и спешу им с вами поделиться! 🚀

📌 SWOT-анализ + стратегия «Айтишник в шестой технологической волне»
➡️ https://app.sociotech.center/projects/public/133b2a7b-c7b0-4559-8fe6-1b734e5085b1

Это не очередные «10 советов, как не потерять работу из-за ИИ» 😅. Это полноценная стратегия — с целью до 2029 года, измеримыми метриками, тремя ключевыми гипотезами и конкретными задачами под каждую. Всё по букве методологий Карты гипотез и Связанного SWOT-анализа: сначала факторы, потом ставки, потом сами гипотезы и задачи.

❗️ И самое главное — там не только «анализ ради анализа». Там расписаны конкретные задачи и советы, которые можно начать делать уже на этой неделе ☺️. Не абстрактное «развивайтесь», а «возьми одну реальную задачу и пройди её полностью через ИИ — от цели до верификации», «напиши один ADR для ИИ-агента, который возьмётся за твой код через год», «настрой один архитектурный автотест через AACT или ArchUnit».

🤩🤩🤩

🎯 Если вкратце — стратегия сводится к трём сдвигам:

1️⃣ Борьба со сложностью вместо производства кода
Код скоро станет таким же внутренним слоем, как ассемблер. Ценность сдвигается на уровень выше — в визуализацию систем, графовое мышление, архитектурные решения. Если сложность живёт только у тебя в голове — контроль над ней иллюзорен. Выплесни её на схему и начни с ней работать.

2️⃣ ИИ как новый режим мышления, а не как новый инструмент
В зависимости от того как ты работаешь с ИИ — разброс качества результата может быть огромным. Чат с ИИ ≠ работа с ИИ. Загрузи в агента полный контекст проекта и цель бизнеса — а не отдельный вопрос. Разбери свои типовые задачи на три корзины: рутина → агенту, решение → себе, проверка → обязательно себе. Напиши свой первый agent skill (сегодня это просто текстовый файл, а не поднятие векторных БД, как полгода назад).

3️⃣ Ответственность за результат, а не за код
До кода и до ИИ — запиши бизнес-цель, не-цели, ограничения, критерии «достигнуто». И проверь — а нужен ли вообще новый код? Это самый контринтуитивный пункт во всём списке. Перепиши резюме вокруг решений и результатов, а не стека. Проведи один пилот безопасного внедрения ИИ в команде — роль проводника ИИ в организации уже оплачивается, в отличие от роли «ещё один prompt-оператор» 🙂

🤩🤩🤩

🧩 И вот что ещё круто — стратегия не высечена в граните! Можно ведь совместно редактировать и дополнять карту гипотез и SWOT. И я очень хочу позвать вас поучаствовать! ❤️

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

🙏 Поэтому приглашаю:
— просто посмотреть, покликать, повертеть карту и SWOT
— применить задачи к себе (реально, не отложив «на потом»)
— а главное — присоединиться к совместному редактированию и расширению стратегии и анализа: скидывайте мне свои аккаунты (@razonrus) — добавлю вас в пространство

Это тот случай, когда коллективный интеллект реально даст больше, чем любой индивидуальный анализ. Давайте вместе соберём самую толковую стратегию выживания усиления айтишника в шестой технологической волне ✨

❤️ Буду рад любым комментариям, дополнениям, несогласиям, своим ставкам, гипотезам и задачам — всё это добавляет глубины и смысла общей работе.

А применённые задачки и инсайты по ходу дела — скидывайте в комментарии сюда или мне в личку (@razonrus). Самое интересное соберу в следующем посте 😌.
А ещё, если вдруг вы из Челябинска — приходите через месяц, в рамках доклада представлю данную стратегию в оффлайне 🐰

Погнали! 🚀

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

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

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

В одной будут красивые bounded context’ы. В другой — event-driven и асинхронщина. В третьей — платформы, observability, service mesh и прочие признаки взрослой айтишечки. И почти у каждой найдутся разумные аргументы, ссылки на прошлый опыт и очень уверенная защита.

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

И вот тут начинается самое интересное.

А что мы тогда вообще оцениваем — красоту схемы, напор на защите, количество модных слов на квадратный сантиметр слайда, совпадение с тем, что сейчас считается хорошим тоном в индустрии?

Если честно, архитектурные решения слишком часто принимаются именно так. Никто, конечно, не говорит в лоб: “давайте возьмём Kafka, потому что у меня её ещё нет в резюме”. Нет, всё звучит намного благороднее: это стандарт индустрии, так делают в ◀️ваш любимый бигтех▶️, так правильнее, гибче, надежнее. И вот это вот всё.

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

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

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

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

И чем больше я думаю про архитектурную кату, тем меньше верю в оценку по красоте квадратиков. Кажется, смотреть надо на другое: есть ли у решения логика, понятно ли, от какого контекста оно отталкивается, и можно ли вообще проверить, что это не просто хорошо упакованное мнение.

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

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

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

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

Говорить, что «у ИИ нет памяти», неправильно. У современных моделей есть объём знаний, заложенный на этапе обучения. В каком-то смысле они “помнят” почти всё, что накопило человечество. Но это не память в человеческом (белковом) смысле. Скорее что-то вроде глубокой статистической, почти мышечной памяти. Примерно как человек умеет ездить на велосипеде или плавать: мы не расписываем себе, каким мышцам какие команды отдаём, а просто делаем. Мне кажется, ИИ так же решает и многие аналитические задачи: не по-человечески “вспоминает” как их решать, а как будто сразу умеет.

А вот обычная память диалога или проекта у ИИ устроена иначе. Это не выученное с молоком матери знание, а контекст: временно подгруженная рабочая среда (контекст, скиллы и т.д.). И она хрупкая. Что-то попало в неё, что-то нет. Что-то модель посчитала важным, что-то второстепенным. Что-то при упаковке контекста сократилось или исчезло. Поэтому модель может знать огромный пласт общих вещей и при этом забыть, о чём вы договорились десять сообщений назад.

И отсюда следует главный практический вывод. При работе с ИИ-агентами нужно фиксировать вообще всё, что вы хотите сделать частью их устойчивого поведения в проекте: договорённости, подходы, найденные грабли, ограничения.. Всё это должно существовать не только в головах команды или чатах. Обсудили на стендапе, что каждую задачу начинаем в отдельной ветке, — напишите бумажульку для ИИ-агента. Нашли подводный камень в работе приложения на iOS, договорились, как называете фичи и релизите — зафиксируйте это там, откуда агент сможет подгружать это снова и снова.

Промпт он забудет. Точнее, промпт слишком ситуативен и живёт недолго. А вот контекст, лежащий в репозитории, в спецификациях, ADR, заметках — это уже не человеческая память, но это та среда, из которой ИИ может заново собирать себе рабочую картину мира.

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

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

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

И да, типичная фраза архитекторов "зависит от контекста", становится ещё более актуальной!

Давно я тут ничего не писал.. Ещё давнее — чего-то на самом деле архитектурного. Исправляюсь :)

Сегодня хочу поговорить о применении Common Reuse Principle (CRP) для микросервисной архитектуры. Вкратце я упоминал о применении данного принципа к микросервисам, например, в докладе по рефакторингу архитектуры. Давайте разберём подробнее и с примерами.

Вспомним, о чём говорит классическая формулировка CRP предложенная Робертом Мартиным:

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

Пример нарушения:

Представьте библиотеку GraphicsUtils, в которой лежат классы для работы с 2D-графикой и классы для сложной 3D-анимации. Если разработчику просто нужно нарисовать круг (2D), он вынужден подключить всю библиотеку, включая тяжелые 3D-алгоритмы. Согласно CRP, их следует разделить на два разных компонента

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

Итак, принцип будет звучать примерно так:

Если один контекст (1) использует микросервис из другого контекста (2), то использовать он должен и остальные "публичные" микросервисы.

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

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

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

Наверное, проще проиллюстрировать соблюдение и нарушение принципа на примерах.

На схемах 1 и 2 нарушения принципа нет. В первом случае контекст 1 использует сервисы C и D контекста 2, и это допустимо — он зависит от всех "компонентов" контекста 2. Во втором случае контекст 1 использует только C, и тут тоже всё нормально, т.к. микросервис D — внутренний сервис контекста 2, который нужен только для внутреннего взаимодействия (например C -> D) и не используется извне никем.

Теперь перейдём к нарушениям принципа на схемах 3 и 4.

На этих схемах у контекста 2 оба микросервиса являются "публичными" — их использует кто-то извне. Согласно принципу: если мы зависим от одного из микросервисов контекста — мы должны зависеть от всех его публичных частей. На схеме 3 контекст 3 зависит только от одного микросервиса контекста 2, а на схеме 4 — такая же проблема у контекста 1. В этом и нарушение :) Т.е. контекст 2 перестает быть для внешнего мира цельным модулем, его начинают переиспользовать частями.

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

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

P.S. Спасибо Сергею — он оперативно добавил ADR с описанием принципа в каталог принципов проектирования, и планирует написать пример архитектурного теста на соблюдение данного принципа 🔥