17.4 Minta Opsi, Bukan Satu Jawaban

Setelah area kerja jelas, langkah berikutnya adalah meminta AI memberikan opsi implementasi, bukan langsung satu solusi. Ini adalah titik di mana kebanyakan engineer tersandung. Mereka melihat AI sebagai mesin jawaban: beri pertanyaan, dapatkan jawaban, selesai. Pola pikir ini berbahaya karena satu jawaban dari AI sering kali terlihat meyakinkan, padahal menyembunyikan asumsi yang tidak kita sadari.

Bayangkan seorang arsitek yang meminta AI menambahkan fitur caching ke modul product catalog. Engineer biasa mungkin mengetik: “buatkan caching untuk product catalog dengan Redis.” AI akan mengeluarkan kode yang rapi, menggunakan Redis, cache-aside pattern, TTL tiga menit, dan serialisasi JSON. Semua terlihat profesional. Tapi apakah ini opsi terbaik untuk sistem yang sedang dibangun? Mungkin sistem ini membutuhkan cache yang di-invalidate saat ada perubahan data, bukan cache yang kedaluwarsa berdasarkan waktu. Mungkin Redis terlalu berat untuk traffic saat ini, dan in-memory cache sudah cukup. Mungkin cache perlu dibangun di layer API gateway, bukan di service layer.

Perhatikan dua contoh prompt berikut yang menunjukkan perbedaan pendekatan.

# Prompt yang meminta satu jawaban (pola engineer biasa)
buatkan caching untuk product catalog dengan Redis

# Prompt yang meminta opsi (pola arsitek)
berikan tiga pendekatan caching untuk product catalog, lengkap dengan trade-off latency, memory, complexity, dan consistency

Pola kerja arsitektural berbeda. Ia tidak meminta satu solusi. Ia meminta opsi. “Berikan tiga pendekatan caching untuk product catalog, lengkap dengan trade-off masing-masing: latency, memory usage, complexity implementasi, dan dampak pada consistency.” Dengan cara ini, AI tidak hanya memberikan kode, tetapi memberikan bahan pertimbangan. Arsitek bisa membandingkan, menilai mana yang cocok dengan konteks sistem saat ini, dan membuat keputusan berdasarkan informasi, bukan berdasarkan kode pertama yang keluar.

Pola ini mengubah hubungan antara manusia dan AI. AI bukan lagi asisten yang menyelesaikan tugas, tetapi rekan yang menyajikan opsi. Manusia tetap menjadi pengambil keputusan. Perbedaan ini krusial. Ketika AI memberikan satu jawaban, kita cenderung menerima karena outputnya terlihat rapi. Ketika AI memberikan tiga opsi dengan trade-off, kita dipaksa berpikir: mana yang paling sesuai dengan constraint yang ada? Mana yang paling aman untuk boundary yang sudah ditetapkan? Mana yang paling mudah diverifikasi?

Diagram berikut memperjelas dua jalur yang kontras.

flowchart TD A[Mulai] --> B{Pilih pendekatan} B --> C[Minta satu jawaban] B --> D[Minta opsi] C --> E[AI berasumsi sendiri] E --> F[Output langsung: kode caching Redis] F --> G[Risiko: asumsi tersembunyi tidak terdeteksi] D --> H[AI berikan 3 opsi dengan trade-off] H --> I[Opsi 1: Cache-aside] H --> J[Opsi 2: Write-through] H --> K[Opsi 3: In-memory cache] I --> L[Trade-off: latency rendah, data basi] J --> M[Trade-off: konsisten, write lambat] K --> N[Trade-off: cepat, tidak shared] L --> O[Manusia bandingkan & pilih] M --> O N --> O O --> P[Keputusan berdasarkan informasi]

Trade-off adalah inti dari pekerjaan arsitek. Tidak ada solusi sempurna. Setiap pendekatan punya harga. Cache-aside pattern lebih sederhana tetapi bisa memberikan data basi. Write-through cache lebih konsisten tetapi memperlambat write operation. Cache di application layer lebih cepat tetapi tidak bisa dipakai oleh service lain. Dengan meminta opsi, arsitek bisa melihat harga dari setiap pilihan sebelum memutuskan.

Ini juga melatih kemampuan judgment. Semakin sering seorang arsitek membandingkan opsi, semakin tajam instingnya terhadap mana yang cocok untuk situasi tertentu. AI membantu mempercepat proses ini dengan menyajikan opsi dalam hitungan detik, tetapi keputusan tetap di tangan manusia. Di organisasi yang matang, pola ini menjadi standar: sebelum AI menulis satu baris kode, ia harus menyajikan opsi implementasi beserta trade-off-nya. Baru setelah arsitek memilih, AI boleh menulis kode untuk opsi yang dipilih.

Setelah opsi dipilih dan kode ditulis, langkah berikutnya adalah memeriksa apakah output AI benar-benar sesuai dengan yang diminta. Tidak semua yang keluar dari AI bisa dipercaya. Subbab berikutnya akan membahas apa yang sering salah dari output AI dan bagaimana cara mengauditnya.