არსებობს შეხვედრა, რომელიც უფრო მეტ აგენტურ პროექტს კლავს, ვიდრე რომელიმე ბაგი ოდესმე. ის ხდება გაშვებიდან დაახლოებით ორ თვეში, და მას ინჟინერია არ ატარებს. ფინანსები ხსნიან დაშბორდს, უჩვენებენ სტრიქონზე, რომელიც 8-ჯერ გაიზარდა, მაშინ როცა გამოყენება 2-ჯერ გაიზარდა, და სვამენ კითხვას, რომელზეც ოთახში ვერავინ პასუხობს: „ზუსტად რაში ვიხდით?”
ინჟინრები არაკომპეტენტურები არ არიან — სისტემა მუშაობს. მაგრამ არავის დაუპროექტებია მისი ღირებულებითი ქცევა, ამიტომ ღირებულებითმა ქცევამ თავი თვითონ დააპროექტა. ეს პოსტი ასახელებს დისციპლინას, რომელიც იმ შეხვედრას თავიდან იცილებს: token economics. ეს არის მეექვსე საყრდენი არკაში, რომელსაც ვწერ, — context engineering-ის, spec-driven development-ის, evals-ის, OpenSpec-ისა და durable execution-ის შემდეგ — და სწორედ ის წყვეტს, გააგრძელებს თუ არა დანარჩენი ხუთი პროდაქშენში მუშაობას.
რა არის token economics?
Token economics — ეს არის საინჟინრო დისციპლინა, რომელიც LLM-ის ღირებულებას უყურებს როგორც სისტემის დაპროექტებულ თვისებას და არა აღმოჩენილს. ის ფარავს ოთხ გადაწყვეტილებას: რა ეშვება ღირდეს თითოეულ მოთხოვნას (ბიუჯეტირება), რომელ სამუშაოზე უარს ამბობთ ორჯერ გადახდაზე (ქეშირება), რომელ სამუშაოს შეუძლია დაელოდოს უფრო იაფ დამუშავებას (ბატჩინგი) და რომელი მოდელი იმსახურებს თითოეულ მოთხოვნას (routing). გუნდები, რომლებიც ამ გადაწყვეტილებებს აშკარად იღებენ, რგავენ აგენტებს პროგნოზირებადი unit cost-ით; გუნდები, რომლებიც არა, თავიანთ unit costs-ს ინვოისიდან იგებენ.
სიტყვა „economics” ამ განმარტებაში რეალურ სამუშაოს აკეთებს. ეს არ არის ხარჯების ჭრა — ეს არის მათი მოდელირება: იცოდე კიდევ ერთი მომხმარებლის, კიდევ ერთი ფიჩის, აგენტის კიდევ ერთი ნაბიჯის მარგინალური ღირებულება მანამ, სანამ ფინანსები იკითხავენ.
არავის დაუპროექტებია მისი ღირებულებითი ქცევა, ამიტომ ღირებულებითმა ქცევამ თავი თვითონ დააპროექტა. ეს წინადადება აღწერს თითქმის ყოველ აგენტურ სისტემას, რომელსაც მეორე კვარტალში გამორთავენ.
ბერკეტი ექვსია, და მათი ნაკრებად ცოდნა ღირს, რადგან თითოეულს აქვს ჩავარდნის რეჟიმი, რომელიც ხარჯების სიურპრიზად ჩნდება და არა შეცდომად:
| ბერკეტი | რას აკეთებს | ტიპური ეფექტი | როგორ ბრუნდება თქვენს წინააღმდეგ |
|---|---|---|---|
| ბიუჯეტი მოთხოვნაზე | ზღუდავს, რამდენის დახარჯვა შეუძლია ერთ გაშვებას, რანტაიმში აღსრულებით | „შეგვიძლია ვერიფიკაციის ნაბიჯი დავამატოთ?”-ს დებატიდან არითმეტიკად აქცევს | საშუალოებით არის გაზომილი, ამიტომ გრძელი კუდის გაშვებები ჭერთან კვდებიან დასრულების ნაცვლად |
| Prompt caching | წყვეტს სტაბილური prefix-ის ხელახლა ყიდვას ყოველ ნაბიჯზე | გადასახდელი შემავალი ტოკენების დიდი შემცირება, ხარისხის ყოველგვარი გაცვლის გარეშე | ცვალებადი თანმიმდევრობით აწყობილი პრომპტი ჩუმად აცდენს — სრული ფასი, არავითარი შეცდომა |
| Batch-დამუშავება | სამუშაოს, რომელსაც არავინ ელოდება, გადააქვს ფასდაკლებულ async-ში | მკვეთრი ფასდაკლება evals-ზე, ბექფილებსა და შეჯამებაზე | გამოყენებულია იმაზე, რასაც მომხმარებელი ელოდება, და ახლა ფიჩა გატეხილად აღიქმება |
| მოდელების routing | აგზავნის თითოეულ ნაბიჯს ყველაზე იაფ მოდელთან, რომლის გამოსავალიც შეგიძლიათ შეამოწმოთ | ნაბიჯების უმეტესობა იაფდება; ტოკენები იქ კონცენტრირდება, სადაც ხარისხი ბოჭავს | გაკეთებულია evals-ის გარეშე, ამიტომ ბრმად ოპტიმიზირებთ და ხარისხის რეგრესიას რგავთ |
| Checkpointing | აძლევს ჩავარდნილ გაშვებას განახლების საშუალებას რესტარტის ნაცვლად | ხელახალი ცდები წყვეტენ მთელი საუბრის ისტორიის ხელახლა ყიდვას | Checkpoint-ები ზედმეტად მსხვილია, ამიტომ გაშვების უმეტეს ნაწილს მაინც თავიდან ათამაშებთ |
| კონტექსტის გამოდევნა | აგდებს იმას, რაც შემდეგ ნაბიჯს დამტკიცებულად არ სჭირდება | წყვეტს ხარჯის კვადრატულ ზრდას გაშვების სიგრძესთან ერთად | გამოდევნის იმ ერთადერთ შეზღუდვას, რომლის დაცვაც აგენტს უნდა გაეგრძელებინა |
რატომ ფეთქდება აგენტების ხარჯები, როცა მოთხოვნების ხარჯები — არა?
იმიტომ, რომ აგენტები ამრავლებენ. ჩატ-ფიჩა ღირს დაახლოებით ერთი მოდელის გამოძახება მომხმარებლის ერთ ქმედებაზე — წრფივი, მოსაწყენი, უსაფრთხო. აგენტი დგამს ნაბიჯებს, და თითოეულ ნაბიჯს შეუძლია ატაროს ყველა წინა ნაბიჯის დაგროვილი კონტექსტი. გაშვების ღირებულება არ არის ნაბიჯის-ღირებულება × ნაბიჯები; ის უფრო ახლოა ნაბიჯის-ღირებულება × ნაბიჯები²-თან, რადგან კონტექსტური ფანჯარა იზრდება გაშვების გაგრძელებასთან ერთად. დაამატეთ ხელახალი ცდები, tool-შედეგები, კონტექსტში სიტყვასიტყვით ჩაყრილი, და დამგეგმავი, რომელიც „კიდევ ერთხელ დაფიქრდება”, — და 8-ჯერადი სიურპრიზი ხარჯებში 2-ჯერად გამოყენებაზე საიდუმლო აღარ არის.
აი რატომ არის token economics განუყოფელი context engineering-ისგან. ყოველი კონტექსტ-საინჟინრო გადაწყვეტილება — რა ამოვიღოთ, რა შევაჯამოთ, რა გამოვდევნოთ — ასევე შესყიდვის გადაწყვეტილებაა. მოუწესრიგებელი კონტექსტ-სტრატეგია არ არის მხოლოდ ხარისხის პრობლემა; ეს არის მუდმივი დავალება, იყიდო ერთი და იგივე ტოკენები ისევ და ისევ.
კავშირი durable execution-თან ისეთივე პირდაპირია: აგენტი, რომელსაც შეუძლია განახლდეს რესტარტის ნაცვლად, ყოველი ჩავარდნის შემდეგ საკუთარ ისტორიას თავიდან არ ყიდულობს. ხარჯების ტერმინებში checkpointing — ეს ფასდაკლების პროგრამაა. Retry-from-zero არქიტექტურები ერთსა და იმავე სამუშაოში სრულ ფასს N-ჯერ იხდიან და ამას საიმედოობას უწოდებენ.
როგორ უნდა გამოიყურებოდეს ტოკენ-ბიუჯეტი სინამდვილეში?
ნამდვილი ტოკენ-ბიუჯეტი — ეს არის ჭერი თითო მოთხოვნაზე მფლობელითა და აღსრულების წერტილით, და არა თვიური ჯამი დაშბორდზე. სამუშაო ფორმა: თითოეული ფიჩა აცხადებს მოსალოდნელ ღირებულებას მოთხოვნაზე და მკაცრ მაქსიმუმს, სისტემა მაქსიმუმს რანტაიმში აღასრულებს (აგენტი, რომელიც ჭერს მიაწყდა, ჩერდება და აფიქსირებს — ზუსტად როგორც timeout), და რიცხვს ჰყავს დასახელებული მფლობელი. თვიური ჯამები პრობლემებს აღმოაჩენენ; ჭერები მოთხოვნაზე მათ თავიდან იცილებენ.
ბიუჯეტები საინჟინრო საუბრებს ისე ცვლიან, როგორც დაშბორდები ვერასოდეს. „შეგვიძლია აგენტს ვერიფიკაციის ნაბიჯი დავუმატოთ?” წყვეტს იყოს ფილოსოფიური დებატი ხარისხზე და ხდება არითმეტიკა: ნაბიჯი ღირს ~4k ტოკენი გაშვებაზე, ბიუჯეტში 3k მარაგია, ესე იგი ან ნაბიჯი გახდება იაფი, ან რაღაც სხვა. ეს პროდუქტიული კამათია. გუნდები მას დარგვამდე აწარმოებენ და არა ინვოისის შემდეგ.
ბიუჯეტი ასევე ხილული უნდა იყოს იქვე, სადაც სპეკა ცხოვრობს. თუ spec-driven development-ს პრაქტიკობთ, ღირებულების ჭერი სპეკას ეკუთვნის ქცევით მოთხოვნებთან ერთად — „პასუხობს 30 წამში, ღირს X-ზე ნაკლები გაშვებაზე” — რადგან მოთხოვნა, რომელიც არავის ჩაუწერია, არის მოთხოვნა, რომელიც სისტემას არ აქვს.
რას ყიდულობს ქეშირება სინამდვილეში?
Prompt caching — ყველაზე მაღალბერკეტიანი ხარჯების ხელსაწყოა სტეკში, რადგან აგენტური დატვირთვები არაჩვეულებრივად განმეორებადია: სისტემური პრომპტი, ხელსაწყოების სქემები და ხანგრძლივი კონტექსტი იდენტურია ნაბიჯებს შორის და ხშირად მომხმარებლებს შორისაც. ქეშზე გათვლილი მოთხოვნების დიზაინი — სტაბილური პრეფიქსი ჯერ, ცვალებადი კონტენტი ბოლოს — რუტინულად ჭრის აგენტური სისტემის გადასახდელ ტოკენების მოცულობას ნახევრით და მეტით, ხარისხის ყოველგვარი გაცვლის გარეშე. ეს ყველაზე ახლოა უფასო ფულთან AI-ინჟინერიაში.
მაგრამ ქეშირება მხოლოდ მაშინ ანაზღაურდება, თუ მოთხოვნები აშენებულია ქეშირებადად, და ეს არქიტექტურული გადაწყვეტილებაა, არა დროშა. პრომპტი, რომელიც ყოველ მოთხოვნაზე სხვადასხვა თანმიმდევრობით იწყობა, ქეშს ჩუმად ამარცხებს — სრულ ფასს იხდით და არაფერი ვარდება შეცდომით. ეს ის ადგილია, სადაც სხვაობა „ერთხელ წავიკითხე API-დოკები”-სა და „რეალურად იცის პლატფორმა”-ს შორის პირდაპირ ინვოისში ჩანს; მექანიკა (cache breakpoints, პრეფიქსის დიზაინი, TTL-ები და ის, თუ როგორ გადაამოწმო, რომ cache-ჰიტებს იღებ) — ზუსტად ის არის, რასაც Claude API-ის კურსი ავარჯიშებს, რადგან ვერიფიცირებული ეკონომია ჯობია ნავარაუდევს.
როგორ დავაპროექტოთ მოთხოვნა, რომელიც რეალურად ქეშირდება
წესი მარტივი ჩამოსაყალიბებელია და ადვილი დასარღვევი: ყველაფერი სტაბილური მიდის ჯერ, ყველაფერი ცვალებადი — ბოლოს. სისტემური ინსტრუქციები, tool schemas და ხანგრძლივი საპროექტო კონტექსტი ქმნიან prefix-ს; მომხმარებლის მიმდინარე შეტყობინება, ამ მოთხოვნისთვის ამოღებული ჩანკები და კონკრეტული ნაბიჯის მდგომარეობა მოდის შემდეგ. იმ წამს, როცა ერთი ცვალებადი ტოკენი ადრე ჩნდება, ყველაფერი მის შემდეგ არაქეშირებადი ხდება — ქეში პრეფიქსებზე ემთხვევა და არა კონტენტზე, რომელსაც მოგვიანებით ცნობს.
თვითდაზიანება, რომელიც ყველაზე ხშირად მინახავს, — timestamp-ია. ვიღაც ამატებს სასარგებლო სტრიქონს Current time: … სისტემური პრომპტის თავთან ახლოს, და მთელი prefix იცვლება ყოველ ცალკეულ გამოძახებაზე. პრომპტი კვლავ მუშაობს. Evals კვლავ გადის. ანგარიში ჩუმად ორმაგდება, და არსად არის ჩავარდნა, რომლის გამოძიებაც შეიძლებოდა. იგივე ეხება მომხმარებლის სახელს, request ID-ს ან ჰეშ-მეპიდან აწყობილ შემთხვევითი თანმიმდევრობის tool-განსაზღვრებების ნაკრებს — ყველაფერი, რაც გამოძახებიდან გამოძახებამდე იცვლება, სტაბილური ბლოკის შემდეგ ეკუთვნის ადგილს, ან არსად.
ქეშის სიცოცხლის ხანგრძლივობაც მნიშვნელოვანია. ქეშირებულ პრეფიქსებს ვადა ეწურებათ, ამიტომ დაბალტრაფიკიანმა ფიჩამ შეიძლება ქეშის ჩაწერაში გადაიხადოს და ვადის გასვლამდე ერთხელაც ვერ წაიკითხოს; მაღალტრაფიკიანი ჩაწერას ათასობით გამოძახებაზე ანაწილებს. აი, რატომ იგებს ქეშირება ასე გადამწყვეტად სწორედ აგენტურ ციკლებზე — ერთი გაშვება ბევრ გამოძახებას აკეთებს სწრაფი თანმიმდევრობით თითქმის იდენტური prefix-ის მიმართ.
როგორ გადავამოწმოთ ეკონომია იმის ნაცვლად, რომ ვივარაუდოთ
ლოგირეთ ქეშირებული და არაქეშირებული შემავალი ტოკენები ცალკე ველებად, ყოველთვის. დაშბორდი, რომელიც ერთ შერწყმულ რიცხვს „შემავალი ტოკენები” აჩვენებს, ვერ გეტყვით, მუშაობს თუ არა ქეშირება, და გუნდები რუტინულად სჯერათ, რომ იღებენ ფასდაკლებას, რომლის მიღებაც კვირების წინ შეწყვიტეს. როცა გაყოფა ჩაწერილია, წარმოებული მეტრიკა, რომელიც რეალურად გჭირდებათ, — cache-hit ratio ფიჩაზე, ხოლო ალერტი, რომელიც გჭირდებათ, — ამ თანაფარდობის ვარდნა, რადგან ქეშირებას არასოდეს ტეხს დეპლოი წარწერით „გატეხე ქეში”, არამედ უწყინარი რეფაქტორინგი, რომელმაც პრომპტის აწყობის თანმიმდევრობა შეცვალა. ეს ალერტი არის სხვაობა „გაიგო ერთ საღამოში”-სა და „გაიგო კვარტალურ რევიუზე”-ს შორის.
ბატჩინგი — ქეშირების ჩუმი და-ძმაა: ნებისმიერ სამუშაოს, რომელსაც პასუხი წამებში არ სჭირდება — ღამის შეჯამება, ბექფილები, eval-სიუტები, — შეუძლია batch-დამუშავებით გაიაროს მკვეთრი ფასდაკლებით. საპროექტო კითხვა მარტივია: თქვენი დატვირთვებიდან რომელია ფარულად ასინქრონული. ჩემი გამოცდილებით, მათგან მეტია, ვიდრე არქიტექტურა აღიარებს, და evals კანონიკური მაგალითია: ყოვლისმომცველი სიუტი, ღამით batch-ფასებში გატარებული, უფრო იაფი ღირს, ვიდრე თხელი, სინქრონულად პანიკაში გატარებული ინციდენტის შემდეგ.
როდის უნდა აიღოს მოთხოვნა უფრო პატარა მოდელმა?
დაარაუტეთ ვერიფიცირებადობით და არა ვაიბებით: გამოიყენეთ ყველაზე პატარა მოდელი, რომლის გამოსავალიც შეგიძლიათ შეამოწმოთ, და შეინახეთ ფრონტირული მოდელი იმ ნაბიჯებისთვის, სადაც შეცდომა ძვირია, ხოლო შემოწმება — ძნელი. კლასიფიკაცია, ექსტრაქცია, ფორმატირება, შეჯამება-შესანახად — მათ ვერიფიცირებადი გამოსავლები აქვთ და იტანენ უფრო იაფ მოდელს, ვალიდაციით გამყარებულს. დაგეგმვა, ხელსაწყოს არჩევა ღია სიტუაციებში და ფინალური მომხმარებლისკენ მიმართული სინთეზი ჩვეულებრივ დიდ მოდელს იმსახურებს. კარგად დარაუტებული აგენტი ხშირად თავისი ნაბიჯების უმეტესობას პატარა მოდელებზე ატარებს, ხოლო თავისი ტოკენების უმეტესობას იქ ხარჯავს, სადაც ხარისხი რეალურად ბოჭავს.
Routing — ეს ასევე ის ადგილია, სადაც evals ოფციონალური აღარ არის. რეგრესიული სიუტის გარეშე ყოველი routing-ცვლილება რწმენის ნახტომია, და გუნდები ან არასოდეს ოპტიმიზირებენ (ძვირი), ან ბრმად ოპტიმიზირებენ (უარესი). ნამდვილი eval-ჰარნესით „ექსტრაქციის პატარა მოდელზე გადატანა” — ეს ნახევარი დღის ექსპერიმენტია pass/fail-პასუხით. Eval-სიუტი — ეს ის არის, რაც ხარჯების ოპტიმიზაციას უსაფრთხოს ხდის; ეს ისევ ის სამეულია: სპეკა ამბობს, რა უნდა შენარჩუნდეს, evals ამოწმებენ, რომ ჯერ კიდევ ნარჩუნდება, ხოლო token economics წყვეტს, რა შეიძლება ეს ღირდეს.
პატერნი, რომელიც ორივე უკიდურესობას ჯობნის, — ესკალაცია და არა მინიჭება: გაატარეთ ნაბიჯი პატარა მოდელზე, დაავალიდირეთ გამოსავალი მექანიკურად და ხელახლა სცადეთ ფრონტირულ მოდელზე მხოლოდ მაშინ, როცა validation ვარდება. თუ იაფი მოდელი შემთხვევათა ოთხმოც პროცენტში მართალია და validation საიმედოა, პატარა მოდელის ფასებს ხუთიდან ოთხჯერ იხდით და მაინც ფრონტირული მოდელის კორექტულობას იღებთ — ეკონომიკა უკეთესია, ვიდრე ყველაფრის ქვემოთ დარაუტება, და ხარისხი უკეთესია, ვიდრე ყველაფრის ზემოთ დარაუტება.
კონკრეტული ფორმა, support-triage აგენტიდან, რომელზეც ვმუშაობდი: შემომავალი მოთხოვნის კლასიფიცირება (პატარა მოდელი, გამოსავალი — ფიქსირებული ნაკრების ერთ-ერთი ნიშნული, ტრივიალურად შესამოწმებელი), რელევანტური ისტორიის ამოღება (საერთოდ მოდელის გარეშე — ეს ბაზის ქვერია, რომელსაც გუნდები რუტინულად LLM-ს აბარებენ ყოველგვარი მიზეზის გარეშე), პასუხის მონახაზის შედგენა (mid-tier), შემდეგ პოლიტიკისა და ტონის ფინალური შემოწმება მანამ, სანამ ეს ადამიანამდე მივა (ფრონტირული). ოთხი ნაბიჯი, სამი სხვადასხვა მოდელი, ერთი ნაბიჯი საერთოდ მოდელის გარეშე. ნაბიჯების უმეტესობა იაფად მიდის; ტოკენების უმეტესობა იმ ორზე ჯდება, რომლებიც მნიშვნელოვანია.
ანტიპატერნი, რომლის დასახელებაც ღირს: routing კლიენტის ტარიფით და არა ამოცანით. მოსახდელ კლიენტებს არ სჭირდებათ უფრო დიდი მოდელი, მათ სჭირდებათ კორექტული პასუხი — და იაფი მოდელი validation-ით მას ხშირად უფრო საიმედოდ გასცემს, ვიდრე ძვირი მოდელი მის გარეშე. დაარაუტეთ ვერიფიცირებადობით, მიეცით evals-ს გადაწყვეტის უფლება და ფასების გვერდი არქიტექტურის გარეთ დატოვეთ.
მულტიაგენტური სისტემებისთვის დაამატეთ ერთი წესი: სუბ-აგენტები ორკესტრატორის მოდელს ნაგულისხმევად არ იმემკვიდრებენ. თითოეული როლი იღებს ყველაზე იაფ მოდელს, რომელიც ამ როლის evals-ს გადის, — სხვაობა ფლოტს, რომელიც მასშტაბირდება, და ფლოტს, რომელსაც გამორთავენ, შორის — ჩვეულებრივ სწორედ ეს წესია, ადრე გამოყენებული. აგენტების აშენება როლზე მიბმული მოდელის არჩევანითა და ხარჯების ინსტრუმენტირებით პირველივე დღიდან — Agent SDK-ის კურსის საბაზისო პატერნია, ზუსტად ამ მიზეზით.
როგორ გავხადოთ ხარჯები ხილული უფრო ადრე, ვიდრე ამას ფინანსები გააკეთებენ?
ინსტრუმენტირეთ ღირებულება მოთხოვნაზე, ფიჩაზე და აგენტის ნაბიჯზე პირველივე დეპლოიდან — ისევე, როგორც latency-ს ეპყრობით. ლოგირეთ ტოკენები შესასვლელზე და გამოსავალზე (ქეშირებულები და არაქეშირებულები ცალ-ცალკე, თორემ საკუთარ თავს მოატყუებთ), თეგირეთ ფიჩისა და ნაბიჯის მიხედვით, ალერტი დააყენეთ ცალკეული მოთხოვნების გადახრებზე და არა თვიურ ჯამებზე. ერთი ნელი ქვერი თვიურ ინფრასტრუქტურულ რევიუს არ ელოდება; ერთი აგენტური გაშვება 50-ჯერადი ღირებულებით ასევე არ უნდა ელოდებოდეს.
მოდელის თითო გამოძახებაზე ხუთი ველი საკმარისია, რომ თითქმის ყველა კითხვას უპასუხოთ, რომელსაც მოგვიანებით დაგისვამენ: ფიჩა, ნაბიჯი, მოდელი, შემავალი ტოკენები ქეშირებულად და არაქეშირებულად გაყოფილი, და გამომავალი ტოკენები. ყველაფერი სასარგებლო მათგან გამომდინარეობს — ღირებულება გაშვებაზე, ღირებულება ფიჩაზე, cache-hit ratio, განაწილება, რომელიც გეტყვით, თქვენი ბიუჯეტის ჭერი საშუალოზეა გაზომილი თუ კუდზე. გუნდები, რომლებიც ნაბიჯის თეგს ტოვებენ, სწორედ ისინი არიან, ვინც იცის, რომ მათი აგენტი ძვირია, მაგრამ ვერ ამბობს, მისი რვა ნაბიჯიდან რომელია ამაზე პასუხისმგებელი, და ეს ნახევარდღიან ფიქსს ერთკვირიან გამოცნობად აქცევს.
შემდეგ ორი ალერტი, და თავი შეიკავეთ მეტის დამატებისგან. პირველი — ცალკეული მოთხოვნის ღირებულების გადახრა: ერთი გაშვება, რომელმაც თავისი ბიუჯეტის რაღაც ჯერადს გადააჭარბა, რადგან გარედან სწორედ ასე გამოიყურება გაქცეული ციკლი. მეორე — cache-hit ratio-ს ვარდნა ფიჩაზე, რადგან სწორედ ასე აცხადებს თავს ჩუმი გაორმაგება. თვიურ ჯამებზე ალერტები პასუხისმგებლურად აღიქმება და თითქმის უსარგებლოა: იმ მომენტისთვის, როცა თვიური რიცხვი შემაშფოთებელი ხდება, ფული დახარჯულია, ხოლო მიზეზი — ოთხი დეპლოის წინ.
საანგარიშო არტეფაქტი, რომელიც პოლიტიკას ცვლის, — unit cost-ის მრუდია: ღირებულება წარმატებულ დავალებაზე დროში. ის ფინანსურ შეხვედრას გადააფრეიმებს „რატომ იზრდება ანგარიში”-დან (საფრთხე) „unit cost 40%-ით დაეცა, სანამ გამოყენება გაორმაგდა”-მდე (საპატიო წრე). იგივე რიცხვები, საპირისპირო შეხვედრა — და გუნდი, რომელიც თავის unit costs-ს ფლობს, იღებს უფლებას განაგრძოს ექსპერიმენტები, რადგან ხელმძღვანელობა ენდობა: მრიცხველს უყურებენ.
დისციპლინა, შეკუმშული
მიეცით ყოველ მოთხოვნას ბიუჯეტი მფლობელით. ააშენეთ პრომპტები ქეშირებადად და გადაამოწმეთ ჰიტები. გაატარეთ batch-ით ყველაფერი, რაც ფარულად ასინქრონულია. დაარაუტეთ ვერიფიცირებადობით, evals-ით როგორც დამცავი ბადით. აკეთეთ checkpoint-ები, რომ ხელახალმა ცდებმა ისტორია თავიდან არ იყიდონ. ინსტრუმენტირეთ unit cost პირველივე დღიდან და აფიქსირეთ ის მანამ, სანამ გკითხავენ. აქედან არაფერია ეგზოტიკა — ეს იგივე სიმწიფის მრუდია, რომელიც ინფრასტრუქტურულმა ხარჯებმა ათწლეულის წინ გაიარეს, ერთ წელიწადში შეკუმშული. გუნდები, რომლებიც მას ინტერნალიზაციას უკეთებენ, იღებენ უფლებას ატარონ ამბიციური აგენტური სისტემები; გუნდები, რომლებიც არა, იღებენ იმ შეხვედრას. RAG-ისა-და-აგენტების არქიტექტურული პატერნები ყველა ამ დისციპლინას გულისხმობს თავის ქვეშ — ხოლო თუ მთელი არკის ვერსია ოპერაციული მოდელის სახით გინდათ, spec-driven development-ის საფუძვლები — ის ადგილია, სადაც ექვსი დისციპლინა ერთ ვორკფლოუდ იწყობა.
