Planning və multi-agent workflow-lar

Agentic coding-də ən bahalı səhv yanlış kodu yazmaq deyil, yanlış şeyi düzgün yazmaqdır. Agent on dəqiqə işləyir, yüz sətir dəyişir, test-lər keçir, sonra məlum olur ki, tapşırığı siz nəzərdə tutduğunuzdan fərqli başa düşüb. Bu, model-in zəifliyi deyil; bu, təsvirin natamamlığıdır. İnsan developer-ə də "login-i düzəlt" deyəndə o əvvəlcə suallar verir. Agent-ə isə sual vermək imkanı və planı sizə göstərmək imkanı qəsdən verilməlidir. Bu fəsil həmin imkanı, yəni planning-i, və onun üstündə qurulan multi-agent workflow-ları izah edir.

Niyə əvvəlcə plan

Agent loop-unda hər addım əvvəlkinin üstünə qurulur. Səhv ilk qərar, məsələn yanlış faylda dəyişiklik və ya mövcud abstraksiyanı görməmək, sonrakı bütün addımları zəhərləyir və context-i boşa xərcləyir. Plan isə ucuzdur: bir neçə yüz token-lik mətn, oxunması bir dəqiqə çəkir və səhvi iş başlamazdan əvvəl tutur.

Praktik qayda belədir: bir-iki fayla toxunan, aydın tapşırıq üçün birbaşa icra. Üçdən çox fayla toxunan, dizayn qərarı tələb edən və ya tanımadığınız kod sahəsinə girən tapşırıq üçün əvvəlcə plan. Plan-ı oxumaq yüz sətir diff oxumaqdan həmişə asandır.

Plan mode

Claude Code-da plan mode xüsusi permission rejimidir: agent faylları oxuyur, axtarış edir, düşünür, amma heç nəyi dəyişmir və command işlətmir. Nəticə sizə təqdim olunan plandır; siz onu təsdiqləyir, düzəldir və ya rədd edirsiniz. Rejimə keçmək üçün session-da Shift+Tab ilə rejimləri dövr etmək və ya session-ı birbaşa bu rejimdə açmaq olar:

claude --permission-mode plan

Plan mode-un dəyəri read-only olmasındadır. Agent-ə "əvvəlcə araşdır, sonra dəyişmə təklifi ver" demək də olar, amma model bəzən səbirsizlənib dəyişikliyə başlayır. Plan mode bunu harness səviyyəsində qadağan edir: hətta model istəsə də, Edit və Bash icazəsiz keçmir. Təsdiqdən sonra siz rejimi dəyişirsiniz və eyni session plan üzrə icraya keçir, araşdırmanın nəticəsi context-də qaldığı üçün heç nə təkrar oxunmur.

Yaxşı plan sorğusu konkret olur. "Auth modulunu refactor et" əvəzinə: "Session-ların Redis-ə köçürülməsi üçün plan hazırla: hansı fayllar dəyişəcək, hansı interface-lər pozulacaq, hansı test-lər əlavə olunacaq, hansı sıra ilə, və hansı addımda rollback mümkündür." Planın özü də yoxlanılmalıdır: mövcud helper-i yenidən yazmağı təklif edirsə, modelin repository-ni kifayət qədər oxumadığının əlamətidir.

Spec-driven development

Plan mode session daxilində işləyir; spec isə session-dan kənarda yaşayır. Spec-driven development-də əvvəlcə faylda, məsələn specs/search.md, nə qurulacağı yazılır: məqsəd, istifadəçi ssenariləri, qəbul meyarları, qeyri-məqsədlər, məhdudiyyətlər. Sonra agent-ə spec verilir. Üstünlükləri birinci fəsildən tanışdır: spec disk-də yaşayır, /clear-dən sonra da qalır, başqa session-a və başqa agent-ə verilə bilir, version control-dadır.

Spec yazmağın iki tələsi var. Birincisi, çox detallı spec: implementasiyanı sətir-sətir diktə etmək agent-in araşdırma qabiliyyətini boşa çıxarır. İkincisi, çox ümumi spec: "yaxşı axtarış olsun" cümləsi ilə agent öz fərziyyələri ilə doldurur. Doğru səviyyə qəbul meyarlarıdır: nə test ediləcəksə, o yazılır. "Axtarış 300 ms-dən tez cavab verir, boş sorğuda bütün nəticələri qaytarır, diakritik işarələrə həssas deyil" kimi cümlələr həm agent-ə, həm də test-lərə bələdçidir.

Yaxşı praktika spec-dən plana, plandan isə addım-addım icraya keçməkdir: spec → plan mode-da plan → təsdiq → icra → test. Hər keçid insanın baxış nöqtəsidir və hər biri bir səviyyə yuxarıda səhvi tutur.

Böyük işi bölmək

Agent bir session-da nə qədər çox iş görürsə, context o qədər dolur və keyfiyyət o qədər düşür. Böyük feature-i kiçik, yoxlanıla bilən addımlara bölmək context engineering-in birbaşa nəticəsidir. Hər addımın öz meyarı olmalıdır: "data modeli və onun test-ləri", sonra "API endpoint-i", sonra "UI". Addım bitəndə commit və /clear; növbəti addım təmiz context ilə başlayır və planı fayldan oxuyur.

Bu bölgü başqa bir imkan açır: addımlar bir-birindən asılı deyilsə, onları paralel işlətmək olar. Burada multi-agent workflow-lar başlayır.

Multi-agent workflow-ların üç forması

Subagent-lər. Əsas agent tapşırığın bir hissəsini ayrı context window-da işləyən subagent-ə verir və nəticəni alır. Bu, bir session daxilində paralellikdir: üç subagent eyni anda üç fərqli modulu araşdırır və ya üç variant yaradır. Subagent-lər 7-ci fəslin mövzusudur.

Paralel session-lar. Bir-birindən asılı olmayan iki feature üçün iki ayrı Claude Code session-ı açmaq olar. Problem eyni working directory-dir: iki agent eyni faylı dəyişsə, nəticə qarışır. Həll git worktree-dir: hər session öz worktree-sində, yəni eyni repository-nin ayrı checkout-unda və ayrı branch-ında işləyir.

git worktree add ../relnotes-search feature/search
cd ../relnotes-search && claude

Hər worktree ayrı qovluqdur, amma eyni git tarixçəsini paylaşır. İş bitəndə branch-lar adi qaydada merge olunur. Claude Code-un özündə də session-ı birbaşa yeni worktree-də açan seçim var; əsas prinsip dəyişmir: paralel agent-lər paralel qovluqlarda.

İerarxik delegasiya. Bir orkestrator agent planı hissələrə bölür, hər hissəni worker agent-ə verir, nəticələri birləşdirir və yoxlayır. 2-ci fəsildəki infinite agentic loop bunun sadə nümunəsidir; 11-ci fəsildəki deep agent-lər isə eyni ideyanı kitabxana səviyyəsində rəsmiləşdirir. İerarxiyanın qiyməti koordinasiyadır: orkestrator hər worker-in nəticəsini context-ində saxlayır, buna görə worker-lər qısa, strukturlu hesabat qaytarmalıdır.

Plan-dan icraya

Təsdiqlənmiş plan icra üçün hazır deyil; onu icra edilə bilən addımlara çevirmək lazımdır. Yaxşı plan addımlarının hər birinin üç xüsusiyyəti var: aydın başlanğıc vəziyyəti, yoxlanıla bilən son vəziyyəti və bir commit-ə sığan ölçüsü. "Axtarış funksiyasını yaz" addım deyil; "search(query) funksiyasını və onun beş test-ini yaz, test-lər keçsin" addımdır.

Claude Code icra zamanı addımları task list kimi göstərir: agent planın bəndlərini yazır, hər birini bitirdikcə işarələyir və siz hər anda işin harada olduğunu görürsünüz. Bu siyahı yalnız sizin üçün deyil; 11-ci fəsildə görəcəyimiz kimi, context-də dayanan plan model-in uzun tapşırıqda məqsədi itirməməsinin əsas mexanizmidir. Addımlar arasında fasilə vermək, yəni commit, qısa review, lazım olanda /compact, hər addımı təmiz context ilə başlatmağın ən sadə yoludur.

Plan icra zamanı dəyişə bilər. Agent ikinci addımda birinci addımın fərziyyəsinin səhv olduğunu görəndə dayanıb deməlidir, davam etməməlidir. Bunu prompt-da açıq yazmaq lazımdır: "plan-dan kənara çıxmalı olsan, əvvəlcə məni məlumatlandır". Plan canlı sənəddir, amma onu dəyişən agent yox, siz olmalısınız.

Orkestrasiya pattern-ləri

Multi-agent işin bir neçə təkrarlanan forması var və hər birinin öz koordinasiya qaydası var:

Fan-out, fan-in. Bir iş bir-birindən asılı olmayan hissələrə bölünür, hər hissə ayrı agent-ə gedir, nəticələr bir yerə yığılır. Üç modulun paralel araşdırması, beş variantın paralel generasiyası, on faylın paralel review-u. Qayda: hissələr həqiqətən müstəqil olmalıdır və fan-in mərhələsində birləşdirmə məntiqi, yəni konfliktlərin necə həll olunacağı, əvvəlcədən bilinməlidir.

Pipeline. Hər agent əvvəlkinin çıxışını alır: spec yazan → plan hazırlayan → icra edən → review edən. Hər mərhələ ayrı context-dir və mərhələlər arasında fayl keçir, söhbət yox. Qayda: hər mərhələnin çıxış formatı sabitdir; mərhələ öz girişini yoxlayır və uyğun gəlməyəndə geri qaytarır.

Generator və reviewer. Bir agent yazır, ikinci agent yoxlayır, birinci düzəldir. Bu, insan review-unun agent-lər arasında təkrarıdır və xüsusilə faydalıdır, çünki yazan agent öz səhvini görməyə meylli deyil; təmiz context-li reviewer onu görür. Qayda: reviewer-in tool-ları yalnız oxumaqdır və dövrün iterasiya limiti var; iki agent bir-birini sonsuz düzəltməməlidir.

Üç pattern-in ortaq tələbi aydın interfeyslərdir: agent-lər arasında keçən şey strukturlu mətn və ya fayldır. Söhbət tarixçəsini bir agent-dən digərinə ötürmək context-i də, qarışıqlığı da ötürür.

Multi-agent sistemin dizayn qaydaları

Paralellik pulsuz deyil. Bir neçə qayda onu idarə olunan saxlayır:

• Aydın sərhəd. Hər agent-in hansı fayllara toxunduğu əvvəlcədən bilinməlidir. İki agent eyni modulu dəyişirsə, bölgü səhvdir.
• Strukturlu nəticə. Worker "bitdi" yox, "dəyişdirilən fayllar, əlavə olunan test-lər, açıq suallar" formatında qaytarmalıdır. Orkestrator-un context-i bu formatla qorunur.
• Müstəqil yoxlama. Hər hissənin öz test-i olmalıdır; birləşdirəndən sonra ümumi test yenidən işləməlidir. Paralel agent-lərin hər biri "mənim hissəm işləyir" deyə bilər, amma inteqrasiya səhvi yalnız birlikdə görünür.
• İnsan nöqtələri. Plan təsdiqi, merge öncəsi review, production-a toxunan hər addım. Avtomatlaşdırma bu nöqtələri silməməli, onlara qədər olan işi sürətləndirməlidir.

Bu qaydaların hamısı eyni fikrə qayıdır: multi-agent workflow planın icrasıdır, planın əvəzi deyil. Plan zəifdirsə, beş agent səhvi beş dəfə sürətli edir.

Tapşırıqlar

1. Layihənizdə orta ölçülü bir dəyişiklik seçin və onu plan mode-da planlaşdırın. Planda modelin yanlış fərziyyəsini tapın: mövcud kodu görməyib, yoxsa tələbi fərqli başa düşüb? Sorğunuzu dəqiqləşdirib planı yenidən alın və iki planı müqayisə edin.
2. Bir feature üçün spec yazın: məqsəd, qəbul meyarları, qeyri-məqsədlər. Spec-i iki ayrı session-a verin və nəticələrin hansı hissələrdə ayrıldığını yoxlayın. Ayrılan hissələr spec-də natamam idi, yoxsa variasiya məqbuldur?
3. Asılı olmayan iki kiçik tapşırığı iki git worktree-də paralel session-larla işlədin. Birləşdirəndə konflikt çıxdımı? Çıxdısa, bölgünü necə dəyişmək lazım idi?