Cara Saya Menggunakan AI Council untuk Menyelesaikan Masalah Engineering yang Ambigu

Satu asisten AI memang berguna. Namun, itu tidak cukup untuk arsitektur perangkat lunak yang kompleks.

Jika Anda menggunakan AI lebih dari sekadar autocomplete, Anda akan melihat sebuah pola. Satu model mengusulkan sebuah solusi. Terlihat bagus. Anda mengimplementasikannya. Kemudian, tiga hari kemudian, Anda menemukan cacat arsitektur yang masif.

Ini bukan kegagalan model tersebut. Ini adalah kegagalan proses Anda. Sebuah model tunggal jarang sekali mempertanyakan asumsinya sendiri.

Untuk menyelesaikan masalah yang ambigu, Anda membutuhkan AI Council. Ini bukan platform baru. Ini adalah sebuah alur kerja (workflow) di mana beberapa konteks AI meninjau sebuah proposal dari berbagai peran yang berbeda.

Tujuannya adalah mengubah penggunaan AI menjadi alur kerja engineering yang terkelola (governed).

Berikut adalah alur kerjanya:

• Problem Statement: Anda merumuskan masalahnya. • Architect Agent: Sebuah agen berbasis sumber (source-grounded) membuat proposal beserta pertimbangannya (trade-offs). • AI Council Critique: Berbagai peran AI meninjau proposal tersebut. • Feedback Synthesis: Sebuah agen mengevaluasi semua umpan balik dan mengidentifikasi konflik. • Objection Ledger: Anda melacak semua keberatan, tingkat keparahannya, dan penyelesaiannya. • Human Governance: Anda memutuskan apakah rencana tersebut sudah siap atau memerlukan putaran berikutnya. • Executor Agent: Konteks terpisah mengimplementasikan rencana tersebut. • Auditor Agent: Konteks ketiga mengaudit kode terhadap spesifikasi asli.

Kekuatannya berasal dari pemisahan peran. Jangan hanya bertanya "apa pendapatmu?" Tetapkan peran spesifik ke sesi AI yang berbeda:

  • System Thinker: Mengevaluasi risiko sistemik dan batasan.
  • Critical Reviewer: Mempertanyakan asumsi dan menemukan celah logika.
  • Simplifier: Menemukan kompleksitas yang tidak perlu.
  • Alternatives Reviewer: Menyarankan pendekatan yang berbeda.

Bagian terpenting adalah Objection Ledger. Tanpanya, umpan balik hanya akan menjadi opini yang samar. Sebuah buku catatan memaksa Anda untuk menyelesaikan setiap kekhawatiran. Anda menandai keberatan sebagai Open, Accepted, Rejected, atau Resolved. Ini menciptakan catatan keputusan yang dapat diaudit.

Anda tidak akan menjadi bottleneck copy-paste. Agen berbasis sumber melakukan sintesis. Anda bertindak sebagai Governor. Anda tidak melakukan pekerjaan manual. Anda yang memegang kendali (own the gates).

Anda memegang kendali atas keputusan:

  • Kapan harus berhenti melakukan iterasi.
  • Kapan harus menyetujui spesifikasi.
  • Kapan harus menerima risiko akhir.

Gunakan ini untuk refaktor berisiko tinggi atau arsitektur yang tidak jelas. Jangan gunakan untuk perbaikan bug yang sepele. Overhead ini hanya sepadan jika biaya dari desain yang salah sangatlah tinggi.

Mulailah dari hal kecil. Gunakan satu kritikus dan satu penyederhana. Anda akan langsung melihat nilainya.

Sumber: https://