AI робить вас тупішим? Ось як цього уникнути

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Кілька тижнів тому мені трапився пост розробника, який протягом шести місяців працював одночасно з п’ятьма-шістьма терміналами Claude Code. Його опис цього досвіду був кумедним, але водночас тривожно знайомим: більшість часу він просто чекав, поки агенти завершать роботу, і натискав Enter.

Його висновок був прямолінійним: «Claude Code плавить мені мозок».

Останнім часом я дедалі частіше бачу різні варіації цієї самої думки. Розробники, які активно використовують AI, починають замислюватися: а чи не стають вони самі слабшими як спеціалісти через те, що машина бере на себе надто велику частину безпосереднього написання коду?

Паралельно в дискусіях про AI-assisted development почав з’являтися ще один термін — comprehension debt, або, умовно, борг розуміння.

На мою думку, він дуже точно описує проблему.

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

Продукт продовжує рухатися вперед, а ваше розуміння системи дедалі сильніше відстає.

У результаті можна опинитися в доволі дивній ситуації: формально ви відповідаєте за систему, володієте нею як інженер, але вже не до кінця розумієте, що відбувається всередині.

На перший погляд, це дві різні проблеми: AI нібито робить розробників «тупішими», а паралельно породжує борг розуміння. Але мені здається, що це здебільшого одна й та сама проблема, просто з двох різних боків.

І що важливіше — я думаю, що для обох існує одне й те саме рішення.

Проблема не в AI.

Проблема починається, коли ви юзаєте повністю автоматичний АІ-пайплайн

Зараз у software engineering відбувається доволі дивне змагання за продуктивність. Майже щотижня я бачу чергову вражаючу цифру: сотні тисяч згенерованих рядків коду, тисячі комітів, десятки агентів, що працюють паралельно, тисячі pull request’ів, створених AI-пайплайнами.

Uber, наприклад, публічно розповідала про внутрішню AI-систему для розробки, яка генерує приблизно 1 800 пул реквестів на тиждень. Це 1 пул реквест кожні 80 секунд.

Це, безумовно, вражаючий показник. Але щоразу, коли я бачу подібні метрики, у мене виникає трохи незручне запитання:

А що саме ми тут оптимізуємо?

Пул реквест — це одиниця доставки змін у коді. Але це не одиниця цінності продукту.

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

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

Уявімо, що хтось каже вам: його AI-воркфлоу здатний створити тисячу PR за відносно короткий проміжок часу. Добре. Тоді поставимо інше запитання: чи можете ви прямо зараз назвати наступну справді важливу фічу, яка потрібна вашому продукту?

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

І це вже набагато складніше. Тим паче з темпом 1 фіча за 80 секунд

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

У якийсь момент досить означає досить.

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

І саме тут, на мою думку, повністю автоматична АІ-розробка стає небезпечною. Не обов’язково тому, що AI пише поганий код, а тому, що розвиток кодової бази стає швидшим за розвиток її розуміння.

Саме тут і починає накопичуватися борг розуміння.

Мій підхід:

Semi-Automatic AI-Native Development with human in the loop

Workflow, який я використовую, має навмисно трохи громіздку назву: Semi-Automatic AI-Native Development with Human in the Loop.

Ширше я описував цей підхід в іншій статті, тому не буду повторювати все тут. Для цієї розмови важлива саме частина Human in the Loop.

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

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

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

І є одна річ, якій я приділяю особливо багато уваги:

СЕМАНТИКА.

Що насправді означає ця сутність? Хто володіє цим станом? Де повинна відбуватися ця трансформація? За що відповідає конкретний модуль? Що ця абстракція означає з точки зору домену? Які поняття справді різні, а які лише названі по-різному?

Це не косметика і не питання форматування коду. Це архітектура.

Коли ці рамки визначені, AI може робити те, в чому він надзвичайно сильний: дуже швидко виконувати роботу всередині заданої системи.

Нещодавно мені трапився пост Роберта Мартіна — Uncle Bob — де він описував підхід, напрочуд схожий на цю філософію.

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

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

Ви задаєте умови. Ви визначаєте архітектуру. Ви формулюєте семантику. А потім дозволяєте машині рухатися дуже швидко всередині цієї системи.

Чому я все одно перевіряю код

Коли люди говорять, що AI-код потрібно перевіряти, стандартне пояснення пов’язане з безпекою: AI може галюцинувати, неправильно зрозуміти вимогу, створити секʼюрну багу або просто написати неправильний код.

Усе це правда.

Але для мене є ще одна причина, яка щонайменше не менш важлива:

Згенерований код — це відгук на архітектуру, яку я спроєктував.

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

Потім AI на високій швидкості реалізує функціональність — і ця гіпотеза стикається з реальністю.

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

Це не просто проблеми реалізації.

Це сигнали.

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

І це створює надзвичайно потужний цикл навчання.

AI може змусити вас вчитися швидше, а не повільніше

Мені здається, саме цій частині AI-assisted development приділяють значно менше уваги, ніж вона заслуговує.

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

AI здатний стиснути величезну частину цього часу.

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

Мій воркфлоу дедалі більше виглядає приблизно так:

Спроєктувати → задати рамки → дати AI реалізувати → перевірити → навчитися → скоригувати дизайн.

Потім приходить нова вимога — і цикл повторюється.

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

Тобто AI прискорює не лише імплементацію.

Використаний таким чином, він прискорює architecture-feedback loop.

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

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

І це вже майже повна протилежність твердженню, що «AI плавить вам мозок».

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

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

AI дедалі більше знає про вашу кодову базу.

А ви — дедалі менше.

Я, мабуть, не згенерую 1 800 PR за тиждень. І це нормально

Semi-automatic workflow with human in the loop, очевидно, буде повільнішим за підхід, де ви просто наказуєте цілому рою агентів змінювати репозиторій якомога швидше.

Мене це абсолютно не турбує.

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

Подальше збільшення швидкості розробки після цієї точки має дедалі меншу цінність.

Мета розробки — не максимізувати кількість створеного софту.

Мета — вирішувати корисні проблеми за його допомогою.

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

Тому так — перевіряйте код. У ньому можуть бути баги. AI може неправильно зрозуміти вимоги. Усе це чудові причини.

Але перевіряйте його ще з однієї причини.

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

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

Є одна фраза з недавнього поста Дядька Боба, яка, на мою думку, підсумовує всю цю відповідальність краще, ніж будь-що, що я міг би додати:

У цьому, власне, і суть.

Ви інженер не тому, що особисто надрукували кожен рядок коду. Не тому, що можете пояснити кожне натискання клавіші, завдяки якому з’явився репозиторій. І точно не тому, що ваш AI згенерував більше пул реквестів, ніж AI когось іншого.

Ви інженер тому, що несете відповідальність за систему, яку будуєте.