Хотел написать небольшой пост – а в итоге получилась целая статья.

Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.

Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна

Заходите почитать, если понравилась ставьте лайкосики.

#devfm

Зачем вы проводите код-ревью?

Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.

И каждый PR дисциплинированно пропускают через код-ревью: назначаются ревьюеры, они что-то пишут, код как-то правится...

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

Ответы бывают разные.

Мы хотим поддерживать качество кода, соблюдать единый стиль.
Что ж, похвально. Только у меня сразу возникает вопрос: а что вы считаете качественным кодом, что считаете единым стилем? А у вас настроены какие-то автоматизации? Ответы бывают разными, но по моему опыту редко есть уверенные ответы на все из них. А без этого код-ревью очень быстро превращается в вкусовщину и в обсуждение того, что вообще-то должна делать машина – линтеры, форматеры, базовые проверки.

Ревьюеры могут найти баг или проблему.
Вот с этого я искренне всегда недоумеваю. У меня сразу возникает вопрос: а кто у вас пишет код, если ревьюеры, не находясь в глубоком контексте задачи, могут заметить баг? Если баги регулярно ловятся на код-ревью, значит вы используете самый дорогой, самый медленный и самый ненадёжный механизм контроля качества. Ревью не воспроизводимо, не масштабируется и слишком сильно зависит от человеческого фактора.

Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.

И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?

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

Первое – составить гайд, хотя бы выровняться по одной линейке: как в команде проводится ревью, что мы ревьюим, на что обращаем внимание, а что считаем минором, тайминги проведения, выбор ревьюера, правила оформления PR-ов.

Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.

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

Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время

Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.

#devfm

Книга "Цель"

Недавно прочитал довольно известную книгу Цель Элияху Голдратта.

Это попытка донести управленческие идеи через художественное повествование – и именно этим книга мне понравилась. Она читается легко, местами даже захватывающе.

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

Но ключевая смысловая нагрузка книги – не в управлении заводом как таковым.

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

Читая книгу, я поймал себя на мысли, что идеи из неё перекликаются с подходами канбана.

И напомню: у нас скоро заканчивается конкурс на самую интересную цитату из практики.
Приходите, голосуйте, приносите свои. Как говорится, от нас пуля вылетела 🙂

Каникулы ещё не закончились – самое время спокойно почитать что-нибудь полезное.

Собрал подборку лучших постов за прошедший год – если пропустили или хотите вернуться к избранному:
– Зачем нужен шаблонный сервис и пример такого сервиса на FastAPI
– Чтобы провести встречу продуктивно, нужно постараться. Мы написали, что сами применяем на практике
– Видео про роли в крупном проекте – аналитики, разработчики, тестировщики и как всё это живёт вместе
– Набор заметок о том, зачем нужны архитектурные схемы, как их составлять и где проходят зоны ответственности
– Пост-стенание на тему код-ревью
– Революционный метод организации рабочих чатов
– Сайт с сериалами на разных языках и бот для изучения иностранного языка методом карточек
– Мой опыт работы с ai-агентами
– Приём, который помогает быстрее принимать решения в команде
– Как не забивать на написание постмитов
– Статья о том, как написать своего первого ai-агента
– Советы и антипаттерны при работе с Postgres
– Очень крутой курс по System Design, который искренне рекомендую

#devfm #backup

Еще один способ работать с ai-агентами

Завтра начинаем работать, но никогда не поздно начать то, что давно откладывал.

Сейчас AI-агенты, действительно, умеют многое. И если с большими проектами всё ещё бывает непросто, то для MVP или пет-проекта – это супер классный инструмент.

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

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

Рекомендую попробовать spec-kit.

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

Главный плюс такого подхода – он сам подталкивает к определённому флоу, чтобы ничего не забыть. Явно подсказывает следующий шаг. Если прервался – можно продолжить с того же места. Поддерживается разными агентами: Claude Code, Copilot, Cursor и другими.

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

Например, чтобы подбить статистику по популярным постам, я сделал небольшой сервис tganalytics – собирает информацию из любого публичного канала в Telegram и позволяет сортировать посты по популярности.

Из полезного:
– когда подписываешься на новый канал – удобно посмотреть самые популярные посты
– бэкап собственного канала
– база для RAG и собственной базы знаний
– выгрузка контента – я так делаю для кулинарных каналов

Если интересно – заходите, попробуйте. А если что-то не полетит – приходите, поправлю.

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

#ai

Я в целом скептически отношусь к курсам. Но так вышло, что как-то время от времени присматривался к курсам Стратоплана – и тут ребята сами предложили пройти у них обучение на курсе CTO.

Сначала подумал: столько в меня не влезет. А потом решил – почему бы и нет. Впихнуть невпихуемое – это мое:)

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

Поступление состоит из двух этапов.

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

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

Второй этап – что-то вроде собеседования. Но по сути это просто обсуждение твоего опыта, чтобы подобрать группу, с которой будешь плотно работать в процессе.

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

Когда у задачи нет даты

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

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

Но есть такие задачи, которые не привязаны к дате – они привязаны к событию.
Примеры из жизни: “когда поеду в Сочи – сходить в такое то место”, “когда будет синк по проекту – обсудить текущий CI/CD”. У этих задач нет конкретной даты, и непонятно, куда их складывать. Если просто кинуть в общий список – они точно потеряются. Если поставить произвольную дату – будут раздражать напоминаниями не в тот момент и постоянно еще придется переносить.

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

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

В общем мне такой прием помогает. Пользуетесь ли чем-то подобным?

#devfm #productivity

Кто такие Skills в ai-агентах?

AI-агенты ехают и бибикают в индустрии. Использование MCP уже стало для всех обыденностью, но с ними есть известная проблема – они жрут токены. Если подключено несколько MCP-серверов, то только начав диалог с агентом, половина контекста может улететь.
И вот тут недавно появилась интересная штука – Skills.

Сначала я подумал: ну что за зверь такой? Есть же уже команды, субагенты, MCP. Зачем нам еще Skills?

Одна из главных фишек – скилы грузятся на лету и поэтапно, а не всё сразу.

Три уровня загрузки:
– Level 1 – Metadata. Загружается всегда при старте. Это просто name и description из YAML-шапки. Claude знает только, что скилл существует и когда его использовать
– Level 2 – Instructions. Загружается, когда скилл триггерится. Основное тело SKILL.md с инструкциями и воркфлоу
– Level 3 – Resources. Загружается по необходимости. Дополнительные файлы, скрипты, шаблоны

То есть если у вас скилл для написания e2e-тестов – он подгрузится только когда речь зайдёт об e2e. До этого момента в контексте болтается только одна строчка с описанием.

Что внутри скилла
Скилл – это не просто файлик с инструкциями. Это директория с модульной структурой. Можно разбивать знания на отдельные файлы – агент подгрузит только то, что нужно для конкретной задачи. Можно добавлять скрипты – и тогда в контекст попадёт только результат выполнения, а не сам код.
Скилы сейчас поддерживаются всеми основными агентами: Cursor, Claude Code, Codex.

Я, например, использую:
– Playwright Skill – описываешь задачу на естественном языке, агент сам пишет и выполняет автоматизацию браузера. Открывается реальное окно, видишь что происходит, получаешь скриншоты и логи
– Frontend Design Skill – на тот случай, когда нет дизайнера, но хочется сделать достаточно хорошо. По умолчанию агенты генерируют типичный дизайн сильно так себе. Скилл содержит рекомендации по типографике, цветам, анимациям – и результат становится заметно лучше

#ai

Правило трёх итераций – когда диалог зашел в тупик

Бывает обсуждаете что-то с коллегой или смежниками, не можете договориться. Обмениваетесь аргументами раз, два, три – и всё никак. Такой словесный пинг-понг получается.

И в этом потоке обсуждения почему-то кажется, что ещё одна итерация – и точно договоримся. Ещё раз объясню свою позицию, приведу новый аргумент, и собеседник наконец поймёт.

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

Поэтому после трех итераций – полезно притормозить. Что-то явно не так. Может, нужны артефакты – данные, метрики, примеры из прода. Может, не хватает контекста, который есть у кого-то третьего. А может, ваш собеседник просто упёрся – и тогда нужна эскалация или человек, у которого есть полномочия рассудить разногласия. Отложите, соберите отсутствующие пазлики и вернитесь к вопросу.

Три итерации – и тормозим, работает удивительно хорошо.

#devfm

Субботнее развлекательное

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

Нашёлся человек, который решил эту проблему по-инженерному – написал STFU.

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

Исходники тоже есть – можно глянуть.

RAG на практике

RAG – наверное, второе по популярности слово в индустрии после ai-aгент. Всем нужен RAG.

Наткнулся на статью победителя RAG Challenge. Это соревнование, где нужно было за 2.5 часа спарсить 100 PDF-отчётов (до 1000 страниц каждый) и построить QA-систему. Автор занял первое место. В статье описал весь пайплайн, показал код, рассказал, на какие грабли наступил – получилось очень интересно и практично.

Парсинг
Первый этап – превратить PDF в текст. Казалось бы, стандартная задача. Автор перепробовал пару десятков парсеров и пришёл к выводу: нормальных не существует. Таблицы разваливаются, многоколоночный текст путается. Пришлось форкнуть Docling и допиливать руками.

Индексация
Дальше текст нарезается на куски и складывается в векторную базу для поиска. Ключевое решение – отдельная база на каждую компанию. Зачем мешать метрики разных компаний в одну кучу? Область поиска сразу сужается в 100 раз.

Поиск
Векторный поиск возвращает топ-N результатов, но ранжирует их довольно грубо – при векторизации часть смысла теряется. В итоге в топ-10 попадает релевантная информация, но не всегда на первых местах.

Логичная идея – добавить классический текстовый поиск (BM25) и скомбинировать результаты. Автор попробовал – не зашло. Гибридный поиск чаще ухудшал качество, чем улучшал.

Зато сработал другой подход: достаём топ-30 из векторного поиска и просим gpt-4o-mini оценить релевантность каждого куска. Получается точнее, чем любой алгоритмический реранкинг. И стоит меньше цента на вопрос.

Генерация ответа
Чем больше правил даёшь модели в одном промпте, тем хуже она им следует. Модель начинает что-то игнорировать или путать.

Решение – роутинг, в зависимости от типа ожидаемого ответа вопрос уходит в разные промпты. В каждом – только релевантные правила.

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

Помогает Structured Output + Chain of Thought: модель сначала рассуждает в отдельном поле, анализирует контекст с разных сторон, и только потом даёт ответ. Это заметно снижает количество галлюцинаций.

Неоднозначность
Отдельная история – что вообще считать правильным ответом. «Who is the CEO?» – звучит просто. Но CEO это только Chief Executive Officer? Или Managing Director тоже подходит? А President? И таких вопросов в бизнес-области может быть мильон.

Автор называет это – порогом свободы интерпретации. И его приходится калибровать с заказчиком вручную, разбирая edge cases.

Вывод такой, что для построения RAG нет одного магического решения. Качество складывается из мелочей на каждом этапе. И чем глубже понимаешь задачу – тем точнее можешь эти мелочи настроить.

Статью очень рекомендую.

#ai

Не могу не поделиться. Александр Поломодов часто пишет и выступает про System Design. Особенно много внимания уделяет System Design интервью.

И вот он собрал многие материалы в одном месте – сделал сайт , посвящённый этой теме.

Если вам актуально – очень рекомендую заглянуть. Надеюсь, проект будет развиваться.

Встречайте новый формат инженерного диалога

T-Sync Conf — офлайн-конференция от Группы «Т-Технологии» для опытных инженеров. 7 февраля в Москве на площадке TAU соберутся платформенные, security- и дата-инженеры, аналитики, DevOps-, SRE-, CI/CD-, AI-, ML-, R&D- и DX -специалисты.

Как все устроено:
— Контуры — тематические зоны, каждая из которых раскрывает отдельный слой инженерной реальности: AI, Data, R&D, Security, Platform и другие направления.
— Вместо классических докладов — круглые столы, стенды, хакатон, воркшопы и мастер-классы.
— Инженерные решения изнутри — возможность посмотреть, как устроены технологии в Т-Банке и других компаниях, и пообщаться напрямую с теми, кто их создает.

А еще много практики, интересных знакомств и живых систем.

Успейте подать заявку

Управление изменениями
Книга "Управление изменениями без потрясений и конфликтов" Адизеса

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

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

Одна из областей, где давно хотел систематизировать знания – понимание особенностей людей. Какие бывают типы, как они действуют, принимают решения. Интуитивно понимаю, что делать, но четкой структуры не было. Решил начать с классики – Адизеса.

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

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

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

Они по-разному понимают одни и те же слова. "Да" для одного типа – это действительно "да". Для другого может означать "может быть". А для третьего – вежливый способ сказать "нет".

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

Конфликт как норма
А раз люди разные – конфликт неизбежен. Один хочет делать сейчас, другой хочет сначала всё продумать, третий хочет менять направление, четвёртый хочет чтобы все договорились. Адизес утверждает, что конфликт – по сути необходимое условие хорошего решения. Плохо не когда команда спорит, а когда не спорит – значит кто-то молчит или всем всё равно.

Но конфликт бывает конструктивным и деструктивным. Разница – во взаимном уважении и доверии. Если они есть, разногласия ведут к лучшим решениям. Если нет – то ничего хорошего не получится.

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

Адизес вводит концепцию CAPI – Coalesced Authority, Power, Influence. Authority – это формальное право говорить "да" или "нет". Power – возможность поощрять или наказывать. Influence – способность убеждать без принуждения. Чтобы изменение реально случилось, нужно собрать все три компонента. Можно быть правым и иметь лучшее решение – но если нет полномочий, власти или влияния, ничего не произойдёт.

Менеджерская результативность – это по сути способность собрать нужный CAPI под свои задачи.

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

#books