Review Jujur Tool AI: Keterbatasan Mengecek Arsitektur Sistem bagi PM

Niatnya mau cepet kelar.
Jatuhnya malah gw harus meeting tiga kali buat benerin miskomunikasi.
Awalnya gw pikir gw udah pakai AI dengan bener.

Gw pikir, masukin diagram arsitektur ke AI,
terus minta dia ngecek celahnya,
bakal bikin kerjaan gw sebagai product manager jadi gampang banget.

Kok bisa?

Ibaratnya gini. Gw butuh ngecek pondasi rumah.
Alih alih turun ke tanah dan ngecek sendiri pakai tangan,
gw malah minta tolong orang lewat yang cuma liat dari foto.
Di atas kertas keliatannya cepet kelar.
Gak keluar keringat.

Tapi pas ujan, rumahnya bocor.
Dan gw yang harus nanggung basahnya sendirian.

Nah, ternyata hal yang sama persis kejadian saat gw pakai tool AI buat ngecek arsitektur sistem.
Selama ini banyak product manager yang tergiur sama janji manis kalau semuanya bisa serba instan.
Tinggal unggah dokumen arsitektur,
minta tolong cariin celah keamanan,
terus berharap dapat hasil yang siap dipresentasikan ke direksi besok paginya.

"Yang penting kerjaan beres," pikir gw waktu itu.
Tapi pas gw bawa hasil analisis dari AI itu ke tim engineer,
gw diketawain abis abisan.
Saran dari AI itu mustahil diterapin di sistem kita yang udah jalan bertahun tahun.

Bukan karena model AI nya bodoh.
Tapi karena alatnya gak punya konteks tentang realita kotor di lapangan.

Di situ gw baru paham satu hal penting soal tool AI buat PM.
Harga sebuah alat itu bukan cuma soal efisiensi waktu di awal pemakaian.
Harga sebenarnya itu berapa banyak waktu yang lo buang buat ngeyakinin engineer pakai argumen yang cacat logika.
Dan model AI itu memang sering halusinasi kalau dipakai di konteks teknis yang sangat dalam.

Beda Konteks Beda Hasil

Waktu kita ngecek arsitektur sistem yang kompleks, masalah utamanya jarang ada di baris kodenya.
Masalah terbesarnya ada di konteks bisnis yang berantakan.
AI itu pinter banget baca pola yang rapi dan terstruktur.
Tapi dia buta total soal sejarah kenapa sebuah sistem dibikin dengan cara tertentu.

Contoh nyata waktu gw ngerjain custom MGC Legacy Sync architecture.
Itu sistem besar dengan ratusan batasan bisnis.
Gw coba kasih diagram ke model AI yang paling mahal cuy.
Gw niat nyari bottleneck di sistem lama pakai cara instan.

Jawabannya keren banget secara teori.
Dia nyaranin kita buat ganti struktur database.
Dia juga nyaranin bikin microservice baru yang lebih modern.
Bahasa yang dipakai keliatan meyakinkan banget buat orang awam.

Tapi dia gak tau kalau sistem itu sengaja dibikin sinkron gara gara ada aturan compliance dari regulator lokal.
Dia pede ngasih saran yang secara teori luar biasa sempurna.
Tapi secara kelayakan bisnis mustahil dieksekusi.

Dan tiap kali dia ngasih saran yang meleset, gw yang harus ngefilter semuanya.
Itu semua keliatan gampang di awal.
Padahal gw bayar pakai waktu buat mikir ulang.
Gw bayar pakai energi buat nyari tau apakah saran ini beneran bisa dipakai atau cuma halusinasi mesin.

Sama persis kayak ngecek pondasi rumah tadi.
Kalau lo cuma liat dari luar, lo gak bakal tau tanah di bawahnya gampang ambles.

Review Jujur Tool AI di Lapangan

Sering banget gw denger klaim ajaib di luar sana.
Kalau lo rajin ngikutin dinamika ekosistem startup,
atau sering baca opini pengamat industri kayak Rama Mamuaya,
pasti kerasa banget narasi kencang soal AI yang katanya bisa menggantikan semua kerjaan mikir.
Banyak yang ngerasa kalau adopsi AI bakal otomatis bikin perusahaan hemat jutaan dolar tanpa usaha keras.

Kenyataannya gak seindah narasi itu.
Bikin perusahaan hemat itu kebiasaan lama gw, jauh sebelum AI ngetren.
Lebih dari $4 juta per tahun berhasil kehemat dari berbagai inisiatif yang gw dorong bareng tim.
Dulu di Flip dan Tokopedia, kita telusurin satu per satu celah inefisiensi yang ada.
Kita perbaiki proses operasional, kita optimasi biaya server, kita potong redundansi produk.

Dulu, leverage sebesar itu butuh posisi strategis.
Lo butuh tim engineer yang jago dan sistem infrastruktur yang mahal banget buat dieksekusi.
Otomasi itu cuma salah satu bagian kecil dari semua inisiatif kita.

Sekarang, AI jadi alat paling tajam buat ngelakuin kebiasaan yang sama.
Dan leverage itu bisa dilatih ke semua orang di tim lo.
Contoh nyatanya, gw sekarang bisa bangun sistem distribusi konten delapan kanal sendirian.
Sistem itu motong video panjang jadi klip, lalu nyebar otomatis tiap hari ke berbagai platform.
Gw cuma perlu review hasil akhirnya dan biarin sistemnya jalan.

Itu adalah contoh di mana AI dipakai dengan benar.
Karena aturannya jelas, konteksnya sempit, dan risikonya sangat rendah buat operasional harian.

Batas Nyata Kemampuan Mesin

Ini bagian yang PM wajib banget sadar dan terima.
Realitanya, tool ini belum siap dikasih kunci rumah buat ngambil keputusan arsitektur.
AI itu gak ngerti kalau sistem sering lambat karena vendor API nya memang bermasalah dari sananya.
Dia gak paham kalau tabel database sengaja digabung demi ngejar tenggat waktu rilis.

Waktu gw mimpin proses migrasi Gogogo V2,
kompleksitas sistem integrasinya luar biasa tinggi.
Kalau saat itu gw pasrahin pengecekan arsitektur murni ke AI tanpa gw pahamin sistemnya dari awal,
keputusan produk yang gw ambil pasti bakal ngerusak pengalaman jutaan pengguna.

AI itu sangat bagus buat ngasih lo pertanyaan kritis.
Dia sangat membantu buat ngecek apakah lo lupa mikirin skenario kegagalan tertentu.
Dia juga jago buat bantuin lo nyusun poin penting sebelum lo masuk ruangan buat berdebat sama lead engineer.

Tapi dia gak boleh disuruh ngambil keputusan final.
Tugas lo sebagai product manager tetap sama.
Lo yang harus paham sistemnya.
Lo yang harus ngerti batasan teknis dari kapabilitas tim lo.
Dan lo yang harus nanggung risikonya kalau sistem itu gagal waktu dipakai secara massal.

Taruh Alat di Tempat yang Tepat

Makanya sekarang prinsip gw buat ngecek arsitektur cuma satu.
Jadikan AI sebagai teman diskusi yang harus selalu lo ragukan,
bukan sebagai ahli senior yang selalu lo percaya tutup mata.

Taruh alat terbaik di tempat di mana proses perbaikan itu paling murah.
Dan jangan pernah serahin keputusan di tempat di mana kesalahan itu harganya mahal banget buat perusahaan.

Yang gw kira bikin kerjaan jadi instan, ternyata nambah beban kerjaan buat ngefilter.
Yang gw kira super efisien, ternyata malah bikin gw jalan di tempat kalau konteksnya gak lengkap.
Lo tetep gak bisa menghindari kerja keras buat paham fundamental dari produk lo sendiri.

Lo tim mana?
Selalu percaya buta sama saran arsitektur dari AI?
Atau tetep turun tangan kotor kotoran ngecek pondasinya bareng tim lo sendiri?

Kalau lo individu yang mau belajar cara bener maksimalkan AI buat kerjaan harian tanpa kejebak hype sesaat, lo bisa gabung dan ngobrol langsung bareng gw di AI Circle.
Tapi kalau lo butuh bantu tim di perusahaan lo biar paham cara pakai AI yang tajam tanpa ngerusak sistem bisnis, kita bisa bahas strategi terbaiknya di halaman corporate.