ექვსი თვეა Claude Code-ს ვიყენებ როგორც მთავარ coding აგენტს ორ production codebase-ში — ერთი .NET, მეორე TypeScript. საკმარისი დრო, რომ მივხვდე რა მუშაობს, რა არის მარკეტინგი, და რა აყენებენ გუნდების უმეტესობას არასწორად. აი გულახდილი ანალიზი.
ეს არ არის ტუტორიალი. ეს არის პოსტი, რომელიც პირველ დღეს მინდოდა მიმეღო.
მთავარი შეცდომა
ინჟინრების უმეტესობა Claude Code-ს ჭკვიან ChatGPT-სავით ექცევა — გახსნიან, თხოვენ „გაასწორე bug user.service.ts-ში”, paste-ენ, აფასებენ ინსტრუმენტს ამ ერთი პასუხის ხარისხით.
Claude Code ასე არ მუშაობს. ეს არის agent loop tools-ით, hooks-ით და persistent project memory-ით. მისი chat ფანჯრად მოპყრობა ჰგავს Tesla-ს ყიდვას მის რადიოდ გამოყენებისთვის. იღებთ 5% ღირებულებას.
ინჟინრები, რომლებიც ყველაზე მეტ ღირებულებას იღებენ, ოთხი კონკრეტული რამ გააკეთეს:
- დაწერეს
CLAUDE.mdფაილი, რომელიც აღწერს რა არის პროექტი რეალურად - დაამატეს pre/post-tool hooks-ი, რომლებიც ავტომატურად ხვევენ lint-ს და ტესტებს
- დააკონფიგურირეს
settings.jsonallowlist, რომ permission prompts-ის მიღება შეწყვიტონ - დაამატეს 1–2 MCP სერვერი მათ რეალურ სისტემებთან (DB, issue tracker)
ამის გარეშე იყენებთ $20/თვე ინსტრუმენტს $2 სამუშაოს გასაკეთებლად.
რაში არის მართლა კარგი
ექვსი თვის შემდეგ, workflows, სადაც სტაბილურად დაზოგავს რეალურ დროს, უფრო ვიწროა ვიდრე მარკეტინგი ვარაუდობს, მაგრამ მნიშვნელოვანი:
Multi-file refactors გასაგები ფორმით. „გადაარქვი getUserById findUserById-ად ყველგან, განაახლე ტესტები და გადაიტანე ფაილი services/-დან repositories/-ში.” ასეთი მექანიკური ცვლილებები პროგნოზირებადი საზღვრებით — სადაც აგენტი ბრწყინავს. 30 წამში აკეთებს იმას, რასაც მე 15 წუთი ფრთხილი მუშაობა მჭირდება.
კოდის კითხვა, რომელიც მე არ მიწერია. როდესაც onboard ვხდები კოდბაზაზე ან debug ვაკეთებ რაღაც სერვისს, რომელიც 8 თვეა არ მიხილავს, Claude Code-ს „აუხსენი data flow ამ controller-დან DB-მდე” თხოვნა უფრო სწრაფი და საიმედოა, ვიდრე კოდის ზემოდან ქვემოთ წაკითხვა. მთავარია — ის რეალურ კოდზე ლაპარაკობს, არა დოკუმენტაციაზე, რომელიც სამი რელიზით ჩამორჩება.
ტესტების scaffolding. „დაწერე integration ტესტები ამ endpoint-ისთვის: happy path, 404, 401, duplicate-email.” 80%-ით სწორ ტესტებს ვიღებ; ბოლო 20%-ს ვასწორებ. შედეგი: მეტ ტესტს ვწერ, ვიდრე ამის გარეშე. ეს მარტო ღირებულებას ამართლებს.
One-shot სკრიპტები. Migrations, log parsers, cleanup utilities. რასაც 20 წუთში დავწერდი და ერთხელ გამოვიყენებდი. აგენტი 2 წუთში წერს; მე 1 წუთში ვკითხულობ.
რაში არის ჩუმად ცუდი
თანაბრად მნიშვნელოვანი — და იშვიათად განხილული:
ყველაფერი, რაც გემოვნებას მოითხოვს. სახელები, API დიზაინი, გადაწყვეტილებები რა აბსტრაგიროთ. აგენტი მოგცემთ რაიმე მუშა, მაგრამ თითქმის ყოველთვის ერთი დონით უარესს, ვიდრე senior ინჟინერი დაწერდა. შევწყვიტე ამის დელეგირება.
Long-horizon სამუშაო checkpoints-ის გარეშე. „ააშენე ეს feature end-to-end” ნაწილებად დაყოფის გარეშე ქმნის გავრცელებას. აგენტი შექმნის ფაილებს, რომლებსაც არ ითხოვდით, აბსტრაქციებს, რომლებიც არ გინდათ, და feature flags-ს ჰიპოთეტური მომავალი შემთხვევებისთვის. Plan mode არის ანტიდოტი (ამაზე ქვემოთ).
ნებისმიერი რამ ბუნდოვანი წარმატების კრიტერიუმით. „გახადე უფრო სწრაფი” baseline მეტრიკის ან კონკრეტული bottleneck-ის გარეშე — რეცეპტი ცვლილებებისთვის, რომელთა შეფასება შეუძლებელია. ჯერ მეტრიკა დააფიქსირეთ.
Production debugging observability-ის გარეშე. მას შეუძლია ლოგებისა და stack traces-ის წაკითხვა, მაგრამ ვერ ხედავს თქვენს Datadog dashboards ან distributed traces. თუ თქვენი „bug” მოითხოვს იმის გაგებას, რა მოხდა production-ში, აგენტი არის junior ინჟინერი, რომელიც გამოიცნობს — სასარგებლოა მხოლოდ მას შემდეგ, რაც თქვენ შეავიწროვებთ.
კონფიგურაციები, რომლებიც ცვლიან მაჩვენებელს
თუ უნდა მე-onboard ვაქცევდი ჩემი თანამშრომელი Claude Code-ზე 30 წუთში, აი რას დავაკონფიგურირებდი მათთვის:
1. რეალური CLAUDE.md
არა სამი ხაზი. რეალური. რას აკეთებს პროექტი, არქიტექტურული გადაწყვეტილებები, არააშკარა გასაცემი წერტილები, ტესტირების კონვენცია, რას არ უნდა შეეხოთ. ჩემი .NET პროექტისთვის 90 ხაზია და ადვილად დაზოგავს „კონტექსტის ახსნის” დროის 50%-ს სესიებს შორის.
2. Hooks lint-ისა და ტესტებისთვის
PostToolUse:Edit hook, რომელიც აწარმოებს linter-ს შეცვლილ ფაილზე. Stop hook, რომელიც აწარმოებს unit ტესტებს მოდულზე. აგენტი იღებს მყისიერ უკუკავშირს, თუ მისმა ცვლილებამ რამე გატეხა, და თქვენ წყვეტთ მის ძიძობას.
3. რეალური allowlist settings.json-ში
By default აგენტი ითხოვს ნებართვას ყოველი shell ბრძანებისთვის. ორ დღეში მოგიწევთ ერთი და იგივე 20 ბრძანების მუდმივი დადასტურება. Allowlist-ში ჩასვით read-only-ები (git status, npm test, dotnet build, gh pr view) და inner-loop-ები. დესტრუქციული (git push, git reset --hard, rm) შეინარჩუნეთ შეზღუდული.
4. Plan mode ნებისმიერი არატრივიალურისთვის
Plan mode არის review-before-execute. აგენტი გაჩვენებთ, რის გაკეთებას აპირებს; დაამტკიცებთ ან რედაქტირებთ; შემდეგ აწარმოებს. გამოიყენეთ ნებისმიერი ამოცანისთვის, რომელიც ორზე მეტ ფაილს ეხება. 30 წამი, რომელიც გეგმის წაკითხვაზე ხარჯავთ, 30 წუთი ცუდი გადაწყვეტილებების გაუქმებას დაზოგავს.
5. ერთი ან ორი MCP სერვერი
ყველაზე დიდი წინსვლა ჩემთვის იყო MCP სერვერის მიერთება ჩვენს შიდა დოკუმენტაციასთან და issue tracker-თან. აგენტი ახლა პასუხობს „რა არის design doc feature X-ისთვის” URL-ების copy-paste-ის გარეშე. მათი აშენება მარტივია — დეტალურად დაფარულია კურსში MCP სერვერების და AI Tool Integrations-ის შექმნა.
Sub-agents — როდის გამოიყენოთ რეალურად
Sub-agents (Explore, Plan, general-purpose, etc.) ძლიერია, მაგრამ მარტივი over-use-ისთვის. ჩემი წესები:
- Explore — როდესაც რაიმე უნდა იპოვოთ კოდბაზაში, რომელიც არ იცით — მას აქვს ცალკე context window, ასე რომ თქვენს მთავარ სესიას არ ანაგვიანებს.
- Plan — ნებისმიერ არატრივიალურ implementation-მდე — იმავე მიზეზი, plus გაძლევთ წერილობით artifact-ს review-სთვის.
- General-purpose — parallelizable დამოუკიდებელი სამუშაოსთვის (მაგ., „შეისწავლე X სანამ მე ვაკეთებ Y”).
- არ გამოიყენოთ sub-agents იმისთვის, რასაც 5 წუთში დაამთავრებდით თვითონ. orchestration-ის overhead რეალურია.
ეკონომიკა
Solo engineering work-ისთვის Claude Code $20/თვე-ში პირველივე საღამოში თავს ამართლებს. გუნდის გამოყენებისთვის მათემატიკა უფრო ნიუანსურია:
- Junior ინჟინრები იღებენ ყველაზე დიდ აბსოლუტურ პროდუქტიულობის ზრდას (50%+) მაგრამ ასევე აწარმოებენ ყველაზე მეტ კოდს, რომელიც review-ს მოითხოვს.
- Senior ინჟინრები იღებენ უფრო პატარა პროცენტულ ზრდას (15–25%) მაგრამ ზრდა high-leverage სამუშაოშია — გათავისუფლდებიან რუტინისგან, არა არქიტექტურისგან.
- Code review დატვირთვა იზრდება, არ კლებულობს. დაგეგმეთ. ან უფრო აგრესიულად ვროტირებთ review duty, ან ვაყენებთ უფრო მკაცრ „agent-generated PR-ებმა უნდა შეიცავდნენ reasoning-ს” პოლიტიკას.
გუნდები, რომლებიც იგებენ ამ ინსტრუმენტთან, ცვლიან თავიანთ პროცესს, არა მხოლოდ tooling-ს. გუნდები, რომლებიც ამარცხდებიან, მას იღებენ როგორც productivity hack-ს და ამთავრებენ უფრო მეტი დაბალი ხარისხის კოდის უფრო სწრაფად გაშვებით.
80/20 თუ სხვა არაფერს კითხულობთ
თუ ერთ რამეს უნდა აიღოთ:
დახარჯეთ ერთი შუადღე კონფიგურაციაზე სანამ ერთი კვირას დახარჯავთ გამოყენებაზე. სერიოზული
CLAUDE.md, რეალური allowlist, ორი კარგად შერჩეული hook და ერთი MCP სერვერი მოგცემთ ღირებულების 80%-ს. ინჟინრების უმეტესობა ამას არასოდეს აკეთებს და აფასებს ინსტრუმენტს არაკონფიგურირებული გამოცდილების მიხედვით.
თუ გინდათ სტრუქტურირებული გზა hooks-ზე, slash commands-ზე, sub-agents-ზე და MCP integration-ზე როგორც რეალურ workflow-ზე — ზუსტად ეს არის კურსის Claude Code Mastery: Agentic Coding ინჟინრებისთვის შინაარსი. ხუთი კვირა, ათი გაკვეთილი, კონცენტრირებული რეალურ პროექტებზე უფრო სწრაფად გაშვებაზე.
სად ვიკამათებდი hype-თან
Claude Code არ აქცევს junior-ს senior-ად. ის აკეთებს junior-ს უფრო სწრაფს იმ ტიპის სამუშაოს გაკეთებაში, რომელსაც junior-ები აკეთებენ — რაც ძირითადად კარგია, მაგრამ junior-ის კარიერის შემზღუდველი ფაქტორი არის გადაწყვეტილების მიღება, არა აკრეფის სიჩქარე. ინსტრუმენტი არ ასწავლის გადაწყვეტილების მიღებას. Mentorship და code review ისევ ასწავლის.
ის ასევე არ აუქმებს კოდის ფრთხილად კითხვის საჭიროებას. ინჟინრები, რომლებიც გამოტოვებენ read-and-understand ნაბიჯს, რადგან „აგენტმა დაწერა”, გროვდებიან ვალს, რომელსაც ჯერ არ ხედავენ. ანგარიშები მოდის კვარტალში ან ორში, როდესაც გუნდში არავინ იცის, როგორ მუშაობს სისტემა რეალურად.
გამოიყენეთ. მაგრამ იმავე სტანდარტებით, რასაც კონტრაქტორს გამოიყენებდით: თქვენ ხართ პასუხისმგებელი იმისთვის, რასაც აშენებთ, თუნდაც სხვამ აკრიფა.
გინდათ კონცენტრირებული გზა Claude Code-ის ძლიერ ფუნქციებზე? დაიწყეთ Claude Code Mastery: Agentic Coding ინჟინრებისთვის-ით. უკვე ხედავთ მისგან გავრცელებას? კურსი MCP სერვერების და AI Tool Integrations-ის შექმნა ბუნებრივი შემდეგი ნაბიჯია — დაწერეთ თქვენი საკუთარი MCP სერვერები, რომ თქვენი გუნდის შიდა ინსტრუმენტები და მონაცემები Claude-ს გადასცეთ.
