Все рано или поздно задумывались, а куда мне развиваться дальше? Кто-то дополнительно занимался аналитикой, кто-то бэкендом, но вот мой путь пошел в сторону SRE и в своем докладе я расскажу, что вам удастся развить в себе как разработчику, если вы решите пойти по данному пути. Как научитесь разбираться в инцидентах, искать корневые причины возникновения и пути их исправления. Но и самое главное, как это повлияет на вас как фронтенд разработчика ибо вы станете гуру в проектировании и разработке безопасных и отказоустойчивых систем.

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

Каждый месяц в реестре NPM публикуется 30-40 тысяч новых пакетов и огромное количество обновлений существующих библиотек. Что там лежит - очередное обновление React, полезная доработка axios или "небольшие правки", нацеленные на кражу данных ваших криптокошельков, - никто не знает.

При этом, работа с реестром NPM - неотъемлемая часть нашей жизни, и доля опенсорса в современных проектах иногда достигает 80-90%.

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

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

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

Вместе построим роутинг, который работает на ts. Не используя никаких сторонних библиотек, имея в руках только react-router-dom, соберем систему, при которой все параметры и урлы станут строго типизированными. Долой строки!

Многие фронтенд-разработчики сталкиваются с ощущением «карьерного потолка», достигнув уровня сеньора. Как выбраться из этого замкнутого круга и открыть для себя новые перспективы? В рамках доклада мы разберем, почему фронтендеры часто застревают на одном уровне, какие компетенции помогут вырасти в роли архитектора, Staff Engineer или даже Technical Fellow, и как сформировать собственную матрицу навыков для устойчивого профессионального роста.

Вы узнаете:
- Какие качества ценятся на высоких технических позициях и как их развивать.
- Как двигаться в сторону бизнес-ориентированности, не теряя экспертности.
- Как определить свои слабые стороны и превратить их в точки роста.

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

Какая была задача. Для чего Директу приложение?
Выбор технологии. Какие варианты? Почему именно WebView?
Как работает приложение
Пуш-уведомления
Другие технические вызовы. Избавляемся от "вебности" в приложении
Как устроен релизный цикл

Библиотеки компонентов играют важную роль в большинстве проектов.
При самостоятельной разработке компонентов мы стремимся сделать их гибкими и универсальными, чтобы они подходили для различных случаев. Но является ли это оптимальным подходом? Может ли ограниченный компонент быть лучше гибкого? Да, может! В своем докладе я продемонстрирую, каким образом ограничение API UI-компонента способствует более эффективному выполнению его задач и облегчает его использование для разработчика.

«Плох тот солдат, который не мечтает стать генералом», — гласит народная мудрость.

«Плох тот разработчик, который не мечтает стать СТО», — перефразировал я эту фразу.

Я в своей работе неоднократно встречал убеждение, что техлиды и более высокие технические менеджеры — это бывшие бекендеры, а фронтендерам наверх дорога закрыта.

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

Frontend-приложения могут иметь сотни транзитивных зависимостей, Supply Chain-атаки в NPM происходят все чаще. Js-код минифицируется при сборке, а браузер пользователя всегда является "слепой" зоной с т.з. безопасности. Поговорим об актуальных рисках, угрозах для frontend-приложений, разберем известные инциденты. Рассмотрим, как сделать FrontSecOps в DevSecOps, совместить E2E-тесты с безопасностью и прийти к Secure By Design

Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!

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

Сложно найти того, кому ни разу не приходилось обвешивать страницу событиями веб-аналитики. Этот процесс, выполняемый по четко-выверенному ТЗ олицетворяет из себя рутину - 20+ пунктов, каждый описывает конкретное событие и payload.

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

Берем углубленные знания веб-технологий, добавляем щепотку react internals и заворачиваем в системный подход. И вот эта адская смесь уже готова отправлять все нужные события самостоятельно!

Методология DDD(Domain Driven Design) появилась достаточно давно, а в русскоязычном сегменте ИТ начала набирать популярность во второй половине 10х годов. Больше всего, конечно, эту методологию используют в бэкэнде, и даже считают, что в соответствии с этой методологией можно писать код.
Я хочу показать, что методология !== технология, и рассказать, как использовать DDD на фронтэнде, как сделать вашу жизнь в команде лучше, понятнее и дружнее с помощью небольшого изменения ментальных конструкций, которыми вы оперируете.

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

В это докладе я расскажу:
- Зачем нужна сложная архитектура для плеера, а не просто тег video.
- Как старая реализация на redux и супер-компоненте тормозила разработку, убивала возможности развития и масштабирования
- Какие задачи окончательно заставили выделить ресурсы на тотальный рефакторинг.
- Каким образом мы переписали плеер на Mobx, распилили на модули, внедрили DI и интегрировали плеер в другие проекты холдинга

Как заставить команду писать красивый (поддерживаемый, понятный) код

1. Введение: зачем писать красивый код?
• Почему качество кода важно для команды и компании?
• Примеры проблем, которые возникают из-за разного кода.
• Краткий обзор инструментов и подходов.
• Почему стандартизация полезна для команды и компании?
2. Написание собственных правил для линтера
• Почему стандартных правил может быть недостаточно?
• Как писать собственные правила:
• - Примеры в rules для (ESLint).
• - Использование AST (Abstract Syntax Tree).
• Как внедрить собственные правила в проект.
3. SonarQube: мощный инструмент для анализа кода
• Что такое SonarQube?
• Какие метрики предоставляет SonarQube:
• - Code smells.
• - Уровень покрытия тестами (test coverage).
• - Технический долг.
• - Уязвимости и ошибки.
• Примеры пользы для бизнеса и разработчиков.
• Как подключить SonarQube к проекту:
• - Развертывание на сервере.
• - Интеграция с CI/CD.
• - Подключение к IDE.
4. Границы жесткости стандартов
• Можно ли запретить всё?
• Преимущества и недостатки жестких правил:
• - Упрощение онбординга новых разработчиков.
• Рекомендации: где стоит быть гибким, а где — строгим.
• Почему важно вовлекать команду в обсуждение стандартов.
5. Кейсы и примеры: демонстрация на практике
• Реальный пример линтера с кастомными правилами.
• Анализ реального проекта через SonarQube:
• - Выявление проблем.
• - Рекомендации по их устранению.
• Обсуждение: как это улучшило код и взаимодействие команды.
6. Заключение: путь к красивому коду
• Резюме: инструменты и подходы.
• Советы для внедрения:
• - Начните с небольших изменений.
• - Слушайте команду.
• - Делайте код-ревью частью культуры.

Обсудим следующие темы:
– Почему FSD так выстрелил
– Какая главная польза от FSD в проекте
– Почему многие критикуют FSD
– Какие архитектурные принципы FSD действительно работают, а какие можно выкинуть
– Evolution design, как FSD без мишуры

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

Хотите узнать, как искусственный интеллект может трансформировать работу фронтенд-разработчика? Этот доклад раскрывает, как ИИ помогает:

• генерировать фронтенд код из скриншотов интерфейсов;
• автоматизировать написание юнитов и интеграционных тестов;
• упрощать миграции между версиями фреймворков;
• создавать стор-модули, локализации и даже документацию;
• а еще рефакторить и не только.

Я поделюсь реальными примерами использования инструментов вроде Cursor, Codeium и Windsurf, расскажу о внедрении ИИ в повседневные задачи и о том, как это уже меняет фронтенд. Также обсудим, зачем и как разворачивать модели on premise, их преимущества и недостатки.

Исследуем API Picture-in-Picture в Chrome: как выносить за пределы браузера не только видео, но и любой (почти) контент - текст, графики, чаты и даже интерактивные элементы

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

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

Обычно для реализации подобного поведения нам необходимо использовать JavaScript.

Однако теперь это необязательно благодаря новой фиче в CSS.

В докладе расскажу про CSS Anchor Positioning и как с его помощью упростить разработку связанных друг с другом элементов.

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

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

Поговорим про:
- Области применения веб-компонентов: SPA, виджеты, UI-kit'ы. Универсальность веб-компонентов и их совместимость вне зависимости от используемого стека.
- В чем преимущество веб-компонентов перед фреймворками из большой тройки? Как они влияют на mindset разработчика?
- Нюансы работы с ShadowDOM.
- Ограничения технологии: SSR, доступность, использование в формах.

Не справляетесь с безграничным потреблением ресурсов в NextJS при использовании картинок? Надежда на сообщество Open Source разработчиков фреймворка угасла? После этого доклада вы избавитесь от всех страданий!

Я расскажу, как мы столкнулись с утечками памяти в NextJS из-за модуля оптимизации изображений и первыми решили проблему, вызванную модулем оптимизации изображений. Мы прошли весь путь от локализации проблемы до разработки open source решения и разработали утилиту next-image-cache-cleaner, которую вы можете переиспользовать у себя. В ходе доклада вы научитесь:

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

Мы привыкли, что JavaScript справляется со всем, но это не всегда так. Как только возникает задача ускорить вычисления, работать с железом или файлами, на сцену выходят нативные расширения. Но как их правильно писать в 2025 году?
В докладе разберем, как устроены нативные модули в Node.js и когда без них не обойтись, посмотрим на реализацию собственного нативного модуля с нуля, и ответим на вопрос, насколько актуален node-gyp в 2025 году и какие у него есть альтернативы.

Год назад мы уже обсуждали внедрение AI в производственный процесс: https://conf.ontico.ru/lectures/5495369/discuss
Поигрались, насмотрелись, сделали выводы. Для чего нужны мы руководители? Правильно, чтобы говорить о рисках.
Вот и теперь хочется поговорить о рисках и ошибках внедрения AI в SDLC.

Что происходит с производительностью, когда у тебя сотни модулей, микрофронты, отдельные команды на каждый крупный блок, и всё это работает в общем приложении, которым ежедневно пользуются миллионы людей?

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

Web Vitals — это только начало: пришлось внедрять собственные метрики, отслеживать поведение отдельных компонентов и делать замеры не на синтетике, а в реальном продакшене.

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

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

Иногда интерфейс начинает вести себя неожиданно: компонент обновляется, но получает устаревшие данные, или часть приложения перестаёт рендериться под нагрузкой. С такими эффектами я столкнулся при разработке корпоративного чата.
Оказалось, дело в приоритизации обновлений в React: он может отбрасывать низкоприоритетные изменения, что приводит к tearing (разрывам интерфейса). В докладе проведу разбор реального кейса: обсудим работу React под капотом и рассмотрим, как устроены lanes и concurrent rendering.

Поговорим о подходе с использованием инструмента TRPC https://trpc.io/, почему данный подход удобен, что такое End-to-end typesafe API. И как сделать свой собственный провайдер который позволит шарить логику в рамках проекта.

Введение в проблему
1. Дублирование кода
2. Сложность типизации REST
3. Интеграция с разными провайдерами БД

Архитектура пакета
1. tRPC-роутеры
2. Абстракция над БД
3. Zod-валидация

Преимущества подхода
1. Единая кодовая база
2. Автоматическая типизация
3. Гибкость (БД провайдеры)
4. Меньше boilerplate-кода

Пример приложения
1. Приложение Express + React SPA
2. Прототипирование

Ограничения и подводные камни
1. Не подходит для публичных API
2. Привязка к TypeScript
3. Сложности с кэшированием

Заключение
1. Упрощаем жизнь разработчикам
2. tRPC — это не замена REST
3. Ссылка на GitHub

Поговорим о пути создания интерфейса от момента MVP до запуска полноценного проекта. О том, когда нужно использовать библиотеку стилей и компонентов из open-source, а когда пилить своё. Если делаете своё, то как настроить флоу так, чтобы разработка нового не ломала старое. А если проектов много, но они плюс-минус одинаковые? А если у заказчика строгий брендбук и жёсткие правила? Можно ли брать готовую библиотеку или надо пилить что-то своё?

Атаки на цепочку поставок становятся причиной проникновения в компанию, которая занимается разработкой продукта. Манипулирование зависимостями в SDLC позволяет злоумышленникам массово получать доступ к рабочим станциям разработчиков, интеллектуальной собственности и дальше распространять вредоносный код. Использование LLM усиливает этот тренд и открывает новые возможности для атак.

Мы изучили нетривиальные векторы проникновения в разработку, которые открывают ML-модели. В докладе на примере реальных кейсов мы рассмотрим эффективные тактики и инструменты атакующих. В результате определим практические меры, позволяющие разработчику снизить риски для конвеера разработки. А также рассмотрим, как в этой задаче им помогает и мешает LLM.

В докладе мы подробно разберём, как работают динамические AMP-emails с точки зрения пользователя. Погрузимся в особенности HTML-разметки AMP, научимся создавать простые компоненты, отправлять POST и GET-запросы прямо из письма, обрабатывать ответы сервера и работать с состоянием (state). Мы посмотрим, как объединение состояния и сетевых запросов превращает обычное письмо в полноценное мини-приложение. Также обсудим процесс отправки AMP-email'ов, требования к отправителям (whitelist Google), поддержку со стороны почтовых клиентов и существующие ограничения технологии.

По статистике Веб-альманаха за 2024 год 87% сайтов в интернете используют веб-шрифты. При этом загрузить шрифт так, чтобы не съесть весь мобильный трафик пользователя, страничка не прыгала, а идеи дизайнеров не разбивались о суровую реальность рендеринга в браузере, всё ещё не просто.

В докладе я покажу, как готовить и подключать на сайт шрифты, что умеет CSS для работы с типографикой и почему для Core Web Vitals так важно работать со шрифтами правильно.

Распространено мнение, что CSS придает внешний вид html-элементам. Это не совсем верно. Он оперирует не блоками, которые вы видите в разметке, но боксами, сгенерированными на их основе.

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

Зачем мы пошли в PWA
1. Единый UX для всех платформ: web, mobile, WebView.
2. Обход ограничений стора: быстрые релизы, A/B-тесты, отсутствие модерации.
3. Низкий порог входа: не требует установки, доступен по ссылке.

Как мы это построили
4. Микрофронтенды + SystemJS: каждая команда — владелец экрана.
5. Платформа как продукт: единые сборки, дизайн-система, CI/CD, релизы.

UX и ощущение «нативности»
6. Анимации, свайпы, skeleton-экран — поведение как у мобильного приложения.
7. Поддержка WebView: плавность, адаптивность, совместимость с навигацией.
8. Работаем над нулевым временем загрузки: инкрементальная отрисовка, lazy loading.


С чем столкнулись
9. Производительность на слабых устройствах и в WebView — JS-оптимизации критичны.
10. Компоненты не учитывают мобильный UX: дорабатываем UI-kit.
11. Дублирование логики между mobile и web — работаем над переиспользованием. Шаг в WebView.

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

Side effects:

1) Несколько раз помусолим эвристики с разных сторон, часть из них точно отложиться в голове
2) Соберу много практических примеров и проваледирую у разработчиков и комитета, посмеемся над типовыми ошибками, чтобы их больше не делать
3) Будет много шуток

Ремарка: Хотя современные IDE, всё больше похожи на UI для написания кода, который стараеться помочь и предотвратить ошибки, автор любит сравнивать их с написанием текста в блокноте.

Также автор достаточно самокритичен страдает простой формой Дислексиии и сложной СДВГ. Никогда не писал идеальный код и достаточно самокритичен. Почти все свободное время тратит на размышления про более интерактивные и визуальные способы программирования и изучение новых frameworks.

Список эвристик от Nielsen Norman Group:
https://www.nngroup.com/articles/ten-usability-heuristics/

Инновационная часть доклада (набросок):

Ниже распишу примеры match эвристик на опыт разработчика (в большей степени Typescript/JS)

1. Понятный статус системы → REPL и realtime time debug, статусы подлючения к серверу и git, minimap для навишации по коду, консоль для отображения статуса не видимых в UI действий и многое другое)

2. Соответвие системы и миру пользователя → использовать названия переменных, свойств и стилей (camelCase, snake-case и прочие правила), термины и подходы принятые в конкретной среде разработки (напримере JS), а не как тебе вздумается

3. Контролиремость и свобода выбора (разработчики всегда хотят больше контроля) → Undo/Redo, Git Versions: Review, Restore и пр.

4. Консистеность и стандарты → Cистемность однотипных решений, DX Patterns, (проектируем одинаковые вещи одинаково). Typescript для описания в одном месте. того что используется в нескольких. Interfaces для как способность классов (Drawable, Iterable и пр.)

5. Предотвращение ошибок системы и пользователя → подсветка гарантированных ошибок перед выполнением кода, Typescript для гарнтирования прафильного ввода текст кода, отображение ошибок вместо выполнения программы, ошибки линтера, debug для поиска ошибок в верстке и коде и пр.

6. Уменьшение ментальной нагрузки →
показывать имена функции/метода в sticky headers чтобы не зопоминать в каком месте кода ты сейчас, уменьшать количество текста кода и дулированные обращения (локаничность), показывать выпадающие списки для типизированных свойсств (чтобы не запоминат и не ошибиться), быстрое условное присвоение c = bool? a : b и пр., JSX для как удобный язык разметки, state chart и пр.

7. Уменьшение механической нагрузки → горячие клавиши по выделениям, поиску, запуску, дебагу, переключению между окнами с кодом и отображением, ускорение code review и написания кода в нескольких местах (мне кстати до сих пор ломает мозг)

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

9. Понятность при информировании пользователя → текст, ошибки такой, что пожно понять в чем проблема, а не сразу Stack Overflow или Github issues (хотя в разработке как раз с этим плохо всё). Source map для минификации, чтобы понять где это был (а если отломалося source map, чинишь, а надо релизить)?

10. Помощь, onboarding и документация → документацию легко найти, она понятная и простая, есть разделы с чего начать и пр. соответвует стандартам и лучшим практикам, описаны варианты свойств и их типы, песочница для DS c перечнем возможностей и возмодностью применить варианты на лету и пр.

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

Примеры экзистенциальных выборов при проектировании интерфейса:

1) Disbales vs Hide - вечный спор (Disable только когда пользователю понятно как сделать enable. Hide - только когда очевидна смена контекста - новый диалог, явная смена selection).

2) Дублировать действие в двух местах или нет. Например кнопка [Close] и X в модальном диалоге (только когда очень высокое модальное окно. Дублировать плохо).

3) Потеря данных (как blocker баг) - это в т.ч. когда пользователь совершил случайно типовые действия, которые привели к потере (расскажу примеры потери данных при реализации черновиков нашего мессенджеры Squadus)

и др.

О себе:



Опыт выступления (года 3 не выступал, но постоянно делаю это в роли дизайн-директора внутри компании МойОфис):

Data Art Meetup: "Парное review. Управляемая и дружная команда без Bottleneck"
https:/youtu.be/wi7I3D0BMOE?t=2630

Профсо UX : "Кроссплатформенная унификация. На что обратить внимание и как развивать большой и сложный продукт" https:/vimeo.com/267044787 (самы первый доклад)

Обучающие видео про плагин Design System Organizer на английском:
https://www.youtube.com/watch?v=XtRfPe-vEXU

В слове “наставничество” сразу же чувствуется груз ответственности. Обучение молодого специалиста с нуля вызывает страх. Это и не удивительно, особенно если у наставника до этого не было такого опыта.

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

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

Расскажу о том как сломан найм в IT — от завышенных требований и фальсификации опыта до шаблонных алгоритмических секций и субъективных HR-фильтрах. А в конце мы проговорим про проверенные практики — от оплачиваемых пилотных проектов до blind hiring — чтобы сделать найм честным и результативным.

Вы наверняка слышали выражение Performance Review — многие его боятся, другие же считают простой формальностью. Но что если я вам скажу, что, на самом деле, это мощный инструмент развития, если подходить к нему осознанно. Как получить реальные карьерные перспективы, а не набор шаблонных фидбэков? Как структурировать результаты своей работы так, чтобы они были убедительными для менеджеров? В этом докладе мы разберём, как готовиться к перформанс-ревью, какие метрики и примеры стоит приводить, как объективно оценивать свои достижения и презентовать их так, чтобы они работали на вас.

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

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

Что такое вайбкодинг
База промптов и актуальных llm
Принципы работы с аи ассистентом (подход, мышление, структурность)
Как создавать мвп и цикл этапов
Практический пример создания приложения
Окружения и сервисы