AI-Native SDLC: როცა კოდი ბოთლის ყელი აღარ არის

აი, უხერხული პატერნი, რომელიც agentic-coding-ის მრავალი დანერგვის უკან დგას: build ეტაპი დრამატულად აჩქარდება, ხოლო იდეიდან პროდაქშენამდე გასავლელი დრო თითქმის არ იცვლება.

აგენტებს არაფერი უშავთ. პრობლემა ყველაფერშია, რაც მათ გარშემოა. დამტკიცების gate-ები, refinement-შეხვედრები, რევიუს რიგი, ყოველკვირეული change board — ყველაფერი ეს შექმნილი იყო სამყაროსთვის, სადაც კოდის წერა მიწოდების ყველაზე ძვირი ეტაპი იყო. ის სამყარო წავიდა. მისთვის აშენებული პროცესი კი ისევ აქაა და ახლა სწორედ ის არის ბოთლის ყელი.

2026 წლის აგვისტოში Anthropic-მა გამოაქვეყნა The AI-Native SDLC Playbook — გრძელი, პრაქტიკული დოკუმენტი იმის შესახებ, როგორ უნდა ავაგოთ პროგრამული უზრუნველყოფის სასიცოცხლო ციკლი ამ რეალობის გარშემო. ღირს მისი სრულად წაკითხვა. ეს პოსტი ჩემი, როგორც ინჟინრის, წაკითხვაა: რა არის მთავარი იდეა, რომელი ნაწილებია, ჩემი აზრით, ყველაზე მნიშვნელოვანი, სად ვიქნებოდი ფრთხილად და როგორ უკავშირდება ის დისციპლინებს, რომლებსაც ამ სერიაში ვაშუქებდით — spec-driven development, context engineering და evals.

რატომ ტყდება ძველი SDLC აგენტებთან

კლასიკურ სასიცოცხლო ციკლს ექვსი ეტაპი აქვს — plan, design, build, test, deploy, maintain — და თითოეულს ჰყავს მფლობელი. Product წერს მოთხოვნებს. Architecture წერს დიზაინებს. ინჟინრები აშენებენ. QA ამოწმებს. Release აგზავნის. Ops უყურებს. სამუშაო ეტაპებს შორის დოკუმენტების, ტიკეტებისა და sign-off-ების სახით გადადის.

ეს ფორმა აზრიანი იყო. როცა იმპლემენტაცია კვირებს ან თვეებს გრძელდებოდა, წინასწარი მძიმე შეთანხმება გინდოდათ: PRD-ები, შეფასება, უსაფრთხოების რევიუები. სისტემის ყოველი კონტროლი ჩუმად გულისხმობს, რომ ყოველ ნაბიჯს ადამიანი ასრულებს და ყოველ ხაზს ადამიანს შეუძლია გადახედოს.

გახადეთ build ეტაპი თითქმის უფასო და სამი რამ მოხდება:

1. ბოთლის ყელი გადაინაცვლებს. Planning, review და deployment ისევ ადამიანის სიჩქარით მუშაობს. ისინი სისტემის ყველაზე ნელ ნაწილად იქცევიან.
2. ხაზ-ხაზ რევიუ აღარ მასშტაბირდება. როცა diff-ის უმეტესობას აგენტები წერენ, „ადამიანი ყოველ ხაზს კითხულობს” იქცევა ან უსასრულო რიგად, ან რეზინის შტამპად.
3. Governance ძვირდება. გამონაკლისები, რომლებიც ყოველთვიურ კომიტეტს ელოდება, ახლა ბლოკავს სამუშაოს, რომელიც ერთ შუადღეში დასრულდა.

უსაფრთხოება ყველაზე მკვეთრი მაგალითია. უსაფრთხოების გუნდი, რომელიც ადამიანის გამომუშავებაზეა გათვლილი, არჩევანის წინაშე დგას: რიგი გაზარდოს თუ ნაკლებად გადამოწმებული კოდი გაუშვას. რეგულირებად კომპანიას არც ერთი არ შეუძლია. მისი შემოწმებები აგენტის გამომუშავებასთან ერთად უნდა მასშტაბირდეს — ანუ ისინი ვეღარ იქნება წმინდა ადამიანური.

რას ნიშნავს „AI-native” სინამდვილეში

Playbook-ის განმარტება ის ნაწილია, რომელიც ყველაზე სასარგებლოდ მიმაჩნია, რადგან ის არ არის „დაამატე AI ყოველ ნაბიჯზე”. ის ასეთია: შეინარჩუნე კონტროლის მიზნები, შეცვალე მათი აღსრულების გზა. თქვენ ისევ გინდათ traceability, მოვალეობათა გამიჯვნა, დამოწმებული ცვლილებები და ავტორიზებული რელიზები. უბრალოდ წყვეტთ მათ აღსრულებას შეხვედრებითა და ხელით კითხვით და იწყებთ აღსრულებას არტეფაქტებით, hooks-ითა და ავტომატური შემოწმებებით.

აქედან სამი სტრუქტურული ცვლილება გამომდინარეობს:

• ხაზი ხდება ციკლი. პროდაქშენის სიგნალები ავტომატურად ბრუნდება planning-ში, იმის ნაცვლად, რომ post-mortem-ს დაელოდოს, რომელსაც შეიძლება არავინ მიჰყვეს.
• Handoff-ები ხდება კომიტები. ყოველი ეტაპი სრულდება არტეფაქტის ვერსიის კონტროლში commit-ით, და შემდეგი ეტაპი მას კითხულობს.
• ადამიანები წარმოებიდან განსჯაზე გადადიან. ადამიანები ყოველ განსჯის გადაწყვეტილებაზე პასუხისმგებელი რჩებიან; უბრალოდ ყურადღებას არტეფაქტების დაწერაზე კი არა, მათ რევიუზე ხარჯავენ.

არტეფაქტების ძაფი

ეს მთელი მოდელის ხერხემალია და იდეა, რომელსაც მაშინაც მოვიპარავდი, დანარჩენს რომ უგულებელყოფდეთ:

ეტაპი	Committed არტეფაქტი	ვინ ამოწმებს
Plan	intent.md — პრობლემა ინიციატორის სიტყვებით	Product owner იღებს ან უარყოფს
Design	spec.md — მოთხოვნები + დიზაინი, პოლიტიკა გამოყენებული	Product owner, flagged საკითხებზე — policy owner-ებთან ერთად
Build	plan.md, შემდეგ diff და ტესტები	ინჟინერი (სარისკო სამუშაოზე — tech lead)
Test	ტესტის გამოსავალი, PR-ზე მიმაგრებული eval-ის შედეგები	ავტომატური gate-ები + code owner-ები
Deploy	PR რევიუს მიგნებებით, რელიზის ავტორიზაცია	Code owner, release manager
Maintain	ინციდენტის ჩანაწერი → ახალი intent.md	On-call / სერვისის მფლობელი ახარისხებს

ადრეული არტეფაქტები განზრახ Markdown-ია: product owner-საც და აგენტსაც შეუძლია მათი წაკითხვა. build-იდან მოყოლებული არტეფაქტები კოდი და მისი ჩანაწერებია.

ორი რამ ხდის ამას ძლიერს. პირველი, ჯაჭვი თავად არის audit trail: ვინ რა ითხოვა, რა დაამზადა აგენტმა, ვინ დაამტკიცა — ყველაფერი git-ის ისტორიაშია, ცალკე compliance-ის ცხრილის გარეშე. მეორე, ყოველი მიღებული არტეფაქტი შეიძლება გახდეს შემდეგი ეტაპის ტრიგერი. დამერჯებული intent.md იწყებს spec-ის გავლას. დამტკიცებული spec.md ხსნის plan-mode სესიას. დამერჯებული PR ატარებს pipeline-ს. დარღვეული პროდაქშენ-მეტრიკა წერს შემდეგ intent.md-ს. ეს არის „ციკლი”.

თუ spec-driven development-ის პოსტი წაიკითხეთ, ეს ნაცნობი იქნება: ეს იგივე „spec როგორც ჭეშმარიტება, კოდი როგორც ქეში” იდეაა, გაფართოებული მთელ სასიცოცხლო ციკლზე და არა მხოლოდ build ეტაპზე.

ეტაპი-ეტაპ: რა იცვლება

Playbook-ს არ გავიმეორებ — წაიკითხეთ ის — მაგრამ აი, თითოეული ეტაპის ფორმა და ერთი იდეა ეტაპზე, რომელსაც ყველაზე მეტი წონა აქვს, ჩემი აზრით.

Plan: დააფიქსირე განზრახვა ერთხელ

იმის ნაცვლად, რომ იდეა გაიაროს backlog-ჩანაწერში, user story-ში, ქულებით შეფასებასა და ორ refinement-შეხვედრაში — და ყოველ ნახტომზე დაკარგოს აზრი — ადამიანი, ვისაც იდეა გაუჩნდა, აბრეინსტორმებს მას აგენტთან და აკომიტებს intent.md-ს: პრობლემა, სასურველი შედეგი, ვის ეხება, შეზღუდვები, ღია კითხვები.

მნიშვნელოვანი იდეა: არაინჟინრები git-ში აკომიტებენ (connector-ის მეშვეობით), ამიტომ ორიგინალი ფორმულირება გადარჩება. საყურადღებო მეტრიკაა დრო პირველი საუბრიდან committed intent-მდე — playbook-ის მიზანია კვირების საათებამდე შემცირება.

Design: პოლიტიკა წერისას გამოიყენე, არა რევიუში

მოთხოვნები და დიზაინი ერთ სესიაში ხდება. აგენტი კითხულობს მიღებულ intent-ს და აწარმოებს spec.md-ს, შეზღუდულს უსაფრთხოების, compliance-ის, ბრენდისა და UX-ის ორგანიზაციული skills-ით — და მას პირდაპირ ეთხოვება, მიუთითოს, სად ეწინააღმდეგება პოლიტიკები ერთმანეთს, და არა ჩუმად აირჩიოს ერთ-ერთი. Flagged საკითხები სახელდებულ policy owner-ებთან მიდის მანამ, სანამ ინჟინერია spec-ს ნახავს.

მნიშვნელოვანი იდეა: პოლიტიკის აღსრულება PR რევიუდან spec-ის წერაში გადმოდის (shift left). ჭკვიანი lagging მეტრიკა: დათვალეთ spec.md-ის ის რედაქტირებები, რომლებიც პირველი plan.md-ის შემდეგ გაკეთდა. ეს არის გაზომილი rework.

Build: მიღებული plan-ის გარეშე იმპლემენტაცია არ არის

სესიები იწყება plan mode-ში: აგენტი კითხულობს კოდბაზას რედაქტირების გარეშე და გვთავაზობს plan-ს — რომელი ფაილები იცვლება, სამუშაოს თანმიმდევრობა, რისკები, როგორ დადასტურდება. თქვენ მას დაკითხავთ („რა გაფუჭდება? რომელია ყველაზე სარისკო ნაბიჯი? რა უარყავი?”), სანამ ადამიანს, ვინც საუბარი არ უნახავს, მისგან იმპლემენტაცია არ შეეძლება. შემდეგ ის commit-დება როგორც plan.md, და მოგვიანებით PR რევიუ diff-ს მას ადარებს.

მის გარშემო დგას ნაწილები, რომლებიც აგენტის გამოსავალს სანდოს ხდის:

• CLAUDE.md როგორც საერთო კონტექსტი — ერთ გვერდზე ნაკლები, მხოლოდ პირველი დღის აუცილებელი. სამუშაო წესი: თუ აგენტი ერთსა და იმავე შეცდომას ორჯერ უშვებს, დაამატე შესწორება.
• Skills ცოდნისთვის, რომელიც რეპოებში თანმიმდევრულად უნდა გამოიყენებოდეს (უსაფრთხოების რევიუ, API სტანდარტები). ვერსიონირებული, policy owner-ის საკუთრებაში.
• Hooks როგორც დეტერმინირებული მცველები — დაბლოკე დაცული ბილიკების რედაქტირება, გაუშვი formatter რედაქტირების შემდეგ, არ გაუშვა secrets diff-ებში.
• პარალელური სესიები worktree-ებსა და subagent-ებში — verifier, რომელიც აპს უშვებს და plan.md-ს წინააღმდეგ ანგარიშს აბრუნებს რამის გასწორების გარეშე; simplifier; researcher.

მნიშვნელოვანი იდეა: skills მრჩევლებია, hooks აღმსრულებლები. Skill კვალიფიკაციას სავარაუდოს ხდის. Hook — უეჭველს. ნებისმიერ პოლიტიკას, რომელიც უნდა სრულდებოდეს, დეტერმინირებული მხარდაჭერა სჭირდება. სწორედ ეს ერთი გამიჯვნა ხელს უშლის „ვუთხარით აგენტს, მაინც რატომ გააკეთა?” ტიპის ინციდენტების უმეტესობას, რომლებზეც მესმის.

Test: დამოწმება, სანამ ადამიანი შეხედავს

ორი შრე. პირველი, აგენტს ეძლევა feedback loop — ერთი ბრძანება (make test), რომელიც წარუმატებლობისას არანულოვანი კოდით გამოდის, CLAUDE.md-ში ჩამოთვლილი იმით, თუ როგორ გამოიყურება ჯანსაღი გამოსავალი. ბაგებისთვის: ჯერ დაწერე ჩამოვარდნადი ტესტი, დააკომიტე, შემდეგ აგენტს მიეცი კოდის გასწორების საშუალება ტესტის შეხების გარეშე, იდეალურად hook-ით, რომელიც fix-დავალებებზე ტესტ-ფაილების რედაქტირებას ბლოკავს. „დასრულებული” ნიშნავს დამოწმებულს, მტკიცებულებად ჩასმული გამოსავლით.

მეორე, უწყვეტი evals აგენტის კონფიგურაციაზე. შეაგროვეთ 20–50 რეალური დავალება მიღებული შედეგებით, თითოეული გადააქციეთ eval-ად და გაუშვით სიუტი, როცა CLAUDE.md, skills, hooks ან მოდელი იცვლება. კონფიგურაციის ცვლილება, რომელიც pass rate-ს ამცირებს, მერჯამდე რევიუვდება. ყოველი პროდაქშენ-ინციდენტი ხდება მუდმივი eval.

მნიშვნელოვანი იდეა: თქვენი აგენტის setup არის კოდი და ის კოდივით რეგრესირებს. ეს ზუსტად evals-ის პოსტის არგუმენტია, ოღონდ პროდუქტზე კი არა, harness-ზე გამოყენებული.

Deploy: აგენტი gate-მდე მიდის და არასოდეს გადის მასში

PR რევიუ ორივე მიმართულებით მუშაობს. AI-რევიუერი ყოველ PR-ზე ერთსა და იმავე გავლებს ატარებს — ბაგები და ლოგიკა, უსაფრთხოება, compliance spec.md-სა და plan.md-ს მიმართ — კონფიგურირებული REVIEW.md-ში, რომელსაც tech lead ფლობს, nit-ების ლიმიტით. აგენტი ასევე თავად პასუხობს რევიუს კომენტარებს საკუთარ PR-ებზე. მიგნებები არასოდეს ამტკიცებს ან ბლოკავს თავისით; code owner-ის დამტკიცება მაინც მოქმედებს, და ავტორ-აგენტს საკუთარი სამუშაოს დამტკიცება არ შეუძლია.

Hooks „allow/block”-იდან „ask”-ზე ვითარდება: პროდაქშენ-დეპლოი ჩერდება, სანამ დასახელებული release manager არ ავტორიზებს. CI jobs იწყება read-only რეჟიმში (ჩავარდნილი build-ების triage, flaky ტესტების კლასიფიკაცია, changelog-ების დრაფტი), შემდეგ ემატება write jobs, რომლებიც მხოლოდ PR-ებს აწარმოებს. Deploy და rollback გამოიფინება როგორც გარემოზე შეზღუდული ხელსაწყოები, დონეებად დაყოფილი ავტონომიით: dev-ში თავისუფალი, staging-ში შეზღუდული, პროდაქშენში მხოლოდ მომზადება.

მნიშვნელოვანი იდეა: აგენტს შეუძლია იმოქმედოს პროდაქშენ-gate-მდე, მაგრამ არა მასში. ეს ერთი წინადადება არის governance-მოდელი, რომელსაც აუდიტორს ოცდაათ წამში აუხსნით.

Maintain: დახურე ციკლი

წინა ეტაპებს დასაწყებად ადამიანი სჭირდებოდა. აქ ტრიგერი არის დეტერმინირებული სკრიპტი, რომელიც პროდაქშენ-მეტრიკას მოძრავი baseline-ით აკვირდება — CI-ს ჩავარდნის მაჩვენებელი, post-deploy 5xx, PR-ის ციკლის დრო — დონეებად დაყოფილი რეაგირებით: 1σ-ზე ლოგი, 2σ-ზე read-only დიაგნოსტიკა, 3σ-ზე PR-ის შეთავაზება ან წინასწარ დამტკიცებული rollback-ის ტრიგერი. აგენტი თავის დიაგნოზს წერს intent.md-ად, და ადამიანი ახარისხებს: გაასწორე ახლავე, დაგეგმე ან უარყავი (უარყოფები band-ებს არეგულირებს). გასწორების გაშვების შემდეგ ინციდენტი ხდება eval.

მნიშვნელოვანი იდეა: აღმოჩენა დეტერმინირებულია; განსჯა დელეგირებულია. არცერთი მოდელი არ წყვეტს, არის თუ არა ანომალია. მოდელი მხოლოდ ხსნის მას და გვთავაზობს რეაგირებას, იმავე gate-ებით, როგორც ყველა სხვა.

სამი პრინციპი ქვემოთ

თუ პროდუქტის სახელებს მოვაცილებთ, playbook სამ წესზე დგას. კედელზე გავაკრავდი:

1. Git-ში არტეფაქტები არის audit trail. თუ commit-ში არ არის, არ მომხდარა.
2. Skills ურჩევენ, hooks ასრულებინებენ. არასოდეს დაეყრდნოთ მოდელის კარგ ქცევას პოლიტიკისთვის, რომელიც აუცილებლად უნდა სრულდებოდეს.
3. დეტერმინირებული აღმოჩენა, დელეგირებული განსჯა, ადამიანის ავტორიზაცია. სკრიპტები წყვეტენ როდის, აგენტები გვთავაზობენ რას, ადამიანები ამტკიცებენ ღირს თუ არა.

სად ვიქნებოდი ფრთხილად

ამის გაყიდვა დათქმების გარეშე თქვენს მიმართ უსამართლო იქნებოდა.

• ეს ვენდორის დოკუმენტია. Playbook-ი Anthropic-მა დაწერა და ის Claude Code-ის გარშემოა აგებული, რამდენიმე პროდუქტით, რომლებიც დაწერის დროს beta-ად იყო მონიშნული. პატერნები — committed არტეფაქტები, დეტერმინირებული gate-ები, evals კონფიგურაციაზე, დონეებად დაყოფილი ავტონომია — ხელსაწყოსგან დამოუკიდებელია და სხვა აგენტებთანაც მუშაობს. პროდუქტის დეტალები შეიცვლება; დააპროექტეთ პატერნების გარშემო.
• რევიუს მოცულობა მაინც ჭერია. პარალელური სესიები მხოლოდ მანამ ეხმარება, სანამ ადამიანის რევიუ ფეხს აყოლებს. Playbook ამბობს, დაიწყეთ ორი-სამი სესიით და მეტი დაამატეთ მხოლოდ თუ რევიუს ხარისხი შენარჩუნდება. გუნდები, რომლებიც ამ წინადადებას გამოტოვებენ, აწარმოებენ ბევრ დამაჯერებელ კოდს, რომელიც ნამდვილად არავის შეუმოწმებია.
• Managed-settings lockdown კომპრომისია, არა შაბლონი. ყოველი deny წესი შესაძლებლობას ღირს. შეუსაბამეთ შეზღუდვები თითოეული რეპოს მონაცემთა კლასიფიკაციას და ყველაზე მკაცრი მაგალითი ყველგან ნუ დააკოპირებთ.
• Legacy სისტემები არ ქრება. Jira, Figma და change board-ები არსებობს, რადგან აუდიტორები და სხვა გუნდები მათზე არიან დამოკიდებულნი. Playbook-ის პასუხი პრაგმატულია: ყოველი არტეფაქტისთვის გამოაცხადეთ ერთი system of record — რეპო, legacy ხელსაწყო ან მინიმუმ ორმხრივი ბმული (არტეფაქტი ციტირებს ტიკეტის ID-ს, ტიკეტი ციტირებს კომიტის SHA-ს). თანაარსებობა კარგია; ორაზროვნება — არა.
• ციკლი საბოლოო მდგომარეობაა. headless აგენტებით, რომლებიც 3σ ალერტებზე რეაგირებენ, არ იწყებთ. იწყებთ ყოველი ნაბიჯის ხელით prompt-ირებით, შემდეგ აკოდებთ slash command-ებად, შემდეგ — ტრიგერებად. რამდენიმე play-ს წინაპირობა არ აქვს — intent.md, CLAUDE.md, feedback loop, approval hooks — და სწორედ იქიდან უნდა დაიწყოთ.

როგორ დავნერგავდი ამას რეალურ გუნდში

რომ მომდევნო კვარტალში დამენერგა, თანმიმდევრობა ასეთი იქნებოდა:

1. კვირა 1–2: CLAUDE.md ყოველ აქტიურ რეპოში და ერთბრძანებიანი feedback loop (make test, რომელიც არანულოვანი კოდით გამოდის). ნულოვანი წინაპირობა, მყისიერი სარგებელი.
2. კვირა 3–4: Plan mode როგორც დეფოლტი. აკომიტეთ plan.md ყოველ არატრივიალურ ცვლილებაზე. დაიწყეთ first-pass merge rate-ის გაზომვა.
3. თვე 2: Hooks — დაცული ბილიკები, secret scanning, ტესტ-ფაილების დაცვა fix-ების დროს. აირჩიეთ ერთი არათანმიმდევრულად აღსრულებადი პოლიტიკა და გადააქციეთ skill-ად დასახელებული მფლობელით.
4. თვე 2–3: AI PR review REVIEW.md-ით, branch protection უცვლელად. Approval hooks პროდაქშენ-დეპლოიზე.
5. თვე 3+: intent.md → spec.md product owner-ებისთვის. უწყვეტი evals აგენტის კონფიგურაციაზე. შემდეგ და მხოლოდ შემდეგ, ერთი დახურული ციკლი ერთ მეტრიკაზე.

გაზომეთ სვლისას — playbook ყოველ play-ს წყვილებს leading და lagging ინდიკატორით, და ეს დისციპლინა ღირს გადაკოპირებად, დანარჩენს თუნდაც ყველაფერს შეცვლიდეთ.

კარიერული კუთხე

სამუშაოს აღწერა ჩვენ ყველას ქვეშ იცვლება. ინჟინერი ამ მოდელში ნაკლებ დროს ხარჯავს კრეფაზე და მეტს — დასამტკიცებელი plan-ების წერაზე, არტეფაქტების რევიუზე, gate-ების დაპროექტებასა და პარალელური სამუშაოს ორკესტრაციაზე. Tech lead-ები ხდებიან REVIEW.md-ის, CLAUDE.md-სა და eval-სიუტის მფლობელები. Platform ინჟინრები ხდებიან ადამიანები, ვინც governance-ს hooks-სა და managed settings-ად აკოდებს. Engineering manager-ები იღებენ სასიცოცხლო ციკლს, სადაც ყოველი ნაბიჯი მტკიცებულებას ტოვებს — რაც, თუ ოდესმე აუდიტისთვის მომზადებულხართ, პატარა რამ არ არის.

უნარები, რომლებიც გროვდება, ისინია, რომლებსაც playbook განუწყვეტლივ უბრუნდება: specs, context, verification და governance-as-code. არც ერთი მათგანი კონკრეტულ მოდელზე არ არის, და არც ერთი არ მოძველდება, როცა შემდეგი მოდელი გამოვა.

უფრო ღრმად

სწორედ ამის გარშემო ავაგეთ კურსი: AI-Native SDLC: Engineering Delivery from Intent to Production. ექვსი მოდული, თითო სასიცოცხლო ციკლის ეტაპზე, თითოეული სრულდება თქვენს კოდბაზაზე committed არტეფაქტით — intent და spec შაბლონები, დაზუსტებული CLAUDE.md, skills და hooks, eval-სიუტი თქვენი აგენტის კონფიგურაციისთვის, AI review gate და ერთი დახურული მონიტორინგის ციკლი.

თუ ჯერ საფუძვლები გინდათ: Claude Code Mastery ყოველდღიური აგენტური ციკლისთვის, Spec-Driven Development Foundations მეთოდოლოგიისთვის და OpenSpec Mastery production spec workflow-სთვის. გუნდებისთვის, რომლებიც ამას მთელ ორგანიზაციაში ნერგავენ, ჩვენ მას corporate training-ადაც ვატარებთ.

---

წყარო: Anthropic, The AI-Native SDLC Playbook (2026 წლის აგვისტო). ეს პოსტი დამოუკიდებელი შეჯამება და კომენტარია; სრული play-ებისთვის, მაგალითებისა და კონფიგურაციის მითითებებისთვის წაიკითხეთ ორიგინალი. ამ სერიაში ასევე: spec-driven development, context engineering, evals, OpenSpec, AI coding ხელსაწყოების დანერგვა.