Bila orang tanya "berapa leads KISEW dapat?", jawapan aku selalu berubah ikut siapa yang tanya. Kalau vendor tanya, aku cakap 807. Kalau bos tanya, aku cakap 2,949. Dua-dua betul — cuma satu tu angka hari keempat, satu lagi angka penuh sepuluh hari.

Dan itu sebenarnya masalah pertama yang aku hadapi bila nak tulis breakdown ni: angka sorang-sorang tak bermakna apa-apa tanpa konteks. Jadi biar aku cerita dari mula, bukan dari nombor.

MAHA 2026 di MAEPS Serdang, Sarawak Pavilion. Sepuluh hari. Aku dapat satu booth, satu skrin, dan satu andaian yang salah: "orang datang exhibition nak tengok produk, bukan main game."

Andaian tu pecah dalam masa empat jam pertama.

Apa KISEW ni sebenarnya

KISEW bukan satu app. Ia tiga benda yang berkongsi satu pangkalan data:

Satu — kiosk. Skrin besar di booth. Orang datang, taip nama dan nombor telefon, kemudian tanya apa-apa pasal Sarawak kepada chatbot. Bilingual, BM dan English, sebab separuh pelawat datang dari luar.

Dua — quiz. Sepuluh soalan pasal Sarawak. Passing mark tujuh. Dua cubaan. Kalau lulus, boleh spin gacha untuk menang hadiah.

Tiga — redemption. Hadiah bukan dipegang di tangan. Ia masuk sebagai claim code dalam sistem. Pemenang pergi ke kaunter, staf scan, sistem sahkan, baru hadiah diserahkan.

Yang ketiga tu bunyi macam detail kecil. Ia sebenarnya sebab utama sistem ni tak jadi huru-hara.

Kenapa gacha, bukan bagi hadiah terus

Ini bukan keputusan marketing. Ini keputusan operasi.

Kalau kau bagi hadiah terus kepada sesiapa yang datang, kau akan habis stok dalam dua hari dan tak dapat apa-apa data. Kalau kau bagi hadiah selepas isi borang, orang isi borang dengan nombor telefon palsu.

Gacha buat satu benda: ia tukar masa dengan data. Orang sanggup duduk sepuluh minit jawab quiz sebab ada peluang menang. Dalam sepuluh minit tu, kau dapat nombor telefon yang betul (sebab ia diikat pada claim code), nama, dan satu rekod interaksi yang kau boleh guna kemudian.

Dan yang paling penting — kau dapat alasan untuk orang kembali. Setiap hari ada Happy Hour, sesi dua jam di mana kuota hadiah ditambah. Orang yang dah main semalam datang balik.

Angka sebenar, sepuluh hari

Ini angka yang aku verify terus dari Supabase production, bukan dari dashboard marketing:

2,949 leads. Nombor telefon unik. Zero duplicate. Ini penting sebab kalau kau tak buat constraint pada nombor telefon, kau akan dapat 5,000 "leads" yang sebenarnya 1,800 orang.

2,088 pemenang hadiah — setiap satu dengan claim code sendiri.

1,989 hadiah ditebus. Kadar penebusan 95.3%.

436 skor sempurna — orang yang jawab 10/10.

1,344 soalan AI. Bukan "berapa kali chatbot dibuka" — ini soalan sebenar yang ditaip orang.

Dan angka hari keempat, yang aku selalu sebut dulu: 807 leads, 594 hadiah, 120 skor sempurna. Hari keempat sahaja mengalahkan gabungan tiga hari pertama dalam hampir semua metrik.

Hari yang sistem hampir mati

Hari keempat tu juga hari yang paling aku risau.

381 leads dalam satu hari. Bukan lead biasa — setiap satu melalui chatbot, quiz, gacha, dan redemption. 359 quiz siap, 291 hadiah keluar, 64 orang dapat 10/10.

Dua sesi Happy Hour hari tu: tengah hari dapat 132 leads, malam dapat 231. Yang malam tu adalah dua kali ganda sesi biasa. Sistem tak down. Tapi bukan sebab ia hebat — sebab aku dah buat keputusan dua minggu sebelum tu.

Keputusan tu: jangan simpan apa-apa yang boleh dikira dalam browser. Kuota hadiah, baki stok, status redemption — semua diurus dalam database dengan row locking. Kalau kau simpan baki stok dalam JavaScript, dua kiosk akan bagi hadiah yang sama pada masa yang sama.

Benda yang aku tak jangka

Bila aku baca balik 1,344 soalan AI tu, ada satu pola yang jelas: orang tanya benda yang boleh dicari di Google, tapi mereka tanya chatbot sebab mereka sedang berdiri di booth kau.

Top lima soalan:

1. Resipi laksa Sarawak step-by-step — 43 kali
2. Apa itu pua kumbu — 40 kali
3. Muzium kucing di mana — 29 kali
4. Orangutan Semenggoh — 27 kali
5. Tarikh dan lokasi MAHA — 26 kali

Perhatikan nombor lima. Dua puluh enam orang tanya di mana event yang mereka sedang berada. Itu bukan kegagalan chatbot. Itu kegagalan signage.

Dari situ aku kenal pasti enam jurang knowledge base yang aku tak nampak masa tulis kandungan: resipi teknikal, logistik venue, sejarah dan tokoh, fakta ringkas, lokasi spesifik, dan dialek Sarawak. Semua enam tu aku tambah semasa event berjalan — dokumen KB naik dari 9 ke 15 dalam sepuluh hari.

Benda yang tak jadi

Kalau aku cuma cerita yang berjaya, artikel ni tak berguna.

Satu — admin dashboard lambat. Selepas event, aku buka dashboard dan ia ambil masa berpuluh saat untuk load. Puncanya jelas bila aku periksa: kod ambil semua 2,949 baris lead, hantar ke browser, kemudian kira statistik dalam JavaScript. Setiap kali buka tab, 2,949 rows melintasi network.

Fix: satu fungsi database yang kira semua sekali di server, pulangkan satu objek kecil. Satu panggilan ganti puluhan. Dashboard jadi serta-merta.

Dua — kuota Happy Hour tersangkut. Ada satu ketika kuota tak turun walaupun hadiah dah keluar. Puncanya bukan logik — ia migration lama yang ter-overwrite semasa deploy. Pelajaran yang aku bawa sampai sekarang: kalau migration dah di-apply, jangan edit balik. Buat migration baru.

Tiga — link event tersasar. Bila event ditukar dari satu ke event lain, ada tiga tempat dalam kod yang simpan slug event. Aku update dua, terlupa satu. Akibatnya QR code bawa orang ke event yang dah tamat. Tiga tempat. Sentiasa tiga tempat.

Apa yang aku buat lain kali

Kalau aku ulang projek ni, lima benda berubah:

1. Angka jangan jadi satu-satunya ukuran. 2,949 leads nampak hebat sampai kau tanya "berapa yang convert jadi pelanggan sebenar?" Sistem ni tak jawab soalan tu. Versi seterusnya mesti ada post-event follow-up terbina dalam, bukan sebagai idea kemudian.

2. Signage dulu, chatbot kemudian. Dua puluh enam orang tanya lokasi event melalui chatbot. Satu papan tanda yang betul akan jimat 26 interaksi dan beri jawapan lebih laju.

3. Kuota hadiah mesti boleh diselaraskan dari luar. Sekarang ia perlu deploy. Sepatutnya ada satu skrin admin yang boleh tukar kuota dalam masa sepuluh saat, sebab keperluan event berubah setiap jam.

4. Ujian dengan beban sebenar, bukan beban andaian. Aku uji dengan 50 concurrent user. Realitinya 381 leads sehari bermakna berpuluh orang berdiri menunggu skrin yang sama. Ujian seterusnya mesti simulate orang beratur, bukan orang duduk.

5. Data lead mesti keluar dalam format yang boleh diguna. CSV dengan 2,949 baris tak berguna kalau tiada konteks: siapa datang hari apa, main berapa kali, dapat hadiah apa, tanya apa. Versi seterusnya eksport satu profil per orang, bukan satu baris per transaksi.

Kenapa aku tulis ni

Bukan untuk tunjuk sistem ni hebat. Sistem ni berfungsi, dan itu punca ia dipakai 2,949 kali.

Aku tulis sebab kebanyakan case study yang aku baca cerita hasil, bukan keputusan. Dan keputusan yang paling penting dalam projek ni bukan teknikal — ia satu soalan masa minggu kedua: nak tambah feature, atau nak pastikan yang sedia ada tak pecah?

Aku pilih yang kedua. Setiap kali.

Kalau kau sedang bina sesuatu yang akan digunakan orang ramai dalam masa terdekat, satu nasihat: sistem yang membosankan tapi tak pecah lebih bernilai dari sistem menarik yang perlu kau restart tengah hari.

KISEW tak menarik dari segi teknikal. Ia cuma tak mati.

Ia bukan error. Tiada stack trace. Tiada mesej merah.

Cuma satu baris: exit 255, selepas 52 saat.

Aku buka log Coolify, scroll dari atas ke bawah tiga kali. Kosong. Aku jalankan build yang sama pada Mac mini — lulus, tiga minit, tiada masalah. Aku push semula. Gagal lagi. Sama, 52 saat.

Masa tu aku dah mula salahkan kod. Mungkin dependency baru. Mungkin Next.js 16 dengan Turbopack ada bug. Aku baca issue GitHub selama dua jam.

Kemudian aku tanya soalan yang sepatutnya aku tanya dari awal: apa yang berubah pada server, bukan pada kod?

Jawapannya ada dalam satu command

free -h

               total        used        free      shared  buff/cache
Mem:           7.8Gi       3.9Gi       1.2Gi       112Mi       2.7Gi
Swap:          4.0Gi       3.3Gi       0.7Gi

Swap 83% penuh. Mesin ni bukan kekurangan RAM sedikit — ia tercekik.

Dan bila mesin tercekik, benda pertama yang mati ialah proses yang paling lapar RAM. Dalam kes aku, itu next build.

Bukan kod aku salah. Mesin tu cuma tak cukup nafas.

Apa sebenarnya ada dalam VPS 8GB tu

Ini senarai servis yang berjalan pada satu box, pada masa tu:

— Coolify sendiri (dashboard + proxy + builder)
— Kembara AI (Next.js app + Postgres + Redis + Evolution API + Socket.io)
— n8n (main process + task runner)
— Temporal (untuk workflow panjang)
— MySQL
— Apache
— Postiz (social scheduler)
— WordPress (projek lama)

Sembilan benda. Lapan gigabait.

Setiap satu munasabah bila berdiri sendiri. Digabung, ia satu mesin yang bekerja pada had setiap minit, sepanjang hari.

Kenapa swap bukan penyelesaian

Reaksi pertama orang bila swap penuh: tambah swap lagi.

Itu yang aku buat. Tambah /swapfile2 2GB, total jadi 6GB. Build lulus. Masalah selesai — untuk seminggu.

Kenapa ia bukan penyelesaian sebenar:

Swap ialah disk, bukan RAM. Bila sistem terpaksa swap, ia baca dan tulis ke SSD. SSD lebih lambat 100 hingga 1,000 kali dari RAM. Jadi bila swap penuh, kau bukan "kekurangan memori sikit" — kau buat mesin berjalan pada kelajuan disk.

Ia menangguhkan masalah, bukan selesaikan. Setiap servis baru yang kau tambah akan makan ruang yang kau baru bagi. Dalam sebulan, swap penuh balik.

Ia menyembunyikan punca sebenar. Selagi build lulus, kau takkan tanya "kenapa aku letak sembilan servis dalam satu mesin?"

Swap menyelamatkan kau hari ini. Ia tak menyelamatkan kau bulan depan.

Apa yang aku buat selepas tu

Aku tak upgrade RAM. Aku buat tiga benda lain dulu, dalam susunan ni:

1. Buang yang tak perlu

Aku matikan WordPress dan Postiz. Kedua-duanya projek lama yang tak aktif. Volume simpan, container stop.

Hasil: RAM turun dari 5.0GB ke 1.9GB. Swap dari 2.8GB ke sifar.

Itu bukan penambahbaikan kecil. Itu satu mesin yang berhenti tercekik.

2. Kemas build cache

Seminggu kemudian disk naik mendadak. Aku semak:

docker system df

Build cache: 7.35GB. Semua reclaimable. Sifar aktif.

Setiap build menyimpan layer untuk build seterusnya lebih laju. Bagus. Tapi bila kau push 40 kali dalam seminggu, ia jadi sampah yang membesar senyap.

Satu command, tiga puluh saat, 7GB balik.

3. Tetapkan n8n supaya berhenti menyimpan sejarah

n8n simpan setiap execution. Database SQLite naik ke 2.0GB.

Bila aku siasat, data sebenar cuma 34MB. Selebihnya free pages — ruang yang pernah dipakai, kemudian dipadam, tapi tak dipulangkan ke disk.

Fix: prune execution lama, kemudian VACUUM. Database turun dari 2.0GB ke 26MB.

Dan yang lebih penting — aku set retention supaya ia tak membesar balik:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none

Bila kau patut upgrade, bukan optimize

Ini bahagian yang orang selalu tanya, dan jawapan aku tak popular: kalau kau tanya soalan tu, kau mungkin memang patut upgrade.

Aku optimize sebab masa tu aku masih ada benda jelas untuk dibuang. Tapi bila kau dah buang semua yang patut dibuang, dan mesin masih tercekik — itu bukan masalah konfigurasi lagi. Itu kapasiti.

Petunjuk yang kau dah sampai had:

— Swap kekal penuh walaupun selepas cleanup
— Build gagal secara rawak (kadang lulus, kadang tidak, kod sama)
— Kau mula menolak servis baru sebab "nanti mesin tak cukup"
— Kau restart servis setiap hari sebagai rutin, bukan sebagai kejadian

Bila empat perkara ni berlaku, tambah swap lagi takkan tolong. Kau cuma beli masa.

Pilihan yang aku tak ambil (dan kenapa)

Upgrade ke 16GB. Selesaikan masalah selama enam bulan. Tapi kos bulanan naik dua kali ganda untuk mesin yang separuh isinya tak perlu ada.

Pecah ke dua VPS. Satu untuk automation stack, satu untuk app production. Ini yang aku rasa betul jangka panjang, tapi ia kerja — pindah data, tukar DNS, test semula. Aku belum buat.

Pindah ke managed service. Mahal dengan cepat. Untuk lapan projek, satu Postgres managed sahaja dah lebih dari kos VPS sekarang.

Aku pilih: buang yang tak perlu dulu, ukur semula, baru putuskan. Ternyata buang WordPress dan Postiz dah cukup untuk sementara.

Tiga perkara yang aku buat setiap kali VPS rasa perlahan

Satu — semak memori dulu, bukan CPU.

free -h
ps aux --sort=-%mem | head -10

Kalau swap tinggi, jawapannya ada di situ, bukan di graf CPU.

Dua — semak disk guna satu command.

docker system df

Empat baris tu bagi kau gambar penuh: images, containers, volumes, build cache. Aku dah jumpa ber-GB sampah setiap kali guna command ni.

Tiga — semak servis yang berjalan, bukan yang patut berjalan.

docker ps --format '{{.Names}}\t{{.Status}}'

Kadang kau akan jumpa servis yang kau ingat dah mati, masih hidup. Atau sebaliknya.

Penutup

VPS 8GB tu masih berjalan hari ini. Masih dengan swap yang kadang naik bila aku deploy serentak. Masih dengan sembilan servis yang aku tak sempat pecahkan.

Tapi ia tak mati lagi. Dan perbezaan antara "VPS yang buat aku bangun tengah malam" dengan "VPS yang aku tak fikir langsung" bukan RAM — ia keputusan untuk berhenti tambah benda, dan mula buang benda.

Kalau kau mengurus server sendiri, satu tabiat yang paling berbaloi: sebulan sekali, buka docker system df dan free -h. Bukan bila masalah datang. Sebelum.

Biar aku mulakan dengan pengakuan: aku tak ada latar belakang DevOps. Aku tak tahu apa itu Kubernetes masa mula. Aku belajar Docker sebab satu build mati dan aku terpaksa faham kenapa.

Tapi hari ini, semua projek aku berjalan atas satu VPS 8GB yang aku uruskan sendiri, dengan Coolify sebagai lapisan atas. Bukan sebab aku nak jadi sysadmin. Sebab alternatifnya — bayar satu managed platform untuk setiap projek — tak masuk akal bila kau ada lapan projek dan separuh daripadanya belum hasilkan duit.

Artikel ni bukan tutorial pemasangan. Ia cerita apa yang aku belajar selepas setahun guna, termasuk lubang yang aku jatuh masuk.

Apa Coolify buat, dalam satu ayat

Coolify ialah dashboard untuk Docker yang faham Git.

Kau sambung repo GitHub, dia pull, build, jalankan container, urus SSL, dan tunjuk log. Benda yang biasanya kau taip dalam terminal selama dua jam, dia buat dalam satu klik — atau automatik bila kau push.

Yang penting: ia bukan platform berbayar. Ia software yang kau jalankan atas server sendiri. Jadi kos bulanan kau = kos VPS sahaja.

Kenapa aku pilih self-host, bukan Vercel untuk semua

Sebenarnya aku guna dua-dua. Ini bukan pilihan ideologi, ini pilihan kos dan keperluan.

Vercel untuk static dan Next.js ringkas. Push, siap. Tiada server untuk difikir. Percuma untuk projek kecil.

Coolify untuk yang perlukan VPS sebenar. Bila projek kau perlukan:

— Container yang jalan 24 jam (Evolution API untuk WhatsApp, n8n untuk workflow)
— Postgres yang kau nak backup sendiri
— Redis untuk queue
— WebSocket yang perlu state kekal

Vercel tak bagi benda-benda ni. Bukan sebab ia teruk — ia memang direka untuk serverless. Kalau kau paksa serverless buat kerja yang perlukan process kekal, kau akan menangis.

Enam perkara yang aku belajar dengan menyakitkan

1. Jangan stop service guna docker stop

Ini kesilapan pertama dan paling memalukan.

Aku nak jimat RAM, jadi aku taip docker stop postiz melalui SSH. Container mati. Dua minit kemudian ia hidup balik.

Puncanya: Coolify ada watchdog yang pastikan setiap service yang sepatutnya jalan, jalan. Kalau kau matikan dari luar, ia anggap itu crash dan restart.

Betul: stop dari UI Coolify. Baru ia tak dilawan.

2. Edit .env sahaja tak ubah apa-apa

Aku ubah satu env variable n8n untuk prune execution data. Simpan. Restart. Tiada perubahan.

Selepas sejam barulah aku faham: container tu guna env_file: .env dalam docker-compose. Env dibaca masa container dicipta, bukan masa ia dimulakan. Restart tak baca semula fail.

Betul:

docker compose up -d --force-recreate

Bukan restart. force-recreate.

3. Build cache boleh makan 7GB tanpa kau sedar

Disk naik 10GB dalam satu hari. Aku ingat ada log yang membengkak atau container yang menulis sampah.

Rupanya build cache. 7.346GB, 93 entries, sifar aktif.

Setiap kali Coolify build, ia simpan layer untuk build seterusnya lebih laju. Bagus untuk kelajuan. Tapi kalau kau push 40 kali dalam seminggu (macam aku masa kejar bug), ia terkumpul jadi sampah.

Betul: semak docker system df setiap kali disk naik mendadak. Kalau build cache besar dan semua reclaimable, buang:

docker builder prune -f

Aku buat ni semasa VPS dalam keadaan kritikal dan dapat balik 7GB dalam masa tiga puluh saat.

4. Build mati senyap biasanya bukan salah kod

Build gagal dengan exit 255. Log tunjuk ia mati dalam next build selepas ~52 saat. Tiada error message. Tiada stack trace. Cuma berhenti.

Kod yang sama lulus pada laptop aku.

Puncanya bukan kod. Puncanya RAM. Turbopack dalam Next.js 16 makan RAM lebih banyak dari yang VPS 8GB boleh bagi bila empat container lain sedang berjalan.

Betul: bila build mati senyap tanpa error, semak RAM dan swap dulu, bukan kod. Kalau swap penuh, itu jawapannya.

5. Verify deployment kena tengok chunk yang betul

Aku push fix, deploy kata berjaya, tapi perubahan tak nampak.

Sebabnya: aku grep string baru dalam bundle, tapi aku grep dalam chunk yang salah. Next.js pecahkan app jadi banyak chunk. Chunk login tak sama dengan chunk dashboard. Aku jumpa string lama dalam chunk yang memang tak sepatutnya berubah, dan ingat deploy gagal.

Betul: cari string yang unik pada page yang kau ubah, dan sahkan ia ada dalam chunk yang load untuk page itu. Atau lebih mudah — buka page, hard refresh, tengok sendiri.

6. API token akan expire, dan kau akan lupa

Aku setup satu automation yang guna Coolify API untuk monitor deployment. Ia berjalan selama sebulan. Kemudian senyap.

Token expire. Semua request pulang 401. Tiada notifikasi, tiada amaran — automation cuma berhenti buat kerja.

Betul: apa-apa automation yang guna token, kena ada semakan yang akan lapor bila ia gagal, bukan cuma bila ia berjaya.

Apa yang aku tak buat, dan tak akan buat

Satu — auto-deploy untuk semua branch. Auto-deploy hanya pada main. Branch lain manual. Sebab kalau setiap branch deploy, VPS kau akan build sepuluh versi app yang tak pernah dilihat orang.

Dua — monitoring berlapis. Aku tak pasang Prometheus, Grafana, Loki, atau apa-apa stack observability. Untuk skala aku, ia lebih banyak kos (RAM) dari manfaat. Aku guna docker stats bila ada masalah, dan uptime check ringkas untuk servis kritikal.

Tiga — Kubernetes. Tidak. Satu VPS dengan Docker Compose dah cukup untuk lapan projek. Kubernetes selesaikan masalah yang aku tak ada.

Nasihat paling jujur

Kalau kau baru mula dan tak ada latar DevOps: jangan mula dengan Coolify.

Mula dengan satu VPS, satu Dockerfile, satu docker compose up. Faham dulu apa itu image, container, volume, dan network. Sebab Coolify sembunyikan semua tu — dan bila sesuatu rosak, kau takkan tahu apa yang rosak.

Baru lepas kau faham asas, pasang Coolify. Masa tu ia jadi alat yang mempercepat kerja, bukan kotak hitam yang kau takut sentuh.

Dan satu lagi: tulis down semua command yang kau guna untuk fix sesuatu. Bukan dalam kepala. Dalam fail. Sebab enam bulan kemudian, kau akan hadap masalah yang sama dan kau takkan ingat apa yang kau buat.

Aku ada satu fail bernama TOOLS.md. Ia menyelamatkan aku lebih banyak kali dari apa-apa dokumentasi rasmi.

Tiada satu pun kesilapan dalam senarai ni adalah teori. Semua adalah perbuatan aku sendiri — setiap satu memakan masa aku dari beberapa jam hingga beberapa minggu. Kalau satu je dapat mengelakkan satu malam tak tidur boss, artikel ni dah berbaloi.

1. Terima code tanpa faham

Yang pertama, yang paling klasik. Code dah jalan, feature dah nampak — terus deploy. Bulan kemudian ada masalah, dan aku sedar aku tak faham pun code yang aku "tulis". Bila kamu tak faham code kamu, kamu bukan pemilik sistem — kamu tukang gawai. Sekarang, setiap code yang masuk production, aku mampu explain kenapa ia ditulis begitu. Kalau tak mampu, aku tanya AI sampai faham. Itu bukan kelemahan. Itu kerja.

2. Prompt terus code, tanpa bertanya reka bentuk dulu

"Buatkan dashboard" menghasilkan dashboard — mungkin dengan arah yang salah sepenuhnya. Kesilapan mahal bukan error; kesilapan paling mahal ialah sistem yang betul dibina untuk masalah yang salah. Sekarang, prompt pertama aku selalu minta AI berhenti dan bertanya dahulu.

3. Tidak bertanya "siapa boleh buat apa" sejak awal

Sistem pertama aku dibina dengan penuh keghairahan — features bertambah-tambah, keselamatan "nanti". "Nanti" tu berminggu-minggu. Aku pernah jumpa satu pintu terbuka yang membenarkan mana-mana user meluluskan sendiri permohonan mereka. Niat baik yang tidak dilaksanakan adalah risiko yang hanya menunggu waktu.

4. Minta AI buat semua sekali gus

"Bina sistem lengkap dengan login, dashboard, notifikasi dan laporan" — AI akan cuba. Hasilnya: dinding code besar yang separuh betul, dan kamu tak tahu yang mana yang separuh itu. Satu feature dulu. Kecil. Berjalan. Kemudian tambah.

5. Skip version control sebab "projek kecil je"

Projek yang aku fikir "kecil je" ialah projek yang aku paling banyak menangis. Git bukan untuk projek besar — ia untuk bila AI buat perubahan yang rosakkan semuanya pada jam 1 pagi, dan kamu perlukan jalan pulang dalam 30 saat. Aku pernah nyaris hilang kerja sebab satu sequence git yang salah. Sekarang: commit sebelum setiap langkah berani. Sentiasa.

6. Terus deploy tanpa build test lokal

"Jalankan je di production, tengok jadi tak." Satu hari, build gagal di server kerana kehabisan memori — bukan sebab code salah, tapi sebab aku tak pernah test binaan dalam persekitaran yang sama. Lokal test dulu, deploy kemudian. Dan bila deploy gagal, jangan assume code — semak server juga. Kadang-kadang masalahnya bukan dalam repo; ia dalam memori yang tak cukup.

7. Ambil "Success" sebagai "Betul"

Deployment pipeline kata berjaya, aku kata siap, dan terus tutup laptop. Kemudian boss tanya "kenapa belum ada?" — rupanya deployment lama yang masih lari. Kini aku sentiasa sahkan perubahan di production dengan mata: buka page yang betul, periksa bundle yang betul. Pipeline yang selesai bukan sama dengan hasil yang betul.

8. Biarkan API key terbocor dalam client code

Kunci yang berawalan VITE_ atau hidup dalam frontend akan sampai ke tangan orang lain — itu bukan sekret, itu alamat. Satu hari aku sedar satu kunci automasi boleh diambil dari browser oleh sesiapa yang tahu cara. Nasib baik risikonya terkawal, tapi pelajaran tetap: sekret hidup di server. Kunci yang sampai ke browser sudah dianggap awam.

9. Kejar tool baru setiap minggu

Dua minggu dengan satu tool, ganti ke tool lain, ganti lagi. Hasilnya: tiada satu pun dikuasai. Tool akan sentiasa bertambah — itu industri ini. Tapi asasnya tidak berubah: kebolehan menjelaskan masalah, memahami sistem, dan menghantar dengan disiplin. Tool yang lama kamu kuasai mengalahkan tool baru yang kamu sentuh seminggu.

10. Bina sendirian tanpa tunjuk orang

Kesilapan yang paling senyap: sistem siap, hebat, tak pernah ditunjuk kepada pengguna sebenar sampai hari pelancaran. Mereka guna dengan cara yang aku tak pernah jangka, dan separuh aliran yang aku banggakan tak pernah disentuh. Sekarang: tunjuk awal, tunjang kasar, biar mereka kata "eh, aku tak guna ni pun". Lebih baik dengar tu bulan pertama daripada hari pelancaran.

Pesanan terakhir

Semua sepuluh ni aku buat. Ada yang sekali, ada yang berkali-kali sampai dia jadi peraturan bertulis. Kesilapan dalam vibe coding bukan tanda kamu tak layak — ia tanda kamu sedang melalui fasa yang semua orang lalui, cuma ramai yang tak bercerita.

Beza yang berjaya dan yang berputus asa? Yang berjaya buat kesilapan sekali, catat, dan tak ulang. Mulakan senarai kamu sendiri hari ni.

Hari ketiga satu event besar. Booth penuh orang, queue panjang, dan sistem tengah menelan deretan leads pada kadar yang belum pernah berlaku. Tepat jam 6:45 petang, satu alert masuk: 231 leads dalam satu jam — rekod. Dan di bawahnya, satu notis kecil yang buat nafas aku sekejap: satu perubahan yang aku deploy pagi tadi sedang bertindak dengan cara yang aku tak jangka.

Nasib baik: perubahan itu kecil, dan ada jalan kembali. Tapi detik tu tetap terukir — sistem yang diguna oleh ratusan orang sebenar tidak tahu maksud "nanti aku test".

Code yang ditulis oleh AI menjadikan penulisan code lebih pantas. Ia tidak mengubah satu benda: tanggungjawab atas apa yang berlaku di production masih pada manusia yang tekan butang deploy. Itu diri kamu.

Ritual empat langkah sebelum setiap release

Selepas satu hari tersebut, aku tetapkan satu ritual yang aku tak langgar walaupun tergesa-gesa. Empat langkah, lima belas minit, setiap kali.

Langkah 1: Biar mesin cek yang boleh dicek mesin. Type check, build, lint. Tiga command, dua minit. Ia tak akan jumpa bug logic — tapi ia jumpa 80% kesilapan bodoh sebelum dia sampai ke mata user. Dan penting: jumlah error perlu sama sebelum dan selepas perubahan. Kalau tsc keluar 16 error sebelum dan 16 selepas, itu baseline lama, bukan regression kamu. 16 jadi 17? Ada yang baru masuk. Cari dia.

Langkah 2: Test yang kamu tak boleh test mesin — test dengan mata. Buka app, tekan flow yang berubah, masuk sebagai user biasa dan sebagai admin. Sembilan puluh peratus bug UX tak nampak dalam automated test — mereka nampak bila kamu berlakulah sebagai pengguna yang malas dan tergesa. Buka page tu dengan telefon juga, bukan desktop sahaja. Separuh dunia online hidup dalam skrin 6 inci.

Langkah 3: Deploy kecil, kerap, dan satu arah. Release besar adalah kutukan. Sepuluh feature dalam satu deploy bermaksud bila ada yang pecah, kamu ada sepuluh suspek. Aku punya aturan: satu commit, satu tujuan, deploy terus. Kalau ada masalah, aku tahu dengan tepat commit mana — dan rollback dalam masa satu minit. Versi lama sentiasa ada di sisi untuk rollback sekejap.

Langkah 4: Verify production, jangan assume. Ini langkah yang paling kerap di-skip dan paling bahaya. Deployment kata "success" — tapi adakah perubahan betul-betul live? Aku belajar cara susahnya: dua kali dalam sehari, aku monitor deployment dan tarik kesimpulan salah sebab aku memeriksa fail yang betul di halaman yang salah. "Success" pada pipeline bermakna proses selesai — bukan bermakna keputusannya betul. Grep pada bundle yang betul, buka page yang betul, sahkan dengan mata.

Yang AI takkan buat untuk kamu

AI akan tulis code. AI akan jalankan build. Tapi AI tidak akan rasa takut bila 231 leads masuk dalam satu jam. Ia tidak akan tahu bahawa esok ada event besar dan malam ni bukan malam untuk eksperimen berani. Ia tidak akan anggung tanggungjawab bila pelanggan telefon.

Itu sisa di bahu kamu. Dan jujurnya? Itu berita baik. Sebab bila code boleh ditulis pantas, nilai kamu bukan lagi di kelajuan menaip — ia di disiplin kamu menghantar.

Siapa pun boleh build pantas dengan AI sekarang. Yang jarang ialah orang yang build pantas dan tidur lena selepas deploy.

Ada satu fail Excel dalam satu organisasi yang aku kenal. Nama failnya penuh dengan version number: FINAL, FINAL_v2, FINAL_BETUL_INI, JANGAN_SENTAH_INI. Sebelas orang kongsinya. Setiap pagi ada satu soalan yang berlegar: "yang mana versi betul ni?"

Booking bilik mesyuarat dibuat melalui WhatsApp group. Kelulusan melalui tanda tangan kertas. Status kerja melalui "boss, dah settle tu" — tanpa rekod, tanpa jejak.

Tiada siapa salah di sini. Orang-orang tu rajin, jujur, dan buat yang terbaik dengan alat yang ada. Masalahnya bukan orang — masalahnya sistem tidak wujud.

Dari pengalaman membina beberapa sistem untuk organisasi macam ni, aku dah nampak satu formula yang berulang. Ini dia.

Langkah 1: Jangan automatikkan kekacauan — kekalkan dulu, fahami dulu

Godaan pertama: terus bina sistem digital yang mirror proses lama. Jangan. Excel yang berselirat tu selalunya mengandungi proses yang dah lapuk — langkah yang tiada siapa ingat kenapa wujud, kolum yang tak pernah dipakai, kelulusan yang sebenarnya tak dilaksanakan.

Yang aku buat: duduk dengan pengguna sebenar selama satu jam. Tanya tiga soalan — apa yang paling membosankan? apa yang paling kerap salah? apa yang paling menakutkan kalau hilang? Jawapan tiga soalan tu adalah blueprint sebenar sistem. Bukan kolum Excel. Ia sakit sebenar pengguna.

Langkah 2: Satu proses dulu, bukan semua

Kesilapan klasik transformasi digital: cuba digitalkan segalanya sekali gus. Tiga bulan kemudian: sistem separuh siap, orang dah penat, Excel masih raja.

Formula aku: pilih satu proses yang paling sakit dan paling kerap berlaku. Untuk organisasi yang aku sebut tadi, itu booking bilik mesyuarat — kerap, menyusahkan, dan statusnya sentiasa kabur. Sistem pertama hanya buat tu. Satu benda, dibuat betul.

Hasil minggu pertama? Orang nampak sendiri: mereka taip sekali, status terus nampak, tiada lagi "versi betul". Itu pembelian keyakinan yang tak boleh dibeli dengan powerpoint.

Langkah 3: Vibe coding menjadikan kos tak lagi alasan

Dulu, jawapan kepada "kita patut buat sistem" ialah "tiada budget". Sekarang? Sebuah sistem booking dengan workflow kelulusan, notification, audit trail — dibina dalam beberapa petang, tanpa team IT, tanpa lesen beribu.

Bukan sebab AI magic. Sebab formula tu dah berubah: dulu kos terbesar ialah menulis code. Sekarang kos terbesar ialah memahami masalah — dan itu boleh dibuat oleh orang dalam, malam ini, dengan bantuan AI.

Langkah 3.5 (yang sering dilupakan): Keselamatan dari hari pertama

Salah satu kesilapan yang paling mahal: bina sistem, kemudian fikir tentang siapa boleh buat apa. Jangan. Dari hari pertama, setiap tindakan perlu ada jawapan: siapa boleh buat apa, dan bagaimana database itu sendiri menolak apa yang tak patut. UI boleh dikelabu — peraturan pada peringkat data tidak.

Langkah 4: Angkat Excel jadi backup, bukan musuh

Jangan perang dengan Excel. Ia menang. Yang betul: jadikan sistem baharu tempat kerja berlaku, dan export Excel tetap ada untuk mereka yang nak melihat. Mentalitanya bukan "bunuh Excel" — ia "Excel bukan lagi tempat keputusan dibuat". Dalam enam bulan, peranannya mengecil dengan sendirinya.

Langkah 5: Ukur satu nombor yang orang sayang

Jangan ukur kejayaan dengan "sistem dah live". Ukur dengan nombor yang pengguna peduli: masa menunggu kelulusan dari 2 hari ke 5 minit. "Siapa booking bilik?" dari 3 telefon ke 1 tapisan. Satu nombor yang berubah — itu cerita yang membuatkan orang lain mahu ikut.

Penghujungnya

Organisasi yang manual bukan kekal sebagai manual sebab mereka bodho. Ia sebab tiada siapa bina jambatan yang muat dengan kaki mereka. Vibe coding bina jambatan tu lebih murah dan lebih cepat dari sebelum ini — tapi formula tetap sama: dengar sakit yang sebenar, buat satu benda dulu, buat dia betul, biarkan hasil jualan yang bawa sisanya.

Excel tak akan hilang malam ini. Tapi minggu depan, ia boleh mula kehilangan kuasa.

Ada hari yang memalukan sikit: admin tekan satu butang "Print" dalam sistem yang aku bina — dan skrin keluar error. Bukan error cantik. Crash.

Code tu ditulis oleh AI, direview oleh aku, dan dah berlari dalam production berminggu-minggu. Macam mana boleh terlepas?

Sebabnya buat aku tersenyum bila sedar: fungsi tu wujud dalam code, tapi tak pernah dihubungkan. Ada mesin, tapi kabel tak dipasang. Build lulus, semua test hijau — kerana tiada apa yang test fungsi yang tak pernah dipanggil.

Itu hari aku tulis peraturan debug pertama untuk code AI-generated.

Peraturan 1: Baca error sebenar, bukan rasa error

"Tak berfungsi" ialah deskripsi perasaan, bukan maklumat. Yang AI perlukan ialah error message penuh — line number, stack trace, dan apa yang boss buat sebelum error tu muncul.

Contoh nyata dari hari yang sama: satu build gagal dengan exit code 255 dan tiada error jelas. Kalau aku tulis "build gagal, fix", AI akan guess. Tapi bila aku selidiki — log tunjuk build mati senyap 52 saat dalam langkah build paling berat — tekaan pertama aku terus betul: VPS kehabisan memori. Perbetulkan swap, deploy berjaya dalam lima minit. Diagnosis yang tepat separuh daripada penyelesaian.

Peraturan 2: reproduksi dulu, teori kemudian

Sebelum tanya AI kenapa, aku pastikan aku boleh buat bug tu muncul dengan sengaja. Langkah apa, data apa, bila ia berlaku. Bug yang boleh di-reproduce ialah bug yang 80% selesai — sebab sekarang setiap cadangan fix boleh disahkan terus.

Bug yang "kadang-kadang jadi"? Itu yang makan masa. Tapi malah itulah yang patut diberi paling banyak konteks kepada AI: bila ia jadi, bila tak jadi, apa yang berbeza.

Peraturan 3: AI debugging, kamu yang sahkan

Ada satu kegodaan berbahaya bila AI debug: menerima jawapan pertama yang bunyi betul. Aku kena tipu dengan ni dulu — AI bagi penjelasan yang logik, aku terima, masalah sebenarnya masih ada dua langkah lebih dalam.

Sekarang ritual aku: AI cadangkan punca → aku verify punca tu wujud (buka code, letak log, test) → baru fix. Cadangan tanpa verifikasi ialah teori. Teori yang belum dibayar.

Peraturan 4: satu perubahan pada satu masa

Godaan terbesar bila debug: tukar tiga benda serentak sebab "mesti ni pun salah jugak". Jangan. Satu perubahan, satu test. Kalau tiga benda ditukar dan error hilang, kamu tak tahu yang mana yang membetulkan — dan yang mana yang merosakkan benda lain sambil menyelamatkan yang satu.

Aku pernah tengok satu bug "settle" selepas lima perubahan serentak — dua minggu kemudian bug yang sama datang balik bawa kawan. Empat masalah, satu yang diperbetulkan, tiga yang ditanam.

Peraturan 5: simpan kesilapan AI untuk jadi bahan ajar

Setiap bug yang AI buat — dan cara ia akhirnya diselesaikan — aku tulis dalam fail log mudah dalam repo. "Simptom, punca, fix, pelajaran."

Hasilnya? Pattern mula nampak. AI dalam projek ini kerap silap pada tempat yang sama — biasanya lupa expose sesuatu dari hook, atau assume field yang tak wujud dalam database. Dengan log tu, prompt seterusnya dah jaga perangkap-perangkap lama. Kesilapan berbayar sekali je.

Penutup: silap itu normal, buta itu bahaya

AI akan terus membuat kesilapan — kadang-kadang cara yang manusia tak sangka. Itu bukan alasan untuk tak guna AI. Ia sebab untuk guna dia dengan cara yang betul: kamu pemilik keputusan, AI ialah pelaksana yang pantas tapi kadang tersasar.

Yang membezakan developer yang matang dengan yang baru ialah bukan jumlah bug yang diterima — semua orang terima bug. Ia kelajuan dan kejujuran cara kamu mencarinya.

Dua orang boleh guna AI coding tool yang sama, dengan model yang sama — tapi satu hasilnya slow dan penuh kesilapan, yang satu lagi siapkan sistem dalam masa separuh. Bezanya bukan model. Bukan prompt magic. Ia setup.

Selepas membina lebih sepuluh sistem dengan AI — dari booking system sampai SaaS multi-tenant — ni setup yang aku settlekan, dan kenapa.

1. Rules file: jaga mula bumi

Fail paling berharga dalam setup aku bukan code. Ia satu file markdown pendek yang letak di root projek: CLAUDE.md / AGENTS.md.

Isinya? Peraturan tetap projek. Contoh dari sistem terbaru aku:

"Setiap table ada tenantId. Setiap API route filter dengan tenantId. Tiada pengecualian. Baca workflows/ sebelum buat kerja. Jangan overwrite workflows tanpa bertanya."

Tanpa file ni, aku kena ulang peraturan ni setiap conversation baru. Dengan file tu, AI baca sekali dan faham — bermula setiap sesi sudah tahu peraturan rumah. Ia macam onboarding dokumen untuk rakan kerja yang lupa semula setiap pagi. Tulis sekali, jimat selamanya.

2. Struktur folder yang AI boleh "baca niatnya"

Aku belajar ni cara yang susah: bila folder kucar-kacir, AI guess di mana letak code baru — dan guess salah. Sekarang setiap projek aku ada struktur yang sama: src/app untuk pages, src/lib untuk logic, src/components untuk UI, docs untuk keputusan, workflows/ untuk SOP.

Bila struktur tu konsisten, AI tak perlu ditanya "letak ni kat mana" — ia dah tahu, sebab semua projek lain ikut konvensyen yang sama.

3. Konteks berperingkat, bukan dump semua

Kesilapan awal aku: masukkan seluruh codebase dalam context dan harap AI faham. Hasilnya: jawapan generic, token terbakar, dan kadang-kadang AI "halusinasi" fail yang tak wujud.

Sekarang aku bagi AI hanya yang relevan: fail yang akan diubah, fail yang berkaitan, dan rules file. Untuk kerja besar, aku delegate pada sub-agent dengan task jelas dan scope tertutup — "baca struktur ni, laporkan balik, jangan ubah apa-apa". Maklumat yang tepat masuk, keputusan yang tepat keluar.

4. Git commit sebelum setiap langkah berani

Ini bukan tip AI — ni tip survival. Sebelum aku minta AI buat refactor besar atau upgrade dependencies, satu commit. Bila hasilnya tak seperti diharap, satu command kembali. Aku pernah buat kesilapan: satu commit yang sepatutnya bawa dua fail perubahan ternyata stage hampir seratus fail deletion — sebab sequence git yang salah. Berbalik ke snapshot dalam 30 saat. Tanpa git, malam tu aku akan mula dari kosong.

5. Satu tab soalan berasingan dari kerja

Bunyi kecil tapi besar kesannya: aku pisahkan conversation "buat kerja" dan conversation "bertanya". Bila aku minta AI explain konsep atau semak pendekatan aku, aku tak nak jawapan dia tercampur dengan code yang sedang separuh siap. Kekacauan context menjadikan jawapan kurang tajam.

Yang tak berbaloi (jangan buang masa)

Aku juga pernah cuba benda yang akhirnya aku buang: prompt library gergasi dengan ratusan template (aku guna enam pattern je sebenarnya), custom agents untuk setiap micro-task (overhead lebih dari hasil), dan memory systems yang rumit (markdown file pendek cukup).

Sebab setup yang baik bukan yang paling kompleks. Ia yang membuatkan kamu lupa dia wujud — kamu cuma terus membina.

Kalau boss baru nak mula serius dengan AI coding: jangan sibuk tool terbaru. Sediakan rules file projek anda hari ni. Itu satu jam yang akan berbaloi sepanjang tahun.

Pagi Isnin, selepas selesai satu feature kecil, aku tanya soalan tu pada diri aku sendiri. Sistem dah lari stabil, user happy — tapi ada satu rasa tak sedap yang aku tak boleh explain. Bila last kali aku betul-betul audit keselamatan sistem ni?

Jawapannya: lama. Terlalu lama.

Tiga puluh minit kemudian, skrin aku tunjuk nombor yang buat aku duduk tegak: 18 vulnerabilities. 2 critical. 9 high.

Lubang yang paling menakutkan bukan yang paling teknikal

Dari 18 tu, satu yang buat aku terkejut paling sangat: @auth/core — otak sistem login sendiri. Bayangkan kunci pintu rumah anda adalah kunci yang orang lain dah ada salinannya. Itu rasa dia.

Yang kedua: satu rule Firestore yang membenarkan mana-mana user yang login untuk update apa-apa field booking mereka sendiri — termasuk status. Maksudnya, user yang faham API boleh approve sendiri booking mereka, lansung tanpa pengetahuan admin.

Sistem tu memang direka dengan workflow kelulusan yang rapi di UI. Tapi di peringkat database, pintu belakang terbuka luas.

Renungan: kenapa lubang ni wujud?

Bukan sebab aku tak ambil peduli. Ia wujud sebab tiada siapa cuba pecah masuk. Sistem kecil yang tak terkenal jarang diserang — dan itu justru bahayanya. Kami rasa selamat sebab tiada insiden. Padahal kebetulan je belum ada yang masuk.

Dan ada satu lagi: lubang tu tertulis dalam comment sebagai "contoh: cancel" — niat baik, tapi tak pernah disekat betul-betul. Niat baik tanpa enforcement cuma harapan, bukan keselamatan.

Anatomi fix dalam satu petang

Aturan aku masa fix semua ni:

1. Rules dulu, sebab dia paling bahaya. Setiap user hanya boleh batalkan booking sendiri — dan bukan apa-apa field pun. Status mesti bertukar ke "cancelled", medan identiti (bilik, masa, jenis) dikunci, dan hanya medan metadata pembatalan yang boleh berubah. Self-approve? Ditolak oleh database itu sendiri, bukan bergantung pada UI.

2. Dependencies kemudian. npm audit fix dulu untuk yang selamat, kemudian --force untuk yang perlukan upgrade besar — Next.js melompat satu minor version kerana tujuh advisories. Risiko upgrade? Ada. Tapi risiko biarkan DoS dan cache poisoning dalam production? Lebih besar.

3. Build dan test selepas setiap langkah. Bukan sekali di hujung. Setiap kali. Sebab kalau ada yang pecah, aku nak tahu sebab mana — bukan cari dalam lima belas perubahan.

Dua jam kemudian: 0 vulnerabilities. Dan yang penting — tiada apa-apa yang rosak.

Pelajaran yang aku bawa balik

Pertama: keselamatan bukan satu projek. Ia satu ritme. Setiap bulan, satu audit ringkas. Satu jam je — tapi ia jumpa benda yang bulan-bulan tersembunyi.

Kedua: UI yang betul bukan keselamatan. Yang betul ialah apabila database itu sendiri menolak apa yang tak patut. UI boleh dikelabu; rules tak boleh.

Ketiga, dan yang paling aku rasa: sistem yang tak diserang bukan bermakna selamat. Ia cuma bermakna belum ada yang datang. Jangan tunggu tetamu tak dijemput untuk sedar kunci tak dipasang.

Bila kali terakhir boss audit sistem boss sendiri? Kalau jawapannya "tak ingat" — itu jawapannya. Mula dengan satu command: npm audit. Tengok apa keluar. Kemudian beralanlah dari sana.

Masa aku scroll balik sejarah conversation aku dengan AI untuk e-RUAI, aku perasan satu pattern: dari ratusan prompt aku, ada enam bentuk yang aku ulang lagi dan lagi. Enam je. Sepanjang build sistem yang urus ribuan booking setahun.

Itu masa aku sedar — vibe coding ni bukan pasal pandai menulis prompt panjang. Ia pasal ada beberapa pattern yang betul-betul berkesan, dan guna dia macam tukang kunci guna kunci yang sama pada setiap pintu.

Ni enam patterns tu. Aku guna semua ni hari ni juga, pada setiap projek.

Pattern 1: "Berlakulah sebagai architect dulu, jangan contractor"

Sebelum minta code, aku mula dengan: "Kau adalah software architect. Ini masalah pengguna: [masalah]. Cadangkan 2-3 pendekatan berbeza dengan trade-offs masing-masing. Jangan tulis code lagi."

Kenapa? Sebab kalau terus minta code, AI jadi contractor — buat apa yang diminta. Tapi bila minta ia fikir macam architect dulu, aku dapat pilihan dan trade-offs. Masa build sistem tempahan bilik mesyuarat, pattern ni yang menyelamatkan aku dari satu keputusan besar: real-time sync vs polling. AI cadangkan tiga opsyen, aku pilih yang paling sesuai dengan realiti organisasi.

Pattern 2: "Contoh data sebelum code"

Sebelum AI tulis satu pun logic, aku bagi contoh data: "Booking ada field ni: userId, roomId, startTime, endTime, status. Nilai status: pending, approved, rejected, cancelled."

Kedengaran remeh, tapi ni yang elakkan bug paling mahal — salah faham struktur data. AI yang faham data anda akan tulis logic yang betul pada percubaan pertama. Yang tak faham akan tulis code cantik untuk struktur yang salah.

Pattern 3: "Error full context, bukan summary"

Bila ada error, jangan taip "tak jadi, fix". Copy seluruh error message — termasuk line number dan stack trace — dan paste.

Semalam aku paste satu error TypeScript: TS2552: Cannot find name 'setMaintenancePrintData'. Dalam masa 30 saat, AI jumpa punca: setter tu wujud dalam hook tapi tak exposed dalam return object. Fix dua baris. Kalau aku taip "button tak berfungsi, fix", ia akan guess — dan guess memakan masa.

Pattern 4: "Guard rails dulu, features kemudian"

"Sebelum kita tambah feature ni, tulis dulu Firestore rules untuk pastikan user tak boleh approve booking sendiri."

Pattern ni aku belajar cara yang mahal. Sistem pertama aku, aku biarkan rules longgar dengan niat "nanti kita ketatkan". Bulan-bulan kemudian, lubang tu masih ada. Sekarang, setiap feature baru bermula dengan soalan security dulu — siapa boleh buat apa, dan apa yang tak boleh.

Pattern 5: "Tanya sebelum assumption"

"Sebelum code, tanya aku 3 soalan kalau ada apa-apa yang tak pasti."

Satu baris ni menjimatkan berpuluh jam. AI dengan assumption yang salah akan build sistem yang salah dengan penuh keyakinan. AI yang bertanya dulu akan build yang betul pada percubaan pertama.

Pattern 6: "Iterate dalam kecil, commit dalam besar"

"Ubah sahaja fungsi ni, jangan sentuh yang lain. Tunjuk diff sebelum apply."

Bila AI faham scope — ubah sikit, bukan tulis semula — risiko merosakkan benda yang dah jadi jadi hampir sifar. Dan aku sentiasa commit git sebelum setiap perubahan besar. Bila ada yang rosak, aku boleh kembali dalam satu command.

Akhir kata

Enam pattern ni bukan magic. Ia hanya disiplin — cara yang sama, ulang setiap kali, sampai jadi refleks. e-RUAI, KISEW, Kembara — semuanya dibina dengan pattern yang sama.

Yang best-nya? Pattern ni tak berubah bila AI bertukar model. Pattern tu tentang cara berfikir dan berkomunikasi jelas. Model datang dan pergi, tapi kebolehan menjelaskan masalah dengan jelas — itu kekal.

"Abang, boleh tak kita tahu sapa yang dah booking bilik mesyuarat, tanpa aku kena tanya orang lain?"

Soalan tu datang dari seorang staff pada suatu petang. Biasa, jawapan aku akan jadi macam ni: "boleh, kita kena buat sistem. Kena cari developer, kena budget, kena tunggu." Tapi hari tu, jawapan aku lain. Aku balik rumah, buka laptop, dan jam 11 malam aku mula menulis prompt pertama.

Jam 2 pagi, versi pertama sistem mesyuarat tu dah live. Bukan prototype. Bukan wireframe. Sistem yang betul-betul boleh guna.

Itulah vibe coding. Dan hari ni aku nak kongsi workflow yang aku guna setiap kali — bukan teori, tapi yang terbukti pada lebih sepuluh sistem yang dah lari dalam production.

Langkah 1: Tulis masalah, bukan solution

Kesilapan paling besar orang mula vibe coding: mereka tulis "buatkan saya dashboard React dengan sidebar dan dark mode". Itu solution. AI boleh hasilkan, tapi ia akan jadi sistem yang cantik tapi tak menyelesaikan apa-apa.

Apa yang aku tulis selalunya macam ni: "Admin perlu nampak semua booking hari ini, boleh approve atau reject, dan user dapat tahu status dalam masa 5 minit." Itu masalah. AI akan cadangkan solution sendiri — dan biasanya pilihannya tak sangka-sangka bagus.

Langkah 2: Biar AI cadangkan struktur, aku kekal yang decide

Selepas prompt pertama, aku tak terus terima code. Aku tanya AI cadangkan architecture dulu: database apa, struktur data macam mana, flow user macam mana. Aku baca macam baca proposal kontraktor — ada yang masuk akal, ada yang over-engineered.

Contoh sebenar: masa build e-RUAI, AI cadangkan real-time sync dengan WebSocket untuk semua data. Aku tolak — polling 3 saat cukup untuk use case kami, dan server kami tak perlu tanggung beban tu. Keputusan tu jimat berbulan-bulan maintenance. AI bagi pilihan; aku yang faham konteks, jadi aku yang pilih.

Langkah 3: Build kecik, test cepat, ulang

Aku tak pernah minta AI buat seluruh sistem sekali gus. Satu feature dulu. Build, test, tengok hasil. Kalau jalan, sambung. Kalau tak, aku tanya balik dengan error message yang jelas.

Ni yang membezakan orang yang berjaya dengan vibe coding dan yang frustrated. Yang frustrated cakap "tak jadi, buat balik semua". Yang berjaya cakap "line 47 ni error TS2552 — setter ni tak exposed dari hook. Fix dengan tambah dalam return object". Makin specific, makin cepat settle.

Langkah 4: Hardening — bahagian yang tak boleh skip

Code dah jalan bukan maksud siap. Setiap sistem yang aku deliver lalu pipeline yang sama: security audit (rules, permissions, API keys), error handling, dan deployment test. Hari tu saja aku audit satu sistem dan jumpa 18 vulnerabilities — semua tertutup dalam satu petang sebab pipeline ni dah jadi rutin.

Vibe coding bukan bermaksud "biar AI buat semua, aku tidur". Ia bermaksud aku fokus pada keputusan yang penting, dan biar AI buat kerja mengtaip yang membosankan.

Hasilnya?

Sistem mesyuarat tu? Hari ni ia urus ribuan booking setahun. Mula dari satu soalan petang tu.

Kalau boss ada idea yang dah lama tergantung dalam kepala — jangan tunggu "ada masa". Masa tu takkan datang. Tapi dengan workflow yang betul, idea tu boleh jadi sistem live sebelum minggu ni habis.

Dalam artikel seterusnya, aku kongsi prompt patterns spesifik yang aku guna — yang sama aku ulang pada setiap projek. Jangan miss.

Bayangkan operasi restoran

• Pelanggan = user atau sistem yang hantar request
• Waiter = n8n yang terima dan bawa request ke tempat betul
• Dapur = servis/API yang proses kerja
• Resipi = workflow anda
• Bahan = data yang anda hantar ke API

Apa itu node dalam n8n?

Node ialah satu langkah kerja dalam workflow. Setiap node ada peranan berbeza. Contohnya webhook node terima data, HTTP Request node hantar data ke API, IF node buat keputusan ikut syarat, dan set/code node kemas data.

Jadi node bukan sistem penuh. Node cuma satu step dalam “resepi” automasi anda.

Workflow ialah resipi

Dalam masakan, anda ikut urutan. Dalam n8n pun sama. Anda tak boleh campak semua step sekali gus dan harap hasil jadi cantik.

1. Terima data
2. Semak format
3. Kemas data
4. Hantar ke API
5. Simpan log
6. Beri respons

Itu workflow. Bila urutan jelas, hasil lebih stabil.

API ialah bahan dalam resipi

API bukan sekadar URL. API ialah kontrak data. Macam dapur perlukan bahan yang betul, API pun perlukan field yang betul.

Contoh API WhatsApp perlukan phone, message, dan token. Kalau satu pun salah, order tak jalan.

Kenapa kena baca API documentation?

Documentation API adalah manual dapur. Dalam tu ada endpoint, method (GET/POST), auth, required fields, dan contoh response.

Kalau tak baca, biasa akan kena error:

• Unauthorized
• Invalid payload
• Missing field
• Rate limit

Kebanyakan masa, masalah bukan pada n8n. Masalah pada input yang tak ikut requirement API.

Sekarang AI mudahkan proses

Dulu nak connect API ambil masa lama. Sekarang anda boleh guna AI untuk percepatkan.

Cara paling practical:

1. Beri AI objective anda
2. Paste endpoint + sample docs
3. Minta step setup node (method, headers, body)
4. Minta fallback untuk error handling

AI tak gantikan logik anda, tapi AI sangat bantu untuk kurangkan trial and error.

Framework simple sebelum pergi besar

1. Define objective dulu
2. Build flow kecil dan test end to end
3. Validate dengan data real
4. Add retry + logging
5. Scale perlahan-lahan

Penutup

Bila anda faham konsep waiter, dapur, pelanggan, n8n jadi jauh lebih mudah.

Workflow ialah resipi. API ialah bahan. Node ialah langkah kerja.

Start simple dulu. Bila stabil, baru pergi besar.

SAFE Framework bermaksud Systematic AI For Everyone. Ia bukan satu software, bukan satu app — ia satu cara berfikir tentang macam mana nak guna AI tools secara practical dalam kerja harian.

Kenapa SAFE Framework?

Aku nampak satu pattern di sekeliling aku — ramai rakan sekerja dan entrepreneur yang tau AI tu berguna, tapi tak tau dari mana nak mula. Diorang rasa intimidated. Rasa macam AI ni untuk orang lain.

SAFE Framework hadir untuk break that barrier. Dengan 4 prinsip mudah:

• Start with the problem, bukan the tool
• Ask clearly, get clearly
• Feedback loop — iterate sampai dapat output yang ko nak
• Embed into your workflow — buat jadi habit

Siapa yang boleh guna?

Government officers. Usahawan. Guru. Event managers. Basically sesiapa yang ada kerja berulang yang makan masa. Kalau ko boleh type WhatsApp message, ko boleh guna AI.

Ini bukan sekadar bahan percuma

Cuba pergi ke safe.mohdhisyamudin.com untuk explore full playbook. SAFE ialah playbook premium bernilai, dibina daripada trial-and-error sebenar supaya anda boleh terus implement sistem AI dengan lebih cepat, teratur, dan kurang risiko.

Itulah asal cerita eRUAI untuk saya. Mula-mula nampak macam isu kecil: meeting clash, approval lambat, semua jadi last minute. Tapi bila dibiarkan, ia jadi culture — semua orang firefighting.

Versi 1.0: Excel (manual)

Saya bermula dengan cara paling asas — Excel. Masa tu niatnya cuma satu: sekurang-kurangnya ada rekod. Tapi bila volume meningkat, manual update jadi perlahan. Bila ramai orang sentuh data yang sama, error mula berlaku.

• Slot meeting overlap
• Status approval tak konsisten
• Sukar audit siapa buat apa

Versi 2.0: Semi-manual (PDF + Auto Email)

Saya cuba improve. Saya introduce semi-manual flow: generate PDF dan automate email untuk maklumkan status. Hasilnya memang lebih baik dari Excel. Tapi bila requirement jadi kompleks, flow ni mula tunjuk limit.

Masalah tak hilang, cuma beralih tempat: orang masih tanya status, masih ada bottleneck pada admin, dan meeting clash masih berlaku dalam situasi tertentu.

Turning point: Janji upgrade sebelum saya keluar admin

Ada satu janji yang saya pegang: sebelum saya keluar dari role admin, saya nak tinggalkan sistem yang lebih baik daripada asal. Saya cuba naikkan 2.0 dengan Google Sheet integration, tapi tak dapat response yang cukup untuk momentum.

Jadi saya decide buat 3.0 — web app sebenar dengan logic yang lebih kukuh. Di sinilah saya nampak kuasa vibe coding: bukan tunggu sempurna, tapi bina iteratif sampai orang nampak nilai.

Versi 3.0: Web App (React + Tailwind + Firebase)

Stack yang saya guna: React, Tailwind, Firebase. Fokus utama bukan design cantik dulu — fokus utama ialah logic anti-clash meeting.

Untuk saya, itu MVP sebenar: solve pain paling sakit dahulu.

Apa yang saya sengaja tangguh

• Email CC automatik
• Auto reminder
• Auto online meeting ID

Bukan sebab tak penting — tapi sebab saya tak nak overbuild awal. Saya pilih untuk launch fungsi paling kritikal dulu.

Status semasa: stabil, tapi saya still jujur tentang gap

eRUAI sekarang dalam keadaan stabil. Tapi saya tak suka cerita seolah-olah semuanya perfect. Masih ada 2-3 incident clash, terutama bila:

• Sistem belum ada logic combine room untuk attendance lebih besar
• Admin terlepas special request disebabkan bug tertentu

Bagi saya, ini bukan failure. Ini signal untuk next iteration.

Framework praktikal yang saya guna

1. See the main problem — jangan solve benda kosmetik dulu.
2. Solve the bottleneck — bina logic minimum yang terus kurangkan pain.
3. Deploy, observe, improve — data penggunaan sebenar lebih bernilai dari assumption.

Checklist action (kalau anda nak bina sistem sendiri)

• Senaraikan 3 pain paling mahal (masa, conflict, visibility).
• Pilih 1 pain paling kritikal untuk jadi MVP.
• Bina versi kecil, release cepat kepada user sebenar.
• Track incident, bukan sekadar feedback umum.
• Iterate mengikut bug/usage, bukan ikut ego builder.

Penutup

Kalau ada satu lesson dari eRUAI, ini dia: jangan tunggu sempurna untuk mula. Sistem yang baik selalunya lahir dari versi yang jujur, bukan versi yang pura-pura flawless.

Mulakan kecil, tapi konsisten improve. Itu yang bezakan project “cantik” dengan sistem yang betul-betul dipakai.

Masalah ni bukan sekadar “nampak serabut”. Ia bagi kesan terus pada execution — team jadi lambat, vendor jadi blur, dan deadline mula tertekan.

Kenapa MELI dibina?

MELI dibina sebagai platform untuk kumpul vendor yang berminat join sebagai service provider semasa event STB. Fokus utamanya ialah satu: jadikan data vendor teratur, boleh audit, dan mudah ditindak.

Nama MELI sendiri datang dari slang Sarawak yang dekat dengan maksud “selling”. Bagi saya, itu identiti yang cantik — lokal, relevan, dan ada karakter.

Masalah yang MELI cuba hentikan

• Data vendor bertebaran di banyak saluran
• Status tak jelas, jadi vendor asyik follow-up soalan sama
• Team terpaksa check manual berulang kali
• Deadline management jadi rapuh bila info tak sinkron

Design principle MELI (yang saya pegang)

1) Auditable

Setiap perubahan status mesti boleh dijejak. Bila ada pertikaian, kita rujuk data — bukan memory.

2) Simple

User tak perlu training panjang. Kalau UI terlalu kompleks, adoption jatuh.

3) Menyahut digitalisation

MELI bukan sekadar app. Ia sebahagian budaya kerja yang lebih cepat, lebih jelas, dan kurang friction.

Apa impak paling ketara setakat ini?

• Deadline lebih terkawal
• User boleh semak status sendiri (kurang tanya team berulang kali)
• Kurang workload checking manual untuk admin/team

Bila sistem buat kerja tracking asas dengan baik, team boleh fokus pada kerja keputusan (decision-making), bukan kerja clerical yang berulang.

Roadmap MELI (next phase)

• Integrasi POS
• Modul Sales Revenue
• Lebih banyak admin features untuk operasi skala lebih besar

Tapi prinsip saya kekal: add bila perlu, bukan sebab “nampak canggih”.

Risiko terbesar: Security

Saya paling risau tentang security. Dari pengalaman sistem terdahulu, saya dah awal-awal hardening MELI dengan panduan AI — dari access control, sanitization, hingga audit approach.

Bagi saya, sistem vendor bukan sekadar tempat simpan data — ia trust infrastructure. Kalau trust jatuh, sistem takkan dipakai walau secanggih mana pun.

Framework praktikal (untuk builder lain)

1. Problem to solve — jelaskan pain sebenar dengan spesifik.
2. Validate — release versi kecil kepada user sebenar.
3. Improve — upgrade ikut feedback dan data penggunaan.

Checklist action (untuk anda)

• Definisikan 1 objective utama sistem (contoh: status visibility).
• Pastikan setiap field dalam form ada tujuan operasi jelas.
• Bina dashboard status yang user boleh semak sendiri.
• Track bottleneck paling kerap (bukan yang paling bising).
• Upgrade secara berperingkat, jangan “buat semua” serentak.

Penutup

Kalau saya boleh ringkaskan Why MELI dalam satu ayat: sebab team perlukan satu sumber kebenaran yang boleh dipercayai.

Dan lesson paling penting: jangan buat semua dari awal. Start small, then scale with confidence.

Kalau nak elak burn masa, ini prinsip yang saya pegang: mula kecil, stabilkan, baru scale.

Kenapa “simple first” lebih laju?

Sebab automasi sebenar hidup dalam environment sebenar: internet down, API timeout, webhook delay, data format berubah, dan manusia typo input. Flow kecil lebih cepat dibaiki bila real-world issue muncul.

5 Tips n8n sebelum anda pergi besar

1) Satu flow = satu objective

Contoh objective: “Lead baru masuk form → hantar WhatsApp welcome”. Jangan campur sekali dengan invois, reminder, analytics, dan CRM sync dalam flow sama. Pisahkan.

2) Design fallback dari awal

Dari pengalaman kita, ada masa provider WhatsApp boleh down. Kalau tiada fallback, team panik dan kembali manual. Letak branch fallback (log + notify admin) supaya anda nampak bila flow tak berjalan.

3) Normalize data seawal mungkin

Contoh phone number: user isi "012..." atau "6012...". Standardize dulu (trim, remove spaces, add 6 jika perlu) sebelum hantar ke API. Ini kurangkan error pelik di hujung flow.

4) Log minimal tapi bermakna

Log benda penting sahaja: timestamp, input id, status step, error ringkas. Log yang terlalu detail tanpa struktur akan jadi noise dan susah audit.

5) Test dengan data real, bukan sample cantik

Uji dengan data yang messy: nama pelik, nombor tak lengkap, email typo, duplicate submit. Sistem production rosak bukan sebab data cantik — rosak sebab data sebenar.

Template progression (yang saya guna)

1. Version 0.1: Flow asas jalan end-to-end.
2. Version 0.2: Tambah validation + fallback.
3. Version 0.3: Tambah logging + notification.
4. Version 1.0: Stabil 7–14 hari tanpa incident besar.
5. Version 2.0: Baru scale (extra branch/integration/AI).

Checklist sebelum scale

• ✅ Error rate rendah dan boleh dijelaskan.
• ✅ Fallback path sudah diuji.
• ✅ Manual override ada (jika urgent).
• ✅ Team tahu baca log asas.
• ✅ Anda tahu bottleneck sebenar, bukan sekadar sangkaan.

Penutup

Automasi yang bagus bukan yang paling kompleks. Ia yang paling boleh dipercayai. Bila flow kecil dah stabil, anda akan scale dengan lebih tenang — bukan dengan harapan semata-mata.

Mulakan simple. Menang konsisten. Kemudian baru pergi besar.

🔥 Apa anda akan pelajari

• Apa itu AI automation
• Fungsi n8n untuk beginner
• Contoh automasi kerja sebenar
• Perjalanan saya dari zero tanpa coding

Video: Apa Itu n8n?

Anda boleh tonton video penuh di bawah:

Chapter ringkas video

• 00:00 — Intro & Siapa Saya
• 00:30 — Kenapa Saya Mula Belajar AI
• 01:00 — Jumpa ChatGPT & AI Agent
• 01:32 — Platform n8n: Apa & Kenapa
• 02:44 — Apa Yang Akan Anda Pelajari
• 04:18 — Ajak Join Journey

Apa itu AI automation dalam bahasa mudah?

AI automation ialah bila kita gabungkan proses kerja berulang dengan automasi dan AI supaya kerja lebih cepat, kurang manual, dan kurang error. Bukan bermaksud robot ambil alih semua kerja. Ia lebih kepada bantu manusia fokus pada kerja yang lebih penting.

Kenapa n8n sesuai untuk beginner?

Sebab n8n benarkan anda bina flow secara visual. Anda nampak step by step dari trigger hingga action. Untuk orang yang baru mula, ini sangat membantu sebab kita boleh faham logik proses dulu sebelum fikir benda kompleks.

Contoh automasi kerja sebenar

• Form masuk lead baru → simpan data → hantar notifikasi WhatsApp/email
• Mesej pelanggan masuk → classify intent → balas ikut template
• Data status kerja update → team terus dapat alert

Flow begini nampak kecil, tapi impak dia besar bila dibuat konsisten.

Perjalanan saya dari zero

Saya bermula dengan rasa blur juga. Saya tak tunggu jadi programmer baru nak mula. Saya belajar satu flow kecil dulu, test, gagal, baiki, dan ulang. Dari situ saya nampak satu perkara penting: yang penting bukan hafal code, tapi faham problem dan susun langkah penyelesaian.

Checklist action untuk beginner

• Pilih satu kerja berulang yang paling menyusahkan anda sekarang
• Lukis flow mudah atas kertas dulu
• Bina flow minimum dalam n8n
• Test dengan data real
• Tambah baik sikit demi sikit

Mulakan simple. Bila flow kecil dah stabil, barulah pergi ke automasi yang lebih besar.

Ni bukan exaggeration — itulah constraint sebenar yang aku hadapi. Dan aku nak share exactly macam mana ia jadi, termasuk bahagian-bahagian yang tak smooth.

Stack yang aku guna

• n8n — automation backbone, self-hosted
• WhatsApp Business API via third-party provider
• Google Sheets — knowledge base yang boleh di-update real-time
• LLM (Claude API) — untuk understand questions dan generate natural answers

Week 1: Setup & Knowledge Base

Hari pertama bukan coding — hari pertama adalah knowledge gathering. Aku pergi ke team RWMF dan kumpul semua FAQ yang biasa diorang dapat: parking, lineup, vendor requirements, ticketing, accessibility.

Semua masuk dalam Google Sheet. Simple. Tapi ini adalah the most important part — garbage in, garbage out.

Week 2: Testing & Go-Live

n8n workflow dia: WhatsApp message masuk → extract intent → cari dalam knowledge base → LLM polish the answer → reply. Kalau tak jumpa answer → escalate ke human.

Result? Lebih 70% queries answered automatically. Team aku boleh focus pada high-value interactions je.

Lesson terbesar: Start simple. Ship fast. Iterate. Chatbot pertama aku bukan perfect — tapi ia functional, dan functional beats perfect every time.

Apa yang dimaksudkan dengan 'Vibe'?

Bila ko describe sesuatu sistem kepada AI, ko perlu convey bukan sahaja apa yang ko nak, tapi juga feel dan context dia. Macam brief kepada designer — semakin jelas brief, semakin bagus output.

Contoh weak prompt: 'Buat dashboard'

Contoh vibe prompt: 'Buat dashboard untuk track project submissions dalam organisasi kerajaan. User adalah manager yang tak IT-savvy. Kena ada status indicator, filter by department, dan export to PDF. Dark theme, clean, no clutter.'

Nampak perbezaan? Yang kedua ada context, ada user persona, ada constraints, ada aesthetic direction.

3 Kemahiran Core Vibe Coding

• Context Engineering — Bagi AI semua maklumat yang dia perlukan upfront
• Iterative Prompting — Refine output step by step, jangan expect perfect on first try
• Error Interpretation — Bila ada error, describe error kepada AI dan tanya solution

Boleh ke orang bukan-IT belajar ni?

100% boleh. Malah, kadang-kadang orang bukan-IT lebih bagus dalam Vibe Coding sebab diorang focus kepada business problem, bukan kepada technical implementation. Diorang describe apa yang user perlukan — dan itulah sebenarnya yang paling penting.

Mulakan dengan satu masalah kecil dalam kerja harian ko. Describe kepada Claude atau ChatGPT. Iterate. Deploy. Ulangi.