Редакторська примітка: У січні 2026 року Андрій Карпатій зробив зауваження щодо написання коду Claude, що призвело до виявлення файлу, який здається дрібним, але є надзвичайно важливим у робочому процесі AI-програмування: CLAUDE.md. Пізніше Форрест Чанг структурував ці проблеми у чотири поведінкові правила, намагаючись обмежити типові помилки Claude під час кодування: мовчазні припущення, надмірне ускладнення, ушкодження не пов’язаних з цим кодів та відсутність чітких критеріїв успіху.

Але через кілька місяців сценарії використання Claude Code вже не обмежувалися лише «дозволити моделі написати шматок коду». З того часу, як багатокрокові агенти, підключення ланцюгових тригерів, завантаження навичок та спільна робота з кількома кодовими репозиторіями стали нормою, з’явилися нові моделі невдач: модель втрачає контроль під час довгих завдань, тести проходять, але реальна логіка не перевіряється, міграція завершена, але помилки пропускаються мовчки, різні стилі коду неправильно поєднуються.

Автор цієї статті протестував 30 репозиторіїв протягом 6 тижнів і додав 8 нових правил до початкових 4 правил Карпаті, щоб охопити нові проблеми, що виникли після переходу від одноразового доповнення коду до агентної співпраці в AI-програмуванні.

Нижче наведено оригінал:

Кінець січня 2026 року Андрій Карпатій опублікував серію твітів, у яких критикував спосіб, яким Claude пише код. Він вказав на три типові проблеми: робота з помилковими припущеннями без пояснень, надмірне ускладнення та незв’язне пошкодження коду, який не мав підлягати змінам.

Форрест Чан побачив цей тред і зібрав скарги у 4 правила поведінки, які він записав у окремий файл CLAUDE.md та опублікував на GitHub. Цей проект отримав 5 828 зірок в перший день запуску, за два тижні його зберегли 60 000 разів, а зараз у нього 120 000 зірок — він став найшвидшо зростаючою однofайловим репозиторієм 2026 року.

Потім я протестував його на 30 репозиторіях протягом 6 тижнів.

Ці 4 правила дійсно працюють. Помилки, які раніше виникали приблизно в 40% випадків, у завданнях, де ці правила застосовуються, знизилися до менше ніж 3%. Але проблема в тому, що цей шаблон спочатку був створений для вирішення помилок, які Claude допускав під час написання коду в січні.

До травня 2026 року проблеми в екосистемі Claude Code змінилися: конфлікти між агентами, ланцюгове спрацьовування хуків, конфлікти завантаження навичок та перерви в багатокрокових робочих процесах між сесіями.

Отже, я додав ще 8 правил. Ось повна версія з 12 правилами CLAUDE.md: чому кожне з них варто додавати, а також у яких 4 місцях оригінальний шаблон Karpathy тихо перестає працювати.

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

Чому це важливо

Файл CLAUDE.md в Claude Code — це найбільш недооцінений файл у всьому стеку AI-програмування. Більшість розробників зазвичай допускають три типи помилок:

По-перше, перетворіть його на сміттєвий кошик для переваг, заповніть його всіма своїми звичками, і він розростеться до 4000+ токенів, а рівень дотримання правил впаде до 30%.

Друге, повністю не використовувати й кожен раз вводити новий запит. Це призведе до витрати в 5 разів більше токенів і відсутності послідовності між різними сеансами.

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

Офіційна документація Anthropic чітко зазначає: CLAUDE.md є лише рекомендаційним. Claude дотримується його приблизно 80% часу. Після 200 рядків частота дотримання значно знижується, оскільки важливі правила заглушаються шумом.

Шаблон Карпатського вирішує цю проблему: один файл, 65 рядків, 4 правила. Це мінімальний стандарт.

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

Оригінальні 4 правила

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

Правило 1: Спочатку подумайте, перш ніж кодувати.

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

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

Правило 3: Хірургічні зміни.
Змініть лише те, що обов’язково треба змінити. Не «оптимізуйте» сусідній код, коментарі чи форматування. Не рефакторіть те, що не зламане. Зберігайте єдиний стиль.

Правило 4: Виконуйте з орієнтацією на ціль.
Спочатку визначте критерії успіху, а потім ітеруйте, доки не буде виконано перевірку. Не кажіть Claude, як діяти на кожному кроці, а просто поясніть, яким має бути результат успіху, і дайте йому самому ітерувати.

Ці 4 правила можуть вирішити близько 40% невдач, які я бачу у сесіях Claude Code без нагляду. Решта приблизно 60% проблем приховані в цих порожніх місцях.

Я додав 8 нових правил і пояснив, чому

Кожне правило походить з реального моменту: початкові 4 правила Карпаті не достатні. Нижче я спочатку розповім про цей сценарій, а потім наведу відповідне правило.

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

Той момент був таким: існував код, який викликав Claude, щоб «визначити, чи варто повторювати запит при отриманні 503». Спочатку він добре працював протягом двох тижнів, а потім раптово став нестабільним, оскільки модель почала включати тіло запиту до контексту для визначення. Стратегія повторних спроб стала випадковою, бо сам prompt був випадковим.

CLAUDE.md без обмежень бюджету — це як порожній чек. Кожен цикл може вийти з-під контролю і перетворитися на виливання контексту в 50 000 токенів. Модель сама не зупиниться.

Той момент був таким: сеанс налагодження тривав 90 хвилин. Модель постійно ітерувала навколо одного й того ж 8 КБ повідомлення про помилку і поступово забувала, які вирішення вже пробувала. У кінці вона почала пропонувати рішення, які я вже відхилив 40 повідомлень тому. Якби був ліміт на токени, цей процес мав бути зупинений на 12-й хвилині.

Коли дві частини кодового базу суперечать одна одній, Claude намагається одночасно задовольнити обидві сторони, в результаті чого отримується незв’язний код.

Той момент був таким: у репозиторії коду існували дві моделі обробки помилок — одна з async/await та явними try/catch, інша — глобальні межі помилок. Новий код, написаний Claude, використовував обидві. У результаті обробка помилок виконувалася двічі. Мені знадобилося 30 хвилин, щоб зрозуміти, чому помилки двічі «з’їдалися».

«Хірургічна зміна» Карпатського навчає Claude не змінювати сусідній код. Але вона не навчає Claude: спочатку зрозуміти сусідній код. Без цього Claude може написати новий код, який суперечить існуючому коду на відстані 30 рядків.

Той момент був таким: Claude додав функцію, яка була повністю ідентична існуючій, оскільки не прочитав початкову функцію. Обидві функції виконували одне й те саме. Але через порядок імпорту нова функція перевизначила стару, яка протягом 6 місяців була єдиним фактичним стандартом.

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

Той момент був таким: Claude написав 12 тестів для функції автентифікації, і всі вони пройшли. Але логіка автентифікації у виробничому середовищі була зламана. Ці тести перевіряли лише те, що функція «повернула щось», а не те, чи повернула вона правильну річ. Функція проходила тести, бо повертала константу.

Шаблон Карпатського за замовчуванням передбачає одноразову взаємодію. Але реальна робота з Claude Code зазвичай багатокрокова: рефакторинг через 20 файлів, створення функціоналу в одному сеансі, налагодження через кілька комітів. Без точок збереження один помилковий крок може призвести до втрати всього попереднього прогресу.

Той момент був таким: завдання з 6 кроків зазнало помилки на 4-му кроці. Коли я це виявив, Claude вже продовжив і виконав 5-й і 6-й кроки, базуючись на помилковому стані. Час, витрачений на розбирання та виправлення, був довший, ніж час, необхідний для повного перезапуску завдання. Якби були контрольні точки, проблему можна було б виявити вже на 4-му кроці.

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

Той момент був таким: Claude ввів hooks у кодову базу React, яка базувалася на class component. Він працював, але зламав існуючі тести, оскільки вони залежали від componentDidMount. Зрештою, на видалення та переписування витратили півдня.

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

Той момент був таким: Claude сказав, що міграція бази даних «успішно завершена». Але насправді вона тихо пропустила 14% записів, що викликали конфлікти з тригерними обмеженнями. Поведінка пропуску була записана у лог, але не була явно виявлена. Лише через 11 днів, коли дані звітів почали виявляти аномалії, ми виявили проблему.

Протягом 6 тижнів я відстежував одну й ту саму групу з 50代表性 завдань, що охоплюють 30 репозиторіїв, тестируючи три конфігурації.

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

Ступінь дотримання — це ймовірність, з якою Claude явно застосовує правило, коли воно застосовне.

Справжній інтерес полягає не лише в тому, що частота помилок знизилася з 41% до 3%. Ще важливіше те, що при розширенні з 4 правил до 12 правил навантаження на дотримання майже не зросло — показник дотримання змінився лише з 78% на 76%, а частота помилок знизилася ще на 8 відсоткових пунктів. Нові правила охоплюють типи невдач, які не враховувалися в оригінальних 4 правилах, і не конкурують за той самий бюджет уваги.

Де саме шаблон Карпатського може тихо втрачати ефективність

Навіть без додавання нових правил, оригінальні 4 шаблони правил принаймні в 4 місцях є недостатніми.

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

Друге, узгодженість між кількома репозиторіями.
«Підігнання під існуючий стиль» за замовчуванням передбачає лише один стиль. Але в монорепозиторії з 12 сервісами Claude повинен вибрати, під який саме стиль підігнання. Початкові правила не пояснюють йому, як вибирати. Тому він або вибирає випадково, або змішує кілька стилів у рівних пропорціях.

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

Четверте, різниця між виробничим середовищем та етапом прототипу.
Ті самі 4 правила можуть запобігти надмірному ускладненню виробничого коду, але також можуть уповільнити розробку прототипів, оскільки на етапі прототипування іноді дійсно потрібні 100 рядків експериментального каркасу, щоб спочатку зрозуміти напрямок. Підхід Karpathy «простота перш за все» легко надмірно активується у ранніх кодах.

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

Які методи не спрацювали

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

Дотримуйтесь правил, які я бачив у Reddit / X.
Більшість з них або просто повторювали оригінальні 4 правила Карпаті з іншою формулюванням, або були спеціалізованими правилами, що не узагальнюються, наприклад «завжди використовуйте класи Tailwind». Всі вони були видалені.

Більше 12 правил.
Я протестував максимум 18 пунктів. Після 14 пунктів відповідність впала з 76% до 52%. Ліміт у 200 рядків є реальним. Після цього обсягу Claude починає виконувати патерн-мачинг, вважаючи «тут є правила», а не читаючи правила по черзі.

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

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

Будьте обережні, уважно подумайте, зосередьтесь.
Це всі шум. Дотримання таких інструкцій впало приблизно до 30%, оскільки їх не можна перевірити. Пізніше я замінив їх на більш конкретні наказові правила, наприклад, «чітко вказувати припущення».

Скажіть Claude, щоб він діяв як «досвідчений інженер».
Це не має сенсу. Claude і так вважає себе досвідченим інженером. Справжня проблема не в тому, чи вважає він це так, а в тому, чи діє він саме так. Імперативні правила можуть зменшити цю різницю, але підказки про ідентичність — ні.

Повна версія з 12 правилами CLAUDE.md

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

Цей контент неможливо відобразити поза межами документів Feishu

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

Як встановити

Дві прості кроки:

1. Додайте чотири базові правила Карпатського до вашого файлу CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. Вставте правила 5–12 з цієї статті нижче

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

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

Кожне правило повинно відповідати на питання: що воно запобігає?

Чотири правила Карпаті, що захищають від моделей невдач, які він побачив у січні 2026 року: мовчазні припущення, надмірне інженерування, нерелевантне зрушення, слабкі критерії успіху. Це основи, не пропускайте їх.

Мої 8 нових правил захищають від нових типів невдач, що виникнуть після травня 2026 року: цикли агентів без обмежень бюджету, багатокрокові завдання без контрольних точок, тести, які здаються такими, що перевіряють, але насправді не перевіряють ключову логіку, а також приховування тихого невдачі під виглядом тихого успіху. Це інкрементні виправлення.

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

Версія CLAUDE.md з 6 правилами, розробленими під реальні моделі невдач, краща, ніж версія з 12 правилами, з яких 6 ви ніколи не використовуватимете.

Заключення

Твіт Карпатського від січня 2026 року був суттєво скаргою. Форрест Чанг перетворив його на 4 правила. У підсумку 120 000 розробників поставили цьому результату зірочку. І більшість з них сьогодні все ще використовують лише ці 4 правила.

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

Додано 8 нових правил. 6 тижнів, охоплено 30 репозиторіїв. Похибка знизилася з 41% до 3%.

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