AI Coding untuk Debugging dan Testing

Error merah di terminal sering terlihat seperti masalah yang jelas. Padahal satu pesan TypeError bisa muncul karena data masuk dalam bentuk yang salah, fungsi dipanggil terlalu cepat, atau tes memakai fixture lama. AI coding dapat membantu membaca jejak error, menyusun dugaan, membuat tes awal, dan mengusulkan perubahan. Kamu tetap perlu menjalankan kode, memeriksa diff, lalu memutuskan apakah perbaikannya benar.

Panduan ini membahas penggunaan asisten pemrograman untuk debugging dan testing, bukan cara meminta mesin menulis proyek tanpa pengawasan. Contohnya memakai Python, JavaScript, dan perintah umum yang bisa kamu sesuaikan. Kode contoh sengaja kecil supaya alurnya gampang diuji. Waktu baca sekitar 24 menit pada kecepatan 200 kata per menit.

AI coding paling berguna saat masalahnya dipersempit

Kamu tidak perlu memberi seluruh repositori kepada sebuah model hanya karena error muncul di satu fungsi. Mulai dari berkas yang relevan, pesan error lengkap, perintah untuk menjalankan tes, serta hasil yang kamu harapkan. Empat potong informasi itu sering lebih berguna daripada prompt panjang yang menceritakan sejarah proyek dari awal.

Istilah AI coding di sini mencakup asisten di editor, chatbot yang bisa membaca potongan kode, dan agen yang dapat mengusulkan perubahan pada beberapa berkas. Nama produk, model, batas pemakaian, serta fitur akses berkas berubah menurut layanan dan akun. GitHub menjelaskan bahwa Copilot dapat membantu membuat unit test dan integration test, tetapi kompleksitas skenario membutuhkan prompt yang lebih rinci dan pemeriksaan manual. Dokumentasinya juga memperlihatkan contoh menjalankan tes dengan python -m unittest.

Ada batas yang tidak boleh dilewati. Jangan tempel token API, kata sandi, private key, data pelanggan, isi berkas .env, atau alamat server yang sebenarnya ke layanan yang tidak kamu pahami kebijakan datanya. Ganti alamat dengan app.example.test, IP dokumentasi 203.0.113.10, dan kredensial dengan REDACTED. Kalau bug menyangkut sistem produksi, kirim potongan log yang sudah disamarkan.

Bedakan debugging, testing, dan refactoring

Debugging mencari penyebab perilaku yang salah. Testing memeriksa apakah perilaku yang disepakati tetap benar. Refactoring merapikan struktur tanpa mengubah perilaku yang terlihat. Tiga pekerjaan ini sering muncul dalam satu sesi, tetapi permintaannya tidak sama.

Kalau pengguna gagal masuk ketika kata sandinya benar, kamu sedang mencari bug. Kalau kamu menulis tes agar kegagalan itu tidak terulang, kamu sedang menambah pengujian. Kalau kamu memecah fungsi besar menjadi beberapa fungsi kecil setelah tes lulus, kamu sedang melakukan refactoring. Minta bantuan AI sesuai tahapnya. Kalau semua dicampur dalam satu perintah, diff yang dihasilkan sulit ditinjau.

Pemisahan ini juga membantu saat memakai agen yang bisa mengubah berkas. Minta diagnosis tanpa perubahan dulu. Setelah hipotesis masuk akal, minta patch sekecil mungkin. Jalankan tes yang gagal. Baru minta tambahan tes atau perapian. Kedengarannya lebih lambat, tetapi biasanya menghemat waktu ketika usulan pertama ternyata salah.

Alur kerja yang aman untuk mencari bug

Simpan kondisi awal sebelum bertanya. Pastikan branch kerja bersih atau perubahan lokal sudah kamu pahami. Jalankan perintah yang biasanya gagal dan simpan outputnya. Kalau tes belum pernah dijalankan, jalankan seluruh suite sekali untuk mengetahui kondisi awal. Jangan menyebut hasil lulus kalau kamu belum melihat perintahnya selesai.

Setelah itu, buat ringkasan pendek. Tulis nama fungsi, input yang memicu masalah, hasil aktual, hasil yang seharusnya, versi runtime jika relevan, dan perintah reproduksi. AI akan bekerja dengan bahan itu. Kamu juga akan lebih mudah membandingkan dugaan model dengan fakta.

Contoh prompt diagnosis:

Saya punya fungsi Python berikut.

[potongan kode]

Saat menjalankan `python -m unittest`, tes `test_empty_cart_total` gagal.
Hasil aktual: 15000.
Hasil yang diharapkan: 0.

Tolong:
1. jelaskan alur nilai dari input sampai hasil,
2. beri dua hipotesis penyebab yang bisa diuji,
3. jangan ubah kode dulu,
4. sebutkan informasi yang masih kurang.

Kalimat “jangan ubah kode dulu” bukan jaminan mutlak pada semua alat, tetapi ia memberi batas kerja yang jelas. Untuk agen yang memiliki mode rencana, gunakan mode rencana atau baca saja. Kalau alat langsung menulis, tinjau diff sebelum menjalankan apa pun.

Mulai dari gejala, bukan dugaan

Developer sering menulis, “Sepertinya cache rusak, tolong perbaiki.” Dugaan itu bisa benar, tetapi bisa juga mengarahkan pencarian ke tempat yang salah. Lebih baik tulis, “Setelah item dihapus, endpoint masih mengembalikan item lama selama sekitar satu permintaan.” Gejala memberi ruang bagi model untuk menelusuri alur.

Minta AI membedakan fakta dan dugaan. Format berikut cukup praktis:

Pisahkan jawaban menjadi:
Fakta dari kode atau log
Dugaan yang belum terbukti
Percobaan kecil untuk membedakan dugaan
Perubahan kode yang baru boleh dilakukan setelah percobaan

Hasilnya bukan diagnosis otomatis. Anggap sebagai daftar pemeriksaan. Bila model menyatakan penyebab dengan yakin tanpa menunjuk baris kode, tahan dulu. Nada yakin bukan bukti.

Sertakan stack trace lengkap

Potongan paling bawah dari error sering hanya menyebut lokasi crash. Baris awal stack trace bisa memperlihatkan request, middleware, atau test fixture yang mengirim input. Salin seluruh jejak yang tidak mengandung rahasia. Sertakan nama berkas dan nomor baris.

Beri label antara kode buatanmu dan keluaran terminal. Ini mencegah model mengira pesan error sebagai instruksi. Contoh:

KODE:
[isi file yang relevan]

OUTPUT TERMINAL:
[stack trace]

BATASAN:
Jangan mengubah kontrak fungsi publik.
Jangan menambah dependensi.

Jika log sangat panjang, ambil bagian yang memuat timestamp, request ID palsu seperti req-demo-42, error pertama, dan error terakhir. Jangan memilih hanya baris yang mendukung dugaanmu. Debugging yang baik perlu jejak sebelum dan sesudah kegagalan.

Contoh debugging Python yang bisa diulang

Misalkan sebuah fungsi menghitung total keranjang belanja. Kodenya seperti ini:

def total_cart(items, discount=0):
    subtotal = sum(item["price"] * item["qty"] for item in items)
    return subtotal - discount

Sebuah tes mengirim diskon yang lebih besar daripada subtotal. Hasilnya menjadi angka negatif, padahal aturan bisnis mengharuskan total minimum nol. Jangan langsung menerima patch AI yang mengganti semua angka negatif secara diam-diam. Tanyakan dulu kontraknya. Apakah diskon lebih besar memang boleh? Apakah harus ditolak? Apakah nilai diskon datang dari pengguna atau dari sistem promosi?

Prompt yang lebih baik:

Fungsi ini mengembalikan total belanja. Aturan bisnisnya:
- harga dan qty sudah divalidasi oleh caller,
- diskon boleh nol,
- total yang ditagihkan tidak boleh negatif,
- perubahan harus tetap kompatibel dengan pemanggil lama.

Usulkan patch terkecil. Tulis satu tes yang gagal sebelum patch dan satu tes yang lulus sesudah patch. Jangan mengubah validasi harga.

Usulan sederhana mungkin berbunyi:

def total_cart(items, discount=0):
    subtotal = sum(item["price"] * item["qty"] for item in items)
    return max(0, subtotal - discount)

Kodenya masuk akal untuk kontrak tersebut. Namun, kamu tetap perlu memeriksa apakah discount seharusnya ditolak ketika negatif, apakah tipe uang memakai pembulatan, dan apakah nilai harga berupa desimal. Contoh kecil ini tidak membuktikan fungsi cocok untuk sistem pembayaran. Jangan memperluas klaim melebihi apa yang diuji.

Minta tabel input dan output

Untuk fungsi yang punya banyak cabang, minta AI menyusun tabel kasus sebelum menulis patch. Kolom yang berguna adalah input, jalur kode, hasil yang diharapkan, dan alasan kasus itu perlu ada. Dua kasus sering cukup untuk bug tertentu, sementara fungsi otorisasi mungkin membutuhkan lebih banyak batas.

Contoh untuk validasi kuantitas:

Jangan biarkan model mengisi perilaku yang belum diputuskan. Tanda “sesuai kontrak tipe” bukan jawaban final. Itu pengingat bahwa tim perlu memilih aturan.

Membaca error dengan bantuan AI

Pesan error dapat dikelompokkan menjadi masalah input, tipe data, urutan eksekusi, dependensi, konfigurasi, lingkungan, atau logika. Pengelompokan ini membantu memilih pemeriksaan. ModuleNotFoundError tidak diselesaikan dengan mengubah algoritme. AssertionError pada nilai yang salah tidak otomatis berarti framework tes rusak.

Tanyakan tiga hal pada setiap error. Baris mana yang gagal? Nilai apa yang masuk saat itu? Asumsi kode apa yang ternyata tidak berlaku? Pertanyaan kedua sering dilewatkan. Developer membaca nama variabel, sedangkan bug mengikuti nilai aktual.

Untuk KeyError, minta model melacak sumber dictionary dan semua jalur yang bisa menghilangkan kunci. Untuk IndexError, minta daftar panjang array sebelum akses. Untuk kegagalan asinkron, minta urutan event serta titik tunggu. Jangan puas dengan jawaban “tambahkan pengecekan null” jika sumber data belum ditemukan.

Perintah pemeriksaan kecil lebih berharga daripada paragraf teori. Misalnya, kamu bisa meminta:

Buatkan tiga print sementara atau assertion diagnostik untuk memeriksa tipe dan nilai pada batas masuk fungsi. Jangan ubah logika produksi. Tandai lokasi yang harus dihapus setelah penyebab ditemukan.

Setelah penyebab ketemu, hapus diagnostik tersebut atau ubah menjadi logging yang memang dibutuhkan. Print tertinggal di produksi itu kecil, tapi bisa membuat log berisik dan membocorkan data.

Menggunakan AI untuk menulis unit test

Unit test memeriksa unit kecil dalam kondisi terkontrol. AI bisa cepat menghasilkan kasus normal, tetapi sering lupa nilai kosong, batas bawah, exception, serta kontrak tipe. Beri model spesifikasi yang benar dan minta daftar kasus sebelum kode tes.

Contoh kelas:

class BankAccount:
    def __init__(self, balance=0):
        if balance < 0:
            raise ValueError("balance tidak boleh negatif")
        self.balance = balance

    def withdraw(self, amount):
        if amount <= 0:
            raise ValueError("amount harus positif")
        if amount > self.balance:
            raise ValueError("saldo tidak cukup")
        self.balance -= amount

Prompt yang berguna:

Tulis unit test unittest untuk BankAccount.
Gunakan perilaku pada kode, jangan membuat aturan baru.
Uji saldo awal nol, penarikan valid, amount nol, amount negatif,
penarikan melebihi saldo, dan saldo awal negatif.
Sebutkan satu asumsi yang belum dijelaskan.

Kamu dapat menjalankan tes dengan:

python -m unittest test_bank_account.py

GitHub menyarankan pengujian yang mencakup kasus normal, edge case, exception, dan validasi input dalam panduan Copilot untuk penulisan tes. Dokumentasi yang sama mengingatkan bahwa hasil buatan Copilot tetap perlu ditinjau. Itu sejalan dengan praktik yang masuk akal. Tes yang hijau hanya membuktikan kode cocok dengan assertion yang kamu tulis, bukan bahwa assertion-nya benar.

Jangan menulis tes yang menyalin implementasi

Tes berikut lemah:

self.assertEqual(account.balance, 70)

Akses langsung ke atribut mungkin sah jika memang bagian dari API internal. Namun, kalau kontrak publiknya adalah saldo yang terlihat melalui get_balance(), gunakan antarmuka itu. Tes yang meniru setiap langkah internal akan rusak saat refactoring, meskipun perilaku pengguna tetap sama.

Minta AI menjelaskan perilaku yang ingin dijaga. Lalu periksa apakah assertion mengikuti perilaku itu, bukan susunan baris di fungsi. Kalau model membuat mock untuk setiap pemanggilan kecil, tanyakan apakah mock tersebut memang menguji batas antar komponen atau hanya mengunci implementasi.

Gunakan property dan invariants

Beberapa aturan lebih mudah ditulis sebagai invariants. Setelah penarikan yang valid, saldo tidak boleh naik. Setelah total item dihitung, hasilnya tidak boleh negatif jika kontrak memang menetapkan batas nol. Setelah serialisasi lalu deserialisasi, data penting harus tetap sama.

Prompt:

Dari fungsi berikut, cari invariants yang bisa diuji tanpa mengetahui implementasi internal.
Pisahkan invariants yang pasti dari dugaan. Beri contoh unit test sederhana
menggunakan library yang sudah ada di proyek. Jangan menambah package baru.

Jangan menerima property yang terdengar bagus tetapi tidak berlaku. Misalnya, urutan hasil pencarian tidak selalu stabil kalau kontraknya memang tidak menjanjikan urutan. Tes yang terlalu ketat bisa mengubah fleksibilitas yang sengaja dirancang.

Testing dengan AI tanpa menerima tes secara mentah

Membuat tes dan menilai tes adalah dua pekerjaan. Minta AI melakukan review dengan konteks terpisah. Berikan fungsi dan test suite, lalu tanyakan kasus apa yang belum tertutup. Jangan menyebut hasil coverage saja. Coverage baris tinggi bisa tetap melewatkan bug pada kombinasi input.

Contoh permintaan review:

Review fungsi dan tes ini sebagai reviewer yang skeptis.
Cari:
- cabang yang belum diuji,
- assertion yang terlalu lemah,
- mock yang menutupi bug,
- kasus yang belum diputuskan kontraknya,
- tes yang akan lulus meskipun implementasi salah.
Jangan menulis ulang semua tes. Beri daftar prioritas.

Minta model mengutip fungsi atau nama tes yang menjadi dasar tiap catatan. Kalau jawabannya mengusulkan kasus yang tidak masuk kontrak, tandai sebagai pertanyaan produk, bukan langsung menambah tes.

Unit test dan integration test punya tujuan berbeda

Unit test cepat karena dependensi diganti dengan stub atau mock. Integration test memeriksa sambungan nyata, misalnya aplikasi dengan database, queue, atau layanan HTTP lokal. Keduanya dibutuhkan pada tempat berbeda, tetapi jangan menyebut unit test sebagai integration test hanya karena ada dua fungsi yang dipanggil.

GitHub memberi contoh integration test dengan mock untuk sistem notifikasi. Contoh itu berguna untuk menguji apakah komponen rekening memanggil notifikasi sesuai kontrak. Ia belum membuktikan layanan notifikasi sungguhan bisa menerima request. Untuk itu kamu butuh tes integrasi dengan boundary yang nyata atau server palsu yang perilakunya sudah ditentukan.

Tanyakan kepada AI:

Klasifikasikan setiap test berikut sebagai unit, integration, contract, atau end to end.
Jelaskan boundary yang sedang diuji. Jangan mengubah label hanya karena tesnya lambat.

Perbedaan ini membantu ketika suite mulai lambat. Kamu bisa menjalankan unit test pada setiap perubahan, lalu integration test dalam pipeline yang sesuai. Jangan mematikan tes lambat tanpa memahami risiko yang dipindahkan.

Membuat integration test yang tidak rapuh

Tes integrasi sering gagal bukan karena bug aplikasi, melainkan karena data uji bocor antar kasus, waktu tunggu terlalu pendek, atau layanan eksternal tidak tersedia. AI bisa menyarankan retry pada semua error. Itu solusi berbahaya karena dapat menyamarkan kegagalan nyata.

Berikan batas yang tegas:

Bantu stabilkan integration test ini.
Jangan menambah retry pada assertion bisnis.
Identifikasi apakah kegagalan berasal dari fixture, cleanup, timeout, atau layanan.
Jelaskan perubahan yang membuat failure tetap terlihat.

Fixture harus membuat keadaan awal yang jelas. Cleanup perlu terjadi walau assertion gagal. Data harus punya ID unik yang aman untuk lingkungan tes. Kalau memakai domain contoh, gunakan api.example.test, bukan host publik yang tidak kamu kendalikan.

Untuk request HTTP, tes status code, payload penting, serta perilaku ketika upstream mengembalikan timeout atau error. Tidak semua detail respons perlu dikunci. Header yang tidak ada dalam kontrak jangan dijadikan assertion hanya karena kebetulan muncul hari ini.

Memakai AI untuk regression test

Regression test lahir dari bug yang pernah terjadi. Setelah perbaikan dibuat, tulis kasus yang sebelumnya gagal. Masukkan input yang memicu bug, output yang seharusnya, dan alasan kasus itu tidak boleh hilang. Tes tersebut menjadi pagar untuk perubahan berikutnya.

Contoh sederhana:

Bug: parser tanggal menerima `2026-02-29` dan menggesernya ke Maret.
Aturan: tanggal tidak valid harus ditolak dengan ValueError.
Buat regression test yang tidak bergantung pada zona waktu lokal.
Jelaskan mengapa test ini akan menangkap bug lama.

Model mungkin mengusulkan datetime.now() tanpa zona waktu. Tolak pola itu jika perilaku harus deterministik. Pakai tanggal tetap dan zona waktu yang disebutkan kontrak. Waktu, locale, urutan dictionary, dan nomor acak adalah sumber flaky test yang sering perlu diberi instruksi khusus.

Debugging test yang gagal

Tes gagal tidak selalu berarti produk rusak. Kegagalan dapat berasal dari expectation yang keliru, fixture yang salah, lingkungan yang berbeda, race condition, atau perubahan kontrak yang belum diikuti. Baca diff aktual dan yang diharapkan sebelum meminta AI memperbaiki.

Kirim informasi berikut:

Nama test:
Perintah untuk menjalankan ulang:
Output gagal lengkap:
Commit atau perubahan terakhir yang relevan:
Apakah gagal konsisten atau acak:
Sistem operasi dan versi runtime:

Lalu minta langkah reproduksi paling kecil. Jika gagal hanya sekali dari sepuluh kali, jangan minta “buat tes lulus”. Minta cara mengukur kondisi balapan dan menemukan sumber nondeterminism. Tes yang dipaksa lulus dengan sleep panjang bukan perbaikan yang baik.

Masalah umum pada mock

Mock yang terlalu luas dapat mengembalikan nilai apa pun dan membuat kode terlihat benar. AI sering membuat Mock() tanpa spesifikasi sehingga tes tidak memeriksa kontrak. Minta mock menolak atribut atau pemanggilan yang tidak didefinisikan jika framework mendukungnya.

Periksa juga apakah mock dibuat ulang pada setiap tes. Mock global yang menyimpan panggilan dari tes sebelumnya bisa membuat hasil bergantung pada urutan. Model dapat membantu membaca setup, tetapi kamu harus memeriksa lifecycle fixture di framework yang dipakai.

Bila tujuan tes adalah memeriksa query database, mock repository hanya menguji bahwa fungsi memanggil repository. Itu belum memeriksa query. Pilih boundary sesuai risiko. Jangan mengejar unit test sebanyak mungkin kalau bug paling sering berada pada wiring dan konfigurasi.

Meminta patch yang aman

Ada perbedaan besar antara “perbaiki error ini” dan “ubah dua baris pada fungsi X agar kondisi Y ditangani, tanpa mengubah API”. Prompt kedua membatasi ruang gerak. Cantumkan berkas yang boleh diubah dan perintah tes yang wajib dijalankan.

Template yang bisa dipakai:

Tujuan: perbaiki [gejala].
Berkas yang boleh berubah: [daftar].
Kontrak yang harus dipertahankan: [daftar].
Batasan: jangan menambah dependensi, jangan mengubah format respons,
jangan menghapus tes yang gagal.
Sebelum patch: jelaskan akar masalah dan tes yang akan membuktikannya.
Sesudah patch: tampilkan diff, perintah yang dijalankan, dan hasil aktual.

Kalau agen mengubah terlalu banyak berkas, kembalikan ke titik awal bila aman, lalu pecah tugas. Diff kecil lebih mudah diperiksa. Namun, diff kecil bukan alasan mengabaikan migrasi yang memang membutuhkan beberapa berkas. Ukuran patch mengikuti batas masalah, bukan ego.

Minta komentar hanya jika alasan kode tidak bisa dijelaskan dengan struktur yang lebih jelas. Komentar yang berbunyi “fix bug” tidak membantu enam bulan lagi. Komentar yang menjelaskan alasan mempertahankan timeout tertentu lebih berguna, terutama kalau nilainya berasal dari kontrak eksternal.

Menangani usulan AI yang salah

Model bisa mengarang fungsi library, parameter, atau versi API. Kode yang tampak rapi tetap bisa salah. Saat jawaban menyebut API yang tidak kamu kenal, minta tautan dokumentasi resmi atau periksa dokumentasi paket yang terpasang. Jangan memasang dependensi baru hanya karena model menulis import-nya.

AI juga bisa menghapus validasi untuk membuat tes lulus. Ini lampu merah. Tanyakan tes mana yang gagal sebelum perubahan dan apa aturan yang dilanggar. Tes hijau setelah assertion dihapus bukan keberhasilan.

Usulan lain yang perlu dicurigai adalah menangkap Exception secara luas, mengembalikan None pada semua error, menambah retry tanpa batas, atau menonaktifkan verifikasi TLS. Minta alasan konkret dan ruang lingkup. Pada aplikasi yang mengurus akun atau pembayaran, perubahan semacam itu perlu review manusia yang mengerti risikonya.

Jika model buntu, ganti bentuk pertanyaan. Minta ia menjadi pengulas diff, penyusun reproduction case, atau pembuat tabel keputusan. Jangan mengulang prompt yang sama sambil berharap jawaban tiba-tiba berubah. Kadang konteksnya memang kurang, dan jawabannya adalah membuka kode yang tepat, bukan mencari kata-kata ajaib.

Debugging JavaScript dan TypeScript

Pada JavaScript, bug sering berkaitan dengan nilai undefined, mutasi objek, urutan promise, atau perbedaan environment browser dan Node.js. Minta AI menuliskan tipe nilai pada setiap batas fungsi. Dalam TypeScript, jangan langsung menekan error dengan as any atau @ts-ignore.

Contoh permintaan:

Fungsi TypeScript ini gagal ketika `options.timeout` tidak diisi.
Telusuri semua jalur nilai undefined.
Usulkan perbaikan dengan tipe yang lebih jujur.
Jangan memakai `any`, `as`, atau menonaktifkan strict mode.
Tambahkan tes untuk default, nilai nol, dan nilai negatif.

Nilai nol perlu disebut karena kode sering memakai options.timeout || 5000, yang menganggap nol sebagai false. Jika kontrak menganggap nol valid, gunakan pemeriksaan nullish atau aturan yang memang sesuai. AI dapat menemukan pola ini, tetapi tes kontraklah yang memutuskan perilakunya.

Pada promise, minta urutan event. Tanyakan apakah fungsi menunggu pekerjaan asynchronous sebelum mengembalikan nilai. Tes yang hanya memeriksa bahwa fungsi dipanggil belum tentu memeriksa hasil setelah promise selesai. Gunakan fake timer hanya jika kamu memahami cara framework menangani microtask.

Debugging di lingkungan yang berbeda

Bug yang hanya muncul di server sering dituduhkan pada “Linux” atau “produksi”. Pecah perbedaannya. Bandingkan versi runtime, variabel lingkungan yang memang diperlukan, locale, zona waktu, filesystem, database, dan jaringan. Jangan kirim seluruh konfigurasi rahasia kepada model.

Buat matriks kecil:

Tanda “versi terverifikasi” berarti kamu perlu mengisi hasil perintah nyata, bukan menebak. AI bisa menyusun perintah pemeriksaan, tetapi terminal yang menghasilkan faktanya.

Untuk jaringan, dummy domain tetap berguna dalam artikel dan dokumentasi. Pada proyek nyata, simpan endpoint dalam konfigurasi aman. Jangan menjadikan contoh https://app.example.test sebagai alamat produksi hanya karena salin-tempel terasa cepat.

Kapan memakai chatbot, asisten editor, atau agen

Chatbot cocok untuk menjelaskan error, membandingkan pendekatan, dan menyusun contoh kecil tanpa memberi akses ke repositori. Asisten editor cocok ketika kamu butuh konteks file yang sedang dibuka dan saran singkat. Agen cocok untuk tugas yang berulang pada beberapa berkas, tetapi risikonya lebih tinggi karena ruang perubahan lebih besar.

Pilih chatbot ketika masalahnya belum jelas. Pilih asisten editor ketika lokasi perubahan sudah diketahui. Pilih agen ketika pekerjaan bisa ditulis sebagai kriteria selesai yang bisa diuji, misalnya menambah regression test pada modul tertentu lalu menjalankan perintah yang spesifik.

OpenAI Codex dijelaskan dalam dokumentasi GitHub sebagai coding agent dan integrasi VS Code yang tersedia dalam pratinjau publik pada halaman yang diperiksa untuk artikel ini. Detail dukungan model, paket, dan billing dapat berubah. Jangan menulis klaim harga atau ketersediaan yang tidak kamu verifikasi pada saat pembaca membacanya.

Apa pun alatnya, aturan kerjanya sama. Akses minimum, perubahan bertahap, diff terbaca, tes nyata, dan keputusan akhir di tangan manusia. Agen yang bisa menjalankan perintah bukan alasan untuk memberinya akses root atau kredensial produksi.

Checklist sebelum menerima hasil AI

Sebelum merge patch, jawab pertanyaan berikut dalam catatan pull request:

1. Bug dapat direproduksi sebelum perubahan dengan perintah yang jelas?
2. Tes baru gagal pada kondisi lama atau hanya lulus setelah ditulis?
3. Patch memperbaiki penyebab, bukan sekadar menyembunyikan error?
4. Kontrak API, tipe data, dan perilaku valid tetap sama?
5. Ada kasus batas yang belum diputuskan?
6. Tes unit, integration, atau smoke test mana yang sudah dijalankan?
7. Apakah output perintah benar-benar diperoleh dari lingkungan yang sesuai?
8. Apakah perubahan menyentuh data, keamanan, billing, atau izin akses?
9. Apakah ada secret, alamat internal, atau data pribadi di diff dan log?
10. Apakah reviewer lain bisa memahami alasan perubahan tanpa membaca percakapan dengan AI?

Jangan mengisi jawaban dengan “AI sudah memeriksa”. Nama alat bukan bukti pemeriksaan. Tempel perintah dan hasil ringkas yang memang kamu lihat. Bila belum dijalankan, tulis “belum dijalankan”. Kalimat itu lebih sehat daripada status palsu.

Contoh alur satu bug sampai selesai

Bayangkan endpoint /cart/total mengembalikan nilai negatif ketika kode voucher lebih besar daripada subtotal. Langkah pertama adalah membuat request lokal dengan data minimal dan menyimpan respons aktual. Langkah kedua, jalankan unit test yang paling dekat dengan kalkulasi. Langkah ketiga, minta AI menjelaskan jalur nilai tanpa patch.

Setelah aturan bisnis dikonfirmasi, tambahkan regression test yang menggambarkan diskon besar. Pastikan tes gagal sebelum perubahan. Ubah fungsi dengan patch kecil. Jalankan unit test, lalu tes endpoint yang memanggil fungsi tersebut. Jika hasilnya lulus, periksa diff dan kasus diskon nol. Jangan melebar ke refactoring keranjang pada pull request yang sama.

Kamu juga perlu memikirkan tipe uang. Jika proyek memakai integer dalam satuan rupiah terkecil, contoh 15000 cukup. Jika memakai floating point atau desimal, aturan pembulatan harus tertulis. AI mungkin mengusulkan round() karena itu lazim, tetapi pembulatan harga adalah keputusan domain, bukan kosmetik kode.

Di titik ini, AI sudah membantu membuat diagnosis, test case, dan patch. Ia belum memutuskan aturan bisnis, belum membuktikan semua jalur, dan belum menggantikan review. Pembagian kerja itu justru membuat alatnya berguna.

Catatan kerja untuk tim kecil

Tim kecil sering tidak punya reviewer khusus untuk setiap pull request. Di situ catatan kerja menjadi penting. Simpan prompt yang menghasilkan diagnosis, hash atau nama commit yang diperiksa, perintah tes, dan keputusan yang diambil. Jangan menyimpan token sesi atau potongan source yang mengandung rahasia. Catatan ini bukan arsip obrolan panjang. Cukup bahan yang membuat orang lain bisa mengulang pemeriksaan.

Minta AI menulis ringkasan perubahan dalam tiga bagian, yaitu masalah, bukti, dan dampak. Kalau bagian bukti kosong, berarti diagnosis belum selesai. Kalau dampak hanya berbunyi “kode lebih baik”, minta penjelasan yang dapat diuji. Misalnya, “request dengan kupon lebih besar daripada subtotal kini menghasilkan nol dan tes regression menangkap kasus tersebut.” Kalimat itu bisa diverifikasi.

Atur kebiasaan review sesuai risiko. Perubahan format teks biasa mungkin cukup dengan satu reviewer. Kode yang menyentuh autentikasi, pembayaran, penghapusan data, atau izin file perlu pemeriksaan lebih ketat. Jangan membiarkan kecepatan asisten menentukan tingkat pengawasan. Kode pendek tetap bisa punya akibat panjang.

Satu kebiasaan kecil cukup membantu: setelah patch lulus, ubah satu input secara manual dan lihat apakah tes gagal ketika aturan sengaja dilanggar. Ini bukan pengganti suite, tetapi cara cepat untuk menemukan assertion yang terlalu longgar. Kalau tes tetap lulus setelah kamu merusak perilaku yang diuji, perbaiki tesnya dulu.

Artikel terkait

Kalau kamu masih memilih alat, baca perbandingan paket asisten pemrograman 2026. Untuk kerja rutin, baca AI tools untuk produktivitas. Pembaca yang ingin memahami dasar layanan AI dapat mulai dari OpenAI Academy dan materi belajar gratis.

Sumber resmi

1. GitHub Docs, Writing tests with GitHub Copilot
2. GitHub Docs, OpenAI Codex
3. OpenAI Codex documentation
4. Python unittest documentation

Fitur layanan AI dan dokumentasi produk bisa berubah. Periksa halaman resmi sebelum memilih paket, mengaktifkan akses repositori, atau memberi izin menjalankan perintah. Contoh di artikel ini memakai data fiktif dan bukan panduan untuk mengakses infrastruktur milik orang lain.

Kalau tes baru lulus, pekerjaan belum selesai. Buka diff-nya, baca assertion-nya, lalu jalankan lagi perintah yang menjadi dasar klaim perbaikan. Di situlah debugging berhenti menjadi tebak-tebakan.