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

Створи власний AI Second Brain — персональну систему, яка допоможе впорядкувати інформацію, що зазвичай розпорошена між нотатками, чатами, документами та списками задач. Під час воркшопу ти крок за кроком збереш першу робочу версію системи, яку зможеш використовувати одразу після заняття. А згодом — масштабувати й адаптувати під власний стиль роботи. Разом налаштуємо ключові зони для щоденної роботи: • Inbox — ідеї, думки та швидкі нотатки; • Work — задачі, мітинги, follow-up та рішення; • Learning — книги, курси, статті й конспекти; • Personal Projects — особисті проєкти та цілі; • Decisions — аналіз варіантів і прийняття рішень; • Weekly Review — щотижневий огляд, рефлексія та планування. Технічні вимоги: • Воркшоп буде в Claude, для нього потрібна Pro підписка • По знаннях - Claude, Claude Code • Воркшоп працюватиме на MacOS, Linux та Windows Візьми із собою свої нотатки, задачі, ідеї чи плани — наприкінці воркшопу вони стануть основою твоєї персональної AI-системи.

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

Коли пишеш продукт сам разом з AI-агентом, код перестає бути вузьким місцем. Код агент пише швидко, а помиляється впевнено: цитує закон, якого не існує, або вигадує засновників для сторінки «Про нас». Розповім, як від ідеї в барі дійшов до Jurly — двостороннього юридичного маркетплейсу в проді, з ШІ-висновками для клієнтів і робочим простором для юристів — і що довелося збудувати навколо агента, щоб його «готово» можна було вірити. Розберемо: - Як одна людина з Claude Code веде продукт від ідеї до проду: спеки, TDD, dev-рев'ю, AGENTS.md і власні скіли для перевірки спек і коду. - AI harness - Галюцинації в продукті: неіснуючий закон, справжня стаття з вигаданим змістом і «чиста галюцинація», яку пропустила навіть автоматична перевірка; як RAG, перевірка цитат кодом, критик і golden set зменшують ризик. - Ціна такого підходу: відповідальність без команди, PII і безпека, журнал помилок агента — і що з цього спрацювало, а що ні. Головна думка: ШІ-система надійна рівно настільки, наскільки надійні перевірки навколо неї. Робота інженера зміщується від написання коду до проектування цих перевірок - від software engineer до product engineer.

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

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

Мовна модель пише вільно і часом помиляється впевнено. У чаті це коштує однієї поганої відповіді. В агенті з пам’яттю — більше: агент зберігає помилку, міркує з неї й завтра повторює. Пошук не може сказати, яка з двох суперечливих нотаток правильна, а друга модель у ролі судді лише передбачає правдоподібний вердикт. Ліки не нові. До глибокого навчання експертні системи, як-от MYCIN і XCON, тримали знання у вигляді правил, застосовували їх щоразу однаково й відповідали на «чому?» і «як?». Підвело їх одне: внесення знань, бо кожне правило вводили вручну. Саме це LLM уміють дуже добре. Нейросимвольний ШІ знову з’єднує дві половини. Доповідь проходить цей шлях на одному наскрізному прикладі: асистент, чия LLM «пам’ятає» зустріч у Берліні, тоді як у календарі та сама людина в цю годину в Лісабоні. Ми розберемо дедукцію, індукцію й абдукцію і те, чому LLM сильні саме в останній; міркування над графом знань із Prolog і Datalog; і те, чому логічне програмування вищого порядку (λProlog) добре пасує агентам: типи, що відкидають некоректний вивід LLM, відношення як значення, локальні припущення «а що як», правила про правила й доведення, які перевіряє мале ядро. Наприкінці — робочий агент, чия LLM пише λProlog за шістьма вартовими, і чесні цифри про те, що логічний шар ловить, а чого не може. Для інженерів ШІ та агентів, які знають Python і LLM. Знань логіки чи математики не потрібно.

AI-агент знає лише те, що ви йому показали, і не підкаже рішення, про існування якого не підозрюєте ви самі. А ще він забуває все між чатами. Доповідь пояснює, які знання потрібні людині, щоб агент працював на повну, і як побудувати для нього пам'ять: від локальних файлів до спільної пам'яті через MCP-сервер. Ви дізнаєтесь: — чому агент не пропонує очевидних рішень і як це виправити — патерн memory bank і готову структуру файлів, з якої можна почати — рівні пам'яті агента: чати, локальні файли, Obsidian, git, MCP-сервер пам'яті — практичні правила, як тримати пам'ять агента актуальною

Ми створили 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. Мірило успіху — фабрика, чиєму «готово» можна вірити.