ექვსი კვირის წინ დავაყენე @fission-ai/openspec brownfield TypeScript-კოდბაზაზე, რომელსაც სამი ინჟინერი ორი წელია ასწორებდა. გუშინ ჩავაბარე თოთხმეტ-ფაილიანი ცვლილება ოთხმოცდაათ წუთში ორას-ხაზიანი სპეციფიკაციიდან. მერჯ-კონფლიქტების გარეშე. რევიუს ესკალაციის გარეშე. PR-აღწერა იყო proposal და სამოცი-ხაზიანი spec-დელტა; კოდის დიფი მისი შედეგი იყო. სენიორი ინჟინერი, რომელმაც გადახედა, კოდი არ წაუკითხავს — მან წაიკითხა spec-დელტა და დაამტკიცა.
ეს ფრაზა ორი წლის წინ მარკეტინგად ჟღერდა. 2026 წლის მაისში ეს მესამე კვირაა ზედიზედ, რომ რაღაც ამ გზით ვაბარებ, და დავიწყე ფიქრი, რომ ჯადო OpenSpec-ში არ არის. ჯადო ისაა, რომ მეთოდოლოგიას ბოლოს და ბოლოს გაუჩნდა ხელსაწყო, რომელიც მის საკუთარ პრეტენზიებს სერიოზულად აღიქვამს.
ეს არის მეოთხე პოსტი რკალში, რომელსაც ვწერ. კონტექსტ-ინჟინერია იყო რანტაიმის დისციპლინა. Spec-driven development იყო design-time ფილოსოფია. Evals იყო ვერიფიკაციის შრე. თითოეული ეს პოსტი წინ უთითებდა კითხვაზე, რომელზეც ჯერ ვერ ვუპასუხე: მაგრამ რეალურად როგორ ატარებ ამას რეალურ კოდბაზაში, რეალური ხალხით, სამშაბათს? OpenSpec არის პირველი ხელსაწყო, რომელიც ამ კითხვაზე გულწრფელად პასუხობს.
თეზისი უფრო მკვეთრია, ვიდრე ხალხს ეხერხება. OpenSpec არის პირველი spec-driven ფრეიმვორქი, რომელიც სპეციფიკაციებს ისე ეპყრობა, როგორც Git ეპყრობა კოდს: filesystem-state-machine ბრენჩებით, იზოლაციით და ატომური მერჯებით. ეს არ არის ფიჩა. ეს არის მთელი მიზეზი, რის გამოც ის მუშაობს.
რა არის OpenSpec, ზუსტად რომ ვთქვათ
OpenSpec არის open-source CLI Fission-AI-ისგან, დაარსებული Tabish Bidiwale-ის მიერ, გაშვებული Y Combinator-ის გავლით ამ წლის დასაწყისში, რომელიც გამოშვებიდან დაახლოებით ექვს თვეში ორმოცდაათ ათას GitHub-ვარსკვლავზე ზის. NPM-პაკეტი არის @fission-ai/openspec. TypeScript, საჭიროებს Node 20.19+-ს, ბოლო სტაბილური v1.3.1-ია (2026 წლის 21 აპრილი — დაახლოებით თვის წინ ამ ტექსტის წერისას).
დამფუძნებლის ჩარჩო ღირს ციტირებად, რადგან ის სამი წლის LLM-ჰაიპს ერთი წინადადებით ჭრის:
კოდის გენერაცია ახლა იაფია. სისწორე — ჯერ კიდევ ძვირი.
ეს არის მთელი დიაგნოზი. AI-ფიჩების ჩაბარების ბოთლის კისერი 2026-ში არ არის მოდელის შესაძლებლობა — Opus 4.7-მ და Codex 5.5-მ თითქმის ნებისმიერი კარგად ფორმირებული სპეციფიკაციიდან შეუძლიათ აწარმოონ მუშა იმპლემენტაცია. ბოთლის კისერი არის კარგად ფორმირებულ სპეციფიკაციამდე მისვლა, მისი სტაბილურად შენარჩუნება სესიებს შორის, პარალელური ცვლილებების იზოლირება და მათი ჭეშმარიტების წყაროში დაბრუნება დაბინძურების გარეშე. ეს არის სისტემური ამოცანა, არა promptting-ის ამოცანა.
OpenSpec ამას ისე ჭრის, როგორც backend-ინჟინერი ჭრიდა — ფაილური სისტემით, ბაზის გარეშე, ყველგან markdown-ით, და სამუშაო ნაკადით, რომელიც თითქმის ერთი-ერთზე მაპირდება Git Flow-ზე. ეი კანონიკური layout:
project_root/
└── openspec/
├── AGENTS.md # ქცევითი წესები ნებისმიერი AI-ხელსაწყოსთვის
├── project.md # გლობალური კონტექსტი — სტეკი, კონვენციები, შეზღუდვები
├── specs/ # ჭეშმარიტების წყარო — სისტემის მიმდინარე ქცევა
│ ├── auth-login/spec.md
│ ├── payment-checkout/spec.md
│ └── ...
└── changes/ # იზოლირებული სამუშაო სივრცე in-flight წინადადებებისთვის
├── add-oauth-login/
│ ├── proposal.md # "რატომ" და "რა"
│ ├── design.md # ტექნიკური მიდგომა
│ ├── tasks.md # იმპლემენტაციის ჩეკლისტი
│ └── specs/ # spec-დელტები: ADDED / MODIFIED / REMOVED
└── archive/
└── 2026-04-12-add-rate-limiting/
└── ...ორი დირექტორია ატარებს მთელ მოდელს. specs/ არის სამყაროს მიმდინარე მდგომარეობა — სისტემის ჭეშმარიტების წყარო, ორგანიზებული capability-ის მიხედვით. changes/ არის in-flight სამუშაო სივრცე; ყველა წინადადება საკუთარი საქაღალდეა, სრულად იზოლირებული, საკუთარი დელტით მიმდინარე სპეციფიკაციების წინააღმდეგ. როცა ცვლილება დამტკიცებულია და გამოყენებული, მისი დელტები ბრუნდება specs/-ში მერჯით, ხოლო proposal-ის საქაღალდე გადადის changes/archive/[date]-[name]/-ში. არქივი უცვლელია. ეს ყველაფერია. ეს არის მთელი ფაილური სისტემის კონტრაქტი.
დანარჩენი ყველაფერი — CLI, slash-ბრძანებები, AI-ხელსაწყოებთან ინტეგრაცია — ეს არის ინტერფეისი ამ კონტრაქტზე. შეიძლება წაშალო ყველა JavaScript-ფაილი node_modules-ში და მაინც გექნება კოჰერენტული SDD-კოდბაზა, რადგან მეთოდოლოგია ცხოვრობს დირექტორიის სტრუქტურაში, არა ხელსაწყოში.
ოთხ-ფაზიანი მდგომარეობათა მანქანა
CLI ექსპონირებს slash-ბრძანებების მცირე ნაკრებს, რომელიც ცვლილებას ოთხ ფაზაში გადააქვს. Claude Code-ის ან Cursor-ის მაგვარი AI-ხელსაწყოს შიგნით ბრძანებას ბეჭდავ, AI ასრულებს სამუშაოს; შენ ხედავ.
| ფაზა | ბრძანება | შექმნილი / შეცვლილი ფაილები | რა ხდება downstream |
|---|---|---|---|
| 1. Propose | /opsx:propose <feature> | openspec/changes/<feature>/ proposal.md-ით, design.md-ით, tasks.md-ით, specs/ დელტებით | არსებობს ახალი იზოლირებული სამუშაო სივრცე; ჭეშმარიტების წყაროში არაფერი არ შეცვლილა |
| 2. Define | openspec validate | ახალი ფაილები არ არის; ანგარიშობს სპეციფიკაციის სინტაქსის / სცენარების შეცდომებს | სტატიკური ანალიზი spec-დელტაზე სანამ კოდი დაიწერება |
| 3. Implement | /opsx:apply | წყაროს კოდის ცვლილებები, ამოცანების ჩექბოქსები მონიშნული | AI ასრულებს tasks.md-ს მკაცრად შეთანხმებული სპეციფიკაციის წინააღმდეგ; შენ ერთად ხედავ კოდის დიფებსა და spec-დელტებს |
| 4. Archive | /opsx:archive | specs/ განახლებულია მერჯირებული დელტებით; proposal გადავიდა changes/archive/[date]-<feature>/-ში | ჭეშმარიტების წყარო ასახავს სისტემის ახალ მდგომარეობას; დაარქივებული proposal არის მუდმივი ისტორია |
კონკრეტული end-to-end:
შენ: /opsx:propose add-dark-mode
AI: შეიქმნა openspec/changes/add-dark-mode/
✓ proposal.md (დასაბუთება, წარმატების კრიტერიუმები)
✓ design.md (theme-კონტექსტი, CSS-ცვლადები, პერსისტენტი)
✓ tasks.md (8 ამოცანა 3 კომპონენტზე)
✓ specs/theme/spec.md (ADDED: 4 სცენარი)
შენ: openspec validate
✓ ყველა სცენარი კარგად ფორმირებულია
✓ კონფლიქტი არსებულ სპეციფიკაციებთან არ არის
შენ: /opsx:apply
AI: ✓ 1.1 დაამატე theme context provider
✓ 1.2 შექმენი toggle-კომპონენტი
✓ 2.1 დაამატე CSS-ცვლადები მუქი პალიტრისთვის
...
შენ: /opsx:archive add-dark-mode
✓ სპეციფიკაციები მერჯირებულია openspec/specs/theme/-ში
✓ Proposal დაარქივებულია openspec/changes/archive/2026-05-21-add-dark-mode/-შიმთელი ციკლი, “მინდა მუქი თემა”-დან “მუქი თემა main-ში სპეციფიკაციით”-მდე — ერთი ტერმინალის სესიაა. სპეციფიკაცია არის გრძელვადიანი არტეფაქტი; კოდი მისი შედეგია. არქივი არის ისტორია.
რატომ არის filesystem-as-state-machine სწორი არჩევანი
ხერხი აქ არ არის CLI-ში. ხერხი ისაა, რომ ვიღაცამ ბოლოს დასჯდა და იკითხა: როგორი იქნებოდა Git, თუ Git-ი კოდის ნაცვლად ქცევას ვერსიონირებდა? და მერე ეს განახორციელა ბაზის გარეშე, სერვისის გარეშე, ცენტრალიზებული სერვერის გარეშე — უბრალოდ ფაილებით დირექტორიაში და ოთხ-ბრძანებიანი მდგომარეობათა მანქანით.
მაპინგი ერთი-ერთზე ემთხვევა ინტუიციებს, რომელიც ყველა backend-ინჟინერს უკვე აქვს.
| Git-ცნება | OpenSpec-ეკვივალენტი | შენიშვნები |
|---|---|---|
main ბრენჩი | openspec/specs/ | ჭეშმარიტების წყარო; სამყაროს მიმდინარე მდგომარეობა |
| Feature ბრენჩი | openspec/changes/<feature>/ | იზოლირებული სამუშაო სივრცე; არ აბინძურებს main-ს მერჯამდე |
| დიფი | Spec-დელტა (ADDED / MODIFIED / REMOVED სცენარები) | ტექსტად ხედავ, ხაზობრივი ისტორია |
| მერჯი | /opsx:archive | ატომური; დელტები გამოყენებულია, proposal გადავიდა ისტორიაში |
git log | openspec/changes/archive/ | Append-only ისტორია ყოველი ცვლილებისა შენარჩუნებული დასაბუთებით |
| Pre-commit hook | openspec validate CI-ში | იჭერს ცუდად ფორმირებულ სპეციფიკაციებს რევიუმდე |
როცა მაპინგს დაინახე, ნებისმიერი სხვა SDD-ხელსაწყო ნაკლებად დაპროექტებული გამოიყურება. GitHub Spec Kit მძიმეა და მკაცრი; ის ფაზურ კარიბჭეებს ახვევს და source-of-truth სპეციფიკაციებს inline-ზე ცვლის, რაც ნიშნავს, რომ ორი ინჟინრის პარალელური წინადადებები ერთსა და იმავე ფაილზე შეჯახდებიან. AWS Kiro Kiro IDE-ზე და კერძოდ Claude-მოდელებზე გაბმავთ — ნორმაა, თუ უკვე AWS-shop ხართ, ფატალურია სხვა შემთხვევაში. Tessl — პურისტური პოზიცია (“კოდი რეკონსტრუირდება სპეციფიკაციიდან”), ფილოსოფიურად სუფთა და ოპერაციულად მტკივნეული — რეალური კოდბაზების უმეტესობას აქვს ხელით ნაწერი კოდი, რომელიც გენერირებულ კოდთან ერთად უნდა იარსებოს. BMAD, Google-ის Antigravity და სხვა SDD-ფრეიმვორქების მუშტი, რომელიც 2026-ში იგზავნება, სხვადასხვა ფსონებს დებენ, მაგრამ თითქმის ყველა greenfield-ს ვარაუდობს — ახალი პროექტი, ცარიელი რეპო, სუფთა ფურცელი.
Brownfield არის სადაც სამუშაო რეალურად არის. ყველა გუნდი, რომელსაც ვაფასებ, კოდბაზაში აბარებს, რომელსაც წლები ასწორებდნენ, კომპანიიდან წასული ხალხი, კონვენციებით, რომელიც README-ს არ ემთხვევა, დირექტორიებში, რომელიც პროდუქტებზე იყო დასახელებული, რომელიც ორჯერ გადაერქვა. OpenSpec-ის მთელი არქიტექტურა ამ რეალობისთვის არის აშენებული. specs/ დირექტორია არსებულ პროექტზე შეიძლება დაერთოს — არსებობს დოკუმენტირებული retrofitting რეჟიმიც, სადაც AI-ს თხოვ, რომ არსებული კოდიდან სპეციფიკაციები უკუ-ინჟინერია, რითაც აწარმოებს საბაზო დოკუმენტაციას სისტემებისთვის, რომელსაც არასოდეს ჰქონდა. ეს არის ნამდვილი გახსნა. არა “spec-driven პირველი დღიდან” — spec-driven მესამე წლიდან.
Backend-არქიტექტორმა, რომელიც ამას კითხულობს, უნდა შენიშნოს, რომ OpenSpec რეალურად აბარებს workflow-engine-ს content-addressed store-ის თავზე, და მისამართებას ფაილური სისტემა აკეთებს. ეს ყველაფერი USB-ფლეშზე ეტევა. არ არსებობს სერვისი, რომელიც უნდა ექსპლუატირდეს, არ არსებობს consensus-პროტოკოლი დებაგისთვის, არ არსებობს API ვერსიონირებისთვის. ეს არის რეალური იდეის ყველაზე მსუბუქი შესაძლო რეალიზაცია, და სწორედ ამიტომ ის უკვე იგებს SDD-ეკოსისტემას.
PR-ის ფორმა ამის downstream იცვლება. ძველ სამყაროში რევიუერი ხსნის PR-ს, ხედავს 600-ხაზიან დიფს, სქროლავს, იმედი აქვს, რომ შუაში მნიშვნელოვანი არაფერი იმალება, და ამტკიცებს. OpenSpec-ფორმის PR-ში სხეული არის proposal.md + design.md + spec-დელტა. რევიუერი კითხულობს სამოც ხაზიან სპეციფიკაციას, სვამს ერთ კითხვას ორაზროვან სცენარზე და ამტკიცებს. 600-ხაზიანი კოდის დიფი sanity-check-ად ნახულობს — ეს არის შედეგი შეთანხმებული ცვლილებისა, არა თვითონ ცვლილება. ეს არის სამუშაო ნაკადის ცვლილება, რომელზეც Spec-Driven Development უთითებდა; OpenSpec არის პირველი ხელსაწყო, რომელიც ამას რეალურად აბარებს brownfield-გუნდზე.
როგორ ეხება ეს კომპონენტების დიზაინს
OpenSpec-ს უმთავრესად backend-leaning ინჟინრები აღწერენ და დემონსტრირებენ, რაც დაფარა რაღაც სათქმელი: ეს ჩუმად-შესანიშნავი frontend-ხელსაწყოა.
მიზეზი ფაილების layout-ში არის. ყოველი ქცევითი capability იღებს საკუთარ საქაღალდეს openspec/specs/-ის ქვეშ. Component-heavy frontend-ისთვის ეს მაპირდება ასე:
openspec/specs/
├── ui-button/spec.md
├── ui-form-field/spec.md
├── auth-login-form/spec.md
├── checkout-cart/spec.md
├── nav-language-switcher/spec.md
└── ...ყოველი spec.md შეიცავს სცენარებს GIVEN / WHEN / THEN ფორმატში — მაგალითად, ლოგინის ფორმისთვის:
სცენარი: 2FA-ჩართული მომხმარებელი აგზავნის ვალიდურ რწმუნებებს
GIVEN მომხმარებელს ჩართული აქვს 2FA
AND მომხმარებელმა გააგზავნა ვალიდური email და პაროლი
WHEN ფორმა იგზავნება
THEN სერვერი აბრუნებს OTP-გამოწვევას
AND ფორმა გადადის OTP-შესვლის მდგომარეობაში
AND email/პაროლის ველები გათიშულია
სცენარი: ფორმის გაგზავნა არასწორი email ფორმატით
GIVEN email ველი შეიცავს "not-an-email"
WHEN მომხმარებელი ველს ბლერავს
THEN ველი აჩვენებს inline ვალიდაციის შეცდომას
AND submit ღილაკი დარჩება გათიშულიეს არ არის ახალი ფორმატი. ეს იგივე მონაცემთა ფორმაა, რომელსაც შენი Playwright-ტესტები უკვე იყენებენ. იგივე ფორმაა, რომელსაც Storybook play-ფუნქციები უკვე იყენებენ. იგივე ფორმაა, რომელშიც შენი QA-გუნდი user story-ებს უკვე წერს. მიზეზი, რომ frontend-გუნდების უმეტესობა სპეციფიკაციებს არ წერს — არ არის ის, რომ ფორმატი უცნობია — ისაა, რომ ფორმატს კანონიკური სახლი არ ჰქონდა. OpenSpec მას სახლს აძლევს.
რა ეხსნება frontend-ისთვის:
- A11y, i18n, design tokens და responsive-შეზღუდვები ხდება first-class spec-კონტენტი გაფანტული კომენტარების ნაცვლად. “ღილაკი მობილზე უნდა აღწევდეს მინიმუმ touch-target 44×44-ს” აღარ არის Slack-შეტყობინება და ხდება სცენარი, რომელიც რევიუვდება, როცა სპეციფიკაცია რევიუვდება.
- დიზაინერს შეუძლია UX-წინადადება spec-დელტად ჩააბაროს, ხოლო ინჟინერი data-layer-წინადადებას ცალკე spec-დელტად აბარებს. ეს ორი ერთსა და იმავე ფაილს არასოდეს ეხება. ისინი დამოუკიდებლად მერჯირდება
specs/-ში. მერჯ-კონფლიქტი არ არის, რადგან არ არსებობს გაზიარებული ცვალებადი მდგომარეობა — ყოველი წინადადება იზოლირებულია by design. - კომპონენტის რეფაქტორი წყვეტს ყოფას “ფორმა გადავწერე” და ხდება “მე MODIFIED ორი სცენარი და ADDED ერთი”. რევიუერებს ხედავენ, რომელი ქცევა შეიცვალა. თუ სცენარი არ შეცვლილა — ქცევა არ შეცვლილა, და რევიუერს შეუძლია იმპლემენტაციას ენდოს.
სად იჭიმება ეს — და თუ ამას არ ვიტყვი, რაღაცას გაყიდიდი — ეს არის ძალიან ვიზუალურ სამუშაოზე. ანიმაციის ტაიმინგი, layout-as-art, მიკრო-ინტერაქციები, რომელიც მოძრაობასა და ფერების გადაწყვეტილებებზე იყრება: ეს GIVEN / WHEN / THEN-ში სუფთად არ ჯდება. ჯერ კიდევ საჭიროა visual-regression evals, screenshot-დიფები, design-system stories. OpenSpec ამას არ ცვლის. მაგრამ ის ნიშნავს, რომ ქცევითი შრე — რას აკეთებს ეს კომპონენტი, როდის, ვისთვის, რა შედეგით — აქვს კანონიკური სახლი, რაც ნიშნავს, რომ წყვეტს ვიზუალურ შრესთან სივრცისთვის ბრძოლას.
Frontend-არქიტექტორის tell აქ — ის, რომ
GIVEN / WHEN / THENბაიტი-ბაიტში იგივე მონაცემთა ფორმაა, რომელსაც შენი Playwright-სპეციფიკაცია უკვე იყენებს. შენ არ სწავლობ ახალ ფორმატს. შენ სწავლობ სად დადო ის, რომელიც გაქვს, რომ ის შეწყვიტოს ობოლი ყოფა საქაღალდეში, რომელსაც არავინ კითხულობს.
ეს ასევე ის ადგილია, სადაც evals-ის დისციპლინა ბუნებრივად ხვდება OpenSpec-ს. ყოველი სცენარი სპეციფიკაციაში — მექანიკურად — eval-შესასვლელია. პაიპლაინი, რომელიც openspec/specs/**/spec.md-ს კითხულობს, სცენარებს იღებს და მათ Playwright-ტესტებად ატარებს განთავსებული preview-ის წინააღმდეგ, შაბათ-კვირის პროექტია. როცა ის არსებობს, სპეციფიკაცია წყვეტს aspirational ყოფას — ის ვერიფიცირდება ყოველ PR-ზე, ნებისმიერი განსხვავება სპეციფიკაციასა და იმპლემენტაციას შორის არის CI-ვარდნა, არა რევიუს ესკალაცია.
კონტექსტ-ინჟინერია სხვა სახელით
პირველად, როცა OpenSpec-ის დოკები წავიკითხე, კონკრეტული შეგრძნება მქონდა ძველი იდეის ახალ ტანსაცმელში ცნობისა.
დოკები პირდაპირ ამბობს: “როცა კონტექსტის გამოყენება 40%-ს აღემატება, AI-ის შესრულება მნიშვნელოვნად დეგრადირდება, წინა მოთხოვნების დეტალები იკარგება”. ეს არ არის OpenSpec-ის აღმოჩენა; ეს არის long-context LLM-ის ცნობილი თვისება 2026-ში, და ეს არის მთელი მიზეზი, რის გამოც კონტექსტ-ინჟინერია არის დისციპლინა, რომელიც მნიშვნელოვანია. საინტერესოა, რას აკეთებს ამასთან OpenSpec.
OpenSpec-ის სამუშაო ნაკადი, რანტაიმში, არის load-on-demand კონტექსტის სტრატეგია. როცა AI იწყებს სესიას, ის კითხულობს სამ ფაილს: openspec/project.md (გლობალური სტეკი, კონვენციები, ~200 ხაზი), openspec/changes/<active>/tasks.md (მიმდინარე ფოკუსი, ~50 ხაზი) და კონკრეტული openspec/specs/<capability>/spec.md ფაილები, რომელზეც ამოცანა მიუთითებს (~100 ხაზი თითო). ეს არის დაახლოებით 500–1,000 ტოკენი კურირებული, მაღალი სიმკვრივის კონტექსტისა — არა 50,000 ტოკენი “აი მთელი რეპო, თვითონ მოახერხე”.
ყოველი პრობლემა, რომელსაც კონტექსტ-ინჟინერია იდენტიფიცირებს — კონტექსტური ფანჯრის გათხელება, hot/warm/cold ფენიერება, ტოკენების ეკონომიკა, ევიქციის სტრატეგია, planning context vs execution context — აქ წყდება დირექტორიის layout-ით. Hot-შრე არის tasks.md. Warm-შრე არის ნახსენები spec.md-ფაილები. Cold-შრე არის დარჩენილი specs/ და მთელი archive/, ხელმისაწვდომი მოთხოვნისას ჩასატვირთად, მაგრამ ნაგულისხმევად არ გადახდილი. შენ არ კონფიგურირებ კონტექსტურ პაიპლაინს. შენ იყენებ ხელსაწყოს, რომელშიც სწორი პაიპლაინი ჩაშენებულია მის ფაილურ სტრუქტურაში.
ასევე არის ისტორია მეხსიერების შესახებ. Plan mode ქრება, როცა მოდელი გადატვირთულია; საუბრის ისტორია ორთქლდება სესიებს შორის; საუკეთესო long-context მოდელიც ვერ ახსოვს, რა გადაწყვიტე გასული სამშაბათს. სპეციფიკაციები ამას ცერემონიის გარეშე წყვეტს: ეს არის ფაილები, ვერსიონირებული, გრძელვადიანი, ტრივიალურად ჩასატვირთი. OpenSpec-პროექტის “მეხსიერება” არის specs/ დირექტორია. OpenSpec-პროექტის “აზროვნება” არის changes/ დირექტორია. თითოეული შემოსაზღვრულია, ინსპექციად, რესტარტებს გადარჩება. ეს არის ის, რასაც ნებისმიერი agent-ფრეიმვორქი, რომელიც გამიყენებია, ცდილობდა აეშენებინა ვექტორული საცავებიდან და KV-ქეშებიდან, ხოლო OpenSpec ამას აბარებს როგორც .md-ფაილებს საქაღალდეში.
აქ უფრო დახვეწილი თვისებაცაა, რომელიც ბრძოლის რამდენიმე კვირაში ვისწავლე დაფასებას. რადგან OpenSpec-სპეციფიკაციები GIVEN / WHEN / THEN-ში არის ნაწერი, ყოველი სცენარი ბუნებრივად eval-ფორმირებულია. შეგიძლია მთელი specs/ ხის scrape გააკეთო, თითო სცენარი ტესტ-კეისად ჩათვალო და ის შენი eval-ჰარნესის კანონიკურ კორექტულობის კრიტერიუმად მიაწოდო. შენ evals-ს ცალკე არ წერ — ისინი არიან სპეციფიკაცია, საკმარისად სტრუქტურირებულ ფორმაში, რომ მანქანის მიერ მოპოვებადი იყოს. ეს არის უნიფიკაცია, რომელსაც eval-პოსტის ბოლოს ვაცხადებდი, და OpenSpec არის პირველი ხელსაწყო, რომელიც იქ ცერემონიის ნაცვლად შემთხვევით აღწევს.
AI-არქიტექტორმა უკვე იცის, რა ხდება აქ: ეს არის load-on-demand context engineering, CLI-ქუდი ჩამოცმული. საინტერესოა, რომ ეს ასწავლის დისციპლინას ინჟინრებს, რომელთაც არ იციან, რომ ის სჭირდებათ. ნახევარი წლის შემდეგ ინჟინერი, რომელიც OpenSpec-ს ყოველდღე იყენებს და კონტექსტ-ინჟინერიის სტატია არასოდეს არ უკითხავს, იქნება კონტექსტ-ინჟინერი, ჩვევით, ტერმინი არასოდეს მოუსმენია.
პრაქტიკული ნოტა მოდელების შესახებ. OpenSpec მუშაობს ოცდახუთ+ AI-ხელსაწყოსთან, მაგრამ არ მუშაობს თანაბრად კარგად ყველასთან. სპეციფიკაციები არის markdown, რომელიც კარგად მისაწერად საჭიროებს მსჯელობას — capability-ის დასახელება, ამოცანების დეკომპოზიცია, სცენარების წერა, რომელიც კიდურა შემთხვევებს ფარავს — და იაფი მოდელები ზედაპირულ სპეციფიკაციებს აწარმოებენ. საზოგადოების კონსენსუსი, რომელიც ემთხვევა იმას, რაც ორ პროდაქშენ-კოდბაზაში დავინახე: Opus 4.7 ან Codex 5.5 propose-სა და apply-ისთვის. პატარა მოდელები archive-სა და validate-ს უმკლავდებიან. თუ Haiku-ფენის მოდელს /opsx:propose-ზე გადააბამ, მიიღებ სპეციფიკაციებს, რომელიც სარწმუნოდ გამოიყურება და მესამე კიდურა შემთხვევას ყოველთვის ცდება. გადაიხადე მსჯელობისთვის იქ, სადაც მსჯელობას აქვს მნიშვნელობა.
ხუთი წესი, რომელიც OpenSpec-ით ჩაბარებისას გამოვიმუშავე
დანომრილია, რადგან ორ პროდაქშენ-კოდბაზაში ექვს კვირაში გამოვიმუშავე, არ მოვიყვანე დოკების გვერდიდან.
1. openspec validate CI-ს ბლოკავს პირველი დღიდან, არა “მერე”. ვალიდაცია არის spec-ეკვივალენტი type-check-ისა. მის გარეშე ცუდად ფორმირებული სცენარები specs/-ში გადადის, და კვირაში გექნება “სპეციფიკაცია”, რომელიც სინამდვილეში გაუპარსებელი პროზაა, შენი spec-to-eval პაიპლაინი კი ჩუმად ნახევარს ცდის. დაამატე openspec validate როგორც სავალდებულო ნაბიჯი pre-commit hook-ში და როგორც დამბლოკავი CI-შემოწმება პირველ დღეს, როცა ხელსაწყოს იღებ. არა მეორე. პირველ.
2. project.md მოკლე და კონკრეტულია, არა გრძელი და aspirational. ეს არის გლობალური კონტექსტი, რომელსაც ყოველი აგენტი პირველად კითხულობს, ყოველ სესიაზე. ჭერი — 200 ხაზი. დაასახელე სტეკი (“Next.js 16, Tailwind 5, Postgres, Drizzle ORM”). დაასახელე კონვენციები (“ვიყენებთ Result-ტიპებს, არა throw-ს”). დაასახელე უარყოფები (“არ გამოვიყენებთ any-ს TypeScript-ში; არც eval-ს; არც პირდაპირ DB-წვდომას ჰენდლერებიდან”). გამოტოვე მარკეტინგი. გამოტოვე team mission statement. აგენტი არ არის შენი ინვესტორი.
3. არქივი უცვლელია. არასოდეს არ ცვალო openspec/changes/archive/*. მოეპყარი მას, როგორც Git-ისტორიას. თუ წარსული გადაწყვეტილების გადახედვა საჭიროა — წერ ახალ proposal-ს, რომელიც მას ცვლის; ახალი proposal ძველს მიუთითებს, არქივი იზრდება. დღე, როცა ვინმე დაარქივებულ proposal-ს “უბრალოდ შეცდომა შევასწორო”-დ შეცვლის, არის დღე, როცა ისტორია არასანდო ხდება, ხოლო რამდენიმე თვის შემდეგ რეგრესიას ადებაგებ და არქივი გტყუებს. არ ღირს.
4. რევიუ spec-დელტას, არა კოდის დიფს. ეს არის ყველაზე მაღალი ბერკეტის სამუშაო ნაკადის ცვლილება, რომელიც 2026-ში გავაკეთე, და სამი კვირა დამჭირდა მის შინაგანი მისაღებად. PR-ის სხეული უნდა იყოს proposal, design-summary და spec-დელტა — ეს არის ის, რასაც ხალხი კითხულობს. კოდის დიფი არის sanity-check საუკეთესო შემთხვევაში. თუ spec-დელტა სწორია და კოდი გადის validator-ს და evals-ს, კოდი სწორია; თუ spec-დელტა არასწორია, კოდიც არასწორია, მაგრამ კოდი იყო არასწორი, რადგან სპეციფიკაცია იყო არასწორი, ხოლო კოდის შესწორება სპეციფიკაციის შესწორების გარეშე ბაგს უბრალოდ აყოვნებს. რევიუერები, რომელიც spec-დელტას პირველად კითხულობენ, უკეთეს კოდს აბარებენ, ვიდრე რევიუერები, რომელიც კოდს პირველად კითხულობენ.
5. არ გამოიყენო OpenSpec საძიებო სამუშაოსთვის. ეს იგივე გაფრთხილებაა, რომელიც Spec-Driven Development-ში დავასახელე, ორმაგი ძალით. ვერ დაასპეციფიცირებ იმას, რასაც ჯერ არ ხვდები. თუ research-ფაზაში ხარ — ხედავ, იმუშავებს თუ არა მიდგომა, API-ის ფორმებს ხატავ, მტყუნების რეჟიმებს სწავლობ — წერე კოდი ხელით, წაიკითხე გამოსავალი, შემდეგ ამოიღე სპეციფიკაცია იქიდან, რაც იმუშავა. Spec-after, არა spec-first. შეცდომა, რომელსაც ახალი adopter-ები აკეთებენ, არის OpenSpec-ისკენ ხელის გაწვდენა research-spike-ის პირველ დღეს. ასე გექნებათ ორმოცდაათ-ხაზიანი სპეციფიკაცია იმაზე, რომელიც ორი დღის შემდეგ აღმოჩნდება სამი სხვადასხვა რამ. გამოიყენე ცნობილი სამუშაოსთვის, არა უცნობისთვის.
სად იშლება ეს მაინც
გულწრფელი აღრიცხვა. ხელსაწყოს გავყიდიდი, არა მეთოდოლოგიას, თუ წესებზე გავჩერდი.
- ძალიან ვიზუალური / animation-heavy სამუშაო
GIVEN / WHEN / THEN-ში სუფთად არ ჯდება. შეინარჩუნე visual-regression-სიუტი. OpenSpec არის ქცევითი შრისთვის, არა ესთეტიკურისთვის. - Research-ფაზის კოდი ჯერ კიდევ უკეთესია ხელით ნაწერი spec-after-extraction-ით. ნუ ებრძვი ამას.
- იაფი მოდელის სეტაპები ზედაპირულ სპეციფიკაციებს გვაძლევენ. თუ შენი AI-ბიუჯეტი მთელ ფრონტზე haiku-ფენისაა, შენ თვითონ მოგიწევს სცენარების წერა, რომელიც კიდურა შემთხვევებს იჭერს, და ხელსაწყო მამრავლის ნაცვლად დამამუხრუჭებლად გადაიქცევა. გადაიხადე high-reasoning მოდელისთვის იქ, სადაც მნიშვნელოვანია — propose, apply, validate. დაზოგე archive-ზე, თუ უნდა.
- ეკოსისტემის ფრაგმენტაცია რეალურია. SpecKit, Kiro, BMAD, Antigravity, Tessl და OpenSpec ყველა გინდა იყოს SDD-ფრეიმვორქი, რომელსაც ღებულობ, და ისინი სუფთად არ ინტერპერირებენ. აირჩიე ერთი. შენი გუნდი მასზე ჩააწერ. გადართვის ხარჯები მაღალია, ვიდრე დოკები აღიარებენ; შენ მხოლოდ CLI-ს არ სწავლობ, კოდირებ მთელი გუნდის change-დისციპლინას ხელსაწყოს ფორმაში.
- ტელემეტრია არის opt-out, არა off-by-default. OpenSpec აგროვებს ანონიმური ბრძანების სახელისა და ვერსიის მონაცემებს, თუ არ დააყენე
OPENSPEC_TELEMETRY=0ანDO_NOT_TRACK=1. გუნდების უმეტესობისთვის ეს ნორმაა. რეგულირებად გარემოში გუნდებისთვის ან მკაცრი data-handling პოლიტიკით — ეს არის ერთხაზიანი კონფიგი shell-პროფილსა და CI-ში, მაგრამ ამის შესახებ უნდა იცოდე. - Brownfield retrofitting მუშაობს, მაგრამ უფასოდ არ. რეკლამირებული სამუშაო ნაკადი “სთხოვე AI-ს უკუ-ინჟინერია სპეციფიკაციები შენი კოდიდან” მუშაობს — ეს გამოვიყენე ექვს ათას ფაილიან კოდბაზაზე — მაგრამ პირველი გავლა იძლევა descriptive-სპეციფიკაციებს, არა prescriptive-ს. ისინი გეუბნებიან, რას აკეთებს კოდი, არა რა უნდა გააკეთოს. შემდეგ გჭირდება მეორე გავლა მარყუჟში ადამიანით, რომ descriptive-სპეციფიკაციები რეალური განზრახვის კოდირებად აქციოს. დაგეგმე ეს. არ ჩააბარო პირველი გავლის სპეციფიკაციები შენი ჭეშმარიტების წყაროდ.
გულწრფელი ჩარჩო: OpenSpec არის სწორი ხელსაწყო ოთხმოცდაათი პროცენტი სამუშაოსთვის მომწიფებულ 2026-ის კოდბაზაში, და დარჩენილი ათი პროცენტი მნიშვნელოვანია. სენიორი ინჟინერი არის ის, ვინც განასხვავებას ხედავს.
კარიერული კუთხე
“მაჩვენე შენი eval-სიუტი” იყო კითხვა, რომელიც ამ წელს AI-საინჟინრო ინტერვიუებში ვიწყე. “მაჩვენე შენი OpenSpec-სამუშაო ნაკადი” — ან SpecKit, ან Kiro, მაგრამ რომელიმე SDD-ოპერაციული მოდელი რეალური ფორმით — ეს არის კითხვა, რომელიც ბოლო ორ თვეში მას შეუერთდა. პასუხის ხარისხი კანდიდატზე უფრო მეტს ამბობს, ვიდრე ნებისმიერი სხვა ცალკეული სიგნალი.
ბაზარს ეს ჯერ არ შეუფასებია. ინჟინრები, რომელთაც შეუძლიათ კოჰერენტული spec-driven ოპერაციული მოდელის არტიკულირება — რა ცხოვრობს project.md-ში და რა არა, სად არის ცვლილების საზღვრები, როგორ იცვლება PR-რევიუ, როგორ ინტეგრირდება evals — ისევ ერთციფრიანი პროცენტი კანდიდატთა აუზისა, რომელსაც ვხედავ. პრემია შემცირდება დისციპლინის სტანდარტული პრაქტიკის გახდომის შესაბამისად, იმავე გზით, რომელიც unit-testing-მა 2005-დან 2015-მდე გამოიარა. ჩემი შეფასება — თვრამეტი თვე, სანამ SDD-ის რომელიმე flavor-ში ფლუენტობა გახდება table stakes სენიორი AI-საინჟინრო როლებისთვის.
80/20, თუ მეტს არაფერს კითხულობ: აიღე პროდაქშენ AI-ფიჩა, რომელსაც ფლობ. დააყენე OpenSpec მასზე ამ კვირაში. ჩაამატე სპეციფიკაციები არსებული ქცევისთვის ორ გავლაში — სასწავლოდ descriptive-ში, შემდეგ ადამიანის რედაქტირებული prescriptive-ში. გაატარე ერთი სრული proposal-to-archive ციკლი რეალურ ცვლილებაზე. კვირაში აღმოაჩენ, რომ შენი ძველი სამუშაო ნაკადი სამ ადგილას გამოცნობაზე იდგა — განზრახვაზე, სკოპზე, ვერიფიკაციის გამცეზე — და OpenSpec-მა სამივე ისეთ ფაილებად აქცია, რომელზეც თითის ჩამოვლება შეგვიძლია. ეს აღმოჩენა არის მთელი უნარი.
უფრო ღრმა აზრი
გაკვეთილი არ არის “გამოიყენე OpenSpec”. გაკვეთილი ისაა, რომ როცა მეთოდოლოგიას ასეთი კარგი ხელსაწყო უჩნდება, ის ხალხი, ვინც უკვე ხვდებოდა მეთოდოლოგიას, ათჯერ აკომპაუნდებს ბერკეტს, ხოლო ისინი, ვინც არ ხვდებოდა, მიიღებენ შესაძლებლობას ისწავლონ მეთოდოლოგია ხელსაწყოს გამოყენებით. ეს ასიმეტრია არის 2026-ის ინჟინერიის კარიერული ისტორია.
Spec-driven development იყო ფილოსოფია სამი წლის წინ. გახდა პრაქტიკა 2025-ში. 2026-ში ხდება ოპერაციული სისტემა, და OpenSpec არის ამ სისტემის დღემდე ჩაბარებული ყველაზე მსუბუქი იმპლემენტაცია. საინტერესო კითხვა აღარ არის “ღირს თუ არა spec-driven development-ის გაკეთება?”. არის “რომელ SDD-ოპერაციულ მოდელს ვაკომიტავ ჩემს გუნდს, და რამდენად სწრაფად შემიძლია ჩავამატო კოდბაზაში, რომელიც უკვე მაქვს?”
თუ უფრო ღრმად გინდათ, ქვემოთ მოცემული კურსები მოიცავს დისციპლინის იმ ნაწილებს, რომლებსაც ყველაზე ხშირად ვასწავლი: Claude Code Mastery: Agentic Coding for Engineers — ყოველდღიური slash-command სამუშაო ნაკადი ხელსაწყოს შიგნით, რომელიც საუკეთესოდ ეწყვილება OpenSpec-ს, Building Agents with the Claude Agent SDK — აგენტების აშენება, რომლებიც სპეციფიკაციებს first-class შესასვლელად მოიხმარს და გამოსავლად აწარმოებს, Building MCP Servers & AI Tool Integrations — OpenSpec-სამუშაო ნაკადის გაფართოება MCP-მომსახურებული capability-ით, და Building LLM-Powered Apps: RAG & Agents — GIVEN / WHEN / THEN სცენარების შენი სპეციფიკაციებიდან მუშა evals-ჰარნესში პროდაქშენ-ტრაფიკზე გაყვანა.
