17.3 Menentukan Area Kerja AI: Boleh, Perlu Persetujuan, atau Ditangani Manusia
Brief kerja sudah siap, tetapi sebelum meminta AI membuat kode, kita perlu menentukan area mana yang boleh disentuh AI. Ini adalah keputusan yang sering dilewati. Banyak engineer langsung memberikan brief ke AI tanpa batas yang jelas, lalu AI mengubah hal-hal yang seharusnya tidak berubah.
Bayangkan seorang arsitek yang memberikan brief untuk menambahkan fitur logging ke modul payment. AI menerima brief, lalu dengan inisiatif sendiri memperbaiki struktur database, mengubah nama tabel, dan merapikan kode di modul lain yang tidak terkait. Semua terlihat rapi, tetapi tim tidak menyadari bahwa perubahan itu melanggar kontrak integrasi dengan sistem legacy. Testing baru ketahuan seminggu kemudian, dan rollback menjadi rumit karena AI sudah mengubah terlalu banyak file.
Masalahnya bukan pada AI yang terlalu kreatif. Masalahnya pada brief yang tidak menentukan area kerja.
Setiap pekerjaan yang diberikan ke AI harus dibagi menjadi tiga zona. Zona pertama adalah area yang boleh dikerjakan AI langsung. Di sini AI bisa menghasilkan output dan langsung diintegrasikan tanpa review manusia, asalkan verification plan terpenuhi. Contohnya adalah refaktor kode yang hanya menyentuh satu fungsi internal, atau menghasilkan dokumentasi teknis dari kode yang sudah stabil. Zona ini biasanya mencakup pekerjaan yang dampaknya terisolasi, mudah diverifikasi secara otomatis, dan tidak mengubah kontrak antar modul.
Zona kedua adalah area yang perlu persetujuan manusia. Di sini AI boleh mengerjakan, tetapi outputnya harus direview oleh manusia sebelum masuk ke branch utama. Contohnya adalah perubahan API yang mempengaruhi konsumen lain, penambahan field di database yang sudah dipakai banyak modul, atau perubahan logic bisnis yang berkaitan dengan aturan compliance. Zona persetujuan membutuhkan evidence yang lebih ketat: tidak cukup hanya kode berjalan, tetapi harus ada bukti bahwa perubahan tidak memutus kontrak yang sudah ada.
Zona ketiga adalah area yang harus ditangani manusia. Ini adalah zona yang tidak boleh disentuh AI sama sekali, bahkan untuk sekadar saran. Contohnya adalah keputusan arsitektural yang berdampak lintas sistem, perubahan kebijakan keamanan, konfigurasi production, atau modul yang sedang dalam audit. Zona ini bersifat non-negotiable. Jika AI menghasilkan perubahan di zona ini, perubahan harus ditolak mentah-mentah tanpa review.
Penentuan tiga zona ini harus ditulis di dalam brief kerja. Jangan hanya disimpan di kepala arsitek. Tulis secara eksplisit: “AI boleh mengerjakan modul A dan B secara langsung. Modul C dan D perlu persetujuan. Modul E dan F tidak boleh disentuh.” Dengan cara ini, AI tidak akan mengubah hal di luar batas, dan tim tidak perlu membuang waktu mereview perubahan yang seharusnya tidak terjadi.
Berikut contoh konfigurasi YAML yang mendefinisikan tiga zona tersebut berdasarkan modul dan file.
# area-kerja-ai.yaml
zona:
allowed:
- "modul/logging/**"
- "modul/utils/internal/*"
needs-approval:
- "modul/payment/api/*"
- "modul/database/migrations/*"
forbidden:
- "config/production/*"
- "modul/security/**"
- "modul/audit/**"
Berikut diagram alur yang merangkum tiga zona tersebut beserta contoh keputusan di setiap zona.
Implikasinya untuk organisasi cukup besar. Tim perlu mendefinisikan zona-zona ini sebelum proyek dimulai, bukan saat review. Setiap modul, setiap API, setiap konfigurasi perlu diketahui statusnya: boleh AI langsung, perlu persetujuan, atau hanya manusia. Ini membutuhkan pemetaan yang rapi, tetapi hasilnya adalah kecepatan tanpa kehilangan kendali.
Brief kerja sudah memiliki boundary. Sekarang boundary itu perlu dipertegas dengan zona kerja. Setelah zona jelas, langkah berikutnya adalah bagaimana meminta AI tidak hanya menghasilkan satu jawaban, tetapi beberapa opsi yang bisa dibandingkan.