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

С 2022 года я задаю индустрии один и тот же вопрос: насколько мелко нарезать? Сначала про микросервисы, потом про модули монолита и даже про команды и отделы. Теперь настало время приложить вопрос и принципы ответа на него к большим объёмам данных и поиску по ним. Здесь он звучит так: какого размера должен быть шард индекса.

Повод задуматься дал Яндекс. На конференции «Я про бэкенд» есть активность «2718» — system design наоборот. Задачи присылают зрители, жюри отбирает самую заковыристую, а решает её в прямом эфире инженер Яндекса: условие видит впервые, детали выспрашивает сам. Я не удержался и отправил свою.

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

Кому-то наверняка знакомо? :) Нарежешь мелко — утонешь в сетевых вызовах и накладных расходах. Нарежешь крупно — пара сервисов заберёт всю нагрузку, а любая переделка растянется на недели. Тот же баланс, что с микросервисами, только искать его надо на трёх уровнях сразу: размер шарда, размер сегмента внутри шарда и размер виртуального шарда (chunk'а или таблетки) — куска, которым данные переезжают с сервера на сервер, когда база выросла и её пора перераспределять. Переносить по целому шарду долго, по одному документу — бесконечно, так что и здесь нужен свой размер.

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

1. Чем сервис пожертвует первым, если нагрузка окажется выше расчётной — частью результатов, скоростью появления новых документов или временем ответа. Запроектировать этот порядок нужно заранее, до первой аварии.
2. По каким признакам архитектор поймёт, что нарезал неправильно. У микросервисов это могут быть повторы в трассировках, у шардов — например, доля запросов, в которых один шард не ответил вовремя.
3. При каких значениях этих признаков пора принимать решение о перепроектировании и перенарезке шардов.

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


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

3 октября, Москва и онлайн, бесплатно: регистрация

Продолжаю развивать свои архитектурные подходы и aact — мой открытый репозиторий для работы с архитектурой as code. Теперь хочу подключить к этому студентов и магистрантов: подал несколько проектов в AI Talent Hub ИТМО, которые можно начать на проектной практике и развить в диплом/ВКР под моим научным руководством.

Да, с прошлого года я ещё и научрук 🧑‍🎓

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

Из всего этого как раз и выросли темы проектов в рамках магистратуры:

- Архитектурный ИИ-ревьюер. Сравнить агента, который читает ADR, проверки по правилам в aact и их связку. То есть, что лучше — просто ИИ-агент, проверяющий PR'ы, декларативные автоматизированные тесты на архитектуру (aact) или и то, и другое в связке. В проекте нужно будет измерить пропущенные нарушения, ложные тревоги и повторяемость ответов в каждом из вариантов. А лучший вариант — реализовать в виде бота для GitHub. Он пригодится командам, у которых архитектурных договорённостей уже больше, чем архитектор удерживает в голове.

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

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

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

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

И ещё одна тема в мою любимую, но в сторону — нейросетевой движок для шахмат с кубиками. Я для них уже написал алгоритмический движок (по ночам 🌙), теперь хочется попробовать обучение нейросети игрой с самой собой ) Проверять силу нейросети будем на длинных сериях партий, чтобы отделить качество игры от везения.

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

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

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

Всех с началом учебного года 🍁

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо 🙏

🎙 На канале @another_sa вышел подкаст с моим участием [спасибо Андрей @and_burakov, что позвал. Зови ещё!]

Говорили про то, что я люблю больше всего: куда едут код-агенты, что будет с индустрией, как поедут наши роли и чему придётся доучиваться. Вышло и правда философски — местами улетали лет на десять вперёд.

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

💨 Несколько мыслей, которые я в подкасте накидываю на вентилятор

🤖 Код-агенты за полгода прыгнули так, что я сам не сразу поверил
Прошлым летом я по ночам пилил движок для своих шахмат с кубиками и упирался в тяжёлые расчёты на процессоре — мы с агентом неделями вылизывали профайлером каждый процент, и я его в итоге забросил. Вернулся весной, уже на новых моделях, — и агент даже не стал запускать код: подумал минут десять, прочитал кодовую базу, нашёл хвост рекурсии и применил математический алгоритм, которого я, честно, даже не знал (потом загуглил — действительно есть такой). Час работы — ускорение в 20 раз, и все тесты зелёные.
А ещё мы по согласованию с заказчиком сделали коммерческий проект целиком на агентах: ни строчки кода руками, два месяца — сдали и получили оплату. Классической командой людей было бы раза в два больше, а провозились бы минимум в полтора раза дольше.

🌱 От проектирования систем — к выращиванию среды.
Это моя главная ставка на будущее. Система — когда ты знаешь все компоненты и связи и держишь их в голове. Среда — когда их столько, что учитывать каждую связь бессмысленно, и ты работаешь на уровне законов: как гладь воды, где форму волны считаешь формулой, не отслеживая каждую молекулу. Архитектор здесь становится садовником — ставит свет, подвязывает, обрезает, а растение тянется само. И это не на самом деле уже сейчас не фантастика: k8s, автоскейлинг, FinOps — всё это отчасти уже имеет в себе элементы средового подхода (а не системного).
А SDD и harness для ИИ-агента — это вообще один в один оно и есть: ты не диктуешь строчки кода, а задаёшь законы, стимулы и фитнес-функции, по которым код вырастает сам. Как раз про это моя свежая статья, её в выпуске и разбираем: https://habr.com/ru/articles/1051722/

🧭 Языки программирования — временный костыль.

[Я это уже несколько лет говорю, а на этой неделе и Илон Маск сказал то же самое )) тут должен быть мем: я же говорил]

Python, Java, C# придумывали, чтобы код читал и писал человек. Уходит человек из цикла — костыль становится не нужен. Тут я всегда вспоминаю шахматный движок AlphaZero: он разгромил собственную прошлую версию именно потому, что его не кормили человеческими партиями — не досталось наших стереотипов «в дебюте ходи так». Следующий шаг — освободить и ИИ-агентов от наших языков и паттернов, пусть пишут на языке математики. Отсюда мой любимый тезис про джунов: джуны на Python/Java не нужны, а вот просто способные джуны — очень нужны. Только сажать их сразу в кабину экскаватора, а не учить сперва копать лопатой.

И одно наблюдение уже про нас самих: ИИ обещал разгрузить, а когнитивная нагрузка выросла. Раньше ты сильно думал, а потом отдыхал мозгом на механике — рисовал схемы, печатал код. Теперь всю механику забирает агент, и держать максимальную концентрацию приходится постоянно. К такому режиму пока не готов ни один из нас — впору вспоминать про медитацию 🧘‍♀️

Послушайте подкаст целиком (там ещё про отбор, ниши, схлопывание ролей, живые возражения ведущего и почему в код лучше не лезть руками): https://youtu.be/Wx1L69NihbM

Копаем дальше 🏗

В этом году я впервые был научруком в ИТМО ▪️ И я в очередной раз убедился, что преподавание для архитектора работает как супер-ускоритель насмотренности (писал об этом: https://t.me/rsa_enc/339). Приведу три примерчика, какие штуки в итоге получились у моих дипломников:

➡️ Сервис изучения английского на LLM. Самое вкусное там — каскадный пайплайн: большая внешняя модель занимается только коррекцией ошибок, а классификацию по 263 компонентам знаний делает дешёвый правило-ориентированный маршрутизатор. Качество обнаружения ошибок выше 90%, а время и стоимость запроса — кратно ниже, чем если загонять всё в одну большую западную LLM. Хорошее напоминание: стохастическое и детерминированное стоит разносить по разным компонентам. Продукт запущен: https://dreamlang.ru/ 🔥

➡️ Корпоративная платформа LLM-агентов: графовый оркестратор, структурированная генерация по Pydantic-схемам, доступ к инструментам через MCP. Интересный момент — экономика: автор посчитал, что отдельные сценарии автоматизации обходятся компании примерно в 13 млн в год, платформа — в 4,9 млн, а новый сценарий конфигурируется за 40 часов вместо 240–1600 часов разработки. Платформенная гипотеза с числами и сроком окупаемости — то, чего обычно так не хватает спроектированным архитектурам.
Продукт запущен во внутреннем контуре заказчика 🔥

➡️ Планировщик питания с ML: Java/Spring-микросервисы, Python ML-сервис за Apache Kafka, у каждого сервиса своя БД. Подбор рациона — целочисленное линейное программирование по базе из ~2700 рецептов, с учётом аллергенов и времени на готовку. Аккуратная классика микросервисной архитектуры 💎
Продукт запущен: https://meal-planner.ru/ 🔥

Это дипломы магистратуры AI Talent Hub в ИТМО, где я веду свой авторский курс по проектированию микросервисных архитектур, а теперь ещё и являюсь научруком ). Среди магистрантов, кстати, немало айтишников с опытом Яндекса, Озона и других бигтехов.

И важная новость — сейчас идёт последняя волна Junior ML Contest — конкурса, через который в эту магистратуру поступают бесплатно и без экзаменов: подаёте свой реальный AI/ML-проект (с работы, с хакатона, хоть собственный стартап), защищаете его на питчинге — и учитесь на бюджетном месте. Дедлайн — 20 июля включительно, времени в обрез 😅

Чем сильнее будут магистранты и их проекты — тем интереснее мне преподавать 😎

Условия JMLC-конкурса и подача заявок тут

Приходите сами и пересылайте друзьям с живыми ML-проектами. И как поступите — приходите на мой курс 😎

И напоследок — короткое видео с выпускного магистратуры, прошедшего совсем недавно 🚤

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

Ещё в школе, когда я только изучал Паскаль, мне казалось, что настоящий искусственный интеллект наступит тогда, когда программы начнут ошибаться (как и мы, люди — в этом одна из главных наших сильных способностей). Тогда бесило, что "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/
Буду рад вашим ➕ и 💬

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

В одном из прошлых постов я писал о том, что архитектура часто строится на вере:

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

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

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

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

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

Из этого факта обычно делают два противоположных и одинаково вредных вывода.

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

2️⃣. Раз доказательство невозможно, давайте сделаем вид, что возможно, обложимся метриками на каждый чих, заведём архитектурный комитет с формальными скорингами и будем называть это data-driven architecture.

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

Зависит от контекста

Начнём с главного свойства любого архитектурного аргумента: он контекстен (все же помнят коронную фразу архитекторов и анекдот про попугая 💃?)

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

Разберём на примере моего принципа каскадного снижения связанности:

Возьмём классическую пару: связанность и прочность, coupling и cohesion. Полвека индустрия повторяет мантру: связанность — плохо, прочность — хорошо. Low coupling, high cohesion. Но ведь и то и другое — это просто связи между элементами. Почему одна связь хорошая, а другая плохая?

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

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

Поэтому когда я говорю о доказательстве в архитектуре, я всегда имею в виду конструкцию из трёх частей:

1️⃣ требования — описание назначения (целей), гипотез, поведения и свойств системы;
2️⃣явный контекст, в котором сделаны требования;
3️⃣способ их проверить в этом контексте.

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

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

Я бы прям добавил такой пункт в формат ваших ADR — помимо обязательного описания контекста, в рамках которого принято решение; прописывать ещё и критерии и условия пересмотра (или устаревания) инженерного решения.

➡️ Продолжение следует.. в будущих постах продолжу тему доказательства и метрик в архитектуре

🎙 На 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

На дне открытых дверей ИТМО кратко рассказал про свой курс по проектированию микросервисной архитектуры (https://microservices.itmo.ru/)

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

Почему курс сейчас кажется мне ещё актуальнее, чем несколько лет назад?

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

То есть ровно то, чем и должна заниматься ИТ-архитектура.

В курсе есть теория, воркшопы и практика.

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

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

И главное — в разбор архитектуры конкретного проекта вникают все слушатели курса, а не только студенты группы.

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

А тут за один семестр слушатели курса могут посмотреть много разных архитектур, несколько раз пройти путь от идеи до схемы, а в конце — защитить своё решение и послушать защиты других. Услышать множество ответов на многочисленные «почему именно так?».

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

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

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

Полное видео дня открытых дверей:
🟥 СМОТРЕТЬ
🟦 CМОТРЕТЬ

Встречайте AACT 2.0 — большое обновление моего OpenSource-репозитория с инструментами для работы с архитектурой as Code!

Сегодня замержили большой PR #17: https://github.com/Byndyusoft/aact/pull/17 🐱

Только зацените: +16871 | -6444 🟩🟩🟩⬜️⬜️

Когда я впервые выкладывал aact, это был код и примеры к идее: раз архитектура у нас «as Code», почему бы не покрыть её тестами? Потом появились автогенерация, roadmap, справочник принципов и паттернов...
А теперь репозиторий сделал следующий большой шаг: aact превращается из набора примеров в полноценный инструмент — CLI + npm-пакет для проверки, анализа, генерации и частичного автоисправления архитектуры.

Команды CLI:

npx aact init
npx aact check
npx aact check --fix
npx aact analyze
npx aact generate

Что умеет:
🔘поддержка PlantUML и Structurizr
🔘набор проверок на соответствие принципам и паттернам проектирования: ACL, acyclic dependencies, API Gateway, CRUD-сервисы, database per service, cohesion > coupling, stable dependencies, common reuse principle
🔘запуск анализатора для подсчета архитектурных метрик и проверки принципа каскадного снижения связанности

Приятный бонус: часть нарушений теперь можно не только найти, но и автоматически поправить. Причём это не просто «заменить строку»: учитываются границы контекстов, соглашения по именованию (snake_case, camelCase, kebab-case), а правки пишутся обратно в PlantUML или Structurizr DSL.

Масштаб обновления: 77 коммитов, 139 файлов, 267 тестов. Огромное спасибо Сергею Волчкову @chs237 за такой вклад 🙌

Для меня это ещё один важный шаг к той самой идее: архитектурные договорённости должны жить не только в головах, слайдах и Confluence контекстном окне 😆, а проверяться в процессе разработки и ловиться ещё на этапе PR.

Как, я думаю, заметно — не удержался — и записал небольшое видео по использованию aact через консоль ) 📱🤪

Репозиторий: https://github.com/Byndyusoft/aact
PR: https://github.com/Byndyusoft/aact/pull/17

Как и всегда — рад вашим ⭐️ на 🐱, вопросам, Issues и PullRequest'ам. И самое ценное — очень буду признателен за пожелания по дальнейшим фичам и развитию инструментов в целом — кому чего не хватает, и чего хочется? ✍️
Пишите!

🎙 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). Самое интересное соберу в следующем посте 😌.
А ещё, если вдруг вы из Челябинска — приходите через месяц, в рамках доклада представлю данную стратегию в оффлайне 🐰

Погнали! 🚀

Вышел пилотный выпуск подкаста про ИИ в разработке, в котором я принимал участие 🎙 Говорили не про ИИ в SDLC в целом, а конкретно про проектирование архитектуры — ровно нашу тему 😋, которая иногда теряется пока все обсуждают генерацию кода.

Собрались вчетвером: ведущий Андрей Дмитриев (JUG Ru Group), Максим Смирнов (@it_arch), Андрей Бураков (@another_sa) и я.

Пара тем, которые хочется отдельно отметить 👇

🚀 Архитектурные метрики.
Тема, про которую я писал и выступал уже много раз — и метрики через покрытие архитектуры тестами, и принцип каскадного снижения связанности, и наш опенсорс-инструмент для подсчета архитектурных метрик.. И вот прямо сейчас та самая ситуация, когда то, чем занимался годами, на глазах становится в разы актуальнее! Собирать метрики стало заметно проще, а их важность взлетела 🤩
То, что раньше жило в голове архитектора на уровне «ну вроде паттерн нарушен, вроде нет», теперь без особых усилий проверяется тестами и ложится в цифры. Очень радует!

💾 ADR.
Последние годы архитектурные решения иногда воспринимались как бюрократия (особенно в некоторых процессах и компаниях 😉). А сейчас их ценность только растёт. У агентов короткая память — они не помнят, что семь лет назад вы уже пробовали вот так и откатились по вполне конкретным причинам. ADR — это ровно то, что завтра вы будете скармливать агенту, работающему с вашим проектом. Даже если сегодня они вам не особо нужны — пишите. Через год скажете себе спасибо 🤩

🧪 SDD (Spec-Driven Development).
Идея классная, реализация пока сыровата. Я ставил эксперимент со Spec Kit — дал ТЗ и дальше почти не вмешивался. MVP получил за четыре дня 🙂 Последние два, правда, вычищал баги уже руками. Главный вывод для себя такой: спецификации, которые LLM генерит сама для себя, без человека в цикле начинают накапливать ошибку как снежный ком. Где-то это ломается раньше, где-то позже, но ломается.

А что по этим вопросам думают Максим, Андрей и Андрей — можно послушать в самом выпуске:

https://www.youtube.com/watch?v=IQ6zFeYDXd8
или на Rutube