Штучний інтелект уже став звичним інструментом для розробників: автодоповнення, генерація функцій, цілі pull request-и, написані агентами. Але разом із відчуттям «магічної» швидкості приходить менш очевидна загроза. Про цю психологічну й організаційну пастку говорять Армін Роначер — автор Flask із понад 20‑річним досвідом у open source — та Крістіна Понсела Кубейро, «нативна» AI‑інженерка, яка з самого початку вчилася програмувати з такими інструментами. Вони разом розвивають компанію Earendil, що намагається осмислити роль AI‑агентів у розробці ПЗ.
Їхній головний висновок: обіцянка «ship without friction» — «постачати без тертя» — перетворюється на системну проблему. AI‑інструменти змінюють поведінку інженерів, структуру команд і розподіл відповідальності так, що швидкість починає підривати саме те, що мало би захищати — якість, надійність і розуміння системи.
Коли «фановий буст продуктивності» стає нормою й тиском
Перший етап знайомий майже кожному, хто серйозно працював із AI‑асистентами коду. Спочатку це відчувається як бонус: кілька вдалих промптів — і рутинні шматки коду пишуться за секунди, прототипи збираються швидше, дрібні задачі закриваються без зайвих зусиль. Інструмент дає відчутний приріст продуктивності й навіть звільняє час.
Але цей «золотий період» триває недовго. Як тільки інструменти стають достатньо корисними, вони дуже швидко стають загальноприйнятим стандартом. Якщо вчора AI був вашим особистим секретною зброєю, сьогодні він — очікуваний мінімум. У команді, де більшість уже користується такими засобами, «ручний» темп роботи починає виглядати повільним, навіть якщо він якісніший.
Так виникає нова норма: всі «мають» використовувати AI, а отже — «мають» відвантажувати більше й швидше. Те, що спочатку давало відчуття свободи й додаткового часу, перетворюється на джерело тиску. Планка продуктивності піднімається, але час на осмислення, дизайн і рецензування коду нікуди не додається. Навпаки, саме ці «повільні» активності першими опиняються під скороченням.
У результаті швидкість стає самоціллю. Якщо раніше інженер міг аргументовано сказати: «Мені потрібен день, щоб продумати архітектуру», — то тепер очікування зміщується до: «AI ж уже нагенерував код, чому це ще не в проді?».
Аддиктивний цикл промптів: ще один запит — і, можливо, все запрацює
Другий шар пастки — чисто психологічний. AI‑інструменти кодування працюють у надзвичайно короткому циклі «запит — відповідь». Ви пишете промпт, отримуєте код, запускаєте, бачите помилку, уточнюєте промпт, отримуєте новий код. Кожна ітерація займає хвилини, іноді секунди.
Цей цикл виявляється дивовижно аддиктивним. Кожен наступний промпт може стати тим самим «щасливим» — тим, після якого тест нарешті пройде, фіча запрацює, баг зникне. А може, навпаки, додати ще трохи «слопу» — коду, який формально працює, але ускладнює систему, маскує помилки або створює нові.
Саме ця невизначеність і тримає в грі. Замість того щоб зупинитися, відкотити зміни, перечитати код і спроєктувати рішення, інженер частіше обирає ще один промпт. І ще один. І ще. Кожен раз здається, що до правильного варіанту залишився один крок.
Проблема в тому, що швидкість генерації коду створює ілюзію продуктивності. На екрані постійно з’являється щось нове: функції, класи, конфігурації, тести. Відчуття «я багато зробив» підкріплюється візуально. Але саме в цей момент найчастіше зникає час на ключові питання: чи потрібен взагалі цей код? чи правильно ми розв’язуємо задачу? чи не ламаємо ми приховані інваріанти системи?
AI не зупиниться сам. Агент не відчує, що «щось пішло не туди» або що зміни стали надто масштабними й ризикованими. Він продовжить читати файли, які не мав би чіпати, створювати нові, дублювати логіку, поки його не зупинить людина. Але саме людині в цьому режимі найважче натиснути на гальма.
Швидкість проти розуміння: як AI витісняє дизайн і рев’ю
Швидке генерування коду створює ще одну, більш структурну проблему: воно витісняє час на глибоке розуміння системи. Коли інженер бачить, що за годину можна «наштампувати» десятки функцій і кілька сотень рядків коду, спокуса вимірювати свій внесок у рядках і закритих задачах стає дуже сильною.
У цьому режимі страждають три критичні практики.
По-перше, системний дизайн. Продумати структуру сервісу, межі модулів, контракти між компонентами — це завжди повільніше, ніж попросити агента «зроби мені ендпоінт, який робить X». Коли швидкість стає головною метрикою, дизайн починає виглядати як «розкіш», а не як необхідність.
По-друге, уважне рев’ю. AI‑агенти легко генерують великі pull request-и на тисячі рядків. Формально це «прогрес»: фіча реалізована, тести, можливо, навіть проходять. Але саме обсяг стає бар’єром. Рев’юер відкриває PR на 5 000 рядків і відчуває перевантаження. У такому стані найпростіше рішення — поверхнево пробігтися, поставити кілька коментарів по стилю й натиснути «Approve». Або взагалі перетворити рев’ю на ритуал rubber stamp.
По-третє, глибоке розуміння коду. Коли значна частина змін з’являється як відповідь моделі, інженер часто перестає бути автором логіки, а стає радше оператором, який формулює запити й з’єднує шматки. Це не обов’язково погано, але в поєднанні з браком часу на читання й осмислення коду призводить до того, що в команді стає все менше людей, які справді розуміють, як працює система в цілому.
У підсумку AI створює відчуття «я роблю більше», але насправді зменшує частку часу, яку інженери витрачають на те, що робить системи надійними: дизайн, рев’ю, рефлексію.
Дисбаланс потужності: коду пишуть більше, ніж хтось здатен перевірити
На рівні окремого інженера AI‑інструменти різко збільшують здатність створювати код. Але вони майже не збільшують здатність цей код перевіряти. Прочитати, зрозуміти й критично оцінити 500 рядків коду все ще займає приблизно стільки ж часу, як і раніше, незалежно від того, хто їх написав — людина чи модель.
У командному масштабі це створює нову асиметрію. Раніше баланс між написанням і рев’ю був відносно стабільним: швидкість, з якою інженери могли продукувати код, приблизно відповідала їхній здатності його переглядати. Тепер кожен інженер отримує множник до продуктивності написання, але не до рев’ю. У результаті:
обсяг pull request-ів зростає швидше, ніж здатність команди їх якісно переглядати;
частка великих, «страшних» PR-ів на тисячі рядків збільшується;
рев’ю все частіше або пропускається, або перетворюється на формальність.
До цього додається ще один фактор: AI‑агенти оптимізовані на те, щоб «робити прогрес». Їхня внутрішня логіка — написати код, запустити тести, пройти їх, рухатися далі. Вони не оптимізовані на підтримуваність, чистоту архітектури чи мінімізацію майбутнього боргу.
Звідси — характерні патерни коду, які досвідчений інженер інстинктивно уникає. Наприклад, конфігураційні лоадери, які при помилці читання файлу «тихо» падають назад на дефолтні значення. Формально система працює, але ризик колосальний: можна годинами писати в базу дані з неправильними параметрами й помітити це лише постфактум. Людина, яка вже обпікалася на подібних ситуаціях, відчуває внутрішній дискомфорт від такого коду. Агент — ні.
Ще один наслідок: агенти легко створюють додаткові точки відмови, намагаючись «героїчно» відновлюватися від локальних помилок. Сервіс, який замість того, щоб чітко впасти при критичній проблемі, продовжує працювати в напівзламаному стані, виглядає стійким, але насправді стає крихким. Він накопичує приховані помилки, які важко відтворити й діагностувати.
Усе це збільшує ентропію кодової бази. Причому настільки швидко, що в якийсь момент навіть сам агент перестає бути здатним адекватно «мислити» про систему: він більше не читає всі потрібні файли, дублює логіку в нових місцях, не помічає вже наявних абстракцій. Люди ж, які мали би це контролювати, фізично не встигають перевірити весь потік змін.
Коли маркетинг пише код: розширення кола авторів без розширення відповідальності
Ще один малопомітний, але важливий ефект AI‑інструментів — вони радикально розширюють коло людей, які можуть змінювати продакшн‑системи. Якщо раніше для цього потрібно було мати хоча б базову інженерну підготовку, то тепер достатньо вміти формулювати промпти й розуміти бізнес‑контекст.
У багатьох компаніях уже з’явилися кейси, коли:
маркетингові фахівці самі вносять зміни в код, наприклад, у трекінг, лендинги, прості інтеграції;
колишні інженери, які стали керівниками або СЕО, повертаються до коду через AI‑асистентів, не витрачаючи час на відновлення технічної форми.
Формально це виглядає як перемога: бізнес‑команди стають більш самостійними, зменшується кількість «дрібних» запитів до інженерів, фічі для експериментів запускаються швидше. Але є ключовий нюанс: разом із правом змінювати код до цих людей не переходить повна технічна відповідальність за наслідки.
Відповідальність за якість, безпеку й надійність системи, як і раніше, лежить на ядровій інженерній команді. Саме інженери чергують по інцидентах, розгрібають аварії, розуміють, як пов’язані між собою сервіси, конфігурації, бази даних, черги. Але тепер кількість «акторів», які можуть внести зміни, зростає — і серед людей, і серед машин.
Виникає дисбаланс: число тих, хто може створювати код, значно перевищує число тих, хто реально може й повинен нести за нього відповідальність. Машини поки не можуть бути суб’єктами відповідальності, а неінженерні ролі зазвичай не включені в процеси глибокого технічного рев’ю й постінцидентного аналізу.
На практиці це часто призводить до того, що:
код‑рев’ю для «простих» змін починають сприймати як бюрократію, яку хочеться обійти;
pull request-и від неінженерних ролей отримують поверхневий перегляд, бо «там же всього кілька рядків»;
зміни, згенеровані AI, сприймаються як менш ризиковані, ніж «ручні», хоча насправді можуть містити більше прихованих проблем.
Інженерна команда виявляється в ситуації, коли вона відповідає за систему, але не контролює повністю ні обсяг, ні джерела змін. Це створює хронічний стрес і спокусу ще більше спрощувати рев’ю, щоб «не бути вузьким місцем».
Фрикція як форма судження: чому «гальма» потрібні саме зараз
Усі ці ефекти — аддиктивний цикл промптів, ілюзія продуктивності, дисбаланс між створенням і рев’ю, розширення кола авторів коду без розширення відповідальності — зводяться до однієї ідеї: тертя в розробці було не лише перешкодою, а й механізмом судження.
Час, який раніше витрачався на те, щоб написати код вручну, читати документацію, обговорювати дизайн, чекати рев’ю, був не просто «втратою швидкості». Це був простір, у якому виникали питання: чи правильно ми це робимо, чи не пропускаємо ми важливий ризик, чи не варто зупинитися й переосмислити підхід.
AI‑інструменти радикально зменшують це тертя. Вони роблять створення коду майже миттєвим, а отже — виносять за дужки багато моментів, де раніше природно включалося людське судження. Якщо не компенсувати це свідомим поверненням «гальм» у процес, команда ризикує опинитися в режимі постійного прискорення без керма.
Йдеться не про відмову від AI, а про визнання його психологічного й організаційного ефекту. Якщо інженери не помічають, як швидкість витісняє розуміння, якщо рев’ю перетворюється на формальність, якщо неінженерні ролі отримують інструменти зміни коду без відповідних процесів контролю, система неминуче стає крихкішою.
Фрикція в цьому контексті — це не зайва бюрократія, а спосіб повернути в процес людське судження: моменти, коли хтось має право й обов’язок сказати «стоп, давайте подумаємо». І чим потужнішими стають AI‑інструменти, тим важливішою стає ця роль.
Висновок: швидкість без меж — це не прогрес, а ризик
AI‑інструменти кодування вже змінили те, як працюють інженери, і продовжать змінювати. Вони справді дають потужний приріст швидкості створення коду й відкривають доступ до розробки для ширшого кола людей. Але разом із цим вони створюють психологічну пастку, у якій швидкість підміняє якість, а відчуття продуктивності — реальне розуміння системи.
Ключові ризики не в тому, що AI «пише поганий код», а в тому, як змінюється поведінка людей і структур команд: зростає тиск «шипити» швидше, посилюється залежність від нескінченного циклу промптів, розширюється коло авторів коду без відповідного розширення відповідальності, а дисбаланс між створенням і рев’ю робить пропуски й rubber stamp рев’ю майже неминучими.
У цій ситуації питання вже не в тому, чи варто використовувати AI, а в тому, як свідомо повернути в процеси розробки необхідну кількість тертя — таких точок, де людське судження не можна обійти. Без цього «фрикціяless» розробка ризикує стати не стільки проривом, скільки шляхом до крихких систем, які ніхто по‑справжньому не розуміє, але за які все одно відповідає невелика група інженерів.
Джерело
The Friction is Your Judgment — Armin Ronacher & Cristina Poncela Cubeiro, Earendil