
Един CLAUDE.md, няколко точни правила и малко желязна дисциплина могат да спестят часове хаос, излишни промени и умно звучаща, но ненужна сложност
Claude Code вече не е просто чат, който хвърля идеи в терминала. По официална документация това е инструмент за програмиране с агентно поведение - чете кодовата база, редактира файлове, пуска команди и се връзва с външни инструменти и среди. И точно тук започва проблемът - когато един инструмент може много, хората започват да му поверяват всичко, без да му дадат характер, правила и граници. После се чудят защо AI-то се държи като самоуверен стажант с достъп до целия склад.
Проблемът не е, че моделът е глупав. Проблемът е, че е пуснат без кодекс.
Това е голямото недоразумение в много AI работни процеси. Хората мислят, че им трябва „по-умен модел“, а всъщност често им трябва по-добра рамка. В Claude Code тази рамка има име - CLAUDE.md. Официалната документация го описва като част от проектната памет - файл с проектни инструкции, конвенции и контекст, които се зареждат в началото на сесиите. Важният детайл е още по-интересен - това не е твърдо наложена конфигурация, а контекст. Тоест колкото по-ясно и кратко формулираш правилата, толкова по-последователно ще ги следва.
И тук идва моментът, който мнозина пропускат. AI не ти троши проекта, защото „има лош ден“. Троши го, защото не си му казал достатъчно ясно какво е свещено и какво не се пипа. При липса на правила моделът запълва празнините с догадки. А догадките в кодов проект миришат на over-engineering, излишни зависимости и героични „подобрения“, които никой не е поискал.
Около Claude Code вече се оформи силна практика в общността - вместо дълги романи в инструкциите, да се използват няколко ясни принципа. Един от най-полезните примери е forrestchang/andrej-karpathy-skills - единичен CLAUDE.md файл, изграден около наблюденията на Andrej Karpathy за типичните грешки на LLM-ите при писане на код. Идеята не е магия, а дисциплина.
Code:
Think Before Coding -> мисли преди да пипаш код
Simplicity First -> избирай най-простото работещо решение
Surgical Changes -> променяй само това, което е поискано
Goal-Driven Execution -> работи по ясни критерии за успех
Това може да звучи елементарно, но точно тук е силата. AI моделите не страдат толкова от липса на интелект, колкото от липса на ограничения. И когато няма ограничения, започват фойерверките - излишни refactor-и, нови слоеве без причина, смяна на установени конвенции и пипане на код, който никой не е искал да бъде пипан.
Това е същото като в сервиза. Добър майстор не разглобява половината кола, защото един тампон е изпял последната си песен. Първо гледа симптома. После пътя до причината. После пипа точно където трябва. С модела е същото - кажеш ли му „оправи това“ без граници, той започва да строи катедрала, когато на теб ти трябва врата на гараж.
Code:
# Команда за автоматично генериране на CLAUDE.md
claude -p "Read the entire project and create a CLAUDE.md based on:
Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution.
Adapt to the real architecture you see." --allowedTools Bash,Write,Read
В практиката разликата е осезаема - без ясен CLAUDE.md моделът много по-често нарушава стил, конвенции и граници. С добре написан файл поведението става значително по-предсказуемо.
Официалните docs за Claude Code показват, че системата вече работи със subagents - включително вградени роли като Explore, Plan и general-purpose, а също позволява и custom subagents за конкретни задачи. Идеята е проста, но мощна: вместо един и същ контекст да се влачи като препълнен багажник навсякъде, разделяш работата по роли и отговорности.
Skills са отделен слой - допълнителни инструкции и slash commands, описани чрез SKILL.md, които Claude може да зарежда автоматично.
Тук много хора правят класическата грешка на ентусиаста - виждат сто възможности и искат да включат сто възможности. После се чудят защо всичко е тежко, шумно и неясно. Реалният ход е друг - започваш с малко:
- един subagent за проучване на кодовата база
- един subagent за планиране
- един skill за review или testing
Не ти трябва AI армия. Трябва ти малък отряд, който знае кой мисли, кой проверява и кой не пипа излишно.
Тук е разликата между молба и система. Официалната документация за hooks казва нещо много важно - те дават deterministic control. Тоест не разчиташ моделът да „се сети“ да направи правилното нещо, а конфигурираш автоматично поведение в определени моменти от жизнения цикъл.
Hooks могат да налагат проектни правила, да автоматизират повтарящи се действия и да интегрират Claude Code с останалите инструменти. На човешки език - вместо да повтаряш едни и същи инструкции всеки път, правиш системата така, че определени проверки и действия да се случват по подразбиране.
Това вече е друго ниво. Не говорим за „добър prompt“. Говорим за дисциплина на ниво процес. AI-то не е по-мъдро. Просто е вкарано в релси.
Голямата спирачка в реалната работа е, че хората ползват AI сякаш е отделен остров. Четат issue в една система, логове в друга, мониторинг в трета - и накрая копират всичко ръчно в чата.
Claude Code поддържа MCP (Model Context Protocol), а официалната документация го описва като начин да вържеш външни инструменти, бази и API-та, така че Claude да работи директно с тях. Това е мястото, където AI спира да бъде „умен тефтер“ и започва да се държи като помощник с достъп до реалната работна среда.
Тук се отваря истинската автоматизация. Не онази от постовете в X, където всички магически печелят пари, докато спят, а нормалната, човешката и полезната - по-малко ръчно прехвърляне, по-малко загуба на контекст, по-малко повторение.
Има огромни community проекти, които опаковат правила, агенти, skills, hooks и цели работни слоеве накуп. affaan-m/everything-claude-code е точно такъв пример - описва се като system/harness за Claude Code и сродни инструменти, с десетки агенти и огромен набор от skills.
Но тук е моментът за студен душ - когато нещо е мощно и популярно, това не значи, че трябва да го глътнеш цяло. В отворените issues на същото repo има съвсем реални проблеми около plugin manifest validation, hooks schema compatibility и Windows-specific счупвания. Тоест - да, полезно е. Не, не е магически безгрешно.
Умният ход е селективно вземане на части, които наистина ти решават проблем. Не инсталираш всичко, само защото свети красиво на GitHub.
Това е същото като с инструментите в работилницата. Че имаш цял шкаф, не значи, че трябва да го хвърлиш върху болта.
Официалните workflow docs на Anthropic са доста по-трезви от шумните нишки в социалките. Те говорят за проучване на кодови бази, debugging, refactoring, писане на тестове, PR-и и управление на сесии. Реалната стойност не е в това да замениш мисленето си, а да преместиш повтарящата се, досадната и поддаваща се на структура част от работата към един по-подреден слой.
Когато към това добавиш monitoring чрез OpenTelemetry, вече можеш не само да ползваш системата, а и да виждаш какво харчи, как работи и къде се задъхва.
Това е голямата разлика между hype и инженерство.
Hype-ът казва: „AI ще ти даде нов живот.“
Инженерството казва: „AI ще ти даде по-малко безсмислени цикли, ако първо му дадеш правила.“
- CLAUDE.md - кратък, остър. Архитектурни ограничения, naming conventions, какво не се пипа, кога се пишат тестове, кога се иска план преди промяна. Не роман. Кодекс.
- Един skill - за review или test-first работа.
- Един subagent - за проучване на кодовата база.
- Един hook - за нещо досадно, но важно.
- MCP connector - при нужда, към issue tracker или друг външен източник.
- Чак когато това работи спокойно, мислиш за по-сложни вериги.
Точно така се строи нещо здраво. Не с 200 промпта и шамански ритуали, а с малко на брой, но добре подредени правила.
Финалът е прост
Claude Code не става полезен, когато му позволиш всичко.
Става полезен, когато му забраниш глупостите.
Не ти трябва AI, който звучи впечатляващо.
Трябва ти AI, който не пипа излишно, не драматизира простите задачи и не превръща всеки bugfix в дипломна работа.
Това е разликата между играчка и инструмент.
И точно там започва истинската полза.
Claude Code не става полезен, когато му позволиш всичко.
Става полезен, когато му забраниш глупостите.
Не ти трябва AI, който звучи впечатляващо.
Трябва ти AI, който не пипа излишно, не драматизира простите задачи и не превръща всеки bugfix в дипломна работа.
Това е разликата между играчка и инструмент.
И точно там започва истинската полза.