# Cara Menguji Kode Buatan AI: Praktik Terbaik > AI menulis 70 persen pertama dengan cepat dan 30 persen terakhir dengan buruk. Strategi pengujian berlapis untuk memperlakukan kode buatan AI sebagai pull request junior yang tidak tepercaya. URL: https://www.matthewswong.com/id/blog/testing-ai-generated-code-guide/ - Author: Matthews Wong (https://www.matthewswong.com/id/about/) - Published: 2026-08-07 - Updated: 2026-08-07 - Category: Software Development > **Key takeaway:** Kode buatan AI sering berfungsi di happy path dan gagal di tepian, sehingga demo yang hijau bukan bukti bahwa ia benar. Perlakukan setiap diff AI seperti pull request junior yang tidak tepercaya: lapisi test unit, integrasi, dan edge case, jalankan pengecekan tipe dan lint, serta tinjau kodenya alih-alih memercayai bahwa ia berjalan. Tool generatif telah menjadikan menulis kode sebagai bagian yang mudah. Seorang agen bisa menghasilkan fitur yang berfungsi dalam hitungan menit, dan kecepatan itulah yang membuat pertanyaan pengujian menjadi mendesak: hambatannya telah berpindah dari mengetik kode ke memercayainya. Demonya berjalan, tetapi apakah ia bertahan? Jawaban jujurnya adalah kode buatan AI perlu pengawasan lebih ketat daripada kode tulisan tangan, bukan lebih longgar, karena ia datang dengan percaya diri yang tak beralasan dan tanpa penulis yang memahami setiap baris. Panduan ini memaparkan strategi pengujian berlapis untuk merilisnya dengan aman, dan pola pikir yang membuat strategi itu bertahan. ## Mengapa kode AI perlu pengujian lebih keras Addy Osmani menyebutnya masalah 70 persen: AI membawa Anda sebagian besar jalan menuju sebuah fitur dengan sangat cepat, lalu 30 persen terakhir, yaitu edge case, error handling, dan integrasi, berubah menjadi perjuangan berat yang tersembunyi oleh kecepatan bagian pertama. Ada paradoks pengetahuan di atasnya. Developer yang paling diuntungkan oleh kode AI adalah yang cukup berpengalaman untuk menangkap kesalahannya, sementara yang paling tidak berpengalaman adalah yang paling tidak siap mengujinya. Itu membentuk cara Anda seharusnya menguji: - Jangan menyamakan berjalan dengan benar. Sebuah demo yang lolos menjalankan satu jalur yang dicoba penulisnya, bukan input yang benar-benar akan dikirim pengguna. - Asumsikan percaya diri yang tak beralasan. Kodenya terbaca seolah seseorang memikirkannya matang, tetapi tidak ada manusia yang memvalidasi asumsi yang tertanam di dalamnya. - Belanjakan anggaran review Anda di tempat AI lemah, pada 30 persen terakhir, alih-alih membaca ulang boilerplate yang sudah ditanganinya dengan baik. ## Pendekatan pengujian berlapis Tidak ada satu pengecekan pun yang menangkap segalanya, jadi tumpuk mereka. Test unit mematok perilaku, test integrasi menangkap sambungan, dan tooling statis menangkap kecerobohan yang terlewat test. Tujuannya adalah banyak sinyal murah dan cepat alih-alih satu suite yang berat. Rangkai lapisan-lapisan itu ke dalam satu perintah yang dijalankan agen dan CI Anda, sehingga tak seorang pun bisa melewatkan sebuah langkah. Sebuah gerbang minimal terlihat seperti ini: > Tinjau diff-nya, bukan hanya keluarannya. Minta agen menjelaskan setiap baris yang tujuannya tidak jelas, dan jika penjelasannya kabur, baris itulah tempat test Anda berikutnya. Kode yang tak terjelaskan adalah kode tak teruji yang menunggu untuk gagal. ## Di mana kode AI paling sering rusak Arahkan test Anda ke kategori dengan rekam jejak terburuk. Menurut analisis Skyramp atas kode buatan AI, tingkat cacatnya berkumpul di beberapa tempat yang bisa diperkirakan. - Error handling, kira-kira 3,4 kali lebih rawan cacat menurut Skyramp, tempat agen menulis happy path dan sekadar men-stub jalur kegagalan. - Edge case, kira-kira 4,1 kali lebih rawan cacat menurut Skyramp, meliputi koleksi kosong, batas, dan tipe yang tak terduga. - Concurrency, kira-kira 4,7 kali lebih rawan cacat menurut Skyramp, tempat race condition bertahan karena tidak pernah muncul dalam sebuah test manual yang cepat. - Kode yang sensitif secara keamanan, tempat agen mungkin memilih default yang tidak aman yang lolos test fungsional tetapi gagal pada sebuah threat model. ## Pertahankan manusia dalam loop Test otomatis itu perlu tetapi mereka berbagi titik buta dengan kodenya: jika agen salah memahami kebutuhan, ia bisa menulis kode yang salah sekaligus test yang salah, dan keduanya akan cocok satu sama lain dengan sempurna. Itulah mengapa seorang manusia tetap harus mengecek test terhadap maksud yang sebenarnya. Baca assertion-nya dan tanyakan apakah mereka mengkodekan apa yang seharusnya dilakukan fitur itu, bukan sekadar apa yang saat ini dilakukan kodenya. > Waspadai test tautologis. Ketika agen yang sama menulis baik kode maupun test-nya, mereka bisa mengkodekan asumsi salah yang identik, menghasilkan suite yang lolos padahal perilakunya salah. Sebuah test yang sekadar mengulang implementasi tidak membuktikan apa pun. ## Checklist untuk merilis kode AI Sebelum perubahan tulisan AI di-merge, lewatkan ia melalui gerbang yang sama setiap kali. Konsistensi itulah yang mengubah kebiasaan ini menjadi keamanan. - Jalankan seluruh test suite ditambah pengecekan tipe, lint, dan build produksi, dan perlakukan setiap kegagalan sebagai penghalang. - Tambahkan test eksplisit untuk jalur kesalahan dan edge case yang dilewati agen. - Baca diff-nya baris demi baris, dan tulis ulang apa pun yang tidak bisa Anda jelaskan kepada seorang rekan. - Untuk perubahan berisiko, minta agen baru atau seorang kolega meninjau diff tanpa alur pikir penulis aslinya. Kecepatan pembuatan kode AI itu nyata, tetapi ia memindahkan pekerjaan alih-alih menghilangkannya. 30 persen terakhir, bagian yang menentukan apakah fitur itu bertahan saat bersentuhan dengan pengguna sungguhan, tetap menjadi milik Anda. Uji kode AI seperti kontribusi tak tepercaya sebagaimana adanya, dan Anda mempertahankan kecepatannya tanpa mewarisi cacatnya. ## Sumber & bacaan lanjutan - Skyramp — Testing AI-generated code - Dokumentasi Claude Code — Praktik terbaik agentic coding - Addy Osmani — Masalah 70 persen - Augment Code — Spec dan TDD untuk kode AI yang layak rilis ## Source links - https://skyramp.dev/blog/testing-ai-generated-code - https://code.claude.com/docs/en/best-practices - https://addyo.substack.com/p/the-70-problem-hard-truths-about - https://www.augmentcode.com/guides/spec-tdd-shippable-ai-generated-code ## FAQ ### Mengapa kode buatan AI perlu lebih banyak pengujian? Kode AI datang dengan percaya diri yang tak beralasan: ia terbaca seolah seseorang menalarnya, tetapi tidak ada manusia yang memvalidasi asumsinya. Masalah 70 persen dari Addy Osmani menangkap mengapa 30 persen terakhir, yaitu edge case dan error handling, adalah tempat kode AI gagal. Demo yang hijau hanya membuktikan satu jalur yang dicoba penulis, bukan input yang akan dikirim pengguna sungguhan. ### Strategi pengujian apa yang cocok untuk kode AI? Lapisi pengecekan Anda alih-alih mengandalkan satu. Test unit mematok perilaku, test integrasi menangkap sambungan, dan tooling statis seperti pengecekan tipe dan linter menangkap kecerobohan yang terlewat test. Rangkai mereka ke dalam satu perintah yang dijalankan agen dan CI, sehingga tidak ada langkah yang terlewat, dan perlakukan setiap kegagalan sebagai penghalang. ### Di mana kode buatan AI paling sering gagal? Menurut Skyramp, tingkat cacat kira-kira 3,4 kali lebih tinggi pada error handling, 4,1 kali lebih tinggi pada edge case, dan 4,7 kali lebih tinggi pada concurrency untuk kode buatan AI. Kode yang sensitif secara keamanan adalah titik lemah lain, karena agen mungkin memilih default tak aman yang tetap lolos test fungsional. ### Bisakah saya memercayai test yang ditulis AI sendiri? Tidak tanpa peninjauan. Ketika agen yang sama menulis kode dan test-nya, keduanya bisa mengkodekan asumsi salah yang identik, menghasilkan suite tautologis yang lolos padahal perilakunya salah. Seorang manusia harus membaca assertion-nya dan memastikan mereka mengungkapkan maksud sebenarnya, bukan sekadar mengulang apa yang saat ini dilakukan kodenya. ### Apakah lolos test suite cukup untuk merilis kode AI? Tidak. Suite yang hijau itu perlu tetapi tidak cukup, karena ia hanya membuktikan perilaku yang seseorang pilih untuk diuji. Baca diff-nya baris demi baris, tambahkan test eksplisit untuk jalur kesalahan dan edge case yang dilewati agen, dan untuk perubahan berisiko minta agen baru atau kolega meninjau kode tanpa alur pikir aslinya. --- - HTML version: https://www.matthewswong.com/id/blog/testing-ai-generated-code-guide/ - English: https://www.matthewswong.com/en/blog/testing-ai-generated-code-guide/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json