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 sumber daya 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 pemeliharaan 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 keahlian 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 ceruk
Masalahnya bukan daya komputasi. Komputasi murah sudah tersedia cukup lama.
Masalahnya juga bukan semata alat. 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.
Hambatan yang sebenarnya adalah keahlian 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 alat verifikasi formal.
- Living specifications membutuhkan penerjemahan keputusan manusia menjadi architecture rules yang bisa ditegakkan.
Setiap strategi punya pajak pemeliharaan sendiri. Menggabungkan beberapa strategi malah lebih mahal karena butuh lapisan penghubung di antara semuanya.
Itulah sebabnya banyak ide yang “bagus di atas kertas” tetap berada di dirgantara, keuangan, penelitian metode formal, atau tim infrastruktur yang sangat disiplin. Metodenya bekerja. Model penempatan orangnya tidak.
Apa yang diubah AI
AI tidak menghilangkan penilaian engineering. AI mengubah di mana penilaian itu dipakai.
Dulu, engineer senior harus menulis hampir seluruh kerangka awal 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 meninjau correctness dari sisi domain, bukan mulai dari halaman kosong.
Perubahan ini lebih besar dari kelihatannya.
Alur kerja lama itu berat di penulisan. Alur kerja baru menjadi berat di peninjauan.
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 pembuka ekonomi yang sebenarnya. Bukan mengganti engineers dengan model, tetapi membuat strategi yang dulu butuh penulisan 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 lapisan penghubung antarbagian.
Sebelum AI, kebanyakan tim nyaris hanya bisa membenarkan satu strategi. Setelah AI, beberapa strategi bisa digabungkan tanpa mengubah pekerjaan reliability 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 celah keahlian, bukan karena ia harus menjadi hakim terakhir.
Mengapa ini penting sekarang
Tim sudah memakai AI untuk mempercepat implementasi. Risikonya adalah kecepatan delivery 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.