- Sebuah metodologi untuk membuat alat coding AI menyusun rencana sebelum menulis kode, sehingga bisa mencegah implementasi yang keliru dan mempercepat pengembangan
- 8 strategi perencanaan diterapkan menurut tingkat kesulitan, dengan struktur di mana agen tertentu melakukan riset secara paralel lalu developer mengambil penilaian dan keputusan
- Setiap strategi mencakup reproduksi bug, pencarian best practice, analisis codebase yang ada, investigasi histori git, dan lain-lain, serta preferensi dan pola yang dipelajari agen terakumulasi secara otomatis
- Sistem yang telah dirilis sebagai open source ini bisa dipasang di Claude Code, atau dimulai dari satu fitur saja untuk secara bertahap mengajarkan cara berpikir developer kepada AI
Pendekatan Pengembangan Berbasis Perencanaan AI
- Memperkenalkan pendekatan yang membuat AI menyusun rencana sebelum menulis kode
- Pendekatan ini menghasilkan kecepatan implementasi fitur yang lebih tinggi dan lebih sedikit kesalahan dibanding sekadar menulis kode
- Sebagai contoh, diperkenalkan proses pengembangan fitur "email bankruptcy" pada aplikasi pengelola email Cora
- Saat mengimplementasikan fitur untuk merapikan 53.000 email tanpa kehilangan email penting, agen riset AI melakukan analisis pendahuluan
- Dengan begitu, masalah seperti batas 2.000 item Gmail, timeout sistem, dan waktu tunggu pengguna ditemukan lebih dulu sehingga implementasi yang salah bisa dicegah
8 Strategi Perencanaan
Strategi 1: Reproduksi dan Dokumentasi Bug
- Tujuan: mereproduksi bug sebelum perbaikan dan membuat panduan langkah demi langkah
- Kapan digunakan: Fidelity 1~2, khususnya saat memperbaiki bug
- Tepat setelah peluncuran fitur email bankruptcy, muncul masalah di mana 19 pengguna terjebak dalam status gagal kerja
- Hasil diagnosis dengan menelusuri log AppSignal menunjukkan bahwa error rate limit Gmail diabaikan di production
- Jika satu batch gagal, seluruh pekerjaan berhenti, tetapi pengguna tidak diberi tahu sehingga mereka hanya melihat spinner loading tanpa akhir
- Dalam proses reproduksi ditemukan bahwa pemrosesan batch dan fitur melanjutkan pekerjaan dibutuhkan; retry sederhana saja tidak cukup
- Efek majemuk: pada checklist agen @kieran-rails-reviewer ditambahkan butir seperti "saat background job memanggil API eksternal, apakah penanganan rate limit, retry, dan kemungkinan meninggalkan status parsial sudah diperiksa"
Strategi 2: Meneliti Best Practice
- Tujuan: mencari di web contoh penyelesaian masalah serupa
- Kapan digunakan: semua tingkat kesulitan, terutama untuk pola yang belum familiar
- Saat meng-upgrade gem yang tertinggal 2 versi, agen mencari "jalur upgrade dari versi X ke Y", "breaking change antarversi", dan "masalah migrasi yang umum"
- Ditemukan panduan upgrade resmi dan 3 posting blog engineer yang melakukan upgrade yang sama
- Riset 3 menit mencegah trial-and-error debugging selama berjam-jam
- Juga bisa dipakai untuk keputusan nonteknis: seperti "best practice tier harga SaaS", "copy konversi untuk kampanye email drip", atau "strategi retry background job"
- Efek majemuk: ketika menemukan pola yang berguna, pola itu otomatis disimpan ke file
docs/*.md, lalu saat pertanyaan serupa muncul lagi, sistem akan memeriksanya lebih dulu sebelum melakukan pencarian web
Strategi 3: Investigasi Codebase
- Tujuan: mencari pola serupa dalam kode yang sudah ada
- Kapan digunakan: semua pekerjaan yang mungkin menduplikasi fitur yang ada
- Sebelum menambahkan event tracking ke fitur baru, agen menelusuri codebase: "bagaimana event tracking ditangani saat ini?", "apa pola pemanggilan analitiknya?", "di mana event dikirim?"
- Ditemukan sistem tracking yang sudah ada lengkap dengan helper method (yang bahkan sempat terlupakan)
- Jika AI tidak merujuk ke codebase, ia akan mencoba membuat semuanya dari nol
- Alih-alih membuat sistem tracking baru, masalah diselesaikan dengan memperluas pola yang sudah ada, sehingga terhindar dari membangun sistem kedua yang tidak kompatibel
- Efek majemuk: dibuat agen "@event-tracking-expert" yang dijalankan otomatis saat merencanakan fitur apa pun yang membutuhkan tracking
Strategi 4: Meneliti Source Code Library
- Tujuan: membaca langsung source code paket dan gem yang terpasang
- Kapan digunakan: saat memakai library yang berubah cepat atau dokumentasinya kurang memadai
- Gem RubyLLM terus menambahkan model, parameter, dan fitur baru, tetapi dokumentasinya tertinggal
- Agen menganalisis source code RubyLLM: "opsi model apa yang tersedia?", "parameter apa yang bisa dikirim?", "fitur terbaru apa yang belum terdokumentasi?"
- Lalu memberi tahu bahwa "dukungan streaming ditambahkan di versi 1.9 tetapi belum didokumentasikan", beserta nama parameter dan contoh penggunaan dari test suite
- Efek majemuk: setiap kali dependency diperbarui, pengetahuannya juga ikut diperbarui secara otomatis, sehingga tidak bekerja dengan informasi usang
Strategi 5: Meneliti Histori git
- Tujuan: memahami maksud di balik keputusan masa lalu melalui analisis histori commit
- Kapan digunakan: saat refactor, melanjutkan pekerjaan, atau ketika perlu memahami "mengapa"
- Saat ditemukan penggunaan EmailClassifier versi lama, sebelum mencoba upgrade dilakukan pencarian histori git: "mengapa masih memakai v1?", "apakah pernah mencoba upgrade ke v2?"
- Ditemukan PR dari anggota tim lain tiga bulan sebelumnya: upgrade ke v2 menyebabkan email inbox masuk ke archive, dan email archive masuk ke inbox
- Di diskusi PR ada catatan rollback yang disengaja beserta alasan detailnya
- Efek majemuk: memori institusional terjaga dan bisa dicari, sehingga anggota tim baru dapat mewarisi logika di balik keputusan masa lalu
Strategi 6: Memperjelas Kebutuhan dengan Prototyping
- Tujuan: memperjelas requirement lewat prototyping cepat di lingkungan terpisah
- Kapan digunakan: Fidelity 3, saat UX belum pasti, atau untuk pekerjaan eksploratif
- Saat mendesain ulang antarmuka Email Brief, dibuat 5 prototipe layout berbeda di Claude, masing-masing dalam waktu 5 menit
- Prototipe itu diklik langsung untuk menemukan titik yang tidak nyaman, lalu versi terbaik ditunjukkan ke beberapa pengguna
- Salah satu umpan balik pengguna: "layout-nya terasa terlalu penuh dan saya tidak tahu cara mengarsipkan email"
- Insight tersebut lalu dimasukkan ke requirement rencana yang sesungguhnya: "tombol archive wajib diletakkan di sudut kiri atas—muscle memory pengguna mengharapkan posisi itu dari Gmail"
- Efek majemuk: prototyping mengubah ketidakpastian menjadi spesifikasi konkret dan mendokumentasikan reaksi pengguna
Strategi 7: Sintesis dengan Opsi
- Tujuan: menggabungkan seluruh hasil riset menjadi satu rencana lengkap beserta trade-off-nya
- Kapan digunakan: setelah tahap riset selesai, sebelum implementasi
- Setelah strategi 1~6 dijalankan, agen menyintesis hasilnya: "berdasarkan riset ini, ajukan 3 cara menyelesaikan masalah. Untuk tiap pendekatan, jelaskan kompleksitas implementasi, dampak kinerja, beban maintenance, dan pola yang cocok di codebase saat ini"
- Contoh sinkronisasi inbox Gmail:
- Opsi A—menggunakan sistem sinkronisasi yang ada: implementasi cepat, tetapi menambah duplikasi kode dan mengaburkan pemisahan concern
- Opsi B—sinkronisasi real-time: arsitektur lebih bersih, tetapi berpotensi lambat dan kurang andal
- Opsi C—membangun sistem mirror caching: solusi jangka panjang terbaik dan pemisahan paling bersih, tetapi pekerjaan awal paling besar
- Setelah membandingkannya, pilihan yang terinformasi bisa dibuat hanya dalam 30 detik
- Efek majemuk: pilihan yang diambil memperlihatkan preferensi; jika menandai preferensi seperti "kompatibilitas lebih dulu", sistem akan memberi bobot lebih tinggi pada kompatibilitas untuk keputusan serupa berikutnya
Strategi 8: Review oleh Agen Gaya
- Tujuan: mengirim rencana yang sudah selesai ke reviewer khusus untuk memeriksa preferensi developer
- Kapan digunakan: tahap rencana final, sebelum implementasi
- 3 agen review yang berjalan otomatis:
- Agen penyederhanaan: menandai overengineering, seperti "apakah fitur ini benar-benar butuh 3 tabel database? Bukankah cukup 1 tabel dengan field tipe?"
- Agen keamanan: memeriksa kerentanan umum, seperti "rencana ini mengizinkan input pengguna langsung masuk ke query database—perlu menambahkan sanitasi input"
- Agen gaya Kieran: menegakkan preferensi pribadi, seperti "menggunakan join yang kompleks; Kieran lebih suka query sederhana, pertimbangkan denormalisasi"
- Efek majemuk: agen mengakumulasi selera developer seiring waktu; ketika diberi sinyal seperti "tidak suka ini" atau "bagus", sistem akan belajar
Memulai
Cara yang Bisa Dicoba Hari Ini Juga
- Sistem perencanaan ini dirilis sebagai open source di Github Marketplace milik Every
- Jika dipasang di Claude Code, Anda bisa langsung memakai slash command /plan dan agen riset
- Plugin bisa digunakan di Claude Code atau Droid
Cara Memulai dengan Sederhana
- Pilih satu fitur Fidelity 2 yang sedang dibangun minggu ini: pekerjaan yang mencakup beberapa file dan punya ruang lingkup yang jelas (menambahkan view baru, membangun sistem feedback, refactor komponen)
- Sebelum meminta Claude Code atau Cursor untuk membangun, lakukan riset 15~20 menit:
- Best practice: bagaimana orang lain menyelesaikannya? Cari posting blog, Stack Overflow, dan dokumentasi di web
- Pola Anda sendiri: bagaimana Anda biasanya menyelesaikannya? Cari fitur serupa di codebase yang ada
- Fitur library: apa yang sebenarnya didukung alat yang sedang dipakai? Gunakan AI untuk membaca dokumentasi atau source code
- Minta AI menyintesis riset itu menjadi rencana yang memuat:
- Masalah yang ingin diselesaikan (satu kalimat yang jelas)
- 2~3 pendekatan solusi (masing-masing dengan kelebihan dan kekurangan yang jujur)
- Pola kode yang sudah ada dan harus dicocokkan
- Edge case atau pertimbangan keamanan
- Tinjau rencananya dan amati reaksi Anda: jika Anda berpikir "terlalu rumit" atau "sudah ada cara yang lebih baik", jangan hanya mengubah rencananya—tangkap alasan Anda berpikir begitu lalu catat
- Rilis fitur berdasarkan rencana, bandingkan implementasi akhirnya dengan rencana awal: di mana menyimpang? Mengapa? Apa yang bisa membuat rencananya lebih baik?
- Luangkan 10 menit untuk membakukan satu pelajaran: tambahkan ke file CLAUDE.md, tulis satu aturan seperti "saat mengerjakan tipe pekerjaan X, ingat cek Y" atau "karena alasan C, lebih memilih pendekatan A daripada B"
- Setelah pembelajaran terkumpul, buat agen riset atau command yang lebih khusus: seperti "Event Tracking Expert" (paham pola Anda sendiri) atau "Security Checker" (menandai kesalahan umum)
- Ulangi minggu depan, rujuk catatan, lihat apakah rencana kedua lebih baik daripada yang pertama, dan dalam beberapa bulan bangun sistem yang memahami cara berpikir developer
Belum ada komentar.