Menguji GPT Astra untuk Desain Antarmuka: Catatan Teknis dan Batas Kemampuannya

Dua tahun belakangan, saya sering merasa lelah melihat hasil kode antarmuka buatan AI. Polanya hampir selalu seragam: kartu dengan sudut membulat berlebihan, gradien ungu neon yang tidak jelas tujuannya, serta susunan layout yang sekilas rapi di editor tetapi berantakan saat dibuka di layar ponsel.

Kelemahan itu biasanya bukan karena modelnya kurang pintar menulis sintaks CSS, melainkan karena ketiadaan disiplin sistemik. Model bahasa generasi sebelumnya cenderung menebak tampilan berdasarkan rata-rata template di internet. Ketika saya mencoba GPT Astra untuk beberapa tugas antarmuka di Freeclay, ada perubahan yang cukup terasa dalam cara model ini memproses batasan desain.

1. Mengunci Token Desain Tanpa Deviasi

Masalah paling menjengkelkan dari asisten kode AI terdahulu adalah inkonsistensi spasi dan warna. Di komponen navigasi ia memakai padding 16px, tetapi di kartu konten mendadak berubah menjadi 14px atau 22px tanpa alasan logis.

Kapasitas konteks Astra yang besar memungkinkan kita memasukkan seluruh berkas token proyek: variabel warna CSS, skala modular 4px dan 8px, hingga aturan radius border. Dalam pengujian saya, model ini mampu mempertahankan variabel semantic yang sama di seluruh komponen bersarang. Tombol sekunder di form pengaturan tetap mematuhi warna border dan transisi hover yang sama persis dengan tombol di modal utama.

2. Menerjemahkan Tangkapan Layar ke Struktur Layout

Saat diberikan tangkapan layar atau sketsa wireframe, Astra tidak langsung menebak posisi absolut. Ia membedah hierarki visual ke dalam struktur Flexbox dan CSS Grid modern yang adaptif.

Yang menarik, model ini tidak melupakan status interaktif dasar yang sering terlewat. Tombol yang dihasilkan sudah menyertakan state :focus-visible untuk aksesibilitas navigasi keyboard, transisi halus pada state hover, dan struktur skeleton loader saat data sedang dimuat.

3. Kelemahan yang Masih Sering Muncul

Meskipun lebih tertata, Astra tetap memiliki bias visual yang perlu diawasi secara teliti:

Teks abu-abu di mode gelap sering kali dipilih terlalu redup sehingga gagal memenuhi standar kontras WCAG AA. Selain itu, model ini masih gemar menambahkan wrapper div ekstra yang sebenarnya tidak diperlukan di DOM.

Model ini juga belum memiliki kepekaan rasa atau selera visual manusia. Ia bisa menyusun layout yang rapi secara matematis, tetapi ia tidak tahu apakah spasi antara judul dan paragraf terasa terlalu renggang saat dibaca di layar kecil.

4. Mengapa Verifikasi di Browser Sungguhan Tetap Wajib

Menghasilkan kode di teks editor hanyalah separuh pekerjaan. Kode yang terlihat sempurna secara teori sering kali menghasilkan bug rendering yang tak terduga di browser.

Alur kerja terbaik yang saya temukan adalah menghubungkan model dengan browser otomatis via Playwright atau Chrome DevTools. Kita me-render komponen pada tiga ukuran viewport (375px ponsel, 768px tablet, dan 1440px desktop), mengambil screenshot, lalu meminta model mengaudit hasil tangkapan layarnya sendiri.

Dengan cara ini, masalah teks terpotong atau margin yang meluber bisa langsung diperbaiki sebelum kodenya masuk ke repositori.

5. Kesimpulan Praktis

Astra tidak menggantikan peran desainer produk maupun engineer frontend. Pekerjaan merumuskan solusi pengguna, menentukan arsitektur informasi, dan memilih tone brand tetap berada di tangan manusia.

Namun untuk pekerjaan mekanis seperti menyusun scaffolding komponen dari wireframe, merapikan variasi button, dan memastikan token desain tetap konsisten, alat ini sangat menghemat waktu. Yang terpenting, jangan biarkan model berjalan tanpa pengawasan, dan selalu uji hasil akhirnya di layar nyata.