На прикладі Awesomic покажу, як повернувся з менеджменту в кодинг і переважно сам перебудував продукт із нуля. Тепер це хмарна платформа для керування software factories та спільної роботи людей і агентів. Поділюся, як впроваджую цей підхід у компанії зі 100 людей: як змінюються процеси й ролі, як зберігати контроль над даними та накопиченими знаннями компанії й уникати vendor lock-in. Усе на прикладі реального воркфлоу, з живим демо та власними скілами для агентів, які ще ніде не публікував. Технічні вимоги: • Учасники працюватимуть у хмарному середовищі: кожен отримає власну Cloud VM, вартість якої покриває Awesomic • Для участі потрібна власна підписка на Claude або Codex

Коли кодбейс росте, AI-агенти для кодингу стають дорожчими й менш надійними. Кожна сесія заново вивчає архітектуру, конвенції розповзаються, а виправлення ламають інші виправлення. Типова реакція — перейти на потужнішу модель. Рахунок від цього зростає, а причина нікуди не дівається. Я пройшов цей шлях на власному продукті: від повністю делегованого агенту фронтенду і рахунку понад $1000 на місяць до пайплайну, де агент працює зі специфікації, а не з історії чату. Поговоримо про те: - як перенести правила, знання та перевірку з чату в репозиторій, щоб сесії стали одноразовими; - чим закінчилися три спроби побудувати базу знань і чому застаріла документація гірша, ніж її відсутність; - як виглядає пайплайн від задачі до пушу і чому специфікація важливіша за промпт; - чому дозволи агента мають бути примусовими обмеженнями, а не проханнями в rules-файлі, і чому все, що агент читає, — потенційні інструкції. Наприкінці я поділюся відкритим плейбуком із правилами, які можна одразу забрати у свій репозиторій.

Що, якби на типове запитання під час онколу першим відповідав не інженер? AI-асистент, створений платформною командою Superhuman, допомагає понад 25 командам і самостійно вирішує 20% запитань. Я розповім, як ми перетворили його на платформний сервіс, а також познайомлю з AI Golden Path — внутрішнім сервісом, який допомагає інженерам використовувати AI-агентів і виконувати типові задачі розробки та роботи з інфраструктурою через готові інструменти й покрокові робочі процеси. Поділюся, як ці сервіси вписуються в платформну стратегію, чого ми навчилися, як ми здобували довіру команд, і що плануємо розвивати далі.

Коли звикаєш працювати з AI-агентами за ноутом, рано чи пізно хочеться мати їх під рукою 24/7. Можна залишити робочий комп’ютер увімкненим, підняти власний сервер, запустити агента в хмарі або скористатися готовим рішенням на кшталт dot у ChatGPT чи Grok Bot. Розповім, як від першої ідеї «можна ж із телефона» дійшов до експериментів із кількома сетапами для робочих та особистих проєктів. Розберемо • Відмінності в автономності агентів поза робочим місцем. • Підходи та інструменти для роботи з телефона - від сесій у tmux до агрегаторів підписок (T3 Code, Orca) та окремих агентів, які самі оркеструють проєкти (Hermes тощо). • Проблеми синхронізації, оточення, рев’ю результатів та розсіювання уваги. • Підсумуємо, що спрацювало для мене, а від чого я відмовився та чому.

Ми створили 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.

Чому майбутнє автоматизації — не в кількості розробників, а в доступності AI-агентів Традиційна автоматизація вимагає часу, бюджету та залучення IT-команд. Але що, якщо кожен співробітник зможе самостійно автоматизувати власні процеси? Agentic Workforce змінює сам принцип організації роботи. Люди визначають цілі, агенти виконують задачі, а платформа забезпечує інструменти, доступи, безпеку та контроль. Розповім про наш досвід побудови та впровадження Agentic Workforce продукту в ентерпрайз організації, архітектуру агентної платформи, управління цифровими виконавцями та те, як ми бачимо трансформацію корпоративної автоматизації.

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

Створити AI-агента — лише половина задачі. Треба ще зрозуміти, наскільки добре він працює і чи не став гіршим після зміни моделі, запиту, інструментів або даних. У доповіді на практичному прикладі розберемо, як створювати Evals для AI-агентів: формувати тестові сценарії, визначати критерії та метрики якості, використовувати автоматичні перевірки, LLM-as-a-Judge і ручне оцінювання, порівнювати версії агента та вбудовувати Evals у процес розробки й тестування.

Агентна інженерія дорослішає: від «попроси агента написати код» ми переходимо до фабрик — конвеєрів, де команда AI-агентів проводить проєкт повним циклом: вимоги → специфікації → тести → імплементація → адверсарне рев'ю → докази якості. У доповіді розберемо, з чого така фабрика складається насправді: оркестратор і спеціалізовані субагенти, детерміновані quality gates, ланцюг трасування від вимоги до тесту, петлі верифікації замість «здається, працює». Головний виклик автономної розробки — не змусити агентів писати код, а не дати фабриці впевнено рапортувати успіх там, де його немає. Розберемо типові механізми самообману конвеєра: «м'які» правила в промптах, що зникають під тиском реального проєкту; перевірки, які тихо пропускають відсутні докази; вимоги, чий метод приймання ніколи не існував у вигляді коду. Ілюструватиму живим матеріалом — зокрема кейсом, де фабрика пройшла всі гейти «на зелено» й видала продукт, що не відповідав ключовій вимозі, і тим, що знадобилося, аби той самий прогін став чесно червоним. Окрема частина — про самовдосконалення: як побудувати цикл, у якому кожен виявлений провал стає новим гейтом, який наступний проєкт вже не зможе оминути. Три-значна семантика перевірок (PASS / NOT-EARNED / FAIL), реєстр процес-дефектів, бібліотека «уроків», що успадковується кожним новим проєктом. Все — на реальних артефактах: коміти, метрики, вимірювані результати. Про що поговоримо: Анатомія agentic-фабрики: оркестратор, субагенти, детерміновані гейти, ланцюг трасування Механізми самообману конвеєра — і форензика реального «фальшивого done» Maker ≠ checker на практиці: адверсарне рев'ю, яке реально ловить дефекти Цикл самовдосконалення: correction → retro → новий гейт → урок для наступного проєкту Скільки це коштує: про токени, час і де фабрика (поки) програє людині Кому буде корисно: інженерам і тимлідам, які вже використовують AI-агентів у розробці й хочуть перейти від «іноді спрацьовує» до передбачуваного конвеєра з доказами якості.

Що варто делегувати AI вже зараз, а що все ще потребує людини? На прикладі стрімінгового продукту поговоримо, як за допомогою AI-copilots оптимізувати QA-командам технічну рутину, масштабувати тестування, пришвидшувати релізи та залишати людям простір для дослідження продукту, UX і складних користувацьких сценаріїв