ყოველდღე ვიყენებ AI ინსტრუმენტებს. ვასწავლი კურსებს მათზე აპლიკაციების შექმნის შესახებ. მე არ ვარ ის ადამიანი, რომელიც გეტყვით, რომ ეს მოდურია. მაგრამ ორი წლის ინჟინრების — ჩემი ჩათვლით — დაკვირვების შემდეგ შემიძლია ვთქვა სიტუაციები, სადაც AI მუდმივად აკეთებს სამუშაოს უარესად.
თუ წელს ერთ contrarian პოსტს წაიკითხავთ AI-ზე development-ში, ეს იყოს ეს. ამ ინსტრუმენტების ზედმეტი გამოყენების ფასი რეალურია და ძირითადად უხილავია, სანამ ძვირი არ გახდება.
წესი 1: არ გამოიყენოთ AI ფუნდამენტების სასწავლად
ეს არის ის, რასაც ბილბორდზე დავწერდი.
როდესაც junior ხართ ან ახალ ენას სწავლობთ, ცდუნება დიდია. ეკითხებით Claude-ს ან Copilot-ს, იღებთ მუშა პასუხს 10 წამში, paste-ეთ, აცხადებთ. Bug გასწორდა. წინ მიდიხართ.
რა არ გააკეთეთ: არ წაიკითხეთ docs, არ ჰქონდათ data structure თავში, არ იბრძოლეთ type system-თან, არ ააშენეთ mental model. ექვს თვეში ვერ დებაგებთ თქვენს კოდს AI-ის გარეშე. ვერ ცნობთ patterns-ს. თქვენი code reviews ზედაპირულია, რადგან AI-ის გარეშე ვერ ხედავთ რა არის არასწორი.
ვუყურებდი როგორ ემართებათ ეს რამდენიმე junior ინჟინერს, რომელთაც მენტორობდი. ისინი უფრო მეტს ხდიან პირველ სამ თვეში, ვიდრე junior-ები ხდიდნენ. მე-9 თვისთვის plateau-ზე დგებიან ისე, რომ აღდგენა ძნელია, რადგან ფუნდამენტური repetitions არასოდეს მოხდა.
ემპირიული წესი: თუ კოდს ვერ წერთ AI-ის გარეშე, თემა ჯერ არ იცით. AI კარგია მეორეჯერ, არა პირველჯერ.
წესი 2: არ გამოიყენოთ AI სახელებისთვის, API დიზაინისთვის ან აბსტრაქციებისთვის
ეს ის არის, რაც უფრო მეტად აოცებს ინჟინრებს, როცა ხმამაღლა ვამბობ.
LLM-ები აწარმოებენ ტექნიკურად სწორ სახელებს და API-ებს. ისინი თითქმის არასოდეს აწარმოებენ კარგ-ებს. სხვაობა გემოვნებაშია — იცოდე, რომ processData() არის smell, იცოდე, რომ მეთოდი 7 პარამეტრით კლასი უნდა იყოს, იცოდე, რომ ეს აბსტრაქცია ნაადრევია და ის — დაგვიანებული. გემოვნება შენდება წლების მანძილზე სხვების კოდის (განსაკუთრებით საკუთარი წარსულის) შენარჩუნებით.
შევწყვიტე ამის დელეგაცია აგენტზე:
- ფუნქციებისა და მეთოდების სახელები
- კლასების საზღვრები და responsibilities
- API surface design (რა argument-ები, რა return shape, რა errors)
- როდის ამოიღოთ აბსტრაქცია
- როდის არ ამოიღოთ
აგენტი ყველაფერზე გასცემს დასაცავ პასუხს. იშვიათად სწორს. ფასი ცხადდება თვეების შემდეგ, როდესაც კოდის წაკითხვა აღარავის შეუძლია.
წესი 3: არ debug-ოთ production AI-ით observability-ის გარეშე
ეს ხაფანგი senior ინჟინრებს უფრო ხშირად აჭერს, ვიდრე junior-ებს.
Bug ჩნდება production-ში. Stack trace-ს Claude-ში ჩასვით. ის სარწმუნოდ სპეკულირებს. Fix-ს ახორციელებთ. Error აღარ ჩნდება test environment-ში. ხდიდთ. ორ კვირაში error კვლავ გამოჩნდა.
რა მოხდა: stack trace იყო სიმპტომი, არა მიზეზი. აგენტმა მიზეზი მხოლოდ სიმპტომისგან გამოიცნო — თქვენი distributed traces-ის, metrics-ის, deployment history-ისა და იმავე საათში მომხდარი ოთხი დაკავშირებული შეცდომის გარეშე. წარმოქმნა fix, რომელმაც რაღაც მოაგვარა, მაგრამ არა the პრობლემა.
Production debugging მოითხოვს, რომ:
- გაამეოროთ ან ზუსტად დაახასიათოთ failure
- იზოლირება, რომელმა ცვლილებამ შემოიტანა იგი
- ააშენოთ hypothesis რეალური signals-ისგან (logs, traces, metrics)
- გადაამოწმოთ, რომ fix-მა მართლა გაამყარა root cause
AI სასარგებლოა step 3 და step 4-ზე — მაგრამ მხოლოდ მას შემდეგ, რაც step 1-სა და 2-ს შეასრულებთ. გამოტოვეთ — და სარწმუნო patches-ს მუდმივად გამოიყენებთ.
წესი 4: არ გააკეთოთ AI-ით ის, რის შეფასებასაც ვერ ახერხებთ
თუ კარგ პასუხსა და ცუდს ვერ ანსხვავებთ, AI-სთვის თხოვნაც არ გაქვთ.
ეს აშკარაა. არ არის. აი სად კბენს ეს:
- წერთ ენაზე, რომელიც კარგად არ იცით. აგენტი წერს Rust-ს, რომელიც compile-ს უძლებს და მუშაობს, მაგრამ არ არის idiomatic. ხდიდთ. რეალური Rust ინჟინერი მოგვიანებით review-ს თქვენს repo-ს — და კოდი სავსეა beginner anti-patterns-ით.
- არქიტექტურული გადაწყვეტილებები თქვენი გამოცდილების მიღმა. „აქ Kafka-ს უნდა ვიყენო თუ RabbitMQ-ს?” არ არის ერთპასუხიანი კითხვა; ეს დამოკიდებულია operational concerns-ზე, რომელიც აგენტი ვერ ხედავს.
- Security-sensitive კოდი. აგენტი წარმოშობს კოდს, რომელიც უსაფრთხოდ გამოიყურება. გაიგო რეალურად უსაფრთხოა თუ არა — მხოლოდ თუ თქვენ თვითონ გესმით threat model.
ყველა ამ შემთხვევაში AI არ ცვლის ექსპერტიზას. ის გრძნობას ცვლის output-ში, რომელსაც ხდიდთ ისე, რომ არც კი ხვდებით, რომ არ გესმით.
წესი 5: არ გამოიყენოთ AI ერთხაზიანი edits-ისთვის
ეს მცირეა, მაგრამ რეალური. ინჟინრები მიწვდებიან AI-ს ერთი ხაზის ჩასვლის ან ცვლადის გადარქმევის საქმეში. 4 წამს ელოდებიან მის ფიქრს. წარმოებულს review-ს. იღებენ.
იგივე edit-ს თქვენ თქვენი ხელით 1 წამში გააკეთებდით, თუ უბრალოდ გააკეთებდით. დაგროვილი დრო, რომელსაც აგენტისთვის ხარჯავთ ტრივიალურ edits-ზე ლოდინში, ჩემი გაზომვებით, უფრო დიდია, ვიდრე ის დრო, რომელსაც ის საშუალოებზე დაზოგავს.
ემპირიული წესი: თუ თქვენი თითები იციან რა აკრიფონ, აკრიფეთ. აგენტი იმისთვის, სადაც სამუშაო თვითონ გადაწყვეტაა რა აკრიფოთ.
წესი 6: არ გამოიყენოთ AI ისეთი რამეებისთვის, რომელიც დასამახსოვრებელია
ნებისმიერი რამ, რომელსაც თქვენს თავში უნდა ცხოვრობდეს — მეორე გუნდთან გარიგება, კონსტრეინტი, რომელიც კოდში არ არის, პოლიტიკურად დელიკატური კომპრომისი, რომელიც ხსნის რატომ გამოიყურება ეს კოდი უცნაურად — არ უნდა დაუდელეგიროთ აგენტს. აგენტს ამის მეხსიერება არ აქვს სესიებს შორის. ის გადააფაქტორებს უცნაურად გამოყურებად კოდს, რომელიც არსებობს რაიმე მიზეზის გამო, რომელიც არავის დაუდოკუმენტებია.
დაადოკუმენტეთ რატომ. კოდის კომენტარებში სადაც შესაფერისია, CLAUDE.md-ში თუ აგენტს უნდა ცოდნა, design docs-ში. „რატომ” არის engineering-ის ის ნაწილი, რომელიც AI-ზე არ გადადის, და ყველაზე ღირებული ნაწილი.
წესი 7: არ გამოიყენოთ AI code review-ს გასამოტოვებლად
თქვენ დაწერეთ კოდი. (თუნდაც აგენტმა ჩაწერა, თქვენ დაწერეთ — თქვენ ხართ პასუხისმგებელი.) წაიკითხეთ. ხაზი ხაზის შემდეგ. ხმამაღლა, თუ ეხმარება.
ინჟინრები, რომლებიც ამ ნაბიჯს გამოტოვებენ, რადგან „აგენტმა უკვე validate გააკეთა”, გროვდებიან ისეთი სახის ვალს, რომელიც უხილავია, სანამ overwhelming არ გახდება. აგენტის validation არის სტატისტიკური: ეს კოდი ჰგავს კოდს, რომელიც მუშაობს. ეს არ არის იგივე, რაც human-ის გააზრებული validation: ეს კოდი სწორია ამ სისტემისთვის, ამ კონტექსტში, იმისთვის რასაც ვცდილობ მივაღწიო.
ორი წლის შემდეგ ეს არის pattern, რომელიც ყველაზე მტკიცედ correlate ხდება ინჟინრებთან, რომელთა კარიერებიც stall-ებს — ისინი AI-ს ხარისხის gate-ად ექცევიან. ის არ არის.
რას ვაკეთებ ნაცვლად
თითოეული შემთხვევისთვის, აი რას ვაკეთებ რეალურად:
| სიტუაცია | რას ვაკეთებ |
|---|---|
| ახალი თემის სწავლა | ჯერ ვაშენებ mental model-ს. AI მეორე პროექტისთვის, არა პირველისთვის. |
| სახელების მინიჭება | სამ სახელს ვწერ თვითონ. ვირჩევ საუკეთესოს. შემიძლია AI-ს ვთხოვო კრიტიკა. |
| Production debugging | ვამოიღებ logs-ს, traces-ს, metrics-ს. ვაყალიბებ hypothesis-ს. შემდეგ AI შეიძლება დაგვეხმაროს fix-ის წერაში. |
| ჩემი ექსპერტიზის გარეთ კოდი | ვწყვილდები ადამიან-ექსპერტთან როცა stakes ამართლებენ. AI არ არის შემცვლელი. |
| ტრივიალური edits | ვწერ მათ. უფრო სწრაფი, ნაკლები context-switching. |
| მნიშვნელოვანი კონტექსტი | ვადოკუმენტებ. კოდში, CLAUDE.md-ში, design doc-ში. |
| Code review | ყოველ ხაზს ვკითხულობ, ყოველჯერ. AI არის junior თანამშრომელი, არა senior. |
უფრო ღრმა საკითხი
Framing-ის კითხვა, რომელსაც ყოველ ინჟინერს ვუკრავდი ვკითხო AI ინსტრუმენტისკენ მიწვდის ნაცვლად:
რომელ უნარს ვაშენებ, და AI მე უფრო ძლიერად ხდის თუ უფრო სუსტად მასში?
მექანიკური სამუშაოსთვის AI უფრო ძლიერად გხდით, რადგან თავისუფალს ხდით დროს იმ სამუშაოსთვის, რომელიც მნიშვნელოვანია.
განსჯის სამუშაოსთვის AI უფრო სუსტად გხდით, რადგან საშუალებას გაძლევთ outsource-თ ის repetitions, რომლებიც განსჯას აშენებენ.
ინჟინრები, რომლებიც აყვავდებიან მომდევნო ათწლეულში, არიან ისინი, ვისაც სხვაობის დანახვა შეუძლია. არა ისინი, ვინც AI-ს ყველაზე აგრესიულად იყენებს, და არც ისინი, ვინც მას უარყოფს. ისინი, ვინც ზუსტად იცის, როდის გადადოს იგი.
თუ გინდათ სტრუქტურირებული გზა AI-სთან მუშაობაზე როგორც რეალურ engineering ინსტრუმენტთან — გულახდილი tradeoffs-ით — დაიწყეთ Prompt Engineering & AI Workflow Automation-ით. Production AI სისტემების შესაქმნელად უფრო ღრმად, კურსები Claude API-ით აპლიკაციების შექმნა და Claude Code Mastery აგრძელებენ იქ, სადაც ეს სტატია ჩერდება.
