Metrik yang Salah

Kebanyakan percakapan tentang kualitas AI-generated code berfokus pada ketepatan saat generation. Apakah output-nya bisa di-compile? Apakah ia lolos tests? Apakah ia sesuai dengan spec?

Itu baru syarat dasar. Semua itu tidak memberi tahu Anda apa-apa tentang biaya yang sebenarnya.

Metrik yang sebenarnya adalah replaceability: seberapa murah Anda bisa menghapus module ini dan mengimplementasikannya ulang di balik contract yang sama ketika kebutuhan berubah?

Kalau jawabannya adalah “dengan mudah sekali,” kecepatan AI akan terakumulasi. Kalau jawabannya adalah “kita perlu menelusuri enam dependency implisit dulu,” Anda sudah kehilangan keuntungan kecepatan yang Anda kira sedang Anda beli.

Kenapa AI Code Cenderung Menghasilkan Coupling

Model bahasa besar mengoptimalkan permintaan yang langsung ada di depan mereka. Mereka tidak mengoptimalkan perubahan di masa depan.

Saat Anda memberi prompt untuk login flow, Anda mendapatkan login flow yang berfungsi. Anda tidak mendapatkan login flow di balik auth interface yang bisa ditukar dari Firebase ke Supabase ke custom JWT service tanpa menyentuh screen mana pun yang memakainya.

Ini bukan kegagalan model. Ini kegagalan konteks. Model itu tidak diminta mengoptimalkan replaceability, jadi ia tidak melakukannya.

Hasilnya: AI-generated code secara default cenderung menuju tight coupling. Bukan karena modelnya buruk, tetapi karena bagi next-token predictor, isolation tidak pernah menjadi pilihan yang paling mudah.

Replaceability adalah Keputusan Arsitektur

Replaceability tidak terjadi secara kebetulan. Ia adalah pilihan struktural yang disengaja:

  • Setiap dependency eksternal berada di balik interface yang dimiliki aplikasi.
  • Setiap module hasil generation mengekspos contract, bukan implementation.
  • Setiap capability opsional di-inject, tidak pernah di-import secara langsung.
  • Setiap keputusan composition berada di satu composition root, bukan tersebar di lima puluh file.

Ini bukan hal baru. Ini adalah dependency inversion dasar. Yang baru adalah AI-generated code membuat pelanggaran terhadap prinsip-prinsip ini terasa tanpa usaha dan tidak terlihat sampai Anda perlu mengubah sesuatu.

Efek Berlipat

Ketika setiap module bisa diganti:

  • Generation yang buruk hanya memakan menit, bukan hari.
  • Perubahan vendor cukup berupa swap interface, bukan rewrite.
  • Kecepatan AI tetap linear di berbagai iterasi, bukan logaritmik.
  • Tim bisa berkata “generate ulang ini di balik contract yang sama” dan benar-benar serius dengan itu.

Ketika module saling terjerat:

  • Setiap perubahan mengharuskan pemahaman atas seluruh dependency graph.
  • Setiap refactor berbantuan AI berisiko merusak sistem yang tidak terkait.
  • Tim perlahan berhenti mempercayai output AI karena radius dampaknya tidak bisa diprediksi.
  • Kecepatan runtuh kembali ke level pra-AI, tetapi sekarang dengan lebih banyak code yang harus dirawat.

Uji Praktis

Sebelum menerima module AI-generated apa pun ke dalam codebase, terapkan satu uji:

Bisakah saya menghapus file ini dan mengimplementasikannya ulang dari nol, hanya dengan memakai interface yang ia ekspos, tanpa memodifikasi consumer mana pun?

Jika ya, rilis. Jika tidak, perbaiki boundary sebelum Anda merilisnya.

Ini murah untuk ditegakkan. Composition root ditambah desain interface-first memberi Anda properti ini secara struktural. Anda tidak memerlukan tata kelola yang rumit. Anda memerlukan satu aturan arsitektural yang diterapkan secara konsisten.

Kaitannya dengan AI-Native Architecture

Saya menulis tentang masalah yang lebih luas ini dalam Stanford CS146S benar soal AI coding. Mata kuliah yang hilang adalah arsitektur. Prinsip replaceability adalah mekanisme spesifik yang membuat AI-native codebase tetap bisa bertahan melewati versi satu.

Stanford sedang mengajarkan pengembang cara menggunakan AI tools secara efektif. Itu penting. Tapi kefasihan memakai alat tanpa replaceability adalah jebakan: Anda merilis lebih cepat sampai codebase menjadi mahal untuk diubah, lalu Anda merilis lebih lambat daripada tim yang sama sekali tidak pernah memakai AI.

Disiplinnya bukan “buat prompt lebih baik.” Disiplinnya adalah “susun arsitektur agar kesalahan prompting murah untuk dibatalkan.”

FAQ

Apa arti “arsitektur yang mudah diganti” untuk AI-generated code?

Arsitektur yang mudah diganti berarti setiap module AI-generated berada di balik interface yang menjadi dependency bagi sisa sistem — bukan implementation-nya langsung. Saat kebutuhan berubah atau hasil generation salah, Anda menghapus module itu dan mengimplementasikannya ulang tanpa menyentuh consumer.

Bagaimana Anda menegakkan replaceability dalam AI-generated codebase?

Tiga mekanisme: interface yang dimiliki aplikasi (bukan dependency), satu composition root tempat semua implementation dirangkai bersama, dan check CI yang gagal jika ada module yang langsung mengimpor internal module lain.

Apakah replaceability memperlambat development awal?

Tidak. Mendefinisikan interface sebelum menghasilkan implementation hanya menambah hitungan detik. Biaya karena tidak melakukannya baru muncul beberapa minggu kemudian ketika pergantian vendor atau refactor berubah menjadi rewrite penuh.

Apakah ini sama dengan dependency injection?

Dependency injection adalah salah satu mekanisme untuk mencapai replaceability, tetapi itu bukan keseluruhan gambarnya. Replaceability juga memerlukan contract tests, validasi boundary, dan composition root — bukan sekadar parameter constructor.