Otoritas Desain AI
Kami berada di titik balik dalam pengembangan perangkat lunak. Diskusi sering berfokus pada yang AI menulis kode terbaik (Claude vs. ChatGPT) atau di mana AI harus tinggal (IDE atau CLI). Tetapi itu bukan pertanyaan yang tepat.
Masalahnya bukan menghasilkan dari kode. Itu adalah validasi darinya.
Jika kita mengadopsi AI sebagai “Vibe Coders” – dengan menunjukkan niat dan AI melakukan eksekusinya – kita menciptakan aliran besar perangkat lunak baru. Sekelompok agen AI dapat dalam satu menit menghasilkan lebih banyak kode daripada seorang pengembang senior yang dapat meninjau dalam seminggu. Manusia menjadi bottleneck.
Solusinya bukan lebih manusia. Solusinya adalah sebuah Otoritas Desain AI.
Dari Pengrajin ke Direktur Pabrik
Secara tradisional, “Design Authority” adalah sekelompok arsitek yang berkumpul seminggu atau sebulan sekali untuk menyetujui atau menolak sebuah desain. Dalam dunia yang pengembangan AI berkecepatan tinggi model itu sudah sangat usang. Ia terlalu lambat dan terlalu reaktif.
Jika kita beralih ke “Disposable Code” – perangkat lunak yang tidak kita refaktor terus-menerus, melainkan dibuang dan dibuat kembali ketika persyaratan berubah – maka peran kita berubah secara fundamental. Kita bukan lagi tukang batu yang menumpuk batu satu per satu. Kita adalah arsitek pabrik yang mencetak dinding.
Tapi siapa yang memeriksa apakah dinding itu berdiri lurus?
“Gauntlet”: Uji Api Otomatis
AI Design Authority bukanlah seorang individu, melainkan sebuah pipeline. Sebuah “Gauntlet” dimana setiap baris kode yang dihasilkan harus melewatinya untuk mencapai produksi. Proses ini tidak menggantikan tinjauan kode manusia dengan tidak ada, tetapi dengan sesuatu lebih baik.
Ini bekerja dalam tiga lapisan:
1. Kekuatan Eksekutif (Generasi)
Kami tidak meminta satu AI untuk memberikan solusi, kami meminta tiga. Kami membiarkan Gemini 3, GPT-5, dan model sumber terbuka (seperti Llama) bekerja secara paralel pada masalah yang sama. Ini mencegah pandangan terowongan dan memecahkan “kemalasan” yang kadang dialami LLM. Pendekatan ini juga diteliti secara ilmiah dan menunjukkan bahwa Anda dapat mencegah halusinasi AI serta membangun rantai yang sangat panjang tanpa kesalahan
2. Filter Keras (Hukum)
Tidak ada ruang untuk diskusi di sini. Kode harus dapat dikompilasi. Linters tidak boleh mengeluh. Dan yang krusial: Uji Kotak Hitam harus berhasil. Kami tidak menguji apakah fungsi bekerja secara internal (itu dapat dimanipulasi AI), kami menguji apakah sistem di luar melakukan apa yang seharusnya dilakukan. Gagal tes? Langsung ke tempat sampah.
3. Filter Lembut (Juri AI)
Ini adalah inovasi sejati. Solusi yang tersisa diajukan kepada “Voting AI” khusus. Agen ini tidak menulis kode, tetapi membaca kode. Ia dilatih pada prinsip arsitektur kami, persyaratan keamanan (OWASP, ISO), dan aturan kepatuhan (EU AI Act).
Ia memberi suara: “Solusi A lebih cepat, tetapi Solusi B lebih aman dan lebih sesuai dengan arsitektur mikroservis kami.”
Pemenang masuk ke produksi.
Trias Politika Perangkat Lunak
Model ini memaksa pemisahan kekuasaan yang sering tidak ada di banyak tim.
- Kekuasaan Legislatif (Arsitek): Arsitek menulis “Konstitusi”. Prompt, dokumen arsitektur (
project-description.md, rules.md, skills.md en principles.md), persyaratan keras. Arsitek menentukan apa kami membangun, siapa yang membangunnya, bagaimana, dan mengapa. - Kekuasaan Eksekutif (Agen Pengkodean): Mereka melaksanakan. Cepat, murah, dan di bawah naungan pengembang manusia.
- Kekuasaan Yudisial (Otoritas Desain): Lapisan AI independen yang mematuhi hukum.
Kesimpulan: Peran Baru Arsitek
Ini membebaskan kami dari tirani kesalahan sintaks dan memungkinkan kami fokus pada apa yang kami kuasai: berpikir sistemik. Penemuan kebenaran. Struktur dan pengambilan keputusan.
Pertanyaannya bukan apakah AI dapat menulis kode kami. Itu sudah selesai. Kode sebagian besar menjadi produk sekali pakai.
Pertanyaannya: Beranikah kamu mengendalikan kode melepaskannya, untuk dengan itu mengendalikan kualitas memperoleh kembali?
beritahu saya
