- Ringkasan pengalaman selama 6 minggu ketika jumlah commit meningkat tajam melalui perbaikan infrastruktur pengembangan, seperti otomatisasi pekerjaan berulang sederhana untuk agen AI, menghilangkan waktu tunggu build, dan membangun sistem worktree paralel
- Mengotomatisasi proses pembuatan PR dengan skill
/git-pr untuk menghilangkan biaya context switching, sekaligus membuat agen menulis deskripsi PR yang lebih rinci sendiri
- Beralih ke SWC sebagai alat build sehingga restart server dipersingkat menjadi kurang dari 1 detik, menciptakan lingkungan pengembangan yang tidak memutus alur kerja
- Dengan fitur preview Claude Code, agen bisa memverifikasi UI sendiri, menghilangkan bottleneck karena developer harus memeriksa semua perubahan secara manual
- Saat setiap elemen gesekan dihilangkan satu per satu, pola Theory of Constraints muncul apa adanya, di mana bottleneck berikutnya langsung terlihat
- Kini fokusnya bukan lagi implementasi fitur, melainkan membangun infrastruktur agar agen bekerja efisien dan meningkatkan kecepatan loop
Otomatisasi pekerjaan berulang sederhana
- Pada awalnya, semua proses dilakukan secara manual, mulai dari men-stage perubahan, menulis pesan commit, menulis deskripsi PR, push, hingga membuat GitHub PR
- Menyadari bahwa pekerjaan ini hanyalah pekerjaan berulang (grunt work) menjadi titik balik pertama, dan perannya berubah dari pelaksana menjadi manajer yang mengelola agen
- Menulis skill Claude Code pertama,
/git-pr, untuk mengotomatisasi seluruh proses pembuatan PR
- Karena agen membaca seluruh diff dan merangkum perubahan dengan baik, deskripsi PR justru menjadi lebih detail daripada saat ditulis sendiri
- Meskipun CLAUDE.md di codebase menyatakan penggunaan Graphite, secara pribadi tetap lebih menyukai plain git, sehingga operasional dijalankan lewat
/git-pr
- Dampak yang lebih besar daripada penghematan waktu adalah hilangnya beban mental: context switching kecil yang terjadi setiap kali menulis PR, dari "berpikir tentang kode → berpikir tentang menjelaskan kode", lenyap
Menghilangkan waktu tunggu
- Untuk preview lokal, berulang kali harus keluar dari pekerjaan yang sedang dikerjakan, mematikan dev server, lalu menjalankannya kembali di branch baru
- Build server memakan waktu sekitar 1 menit, cukup lama untuk merusak fokus, tetapi terlalu singkat untuk dipakai mengerjakan hal lain
- Dengan memindahkan build ke SWC, restart server dipangkas menjadi kurang dari 1 detik
- Begitu file disimpan, server sudah aktif, sehingga tidak ada celah bagi perhatian untuk terpecah
- Diibaratkan sebagai perbedaan antara "percakapan dengan jeda canggung" dan "percakapan yang mengalir alami"
Verifikasi UI oleh agen itu sendiri
- Sebelumnya, semua perubahan UI harus diperiksa sendiri lewat preview lokal, sehingga developer menjadi bottleneck untuk semua fitur
- Setelah ekstensi Chrome terus crash, beralih ke fitur preview Claude Code
- Agen dapat menyiapkan preview, mempertahankan data sesi, dan langsung melihat bagaimana UI benar-benar tampil
- Setelah diintegrasikan ke workflow, sebuah tugas hanya dianggap "selesai" jika agen telah memverifikasi UI secara langsung
- Karena verifikasi bisa didelegasikan, developer cukup turun tangan pada review akhir, dan agen dapat berjalan mandiri lebih lama
- Efek yang ternyata jauh lebih penting dari dugaan adalah bahwa agen menangkap kesalahannya sendiri
Sistem worktree paralel
- Setelah rebuild cepat dan preview otomatis tersedia, gesekan berikutnya yang muncul adalah bahwa hanya satu tugas yang bisa dikerjakan dengan nyaman pada satu waktu
- Untuk mereview PR agen lain atau rekan tim, harus checkout dari main ke branch PR lalu rebuild dan test, tetapi ini bentrok dengan perubahan yang belum di-commit
- Pilihannya adalah stash → checkout → rebuild → test → switch back → pop stash, atau membuat worktree manual lalu menghadapi konflik port
- Aplikasi memerlukan port terpisah untuk frontend dan backend, dan semua worktree berbagi environment variable yang sama, sehingga mencoba bind ke port yang sama
- Untuk mengatasinya, dibangun sistem yang saat membuat worktree akan secara otomatis mengalokasikan rentang port unik ke tiap server
- Bahkan 10 preview sekaligus pun bisa dijalankan
- Dari kondisi yang sudah kewalahan dengan 2 branch paralel, beralih ke tingkat mengoperasikan 5 worktree sekaligus
- Menjalankan beberapa agen di worktree terpisah untuk membangun fitur yang berbeda, lalu membiarkannya berjalan mandiri sampai verifikasi UI selesai
- Terlibat mendalam pada tahap perencanaan, lalu tidak ikut campur lagi sampai saat code review
- Proses review juga menjadi jauh lebih mulus: tanpa setup, rebuild, atau konflik port, cukup baca, cek, dan merge
Intinya bukan AI, melainkan infrastruktur
- Perannya berubah: alih-alih menghabiskan waktu untuk menyelesaikan masalah kompleks sendiri dan membuat UI yang sempurna, kini yang lebih menarik adalah membangun infrastruktur yang membuat agen lebih efektif
- Rasanya mirip menjadi manajer dari tim beranggotakan 10 orang, bukan solo developer
- Ini memang pekerjaan plumbing yang tidak glamor, tetapi justru inilah yang menentukan apakah seseorang tetap berada dalam flow atau malah terus bertarung dengan lingkungan
- Di Tano, pekerjaan dengan leverage tertinggi bukan pengembangan fitur, melainkan membangun infrastruktur yang mengubah aliran commit menjadi deras
Loop: penerapan Theory of Constraints
- Setiap tahap menghilangkan jenis gesekan yang berbeda:
/git-pr: menghilangkan gesekan pemformatan saat mengubah perubahan kode menjadi PR- SWC: menghilangkan gesekan menunggu sampai hasil perubahan bisa dilihat
- Fitur preview: menghilangkan gesekan verifikasi saat memeriksa perubahan
- Sistem worktree: menghilangkan gesekan context switching antar beberapa alur kerja
- Setiap kali satu hambatan dihilangkan, bottleneck berikutnya langsung muncul; ini adalah pola khas Theory of Constraints
- Hakikat pekerjaannya pun berubah: bukan lagi "menggunakan alat untuk menulis kode", melainkan loop umpan balik yang rapat berupa memulai pekerjaan → agen menulis kode → memeriksa preview → membaca diff → memberi masukan atau merge → pekerjaan berikutnya
- Jika loop cukup cepat, tidak ada celah bagi perhatian untuk kabur, dan peningkatan kecepatan itu sendiri menjadi semacam permainan
- Pada akhirnya, tujuan pengembangan bergeser dari implementasi fitur menjadi seberapa jauh kecepatan loop masih bisa ditingkatkan
- Sampai pada tahap di mana kecepatan itu sendiri menjadi kesenangan dalam engineering
2 komentar
Sebagai reviewer, pengalaman saya saat melihat PR Description yang ditulis mesin memang tidak terlalu baik. Mungkin kalau prompt tuning-nya bagus hasilnya bisa lebih baik, tapi..
Komentar Hacker News
Terasa seperti kembalinya metrik "jumlah baris kode per minggu" dari era 90-an
“Membuat lebih banyak PR” bukan bukti bahwa AI bekerja dengan baik, melainkan hanya berarti lebih banyak hal yang di-merge
Menilai kinerja hanya dari output tanpa mempertimbangkan kualitas kode, bug, dan beban pemeliharaan pada dasarnya sama saja dengan metrik buruk yang dulu dipaksakan manajer
Pada akhirnya, tampaknya kita bukan menolak metrik buruk, melainkan tidak suka diukur itu sendiri
Tujuan sebenarnya adalah menghasilkan kode yang sederhana dan berdampak
Saya sedang bereksperimen dengan menjalankan beberapa agen sekaligus untuk mencoba implementasi berbeda, lalu menggabungkan ide terbaik di antaranya
Saya juga mengumpulkan dokumentasi dan requirement untuk diajukan ke agen, lalu menggeneralisasi umpan balik code review menjadi checklist agar bisa diterapkan pada review berikutnya
Bekerja sampai sakit bukan sesuatu yang patut dibanggakan, melainkan sinyal bahwa sistemnya bermasalah
Misalnya, model COCOMO cukup dipercaya sampai dipakai di pengadilan untuk memperkirakan nilai suatu sistem
Kebanyakan developer memang tidak ingin dirinya dikuantifikasi
Namun para pendukung AI merasa bahwa untuk membuktikan adanya peningkatan, pengukuran tetap diperlukan
Saya rasa LLM seharusnya dipakai ke arah mengurangi beban kognitif
Manusia lemah dalam multitasking, dan LLM tidak otomatis menutupi kelemahan itu
Saya tidak menyerahkan implementasi sepenuhnya ke Claude, melainkan memakainya dengan cara dipandu langsung melalui proses implementasi
Dengan begitu saya bisa memahami keseluruhan proses sambil tetap melihat detail dan gambaran besar secara bersamaan
Bagian yang repetitif dan mekanis saja yang saya serahkan ke Claude
Saya melempar pertanyaan ke LLM agar ia memahami masalahnya, lalu saya menulis kode inti sendiri dan memintanya menyusun rencana implementasi sisanya
LLM kuat dalam membaca kode, menjelaskan, dan menangani tugas sederhana, sementara saya fokus memilih arah pemecahan masalah
Untuk melacak bagian yang diputuskan LLM alih-alih saya, saya sedang bereksperimen dengan prompt seperti “buat daftar asumsi” atau “sebutkan keputusan yang tidak ada di rencana”
Jika paham karakteristik Claude, efisiensi verifikasi juga meningkat, dan makin banyak pengalaman, makin mudah menjaga kualitas
Jika menjalankan banyak agen untuk membuat fitur besar, pada akhirnya muncul masalah waktu review yang meningkat drastis
Karena membaca kode orang lain (atau AI) lebih sulit daripada menulisnya sendiri
Mungkin bisa ditutupi dengan otomatisasi testing, tetapi tetap sulit untuk benar-benar percaya penuh
Ruang lingkup, testing, dan rencana dokumentasi harus jelas, lalu terapkan bot code review (Sourcery, CodeRabbit, Codescene) dan aturan linting yang kuat
Saya juga memanfaatkan BDD, property testing, testing e2e, audit kode, hingga mutation/fuzzing testing
Keunggulan agent coding adalah ia memberi kita waktu untuk fokus pada kontrol kualitas semacam ini
Saya sedang mencoba deployment bertahap dengan pendekatan seperti 100 PRs a day
Jika pekerjaan dipecah kecil-kecil dan testing bisa dipercaya, review kode AI juga jadi lebih ringan
Saya melihat test case dengan lebih teliti, dan menyelesaikan code review dengan cepat
Saya memang tidak menjalankan banyak agen secara paralel, tetapi produktivitas saya jelas meningkat berkat AI
Jika proses penulisan PR terlalu diotomatisasi, kita kehilangan kesempatan untuk memverifikasi diri sendiri
Saya sering menemukan keanehan dalam kode saya saat menulis deskripsi PR
Momen menjelaskannya dalam bahasa Inggris itu adalah sanity check terakhir
Berkat sistem worktree, perpindahan konteks jadi lebih mudah, tetapi pada saat yang sama kelelahan mental juga meningkat
Jika dipecah menjadi unit kecil dan siklus review dibuat singkat, kontrol kualitas jadi lebih mudah
Yang saya suka adalah tetap bisa kembali keesokan harinya tanpa alur kerja saya terganggu, dan progresnya sudah berjalan
Saya skeptis terhadap asumsi bahwa Claude bisa menulis kode dengan tingkat kelengkapan yang tinggi
Kenyataannya tetap perlu berkali-kali feedback dan revisi, dan jika beberapa pekerjaan dikelola paralel sekaligus, justru jadi tidak efisien
Claude Code memang revolusioner sebagai alat belajar, tetapi kualitas generasi kodenya naik turun
Saya mempelajari Flutter/Dart dengan bertanya konsep ke Claude, dan bisa membuat aplikasi dalam seminggu tanpa buku
Rasanya seperti ensiklopedia interaktif
Untuk pertanyaan seperti “apa cara idiomatis melakukan X di bahasa ini?”, ia langsung memberi jawaban yang berguna
Hanya saja, ini lebih merupakan alat yang sangat bagus daripada sesuatu yang mengubah dunia
Namun pemasaran yang berlebihan sedang memberi dampak negatif ke ekonomi secara luas
Ada juga kekhawatiran bahwa ilusi AI akan menggantikan pekerjaan membuat generasi muda menyerah pada pilihan karier tertentu
Ada yang bilang, “setelah beralih build ke SWC, restart server turun menjadi kurang dari 1 detik,”
SWC adalah Speedy Web Compiler, alat untuk transpile cepat tanpa type checking
Dokumentasi NestJS juga menjelaskan hal yang sama
Memakai LLM bukan sesuatu yang patut dibanggakan seolah produktivitas meledak drastis
Kalau semua orang memakai alat yang sama, patokannya hanya akan ikut naik
Selain itu, jika kode besar hasil AI tidak direview dengan benar, kualitas jangka panjangnya tetap tidak pasti
LLM memang meningkatkan produktivitas, tetapi mengukurnya dengan grafik jumlah commit itu tidak berarti
Sama bodohnya dengan menilai kualitas dari LOC
Saya tetap menulis kode sendiri sambil memahaminya, dan Claude sangat membantu sebagai partner untuk memecah pekerjaan dan review
Kemampuan mengganti kode kompleks dengan abstraksi yang sederhana itulah produktivitas yang sesungguhnya