DTGaraGe | Автомобили, Офроуд, Заваряване, Linux, AI

Регистрирайте безплатен акаунт днес, за да станете член! След като влезете, ще можете да участвате в този сайт, като добавяте свои собствени теми и публикации, както и да се свързвате с други членове чрез вашата лична пощенска кутия!

Експертен Поглед Claude Code без хаос - как CLAUDE.md, hooks и MCP го превръщат в дисциплиниран инженер

🛠️ Как укротих Claude Code и го превърнах от приказлив помощник в дисциплиниран инженер

claude_code_banner.png



Един 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 моделът много по-често нарушава стил, конвенции и граници. С добре написан файл поведението става значително по-предсказуемо.



🤖 Не ти трябва армия от агенти. Трябват ти 2-3 точни роли.

Официалните docs за Claude Code показват, че системата вече работи със subagents - включително вградени роли като Explore, Plan и general-purpose, а също позволява и custom subagents за конкретни задачи. Идеята е проста, но мощна: вместо един и същ контекст да се влачи като препълнен багажник навсякъде, разделяш работата по роли и отговорности.

Skills са отделен слой - допълнителни инструкции и slash commands, описани чрез SKILL.md, които Claude може да зарежда автоматично.

Тук много хора правят класическата грешка на ентусиаста - виждат сто възможности и искат да включат сто възможности. После се чудят защо всичко е тежко, шумно и неясно. Реалният ход е друг - започваш с малко:

  • един subagent за проучване на кодовата база
  • един subagent за планиране
  • един skill за review или testing

Не ти трябва AI армия. Трябва ти малък отряд, който знае кой мисли, кой проверява и кой не пипа излишно.



⚙️ Истинският контрол не идва от „моля те“, а от hooks

Тук е разликата между молба и система. Официалната документация за hooks казва нещо много важно - те дават deterministic control. Тоест не разчиташ моделът да „се сети“ да направи правилното нещо, а конфигурираш автоматично поведение в определени моменти от жизнения цикъл.

Hooks могат да налагат проектни правила, да автоматизират повтарящи се действия и да интегрират Claude Code с останалите инструменти. На човешки език - вместо да повтаряш едни и същи инструкции всеки път, правиш системата така, че определени проверки и действия да се случват по подразбиране.

Това вече е друго ниво. Не говорим за „добър prompt“. Говорим за дисциплина на ниво процес. AI-то не е по-мъдро. Просто е вкарано в релси.



🔌 Когато ти писне да copy-paste-ваш между инструменти, включваш MCP

Голямата спирачка в реалната работа е, че хората ползват AI сякаш е отделен остров. Четат issue в една система, логове в друга, мониторинг в трета - и накрая копират всичко ръчно в чата.

Claude Code поддържа MCP (Model Context Protocol), а официалната документация го описва като начин да вържеш външни инструменти, бази и API-та, така че Claude да работи директно с тях. Това е мястото, където AI спира да бъде „умен тефтер“ и започва да се държи като помощник с достъп до реалната работна среда.

Тук се отваря истинската автоматизация. Не онази от постовете в X, където всички магически печелят пари, докато спят, а нормалната, човешката и полезната - по-малко ръчно прехвърляне, по-малко загуба на контекст, по-малко повторение.



📦 Големите community пакети са полезни. Но не са свещени.

Има огромни 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 ще ти даде по-малко безсмислени цикли, ако първо му дадеш правила.“



🚀 Как бих започнал тази вечер, без цирк и без театър

  1. CLAUDE.md - кратък, остър. Архитектурни ограничения, naming conventions, какво не се пипа, кога се пишат тестове, кога се иска план преди промяна. Не роман. Кодекс.
  2. Един skill - за review или test-first работа.
  3. Един subagent - за проучване на кодовата база.
  4. Един hook - за нещо досадно, но важно.
  5. MCP connector - при нужда, към issue tracker или друг външен източник.
  6. Чак когато това работи спокойно, мислиш за по-сложни вериги.

Точно така се строи нещо здраво. Не с 200 промпта и шамански ритуали, а с малко на брой, но добре подредени правила.



Финалът е прост

Claude Code не става полезен, когато му позволиш всичко.
Става полезен, когато му забраниш глупостите.

Не ти трябва AI, който звучи впечатляващо.
Трябва ти AI, който не пипа излишно, не драматизира простите задачи и не превръща всеки bugfix в дипломна работа.

Това е разликата между играчка и инструмент.
И точно там започва истинската полза.


🖋️ Автор: Тони Ангелчовски | Ексклузивно за DTGaraGe
🔒 Копирането и препубликуването без разрешение не е позволено
☕ Подкрепи проекта: https://dtgarage.eu/forums/donate/
 
Допълнение към темата:

Най-голямата грешка при работа с Claude Code не е, че хората го ползват. Грешката е, че го пускат без правила и после се сърдят на резултата.

Ако трябва да го кажа съвсем просто - един добър CLAUDE.md често е по-ценен от десет шумни промпта.

Преди да мислите за сложни агенти, тежки автоматизации и "магически" workflow-и, оправете основата:
  • какво не се пипа
  • какви са конвенциите
  • кога се иска план
  • кога се пишат тестове
  • какво се счита за завършена задача

Точно там е разликата между AI, който помага, и AI, който се прави на архитект на вселената.

Много хора искат повече мощ.
Аз бих казал друго - първо си осигури повече ред.

Тогава и мощта идва на мястото си.
 
Точно така.
CLAUDE.md е като чертежа преди рязане. Без него – всеки реже както си знае и после чудесата са само по снимки.

Хаосът не идва от AI-то.
Хаосът идва от липса на граници.

Колкото по-ясни са линиите – толкова по-малко „чудеса“ накрая има за оправяне.
Първо се прави рамка. После се пуска мощност.

Не ти трябва още един „архитект на вселената“.
Трябва ти точен майстор, който знае докъде да пипа.
Останалото е само шум.
 
Top Bottom
🛡️ Този сайт използва аналитични инструменти за подобряване на потребителското изживяване. Никакви лични данни не се събират. С продължаването си в Потока приемаш тази философия на прозрачност и уважение.