З розвитком AI інструментів IT галузь досягла тієї точки, коли зробити новий проєкт часто стає дешевше і простіше, ніж підтримувати існуючий. Проте для багатьох великих довготривалих проєктів переписування з нуля не найкращий варіант, особливо якщо навчитися їх підтримувати та розвивати за допомогою Agentic інструментів. Досвід роботи з подібними проєктами у всіх ключових аспектах роботи з людьми, інструментами, технологіями і процесами розглянемо на прикладі реальних кейсів.

Більшість інженерів рано чи пізно стикаються з необхідністю проводити load testing: перевірити масштабування сервісу, протестувати нову базу даних або зробити performance benchmark для нової технології. І тут виникає питання — який інструмент обрати? Існуючі рішення добре працюють для HTTP-навантаження, але часто мають обмеження, коли потрібно тестувати інші протоколи, моделювати складні workload-патерни (open vs closed systems, skewed distributions, hot partitions) або запускати distributed load testing у кластері. У цій доповіді я розповім про NBomber — Load Testing Framework, який я створив для вирішення цих задач. Ми поговоримо про: - чому виникла ідея створити новий інструмент попри існування Gatling, Locust та k6; - використання .NET та мови F# для побудови latency-sensitive систем; - архітектуру NBomber; - як працює NBomber Cluster; - кілька практичних кейсів: database benchmarks, anomaly detection, Kubernetes integration, benchmark comparison та аналіз performance trends.

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

Якщо інженери не мислять як продакт-менеджери, це стає вузьким місцем у процесі та розвитку продукту. У багатьох командах інженери просто виконують задачі, тоді як PM-и самостійно несуть відповідальність за стратегію, контекст і ключові рішення. Результат? Повільні інновації, низька відповідальність, формат роботи “feature factory” та постійні зміни. У цьому виступі ми розглянемо, чи мають PM-и достатньо впливу, щоб перебудувати систему — а не лише мислення — і створити команди, орієнтовані на результат. Так, мають. І ми розберемо це разом із вами. Ви дізнаєтесь: • Чому виникають feature factory • Як з’являється перевантаження PM • Як передавати контекст і прийняття рішень вниз по команді • Як створити спільну відповідальність за метрики та вплив • Реальні приклади трансформації delivery-команд у product-команди

Розробка AI зараз впливає на всіх — тож давайте зануримось у неї разом. Усі хочуть, щоб AI-агенти замінили звичні інтерфейси. У цій доповіді я розповім про еволюцію нашого мультиінструментального AI-агента, створеного на Node.js поверх Google Vertex AI. Я поділюся нашим шляхом вибору правильних моделей та масштабування розробки за допомогою CI/CD, TDD і моніторингу продуктивності. Але виникає питання: чи взагалі можливо досягти стабільних результатів у AI-проєктах, де моделі можуть галюцинувати та повертати різні відповіді? Цікаво, що з часом ми вирішили відмовитися від MCP-серверів і валідації схем через Zod — технологій, які часто вважають «стандартом» для таких задач. Хочете дізнатися, чому ми відійшли від них? Приходьте на мою доповідь, щоб отримати ці інсайти та поставити свої запитання наживо.

- Проф-деформація і її наслідки. - Упередження і сприйняття ринку - як віднайти баланс? Поговоримо про дві важливі складові профілю будь-якого досвідченого продукт-лідера - його експертизу, котра може стати тягарем і різницю в динаміці розвитку тої самої експертизи і власне ринку до якого вона дотична. Питань точно буде більше ніж відповідей, але пошук відповіденй стане цікавою пригодою для "домашнього завдання"

Сервіси AI-генерації відео розвиваються дуже стрімко й фактично відкривають новий спосіб створення відео — у момент, коли стандарти, мова та правила цієї індустрії ще тільки формуються. Це схоже на перевинайдення кінематографа, де поки немає “правильного” підходу, але вже видно, що саме заважає перетворювати генерацію на керований продакшен-процес. Я поділюся ідеями, як можна вдосконалити існуючі платформи, спираючись на режисерський досвід: які потреби режисера продукт має враховувати, де сучасні сервіси найчастіше ламають пайплайн, і які продуктові зміни можуть дати відчутний приріст якості результату. У фокусі — платформа, яка однаково добре працює для двох аудиторій: досвідчених відеомейкерів, яким потрібен контроль і передбачуваність, та “native AI” авторів, які почали шлях у відео з генерації й не мають досвіду реального продакшену; для обох окреслю логіку пайплайну “ідея → генерація → чорновий монтаж → експорт”, мінімально необхідний монтаж у сервісі та професійний експорт у Premiere/DaVinci для фіналізації.

Розповідати про щось абстрактне легко і прикольно – і розумним можна прикинутися, і перевірити тези ніяк не вийде – це ж абстракція. У світі, де кожен перший тепер "ШІ-візіонер" я хочу поговорити з вами про ШІ максимально предметно на прикладі своєї роботи – GitLab.  І це ідеальний приклад, поки всі розповідають про світ рожевих поні – greenfield проєкти, де все пишеться з нуля, я хочу поділитися досвідом хардкорного brownfield – що де і як на проєкті, що існує багато років. Ми поговоримо про те: - Як ми дружимо (або скоріше ні) штучний інтелект та джаваскрипт - Мої налаштування та секретний соус для агентської розробки - Які мої досягнення на пару з Опусом (улюблена моделька) - Скільки коду на джаваскрипті я пишу руками - Що заважає нам отримати оту міфічну х10 продуктивність і що я з цим роблю Я сподіваюся, що з цього case study кожен вийде з розумінням, а що саме зробити на своєму проєкті, щоб покращувати життя вже просто зараз.

Більшість використовує штучний інтелект насамперед як інструмент підвищення продуктивності — щоб виконувати задачі швидше та якісніше. Однак чи можемо ми розвиватися швидше та якісніше завдяки ШІ? З одного боку, ШІ як дизайнер планів допомагає визначати кроки для досягнення особистих цілей. ШІ як рефлексивний партнер аналізує твій голосовий щоденник (структурує хаотичні думки, виявляє патерни, відкриває несподівані інсайти), дозволяє глибше розмірковувати над статтями, книжками, відеороликами. ШІ як спаринг-партнер створює безпечний простір для відпрацювання навичок у симуляціях — від інтерв’ю і складних розмов до практикування англійської. ШІ як тьютор дозволяє опановувати нові знання та навички у зручному для вас темпі. З іншого боку, виникає ризик ілюзії компетентності — як ви зрозумієте, що якісно опанували знання та навички за допомогою ШІ, якщо не є експертом у цій сфері? Ба більше, деякі дослідження показують когнітивну атрофію у людей через аутсорсинг мислення і використання ШІ як милиці для розмірковувань. Тож, використання ШІ — це про прискорений розвиток чи про поступову деградацію? Під час виступу спікер представить результати практичного експерименту з кейсами — чи може використання ШІ допомогти стати кращою версією себе.

Дизайн — це те, що доходить до людей, а не те, що лежить у файлах чи обговорюється на внутрішніх мітингах. Щоб дизайн справді запрацював, його потрібно презентувати й “продати”. Клієнт, стейкхолдери, команда розробки — усі, хто буде його реалізовувати, мають повірити в рішення. Я поділюся тим, чого навчився, працюючи з продуктовими компаніями, студіями, агенціями, підприємцями та людьми, які ухвалюють рішення. У доповіді розглянемо: • чому гарний і логічний дизайн сам по собі не гарантує, що його погодять і реалізують • як структурувати презентацію, щоб її справді зрозуміли • коли демонстрація екрана у Figma працює добре, а коли вбиває атмосферу • як думати про аудиторію презентації — хто перед вами, що їм потрібно і чому — щоб менше переробляти й швидше релізити продукт