Хвост инженера

Автор: Екатерина Давыдова · AvitoTech

Екатерина Давыдова — программный менеджер в Авито, ведёт внутреннюю программу, которая объединяет все GenAI-команды компании. Авито — один из крупнейших классифайдов мира, и в этой связи их опыт выстраивания работу с GenAI отличается от опыта стартапов с «чистым листом».

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

Формат — не история успеха, а производственный разбор. Что делать на каждом шаге, какие этапы выпадают при планировании и потом больно бьют, и почему «80% компаний сказали что начали что-то внедрять, но только 10% смогли объяснить — что именно».

Кому смотреть: продуктовым лидерам, которым пришла задача «запустить что-то на GenAI» — и…

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. Event Storming — воркшоп-техника, разработанная Альберто Брандолини. Сессия начинается не с рисования схем, а с вопроса: какие события происходят в системе? И именно этот порядок меняет всё.

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

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

Из этого можно взять в…

Автор: Кирилл Мокевнин · TechLead Channel

Кирилл Мокевнин — основатель Hexlet, образовательной платформы для разработчиков. Он не просто учит программировать — он годами наблюдает, где люди застревают, и думает о том, чему именно нужно учить. Доклад на TechLead Conf.

Название доклада намеренно отсылает к «Гарри Поттеру и методам рационального мышления» — книге о применении научного мышления к реальным задачам. Мокевнин идёт тем же путём: берёт «Прагматичного программиста» Ханта и Томаса и разбирает, что за этим словом стоит на практике. Вывод неудобный: большинство обучающих материалов учат решать задачи с известным правильным ответом — алгоритмы, паттерны, синтаксис. Реальная работа — это задачи с неизвестным правильным ответом, где нужно выбрать направление при неполных данных, попробовать, получить обратную связь и скорректироваться. Этот навык почти нигде не преподают явно — и именно поэтому технически грамотные разработчики застревают на одном уровне годами.

Ценный угол: Мокевнин смотрит на обучение не…

Автор: Егор Заплатин · Яндекс Вертикали

Егор Заплатин — фронтенд тимлид в Яндекс Вертикалях (Путешествия, Аренда, Авто.ру). Доклад на Vertis JS 2026: полгода работы с AI-агентами в реальных задачах, выводы о том, что нужно сделать, чтобы они работали предсказуемо.

AI-агент не замещает инженера — он меняет то, на что инженер тратит время. Заплатин это понимает, хотя в докладе использует популярную аналогию «прокачать до мидла» — скорее как метафору для аудитории, а не буквальное сравнение. Содержательная часть, если убрать маркетинговую рамку, прикладная и по делу.

Центральная мысль: если ваш агент работает — это ещё ничего не значит. Надёжная работа в production требует инженерии. Заплатин разбирает четыре конкретные практики: правильно выстроенный контекст (что агент видит и в каком виде), feedback loop (как агент получает сигнал об ошибке и исправляет курс до конца задачи), MCP-интеграции (реальные инструменты вместо угадывания по обучающим данным), и скиллы — описания того, как решать конкретные задачи в…

Автор: Александр Макаров · Организованное программирование | Кирилл Мокевнин

Александр Макаров — Lead of Yii Framework, CTO нескольких компаний — пришёл с провокацией: «трофей» вместо «пирамиды тестирования». Идея в том, что классическая пирамида — карго-культ. Она хорошо работает на первом проекте, а потом перестаёт отражать реальную архитектуру системы и реальные риски.

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

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

Из этого можно взять в работу: вместо того чтобы спорить «юниты или интеграционные» — спроси: что ты называешь…

Автор: Сергей Андржеевский · ScrumTrek

Сергей Андржеевский выступал на Ag;)eDays 2011 — одной из ранних российских Agile-конференций. Доклад старый, но вопрос, который он разбирает, не устарел: как работают XP-практики в условиях, когда команда разделена географически и работает на внешнего заказчика.

Офшорный проект — это специфический контекст. Разные часовые пояса, заказчик, который не сидит рядом, контрактная модель, которая создаёт стимулы скрывать проблемы, а не решать их. XP создавался для команды в одной комнате с заказчиком рядом. Андржеевский рассказывает, что из XP работает в офшорном контексте, что требует адаптации, а что — предположение, которое офшор разрушает принципиально. Центральный тезис: парное программирование и TDD в офшорном контексте — это не способ быстро работать, это способ поддерживать качество без прямого контроля. Заказчик не видит код — он видит результат. Дисциплина XP-практик создаёт доверие через предсказуемость результата.

Кому смотреть: тимлидам и менеджерам в распределённых…

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях, объясняет практики разработки коротко и без академической перегруженности. Этот выпуск — девятиминутный обзор Extreme Programming (XP).

Большинство разработчиков знают отдельные XP-практики: TDD, парное программирование, непрерывная интеграция. Многие применяют их в изоляции. Суть XP в том, что эти практики спроектированы как система: TDD даёт быструю обратную связь, парное программирование распределяет знание о коде, CI гарантирует, что интеграция не накапливает долг. Убери одно — другие становятся менее ценными. XP существовал до Agile Manifesto (Кент Бек опубликовал книгу в 1999-м), и многие принципы манифеста 2001 года прямо из него вышли. При этом XP как целостная система встречается в командах гораздо реже, чем Scrum, — хотя технические практики у него сильнее.

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

Из этого можно взять в…

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях и процессах, объясняет сложные концепции коротко и структурированно. Это видео — обзор Agile: не реклама и не критика, а попытка разобраться, чем Agile является на самом деле.

Большинство команд, которые «работают по Agile», работают по Scrum или Kanban — и это не одно и то же. Agile — это набор ценностей и принципов, сформулированных в Манифесте 2001 года. Он не описывает церемоний, ролей и спринтов. Scrum — это уже конкретный фреймворк, одна из возможных реализаций. Путаница между ними ведёт к тому, что команды «внедряют Agile» через ретроспективы и стендапы, не меняя при этом отношения к изменениям и клиенту — и потом удивляются, почему не работает.

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

Из этого можно взять в работу: спроси на следующей ретроспективе: «Какую…