16.4 AI sebagai Asisten Arsitek
Kemampuan memahami codebase ini membuka jalan bagi AI untuk membantu tugas yang lebih strategis: mendokumentasikan keputusan arsitektur. Rina, setelah berhasil memperbaiki bug, menyadari bahwa timnya sering mengambil keputusan arsitektur tanpa mencatatnya dengan baik. Enam bulan lalu, seseorang memutuskan untuk memisahkan modul pembayaran menjadi service terpisah. Alasannya? Tidak ada yang ingat persis. Sekarang tim baru harus menebak-nebak.
Situasi seperti ini akrab bagi banyak arsitek. Keputusan diambil dalam rapat, diskusi singkat di Slack, atau bahkan saat pair programming. Semua masuk akal pada saat itu, tetapi tiga bulan kemudian tidak ada yang bisa menjelaskan mengapa sistem dirancang dengan cara tertentu. Padahal, dokumentasi keputusan arsitektur — yang sering disebut ADR atau Architecture Decision Record — adalah salah satu artefak paling penting yang bisa ditinggalkan seorang arsitek untuk timnya.
Masalahnya, menulis ADR terasa seperti pekerjaan administratif. Arsitek tahu ini penting, tetapi selalu ada hal lain yang lebih mendesak: rapat dengan stakeholder, review desain, debugging issue production. Akibatnya, ADR ditulis setengah hati, ditunda, atau tidak pernah dibuat sama sekali.
Di sinilah AI bisa menjadi asisten yang berguna. Bukan untuk menggantikan judgment arsitek, tetapi untuk mempercepat pembuatan artefak arsitektur.
Bayangkan Rina baru saja selesai diskusi dengan tim tentang keputusan memakai event-driven architecture untuk modul notifikasi. Ia membuka editor, mengetikkan prompt singkat: "Buat draft ADR untuk keputusan menggunakan event-driven architecture pada modul notifikasi. Tim sudah sepakat menggunakan RabbitMQ. Pertimbangan utamanya adalah decoupling dan scalability." Dalam hitungan detik, AI menghasilkan draf yang berisi konteks, opsi yang dipertimbangkan, keputusan yang diambil, dan konsekuensinya.
Berikut contoh template ADR dalam format YAML yang bisa dihasilkan AI.
# architecture-decision-record.yaml
title: "Gunakan Event-Driven Architecture untuk Modul Notifikasi"
status: proposed # proposed | accepted | deprecated | superseded
context: |
Modul notifikasi perlu mengirim email, SMS, dan push notification.
Permintaan notifikasi bisa melonjak 10x saat campaign berlangsung.
Sistem saat ini memproses notifikasi secara sinkron, menyebabkan
bottleneck di API gateway.
decision: |
Gunakan event-driven architecture dengan RabbitMQ sebagai message broker.
Service notifikasi akan subscribe ke queue terpisah per jenis notifikasi.
consequences:
positive:
- Decoupling antara service pengirim dan pemroses notifikasi
- Scalability horizontal untuk masing-masing consumer
- Fault isolation: satu consumer gagal tidak memblokir yang lain
negative:
- Kompleksitas operasional tambahan (manage RabbitMQ cluster)
- Latensi end-to-end bertambah (proses jadi asynchronous)
- Perlu idempotency handling di consumer
Perbandingan berikut menunjukkan bagaimana AI mempercepat proses dokumentasi keputusan arsitektur.
Rina tidak langsung menerima draf itu. Ia membaca, menyesuaikan, menambahkan detail teknis yang hanya ia ketahui, dan menghapus bagian yang terlalu generik. Tapi waktu yang ia habiskan turun dari satu jam menjadi sepuluh menit. Yang lebih penting, ADR itu jadi tertulis, bukan hanya ada di kepala.
AI juga bisa membantu membuat diagram awal. Rina bisa meminta, "Gambarkan alur data dari mobile app ke notifikasi service, melewati API gateway dan message broker." AI menghasilkan diagram berbasis teks yang bisa ia edit, atau kode untuk tools diagram seperti Mermaid atau PlantUML. Lagi-lagi, hasilnya bukan final, tetapi titik awal yang jauh lebih cepat daripada mulai dari kanvas kosong.
Selain ADR dan diagram, ada artefak lain yang sering tertunda karena alasan sama: decision brief untuk stakeholder, risk register yang mencatat risiko arsitektur, integration note yang menjelaskan bagaimana sistem baru terhubung dengan sistem lama, dan review checklist yang dipakai saat sesi review desain. Semua ini bisa dimulai dengan bantuan AI.
Yang perlu diingat adalah peran AI tetap sebagai asisten, bukan pengambil keputusan. AI tidak tahu konteks bisnis perusahaan, relasi politik antar tim, atau batasan regulasi yang memengaruhi keputusan arsitektur. AI tidak bisa merasakan apakah suatu keputusan akan diterima oleh tim operasi atau ditolak oleh kepala keamanan. Semua itu adalah judgment manusia.
Tetapi dengan AI, arsitek bisa menghabiskan lebih sedikit waktu untuk menulis draf dan lebih banyak waktu untuk berpikir, berdiskusi, dan memastikan keputusan yang diambil benar-benar tepat. Ini bukan tentang membuat arsitek malas, tetapi tentang membebaskan arsitek dari pekerjaan yang seharusnya bisa dilakukan mesin agar ia bisa fokus pada pekerjaan yang hanya bisa dilakukan manusia.
Setelah arsitek terbantu dengan AI untuk tugas dokumentasi, pertanyaan berikutnya muncul: apakah AI hanya berguna untuk peran teknis? Atau bisakah fungsi lain di organisasi juga mendapatkan manfaat serupa?