Чет я забыл рассказать, что сегодня вечером делаем открытый вебинар про Cursor и SDD.
Запись будет только для членов клуба, так что не пропускайте.

#AI

Мегаинтересный и короткий доклад про от SRE в Яндекс Go про внедрение иишечки.
Да, спикер прямо говорит, что собрать такое сейчас могут только бигтехи и около, но все равно круто. Будем подождать.

https://youtu.be/2V9h3FYBS_Y?si=n8q83RMW6KAk8k0d&t=1366

Ну что, на марафон отправляется @zy_ana, а остальным достается промик со скидкой 20% — AB20_AM17

Приходите к нам еще

#манагерское

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

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

Зато каждый живет в абсолютной уверенности, что по ту сторону все тупые и ленивые, а уж мы-то знаем, как надо! И никакие сомнения не тревожат эти дивные миры.

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

Должно годное реалити-шоу получиться.

P.S. Расскажите, что у вас все не так, спасите мою верю в людей

#AI #манагерское

В продолжение темы ловите заметки Максима Цепкова из лагеря маркетологов.

Секция – важна, потому что это – позиция заказчика. И они – в восторге, потому что разработка – достала, а вайбкодинг дает альтернативу, которая реально работала. формат стола – отдельные реплики и истории. Я это записывал, ловите избранные цитаты.

P.S. Обязательно напишите, почему там все неправы, и вообще

#конференции

На следующей неделе иду возвращаться к корням у джугов на JPoint и Heisenbug.

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

Heisenbug (27-28 апреля)

• LLM'изация тестирования в Яндексе: измеряем эффект от AI в команде из 1000+ QA-инженеров

• Как автоматизировать тестирование ИИ-агентов: бенчмарки, метрики, LLM-as-a-Judge

• Тестирование LLM-приложений с DeepEval

JPoint (29-30 апреля)

• История сборщика мусора G1. Часть 1. Java 17-25

• Хайлоад на ровном месте

• Кровь, пот и Kafka. Request/reply не больно

• ИИ в ревью кода: как перестать тюнить промпты и начать строить систему

Кто еще туда собирается? Го по чайку вживую.

Штош, люди все равно спрашивают, поэтому держите неофициальный пресс-релиз.

Жизненный путь NextWay (ArchWays) начался 4 года назад с забавной истории, теперь он подошел к логическому завершению. Спасибо всем, с кем делали его, и всем кто доверял свое время, деньги, внимание.

Обычно в этом месте выкладывают стату про тренинги, участников и все такое, но мне лень и не вижу смысла. Знаю, что через школу прошло примерно 450-500 человек. Часто в личке и при случайных встречах мы слышали благодарность и истории о том, как после курсов получилось найти интересную работу, стать архитектором, вырасти в лида или хеда. Безусловно, это их заслуга, а не наша. Но хочу верить, что получилось сделать этот путь чуть проще. Если так, то все было не зря.

В мае-июне планирую провести последний поток интеграции и архитектуры систем.

Дальше буду заниматься Tech Analyst Club, не прощаемся.

Если проект как-то помог вам, оставьте пару слов в комментах, поностальгировать.

Зато завтра на DUMP буду снова вещать, почему аналитик должен стать инженером. Как в этом пути помогу лего-сервисы и другие подручные инструменты.

Кто еще будет?

Меня совсем поглотил DUMP, буду краток.

Завтра в Tech Analyst Club делаем первого AI-агента с RAG’ом в n8n. Если вы ждали знака, чтобы начать — вот он.

Вчера нас 4 часа гуляли по Екатеринбургу, проникся городом, хочу вернутся. Есть тут кто из местных? Думаю устроить оффлайн митап тут летом.

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

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

#AI

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

А главное, как это может произойти в Амазоне?

Sync-async, часть 3. Бытовое безумие

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

Принято считать Polling, Callback, Webhook асинхронными паттернами. А в чем их асинхронность?

Я пользуюсь таким определением sync-async:

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

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

Что такое (Short) Polling?
Формально, его можно назвать асинхронным паттерном, т.к. после первого вызова соединение закрывается и технический процесс на клиенте не блокируется. Дальше просто добиваем статус регулярными запросами.

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

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

Что такое Callback?
Если говорить о “классическом” коллбеке с двумя акторами, то здесь примерно та же история. Формально это можно обозвать асихнронщиной, но фактически нам нужно дождаться результата, чтобы продолжить бизнес-процесс. Получается та же история, что и с поллингом.

Возможен вариант коллбека, когда запрос кидает Service A, обрабатывает его Service B и отправляет ответ в Service C. Адрес последнего сервиса можно забить в настройки или передавать в исходном запросе. Считать ли это коллбеком — вопрос холиварный. Я буду считать это схемой из двух вебхуков.

Что такое Webhook?
Выглядит как одиночный синхронный запрос-ответ. Но на уровне общей картины это передача события поверх HTTP, где актор делиться инфой о последних происшествиях с подписанными соседями, не требуя ничего в ответ. Здесь HTTP-response — формальность самого протокола. Выглядит как событийная архитектура, только без очередей.

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

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

#интеграция

Ща будет мерзкая реклама, пролистывайте.
 
Я уже писал, что в мае-июне провожу последний поток курса по интеграции и архитектуре для аналитиков. Забавно, но только после пятого потока окончательно понял, про что он:
 
— про самостоятельный поиск решений, когда ты встречаешь новую задачу, а у тебя нет заученных паттернов и бест практик
 
— про понимание протоколов и инфры под ними, а не механическую работу по чек-листам и чужим критериям выбора
 
— про распределенные системы и фундаментальные проблемы проектирования, а не модные базворды и технологии
 
В конечном счете, это про умение сформулировать архитектурный вопрос, провести исследование, оценить возможные ответы. Не знаю, на сколько успешно, но судя по фидбеку последней группы, как-то получается передать это. Если интересно, почитайте отзывы здесь.
 
Начинаем в среду, запрыгивайте в последний поезд.

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

Если согласованность особо не интересует, то можно кидать сообщения всяких без гарантий через какие-нибудь in-memory Redis или NATS, или вообще по UDP.

Если согласованность нужна, но не вотпрямщас, то кидаем события в одностороннем порядке (one way) в кафку, кролика или еще кого

Хотим убедиться, что до получателя событие долетело – делаем вебхук или request-response поверх очередей.

Если нужна более строгая согласованность, берем поллинг или коллбек.

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

#интеграция

#AI

Послушал подкаст Маши Серегиной про иллюзию эффективности при внедрении нейросетей с Сергеем Путятинским.

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

Вытащил несколько мыслей (вольные цитаты):

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

Нет, и это нормально. Люди и без ии стремятся больше получать и меньше работать. Так будет, пока использование иишечки не станет общепринятой практикой.

Внедрение AI легко превращается в локальную оптимизацию, т.к. для роста общей эффективности нужен не HR или разраб с AI, а трансформация ролей и процессов.

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

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

А вот здесь популярное заблуждение, что иишечка в разработке – это вайбкодинг, где ты с 2-3 промптов получаешь красивое приложение, но не более. Копилоты, код-агенты, ревью-агенты, SDD и т.п. уже используют в промышленных масштабах. Да, допиливать АБС или телеком-биллинг, я бы так не стал, но определить необходимые изменения в нужных сервисах и последовательно реализовать их вполне реально. С AI-driven инженерией в массах еще незнакомы. Именно поэтому 21 мая мы с джугами делаем вторую AI Dev Conf. Там спикеры из бигтехов расскажут, как AI меняет процессы в кровавом энтерпрайзе, с кейсами, метриками и вот этим всем.

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

Самое важное, хотя говорить об этом никто не любит. Принято считать, что процессы и оргструктуры строятся так, чтобы они были максимально эффективными. Хотя строят их конкретные люди так, чтобы им это было выгодно. Об этом я писал тут.

Причем выгода не только в бюджетах и влиянии. У каждого руководителя есть команда, которую он либо нанимал, либо в доверительных отношениях. Такие связи бывают очень полезны при смене проектов, компаний и вообще изменениях. Этот тот самый человеческий капитал. Компании меняются, люди остаются. Что произойдет с капиталом, если начать оптимизировать команду?

Я уже видел много революций, которые обещали изменить мир: SOA, BPM, микросервисы, RPA, блокчейн – и где они теперь?

Вообще-то они все на своих местах, где есть реальное применение. Да, те же SOA, MSA, BPM не стали концом истории, но дали огромное развитие инженерной и манагерской мысли. Это все равно, что ругать REST Филдинга за его бесполезность в 2026 году.

Так будет с AI. Пока пробудившейся Skynet не очистит эту землю от двуногих.

#интеграция

Есть у меня любимое задание на курсах по интеграции: выбрать технологию или протокол для взаимодействия и обосновать выбор.

Каждый раз, случается диалог вида:

— Мы выбрали gRPC для внутренних взаимодействий, потому это быстрее, чем REST

— А на сколько быстрее?

— Что вы называете REST’ом? А если это REST API поверх HTTP/2, будет ли gRPC быстрее, и на сколько?

— Какую долю от времени ответа занимает передача данных? Будет ли разница в скорости между gRPC и REST значимой для нас?

— Какая общая нагрузка на систему или продукт? Важна ли нам вообще скорость внутренних взаимодействий?

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

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

Поэтому для желающих стать человеком мыслящим в мае проведем несколько активностей в Tech Analyst Club:

• 23.05, сбт — воркшоп по тестированию и документированию нестандартных API (GraphQL, gRPC, WebSocket) в Postman, чтобы пощупать их ручками

• 28.05, чтв — вебинар про иерархию и устройство протоколов и технологий взаимодействий, если хочется какой-то цельной классификации

• 30.05, сбт — воркшоп про выделение и приоритезацию критериев выбора способа интеграции, там будет самое мясо

Кстати, о производительности gRPC у нас был стрим с Алексеем Романовым.

Завтра веду трек на AI Dev Conf. Будем говорить про внедрение AI в российских бигтехах, что получается, что нет, как измеряют результаты, на какие метрики смотрят.

Отдельно выделю два классных кейноута:

Александр Поломодов — техдир в T-Банке, создатель System Desing Space. О том, как AI меняет процесс разработки на всех этапах.

Андрей Бреслав — создатель языка Kotlin, сейчас разрабатывает новую систему AI-программирования CodeSpeak. Поделится своим видением роли человека в будущем программной инженерии.

Если хотите бесплатный билетик, напишите в комментах, какие AI-инструменты вы уже успешно используете в команде, а что не получается. Сегодня в 21:00 мск выберу пару победителей.

Май классически забит конференциями. В пятницу-субботу пройдет Analyst Days 22. Нравится, что конфа взрослеет, на ней идет полноценное обсуждение инженерных практик, а не очередные разговоры “как писать требования” и “что такое REST API”.

С прошлого раза запомнилось:

Сергей Баранов — о том, как аналитик помогает в управлении архдолгом и качеством архитетектуры на долгой дистанции.

Дмитрий Безуглый — про корпоративный буллшит и четыре пути эволюции сисаналитика в AI-мире. В этот раз проведет воркшоп про использование AI.

Татьяна Половинкина — “если вы не платите за продукт, то продукт — это вы”, или как беречь себя в мире цифрового СДВГ.

Анна Обухова — классная лекция по нейробиологии про мозг и энергию. В субботу от нее будет мастер-класс про внедрение изменений с точки зрения работы мозга.

Программа грядущей конфы обещает много интересного про архитектуру и практическое AI, посмотрите сами. Отдельно жду доклады Максима Цепкова про китайский бигтех и Саши Брызгаловой про проблемы и решения с точки зрения теории ограничений.

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