Якщо в тебе процес розробки виглядає як "я пишу в Claude Code промпт, а далі разом з своїм улюбленим комплектом скілів робимо справу" - то ви застарілі роки на півтора, що в наших ШІ-реаліях - вічність. Зараз в моді графи та self-improving loops - ви пишете задачу - її розбивають на 100500 окремих блоків, кожен з яких простий, дає вимірюваний результат а отже - ним легко керувати і легко покращувати. Виглядає ідеально? Так, доки тебе не втомлює, що проста задача робиться годинки півтори або поки ти не рахуєш скільки це коштує (в грошах чи токенах - неважливо). За останні півроку я побудував 6 подібних фабрик як консалтер - як під копірку за ідеологією - однак тепер з кожним новим клієнтом я починаю довгу розмову, що скоріше за все вам або воно не треба, або треба - але в інший спосіб. Ми зачепимо три аспекти: технологічний, економічний та культурний, щоб пояснити де власне виникають проблеми і чому я більше не вважаю dark software factory у її графово-блоковому вигляді срібною кулею для всіх.

Розповідь про шлях створення та розвитку найбільшого військового застосунку, особливості айтішної служби і погляд на плюси, мінуси і підводні камені процесу

Я хочу поговорити про справжнє впровадження AI — проблеми, про які рідко пишуть у LinkedIn-історіях успіху, — спираючись на досвід Temabit з розгортання AI в delivery-процесі. Поговоримо про проблеми на землі — не в презентаціях, а в роботі команд: як команди опираються змінам, що нарешті веде до прийняття нового підходу, і яку ціну це справді має — у часі, процесах і культурі. Пояснимо, чому видачі розробникам ліцензії на Claude Code недостатньо — і чому AI SDLC важливий, коли мета — масштабувати впровадження далі одного «power user» на весь delivery process. Розглянемо шлях Temabit від хаотичного застосування агентів до SDD, а потім до AI SDLC, з ключовими проблемами на кожному кроці. Завершимо розмову наступними кроками і проблемами, які досі вирішуються.

Vibecoding — один із найефективніших інструментів для product-менеджера сьогодні. Він дозволяє не лише використовувати готові сервіси для пришвидшення роботи, а й створювати власні інструменти під конкретні задачі — з урахуванням контексту продукту і процесів. Це зменшує кількість зайвих дій і повернень до одних і тих самих задач вручну. У великих командах це про персональну ефективність і автоматизацію роботи. На етапі R&D — про можливість самостійно зібрати MVP, отримати перший фідбек від користувачів і лише після цього передати рішення в розробку. У доповіді Максим розкаже, як він використовує vibecoding у роботі product-менеджера: від MVP до створення власних інструментів.

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

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

Ця доповідь присвячена шляху розвитку після досягнення рівня сеньйор-інженера. Спираючись на власний досвід — від Junior Engineer до керівника Node.js Department — я розповім про особисті виклики, уроки та ключові моменти, які сформували мою кар’єру. Сесія стане практичним посібником для інженерів, які вже досягли рівня сеньйора і замислюються: «Що далі?». Ми розглянемо можливості як вертикального, так і горизонтального розвитку — від технічної майстерності до лідерства, від становлення експертом до формування команд і цілих департаментів.

Зараз дуже багате різноманіття інструментів для документування архітектури програмного забезпечення. При цьому з часом виникає питання, а чи є інструмент, який дозволяє не тільки зображувати архітектурні блоки як взаємопов'язані сервіси чи компоненти, а й включати комплексну інформацію про бізнес-прцеси, інформаційні системи та ІТ-інфраструктуру в єдиному вигляді? Таким інстурментом є Archimate. ArchiMate — мовa моделювання для опису, візуалізації й аналізу корпоративної архітектури, що разом з TOGAF стає потужним інструментом в руках архітектора. Під час доповіді розповім на прикладах про мову моделювання Archimate, покажу які є можливості в Archi для прискорення документування та аналізу архітектури, розповім як ми в використовуємо можливості мови моделювання у нас в компанії.

There are many obstacles and pitfalls on the path towards operational zen. Many routes could lead to dead ends, and many detours could end up being loops. In this semi-comedy talk, I share some examples of how processes fail for engineering teams that I observed through my career, using two pillars of the Internet culture - memes and numbered lists.

На шляху до інженерної нірвани існує безліч перешкод. Є багато місць, де можна зробити помилку і стежок, що ведуть в нікуди. В цій напівжартівливій доповіді я поділюся прикладами того, як процеси підводять інженерні команди. Всі приклади взяті із життя і подані за допомогою двох стовпів інтернет-культури - мемів і нумерованих списків.