Crash Course: Розробка Software Factories
Ментор - Вʼячеслав Колдовський, Founder Dev AI Consulting
Побудова автономних фабрик AI-агентів стала головним трендом 2026 року. В їх контексті, агенти працюють практично без нагляду: втілюють проєкт від постановки задачі до фінального релізу.
Ментор: В'ячеслав Колдовський, засновник Dev AI Consulting.
Він на практиці збудував кілька десятків фабрик для своїх клієнтів на проєктах з різноманітними технологіями. За цей час він отримав досвід як самостійної роботи, так і з командами розробників. Автор підготував цей курс на основі цього досвіду.
Необхідна підготовка
Щоденна робота з coding-агентом (CLI або IDE), Git і CI і розуміння хоча б однієї мови програмування. Механізми не прив'язані до стеку. Бажано, але не обов'язково проходження одного з курсів: Agentic Engineering чи Agentic Engineering для нових проєктів.
Після курсу ви:
- спроєктуєте власну фабрику і визначите важливі для ваших задач компоненти
- прийматимете в роботу лише те, що фабрика здатна перевірити
- запускатимете quality gates, починаючи з найдешевших і найшвидших для перевірки
- захистите oracle (джерело еталонних відповідей): тести і приховані holdouts, а також знатимете, як вони можуть витекти
- налаштуєте review за принципом maker ≠ checker
- обмежите повноваження агента-виконавця: policy hook, ізоляція процесів і план для мережевого egress
- вимірюватимете вартість однієї прийнятої зміни й метрики результату, а не активності
- зробите dashboard для свого агента, який дозволить візуально моніторити його роботу
- запускати AI харнес (Claude Code, Codex і т.п.) автономно, але не мати надійного механізму перевірки результату
- вважати «готово» — коли агент сказав «готово»
- acceptance-тести, які агент може прочитати, змінити або побачити цитатою в prompt повторної спроби
- зміну перевіряє той самий агент, що її написав
- рядки в prompt замість механізмів («не редагуй тести»)
- витрати рахують у токенах чи змерджених PR, а не в прийнятих змінах
- автономію дають одразу всьому проєкту
- ефективні гейти якості, які агенти не можуть обійти
- тести, які агент-виконавець не може змінити, і приховані holdouts (тести, яких агент не бачить)
- maker ≠ checker: reviewer із чистим контекстом, якому доручено спростувати зміну і який мусить підкріплювати висновки посиланнями
- policy hook, ізоляція процесів і правила egress (вихідного мережевого трафіку) для всього, що запускає агент
- вартість однієї прийнятої зміни — за звітом про витрати
- автономія окремо для кожного типу змін: її треба заслужити доказами
Курс розбирає десятки принципів dark software factory (фабрики, де агенти працюють без постійного нагляду людей). Вони згруповані в окремі напрями і йдуть у тому порядку, у якому їх проходить реальний запуск: намір, контекст, контроль, верифікація, довіра, прозорість, автономія, люди й еволюція. Ви зрозумієте навіщо потрібен кожен принцип і як його збудувати та довести ефективність.
Автор надасть код власних фабрик, які ви можете використати як стартову точку щоб будувати свої. Демо показуємо в Claude Code, але принципи переносяться на будь-який інший харнесс (Codex, Cursor, GitHub Copilot, OpenCode...).
- Tech Leads, Solution Architects та Staff Engineers, які проєктують, як агенти працюватимуть без нагляду у своєму delivery
- Middle/Senior-розробники, які вже активно працюють із Claude Code, Codex чи Cursor і хочуть, щоб агенти працювали автономніше з меншим наглядом
- QA-інженери та інженери з автоматизації тестування: оскільки значна частина фабрики зосереджена на контролі якості (automated tests, holdouts, evals, acceptance criteria), то саме тут зможете поглибити свою експертизу
- DevOps та Platform Engineers, які будують sandboxes, CI gates і екосистеми для виконання агентів
- Engineering Managers, яким треба оцінювати ефективність роботи фабрик з погляду вартості, швидкості роботи, якості імплементації задач та знаходити баланс між автономністю та залученням інженерів
Дві сесії: від поточного стану галузі до власної фабрики
session-1 Поточний стан Software Factoriesблизько 2,5–3 год 1/2 ›
Що таке software factory і які вони бувають?
- – П'ять рівнів автономії; той самий pipeline у трьох режимах: lights-on, dim, dark
- – Хто вже має фабрики (OpenAI, Anthropic, Stripe, Uber та ін.), типи фабрик, їхні переваги й недоліки
Анатомія фабрики
- – Зони фабрики (Control, Store, Target) і шлях зміни від наміру до релізу
- – Головне правило: принцип працює, лише коли його забезпечує механізм, а не інструкція в prompt
Чого навчає досвід галузі
- – Генерувати код дешево; вузьке місце тепер — перевірка
- – Типові збої: «готово» без доказів, підігнані тести, агент перевіряє сам себе, вихід за sandbox, невидимі витрати
Принципи: що будувати, як перевіряти і скільки довіряти
- – Намір, контекст, контроль: люди вирішують, що будувати; репозиторій — єдине джерело правди; ліміти задає фабрика
- – Верифікація: докази замість тверджень; gates і тести, які агент не обійде і не змінить; приховані holdouts
- – Довіра і прозорість: мінімальні права, ізоляція, контроль egress; вартість прийнятої зміни замість токенів
- – Автономія, люди, еволюція: автономію заслуговують окремо для кожного типу змін; кожен механізм доводить, що він потрібен
Підсумок сесії
- – Чекліст принципів і самооцінка власних проєктів
session-2 Як збудовано справжню фабрику: принципи в діїблизько 2,5–3 год 2/2 ›
Принципи в порядку реального запуску: збій, який кожен зупиняє, механізм і доказ, що він справді каже «ні». Слайди, живе демо, записи запусків фабрик автора.
Архітектура і запуск
- – Фальшиве «готово» і три фабрики автора: від урізаної «мегафабрики» до фабрики, де кожен принцип підкріплено механізмом
- – Три зони й межа навколо виконавця; людина переглядає план, а не diff
- – Модель пропонує — код вирішує: найдешевші перевірки першими, ліміти, kill switch
Захистити oracle і заслужити кожне «пройдено»
- – Немає доказів — немає «пройдено»; перевірка, яку агент може змінити, — не перевірка
- – Приховані holdouts і де їх зберігати; reviewer із чистим контекстом, який мусить спростувати зміну
- – Кейс: reviewer знайшов діри у фабриці автора; обговорення: holdout-сценарії для вашої фічі
Межі довіри
- – Жодна роль не поєднує приватні дані, ненадійний контент і канал назовні (lethal trifecta)
- – Кільця ізоляції, allowlist як парсер; запобігання — ще не виявлення
- – Затвердження прив'язане до версії артефакту й названої людини; автор запиту не схвалює власний реліз
Демо: фабрика в роботі
- – Живе демо зі скриптованими агентами: чесний виконавець проходить усі gates, а реліз чекає на людину
- – Запис реального запуску публічної фабрики project-factory-next і пакет доказів (proof pack) замість diff
Прозорість, автономія і люди
- – Вартість однієї прийнятої зміни за звітом фабрики; dashboard: спершу метрики результату
- – Автономія окремо для кожного типу змін; обговорення: ваша матриця автономії
Еволюція і підсумок
- – Автоматичне покращення фабрики і захист від її деградації
- – Уся фабрика на одній схемі, порівняння практик, з чого почати, пояснення фінального завдання
Після першої сесії домашнього завдання немає. Після другої — фінальне завдання: ваша власна фабрика в роботі.
- Збудуйте фабрику для власного репозиторію: на основі коду фабрик автора або з нуля, на будь-якому харнессі
- Запустіть її на реальному проєкті — новому або наявному
- Доведіть, що проєкт реалізовано успішно: до запуску зафіксуйте критерії успіху (acceptance-кейси), а після покажіть, що їх виконано (робочий результат, демо або запис)
Зберіть докази запуску:
- логи й трасування запусків
- звіт про витрати і вартість однієї прийнятої зміни
- результати перевірок: тести, приховані holdouts, висновки review
- пакет доказів для ключових змін і короткий опис того, що фабрика зупинила
- dashboard вашої фабрики (скріншот або посилання), на якому видно хід запусків
Матеріали:
- презентації та відеозаписи сесій
- код фабрик автора як стартова точка для вашої
- стартовий репозиторій із шаблонами, зокрема шаблоном пакета доказів для фінального завдання
- чекліст принципів із першими кроками
Сертифікат — за умови виконання фінального завдання.
- Coding-агент із CLI та hooks. Рекомендуємо Claude Code (його буде використовувати автор для курсу). Інші харнесси (Codex, Cursor, GitHub Copilot, OpenCode) теж можна використати, але можливі відмінності в поведінці.
- Git і доступ до GitHub (GitHub або GitLab).
- Проєкт для фінального завдання: новий або наявний.
В'ячеслав Колдовський
- – 20+ років в IT
- – PhD / кандидат економічних наук, доцент, керівник Центру Gen AI в IT STEP Університеті
- – Засновник YouTube- і Telegram-каналів Programming Mentor; лідер AI-спільноти на DOU; спікер iForum і DOU Day
- – Будує software-фабрики для клієнтів Dev AI Consulting
- – Консультує компанії щодо переходу SDLC на AI; автор курсів Fwdays Academy з Agentic Engineering
Вартість участі
Доступ до 2 онлайн-трансляцій (~6 годин)
Презентації та матеріали
Доступ до запису курсу на навчальній платформі
Доступ до чату в ТГ, де спікер буде відповідати на питання
Сертифікат учасника (за умови виконання домашніх завдань)
Безкоштовний місяць в Fwdays Club
Учасники курсу отримують знижку 10% на участь в конференціях Fwdays
Доступна оплата частинами від Monobank та покупка частинами від ПриватбанкуЯкщо після першого заняття ви зрозумієте, що очікування не співпадають, ми повертаємо гроші в повному обсязі.