[🛠] AI Orchestration #5: Mendesain ulang pemisahan koordinator dan worker yang pernah saya tinggalkan

✨ Ringkasan GPT-5.6 Sol

Catatan tentang pembagian kerja yang saya tinggalkan ketika pesan worker membuat koordinator kehilangan konteks, lalu saya rancang ulang dengan laporan berbasis file dan commit khusus koordinator setelah mengalami kemacetan sesi tunggal.

Saya pernah menyerah memisahkan koordinator dan worker

Bulan lalu, saya benar-benar menghubungkan koordinator dan beberapa worker. Satu tujuan dibagi menjadi beberapa tugas, lalu koordinator meninjau dan menggabungkan hasil implementasi para worker.

Pembagian kerja itu sendiri cepat. Fitur yang tidak tumpang tindih dapat diimplementasikan bersamaan, sedangkan koordinator hanya menangani arah keseluruhan produk dan integrasi. Masalahnya ada pada cara worker menyampaikan hasil.

Setiap kali selesai atau terhambat, worker mengirim laporan ke sesi koordinator. Awalnya cara itu terasa wajar. Namun, ketika jumlah worker bertambah, laporan terus menumpuk dalam percakapan koordinator, dan setiap pesan baru menghentikan pekerjaan saat ini lalu menarik perhatian ke tugas lain.

Saya sedang membaca hasil tes satu worker, beralih memeriksa konflik Git index worker lain, lalu menerima laporan selesai berikutnya tepat saat hendak kembali ke implementasi awal. Percakapan cepat memanjang. Semakin sering kompaksi terjadi, semakin banyak waktu yang dibutuhkan untuk memulihkan tujuan, larangan deployment, dan status stage saat ini. Pada satu titik, koordinator lebih mirip loket penerima pesan worker daripada integrator.

Akhirnya saya menyerah pada pemisahan koordinator dan worker itu sendiri. Skill koordinasi yang sudah dibuat pun saya hapus secara impulsif. Saya berpikir bahwa mengerjakan semuanya di satu sesi utama setidaknya akan mencegah konteks ditarik ke berbagai arah.

Kembali ke satu sesi menunjukkan mengapa pembagian kerja diperlukan

Namun, ketika pekerjaan produk besar berlanjut dalam satu sesi, kemacetan dari sisi berlawanan langsung terlihat.

Implementasi, tes, penyelarasan dokumen, pemeriksaan perangkat fisik, dan persiapan Runtime semuanya harus ditangani secara berurutan oleh sesi yang sama. Jika pertanyaan prioritas atau handoff dari sesi lain masuk di tengah, saya harus memulihkan dulu status pekerjaan yang sedang berlangsung. Menuntaskan satu hal dengan pasti memperpanjang keseluruhan proses; menangani hal mendesak lebih dulu menuntut keputusan baru tentang seberapa jauh pekerjaan lama perlu ditutup.

Masalahnya bukan pembagian kerja. Justru tidak efisien bila satu sesi menahan bahkan tugas-tugas yang saling independen. Memisahkan koordinator dan worker tetap merupakan pendekatan paling efisien. Namun, menghidupkan kembali struktur tempat worker masuk langsung ke percakapan koordinator hanya akan mengulangi kegagalan yang sama.

Kali ini, alih-alih meninggalkan pembagian kerja, saya memutuskan menghapus jalur penyampaian yang memutus konteks koordinator.

Notifikasi satu baris pun membuka pintu yang sama

Awalnya saya berpikir worker mungkin cukup mengirim satu pesan pendek alih-alih laporan panjang.

READY task-042: path laporan

Namun, panjang bukan masalahnya. Begitu sebuah pesan masuk ke percakapan koordinator, Codex dapat dengan mudah memperlakukannya sebagai konteks yang lebih baru daripada pekerjaan yang sedang berjalan. Satu baris pun tetap membuka pintu yang sama untuk berpindah tugas.

Karena itu, worker tidak lagi mengirim pesan kepada koordinator. Status selesai, terhambat, dan gagal hanya ditulis ke file laporan. Koordinator memeriksa inbox setelah pekerjaannya sendiri mencapai checkpoint atau commit yang aman.

Datangnya laporan bukan peristiwa yang harus memutus pekerjaan saat ini. Itu hanya menambahkan satu file ke antrean tinjauan berikutnya.

Worktree bersih, tetapi menjauh dari keadaan terbaru

Selanjutnya saya mempertimbangkan Worktree dan Branch terpisah untuk setiap worker. Git index dan perubahan yang belum di-commit tidak bercampur, sehingga tampak sebagai pilihan paling bersih.

Dalam proyek nyata, masalah yang lebih besar muncul. Beberapa fitur terus menyentuh API, schema, dan layar yang sama. Perbaikan yang lebih dahulu selesai di satu sesi tidak langsung terlihat di Worktree lain. Setiap orang bekerja dengan bersih, tetapi saat integrasi, perubahan yang dibangun di atas struktur lama sudah menumpuk. Jumlah pekerjaan ulang pun menjadi buruk.

Kali ini saya memilih struktur sebaliknya.

Satu main Working Tree
├─ Beberapa worker melihat perubahan terbaru bersama-sama
├─ Worker hanya mengedit file dan hunk yang ditugaskan
├─ Worker tidak melakukan stage atau commit
└─ Hanya koordinator yang meninjau, melakukan stage, dan commit

Working Tree bersama juga akan segera kusut tanpa batasan. Secara default, satu file memiliki satu writer; pengeditan paralel pada file yang sama hanya diperbolehkan jika hunk terpisah dengan jelas. Schema bersama, pembersihan import, formatter, dan perubahan yang menggeser kode sekitar dikerjakan secara serial.

Tes yang dijalankan worker juga tidak langsung dipercaya sebagai bukti akhir. Tes itu mungkin berjalan bersama perubahan worker lain yang belum di-commit. Worker memeriksa ruang lingkupnya sendiri; koordinator membekukan kumpulan perubahan lalu menjalankan regresi penuh dan build satu kali.

Laporan menjadi kontrak tinjauan, bukan pesan percakapan

Saya membangun kembali Skill koordinasi yang dihapus berdasarkan prinsip ini. Skill baru custom-coordinate-parallel-workers berisi alur tersebut.

Koordinator menetapkan task id, hasil yang harus diperoleh pengguna, dan path yang boleh ditulis. Worker menyelesaikan implementasi, verifikasi terbatas, serta pembersihan proses sementara, lalu membuat laporan secara atomik dan berhenti. Laporan mencantumkan file yang benar-benar diubah, hasil pemeriksaan, tumpang tindih dengan pekerjaan lain, ruang lingkup yang belum selesai, dan commit yang diusulkan.

Koordinator tidak membaca ulang semua percakapan. Ia lebih dahulu memeriksa task id, status, judul, dan ringkasan pemeriksaan di inbox, lalu memilih satu tugas berikutnya untuk diintegrasikan. Setelah memastikan laporan sesuai dengan diff nyata, ia hanya melakukan stage dan commit pada hunk yang tepat.

Setelah kandidat release dipilih, freeze mencegah mutation worker berikutnya. Alih-alih mengulang tes penuh ketika perubahan terus masuk, dokumentasi current state, regresi penuh, build, dan verifikasi deployment dimulai setelah kumpulan release berhenti berubah.

Laporan bukan lagi sekadar catatan kerja. Ia menjadi kontrak tinjauan yang memungkinkan koordinator mempercayai perubahan dan membawanya ke keadaan berikutnya.

Sekarang harus dijalankan dalam pekerjaan nyata

Saya menguji alat pengelolaan status Skill di lingkungan sementara yang terisolasi. Penyelesaian normal, konflik path yang dapat ditulis, pengerjaan ulang setelah permintaan perubahan, penolakan freeze saat masih berjalan, dan penundaan ke batch berikutnya semuanya lolos.

Namun, saya belum mengoperasikan beberapa sesi Codex nyata dengan cara ini. Tugas paralel berikutnya harus menunjukkan apakah laporan berbasis file benar-benar lebih sedikit mengguncang konteks koordinator dan apakah kepemilikan path di Working Tree bersama dipatuhi seperti yang diharapkan.

Kesimpulannya mirip dengan titik awal, tetapi alasannya kini lebih jelas. Koordinator dan worker perlu dipisahkan. Yang gagal bukan pembagian kerja, melainkan cara mendorong setiap laporan worker secara real time ke percakapan koordinator saat ini.

Perubahan yang saya harapkan bukan sekadar membuka lebih banyak worker. Tujuannya adalah membiarkan koordinator menjaga konteksnya sendiri sampai pekerjaannya selesai. Kecepatan kerja paralel lebih sedikit bergantung pada jumlah worker dan lebih banyak pada seberapa jarang orang yang mengintegrasikan hasil mereka ditarik ke tempat lain.