Програмна фабрика — це повторюваний цикл навколо програмної роботи. Якщо ви будуєте програмну фабрику, код, достатньо хороший для релізу, все ще потребує людського смаку та відповідальності. Ми обговоримо це, включаючи те, чи дійсно вам потрібна фабрика.
Якщо так:
- Швидше за все, вам знадобляться люди в циклі на початковому етапі для визначення наміру продукту, системного дизайну (якщо це важливо) та вашої планки якості.
- Обов'язково перевіряйте код (фабрика зі світлом), але робіть це навмисно там, де це найбільше потрібно. Я виявив, що варто слідкувати за тим, де автоматичний зворотний зв'язок ламається. Або де потрібно йти на компроміси щодо підтримуваності.
- Прагніть до того, щоб перевірки якості відбувалися якомога раніше та безперервно. Не всі з них повинні, але це включає системи типів, автоматизовані тести, мутаційне тестування, сканери безпеки та лінтери для архітектурних правил.
- Кількість перевірок != якість. Швидше за все, вам доведеться експериментувати, щоб зрозуміти, які перевірки дають найкраще співвідношення сигналу до шуму. Будьте готові навмисно посилювати або послаблювати ваші обмеження.
Ви хочете побудувати свою фабрику так, щоб деякі аспекти людського смаку були закодовані в середовищі, агент надавав вам докази правильності своєї роботи, а людина все ще «володіла» тим, що потрапляє в продакшн.
Чи дійсно вам потрібна програмна фабрика?
З мого досвіду, ви можете зайти напрочуд далеко зі своїм стандартним інструментарієм кодування! Тобто Claude Code або Codex, кілька сесій, хороші специфікації з вбудованою верифікацією та обмеженнями. Ви навіть можете кинути на них купу завдань з GitHub з критеріями реалізації та залучення людини. Рутіни Claude Code та хмарні агенти Copilot/Codex вже надають вам запланований або подієво-керований цикл без спеціальної інфраструктури.
Фабрика варта того, якщо вам потрібні повторювані послідовні запуски, передача роботи між агентами, запобігання тому, щоб дві сесії бралися за одне й те саме завдання, збереження доказів та призупинення виробництва, коли рев'ю відстають.
Отже, я почав з того, що сказав: програмна фабрика — це повторюваний цикл навколо програмної роботи. Ми можемо навіть подивитися на промпт, який демонструє дуже маленький цикл фабрики:
Прочитайте завдання GitHub #123 та інструкції репозиторію перед зміною коду.
Реалізуйте лише зазначені критерії приймання. Не змінюйте автентифікацію, білінг, міграції або існуючі твердження в тестах. Працюйте в гілці та тримайте diff таким, щоб його було зручно рев'ювати.
Запустіть npm run lint, npm test та npm run build. Якщо необхідна перевірка не може бути виконана, зупиніться та поясніть чому. Відкрийте чернетку pull request з перевірками, які ви запустили, ризиками, що залишилися, та будь-яким рішенням, яке людина все ще повинна прийняти. Не зливайте.
Мета може підтримувати цей рух, доки перевірки не пройдуть, і ми можемо опитувати завдання GitHub на наявність певних міток або переглядати відкриті pull request щоранку. Захист гілок може забезпечити межу злиття, а людина може залишатися в циклі, вибираючи, що стане готовим, переглядаючи та приймаючи остаточні рішення щодо злиття тощо.
Додайте програмну фабрику, коли вам потрібна подієво-керована черга роботи (наприклад, тригери Slack, завдання GitHub, Linear, беклог) для запуску в ізольованому хмарному середовищі для виконання тріажу, реалізації та тестування з певним явним наглядом людини. Деякі завершують свій цикл агентом моніторингу, який спостерігає за продакшном і створює завдання, які знову проходять тріаж.
На мій досвід, фабрика стає корисною, коли складною частиною є забезпечення узгодженої поведінки різних запусків, передача роботи між агентами та запобігання тому, щоб різні сесії претендували на одне й те саме завдання, збереження доказів та зупинка виробництва, коли людський перегляд відстає.
Те, що вирішує це, може звучати трохи нудно. Наприклад, Warp згадує тріаж кожного вхідного завдання в один із чотирьох станів — готове-до-реалізації, готове-до-специфікації, потребує-інформації, чекає-на-реалізацію — і мітка запускає наступного агента.
Ця мітка виконує кілька завдань одночасно: це черга, блокування, і оскільки сесія бере лише те, що позначено як готове, це місце, де людина може припаркувати щось, не кажучи «ні» назавжди.
З точки зору робочого процесу, є кілька подібностей та відмінностей від простого використання Claude/Codex:
- Спрямування: агенту потрібна корекція курсу, ви можете надати вхідні дані та перенаправити його
- Сповіщення: як фабрика повідомляє, що вона заблокована. Це може бути через те, що вимога була неоднозначною, вона почала щось ризиковане або їй потрібен внесок людини (спрямування)
- Передача: переміщення завдання, його стану та контексту між хмарною фабрикою/іншим агентом/рев'юером-людиною. Хороші передачі відстежуватимуть, що сталося, що залишилося зробити та чому передача потрібна.
У хорошій фабриці людина не обмежується лише переглядом та затвердженням кінцевого diff в самому кінці. Вона може формувати роботу на ранньому етапі, спрямовувати її під час реалізації, передавати її через рукостискання або зупинити її потрапляння в продакшн.
Верифікація — це те, на що відповідальна фабрика витрачає багато часу. Ми розглянемо це детальніше пізніше.
Якщо ви вирішите, що вам дійсно потрібна програмна фабрика, її створення — не єдиний варіант. Розгортання інфраструктури для масштабування фабрики може бути великою роботою, і ви можете розглянути варіант покупки проти створення. Factory.ai, Devin, Warp та HumanLayer продають деякі частини цього циклу.
На що я насправді витрачаю свою увагу
Мій щоденний досвід розробки програмного забезпечення дуже змінився за останній рік. Я все частіше говорю про виконання великої кількості паралельної роботи з агентами, рухаючись до створення програмної фабрики зі світлом. І багато людей запитують мене: що це насправді означає? Що ви будуєте? Які типи проєктів ви використовуєте для цього? Це багато з наступного:
Отже, у звичайний день у мене є простіша програмна фабрика зі світлом. У мене можуть бути завдання, які виконуються в хмарі. Половина цих завдань може бути роботою над клієнтськими додатками в продакшні для менших компаній, з якими я працюю. Вони матимуть реальних користувачів. Вони матимуть реальну автентифікацію, платежі, підписки, реальні серйозні ризики, з якими потрібно бути обережним. Не можна просто сказати: «О, агенте, просто зроби це» без тестів, обмежень та перевірок якості.
Я міг би працювати над своїми проєктами з відкритим кодом. Я міг би створювати супутні сайти для своїх книг. Я міг би працювати над інструментами. Я міг би створювати власні додатки. І це дуже, дуже різні типи додатків, над якими я працюю. І іноді єдине, що їх об'єднує, — це інструмент, який я використовую для роботи над ними, чи не так? Можливо, я працюю над міграцією. Іншого разу я можу виконувати справжню серйозну роботу над функціоналом. І радіус вибуху роботи також може бути дуже, дуже різним.
Отже, коли ви починаєте думати про те, як дійти до місця, де ми все частіше виконуємо багато паралельної роботи, намагаємося підвищити швидкість, продуктивність та автономність, що означає довести систему до стану, коли ми їй більше довіряємо, вам дійсно потрібно подумати про те, які місця абсолютно вимагають людського рев'ю коду, людського внеску.
І велика частина цього буде потрібна на початку, чи не так? Коли ви визначаєте свою специфікацію, вимоги, яким буде дизайн продукту? Яким буде намір продукту? А потім як ви перевіряєте, що агенти насправді правильно виконали роботу? Як ви перевіряєте, що вони не зламали існуючу систему? Як ви переконуєтеся, що це відповідає вашій планці якості?
І тому генерація коду не обов'язково є частиною, про яку вам потрібно найбільше турбуватися. Маючи достатньо контексту, агенти можуть написати реалізацію, запустити тести, перевірити невдачі та виправити код за нас. Нам потрібно дійти до стану, коли ми відчуваємо, що в середовищі закодовано достатньо людського смаку, щоб ми могли довіряти тому, що будується, щоб наша людська увага могла бути зосереджена на місцях, де вона найбільше потрібна.
Зараз є заперечення від деяких людей, які кажуть: «Я не вірю, що можна просто автоматизувати багато з цього». Справа не в тому, що ми автоматизуємо все, чи не так? Але враховуючи обсяг коду, який генерується, я не думаю, що реалістично, щоб люди читали його весь, особливо коли ми не будуємо ракети більшу частину часу, чи не так? Ми будуємо UI, ми будуємо full stack додатки.
Наше судження, наш смак найкраще зосередити на місцях, де це найбільше потрібно. Наприклад, які найризикованіші частини систем? Де нам потрібно застосувати людський смак? І це може бути у фронтенді. Це може бути в тому, як працює система. Це не повинно бути 100% всього.
Моя когнітивна пропускна здатність не масштабується разом з агентами
Реальність така: так, тепер ми можемо запустити десятки, сотні, тисячі агентів паралельно, але ваша власна когнітивна пропускна здатність не масштабується так само. Це може призвести до когнітивного боргу або боргу розуміння, про що я вже говорив раніше.
Якщо ви згадаєте всього п'ять-десять років тому, в інженерній спільноті було багато дискусій про перемикання контексту та його вартість. Ми говорили про те, як люди ненавиділи, коли колега або хтось підходив до вашого столу, коли ви були в середині завдання. Потім вам потрібно було так багато часу, щоб повернутися в стан потоку, тому що вам доводилося наздоганяти: де я був? Що я робив? Навіть якщо у вас був невеликий залишок, це все одно займало час.
Тепер ми перемикаємо контекст ще більше, ніж раніше. У будь-який день, якщо я працюю поза програмною фабрикою, я можу одночасно працювати над п'ятьма або десятьма різними проєктами з агентами, або п'ятьма або десятьма різними функціями в одному проєкті. Можна сказати, що у мене може бути п'ять або десять різних сесій.
Це означає, що я повинен мати можливість контролювати принаймні кілька з них. Можливо, я зможу збільшити автономність, яку я надаю деяким завданням, якщо я довіряю, що достатньо добре визначив завдання, достатньо добре визначив результат, як воно буде перевіряти, що зроблено достатньо добре. Але будуть завдання, де я, можливо, не відчуваю цього, і є більше ризику або більше нюансів. Мені доведеться звертати увагу.
Подумайте про оптимізацію програмної фабрики для вашого рев'юера. Враховуючи, що кожен з цих підходів все одно направляє свій результат на увагу однієї людини, ви повинні запитати, наскільки фабрика робить дешевшими рішення, які вам все одно доводиться приймати.
Помилка неправильного проєкту
Я пам'ятаю, коли працював над кількома паралельними проєктами зі своїми агентами, і були випадки, коли я випадково робив такі речі, як, можливо, я працював над веб-додатком, де хотів додати темний режим, і тому у мене в голові було: «Гаразд, ось як це має виглядати». Але я випадково перейшов до сесії для іншого проєкту і почав вводити той самий промпт.
Тож я почав реалізовувати темний режим для чогось, що абсолютно цього не потребувало. І я можу зробити таку помилку. Я не хочу, щоб моя програмна фабрика робила таку помилку.
Вам потрібно думати про це насправді з точки зору системи. Ви фактично намагаєтеся закодувати культуру програмної інженерії, командну культуру в систему, щоб вона мала таку саму поведінку, щоб вона мала власність, яка десь належить, щоб хтось все ще відповідав за те, що відбувається, і ви були дуже чіткими щодо того, як ви думаєте про ці речі.
Коли зелений колір вводить в оману
Навіть у цих системах потрібно бути дуже обережним, чи не так? Багато хто з нас бачив, що коли ви просили AI допомогти вам пройти тест, наприклад, ми говоримо про тест програмування, модульний тест, він може змінити модульний тест, щоб задовольнити цю умову, або він може змінити логіку коду, щоб пройти цю умову. Це не означає, що він насправді дотримувався вашого наміру, щоб узгодити як функціональну поведінку, так і те, що тест мав перевіряти, чи не так?
Те, що програмна фабрика показує, що все зелено, не означає, що воно насправді зелене, особливо на початку, коли ви налаштовуєте ці речі. Вам потрібно приділяти багато уваги, щоб переконатися, що ваші перевірки, ваші верифікації, всі вони налаштовані правильно. Вони роблять те, що ви від них очікуєте. Ви не хочете, щоб вони вводили в оману.
Ви не хочете ситуації, коли у вас були тести, які сказали: «Гей, насправді, я змінив підтримувані провайдери автентифікації. Ви попросили мене додати GitHub, наприклад, як провайдер автентифікації, але, гей, у моєму UI було місце лише для трьох, тому я пішов і видалив один з інших. І, до речі, це виявився той, який ваші клієнти насправді хотіли». Тому вам просто потрібно бути дуже чіткими щодо того, як ви хочете, щоб ці системи працювали.
До речі, безпека також дуже важлива, і якщо ваша фабрика читає ненадійні вхідні дані, такі як завдання GitHub або повідомлення Slack, вони можуть бути ворожими та включати такі проблеми, як атаки на ланцюг постачання. Деякі продукти, пов'язані з програмними фабриками, такі як Vercel Sandbox/AI ADK Factory, запускають своїх агентів в ізольованих пісочницях, які містять лише секрети, необхідні для завдання. Таким чином, скомпрометований запуск не може отримати доступ до того, що не потрібно для роботи. Ваш захист виявляється багаторівневим.
Які старі проєкти заслуговують на друге життя?
Я також вважаю, що велика частина того, як ми працюємо сьогодні, полягає у вирішенні того, що має існувати. Якщо ви згадаєте багато років тому, до AI, було так багато покинутих проєктів програмної інженерії, так багато покинутих вихідних проєктів, особистих проєктів, які просто не запускалися, тому що у нас не було часу їх закінчити. У нас не було пропускної здатності, щоб визначити пріоритети для їх випуску, тому що вони були не настільки важливі для нас, або ми не могли знайти час.
Тепер для нас досить тривіально завершити ці проєкти, але виникає те саме питання людського судження. Чи заслуговують ці проєкти на існування? Чи варто їх запускати? Тому що ви випускаєте їх у світ, і навіть якщо він має лише п'ять користувачів, можливо, вам доведеться його підтримувати. Можливо, у вас тепер є планка якості, яку ви хочете підтримувати.
Я знаю, що у мене було так багато проєктів GitHub за ці роки, і тепер, коли у мене є агент, перше, що я роблю, це змушую проєкт збиратися. Тому що, звичайно, ви клонуєте його, і тепер він не збирається, тому що всі залежності змінилися. Половина речей застаріла або має вразливості безпеки, тому вам потрібно це оновити.
Потім вам потрібно додати тести, якщо їх не було, щоб знати, що поведінка принаймні буде збережена, якщо ви оновлюєте проєкт у будь-який спосіб, або якщо ви мігруєте його на більш сучасну мову, фреймворк або щось подібне.
Потім ви починаєте запитувати себе: «Ну, можливо, дурний приклад, але, можливо, я використовував Twitter Bootstrap для цього колись, але тепер усі використовують Tailwind та shadcn, тому мені доведеться переробити UI». І ви помітите, що раптом це займає у вас більше часу, чи не так? Так, агент може зробити багато з цього швидше, але тепер вам доводиться враховувати продуктове чуття, смак та всі ці речі.
Ви все ще запитуєте: «Для кого це? Чи має це ринок? Це для мене? Це для інших людей? Якщо я випускаю це у світ, чи буде це все ще так само цікаво, враховуючи, що тепер будь-хто може створити це так само швидко?»
Тому я вважаю, що людське питання про те, чи заслуговують ці речі на існування, як ми враховуємо наш смак та судження, залишаються надзвичайно важливими. Саме тут цей дефіцитний ресурс людської уваги дійсно проявляється. Колись у нас була лише обмежена кількість годин на день. У нас були зустрічі. Нам потрібно було планувати час на дизайн, кодування тощо.
Тепер, коли у нас є агенти, які допомагають нам, я думаю, що ви повинні бути дуже чіткими щодо того, на що ви витрачаєте свій час і чому.
Що сталося, коли я побудував зразкову фабрику
Отже, я розповім про 82-хвилинний запуск фабрики. Люди давно запитують мене: «Як побудувати програмну фабрику?» Або: «Я звик використовувати Claude Code або Codex. Як розвинути мою установку до використання програмної фабрики?»
Перше, що я кажу: «Можливо, у вас все добре. Ваша робота може бути абсолютно нормальною без фабрики». Але я хотів дати людям еталонну установку, яку вони можуть перевірити. Тож я створив репозиторій під назвою Factory, який ви можете переглянути. Я також створив демонстраційний додаток та воркшоп.
Останні кілька років моїм улюбленим демонстраційним додатком для багатьох речей був додаток про фільми. Я великий шанувальник фільмів. Я люблю дивитися фільми. Я дивлюся фільми постійно, тому у мене є демонстраційний додаток, який починається як дуже простий додаток про фільми. І я хочу, щоб фабрика могла реалізувати кілька функцій. Є кілька різних функцій. Я хочу функцію «улюблені». Я хочу, щоб вона могла, можливо, виконувати пошук, а також, можливо, мати темну тему, такі речі.
Отже, я запускаю свою фабрику, і вона починає працювати з цими речами. Ви можете перевірити реалізацію. Однією з переваг було те, що вона насправді виявляла реальні проблеми. Ці проблеми могли бути не тими, які я б виявив, якби просто попросив її зробити одноразову реалізацію.
Десь на 60-й хвилині я відчув: «Ого, це надзвичайно повільно». Я запитав свою оболонку, використовуючи фабрику: «Чому все йде повільно?» Вона відповіла: «Це абсолютно нормально. Всі верифікатори все ще працюють».
Ви могли очікувати, що окремі завдання займуть 10 хвилин, 15 хвилин, 20 хвилин, але вони можуть зайняти в два-чотири рази більше часу, коли ви починаєте включати верифікацію, повторні спроби, перевірки браузера, людський перегляд, будь-які з цих додаткових затримок.
Я вважаю, що це може призвести до кращої якості та кращої довіри до системи. З точки зору вимірювання, ви можете подивитися на такі метрики, як вартість за злитий PR та термін життя коду як метрики боргу розуміння.
Вам також потрібно подумати про те, що є корисною затримкою, а що — накладними витратами фабрики. Верифікатори, в моєму випадку, виявили деякі реальні проблеми. Трохи часу було витрачено на створення доказів, які я хотів. Частина була накладними витратами на роботу фабрики. Я не витрачав часу на її оптимізацію, але фабрика, яка просто виконує багато перевірок, які ви не вважаєте цінними, не означає, що вона високоякісна.
Ви хочете вивчити, як для будь-яких повторюваних перевірок: чи вони нерелевантні? Чи вони шумні? Чи вони насправді роблять систему безпечнішою?
Верифікація потребує бюджету
Те, як я думаю про бюджет для верифікації, це, власне, те, про що ми говоримо. Ми говоримо про бюджет верифікації. Я думаю про це так само, як історично думав про бюджети продуктивності.
Будуть певні види перевірок, які ви можете запустити на ранніх етапах вашого життєвого циклу розробки програмного забезпечення, і будуть деякі речі, які настільки важкі, але пропонують стільки цінності, що ви захочете запустити їх пізніше. Є деякі види швидких перевірок, наприклад, лінтінг, перевірка типів. Це відносно швидкі перевірки, які ви можете запустити на ранньому етапі.
Наш повний набір тестів можна запустити ближче до того, як буде створено чернетку PR або після цього. Це може включати мутаційне тестування, тестування браузера, перевірки безпеки тощо.
Я думаю, що ви не обов'язково хочете замінювати їх просто підсумками. Вам потрібні реальні тести, але вам просто потрібно переконатися, що ви плануєте бюджет для них у правильних місцях, тому що ви не хочете сповільнювати свій цикл розробки. Я точно ніколи не хочу сповільнювати свій цикл розробки. Швидкий цикл ітерацій важливий для мене, але я також хочу мати ці стримування та противаги.
Коли запуск не потрапляє в реліз
Багато з того, що я написав вище, стосується перевірок.
У своїй програмній фабриці Vercel позначає кожен запуск агента як «успіх», «недолік», «заблоковано» або «вручну», і лише «успіх» потрапляє в продакшн. Решта повертаються в систему. Я думав про запуски в подібних термінах.
«Недолік» тут означає, що було реалізовано неправильну річ або, можливо, не було повного контексту, тому це потрібно виправити. «Заблоковано» означає, що в середовищі, можливо, не вистачало облікових даних, тому вам потрібно їх надати. «Вручну» — це межа, яку фабрика, можливо, ще не може перетнути.
Дві з трьох речей тут можуть мати механічні виправлення, а остання стосується довіри.
Хоча це чудово, сортування не показує вам вартість. Повертаючись до моєї реалізації фабрики з додатком TMDB, швидкий пошук без відхилень зайняв 7 хвилин. Улюблені, з двома відхиленнями та людським рішенням посередині, зайняли 56 хвилин. Та сама фабрика. Тому я б поєднав таксономію з часом на етапі, інакше ви знаєте, що запуск повернувся з недоліком, не знаючи, скільки це вам коштувало. Інша річ, яку я б виправив, це передача на межі: моя зразкова фабрика зупинила перше завдання і перемістила його в factory:needs-info, що було правильно, але я не знав, куди помістити свою відповідь. Ручний запуск не завершується, коли фабрика зупиняється, а коли людина знає, що робити далі.
Автономність — це не єдиний параметр
Кілька тижнів тому я написав статтю про рівні агентної автономності та про те, як думати про автономність, тому що автономність не буде єдиним параметром для кожного проєкту.
Верифікація купує вам довіру та можливість надавати більше автономії вашим агентам. Отже, якщо, наприклад, я працюю над нетривіальною зміною, але маю ряд перевірок, все верифікується правильно, і, можливо, я сам перевірив це вручну. Наступного разу, коли я буду виконувати подібне завдання в тому самому проєкті, можливо, я буду почуватися комфортніше, надаючи агенту трохи більше автономії.
Ось про що ви думаєте, коли будуєте ці програмні фабрики. Ваша верифікація буде змінюватися залежно від ризику. Ваша мета — найкраще співвідношення сигналу до шуму. Ви не просто хочете мати якийсь великий контрольний список, який ви виконуєте.
Функція, яку мені довелося перевчити
Була одна функція, яку я відкладав у день, коли використовував кілька сесій з Claude, і я працював над кількома різними проєктами одночасно, кількома різними функціями в кожному проєкті. І так Claude реалізував функцію, над якою я працював. Здавалося, що тести проходять. Я не приділив багато уваги верифікації, але тести пройшли, і я подумав, що це працює. Я злив це.
І це була функція «улюблені». Я думав, що це досить добре. Я спробував перевірити це в браузері. Здавалося, що все гаразд, але через кілька днів я насправді повернувся до коду, тому що хотів внести деякі зміни.
Я не хотів просто просити свого агента внести зміни, тому що це був тонкий нюанс роботи. Натискаєш на іконку, а потрібного ефекту при натисканні не було, і я хотів просто підправити це. Я хотів зрозуміти, як це працює, щоб правильно скерувати свого агента.
Я повернувся до коду, але не міг пояснити, як працює ця функція. Адже це мій репозиторій, чи не так? Я схвалив цю зміну. Я розумів, як працює багато чого, більша частина репозиторію, але моє розуміння не встигало за всім тим кодом, який накопичувався.
Чого я не зміг засвоїти, так це того, як насправді працює ця додана функція, як працює інтерфейс, як працює ефект на ньому. Мені довелося переробити цю функцію і буквально крок за кроком розбиратися: «Як це працює? Як я можу це зрозуміти?»
Що паралельна робота робить з розумінням
Коли ви працюєте паралельно, це посилює загальну проблему, і вона стає ще більш вираженою, коли ви робите це в програмній фабриці. Коли ви проводите п'ять або десять сесій, вони створюють набагато більше, ніж просто проблему обсягу перевірки. Вони створюють кілька ментальних моделей, які можуть досить сильно «охолонути», поки ви працюєте в іншому місці.
Ми вже говорили про проблеми з перемиканням контексту, і як тільки чат ущільнюється, ви відкидаєте деякі підходи, пробуєте різні речі, працюєте в парі з агентом, вам буде важко запам'ятати все, що відбувалося під час вашої сесії.
Ви можете прокрутити вгору, але оскільки відбувалося ущільнення, там буде не все, і ви не зможете втримати все це в голові. Код часто зберігає прийняте рішення, але не те, чому це рішення було прийнято.
Я думаю, це може бути корисним уроком для вас, де важливо подумати про те, щоб попросити вашого агента фактично зберігати інформацію про свою траєкторію або цікаві уроки про те, як він підійшов до вирішення проблеми, щоб ви могли повернутися до цього пізніше.
Ви можете вирішити, чи варто комітити це в репозиторій, чи ні. Ви можете залишити це локально, якщо хочете, можете поділитися з командою, якщо хочете, але це може стати тим, до чого можна буде звернутися пізніше. Замість того, щоб покладатися на те, що це, можливо, є в сесії, або що ви, можливо, згадаєте про це пізніше.
Що це насправді створює?
@threepointone та @bentlegen опублікували свої думки щодо програмних фабрик, з якими я був повністю згоден:
Легко захопитися механікою процесу, оптимізувати її та забути, що вона мала виробляти. Якщо ваша фабрика в основному виробляє кращу фабрику, ви створили програмне забезпечення, продуктом якого є воно саме.
Я вважаю, що інвестувати в цикл — це нормально, і це дає складний ефект. Провал настає, коли цикл замикається, коли все, що виробляє фабрика, споживається фабрикою, і ніхто ззовні не помітив би, якби її вимкнули. Тест, який я б застосував, — це «витягування». Хтось ззовні має запитувати покращення. Якщо ви не можете назвати того, хто «витягує», ви просто поліруєте.
Відповідальність нікуди не зникає
Під усім цим лежить ширший принцип.
Відсоток коду, фізично надрукованого людьми, може різко впасти. Я не думаю, що людська відповідальність має впасти разом з ним.
- Хтось все одно обирає проблему.
- Хтось все одно обирає архітектуру.
- Хтось все одно встановлює планку якості.
- Хтось вирішує, яким сигналам верифікації можна довіряти.
- Хтось вирішує, коли доказів достатньо для релізу.
І коли отримана система виходить з ладу, фраза «це написав агент» не є виправданням. Саме тому я не вважаю, що майбутнє програмної інженерії найкраще описується як вихід людей з циклу. Натомість, людське судження переміщується.
Ми повинні вивести людей з тих частин циклу, де машини можуть генерувати сильніші, швидші, більш детерміновані сигнали. Водночас, ми повинні зосередити людей на тих місцях, де контекст, смак, ризик та довгострокова відповідальність мають найбільше значення.
Найкращі програмні фабрики визначатимуться не тим, наскільки повно вони усувають людську участь.
Вони визначатимуться тим, наскільки розумно вони її розміщують.
Тримайте людське судження вище за течією щодо наміру, форми системи та планки якості. Перевіряйте код там, де автоматичний зворотний зв'язок стає слабким або наслідки стають суб'єктивними. Просувайте кожен детермінований сигнал якомога раніше та безперервно в цикл. Свідомо посилюйте та послаблюйте обмеження в міру того, як система заслуговує або втрачає довіру.
Людина все одно повинна відповідати за те, який код в кінцевому підсумку потрапляє в реліз. Код, достатньо хороший для релізу, все одно починається з того, кому не байдуже, чи варто йому існувати.
