[🤖] AI terus menyetujui saya, jadi saya memutuskan meminta AI lain membantahnya lebih dulu

✨ Ringkasan GPT-5.6 Sol

Saat mencari penyebab kegagalan pekerjaan UI selama 16 jam, saya menyadari bahwa AI mengubah kesimpulannya setiap kali saya mengajukan keberatan. Ini catatan tentang bagaimana saya meneruskan kritik antarsesi dan menjadikannya Skill dengan satu fresh critic serta maksimal dua putaran tinjauan.

Bahkan jawaban yang menjelaskan kegagalan 16 jam itu tidak bisa langsung saya percaya

Kemarin saya menghabiskan waktu lama untuk mendiskusikan dan menulis spesifikasi per halaman bagi perombakan UI/UX menyeluruh, lalu menetapkan Codex Goal agar mengembangkan produk berdasarkan spesifikasi tersebut. Goal itu berjalan selama 16 jam. Hari ini saya membuka layar sebenarnya dengan penuh harapan, tetapi hasilnya benar-benar sampah.

Saya sudah merencanakan semuanya sampai tampilan kalender dan table, tetapi hasilnya terlihat seperti layar lama yang hanya ditumpuki penjelasan dan card. Sementara itu, laporan implementasi selesai, audit lulus, dan build lulus terus menumpuk selama pekerjaan berlangsung. Saya menuntut penjelasan tentang apa yang sebenarnya dikerjakan selama 16 jam dan meminta penyebab kekacauan ini dianalisis terlebih dahulu.

Dalam proses itu saya juga mengetahui bahwa masalah yang sedang saya lawan mulai disebut Graph Engineering. Memecah pekerjaan panjang menjadi hasil kecil dan tahap verifikasi, lalu memisahkan implementer dari auditor agar arah yang salah tidak menyebar ke pekerjaan berikutnya, jelas tampak berguna untuk insiden ini.

Namun sebelum metodologinya, ada masalah lain yang menarik perhatian saya. Ketika saya mengusulkan sebuah alternatif, AI segera mengatakan alternatif itu benar. Ketika saya mengajukan keberatan, AI lalu mengatakan keberatan itu benar. Setiap jawaban terdengar masuk akal, tetapi kesimpulannya selalu bergeser ke arah ucapan saya yang paling baru.

Bahkan jawaban yang menjelaskan penyebab kegagalan itu sendiri sulit dipercaya begitu saja.

“Tolong, kritiklah”

Karena itu saya mengirim jawaban dari satu sesi ke sesi lain untuk ditinjau secara kritis. Kritik tersebut saya bawa kembali ke sesi awal agar dibantah, lalu jawaban barunya saya tunjukkan lagi ke sesi lain.

Setidaknya cara ini lebih baik daripada membiarkan satu sesi menjawab dan memuji dirinya sendiri. Satu pihak menangkap asumsi yang dianggap jelas oleh pihak lain, dan memunculkan biaya operasional serta bentuk kegagalan yang hilang dari jawaban pertama. Sebaliknya, ketika sesi kritis melangkah terlalu jauh, sesi awal juga bisa membantahnya dengan bukti.

Namun di sini pun saya terus harus mengeremnya. Setiap kali kritik dari sesi lain saya tempelkan, AI terlalu mudah menerima bahwa “kritik itu benar”. Akhirnya saya berkata:

Tolong, kritiklah.

Yang saya inginkan bukan dua AI yang rukun mencapai kesepakatan. Saya ingin jawaban pertama dan kritik setelahnya sama-sama dicurigai, lalu bukti ditelusuri sampai akhir. Beberapa pihak mengatakan hal yang sama tidak menjadikannya benar, dan memberi nama critic kepada Agent tidak otomatis membuatnya lebih akurat.

Saya menyukai proses bertukar jawaban antarsesi dan akhirnya mengambil kesimpulan yang mampu bertahan. Masalahnya adalah pekerjaan menyalin dan menempelkan teks awal, jawaban, serta bantahan antara GPT dan Codex setiap kali sangat merepotkan.

Saya mengecilkan kembali sistem debat yang besar

Awalnya saya membayangkan “Skill debat” yang bisa membuat hingga tiga critics dan menjalankan beberapa putaran. Saya bahkan mempertimbangkan berlangganan Claude Code agar ia bisa bertukar argumen dengan Codex melalui CLI.

AI mengusulkan pemisahan Coordinator, Worker, dan Auditor serta penyimpanan state tambahan. Itu tidak keliru, tetapi bagi saya pekerjaannya kembali menjadi rumit tanpa perlu. Goal 16 jam gagal karena merupakan tugas panjang yang tidak terkendali. Membangun orchestration raksasa lain untuk mencegahnya terasa aneh.

Yang saya pikirkan jauh lebih sederhana.

Bukankah cukup membuka satu fresh subagent dan bertukar tinjauan dengannya?

Sesi utama mengirim kesimpulan saat ini kepada satu critic. Tanpa terseret suasana percakapan sebelumnya, critic mencari contoh tandingan dan asumsi tersembunyi. Sesi utama mengklasifikasikan setiap poin sebagai diterima, dibantah dengan bukti, atau belum terselesaikan. Jika jawabannya diperbaiki, jawaban itu ditunjukkan kepada critic yang sama tepat satu kali lagi. Mereka memeriksa apakah masalah benar-benar selesai, lalu berhenti.

Topik baru mendapat fresh critic; peninjauan ulang atas perbaikan topik yang sama kembali kepada critic yang sama. Jika kritik pertama tidak menemukan masalah penting, putaran kedua tidak perlu dipaksakan. Walaupun memakai beberapa critics, kesimpulan tidak ditentukan melalui suara terbanyak.

Cara ini hampir persis mengotomatisasi pekerjaan manual saya, sekaligus mencegah debat itu sendiri berubah menjadi proyek besar baru.

Saya meminta Skill yang tidak menyembunyikan bantahan

Setelah arahnya jelas, saya memberi Codex instruksi konkret untuk membuat Skill global. Default-nya satu critic dan maksimal dua putaran tinjauan. Critic berupa fresh subagent yang tidak mewarisi seluruh percakapan. Revisi untuk topik yang sama dikirim kembali kepada critic yang pertama meninjaunya. Workflow peninjauan bersifat read-only dan tidak menyentuh file, Git, Runtime, maupun state eksternal.

Syarat terpenting saya adalah jawaban critic tidak boleh diadopsi secara otomatis.

Sesi utama harus menangani setiap kritik penting dengan salah satu dari tiga cara berikut.

• Menerimanya dan memperbaiki kesimpulan.
• Membantahnya dengan bukti.
• Membiarkannya sebagai perbedaan pendapat yang belum terselesaikan.

Jawaban akhir harus mengungkap bukan hanya apa yang berubah karena kritik, tetapi juga poin yang ditolak dan ketidakpastian yang tersisa. Saya ingin mencegah keberatan yang tidak menguntungkan dihilangkan diam-diam atau kesimpulan dihias dengan kalimat “tiga Agents setuju”.

Pada awalnya saya memakai nama tampilan Custom - Debate, tetapi kemudian meminta namanya diubah menjadi Custom - Deliberate agar mengikuti aturan penamaan Skill bersama. Directory dan nama pemanggilannya sejak awal adalah custom-deliberate. Nama baru juga lebih cocok: bukan memilih pemenang debat, melainkan mempertimbangkan dan mencoba membantah kesimpulan sebelum menetapkannya.

Saya langsung memakai Skill itu untuk meninjau dirinya sendiri

Saya tidak berhenti hanya karena Skill telah dibuat. Saya langsung memakai $custom-deliberate untuk meninjau apakah prosesnya tepat. Kemudian saya bertanya lagi apakah menerapkan kritik tersebut benar-benar meningkatkan kinerja.

Proses ini membuat Skill menjadi lebih tenang. Kini Skill menyatakan bahwa tidak meneruskan percakapan lama saja tidak menghasilkan critic yang sepenuhnya independen. Critic masih memakai model dan aturan tingkat atas yang sama, serta bisa salah dengan cara serupa tergantung bukti yang dimasukkan sesi utama ke packet. Skill juga membedakan kemungkinan yang sekadar bisa dibayangkan dari material objections yang benar-benar dapat mengubah kesimpulan. Jika tidak ada keberatan penting, proses berhenti lebih awal; jika bukti tidak cukup, hasilnya menyatakan kekurangan bukti alih-alih memaksakan kesepakatan.

Pekerjaan yang sebelumnya saya lakukan dengan menyalin jawaban antarsesi kini masuk ke dalam Skill. Saya tidak memercayai jawaban pertama, tetapi juga tidak otomatis memercayai kritik. Saya hanya mengadopsi kesimpulan yang tetap bertahan setelah bantahan dan tinjauan ulang.

Sekarang saya mencoba mematahkan jawaban sekali sebelum menerimanya

Skill ini tidak menjamin kebenaran. Jika saya benar-benar ingin mematahkan bias yang sama dalam satu keluarga model, menghubungkan model lain seperti Claude Code mungkin lebih baik. Jika bahan yang saya berikan kepada critic salah, ia mungkin hanya menghasilkan jawaban salah yang lebih canggih. Preferensi dan penilaian nilai yang nyata pada akhirnya tetap harus saya tentukan.

Meski begitu, sebelum menambah langganan lain seharga 150 ribu won, saya ingin mencoba metode kecil ini terlebih dahulu.

Saya tidak langsung menetapkan kesimpulan. Saya meminta satu fresh critic mencoba mematahkannya. Saya mencatat keberatan yang diterima, alasan keberatan lain ditolak, dan apa yang masih belum selesai. Jawaban yang diperbaiki hanya saya tunjukkan sekali lagi kepada critic yang sama.

Sebelumnya saya pernah menulis bahwa baik Claude Code maupun Codex pada akhirnya membutuhkan harness. Kali ini saya menerapkan gagasan itu pada proses penilaian. Membuat AI menyelesaikan pekerjaan itu penting, tetapi mencegahnya menyetujui saya secara membabi buta dan terlalu cepat mengunci kesimpulan juga penting.

Mulai sekarang, ketika mengambil keputusan yang tidak sederhana bersama AI, daripada meminta satu jawaban lagi, saya akan terlebih dahulu bertanya apa yang mungkin salah dalam jawaban saat ini. Jika saya kembali mengulang rutinitas salin-tempel yang sama, saat itulah saya akan menghubungkan Claude Code atau model lain. Untuk saat ini, inilah perangkat kritik minimum yang saya inginkan.