Halo teman-teman di #indonesia, beberapa minggu terakhir saya sempat ngobrol sama beberapa rekan developer di Jakarta yang sering ambil kerjaan sampingan jarak jauh — mulai dari bikin skrip backend, rapihin alur data, sampai nulis dokumentasi API. Hampir semuanya pernah ngalamin satu kejadian yang polanya mirip banget: waktu tugas baru disepakati di awal, deskripsi permintaannya cuma ditulis singkat tiga atau empat baris. Pas kita tanya apakah ada format khusus yang harus diikuti, jawabannya selalu terdengar santai, "bebas kok mas, yang penting jalan dan jelas." Tapi begitu hasil kerjaan diserahkan, tiba-tiba muncul daftar koreksi panjang soal hal-hal yang sejak awal sama sekali nggak pernah disebut. Kalau sudah begitu, mau debat juga percuma karena patokan tertulisnya memang nggak pernah dikunci sebelum pekerjaan dimulai.
Dari pengalaman itu saya makin sadar kalau masalah utama di kesepakatan kerja teknis sebenarnya jarang soal tempat penyimpanan dananya, melainkan soal urutan waktu perumusan kriteria serah-terimanya. Rekening bersama atau escrow biasa memang bisa menahan uang, tapi selama definisi tentang apa yang bikin sebuah hasil kerja dianggap selesai baru dikarang belakangan setelah berkas dikirim, posisi orang yang mengerjakan tetap saja rawan digantung.
Gara-gara penasaran sama desain sistem yang mencoba membalik urutan tersebut, belakangan ini saya nyempetin waktu buat ngulik mekanisme yang dipakai protokol Verdikta di jaringan Base (https://bounties.verdikta.org). Hal yang menurut saya paling menarik dari kacamata teknis justru aturan utamanya yang mengharuskan rubrik penilaian dipublikasikan lebih dulu ke IPFS dan diikat langsung ke kontrak pintar bersamaan saat dana dikunci di escrow Base. Di dalam dokumen rubrik itu sudah dipisah secara terbuka bagian mana yang jadi syarat gerbang wajib lulus, bagian mana yang merupakan kriteria kualitas dengan bobot persentase tertentu, serta berapa angka skor ambang batas supaya kiriman dianggap sah. Karena rubriknya sudah terikat di on-chain sejak awal, syarat penilaiannya nggak bisa lagi digeser-geser sepihak di tengah jalan.
Waktu saya pelajari bagaimana kiriman pekerjaan diperiksa di sana, prosesnya juga nggak diserahkan ke mood satu orang, melainkan dijalankan oleh panel juri AI independen yang terdiri dari beberapa model berbeda. Bukannya cuma mengeluarkan vonis lolos atau gagal tanpa penjelasan, setiap kriteria di dalam rubrik diberi skor angka masing-masing lengkap dengan catatan alasan evaluasinya yang tercatat terbuka dan bisa diaudit siapa saja. Jadi kalau sebuah kiriman belum tembus ambang batas, kita bisa lihat persis di kriteria mana nilainya kurang dan berapa poin selisihnya. Aturan pencairannya juga lugas: kiriman pertama yang skor gabungannya berhasil melewati ambang batas langsung otomatis menerima dana escrow dari kontrak pintar, sedangkan kalau sampai tenggat waktu habis belum ada yang lolos, dananya kembali utuh ke pembuat tugas. Dari sisi biaya, protokolnya sendiri nggak memotong komisi platform (0% biaya platform), dan pengirim hanya perlu menyiapkan biaya gas Base serta deposit kecil sekitar 0.00024 ETH untuk membiayai putaran evaluasi orakel.
Walaupun alur seperti ini terasa jauh lebih terukur, menurut saya kita tetap harus jujur melihat batasannya di lapangan. Panel model AI pada dasarnya cuma bisa memeriksa apa yang dikirim dalam bentuk berkas, kode sumber, teks, atau tangkapan layar digital yang bisa diakses lewat jaringan, sehingga pendekatan ini jelas nggak bisa dipakai kalau tugasnya menuntut pengecekan perangkat keras fisik di dunia nyata. Selain itu, titik krusialnya pindah ke ketelitian orang yang menyusun rubrik di awal: kalau kalimat kriterianya ditulis terlalu kabur atau bobotnya nggak seimbang, skor yang keluar dari model AI juga bakal ikut timpang walaupun seluruh prosesnya transparan, apalagi rubrik yang sudah terkunci di kontrak nggak bisa diedit lagi. Belum lagi sifat kontrak pintar yang kaku terhadap angka ambang batas, di mana hasil kerja yang sebenarnya sudah rapi tapi kurang satu poin saja dari syarat kelulusan tetap bakal ditolak otomatis tanpa ruang tawar-menawar.
Terlepas dari keterbatasan tadi, kebiasaan mengunci tolok ukur penilaian di depan dan membuka alasan skor per kriteria menurut saya jauh lebih sehat daripada penolakan sepihak dengan alasan "kurang cocok." Buat teman-teman developer di komunitas #indonesia yang sering garap proyek lepas atau ngulik smart contract, menurut kalian apakah rubrik yang dikunci kaku di awal seperti ini bikin kerjaan jadi lebih tenang, atau malah terasa terlalu membatasi ruang diskusi teknis?
