Aplikasi sudah ada halaman login. Dashboard nampak kemas. Butang “Simpan” pun keluar mesej berjaya.
Tetapi kalau data hilang selepas buka semula aplikasi, adakah ia betul-betul sudah siap?
Itulah persoalan yang saya mahu letakkan di tengah-tengah AI coding challenge ini. Bukan berapa cantik aplikasi yang AI boleh hasilkan, tetapi berapa banyak fungsinya benar-benar boleh digunakan.
Nota ketelusan: Artikel ini menerangkan rancangan cabaran dan cara saya akan menilainya. Eksperimen 24 jam belum dilaporkan selesai, jadi belum ada keputusan, jumlah bug atau kadar kejayaan untuk dikongsikan.
Cabarannya: AI bina aplikasi daripada kosong
Untuk cabaran ini, saya memilih skop yang mudah difahami: aplikasi pengurusan tugasan kecil.
Pengguna perlu boleh mendaftar, log masuk, menambah tugasan, mengubahnya, menandakan selesai dan memadam rekod sendiri. Data mesti kekal selepas pengguna keluar dan masuk semula.
Saya sengaja mengecilkan skop. Kalau saya minta sistem lengkap dengan pembayaran, invois dan WhatsApp sekali gus, sukar untuk mengenal pasti apa sebenarnya yang berjaya dalam tempoh sehari.
Syarat paling penting: setiap fungsi perlu mempunyai bukti ujian. Jawapan AI “sudah siap” hanya bermaksud sudah tiba masa untuk saya menyemaknya.
Apa maksud 24 jam dalam cabaran ini?
Saya menetapkan 24 jam sebagai masa berlalu sejak arahan pertama diberikan, termasuk masa pemasangan, menunggu proses, membetulkan masalah dan menyediakan aplikasi untuk diakses melalui internet.
Masa kerja aktif manusia akan dicatat berasingan. Begitu juga kos alat AI dan hosting, jika ada. Kalau manusia menghabiskan berjam-jam membaiki kod, maklumat itu sebahagian daripada keputusan.
Pembahagian masa yang saya cadangkan:
| Tempoh | Fokus |
|---|---|
| Jam 1–2 | Tetapkan skop dan syarat lulus |
| Jam 3–8 | Bina antara muka, login dan database |
| Jam 9–14 | Uji aliran pengguna dan baiki fungsi |
| Jam 15–19 | Semak akses data dan pengendalian ralat |
| Jam 20–24 | Deployment, ujian semula dan dokumentasi |
Ini jadual sasaran, bukannya rekod masa eksperimen yang sudah berlaku.
Vibe coding: seronok membina, tetapi perlu faham hasilnya
Dalam artikel ini, saya menggunakan istilah vibe coding untuk pendekatan memberi arahan dalam bahasa biasa, menerima kod daripada AI dan mengubahnya melalui perbualan.
Contohnya: “Tambah butang untuk tandakan tugasan selesai.”
Cara ini memudahkan kita menerangkan idea. Namun, arahan yang ringkas boleh meninggalkan banyak persoalan: siapa boleh menekan butang itu, bagaimana perubahan disimpan dan apa berlaku jika sambungan terputus?
Sebab itu saya mahu menilai proses AI bina aplikasi melalui tindakan pengguna, bukan jumlah fail yang dihasilkan. Untuk bacaan berkaitan, terokai panduan AI praktikal.
Ujian pertama: login itu benar-benar berfungsi?
Halaman login yang cantik belum membuktikan identiti pengguna disahkan dengan betul.
Saya akan mencuba pendaftaran baharu, kata laluan salah, e-mel yang sudah digunakan dan proses logout. Selepas logout, saya akan cuba membuka semula halaman yang memerlukan akaun.
Aplikasi sepatutnya menolak akses tanpa sesi yang sah. Mesej ralat pula perlu jelas: pengguna patut tahu sama ada input salah atau sistem sedang bermasalah.
Saya juga akan memeriksa fungsi tetapan semula kata laluan jika ia termasuk dalam skop. Pautan yang kelihatan meyakinkan tetapi tidak menghantar apa-apa belum boleh dikira berfungsi.
Ujian kedua: data disimpan di mana?
Ada beza antara tugasan yang muncul pada skrin dengan tugasan yang benar-benar disimpan dalam database.
Ujian saya mudah: tambah satu tugasan, muat semula halaman, kemudian log keluar dan masuk semula. Selepas itu, buka akaun sama melalui pelayar lain.
Jika rekod hanya berada dalam storan pelayar, ia belum memenuhi syarat database untuk cabaran ini.
Saya juga akan mengubah dan memadam tugasan, kemudian menyemak hasil selepas halaman dimuat semula. Mesej “Berjaya disimpan” perlu sepadan dengan keadaan rekod sebenar.
Ujian ketiga: dua akaun, dua ruang data
Inilah ujian yang saya anggap wajib: cipta akaun A dan akaun B menggunakan data rekaan.
Akaun A menambah tugasan. Akaun B sepatutnya tidak boleh melihat, mengubah atau memadamnya, termasuk apabila permintaan dihantar terus kepada pelayan.
Menyembunyikan butang pada skrin sahaja tidak mencukupi. OWASP menerangkan bahawa kawalan akses perlu dikuatkuasakan pada bahagian pelayan yang dipercayai dan mengambil kira pemilikan rekod.
Bagi pembaca biasa, bayangkan setiap pengguna mempunyai laci sendiri. Login mengenal pasti siapa kita. Kawalan akses menentukan laci mana yang boleh kita buka.
Kedua-duanya perlu berfungsi.
Ujian keempat: cuba keadaan yang kurang sempurna
Pengguna tidak semestinya mengisi borang seperti yang pembangun jangkakan.
Saya akan menghantar tugasan kosong, memasukkan tajuk panjang, menekan butang simpan berulang kali dan mencuba skrin telefon. Saya juga akan memeriksa respons apabila permintaan gagal.
Contohnya, jika simpanan gagal, adakah teks yang sudah ditaip masih ada? Adakah pengguna mendapat penjelasan, atau aplikasi terus memaparkan kejayaan?
Bug bukan sekadar butang yang tidak bergerak. Mesej mengelirukan dan rekod berganda juga boleh mengganggu kerja sebenar.
Ujian kelima: berfungsi selepas deployment?
Deployment bermaksud menyediakan aplikasi supaya boleh diakses melalui internet.
Aplikasi yang berjalan pada komputer pembangunan masih perlu diuji semula pada alamat dalam talian. Saya akan mengulangi pendaftaran, login serta proses tambah, ubah dan padam tugasan di situ.
Saya juga mahu menyemak sambungan database, konfigurasi alamat aplikasi dan pengurusan rahsia seperti kunci pentadbir. Rahsia tersebut tidak sepatutnya terdedah dalam kod yang dihantar kepada pelayar.
Untuk cabaran awal, saya akan menggunakan data rekaan. Ujian asas ini pula tidak sama dengan audit keselamatan menyeluruh.
Berapa banyak yang betul-betul berfungsi?
Jawapan jujur setakat ini: belum boleh ditentukan sebelum ujian dilakukan.
Saya akan melaporkan keputusan menggunakan empat status: lulus, separa berfungsi, gagal dan belum diuji.
Setiap status perlu disertakan bukti ringkas: langkah ujian, hasil dijangka dan hasil sebenar. Saya juga akan merekodkan pembetulan manusia supaya sumbangan AI tidak dibesar-besarkan.
Jika login dan tugasan berjalan tetapi akaun B boleh membaca rekod akaun A, saya tidak akan menganggap aplikasi itu sedia digunakan untuk data peribadi.
Satu kegagalan kritikal boleh lebih penting daripada sepuluh fungsi kecil yang lulus.
FAQ ringkas
Bolehkah beginner menyertai AI coding challenge?
Boleh, dengan skop kecil dan data rekaan. Namun, kod yang tidak difahami masih perlu disemak, terutama bahagian akaun dan akses data.
Adakah aplikasi siap dalam 24 jam boleh terus dijual?
Tempoh pembangunan sahaja bukan ukuran kesiapsiagaan. Kebolehpercayaan, keselamatan, pemulihan data dan sokongan pengguna turut perlu dinilai.
Adakah AI boleh menguji kodnya sendiri?
AI boleh membantu menyediakan dan menjalankan ujian, bergantung pada alatnya. Tetapi keputusan perlu diperiksa dengan bukti dan kriteria yang ditetapkan.
Ukuran saya bukan sekadar “siap”
Saya mahu cabaran ini menjawab soalan yang lebih berguna daripada “AI boleh tulis kod atau tidak?”
Bolehkah pengguna menyelesaikan tugasnya? Adakah data kekal? Adakah akses pengguna lain disekat? Apakah yang masih memerlukan bantuan manusia?
Sehingga ada rekod ujian, saya memilih untuk menyimpan soalan itu terbuka. Itulah asas kredibiliti eksperimen ini: bezakan apa yang dirancang, apa yang diuji dan apa yang benar-benar terbukti.
Terokai juga koleksi tools praktikal atau kenali pendekatan saya belajar dan membina.
