Menjalankan Claude Code Seperti Tech Lead, Bukan Senior Engineer

Sebulan lalu saya menulis soal memperlakukan Claude seperti rekan junior: beri brief yang jelas, rencanakan sebelum menulis kode, baca diff-nya. Tulisan itu masih berlaku, tapi sekarang terasa seperti lantai dasar, bukan lantai tempat saya bekerja.

Sekitar Juli, aktivitas saya berhenti menjadi pair programming dengan AI dan berubah jadi sesuatu yang lain. Saya mendapati empat sesi Claude Code terbuka sekaligus: satu sedang membangun fitur, satu menjalankan pengujian di simulator, satu mengunyah migrasi di worktree terpisah, satu lagi mereview pull request yang bahkan belum saya baca.

Saya tidak sedang menulis kode. Saya bahkan tidak sedang memberi brief ke satu agent. Saya sedang menjalankan sebuah tim.

Dan menjalankan tim adalah keterampilan yang sama sekali berbeda dari sekadar jago mengerjakan sendiri. Setiap engineer yang pernah dipromosikan jadi lead tahu rasanya: hal yang membuatmu bagus saat mengerjakan sendiri malah memperlambat semua orang.

Di situlah sebagian besar pengguna Claude Code sekarang terjebak. Bukan karena prompt-nya kurang bagus, tapi karena mereka masih beroperasi sebagai satu individual contributor yang sangat produktif, ditemani asisten yang sangat cepat.

Berhenti Membuka Sesi, Mulai Membuka Tim

Kebiasaan pertama yang harus dipatahkan: cd ke repo, jalankan claude, lalu menganggap satu jendela itu sebagai "tempat Claude tinggal". Jendela itu cuma satu anggota tim. Kamu punya tim.

BASH

claude agents

Itu tampilan papan: satu layar untuk semua sesi Claude Code yang sedang berjalan, mana yang bekerja, mana yang terblokir menunggu keputusanmu, mana yang sudah selesai. Tiap baris menampilkan status berwarna dan satu kalimat tentang apa yang sebenarnya dikerjakan sesi tersebut; sesi yang terikat ke pull request atau merge request diberi label nomor PR-nya.

Saat pertama membukanya, saya melihat enam sesi hidup dan benar-benar lupa pada dua di antaranya. Ini layar seorang tech lead: bukan terminal, tapi papan kerja.

Pergeseran mentalnya kecil tapi mengubah segalanya. Kamu berhenti bertanya "Claude sedang apa" dan mulai bertanya "apa yang terblokir".

Memecah Pekerjaan Seperti Memecah Tiket

Alur kerja yang membuat semua ini klik bagi saya sederhana sekali: dua sesi, satu bernama developer, satu bernama QA.

Sesi developer menerima PRD dan membangun. Sesi QA memasang harness pengujian, menjalankan aplikasi, menelusuri alurnya, lalu melaporkan apa yang rusak. Tidak ada satu sesi pun yang mengerjakan dua pekerjaan sekaligus, dan itu intinya. Sesi yang menulis kode adalah reviewer terburuk untuk kode itu sendiri.

Yang kemudian membuat dua sesi berubah dari "dua tab" menjadi "satu tim": sesi bisa saling mengirim pesan. Claude menemukan sesi lain lewat ListAgents dan mengirim pesan dengan SendMessage, baik saat kamu perintahkan maupun inisiatif sendiri ketika perubahannya memengaruhi sesi lain.

Kamu cukup mengatakannya dengan bahasa biasa:

CODE

Beri tahu sesi yang mengerjakan API pembayaran bahwa users.name sekarang users.display_name

Sesi tujuan akan menampilkan baris pesan masuk; tekan Ctrl+O untuk memperluasnya. Bisa juga menyebut sesi lain langsung dengan mengetik @ di prompt, kalau namanya cocok dengan tepat satu sesi hidup, pesan langsung terkirim tanpa konfirmasi. Jalankan /list-agents untuk melihat siapa saja yang bisa dihubungi.

Sesi di satu mesin memakai nama unik. Kalau kamu memakai nama yang sudah dipakai, Claude Code mengganti namamu dengan varian nama-kata-kata dan memberi tahu. Fitur ini tersedia di macOS, Linux, dan Windows native sejak akhir Agustus.

Yang digantikannya adalah hal yang tidak kamu sadari memakan satu jam sehari: menjelaskan ulang konteks. Menyalin keputusan dari satu terminal ke terminal lain, dengan setengah alasannya hilang. Seorang lead tidak memberi brief ulang ke tiap orang satu per satu. Seorang lead memastikan informasi bergerak menyamping, bukan lewat dirinya.

Fork untuk Konteks, Sesi Baru untuk Isolasi

Dua hal tersebut terlihat mirip, padahal berbeda.

Fork adalah tugas sampingan yang sudah tahu semua yang pernah kamu bahas. Mode fork sekarang aktif secara default di sesi interaktif, jadi Claude bisa memunculkan subagent yang mewarisi percakapan dan prompt cache penuh, bukan mulai dari nol.

CODE

/subtask susun unit test untuk perubahan parser sejauh ini

Perintah itu muncul di panel bawah prompt, berjalan di latar belakang, dan hasilnya masuk ke percakapanmu saat selesai, kamu tetap bekerja sepanjang prosesnya. Perhatikan frasa "sejauh ini": itulah wilayah kerja fork. Tugas yang hanya bermakna dalam konteks percakapan ini. Test untuk yang baru saja kita bangun, ringkasan keputusan yang baru saja kita ambil, pendapat kedua atas pendekatan yang baru saja kita debatkan.

Sesi baru adalah jalur paralel: masalah lain, konteks lain, kepalanya sendiri. /fork menyalin percakapanmu ke sesi latar belakang baru dan (ini bagian pentingnya) membuat perubahan kode di worktree sendiri, bukan di checkout kamu.

Aturan yang saya pakai:

Salah menerapkan ini adalah alasan eksperimen "Claude paralel" banyak orang berakhir berantakan: mereka memunculkan lima sesi di satu checkout, lalu heran kenapa diff-nya saling bertabrakan.

Isolasi, atau Merge Conflict Datang dari AI-mu Sendiri

Ini bagian yang dilewati senior engineer dan tidak pernah dilewati tech lead. Empat sesi mengedit satu working copy bukan paralelisme, itu race condition yang namamu ada di commit-nya.

Jawabannya worktree, dan sekarang cukup serius:

BASH

claude --worktree https://github.com/org/repo/pull/128

Perintah itu menurunkan sesi dari pull request itu sendiri. URL merge request GitLab berlaku sama. Isolasi worktree sekarang tidak cuma memblokir edit file, tapi juga perintah Bash dan pengalihan git yang mencoba menjangkau checkout utama, di semua jenis sesi dan subagent di dalamnya. Jadi agent latar belakang tidak bisa diam-diam git checkout masuk ke direktori kerjamu.

Sesi latar belakang yang mengubah kode di worktree juga akan commit dan push sebelum selesai, membuka draft pull request kalau tugasnya memang menuntut itu, dan mengikuti instruksi git di CLAUDE.md kamu.

Baca bagian terakhir sekali lagi, karena di situ kunci sebenarnya: CLAUDE.md sekarang adalah kebijakan tim, bukan konfigurasi pribadi. Aturan penamaan branch, format pesan commit, kapan harus membuka draft PR, tulis sekali, dan setiap sesi yang kamu jalankan mengikutinya. Itulah yang dilakukan seorang lead. Bukan mereview tiap pesan commit, tapi menuliskan konvensinya supaya tidak ada yang perlu mengingat.

Tuliskan Peran, Jangan Menjelaskan Ulang

Kalau kamu sudah empat kali mengetik "kamu reviewer, ketat soal concurrency, jangan ubah struktur modul", berhenti. Itu sebuah peran, dan peran tempatnya di file.

Contoh untuk konteks Laravel, simpan di .claude/agents/laravel-reviewer.md:

---
name: laravel-reviewer
description: Mereview perubahan PHP untuk masalah scope tenant, migrasi, dan kompatibilitas API. Pakai setelah perubahan pada modul bersama.
tools: Read, Glob, Grep, Bash
model: opus
effort: xhigh
isolation: worktree
maxTurns: 8
---

Kamu reviewer Laravel senior pada aplikasi ERP multi-tenant.
Anggap setiap query bisa bocor antar tenant. Tandai setiap perubahan
yang menyentuh migrasi tanpa rollback, atau mengubah bentuk respons API
tanpa catatan migrasi. Jangan usulkan refactor yang tidak diminta.
Laporkan temuan sebagai daftar bernomor dengan referensi file dan baris.

Perhatikan frontmatter-nya. tools adalah allowlist, jadi reviewer ini secara harfiah tidak bisa menulis file. isolation: worktree memberinya salinan sendiri. effort: xhigh membelanjakan penalaran untuk pekerjaan sulit. model: opus memilih orang yang tepat untuk tugasnya.

Kamu bisa mengikatnya ke seluruh sesi:

BASH

claude --agent laravel-reviewer

Atau memanggilnya dengan nama dan menjamin kamu mendapatkannya:

CODE

@"laravel-reviewer (agent)" review alur konfirmasi pesanan

Agent tinggal di .claude/agents/ untuk satu proyek, ~/.claude/agents/ untuk semua yang kamu kerjakan, atau di dalam plugin untuk satu tim. Ini dua puluh menit paling berdampak di seluruh artikel ini: peran yang kamu tulis sekali adalah rekan tim yang tidak perlu kamu onboarding lagi.

Pasang Batas Sebelum Dibutuhkan

Seorang lead menetapkan guardrail untuk timnya. Ini yang penting.

Soal permission: auto mode memang bagus. Klasifikator meninjau tiap aksi dan meloloskan yang aman sambil memblokir yang berisiko, dan panggilan klasifikator itu tidak dihitung ke kuota. Tapi itu bukan alasan melonggarkan jalur yang penting. Pada apa pun yang menyentuh uang, autentikasi, atau penyimpanan data, saya tetap memakai permission ketat: "klasifikator menganggapnya aman" bukan kalimat yang ingin saya ucapkan dalam post-mortem.

Soal effort: sesuaikan dengan tingkat kesulitan, per agent. standard untuk pekerjaan membosankan, xhigh untuk bug concurrency, max untuk kasus berat yang benar-benar sekali jalan. Menjalankan seluruh tim di max lebih lambat dan lebih mahal tanpa manfaat, kesalahan yang sama dengan menugaskan engineer terbaikmu untuk mengubah teks tombol.

Bagian yang Tidak Ada yang Memperingatkan: Kamu Jadi Bottleneck

Ada bagian yang jarang diceritakan. Minggu pertama saya menjalankan empat sesi, hasil yang saya kirim malah lebih sedikit daripada saat menjalankan satu sesi. Bukan karena agent-nya buruk, tapi karena saya tidak sanggup mereview secepat itu.

Empat sesi menghasilkan empat diff, dan saya membaca keempatnya sekilas, bukan satu pun dengan benar. Salah satunya mengubah jalur error pada alur konfirmasi pesanan dengan cara yang terlihat sangat wajar dan sepenuhnya salah. Saya menangkapnya. Di review. Nyaris tidak.

Itu mode kegagalan sebenarnya seorang tech lead, dan hal yang sama terjadi pada tim manusia: kamu memperbesar tim melebihi kemampuanmu menjaga kualitas, dan yang rusak bukan throughput, melainkan judgment.

Jadi batasannya bukan berapa sesi yang bisa kamu jalankan, tapi berapa diff yang benar-benar sanggup kamu baca hari ini. Bagi saya angkanya tiga. Kadang dua. Di hari penuh rapat, satu. Menjalankan lebih dari itu bukan memimpin tim, itu menyetempel asal-asalan.

Review Timnya, Bukan Cuma Kodenya

Mereview empat agent berbeda dari mereview satu. Biarkan review berjalan paralel dengan pekerjaan.

/code-review sekarang berjalan sebagai agent latar belakang di semua level effort, dan /review adalah aliasnya. Jalankan, lalu lanjut bekerja. Untuk hal yang serius, pakai mata yang segar: /ultrareview mengirim sekumpulan agent pemburu bug ke cloud dan temuannya kembali ke CLI atau desktop-mu.

Intinya bukan bahwa ia lebih pintar, tapi bahwa ia tidak ada di ruangan saat kode itu ditulis, dan tidak punya apa pun untuk dibela.

Baca tampilan agent seperti membaca standup. Sesi mana yang terblokir olehmu? Sesi terblokir adalah yang memakan throughput-mu, dan semua itu tidak terlihat kalau kamu tenggelam di satu terminal.

Untuk mengecek tanpa harus duduk di depan mesin: jalankan claude remote-control, dan mesinmu muncul sebagai kartu perangkat di bagian atas tab Code di aplikasi Claude. Saya pernah memulai migrasi, pergi makan siang, lalu membaca diff-nya dari ponsel. Level effort juga bisa diubah dari ponsel dan langsung berlaku pada sesi di mesinmu.

Dan aturan yang tidak berubah dan tidak akan berubah: kamu tetap yang menandatangani commit. Bukan agent yang menulisnya, bukan agent yang mereviewnya. Kamu.

Satu Hari yang Realistis

Beginilah rangkaiannya pada satu fitur biasa:

1. Buka claude agents. Lihat apa yang masih jalan dari kemarin, selesaikan yang terblokir lebih dulu.
2. Mulai sesi build dalam plan mode dengan brief yang benar: lingkup, batasan, definisi selesai.
3. Mulai sesi kedua bernama QA di worktree sendiri. Tugasnya menjalankan aplikasi dan merusak fitur, bukan membantu membangunnya.
4. Selama build berjalan, /subtask sebuah fork untuk menyusun unit test, konteksnya sudah lengkap.
5. Saat skema berubah, suruh satu sesi memberi tahu sesi lain. Jangan jelaskan ulang sendiri.
6. Jalankan /code-review di latar belakang sebelum kamu membaca apa pun.
7. Baca diff-nya. Benar-benar dibaca. Ini pekerjaannya sekarang.
8. Kalau ada yang salah, rewind sesi itu ke checkpoint dan perbaiki brief-nya, jangan berdebat dengan agent.
9. Commit, dengan namamu di sana, karena kamu yang mereview.

Perhatikan apa yang tidak ada dalam daftar itu: menulis kode dan menjelaskan ulang konteks. Perhatikan apa yang ada: menugaskan, membuka jalan, dan mereview. Itu deskripsi pekerjaan seorang tech lead. Dari dulu memang itu.

Lima Kebiasaan yang Membedakan Lead dari Power User

Kalau hanya satu hal yang ingin kamu ingat:

• Jalankan papan, bukan terminal. claude agents adalah standup-mu. Sesi yang terblokir adalah yang memakan waktumu.
• Biarkan informasi bergerak menyamping. Sesi bisa saling mengirim pesan. Berhenti jadi lapisan copy-paste di antara agent-mu sendiri.
• Fork untuk konteks, sesi baru untuk isolasi. Kalau tugasnya butuh yang baru kamu katakan, fork. Kalau tidak, beri sesi dan worktree sendiri.
• Tulis peran sekali. File subagent dengan allowlist tool adalah rekan tim yang tidak perlu di-onboarding ulang.
• Batasi tim sesuai kapasitas review-mu. Sesi lebih banyak daripada diff yang sanggup kamu baca bukanlah leverage, itu cara yang lebih lambat untuk mengirim bug.

Engineer yang benar-benar mendapat leverage dari Claude Code di 2026 bukan yang prompt-nya lebih baik darimu. Mereka menjalankan sejumlah kecil agent dengan lingkup yang jelas, peran tertulis, di branch terisolasi, dan membaca setiap diff yang kembali.

Kalau dipikir-pikir, itu tidak lain adalah praktik manajemen engineering yang baik, diterapkan pada rekan tim yang kebetulan mengetik lebih cepat dari siapa pun yang pernah kamu ajak kerja.

Pertanyaannya sekarang: kamu akan terus mengerjakan pekerjaannya, atau mulai memimpinnya?

Untuk sisi lain dari cerita ini (bagaimana AI bisa mengikis kemampuan developer kalau dipakai tanpa judgment) ada di artikel bahaya AI coding bagi developer.