Ми створили self-aware infrastructure: систему з пам’яттю, класифікаторами, моделями прийняття рішень у стилі Jev, оцінками та агентами, які здійснюють triage подій в інфраструктурі. Здебільшого агенти розгортаються або як обробники запитів без збереження стану, або як один спільний агент, що обслуговує всіх. Для автономних Triage агентів та командних експериментів нам потрібно було щось інше. Кожна команда або інженер отримує власного агента, що завжди увімкнений (always-on), - Spot. Він запам’ятовує поставлені завдання, продовжує працювати після того, як вони завершують сесію, і чекає на них, коли вони повертаються. Ви можете голосом попросити «RCA для кожної проблеми минулого тижня», закрити сесію і через кілька годин побачити, що робота виконана. У цій доповіді йдеться про те, як ми створили https://triageagent.dev Що отримають учасники: 1. З чого ми почали. Наше експериментальне середовище для масштабного запуску агентів, побудоване на kagent, agentgateway, ego та substrate. 2. Що ми отримали — «Triage Spots». Реальний приклад використання життєвого циклу агента, що завжди активний: один агент на користувача, який активується подіями, має власну пам’ять та квоту. 3. Чесний перелік наших помилок. Історія, що стоїть за цим кейсом: Замість відкриття запитів на платформі та отримання дозволу, ми запровадили для наших команд ізольоване середовище, щоб зменшити масштаб можливих наслідків від ненадійного або експериментального коду на спільних кластерах у великих масштабах. Цей підхід є конкретним, відкритим прикладом створення середовища для розробників на базі agent substrate, включаючи triageagent — переможця Національної премії Індії AI Gamechanger 2026.

Розробка ПЗ переходить від агентів, які допомагають писати код, до автономних систем, що беруть затверджену вимогу, пишуть код і самі перевіряють результат майже без нагляду людини, — software factories. Підхід новий, але OpenAI, Anthropic, Stripe, Uber та інші компанії вже публічно описали свої фабрики. У кожної — власний шлях, проте через усі ці історії проходять спільні принципи: що фабриці дозволено будувати, як вона доводить, що результат правильний, наскільки можна довіряти її агентам і як зробити, щоб вона окупалася. У доповіді я розбираю ці принципи й пояснюю, навіщо потрібен кожен, спираючись на публічні описи та на фабрики, які будую в Dev AI Consulting. Мірило успіху — фабрика, чиєму «готово» можна вірити.

Якщо в тебе процес розробки виглядає як "я пишу в 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 для прискорення документування та аналізу архітектури, розповім як ми в використовуємо можливості мови моделювання у нас в компанії.