Чому «фабрики програмного забезпечення» зазнають невдачі: як повернути контроль

Це частина друга статті Чому програмні фабрики зазнають невдач

Відеоверсія цього допису доступна на YouTube: https://www.youtube.com/watch?v=Ib5GBkD555M

Повертаємо світло

У частині 1 я детально розповів, чому моделям не можна довіряти підтримку якості кодової бази з часом. Чому жодна кількість інженерії «обв'язки» чи токенмаксингу не вирішить проблему навчання моделей і бенчмарків. Чому «модель як суддя» для якості коду працює не так добре, як дехто намагається вам розповісти.

Наразі суддя — це ви, тож ми повернемо рев'ю коду.

Ми будемо робити те саме, що й до появи ШІ, — трохи планування наперед, щоб зменшити ймовірність довгого та складного рев'ю.

Ми знайдемо важелі впливу та використаємо ШІ для допомоги в цьому протягом 4 етапів:

• Вимоги до продукту
• Системна архітектура
• Проєктування програми
• Вертикальні зрізи

Рев'ю продукту

Все починається з рев'ю продукту: короткого документа, який фіксує що ми будуємо і чому. Мета — взяти два речення або довгий голосовий запис і перетворити це на щось напівструктуроване.

Спочатку ми узгоджуємо проблему, яку потрібно вирішити — реальний біль користувача, його мовою. По-друге, як виглядає успіх — що ми зможемо прочитати після релізу, щоб зрозуміти, чи варто було це будувати. В ідеалі це результат для користувача, наприклад, «може виконати робочий процес XYZ швидше» або «досягає віхи онбордингу ABC раніше». Іноді це щось більш низькорівневе, як-от кількість помилок або показник затримки, а іноді просто «припинилися тікети в підтримку про X».

Ми намагаємося триматися в межах продукту, а не технічних деталей. Як людина, яка стоїть однією ногою у світі продукту, а іншою — у технологіях, я часто помічаю, що відхиляюся в технічні подробиці тут. Коли це трапляється, я намагаюся просто записати це для наступних етапів і повернутися до того, що насправді відчуває користувач. Якщо технічні рішення блокують продуктові рішення, ми фіксуємо те, що маємо, і переходимо до архітектури або проводимо більше прототипних досліджень того, що можливо

І оскільки більшість цього стосується того, що бачить користувач, я не описую це — я створюю макет. Грубий HTML-макет фактичного екрану вирішує суперечку, яку три абзаци лише затягнули б.

Ось реальний приклад у роботі — документ фіксує функцію за допомогою JSON-структури, а потім два грубих HTML-макети фактичних екранів:

https://x.com/dexhorthy/status/2078592010852982977

Звісно, не все отримує рев'ю продукту. Коригування тексту, одноразовий скрипт, помилка з очевидним відтворенням — ми все ще надсилаємо це агенту одним пострілом. Це для змін, де неправильне розуміння нашого наміру агентом є дорогим.

Для цього та всіх документів у серії ми робимо рев'ю за вибором автора. Якщо ви хочете заощадити час під час рев'ю, ви обираєте людину, яка б рев'ювала PR, і проходите з нею продуктові/технічні специфікації асинхронно через коментарі в документі (ми використовуємо humanlayer для цього, але ви так само легко можете зробити це в github/notion/plannotator тощо).

Системна архітектура

Після того, як рев'ю продукту завершено, ми переходимо до системної архітектури. Це не є особливо новим, і навіть вайб-кодери починають це використовувати.

Якщо ви хочете заощадити час під час рев'ю, ви обираєте людину, яка б рев'ювала PR, і проходите з нею продуктові/технічні специфікації до того, як дійдете до кодування.

На цьому етапі ми узгоджуємо, як сервіси, кінцеві точки, схеми, черги та сховища взаємодіють між собою, не заглиблюючись у деталі проєктування програми. Щоб максимізувати пропускну здатність комунікації між людиною та агентом, ми активно використовуємо візуалізацію — наприклад, діаграми послідовності:

Форми контрактів / кінцевих точок:

Моделі даних та трансформації:

Mermaid тут підходить, але іноді це може бути надмірністю, а іноді може створити хибне відчуття, що ви досягли узгодженості. Архітектура є досить ефективним важелем, і на цьому етапі можна запобігти багатьом потенційно поганим звичкам моделі. Але цього недостатньо для створення високоякісного коду. Для цього нам потрібне проєктування програми.

Проєктування програми

Після архітектури ми робимо те, що, на мою думку, є злочинно недооціненим в агентному кодуванні: проєктування програми.

Більшість людей припускають, що коли архітектура правильна, модель може просто «варити». Ви можете це зробити, але вам може не сподобатися результат.

Але я бачу, що добре працює наступне: перш ніж хтось (людина чи агент) напише реалізацію, ми спускаємося на рівень нижче від архітектури до форми коду: типів, сигнатур методів, структури програми та стеків викликів.

Перша версія нашого навику проєктування програми була жахливою. Її було важко читати, вона виснажувала. Ми спробували mermaid, що має своє місце, але те, що ми насправді любимо — це легкі візуалізації в псевдокоді:

Дерева стеків викликів для будь-якої зміни оркестрації або потоку керування. Використовуйте синтаксис diff, коли цікава частина — це те, що змінюється:

Dillon Mulroy говорить про використання графів викликів як частини свого процесу планування, і я думаю, що це абсолютно правильно.

Файлові дерева-диффи — щоб ви завжди знали структуру вашої кодової бази та де що знаходиться

Типи та сигнатури методів для ключових нових функцій — того, що надто внутрішнє для документа архітектури, але агент все одно може зробити неправильно

Жодне з цих завдань не потребує багато часу (модель створює чернетку, ви сперечаєтеся з нею), і кожне з них — це рішення, яке ви інакше приймали б неявно під час рев'ю коду — в найдорожчий можливий момент для зміни думки.

Вертикальні зрізи

Далі ми любимо робити те, що я називаю «вертикальними зрізами» — у мене та Метта Покока була

розмова про вертикальні зрізи або «трасерні кулі» на прямому ефірі в січні 2026 року — це також називають трасерними кулями

Моделі люблять те, що я називаю «горизонтальними планами» — робити речі в порядку стеку:

1. Міграції бази даних
2. Рівень сервісів
3. API
4. Фронтенд

На практиці це означає, що немає реального способу «помацати» рішення в процесі роботи. Ви можете тестувати речі за допомогою коду, але майже для будь-якої функції, яку я коли-небудь будував, читання тестів було початком, але перегляд чогось у браузері або запит через curl під час роботи завжди був частою частиною робочого процесу.

До появи ШІ рідко хто писав 2000+ рядків коду або навіть 500 рядків без перевірки чогось по дорозі.

Мені знадобився деякий час, щоб помітити різницю з тим, до чого я звик — коли я писав код до ШІ, я завжди починав з середини і рухався назовні. Приблизно:

1. Створити контракт API та віддавати тестові дані, протестувати за допомогою curl
2. Створити фронтенд для споживання тестових даних, ітерувати та полірувати в браузері
3. Підключити API до рівня сервісів (сервіси віддають тестові дані/поведінку)
4. Додати міграції бази даних, підключити сервіси до бази даних
5. Додати багато бізнес-логіки
6. Додати багато обробки помилок

І я тестував/ітерував/полірував на кожному кроці.

Якщо я дбаю про код або скептично ставлюся до здатності моделі добре виконати роботу в цій частині кодової бази, я рев'юю код на кожному кроці. Перевірка 100-200 рядків і перенаправлення коштує набагато дешевше.

Більшість найсучасніших моделей не спроєктують такий план без людського керівництва, і важко узагальнити для кожної кодової бази чи навіть завдання, тому я вважаю за краще залишатися в циклі тут. Повірте мені. Якби я міг передати мислення на аутсорс

30 хвилин планування економить години рев'ю

Отже, у нас є кілька кроків, які, на мою думку, потребують участі людини, якщо ви хочете підтримувати якість, близьку до людської, не надриваючись над горами «сміттєвого» коду, намагаючись його прибрати постфактум. (Тобто ви дійсно хочете рухатися швидко)

1. Дизайн продукту
2. Системна архітектура
3. Проєктування програми
4. Вертикальні зрізи

Очевидно, ми не робимо весь цей процес для всього, що випускаємо (див. сайдквест нижче). Я б припустив, що розподіл приблизно такий:

• ~40% завдань отримують одноразове виконання або одноразове з 1-2 раундами легкого зворотного зв'язку
• для середніх завдань ми робимо дизайн продукту/системи в одному документі плану і не турбуємося про розбиття роботи на етапи
• для великих речей ми робимо всі кроки. Ми пропускаємо частину про продукт для речей, де це не має сенсу, наприклад, великих рефакторингів.

І в більшості випадків я відправляю модель робити 1-3 зрізи за раз і рев'юю код у міру роботи. Набагато легше перенаправити на ранньому етапі, чи то внутрішню логіку, чи то фактичну функціональність, ніж опинитися з іншого боку 2000+ рядків коду, не маючи уявлення, що зламано.

Вам, мабуть, здається, що у вас забагато пул-реквестів

У вас не забагато PR. У вас забагато поганих PR.

Ми всі рев'ювали багато PR, які потребували переробки, ще задовго до ШІ.

Але чудовий PR — це задоволення рев'ювати. Ви гортаєте кожен файл, код чистий, він відповідає всім вашим рішенням/обговоренням/вистражданим думкам про те, яким має бути програмне забезпечення.

З іншого боку, якщо пул-реквест потребує хоча б 20% переробки (і це щедро, я б сказав, що більшість одноразових PR від ШІ ближчі до 50%), це інтелектуальне навантаження та емоційне навантаження як для відправника, так і для рев'юера. (Навіть якщо відправник — ШІ, хтось, ймовірно, запустив цю роботу або «відполірував» результат ШІ, або, принаймні, дбає про результат).

Щоб заощадити ваш час (ми вже майже закінчили), я більше розповів про це в сайдквесті:

«куди йде час»

Теорія обмежень (видання 2026)

Легко трохи засмутитися через основну тезу: «поки що ми змушені читати код».

Я був досить схвильований через світ, де ми могли б просто просити про речі, дозволяти моделям «варити», не читати код і отримувати гарне програмне забезпечення, яке еволюціонує з часом і не перетворюється на лайно.

Але те, що я намагався тут викласти, — це не що інше, як обмеження. Моделі добре вміють одне, не дуже добре — інше. Як оптимізувати свій процес з огляду на ці обмеження?

Моделі добре вміють одне, не дуже добре — інше. Як оптимізувати свій процес з огляду на ці обмеження?

Можливо, ви занадто зайняті спробами рухатися в 10-100 разів швидше та намагаєтеся переконати себе, що якість коду більше не має значення, тоді як ви могли б прийняти обмеження та рухатися в 2-3 рази швидше, безпечно.

Моя заключна порада, по суті, така:

1. Добре вивчіть обмеження, розвивайте інтуїцію, багато працюючи з моделями
2. Оптимізуйте системи в межах цих обмежень
3. Шукайте важелі впливу
4. Читайте, чорт забирай, код

Ось і все. Якщо хочете залишитися на пітч, гортайте далі, мабуть. Сподіваюся, це допоможе вам уникнути катастрофи або, принаймні, вам сподобалося дивитися на милі маленькі анімації.

Дякую за читання

-дек

P.S. Ми одержимі цим

Ми будуємо humanlayer.com, агентне IDE та платформу для співпраці, яка допоможе вам рухатися в 2-3 рази швидше, підтримуючи людський (або дуже близький до людського) рівень якості коду.

Ми рухаємося до двох ідей: «будівельні блоки для вашої програмної фабрики» та «кращі верифікатори для підтримуваності програмного забезпечення» (можливо, навіть кращі моделі).

HumanLayer безкоштовний для невеликих команд до 3 осіб, і якщо ви хочете отримати допомогу з початком роботи, заходьте в наш discord або напишіть нам на founders@humanlayer.dev

Швидка подяка @calvinfo за натхнення, моєму співзасновнику @0xBlacklight, @swyx та команді @aiDotEngineer за те, що дали мені майданчик для дослідження цих ідей, а також усім нашим неймовірним клієнтам, інвесторам, друзям та родині, які вболівають за нас.

Якщо хочете дізнатися більше, я просто не замовкаю про це, тож ви можете знайти всі посилання з цього допису, а також кілька інших варіацій матеріалу в подкастах, довгострокових відео на білій дошці тощо нижче.

P.P.S. Інші ресурси

Подкасти та статті:

• Dex та Gergely обговорюють контекстну інженерію та програмні фабрики на The Pragmatic Engineer - Липень 2026
• Dex та Matt Pocock обговорюють вічні поради з кодування на ШІ (та ralph loops) - Січень 2026

Епізоди AI That Works:

• Бенчмарки нічого не доводять
• Специфікації продукту для кодування на ШІ
• Навчальні тести для кращого зворотного тиску
• Застосування принципів 12-факторних агентів до кодування на ШІ

Посилання з цього допису:

• Чому програмні фабрики зазнають невдач — ключова доповідь на AI Engineer World's Fair 2026
• StrongDM's lights-off software factory
• OpenAI: Harness Engineering (Лютий 2026)
• Ryan Lopopolo про Symphony (доповідь, Квітень 2026)
• Mario на AI Engineer Europe: «Building pi in a world of slop»
• FT: Збої Amazon через помилки кодуючих агентів
• Matt Pocock: кодові бази розвалюються
• Faros AI: звіт про прискорення та «хлист» від ШІ
• Advanced Context Engineering for Coding Agents (доповідь 25/08)
• No Vibes Allowed (доповідь 25/11)
• Everything We Got Wrong About RPI (доповідь 26/03)
• Awesome-RLVR - Ресурси з навчання з підкріпленням
• Advanced Context Engineering for Coding Agents (стаття)
• 12-Factor Agents
• Addy Osmani про вайб-кодинг vs. підтримку
• NATO Software Engineering Conference, 1968
• DoD DevSecOps Reference Design (PDF)
• Платформа кодуючих агентів Ramp
• Stripe: Minions, одноразові наскрізні кодуючі агенти
• WorkOS: Project Horizon
• Brex (Latent Space)
• Dan Shapiro: п'ять рівнів до програмної фабрики
• Simon Willison про програмну фабрику StrongDM
• «Boil the ocean»
• Shotgun surgery (refactoring.guru)
• John Ousterhout — A Philosophy of Software Design
• Robert C. Martin — Clean Code
• Martin Fowler — Refactoring
• aider
• cline
• codebuff
• SWE-Agent paper (2024)
• OpenAI Codex talk (Листопад)
• Calvin French-Owen — AI Council talk
• SWE-bench Multilingual (dataset)
• AIE Worlds Fair 2026 - The Great Loops Debate («the hype is outrunning the discipline»)
• SWE-Marathon (Abundant AI)
• DeepSWE (Datacurve)
• Frontier Code (Cognition)
• Mutation testing (Wikipedia)
• Dillon Mulroy про графи викликів у плануванні
• Dex × Matt Pocock: вертикальні зрізи / трасерні кулі (прямий ефір, Січень 2026)
• «The hard work of thinking can't be outsourced» (Jake Nations)