У технологічних компаніях AI уже виходить за межі тренду та впливає на продукт, інженіринг і щоденні бізнес-процеси. Разом із можливостями з’являються й виклики: робота з чутливими даними, вимоги безпеки та складність інтеграції в існуючі системи. У таких умовах важливо розуміти, де AI справді створює цінність, а де — лише додає шум. Під час дискусії учасники поділяться практичним досвідом: як вони впроваджують AI у продукт, адаптують інженірингові процеси та перебудовують операційку під нові інструменти. Це розмова про реальні болі, можливості та рішення, які допомагають командам рухатися вперед.

Як за лічені години побудувати власне середовище для генеративного ШІ — від ідеї до робочого рішення? Під час виступу команда De Novo поділиться практичним досвідом створення керованого середовища для GenAI, розповість про архітектуру, підхід до безпеки та реальні сценарії використання в українських компаніях.

Рожева мрія багатьох дизайнерів «втікти з фрілансу/аутсорзу і попасти на продукт». Давайте розберемось чи настільки круто бути продуктовиком, який скілсет потрібен для цього і чи не призведе це до професійної деградації.

Усього за 20 хвилин Сергій Сарайчиков, засновник A42 і один із топових білих хакерів Prozorro, покаже чому 80% атак починаються зі звичайного збору даних про вашу компанію. Ви дізнаєтесь, які типові помилки відкривають шлях до зламу, як автоматизовані системи знаходять ваші слабкі місця швидше, ніж ваші команди, та як побудувати моніторинг активів, який реально запобігає витокам. Це must-see для СТО, які хочуть бачити інфраструктуру очима атакуючого й отримати готову стратегію контролю ризиків без зайвих витрат.

У міру того, як команда зростає, з`являються нові продукти, а інженерна команда проходить етапи трансформації - роль CTO легко перетворюється з технічного лідера на менеджера, що дивиться у таблиці та аналітику. І саме в цей момент настає найскладніше: не втратити технічний контекст, не відстати від архітектури, і реального стану справ у командах. У цій доповіді я поділюся власним досвідом: як залишатися Hands-on CTO - зберігати глибоке розуміння технічної бази, впливати на архітектуру й одночасно масштабувати компанію, не перетворюючись на "менеджера без коду". Основні теми, які ми розглянемо: - Як змінюється роль CTO у міру росту компанії - від кодера до системного лідера. - Найпоширеніші пастки: втрата архітектурної пам’яті, розрив між бізнесом і технічкою, залежність від кількох ключових людей. - Хороші звички, що допомагають утримувати технічний контекст: code-review, архітектурні стендапи, "walk the code", R&D-спринти CTO. - Системи прийняття рішень: як використовувати ADR / RFC, щоб зберігати прозорість і контроль. - Комунікація з техлідерами: ефективні формати 1:1, технічні сінки. - Інструменти та платформи, які допомагають не втратити контекст - дашборди, системи моніторингу, архітектурні огляди.

Бути тімлідом - це як кермувати космічним кораблем, де кожен член екіпажу має свій темперамент і траєкторію. Модель DISC - це GPS, що допоможе не згоріти в атмосфері «штормінгу» й вивести команду на стабільну орбіту «перформінгу».

Сучасні кібер загрози потребують від CTO сучасних підходів до реагування та протидії. Розвиток даркнету як маркетплейсу скомпрометованих облікових даних(credentials) вимагає впровадження нових методів захисту. Ми поговоримо про безпеку авторизації в SaaS сервісах. Я розповім, які існують сучасні загрози, наскільки 2FA може захистити проти використання злитих даних, що робити якщо скомпрометовані cookies разом із session tokens, та розглянемо кейси, як автоматизація darknet моніторингу допомагає CTO у забезпеченні безпеки не тільки власного продукту, а й також third-party supply chain сервісів(Slack, GitLab, Jira, CRM), партнерів та C-level тощо.

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

Ми звикли довіряти відчуттям: здається, що процеси працюють, а продукт якісний. Але відчуття не масштабуються. У цій доповіді я покажу, як ми перейшли від інтуїтивних рішень до системи метрик, яка вимірює якість продуктів і процесів у реальному часі. Як команди, маючи «приборну панель», самі керують розвитком своїх продуктів із точки зору якості. І головне — як технічні метрики стають зрозумілими бізнесу, допомагають говорити про ризики однією мовою й приймати рішення на масштабі.

У кожного інженера — своя дорога в IT. Моя почалася не з красивих презентацій і чітких планів, а з того, що мене на крані піднімали ремонтувати екран на стадіоні «Металіст». Потім були телеком-проєкти, автотести, Red Hat, OpenStack, OpenShift — і постійний пошук, куди рухатися далі. З часом прості кострубаті скрипти, які я писав лише щоб зекономити собі кілька годин, почали тримати прод. «Пожежі» стали приводами для нових рішень, а експерименти — досвідом, який справді працює. І десь у цьому всьому були моменти, коли я хотів піти з IT. Але натомість з’явилися DevOps01, ком’юніті, а згодом — AWS та HashiCorp-амбасадорство. У цьому виступі я розповім, як постійний пошук себе у професії та професії в собі став тим самим двигуном, що змінив не лише кар’єру, а й життя. Як маленькі ініціативи виростають у великі системи, а спільнота відкриває нові двері.