Чи Може ШІ Побудувати Все Сам? Моя Особиста Історія Про “Темну Фабрику” та Знаходження Ідеального Балансу
Минулого тижня, під час жвавої дискусії з колегою-розробником, яка була натхненна останніми досягненнями у сфері штучного інтелекту, прозвучала ідея, що змусила мене відкласти свою чашку кави та заглибитися в роздуми. “Уяви собі, – почав він, – фабрику, яка самостійно пише код. Ти просто даєш їй завдання – створити епічне програмне забезпечення – а вона бере на себе все: проєктування, написання, тестування та випуск у продакшн. Повністю автономно!” Звучить, як мрія, чи не так? Особливо для мене, хто проводив незліченні години, а іноді й дні, за монотонними завданнями кодування.
Ця концепція настільки мене захопила, що я вирішив провести власний експеримент на початку цього року, запустивши так звану “темну фабрику” на базі ШІ. Перші враження були надзвичайно позитивними. Я відчував себе цифровим чарівником, надаючи настанови, поки машини виконували всю “брудну роботу”. Це було захопливо, але, як це часто буває, коли мрії стикаються з реальністю, мої очікування були розбиті. Чим глибше я занурювався, тим очевиднішим ставало: ідея “темної фабрики”, де ШІ працює абсолютно самостійно, є, м’яко кажучи, надто оптимістичною.
Однак, це зовсім не означає, що я повністю розчарувався. Навпаки, ця подорож привела мене до чогось набагато ціннішого, до системи, яка дійсно працює і, я переконаний, є шляхом до майбутнього розробки програмного забезпечення. Я не відмовився від прагнення до автономії, але зрозумів, що справжня сила полягає не в повній незалежності машини, а в гармонійному поєднанні людського інтелекту та машинного виконання.
Ця подорож до нового розуміння була неймовірно захопливою, і я хочу поділитися з вами всіма уроками, які я винесла. Чому “темна фабрика” не працює так, як нам би хотілося, і чому те, що я зараз будую, приносить реальні результати. Приготуйтеся, адже ми зануримося у світ, де код пишеться сам, але завжди під пильним наглядом людини.
Чому “Темна Фабрика” – Це Наразі Міф: Мої Спостереження
Коли ми говоримо про “темну фабрику”, ми маємо на увазі найвищий рівень автономії ШІ-агентів. Уявіть, що ви не просто задаєте напрямок, а визначаєте кінцеву мету, а весь шлях до її досягнення – з усіма поворотами, рішеннями та уникненням перешкод – залишається за машиною. Просто скажіть: “Привіт, ШІ! Побудуй мені ось цей масштабний застосунок. І зроби це бездоганно, без помилок, доки не завершиш”. Звучить як наукова фантастика, яка от-от стане реальністю, чи не так?
Однак, саме тут криється ключова проблема, яка, до речі, перегукується з моїми попередніми спостереженнями. Штучний інтелект, включно з найсучаснішими великими мовними моделями (LLM), демонструє вражаючі здібності до написання коду. Вони чудово розуміють технічні інструкції. Але чи стають вони так само кращими у розумінні нас, людей? Наших намірів, тонких нюансів, тих неусвідомлених бажань, які роблять продукт справді “тим, що треба”? На жаль, прогрес у цій сфері є значно меншим.
Мої особисті висновки свідчать, що головна перешкода – це наше спілкування. Ми, люди, ніколи не зможемо ідеально сформулювати всі деталі, які очікуємо побачити в програмному забезпеченні. Як ми хочемо, щоб код підтримувався, які саме функції є пріоритетними, а які – другорядними. І саме тут “темна фабрика” зазнає краху. Вона не може читати наші думки. Навіть найпотужніша LLM не може повністю замінити людський намір.
Звісно, існує думка, що з часом ШІ стане настільки розвиненим, що його ідеї перевершать наші, і ми повністю передамо йому процес розробки. Проте, я в це не вірю. Ми завжди будемо тими, хто краще розуміє потреби наших користувачів та проблеми, які ми прагнемо вирішити. І ми повинні залишатися тими, хто керує процесом.
Код, Який Ніхто Не Доглядає? Моя Негативна Позиція
Ще одним суттєвим недоліком “темної фабрики” є підтримка коду. ШІ-агенти, що працюють повністю автономно, мають тенденцію до “розростання”. Вони пишуть код, але не завжди роблять це у спосіб, що забезпечує легкість його розуміння та подальшої підтримки. Це можна порівняти з дітьми, які ростуть: спочатку вони милі, але без батьківського нагляду можуть наробити проблем.
Це саме той аспект, про який говорить Декс Хорті, який, до речі, теж експериментував з “темними фабриками”, а згодом був змушений інтегрувати більше людського контролю. Він стверджує, що програмні фабрики зазнають невдачі, оскільки агенти не можуть підтримувати кодову базу настільки ефективно, як це роблять люди. Я повністю поділяю цю думку. Ми не можемо повністю виключати себе з процесу догляду за кодом.
Саме тут я прийшла до свого нового підходу – “AI Software Factory”. Це не “темна фабрика”. Це система, яка дозволяє зберегти людський контроль, одночасно максимізуючи автономію та ефективність. Це те, що працює для мене, і я впевнена, що це – майбутнє.
“AI Software Factory”: Де Людина та Машина Танцюють Разом
Ключова відмінність моєї “AI Software Factory” від “темної фабрики” полягає в масштабі довіреної роботи та рівні попереднього планування.
У “темній фабриці” ми надаємо агенту величезний документ з описом бажаного застосунку і очікуємо, що він самостійно розіб’є його на завдання, розставить пріоритети та виконає. Все відбувається “в темряві” після нашої початкової команди. Ми навіть дозволяємо йому самостійно заповнювати прогалини в нашому намірі. І саме це є фундаментальною проблемою. Ми не хочемо, щоб агент самостійно додумував наші бажання, навіть якщо він надзвичайно здібний.
У моїй “AI Software Factory” ми діємо інакше. Ми надаємо системі індивідуальні релізи для роботи. Це означає, що агент все ще може самостійно опрацьовувати значну частину завдань. Але замість “зроби все одразу”, ми говоримо: “Давай визначимо наступний обсяг робіт. Розбий його на завдання (тікети) і виконай їх”.
Основний цикл фабрики залишається незмінним:
- Вхід: Тікет (завдання)
- Вихід: Pull Request (запит на злиття коду)
Однак, саме те, що відбувається до і після цього циклу, робить мою фабрику значно надійнішою та гуманнішою.
Три Стовпи Моєї Фабрики: Планування, Виконання та Перевірка
Давайте детально розглянемо, як це працює. Я витратила сотні годин на розробку цієї системи, тому зараз буду говорити достатньо загально, але сподіваюся, це надихне вас.
Частина 1: Планування та Розбиття на Завдання
Перш ніж фабрика розпочне роботу, нам потрібно спланувати значний обсяг робіт для наступного релізу та розбити його на маленькі, керовані завдання (тікети).
- Планування: Я навмисно залишила цей етап поза самою фабрикою. Чому? Тому що у вас, швидше за все, вже є власний спосіб планування, і це чудово! Кожна компанія, з якою я співпрацюю, має свої методи. Я не хочу нав’язувати свої. Ви створюєте свій PRD (Product Requirements Document), архітектурний документ – все, як зазвичай. Це стає вхідними даними для фабрики.
- Обсяг Роботи: Ми не намагаємося побудувати весь застосунок одразу. Для нових проєктів (greenfield) це може бути перша ітерація, Proof of Concept. Для вже існуючих проєктів (brownfield) – це невеликий епік.
- Розмір Епіка: “Невеликий” – це відносне поняття. Зазвичай я намагаюся, щоб один документ епіка розбивався на 10-20 тікетів. Це дає мені відчуття масштабу. Кожен тікет може мати різний розмір, але це моя загальна емпірична формула. З часом ви теж виробите свої.
- Що Буде і Чого Не Буде: В епіку важливо описати не тільки те, що ми будуємо, але й те, що не буде входити до цього релізу. Це допомагає фабриці краще орієнтуватися.
- “Holdout Scenarios” (Сценарії “На Випадок”): Це одна з моїх улюблених технік! Ми визначаємо тести, які будуть виконані в кінці, але сам агент-будівельник не знає про них. Це запобігає “підганянню” коду під конкретні тести. Агенти не повинні бути “екстрасенсами”, які бачать майбутні тести. Так ми робимо код дійсно якісним, а не просто таким, що проходить тести.
- Розбиття та Залежності: Фабрика допомагає розбити епік на тікети, проаналізувати залежності між ними (що можна робити паралельно, а що – послідовно) і навіть призначає GitHub-мітки для організації процесу.
Людина в Циклі (Human in the Loop): На цьому етапі ми можемо вирішувати, скільки людського контролю нам потрібно. Ми можемо переглядати розбиття на тікети перед початком роботи, або довірити це повністю фабриці. Все залежить від складності проєкту та нашої потреби в безпеці (наприклад, при роботі з фінансовими даними або регуляторними вимогами).
Частина 2: Основний Цикл Роботи Фабрики
Після планування ми маємо список GitHub-тікетів. Тепер фабрика бере їх і проходить через основний цикл, включаючи планування та валідацію.
- Вибір Тікета: Фабрика обирає один тікет для роботи, застосовуючи спеціальну мітку, щоб інші паралельні процеси його не чіпали.
- Швидкий чи Складний: Я використовую інструмент, щоб вирішити, чи це простий тікет, який можна швидко реалізувати, чи він вимагає більш детального ітераційного процесу.
- Побудова та Валідація: Після написання коду, він проходить валідацію. Це як користувач, який тестує застосунок: натискає кнопки, вводить текст. Це автоматизує значну частину ручного тестування.
- Code Review (Перегляд Коду): Це вже класичний аналіз коду: чи він простий, підтримуваний, правильно реалізований.
- Виправлення: Якщо щось не так на будь-якому з етапів, тікет повертається на виправлення. Максимум спроб обмежений, щоб уникнути вічного циклу.
- Злиття (Merge): Якщо все добре, Pull Request зливається у гілку staging (проміжний середовище) – але тільки якщо Continuous Integration (CI) зелений і код пройшов рев’ю.
Менеджер-Агент: Я додав спеціального агента, який періодично (кожні 2-3 години) перевіряє успішність роботи всіх паралельних процесів. Він як “наглядач” за фабрикою. Якщо один тікет “застряг” або виникли проблеми з залежностями, він може переналаштувати завдання або навіть “перехопити” його і завершити. Це значно підвищує надійність.
Ніколи не Змінювати Ці Файли! Я маю головні файли (наприклад, mission.md або engineering.md), які містять вищу директиву для агента: що знаходиться поза обсягом, які глобальні правила. Важливо, щоб фабрика ніколи не могла змінити ці файли. Це запобігає зміні дозволів або поведінки самої фабрики.
Економія Токенів: Я використовую різні моделі ШІ для різних завдань. Для складного планування – потужні моделі, а для простих завдань – менш ресурсоємні. Це робить фабрику дуже ефективною з точки зору використання токенів.
Частина 3: Тестування в Staging та Перехід до Production
- Людське Тестування: Коли всі завдання епіка оброблені та злиті в staging, настає наша черга. Ми самі тестуємо весь пакет функцій, щоб перевірити, чи відповідає результат нашому наміру.
- Зворотний Зв’язок: Якщо щось не так, ми просто створюємо новий тікет у репозиторії. Фабрика автоматично його підхопить і обробить. Це дозволяє нам легко надавати пакетний зворотний зв’язок.
- Від Staging до Production: Після того, як ми задоволені роботою в staging, ми переходимо до production. На відміну від “темної фабрики”, яка може одразу стрибнути в production, моя система забезпечує цей проміжний етап перевірки.
Підсумок: Майбутнє – в Гармонії, а не в Повній Автономії
Отже, що ми маємо? “Темна фабрика” – це мрія про повну автономію, яка поки що залишається мрією. Справжня сила – в “AI Software Factory”, де людина та машина працюють у тісній співпраці. Ми плануємо, фабрика виконує, а ми перевіряємо. Це дає нам найкраще з обох світів: швидкість і масштабованість ШІ, а також людський інтелект, намір і контроль.
Я вірю, що саме такі системи стануть майбутнім інженерії агентів. Вони дозволяють нам не тільки створювати складне програмне забезпечення швидше, але й робити це надійніше та з гарантією якості.
Якщо ви захотіли дізнатися більше про певні аспекти цієї фабрики, або навіть спробувати побудувати свою, будь ласка, дайте мені знати в коментарях! А поки що – пам’ятайте, що технології – це інструменти. І найцінніше, що ми можемо зробити, – це навчитися користуватися ними мудро, знаходячи той ідеальний баланс між можливостями машини та нашим власним досвідом.
Підсумовуючи все вище сказане, ми бачимо, що прямий шлях до повної автономії ШІ-розробки, відомий як “темна фабрика”, наразі не є реалістичним. Основні перешкоди – це нездатність ШІ повністю зрозуміти людський намір та проблеми з підтримкою коду. Натомість, більш ефективним та надійним підходом є “AI Software Factory”, яка інтегрує людський контроль на ключових етапах процесу. Ця модель передбачає спільне планування, автономне виконання завдань агентом та обов’язкову людську перевірку перед випуском.
У підсумку, я закликаю вас не боятися експериментувати з автоматизацією, але робити це розумно. Аналізуйте, що дійсно працює, і шукайте баланс. Це не лише про написання коду, а й про створення системи, яка дозволяє нам, людям, зосередитися на найважливішому – на творчості, на стратегічному баченні та на створенні продуктів, які дійсно люблять користувачі.
І пам’ятайте: якщо вам сподобалася ця інформація і ви хочете більше матеріалів про “AI Software Factory” та розробку за допомогою ШІ, будь ласка, поставте лайк і підпишіться на канал. А я побачуся з вами в наступному матеріалі!
