Seorang netizen pernah bertanya kepada saya apa alur pengembangan AI saya. Kebetulan beberapa hari lalu saya menggunakan AI untuk membuat sebuah fitur kecil—layak dijadikan contoh untuk ditampilkan, sekaligus bisa jadi referensi.
Fitur ini bermula dari seorang netizen yang meninggalkan pesan di GitHub Issues (Gambar 1). Ia bertanya apakah saya bisa menambahkan fitur transkripsi jarak jauh pada aplikasi BaoCut (app transkripsi dan terjemahan subtitle) yang saya buat.
Maksudnya begini: saya punya dua komputer. Komputer A adalah komputer berperforma tinggi yang dilengkapi kartu grafis NVIDIA. Komputer B hanya komputer untuk kerja sehari-hari. Saya ingin memanfaatkan daya komputasi dari komputer A, tetapi biasanya saya hanya menggunakan BaoCut di komputer B. Saat saya menjalankan transkripsi di komputer B dengan BaoCut, pekerjaan yang menghabiskan komputasi untuk transkripsi akan dikerjakan oleh komputer A.
Saya langsung merasa ini adalah kebutuhan yang cukup bagus, tetapi saya belum pernah mengerjakan hal seperti ini, dan saya juga tidak tahu apakah itu memungkinkan.
Jadi langkah pertama saya bukan langsung menulis kode, melainkan melakukan analisis kelayakan.
1. Analisis kelayakan
Kalau langsung mulai tanpa analisis kelayakan, akibatnya bisa sangat banyak. Saya sudah terlalu sering mengalami hal seperti itu—sering kali ujungnya cuma buang waktu. Selain itu, meskipun sudah melakukan analisis kelayakan, kadang tetap bisa membuat keputusan yang keliru. Misalnya beberapa hari lalu saya membuat model teks lokal untuk membantu memecah dan menyelaraskan (splitting dan alignment). Saat analisis kelayakan, saya merasa tidak ada masalah, tapi setelah selesai dan dicoba langsung ternyata hasilnya sangat buruk. Akhirnya tetap dipotong, dan saya kehilangan beberapa hari waktu, ditambah token yang lumayan banyak—untungnya hanya token.
Analisis kelayakan biasanya punya dua sudut pandang:
Satu dari sisi produk: apakah fitur ini bernilai bagi pengguna, dan apakah sesuai dengan positioning aplikasi.
Satu lagi dari sisi teknis: apakah fitur ini memungkinkan secara teknis, dan apakah biayanya dapat dikendalikan.
Di sini, dari sisi produk saya merasa fitur ini bermanfaat bagi pengguna dan sesuai dengan positioning aplikasi, jadi saya fokus pada analisis kelayakan teknis saja.
Saya lalu memasukkan kebutuhan asli ke dalam Claude Code, meminta supaya digabungkan dengan kondisi proyek saat ini untuk melakukan analisis kelayakan (Gambar 2). Setelah dianalisis, ia memberikan kesimpulan: bisa dilakukan, dan menyertakan beberapa opsi (Gambar 3).
Opsi-opsi itu mungkin lebih mudah dipahami jika ada sedikit latar belakang teknis. Setelah saya baca, saya cepat membuat penilaian saya sendiri:
Opsi 0 dan opsi C—meski tidak perlu memodifikasi kode—namun bagi pengguna terlalu tidak ramah: pengguna harus memikirkan sendiri cara membangun server asr.
Opsi A terlihat bagus: cukup install aplikasinya, lalu bisa menjalankan layanan transkripsi sendiri.
Opsi B tidak ramah untuk Windows.
Jadi saya memutuskan untuk melanjutkan dengan opsi A. Selain itu, meski opsi 0 tidak terlalu bisa diandalkan, bagian yang menyediakan http transkripsi API juga merupakan tambahan fitur yang bagus—sekalian bisa ditambahkan.
2. Menulis dokumen desain
Setelah memastikan kelayakan dan sekaligus menentukan rancangan teknis awal, saya tetap tidak langsung mulai menulis kode. Saya mulai dengan menulis dokumen desain.
Dokumen desain di sini lebih mirip gabungan antara dokumen desain produk dan rencana desain teknis. Kurang lebih berisi deskripsi yang jelas tentang kebutuhan, rancangan arsitektur, dan rancangan dokumen UI—campur jadi satu.
Tujuannya adalah agar AI bisa membantu merapikan dan memastikan teknologi apa saja yang diperlukan saat implementasi, kondisi proyek saat ini, serta semuanya dicatat dalam dokumen. Nantinya saat implementasi bisa jadi acuan yang baik, dan saat pemeliharaan juga bisa dijadikan referensi. Yang paling penting: manusia bisa mengonfirmasi apakah arah yang dipilih sudah benar. (lihat Gambar 4)
Tentu saya akui di sini saya sedikit malas: saya langsung menyuruhnya selesai menulis dokumen lalu mulai kerja. Alasannya: saya melihat opsi yang diberikan sebelumnya tidak punya masalah besar, dan saya cukup percaya pada Fable—kalau ada kesempatan, tentu saya akan lihat lebih lanjut juga.
3. Desain prototipe
Saya membuat prototipe terlebih dahulu sebelum menulis kode karena ingin memvalidasi kebutuhan dengan biaya rendah melalui prototipe, untuk cepat mendefinisikan desain antarmuka dan interaksi. Di sini saya sudah menginstal skill baoyu-design (github.com/jimliu/baoyu-design), jadi begitu menyebut prototipe, prosesnya bisa otomatis terpanggil.
Aplikasi saya punya halaman prototipe khusus. Setiap kali menambah atau mengubah fitur, saya akan lebih dulu memperbarui halaman prototipe tersebut.
Dengan dokumen desain sebelumnya, pembuatan prototipe relatif masih cukup lancar. Versi pertama (Gambar 5) sudah memberikan hasil yang cukup bagus: di halaman pengaturan ditambahkan satu tab halaman opsi baru. Di sana bisa mengaktifkan layanan dan menemukan node.
Perlu dicatat: prototipe yang saya buat sebenarnya menggabungkan prototipe tingkat presisi tinggi antara prototipe dan desain UI—jadi prototipe tersebut sekaligus merupakan desain UI. Ini juga salah satu ciri khas Claude Design.
Setelah prototipe jadi, tetap perlu penyesuaian. Di tahap ini, manusia perlu memberi masukan berdasarkan hasil prototipe agar Agent bisa melakukan penyesuaian. Misalnya di sini saya berulang kali mengubahnya. (lihat Gambar 6)
Pertama, ubah layout menjadi Tab, memisahkan pengaktifan layanan dan akses ke node lain—karena menurut saya ini dua skenario berbeda. Selain itu, saya menambahkan ikon untuk menampilkan status layanan, sehingga bisa jelas lewat ikon apakah layanan sedang berjalan atau berhenti. (lihat Gambar 7)
Kemudian saya menyadari meletakkannya di halaman pengaturan tidak terlalu nyaman untuk melihat status layanan, jadi saya pindahkan ke halaman utama. Akhirnya saya merasa sudah cukup. (Gambar 8, Gambar 9)
4. Implementasi
Kalau Anda sudah punya dokumen desain, sudah punya prototipe (UI) design, lalu meminta AI menulis kode, maka untuk Agent saat ini ini merupakan tugas yang sangat mudah.
Biasanya pada tahap ini, saya akan menggunakan /goal untuk mengirimkan dokumen bersama ke Claude Code (Fable 5) agar diimplementasikan. Ia akan menjalankan implementasi sesuai Milestones yang direncanakan dalam dokumen, serta akan mengambil screenshot untuk memverifikasi hasilnya sendiri. (Gambar 10, Gambar 11)
5. Pengujian dan validasi
Meskipun Agent akan membantu memvalidasi, itu tidak berarti kita bisa sepenuhnya percaya pada hasil AI. Selanjutnya tetap perlu menjalankan beberapa kali secara manual, kemudian semua masalah yang ditemukan saya laporkan ke Agent agar ia menyesuaikan (Gambar 12).
Setelah beberapa putaran penyesuaian, akhirnya sudah cukup bisa digunakan.
Lihat hasil finalnya (Gambar 13, Gambar 14)
Kalau Anda bertanya apakah saya melakukan Review kode?
Tidak. Saya memposisikan diri sebagai QA: saya hanya melakukan pengujian black-box. Saya tetap percaya pada kemampuan Fable.
Fitur ini bermula dari seorang netizen yang meninggalkan pesan di GitHub Issues (Gambar 1). Ia bertanya apakah saya bisa menambahkan fitur transkripsi jarak jauh pada aplikasi BaoCut (app transkripsi dan terjemahan subtitle) yang saya buat.
Maksudnya begini: saya punya dua komputer. Komputer A adalah komputer berperforma tinggi yang dilengkapi kartu grafis NVIDIA. Komputer B hanya komputer untuk kerja sehari-hari. Saya ingin memanfaatkan daya komputasi dari komputer A, tetapi biasanya saya hanya menggunakan BaoCut di komputer B. Saat saya menjalankan transkripsi di komputer B dengan BaoCut, pekerjaan yang menghabiskan komputasi untuk transkripsi akan dikerjakan oleh komputer A.
Saya langsung merasa ini adalah kebutuhan yang cukup bagus, tetapi saya belum pernah mengerjakan hal seperti ini, dan saya juga tidak tahu apakah itu memungkinkan.
Jadi langkah pertama saya bukan langsung menulis kode, melainkan melakukan analisis kelayakan.
1. Analisis kelayakan
Kalau langsung mulai tanpa analisis kelayakan, akibatnya bisa sangat banyak. Saya sudah terlalu sering mengalami hal seperti itu—sering kali ujungnya cuma buang waktu. Selain itu, meskipun sudah melakukan analisis kelayakan, kadang tetap bisa membuat keputusan yang keliru. Misalnya beberapa hari lalu saya membuat model teks lokal untuk membantu memecah dan menyelaraskan (splitting dan alignment). Saat analisis kelayakan, saya merasa tidak ada masalah, tapi setelah selesai dan dicoba langsung ternyata hasilnya sangat buruk. Akhirnya tetap dipotong, dan saya kehilangan beberapa hari waktu, ditambah token yang lumayan banyak—untungnya hanya token.
Analisis kelayakan biasanya punya dua sudut pandang:
Satu dari sisi produk: apakah fitur ini bernilai bagi pengguna, dan apakah sesuai dengan positioning aplikasi.
Satu lagi dari sisi teknis: apakah fitur ini memungkinkan secara teknis, dan apakah biayanya dapat dikendalikan.
Di sini, dari sisi produk saya merasa fitur ini bermanfaat bagi pengguna dan sesuai dengan positioning aplikasi, jadi saya fokus pada analisis kelayakan teknis saja.
Saya lalu memasukkan kebutuhan asli ke dalam Claude Code, meminta supaya digabungkan dengan kondisi proyek saat ini untuk melakukan analisis kelayakan (Gambar 2). Setelah dianalisis, ia memberikan kesimpulan: bisa dilakukan, dan menyertakan beberapa opsi (Gambar 3).
Opsi-opsi itu mungkin lebih mudah dipahami jika ada sedikit latar belakang teknis. Setelah saya baca, saya cepat membuat penilaian saya sendiri:
Opsi 0 dan opsi C—meski tidak perlu memodifikasi kode—namun bagi pengguna terlalu tidak ramah: pengguna harus memikirkan sendiri cara membangun server asr.
Opsi A terlihat bagus: cukup install aplikasinya, lalu bisa menjalankan layanan transkripsi sendiri.
Opsi B tidak ramah untuk Windows.
Jadi saya memutuskan untuk melanjutkan dengan opsi A. Selain itu, meski opsi 0 tidak terlalu bisa diandalkan, bagian yang menyediakan http transkripsi API juga merupakan tambahan fitur yang bagus—sekalian bisa ditambahkan.
2. Menulis dokumen desain
Setelah memastikan kelayakan dan sekaligus menentukan rancangan teknis awal, saya tetap tidak langsung mulai menulis kode. Saya mulai dengan menulis dokumen desain.
Dokumen desain di sini lebih mirip gabungan antara dokumen desain produk dan rencana desain teknis. Kurang lebih berisi deskripsi yang jelas tentang kebutuhan, rancangan arsitektur, dan rancangan dokumen UI—campur jadi satu.
Tujuannya adalah agar AI bisa membantu merapikan dan memastikan teknologi apa saja yang diperlukan saat implementasi, kondisi proyek saat ini, serta semuanya dicatat dalam dokumen. Nantinya saat implementasi bisa jadi acuan yang baik, dan saat pemeliharaan juga bisa dijadikan referensi. Yang paling penting: manusia bisa mengonfirmasi apakah arah yang dipilih sudah benar. (lihat Gambar 4)
Tentu saya akui di sini saya sedikit malas: saya langsung menyuruhnya selesai menulis dokumen lalu mulai kerja. Alasannya: saya melihat opsi yang diberikan sebelumnya tidak punya masalah besar, dan saya cukup percaya pada Fable—kalau ada kesempatan, tentu saya akan lihat lebih lanjut juga.
3. Desain prototipe
Saya membuat prototipe terlebih dahulu sebelum menulis kode karena ingin memvalidasi kebutuhan dengan biaya rendah melalui prototipe, untuk cepat mendefinisikan desain antarmuka dan interaksi. Di sini saya sudah menginstal skill baoyu-design (github.com/jimliu/baoyu-design), jadi begitu menyebut prototipe, prosesnya bisa otomatis terpanggil.
Aplikasi saya punya halaman prototipe khusus. Setiap kali menambah atau mengubah fitur, saya akan lebih dulu memperbarui halaman prototipe tersebut.
Dengan dokumen desain sebelumnya, pembuatan prototipe relatif masih cukup lancar. Versi pertama (Gambar 5) sudah memberikan hasil yang cukup bagus: di halaman pengaturan ditambahkan satu tab halaman opsi baru. Di sana bisa mengaktifkan layanan dan menemukan node.
Perlu dicatat: prototipe yang saya buat sebenarnya menggabungkan prototipe tingkat presisi tinggi antara prototipe dan desain UI—jadi prototipe tersebut sekaligus merupakan desain UI. Ini juga salah satu ciri khas Claude Design.
Setelah prototipe jadi, tetap perlu penyesuaian. Di tahap ini, manusia perlu memberi masukan berdasarkan hasil prototipe agar Agent bisa melakukan penyesuaian. Misalnya di sini saya berulang kali mengubahnya. (lihat Gambar 6)
Pertama, ubah layout menjadi Tab, memisahkan pengaktifan layanan dan akses ke node lain—karena menurut saya ini dua skenario berbeda. Selain itu, saya menambahkan ikon untuk menampilkan status layanan, sehingga bisa jelas lewat ikon apakah layanan sedang berjalan atau berhenti. (lihat Gambar 7)
Kemudian saya menyadari meletakkannya di halaman pengaturan tidak terlalu nyaman untuk melihat status layanan, jadi saya pindahkan ke halaman utama. Akhirnya saya merasa sudah cukup. (Gambar 8, Gambar 9)
4. Implementasi
Kalau Anda sudah punya dokumen desain, sudah punya prototipe (UI) design, lalu meminta AI menulis kode, maka untuk Agent saat ini ini merupakan tugas yang sangat mudah.
Biasanya pada tahap ini, saya akan menggunakan /goal untuk mengirimkan dokumen bersama ke Claude Code (Fable 5) agar diimplementasikan. Ia akan menjalankan implementasi sesuai Milestones yang direncanakan dalam dokumen, serta akan mengambil screenshot untuk memverifikasi hasilnya sendiri. (Gambar 10, Gambar 11)
5. Pengujian dan validasi
Meskipun Agent akan membantu memvalidasi, itu tidak berarti kita bisa sepenuhnya percaya pada hasil AI. Selanjutnya tetap perlu menjalankan beberapa kali secara manual, kemudian semua masalah yang ditemukan saya laporkan ke Agent agar ia menyesuaikan (Gambar 12).
Setelah beberapa putaran penyesuaian, akhirnya sudah cukup bisa digunakan.
Lihat hasil finalnya (Gambar 13, Gambar 14)
Kalau Anda bertanya apakah saya melakukan Review kode?
Tidak. Saya memposisikan diri sebagai QA: saya hanya melakukan pengujian black-box. Saya tetap percaya pada kemampuan Fable.