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

або: вуздечки недостатньо

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

схоже, ми тепер робимо цикли

Ми всі змагаємося, хто швидше запустить AI-кодинг у продакшн. Багато вже сказано про інженерію циклів, і панівна думка така: нам варто писати більше циклів.

StrongDM написав про свою фабрику програмного забезпечення з вимкненим світлом, де жодна людина не читає код і не пише код.

Наратив виглядає приблизно так:

1. Ви — вузьке місце.
2. Моделі вже достатньо хороші.
3. Код — безкоштовний.
4. Просто випускайте більше продукту.

Раян Лопополо з OpenAI писав про це в лютому та виступив з доповіддю в квітні про програмну фабрику OpenAI, Symphony.

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

ну, це... це працює

Наш друг Маріо вийшов на AI Engineer Europe і благав нас сповільнитися — тому що компанії, які не мають жодних підстав мати простої через помилки код-агентів, ну... мають простої через помилки код-агентів.

Як сказав Метт Покок, кодові бази розвалюються швидше, ніж будь-коли раніше.

Мені не вдалося знайти жодних остаточних даних/висновків від StrongDM про те, як пройшла та темна фабрика. Звіт про погоду має кілька рідкісних оновлень між лютим і червнем цього року. ред. — є трохи обговорення з командою на hacker news від 23 липня — схоже, незабаром ми можемо отримати більш формальне оновлення!

Команда Faros AI опублікувала звіт: відколи ми2 всі взялися за ці AI-інструменти для кодування в січні-лютому, якість рев'ю пул-реквестів значно впала.

• Більше коментарів, довші коментарі та безліч PR, які зливають без жодного рев'ю.
• Інцидентів значно більше.
• Багів на одного розробника значно більше.

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

«Ви тримаєте це неправильно» (ні, не ви)

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

Але як би ви не вирішили... гм... тримати це, я гарантую, вам кажуть, що якщо токен-максинг не працює для вас, це проблема навичок. Вам просто потрібно витрачати більше токенів. Відпустити читання коду. І якщо ви тільки починаєте, обіцяю, це частина прогресу. Я теж так думав минулого літа.

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

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed — Solving Hard Problems in Complex Codebases
• Everything We Got Wrong About RPI

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

• у 10–100 разів швидше,
• високої якості,
• і нікому не доведеться робити те, що ми всі ненавидимо, — код-рев'ю.

Все, що нам потрібно зробити, — налаштувати більше лінтерів і додати трохи магічних слів на кшталт «змагальне рев'ю» до достатньої кількості ботів для рев'ю PR, і наше програмне забезпечення щасливо будуватиме себе без інцидентів.

Це не проблема навичок

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

Щоб розібратися з цим, мені довелося заглибитися в те, як насправді навчають та оцінюють моделі для кодування — як з точки зору RLVR, так і з точки зору бенчмарків.

У цьому дописі я розгляну:

1. Програмні фабрики сягають 1968 року, як вони еволюціонували, і як AI їх змінив
2. Чому моделі можуть генерувати гори сміття, незважаючи на відмінні результати в бенчмарках (навіть у новітніх «передових»)
3. Незважаючи на це, ви можете рухатися досить швидко, не спалюючи свою кодову базу

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

Відеоверсія: цей допис заснований на (та розширює) моїй основній доповіді на AI Engineer World's Fair 2026.

Дякую @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, та @jeffreyhuber за відгуки до цього допису.

Відступ: це не має нічого спільного з віб-кодингом

Адді Османі розплутав цю річ, яку варто підкреслити:

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

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

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

Коротка історія програмної фабрики

Я будував та вивчав програмні фабрики всю свою кар'єру, але я дізнався це лише нещодавно: термін сягає корінням конференції НАТО в 1968 році — тієї самої, яка подарувала нам «програмну інженерію».

Єдине, що я знаходжу дуже цікавим з того часу, це те, що Міністерство оборони США написало 31-сторінковий PDF про те, як DoD має почати краще використовувати jenkins або щось таке.

Програмна фабрика 2022 року

Давайте визначимо нашу «програмну фабрику» приблизно 2022 роком, безпосередньо перед AI. У типовій програмній фабриці:

• Люди вирішують, що будувати — інженери, PM, керівництво, яке задає бачення
• Це потрапляє в трекер — Linear, Jira, байдуже: скінченний автомат того, що потрібно зробити
• Хтось бере задачу і будує її — ймовірно, виконує деяке ручне/автоматизоване тестування в процесі
• Пул-реквест — автоматичні перевірки, людина перевіряє код, можливо, хтось забирає його, щоб протестувати
• Щось не так? Повернення до «хтось будує річ»
• Реліз у продакшн — і він контактує з користувачами
• Додавання моніторингу — ціла індустрія побудована на тому, щоб підняти інженера о 3-й ночі, коли щось ламається
• Користувачі скаржаться — просять речі, знаходять баги, подають запити на функції → назад до команди, щоб додати в трекер

І так далі. Ми ще навіть не дійшли до AI, а вже є кілька циклів на цій картинці.

винесення узгодження на передній план

Є річ, яку команди зрозуміли десятиліття тому: побудова займає години або дні, і рев'ю теж.

Тому ми виносимо роботу на передній план — планування, архітектурні пропозиції, спринт-планування — разом, як команда. Це означає:

• менше переробок, тому що ми узгодили до того, як хтось написав код
• менше часу на рев'ю кожного рядка, якщо ви коли-небудь читали довгий, але добре написаний PR, ви знаєте, як швидко проходить рев'ю, коли все майже ідеально

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

Агентна програмна фабрика

Тепер кожна компанія та її мати —

• Ramp
• Stripe
• WorkOS
• Brex

провела більшу частину цього року, пояснюючи, як вони побудували агентну фабрику, яка випускає близько 75% їхнього коду.

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

Коли агент будує річ:

• Побудова скорочується з годин або днів до хвилин або годин.
• Рев'ю все ще займає години або дні. Людина все ще повинна прочитати код і протестувати зміну. Отже, рев'ю тепер є вузьким місцем.

Тому ви пришвидшуєте і рев'ю:

• Агентне код-рев'ю, щоб виявити стиль, баги, безпеку.
• Агентне регресійне тестування, щоб протестувати його ззовні за допомогою браузерів і комп'ютера, і, можливо, надіслати вам миле маленьке відео, коли воно закінчить

Рев'ю тепер швидше, але, ймовірно, все ще є вузьким місцем. Але ми можемо зробити більше циклів.

Далі ви можете направляти інциденти на фабрику. Замість того, щоб піднімати когось о 3-й ночі, вони прокидаються від PR, який, можливо, вже це виправляє.

Ми також можемо направляти відгуки користувачів на фабрику. Люди просять речі, вони будуються.

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

Що підводить нас до програмної фабрики з вимкненим світлом.

Програмна фабрика з вимкненим світлом

Ден Шапіро ввів цей термін, а Саймон Віллісон написав про реалізацію StrongDM — де ми більше не читаємо код.

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

Тому ви відкидаєте його і вкладаєте зусилля в інше місце:

• Інвестуєте в тестування та дозволяєте агенту тестувати власну роботу
• Інвестуєте в пісочниці та оркестрацію
• Інвестуєте в автоматизоване рев'ю
• Інвестуєте в моніторинг
• Інвестуєте в розгортання
• Інвестуєте в збір сигналів зворотного зв'язку від користувачів

І тепер робота дійсно зводиться лише до одного питання: скільки речей ми можемо попросити агента побудувати? Яку частину океану ми хочемо викип'ятити?

Це буде чудово (ні, не буде)

Я збираюся висунути дещо потенційно суперечливе: фабрика з вимкненим світлом не працює.

Давайте розберемося, чому програмні фабрики зазнають невдач.

Ми пробували це

У липні 2025 року ми повністю перейшли на режим без світла. Просто читали специфікації та задачі, фонові агенти для всього дрібного/середнього, все таке.

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

• Ви проводите глибоке дослідження з урахуванням контексту, збираючи всі правильні частини в розумну зону для аналізу моделлю
• Ви змушуєте агента спробувати відтворити проблему 10 різними способами

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

І тим часом:

• Ваш сайт був недоступний.
• Ваші користувачі були розлючені.
• І ви, якщо ви хоч трохи схожі на мене, були нещасні — читаючи весь той сміттєвий код, який ви пропустили у свою систему.

Коли це сталося вперше, я відмахнувся. Навіть після того, як провів майже два тижні, копаючись у спагеті від Claude, «ризик невдачі був вартий швидкості». Десь до ~третього разу в листопаді ми вирішили, що буде легше переписати все з нуля, і мій співзасновник провів два цілих тижні у VS Code (навіть не в Cursor), прокладаючи всі патерни вручну.

моделі погіршують якість кодової бази з часом

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

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

Я не буду багато говорити про підтримуваність. Є купа книг, які ви можете прочитати про це:

• Джон Оустерхаут, A Philosophy of Software Design
• Роберт С. Мартін, Clean Code
• Мартін Фаулер, Refactoring

Отже, чому моделі не можуть робити підтримуваність програмного забезпечення?

«Але ж моделі, напевно, стали кращими з того часу»

У цей момент вам, можливо, не терпиться сказати: але, Дексе, моделі, напевно, стали набагато кращими з липня

Вони стали кращими — у деяких аспектах. В інших вони приблизно такі ж.

• Вирішення разових проблем або віб-кодинг нового маркетингового сайту? Так. Набагато краще.
• Покращення якості кодової бази з часом? Не набагато краще, наскільки я можу судити.

Я не можу цього довести. Ви теж не можете. Не існує хороших бенчмарків для здатності моделі підтримувати якість кодової бази. (Докладніше про те, куди це рухається, пізніше.)

НЕ ІСНУЄ ХОРОШИХ БЕНЧМАРКІВ для здатності моделі підтримувати якість кодової бази

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

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

Claude Code виграв завдяки навчанню з підкріпленням всередині оснащення

Claude Code пройшов шлях від нуля до ~$4 млрд — тепер приблизно ~$9 млрд — доходу менш ніж за рік.

Що трохи дико, тому що вже були чудові CLI-агенти. aider, cline, codebuff — всі вони з'явилися до Claude Code, всі з дійсно чудовою вбудованою інженерією контексту, всі з тим самим набором інструментів, які ви могли б приписати Claude Code: читати, писати, редагувати, grep, bash. Я користувався ними. Вони були хороші. Але також використання інструментів іноді... просто не вдавалося — ви спостерігали, як він тричі марно намагається зробити одне й те саме редагування, і знову відкривали свій редактор, щоб зробити це самому.

Стаття SWE-Agent від 2024 року описує, як невеликі зміни у формі інструментів призводять до помітних відмінностей, наприклад, включення номерів рядків у результати ReadFile або зміна інструменту Edit із заміни знайденого/заміненого на редагування діапазону рядків.

Потім запустили Claude Code, і він досить швидко пішов угору. Ви можете списати це на дистрибуцію, але загальноприйняте пояснення полягає в тому, що Claude Code виграв, тому що він був кращим, і що він був кращим, тому що Anthropic застосував RL до моделі всередині оснащення — вперше лабораторія навчила модель на тих самих інструментах, з якими збиралася її випустити. І вона стала дійсно, дійсно хорошою у використанні цих інструментів в агентному циклі.

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

Команда OpenAI виступила з доповіддю в листопаді, яка досить добре це сформулювала: якщо ви будуєте оснащення, але не володієте вагами і не можете застосувати RL до моделі всередині нього, ви завжди будете в програші перед командою, яка володіє і тим, і іншим.

RL для код-агентів за 60 секунд

Я провів багато досліджень на цю тему і створив купу візуалізацій, щоб спробувати пояснити важливі частини, але я виявив, що Келвін Френч-Оуен (MTS у команді codex, засновник Segment) виступив на AI Council і зробив це набагато краще і чистіше, тому я просто вставлю цю анімацію тут, натхненну його слайдами:

Щоб зробити модель кращою в кодуванні, ви:

1. генеруєте кілька трасувань код-агента для вирішення проблеми (наприклад, виправити мої тести)
2. оцінюєте трасування на основі деяких критеріїв (верифікатор)
3. оновлюєте ваги моделі, щоб зробити хороші трасування більш імовірними, а погані — менш імовірними

І потім ви робите це мільйони разів протягом тижнів або місяців.

Однак «оціночна» частина цих речей, як правило, може бути примхливо одномірною.

Немає штрафу за поганий дизайн

Візьмемо SWE-bench Multilingual. Завдання невеликі — приблизно п'ятнадцять хвилин роботи кожне — зібрані з відкритих репозиторіїв, таких як Redis, jq та Django. Винагорода — одиниця або нуль на основі:

• FAIL_TO_PASS — чи виправили ви те, що вас просили виправити?
• PASS_TO_PASS — чи зробили ви це, не зламавши нічого іншого?

Ось реальний приклад, fastlane__fastlane-19304, з fastlane — Ruby-проєкту. Його zip-дія бере два опціональні параметри і одразу викликає на них .empty?, тому щойно ви залишаєте include та exclude порожніми, все падає:

Людське виправлення, яке закрило цю конкретну проблему, — це два рядки (за замовчуванням nil перетворюються на порожні масиви):

Під час оцінки модель

1. починає з базового коміту — репозиторій перевірено на момент безпосередньо перед тим, як було застосовано те виправлення
2. звіт про помилку — у цьому випадку 'zip_command': undefined method 'empty?' for nil:NilClass

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

Потім:

1. Ми зберігаємо будь-який патч, який він створив, потім
2. Викидаємо будь-які редагування, які він зробив у тестових файлах (ми ловили модель, яка тихо закоментовувала невдалий тест або вставляла імітацію, яка робить тест марним)
3. Застосовуємо тестовий патч бенчмарку зверху, і
4. Запускаємо весь набір: існуючі zip-тести (PASS_TO_PASS) плюс новий (FAIL_TO_PASS), щоб побачити, чи обидва вони проходять

Відступ — Бенчмарки не є верифікаторами — насправді їх потрібно ізолювати один від одного (не тренуватися на тесті, і так далі) — я в основному маю на увазі передати форму «оцінки якості трасування код-агента» та її обмеження.

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

немає штрафу за погіршення підтримуваності кодової бази

Ось як ви отримуєте try-catch навколо всього:

Верифікація якості на порядки складніша, ніж «чи тести пройшли»

Запуск тестів дає вам чіткий успіх або невдачу за ~секунди. Ось чому RL може виконувати мільйони циклів для оптимізації кожного покоління моделі.

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

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

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

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

Передній край повільно стає кращим

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

Кілька зусиль, які, на мою думку, рухаються в правильному напрямку:

• SWE-Marathon (Abundant AI): завдання на ~400 годин, як-от «клонувати весь Excel, кожну функцію» — зі складовим каналом винагороди замість одного біта успіху/невдачі
• DeepSWE (Datacurve): великі завдання на OSS-репозиторіях, які ніколи не були побудовані в реальному світі, тому за побудовою вони не можуть вже бути в навчальному наборі (вирішує контамінацію, але не якість)
• Frontier Code (Cognition): завдання з кількома PR і розумний хід, який оцінює якість детерміновано — він штрафує модель за написання тестів, які не провалюються на коді до патча (якщо ви ніколи не чули про мутаційне тестування, на вас чекає веселий райд5). Він також запускає модель-суддю над diff, перевіряючи правила якості коду.

Але модель, яка оцінює якість, може зайти лише так далеко.

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

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

Звичайно, більше агентів рев'ю та більше токенів допомагають — вони піднімають нижню планку, виловлюючи дурниці.

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

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

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

Вмикаємо світло знову

Сьогодні я дізнався, що Twitter Articles мають "медіа-ліміт", тож решта цього матеріалу піде в другу частину — стежте за оновленнями.