Masalah Review

Nasihat standar untuk AI-generated code adalah “review dengan cermat.”

Nasihat itu benar dan tidak berguna pada skala besar.

Seorang pengembang yang meninjau output AI akan menangkap masalah ketika ia sedang fokus, paham domainnya, dan tidak berada di bawah tekanan waktu. Dalam semua kondisi lain — yang berarti sebagian besar kondisi — berbagai hal akan lolos.

AI reviewer yang mencoba menangkap masalah pada AI-generated code bahkan lebih tidak andal. Anda meminta satu sistem probabilistik untuk memverifikasi output sistem probabilistik lain. Failure mode-nya saling berkorelasi.

Satu-satunya pola yang bisa diskalakan adalah deterministic enforcement. Aturan yang diperiksa di setiap commit, yang tidak bisa dikesampingkan oleh kelelahan atau optimisme, dan yang menggagalkan build ketika dilanggar.

Apa Arti Deterministic

Deterministic berarti check tersebut menghasilkan hasil yang sama setiap kali, tanpa peduli siapa yang menjalankannya atau kapan.

  • Aturan linter itu deterministic.
  • Type check itu deterministic.
  • Pembatasan import lintas boundary itu deterministic.
  • Contract test itu deterministic.
  • Rentang perhatian reviewer manusia tidak.
  • Penilaian LLM tidak.

Pembedaan ini lebih penting dalam AI-generated codebase karena volume generated code melampaui apa yang bisa direview manual oleh tim mana pun. Anda tidak bisa menskalakan review secara linear mengikuti kecepatan generation. Anda bisa menskalakan deterministic checks dengan mudah.

Stack Guardrail

Untuk AI-generated codebase, stack guardrail memiliki empat layer:

Layer 1: Type System

Type system adalah guardrail pertama. Strict types menangkap satu kelas error yang tidak bisa ditangkap secara konsisten oleh proses review mana pun — manusia maupun AI:

  • Pelanggaran null
  • Interface mismatch
  • Penanganan case yang hilang
  • Tipe argumen yang salah

Jika proyek memakai TypeScript, strict: true tidak bisa ditawar. Jika proyek memakai bahasa tanpa type system yang kuat, tambahkan itu melalui tooling atau pilih bahasa yang berbeda.

Layer 2: Architecture Rules

Architecture rules menegakkan disiplin boundary:

  • Tidak ada screen yang mengimpor internal screen lain.
  • Tidak ada domain logic yang langsung mengimpor infrastructure.
  • Tidak ada module yang melewati composition root untuk mengakses dependency.
  • Tidak ada vendor SDK yang muncul di luar module adapter-nya.

Alat seperti Semgrep, ArchUnit, dependency-cruiser, atau aturan ESLint kustom bisa menegakkan ini secara statis. Kuncinya adalah semua itu berjalan di CI dan menggagalkan build. Peringatan yang bisa diabaikan pengembang bukanlah guardrail.

Layer 3: Contract Tests

Contract tests memverifikasi bahwa module memenuhi interface-nya tanpa menjalankan seluruh sistem:

  • Auth adapter memenuhi auth interface.
  • Analytics adapter memenuhi analytics interface.
  • Storage adapter memenuhi storage interface.

Tests ini berjalan cepat, menguji boundary integrasi, dan menangkap failure mode spesifik ketika AI-generated code memenuhi type signature tetapi melanggar behavioral contract.

Layer 4: Deterministic Integration Checks

Pada level integrasi, checks memverifikasi properti seluruh sistem:

  • Composition root me-resolve semua dependency tanpa runtime error.
  • Dependency graph tidak mengandung cycle.
  • Semua environment variable yang wajib sudah dideklarasikan.
  • Configuration valid pada build time, bukan hanya pada runtime.

Semgrep untuk AI-Generated Code

Semgrep layak disebut secara khusus karena ia unggul dalam mengekspresikan architecture rules sebagai code:

  • Pattern-matching pada struktur AST, bukan string matching.
  • Aturan kustom per proyek, bukan hanya linting generik.
  • Cukup cepat untuk dijalankan di setiap commit.
  • Cukup ekspresif untuk mengodekan pelanggaran boundary.

Tim yang banyak memakai AI generation seharusnya memelihara ruleset Semgrep yang mengodekan boundary arsitektural mereka. Ketika AI menghasilkan code yang melanggar boundary, build gagal sebelum merge. Tidak perlu perhatian manusia.

Ini bukan tentang menangkap bug dalam output AI. Ini tentang membuat pelanggaran struktural mustahil untuk di-merge tanpa peduli bagaimana pelanggaran itu dihasilkan.

Apa yang Sebenarnya Ditangkap AI Code Review

Tool AI code review berguna untuk:

  • Konsistensi style
  • Celah dokumentasi
  • Error logika yang jelas
  • Menyarankan pendekatan alternatif

Tool AI code review tidak andal untuk:

  • Pelanggaran boundary arsitektural
  • Coupling halus yang diperkenalkan lintas module
  • Pelanggaran behavioral contract
  • Properti keamanan yang memerlukan penalaran seluruh sistem

Failure mode-nya bukan sekadar bahwa AI review sesekali melewatkan sesuatu. Failure mode-nya adalah ia melewatkan sesuatu secara tidak terduga, dan Anda tidak akan tahu kapan itu terjadi. Itulah sebabnya AI review tidak bisa menggantikan deterministic enforcement — hanya melengkapinya.

Ekonominya

Deterministic guardrails murah untuk dijalankan dan mahal untuk dibangun pada awalnya.

Menulis architecture rules memerlukan beberapa hari. Memelihara konfigurasi Semgrep memerlukan perhatian berkelanjutan. Menyiapkan contract tests mengharuskan interface didefinisikan lebih dulu.

Tetapi begitu semuanya ada, semuanya berjalan pada setiap commit dengan biaya marginal yang nyaris nol. Mereka tidak lelah. Mereka tidak melewatkan check pada Jumat sore. Mereka tidak tunduk pada senioritas atau tekanan sosial.

Untuk AI-generated codebase yang volume codenya tinggi dan kecepatan generation-nya cepat, profil ekonomi ini sangat menentukan. Alternatifnya — menskalakan review manusia agar menyamai kecepatan AI generation — tidak layak.

Kaitannya dengan AI-Native Architecture

Saya menulis tentang pola yang lebih luas ini dalam Stanford CS146S benar soal AI coding. Mata kuliah yang hilang adalah arsitektur. Deterministic guardrails adalah mekanisme enforcement yang membuat arsitektur yang bisa diganti menjadi nyata.

Tanpa guardrails, boundary arsitektural hanyalah aspirasi. Dengan guardrails, boundary menjadi struktural. Perbedaan antara “kami berusaha menjaga module tetap terisolasi” dan “build gagal jika isolation module dilanggar” adalah perbedaan antara arsitektur yang bertahan dalam iterasi secepat AI dan arsitektur yang runtuh karenanya.

Pengembang perangkat lunak modern tidak hanya membutuhkan kefasihan memakai AI tools. Mereka membutuhkan stack guardrail yang membuat AI-generated code aman secara struktural untuk dirilis dengan cepat.

FAQ

Apa tool terbaik untuk menegakkan architecture rules pada AI-generated code?

Semgrep adalah opsi yang paling fleksibel untuk aturan arsitektural kustom. Ia mendukung pattern-matching terhadap struktur AST, berjalan cepat di CI, dan memungkinkan tim mengodekan boundary yang spesifik untuk proyek mereka. Untuk proyek JavaScript/TypeScript, dependency-cruiser dan aturan ESLint kustom juga efektif.

Bisakah AI code review menggantikan review code manusia?

Tidak. AI code review melengkapi review manusia untuk style dan dokumentasi, tetapi tidak andal untuk enforcement boundary arsitektural dan properti keamanan. Deterministic checks (type system, linters, architecture rules, contract tests) adalah satu-satunya pengganti yang bisa diskalakan untuk review yang bergantung pada perhatian.

Bagaimana Anda menyiapkan guardrails tanpa memperlambat tim?

Mulailah dengan type system (strict mode, tanpa pengecualian). Tambahkan architecture rules untuk tiga boundary dengan risiko tertinggi. Tambahkan contract tests untuk integrasi eksternal. Setiap layer hanya butuh satu hari untuk disiapkan dan berjalan dalam hitungan detik. Perlambatan datang dari pelanggaran, bukan dari check-nya sendiri.

Apa perbedaan guardrail dan linter?

Linter memberi saran perbaikan. Guardrail menggagalkan build. Perbedaannya adalah enforcement. Dalam AI-generated codebase, saran akan diabaikan pada skala besar karena volumenya terlalu tinggi untuk perhatian manual yang konsisten. Hanya kegagalan build yang menjamin kepatuhan.