Несколько ночей я провёл в вайбе за совместным с ИИ программированием (в платной IDE — то есть в нормальном режиме парного программирования, а не копи‑паста в чатбот).
В целом, я уже лет 5 как не пишу код (кроме изредка опенсорса).. И вот что хочу сказать — такого азарта я не ощущал уже лет 20! Помню, как после универа садишься «на пару часов» за комп... и обнаруживаешь себя в 5 утра не отходившим от тогда ещё совсем неплоского монитора🤓
Конечно, всё зависит от задачи. Азарт быстро садится, когда первый этап pet‑проекта пройден, и начинается рутина: загрузки, парсеры, сериализация, кэширование, инфраструктура… всё нужное, но скучное. Уже не пишешь самую мякотку — алгоритм, визуал или физику идеи. А лепишь обвязку.
Так вот! С ИИ, как я уже много раз говорил, человеку остаются только человечные задачи — задачи, требующие искры идеи, мысли, озарения! А всю остальную обвязку на себя возьмёт ИИ. Скорость разработки взлетает, азарт возвращается с новой силой, ведь теперь ты воплощаешь более смелые и сложные идеи , проверяешь гипотезы и получаешь фидбек, можешь быстро в одного реализовать гораздо более масштабный проект! Переходить к следующимбелковым человеческим задачам своей мега идеи!
Наверное, без примера меня понять сложно. Я — старый шахматист и азартный игрок. Так вот, по ночам я пишу ради интереса компьютерный движок (алгоритмический, не нейросеть) для вероятностной версии шахмат.
Ещё с универа я мечтал создать разные версии шахматных движков (с разными алгоритмами мышления и конфигурациями оценки позиций) и заставить их играть между собой, тем самым выявляя сильнейшего и развивая его дальше. Но всё разбивалось об нехватку времени и лень — слишком много скучного, но нужного кода надо было бы писать.
Так вот. С помощником в виде ИИ я могу лишь генерировать идеи, направлять, думать и смотреть результаты! Больше не нужно самому писать движок доски, I/O, тесты.. и даже больше — я лишь формулирую идеи алгоритмов, прошу добавить кэш уже оценённых позиций, просчитать ходы вперёд! И даже более сложные вещи — например, я пишу: "добавь альфа-бета отсечение для ускорения оценки позиции", и ИИ меня понимает и правильно реализует этот алгоритм применительно ко всему остальному имеющемуся коду!
Азарт только нарастает, двигаться удаётся семимильными шагами, и вчера ночью я впервые проиграл своему детищу!🤩
При этом я вовсе не хочу сказать, что ИИ заменит программистов (по крайней мере не всех😂 ) если бы я не умел программировать — ничего бы не получилось. Естественно ИИ ошибается. Иногда нужно смотреть его код, поправлять и направлять, подсказывать, просить отрефакторить.. Плюс даже в такой известной игре как шахматы — он далеко не эксперт.
На мой взгляд, для эффективной реализации проекта с ИИ в виде программиста нужны две вещи — глубокое понимание предметной области (идеи) проекта и хорошие навыки программирования и использования инструментов . В такой связке ИИ на порядок увеличивает производительность и возвращает детский азарт отпрограммирования реализации своих идей и концепций.
P.S. Один умный мужик в твиттере еще до мейнстрима (года два назад) сказал, что "лучший язык программирования — английский!" (читай — человечий). Всё именно так — я общаюсь с ИИ на русском, редко что-то дописываю сам на C#. Но есть ощущение, что понимая структуры данных, мне уже сложно на русском формулировать чего хочу. В уме абстрактно я понимаю как оптимизировать сложную структуру нескольких вложенных массивов и хэшсетов и примерно написать это на LINQ.. я уверен, что ИИ меня бы понял с его уровнем владения и русским, и C#.. Но вот выразить это в виде промпта на русском иногда бывает достаточно сложно.
Думаю, в ближайшее время я точно перейду на некую смесь русского с LINQ ))
P.P.S. Все эксперименты и рассуждения проводились на основе не очень большого pet-проекта (~8K строк кода), для которого нестрашно, что код будет отправляться на забугорные сервера
ИИ не убивает программирование, он делает его великим и интересным снова, возвращает его ностальгический вайб!😃
Делает его снова нашим!
В целом, я уже лет 5 как не пишу код (кроме изредка опенсорса).. И вот что хочу сказать — такого азарта я не ощущал уже лет 20! Помню, как после универа садишься «на пару часов» за комп... и обнаруживаешь себя в 5 утра не отходившим от тогда ещё совсем неплоского монитора
Конечно, всё зависит от задачи. Азарт быстро садится, когда первый этап pet‑проекта пройден, и начинается рутина: загрузки, парсеры, сериализация, кэширование, инфраструктура… всё нужное, но скучное. Уже не пишешь самую мякотку — алгоритм, визуал или физику идеи. А лепишь обвязку.
Так вот! С ИИ, как я уже много раз говорил, человеку остаются только человечные задачи — задачи, требующие искры идеи, мысли, озарения! А всю остальную обвязку на себя возьмёт ИИ. Скорость разработки взлетает, азарт возвращается с новой силой, ведь теперь ты воплощаешь более смелые и сложные идеи , проверяешь гипотезы и получаешь фидбек, можешь быстро в одного реализовать гораздо более масштабный проект! Переходить к следующим
Наверное, без примера меня понять сложно. Я — старый шахматист и азартный игрок. Так вот, по ночам я пишу ради интереса компьютерный движок (алгоритмический, не нейросеть) для вероятностной версии шахмат.
Ещё с универа я мечтал создать разные версии шахматных движков (с разными алгоритмами мышления и конфигурациями оценки позиций) и заставить их играть между собой, тем самым выявляя сильнейшего и развивая его дальше. Но всё разбивалось об нехватку времени и лень — слишком много скучного, но нужного кода надо было бы писать.
Так вот. С помощником в виде ИИ я могу лишь генерировать идеи, направлять, думать и смотреть результаты! Больше не нужно самому писать движок доски, I/O, тесты.. и даже больше — я лишь формулирую идеи алгоритмов, прошу добавить кэш уже оценённых позиций, просчитать ходы вперёд! И даже более сложные вещи — например, я пишу: "добавь альфа-бета отсечение для ускорения оценки позиции", и ИИ меня понимает и правильно реализует этот алгоритм применительно ко всему остальному имеющемуся коду!
Азарт только нарастает, двигаться удаётся семимильными шагами, и вчера ночью я впервые проиграл своему детищу!
При этом я вовсе не хочу сказать, что ИИ заменит программистов (по крайней мере не всех
На мой взгляд, для эффективной реализации проекта с ИИ в виде программиста нужны две вещи — глубокое понимание предметной области (идеи) проекта и хорошие навыки программирования и использования инструментов . В такой связке ИИ на порядок увеличивает производительность и возвращает детский азарт от
P.S. Один умный мужик в твиттере еще до мейнстрима (года два назад) сказал, что "лучший язык программирования — английский!" (читай — человечий). Всё именно так — я общаюсь с ИИ на русском, редко что-то дописываю сам на C#. Но есть ощущение, что понимая структуры данных, мне уже сложно на русском формулировать чего хочу. В уме абстрактно я понимаю как оптимизировать сложную структуру нескольких вложенных массивов и хэшсетов и примерно написать это на LINQ.. я уверен, что ИИ меня бы понял с его уровнем владения и русским, и C#.. Но вот выразить это в виде промпта на русском иногда бывает достаточно сложно.
Думаю, в ближайшее время я точно перейду на некую смесь русского с LINQ ))
P.P.S. Все эксперименты и рассуждения проводились на основе не очень большого pet-проекта (~8K строк кода), для которого нестрашно, что код будет отправляться на забугорные сервера
ИИ не убивает программирование, он делает его великим и интересным снова, возвращает его ностальгический вайб!
Делает его снова нашим!
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥33❤18🤓5💯1
Media is too big
VIEW IN TELEGRAM
Чем ближе сентябрь — тем больше подписчиков меня спрашивают..
И вот наконец спешу сообщить, что уже совсем скоро стартует очередной, как и каждый год обновленный, мой авторский курс по проектированию микросервисной архитектуры!
Как и последние несколько лет курс будет запущен в рамках магистратуры ИТМО, но будет открытым и выборным для магистрантов партнёрских программ, ВУЗов и компаний.
И что особенно может быть актуально читателям канала — как и в прошлом году, обучение на курсе можно будет приобрести отдельно, не поступая в магистратуры и т.д.
В прошлом году это стоило 75 тыс. руб, в этом году цена и подробности будут чуть позже, пока просто напишите мне в личку (@razonrus), что этим заинтересовались.
🔜 Старт — уже 15 сентября!
Курс состоит из лекций, воркшопов и практики. В этом году курс пополнится последними изысканиями по предлагаемому мной принципу каскадного снижения связанности (лендинг скоро актуализируем: https://microservices.itmo.ru/).
Основная программа курса:
1. Шаблоны интеграции приложений
2. Зачем бизнесу микросервисы.
Распил монолита на микросервисы
3. Управление мастер-данными в микросервисной архитектуре
4. Воркшоп по проектированию архитектуры с нуля
5. Распределенные транзакции. Оркестратор бизнес-процессов. BPMN
6. Гранулярность микросервисов
7. Рефакторинг микросервисной архитектуры
8. Отказоустойчивость / Fault tolerance
9. Архитектура as Code. Автоматизация и покрытие архитектуры тестами
Оставляйте заявку мне, и вам чуть позже напишут из ИТМО✏️
Всех с осенью! 🍁
И вот наконец спешу сообщить, что уже совсем скоро стартует очередной, как и каждый год обновленный, мой авторский курс по проектированию микросервисной архитектуры!
Как и последние несколько лет курс будет запущен в рамках магистратуры ИТМО, но будет открытым и выборным для магистрантов партнёрских программ, ВУЗов и компаний.
И что особенно может быть актуально читателям канала — как и в прошлом году, обучение на курсе можно будет приобрести отдельно, не поступая в магистратуры и т.д.
В прошлом году это стоило 75 тыс. руб, в этом году цена и подробности будут чуть позже, пока просто напишите мне в личку (@razonrus), что этим заинтересовались.
Курс состоит из лекций, воркшопов и практики. В этом году курс пополнится последними изысканиями по предлагаемому мной принципу каскадного снижения связанности (лендинг скоро актуализируем: https://microservices.itmo.ru/).
Основная программа курса:
1. Шаблоны интеграции приложений
2. Зачем бизнесу микросервисы.
Распил монолита на микросервисы
3. Управление мастер-данными в микросервисной архитектуре
4. Воркшоп по проектированию архитектуры с нуля
5. Распределенные транзакции. Оркестратор бизнес-процессов. BPMN
6. Гранулярность микросервисов
7. Рефакторинг микросервисной архитектуры
8. Отказоустойчивость / Fault tolerance
9. Архитектура as Code. Автоматизация и покрытие архитектуры тестами
Оставляйте заявку мне, и вам чуть позже напишут из ИТМО
Всех с осенью! 🍁
Please open Telegram to view this post
VIEW IN TELEGRAM
4🔥17👍5❤1🙏1
Media is too big
VIEW IN TELEGRAM
🌀 Языки программирования уходят в прошлое 😎
Код — это костыль. Языки придумали не потому, что они нужны машине, а потому что они нужны человеку. Человек не способен оперировать нулями и единицами, не может держать в голове гигантские структуры. Поэтому и появились Python, Java, C#, SQL... Это интерфейсы для нашего мозга, чтобы было хоть как-то удобно.🧠
Но у этого «синтаксического сахара» есть цена — рамки и ограничения. Язык заставляет подстраиваться под синтаксис, бороться с багами и уязвимостями. Машине всё это не нужно. Ей не нужен Python. Ей не нужен C++. Ей вообще не нужен язык как таковой.🎞
Что происходит прямо сейчас? LLM получает задачу на человеческом языке, обрабатывает её в своей внутренней математике — вектора, коэффициенты, абстрактные представления — и только ради нас переводит результат в «человеческий» код: «смотри, вот тебе Python, узнаёшь?». Но это лишь переходный этап.
Ну и это вынужденный переходный этап, т.к. пока LLM-ки обучились как раз на языках программирования — "промежуточных" инструментах, на котором человеком создан и накоплен большой опыт кодовой базы. Ключевое здесь — человеком! К примеру, когда в шахматах AlphaZero освободили от всего человеческого опыта — он(-о, -а) разгромил в пух и прах AlphaGo, обученную на миллионах человеческих шахматных партий и являющейся на тот момент сильнейшей шахматной нейросетью.
Как когда-то машинный перевод перескочил от «русский→английский» к «русский→внутренний язык модели→английский», так и программирование перейдёт от «задача→Python» к «задача→внутренний язык модели→машинный код». Без посредников. Без лишнего синтаксиса.
И это отличная новость. Потому что вместе с уходом языков уходит и рутина. Человеку наконец-то достанутся действительно человеческие задачи — аналитика, постановка целей, поиск новых решений, творчество и ответственность. Всё то, что машины за нас не сделают.
Так уже было много раз: калькулятор снял с нас ручной счёт, экскаватор заменил лопату, интернет — библиотеки. Каждый раз казалось, что «всё пропало», а на деле освобождалось место для большего.
То, что мы называем «будущим», на самом деле уже наступило.
И это будущее — гораздо более человеческое.🤩
Код — это костыль. Языки придумали не потому, что они нужны машине, а потому что они нужны человеку. Человек не способен оперировать нулями и единицами, не может держать в голове гигантские структуры. Поэтому и появились Python, Java, C#, SQL... Это интерфейсы для нашего мозга, чтобы было хоть как-то удобно.
Но у этого «синтаксического сахара» есть цена — рамки и ограничения. Язык заставляет подстраиваться под синтаксис, бороться с багами и уязвимостями. Машине всё это не нужно. Ей не нужен Python. Ей не нужен C++. Ей вообще не нужен язык как таковой.
Что происходит прямо сейчас? LLM получает задачу на человеческом языке, обрабатывает её в своей внутренней математике — вектора, коэффициенты, абстрактные представления — и только ради нас переводит результат в «человеческий» код: «смотри, вот тебе Python, узнаёшь?». Но это лишь переходный этап.
Ну и это вынужденный переходный этап, т.к. пока LLM-ки обучились как раз на языках программирования — "промежуточных" инструментах, на котором человеком создан и накоплен большой опыт кодовой базы. Ключевое здесь — человеком! К примеру, когда в шахматах AlphaZero освободили от всего человеческого опыта — он(-о, -а) разгромил в пух и прах AlphaGo, обученную на миллионах человеческих шахматных партий и являющейся на тот момент сильнейшей шахматной нейросетью.
Как когда-то машинный перевод перескочил от «русский→английский» к «русский→внутренний язык модели→английский», так и программирование перейдёт от «задача→Python» к «задача→внутренний язык модели→машинный код». Без посредников. Без лишнего синтаксиса.
И это отличная новость. Потому что вместе с уходом языков уходит и рутина. Человеку наконец-то достанутся действительно человеческие задачи — аналитика, постановка целей, поиск новых решений, творчество и ответственность. Всё то, что машины за нас не сделают.
Так уже было много раз: калькулятор снял с нас ручной счёт, экскаватор заменил лопату, интернет — библиотеки. Каждый раз казалось, что «всё пропало», а на деле освобождалось место для большего.
То, что мы называем «будущим», на самом деле уже наступило.
И это будущее — гораздо более человеческое.
Please open Telegram to view this post
VIEW IN TELEGRAM
10👍24🤡18❤7🔥6💯2
И вот о чём думаю.
Да, мы все видим, что ИИ уже умеет писать код. Иногда даже такой, что работает
Тем не менее, направление очевидно: чем больше скучной рутины ИИ будет снимать с нас, тем сильнее мы будем сдвигаться в сторону более высоких уровней абстракции, как в прочем и было на протяжении всей истории развития ИТ. Вопрос в том, изменится ли роль ИТ-архитектуры в этот очередной скачкообразный сдвиг.
Думаю, что архитектура наконец-то уже окончательно поднимется на уровень выше и уйдёт от непосредственно кода (его паттернов и принципов), что уже сейчас происходит. А если говорить про горизонт 5-10 лет — может быть, даже выше уровня систем. Кто знает, возможно, реально придётся переходить от «системного» подхода к «средовому», а там и до «сферного» рукой подать (писал об этом выше: https://xn--r1a.website/rsa_enc/376).
Так что мой доклад — это не про то, как «ИИ всех уволит» или «роботы всё сделают за нас». А скорее про то, как мы, архитекторы, в будущем будем меньше спорить о размере микросервиса и больше думать об уникальной структуре продукта, законах по которым он растёт, развивается и встраивается в различные ИТ-экосистемы.
Но чтобы попробовать смоделировать будущее — не обойтись без попытки вычленить базовые смыслы в настоящем. Применительно к нашей теме — я начну с попытки выделения истинной роли ИТ-архитектуры сейчас, которая перетечёт но несильно изменится и в дальнейшем.
Давайте порассуждаем, чуть подробнее
Если сейчас архитектура в том числе нужна для борьбы со сложностью:
- чтобы большая система была доступна для понимания и "умещалась" в голове архитектора,
- и чтобы разработчик мог разобраться в коде и внести изменения, не сломав себе мозг и всё предыдущее проекту..
то в эру написания кода ИИ всё это станет уже не столь актуальным.
К примеру, возможно станет уже необязательно соблюдать принципы и паттерны, любой запутанный код будет всё равно понятен ИИ, лёгок для тестирования и модификации им.
А ещё, такой запутанный с человеческой точки зрения код (или последовательность вызовов) может быть быстрее оптимальнее и "ближе" для ИИ; и кто сказал, что он должен быть написан на высокоуровневом языке программирования, которые создавались больше для людей, нежели чем для компьютеров (см. мой прошлый провокационный пост https://xn--r1a.website/rsa_enc/382
Ещё раз. Я хочу сказать о том, что функция борьбы со сложностью, как одна из основных задач ИТ-архитектуры, никуда не денется — но она скорее всего перейдёт на новый уровень, поднимется сильно выше уровня кода и простых атомарных взаимодействий между сервисами, что позволит нам делать ещё более крутое и всеобъемлющее ПО. Как выше и писал — возможно, выйти с уровня программных систем и экосистем, на уровень сфер (перейти от системного подхода в ПО к следующему — сферному).
Одна из мыслей доклада — ИТ перестаёт развиваться отдельно, и встаёт на одни рельсы с развитием всех технологий. Для ИТ наконец-то начинают работать парадигмы и законы, по которым развивался и развивается прогресс в других более древних сферах человеческой деятельности.
В итоге архитектор станет программистом снова (точнее все программисты станут архитекторами — смотря с какой стороны смотреть), т.к. создавать ПО становится снова весело кайфово быстро и азартно
А азарт — это главный предвестник будущего
Ну и чтобы пост не выглядел слишком пафосным, добавлю прозаичности (но истинной):
Буду рад всех увидеть 17 октября на своём докладе на балтийских берегах в прекрасном Янтарь-холле в Светлогорске
https://baltic2025.mergeconf.ru/speakers/development/backend/safin
Промокод на скидку 20% для подписчиков канала: SAFIN
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤4🔥3
Перезалил на Rutube одно из первых своих выступлений на больших конференциях — почти ровно 4 года назад на Highload'е рассказал как проектировать и строить распределенную архитектуру без боли и оглядки на количество микросервисов.
Я говорил о факторах, реализация которых позволяет снизить накладные трудозатраты на каждую новую точку деплоя практически до нуля. И, на мой взгляд, все эти факторы актуальны и сейчас — что-то уже стало стандартом для отрасли и даже ушло в глубь инструментов так, что мы об этом не задумываемся в явном виде; а о чём-то до сих пор нужно помнить явно.
Я говорил о следующем:
1️⃣ Шаблоны репозиториев
2️⃣ Визуализация архитектуры
3️⃣ Автообнаружение
4️⃣ CI/CD Pipeline
5️⃣ Окружения по требованию
6️⃣ Процесс проектирования и разработки
7️⃣ Observability
Вдвойне приятно, что спустя годы я понимаю, что не ошибся — всё о чём говорил, действительно сработало и нашло подтверждение в отрасли🚀
https://rutube.ru/video/68da03b2f8cb3e104e9f6d219fd91fc7/
Я говорил о факторах, реализация которых позволяет снизить накладные трудозатраты на каждую новую точку деплоя практически до нуля. И, на мой взгляд, все эти факторы актуальны и сейчас — что-то уже стало стандартом для отрасли и даже ушло в глубь инструментов так, что мы об этом не задумываемся в явном виде; а о чём-то до сих пор нужно помнить явно.
Я говорил о следующем:
Вдвойне приятно, что спустя годы я понимаю, что не ошибся — всё о чём говорил, действительно сработало и нашло подтверждение в отрасли
https://rutube.ru/video/68da03b2f8cb3e104e9f6d219fd91fc7/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍5✍2❤1
Всем привет!
Давно не писал про обновления (а они есть!) репозитория с инструментарием для работы с Архитектурой "as Code" — обещаю исправиться в ближайшее время☺️
А пока хочу рассказать, что репозиторий прошёл отбор в финальное голосование OpenSource трибуны на HighLoad++❗️
Победителям голосования будет представлена возможность представить свои решения на широкую публику на крупнейшей ИТ-конференции в России🤩
Если вам интересен мой OpenSource проект — находите его в списке:
и поддержите голосом, чтобы у ещё большего числа людей был шанс с ним познакомиться:
https://opensource.highload.ru/vote 😊
Для голосования нужно авторизоваться через емаил или ВК🗳
upd: а для тех, кто ещё вдруг с проектом не знаком — скопирую сюда краткое описание:
Давно не писал про обновления (а они есть!) репозитория с инструментарием для работы с Архитектурой "as Code" — обещаю исправиться в ближайшее время
А пока хочу рассказать, что репозиторий прошёл отбор в финальное голосование OpenSource трибуны на HighLoad++
Победителям голосования будет представлена возможность представить свои решения на широкую публику на крупнейшей ИТ-конференции в России
Если вам интересен мой OpenSource проект — находите его в списке:
«Инструменты для работы с AaC (архитектурой «as code»)
AACT (Architecture As Code Tools)»
и поддержите голосом, чтобы у ещё большего числа людей был шанс с ним познакомиться:
https://opensource.highload.ru/vote 😊
Для голосования нужно авторизоваться через емаил или ВК
upd: а для тех, кто ещё вдруг с проектом не знаком — скопирую сюда краткое описание:
AACT (Architecture As Code Tools) — набор инструментов и практик для работы с архитектурой,
представленной в формате «as Code». Основная фишка — это автоматическое тестирование
архитектурной схемы реальному положению вещей на проде (или любом другом окружении),
а также покрытие тестами проверки соответствия архитектуры принятым принципам и паттернам.
Основные цели проекта:
• устранить неактуальность архитектурных схем, которые быстро устаревают относительно
кода и конфигураций IaC;
• повысить декларативность архитектур — не просто зафиксировать «что», но и кодом тестов
формализовать «почему»;
• ввести контроль над соблюдением архитектурных принципов (паттернов, договорённостей)
непосредственно в процессе разработки;
• обеспечить обратную связь об архитектурных проблемах уже на этапе PR (сборки ветки в CI/CD),
чтобы архитектурные нарушения ловились до слияния веток.
Возможности проекта и примеры использования:
• микросервисные архитектуры (REST, gRPC, kafka, Rabbit, ...);
• модульные монолиты.
Ваша архитектура может быть описана при помощи:
• PlantUML,
• Structurizr.
Информация об архитектурных зависимостях может браться из:
• IaC (yaml-файлы для kubernetes),
• исходный код.
AACT делает архитектуру живой, актуальной и контролируемой, устраняя разрыв между
диаграммами и кодом.
Please open Telegram to view this post
VIEW IN TELEGRAM
10🔥13👍6❤2🤮1
Выступил на конференции в Светлогорске с совсем нетипичным для себя мене практическим, но более прогностическим и даже философским докладом:
Ранее при подготовке к выступление писал о том, что хочу рассказать, и вот наконец "релиз" состоялся😎
Всё прошло отлично — переполненный зал, много вопросов и в зале, и потом в коридорах.. Народ подходил и просто пожать руку, поблагодарить за доклад😇
Записи к сожалению не было — поэтому придётся теперь писать статью по теме выступления😅
Выложу комментарием пока хотя бы слайды
Будущее ИТ-архитектуры и работы ИТ-архитекторов
Ранее при подготовке к выступление писал о том, что хочу рассказать, и вот наконец "релиз" состоялся
Всё прошло отлично — переполненный зал, много вопросов и в зале, и потом в коридорах.. Народ подходил и просто пожать руку, поблагодарить за доклад
Записи к сожалению не было — поэтому придётся теперь писать статью по теме выступления
Выложу комментарием пока хотя бы слайды
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥16👍4❤3😢1
Если все твои компетенции в ИТ (да и на самом деле в любой другой профессии) устаревают — это не значит, что «мир слишком быстро меняется».
Это значит, что ты не докопался до сути, корневых постулатов и методологий в своей деятельности.
Значит, что скорее всего ты понимаешь профессию на уровне инструментов, а не на уровне принципов.
К примеру, ты освоил конкретный свойственный лишь настоящему времени фреймворки, а не основания, не меняющиеся десятилетиями.
Когда человек опирается только на инструменты — он неизбежно устаревает. Фреймворки меняются, языки обновляются, аббревиатуры становятся неактуальными быстрее, чем ты успеваешь обновить резюме.
Ты учишься пользоваться кистью — вместо того чтобы учиться рисовать.. Понимаешь как, но не почему..
Если твои знания обесцениваются каждый год — это не профессионализм, а временный навык специалиста.
Тогда в программировании тебя можно будет заменить новой библиотечкой, моделью, агентом или плагином — потому что, грубо говоря, ты и сам в таком случае всего лишь плагин к некой системе деятельности, которую не понимаешь.
Да, звучит жёстко. Но это не упрёк — настоящие компетенции не стареют!
Меняются оболочки, протоколы, синтаксис — но не логика.
Архитектор, который понимает принципы системного (а ещё лучше средового или даже сферного
Педагог, который понимает, как учится мозг, будет нужен и в метавселенной.
Истинная архитектура, инженерия, логика построения систем (любых) не зависят от того, какой сегодня год — 1975 или 2025.
А человек, который просто знает, куда кликать — исчезнет с апдейтом ИИ 6.2.7
Когда говорят «всё так быстро устаревает» — спорно.
Нет, не всё.
Устаревает то, что было поверхностным.
То, что ты изучал как инструкцию, а не как структуру и принципы её работы; то, что ты сам не прожил как идею, не пропустил через себя 🧘
То, что ты выучил из туториала, а не из собственного опыта осмысления.
Любая профессия — это как шахматы
Можно учить дебюты, можно учить комбинации — но пока ты не поймёшь принцип позиций — ты не игрок, ты репликатор заученных ходов.
И вот главный парадокс:
чем быстрее вокруг меняется всё, тем больше понимаешь, что смена инструментов перестаёт пугать.
И если ты, условно, "на правильном пути" — твоё понимание меняется вместе с миром, а не пытается судорожно его догнать.
И тогда устаревают не твои компетенции — а всё вокруг, что уже не нужно.
Что думаете?
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍29🔥11❤10❤🔥1💯1
Вообще, я не очень люблю интервью:
слишком часто их превращают в чек-листы —
«как стать архитектором»,
«что должен знать архитектор»,
«10 ошибок начинающего архитектора».
Но в этот раз разговор получился про суть — про то, что вообще происходит с IT и как сфера будет развиваться дальше.
Как и у многих, мой путь начался с кода.
13 лет писал, руководил командами, решал конкретные задачи.
Постепенно стало интересно не “что написать”, а “как и почему именно так”.
И вот тут начинается архитектура — когда перестаёшь думать строчками кода и начинаешь думать компонентами.
Но, если честно, как я ранее уже писал — сегодня и это разделение уже стирается.
ИИ скоро будет писать код лучше, чем большинство людей.
И если раньше архитектор мог сказать: «Это будет слишком долго и дорого реализовать», то теперь ИИ спокойно скажет: «вот моя стоимость месячного тарифа, хватит пары недель работы в паре».
И твоя роль смещается с реализации ещё больше в сторону понимания, что именно лучше подойдёт бизнесу и как это встроить в текущий ландшафт.
В интервью я повторил мысль, которая для меня сейчас ключевая:
ИИ не “заменит” программистов — он заменит процесс написания кода.
Пока мы заставляем его писать, например, на Python'е, он выглядит как человек.
Но у него нет нужды писать на Python'е или любом другом языке — это ведь наши инструменты, не его.
Он не мыслит синтаксисом, он мыслит математикой.
В какой-то момент ИИ перестанет «писать», он будет просто проектировать исполнение задачи.
И тогда архитектура снова поднимется на уровень выше — не над кодом, а над интеллектами, над экосистемами.
Но об этом тоже уже было в постах выше.
🧩 Про архитектуру как код
Я показал в интервью, как у нас построен подход:
вся архитектура описана как код — в Structurizr или PlantUML, всё хранится в git.
Архитектурные схемы проверяются автоматическими тестами на консистентность и соблюдение принципов.
Если продакшен и архитектура разошлись — тест падает.
Никаких “архитектура лежит в Confluence, но уже неактуальна”.
Это и есть архитектура XXI века — не документ, а часть проекта, часть кода.
Старый стереотип — архитектор это “человек, который всем мешает жить”.
Но на самом деле, одна из главных задач хорошего архитектора — это организация эффективной коммуникации между разработчиками, бизнесом и разработчиками, и даже бизнесом и бизнесом.
Он умеет укрощать сложность, построить простые модели сложных процессов, и объяснить это наглядными схемами так, чтобы у всех в головах сложилась единая общая картинка.
Архитектор не должен быть “самым умным”.
Он должен быть тем, кто видит всю систему целиком.
В этом смысле — это профессия про системность и понимание образов мышления, а не про технический менеджмент.
Когда игровая нейросеть AlphaZero перестала учиться шахматам на человеческом опыте и начала учиться и играть сама — произошёл революционный рывок в силе игры в шахматы.
То же самое сейчас происходит в инженерии:
ИИ перестаёт “копировать людей” и начинает искать свои закономерности.
А мы — остаёмся на уровне созидания, целеполагания и смысла.
Проектировать, интерпретировать и выстраивать баланс.
И вот это, по-моему, главная мысль интервью:
ИИ меняет то, как мы думаем об инженерии,
но не меняет того, зачем она нужна.
Если твоя ценность в том, что ты “знаешь фреймворки” — ИИ обгонит тебя.
Если твоя ценность в том, что ты понимаешь систему — он станет твоим инструментом.
Архитектура — это не про контроль, не про технический менеджмент, не про стандарты.
Это про развитие, стабильность и смысл.
Про умение видеть, как всё связано и насколько это применимо.
И именно это делает профессию архитектора по-настоящему вечной
P.S. Фото взял с другого недавнего интервью
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17💅4👍2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
1/2
🧩 Микросервисы в оргструктуре компании: работает ли эта аналогия?
Недавно у меня был размеренный и длинный разговор с другом-предпринимателем. Он задал, казалось бы, простой вопрос:
Чем больше мы обсуждали — тем интереснее становилась картина. Делюсь самыми полезными кусками.
⚡️ ⚡️ ⚡️ ⚡️ ⚡️ ⚡️ ⚡️ ⚡️
🎯 Контекст: компания растёт, продуктов много, отделов ~20
У друга — бизнес, который делает разные продукты в больших количествах: производство, бренды, маркетинг, склад, реклама, закупки, дизайн и т. д. Чтобы вывести новый продукт, нужно участие кучи отделов — иногда последовательно, иногда параллельно.
Пока выпускаешь 1–2 продукта в месяц, можно дирижировать вручную.
Но вопрос непростой:
как сделать так, чтобы компания могла выпускать 10? 100? 1000 продуктов в месяц?
И не умереть под завалами задач.
🧠 Кажется логичным: а давайте строить оргструктуру «как микросервисы»?
Сергей сформулировал метафору:
- каждый отдел — это по сути «микросервис»
- на входе — задачи из разных частей компании
- каждый «сервис» делает своё маленькое, но важное дело
- хочется, чтобы система была масштабируемая, гибкая, без «архитектурного долга»
(когда отделы созданы из локальной логики, а потом не складываются в общую систему)
Идея выглядит привлекательно. Но…
⚠️ Проблема №1: микросервис можно масштабировать, человека — нет
Моя первая реакция была простая:
Под обратным применением я подразумевал вывернутый наизнанку процесс — обычно ведь мы в ИТ-системах пытаемся построить упрощенную модель мира, и под неё подстраиваем ИТ-процессы и ограничения. Но вот наоборот — не факт, что сработает.
В ИТ можно разделить систему на 200 микросервисов — и не нанять 200 человек.
В компаниях и операционных процессах так не работает.
Лирическое отступление: если что, я не являюсь последователем "1 микросервис — 1 разработчик (или даже 1 микросервис — 1 команда)", а даже являюсь противником такого подхода, вносящего дополнительные ненужные ограничения прежде всего на ту же гранулярность. К примеру, у меня был проект с 5 разработчиками на 60 микросервисов — и это нормально🙂
⚠️ Из первой проблемы логическим следствием вытекает вторая:
оргструктура и ИТ-архитектура должны быть независимы
Когда анализируешь энтерпрайз-архитектуру крупного предприятия — это важное правило почти всегда нарушается. Рано или поздно, в большем или меньшем объёме, но устройство человеческих отделов компании, их операционных процессов протекает и в архитектурные схемы, разделение ответственностей между системами и необоснованные барьеры и границы
Странно будет предполагать, что допустив обратное влияние: ИТ-архитектуры на оргструктуру компании, мы получим хороший результат — слишком разные процессы и правила игры в этих двух мирах.
Но речь всё же чуть о другом — в компании нет идеальной автоматизорованной айтишечки, которую надо "переложить" на людей. Скорее в целом стандартные методы управления перестают работать, и идёт логичный поиск новых парадигм во всех возможных смежных сферах.
⚡ И вот на таком высоком уровне аналогия, кажется, всё же работает!
И тут мы нашли точку пересечения: уровень теории систем, ну или графов, или связанности-связности (прочности).
Я недавно писал об этом при рассмотрении перекладывания моего принципа каскадного снижения связанности на реальную жизнь:
- внутри отдела — высокая прочность
- между отделами — минимальная связанность
- если постоянно «бегают между этажами» — структура неправильная
То есть принципы модульности, низкой связанности и высокой прочности действительно применимы к оргструктуре, но не 1-в-1 как в коде и архитектуре.
🤖 Дальше интереснее...
⬇️ продолжение⬇️
Недавно у меня был размеренный и длинный разговор с другом-предпринимателем. Он задал, казалось бы, простой вопрос:
а можно ли применить принципы микросервисной архитектуры ПО при проектировании оргструктуры компании?
Чем больше мы обсуждали — тем интереснее становилась картина. Делюсь самыми полезными кусками.
У друга — бизнес, который делает разные продукты в больших количествах: производство, бренды, маркетинг, склад, реклама, закупки, дизайн и т. д. Чтобы вывести новый продукт, нужно участие кучи отделов — иногда последовательно, иногда параллельно.
Пока выпускаешь 1–2 продукта в месяц, можно дирижировать вручную.
Но вопрос непростой:
как сделать так, чтобы компания могла выпускать 10? 100? 1000 продуктов в месяц?
И не умереть под завалами задач.
Сергей сформулировал метафору:
- каждый отдел — это по сути «микросервис»
- на входе — задачи из разных частей компании
- каждый «сервис» делает своё маленькое, но важное дело
- хочется, чтобы система была масштабируемая, гибкая, без «архитектурного долга»
(когда отделы созданы из локальной логики, а потом не складываются в общую систему)
Идея выглядит привлекательно. Но…
⚠️ Проблема №1: микросервис можно масштабировать, человека — нет
Моя первая реакция была простая:
Обратное применение микросервисного подхода почти никто не делал — и не случайно.
Микросервис можно сделать любой гранулярности, а вот сотрудника ты не возьмёшь на 20 минут в день.
Человек ≠ маленький сервис на одну функцию.
Под обратным применением я подразумевал вывернутый наизнанку процесс — обычно ведь мы в ИТ-системах пытаемся построить упрощенную модель мира, и под неё подстраиваем ИТ-процессы и ограничения. Но вот наоборот — не факт, что сработает.
В ИТ можно разделить систему на 200 микросервисов — и не нанять 200 человек.
В компаниях и операционных процессах так не работает.
Лирическое отступление: если что, я не являюсь последователем "1 микросервис — 1 разработчик (или даже 1 микросервис — 1 команда)", а даже являюсь противником такого подхода, вносящего дополнительные ненужные ограничения прежде всего на ту же гранулярность. К примеру, у меня был проект с 5 разработчиками на 60 микросервисов — и это нормально
⚠️ Из первой проблемы логическим следствием вытекает вторая:
оргструктура и ИТ-архитектура должны быть независимы
Когда анализируешь энтерпрайз-архитектуру крупного предприятия — это важное правило почти всегда нарушается. Рано или поздно, в большем или меньшем объёме, но устройство человеческих отделов компании, их операционных процессов протекает и в архитектурные схемы, разделение ответственностей между системами и необоснованные барьеры и границы
Странно будет предполагать, что допустив обратное влияние: ИТ-архитектуры на оргструктуру компании, мы получим хороший результат — слишком разные процессы и правила игры в этих двух мирах.
Но речь всё же чуть о другом — в компании нет идеальной автоматизорованной айтишечки, которую надо "переложить" на людей. Скорее в целом стандартные методы управления перестают работать, и идёт логичный поиск новых парадигм во всех возможных смежных сферах.
И тут мы нашли точку пересечения: уровень теории систем, ну или графов, или связанности-связности (прочности).
Я недавно писал об этом при рассмотрении перекладывания моего принципа каскадного снижения связанности на реальную жизнь:
если в компании люди сидят по отделам, и внутри отдела они общаются чаще, чем с соседним — это ровно те же coupling / cohesion.
- внутри отдела — высокая прочность
- между отделами — минимальная связанность
- если постоянно «бегают между этажами» — структура неправильная
То есть принципы модульности, низкой связанности и высокой прочности действительно применимы к оргструктуре, но не 1-в-1 как в коде и архитектуре.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤3👍3🔥2
2/2
⬆️ начало ⬆️
🤖 Дальше интереснее: «оркестратор задач»
Сергей поднял более глубокий уровень:
То, что он описывает — не про оргструктуру, а про устройство (архитектуру) операционного управления.
И здесь аналогия с ИТ-архитектурой уже ближе:
- есть оркестратор
- есть «рои исполнителей» (отделы)
- задачи приходят из разных источников
Но в отличие от классического оркестратора задач из идеального мира паттернов, такой оркестратор должен уметь:
- переопределять приоритеты задач
- отбрасывать протухшие задачи
- перераспределять ресурсы
- смотреть на общую ценность задачи для компании
Это уже сложная модель.
И вот тут ровно то место, где микросервисная аналогия снова ломается:
- как правило, в ИТ-системах все процессы обязаны выполниться;
- а в компании — наоборот: главное выбрать, что НЕ делать.
🧩 Выводы разговора
1. Делить компанию на микросервисы 1-в-1 — нерабочая идея.
Люди не функции, отдел не является сервисом по определению.
2. Но принципы модульности и каскадного снижения связанности — отлично ложатся на оргструктуру.
3. Главная сложность — не в структуре отделов, а в „центре принятия решений“, который:
- знает общие приоритеты,
- видит загрузку всех отделов,
- оптимизирует систему как целое.
4. На больших масштабах это неизбежно становится задачей для ИИ или очень продвинутого алгоритма.
5. И да… создаётся ощущение, что онтология и операционные процессы компании → это тоже вполне себе полноценная архитектура, но работающая в другой среде и по другом принципам.
И если её не продумать заранее — образуется всё тот же пресловутый архитектурный (управленческий) долг😢
🤝 Разговор пока не закончен — далее будем штурмовать этот "центр" принятия решений.
И пока кажется, идея аналогий действительно не так уж безумна.
Но начинать нужно не с микросервисов, как более такического приема на уровне solution-архитектуры, а чего-то более глобального 😉 Ведь по сути — везде нужно решить одну и ту же задачу — побороть и подчинить себе сложность👻
Сергей поднял более глубокий уровень:
«На входе у компании — тысячи задач.
Каждая требует разные комбинации отделов.
Как распределять приоритеты?
Как система должна выбирать оптимальный набор задач для максимального эффекта?
И кто должен быть этим „центром принятия решений“?»
То, что он описывает — не про оргструктуру, а про устройство (архитектуру) операционного управления.
И здесь аналогия с ИТ-архитектурой уже ближе:
- есть оркестратор
- есть «рои исполнителей» (отделы)
- задачи приходят из разных источников
Но в отличие от классического оркестратора задач из идеального мира паттернов, такой оркестратор должен уметь:
- переопределять приоритеты задач
- отбрасывать протухшие задачи
- перераспределять ресурсы
- смотреть на общую ценность задачи для компании
Это уже сложная модель.
Тут нужна либо ИИ-система по центру,
либо очень сложный алгоритм.
Архитектура вокруг исполнителей — это уже вторично.
И вот тут ровно то место, где микросервисная аналогия снова ломается:
- как правило, в ИТ-системах все процессы обязаны выполниться;
- а в компании — наоборот: главное выбрать, что НЕ делать.
1. Делить компанию на микросервисы 1-в-1 — нерабочая идея.
Люди не функции, отдел не является сервисом по определению.
2. Но принципы модульности и каскадного снижения связанности — отлично ложатся на оргструктуру.
3. Главная сложность — не в структуре отделов, а в „центре принятия решений“, который:
- знает общие приоритеты,
- видит загрузку всех отделов,
- оптимизирует систему как целое.
4. На больших масштабах это неизбежно становится задачей для ИИ или очень продвинутого алгоритма.
5. И да… создаётся ощущение, что онтология и операционные процессы компании → это тоже вполне себе полноценная архитектура, но работающая в другой среде и по другом принципам.
И если её не продумать заранее — образуется всё тот же пресловутый архитектурный (управленческий) долг
🤝 Разговор пока не закончен — далее будем штурмовать этот "центр" принятия решений.
И пока кажется, идея аналогий действительно не так уж безумна.
Но начинать нужно не с микросервисов, как более такического приема на уровне solution-архитектуры, а чего-то более глобального 😉 Ведь по сути — везде нужно решить одну и ту же задачу — побороть и подчинить себе сложность
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥8👍5❤3🤓3👾3🐳1
RUTUBE
Будущее ИТ-архитектуры
Как изменится ИТ-архитектура (а следовательно и сфера создания ПО в целом) на пике шестой технологической волны, когда ИИ станет как минимум обязательным инструментом во всех процессах?
Порассуждаем о роли архитектуры и архитектора в условиях, когда написать…
Порассуждаем о роли архитектуры и архитектора в условиях, когда написать…
Наконец-то появилась запись моего доклада про будущее 🔮✨
а точнее — про будущее ИТ-архитектуры и работы ИТ-архитекторов. Спешу ей с вами поделиться:
https://rutube.ru/video/d3676fc6e26626c7f99f1faa877f05fc
Ранее писал пару постов, и про идеи при подготовке доклада и про мысли по его следам
Всех с наступающим.. будущим! Которое уже здесь❄️ 🚀
а точнее — про будущее ИТ-архитектуры и работы ИТ-архитекторов. Спешу ей с вами поделиться:
https://rutube.ru/video/d3676fc6e26626c7f99f1faa877f05fc
Ранее писал пару постов, и про идеи при подготовке доклада и про мысли по его следам
Всех с наступающим.. будущим! Которое уже здесь
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍3
Сегодня (30 декабря) наконец закончился марафон экзаменационных защит у магистрантов по моему курсу микросервисной архитектуры —
6️⃣ 9️⃣ защитившихся на данный момент (часть уйдет на пересдачи уже в следующем году), и это абсолютный рекорд!
Вот уже 6й год как я читаю и модифицирую свой курс и каждый запуск охватывает всё большее и большее количество слушателей (в этом году их было 90+). По сравнению с прошлым годом курс вместил в себя на 1 лекцию и аж на 12 пар практик больше! И все практики оказались востребованы!
Что хочу сказать..
Я уже писал, что для меня проведение особенно практик и защит — это просто невообразимая прокачка насмотренности. Сложно представить, где ещё можно посмотреть и разобрать такой объём различных ИТ-архитектур совершенно разных проектов🌌
И вот, спустя 6 лет и огромное количество архитектурных схем.. До меня наконец дошло😅 , в голове каким-то образом сложились пазлики.. Пока сложно сформулировать, но как будто бы есть не такое большое количество типовых приёмов, из комбинации которых складываются почти все архитектуры.
Да, есть общеизвестные паттерны, но тут под приёмом я подразумеваю нечто большее.. Скорее конкретные реализации разных теоретических подходов (будь то Event-Driven Architecture или архитектура-цитадель, или различные варианты оркестраторов, или что-то ещё, или даже смесь различных тактик).
Это как-будто плюс-минус конечный набор архитектурных кубиков, из которых можно собирать конечные совершенно разнообразные решения!🧠
Да, я знаю, что не открыл Америку, и есть различные каталоги и примеры типовых архитектур (кстати, накидайте таких ссылок, пожалуйста🙏 , давно не занимался вопросом и наверняка появилось много нового).
Но те каталоги, что я видел — они показывали именно типовые архитектуры под решение типовых задач, а у меня сейчас в голове скорее небольшие типовые элементы конструктора, из которых можно собрать решения для любой нетипичной задачи.
Чтобы их окончательно сформулировать — хочу ещё раз пройтись и проанализировать большое количество накопившихся архитектур.. а чтобы это количество пополнить и расширить выборку — обращусь к вам:
⚠️ пришлите, пожалуйста, мне свои микросервисные архитектуры в любом виде (если это нарушает NDA — можно каким-то образом анонимизировать и обфусцировать (например, убрав часть надписей)). Закидывать можно мне в личку (@razonrus)
По результатам, я надеюсь собрать и оформить архитектурные кубики (ну или сказать, что уже всё изобретено под🌛 ).
P.S. Есть ещё идея собрать ещё один публичный каталог архитектурных схем, если хотите чтобы ваша архитектура там была опубликована (на условиях анонимности) — явно в сообщении разрешите мне это сделать в сообщении. Без разрешения, естественно, никакие архитектуры никуда выкладывать не буду.
Буду только их анализировать и медитировать над ними
🧘♂️
Вот уже 6й год как я читаю и модифицирую свой курс и каждый запуск охватывает всё большее и большее количество слушателей (в этом году их было 90+). По сравнению с прошлым годом курс вместил в себя на 1 лекцию и аж на 12 пар практик больше! И все практики оказались востребованы!
Что хочу сказать..
Я уже писал, что для меня проведение особенно практик и защит — это просто невообразимая прокачка насмотренности. Сложно представить, где ещё можно посмотреть и разобрать такой объём различных ИТ-архитектур совершенно разных проектов
И вот, спустя 6 лет и огромное количество архитектурных схем.. До меня наконец дошло
Да, есть общеизвестные паттерны, но тут под приёмом я подразумеваю нечто большее.. Скорее конкретные реализации разных теоретических подходов (будь то Event-Driven Architecture или архитектура-цитадель, или различные варианты оркестраторов, или что-то ещё, или даже смесь различных тактик).
Это как-будто плюс-минус конечный набор архитектурных кубиков, из которых можно собирать конечные совершенно разнообразные решения!
Да, я знаю, что не открыл Америку, и есть различные каталоги и примеры типовых архитектур (кстати, накидайте таких ссылок, пожалуйста
Но те каталоги, что я видел — они показывали именно типовые архитектуры под решение типовых задач, а у меня сейчас в голове скорее небольшие типовые элементы конструктора, из которых можно собрать решения для любой нетипичной задачи.
Чтобы их окончательно сформулировать — хочу ещё раз пройтись и проанализировать большое количество накопившихся архитектур.. а чтобы это количество пополнить и расширить выборку — обращусь к вам:
По результатам, я надеюсь собрать и оформить архитектурные кубики (ну или сказать, что уже всё изобретено под
P.S. Есть ещё идея собрать ещё один публичный каталог архитектурных схем, если хотите чтобы ваша архитектура там была опубликована (на условиях анонимности) — явно в сообщении разрешите мне это сделать в сообщении. Без разрешения, естественно, никакие архитектуры никуда выкладывать не буду.
Буду только их анализировать и медитировать над ними
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍10👏4🎉2
Год получился спокойным, без гонки за частотой и хайпом — но, как мне кажется, достаточно насыщенным по смыслу.
На 1 января 2025 у канала был 1021 подписчик. Сейчас — 1469! СПАСИБО!
Прирост +448 человек, примерно +44% за год.
Без накруток, конкурсов и прочей... (активности) ради цифр — просто органический рост вокруг тем, которые мне самому кажутся важными.
За год вышел 31 пост — в среднем 2–3 поста в месяц.
Самый продуктивный месяц — март (6 постов).
Самый непродуктивный — ноябрь (0 постов) — холодная осень в жизни и в канале — бывает 🙂
— 1676 просмотров
— 26 реакций
— 5,5 комментариев
Говорят, для канала без развлекательного формата и без «кричащих» заголовков — метрики более чем живые. Особенно радуют комментарии: именно в обсуждениях обычно и рождаются новые идеи.
________________________________
________________________________
Если отбросить выбросы в показателях, вызванные репостами пары постов, то наибольшее число просмотров будет у поста про.. внезапно химию! ⚗️
Каскадное снижение связанности — от микросервисов к жизни, бизнесу и даже химии
Пост о том, что архитектурные принципы не заканчиваются на софте.
Аналогии с оргструктурами, этажами офисов, атомами и молекулами — и попытка показать, что правильное соотношение связанности и прочности работает в любой сложной системе, независимо от её природы.
________________________________
Провокационный текст о том, что код — это интерфейс для человека, а не фундамент профессии.
Про LLM, внутренние представления моделей, отказ от синтаксиса в пользу смысла — и почему это не смерть программирования, а его логичное развитие.
Личный опыт совместной разработки с ИИ: когда человеку остаются идеи и мышление, а рутину забирает машина.
Про шахматные движки, pet-проекты и ощущение, что программирование снова стало игрой, а не конвейером.
Пятничный пост с бытовой аналогией: энергетик «на случай падения прода», у которого вышел срок годности, как индикатор реальной стабильности системы.
Иногда простые примеры объясняют сложные вещи лучше любых диаграмм.
________________________________
Большой разговор о применимости архитектурных принципов к управлению компаниями.
Почему нельзя копировать микросервисы 1-в-1 на людей, но почему принципы модульности, связанности и центра принятия решений всё равно универсальны.
По сути — про архитектуру управления сложностью.
Текст не вместился в ограничения телеграма и разделился аж на 2 поста, даю ссылку на первую часть:
Реакция на упоминание принципа в разборе антипаттернов микросервисов.
Про границы сервисов, потоки данных, динамическую связанность и архитектурный долг — в формате живой асинхронной дискуссии.
Жёсткий, но, как мне кажется, честный пост о разнице между инструментами и принципами.
Почему настоящие компетенции не стареют, при чём тут архитектура и шахматы, и почему умение «знать, куда кликать» — самый хрупкий навык в эпоху ИИ.
________________________________
Спасибо всем, кто читает, спорит, не соглашается и дополняет.
Копаем дальше
P.S. На картинке можно найти отсылки практически ко всем упомянутым постам
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍15❤🔥4🔥2❤1
На всех крупных ИТ-конференциях, где мне доводилось бывать, тема технологий двойного назначения фактически находилась под негласным запретом. До 2022 года эта тема, как правило, просто не поднималась, но теоретически подобные доклады как минимум могли быть рассмотрены.
После 2022 года ситуация, на мой взгляд, стала парадоксальной: при резко возросшей актуальности этой тематики она по-прежнему практически отсутствует в повестке ИТ-мероприятий. Складывается ощущение, что организаторы либо исходят из определённых идеологических установок, либо предполагают, что большая часть аудитории придерживается схожих взглядов. Насколько это соответствует реальному состоянию российского ИТ-сообщества — вопрос, по меньшей мере, спорный, особенно начиная с 2023 года, когда состав профессионального сообщества заметно изменился (несогласные уже уехали из страны, и передумавшие — вернулись).
Начиная с 2023 года я осторожно пытался поднимать эту тему, даже иногда это попадало в запись:
🎞 https://xn--r1a.website/rsa_enc/102
И только сейчас появляются первые, пока ещё крайне осторожные сигналы о готовности рассматривать подобные доклады. При том, что чуть ли не на государственном уровне тема технологий двойного назначения уже фактически обозначается как один из базовых вопросов национальной безопасности и подготовки к будущим конфликтам.
Например,
💬 Н. И. Касперская, президент группы компаний InfoWatch (бывший генеральный директор «Лаборатории Касперского»), на дискуссии «Архитектура цифровизации государственного управления»:
https://xn--r1a.website/khazinml/12010
💬 В. В. Шпак, заместитель министра промышленности и торговли РФ:
https://xn--r1a.website/nasledediye21/257
💡 Посмотрите видео по ссылкам — интересно, 14 минут в сумме.
Эти высказывания хорошо иллюстрируют общий сдвиг в официальной риторике и приоритетах. При этом, что особенно важно, соответствующие технологии, компании и специалисты в стране уже существуют.
Как преподаватель в магистратурах российских университетов, я регулярно слушаю защиты и предзащиты работ по подобной тематике. И речь идёт не о абстрактных студенческих проектах, а о реальных, внедрённых и работающих решениях — включая, например, ИИ-операторов антидронных систем, применяемых для защиты промышленных объектов.
При этом в других отраслях подобная демонстрация возможностей давно является нормой. Существуют военные и полувоенные форумы и авиасалоны — такие как МАКС и Ле Бурже — где открыто демонстрируются, обсуждаются, продаются и покупаются технологии вплоть до боевой авиации. На этом фоне возникает закономерный вопрос: почему аналогичного формата практически не существует в сфере ИТ для внутреннего рынка безопасности и обороны? Более того, при определённых условиях — и для внешнего рынка.
Да, существуют конференции по ИТ-безопасности, однако, по моим наблюдениям, подавляющая часть докладов там посвящена гражданской или коммерческой безопасности. Технологии военного или двойного назначения в явном виде практически не представлены.
Разумеется, далеко не обо всём можно и нужно рассказывать публично. Речь не о раскрытии технических деталей, а о демонстрации возможностей, результатов и уже достигнутого уровня решений. Я писал об этом ранее (https://xn--r1a.website/ruslan_on_air/124 ) в своём втором канале в контексте возможного кризиса формата ИТ-конференций. Однако ничто не мешает пересмотреть сам формат мероприятий: дополнять традиционное «как это сделано» более содержательным «что уже сделано» и «какие возможности уже существуют».
В текущем контексте это перестаёт быть вопросом маркетинга или трендов и становится вопросом стратегической значимости для отрасли и страны в целом.
После 2022 года ситуация, на мой взгляд, стала парадоксальной: при резко возросшей актуальности этой тематики она по-прежнему практически отсутствует в повестке ИТ-мероприятий. Складывается ощущение, что организаторы либо исходят из определённых идеологических установок, либо предполагают, что большая часть аудитории придерживается схожих взглядов. Насколько это соответствует реальному состоянию российского ИТ-сообщества — вопрос, по меньшей мере, спорный, особенно начиная с 2023 года, когда состав профессионального сообщества заметно изменился (несогласные уже уехали из страны, и передумавшие — вернулись).
Начиная с 2023 года я осторожно пытался поднимать эту тему, даже иногда это попадало в запись:
И только сейчас появляются первые, пока ещё крайне осторожные сигналы о готовности рассматривать подобные доклады. При том, что чуть ли не на государственном уровне тема технологий двойного назначения уже фактически обозначается как один из базовых вопросов национальной безопасности и подготовки к будущим конфликтам.
Например,
Коллеги, давайте будем честны, мы идем к глобальной войне. У нас через некоторое время отключения интернета будут нормой.
Отказ от бумаги к 2030 году — это диверсия по государственному управлению. На мой взгляд, это просто государственная измена.
https://xn--r1a.website/khazinml/12010
Эпоха, когда мы делили технологии на гражданские и военные — она закончилась.
https://xn--r1a.website/nasledediye21/257
Эти высказывания хорошо иллюстрируют общий сдвиг в официальной риторике и приоритетах. При этом, что особенно важно, соответствующие технологии, компании и специалисты в стране уже существуют.
Как преподаватель в магистратурах российских университетов, я регулярно слушаю защиты и предзащиты работ по подобной тематике. И речь идёт не о абстрактных студенческих проектах, а о реальных, внедрённых и работающих решениях — включая, например, ИИ-операторов антидронных систем, применяемых для защиты промышленных объектов.
При этом в других отраслях подобная демонстрация возможностей давно является нормой. Существуют военные и полувоенные форумы и авиасалоны — такие как МАКС и Ле Бурже — где открыто демонстрируются, обсуждаются, продаются и покупаются технологии вплоть до боевой авиации. На этом фоне возникает закономерный вопрос: почему аналогичного формата практически не существует в сфере ИТ для внутреннего рынка безопасности и обороны? Более того, при определённых условиях — и для внешнего рынка.
Да, существуют конференции по ИТ-безопасности, однако, по моим наблюдениям, подавляющая часть докладов там посвящена гражданской или коммерческой безопасности. Технологии военного или двойного назначения в явном виде практически не представлены.
Разумеется, далеко не обо всём можно и нужно рассказывать публично. Речь не о раскрытии технических деталей, а о демонстрации возможностей, результатов и уже достигнутого уровня решений. Я писал об этом ранее (https://xn--r1a.website/ruslan_on_air/124 ) в своём втором канале в контексте возможного кризиса формата ИТ-конференций. Однако ничто не мешает пересмотреть сам формат мероприятий: дополнять традиционное «как это сделано» более содержательным «что уже сделано» и «какие возможности уже существуют».
В текущем контексте это перестаёт быть вопросом маркетинга или трендов и становится вопросом стратегической значимости для отрасли и страны в целом.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Дискуссионный клуб «Наследие XXI»
Тихая революция: почему беспилотники — это новый фундамент экономики
Эту точку зрения в недавнем интервью подробно разъяснил сооснователь Клуба "Наследие XXI" Василий Шпак. Основные тезисы — ниже ⬇️
💬 Пока все говорят про хайп вокруг ИИ, в России тихо…
Эту точку зрения в недавнем интервью подробно разъяснил сооснователь Клуба "Наследие XXI" Василий Шпак. Основные тезисы — ниже ⬇️
💬 Пока все говорят про хайп вокруг ИИ, в России тихо…
11👍8🔥7👏3😢2🐳2
В архитектуре и в IT в целом всегда была одна закономерность: чем больше мы инструментов используем — тем больше у нас когнитивной нагрузки, связей и рисков. Но похоже, эта закономерность сейчас растёт не просто линейно — она уходит в экспоненту.
Каждая новая конференция, каждый свежий блог или твит — и вот уже в продакшене не только Kubernetes с Terraform, но и ArgoCD, Flux, Crossplane, Istio, Linkerd, Kafka, Prometheus, Grafana, Loki, Vector… и ещё десятки «must-have» штуковин, о которых пару лет назад никто и не слышал. И всё это с разными паттернами конфигурации, API, lifecycle-политиками, схемами RBAC и кучей плагинов.
С одной стороны — классно: инструменты становятся мощнее, автоматизация всё глубже, можно декларировать инфраструктуру как код, наблюдаемость как код, безопасность как код… и вообще делать всё быстрее. С другой — нам приходится управлять зоопарком взаимодействующих систем, каждая из которых умеет жить сама по себе, но в связке с другими — уже приносит новый класс сложностей.
Стаёт очевидно, что в девопсе сложность растёт быстрее, чем наша способность её осознать и контролировать.
И вот что меня особенно беспокоит:
➡️ Многие берут инструменты не подумав о контексте применения.
Инструмент X оказался крутым в десятке крупных команд с выделенными Platform и Infra командами. Там — куча девопсов, бюджеты, процессы, SLA. Там — есть кому его настроить, поддерживать и мигрировать через версии.
➡️ Потом инструмент становится «модным» — про него рассказывают на митапах, он попадает в блог-чарт, все на конференциях в нетворкинге довольные обсуждают, как они теперь используют «Y вместо Z». А дальше — этот же инструмент начинают внедрять в команды с парой девопсов, несколькими бэкендерами, и нулевым временем на поддержку.
И что происходит?
❗️ Команда тонет в конфигурациях CRD, webhooks, операторов, chart’ов.
❗️ Pipelines растут как шевелящиеся графы — читать сложно, дебажить невозможно.
❗️ Инциденты растут, команда не успевает, начинает винить себя, выгорает.
❗️ Продукт работает плохо.
Причина очень простая: инструмент сам по себе не плох — он сложен. А мы не всегда учитываем его назначение, контекст и границы применимости.
То есть:
➡️ инструмент A шикарно решает проблему в энтерпрайзе с 200 нодами и 10 командами — потому что там есть кто за ним следит;
➡️ но тот же A в команде с 2 девопсами — уже приводит к операционной долговой яме.
Иногда куда правильнее взять меньше инструментов, но более понятных и прогнозируемых, пусть и менее хайповых. Старые, зрелые, с простым поведением — и вы скорее добьётесь результата, который приносит бизнес-ценность и спокойствие команде.
Сложность не измеряется числом звезд на GitHub.
Сложность измеряется тем, сколько ты реально можешь понять, предсказать и поддерживать в ежедневной работе.
И если хочешь добавить новый инструмент в инфраструктуру — убедись, что есть ресурсы для его настройки и поддержки, и что он действительно нужен в продукте (а не только в твоём резюме или слайде очередной конференции).
Каждая новая конференция, каждый свежий блог или твит — и вот уже в продакшене не только Kubernetes с Terraform, но и ArgoCD, Flux, Crossplane, Istio, Linkerd, Kafka, Prometheus, Grafana, Loki, Vector… и ещё десятки «must-have» штуковин, о которых пару лет назад никто и не слышал. И всё это с разными паттернами конфигурации, API, lifecycle-политиками, схемами RBAC и кучей плагинов.
С одной стороны — классно: инструменты становятся мощнее, автоматизация всё глубже, можно декларировать инфраструктуру как код, наблюдаемость как код, безопасность как код… и вообще делать всё быстрее. С другой — нам приходится управлять зоопарком взаимодействующих систем, каждая из которых умеет жить сама по себе, но в связке с другими — уже приносит новый класс сложностей.
Стаёт очевидно, что в девопсе сложность растёт быстрее, чем наша способность её осознать и контролировать.
И вот что меня особенно беспокоит:
Инструмент X оказался крутым в десятке крупных команд с выделенными Platform и Infra командами. Там — куча девопсов, бюджеты, процессы, SLA. Там — есть кому его настроить, поддерживать и мигрировать через версии.
И что происходит?
Причина очень простая: инструмент сам по себе не плох — он сложен. А мы не всегда учитываем его назначение, контекст и границы применимости.
То есть:
Иногда куда правильнее взять меньше инструментов, но более понятных и прогнозируемых, пусть и менее хайповых. Старые, зрелые, с простым поведением — и вы скорее добьётесь результата, который приносит бизнес-ценность и спокойствие команде.
Сложность не измеряется числом звезд на GitHub.
Сложность измеряется тем, сколько ты реально можешь понять, предсказать и поддерживать в ежедневной работе.
И если хочешь добавить новый инструмент в инфраструктуру — убедись, что есть ресурсы для его настройки и поддержки, и что он действительно нужен в продукте (а не только в твоём резюме или слайде очередной конференции).
Please open Telegram to view this post
VIEW IN TELEGRAM
1💯18👍5❤3🐳1
Давно я тут ничего не писал.. Ещё давнее — чего-то на самом деле архитектурного. Исправляюсь :)
Сегодня хочу поговорить о применении Common Reuse Principle (CRP) для микросервисной архитектуры. Вкратце я упоминал о применении данного принципа к микросервисам, например, в докладе по рефакторингу архитектуры. Давайте разберём подробнее и с примерами.
Вспомним, о чём говорит классическая формулировка 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 с описанием принципа в каталог принципов проектирования, и планирует написать пример архитектурного теста на соблюдение данного принципа🔥
Сегодня хочу поговорить о применении 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 с описанием принципа в каталог принципов проектирования, и планирует написать пример архитектурного теста на соблюдение данного принципа
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤5👏4🔥2❤🔥1🐳1
Эффективно выстроить работу с ИИ-агентами можно только хотя бы примерно понимая, как они устроены (досконально как работают современные LLM не понимает никто :)).
Попробую описать свое понимание на метафоре, и дать пару практичных советов на основе своего опыта.
🐟 Кажется, мы действительно получили в своё распоряжение золотую рыбку. Не в пушкинском смысле, а в инженерном: ИИ-помощников, которым можно буквально формулировать желания: напиши код, нарисуй схему, сравни подходы. И это уже не магия, а рабочий повседневный инструмент.
Но у новой золотой рыбки есть важная особенность. Мы все знаем выражение «память как у золотой рыбки». И к ИИ-агентам эта метафора хорошо подходит. Не потому, что они ничего не помнят, а потому, что их память устроена иначе, чем наша.
Говорить, что «у ИИ нет памяти», неправильно. У современных моделей есть объём знаний, заложенный на этапе обучения. В каком-то смысле они “помнят” почти всё, что накопило человечество. Но это не память в человеческом (белковом) смысле. Скорее что-то вроде глубокой статистической, почти мышечной памяти. Примерно как человек умеет ездить на велосипеде или плавать: мы не расписываем себе, каким мышцам какие команды отдаём, а просто делаем. Мне кажется, ИИ так же решает и многие аналитические задачи: не по-человечески “вспоминает” как их решать, а как будто сразу умеет.
А вот обычная память диалога или проекта у ИИ устроена иначе. Это не выученноес молоком матери знание, а контекст: временно подгруженная рабочая среда (контекст, скиллы и т.д.). И она хрупкая. Что-то попало в неё, что-то нет. Что-то модель посчитала важным, что-то второстепенным. Что-то при упаковке контекста сократилось или исчезло. Поэтому модель может знать огромный пласт общих вещей и при этом забыть, о чём вы договорились десять сообщений назад.
И отсюда следует главный практический вывод. При работе с ИИ-агентами нужно фиксировать вообще всё, что вы хотите сделать частью их устойчивого поведения в проекте: договорённости, подходы, найденные грабли, ограничения.. Всё это должно существовать не только в головах команды или чатах. Обсудили на стендапе, что каждую задачу начинаем в отдельной ветке, — напишите бумажульку для ИИ-агента. Нашли подводный камень в работе приложения на iOS, договорились, как называете фичи и релизите — зафиксируйте это там, откуда агент сможет подгружать это снова и снова.
Промпт он забудет. Точнее, промпт слишком ситуативен и живёт недолго. А вот контекст, лежащий в репозитории, в спецификациях, ADR, заметках — это уже не человеческая память, но это та среда, из которой ИИ может заново собирать себе рабочую картину мира.
Именно здесь нам ещё предстоит перестроиться. Мы всё ещё пытаемся работать с ИИ как с умным собеседником, которому надо просто получше объяснить. Но эффективная работа с ИИ всё больше похожа не на разговор, а на проектирование среды. Недостаточно один раз удачно что-то сформулировать. Нужно встроить важные смыслы, решения и ограничения в саму ткань работы с репозиторием. Всё, что не попало в репозиторий — растворится после очередного исчерпания окна контекста.
Поэтому вопрос не в том, есть ли у ИИ память. Вопрос в том, что она не такая, как у нас, и ждать от неё человеческого поведения — ошибка. Если обученную статистическую память мы не контролируем, то рабочий контекст полностью зависит от того, насколько хорошо мы умеем оформлять и сохранять свои мысли. Не в воздухе, не в чате, не “где-то обсуждали”, а в явном виде.
Так что да, золотую рыбку мы, кажется, действительно поймали. Но, как и с любой серьёзной силой, проблема не в том, исполняет ли она желания. Проблема в том, умеем ли мы эти желания правильно сформулировать и сохранить так, чтобы с ними можно было работать не один раз и с повторяемым результатом. ИИ не нужна память в нашем понимании — это дорогой и, возможно, необязательный механизм. Его компенсирует скорость обработки информации. Чем лучше мы научимся превращать свои мысли в устойчивый контекст, тем сильнее окажется наша золотая рыбка.
И да, типичная фраза архитекторов "зависит от контекста", становится ещё более актуальной!
Попробую описать свое понимание на метафоре, и дать пару практичных советов на основе своего опыта.
🐟 Кажется, мы действительно получили в своё распоряжение золотую рыбку. Не в пушкинском смысле, а в инженерном: ИИ-помощников, которым можно буквально формулировать желания: напиши код, нарисуй схему, сравни подходы. И это уже не магия, а рабочий повседневный инструмент.
Но у новой золотой рыбки есть важная особенность. Мы все знаем выражение «память как у золотой рыбки». И к ИИ-агентам эта метафора хорошо подходит. Не потому, что они ничего не помнят, а потому, что их память устроена иначе, чем наша.
Говорить, что «у ИИ нет памяти», неправильно. У современных моделей есть объём знаний, заложенный на этапе обучения. В каком-то смысле они “помнят” почти всё, что накопило человечество. Но это не память в человеческом (белковом) смысле. Скорее что-то вроде глубокой статистической, почти мышечной памяти. Примерно как человек умеет ездить на велосипеде или плавать: мы не расписываем себе, каким мышцам какие команды отдаём, а просто делаем. Мне кажется, ИИ так же решает и многие аналитические задачи: не по-человечески “вспоминает” как их решать, а как будто сразу умеет.
А вот обычная память диалога или проекта у ИИ устроена иначе. Это не выученное
И отсюда следует главный практический вывод. При работе с ИИ-агентами нужно фиксировать вообще всё, что вы хотите сделать частью их устойчивого поведения в проекте: договорённости, подходы, найденные грабли, ограничения.. Всё это должно существовать не только в головах команды или чатах. Обсудили на стендапе, что каждую задачу начинаем в отдельной ветке, — напишите бумажульку для ИИ-агента. Нашли подводный камень в работе приложения на iOS, договорились, как называете фичи и релизите — зафиксируйте это там, откуда агент сможет подгружать это снова и снова.
Промпт он забудет. Точнее, промпт слишком ситуативен и живёт недолго. А вот контекст, лежащий в репозитории, в спецификациях, ADR, заметках — это уже не человеческая память, но это та среда, из которой ИИ может заново собирать себе рабочую картину мира.
Именно здесь нам ещё предстоит перестроиться. Мы всё ещё пытаемся работать с ИИ как с умным собеседником, которому надо просто получше объяснить. Но эффективная работа с ИИ всё больше похожа не на разговор, а на проектирование среды. Недостаточно один раз удачно что-то сформулировать. Нужно встроить важные смыслы, решения и ограничения в саму ткань работы с репозиторием. Всё, что не попало в репозиторий — растворится после очередного исчерпания окна контекста.
Поэтому вопрос не в том, есть ли у ИИ память. Вопрос в том, что она не такая, как у нас, и ждать от неё человеческого поведения — ошибка. Если обученную статистическую память мы не контролируем, то рабочий контекст полностью зависит от того, насколько хорошо мы умеем оформлять и сохранять свои мысли. Не в воздухе, не в чате, не “где-то обсуждали”, а в явном виде.
Так что да, золотую рыбку мы, кажется, действительно поймали. Но, как и с любой серьёзной силой, проблема не в том, исполняет ли она желания. Проблема в том, умеем ли мы эти желания правильно сформулировать и сохранить так, чтобы с ними можно было работать не один раз и с повторяемым результатом. ИИ не нужна память в нашем понимании — это дорогой и, возможно, необязательный механизм. Его компенсирует скорость обработки информации. Чем лучше мы научимся превращать свои мысли в устойчивый контекст, тем сильнее окажется наша золотая рыбка.
И да, типичная фраза архитекторов "зависит от контекста", становится ещё более актуальной!
1🔥13👍6❤4😁2
В июне на конференции TechLeadConf в Питере я буду куратором и членом жюри архитектурной каты — соревнования по проектированию ИТ-архитектуры. И пока думаю, как это всё лучше организовать и по каким критериям потом оценивать решения, меня всё сильнее гложет одна неудобная мысль.
⚠️ Если попросить десять сильных архитекторов независимо друг от друга спроектировать одну и ту же систему, почти наверняка мы получим десять разных архитектур.
И ладно бы просто разных.
Почти каждая будет выглядеть убедительно.
В одной будут красивые bounded context’ы. В другой — event-driven и асинхронщина. В третьей — платформы, observability, service mesh и прочие признаки взрослой айтишечки. И почти у каждой найдутся разумные аргументы, ссылки на прошлый опыт и очень уверенная защита.
То есть проблема даже не в том, что решений много.
Проблема в том, что внешне они слишком часто выглядят одинаково правильными.
И вот тут начинается самое интересное.
А что мы тогда вообще оцениваем — красоту схемы, напор на защите, количество модных слов на квадратный сантиметр слайда, совпадение с тем, что сейчас считается хорошим тоном в индустрии?
Если честно, архитектурные решения слишком часто принимаются именно так. Никто, конечно, не говорит в лоб: “давайте возьмём Kafka, потому что у меня её ещё нет в резюме”. Нет, всё звучит намного благороднее: это стандарт индустрии, так делают в◀️ ваш любимый бигтех▶️ , так правильнее, гибче, надежнее. И вот это вот всё.
Но если снять с решения красивую упаковку, очень часто под ней нет самого важного: нормальной логики, явных гипотез и понятных критериев проверки.
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. Не в мистическом смысле. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
На короткой дистанции такой подход иногда даже работает. На длинной — внезапно выясняется, что эту архитектуру трудно объяснить бизнесу, трудно пересмотреть, трудно измерить и ещё труднее развивать без новых слоёв случайной сложности.
И самое неприятное: у архитектуры, принятой на вере, обычно очень слабая связь с той реальностью, в которой ей потом жить.
И чем больше я думаю про архитектурную кату, тем меньше верю в оценку по красоте квадратиков. Кажется, смотреть надо на другое: есть ли у решения логика, понятно ли, от какого контекста оно отталкивается, и можно ли вообще проверить, что это не просто хорошо упакованное мнение.
Потому что хорошая архитектура начинается не там, где нарисовали самую убедительную схему.
А там, где у решения появляется связь с реальностью. Или где хотя бы обозначены гипотезы, почему так а не иначе, и как это вяжется с бизнесом. Гипотезы хотя бы можно будет проверить
И ладно бы просто разных.
Почти каждая будет выглядеть убедительно.
В одной будут красивые bounded context’ы. В другой — event-driven и асинхронщина. В третьей — платформы, observability, service mesh и прочие признаки взрослой айтишечки. И почти у каждой найдутся разумные аргументы, ссылки на прошлый опыт и очень уверенная защита.
То есть проблема даже не в том, что решений много.
Проблема в том, что внешне они слишком часто выглядят одинаково правильными.
И вот тут начинается самое интересное.
А что мы тогда вообще оцениваем — красоту схемы, напор на защите, количество модных слов на квадратный сантиметр слайда, совпадение с тем, что сейчас считается хорошим тоном в индустрии?
Если честно, архитектурные решения слишком часто принимаются именно так. Никто, конечно, не говорит в лоб: “давайте возьмём Kafka, потому что у меня её ещё нет в резюме”. Нет, всё звучит намного благороднее: это стандарт индустрии, так делают в
Но если снять с решения красивую упаковку, очень часто под ней нет самого важного: нормальной логики, явных гипотез и понятных критериев проверки.
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. Не в мистическом смысле. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
На короткой дистанции такой подход иногда даже работает. На длинной — внезапно выясняется, что эту архитектуру трудно объяснить бизнесу, трудно пересмотреть, трудно измерить и ещё труднее развивать без новых слоёв случайной сложности.
И самое неприятное: у архитектуры, принятой на вере, обычно очень слабая связь с той реальностью, в которой ей потом жить.
И чем больше я думаю про архитектурную кату, тем меньше верю в оценку по красоте квадратиков. Кажется, смотреть надо на другое: есть ли у решения логика, понятно ли, от какого контекста оно отталкивается, и можно ли вообще проверить, что это не просто хорошо упакованное мнение.
Потому что хорошая архитектура начинается не там, где нарисовали самую убедительную схему.
А там, где у решения появляется связь с реальностью. Или где хотя бы обозначены гипотезы, почему так а не иначе, и как это вяжется с бизнесом. Гипотезы хотя бы можно будет проверить
Please open Telegram to view this post
VIEW IN TELEGRAM
3❤8👍3🔥3