Di tim dev VM0, setiap developer bekerja dengan banyak instance Claude Code sekaligus. Biasanya lebih dari delapan.
Kami memperlakukan Claude Code sama seperti kami memperlakukan developer sungguhan. (Ya, perusahaan kami setengah bercanda disebut AI Colleagues Co!)
Karena itu, filosofi desain di balik alur kerja dev VM0 mencerminkan praktik manajemen tim klasik dalam software engineering.
Kami menggunakan GitHub Issues untuk melacak pekerjaan, Pull Request untuk code review dan merging, serta GitHub Actions untuk menangani otomasi. Selama dua bulan, penyiapan ini membantu kami merilis 404 release dan menulis lebih dari 230.000 baris kode.
Posting ini menjelaskan bagaimana kami membuatnya dapat berjalan, dan mengapa masalah utamanya tidak pernah soal kemampuan AI, melainkan koordinasi manusia.
Alur kerja dev bertenaga AI dalam praktik
Ketika Anda mengoordinasikan banyak agent AI secara paralel, hambatannya bukan apakah model bisa menulis kode. Hambatan sesungguhnya adalah beban kognitif manusia
Alur kerja ini terdiri dari 14 slash command, yang diorganisasi ke dalam tiga lapis: Deep Dive, Issue Management, dan PR Management.
Mari pertama-tama lihat seperti apa alur kerja saya dan bagaimana sebuah fitur biasanya dibangun.
-
Penyelarasan kebutuhan
Seorang manusia membuka sesi Claude dan memulai dengan
/deep-research. Claude mengumpulkan fakta dari basis kode, dokumentasi, dan konteks yang relevan. Kami mendiskusikan temuannya dan menyelaraskan masalah apa yang sebenarnya sedang kami pecahkan. -
Eksplorasi solusi
Menggunakan
/deep-innovate, Claude mengusulkan beberapa kemungkinan arah, beserta trade-off-nya. Kami berdiskusi, mempersempit, dan memilih satu arah. -
Pembuatan issue
Kami membuat GitHub issue menggunakan
/issue-create. Manusia meninjau issue tersebut untuk memastikan kebutuhan tertangkap dengan jelas. -
Perencanaan dan persetujuan
Gunakan
/issue-planuntuk membiarkan Claude melanjutkan pekerjaan. Claude akan otomatis menjalankan alur kerja deep-dive secara penuh dan memposting hasilnya ke issue, termasuk:- temuan dari
/deep-research - perbandingan dari
/deep-innovate - rencana implementasi konkret dari
/deep-plan
- temuan dari
-
Implementasi
Setelah disetujui,
/issue-actionmembiarkan Claude mengimplementasikan rencana, menulis test, membuka PR, dan memastikan CI lolos. -
Review dan merge
Kami menggunakan
/pr-reviewuntuk review terstruktur, lalu melakukan review manusia final sebelum merge.Manusia turun tangan di tiga checkpoint: kebutuhan, arah, dan penerimaan. Selebihnya berjalan secara otonom.
Pergeseran pola pikir: Anda memimpin tim developer AI
Saat saya menyadari bahwa kami membutuhkan alur kerja terstruktur adalah ketika menambah lebih banyak sesi Claude justru memperburuk keadaan. Semakin banyak instance yang saya jalankan secara paralel, semakin sulit melacak apa yang sedang dilakukan masing-masing, dalam keadaan apa pekerjaannya, dan apa yang sudah diputuskan.
Tanpa tool eksternal, saya sama sekali tidak bisa mengelola sebanyak itu instance Claude sekaligus. Saat itulah saya tersadar: ini bukan masalah AI, ini masalah manajemen.
GitHub sudah menjadi tool alami untuk kolaborasi dalam pengembangan perangkat lunak, jadi alih-alih menciptakan sesuatu yang baru, saya mulai memperlakukan Claude sama seperti saya memperlakukan rekan tim manusia. Begitu saya melakukannya, kapasitas manajemen saya tiba-tiba berskala.
Sepuluh tahun pengalaman manajemen proyek dan tim akhirnya masuk akal dalam konteks baru ini. Dengan memperlakukan Claude sebagai anggota tim dan GitHub sebagai ruang komunikasi serta manajemen bersama kami, seluruh sistem kembali dapat dikelola.
Pemimpin tim yang baik tahu kapan harus terlibat dan kapan harus mundur:
| Checkpoint | Apa yang saya lakukan | Apa yang dilakukan AI |
|---|---|---|
| Kebutuhan | Menyelaraskan masalah, memperjelas cakupan | Meriset basis kode, mengumpulkan konteks |
| Arah | Meninjau temuan, menyetujui pendekatan | Mengusulkan 2-3 pendekatan, mengevaluasi trade-off |
| Penerimaan | Meninjau PR, memverifikasi kualitas | Mengimplementasikan, menguji, memperbaiki CI |
Ini mencerminkan cara tim perangkat lunak yang efektif beroperasi. Saya tidak memikromanajemen developer melainkan menetapkan kebutuhan yang jelas, meninjau keputusan kunci, dan memverifikasi keluaran akhir. Prinsip yang sama berlaku saat mengelola agent AI.
Alur deep dive memaksakan pemikiran terstruktur dan lambat
Alur kerja deep dive memaksakan pemikiran yang cermat sebelum implementasi. Terkadang Claude menemui jalan buntu. Ketika itu terjadi, kami memaksa Claude berhenti dan berpikir, lalu membahasnya bersama. Alur ini punya tiga fase:
| Fase | Command | Tujuan | Keluaran |
|---|---|---|---|
| Research | /deep-research | Mengumpulkan fakta, memahami konteks | research.md |
| Innovate | /deep-innovation | Mengeksplorasi banyak pendekatan | innovate.md |
| Plan | /deep-plan | Menentukan langkah konkret | plan.md |
Setiap fase punya batasan ketat.
- Research: tanpa saran
- Innovate: tanpa detail
- Plan: tanpa implementasi
Batasan-batasan ini memaksa Claude masuk ke penalaran yang lambat dan cermat alih-alih langsung melompat ke kode. Tanpa itu, kasus tepi dan kekhawatiran arsitektural sering terlewat!
Contoh penggunaan
/deep-research investigate the authentication flow, I'm seeing token expiration issues
[Claude researches, analyzes 12 related files, finds 3 similar patterns]
/deep-innovate what are our options for fixing this?
[Claude presents 3 approaches with trade-offs, you pick one]
/issue-create let's track this fix
Untuk tugas sederhana, Anda bisa melewati deep dive dan langsung ke /issue-create.
Untuk tugas kompleks dengan ketidakpastian teknis, fase deep dive membantu memastikan Anda dan Claude selaras sebelum implementasi dimulai.
Gunakan GitHub sebagai memori bersama
Sebagian besar tool AI memperlakukan konteks sebagai sementara. Ketika sesi berakhir, memorinya menghilang.
VM0 menggunakan GitHub sebagai memori persisten:
| Fitur GitHub | Apa yang disimpan |
|---|---|
| Body issue | Kebutuhan dan keputusan |
| Komentar issue | Riset, opsi, rencana |
| Komentar PR | Review dan ringkasan |
| Label | Status alur kerja |
Ini juga memecahkan masalah manusia: pemulihan konteks.
Ketika saya mengelola 8+ instance Claude, saya menerima notifikasi bahwa pekerjaan selesai. Tetapi saya tidak bisa merekonstruksi dari percakapan Claude apa yang sedang dikerjakannya, keputusan apa yang dibuat, atau apa keadaan saat ini.
GitHub issue memecahkan ini. Setiap issue menampilkan:
- Kebutuhan asli
- Temuan riset (apa yang ditemukan)
- Fase inovasi (opsi apa yang dipertimbangkan)
- Rencana yang disetujui (apa yang akan diimplementasikan)
Format terstruktur ini membuat review jadi efisien. Jadi saya bisa cepat memindai fase-fasenya, memahami pendekatannya, dan menyetujui atau meminta perubahan, semuanya tanpa perlu mengingat percakapan aslinya.
Ketika pekerjaan selesai, saya tak perlu mengingat apa yang terjadi di jendela chat. Saya bisa membuka issue dan melihat keseluruhan ceritanya, terstruktur dan tertulis.
Serah terima antar agent
Karena semua konteks tinggal di GitHub, pekerjaan bisa berpindah antar agent dengan mulus:
- Satu agent membuat issue atau PR
- Agent lain melanjutkan nanti menggunakan
/deep-research issue 123atau/issue-plan 123atau/deep-research PR 124
Untuk diskusi panjang, /issue-compact mengonsolidasikan semuanya ke dalam body issue yang bersih. Ini membuat serah terima jadi mudah baik untuk manusia maupun AI.
Mari rangkum pola alur kerjanya
Setelah semua itu, izinkan saya merangkum beberapa tips praktis.
Tugas sederhana
/issue-create → /issue-plan → /issue-action → /pr-check-and-merge
Gunakan ini ketika kebutuhan jelas dan pekerjaannya lugas.
Tugas kompleks
/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check
Ini mencegah usaha terbuang pada pendekatan yang salah.
Pekerjaan paralel
Banyak agent bisa bekerja sekaligus selagi manusia meninjau checkpoint yang sudah selesai. Di sinilah alur kerja berskala paling baik.
Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements
Referensi command
Command deep dive
| Command | Tujuan |
|---|---|
/deep-research | Mengumpulkan informasi, memahami basis kode. Tidak boleh ada saran. |
/deep-innovate | Mengeksplorasi 2-3 pendekatan, mengevaluasi trade-off. Tidak boleh ada kode. |
/deep-plan | Membuat langkah implementasi konkret. Tidak boleh ada implementasi. |
Command issue
| Command | Tujuan |
|---|---|
/issue-create | Membuat issue dari konteks percakapan |
/issue-bug | Membuat laporan bug dengan langkah reproduksi |
/issue-feature | Membuat permintaan fitur yang berfokus pada kebutuhan |
/issue-plan | Menjalankan alur kerja deep-dive penuh, memposting hasil ke issue |
/issue-action | Melanjutkan implementasi setelah persetujuan manusia |
/issue-compact | Mengonsolidasikan body + komentar issue untuk serah terima |
Command PR
| Command | Tujuan |
|---|---|
/pr-check | Memantau pipeline CI, perbaikan otomatis, coba ulang hingga 3x |
/pr-review | Meninjau PR commit-per-commit terhadap standar proyek |
/pr-comment | Meringkas diskusi percakapan menjadi komentar PR |
Memulai
- Mulai sederhana: Gunakan
/issue-create→/issue-plan→/issue-actionuntuk tugas pertama Anda - Tambahkan deep dive untuk tugas kompleks: Ketika kebutuhan tidak jelas atau secara teknis kompleks, mulailah dengan
/deep-research - Berskala secara bertahap: Tambahkan lebih banyak instance Claude seiring Anda terbiasa dengan ritme review
- Percayai prosesnya: Biarkan Claude bekerja secara otonom di antara checkpoint
Alur kerja ini dirancang untuk diadopsi secara bertahap. Anda tidak perlu menggunakan semua 14 command sejak hari pertama. Mulailah dengan alur issue dasar, lalu tambahkan fase deep dive dan pekerjaan paralel seiring tumbuhnya kepercayaan diri Anda.
Pertimbangan penskalaan: Apa yang harus dilakukan saat Anda punya lebih banyak agent
Alur kerja ini telah diuji dengan 10+ instance Claude bersamaan. Rekomendasi kami:
- Hingga 10 agent: Nyaman untuk kolaborasi mendalam dengan masing-masing
- Lebih dari 10: Tidak disarankan
Faktor pembatasnya bukan alur kerja, melainkan perhatian manusia dan kualitas keputusan. Ketika mengelola lebih dari 10 agent, Anda berisiko menjadi hambatan di checkpoint review, dan kualitas keputusan mulai menurun.
Prinsip klasik "two pizza team" berlaku di sini. Batasan yang sama yang membatasi ukuran tim manusia juga membatasi berapa banyak agent AI yang bisa dikelola satu orang secara efektif.
Saya saat ini sedang mengeksplorasi struktur tim dua tingkat 8×8 untuk berskala melampaui 10 agent, tetapi belum mengembangkan praktik yang efektif. Saya akan berbagi lebih banyak ketika ada hasil yang konkret…
Alur kerja dev VM0 mengubah cara kami memandang pengembangan perangkat lunak ketika AI menjadi bagian dari tim.
Ketika Anda memperlakukan agent AI sebagai anggota tim alih-alih tool, semuanya jatuh pada tempatnya. GitHub menjadi memori bersama tim Anda. Issue menjadi item pekerjaan. PR menjadi keluaran. Dan Anda menjadi pemimpin tim, berfokus pada arsitektur, arah, dan kualitas selagi tim AI Anda menangani implementasinya.
Begitulah cara kami merilis 404 release dalam 2 bulan. Dan begitulah cara Anda bisa menskalakan pengembangan Anda sendiri dengan AI.
