Di komik tadi, kita meminta AI memperbaiki bug diskon. Permintaannya cukup pendek, akan tetapi untuk mengecek hasilnya kita perlu tahu kapan promo berakhir, kapan customer mendapat harga diskon, dan apakah perubahan kode tadi ikut mengubah tagihan pada invoice yang sudah dibuat.
Saya ingin membahas pekerjaan engineer dari contoh kecil ini. Diskusinya kita batasi pada aplikasi yang sudah dipakai customer, dengan anggapan aturan bisnisnya sudah ada. Sehingga setiap perubahan perlu mengikuti aturan tersebut, termasuk ketika kita memakai AI untuk menulis kodenya.
Semua test sudah lolos, kenapa belum selesai?
Pada 3 panel pertama, awalnya ada 23 test dan 1 di antaranya gagal. Setelah AI bekerja, semua test lolos. Akan tetapi, jumlahnya tinggal 22 karena test yang gagal tadi dihapus.
Test adalah pemeriksaan otomatis untuk membandingkan hasil kode dengan hasil yang seharusnya. Sebagai contoh, kita memasukkan invoice tanpa diskon dan mengecek apakah harga barangnya tetap Rp200.000.*
Bug diskonnya sendiri belum diperbaiki. Kalau perubahan ini langsung dipakai, customer masih mendapat diskon setelah promo berakhir. Kita hanya tidak lagi menjalankan test yang bisa menemukan kesalahan tersebut.
Sehingga saat membaca hasil pekerjaan AI, kita juga perlu membaca perubahan kodenya. Test apa yang dihapus? Kenapa dihapus? Apakah kasus yang ingin kita perbaiki masih dicek? Laporan bahwa semua test lolos belum cukup untuk menjawab pertanyaan tadi.
Adegan menghapus test ini sengaja dibuat sederhana untuk ilustrasi. Dalam pekerjaan sehari-hari, kesalahannya bisa lebih susah ditemukan, misalnya kode dan test sama-sama memakai aturan diskon yang keliru. Kita bahas dulu aturan diskonnya agar lebih jelas.
Customer membayar setelah promo berakhir, masih dapat diskon?
Anggap saja harga barang Rp200.000 dan ada promo diskon 10%. Harga setelah diskon menjadi Rp200.000 dikurangi Rp20.000 = Rp180.000 (belum termasuk ongkir). Promo berakhir pukul 00.00 waktu Jakarta.
Kalau customer membayar pukul 00.05, apakah kita menagih Rp180.000 atau Rp200.000?
Untuk menjawabnya, kita perlu tahu kapan harga pada invoice ditetapkan. Di panel 4 dan 5, tim memakai aturan bahwa harga mengikuti waktu invoice dibuat. Selama batas waktu pembayaran invoice belum lewat, customer tetap bisa membayar sesuai harga pada invoice.
Sebagai contoh, customer A membuat invoice pukul 23.59. Saat itu promo masih berlaku, sehingga harga barang pada invoice-nya Rp180.000. Walaupun baru dibayar pukul 00.05, harganya tetap Rp180.000.
Customer B baru membuat invoice pukul 00.05. Promo sudah berakhir, sehingga harga barangnya Rp200.000. Kedua customer bisa membayar pada waktu yang sama dengan harga berbeda, karena invoice mereka dibuat pada waktu berbeda.
Nah, pada panel 6 dan 7, AI sudah memperbaiki kode dan menjalankan test. Akan tetapi, setelah dibaca, ternyata kodenya masih memakai waktu pembayaran. Customer A yang seharusnya membayar Rp180.000 akan ikut ditagih Rp200.000.
Perbaikan tadi mungkin sudah membuat customer B membayar harga normal, sesuai aturan promo. Akan tetapi, sekarang muncul masalah pada customer A. Kalau kita hanya menjalankan test untuk invoice yang dibuat dan dibayar sebelum promo berakhir, kasus customer A tidak ikut dicek.
Kita perlu menambahkan contoh seperti customer A ke dalam test: invoice dibuat sebelum promo berakhir, lalu dibayar setelahnya, dan harga barang tetap Rp180.000. AI bisa membantu menulis test tersebut. Engineer yang mengecek hasilnya tetap perlu memahami kenapa angka yang benar Rp180.000, agar bisa mengetahui kalau kode atau test-nya salah.
Apakah aturan ini harus dijelaskan setiap kali memakai AI?
Sampai di sini kita sudah menjelaskan waktu promo, waktu pembuatan invoice, dan contoh 2 customer tadi. Kalau penjelasannya hanya ada di chat, saat mengerjakan tugas lain kita mungkin perlu menjelaskannya lagi.
Di panel 8, aturan tersebut disimpan di project bersama contoh invoice dan referensi file kode. Sehingga ketika mendapat tugas terkait invoice, agent bisa membaca aturan dan contoh yang sama.
Agent di sini adalah AI yang diberi akses untuk membaca file project, mengubah kode, dan menjalankan test.*
File catatannya tidak perlu panjang. Untuk contoh ini, kita perlu menulis bahwa harga mengikuti waktu invoice dibuat, batas waktu promo mengikuti waktu Jakarta, dan invoice yang sudah dibuat tetap mendapat harga tersebut sampai batas waktu pembayaran. Lalu kita tambahkan contoh customer A dan B, beserta referensi file kode untuk perhitungan harga invoice.
Akan tetapi, kita juga perlu mengecek apakah agent memang membaca file itu. Menaruh catatan di project saja belum cukup. Kita perlu mengatur agent yang dipakai tim agar membaca catatan tersebut saat mengerjakan tugas terkait invoice.
Kalau aturan bisnisnya berubah, catatan dan contoh tadi juga perlu diadjust. Misalnya tim memutuskan harga baru ditetapkan saat pembayaran. Test untuk customer A sekarang perlu diubah karena hasil yang benar sudah berbeda. Kalau hanya kode yang diubah, agent pada tugas berikutnya bisa memakai catatan lama dan memakai kembali perhitungan lama yang sudah tidak sesuai.
Menurut saya, pekerjaan menyiapkan konteks seperti ini perlu ikut dihitung saat kita membahas penggunaan AI oleh engineer. Kita perlu memilih informasi yang terkait dengan tugasnya, menulis contoh yang jelas, dan memperbaruinya ketika aturan berubah. Hasilnya bisa dipakai lagi, sehingga kita tidak perlu menjelaskan semuanya dari awal pada setiap tugas.
Kalau sudah ada instruksi jangan hapus test, cukup?
Pada panel 9, tim menambahkan instruksi agar test tidak dihapus tanpa review. Akan tetapi, test juga bisa diubah isinya.
Anggap saja test untuk customer B seharusnya mengecek harga Rp200.000. Kodenya masih salah dan menghasilkan Rp180.000. Kalau angka di dalam test ikut diubah menjadi Rp180.000, test akan lolos walaupun customer B masih mendapat diskon yang seharusnya sudah berakhir.
Jumlah test-nya tidak berkurang. Sehingga kita perlu membaca perubahan pada test juga, termasuk angka yang dipakai sebagai hasil yang benar. Test memang boleh berubah saat aturan bisnis berubah, seperti contoh waktu pembayaran tadi. Kita perlu tahu alasan perubahannya.
Di panel 10, tim juga membuat test invoice wajib lolos sebelum perubahan kode bisa digabungkan ke kode utama. Agent tidak diberi akses untuk mematikan pemeriksaan tersebut. Kalau test gagal, perubahan belum bisa digabungkan.
Pengaturan akses ini tetap perlu disertai review. Agent masih bisa mengusulkan perubahan isi test, sehingga tim perlu mengecek usulannya sebelum menerima perubahan kode. Kalau harga yang dipakai test sudah salah, menjalankannya berkali-kali tetap tidak akan membantu kita menemukan bug diskon tadi.
Setelah perbaikan selesai, kita simpan test untuk kedua customer tersebut. Customer A tetap membayar harga diskon, customer B membayar harga normal. Test ini ikut dijalankan saat ada perubahan berikutnya.
Kenapa perubahan ongkir malah membuat test diskon gagal?
Pada panel 11 dan 12, tugas berikutnya adalah mengubah ongkir. Ternyata perubahan tersebut ikut mengubah harga barang, sehingga test diskon gagal.
Kita pakai contoh order yang masih mendapat harga promo Rp180.000. Anggap saja ongkir sebelumnya Rp10.000, sehingga total invoice Rp190.000. Kalau ongkir berubah menjadi Rp15.000, totalnya seharusnya Rp180.000 + Rp15.000 = Rp195.000.
Akan tetapi, kalau perubahan kode tadi ikut menghilangkan diskon, harga barang kembali menjadi Rp200.000. Ditambah ongkir Rp15.000, totalnya Rp215.000. Tagihannya menjadi Rp20.000 lebih tinggi dari yang seharusnya, walaupun permintaan awalnya hanya mengubah ongkir.
Kesalahan seperti ini disebut regresi: bagian aplikasi yang sebelumnya sudah benar menjadi bermasalah setelah ada perubahan lain.*
Engineer kemudian membaca aturan invoice dan fungsi yang berubah untuk mencari kenapa diskonnya ikut hilang. Bisa saja perhitungan ongkir dan harga barang memakai fungsi yang sama. Kita perlu membaca kode untuk mengecek hubungan itu sebelum memilih bagian yang harus diperbaiki.
Di sini kita beberapa kali membaca aturan bisnis dan kode secara bergantian. Saat membaca kode, kita perlu tahu harga yang benar untuk customer A dan B. Saat membaca aturan bisnis, kita perlu tahu fungsi mana yang menghitung harga tersebut. AI boleh menulis perubahan kodenya, akan tetapi kita tetap perlu memahami hubungan keduanya agar bisa mengecek hasilnya.
Setelah diperbaiki, kita jalankan kembali test invoice lama dan test ongkir yang baru. Untuk order tadi, harga barang tetap Rp180.000, ongkir Rp15.000, dan totalnya Rp195.000. Kasus ini kemudian disimpan sebagai test untuk perubahan berikutnya.