Panduan

Cara Meninjau Kode yang Dibuat AI

Untuk meninjau kode buatan AI, mulailah dari apa yang berubah: file mana dan kenapa, lalu uji perilakunya sendiri sebelum membaca baris kode apa pun. Setelah itu, periksa area tempat kode AI paling sering salah: tidak ada cek izin di sisi server, secret yang terbuka ke browser, input yang tidak divalidasi, paket atau fungsi yang tidak ada, dan perubahan pada hal-hal yang tidak pernah Anda minta untuk disentuh.

AI menulis kode yang biasanya berjalan dan sering terlihat rapi. Itu membuatnya mudah disetujui tanpa benar-benar memeriksa. Panduan ini adalah rutinitas tinjauan yang bisa dipakai, baik Anda membaca kode dengan lancar maupun sama sekali tidak.

Sesuaikan tinjauan dengan risikonya

Tidak setiap perubahan butuh perhatian yang sama.

PerubahanTinjauan
Teks, warna, tata letakLihat di preview, baik di desktop maupun ukuran ponsel
Halaman atau fitur baruUji alurnya; lihat sekilas file yang berubah
Login, izin, pembayaran, data pribadiBaca dengan teliti, uji sungguhan, pertimbangkan orang kedua untuk meninjau
Struktur database, penghapusan data, migrasiBaca perubahannya, uji di salinan, buat backup dulu

Langkah 1: Lihat apa yang berubah

Sebelum menilai kodenya, dapatkan daftar perubahan:

  • Jika proyek ada di Git, lihat diff: file dan baris yang berubah sejak commit terakhir. Lihat cara memakai Git dengan aplikasi yang dibuat AI.
  • Atau tanyakan langsung ke AI:

Daftarkan setiap file yang kamu ubah pada perubahan terakhir, dan untuk setiap file jelaskan dalam satu kalimat apa yang berubah dan kenapa.

Tanda bahaya di tahap ini: file yang tidak berhubungan dengan permintaan, file yang dihapus, atau perubahan pada konfigurasi atau dependensi yang tidak Anda minta.

Langkah 2: Uji perilakunya dulu

Membaca kode memberi tahu apa yang seharusnya dilakukannya; menguji memberi tahu apa yang sebenarnya dilakukannya. Sebelum membaca:

  • Coba perubahan itu sebagai pengguna biasa, di desktop dan di layar ukuran ponsel.
  • Coba dengan input yang salah: kolom kosong, teks yang sangat panjang, angka negatif, tanggal di masa lalu.
  • Coba saat sudah logout, dan sebagai pengguna yang berbeda.
  • Jalankan ulang alur yang paling penting: daftar, login, tindakan utama, pembayaran.

Jika pengujian gagal, Anda sudah menghemat waktu membaca kode. Laporkan dengan jelas dan biarkan AI memperbaikinya. Lihat cara menulis laporan bug yang baik.

Langkah 3: Periksa izin di server

Ini hal paling penting untuk diperiksa. Alat AI sering menyembunyikan tombol di halaman, tetapi membiarkan server tetap mau melakukan tindakan itu untuk siapa pun yang memintanya.

Untuk setiap route atau fungsi yang membaca atau mengubah data, tanyakan:

  • Apakah ia memeriksa bahwa pengguna sudah login?
  • Apakah ia memeriksa bahwa pengguna ini boleh mengakses record ini?
  • Apakah pemeriksaan itu ada di server, bukan hanya di halaman?

Untuk setiap route API yang kamu tambahkan atau ubah, jelaskan cek izin apa yang dilakukannya di server, dengan mengutip baris kodenya. Tandai setiap route yang tidak punya cek.

Lalu uji: login sebagai pengguna A, catat ID sebuah record, login sebagai pengguna B dan minta record tersebut. Daftar periksa keamanan untuk aplikasi yang dibuat AI memuat pengujian lengkapnya.

Langkah 4: Cari secret yang terbuka

  • Cari di file yang berubah apa pun yang terlihat seperti key atau password.
  • Pastikan secret key dibaca dari environment variable dan hanya dipakai di kode server.
  • Waspadai prefix publik seperti VITE_ atau NEXT_PUBLIC_ pada variabel secret, karena itu ikut dibangun ke kode browser.

Lihat cara menjaga API key tetap aman.

Langkah 5: Periksa input dan error

  • Validasi di server. Pemeriksaan di browser bisa dilewati. Kolom wajib, panjang, format, dan nilai yang diizinkan juga harus diperiksa oleh server.
  • Query database memakai parameter, bukan teks yang dibuat dengan menggabungkan input pengguna ke dalam query.
  • Error tidak diabaikan. try/catch yang tidak melakukan apa-apa menyembunyikan kegagalan. Error harus dicatat, dan pengguna cukup melihat pesan yang sederhana.
  • Detail internal tidak ditampilkan ke pengguna: stack trace dan error database termasuk ke log.

Langkah 6: Pastikan semuanya nyata

Model AI kadang menghasilkan kode yang terlihat benar tetapi merujuk hal-hal yang tidak ada.

  • Paket: setiap dependensi baru harus berupa paket nyata yang dipelihara, dengan nama yang persis itu. Waspadai nama yang terlihat seperti salah ketik dari paket populer.
  • Fungsi dan opsi API: jika kode memanggil fungsi library atau opsi API eksternal yang belum pernah Anda lihat, periksa dokumentasi resminya.
  • Kode placeholder: cari TODO, mock, fake, data contoh yang di-hardcode, atau fungsi yang mengembalikan nilai tetap.

Apakah kamu menambahkan paket baru? Untuk setiap paket, berikan nama persisnya, untuk apa paket itu, dan apakah kita bisa tidak memakainya.

Langkah 7: Pastikan sesuai dengan tempatnya

Kode bisa berfungsi dan tetap membuat aplikasi lebih sulit diubah nanti:

  • Duplikasi. Logika yang disalin ke beberapa tempat akan saling menjauh.
  • Konsistensi. Kode harus mengikuti pola yang dipakai aplikasi lainnya.
  • Ukuran. Permintaan 20 baris yang menghasilkan 600 baris layak dipertanyakan.
  • Kode mati. Versi lama yang tertinggal di samping versi baru.

Apakah ada kode di proyek yang sekarang tidak terpakai karena perubahan ini, atau logika yang diduplikasi di tempat lain? Jangan ubah apa pun; cukup daftarkan.

Kesalahan umum

  • Menyetujui karena terlihat rapi. Kode yang rapi tetap bisa melewatkan cek izin.
  • Membaca alih-alih menguji. Uji dulu; baca kemudian.
  • Hanya menguji jalur yang normal. Coba input buruk, pengguna yang salah, dan kondisi logout.
  • Mengabaikan perubahan file yang tidak berhubungan. Tanyakan kenapa setiap file berubah.
  • Mempercayai tinjauan mandiri AI sepenuhnya. Gunakan tinjauan AI sebagai tahap awal dan konfirmasi dengan pengujian.
  • Meninjau seminggu perubahan sekaligus. Tinjau perubahan kecil saat terjadi.

Daftar periksa

  • Saya tahu file mana yang berubah dan kenapa, dan tidak ada yang tidak berhubungan ikut berubah.
  • Perubahan berfungsi di desktop dan ponsel, dengan input buruk, saat logout, dan sebagai pengguna lain.
  • Setiap route data memeriksa login dan kepemilikan di server.
  • Tidak ada secret di kode atau bundle browser.
  • Input divalidasi di server; query memakai parameter.
  • Error dicatat, tidak diabaikan, dan tidak ditampilkan secara detail kepada pengguna.
  • Paket baru itu nyata dan diperlukan; tidak ada fungsi karangan atau placeholder yang tersisa.
  • Perubahan berisiko tinggi sudah dibaca dengan teliti dan, jika perlu, ditinjau oleh orang kedua.

Meninjau kode di Mythex

  • Mode Ask menjawab pertanyaan tentang kode tanpa mengeditnya, ideal untuk permintaan seperti “jelaskan setiap perubahan” dan “route mana yang tidak punya cek izin”. Lihat Chat.
  • Tampilan kode menampilkan pohon file, editor, dan terminal di setiap paket (hanya baca di Free, bisa diedit di Pro), sehingga Anda bisa membaca sendiri apa yang berubah. Lihat Code editor.
  • /test meminta agent mengklik preview sebagai pengguna dan melaporkan alur yang rusak.
  • Checkpoint memungkinkan Anda membatalkan perubahan yang gagal tinjauan.

Jika developer yang meninjau untukmu, cara bekerja dengan developer pada aplikasi yang dibuat AI membahas serah terimanya; jika tinjauan menemukan bug, lihat cara men-debug aplikasi yang dibuat AI.

Pertanyaan

Bisakah saya meninjau kode buatan AI jika saya bukan developer?

Anda bisa meninjau banyak hal. Periksa bahwa perubahan melakukan apa yang Anda minta, uji alur-alur penting, coba akses data pengguna lain, dan minta AI menjelaskan setiap file yang berubah dengan bahasa sederhana. Untuk pembayaran, data sensitif, atau keamanan, minta developer ikut memeriksa.

Apa masalah paling umum dalam kode buatan AI?

Tidak ada cek izin di sisi server, secret yang ditaruh di tempat yang bisa dibaca browser, input yang tidak divalidasi di server, paket atau fungsi yang sebenarnya tidak ada, error yang diabaikan diam-diam, dan perubahan pada file yang tidak Anda minta.

Bisakah saya meminta AI meninjau kodenya sendiri?

Bisa, dan sering kali ia menemukan masalah nyata, terutama jika Anda mengajukan pertanyaan spesifik, misalnya route mana yang tidak punya cek izin. Anggap ini sebagai tinjauan awal, bukan jaminan, dan konfirmasi temuannya dengan pengujian.

Berapa lama seharusnya sebuah tinjauan kode?

Sesuaikan dengan risikonya. Perubahan teks atau gaya cukup dilihat sekilas di preview. Perubahan pada login, pembayaran, izin, atau database layak dibaca dengan teliti, diuji sungguhan, dan mungkin ditinjau oleh orang kedua.

Mythex · Pricing · Bangun apa pun dengan AI · Template website dan aplikasi · Mythex dibandingkan · Glosarium membuat aplikasi dengan AI · Alat gratis untuk membuat aplikasi dengan AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)