Saat PR Terlihat Baik-Baik Saja tapi Tetap Terasa Salah
Kalau kamu sudah shipping dengan AI lebih dari beberapa minggu, perasaan ini mungkin sudah akrab.
Kamu membuka sebuah pull request. Codenya cukup rapi. Penamaannya lumayan. Tests-nya ada. Tidak ada yang tampak jelas rusak. Tetapi tetap ada sesuatu yang terasa tidak beres.
Mungkin boundary-nya sedikit kabur. Mungkin contract-nya cuma tersirat, bukan dinyatakan. Mungkin happy path-nya tercakup, tetapi aturan bisnis yang sebenarnya masih tinggal di kepala seseorang. Kamu bisa merasakan risikonya, meski tidak bisa menunjuk satu baris yang jelas-jelas fatal.
Itulah problem review yang baru.
Kebanyakan tim masih menjalankan coding berbantuan AI lewat alur kerja lama: menulis prompt, menghasilkan diff, membuka PR, lalu meminta engineer senior memeriksa code dengan cukup teliti untuk menangkap invariants yang rusak, edge case yang hilang, architecture drift, dan risiko tersembunyi.
Model itu masuk akal ketika manusia masih menulis hampir seluruh implementasi sendiri. Model itu jauh kurang masuk akal ketika sebuah model bisa menghasilkan implementasi, test suite pertama, schema, bahkan kerangka awal contract dalam satu kali jalan.
Pada titik itu, code review baris demi baris berhenti menjadi tempat dengan leverage tertinggi untuk memakai perhatian engineer senior.
Pertanyaan yang sesungguhnya bukan lagi, “Apakah function ini terlihat masuk akal?”
Pertanyaan yang sesungguhnya adalah, “Apakah kita sudah mendefinisikan behavior, boundary, dan invariant yang tepat sebelum function ini ada?”
Itulah inversi alur kerja yang diciptakan AI. Code review tidak menghilang. Tetapi pusat gravitasinya bergeser ke hulu. Di era AI, code review berubah menjadi review spesifikasi.
Kenapa Pergeseran Ini Terasa Sangat Berbeda
Sudah lama kebanyakan tim engineering memperlakukan spesifikasi sebagai materi pendukung.
Code adalah hal utamanya. Doc comment cuma petunjuk. ADR cuma context kalau ada waktu untuk membacanya. Schema dianggap “sekadar validation.” File Gherkin menyenangkan untuk dimiliki kalau ada yang repot menjaganya tetap update.
Hierarki itu sekarang sedang runtuh.
Kalau sebuah LLM bisa mengubah spesifikasi menjadi artefak implementasi dengan cepat dan berulang kali, maka spesifikasi bukan lagi hal sekunder. Ia menjadi artefak sumber yang darinya bagian lain sistem diturunkan.
Dan itu mengubah di titik mana kesalahan paling murah untuk ditangkap.
Kalau spesifikasinya samar, model bisa menghasilkan implementasi yang salah tetapi tersusun indah. Ia bisa memberimu code yang bersih, tests yang masuk akal, dan rasa percaya diri palsu. Bahkan code review yang kuat pun bisa melewatkan problem sebenarnya karena bug-nya bukan ada di syntax. Bug-nya ada di maksud yang didefinisikan.
Itulah yang membuat momen ini begitu rumit sekaligus penting. AI membuat output yang meyakinkan jadi lebih mudah diproduksi. AI juga membuat sikap sembrono terhadap apa yang kamu minta jadi jauh lebih berbahaya.
Kalau spesifikasinya presisi, punya batas yang jelas, dan bisa diuji, semuanya jadi lebih mudah. Implementasi lebih mudah. Validation lebih mudah. Review lebih mudah. CI lebih kuat.
Itulah sebabnya upaya review manusia yang terbaik sedang bergeser dari audit manual setiap branch menuju pengetatan artefak yang sejak awal mendefinisikan behavior branch tersebut.
Spesifikasi Bukan Dokumen Kebutuhan Raksasa
Ketika orang mendengar kata “spesifikasi,” yang terbayang sering kali adalah dokumen gemuk yang tak ada seorang pun mau menulisnya dan tak ada seorang pun percaya enam minggu kemudian.
Itu bukan yang penting di sini.
Dalam alur kerja AI-assisted yang praktis, spesifikasi adalah artefak apa pun yang mendefinisikan behavior yang diinginkan dengan cukup ketat agar generation dan enforcement bisa dilakukan.
Ini bisa berupa:
- ADR Markdown yang mendeskripsikan boundary rule
- schema Zod yang mendefinisikan bentuk input eksternal
- function signature dengan doc comment yang tajam
- skenario Gherkin yang menangkap behavior yang bisa diamati
- blok contract dengan preconditions dan postconditions
- model reducer atau tabel transisi state
Tak satu pun dari ini harus heavyweight. Semuanya hanya perlu cukup jelas agar tools bisa melakukan sesuatu yang berguna dengannya.
Itulah ambang yang penting. Spesifikasi yang berguna bukan cuma bisa dibaca manusia. Ia juga bisa ditindaklanjuti oleh sistem di sekitar codebase.
Seperti Apa Review yang Bagus Mulai Terlihat
Dalam model lama, seorang engineer senior menghabiskan energinya pada pertanyaan seperti:
- apakah implementasi ini bersih?
- apakah penulisnya melewatkan edge case?
- apakah tests ini cukup kuat?
- apakah import ini melanggar boundary?
Pertanyaan-pertanyaan itu tetap penting. Hanya saja, itu bukan lagi pertanyaan pertama dengan leverage tertinggi.
Dalam alur kerja yang specification-first, pertanyaan yang lebih berharga adalah:
- apakah contract-nya memang benar?
- apakah schema-nya mendefinisikan boundary yang sebenarnya?
- apakah aturan bisnisnya sudah lengkap?
- apakah ADR-nya cukup presisi untuk enforcement?
- apakah daftar properties ini benar-benar mengekspresikan semantiknya?
Itu pertanyaan review yang lebih baik karena satu jawaban yang baik memperbaiki beberapa artefak sekaligus.
Kalau kamu memperketat ADR yang samar, kamu meningkatkan aturan arsitektur, panduan implementasi, dan enforcement di CI dalam satu langkah.
Kalau kamu memperbaiki schema yang lemah, kamu meningkatkan validasi runtime, type inference, dan kualitas code generation dalam satu langkah.
Kalau kamu mempertajam contract, kamu meningkatkan implementasi, tests, dan ketahanan terhadap mutation dalam satu langkah.
Itulah bedanya leverage. Kamu tidak lagi menginspeksi output satu per satu. Kamu sedang mereview hal yang membentuk output-output itu.
Kenapa Code Review Tradisional Mulai Retak
Code review tradisional mengasumsikan manusia adalah penulis utamanya dan reviewer sedang memeriksa kualitas proses berpikir manusia dari code yang sudah jadi.
Dengan AI, asumsi itu makin lemah tiap minggu.
Sebuah model bisa menghasilkan lima puluh baris yang masuk akal dalam hitungan detik. Ia bisa menghasilkan lima puluh lagi sama cepatnya. Lalu lima puluh lagi setelah itu. Kalau seluruh prosesmu bergantung pada reviewer yang secara manual harus menangkap semantic drift yang terkubur di dalam arus itu, surface area review akan tumbuh lebih cepat daripada perhatian manusia.
Itu menciptakan equilibrium yang buruk:
- code generation makin cepat
- diff menjadi lebih besar atau lebih sering
- reviewer fatigue naik
- semantic confidence turun
- tim mulai mengompensasinya dengan vibes, intuisi, dan “looks good to me”
Itu bukan strategi scale. Itu cuma akumulasi risiko yang dibungkus formatting rapi.
Langkah yang lebih baik adalah mengurangi dulu seberapa banyak review subjektif yang kamu butuhkan. Pindahkan lebih banyak makna ke spesifikasi yang deterministic dan bisa direview. Lalu biarkan mesin memeriksa apakah code masih selaras dengan makna itu.
CI yang Membuat Ini Nyata
Inversi alur kerja ini hanya bekerja kalau spesifikasi terikat ke enforcement.
Kalau tidak, kamu cuma mengganti nama dokumentasi lalu berharap orang akan lebih menghormatinya.
Intinya adalah membuat spesifikasi menjadi operasional.
Itu berarti:
- keputusan arsitektur dikompilasi menjadi aturan dependency
- schemas mendefinisikan boundary yang runtime-safe dan type-safe
- contracts menghasilkan executable checks
- daftar properties dipakai untuk menghasilkan tests
- semantik kritis menjadi merge gates
Begitu itu terjadi, CI berhenti menjadi build system pasif dan berubah menjadi mekanisme yang menjaga implementasi tetap selaras dengan maksud aslinya.
Itulah juga alasan Living specifications akhirnya menjadi realistis untuk tim biasa. Secara historis, dokumentasi membusuk karena tak ada yang punya waktu menjaga teks dan code tetap sinkron secara manual.
AI mengubah ekonomi penulisan dan pembaruan artefak itu. CI mengubah ekonomi enforcement atas artefak tersebut.
Kamu butuh keduanya. AI tanpa enforcement memberi kamu drift yang terlihat rapi. Enforcement tanpa spesifikasi yang baik memberi kamu kebingungan yang kaku.
Hard Guards, Soft Reviews
Ini juga bagian dari filosofi Autotomy yang makin terasa tepat buat saya.
Idenya sederhana: letakkan aturan yang tidak bisa dinegosiasikan ke dalam hard guards, lalu biarkan review manusia fokus pada bagian yang memang butuh judgment.
Itu berarti types, schemas, contracts, aturan dependency, dan deterministic checks menangani failure mode yang sudah dikenal. Mereka berjalan setiap kali. Mereka tidak lelah. Mereka tidak terdistraksi oleh diff yang diformat rapi. Mereka tidak peduli apakah code itu datang dari staff engineer atau language model.
Lalu layer review menjadi lebih kecil dan lebih baik.
Alih-alih menghabiskan perhatian senior pada hal-hal yang sebenarnya bisa ditolak sistem secara otomatis, kamu memakainya untuk tradeoffs, semantik, interfaces, dan arsitektur. Kamu bertanya apakah boundary-nya benar, apakah contract-nya jujur, apakah replacement-nya sungguh memenuhi interface, apakah sistemnya makin mudah atau makin susah diubah.
Bagian terakhir itu sangat penting.
Salah satu efek samping paling sehat dari kerja specification-first adalah ia mendorongmu ke titik potong yang lebih bersih. Kalau sebuah module bisa diganti selama ia memenuhi contract dan lulus checks, kamu berhenti menganggap setiap implementasi sakral. Kamu mulai mendesain untuk replacement yang aman alih-alih preservation yang menyakitkan.
Itu pergeseran yang halus, tetapi ia mengubah cara tim menangani growth. Codebase berhenti terasa seperti sesuatu yang hanya bisa kamu patch dengan hati-hati dari dalam. Ia mulai terasa seperti sistem dengan seams yang eksplisit.
Ini Justru Kabar Baik untuk Engineer Senior
Pergeseran ini tidak membuat judgment engineering senior menjadi kurang berharga. Ia justru membuatnya lebih fokus dan lebih penting.
Seorang engineer senior tidak lagi paling berharga sebagai mesin diff syntax manusia. Mereka paling berharga di titik tempat ambiguitas diurai, invariants dipilih, interfaces dibentuk, dan tradeoffs dibuat eksplisit.
Itu berarti lebih banyak waktu dihabiskan untuk:
- menulis ADR yang presisi
- mendefinisikan contracts dan schemas
- mereview perubahan semantik alih-alih yang sekadar stilistik
- memutuskan properties mana yang pantas mendapat enforcement
- mengubah arsitektur menjadi aturan yang bisa ditegakkan saat merge
Itu pemakaian perhatian mahal yang jauh lebih baik.
Mesin sangat bagus dalam mengisi detail implementasi. Engineer senior masih jauh lebih baik dalam memutuskan apa yang harus tetap benar ketika sistem ditekan, diubah, dan diskalakan.
Kamu Tidak Butuh Rewrite Proses Besar-Besaran
Ini bisa terdengar lebih besar daripada kenyataannya.
Kamu tidak perlu meluncurkan inisiatif formal methods. Kamu tidak perlu berhenti shipping. Kamu tidak perlu menenggelamkan tim dalam proses.
Mulailah dengan satu pergeseran sempit: perlakukan satu kelas spesifikasi sebagai artefak utama yang benar-benar direview.
Urutan praktisnya seperti ini:
- wajibkan doc comments dan schemas yang presisi pada boundary kritis
- perlakukan perubahan ADR sebagai item review untuk engineer senior
- hasilkan tests dan contracts dari artefak-artefak itu
- enforce arsitektur dan contract drift di CI
- turunkan prioritas komentar review yang cuma soal style demi memberi ruang pada review semantik
Itu sudah cukup untuk mengubah budaya.
Begitu tim merasakan bahwa spesifikasi yang lebih baik mengurangi churn review di hilir, pola ini mulai menguat dengan sendirinya. Review menjadi lebih tajam. Diff terasa tidak terlalu menakutkan. Trust meningkat.
Pergeseran Strategis yang Sebenarnya
Tim yang menang dengan AI bukan tim yang sekadar menghasilkan code lebih cepat.
Mereka adalah tim yang memindahkan perhatian manusia ke bagian alur kerja yang paling sempit sekaligus paling tinggi leverage-nya.
Bagian itu adalah spesifikasi.
Ketika spesifikasi menjadi artefak utama, code berhenti menjadi satu-satunya hal yang layak direview baris demi baris. Ia menjadi salah satu output dari sistem yang lebih disiplin.
Itulah pergeseran yang sebenarnya.
Implementasi tetap penting. Sangat penting. Tetapi semakin ke sini, keputusan review yang paling penting terjadi sebelum implementasinya ada.
Dan itulah sebabnya, di era AI, code review berubah menjadi review spesifikasi.