უკვე ორი თვეა, ხელით ერთი ფუნქცია არ დამიწერია. კოდბაზა არასოდეს ყოფილა უფრო ჯანმრთელი. ორი წლის წინ ეს ფრაზა მარკეტინგად ჟღერდა. 2026-ში ეს უბრალოდ ახალი ბაზაა, და ინჟინრები, რომლებიც ამას ვერ ხედავენ, აპირებენ დაკარგონ საფეხური, რომელზეც იდგნენ და ვერ ამჩნევდნენ.
ეს არის კონტექსტ-ინჟინერიის დიზაინ-დროის თანამგზავრი. კონტექსტ-ინჟინერია არის ის, რასაც რანტაიმი აწყობს მოდელის გაშვების მომენტში. Spec-driven development არის ის, რასაც გუნდი წერს და საიდანაც რანტაიმი მერე იყრის თავს. ეს ერთი და იმავე ცვლილების ორი მხარეა, და სერიოზულად ერთით ვერ დაკავდები მეორის გარეშე.
თეზისი აქ უფრო მკვეთრია, ვიდრე ხალხს ეხერხება. თქვენი კოდბაზა აღარ არის თქვენი კოდბაზა. თქვენი სპეციფიკაციები — დიახ. კოდი უბრალოდ ქეშია.
ცვლილება: კოდი როგორც ქეში, სპეცი როგორც ჭეშმარიტება
ოცდაათი წელი წყაროს კოდი იყო მდგრადი არტეფაქტი, დანარჩენი კი — ტიკეტები, მოთხოვნების დოკუმენტები, არქიტექტურული დიაგრამები — დეკორაცია მის გარშემო. კოდი იყო ერთადერთი ადგილი, სადაც ჭეშმარიტება ცხოვრობდა. დანარჩენი ყველაფერი იცვლებოდა.
2026-ში ეს ურთიერთობა ბევრ გუნდში ტრიალდება, ჩემიც მათ შორის. მდგრადი არტეფაქტი არის სპეციფიკაცია: ფაილი, რომელსაც აგენტი კითხულობს, eval-კომპლექტი, რომლის წინააღმდეგ მას ამოწმებენ, შეზღუდვები, რომელთა დაცვაც სისტემაა ვალდებული. კოდი არის ის, რაც სპეციფიკაციიდან მოთხოვნით რეგენერირდება. თუ წაშლი კოდს და დატოვებ სპეციფიკაციას, კოდი შეიძლება ხელახლა აწარმოო. თუ წაშლი სპეციფიკაციას და დატოვებ კოდს — დაკარგე ჭეშმარიტება, და წარმატებები რევერს-ინჟინერიაში .ts-ფაილების საქაღალდიდან, რომელსაც ბოლოს სამი სხვადასხვა აგენტი ეხებოდა.
ეს არ არის ჰიპოთეზური. ეს არის კოდბაზის პრაქტიკული რეალობა, სადაც კოდის წერის უმეტესობა დელეგირებულია. კოდი წყვეტს იყოს ჭეშმარიტების წყარო, რადგან აღარ არსებობს ერთი ავტორი, რომელიც მას თავში ინახავს. ეს როლი სპეციფიკაციამ უნდა აიღოს, თორემ — არავინ.
ეს ცვლის ყველაფერს ქვემოთ მდინარეში: რევიუს, ტესტინგს, ონბორდინგს, აყვანას. თითოეულზე გავალთ.
რა არის „სპეციფიკაცია” 2026-ში
სპეციფიკაცია არ არის მოთხოვნების დოკუმენტი. არ არის user story. არ არის wiki-გვერდი, რომელიც ვინმემ ექვსი თვის წინ დაწერა და მას შემდეგ არავის შეხებია.
სპეციფიკაცია 2026-ში არის შესასრულებელი არტეფაქტი, რომელსაც აგენტი პირდაპირ კითხულობს, რომლის წინააღმდეგ მას აფასებენ, და საიდანაც ის კოდს აწარმოებს. მას აქვს სამი კონკრეტული ფორმა, რომელიც მომწიფებულ გუნდებში გვხვდება.
| ძველი არტეფაქტი | 2026-ის ეკვივალენტი-სპეცი | რა შეიცვალა |
|---|---|---|
| Jira ტიკეტი | Feature-სპეცი | აგენტის მიერ შესასრულებელი, არა მისწრაფება; რეპოშია, არა ტრეკერში |
| README | CLAUDE.md / AGENTS.md / რეპოს წესები | მანქანებს კითხულობენ, არა მხოლოდ ადამიანებს; გატარებული, არა დეკორაცია |
| არქიტექტურის დოკუმენტი | სისტემური სპეცი + eval-კომპლექტი | შემოწმებული, არა მემორიული; რევიუვდება ცვლილებისას |
| კოდის კომენტარი | Inline-სპეცი | მართავს ქცევას, არა მხოლოდ აღწერს |
Anthropic Skills ფორმატი, GitHub Spec Kit, AGENTS.md ფაილების გამოჩენა რეპოს ფესვში — ეს არ არის გაბნეული ტრენდები. ეს ერთი და იგივე ტრენდია სხვადასხვა ქუდით. ინდუსტრია კოლექტიურად ხვდება, რომ აგენტური სისტემების მდგრადი შესასვლელი უნდა ცხოვრობდეს ფაილში, არა პრომპტში, და ეს ფაილი უნდა იყოს რევიუვადი და ვერსიონირებული ისე, როგორც კოდი.
სპეციფიკაციების იერარქია
მომწიფებულ spec-driven კოდბაზაში თქვენ პოულობთ ოთხ დონეს, ერთმანეთში ჩადგმულს.
სისტემური სპეცი. ინვარიანტები. არქიტექტურული წესები. უსაფრთხოების საზღვრები. მონაცემთა დამუშავების შეზღუდვები. „API-ის ყველა პასუხი — JSON; PII არ ტოვებს ბაზას; ავტორიზაცია არის edge-ზე, არა ჰენდლერებში”. ეს იშვიათად იცვლება და იშვიათად ეკუთვნის ერთ ფიჩას. ისინი ცხოვრობენ რეპოს ფესვში — AGENTS.md-ში ან ეკვივალენტში.
Feature-სპეცი. რას აკეთებს შესაძლებლობა. მაგალითები და კონტრ-მაგალითები. მიღების კრიტერიუმები. Eval-კომპლექტი, რომელთან ფიჩა გაიყვანება. ეს გადაიწერება ფიჩების ევოლუციისას. ისინი ცხოვრობენ კოდის გვერდით, რომელსაც აღწერენ, ხშირად როგორც feature.md-მეზობელი იმპლემენტაციის დირექტორიის.
Task-სპეცი. ერთეული, რომელსაც აგენტი ერთ გაშვებაში ასრულებს. უფრო ვიწრო, ვიდრე ფიჩა: „დაამატე rate-limit middleware, რომელიც იყენებს არსებულ Redis-კლიენტს და გამოსცემს იმავე ტელემეტრიის ფორმას, რომელსაც auth middleware”. ხშირად ეფემერული, მაგრამ PR-ის აღწერებში ან task-ფაილებში ვერსიონირებული.
Inline-სპეცი. რეპოს ფაილებში ჩაშენებული წესები — CLAUDE.md, AGENTS.md, სქემების კომენტარები, დირექტორიის დონის README.md ფაილები, რომელსაც აგენტი კითხულობს როგორც კონტექსტს ყველაფრისთვის, რასაც ის ამ დირექტორიაში აკეთებს.
რაც მუშაობს: პატარა სპეციფიკაციები, კომპოზიციით. დიდი სპეციფიკაციები იჟონება. ხუთ საკითხს მოიცავი ორი ათასი სიტყვის feature-სპეცი აგენტისთვის (ან ადამიანისთვის) უფრო რთული შესასრულებელია, ვიდრე ხუთი სამასი-სიტყვიანი, თითო საკითხს მოიცავი.
რა იცვლება, როცა სპეციფიკაციები ხდება first-class
როცა სპეციფიკაცია მდგრადი არტეფაქტი ხდება, მის ქვემოთ მდინარეში ხდება სამუშაო პროცესის ფორმის ცვლილება:
- Code review ხდება spec review. PR-ის რევიუ ორასი ხაზის აგენტის მიერ გენერირებული კოდით — უმადური სამუშაოა: კოდი ჩვეულებრივ მექანიკურად ნორმალურია. სპეციფიკაციის რევიუ, რომელმაც ის გამოიწვია — მაღალი ბერკეტის სამუშაოა: სწორედ იქ მოხდა გადაწყვეტილებები. გუნდები, რომლებმაც რევიუს ყურადღება სპეციფიკაციაზე არ გადაიტანეს, ჯერ კიდევ ფლანგავენ უფროსი ინჟინრის დროს კოდზე, რომელსაც აგენტი გასწორებული სპეციფიკაციიდან ოცი წამში ხელახლა გენერირებს.
- PR description ხდება spec diff. „შევცვალე rate-limit პოლიტიკის სპეცი X-დან Y-მდე; კოდი მის შესაბამისად რეგენერირებულია” — გაცილებით უკეთესი PR-აღწერაა, ვიდრე შეცვლილი ფაილების კედელი. Diff, რომელიც ადამიანებს აინტერესებთ — ეს spec diff-ია. Code diff — მისი შედეგი.
- ტესტინგი ხდება eval. იუნიტ-ტესტები ჯერ კიდევ არსებობს. მაგრამ მაღალი ღირებულების ტესტინგი — ფიჩა აკმაყოფილებს თუ არა სპეციფიკაციას სხვადასხვა შესასვლელზე, კიდურა შემთხვევებსა და მტრულ პირობებში — უფრო ჰგავს eval-კომპლექტს, ვიდრე იუნიტ-ტესტის ფაილს. Evals მიბმულია სპეციფიკაციაზე; სპეციფიკაცია იცვლება — evals იცვლება იმავე კომიტში.
- დებაგი ხდება spec-gap-ანალიზი. „რატომ აწარმოა აგენტმა არასწორი კოდი?” გადაიქცევა „სად სპეციფიკაციაში იყო ეს შემთხვევა ნაკლებად სპეციფიცირებული?”. ბაგი თითქმის ყოველთვის სპეციფიკაციაშია, არა იმ კოდში, რომელიც მან აწარმოა. სპეციფიკაციისადმი მოპყრობა, როგორც ბაგების წყაროსადმი — ეს არის ერთადერთი ყველაზე მაღალი ბერკეტის workflow-ცვლილება, რომელიც ბოლო ორ წელში გავაკეთე.
- ონბორდინგი ხდება სპეციფიკაციების კითხვა, არა წყაროების კითხვა. ახალი ინჟინრები არ აჩქარდებიან კოდბაზის კითხვით. ისინი აჩქარდებიან სისტემური სპეციფიკაციის წაკითხვით, შემდეგ feature-სპეციფიკაციების იმ უბნებისა, სადაც იმუშავებენ. კოდი ქვემოთ მდინარეშია — და ისინი თავად სწრაფად აწარმოებენ მას, როცა შეზღუდვებს გაიგებენ.
უფროსი ინჟინრის ბერკეტი 2026-ში არის სპეციფიკაციების წერაში, რომელსაც სხვა ხალხის აგენტები სწორად შეასრულებენ.
ეს ის ნაწილია ცვლილებისა, რომელიც სენიორებს ყველაზე ძლიერად სცემს — ორივე მიმართულებით. ბერკეტი უზარმაზარია. საქმიანობა უცნობია. და კოდის ხელით წერის კუნთის მეხსიერება იწყებს ატროფირებას, თუ აქტიურად არ წყვეტთ, რომელი პრობლემები ჯერ კიდევ ამის ღირსია.
ხუთი წესი სპეციფიკაციების წერისთვის, რომელსაც აგენტები რეალურად ემორჩილებიან
დანომრილია, რადგან გამოვიმუშავე პროდუქშენში, არ გამოვიყვანე ბლოგ-პოსტებიდან.
1. შესასრულებელი, არა მისწრაფება. ყოველ სპეციფიკაციას ჭირდება მიღების შემოწმება. „ეს ფიჩა მომხმარებლისთვის მოსახერხებელი უნდა იყოს” — ეს არ არის სპეციფიკაცია, ეს სურვილია. „როცა მომხმარებელი ფორმას email-ის გარეშე აგზავნის, დააბრუნე 400 სხეულით {error: 'email_required'} და დაალოგე validation_failed ღონისძიება ფორმის ID-ით” — ეს არის სპეციფიკაცია. წესი: თუ მხოლოდ სპეციფიკაციიდან ვერ წერ ტესტს, სპეციფიკაცია არ არის მზად.
2. აჩვენე მაგალითები და კონტრ-მაგალითები. აგენტები კონტრასტიდან უფრო სწრაფად სწავლობენ, ვიდრე წესებიდან. სპეციფიკაცია, რომელიც ამბობს „სახელები უნდა იყოს sentence case-ში” სუსტია, ვიდრე ის, რომელიც დაამატებს „მაგალითი: ‘Annual revenue’. კონტრ-მაგალითი: ‘annual_revenue’ ან ‘AnnualRevenue’”. ყოველთვის აჩვენე, როგორ არ უნდა გამოიყურებოდეს გამოსავალი. სწორედ იქ ცხოვრობს ნამდვილი მართვადობა.
3. დაასახელე მტყუნების რეჟიმები. პოზიტიური სპეციფიკაციები („ყოველთვის გააკეთე X”) უფრო სუსტია, ვიდრე ნეგატიური („არასოდეს გააკეთო Y”). აგენტი უფრო საიმედოდ დაემორჩილება „არ შეიკრიბო ბაზაში ჰენდლერიდან”, ვიდრე „გამოიყენე რეპოზიტორი ფენა”. ორივე ეკუთვნის სპეციფიკაციას, მაგრამ თუ მხოლოდ ერთის წერა შეგიძლია — დაწერე უარყოფა.
4. ვერსიონირე სპეციფიკაციები ისე, როგორც კოდი. სპეციფიკაციები რეპოშია. მათ აქვთ ისტორია. ისინი რევიუვდება PR-ებში. ისინი დაიდანაშაულება, როცა რამე იშლება. „სპეციფიკაციის ცვლილება კოდის ცვლილების გარეშე” — ეს რეალური PR-ფორმაა 2026-ში: ზოგჯერ ყველაზე მნიშვნელოვანი ცვლილება არის სპეცი, ხოლო კოდის რეგენერაცია — შემდგომი ნაბიჯი. სპეციფიკაციებისადმი მოპყრობა, როგორც კოდისადმი — არ განიხილება; ყველაფერი დანარჩენი ინგრევა, თუ სპეციფიკაციები იცვლება.
5. ერთი სპეცი, ერთი შესაძლებლობა. დიდი სპეციფიკაციები იჟონება. სპეცი, რომელიც მოიცავს ავთენტიფიკაციას და rate-limit-ს და ლოგირებას, აწარმოებს კოდს, სადაც ამ სამიდან ერთი მუდმივად ცოტა არასწორია. გაყავი. დააკომპოზიცირე შესაძლებლობები. ის ინსტინქტი „პატარა ფუნქციები, ერთი პასუხისმგებლობა” სპეციფიკაციებზე ვრცელდება ორმაგი ძალით.
სად იშლება ეს
რამეს გვყიდიდი, თუ აქ გავჩერდებოდი. არსებობს რეალური შემთხვევები, სადაც spec-driven development არასწორი ფრეიმია, და საპირისპიროდ ვითარების მოპირდაპირე გამოაცხადება მოგწვათ.
- საძიებო და კვლევითი სამუშაო. თქვენ ჯერ არ იცით, რა სპეციფიცირდეს. თქვენ პრობლემის ფორმას სწავლობთ. სპეციფიკაციის წერა პრობლემის გაგებამდე — ეს კარგო-კულტ ინჟინერიაა. ამ ფაზებში წერეთ კოდი ხელით, წაიკითხეთ გამოსავალი, შემდეგ ამოიღეთ სპეცი იქიდან, რაც იმუშავა. სპეცი მერე, არა — ჯერ.
- Performance-კრიტიული გზები. ცხელი ციკლები, memory-layout-ისადმი მგრძნობიარე კოდი, მჭიდრო შიდა ბირთვები — აგენტი აწარმოებს რაღაცას, რომელიც აკმაყოფილებს სპეციფიკაციას, მაგრამ ორჯერ უფრო ნელია, ვიდრე საჭიროა, ისე, როგორც სპეციფიკაცია ვერ ითვალისწინებდა. დაწერეთ ეს ნაჭრები ხელით. სპეციფიცირეთ ზედაპირი; ბირთვი — ხელით.
- Legacy კოდის არქეოლოგია. „შეცვალე ეს თოთხმეტი წლის ფუნქცია” იშვიათადაა spec-driven დავალება. წაიკითხეთ კოდი, გაიგეთ, რას აკეთებს, შემდეგ გადაწყვიტეთ. სპეციფიკაციები წინ მუშაობისთვისაა; არქეოლოგია — საკუთარი დისციპლინა.
- შემთხვევები, როცა სპეცი კოდზე გრძელია. თუ თქვენი სპეცი ას ხაზია, ხოლო კოდი ოცი — ზე-სპეცი-რებული გაქვთ. spec-to-code თანაფარდობას აქვს sweet spot, და მისი გადაჭარბება ნიშნავს, რომ სპეციფიკაციებს იყენებთ როგორც შემცვლელს იმისა, რომ არ იცით, რა ააშენოთ. გადადგით ნაბიჯი უკან, დაწერეთ ოცდაათ-ხაზიანი სპეცი, დაეთანხმეთ, რომ იტერირებთ.
გულწრფელი ჩარჩო: spec-driven development არის დეფოლტი ოთხმოცდაათი პროცენტი სამუშაოსთვის მომწიფებულ 2026-ის კოდბაზაში. დანარჩენი ათი პროცენტი მნიშვნელოვანია, და უფროსი ინჟინერი არის ის, ვინც ამ განსხვავებას ხედავს.
კარიერული კუთხე: სპეც-ავტორი როგორც ხელობა
რა იცვლება პირადად თქვენთვის, კიბეზე თქვენი ადგილის მიხედვით, უხეშად სამ ჯგუფად იყოფა.
ჯუნიორები. ხაფანგი აშკარა და საშიშია: კოდის წერა, რომელიც აგენტს შეეძლო დაეწერა, იმის ნაცვლად, რომ ისწავლო სპეციფიკაციის წერა, რომელშიც აგენტი ჭირდებოდა. ყველაზე სწრაფი გზა იმისთვის, რომ არასოდეს გახდე უფროსი ინჟინერი — ამაყობდე იმ კოდის მოცულობით, რომელსაც აწარმოებ. ყველაზე სწრაფი გზა გახდომის დასაწყებად — ამაყობდე იმ სპეციფიკაციების სიზუსტით, რომელსაც წერ, ნეგატიური შემთხვევების ჩათვლით. თქვენ მიერ დაწერილი ყოველი სპეცი არის სააზროვნო არტეფაქტი. ყოველი ხაზი აგენტის გენერირებული კოდისა — არა.
მიდლები. ცვლილება აქ ყველაზე დიდია. თქვენი ძველი ბერკეტი იყო კოდის კარგად წერა; ახალი ბერკეტი არის სპეციფიკაციების კარგად წერა. კარიერული რისკი: თუ ცვლილებას არ გააკეთებთ, სენიორთან განსხვავება უფრო რთული გასარღვევი ხდება, რადგან ის, რისთვისაც სენიორებს ახლა ანდრობენ, კოდის ზემოთ მდინარეშია. კარიერული შესაძლებლობა: spec authoring არის განუვითარებელი უნარი მთელ ინდუსტრიაში; მასში სწრაფად დახელოვნება ერთ-ერთი ყველაზე მაღალდაბრუნებადი ინვესტიციაა, რომელიც ახლა ხელმისაწვდომია.
სენიორები და სტაფები. თქვენი სამუშაოს აღწერა შეიცვალა, აღწევია ეს თქვენს წოდებას თუ არა. თქვენ ხართ სპეც-ავტორი, რომელიც ხანდახან წერს კოდს, არა კოდის ავტორი, რომელიც ხანდახან წერს სპეციფიკაციებს. ყველაზე უფროსი ინჟინრები, ვისთანაც ვმუშაობ, დღეს დღეს ატარებენ სპეციფიკაციების ფორმირებაში, რომელიც ხუთ-ათ აგენტურ სესიას აპარალელურად მართავს. ბერკეტი იკრიფება, რადგან კარგად ფორმირებული სპეციფიკაციები კომპოზიციდება რამდენიმე აგენტისა და ფიჩის გასწვრივ. ცუდად ფორმირებული — ერთდროულად ყველაში იჟონება.
უფრო ღრმა აზრი
სპეციფიკაციები — ეს არის ის, რასაც წერთ; კონტექსტი — ეს არის ის, რასაც რანტაიმი მათგან აყრის თავს. ორივე უნდა იყოს სწორი. რომელიმე გატეხეთ — და სისტემა მტყუნებს ისე, რომ AI-ბაგებად გამოიყურება, მაგრამ სინამდვილეში საინჟინრო ბაგებია. ორივე გააკეთეთ სწორად — და კოდბაზის უმეტეს ნაწილს თვითონ წერს. ჟღერს ცუნდრუკულად, სანამ მუშაობაში არ ნახავთ, რომლის შემდეგ ჟღერს ვერსიის კონტროლის შემდეგ საინჟინრო პრაქტიკის ყველაზე მნიშვნელოვან ცვლილებად.
თუ უფრო ღრმად გინდათ, ქვემოთ მოცემული კურსები მოიცავს დისციპლინის იმ ნაწილებს, რომლებსაც ყველაზე ხშირად ვასწავლი: Claude Code Mastery: Agentic Coding for Engineers — spec-driven development-ის ყოველდღიური workflow რეალურ აგენტთან, Building Agents with the Claude Agent SDK — აგენტების აშენება, რომლებიც სპეციფიკაციებს first-class შესასვლელად მოიხმარს, Prompt Engineering & AI Workflow Automation — პრომპტ-დონის ფუნდამენტი, რომელიდანაც სპეციფიკაციები ევოლუციონირებენ, და Building MCP Servers & AI Tool Integrations — როგორ გავხადოთ სპეციფიკაციები აგენტებსა და ხელსაწყოებს შორის გადატანადი.
