Workflow Paralel: Banyak AI Kerja Bareng

Sampai episode 9, workflow kita selalu satu per satu. Satu perintah diketik, hasilnya ditunggu, diperiksa, baru lanjut ke perintah berikutnya. Pola ini aman, tapi lambat. Sekarang bayangkan skenario ini. Kamu sedang membangun fitur login. Sambil satu AI menulis kode autentikasinya, AI lain menulis dokumentasi API-nya, dan AI ketiga menulis unit test-nya. Tiga pekerjaan jalan bersamaan dan semuanya selesai dalam waktu yang hampir sama. Itulah workflow paralel, topik episode 10 seri Vibe Coding Pro ini.

Catatan jujur seperti biasa. Teknik di bawah ini disusun dari dokumentasi resmi tools AI coding dan laporan komunitas developer per Oktober 2026. Saya tidak akan mengklaim sudah menjalankannya di produksi bertahun-tahun. Anggap ini panduan praktik yang bisa kamu uji sendiri minggu ini, lalu nilai apakah cocok dengan gayamu.

Apa Itu Workflow Paralel

Workflow paralel artinya kamu memberikan beberapa tugas ke AI dalam waktu yang bersamaan, bukan berurutan. Analogi dapurnya begini. Selama ini kamu masak seperti punya satu tungku kompor. Air direbus dulu sampai mendidih, baru telur digoreng. Workflow paralel itu seperti punya empat tungku sekaligus. Air direbus, telur digoreng, nasi dimasak, dan sambal diulek, semuanya pada saat yang sama.

Dalam konteks AI coding, tiap "tungku" adalah sesi AI yang berbeda. Satu sesi mengerjakan fitur, sesi lain mengerjakan test, sesi ketiga menulis dokumentasi. Kamu tidak menunggu satu sesi selesai untuk memulai yang lain. Keuntungan utamanya jelas, yaitu waktu. Tiga tugas yang masing-masing butuh 10 menit bisa selesai dalam sekitar 10 menit, bukan 30 menit. Tapi ada syarat penting: tugas-tugas itu harus cukup mandiri dan tidak saling bergantung. Syarat inilah yang akan kita bedah sampai tuntas, karena di sinilah kebanyakan pemula terpeleset.

Tiga Cara Memisahkan Kerja AI

Agar beberapa AI bisa kerja bareng tanpa tabrakan, ruang kerja mereka harus dipisahkan. Ada tiga cara umum, dari yang paling sederhana sampai yang paling rapi. Pilih yang sesuai dengan besarnya tugasmu.

Cara 1: sesi terpisah, area file yang berbeda. Ini yang paling gampang dan tidak butuh setup apa-apa. Kamu membuka dua sesi AI di proyek yang sama, tapi memberi mereka area yang jelas berbeda. Misalnya sesi A hanya boleh menyentuh folder src/auth, sesi B hanya boleh menyentuh folder docs. Kuncinya ada di instruksi yang eksplisit di prompt, contohnya: "kamu HANYA boleh mengubah file di folder docs, jangan sentuh folder lain". Cara ini cepat tapi rapuh, karena batasnya hanya berupa janji di dalam prompt. Kalau AI-nya "lupa", tidak ada yang mencegahnya.

Cara 2: branch git terpisah. Ini cara yang lebih disiplin. Sesi A bekerja di branch fitur-auth, sesi B bekerja di branch docs-api. Masing-masing AI punya cabang kerjanya sendiri, jadi tidak ada risiko saling menimpa. Setelah keduanya selesai, kamu menggabungkannya lewat merge atau pull request seperti biasa. Cara ini cocok untuk tugas yang agak besar dan butuh waktu lama, karena tiap sesi punya riwayat perubahannya sendiri yang bisa kamu periksa.

Cara 3: git worktree. Ini versi paling rapi. Git worktree memungkinkan satu repository punya beberapa folder kerja sekaligus, masing-masing dengan branch yang berbeda. Jadi kamu bisa punya folder proyek-auth dan proyek-docs yang isinya repository yang sama tapi branch berbeda. Tiap sesi AI bekerja di foldernya sendiri, benar-benar terpisah di level file system. Contoh perintahnya seperti ini.

git worktree add ../proyek-auth fitur-auth
git worktree add ../proyek-docs docs-api

Setelah itu, buka satu sesi AI di tiap folder. Mereka tidak akan pernah tabrakan karena memang bekerja di direktori yang berbeda. Saat selesai, hapus worktree-nya dengan git worktree remove ../proyek-auth setelah branch-nya di-merge.

Contoh Skenario: Fitur Auth Jalan, Dokumentasi Ikut Jalan

Mari kita buat konkret. Misalkan kamu membangun aplikasi kasir sederhana untuk tugas sekolah. Kamu butuh dua hal: fungsi login dan dokumentasi cara pakai API-nya. Begini pembagian tugasnya. Tugas 1 (sesi A, branch fitur-auth): buatkan fungsi login dengan validasi. Tugas 2 (sesi B, branch docs-api): tuliskan dokumentasi endpoint API dalam format Markdown. Kedua tugas ini mandiri. Sesi B tidak perlu menunggu kode sesi A selesai, karena dokumentasi bisa ditulis dari rancangan endpoint yang sudah kamu tentukan di awal.

Ini contoh prompt untuk sesi A yang siap kamu salin dan sesuaikan.

Buatkan fungsi login di file src/auth.js.
Batasan:
- input: email dan password (string)
- validasi: email harus mengandung @, password minimal 8 karakter
- kembalikan objek { sukses: true } atau { sukses: false, pesan: "..." }
- JANGAN mengubah file di luar folder src/auth
Tulis juga 3 contoh pemakaian di komentar.

Dan ini prompt untuk sesi B.

Tuliskan dokumentasi API login di file docs/api-login.md.
Struktur: deskripsi endpoint, format request (JSON), format response sukses,
format response gagal, dan 1 contoh memakai curl.
JANGAN mengubah file di luar folder docs.

Perhatikan pola yang sama di kedua prompt: tugas yang jelas, batasan yang konkret, dan larangan menyentuh area lain. Tiga baris terakhir di tiap prompt itulah yang membuat paralelnya aman.

Kapan Paralel Membantu, Kapan Malah Bikin Kacau

Paralel membantu ketika tiga syarat terpenuhi. Pertama, tugasnya mandiri. Hasil tugas A tidak dibutuhkan untuk memulai tugas B. Contoh yang bagus: menulis dokumentasi dari rancangan yang sudah fix, atau menulis test dari spesifikasi yang sudah jelas. Kedua, area kerjanya terpisah. Beda folder, beda branch, atau beda worktree. Ketiga, kamu masih sanggup mereview semuanya. Tiga tugas paralel berarti tiga hasil yang harus kamu periksa satu per satu. Kalau kamu tidak sanggup mereview tiga-tiganya dengan teliti, lebih baik jalan dua saja.

Paralel bikin kacau ketika syarat di atas dilanggar. Contoh paling umum: dua AI disuruh refactor file yang sama. Hasilnya bisa berupa perubahan yang saling menimpa, atau lebih parah, kode yang terlihat rapi tapi logikanya tercampur dari dua versi berbeda. Contoh lain: AI disuruh menulis test untuk kode yang masih ditulis AI lain. Test-nya jadi menebak-nebak isi kode yang belum ada, dan tebakan itu hampir selalu salah. Aturan praktisnya sederhana: kalau tugas B butuh hasil tugas A, jangan diparalel. Kerjakan berurutan, titik.

Cara Menggabungkan Hasilnya

Setelah semua sesi selesai, pekerjaanmu belum beres. Ada tiga langkah penggabungan yang tidak boleh dilewati. Langkah 1: review satu per satu. Baca perubahan tiap sesi seperti kamu membaca pull request dari teman sekelas. Jangan percaya begitu saja hanya karena yang menulis AI. Langkah 2: gabungkan. Kalau memakai branch terpisah, merge satu per satu ke branch utama dan selesaikan konflik bila ada. Kalau memakai folder yang sama, pastikan tidak ada file yang tertimpa diam-diam. Langkah 3: uji integrasi. Jalankan aplikasinya. Fitur auth dan dokumentasi mungkin dikerjakan terpisah, tapi keduanya harus konsisten. Kalau dokumentasi bilang endpoint-nya /api/login tapi kodenya memakai /api/masuk, itu ketahuan di langkah ini, bukan saat demo di depan kelas.

Satu tips penting: beri tahu tiap sesi AI tentang keberadaan sesi lain, tapi batasi wewenangnya. Contoh kalimat di prompt: "Tim lain sedang mengerjakan dokumentasi di folder docs. Kamu tidak perlu menunggunya, tapi jangan mengubah folder itu." Dengan begitu AI tidak kaget saat melihat perubahan yang bukan buatannya, dan tidak mencoba "memperbaiki" pekerjaan sesi lain.

Jebakan Umum Workflow Paralel

Jebakan 1: terlalu banyak sesi sekaligus. Lima sesi paralel terdengar keren, tapi kamu tetap satu orang yang harus mereview lima hasil. Mulailah dari dua sesi. Tambah jumlahnya kalau kamu sudah nyaman dan review-mu masih teliti.

Jebakan 2: instruksi batas area yang samar. Kalimat "jangan ganggu pekerjaan lain" itu terlalu abstrak buat AI. Sebutkan nama folder atau file yang boleh dan tidak boleh disentuh, seperti contoh prompt di atas. Spesifik itu murah, menebak itu mahal.

Jebakan 3: menggabungkan tanpa menjalankan ulang. Kode dari dua sesi yang digabung bisa rusak di titik temu yang tidak disangka. Selalu jalankan aplikasi atau test-nya setelah merge, jangan hanya membaca diff-nya lalu menganggap beres.

Latihan Minggu Ini

Jangan cuma membaca. Latihanmu minggu ini ada tiga langkah. Pertama, siapkan satu proyek kecil yang sudah memakai git, misalnya aplikasi todo list dari episode sebelumnya. Kedua, buat dua branch: satu untuk fitur baru (misalnya fitur hapus semua todo), satu untuk dokumentasi (misalnya README cara menjalankan aplikasi). Ketiga, jalankan dua sesi AI paralel dengan prompt yang membatasi area kerja seperti contoh di atas, lalu gabungkan hasilnya dan jalankan aplikasinya. Catat satu hal: di titik mana kamu merasa paralelnya membantu, dan di titik mana kamu merasa ribet. Catatan itu adalah insting workflow-mu yang sedang terbentuk, dan insting seperti itu tidak bisa dibeli.

Di episode 11 kita akan lanjut ke "Bikin MCP Server Sendiri untuk Proyekmu", yaitu cara memberi AI akses ke tools dan data milikmu sendiri lewat colokan standar bernama MCP, supaya AI tidak cuma bisa baca kode tapi juga bisa mengintip database dan API internalmu. Sampai jumpa besok jam 21:00. Bakar semangat kodingmu seperti api kompor.