Otoritas Desain AI

Kita berada di titik balik dalam pengembangan perangkat lunak. Diskusi sering kali berkisar tentang apa AI mana yang menulis kode terbaik (Claude vs. ChatGPT) atau di mana di mana AI harus berada (IDE atau CLI). Namun, itu adalah diskusi yang salah.

Masalah sebenarnya bukanlah generasi dari kode. Masalah sebenarnya adalah validasi penerapannya.

Jika kita merangkul AI sebagai “Vibe Coders” – di mana kita memberikan niat dan AI melakukan eksekusi – kita akan menciptakan aliran besar perangkat lunak baru. Sekelompok agen AI dapat menghasilkan lebih banyak kode dalam satu menit daripada yang dapat ditinjau oleh pengembang senior dalam seminggu. Manusia telah menjadi hambatan (bottleneck).

Solusinya bukan lebih manusia. Solusinya adalah Otoritas Desain AI.

Dari Pengrajin Menjadi Direktur Pabrik

Secara tradisional, "Otoritas Desain" adalah sekelompok kecil arsitek yang bertemu seminggu atau sebulan sekali untuk menyetujui atau menolak suatu desain. Di dunia pengembangan AI berkecepatan tinggi model itu sudah usang. Terlalu lambat dan terlalu reaktif.

Jika kita beralih ke "Kode yang Dapat Dibuang" – perangkat lunak yang tidak kita refaktor tanpa henti, tetapi kita buang dan buat ulang ketika persyaratan berubah – maka peran kita berubah secara fundamental. Kita bukan lagi tukang batu yang meletakkan batu demi batu. Kita adalah arsitek pabrik yang mencetak dinding.

Namun, siapa yang mengontrol apakah dinding-dinding itu tegak lurus?

The “Gauntlet”: Ujian Api Otomatis

Otoritas Desain AI bukanlah seseorang, melainkan sebuah alur kerja (pipeline). Sebuah “Tantangan” (Gauntlet) di mana setiap baris kode yang dihasilkan harus berjuang melewatinya untuk mencapai produksi. Proses ini tidak menggantikan peninjauan kode manusia dengan tidak ada, melainkan dengan sesuatu yang lebih baik.

Ini bekerja dalam tiga lapisan:

1. Kekuatan Eksekutif (Generasi)
Kami tidak meminta satu AI untuk memberikan solusi, kami meminta tiga. Kami membuat Gemini 3, GPT-5, dan model sumber terbuka (seperti Llama) bekerja secara paralel pada masalah yang sama. Ini mencegah pandangan terowongan dan mengatasi 'kemalasan' yang terkadang dialami oleh LLM. Pendekatan ini juga diteliti secara ilmiah dan menunjukkan bahwa Anda dapat mencegah halusinasi AI dan membangun rantai yang sangat panjang tanpa kesalahan

2. Filter Keras (Hukum)
Di sini, tidak ada ruang untuk diskusi. Kode harus dapat dikompilasi. Linter tidak boleh mengeluh. Dan yang terpenting: Uji Kotak Hitam harus berhasil. Kami tidak menguji apakah fungsi tersebut bekerja secara internal (karena AI dapat memanipulasinya), kami menguji apakah sistem tersebut melakukan apa yang seharusnya dilakukan dari luar. Gagal dalam pengujian? Langsung buang ke tempat sampah.

3. Filter Lunak (Juri AI)
Inilah inovasi sesungguhnya. Solusi yang tersisa disajikan kepada "AI Pemungutan Suara" khusus. Agen ini tidak menulis kode, tetapi membaca kode. Agen ini dilatih berdasarkan prinsip arsitektur kami, persyaratan keamanan (OWASP, ISO), dan aturan kepatuhan (EU AI Act).
Agen ini memberikan suara: “Aplikasi A lebih cepat, tetapi Aplikasi B lebih aman dan lebih sesuai dengan arsitektur microservices kami.”

Pemenang akan masuk ke tahap produksi.

Trias Politica Perangkat Lunak

Model ini memaksakan pemisahan kekuasaan yang sering kali tidak ada dalam banyak tim.

• Kekuasaan Legislatif (Sang Arsitek): Arsitek menulis “Konstitusi”. Prompt, dokumen arsitektur (project-description.md, rules.md en principles.md), persyaratan keras. Arsitek menentukan apa cara kita membangun dan mengapa.
• Kekuasaan Eksekutif (Agen Pengkodean): Mereka mengeksekusi. Cepat, murah, dan di bawah naungan pengembang manusia.
• Kekuasaan Yudikatif (Otoritas Desain): Lapisan AI independen yang menguji kepatuhan terhadap hukum.

Kesimpulan: Peran Baru Arsitek

Ini membebaskan kita dari tirani kesalahan sintaks dan memungkinkan kita untuk fokus pada keahlian kita: Pemikiran Sistem. Penemuan Kebenaran. Struktur dan pengambilan keputusan.

Pertanyaannya bukan apakah AI dapat menulis kode kita. Itu sudah diputuskan. Kode sebagian besar akan menjadi sekali pakai.
Pertanyaannya adalah: Beranikah Anda melepaskan kendali atas implementasi untuk kemudian merebut kembali kendali atas kualitas itu?