"TDD berbasis LLM" untuk Kesenangan dan Keuntungan

Menggabungkan TDD(Test-Driven Development) dan LLM

• TDD adalah metodologi pengembangan yang menulis unit test yang komprehensif terlebih dahulu sebelum mulai menulis program
• Karena test pada dasarnya berperan sebagai spesifikasi, ketika pada akhirnya semua test lolos, ketepatan kode dapat dibuktikan sampai tingkat tertentu
• Secara tradisional, TDD juga kerap dikritik karena menghambat produktivitas atau tidak efisien
• Namun dengan munculnya LLM, proses menulis test dan berulang kali memperbaiki kode menjadi jauh lebih mudah

Cara saya biasanya menggunakan LLM

• Saya telah aktif menggunakan alat seperti Github Copilot
• LLM mahir menemukan pola berulang dan mengautokoreksi beberapa baris berikutnya, tetapi sering kesulitan memahami keseluruhan masalah secara mendalam dan langsung menghasilkan modul yang utuh
• Jika konteks yang diperlukan untuk pemecahan masalah diberikan secara berlebihan, model mudah melenceng dari topik
• Jika pekerjaan dilakukan sambil hanya memberikan sebagian informasi sesuai kebutuhan (seperti output error), model juga sangat membantu untuk debugging
• Saya merasakan adanya friksi dalam proses bolak-balik copy-paste antara IDE, terminal, dan antarmuka chat

Bisakah ini diotomatisasi?

• Untuk mengotomatisasi proses ini, saya sendiri memperkenalkan konsep event loop
• Jika pada prompt pertama dicantumkan spesifikasi fungsi yang akan diimplementasikan dan function signature-nya, model akan menyajikan unit test dan draf kode
• Kode ini disimpan di direktori sandbox dan go test dijalankan secara otomatis
• Jika test gagal, prompt kedua (iteratif) akan mengirimkan kode yang ada beserta hasil test (error kompilasi atau informasi kegagalan)
• Berdasarkan itu, model kembali mengusulkan test dan kode implementasi yang telah diperbaiki
• Proses ini diulang sampai semua test lolos
• Pendekatan ini memungkinkan perbaikan bertahap tanpa menumpuk konteks secara berlebihan
• Model juga bisa berulang kali gagal pada test case yang sama; dalam kasus seperti itu, manusia secara langsung menunjukkan bagian masalah dan memberi petunjuk
• Perlu disadari adanya masalah ‘ketiadaan pengawas’, yaitu harus meragukan apakah test yang dibuat LLM cukup ketat
• Ada kemungkinan kode dan test sama-sama berbagi error yang sama atau desain yang tidak lengkap
• Karena itu, penting bagi manusia untuk memperkuat test case tambahan
• Jika perlu, teknik seperti mutation testing juga bisa diuji coba dengan AI

Pengembangan berbasis LLM dan beban kognitif(cognitive load)

• Jika TDD diterapkan bersama LLM, pendekatan ini diperkirakan dapat digunakan bukan hanya untuk masalah algoritma umum, tetapi juga pada codebase nyata yang memiliki dependensi
• Namun, struktur proyek perlu dipecah menjadi unit yang lebih kecil untuk meningkatkan maintainability, dan setiap direktori/paket harus bisa diuji secara independen
• Untuk mengurangi beban kognitif, disarankan agar setiap paket dipisahkan menjadi definisi tipe utama (shared.go), file yang menangani logika tertentu (x.go), dan test (x_test.go)
• Dalam proses memanfaatkan AI, alih-alih memberikan seluruh kode ke model setiap kali, hanya bagian tertentu yang dipilih secara selektif agar model dapat fokus
• Ini memberi keuntungan jangka panjang pada pemeliharaan dengan meningkatkan test coverage sekaligus mengurangi coupling antarmodul
• Bahkan pada proyek besar sekalipun, arah yang dituju adalah memecahnya menjadi unit-unit kecil dan jelas, memuat logika tiap unit secara kaya namun menjaga cakupannya seminimal mungkin

Penutup

• Mengingat kecepatan perkembangan AI, bisa saja besok langsung muncul arsitektur baru yang melampaui keterbatasan LLM
• Karena itu, alih-alih tiba-tiba merefaktor kode legacy skala besar yang melebihi 100 ribu baris, disarankan untuk mulai mengeksplorasi kemungkinan menggabungkan TDD dan LLM dari skala kecil
• Diharapkan perpaduan TDD dan LLM dapat membawa perubahan positif baik pada pembuatan kode otomatis maupun pengelolaan kualitas test

[jhj0517]

Saya jadi merenung cukup dalam, kira-kira pipeline seperti apa yang digunakan layanan AI khusus pengembangan lainnya.

[halfenif]

(Kalau melihat hal seperti ini) rasanya sebentar lagi orang akan benar-benar memasukkan kabel stimulasi listrik ke otak demi otak sibernetik.

[crawler]

Menurut saya memasukkan kode pengujian memang terdengar bagus, tetapi sepertinya tidak ada nilai tambah pada program yang dibuat orang ini.
Di cline atau aider juga bisa menjalankan lewat command line dan menerima hasilnya, jadi kalau mempertimbangkan kemudahan lainnya, menurut saya akan lebih baik jika cukup menggunakan prompt dengan baik di program-program itu.

[rabolution]

Micro-agent buatan Builder IO juga merupakan pendekatan yang mirip. https://github.com/BuilderIO/micro-agent Saya juga sudah beberapa kali mencoba LLM dan TDD, dan abstraksinya juga harus dibuat dengan baik, misalnya lewat design system. Konvensi dan pola juga harus ditetapkan dengan baik. Untuk test case, saya biasanya menulisnya sendiri. (Walau hanya dalam bahasa manusia?) Yang terpenting, seperti yang juga dikatakan tulisan ini, kita harus merancang modul dengan coupling rendah dan cohesion tinggi agar konteks bisa dimasukkan ke dalam context window yang terbatas.

[jamsya]

LLM memang cukup bagus untuk meninjau kode dalam cakupan kecil, tetapi untuk desain keseluruhan dan sudut pandang yang lebih luas masih agak kurang. Menggabungkannya dengan TDD lalu memperbaikinya sedikit demi sedikit tampaknya merupakan pendekatan yang bagus.