Idenya bagus. Ekonominya yang buruk.

Software engineering penuh dengan ide yang terasa jelas benar begitu kamu membacanya.

Tentu contracts seharusnya mendefinisikan apa yang boleh diterima dan dikembalikan sebuah function. Tentu tests seharusnya memeriksa properties, bukan cuma beberapa contoh yang dipilih manual. Tentu tim seharusnya mengukur apakah tests benar-benar menangkap fault, bukan sekadar menganggap coverage sudah cukup. Tentu keputusan arsitektur seharusnya tetap sinkron dengan code yang mereka atur.

Tak satu pun dari ini kontroversial. Masalahnya ekonomi. Strategi-strategi ini mahal tepat pada resource yang paling sulit diperbanyak oleh kebanyakan tim: perhatian spesialis.

Selama bertahun-tahun, strategi engineering yang kuat jatuh ke siklus yang sama. Tim mengadopsinya. Kualitas naik. Lalu biaya maintenance datang. Contracts mulai drift. Property tests tertinggal saat schema berubah. Surviving mutants menumpuk tanpa triage. Dokumentasi arsitektur berubah jadi fiksi. Strateginya tidak gagal karena salah. Strateginya gagal karena menuntut tingkat expertise berkelanjutan yang sulit dipertahankan oleh tim produk biasa.

Itulah konteks penting dari momen AI sekarang. Perubahan utamanya bukan cuma model bisa menulis code lebih cepat. Perubahan utamanya adalah model sekarang bisa menyerap banyak pekerjaan spesifikasi dan verifikasi yang dulu membuat praktik-praktik ini tidak ekonomis.

Apa yang sebenarnya membuat strategi ini tetap niche

Masalahnya bukan compute. Compute murah sudah tersedia cukup lama.

Masalahnya juga bukan semata tooling. Tool yang bagus sudah ada untuk banyak metode ini. Tetapi tools itu tetap mengasumsikan ada orang yang tahu cara menulis invariants, generators, contracts, dan boundary rules yang benar.

Bottleneck yang sebenarnya adalah expertise yang sulit diparalelkan.

  • Design by contract membutuhkan engineers yang bisa menulis dan menjaga preconditions, postconditions, dan invariants tetap berguna selama refactor.
  • Property-based testing membutuhkan orang yang melihat function lalu langsung berpikir dalam round trip, idempotence, error behavior, dan algebraic properties.
  • Mutation testing membutuhkan triage terhadap survivors untuk membedakan gap nyata dari equivalent mutants.
  • Type-level correctness membutuhkan kenyamanan dengan branded types, phantom types, typestates, atau bahkan tooling verifikasi formal.
  • Living specifications membutuhkan penerjemahan keputusan manusia menjadi architecture rules yang bisa ditegakkan.

Setiap strategi punya pajak maintenance sendiri. Menggabungkan beberapa strategi malah lebih mahal karena butuh glue di antara semuanya.

Itulah sebabnya banyak ide yang “good on paper” tetap berada di aerospace, finance, formal methods research, atau tim infrastruktur yang sangat disiplin. Metodenya bekerja. Model staffing-nya tidak.

Apa yang diubah AI

AI tidak menghilangkan engineering judgment. AI mengubah di mana judgment itu dipakai.

Dulu, senior engineer harus menulis hampir seluruh scaffolding secara manual. Sekarang model bisa membuat draft contract, menyarankan properties, membangun schema, mengusulkan architecture rule, bahkan menulis regression test awal untuk surviving mutant. Manusia tinggal review correctness dari sisi domain, bukan mulai dari halaman kosong.

Perubahan ini lebih besar dari kelihatannya.

Workflow lama itu author-heavy. Workflow baru menjadi review-heavy.

Artinya:

  • contracts jadi lebih murah untuk diadopsi
  • property-based testing jadi lebih realistis untuk dipakai
  • mutation testing jadi lebih berguna
  • architecture constraints jadi lebih mudah ditegakkan

Inilah unlock ekonomi yang sebenarnya. Bukan mengganti engineers dengan model, tetapi membuat strategi yang dulu butuh authoring spesialis menjadi terjangkau untuk tim produk biasa.

Insight pentingnya: strategi ini saling menguatkan

Nilai terbaiknya bukan pada satu teknik terpisah.

Yang menarik adalah AI membuat stack ini terjangkau sebagai satu sistem.

Contract bisa menjadi input untuk property test. Property test bisa dinilai dengan mutation testing. Schema bisa mendefinisikan runtime boundary. ADR bisa menjadi architecture rule. Branded type bisa mempersempit surface area sebelum runtime check berjalan. Nilainya bukan cuma di setiap bagian, tetapi di glue antarbagian.

Sebelum AI, kebanyakan tim nyaris hanya bisa membenarkan satu strategi. Setelah AI, beberapa strategi bisa digabungkan tanpa mengubah reliability work menjadi program spesialis penuh waktu.

Ini bukan sihir

Tetap ada cara yang salah untuk melakukannya.

Kalau kamu membiarkan AI menghasilkan code, contracts, dan tests tanpa deterministic enforcement, kamu cuma membuat tumpukan teks yang terlihat meyakinkan. Tujuannya bukan meminta model memberkati codebase kamu. Tujuannya adalah memakai model untuk menghasilkan artefak yang bisa diperiksa secara murah dan berulang.

Karena itu pola yang menang tetap pola yang membosankan:

  • generate dengan AI
  • validate dengan deterministic tools
  • review perubahan di level spesifikasi
  • buat CI gagal cepat saat aturan dilanggar

AI bernilai di sini karena menutup gap expertise, bukan karena ia harus menjadi hakim terakhir.

Mengapa ini penting sekarang

Tim sudah memakai AI untuk mempercepat implementasi. Risikonya adalah delivery speed naik lebih cepat daripada kedalaman verifikasi.

Kalau itu terjadi, kamu tidak mendapatkan organisasi engineering yang lebih produktif. Kamu mendapatkan jalur lebih cepat menuju sistem yang rapuh.

Peluangnya adalah memakai model yang sama untuk menghidupkan kembali praktik reliability yang dulu terlalu mahal. Dengan begitu, kecepatan tidak berubah menjadi utang operasional.

Beberapa tahun ke depan akan menguntungkan tim yang memahami perbedaan ini lebih awal. AI-assisted coding saja bukan strategi. AI-assisted verification and enforcement adalah strategi.

Itulah mengapa begitu banyak ide engineering lama jadi relevan lagi: bukan karena tiba-tiba lebih benar, tetapi karena akhirnya menjadi ekonomis untuk dijalankan.