Kenapa AI app builder-mu menampilkan data palsu lebih dulu (dan kenapa itu langkah yang tepat)

Kamu mendeskripsikan sebuah aplikasi ke AI app builder-mu. Semenit kemudian kamu sedang menatap antarmuka yang berfungsi — halaman, tombol, sebuah tabel pengguna dengan nama-nama seperti “Alex Rivera” dan “Priya Shah”, harga-harga yang tidak masuk akal, sebuah “Pro Plan” yang tidak kamu minta. Tak ada yang tersimpan. Kalau kamu refresh, datanya masih ada. Kalau kamu menambahkan pengguna baru, ia menghilang.

Kelihatannya seperti trik sulap yang sebentar lagi berantakan. Bukan. Itu justru bagian baik dari proses build. Data mock di layarmu adalah langkah pertama yang disengaja, dan itulah alasan database yang datang berikutnya akan benar-benar cocok dengan aplikasi yang kamu inginkan.

Apa arti “data palsu lebih dulu” sebenarnya

Saat AI app builder mengambil brief-mu, ia tidak langsung ke database. Yang bagus menulis layar-layarnya lebih dulu, mengisinya dengan data pengganti yang masuk akal, lalu — dan baru kemudian — mendesain database agar cocok.

Data pengganti itu bukan hiasan. Ia adalah sebuah kontrak. Begitu aplikasimu mengatakan “setiap pesanan punya nama pelanggan, tiga baris item, satu total, dan satu status”, database yang dibangun berikutnya harus punya persis hal-hal itu, dalam bentuk yang persis sama. Layar-layarnya yang menentukan seperti apa datanya, bukan sebaliknya.

Ini terbalik dari cara seorang developer manusia biasanya memulai. Developer tradisional mendesain database lebih dulu, lalu membangun layar di atasnya. AI builder membalik itu, dan kebanyakan orang tidak menyadarinya — mereka cuma melihat pengguna palsu dan menyimpulkan bahwa builder-nya cuma pura-pura.

Kenapa urutan ini bekerja lebih baik dengan AI

Kami mencoba membangun database dan layar pada saat yang sama. Tidak berhasil. Inilah versi singkat alasannya.

Saat dua AI agent mengerjakan bagian-bagian berbeda dari satu aplikasi tanpa melihat output satu sama lain, mereka membuat tebakan yang tidak kompatibel. Agent antarmuka memutuskan pengguna punya field “name”. Agent database memutuskan pengguna punya field “fullName”. Keduanya kelihatan benar. Disatukan, tidak ada yang berfungsi. Agent ketiga didatangkan untuk menambal ketidakcocokannya. Ia ikut menebak juga. Sekarang ada tiga tebakan berkeliaran, dan aplikasi yang kamu pratinjau adalah semacam Frankenstein dari semuanya.

Perbaikannya hampir bikin malu: kerjakan satu hal dulu, baru yang lain. Antarmukanya dibangun. Ia menuliskan data apa yang ia butuhkan sebagai satu file berisi pengguna palsu, pesanan palsu, apa-pun-tema-aplikasimu palsu. Agent database membaca file itu dan mencocokkannya field demi field. Tanpa tebakan. Tanpa negosiasi. Tanpa ketidakcocokan.

Itulah kenapa AI app builder-mu bisa menampilkan aplikasi yang tampak jadi dalam semenit. Ia tidak memalsukan build-nya. Ia sudah menyelesaikan seperempat dari build — bagian yang menentukan segalanya — dan database adalah pekerjaan sepuluh detik berikutnya, bukan sepuluh jam berikutnya.

Apa yang dicari saat data palsu ada di layar

Inilah momen yang dilewatkan kebanyakan orang. Mereka melihat data pengganti dan mulai meminta perubahan warna. Padahal data pengganti itu adalah sebuah pertanyaan yang diajukan kepadamu. Bacalah.

Beberapa contoh hal yang perlu diperhatikan:

• Kosakata yang salah. Aplikasi yang kamu inginkan melacak “pengiriman”. Data penggantinya menyebutnya “pesanan”. Beritahu builder-nya. Kalau kamu biarkan saja sekarang, setiap layar, setiap field database, setiap laporan akan memakai kata yang salah — dan mengganti nama belakangan bukanlah operasi sekali klik di tools mana pun, sehebat apa pun klaim pemasarannya.
• Field yang hilang. Tagihan palsunya punya total dan tanggal. Kamu juga butuh nomor PO. Lebih baik menambahkannya sekarang, saat ada lima tagihan mock di layar, daripada setelah database-nya dibangun dan diisi dengan data pelanggan sungguhan.
• Bentuk yang salah. Data mock-nya menampilkan “1 pelanggan, 1 alamat”. Pelanggan aslimu punya beberapa alamat. Builder-nya tidak bisa menyimpulkan itu dari brief-mu. Beritahu sekarang, saat mengubah bentuknya tidak ada biayanya.
• Entitas yang mengejutkan. Builder-nya mengarang konsep “tim” yang tidak kamu minta, karena ia berasumsi aplikasi multi-user. Mungkin kamu memang menginginkannya. Mungkin tidak. Apa pun itu, putuskan sebelum database-nya dibangun di sekitarnya.

Aturan yang berguna: kalau aplikasimu punya kata benda yang tidak terwakili di data pengganti di layar, builder-nya belum mengetahuinya. Sebutkan sebelum kamu mengklik “save” di pratinjau pertama.

Kenapa urutannya penting untuk apa yang datang berikutnya

Begitu data penggantinya benar, build database menjadi mekanis. Builder-nya membaca data palsumu, menghasilkan skema yang cocok, menulis query yang sudah dicoba dipanggil oleh layar-layarnya, dan akhirnya menukar impor pengganti dengan yang asli. Layar-layar yang sama yang tadinya menampilkan pengguna palsu kini menampilkan apa pun yang benar-benar kamu masukkan.

Kamu biasanya bisa melihat pertukaran itu terjadi secara langsung. Sebuah halaman yang tadinya termuat seketika karena membaca file lokal kini punya status loading setengah detik — itulah layar yang berbicara dengan database sungguhan untuk pertama kalinya. Kebanyakan orang melewatkan ini dan tidak menyadari bahwa aplikasinya baru saja melewati garis dari “demo” menjadi “benda yang bisa menyimpan data sungguhan”.

Alasan ini bisa berhasil sama sekali adalah karena segala hal di hilirnya — desain database, query-nya, status loading-nya, status kosongnya — ditentukan oleh apa yang kamu lihat di layar selama fase pengganti. Kalau kamu menyetujui tiga kolom, kamu dapat tiga kolom. Kalau kamu menyetujui sebuah field “status” dengan nilai “draf” dan “terkirim”, persis itulah yang diterima database. Tidak ada langkah penerjemahan kedua tempat serah-terima antara desainer dan developer mengacaukan segalanya.

Sebuah uji kecil yang bisa kamu jalankan

Lain kali saat kamu membangun sesuatu, coba ini: saat data penggantinya muncul, ubah satu hal tentangnya sebelum meminta apa pun yang lain. Ganti nama sebuah field. Tambahkan satu kolom. Ganti “users” dengan “members”. Lalu perhatikan apa yang terjadi saat database-nya dibangun.

Kamu akan melihat perubahannya muncul di mana-mana — di desain database, di query-nya, di seed data yang dimasukkan builder saat aplikasinya selesai. Satu kata di tahap pengganti beriak ke seluruh aplikasi. Itulah leverage yang kamu miliki selama fase ini, dan itulah alasan “data palsu lebih dulu” bukanlah trik potong-jalan. Di situlah aplikasinya sebenarnya ditentukan.

Kalau kamu ingin menggali lebih dalam, tulisan terakhir kami tentang apa yang sebenarnya ada di dalam aplikasi buatan AI menelusuri bagian-bagian bergerak lainnya yang tidak bisa kamu lihat sekilas. Polanya sama: sebagian besar leverage-nya ada di bagian-bagian yang kelihatannya tidak penting.