21.4 Implementasi Terbatas: Kapan AI Boleh Menulis Kode dan Kapan Tidak

Setelah desain dipilih, tibalah saatnya menulis kode. Namun, implementasi dengan AI perlu scope yang jelas agar hasilnya bisa dipertanggungjawabkan.

Bayangkan Anda baru saja menyelesaikan eksplorasi desain untuk modul pembayaran. Anda sudah memutuskan bahwa setiap metode pembayaran akan ditangani oleh adapter terpisah dengan antarmuka yang seragam. Sekarang Anda ingin AI menulis kode untuk adapter kartu kredit. Pertanyaan yang langsung muncul: seberapa banyak yang boleh diserahkan ke AI?

Jawabannya tergantung pada tiga faktor: risiko, kompleksitas, dan kejelasan scope.

Diagram berikut merangkum proses pengambilan keputusan berdasarkan tiga faktor tersebut.

flowchart TD A[Mulai menulis kode] --> B{Menyentuh data sensitif} B -- Ya --> C[Manusia pegang kendali penuh] B -- Tidak --> D{Kompleksitas rendah} D -- Tidak --> E[Manusia tulis kode] D -- Ya --> F{Scope jelas} F -- Tidak --> G[Perjelas scope dulu] F -- Ya --> H[AI menulis dengan review manusia]

Faktor pertama adalah risiko. Jika kode yang akan ditulis menyentuh data sensitif, alur transaksi keuangan, atau keputusan yang berdampak langsung pada pengguna, manusia harus memegang kendali. AI boleh menulis kode untuk bagian yang tidak kritis, tetapi setiap baris yang masuk ke production harus melalui review manusia yang ketat. Untuk modul pembayaran, misalnya, Anda bisa membiarkan AI menulis kode untuk validasi format nomor kartu, tetapi jangan biarkan AI menulis logika yang menentukan apakah transaksi disetujui atau ditolak.

Berikut contoh konkret yang membedakan kode aman untuk AI dan kode yang harus ditulis manusia.

// AMAN untuk AI: validasi format nomor kartu kredit
function isValidCardNumber(cardNumber: string): boolean {
  const sanitized = cardNumber.replace(/\s|-/g, '');
  if (!/^\d{13,19}$/.test(sanitized)) return false;

  // Algoritma Luhn
  let sum = 0;
  let alternate = false;
  for (let i = sanitized.length - 1; i >= 0; i--) {
    let digit = parseInt(sanitized[i], 10);
    if (alternate) {
      digit *= 2;
      if (digit > 9) digit -= 9;
    }
    sum += digit;
    alternate = !alternate;
  }
  return sum % 10 === 0;
}

// TIDAK BOLEH AI: logika persetujuan transaksi
function approveTransaction(cardNumber: string, amount: number): boolean {
  // Logika ini melibatkan data sensitif, saldo, risiko, dan keputusan finansial
  // HARUS ditulis dan direview manusia
  if (amount > dailyLimit) { /* ... */ }
  if (isBlacklisted(cardNumber)) { /* ... */ }
  // ...
}

Faktor kedua adalah kompleksitas. Kode yang sederhana dan repetitif adalah kandidat ideal untuk AI. Membuat fungsi CRUD standar, menulis unit test untuk kasus yang sudah jelas, atau menghasilkan kode boilerplate untuk adapter — semua ini bisa diserahkan ke AI dengan pengawasan minimal. Tetapi ketika logika mulai memiliki banyak cabang, kondisi tepi yang tidak terduga, atau ketergantungan pada state internal yang rumit, saatnya manusia mengambil alih. Tanda bahaya yang perlu diwaspadai: ketika Anda sendiri tidak bisa menjelaskan alur logika dalam satu atau dua paragraf, jangan harap AI bisa melakukannya dengan benar.

Faktor ketiga adalah kejelasan scope. Ini adalah kunci dari implementasi terbatas. Sebelum meminta AI menulis kode, Anda harus menentukan batas yang tegas: fungsi apa yang ditulis, input dan output apa yang diharapkan, bagaimana kode ini terhubung dengan komponen lain, dan apa yang tidak boleh disentuh. Dalam brief untuk AI, Anda perlu menyebutkan secara eksplisit batasan ini. Misalnya: “Tulis fungsi validasi nomor kartu kredit yang menerima string dan mengembalikan boolean. Jangan menulis logika penyimpanan data, jangan memanggil API eksternal, dan jangan mengubah state global.”

Di sinilah konsep human takeover point menjadi penting. Anda perlu menentukan titik-titik dalam proses implementasi di mana manusia harus turun tangan. Misalnya: setelah AI menulis draf pertama, Anda melakukan review struktural. Setelah review, Anda menjalankan test dan melihat cakupannya. Jika ada bagian yang tidak sesuai dengan desain yang sudah diputuskan, Anda mengambil alih dan menulis ulang. Jangan biarkan AI memperbaiki kodenya sendiri tanpa batas — siklus “minta AI, review, minta perbaikan, review lagi” bisa berlangsung tanpa akhir jika tidak ada kriteria selesai yang jelas.

Praktik yang baik adalah menetapkan aturan tim: AI boleh menulis kode untuk komponen yang sudah memiliki desain jelas, test case yang sudah ditentukan, dan risiko rendah hingga menengah. Untuk komponen dengan risiko tinggi, AI hanya boleh digunakan sebagai alat bantu — misalnya untuk menulis draf awal atau menghasilkan kode pembanding — tetapi manusia yang menulis versi finalnya.

Yang perlu diingat: implementasi terbatas bukan tentang membatasi penggunaan AI, tetapi tentang memastikan bahwa setiap baris kode yang dihasilkan bisa dipertanggungjawabkan. Scope yang jelas, batas yang tegas, dan titik takeover yang diketahui adalah tiga hal yang membuat AI menjadi asisten yang produktif, bukan sumber masalah baru.

Setelah kode ditulis, langkah berikutnya adalah memastikan kualitasnya. Di sinilah AI bisa berperan sebagai pemeriksa kedua — membantu pengujian, review kode, dan dokumentasi. Tapi sekali lagi, manusia tetap menjadi penanggung jawab keputusan akhir.

AI as Capacity Expansion
AI as Capacity Expansion