Otoritas Desain AI
Kita berada pada titik balik dalam pengembangan perangkat lunak. Diskusinya sering kali tentang yang mana AI menulis kode terbaik (Claude vs. ChatGPT) atau dimana di mana AI harus ditempatkan (IDE atau CLI). Tetapi itu bukan pertanyaan yang tepat.
Masalahnya bukan menghasilkan dari kode. Masalahnya adalah validasi nya.
Jika kita menerima AI sebagai “Vibe Coders” — di mana kita menunjukkan niat dan AI melakukan pelaksanaan — kita menciptakan aliran besar perangkat lunak baru. Kawanan agen AI bisa menghasilkan lebih banyak kode dalam satu menit daripada yang dapat ditinjau oleh developer senior dalam seminggu. Manusia telah menjadi kendala.
Solusinya bukan lebih orang. Solusinya adalah sebuah Otoritas Desain AI.
Dari Tukang ke Direktur Pabrik
Secara tradisional, "Design Authority" adalah sekelompok arsitek yang berkumpul seminggu sekali atau sebulan sekali untuk menyetujui atau menolak sebuah desain. Di dunia pengembangan AI kecepatan-tinggi model itu sudah usang. Terlalu lambat dan terlalu reaktif.
Jika kita beralih ke "Disposable Code" — perangkat lunak yang tidak kita refactor terus-menerus, melainkan dibuang dan digenerasi ulang saat kebutuhan berubah — maka peran kita berubah secara mendasar. Kita bukan lagi tukang batu yang meletakkan batu satu per satu. Kita adalah perancang pabrik yang mencetak dinding.
Tapi siapa yang memastikan dinding itu tegak lurus?
The "Gauntlet": Sebuah Ujian Otomatis
AI Design Authority bukanlah seorang individu, melainkan sebuah pipeline. Sebuah "Gauntlet" yang harus dilalui setiap baris kode yang dihasilkan agar dapat masuk produksi. Proses ini tidak menggantikan code review manusia dengan tidak ada, melainkan dengan sesuatu yang lebih baik.
Ini bekerja dalam tiga lapisan:
1. Kekuasaan Eksekutif (Generasi)
Kita tidak meminta satu AI untuk solusi, kita meminta tiga. Kita menjalankan Gemini 3, GPT-5, dan model open-source (seperti Llama) secara paralel pada masalah yang sama. Ini mencegah pandangan sempit dan mematahkan "kemalasan" yang kadang terjadi pada LLM. Pendekatan ini juga diteliti secara ilmiah dan menunjukkan bahwa Anda dapat mencegah halusinasi AI dan membangun rantai yang sangat panjang tanpa kesalahan
2. Penyaring Keras (Hukum)
Di sini tidak ada ruang untuk perdebatan. Kode harus dikompilasi. Linters tidak boleh mengeluh. Dan yang krusial: Tes Kotak Hitam harus lulus. Kami tidak menguji apakah fungsi bekerja secara internal (itu bisa dimanipulasi oleh AI), kami menguji apakah sistem dari luar melakukan apa yang seharusnya. Gagal uji? Langsung dibuang.
3. Penyaring Lunak (Juri AI)
Inilah inovasi sebenarnya. Solusi yang tersisa diajukan ke "Voting AI" khusus. Agen ini tidak menulis kode, tetapi membaca kode. Ia dilatih berdasarkan prinsip arsitektur kami, persyaratan keamanan (OWASP, ISO) dan aturan kepatuhan (EU AI Act).
Ia memilih: "Solusi A lebih cepat, tetapi Solusi B lebih aman dan lebih sesuai dengan arsitektur mikroservis kami."
Pemenang masuk ke produksi.
Trias Politica Perangkat Lunak
Model ini memaksa pemisahan kekuasaan yang seringkali tidak ada dalam banyak tim.
- Kekuasaan Legislatif (Sang Arsitek): Sang Arsitek menulis "Konstitusi". Prompt, dokumen arsitektur (
project-description.md, rules.md, skills.md en principles.md), persyaratan ketat. Arsitek menentukan apa kita membangun, siapa yang membangunnya, bagaimana dan mengapa. - Kekuasaan Pelaksana (Agen Pengkodean): Mereka melaksanakan. Cepat, murah, dan di bawah pengawasan pengembang manusia.
- Kekuasaan Yudikatif (Otoritas Desain): Lapisan AI independen yang mematuhi hukum.
Kesimpulan: Peran Baru Sang Arsitek
Ini membebaskan kita dari tirani kesalahan sintaks dan membiarkan kita fokus pada keahlian kita: pemikiran sistem. Pencarian kebenaran. Struktur dan pengambilan keputusan.
Pertanyaannya bukan apakah AI dapat menulis kode kita. Topik itu sudah selesai. Kode sebagian besar akan menjadi produk sekali pakai.
Pertanyaannya adalah: Beranikah Anda menyerahkan kontrol atas kode melepaskannya, untuk dengan demikian kembali mendapatkan kendali atas kualitas mengembalikan kendali?
beri tahu saya
