[Meetup Claude Code] Membangun lingkungan agar agen dan manusia sama-sama bekerja efektif di codebase legacy

(Ini adalah materi yang dipresentasikan pada Meetup Claude Code Seoul pada 17 Desember. Untuk materi presentasi lengkap, lihat tautan ini.)

---

Tujuan 'konsultasi internal' tim AX Corca

• Menetapkan praktik agentic engineering yang baik di Corca, dan membangun fondasi agar praktik itu bisa terus dikembangkan bersama.
  • Di Corca, 'praktik agentic engineering' didefinisikan sebagai 'metode praktis untuk memanfaatkan AI agent demi meningkatkan kualitas dan produktivitas software secara bersamaan'
• Menjadikan kapabilitas engineering sebagai salah satu daya saing inti Corca lainnya.
• Untuk itu, mereka mulai membantu tim Moonlight

Situasi Moonlight

• Moonlight, produk utama Corca, mengusung konsep 'rekan AI untuk membaca paper bersama'
• 'Mengobrol dengan PDF' adalah kategori produk yang sudah ada sejak masa sangat awal ChatGPT. Di antara banyak produk pesaing, Moonlight berhasil bertahan dan kini berada di fase awal J-curve (belakangan pertumbuhan pengguna dari Tiongkok melonjak)
• Ada banyak trial and error sampai bisa sampai di titik ini, tetapi daya saing intinya adalah mempertahankan kecepatan dan ritme pengembangan fitur dengan cara apa pun
• Beberapa keputusan awal demi kecepatan
  • typescript strict: false
  • otomatisasi testing diminimalkan
  • duplikasi dan hardcoding diperbolehkan
  • tanpa pembagian peran jabatan. Hampir semua anggota tim (6 dari 7 orang) mengimplementasikan dengan coding agent dan mengajukan PR
• Setelah mulai stabil, technical debt perlahan mulai terasa berat
  • Produk makin kompleks, anggota baru di tim bertambah, dan eksperimen yang berjalan bersamaan makin banyak
  • Kecepatan perbaikan produk perlahan menurun, sementara rasa tidak tenang perlahan meningkat
  • Beban code review menumpuk pada beberapa orang dan muncul kesalahan besar maupun kecil

Tantangan mendesak bagi tim AX

• [Produk] Mari tingkatkan kualitas produk Moonlight sambil mempercepat penambahan dan perbaikan fitur!
• [Tim] Mari buat siapa pun lebih mudah memperbaiki kode Moonlight, dan mengurangi stres setelah deployment!
• [Budaya] Demi 1 dan 2, tim Moonlight dan tim AX berkolaborasi untuk menemukan, menerapkan, menyempurnakan, dan secara bertahap menyebarkan praktik agentic engineering yang baik di dalam perusahaan!
  → Mereka melihat bahwa sebagian besar masalah akan teratasi jika coding agent bisa memberi respons yang lebih baik

Agar agent bisa memberi respons yang lebih baik?

[1] Arahkan ke jalur yang baik sejak awal

• Jika kualitas codebase tinggi, ada keuntungan dalam 3 aspek
• Konteks yang tidak perlu menjadi lebih sedikit (Less is More)
• Agent akan mengikuti pola baik yang sudah ada
• Respons dapat dibiasakan agar lebih mungkin disampling dari area kode pretraining yang berisi kode berkualitas tinggi
  • Ada banyak riset yang menunjukkan bahwa memasukkan konteks berkualitas tinggi menghasilkan respons yang baik.
  • (Hipotesis pribadi) Jika permintaan dikirim ke agent pada codebase yang urutan import-nya rapi, bukankah kemungkinan besar kode-kode pretraining yang juga menata urutan import dengan baik secara umum berkualitas lebih tinggi?
  • Dari blog Anthropic: "Hanya dengan membuatnya memakai font yang menarik, elemen desain lainnya juga ikut membaik"

[2] Cegah agar tidak masuk ke jalur yang salah

• Jalur yang salah bisa diblokir dengan berbagai alat static analysis seperti pengecekan type error, pengecekan error linter, automated test, pemeriksaan dead code, pemeriksaan panjang file, pemeriksaan kompleksitas, penegakan relasi dependensi, penegakan rasio kode test vs kode production, dan lain-lain (biarkan agent bekerja ulang sampai lolos standar)

[3] Minta terutama hal-hal yang memang dikuasai

• Manusia, LLM, dan algoritma masing-masing unggul di hal yang berbeda. Jika bijak memilih kapan memakai apa, waktu dan biaya bisa dihemat
  • contoh) mengatakan agar jangan lupa i18n key vs menyuruh menjalankan skrip untuk mencari i18n key yang terlewat
• Siapa unggul dalam apa dan kapan berubah seiring waktu, dan juga bergantung pada domain masalahnya. Jika terbiasa terus memperbarui 'insting' ini dalam domain sendiri, itu akan sangat membantu
  • contoh) saat model baru keluar, uji dengan benchmark buatan sendiri, atau ikuti contoh terkenal di media sosial

[4] Bantu pada hal-hal yang belum dikuasai

• Namun, selalu perlu memastikan apakah benar-benar belum mampu. Jika bukan karena terlalu berisiko untuk didelegasikan, atau terlalu tidak efisien, dan sebagainya, maka lebih baik AI/algoritma yang lebih banyak melakukannya daripada manusia. (Biaya token pada akhirnya akan semurah biaya listrik)
• Jika memang benar-benar belum bisa? Mintakan review dari LLM lain
  • contoh) yang paling sederhana, "Ini dibuat oleh developer pemula..."
• Jika ingin AI bekerja lebih baik, kita harus menyediakan lingkungan yang memungkinkan AI bekerja lebih baik. Dengan kata lain, hal-hal yang (saat ini) agent (di sini) belum pandai lakukan perlu diperkuat oleh manusia, algoritma, dan agent lain

Hal-hal yang mereka perhatikan

• Moonlight adalah roket yang baru mulai terbang, dan tim AX adalah tamu yang datang dari luar
• Sangat menghindari pola orang luar datang, membuat sesuatu, lalu pergi
• Upaya peningkatan kualitas jangan sampai (sebisa mungkin) menghambat pengembangan fitur
• Mereka memutuskan mencampur pekerjaan yang tidak banyak mengubah cara kerja sehari-hari dengan pekerjaan yang lebih menantang tetapi efektif, dalam proporsi yang seimbang
  → Tim AX dan tim Moonlight membayangkan proses 'bersama-sama' menemukan dan menerapkan praktik yang cocok untuk tim dan produknya, sambil sekaligus meningkatkan kualitas kode, kualitas produk, dan kapabilitas tim

Pencapaian utama selama 4 minggu terakhir

[1] Kebiasaan baik mulai tertanam, dan pola baik mulai ditemukan

• Setiap hari mengajukan commit refactoring super kecil (tidying) tanpa PR review
• Prompt untuk meniru commit teladan di masa lalu (seperti dukungan model baru), serta prompt untuk menemukan dan mengumpulkan pola semacam itu
• SKILL code review dengan sudut pandang developer senior

[2] Mulai mengukur dan memvisualisasikan metrik kualitas kode. Jumlah error/peringatan terhadap jumlah baris kode menurun dengan cepat

• Metrik kualitas kode kadang turun bertahap, kadang turun drastis
• Karena tidying sedikit demi sedikit memperbaiki codebase setiap hari, tim jadi merasa lebih mampu untuk suatu saat melakukan refactoring besar dan pekerjaan besar lainnya
• Dengan menerapkan knip per package, kode lama dan tidak terpakai juga dihapus
• Metrik harus selalu saling melengkapi. Dibanding 1000 error pada 1000 baris kode, 5000 error pada 100 ribu baris kode jauh lebih baik. Karena itu, alih-alih hanya melihat jumlah absolut, mereka melihat rasio error terhadap jumlah baris agar punya indikator pengelolaan yang lebih sehat
  • Jumlah baris bermakna, tidak termasuk komentar dan spasi kosong, diukur dengan tokei

[3] Berhasil memperbaiki masalah memory leak yang berlangsung lebih dari 1 tahun

• Dengan mengerahkan berbagai alat dan prompting termasuk repomix, setelah beberapa kali percobaan mereka berhasil menangkap masalah memory leak yang berlangsung lebih dari 1 tahun
• Mereka senang karena sepertinya tier instance server bisa diturunkan

[4] Muncul struktur abstraksi, prompt, dan skrip yang memudahkan penambahan/penghapusan eksperimen mingguan yang berjalan paralel secara lebih mudah dan aman

Hasilnya, kualitas kode terus meningkat, pengembangan fitur menjadi lebih aman sekaligus lebih cepat, dan kapabilitas engineering (agentic) tim juga terus bertumbuh dengan ritme yang pas

Trial and error

• Tentu saja semuanya tidak berjalan baik sejak awal. Awalnya mereka ingin melakukan dua hal sekaligus
  • Memperkenalkan perubahan bernilai besar sekaligus meski agak mengkhawatirkan: menyalakan strict option, menerapkan aturan eslint yang ketat, menghapus semua dead code sekaligus, dan sebagainya
  • Melangkah aman sedikit demi sedikit meski nilainya kecil: seperti meninggalkan commit tidying setiap hari
• Namun, yang pertama terlalu mengkhawatirkan sehingga 'tidak bisa' dilakukan, dan yang kedua terlalu tidak menarik sehingga 'tidak' dilakukan
• Lalu mereka mengubah pendekatannya seperti ini
  • Membuat hal menantang jadi lebih aman (menyalakan tsc strict per file lalu memperbaiki dan mematikannya kembali, menerapkan eslint dengan aturan minimum, knip satu per package, dan sebagainya)
  • Membuat hal aman jadi lebih bernilai (misalnya membuat prompt untuk menerima usulan tidying terhadap perubahan terbaru)
• Masih banyak tugas yang tersisa
  • menyalakan typescript: strict
  • mengadopsi zod untuk menyelaraskan kontrak server-client
  • menerapkan aturan eslint yang lebih ketat
  • cakupan automated test yang lebih tinggi
  • menutup jalur yang salah dengan lebih banyak alat static analysis
• Namun mereka terus maju bersama, konsisten, dan sama sekali tidak lambat

One More Thing: kebiasaan belajar + debugging saya

Dalam situasi seperti ini, bertanya ke AI lalu bertanya ke para ahli sambil saling memverifikasi memberi banyak pembelajaran. Proses ini juga didokumentasikan di GitHub PR, issue, dan Slack lalu dibagikan ke organisasi

• Hal yang saya tidak tahu, diketahui orang lain
  • Bagaimana orang ini mengetahui pengetahuan/pengalaman ini? Dengan sinyal apa ia memahami masalah ini?
• Menemukan kesalahan saya, bug, atau antipattern di codebase
  • Faktor-faktor apa yang membuat masalah ini hampir pasti terjadi? Perbaikan struktur seperti apa yang bisa membuat saya lebih jarang salah dan menemukan kesalahan lebih awal lain kali?

Penutup

• Jika AI bisa memberi respons yang lebih baik, maka sebagian besar masalah tim produk bisa terselesaikan
  • Tingkatkan kualitas codebase (jalur baik sejak awal), dan perkenalkan berbagai alat (blokir jalur yang salah)
  • Mari bantu anggota tim meningkatkan kapabilitas agentic engineering mereka (minta hal yang dikuasai, bantu hal yang belum dikuasai)
• Jika tim meningkatkan kemampuannya dan lingkungan yang baik terbentuk melalui kolaborasi cerdas dengan AI, maka 'peningkatan kualitas' dan 'percepatan penambahan/perbaikan fitur' sangat mungkin dicapai secara bersamaan
• Bukan membawa sesuatu yang bagus dari 'luar' lalu membantu, tetapi temukan dan coba bersama dari 'dalam'. Mari ukur, visualisasikan, rayakan, dan saling belajar