Seorang pengembang meminta asistennya untuk membuat fungsi yang memeriksa apakah pengguna dapat mengunduh laporan. Kode berhasil dikompilasi. Tes skenario berhasil. Permintaan perubahan (pull request) terlihat rapi. Dua minggu kemudian, seorang kolega menyadari bahwa fungsi tersebut hanya memeriksa apakah pengguna sudah masuk (login), tetapi tidak pernah memeriksa apakah laporan tersebut milik pengguna tersebut.
Ini adalah skenario ilustratif, bukan insiden yang terdokumentasi. Ini menggambarkan kesenjangan yang harus ditutup oleh pelatihan peninjauan kode yang dihasilkan AI: kode yang dihasilkan yang lolos pemeriksaan dasar masih dapat mengandung kesalahan otorisasi atau konkurensi, dan orang yang meninjaunya perlu menemukannya dan menjelaskan mengapa hal itu penting.
Panduan ini ditujukan untuk pimpinan pemberdayaan teknik dan manajer teknik. Panduan ini mencakup cara mendeskripsikan masalah kinerja, mendiagnosis kesenjangan, merancang persiapan dan praktik, mengerjakan studi kasus, dan menilai apakah keterampilan tersebut dapat diterapkan pada tinjauan nyata. Ini tentang desain pelatihan. Setiap cacat, pengujian, dan aturan tinjauan dalam program Anda harus divalidasi oleh insinyur senior dan tim keamanan Anda.
Apa itu pelatihan peninjauan kode yang dihasilkan AI?
Pelatihan peninjauan kode yang dihasilkan AI mengajarkan pengembang untuk memberi arahan yang jelas kepada asisten, kemudian mengevaluasi dan mengaudit apa yang dikembalikan: apakah benar, apakah aman, apakah berfungsi dengan baik di bawah beban konkuren, apakah cukup efisien? Ini bukan kursus tentang alat tertentu. Ini melatih kebiasaan peninjauan yang tetap sama meskipun alatnya berubah.
fakta cepat
| Pertanyaan | Jawaban singkat |
|---|---|
| Apa tugasnya? | Lakukan audit terhadap kode yang dihasilkan dan buktikan setiap risiko dengan pengujian. |
| Berapa skor Anda? | Verifikasi kualitas dan apakah cacat yang relevan telah ditemukan. |
| Apakah kuis tentang aturan pengkodean yang aman sudah cukup? | Tidak. Ini mengkonfirmasi prasyarat, tetapi tidak mengkonfirmasi apakah seorang pengembang dapat menemukan kekurangan dalam kode yang tampak masuk akal. |
| Siapa yang memvalidasi kontennya? | Manajer teknik dan tim keamanan Anda. |
| Apa yang tidak bisa diperbaiki melalui pelatihan? | Waktu peninjauan, perangkat, kepemilikan yang tidak jelas, dan tekanan untuk melakukan merger dengan cepat. |
| Bagaimana Anda tahu itu berhasil? | Latihan penulisan kode baru yang belum pernah dilihat sebelumnya, dinilai berdasarkan kriteria yang disepakati, dengan tindak lanjut pada tinjauan nyata. |
1. Jelaskan masalah kinerja tersebut
Mulailah dengan tugas: audit kode yang dihasilkan dan buktikan risiko dengan pengujian. Audit adalah membaca dengan penuh kecurigaan. Pembuktian adalah mengubah kecurigaan menjadi bukti, biasanya berupa pengujian yang gagal atau reproduksi yang menunjukkan kekurangan tersebut.
Penelitian ini menunjukkan mengapa hal ini membutuhkan latihan yang disengaja. Dalam sebuah studi tentang GitHub Copilot, Pearce dan rekan-rekannya menghasilkan 1,689 program di 89 skenario yang dipilih berdasarkan jenis kelemahan yang diketahui dan menemukan bahwa sekitar 40 persen di antaranya rentan (Pearce dan kolega, 2021). Itu adalah alat awal dan serangkaian skenario spesifik, jadi jangan anggap angka tersebut sebagai tingkat keberhasilan asisten saat ini. Sebuah studi pengguna terpisah meminta peserta untuk menulis kode dengan dan tanpa asisten AI. Mereka yang menggunakan asisten menulis kode yang jauh kurang aman, dan lebih cenderung percaya bahwa kode mereka aman (Perry dan rekan-rekannya, 2023Studi yang sama menemukan bahwa peserta yang kurang mempercayai asisten dan lebih terlibat dengan petunjuk yang diberikan menghasilkan lebih sedikit kerentanan.
Berikut dua pelajaran penting untuk desain pelatihan. Hasil yang masuk akal membutuhkan peninjau aktif. Dan kepercayaan diri bukanlah bukti, jadi latihan tersebut harus meminta pengujian, bukan opini.
Tuliskan pernyataan kinerja dalam satu kalimat dan mintalah seorang manajer teknik untuk memeriksanya: "Berdasarkan perubahan yang dihasilkan, pengembang mencantumkan risiko keamanan, konkurensi, dan efisiensi yang mereka lihat, dan untuk setiap risiko tersebut, jelaskan atau tuliskan sebuah pengujian yang akan menunjukkannya."
2. Mendiagnosis kesenjangan pembelajaran dan konteks.
Sebelum Anda membuat apa pun, bandingkan tugas tersebut dengan apa yang dipraktikkan dan dinilai oleh program Anda saat ini. Tiga pertanyaan biasanya membedakan kesenjangan pelatihan dari hal lain:
- Apakah praktik saat ini menggunakan tugas yang sebenarnya? Jika pelatihan mencakup penulisan kode yang mudah dipahami tetapi tidak pernah meminta pengembang untuk meninjau hasilnya, berarti tidak ada yang mempraktikkan audit. Jika penilaian berupa tes pilihan ganda tentang aturan pengkodean yang aman, itu hanya mengukur daya ingat.
- Apa tuntutan kognitifnya? Dalam taksonomi Bloom yang telah direvisi, menilai apakah kode aman dan memilih pengujian yang membuktikannya berada pada tingkat analisis dan evaluasi, sedangkan merancang prompt yang lebih baik atau perbaikan mencapai tingkat kreasi. Aktivitas yang sesuai dengan tingkatan tersebut dibahas dalam panduan kami. Mencocokkan aktivitas pembelajaran dengan Taksonomi Bloom.
- Apakah ada hal lain selain keterampilan yang menjadi penghalang? Periksa waktu peninjauan, alat bantu, dan kepemilikan. Jika peninjau hanya memiliki lima menit per permintaan perubahan (pull request), tidak ada pelatihan yang akan menghasilkan audit. Jika tidak ada analisis statis atau kerangka pengujian dalam alur kerja, pengembang dapat menemukan risiko tetapi tidak dapat membuktikannya. Laporkan penyebab yang bukan hasil pelatihan kepada orang-orang yang dapat memperbaikinya.
3. Persiapan dan praktik desain
Setelah Anda mengetahui kesenjangan mana yang dapat ditutup oleh pelatihan, berikan tugas yang berbeda untuk setiap tahapannya.
Persiapan. Periksa prasyarat dengan diagnosis singkat: kategori kelemahan umum yang dihadapi tumpukan teknologi Anda, bagaimana struktur pengujian Anda, dan daftar periksa tinjauan yang digunakan tim Anda. Pembelajaran mandiri cocok untuk tahap ini. Pemeriksaan ingatan hanya mengkonfirmasi prasyarat.
Praktek. Gunakan latihan audit yang dibangun dari kode yang dihasilkan secara realistis. Sisipkan sejumlah kecil cacat dari berbagai jenis ke dalam setiap latihan, seperti kurangnya pengecekan kepemilikan, kondisi persaingan antara dua permintaan, dan perulangan yang tidak efisien, ditambah beberapa kode yang baik. Pengembang meninjau, menyebutkan setiap risiko, menyatakan seberapa seriusnya risiko tersebut, dan mengusulkan pengujian yang akan menunjukkannya. Mintalah alasan, bukan daftar nomor baris.
Umpan balik. Hubungkan dengan keputusan, bukan dengan skor total. "Anda menandai loop tetapi bukan race pada penghitung bersama, dan pengujian Anda tidak akan mendeteksinya karena menjalankan permintaan satu per satu" lebih bermanfaat daripada "2 dari 3 ditemukan".
Masukan langsung atau tinjauan asinkron? Masukan langsung paling bermanfaat ketika risiko bersifat ambigu dan pengembang belajar dari penjelasan insinyur senior tentang mengapa mereka akan memblokir penggabungan tersebut. Tinjauan asinkron sudah cukup untuk membandingkan temuan pengembang dengan tinjauan ahli yang diberi anotasi. Banyak tim menggunakan keduanya: persiapan mandiri terlebih dahulu, kemudian sesi terbimbing untuk kasus-kasus sulit.
4. Kerjakan contoh yang realistis.
Sebagai ilustrasi. Manajer teknik harus memvalidasi kasus dan kriteria jawaban sebelum digunakan.
Kasus. Endpoint yang dihasilkan mengembalikan faktur pelanggan berdasarkan ID faktur. Endpoint ini memeriksa apakah pemanggil memiliki sesi yang valid, menggunakan kueri berparameter, dan lolos uji dasar. Fungsi yang sama juga menambah penghitung unduhan bersama tanpa penguncian.
Tugas tersebut. Pengembang menyatakan setiap risiko yang mereka lihat, memberi peringkat pada risiko tersebut, dan menjelaskan pengujian yang akan membuktikan setiap risiko.
Upaya pertama. "Terlihat baik-baik saja. Kueri tersebut diparameterisasi dan pengujian berhasil." Pengembang telah menganggap keberhasilan pengujian sebagai bukti dan tidak menanyakan apa yang tidak dicakup oleh pengujian tersebut.
Berikan masukan dan coba lagi. Peninjau meminta pengembang untuk menyebutkan apa yang dibuktikan oleh pemeriksaan sesi dan apa yang tidak. Percobaan ulang meminta mereka untuk mempertimbangkan dua pelanggan berbeda dan dua permintaan simultan.
Upaya yang lebih baik. "Pemeriksaan sesi membuktikan siapa yang menelepon, bukan bahwa faktur tersebut milik mereka. Saya akan menulis tes di mana pelanggan A meminta ID faktur pelanggan B dan mengharapkan penolakan. Penghitung bertambah tanpa sinkronisasi, jadi dua permintaan sekaligus dapat kehilangan pembaruan. Saya akan menjalankan tes konkuren dan membandingkan jumlahnya. Kueri itu sendiri diparameterisasi, jadi saya tidak akan menghabiskan waktu di sana." Perhatikan bahwa jawaban ini memberi peringkat risiko dan mengaitkan masing-masing dengan sebuah tes.
Mengapa setiap respons dapat dipertahankan atau tidak lengkap. Nilailah setiap upaya berdasarkan kriteria yang telah disetujui, bukan berdasarkan preferensi penilai. Upaya pertama mengikuti kebiasaan tetapi mengabaikan bukti. Upaya yang lebih kuat bersifat spesifik, diprioritaskan, dan dapat diuji.
5. Menilai kemampuan dan merencanakan transfer
Bukti kemampuan adalah kinerja pada latihan baru yang belum pernah dilihat peserta didik. Verifikasi kualitas penilaian dan identifikasi kekurangan yang relevan. Rubrik sederhana menggunakan skala 0 hingga 2 per kriteria:
| Kriterium | Bukti yang dapat diamati |
|---|---|
| Eksekusi tugas | Mengaudit kode yang dihasilkan dan mencatat bukti di balik setiap temuan. |
| Pemikiran | Menjelaskan kendala, alternatif, dan hal-hal yang masih belum pasti, serta mengklasifikasikan risikonya. |
| Batas | Mengikuti aturan peninjauan tim dan meneruskan ke spesialis keamanan jika risikonya di luar wewenang mereka. |
Nilai acuan: 0 berarti tidak ada atau tidak didukung, 1 berarti sebagian dengan kekurangan yang relevan, dan 2 berarti lengkap dan dapat dibenarkan berdasarkan kriteria yang disepakati. Definisikan kesalahan kritis secara terpisah, seperti menyetujui kode dengan jalur akses yang tidak terlindungi, sehingga skor keseluruhan tidak dapat menyembunyikan satu kesalahan. Rubrik ini adalah usulan, bukan standar kesiapan yang telah divalidasi: sesuaikan dengan manajer teknik dan lakukan uji coba. Panduan kami untuk merancang praktik interaktif dengan umpan balik yang bermanfaat Menunjukkan cara menulis umpan balik yang terkait dengan keputusan.
Rencanakan transfer secara cermat. Setelah latihan, pasangkan setiap pengembang dengan permintaan pull request nyata yang mencakup kode yang dihasilkan dan tinjau temuan mereka bersama-sama, atau jalankan retrospektif singkat pada tinjauan terbaru yang melewatkan sesuatu.
Di mana penyampaian interaktif membantu
Format interaktif membantu ketika setiap orang harus berkomitmen sebelum melihat kelompok. Dalam sesi langsung, fasilitator dapat menunjukkan cuplikan yang dihasilkan, meminta setiap pengembang untuk mengetik risiko yang mereka lihat dan pengujian yang akan mereka tulis, lalu mengungkapkan hasilnya sebelum diskusi. Latihan yang sama dapat dilakukan secara mandiri untuk persiapan. AhaSlides mendukung pembelajaran interaktif dan perpindahan antara penyampaian langsung dan mandiri. Ini adalah alat presentasi dan pembelajaran, bukan tempat untuk menjalankan kode, jadi jalankan latihan kode di lingkungan Anda sendiri. Periksa fungsi penulisan, umpan balik, atau pelaporan khusus yang Anda rencanakan untuk diandalkan terhadap alur kerja Anda sendiri. Untuk panduan tentang pemilihan format, lihat artikel kami tentang Kapan menggunakan pembelajaran adaptif, interaktif, dan langsung?.
Ukur apa yang berubah.
Tentukan terlebih dahulu apa yang akan menunjukkan bahwa pengembang mampu melakukan tugas tersebut. Bandingkan kualitas verifikasi dan identifikasi cacat pada latihan yang belum pernah dilihat sebelumnya dengan acuan dasar. Tentukan siapa yang dilibatkan, penyebut, dan waktunya. Jika hasilnya membaik, periksa apa lagi yang berubah dalam periode yang sama, seperti aturan analisis statis baru, daftar periksa tinjauan yang direvisi, atau perubahan asisten, sebelum memberikan kredit untuk pelatihan tersebut.
Kendala yang mungkin masih ada
- Waktunya ulasan. Audit membutuhkan waktu lebih lama daripada pemeriksaan sekilas, dan tenggat waktu semakin mendekati waktu pemeriksaan sekilas.
- Perkakas. Tanpa alat uji atau pemindaian dalam proses produksi, risiko sulit dibuktikan.
- Mengganti alat. Asisten bisa berubah dengan cepat, jadi teruslah berlatih tentang kebiasaan meninjau produk, bukan hanya satu produk.
- Liputan kasus. Satu latihan menunjukkan beberapa jenis cacat. Skor tidak menggambarkan penilaian pengembang secara umum.
- Transfer. Kinerja dalam lokakarya tidak sama dengan kinerja pada antrian peninjauan yang sibuk.
Sebutkan hal-hal ini kepada sponsor sejak dini dan rencanakan perbaikan secara terpisah. Pelatihan meningkatkan kemampuan pengembang dalam menemukan dan membuktikan sesuatu. Namun, pelatihan tidak menciptakan waktu atau alat yang dibutuhkan.
Pertanyaan yang sering diajukan
Apa itu pelatihan peninjauan kode yang dihasilkan AI?
Platform ini mengajarkan pengembang untuk memberikan petunjuk, mengevaluasi, dan mengaudit kode yang dihasilkan oleh asisten AI, menemukan masalah keamanan, konkurensi, dan efisiensi, serta mendukung setiap masalah tersebut dengan pengujian.
Apakah kode yang dihasilkan secara otomatis kurang aman dibandingkan kode yang ditulis manusia?
Studi menunjukkan adanya risiko, tetapi hasilnya bergantung pada alat, tugas, dan desain studi. Sebuah studi pengguna menemukan bahwa peserta yang dibantu asisten menulis kode yang kurang aman dan merasa lebih percaya diri, yang merupakan alasan untuk melatih kebiasaan peninjauan.
Bagaimana Anda menilai apakah pengembang dapat mengaudit kode yang dihasilkan?
Berikan latihan kode baru dan beri nilai kualitas verifikasi serta identifikasi cacat berdasarkan kriteria yang disepakati. Kuis tentang aturan pengkodean yang aman hanya mengkonfirmasi prasyarat.
Apakah Anda memerlukan lingkungan sandbox kode untuk pelatihan?
Anda membutuhkan tempat untuk menjalankan latihan, yang biasanya adalah lingkungan Anda sendiri. Periksa apakah alat apa pun yang Anda gunakan mendukung kebutuhan Anda sebelum Anda mengandalkannya.
Mulai dari mana
Pilih satu jenis perubahan berulang yang dihasilkan dalam basis kode Anda. Tulis pernyataan kinerja, minta manajer teknik untuk memvalidasi cacat yang telah ditentukan dan pengujian yang akan menunjukkannya, dan susun rubrik tiga kriteria dengan skala 0 hingga 2 dan daftar kesalahan kritis. Uji coba dengan kelompok kecil sebelum Anda meluncurkannya.
Untuk melihat bagaimana latihan audit dapat dijalankan secara langsung dengan tim Anda sendiri, dan digunakan kembali secara mandiri setelahnya, jelajahi AhaSlides.
