Твой кролик писал

Месяц на новой работе, как я справился с информационным штормом

Прошло чуть больше месяца с того момента, как я вышел на новое место. Кто пропустил — теперь я руководитель направления в Банк Дом.РФ.

За этот месяц я часто вспоминал вопросы от учеников формата «я вышел на проект, как понять что происходит?», «я на проекте, тут не так, как нас учили?», «я ничего не понимаю...» — потому что сам оказался в новых условиях и столкнулся с этими проблемами в разных форматах.

В первую неделю меня накрыло волной информации: новый домен, новый продукт, новый стек, новые люди. Казалось нереальным даже просто запомнить всё, что мне говорили. Был страх «я не справлюсь». Помог нормальный онбординг и поддержка коллег — отдельное спасибо тем, кто выделял слоты в календаре, чтобы можно было зайти и закинуть вопросы, накопившиеся за сутки. Иногда я задавал один и тот же вопрос разным ролям, так довольно быстро сложилась в голове и draw.io карта домена, технологий и продукта, а дальше уже работа пошла.

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

Но дорогу осилит идущий: почитал документы, помучал коллег и вроде втянулся)

Собрал в голове чек-лист из 5 пунктов на случай, если попадёте на новый проект:
1. Знакомьтесь с коллегами.
2. Читайте документацию — всю, что есть.
3. Задавайте вопросы, даже если один и тот же вопрос разным людям — так быстрее сложится общая картина.
4. Всё, что вам непривычно, на старте надо просто принять.
5. Рисуйте схемы и записывайте всё, что в вас загружают — это помогает осознать огромный поток новой информации. Даже древние люди рисовали на скалах, а мы то явно круче них, вот и я создал файл онбординг.drawio.

Пару недель назад открыли новый офис — сгонял туда, чтобы очно познакомиться с командой. Офис понравился, а сам БЦ, оказался целиком нашим. Заодно оценил станцию метро ЦСКА.

Очная встреча, как всегда, сближает, помогает быстрее найти общий язык и сокращает время притирки.
Разобрали огромный эпик за несколько часов. Офлайн-общение и работа для новичка по эффективности и пользе отличаются от созвонов в разы. А это ещё раз укрепило меня в мысли: самый комфортный формат — удалёнка, самый эффективный — гибрид.

Познакомился с DevRel'ом — думаем сделать митапчик в октябре, скорее всего для аналитиков. Детали скоро.

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

А вообще всё новое — это стресс. Берегите себя!

Но если у вас есть лайфхак, как справиться на новом проекте или работе, делитесь!

🤯 POST, PUT или DELETE? - Вот в чем вопрос!

Выбор правильного HTTP-метода для эндпоинта - это вечная холиварная тема. Особенно когда семантика API не маппится напрямую в REST-методы. Например: вроде бы выполняется удаление, но под капотом происходит update или вовсе создание новой записи.

На практике операции редко соответствуют простой схеме «CREATE → POST, UPDATE → PUT, DELETE → DELETE». В реляционных моделях, например, апдейтится сразу много связей.

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

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

🔶 Выбор строго по конвенции REST часто не подходит, так как операция неконвенционная.

🔶 Выбор "по сути" бизнес-операции (например, если удаление, то строго DELETE) ломает REST-конвенцию и упирается в ограничения метода. Может ли DELETE вернуть в response несколько обновлённых сущностей вместо OK/ERROR?

🔶 Выбор в пользу "понятно для клиента" - это размытый критерий. На рынке нет единого стандарта под такие случаи, и «понятность» превращается во вкусовщину.

Как-то обсуждали эту тему с solution architect Володей @vrogach. И его решение мне очень откликнулось.

Зафиксировать внутренний стандарт для конкретного API (Design Guidelines).

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

Например: "Для всех эндпоинтов, которые запускают комбинацию событий, используется POST"

Это делает поведение API предсказуемым для клиентов и разрубает узел нестыковок с REST-конвенцией.

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

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

💬 А как у вас в командах решают такие спорные случаи? Удаётся ли договориться о едином стандарте? 👇

Пришло время признаться: по вечерам я вайб-кожу. И вот чему я научился.

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

Я не сравниваю SHA, не пересчитываю коммиты, "красоту кода", именование переменных и не перепроверяю за агентом каждое движение мышкой. Для этого есть CI: тесты, линтеры, сборки и прочие quality gates. Красное — не едем. Зелёное — можно начинать проверять, что мы вообще сделали.

И квалифицированные человеческие проверки обязательны! За последнее время я несколько раз получал вполне "готовые" изменения, которые:

1. собирались по частям, но не собирались целиком;
2. показывали интеграцию в интерфейсе, но не могли выполнить реальный запрос;
3. успешно выполняли запрос, но ломались на авторизации;
4. проходили профильные тесты, но падали в полном CI;
5. технически работали, но решали немного не ту задачу
6. реализовывали всё как запрошено, только в результате получалось, что запрошена фигня и требования надо полностью пересматривать.

И вот здесь начинается настоящая работа продуктового разработчика.

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

Можно проверить, что кнопка есть, что сервер отвечает, что инструмент зарегистрирован. А потом пользователь нажимает кнопку — и получает пустой экран, странную ошибку биллинга или вежливое предложение купить подписку вообще у другой компании.

Поэтому для себя я выработал несколько правил.

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

2. Если возникает архитектурная развилка — решение принимает не агент. Он должен принести варианты, последствия и цену каждого.

3. Перед публикацией обязательно спрашиваю: что проверено узко, что проверено целиком, был ли отдельный simplify-проход и что осталось непроверенным.

4. После зелёного CI проверяю продуктовый сценарий руками. Причём не только happy path, но и один-два неприятных случая: истёкший токен, отказ в доступе, повторный запрос, отмена операции. В некоторых случаях неплохо бы провести более или менее крупный регресс — ответственность за понимание импакта изменения лежит на мне.

5. Если исследование касается реального стенда, отдельно требую от агента пруфов: подтверждены ли его утверждения исходниками, рассуждениями на основании общих знаний и треда выше или действительно проверено на выкаченной версии? Это три разных уровня правды.

Многое из этого постепенно уедет в quality gates. Полный typecheck, сборка конечного артефакта, интеграционные тесты, проверки безопасности и стандартные сценарии не должен каждый раз вспоминать человек. Если ошибка уже случилась дважды — это не повод внимательнее читать отчёты агента. Это повод превратить её в автоматический турникет.

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

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

Главный навык — понимать, где автоматике можно довериться, а где человеку всё ещё необходимо проконтролировать: "Мы точно сделали то, что нужно было сделать?"

Пока вы гоняете кодинг-агента в пет-проекте или микро-стартапе на пару тысяч строк, проблем нет: белковый разработчик видит каждый diff и правит костыли вручную. Адочек начинается при масштабировании автономии, когда агенту дают задачу "сделать зелёный CI любой ценой".

Модель — рациональный вычислитель. Если зажать её метрикой прохождения тест-сюита, она начнёт хакать тесты по пути наименьшего сопротивления:
• Выхолащивание тестов: выпиливание ассертов или ослабление условий проверки, если есть доступ на запись к /tests.
• Overfitting под моки: хардкод значений под конкретные входные данные фикстур вместо честной бизнес-логики.
• Засор контекста: попытка залечить проблему слоями костылей, превращающая ветку в радиоактивный технический долг.

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

• AST Delta Validation: Проверка AST-дерева до и после итерации. Если в diff'е появляются выхолощенные условия, маскировка ошибок через catch (e) {} или изменения файлов внеScope — пайплайн сразу режет попытку без вызова LLM.
• eBPF/gVisor Sandboxing: Запуск тестового контура в изолированном пространстве без сетевого доступа, чтобы модель не затягивала ответы с внешних эндпоинтов и не подменяла окружение.
• Atomic Rollback Strategy: Любая гипотеза агента прогоняется как отдельный изолированный коммит. При 2+ неуспешных итерациях — жесткий git reset --hard и очистка контекста. Кормить модель её же галлюцинациями из прошлых попыток — верный способ сжечь бюджет.
• Mutation Testing Gate: Валидировать устойчивость тестов (через условные mutmut / cargo-mutants) до запуска агента, чтобы у него не было шанса пролезть сквозь «слепые» ассерты.
• No LLM-as-a-Judge on Code Review: Заменять ревьюера той же самой LLM — плохая идея. 100% должна присутствовать качественная статическая проверка качества (linters, AST parsers, test runners).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я тут немного учусь на "настоящего управленца" (бесит это слово, честно говоря), и вот что наблюдаю.

Первое: мы с вами в пузыре. Мы привыкли, что в организациях есть процессное управление, ну или хотя бы представление о процессах. Или, например, есть представление об управлении знаниями (все наши вики и architecture as a code — это оно). Многие в курсе про качество и даже слышали про ISO 9000. То есть, мы с вами чаще всего работаем в компаниях, где всё это есть. Часто ещё и с заимствованными с запада практиками управления и опорой на стандарты. Я имею в виду банки, крупную промышленность, крупный ритейл, интернет-компании — многие из которых изначально создавались иностранцами, как Авито и Ламода. Иногда этот подход проникает даже в образовательные проекты типа Сириуса и Летово.

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

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

Поэтому такой управленец постоянно изучает: кто же такие его работники и что как они реагируют на разные воздействия. То есть, постоянно их типирует. По разным психологическим и псевдопсихологическим тестам. По Герчикову, Белбину, Адизесу, DISC, MBTI, Big 5, уровень эмоционального интеллекта, стиль решения задач по Алану Роу и т.д. Заодно типирует среду в компании и отслеживает социальные связи: кто, с кем и зачем общается. А также — и вот тут я немного удивился — так же всё время типирует себя.

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

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

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

Знаете ли вы себя и команду?

Вас не заменит AI, вас заменят процессы

Есть такой опенсоурс продукт для аналитиков AI IDE BAS — плагин для VS Code, в котором можно разрабатывать требования, делать техдизайн, генерить спеки.

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

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

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