17.7 Siklus Evidence: Sebelum Merge, Sebelum Release, Setelah Release, Setelah Alur Pengetahuan
Seorang arsitek baru saja selesai mereview output AI untuk modul integrasi pembayaran. Ia sudah mengumpulkan evidence sesuai jenis perubahan: unit test untuk logika baru, integration test untuk koneksi ke payment gateway, dan security scan untuk data sensitif. Semua terlihat hijau. Ia pun memberikan persetujuan untuk merge ke branch utama.
Berikut diagram yang merangkum empat fase siklus evidence beserta pertanyaan kunci dan contoh evidence minimum di setiap fase.
Tiga minggu kemudian, tim produksi melaporkan bahwa transaksi gagal di jam sibuk. Ternyata masalahnya bukan di logika atau keamanan, tetapi di performa. Evidence yang dikumpulkan saat review tidak mencakup load test karena saat itu arsitek menganggap perubahan hanya bersifat fungsional. Ia baru sadar: evidence yang cukup untuk merge belum tentu cukup untuk release.
Siklus evidence tidak berhenti di satu titik. Setiap fase perjalanan kode dari development ke produksi memiliki pertanyaan yang berbeda. Sebelum merge, kita bertanya: apakah perubahan ini aman untuk digabungkan dengan kode yang sudah ada? Sebelum release, kita bertanya: apakah perubahan ini siap untuk dipakai oleh pengguna sungguhan? Setelah release, kita bertanya: apakah perubahan ini berjalan seperti yang diharapkan di lingkungan nyata? Dan setelah alur pengetahuan dipakai, kita bertanya: apakah pengetahuan yang dihasilkan benar-benar membantu pengguna?
Evidence sebelum merge berfokus pada kebenaran lokal. Kita memeriksa apakah kode baru tidak merusak fungsi yang sudah ada, apakah logika sesuai dengan brief, apakah boundary tidak dilanggar, dan apakah tidak ada hallucinated API atau dependency. Ini adalah lapisan pertama. Banyak tim berhenti di sini dan merasa aman.
Evidence sebelum release menuntut lebih. Kita perlu memastikan bahwa perubahan tidak hanya benar secara lokal, tetapi juga siap untuk skala produksi. Integration test dengan data nyata, performance test dengan beban yang mendekati produksi, security test untuk celah yang mungkin muncul di konfigurasi deployment, dan rollback plan jika terjadi kegagalan. Ini adalah lapisan yang sering dilewati ketika tim terburu-buru merilis.
Setelah release, evidence bergeser dari verifikasi ke monitoring. Kita tidak bisa lagi mengandalkan test yang kita buat sendiri. Kita perlu melihat data nyata: apakah error rate naik? Apakah response time memburuk? Apakah ada pengguna yang melaporkan perilaku aneh? Evidence di fase ini bersifat observasional. Arsitek perlu menyiapkan dashboard dan alert yang relevan dengan perubahan yang dilakukan.
Ada satu fase lagi yang sering dilupakan: setelah alur pengetahuan dipakai oleh pengguna. Jika perubahan melibatkan alur pengetahuan—misalnya AI assistant untuk customer service atau dokumentasi otomatis untuk engineer—evidence tidak cukup hanya dari sisi teknis. Kita perlu tahu apakah pengguna benar-benar terbantu. Apakah mereka menemukan jawaban lebih cepat? Apakah mereka harus mengulang pertanyaan? Apakah knowledge yang dihasilkan akurat? Evidence di sini bersifat kualitatif dan membutuhkan feedback loop dengan pengguna.
Seorang arsitek yang matang tidak menganggap evidence sebagai satu kali cek di meja review. Ia melihat siklus evidence sebagai rangkaian keputusan yang terus berlanjut. Setiap fase memiliki kriteria yang berbeda, dan setiap fase bisa mengungkap masalah yang tidak terlihat di fase sebelumnya.
Dengan memahami siklus ini, kita siap untuk menyusun dua artefak praktis yang akan menyatukan seluruh bab ini: template AI working brief dan checklist evidence. Dua alat yang akan mengubah cara kita bekerja dengan AI dari reaktif menjadi terstruktur.
