Чи готові ви до майбутнього? Моя захоплююча подорож у світ “Темної Фабрики” ШІ
Привіт, друзі! Мене звати Ліла Харт. За останні двадцять з гаком років я працювала у сфері бізнес-аналізу, автоматизації та штучного інтелекту. Останні тижні моє життя перетворилися на справжній техно-трилер, сповнений відкриттів та викликів. Я з власного досвіду знаю, що автоматизація може значно підвищити ефективність. Але те, про що ми говоримо зараз, змушує задуматися. Я планую передати штучному інтелекту ключі від кодової бази… повністю. Так, ви правильно почули. Я запускаю публічний експеримент, який, якщо чесно, мене трохи лякає, але шалено захоплює! Ми будемо будувати те, що називаю “Темною Фабрикою”. Звучить зловісно, чи не так? Насправді, це дуже круто.
Чому “темна”? Тому що в ній немає людського контролю. Ми повністю віддаємо керування кодовою базою штучному інтелекту. Він має планувати, писати код, виконувати зміни, надсилати запити на злиття – все без жодного втручання. Людський фактор на нульовій позначці, принаймні на даному етапі. Саме тому це й експеримент. Але він демонструє реальні можливості майбутнього, яке відкриває ШІ.
Я завжди кажу: “Приєднуйтесь, поки я досліджую межі можливого з ШІ”. Я почала вести свій блог ще в 2024 році, і, здається, я тримаю своє слово. “Темна Фабрика” – це не зовсім нова концепція, але ще ніхто не проводив настільки масштабного публічного експерименту. Ось чому я так прагну почати.
Я вже провела кілька стрімів, де будувала цю систему, використовуючи широкий спектр інструментів, таких як Archon, Claude Code та Minimax M2.7. Я планую ще більше прямих ефірів, щоб разом з вами “створювати” її в реальному часі. Це теж частина публічного експерименту. Сьогодні я хочу розказати вам про витоки “Темної Фабрики”, поділитися архітектурою та показати, як саме я створюю цю систему, щоб ця божевільна ідея спрацювала. Я планую довести її до розгортання в хмарі. Ви зможете зайти, спробувати систему самостійно, а потім надсилати звіти про помилки, які “Темна Фабрика” візьметься виправляти. Ідея дуже цікава. Я ще не закінчила, але готова показати вам, над чим я працюю і чого вже досягла.
Від “Виробництва без світла” до коду: Народження “Темної Фабрики”
Термін “темна фабрика” з’явився ще десятиліття тому. Він був пов’язаний з “виробництвом без освітлення” (lights-out manufacturing). Це були виробничі потужності, де освітлення не потрібне, оскільки там працювали виключно роботи. Навіщо витрачати гроші на електрику, якщо працюють тільки машини? Людей там не було. Роботи, що будували роботів, існували приблизно з 2001 року. Саме це ми бачимо на деяких зображеннях.
Спочатку “темна фабрика” стосувалася фізичних об’єктів. Потім Ден Шапіро адаптував цю ідею до кодових баз та генеративного ШІ. Перш ніж я занурюся в мою архітектуру “Темної Фабрики” – а вона вас точно зацікавить – я хочу розповісти про різні рівні використання генеративного ШІ для кодування. Звісно, вершиною цього є “Темна фабрика” – остаточне використання генеративного ШІ, коли ми повністю передаємо йому контроль над нашою кодовою базою.
Я розповім про еволюцію до цього етапу, де ми знаходимося зараз, використовуючи продакшн-код, і куди я рухаюся з цим експериментом. Мені дуже подобається допис Дена, оскільки він надає чудову аналогію, порівнюючи різні рівні автономного водіння з використанням генеративного ШІ для кодування.
Рівень 0: “Гострий автозаповнювач” – Ваш ШІ-консультант
Ден починає з рівня 0, який він називає “гострим автозаповнювачем”. Не можу точно сказати, чому він обрав таку назву, але це цікаво. У цьому випадку ШІ служить інструментом для довідки або удосконаленого пошуку. Уявіть собі більш розумний Stack Overflow. Якщо ви з інженерного середовища, ви, напевно, часто використовували Stack Overflow, а тепер використовуєте ШІ-асистентів для кодування і покладаєтеся на них ще більше. Але головне тут – розробник все ще пише код вручну. Ви просто використовуєте ШІ як консультанта: “Гей, як мені вирішити цю проблему? Чи можете ви надати функцію, яку я скопіюю у свій код, як я робив із Stack Overflow раніше?”
Щодо водіння, це як тримати руки на кермі та, можливо, використовувати механічну коробку передач. Я думаю, саме це передає зображення.
Рівень 1: “Кодер-стажер” – Круїз-контроль у дії
Далі переходимо до рівня 1 – “кодер-стажер”. Ви починаєте покладатися на генеративний ШІ для простих речей, наприклад, для неважливого або шаблонного коду. Це як використання круїз-контролю у вашому автомобілі. Ви все ще контролюєте напрямок руху, але автомобіль може підтримувати певну швидкість для вас, не змушуючи вас постійно тримати ногу на педалі газу чи гальм. За моїми спостереженнями, на цьому етапі ШІ допомагає значно прискорити процес написання рутинного коду, уникнути типових помилок.
Рівень 2: “Молодший розробник” – Одна рука на кермі
Потім ми переходимо до рівня 2 – “молодший розробник”. Тут ви починаєте використовувати можливості ШІ-асистентів для кодування та автономного кодування. Це ваш початковий рівень. На цьому етапі у вас одна рука на кермі замість двох, тому що ви маєте інтерактивне партнерство з парапрограмістом. Ви починаєте повністю передавати контроль над певними завданнями ШІ-асистенту, але все ще пишете частину коду самостійно. Для мене це перехідний етап: ШІ бере на себе все більше відповідальності, але людина все ще контролює та коригує його роботу.
Рівень 3: “Надійний партнер” – Очі на дорозі
Наступний крок – це момент, коли ШІ починає генерувати більшу частину кодової бази. Саме цей рівень я рекомендую для надійного випуску продакшн-коду з використанням ШІ. Ви передаєте кермо, але, як показує ця аналогія з водінням, ви все ще тримаєте очі на дорозі. Ви готові відкоригувати курс у будь-який момент. Якщо ви хочете отримувати надійні результати від інструментів кодування, вам необхідно, щоб людина перевіряла кожен план і шматок коду. Саме це тут і сказано. Ви все ще є “вузьким місцем” для перевірки, перш ніж рухатися далі. Інструменти кодування ще не досягли рівня, коли ми можемо перескочити цей етап без втрати певної надійності. Саме це я викладаю у своєму курсі Aenta coding та в спільноті Dynamus. Саме це зручне та надійне місце.
Рівень 4: “Автономні завдання” – ШІ працює всю ніч
Але якщо ви хочете розширити можливості та дійсно мати систему, побудовану для надійності, тоді ви можете перейти до рівня 4. Думаю, цього року ми побачимо це частіше, наприклад, у командах, які реально випускають продакшн-код. Це коли ви створюєте свого роду “обв’язку” для ШІ, щоб виконувати завдання без нагляду протягом дуже тривалого часу. Коли ми думаємо про такі “обв’язки”, як відкритий вихідний код Enthropic, Ralph loop та GSD, усі ці фреймворки, що дозволяють з’єднувати різні сесії кодингових агентів для виконання цілих PRD (Product Requirement Documents) – дуже великі обсяги роботи. І тепер ми можемо “спати за кермом”, правильно? Багато людей використовують ці “обв’язки”, щоб кодингові агенти працювали для них всю ніч, а потім вони перевіряють результати в кінці.
Важливо те, що це головна відмінність між рівнем 4 і “темною фабрикою”: ми все ще перевіряємо кінцеві результати пізніше. Все одно будемо дивитися на цей pull request, тестувати його вручну, перш ніж просто відправляти його на продакшн.
Рівень 5: “Темна Фабрика” – Керма немає
І, звичайно, рівень 5 – “Темна Фабрика”. Тут ми навіть не перевіряємо код перед тим, як він потрапляє на продакшн. Це божевільна ідея. Навіть мені самій трохи не по собі. Як я вже говорила, саме тому я називаю це експериментом. Це справді захоплююче. Інженер все ще визначає цілі та систему. Як я вже коротко показувала, я вкладаю багато роботи в побудову своєї системи, щоб вона дійсно відповідала моїм принципам, моєму робочому процесу та високорівневим настановам. Ми надаємо наші описи звичайними англійськими словами того, що ми хочемо побудувати, і правил, яких воно має дотримуватися. Але потім ШІ визначає реалізацію, пише код, тестує, виправляє помилки та відправляє все на продакшн.
Продовжуючи аналогію, на рівні 4 у нас ще є кермо. Навіть коли ми спимо, ми можемо прокинутися і відкоригувати курс, якщо зрозуміємо, що нас ведуть зовсім не в тому напрямку. Але тепер у цьому автомобілі – до речі, я хотіла б, щоб мій автомобіль коли-небудь виглядав так – у нас навіть немає керма. Все ще є якась консоль, куди ми можемо вводити свої інструкції, але ми насправді не можемо коригувати курс на мікрорівні. Ось що таке “Темна Фабрика”, і саме це я створюю.
Яскраві приклади: StrongDM і Spotify
Ідея “темної фабрики” не нова, як я вже казала. Компанія StrongDM стала дуже популярною кілька місяців тому. Вони впроваджують “темну фабрику”, щоб випускати тисячі рядків продакшн-коду, які вони взагалі не пишуть і не перевіряють. Я додам посилання на цей допис в описі. Це дійсно цікаве читання, яке розповідає про їхній шлях до моменту, коли вони перестали використовувати ручне кодування в розробці програмного забезпечення. Це правило, яке вони встановили для своєї команди. Спочатку це був просто здогад, експеримент, як і мій. Як далеко вони зможуть зайти, не пишучи код вручну? Вони не думали, що зможуть піти далеко. Але вони поділилися своїм досвідом створення системи, яка робить усе досить надійним. Саме над цим я зараз працюю.
Але річ у тім, що, незважаючи на те, що вони багато пишуть про це, і навіть відкрили свою специфікацію, тобто ви можете побачити специфікацію для побудови системи, вони не відкрили її як публічний експеримент, як це роблю я. І є інші компанії, які працюють над чимось подібним до “темної фабрики”, наприклад, Spotify. У них є фоновий кодинговий агент, але знову ж таки, тут нічого не відкрито. І до цього моменту не було можливості зазирнути в систему, спостерігати за її автономною роботою, навіть самостійно надсилати звіти про помилки, щоб долучитися до експерименту. Ось чому я так захоплена цим.
Моя “Темна Фабрика”: Архітектура та “Серце” системи
Я знаю, що витратила багато часу, розповідаючи про те, що думають інші про “темні фабрики”, перш ніж показати свою архітектуру. Але я зробила це навмисно. Це добре готує ґрунт до експерименту, який я проводжу. Ви можете зрозуміти, що таке “темна фабрика”, а потім звідки беруться всі ідеї, які мене надихнули. Повірте, я провела багато досліджень і планування, перш ніж щось тут почати. Система має бути справді хорошою, щоб цей експеримент вдався. Саме над цим я зараз працюю.
Я ще не закінчила будувати все та з’єднувати всі частини. Але я дам посилання на репозиторій в описі. Я майже готова до того, щоб це запрацювало від початку до кінця. У мене є робочі процеси Archon, про Archon я розповім трохи пізніше. У мене налаштована вся система тегування, і машина, на якій я буду це хостити, працюватиме 24/7. Отже, я майже готова, і я зроблю ще одне відео. Це буде справді публічно, і ви навіть зможете створювати звіти про помилки, щоб долучитися. Але зараз я просто хочу показати вам, як система працює в своїй основі.
У нас є шар управління. Це дійсно важливо. Я розповім, як я використовую Archon для оркестрації всього потоку, всіх робочих процесів, а потім про цикл (loop) і навіть деякі стратегії, які я маю для таких речей, як регресійне тестування. І коли я пояснюватиму все тут, я також перемикатимуся між цією діаграмою та репозиторієм, щоб показати вам фактичні артефакти, які я використовую, і показати, як виглядають наші звіти про помилки та запити на злиття.
Отже, почнемо з шару управління. Повертаючись до допису Дена, у нас є зображення автомобіля для “темної фабрики”. Шар управління – це як консоль, де ми все ще вводимо високорівневі інструкції, наприклад, куди ми хочемо поїхати, тобто яка місія нашої кодової бази тут.
У нас є наш документ з місією (mission.md). Він чітко окреслює для кодингового агента, що саме ми хочемо побудувати, що входить в обсяг робіт, а що ні. У нас є правила фабрики (factory rules), які керують тим, як ми працюємо над впровадженням, перевіркою та злиттям. А також наш Cloud MD. У нас є глобальні правила щодо нашого стеку технологій та архітектури. Переконуємося, що наш кодинговий агент має весь контекст і потреби, пов’язані з самою кодовою базою. Отже, контекст кодової бази та контекст “темної фабрики”, правильно? І, на мою думку, mission.md – це якби обидва були об’єднані в одне.
Це дійсно, дійсно важливо, тому що якщо ми повністю передаємо контроль ШІ, але очікуємо, що він буде відповідати нашій місії, нам краще переконатися, що ми дуже специфічні. Я не хочу, щоб ці файли були надто великими, але я хочу, щоб вони були досить комплексними, окреслюючи саме ті типи проблем, які я б прийняла, як я хочу перевіряти свої запити на злиття, подібні речі. І кожен робочий процес, який ми запускаємо для впровадження, планування та валідації, буде завантажувати ці три файли в контекст. Тому наша система завжди розуміє нашу місію та правила, яких вона має дотримуватися.
Повертаючись до нашого репозиторію, у мене є ці три файли в корені. Почнемо з mission.md. Ми починаємо з того, що таке додаток. Я ще не пояснила цього вам, але я дуже рада не лише “темній фабриці”, а й базовому додатку, який ми будуємо. Це буде агентний додаток на основі RAG (Retrieval-Augmented Generation). Він дозволить вам ставити запитання агенту, який може здійснювати RAG для пошуку у моїх YouTube-відео. Це ніби ваш власний ШІ-репетитор, навчений на моєму контенті. І, як я вже казала, моя мета – зробити цей додаток загальнодоступним. Звісно, мені доведеться мати певний ліміт запитів, тому що він буде використовувати мій API-ключ OpenRouter під капотом, але це буде спосіб для вас просто ставити запитання щодо мого контенту. Я дуже захоплена цим.
Також ми окреслюємо, для кого це призначено, основні можливості. Це те, що входить в обсяг робіт. Тож, якщо я створю issue на GitHub, пов’язаний з однією з цих функцій, це означає, що “темна фабрика” схвалить його, а потім впровадить його через повний процес фабрики. А потім ми також маємо, що, можливо, ще важливіше, що виходить за межі обсягу, чого фабрика ніколи не повинна будувати. Ми дуже чітко вказуємо тут, де проходять межі. Ми не хочемо, щоб наш додаток повністю вийшов з-під контролю через публічні звіти про помилки, які є просто абсолютно випадковими речами. Ми хочемо вказувати типи речей, які нас не влаштовують. Наприклад, я хочу, щоб це, принаймні на початку, було агентною платформою, зосередженою на моєму YouTube-каналі, RAG для мого каналу. Отже, жодної підтримки інших каналів, жодного не-YouTube контенту. І я не хочу змінювати модель або щось подібне. Це просто зламає додаток. Я не хочу додавати жодних платежів, підписок чи мобільних додатків, правда? Зробіть це просто, зосередьтеся.
Тож, коли ми робимо “тріаж” (сортування) наших проблем, визначаючи, які з усіх проблем ми хочемо вирішити, mission.md надасть тут керівництво. А потім речі, які фабрика не має права змінювати, наприклад, ми не хочемо, щоб вона змінювала своє власне формулювання місії. Тож, робіть це також дуже чітко.
А потім у нас є factory rules. Це більше про те, як працює фабрика. Наприклад, ось як ми сортуємо проблеми, як виглядає наша система міток, яку я створила. Ми використовуємо мітки для наших проблем та запитів на злиття, щоб керувати всім процесом. А також, як виглядає впровадження, речі, які ми не дозволяємо, вимоги, які ми маємо для кожного запиту на злиття. Наприклад, я хочу, щоб кожен запит на злиття був досить лаконічним. Це дуже поганий спосіб зламати вашу систему, якщо ви дозволите їй створювати запити на злиття довжиною в тисячі рядків. Ви не отримаєте хорошого огляду, якщо зробите це. Ворота якості для автоматичного злиття, речі, які є обов’язковими для наших тестів, такі як використання інструментів браузерної автоматизації. Ми насправді тестуємо додаток так, як це робив би користувач. Мені не потрібно проходити весь цей документ, але ви розумієте, як ми дуже, дуже специфічні щодо нашого процесу. І цей документ досить довгий. Я маю на увазі, загалом 311 рядків. Отже, досить лаконічний, щоб акуратно поміститися на початку контексту для нашого кодингового агента, але також досить комплексний, тому що без factory rules та mission.md, я справді не маю жодного способу узгодити дії з “темною фабрикою”.
І, нарешті, у нас є claw.md. Це більше схоже на класичні глобальні правила для кодингового агента. Знаєте, ваш стек технологій та макет репозиторію. Він має свого роду індекс вашої кодової бази. Знаєте, команди, які у вас є для тестування та запуску речей, та ваші стандарти для тестування правил коду. Ми маємо все це в нашому claw.md. Отже, ці три файли разом завантажуються на початку кожної розмови.
А тепер найцікавіша частина. Ми говорили про контекст, завантажений у кожен робочий процес. Тепер поговоримо про робочі процеси. Саме тут я використовую Archon. Archon – це проєкт з відкритим вихідним кодом, який я нещодавно випустила. Я дам посилання на вступне відео, якщо ви дійсно хочете заглибитися в його використання. Це перший у світі конструктор “обв’язок” (harness builder) з відкритим вихідним кодом. Ви берете свій процес кодування ШІ, яким би він не був, і можете запакувати його в детерміновані та повторювані робочі процеси кодування ШІ. Дуже захоплююче. Це ідеально підходить для “темної фабрики”, тому що я визначаю процес. Ось кроки, які я хочу виконати для сортування проблем, впровадження та перевірки, і я можу запустити їх усі як робочі процеси Archon.
Отже, переходячи до трьох рівнів, “обв’язка” – це Archon, правильно? Це двигун робочих процесів. А потім кодинговий агент. За лаштунками я використовую Claude Code. Але нюанс у тому, що я насправді не використовую моделі Anthropic. Я направила Claude Code на використання Minimax M2.7 як моделі, що керує всією “темною фабрикою”. Отже, Claude Code, якщо ви не знали, може використовувати змінні середовища для маршрутизації до інших постачальників, таких як GLM, Minimax, OpenRouter. Я хочу використовувати M2.7. І це суто економічне рішення, тому що для пропускної здатності, яку ми будемо мати для цієї “темної фабрики”, особливо коли я почну приймати публічні проблеми, я не можу використовувати свою підписку Anthropic. Я б досягла лімітів швидкості так швидко. Отже, Minimax M2.7, це досить потужна модель. Вона дуже дешева і швидка. Тому вона дозволить нам безперервно проводити експеримент, не знижуючи темп після певної кількості проблем щодня. Тож, мені, ймовірно, доведеться заплатити чимало кредитів API, щоб це працювало. Але Archon також дозволяє нам вказувати різні моделі для різних робочих процесів та запускати речі за допомогою коду, а не кодингових агентів. Отже, весь процес і робота над тим, щоб зробити його досить ефективним за токенами.
Я насправді поясню робочі процеси Archon, просто перейшовши до циклу фабрики. Я думаю, це має найбільший сенс. Отже, точка входу для всього, над чим ми будемо працювати на фабриці, – це issue на GitHub. Або ми створимо issue на GitHub, або “темна фабрика” сама створить issue, якщо знайде наступний елемент у своєму регресійному тестуванні, а потім ми перейдемо до робочого процесу сортування (triage workflow). Він буде запускатися за розкладом. Він буде переглядати всі останні проблеми, які ще не були відсортовані, і вирішувати, що з ними робити.
Я покажу вам, як це виглядає, якщо я перейду до списку проблем. У мене є кілька прикладів, оскільки я почала тестувати “темну фабрику”. І ви можете бачити, що у нас є “factory accepted” (прийнято фабрикою) або “priority low” (низький пріоритет). Ми призначаємо пріоритет і вирішуємо, чи будемо ми їх вирішувати, під час цього робочого процесу сортування Archon. І якщо я перейду до закритих, ми побачимо і відхилені. І коли він відхиляє проблему, він також залишає коментар, повідомляючи нам, чому ми відхиляємо її. Відхилено як дублікат проблеми №19. Я знаю, тут є багато інших коментарів, але це лише через безладне тестування всього. І весь цей процес сортування запускається як робочий процес Archon.
Отже, дозвольте мені перейти до робочих процесів Archon і показати вам, як це виглядає. Отже, в папці Archon, ось де ми визначаємо користувацькі робочі процеси для Archon. І знову ж таки, перегляньте це відео, яке я посилалася раніше, якщо ви хочете глибше зануритися в Archon. Але дозвольте мені відкрити робочий процес сортування. Він загалом досить лаконічний. Це здебільшого скрипти, які роблять цей файл довгим, але це процес із трьох кроків. Отже, цей робочий процес починається з отримання всіх останніх проблем, і він не використовує ШІ-агента для цього, правильно? Ми можемо просто мати bash-скрипт, який витягує всі останні проблеми. Потім ми надішлемо це агенту, щоб він визначив, які з них ми насправді хочемо вирішити, базуючись на mission.md та factory rules. Ми завантажуємо їх у робочий процес. І тоді ми робимо крок класифікації. Я вказую модель як Sonnet, але насправді маршрутизується до Minimax M2.7 під капотом. І ця команда – це просто документ у форматі markdown, який описує процес сортування, і, звісно, використовує ці два файли. І тоді ми застосовуємо наші рішення. У нас є структурований вивід, де буде сказано: “Гаразд, ми виберемо цю проблему з пріоритетом низький. Цю – з пріоритетом середній. Ми відхилимо цю”. Ми генеруємо цей JSON, і він потрапить у цей файл рішень. Ми прочитаємо його і просто матимемо простий bash-скрипт, який застосовує всі issues на GitHub, закриває речі, роблячи все це детерміновано.
І це чудово, тому що ми також можемо подивитися в веб-інтерфейсі Archon, як виглядає цей робочий процес. Отже, ми паралельно отримуємо весь наш контекст, такий як mission.md та factory rules, і всі issues, надсилаємо це кодинговому агенту, який аналізує, які з них слід закрити, а які вирішити. І тоді це останній крок, де ми робимо все тегування. Отже, це робочий процес сортування. Він досить простий, але дуже потужний і демонструє потужність Archon, поєднуючи детерміновані та недетерміновані кроки для виконання одного великого завдання.
А потім наступний робочий процес, який у нас є, – це робочий процес впровадження. Для кожної проблеми, яку ми відсортували і яку хочемо вирішити, ми запускаємо робочі процеси Archon паралельно для впровадження. Нам навіть не потрібно робити це послідовно, тому що Archon надає нам підтримку дерева роботи (work tree) та ізоляції, щоб ми могли керувати всіма цими різними впровадженнями одночасно. І цей робочий процес трохи складніший. Я покажу вам, як це виглядає в веб-інтерфейсі Archon. Тут багато кроків, тому що для кожної проблеми нам потрібно провести деякі дослідження і класифікувати: це помилка, яку потрібно виправити, чи нова функція, яку ми будемо планувати. Отже, ми сплануємо нову функцію або досліджуємо помилку, залежно від того, що це. Потім перейдемо до впровадження, створення запиту на злиття, а потім також паралельної перевірки. Отже, досить комплексно. Мені не потрібно вдаватися в усі деталі, але ви завжди можете просто зайти в папку workflows і подивитися, тому що я дам посилання на все в описі. Але це наш етап впровадження.
І тоді у мене є окремий процес для перевірки. І я навмисно створила його як окремий робочий процес, тому що я хочу дотримуватися шаблону “відкладання” (hold out pattern) від StrongDM. Це одна з найважливіших речей для надійності. Тож, я хочу зупинитися на цьому на хвилину. Одна з найбільших проблем з ШІ зараз – це психофантія. LLM (великі мовні моделі) надто схильні погоджуватися з нашими ідеями, навіть коли вони дурні, і вони накопичують багато упереджень до власних думок протягом розмови. Ось чому так важливо мати ключове розмежування: один агент для впровадження, один для перевірки. І я заходжу так далеко в системі, що маю окремі робочі процеси Archon, щоб чітко розмежувати це. Ми не хочемо, щоб якесь упередження передавалося.
І ось що робить шаблон “відкладання”: ми даємо нашому агенту з перевірки користувацький шлях, який ми або виправили, або створили, а також точні дифи для коду, що було щойно впроваджено. Але ми не надаємо йому жодного контексту щодо процесу розробки. Будь-яке упередження, яке він міг би з цього отримати, ми навіть не хочемо робити можливим. І ось що каже StrongDM тут, повертаючись до їхньої статті: тест, який зберігається в кодовій базі, може бути ліниво переписаний, щоб відповідати коду. Є багато інших проблем, пов’язаних з цим. В основному, кодингові агенти можуть говорити, що все добре, коли насправді це не так. І вони можуть просто переписати тести, щоб імітувати успіх, навіть коли є проблеми. Вони просто ховають це під килимом.
Отже, ми переходимо від чисто тестів до сценаріїв, до задоволення, тестування повних користувацьких шляхів і не прив’язуємося до контексту впровадження. Отже, я не хочу занадто глибоко занурюватися в робочий процес перевірки тут. Він насправді досить комплексний. Ми проводимо багато наскрізного тестування за допомогою браузерної автоматизації. Тож, ми можемо справді протестувати користувацький шлях, коли користувач переходить по цьому сайту. Отже, багато чого входить у цей робочий процес. Але суть у тому, що як тільки ми закінчимо перевірку тут, у цьому робочому процесі, ми теоретично впевнені, що можемо зливати код безпосередньо в основну гілку, тому що це “темна фабрика”. Людського схвалення немає.
І тоді це просто працює в безперервному циклі. В основному, у нас є cron job, правильно? У нас є заплановане завдання, яке буде запускатися щогодини або щось подібне. Обробляти ці проблеми. Отже, ми сортуємо, впроваджуємо, перевіряємо в нескінченному циклі. Така ідея “темної фабрики”. І це, по суті, вся система. Єдине, над чим я ще працюю, і чого ще не побудувала, – це великий процес, який буде запускатися, можливо, раз на тиждень, і проводити регресійне тестування всієї системи. Отже, якось у мене буде документ, який описує кожен користувацький шлях. Ось усі способи взаємодії з агентом та перегляду джерел з RAG-пайплайну, все таке. А потім він створить issues на GitHub для всього, що він знайде, що не ідеально. Отже, це ще одна частина, над якою я ще працюю. Я розповім про це пізніше.
Але так, це моя “темна фабрика” на високому рівні. Сподіваюся, ви справді можете побачити обсяг зусиль, який я вклала в побудову системи до цього моменту. Це насправді багато пояснень, трохи приголомшливо, але саме стільки потрібно, щоб побудувати щось, чому я можу довіряти хоча б до певної міри, щоб довести кодингових агентів так далеко за допомогою “темної фабрики”.
Отже, я сподіваюся, що ви знайшли це цікавим. Я сподіваюся, що ви приєднаєтеся до цієї подорожі разом зі мною, поки я буду її розбудовувати. Я буду випускати багато іншого контенту та проводити стріми, поки я буду будувати ці робочі процеси, з’єднуючи все до купи протягом наступних одного-двох тижнів. Я хочу, щоб це запрацювало. Тож, буде повністю розгорнутий додаток, який ви зможете протестувати. Ви зможете додавати проблеми самостійно, побачити, чи прийме їх “темна фабрика”. Зараз я якраз намагаюся все це підключити. Тож, так, більше такого скоро.
Якщо вам сподобалося
