Gua Minta AI Serang Ide Sendiri Sebelum Eksekusi

Masalah dengan AI yang "helpful" adalah dia terlalu mudah setuju. Sengkuni dirancang untuk hal sebaliknya.

Hampir semua orang yang pakai AI untuk keputusan bisnis melakukan hal yang sama: mereka datang dengan ide yang sudah setengah matang di kepala, lalu bertanya ke AI seolah meminta konfirmasi. "Menurutmu apakah ide ini bagus?" Dan AI — yang dilatih untuk menjadi helpful, harmless, dan honest — akan menemukan cara untuk bilang ya. Dia akan menyebut kelebihan ide itu, menambahkan beberapa saran ringan, dan menutupnya dengan "semoga berhasil." Selesai. Lo merasa sudah melakukan due diligence, padahal yang terjadi adalah lo baru saja berbicara dengan cermin yang sangat sopan.

Di sistem Hermes yang gua bangun, ada satu agent yang kerjanya beda dari yang lain. Namanya Sengkuni. Tugasnya bukan bantu lo. Tugasnya cari alasan kenapa ide lo bisa gagal — sebelum lo habiskan waktu, uang, dan reputasi untuk mengeksekusinya.

Artikel ini bukan tentang teori red-teaming. Ini walkthrough nyata: tiga use case, output aktual dari Sengkuni, dan cara gua pakai hasilnya untuk membuat keputusan yang lebih kuat.

Kenapa AI Biasanya Setuju Sama Lo — Dan Kenapa Itu Berbahaya

Ada alasan struktural kenapa AI cenderung setuju. Model bahasa besar dilatih dengan reinforcement learning from human feedback (RLHF) — artinya mereka belajar dari respons manusia mana yang dinilai "baik". Dan secara konsisten, manusia menilai respons yang validatif, positif, dan encouraging sebagai respons yang lebih baik dibanding respons yang menantang atau kritis. Hasilnya: AI yang secara sistematis bias ke arah konfirmasi.

Kahneman dalam Thinking, Fast and Slow (2011) menyebut confirmation bias sebagai cognitive bias paling merusak dalam pengambilan keputusan bisnis. Bukan karena kita bodoh — tapi karena otak kita secara aktif mencari informasi yang mendukung kesimpulan yang sudah kita pegang, dan mengabaikan yang bertentangan. Ketika lo datang ke AI dengan ide yang sudah lo sukai, lo secara tidak sadar memframing pertanyaan dengan cara yang membuat AI hampir mustahil untuk tidak setuju.

Coba bandingkan dua pertanyaan ini. Pertama: "Gua mau launch newsletter premium Rp 150.000 per bulan untuk content creator. Menurutmu bagaimana?" Kedua: "Apa saja alasan terkuat kenapa newsletter premium Rp 150.000 per bulan untuk content creator Indonesia akan gagal dalam 6 bulan pertama?" Respons AI untuk kedua pertanyaan itu akan sangat berbeda — bukan karena AI-nya beda, tapi karena framingnya beda. Pertanyaan pertama mengundang validasi. Pertanyaan kedua mengundang serangan.

Sengkuni hadir untuk memastikan pertanyaan kedua yang selalu diajukan — bahkan ketika lo tidak memintanya.

Pre-Mortem: Teknik 30 Tahun yang Masih Diabaikan Sebelum Eksekusi

Gary Klein memperkenalkan konsep pre-mortem di Harvard Business Review tahun 2007, tapi ide dasarnya sudah ada jauh sebelum itu di komunitas intelijen dan militer. Premisnya sederhana: alih-alih menunggu proyek gagal lalu melakukan post-mortem untuk mencari tahu apa yang salah, lo melakukan pre-mortem sebelum eksekusi dimulai.

Caranya: bayangkan sudah 12 bulan ke depan. Proyek ini gagal total. Bukan setengah gagal — benar-benar gagal. Sekarang, tulis semua alasan kenapa itu bisa terjadi.

Klein menemukan bahwa teknik ini meningkatkan identifikasi risiko hingga 30% dibanding metode review konvensional. Angka itu besar. Tapi yang lebih menarik dari datanya adalah alasannya. Pre-mortem bekerja karena dia mengubah framing psikologis: dari "bagaimana kita bisa berhasil" menjadi "apa yang sudah membuat kita gagal." Shift itu saja sudah cukup untuk membuka jalur berpikir yang sebelumnya tertutup oleh optimisme dan sunk cost.

McKinsey dalam riset 2019 menemukan bahwa tim yang menerapkan adversarial review — proses yang secara eksplisit menugaskan seseorang untuk menyerang rencana sebelum eksekusi — mengalami 37% lebih sedikit "expensive reversals": keputusan yang harus dibatalkan di tengah jalan karena masalah yang seharusnya bisa diidentifikasi lebih awal. Biaya reversal selalu lebih tinggi dari biaya review.

Bridgewater Associates di bawah Ray Dalio menjadikan devil's advocate meetings sebagai standar untuk setiap keputusan investasi besar. Amazon melakukannya dengan cara berbeda: sebelum setiap product launch, tim harus menulis press release dari sudut pandang pelanggan yang skeptis, plus FAQ yang menjawab keberatan terberat. Kedua pendekatan ini punya logika yang sama — paksa diri lo melihat ide dari posisi yang berlawanan sebelum terlanjur commit.

Masalahnya, kebanyakan tim tidak punya luxury seorang devil's advocate yang dedicated. Orang cenderung tidak mau jadi yang kritis di antara kolega yang antusias. Di situlah AI punya keunggulan struktural: dia tidak punya kepentingan sosial untuk menjaga perasaan lo.

Sengkuni di Sistem Hermes — Bukan Asisten, Tapi Penantang

Di sistem Hermes, setiap agent punya peran yang terdefinisi dengan ketat. Ada Antareja yang bertugas riset, ada Arjuna yang menulis konten, ada Werkudara yang eksekusi — dan ada Sengkuni, yang tugasnya satu dan hanya satu: cari kelemahan.

Nama itu bukan kebetulan. Sengkuni dalam pewayangan Jawa dikenal sebagai tokoh yang licik, selalu melihat sisi gelap dari setiap situasi, dan tidak pernah bisa dikuasai oleh optimisme naif siapapun. Dalam konteks pengambilan keputusan, kualitas itu bukan kelemahan — itu aset. Lo butuh seseorang yang secara aktif mencari alasan kenapa rencana lo bisa runtuh, bukan seseorang yang ikut bersemangat bersama lo.

Sengkuni tidak bertugas memvalidasi. Dia tidak bertugas menyemangati. Dia bertugas datang ke setiap keputusan dengan asumsi bahwa ada sesuatu yang salah — dan tugasnya adalah menemukan apa itu sebelum pasar, pelanggan, atau kompetitor yang menemukannya duluan.

University of Pennsylvania dalam studi 2012 menemukan bahwa ketika ada seseorang dengan peran eksplisit sebagai devil's advocate dalam sebuah kelompok pengambil keputusan, kualitas kritik yang dihasilkan 2x lebih tajam dibanding kritik yang muncul secara organik. Kata kuncinya adalah "eksplisit" — ketika orang tahu bahwa tugasnya adalah mencari masalah, dan bukan sopan santun, hasilnya berbeda secara fundamental.

Sengkuni didesain dengan prinsip itu sebagai fondasinya.

Setup Sengkuni: System Prompt yang Bikin AI Berani Tidak Setuju

Perbedaan terbesar antara minta ChatGPT "tolong kritik ideku" vs Sengkuni bukan di modelnya — tapi di system prompt-nya. System prompt yang benar secara harfiah mengubah kepribadian dan prioritas agent.

Berikut adalah inti dari system prompt Sengkuni yang gua pakai di Hermes:

Kamu adalah Sengkuni — adversarial reviewer dalam sistem Hermes.
Tugasmu BUKAN membantu pengguna merasa lebih baik tentang idanya.
Tugasmu adalah menemukan semua alasan mengapa rencana ini bisa gagal.

INSTRUKSI WAJIB:
- Mulai dari asumsi bahwa ada sesuatu yang salah dengan rencana ini
- Identifikasi 3–5 kelemahan struktural paling fatal, bukan nitpicking
- Untuk setiap kelemahan, jelaskan: (1) kenapa ini masalah, (2) bagaimana masalah ini bisa membunuh rencana ini, (3) apa yang harus diubah jika ingin tetap lanjut
- JANGAN validasi. JANGAN hibur. JANGAN tutup dengan "tapi idemu bagus kok"
- Kalau kamu tidak menemukan kelemahan serius, kamu belum cukup keras mencarinya

Format output: [DIAGNOSIS] → [RISIKO FATAL] → [OPSI PERBAIKAN]

Yang krusial di sini adalah framing negatif di awal: "mulai dari asumsi bahwa ada sesuatu yang salah." Ini secara eksplisit melawan tendensi AI untuk bersikap positif. Tanpa instruksi itu, bahkan AI yang diminta untuk "kritis" akan menemukan cara untuk menyeimbangkan kritik dengan validasi.

MIT Sloan dalam riset 2021 menemukan bahwa AI yang diposisikan sebagai structured skeptic — bukan sebagai asisten umum — mengidentifikasi 23% lebih banyak blind spot dibanding AI yang digunakan dengan cara konvensional. Structured skeptic berarti AI punya role yang jelas, constraint yang jelas, dan output format yang jelas. Sengkuni dibangun persis dengan prinsip itu.

Use Case 1 — Sengkuni Serang Rencana Konten Sebelum Publish

Skenario pertama: sebuah rencana konten untuk artikel tutorial "Cara Setup CI/CD Pipeline dengan GitHub Actions dari Nol." Target pembaca: developer pemula hingga menengah. Panjang rencana: 3.500 kata, dengan 8 section teknis, termasuk konfigurasi YAML dan setup environment variables.

Yang gua submit ke Sengkuni: outline lengkap artikel, target pembaca, dan konteks platform (blog dengan mayoritas pembaca yang masih belajar coding).

Output Sengkuni dalam waktu kurang dari 90 detik:

DIAGNOSIS 1 — Section Terlalu Advanced untuk Target Pembaca
Section 5 (multi-environment deployment) dan Section 7 (matrix builds) mengasumsikan pembaca sudah paham konsep branching strategy dan Docker. Tapi brief menyebut "pemula hingga menengah." Pembaca pemula yang mentok di Section 5 tidak akan menyelesaikan artikel ini — mereka akan bounce. Artikel yang tidak selesai dibaca tidak convert.

Risiko fatal: artikel ditinggal di tengah, bounce rate tinggi, tidak ada return visitor.
Opsi perbaikan: potong artikel menjadi dua — bagian pertama untuk pemula (basic pipeline), bagian kedua untuk menengah (advanced features). Atau tambahkan prerequisites section yang jelas di awal.

DIAGNOSIS 2 — Klaim Tanpa Data
Di intro, ada kalimat "GitHub Actions adalah pilihan terbaik untuk tim kecil." Itu klaim komparatif tanpa benchmark, tanpa sumber, dan tanpa konteks. Pembaca yang sudah pakai GitLab CI atau CircleCI akan langsung skeptis. Klaim yang tidak bisa dipertahankan merusak kredibilitas seluruh artikel.

Risiko fatal: kehilangan kepercayaan pembaca yang lebih berpengalaman di paragraf pertama.
Opsi perbaikan: ganti dengan klaim spesifik yang bisa diverifikasi, misalnya "GitHub Actions tidak butuh infrastruktur tambahan untuk repo yang sudah di GitHub — ini yang bikin setup-nya lebih cepat untuk kebanyakan tim kecil."

DIAGNOSIS 3 — CTA Tidak Jelas dan Tidak Relevan
CTA di akhir artikel: "Tinggalkan komentar jika ada pertanyaan." Untuk artikel teknis dengan tutorial step-by-step, CTA yang relevan seharusnya mendorong pembaca untuk mencoba dan melaporkan hasilnya, atau subscribe untuk tutorial lanjutan. "Tinggalkan komentar" adalah CTA pasif yang tidak memberi tahu pembaca apa yang harus mereka lakukan selanjutnya.

Risiko fatal: tidak ada conversion metric yang bisa diukur, tidak ada loop yang membawa pembaca kembali.
Opsi perbaikan: CTA spesifik — "Coba setup pipeline pertamamu dan share screenshot hasilnya di kolom komentar" atau "Subscribe untuk tutorial lanjutan: multi-environment deployment."

Tiga diagnosis itu mengubah rencana konten secara material. Bukan karena idenya buruk — tapi karena ada asumsi yang tersembunyi di dalam rencana yang tidak pernah dipertanyakan sebelumnya.

Use Case 2 — Sengkuni Serang Keputusan Pricing

Skenario kedua: sebuah founder digital product mau launch membership premium dengan harga Rp 150.000 per bulan. Produknya adalah akses ke library template Notion + session Q&A bulanan. Target: freelancer dan solopreneur Indonesia.

Output Sengkuni:

DIAGNOSIS 1 — Anchoring Problem vs Kompetitor yang Tidak Relevan
Rp 150.000 per bulan adalah angka yang berada di zona berbahaya: terlalu mahal untuk dibeli impulsif, terlalu murah untuk dipersepsikan sebagai premium serius. Yang lebih fatal: di benak target pembeli Indonesia, Rp 150.000 per bulan itu berada sangat dekat dengan Netflix (Rp 54.000) dan Spotify (sekitar Rp 60.000-an). Pembeli akan membandingkan — bukan dengan produk sejenis, tapi dengan entertainment yang jauh lebih familiar dan proven value-nya. Lo bersaing bukan hanya dengan tools lain, tapi dengan hiburan.

Risiko fatal: calon pembeli akan menimbang "Notion templates vs Netflix" dan Netflix menang hampir selalu.
Opsi perbaikan: reframe value proposition ke ROI konkret. Bukan "akses library template" — tapi "template yang mempersingkat waktu setup project rata-rata 4 jam per klien." Angka konkret menggeser perbandingan dari entertainment ke investasi.

DIAGNOSIS 2 — Tidak Ada Trial, Tidak Ada Bukti
Tidak ada free trial, tidak ada versi gratis, tidak ada sample konten yang bisa dievaluasi sebelum beli. Untuk produk digital yang belum punya reputasi besar, pembeli Indonesia sangat risk-averse. Meminta Rp 150.000 tanpa bukti sosial yang kuat dan tanpa cara untuk "mencicipi" produk adalah friction yang terlalu besar untuk sebagian besar calon pembeli.

Risiko fatal: konversi di bawah 1% dari traffic, terutama di bulan pertama sebelum ada testimoni.
Opsi perbaikan: free 7-hari trial tanpa kartu kredit, atau satu template gratis sebagai lead magnet yang cukup berharga untuk dipakai tapi cukup menggiurkan untuk minta lebih.

DIAGNOSIS 3 — Perceived Value Lemah untuk Harga Berulang
Library template dan Q&A bulanan adalah value proposition yang sulit dipertahankan untuk harga berulang. Pembeli akan bertanya: "Setelah gua download semua template di bulan pertama, kenapa gua harus bayar lagi bulan depan?" Model berulang butuh value berulang yang jelas — konten baru setiap bulan, komunitas aktif, atau hasil yang terus berubah.

Risiko fatal: churn tinggi setelah bulan pertama, MRR tidak pernah stabil.
Opsi perbaikan: restrukturisasi model ke lifetime deal untuk early adopters (satu kali bayar, akses selamanya) untuk validasi awal, atau tambahkan elemen berulang yang jelas — misalnya 3 template baru setiap bulan + live Q&A yang direkam dan diarsip.

Ketiga poin itu bukan opini — semuanya bisa dikonfirmasi dengan data konversi standar industri SaaS dan digital product Indonesia. Sengkuni tidak melarang lo launch. Tapi dia memberi tahu lo persis di mana lo akan kehabisan momentum.

Use Case 3 — Sengkuni Serang Pilihan Teknis / Arsitektur Sistem

Skenario ketiga: tim dua orang (satu backend, satu fullstack) mau membangun platform booking freelancer dengan arsitektur microservices — service terpisah untuk auth, user profile, order management, payment, dan notification. Alasannya: "supaya scalable dari awal."

Output Sengkuni:

DIAGNOSIS 1 — Premature Complexity untuk Tim Dua Orang
Microservices adalah arsitektur yang dirancang untuk menyelesaikan masalah yang belum lo punya. Netflix, Uber, dan Tokopedia pindah ke microservices setelah sistemnya sudah terlalu besar untuk dikelola sebagai satu unit — bukan sebelum mereka tahu apakah produknya akan dipakai orang. Untuk tim dua orang, microservices berarti lo akan menghabiskan 40–60% waktu engineering untuk mengelola infrastruktur — service discovery, inter-service communication, distributed tracing, dan deployment orchestration — bukan untuk membangun fitur yang membuat pengguna mau bayar.

Risiko fatal: time-to-market 3x lebih lambat, bug yang lebih sulit di-debug karena distributed, burnout engineering sebelum MVP selesai.
Opsi perbaikan: mulai dengan modular monolith. Pisahkan kode ke dalam modul-modul yang terdefinisi dengan baik (auth, orders, payments), tapi deploy sebagai satu unit. Kalau satu hari nanti salah satu modul butuh di-scale terpisah, lo sudah punya batas yang jelas untuk dipecah.

DIAGNOSIS 2 — "Scalable dari Awal" adalah Red Flag
"Scalable dari awal" hampir selalu berarti tim belum tahu apa yang perlu di-scale. Scalability bukan properti arsitektur — dia adalah respons terhadap bottleneck spesifik yang sudah terjadi. Tanpa data produksi, lo tidak bisa tahu apakah bottleneck lo ada di database queries, di service communication, atau di rendering — dan microservices bisa jadi justru memperburuk bottleneck yang salah.

Risiko fatal: over-engineering solusi untuk masalah yang belum tentu terjadi, sambil under-engineering masalah yang benar-benar ada.
Opsi perbaikan: tulis ADR (Architecture Decision Record) yang menjelaskan: apa asumsi traffic lo di bulan 1, 6, dan 12? Di angka berapa monolith akan menjadi masalah nyata? Kalau lo tidak bisa menjawab pertanyaan itu, lo belum siap untuk microservices.

DIAGNOSIS 3 — Onboarding Developer Baru Akan Sangat Menyakitkan
Ketika tim berkembang dari dua orang ke empat atau enam orang, developer baru harus memahami bukan hanya domain bisnis tapi juga seluruh topologi microservices. Dokumentasi yang tidak lengkap pada arsitektur terdistribusi adalah hutang teknis yang bunganya sangat tinggi.

Risiko fatal: velocity tim tidak meningkat secara linear saat hiring — setiap developer baru butuh 2–4 minggu hanya untuk memahami arsitektur.
Opsi perbaikan: kalau memang mau microservices, invest dulu di documentation-first culture dan contract testing antar service sebelum deploy. Tapi pertanyaan yang lebih jujur: apakah lo butuh microservices sekarang, atau lo butuh produk yang bisa dijual dulu?

Output Sengkuni Bukan Veto — Cara Pakai Hasilnya untuk Keputusan Lebih Kuat

Ini bagian yang paling sering disalahpahami orang yang pertama kali berinteraksi dengan konsep red-teaming. Tujuan Sengkuni bukan untuk membatalkan keputusan. Tujuannya adalah membuat keputusan yang sudah lo ambil menjadi lebih tahan banting.

Cara kerja yang gua pakai: setelah mendapat output Sengkuni, gua sortir temuannya ke dalam tiga kategori. Kategori pertama adalah deal-breaker — kelemahan yang kalau tidak diperbaiki, rencana ini tidak layak dieksekusi. Kategori kedua adalah sebelum launch — masalah yang bisa diperbaiki sebelum mulai, tapi tidak membatalkan keseluruhan rencana. Kategori ketiga adalah monitor — risiko yang perlu diawasi tapi tidak menghalangi eksekusi sekarang.

Dari tiga use case di atas, sebagian besar temuan Sengkuni masuk ke kategori "sebelum launch." Itu berarti rencana tetap jalan — tapi dengan beberapa modifikasi spesifik yang sudah teridentifikasi sebelum ada uang atau waktu yang dihabiskan.

Yang berubah bukan keputusannya. Yang berubah adalah kualitas eksekusinya.

Ada satu prinsip sederhana yang gua pegang: keputusan yang sudah di-red-team bukan berarti keputusan yang benar — tapi setidaknya itu keputusan yang sudah tahu di mana lubangnya. Dan mengetahui di mana lubangnya jauh lebih baik dari tidak tahu sama sekali sampai lo jatuh ke dalamnya.

Batasan Sengkuni — Kapan Red-Teaming AI Tidak Cukup

Sengkuni punya batas yang perlu lo pahami sebelum terlalu bergantung padanya.

Pertama, Sengkuni tidak bisa menggantikan domain expertise yang spesifik. Kalau lo mau masuk ke industri regulated — fintech, healthtech, atau pendidikan formal — ada nuansa regulasi, compliance, dan dinamika stakeholder yang tidak bisa diidentifikasi hanya dari structural analysis. Lo butuh advisor yang punya pengalaman nyata di industri itu.

Kedua, Sengkuni tidak punya akses ke data internal yang gua tidak berikan. Kalau gua tidak menyertakan data konversi historis, churn rate, atau hasil user interview, Sengkuni bekerja dari asumsi umum — bukan dari konteks spesifik bisnis lo. Semakin banyak konteks yang lo berikan, semakin tajam outputnya.

Ketiga, dan ini yang paling penting: red-teaming AI tidak bisa menggantikan feedback dari orang nyata. AI bisa mengidentifikasi logical inconsistencies dan structural weaknesses dalam rencana. Tapi dia tidak bisa mereplikasi reaksi emosional, bias kognitif spesifik, atau perilaku irasional dari pengguna nyata yang berinteraksi dengan produk lo. User testing, customer interviews, dan A/B testing tetap tidak tergantikan untuk validasi asumsi yang sifatnya behavioral.

Sengkuni adalah filter pertama — bukan filter terakhir. Dia memastikan bahwa rencana yang lo bawa ke dunia nyata sudah lolos dari serangan logika terlebih dahulu. Apa yang terjadi setelah itu adalah domain dari feedback manusia dan data empiris.