Як не припиняти вчитися, поки Claude Code пише за вас код

Уявіть розробника, який опанував PHP за 5 років до появи AI-асистентів. Одна забута крапка з комою могла забрати кілька хвилин, а то й цілий день на пошуки того самого хибного рядка. Динамічний сайт робився тижнями: проєктування схеми, структура коду, планування всього проєкту наперед. Кожен етап приносив задоволення, від планування до збирання, і винагорода була справжньою. Ти зробив щось власними руками після боротьби й вийшов із неї, знаючи більше, ніж на початку.

Тепер порівняйте це з сьогоденням. У 2025 році з'явився Claude Code, і розробники почали віддавати йому дедалі більше щоденної роботи. Через рік багато хто майже не відкриває Stack Overflow, рідше малює на дошці чи папері перед проєктуванням фічі й менше розмовляє з колегами, бо більша частина спілкування тепер відбувається з Claude. Швидкість справжня, і ніхто, хто її скуштував, не хоче від неї відмовлятися. Але вона має ціну. Зникає великий шматок класичного процесу — того, що непомітно перетворює джунів на сеньйорів.

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

Що кажуть дослідження

Anthropic, компанія, що стоїть за Claude Code, опублікувала дослідження про те, як допомога AI впливає на формування навичок програмування. Воно вказує на парадокс: зростання продуктивності завдяки AI може супроводжуватися повільнішим розвитком навичок, особливо в новачків. Висновок збігається з тим, що багато розробників відчувають інтуїтивно. Розумове зусилля, зокрема періоди, коли ти застряг, і далі потрібне, якщо хочеш щось по-справжньому опанувати.

Тож питання в тому, як не припиняти вчитися, коли все робить Claude Code.

Тертя, яке ми втратили

Почнімо з того, до чого змушував старий процес:

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

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

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

Хай інструмент навчає

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

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

Типові запитання виглядають так:

• Чому ця функція поводиться саме так?
• Що станеться, якщо цей виклик впаде?
• Чи потрібен цей рядок?
• Можете дописати цю функцію?
• Чому ця архітектура, а не інша?

Мета проста: хай Claude робить свою роботу, а ви не припиняєте вчитися й заразом стежите за тим, що він виробляє.

Як може працювати навчальний режим

Це можна зібрати як skill для Claude Code плюс кілька хуків. Встановіть один раз, і він буде доступний на вашій машині в кожній сесії. Після зміни Claude дивиться на diff, обирає цікаве місце в коді й просить вас його пояснити. Запитання може виглядати так:

🎓 Learner — src/auth/session.ts
You modified `refreshSession()` to delete the old session line before inserting the new one.
Why use this order rather than “insert then delete,” and what does a caller see if the insert fails after the delete has been committed?

Claude питає й повертається до своєї справи. Якщо ви відповісте skip, він іде далі, не наполягаючи.

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

learner_synthesis_n() {
  case "${1:-}" in
    off)   printf '0' ;;
    rare)  printf '8' ;;
    often) printf '2' ;;
    # LEARNER-TODO Complete this part of code
    *)     printf '4' ;;
  esac
}

Потім Claude просить вас заповнити пропуск і чекає. Він не допише код за вас, доки ви не визнаєте, що не знаєте як, або не наберете skip.

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

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

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

Коли код пишете ви самі

Усе це передбачає, що код пише Claude. А якщо ні? Навіть з усім, що вміє Claude Code, ви можете не хотіти, щоб він писав кожен рядок. Іноді хочеться набрати код самому — не тому, що так швидше чи Claude не впорався б, а тому, що писати рядки і є способом учитися.

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

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