Штучний інтелект уже встиг змінити буденність розробників: від автодоповнення до повноцінних агентів, які самі читають репозиторій, генерують патчі й ганяють тести. Але разом із відчуттям «магічної продуктивності» приходить і новий клас інженерних проблем. Про це говорять Армін Роначер — відомий творець Python‑фреймворку Flask, понад 20 років в open source, колишній технічний лідер у Sentry — та Крістіна Понсела Кубейро, «native AI engineer», яка з самого початку вчилася програмувати з AI‑інструментами. У 2023‑му вони заснували компанію Earendil, що фокусується на тому, як безпечно й осмислено інтегрувати AI‑агентів у розробку.
Їхній досвід за останні 12 місяців активної роботи «з агентами і поверх агентів» показує: головна загроза не в тому, що моделі помиляються, а в тому, як саме вони помиляються і як це змінює структуру кодової бази. Виникає те, що вони називають «slop» — код, який працює, проходить тести, але збільшує ентропію системи, множить приховані точки відмови й накопичує технічний борг. Вихід, на їхню думку, — не відмовлятися від агентів, а перебудовувати код як інфраструктуру, роблячи його «читабельним» для моделей і свідомо повертаючи фрикцію там, де без людського судження не обійтися.
Коли код стає безкоштовним: гігантські PR і неможливість рев’ю
Один із найпомітніших побічних ефектів AI‑агентів — різке зростання розміру змін. Якщо раніше навіть досвідченому інженеру було складно «наштампувати» тисячі рядків коду за день, то тепер це питання кількох промптів. Генерація коду стала майже безкоштовною, і це миттєво відбилося на практиках команд.
Агенти схильні створювати величезні pull request’и — на тисячі рядків, із десятками змінених файлів. Для моделі це природно: вона отримує завдання, бачить можливість «порефакторити заодно» або додати допоміжні утиліти, і робить це без жодного відчуття міри. Для людини ж такий PR — психологічний стоп-сигнал. Саме в момент, коли варто максимально зосередитися й критично подивитися на зміни, більшість рецензентів відчувають перевантаження й «випадають»: рев’ю відкладають, поверхнево проглядають або просто rubber‑stamp’ять.
Проблему підсилює ще один зсув: різко змінилася пропорція між потужністю створення коду й потужністю його рев’ю. Кожен інженер тепер може генерувати в рази більше змін, ніж здатен якісно переглянути. До цього додається новий феномен — у процес розробки входять люди, які раніше не писали продакшн‑код: маркетологи, менеджери, колишні інженери в керівних ролях. Вони теж користуються AI‑інструментами й «шиплять» фічі, але відповідальність за якість залишається на інженерній команді.
У результаті кількість «суб’єктів генерації коду» — людей і агентів — перевищує кількість тих, хто реально може й має нести відповідальність. Це прямий шлях до того, що кодові зміни проходять у продакшн без належного осмислення, а технічний борг накопичується не поступово, а стрибками — разом із кожним гігантським PR.
Оптимізація на «просто працює»: як агенти будують крихкі системи
Ще глибша проблема — у самій цільовій функції сучасних агентів. Вони тренуються на тому, щоб:
- Згенерувати код.
- Запустити його.
- Пройти тести або хоча б не впасти з помилкою.
- Зробити «прогрес» у задачі.
Ніде в цій послідовності немає вимоги «бути підтримуваним через три роки» чи «відповідати архітектурним принципам команди». Відповідно, поведінка агентів системно відрізняється від поведінки досвідченого інженера.
Характерний приклад — завантажувач конфігурації. Типовий патерн, який часто генерує агент: спробувати прочитати конфіг‑файл, а якщо не вийшло — «тихо» впасти назад на дефолтні значення. З погляду моделі це раціонально: код не ламається, сервіс стартує, тести, швидше за все, проходять. З погляду продакшн‑експлуатації це мінне поле.
Людина, яка проєктує систему, зазвичай розуміє, що «мовчазний дефолт» — небезпечний. Якщо сервіс не зміг прочитати конфіг, це має бути явна помилка, яка зупиняє процес або принаймні голосно сигналізує. Інакше можна годинами писати в базу даних некоректні дані, не підозрюючи, що система працює не з тим оточенням, не з тим endpoint’ом чи не з тим ключем.
Агенти ж, навпаки, схильні агресивно «відновлюватися» від локальних збоїв. Не вийшло прочитати файл — візьмемо дефолт. Не вдалося викликати API — повторимо, обгорнемо в try/except, повернемо щось «розумне за замовчуванням». Кожне таке локальне «самовідновлення» додає нову гілку поведінки, новий стан системи, новий тип відмови. У підсумку сервіс начебто «живучий», але насправді стає дедалі більш крихким: замість чітких, передбачуваних точок падіння з’являється безліч напівробочих режимів, які важко відтворити й діагностувати.
Людські розробники часто уникають подібних конструкцій не лише через досвід, а й через інтуїтивне відчуття «це погано пахне». У агентів такого «сором’язливого інстинкту» немає. Вони не відчувають дискомфорту від того, що додають ще один прихований шлях виконання, ще один рівень умов, ще один шар «магії», який ускладнює ментальну модель системи.
Усе це веде до зростання ентропії кодової бази. Кожна нова фіча, згенерована агентом, не просто додає функціональність — вона розширює простір можливих станів і відмов, часто без належної документації, логування чи інваріантів. Система продовжує працювати, але стає дедалі менш зрозумілою навіть для своїх творців.
Коли кодова база переростає власного агента: дублювання, суперечності й «деменція» на глобальному рівні
Ще один парадокс AI‑агентів: вони здатні дуже швидко роздути кодову базу до такого розміру й складності, з якими самі вже не можуть упоратися. Обмеження контекстного вікна означає, що модель ніколи не бачить «усю систему» цілком. Вона працює локально: читає кілька файлів, будує гіпотезу про те, як усе влаштовано, і на цій основі генерує зміни.
Поки проєкт невеликий, це працює відносно добре. Але щойно кількість модулів, сервісів, конфігів і крос‑залежностей зростає, агент починає пропускати важливі частини. Він не встигає прочитати всі релевантні файли, не бачить уже реалізовану логіку й… пише її ще раз, але в іншому місці.
Так виникає класична хвороба великих систем — дублювання функціональності. Наприклад, у коді вже є утиліта для нормалізації користувацьких ідентифікаторів, але агент її не помічає й створює нову, з трохи іншою семантикою, в іншому модулі. Або вже існує централізований шар перевірки прав доступу, але модель додає ще одну перевірку безпосередньо в обробник API, із власною логікою edge‑кейсів.
На локальному рівні кожне таке рішення виглядає «розумним»: агент бачить задачу й вирішує її в межах доступного контексту. На глобальному рівні кодова база починає «розповзатися»: одна й та сама бізнес‑логіка реалізована в кількох місцях, із дрібними відмінностями; інваріанти порушуються; виправлення багів потрібно вносити в кілька точок, і легко щось пропустити.
Цей ефект особливо помітний у продуктах, де багато взаємодіючих аспектів: UI, API, різні рівні дозволів, feature‑flags, білінг, інтеграції з іншими сервісами. Усе це разом просто не поміщається в контекстне вікно агента. Локально модель поводиться раціонально, але на глобальному рівні починає виглядати «дементною»: приймає суперечливі рішення, ігнорує вже прийняті архітектурні домовленості, дублює або розмиває відповідальності.
У бібліотеках ситуація інша. Там зазвичай є чітко окреслена проблема, просте ядро, зрозумілий API й жорсткі обмеження. Агенту легше побудувати цілісну ментальну модель такої системи в межах свого контексту. Тому на бібліотеках моделі часто показують вражаючі результати: акуратні абстракції, чистий код, добре структуровані модулі.
У продуктах же, де все пов’язано з усім, агенти неминуче працюють із «усіченим» уявленням про систему. Це не означає, що їх не можна застосовувати, але вимагає іншого підходу до організації коду.
Бібліотеки проти продуктів: де агенти справді сильні
Розрив між бібліотеками й продуктами — не випадковість, а прямий наслідок того, як влаштовані сучасні моделі. Бібліотека зазвичай має:
чітко сформульовану задачу (наприклад, парсинг формату, клієнт до API, алгоритмічне ядро);
обмежений набір публічних API, які легко описати й утримувати в контексті;
просте, добре виділене ядро, навколо якого будуються розширення.
У такому середовищі агенту легко: він бачить повну картину, може планувати зміни, не боячись зачепити щось несподіване, і здатен утримувати в голові (у контекстному вікні) всі важливі інваріанти.
Продукт — інша історія. Тут одночасно існують:
користувацький інтерфейс із власною логікою станів;
бекенд‑API з контрактами, що еволюціонують;
система прав доступу, яка залежить від ролей, організацій, контексту;
feature‑flags, що вмикають і вимикають поведінку для різних сегментів;
білінг, що впливає на доступність функцій;
інтеграції з іншими сервісами, які мають власні обмеження й SLA.
Усе це переплетено. Змінюючи одну частину, легко ненавмисно зламати іншу. Для людини це теж складно, але хоча б можливо: архітектори й старші інженери будують ментальні моделі, пишуть ADR, проводять дизайн‑сесії. Для агента ж глобальна картина завжди фрагментована.
Саме тому спроби «віддати продукт на відкуп агентам» часто закінчуються розчаруванням: локально все виглядає логічно, але загальна поведінка системи стає непередбачуваною. Висновок не в тому, що агенти «погані», а в тому, що кодову базу потрібно робити для них «легібельною» — такою, яку можна зрозуміти й модифікувати, маючи обмежений контекст.
Агент-легібельна кодова база: код як інфраструктура
Щоб отримати від агентів користь, а не нескінченний «slop», Earendil пропонує дивитися на кодову базу як на інфраструктуру — не лише для людей, а й для моделей. Інакше кажучи, її потрібно спроєктувати так, щоб агент міг:
локально зрозуміти, де він знаходиться;
чітко побачити межі відповідальності модуля;
знайти правильні точки розширення без дублювання логіки;
уникати прихованої «магії», яка неочевидна з коду.
Ключовий принцип тут — модульність. Але йдеться не лише про розбиття на компоненти, а й про модульність самого потоку виконання. Наприклад, якщо будується AI‑асистент, важливо явно виділити основні кроки пайплайна: отримання запиту, нормалізація, вибір інструментів, виклик моделей, пост‑обробка, логування. Кожен крок має бути окремим, чітко названим блоком, а не розмазаний по кількох файлах через динамічні імпорти й приховані колбеки.
Другий важливий елемент — механічне забезпечення якості через строгий лінтинг і правила стилю. Для агентів це не менш важливо, ніж для людей. Серед практик, які особливо допомагають:
заборона «голих» catch‑all’ів на кшталт except Exception: без явної обробки. Вони ховають помилки й заохочують ту саму агресивну «самовідновлюваність», яка робить системи крихкими;
вимога унікальних імен функцій і чіткої семантики. Якщо в коді є кілька handle_request у різних модулях, агенту важко зрозуміти, який саме слід використати або розширити. Унікальні, описові назви полегшують навігацію й зменшують ризик дублювання;
уникнення прихованої магії — динамічних імпортів, метакласів, неявних реєстрів. Те, що для досвідченого Python‑розробника може бути елегантним трюком, для агента стає непрозорою чорною скринькою. Чим більше поведінки виражено явно в коді, тим легше моделі її зрозуміти й коректно змінити.
Нарешті, важливо свідомо повернути фрикцію в ті частини процесу, де помилка особливо дорога. Йдеться про зони, де людське судження має бути обов’язковим:
міграції бази даних, які можуть знищити або пошкодити критичні дані;
зміни в системі прав доступу й авторизації, що впливають на безпеку;
маніпуляції з білінгом і фінансовими потоками;
конфігураційні зміни, що стосуються продакшн‑оточення.
У цих місцях не варто намагатися «зняти тертя» за допомогою агентів. Навпаки, потрібні додаткові бар’єри: обов’язкові ручні рев’ю, двофакторне підтвердження, окремі RFC‑процеси. Агенти можуть допомагати готувати міграції чи політики доступу, але не повинні мати можливість самостійно їх застосовувати без людського контролю.
Висновок: фрикція як інструмент керування ентропією
AI‑агенти вже стали невід’ємною частиною сучасної розробки, і навряд чи цей тренд зміниться. Вони справді здатні прискорювати роботу, знижувати поріг входу й допомагати будувати складні речі меншими командами. Але разом із цим вони приносять новий тип технічного боргу: неочевидний, розмазаний по всій кодовій базі, замаскований під «код, який працює й проходить тести».
Гігантські pull request’и, оптимізація на «просто запустити», агресивне відновлення від локальних збоїв, дублювання логіки й фрагментація — усе це не випадкові артефакти, а закономірний результат того, як влаштовані сучасні моделі й як ми їх застосовуємо. Ігнорувати ці закономірності — означає дозволити ентропії системи рости безконтрольно.
Підхід, який пропонують Армін Роначер і Крістіна Понсела Кубейро, не романтичний і не апокаліптичний. Він прагматичний: прийняти, що агенти — це ще один тип «користувача» вашої кодової бази, зі своїми обмеженнями й сліпими зонами. І, як будь-яку інфраструктуру, код потрібно спроєктувати так, щоб цей користувач міг працювати безпечно.
Модульність компонентів і потоків, строгий лінтинг, уникнення прихованої магії, свідоме повернення фрикції в критичні зони — усе це не «гальма прогресу», а механізми керування. Фрикція змушує зупинитися й подумати саме там, де це найбільш потрібно. У світі, де генерація коду стала майже безкоштовною, саме ці точки опору й визначатимуть, чи залишиться ваш продукт керованим, чи перетвориться на ще одну крихку систему, яку ніхто до кінця не розуміє — включно з агентами, що її написали.
Джерело
The Friction is Your Judgment — Armin Ronacher & Cristina Poncela Cubeiro, Earendil