- Saat agen AI menjadi pusat penulisan kode, praktik terbaik yang sebelumnya ‘opsional’ seperti pengujian, dokumentasi, dan static typing kini berubah menjadi elemen wajib
- Menuntut cakupan kode 100%, agar setiap baris kode benar-benar diverifikasi dan didukung oleh contoh eksekusi nyata
- Memperjelas struktur direktori dan penamaan file agar LLM lebih mudah menavigasi codebase, serta mendorong susunan file dalam unit kecil
- Membangun lingkungan pengembangan yang cepat, ephemeral, dan dapat berjalan bersamaan, sehingga banyak agen bisa bekerja secara paralel
- Kuncinya adalah menjaga ekosistem kode yang dapat dipercaya AI melalui sistem tipe statis dan alat kontrol kualitas otomatis
AI dan keharusan akan ‘kode yang baik’
- Selama bertahun-tahun, developer menganggap pengujian, dokumentasi, modul kecil, dan static typing sebagai standar kode yang baik, tetapi dalam praktiknya hal-hal ini sering diabaikan
- Namun, karena agen AI tidak pandai merapikan kode sendiri, praktik terbaik tersebut menjadi mutlak diperlukan
- Untuk mencegah agen bergerak ke arah yang salah, penetapan guardrail yang jelas dan penegakan otomatis sangat penting
- Dengan guardrail yang kokoh, LLM hanya akan berkumpul pada jalur yang benar, sedangkan dalam lingkungan yang tidak lengkap ia justru memperbesar masalah
Cakupan kode 100%
- Tim mewajibkan cakupan kode 100%, bukan sekadar untuk mencegah bug, tetapi untuk memverifikasi perilaku semua kode yang ditulis agen
- Pada cakupan 95% atau 99.99%, asal-usul kode yang tidak diuji sulit diketahui, tetapi pada 100% setiap baris yang belum diverifikasi dapat diidentifikasi dengan jelas
- Laporan cakupan dipakai sebagai daftar hal yang harus diuji, dan LLM wajib menyajikan contoh yang bisa dijalankan setiap kali mengubah kode
- Pendekatan ini juga memberi efek samping positif seperti menghapus kode yang tak terjangkau, memperjelas edge case, dan meningkatkan efisiensi code review
Namespace dan struktur file
- Agen menjelajahi codebase melalui sistem file, sehingga struktur direktori dan nama file berperan sebagai antarmuka yang penting
- Jalur yang jelas seperti ./billing/invoices/compute.ts menyampaikan jauh lebih banyak informasi daripada ./utils/helpers.ts
- Sebaiknya gunakan file yang kecil dan terdefinisi dengan baik, karena ini memungkinkan LLM memuat seluruh file ke dalam konteks sehingga mencegah penurunan performa
- Struktur seperti ini menghasilkan peningkatan kecepatan dan akurasi penjelajahan agen
Lingkungan pengembangan yang cepat, ephemeral, dan dapat berjalan bersamaan
- Alih-alih satu lingkungan pengembangan tradisional, pengembangan berbasis agen beralih ke bentuk pengelolaan banyak proses secara paralel
- Fast: pengujian dan prosedur verifikasi harus berjalan cepat, dan tim mengoptimalkan lebih dari 10.000 assertion agar selesai dalam 1 menit
- Kecepatan dicapai melalui paralelisasi tingkat tinggi, isolasi yang kuat, dan lapisan cache untuk panggilan pihak ketiga
- Ephemeral: dengan perintah
new-feature <name>, lingkungan baru dibuat dalam 1–2 detik, termasuk pengaturan otomatis dan menjalankan agen
- Jika perlu pengaturan manual, frekuensi penggunaannya akan turun drastis, jadi otomatisasi penuh adalah kuncinya
- Concurrent: agar beberapa lingkungan pengembangan bisa berjalan sekaligus, diperlukan pengaturan pencegahan konflik untuk port, DB, cache, dan lain-lain
- Gunakan Docker atau siapkan isolasi berbasis environment variable
Sistem tipe end-to-end dan kontrol kualitas otomatis
- Mengotomatiskan sebanyak mungkin praktik terbaik untuk mengurangi derajat kebebasan LLM dan menjaga kualitas tetap konsisten
- Atur linter dan formatter otomatis secara ketat, sehingga perbaikan otomatis diterapkan setiap kali LLM menyelesaikan tugasnya
- Disarankan memakai bahasa dengan tipe statis, terutama memanfaatkan sistem tipe yang kuat di TypeScript
- Nama tipe yang bermakna seperti
UserId, WorkspaceSlug, SignedWebhookPayload membantu mengekspresikan maksud kode dengan jelas
- Gunakan OpenAPI untuk menjaga kesesuaian tipe antara frontend dan backend
- Manfaatkan sistem tipe dan trigger di Postgres untuk memastikan integritas data, lalu buat klien yang type-safe dengan Kysely
- Semua klien pihak ketiga juga harus memiliki definisi tipe yang akurat atau digunakan melalui wrapper
Kesimpulan: redefinisi kualitas kode di era AI
- Agen adalah coder yang hebat dan tidak lelah, tetapi performanya bergantung pada kualitas lingkungan
- ‘Kode yang baik’ bukan lagi pilihan, melainkan prasyarat agar AI dapat bekerja dengan benar
- Penyiapan awal mungkin terasa membebani, tetapi ini adalah investasi penting yang terlalu lama ditunda
- Dengan dukungan kepemimpinan engineering, tujuan yang harus dikejar adalah membangun codebase yang ramah AI
1 komentar
Komentar Hacker News
Jebakan saat mencapai cakupan 100% adalah, jika kode dan tes ditulis oleh agen yang sama, kita bisa terjebak dalam validasi yang kontradiktif terhadap dirinya sendiri
Jika agen membuat logika yang salah dan juga menulis tes yang salah untuk memverifikasinya, tes akan lolos tetapi pada kenyataannya kodenya tetap mengandung bug
Cakupan seperti ini hanya bermakna jika tes ditulis lebih dulu daripada kodenya, atau diverifikasi secara ketat oleh manusia
Jika tidak, itu hanya menciptakan ilusi keandalan
Intinya adalah orang-orang dengan cara berpikir yang berbeda saling memeriksa titik buta satu sama lain
Meskipun model AI ada banyak, pada akhirnya semuanya perlu diperlakukan sebagai satu ‘pikiran’
Kode manusia dengan tes AI, kode AI dengan tes manusia, atau saling melakukan code review adalah pendekatan yang baik
Namun bahkan di antara manusia pun, karena relasi kuasa, terkadang hanya pendapat satu orang yang tercermin, dan AI tidak akan mencegah hal itu
Kita harus sengaja menyisipkan bug dan melihat apakah tes gagal
Ini bukan masalah khusus AI; pada manusia pun sama
Meski begitu, berkat AI banyak developer jadi belajar prinsip rekayasa yang benar dan itu hal yang baik
SQLite dan perangkat lunak penerbangan menargetkan tingkat seperti ini
Namun ini masih belum merupakan hipotesis yang tervalidasi secara akademis
Karena itu kita perlu memverifikasi skenario pengguna nyata dengan tes integrasi atau tes otomatisasi UI
Data yang diambil dari lingkungan produksi atau pengujian di lingkungan bayangan juga membantu
Sebelum era LLM, penyiapannya merepotkan, tetapi sekarang ROI-nya jadi bagus
Seperti yang ditekankan Uncle Bob, penting untuk berinvestasi dalam penataan struktur tes
LLM memang menulis tes yang repetitif, tetapi jika diminta, ia juga cukup baik menerapkan prinsip DRY atau pola factory
Ini metode yang saya coba sejak kemarin: saya menulis spesifikasi dulu dengan TLA+/PlusCal, lalu meminta Codex mengimplementasikannya persis sesuai spesifikasi itu
Saya instruksikan agar ia hanya setia pada spesifikasi tanpa kreativitas
Hasil kodenya jelek tapi akurat, dan jauh lebih cepat daripada menerjemahkannya sendiri
Namun jika optimisasinya kurang atau terlalu berantakan, saya tetap memperbaiki sebagian
Khususnya saya sedang bereksperimen dengan struktur data tanpa lock, tetapi Codex masih cenderung memakai lock sehingga harus saya koreksi sendiri
Pada akhirnya saya fokus pada logika matematis, dan AI menangani detail implementasi
Inilah alur ideal “spesifikasi dulu, kode belakangan”
Saya setuju dengan tulisan Martin Kleppmann
Pada model terbaru, ini benar-benar bekerja dengan baik, dan efisiensi biayanya juga membaik 10~100 kali lipat
Ini terasa seperti halusinasi atau sales pitch
Jika bug produksi nyata dan beban pemeliharaan tidak bisa memaksa kode yang baik, AI juga tidak akan bisa
AI pada level saat ini justru sangat mungkin membuat kode menjadi lebih buruk
Bahkan panjang metode saja belum ada kesepakatan, jadi standar kualitas universal itu tidak ada
Metrik seperti cakupan tes juga mudah dimanipulasi, dan jika diterapkan dengan salah justru berbahaya
Terutama saat AI menulis tes, itu bisa memberi rasa percaya diri palsu
Menurut saya pengembangan perangkat lunak mungkin adalah satu-satunya bidang aplikasi LLM yang benar-benar nyata
Dibanding bidang lain, kita bisa membuat feedback loop jauh lebih cepat
Kita membuat rencana bersama LLM dan beberapa jam kemudian memeriksa kegagalannya, lalu LLM berkata, “jadi memang begitu tidak boleh dilakukan”
Ini seperti membangun rumah dengan standar listrik Amerika lalu menemukan masalah saat memasang mesin pencuci piring standar Kanada
Perangkat lunak relatif aman sehingga pengembangan anonim masih dimungkinkan, tetapi sekarang mulai muncul budaya tanda tangan yang bertanggung jawab
Ke depan, mungkin hanya orang yang menulis kode berisiko tinggi dan inovatif yang akan menerima bayaran tinggi
AI terus mengeluarkan kode yang ngawur, kita mendebug, lalu ia mengeluarkan hal aneh lain lagi, dan akhirnya kita cuma masuk loop tanpa akhir
Asalkan hanya spesifikasi arus listriknya yang sesuai, itu aman
Meski begitu, saya tetap merasa lega karena setidaknya dengan tes unit kita punya titik kontak dengan kenyataan
Saya sedang mempelajari rangkaian RLC dan inerter dengan bantuan LLM
Banyak orang terkejut melihat LLM menghasilkan kode dengan cepat, tetapi kecepatan atau jumlah bukanlah bottleneck kualitas
Revolusi yang sesungguhnya akan terjadi ketika AI membuat kode yang lebih akurat daripada manusia
Nilai yang sesungguhnya datang dari mengetahui bagaimana kode itu bekerja
Di tengah engineer yang hanya menebak-nebak saat rapat, momen ketika satu orang membuka kode yang sebenarnya dan memperlihatkannya adalah yang paling berharga
Mungkin ‘kode yang baik’ adalah kode yang dioptimalkan untuk memori kerja manusia yang terbatas
Model bisa melihat seluruh konteks sekaligus, jadi tidak punya batasan seperti itu
Jika context window membesar 100 kali, diskusi seperti ini mungkin akan menjadi kurang penting
Saya khawatir jika kita menuntut cakupan 100% dari LLM, asumsi yang salah akan mengeras
Tapi kalau tetap ada review manusia, kita masih bisa berkata “ini salah, hapus tesnya dan tulis ulang”, bukan?
LLM juga ikut menyusun PRD seperti sedang wawancara, sehingga cakupan dan ekspektasi jadi jelas
“Best practice” berubah tergantung lingkungan teknis
Sekarang ketika menulis kode jadi lebih mudah, cakupan 100% bisa jadi lebih berguna bagi LLM
Tes memberi LLM tujuan yang jelas, dan membuat interaksi setelahnya lebih aman
Setiap tes merujuk pada tiket bug masa lalu dan menjamin bahwa perbaikannya tetap terjaga
Jika kita memberi skenario pada LLM, sebagian besar akan menghasilkan kode dengan kualitas yang mirip
Tidak seperti seni kreatif, perangkat lunak adalah industri yang sangat cocok untuk otomatisasi
Saat membaca judulnya, saya kira isinya akan tentang “agar AI efektif, kita harus menulis kode yang baik”
Memang, Claude sering salah pada nama variabel yang tidak jelas atau kode yang tidak logis
Jika nama variabelnya “iteration_count” tetapi sebenarnya menyimpan total, AI akan terkecoh
Pada akhirnya kode yang rapi membantu AI maupun manusia
Karena AI memakai dokumen internal sebagai sumber belajar, kini dokumentasi yang selalu diperbarui dianggap wajib
Dulu prioritasnya rendah, tetapi sekarang hal itu berdampak langsung pada kualitas model
Namun seiring waktu, bagian ini juga akan membaik
Dengan begitu peluang LLM mengimplementasikannya dengan benar dalam sekali jalan akan lebih tinggi
Artikel ini menunjukkan pemahaman rekayasa yang dangkal dari perusahaan-perusahaan prompt
Cakupan 100% tidak memverifikasi semua kombinasi input
Itu hanya berarti setiap baris dijalankan dengan beberapa contoh
Pada akhirnya yang dibutuhkan adalah pembuktian formal, tetapi biayanya sangat besar dan LLM tidak berguna di sana
Justru menciptakan lingkungan pengembangan yang reaktif dengan tes bisa membuka zaman keemasan baru
Kalau nanti ada masalah pada cakupan, kita bisa memperluasnya kemudian
Lebih baik menyiapkan pengujian semenyeluruh mungkin sejak awal
Sudah banyak upaya menghubungkannya dengan proof assistant
Bahkan jika ada sedikit kesalahan dalam spesifikasi, sebagian besar tetap menghasilkan hasil yang cukup berguna