Vibe Engineering: Tutorial Lengkap Membangun Aplikasi dengan AI secara Terencana dan Teruji

Diperbarui: 28 September 2026 · Panduan Tumbas.in

Anda meminta AI membuat aplikasi katalog produk. Beberapa menit kemudian tampil halaman yang menarik, tombolnya bisa diklik, dan formulirnya tampak berfungsi. Rasanya pekerjaan sudah selesai. Lalu seorang pelanggan membuka tautan produk yang seharusnya tersembunyi. Pengguna lain bisa mengubah harga barang milik toko berbeda. Setelah pembaruan kecil, fitur pencarian yang sebelumnya lancar berhenti bekerja. Tiga kejadian itu mempunyai akar yang sama: tampilan aplikasi sudah dilihat, tetapi perilaku dan batas aksesnya belum diperiksa.

Di sinilah gagasan vibe engineering berguna. AI tetap membantu menulis kode dan mempercepat pembuatan prototipe. Manusia terlebih dahulu merumuskan apa yang hendak dibuat, memberi batas yang jelas, memeriksa perubahan, menjalankan pengujian, dan mengambil keputusan ketika aplikasi akan dipakai orang lain. Tutorial ini menunjukkan cara menerapkan pola tersebut melalui contoh katalog produk UMKM. Anda tidak perlu langsung membangun sistem besar. Justru sebuah fitur kecil yang dapat dibuktikan bekerja adalah titik mulai yang lebih baik.

Hasil yang akan Anda peroleh adalah spesifikasi ringkas, rencana implementasi, kumpulan prompt yang bisa diadaptasi, rancangan data, contoh pengujian, daftar pemeriksaan keamanan, dan keputusan rilis yang bisa dijelaskan. Contoh kode memakai Laravel agar langkahnya konkret; prinsipnya berlaku pula untuk stack lain. Semua perintah dan cuplikan harus disesuaikan dengan versi serta struktur proyek Anda sebelum dijalankan.

Daftar isi

1. Apa itu vibe engineering?
2. Perbedaan dengan vibe coding dan agentic engineering
3. Kapan pendekatan ini cocok digunakan?
4. Studi kasus: katalog produk UMKM
5. Langkah 1: rumuskan masalah dan ruang lingkup
6. Langkah 2: siapkan proyek dan titik kembali
7. Langkah 3: minta AI menyusun rencana
8. Langkah 4: bangun fitur secara bertahap
9. Langkah 5: uji perilaku dan hak akses
10. Langkah 6: tinjau keamanan, data, dan biaya
11. Langkah 7: periksa pratinjau dan tentukan rilis
12. Langkah 8: pasang pemeriksaan otomatis pada pull request
13. Prompt siap pakai dan pemecahan masalah
14. FAQ dan checklist akhir

Apa itu vibe engineering?

Istilah vibe engineering dikemukakan Simon Willison pada Oktober 2025 untuk menggambarkan penggunaan model bahasa dan coding agent oleh orang yang tetap bertanggung jawab atas perangkat lunak yang dihasilkan. Ia menyoroti perencanaan, pengujian otomatis, dokumentasi, Git, code review, pemeriksaan manual, dan lingkungan pratinjau. Pada pembaruan Februari 2026, Willison menyebut istilah agentic engineering tampaknya lebih banyak dipakai untuk gagasan serupa. Karena itu, jangan menganggap vibe engineering sebagai sertifikasi resmi atau metodologi tunggal yang memiliki tahapan wajib bagi semua tim.

Dalam praktik, kata “engineering” berarti keputusan dibuat berdasarkan kebutuhan dan bukti. Sebelum meminta kode, Anda tahu siapa pemakainya dan tindakan apa yang harus berhasil. Setelah AI mengubah proyek, Anda dapat menyebutkan file yang berubah, alasan perubahan, cara mengujinya, dan risiko yang masih terbuka. Jika ada bug, Anda memiliki titik kembali. Jika fitur belum siap untuk pengguna, Anda menahannya di lingkungan pratinjau.

AI dapat mengerjakan banyak tugas: membaca struktur proyek, menyiapkan migration, menulis tampilan, menjelaskan error, atau menyusun usulan pengujian. Kemampuannya bukan jaminan bahwa kebutuhan bisnis sudah dipahami. Aplikasi yang berjalan di komputer pengembang pun belum membuktikan bahwa pengguna lain tidak bisa melihat data yang salah. Pekerjaan manusia bergeser ke spesifikasi, evaluasi, keputusan arsitektur, pengamanan, dan pemeliharaan.

Bayangkan seorang pemilik toko ingin katalog yang dapat diperbarui sendiri. Instruksi “buat aplikasi katalog modern” tidak menjawab apakah harga boleh nol, apakah produk dapat disembunyikan, siapa yang dapat mengedit, dan apa yang terjadi jika foto belum tersedia. Sebuah desain bisa tampak sempurna sambil melanggar semua aturan tersebut. Vibe engineering memberi ruang untuk menjawab pertanyaan sebelum dan selama implementasi.

Perbedaan dengan vibe coding dan agentic engineering

Dalam arti awal yang dikaitkan dengan Andrej Karpathy, vibe coding menekankan pemberian instruksi dalam bahasa alami kepada AI, mencoba hasilnya, lalu meminta perubahan tanpa memperhatikan kode secara mendalam. Martin Fowler menggunakan batas itu untuk membedakannya dari pekerjaan dengan agent yang hasil kodenya tetap dievaluasi. Dalam penggunaan sehari-hari, orang sering menyebut setiap kegiatan pemrograman bersama AI sebagai vibe coding. Karena maknanya meluas, artikel ini selalu menjelaskan perilakunya, bukan sekadar menempelkan label pada seseorang.

Prototipe cepat tetap berguna. Halaman sekali pakai untuk mencoba gagasan berbeda risikonya dari aplikasi yang menyimpan alamat pelanggan. Tingkat pemeriksaan harus mengikuti dampak kesalahan. Jika produk dipakai orang lain, kesalahan akses dapat merugikan mereka, sehingga beban verifikasi naik. Tidak ada kewajiban membaca setiap baris dari setiap dependensi agar bekerja secara bertanggung jawab, tetapi perubahan yang menyentuh otorisasi, data, pembayaran, dan konfigurasi rahasia memerlukan perhatian khusus. Bukti uji, perilaku di pratinjau, dan batas akses harus dapat dinilai.

Agentic engineering biasanya merujuk pada kerja menggunakan agent yang dapat membaca proyek, mengubah file, menjalankan perintah, melihat hasil, lalu mengulang sampai tugas selesai. Kata agentic menyoroti kemampuan alat untuk bertindak dalam beberapa langkah. Kata engineering menyoroti cara kita mengarahkan dan mengevaluasi tindakan itu. Willison kemudian memakai istilah agentic engineering; Fowler juga memakai istilah agentic programming. Terminologi ini masih bergerak. Untuk pembaca pemula, prinsip yang terpenting adalah AI dapat membantu membuat perangkat lunak, sementara pemilik proyek tetap menetapkan dan memeriksa standar hasil.

Kapan pendekatan ini cocok digunakan?

Pendekatan ini berguna ketika Anda mempunyai tujuan produk yang jelas tetapi ingin mempersingkat pekerjaan rutin. Contohnya membuat formulir pendaftaran, halaman administrasi katalog, impor data, laporan internal, atau pengujian sebuah alur yang sudah dikenal. AI bisa membaca dokumentasi dan menyusun perubahan dalam waktu singkat; Anda menyaring usulan yang sesuai dengan kebutuhan nyata.

Untuk percobaan pribadi, cukup mulai dengan spesifikasi sederhana dan beberapa pemeriksaan manual. Untuk aplikasi yang menerima data pelanggan, sertakan autentikasi, otorisasi, validasi, perlindungan data, dan pemantauan. Untuk sistem pembayaran, kesehatan, kepegawaian, atau keputusan yang berdampak besar, libatkan orang yang menguasai domain dan keamanan, lalu lakukan penilaian lebih ketat. Satu prompt yang sama tidak cocok untuk semua tingkat risiko.

Ada kalanya Anda lebih baik memakai layanan yang sudah ada daripada membangun aplikasi baru. Jika kebutuhan hanya menampilkan profil usaha, katalog singkat, dan tombol kontak, biolink Tumbas.in mungkin memenuhi tujuan lebih cepat. Jika kebutuhan menyertakan aturan harga khusus, beberapa pengelola, dan integrasi inventaris, pengembangan sendiri bisa dipertimbangkan. Ini adalah keputusan produk yang perlu ditulis sebelum memilih bahasa pemrograman.

Jangan mengirim data pelanggan asli, kata sandi, token, atau isi berkas konfigurasi rahasia ke layanan AI semata-mata untuk mendapatkan jawaban cepat. Gunakan data contoh yang tidak mengidentifikasi orang. Bila organisasi mempunyai aturan pemrosesan data dan akses alat, ikuti aturan itu. Dokumen persyaratan yang baik dapat menjelaskan bentuk data tanpa membagikan data pribadi.

Studi kasus: katalog produk UMKM

Kita akan membuat versi awal katalog bernama “Katalog Toko”. Tamu dapat melihat produk aktif dan membuka detail. Pemilik yang sudah masuk dapat menambah dan memperbarui produknya sendiri. Produk memiliki nama, slug, deskripsi, harga dalam rupiah sebagai bilangan bulat, status tayang, dan waktu pencatatan. Foto, keranjang, pembayaran, dan integrasi pesan ditunda sampai alur dasar stabil. Dalam artikel ini, spesifikasi tersebut adalah contoh keputusan, bukan definisi wajib bagi setiap toko.

Target pengguna pertama adalah pemilik toko yang mengelola sekitar puluhan produk dan pelanggan yang membuka katalog melalui ponsel. Dua tugas utamanya sederhana: pemilik memperbarui harga tanpa meminta bantuan developer; pelanggan mendapatkan informasi produk aktif yang benar. Ukuran keberhasilan versi awal: pemilik dapat menambah produk valid, mengubah produk miliknya, gagal mengubah produk orang lain, dan pelanggan tidak melihat produk berstatus draf.

Asumsikan proyek memakai Laravel 12, PHP dan Composer yang memenuhi persyaratan versi tersebut, database PostgreSQL pada lingkungan pengembangan, serta Git. Laravel 12 dipilih sebagai contoh, bukan rekomendasi mutlak untuk proyek baru; periksa dokumentasi versi proyek Anda sebelum menyalin perintah. Pengujian dapat memakai database pengujian terpisah sesuai konfigurasi lokal. Jangan menjalankan perintah reset database pada basis data produksi.

Mengapa harga disimpan sebagai bilangan bulat? Karena contoh menggunakan rupiah tanpa pecahan, angka 25000 lebih mudah ditangani daripada representasi desimal yang tidak diperlukan. Kebutuhan lain, misalnya mata uang dengan sen atau aturan pajak, memerlukan model data dan perhitungan berbeda. Mengapa status produk diperlukan? Agar pemilik dapat menyiapkan draf yang tidak tampil ke publik. Mengapa ada owner_id? Agar aplikasi dapat memutuskan siapa yang berhak mengubah produk. Keputusan kecil ini mengubah migration, validasi, query, dan pengujian.

Hasil akhir contoh bukan janji bahwa cuplikan di bawah membentuk aplikasi lengkap setelah ditempel. Tutorial ini mengajarkan alur kerja dan titik pemeriksaannya. Nama route, model pengguna, mekanisme login, dan tampilan perlu diselaraskan dengan proyek Anda. Bila Anda mengikuti tutorial dalam proyek yang sudah ada, periksa kode yang sudah berjalan agar AI tidak membuat fitur duplikat.

Langkah 1: rumuskan masalah dan ruang lingkup

Mulailah dengan dokumen SPEC.md sepanjang satu atau dua halaman. Tulis siapa pengguna, masalah yang dipecahkan, perilaku yang harus ada, perilaku yang sengaja ditunda, aturan data, serta cara memutuskan bahwa sebuah fitur selesai. Dokumen ini adalah acuan bagi Anda dan AI ketika percakapan menjadi panjang atau tugas berpindah ke sesi berikutnya.

Contoh ringkasan kebutuhan: “Pemilik toko yang telah login dapat membuat produk dengan nama 3–120 karakter, harga bilangan bulat lebih dari nol, deskripsi opsional hingga 2.000 karakter, dan status draf atau aktif. Publik hanya melihat produk aktif. Pemilik hanya dapat mengubah dan menghapus produk miliknya. Bila slug sudah dipakai, penyimpanan gagal dengan pesan yang jelas. Versi awal tidak mempunyai pembayaran dan unggah foto.” Batas tersebut lebih mudah diuji daripada “buat katalog profesional”.

Tulis pula kriteria penerimaan dengan pola ketika, tindakan, hasil. Ketika tamu mengunjungi katalog, yang tampil hanya produk aktif. Ketika pemilik mencoba membuka halaman edit produk milik akun lain, permintaan ditolak. Ketika harga kosong, formulir menampilkan pesan validasi dan tidak membuat produk. Ketika produk berubah menjadi draf, ia tidak muncul di halaman publik. Kalimat ini dapat diterjemahkan menjadi pengujian tanpa menebak maksud bisnis.

Pertimbangkan kondisi yang sering terlewat: daftar kosong, deskripsi panjang, nama produk yang sama, slug yang berkonflik, format harga dari formulir, tombol simpan yang diklik dua kali, halaman yang sempit, serta akun yang belum login. Jika suatu kondisi belum diputuskan, beri tanda “perlu keputusan”. Minta AI mengajukan pertanyaan alih-alih mengarang aturan.

Gunakan prompt berikut untuk memperbaiki spesifikasi sebelum menulis kode:

Saya ingin membuat katalog produk UMKM di proyek Laravel yang sudah ada.
Jangan ubah file dahulu. Baca struktur proyek yang relevan dan ringkas temuan.
Bandingkan kebutuhan di SPEC.md dengan fitur yang sudah tersedia.
Daftarkan keputusan yang masih ambigu, risiko hak akses, dan lima kasus
uji paling penting. Ajukan pertanyaan bila aturan bisnis belum jelas.
Jangan mengarang fitur pembayaran, unggah foto, atau peran admin.

Perhatikan dua frasa yang sering menyelamatkan waktu: “jangan ubah file dahulu” dan “fitur yang sudah tersedia”. Tanpa keduanya, agent bisa langsung membangun tabel pengguna atau halaman login kedua. Kebutuhan diperiksa lebih dahulu, kemudian pekerjaan ditugaskan.

Langkah 2: siapkan proyek dan titik kembali

Gunakan repositori Git agar perubahan mudah dibandingkan dan dikembalikan. Pada proyek yang sudah ada, periksa status kerja terlebih dahulu. Bila terdapat perubahan milik orang lain, jangan minta agent menimpa atau merapikannya tanpa memahami tujuan perubahan itu. Buat cabang kerja khusus, lalu lakukan commit pada titik yang telah diverifikasi. Nama cabang seperti feature/katalog-produk cukup menjelaskan maksudnya.

Contoh perintah yang dijalankan di proyek Anda sendiri, setelah memahami status repositori:

git status
git switch -c feature/katalog-produk
php artisan about
php artisan test

Perintah php artisan about membantu Anda mengenali konfigurasi aplikasi. php artisan test memberi gambaran apakah pengujian dasar sudah sehat. Jika pengujian awal gagal, catat hasilnya; jangan menyalahkan perubahan baru atas kegagalan yang sudah ada. Proyek baru boleh memakai cara instalasi resmi Laravel yang sesuai lingkungan lokal, tetapi versi, PHP, Composer, dan database harus dipastikan terlebih dahulu. Jangan menyalin rangkaian instalasi dari artikel lama tanpa memeriksa dokumentasi.

Pisahkan konfigurasi lokal dan pengujian. Jangan memasukkan .env berisi kredensial ke Git, dan jangan menempelkan isinya ke prompt. env.example dapat menunjukkan nama variabel yang diperlukan tanpa nilai rahasia. Untuk database, buat pengguna dan basis data lokal dengan hak minimum yang dibutuhkan; siapkan basis data pengujian terpisah sehingga test yang membuat atau menghapus data tidak menyentuh data kerja.

Catat keadaan awal dalam README proyek: cara menjalankan aplikasi, cara menjalankan test, lokasi konfigurasi, dan langkah memulihkan dari kesalahan. Dokumentasi singkat itu membuat agent berikutnya tidak perlu menebak. Jika dependensi atau skrip instalasi berubah, perbarui catatan dalam perubahan yang sama. Perubahan yang tidak bisa diulang oleh rekan kerja menunjukkan ada langkah yang hilang.

Tentukan batas operasi AI. Agent boleh mengubah kode aplikasi dan menjalankan test lokal, tetapi perubahan schema database yang telah berisi data, instalasi paket baru, konfigurasi produksi, dan deployment perlu ditinjau khusus. Batas ini dapat ditulis dalam instruksi proyek sehingga tidak bergantung pada ingatan percakapan. Pembatasan mengikuti dampak pekerjaan, bukan ketidakpercayaan umum terhadap alat.

Langkah 3: minta AI menyusun rencana

Sebelum implementasi, mintalah rencana satu halaman. Rencana yang baik menyebut file atau area yang mungkin berubah, urutan kerja, dependensi, keputusan data, risiko, dan bukti keberhasilan. Ia tidak perlu menjadi dokumen panjang. Tujuannya untuk menemukan asumsi yang salah sebelum AI menghasilkan banyak kode.

Berdasarkan SPEC.md dan struktur proyek saat ini, buat rencana untuk
fitur katalog produk. Jangan mengubah file.
Urutkan perubahan kecil yang dapat diuji secara terpisah.
Untuk setiap tahap, sebutkan perilaku, file yang mungkin berubah,
pengujian yang membuktikan keberhasilannya, dan risiko utama.
Jelaskan bagaimana publik hanya melihat produk aktif dan bagaimana
pemilik hanya dapat mengubah produknya sendiri.
Tandai keputusan yang memerlukan jawaban saya.

Tinjau rencana dari sudut pandang pemilik produk. Apakah ia langsung membangun pembayaran? Itu di luar ruang lingkup. Apakah ia menambahkan kolom owner_id dan menghubungkannya ke akun? Jika tidak, aturan kepemilikan belum punya dasar. Apakah daftar publik menyaring status di query, bukan hanya menyembunyikannya lewat CSS? Jika tidak, data draf tetap bisa dikirim ke browser. Apakah test mencakup akun berbeda? Jika tidak, masalah akses mungkin baru terlihat setelah rilis.

Setelah rencana cocok, pecah pekerjaan. Tahap pertama: model data dan test untuk aturan status. Tahap kedua: daftar dan detail publik. Tahap ketiga: pembuatan serta edit oleh pemilik. Tahap keempat: penyempurnaan tampilan dan pemeriksaan manual. Tidak ada manfaat meminta perubahan pada dua puluh area sekaligus jika Anda tidak bisa mengaitkan kegagalan dengan perubahan tertentu.

AI dapat menghasilkan rencana yang tampak meyakinkan tetapi salah membaca kebiasaan proyek. Cek nama tabel dan route yang ada, sistem autentikasi, pola controller, serta test yang sudah tersedia. Bila proyek memakai service layer, jangan menambahkan logika bisnis sembarang di view hanya karena cara itu paling cepat. Konsistensi membuat fitur lebih mudah dipelihara oleh manusia dan agent berikutnya.

Langkah 4: bangun fitur secara bertahap

Mulai dari skema. Contoh tabel products mempunyai id, owner_id, name, slug, description, price_idr, status, dan timestamps. Tentukan owner_id wajib, slug unik, harga tidak negatif menurut kebutuhan yang disepakati, serta indeks yang berguna untuk daftar publik. Lakukan review migration sebelum dijalankan pada basis data yang memiliki isi. Perubahan schema yang aman di database kosong bisa berisiko pada database dengan data lama.

Contoh potongan migration untuk memperjelas aturan, bukan berkas yang bisa langsung menggantikan migration lengkap:

Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->foreignId('owner_id')->constrained('users');
    $table->string('name', 120);
    $table->string('slug', 160)->unique();
    $table->text('description')->nullable();
    $table->unsignedBigInteger('price_idr');
    $table->string('status', 16)->default('draft');
    $table->timestamps();
    $table->index(['status', 'created_at']);
});

Dalam database, aturan price_idr sebagai unsigned tidak selalu menggantikan validasi aplikasi yang menyatakan harga lebih dari nol. Input dari pengguna harus divalidasi sebelum disimpan. Aturan status juga perlu dibatasi ke nilai yang dikenal, misalnya draft atau active. Jangan mengandalkan tombol pilihan di halaman web saja: request bisa dikirim langsung tanpa mengikuti tampilan.

Permintaan pertama kepada AI dapat dibuat sesempit ini:

Implementasikan hanya model, migration, factory, dan pengujian dasar
untuk produk sesuai SPEC.md. Jangan membuat halaman atau controller.
Ikuti pola proyek. Jangan menjalankan reset database di luar lingkungan test.
Setelah selesai, ringkas perubahan per file, perintah yang dijalankan,
hasil test, dan asumsi yang belum dibuktikan.

Periksa git diff setelah tahap pertama. Cari dependensi baru yang tidak diminta, perubahan pada file konfigurasi yang tak berhubungan, penghapusan test, serta perubahan data yang tersembunyi di seeder. Jika agent menulis test lalu hanya berkata “semua aman”, minta keluaran perintah yang dijalankan dan lihat sendiri. Test yang hijau membuktikan kondisi yang diuji; ia tidak membuktikan semua perilaku produk.

Tahap kedua adalah halaman publik. Query harus memuat hanya produk aktif. Detail produk draf semestinya tidak tersedia bagi tamu melalui slug, sekalipun tautannya diketahui. Untuk pemilik, buat tampilan khusus yang dapat menampilkan draf miliknya setelah login. Pemisahan query publik dan query dashboard mencegah kesalahan ketika fitur bertambah.

Tahap ketiga adalah tindakan pemilik. Gunakan mekanisme autentikasi yang sudah ada. Periksa otorisasi untuk menampilkan form edit, menyimpan perubahan, serta menghapus. Hanya menampilkan tombol edit untuk pemilik tidak cukup: pengguna bisa mengirim request langsung ke alamat edit. Aturan harus ditegakkan di sisi server melalui policy atau pemeriksaan otorisasi lain sesuai pola proyek.

Contoh gagasan policy Laravel:

public function update(User $user, Product $product): bool
{
    return $product->owner_id === $user->id;
}

Metode itu baru berguna jika benar-benar dipanggil pada alur edit dan update. Karena itu review harus mengikuti perjalanan request: route, autentikasi, pengambilan produk, otorisasi, validasi, penyimpanan, respons. Jangan hanya memeriksa bahwa berkas policy ada. Aturan delete pun perlu keputusan tersendiri, bukan otomatis disamakan dengan update bila kebutuhan berbeda.

Gunakan validasi sisi server untuk nama, slug, deskripsi, harga, dan status. Saat mengubah produk, aturan keunikan slug perlu mengabaikan produk yang sedang diedit dengan cara yang sesuai dokumentasi dan identitas produk yang terpercaya. Jangan menerima owner_id dari form lalu langsung menyimpannya sebagai milik pengguna lain; kepemilikan sebaiknya ditentukan dari akun yang terautentikasi. Review atribut yang boleh diisi secara massal agar request tidak bisa mengubah kolom yang tidak seharusnya.

Setelah fungsi dasarnya berjalan, baru rapikan tampilan. Periksa ponsel kecil, teks panjang, keadaan tanpa produk, harga yang besar, kontras warna, label input, pesan error, serta tombol yang bisa dipakai dengan keyboard. AI sering menunjukkan keadaan ideal dengan foto dan teks rapi; pengguna sesungguhnya datang dengan data tidak seragam. Minta agent memakai data uji yang sengaja sulit agar desain tidak hanya cantik pada screenshot pertama.

Langkah 5: uji perilaku dan hak akses

Pengujian adalah cara menerjemahkan spesifikasi menjadi bukti yang bisa diulang. Mulai dari jalur yang paling berisiko: siapa boleh melihat dan mengubah apa. Test yang diperlukan untuk katalog ini mencakup daftar publik hanya berisi produk aktif; detail draf tidak dapat dibaca tamu; tamu tidak dapat mengakses pembuatan produk; pemilik dapat mengubah produknya; akun berbeda ditolak; harga nol atau kosong ditolak; dan slug duplikat menghasilkan kegagalan validasi yang benar.

Contoh test berikut bersifat ilustratif. Sesuaikan nama route, factory, kebijakan akses, dan assertion dengan proyek Anda:

public function test_user_cannot_update_another_users_product(): void
{
    $owner = User::factory()->create();
    $other = User::factory()->create();
    $product = Product::factory()->for($owner, 'owner')->create();

    $this->actingAs($other)
        ->put(route('products.update', $product), [
            'name' => 'Harga Diubah',
            'slug' => $product->slug,
            'price_idr' => 1000,
            'status' => 'active',
        ])
        ->assertForbidden();

    $this->assertDatabaseMissing('products', [
        'id' => $product->id,
        'name' => 'Harga Diubah',
    ]);
}

Perhatikan assertion kedua. Respons 403 saja belum cukup bila suatu bug sempat menyimpan perubahan sebelum mengirim respons. Pastikan data tidak berubah. Sebaliknya, test untuk pemilik yang sah harus membuktikan update benar-benar tersimpan. Jika aplikasi sengaja mengembalikan 404 untuk menyembunyikan keberadaan produk orang lain, ubah assertion sesuai kebijakan yang disepakati; inti ujiannya adalah akses ditolak dan data tetap aman.

Mintalah AI menjelaskan mengapa setiap test penting. Bila test hanya memanggil metode yang baru saja ia tulis dengan data mudah dan membandingkan hasil yang sama, ia bisa menjadi cermin implementasi tanpa menangkap risiko nyata. Test yang baik bertolak dari aturan bisnis: “akun B tidak mengubah produk akun A” tetap bermakna meskipun implementasi berpindah dari controller ke service.

Jalankan suite yang relevan setelah setiap tahap. Untuk Laravel, php artisan test menjalankan pengujian aplikasi; perhatikan konfigurasi database test sebelum perintah dijalankan. Tambahkan formatter atau pemeriksaan statis yang sudah dipakai proyek. Jangan memasang paket hanya agar checklist tampak lengkap. Bila test gagal, simpan pesan error, nama test, dan perubahan terakhir. Minta AI menelusuri penyebab paling mungkin, bukan menonaktifkan test yang gagal.

Manual QA melengkapi pengujian otomatis. Buka halaman katalog sebagai tamu di ponsel, buka detail produk, coba slug yang tidak ada, ubah status produk dari aktif ke draf, lalu ulangi akses tautan lama. Masuk sebagai dua akun berbeda dan coba alamat edit secara langsung. Isi nama sangat panjang dan harga tidak valid. Periksa tampilan setelah validasi gagal: apakah input tetap terlihat, pesannya dapat dipahami, dan produk tidak tersimpan sebagian?

Tulis matriks sederhana di catatan rilis: skenario, hasil yang diharapkan, hasil aktual, dan bukti. Screenshot berguna untuk masalah tampilan; keluaran test berguna untuk perilaku yang tidak terlihat. Tanggal dan commit membantu Anda memahami versi mana yang diuji. Jika ada bug, perbaiki di cabang yang sama dan ulangi skenario terkait. Semakin kecil perubahan, semakin mudah menemukan penyebabnya.

Langkah 6: tinjau keamanan, data, dan biaya

Keamanan bukan satu prompt seperti “pastikan aman”. Tinjau jalur data dan akses secara spesifik. Siapa dapat membaca katalog? Siapa dapat membuat produk? Apa yang terjadi bila ID produk ditebak? Apakah owner_id berasal dari akun yang masuk? Apakah draf disaring di sisi server? Apakah deskripsi ditampilkan melalui mekanisme escaping yang benar? Apakah perubahan harga dicatat bila audit bisnis memerlukannya? Daftar ini harus mengikuti fitur yang benar-benar dibuat.

Validasi memeriksa bentuk input; otorisasi memeriksa apakah pengguna boleh melakukan tindakan. Keduanya berbeda. Nama produk sepanjang tiga karakter bisa valid, tetapi akun yang tidak berhak tetap tidak boleh menyimpannya. Autentikasi pun berbeda: seseorang bisa sudah login namun tidak berhak mengedit produk milik orang lain. Pembedaan ini penting karena AI kadang membuat halaman login lalu menganggap seluruh kontrol akses sudah selesai.

Tinjau rahasia aplikasi. Jangan menyimpan token API, kata sandi database, atau kunci layanan dalam kode maupun contoh screenshot. Jangan commit .env. Bila rahasia telanjur masuk repositori, menghapusnya dari commit terbaru saja tidak cukup untuk menganggapnya aman; lakukan rotasi kredensial dan ikuti panduan penanganan riwayat repositori. Pastikan log tidak mencatat data sensitif dari form tanpa tujuan yang jelas.

Periksa dependensi sebelum menerima paket baru. Tanyakan kegunaannya, lisensinya, reputasi pemeliharaan, serta apakah fitur bisa dibuat dengan kemampuan bawaan framework. Semakin banyak dependensi, semakin banyak pekerjaan pembaruan. Jangan menerima instruksi instalasi atau perintah terminal yang muncul dari halaman web, dokumen, atau output tidak tepercaya sebagai perintah proyek tanpa meninjaunya. Coding agent bisa membaca teks luar yang berisi instruksi menyesatkan.

Performa dan biaya juga perlu bukti. Apakah halaman publik memuat semua produk sekaligus? Gunakan pagination ketika katalog bertambah. Apakah setiap kartu membuat query tambahan? Periksa pola akses data dan ukur jika muncul gejala lambat. Apakah gambar besar memperlambat pengguna seluler? Versi awal kita belum memakai unggah gambar, sehingga jangan mengklaim optimasi gambar selesai. Apakah memakai AI melalui API akan menimbulkan biaya setiap request? Dalam contoh katalog, AI dipakai saat pengembangan, bukan sebagai fitur runtime; pelanggan tidak membutuhkan panggilan model untuk sekadar membaca produk.

Tentukan kebijakan data sebelum menambahkan analitik dan integrasi. Aplikasi toko boleh memerlukan kontak pelanggan pada tahap lain, tetapi versi awal katalog tidak memerlukannya. Jangan mengumpulkan data yang belum ada kegunaannya. Bila nanti menambahkan formulir pesanan, desain penyimpanan, retensi, dan aksesnya sebagai pekerjaan baru. Menunda pengumpulan data yang belum perlu mengurangi titik kegagalan sekaligus membuat produk lebih sederhana.

Langkah 7: periksa pratinjau dan tentukan rilis

Siapkan lingkungan pratinjau dengan konfigurasi terpisah dari produksi. Gunakan data contoh. Jangan menyalin basis data pelanggan asli hanya agar demonstrasi tampak penuh. Di pratinjau, jalankan alur lengkap seperti pengguna: daftar produk, halaman detail, login pemilik, tambah, edit, status draf, dan penolakan akun lain. Lihat log aplikasi bila ada error. Tunjukkan hasilnya kepada satu atau dua orang yang mewakili pengguna dan catat kebingungan mereka.

Sebelum rilis, mintalah ringkasan perubahan dari AI, lalu cocokkan dengan git diff, hasil test, dan pengalaman di browser. Catat migration yang akan berjalan dan rencana cadangan database bila ada data produksi. Perubahan schema perlu strategi yang mempertimbangkan data lama dan cara pemulihan; migrate:rollback tidak selalu cukup sebagai pemulihan jika data sudah diubah atau dihapus. Pilih waktu rilis yang memungkinkan pemantauan.

Keputusan rilis dapat ditulis: “Versi katalog boleh diterbitkan bila semua kriteria penerimaan lulus, tidak ada temuan hak akses terbuka, tampilan ponsel dapat digunakan, backup tersedia, dan pemilik tahu cara memperbarui produk.” Bila salah satu syarat penting belum terpenuhi, lakukan perbaikan dan uji ulang. Tidak perlu mengejar kesempurnaan visual untuk versi pertama, tetapi data dan akses pengguna harus benar sesuai ruang lingkup.

Setelah rilis, amati error, halaman yang paling dipakai, serta pertanyaan pemilik toko. Pembaruan pertama mungkin berasal dari kebingungan mengatur status aktif, bukan dari ide fitur baru yang glamor. Masukkan temuan itu ke SPEC.md, prioritaskan perubahan kecil berikutnya, dan ulangi siklus. Dengan begitu, AI membantu pertumbuhan produk tanpa membuat proyek menjadi kumpulan perubahan yang tidak dipahami siapa pun.

Langkah 8: pasang pemeriksaan otomatis pada pull request

Sampai di sini, pengujian masih bergantung pada komputer orang yang mengerjakan perubahan. Tambahkan pemeriksaan otomatis agar setiap pull request mendapat hasil yang bisa dilihat seluruh tim. GitHub Actions dapat menjalankan test pada lingkungan baru dan menyediakan PostgreSQL melalui service container. Ini adalah continuous integration (CI). Mengirim versi baru ke server adalah pekerjaan lain, yaitu continuous delivery atau deployment (CD). Pipeline test yang hijau tidak membuktikan bahwa aplikasi telah terpasang dengan benar di server produksi.

Untuk contoh katalog, buat satu tugas kerja: “Produk berstatus draf tidak muncul pada daftar dan detail publik, sementara pemilik dapat melihatnya pada dashboard.” Simpan kriteria penerimaan di deskripsi issue GitHub atau dokumen proyek. Buat cabang feature/sembunyikan-produk-draf, kerjakan perubahan dan test di sana, lalu ajukan pull request. Anda boleh meminta agent menyiapkan draf issue dan perubahan lokal. Tinjau isi issue sebelum dipublikasikan dan tinjau perubahan kode sebelum digabungkan.

Di bawah ini contoh berkas .github/workflows/tests.yml untuk proyek Laravel 12 yang memang memakai PostgreSQL. Sesuaikan versi PHP, dependensi ekstensi, konfigurasi test, dan cara membangun aset dengan proyek Anda. Password pada contoh hanya dipakai untuk database sementara di runner pengujian; jangan menaruh kredensial produksi dalam workflow.

name: Tes katalog

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: katalog_test
          POSTGRES_USER: katalog
          POSTGRES_PASSWORD: test_only_password
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U katalog -d katalog_test"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    env:
      APP_ENV: testing
      DB_CONNECTION: pgsql
      DB_HOST: 127.0.0.1
      DB_PORT: 5432
      DB_DATABASE: katalog_test
      DB_USERNAME: katalog
      DB_PASSWORD: test_only_password
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: pdo_pgsql
          coverage: none
      - run: composer install --no-interaction --prefer-dist
      - run: cp .env.example .env
      - run: php artisan key:generate
      - run: php artisan migrate --force
      - run: php artisan test

Periksa apakah workflow itu cocok dengan proyek sebelum menyalinnya. Bila test memakai SQLite, service PostgreSQL dapat menjadi beban tanpa manfaat, kecuali Anda memang hendak membuktikan perilaku spesifik PostgreSQL. Bila ada konfigurasi Vite atau aset yang dibutuhkan test browser, tambahkan instalasi Node dan build secara eksplisit. Bila proyek memerlukan ekstensi PHP lain, deklarasikan. Pengujian yang gagal pada CI karena lingkungan berbeda tidak boleh “diperbaiki” dengan menghapus test; samakan kebutuhan lingkungan dan telusuri kegagalan yang sebenarnya.

Prompt untuk agent pada tahap ini dapat berbunyi: “Baca composer.json, konfigurasi test, dan workflow yang sudah ada. Usulkan perubahan CI terkecil agar test katalog berjalan pada pull request menggunakan database sesuai proyek. Jangan mengubah konfigurasi deployment. Setelah membuat workflow, jelaskan semua asumsi tentang PHP, ekstensi, database, dan aset frontend.” Tinjau usulannya. Jika repositori sudah mempunyai workflow yang setara, lebih baik menyempurnakannya daripada membuat workflow duplikat.

Setelah membuka pull request, tunggu hasil test, baca diff, dan lakukan review pada aturan akses serta data. Jika ada kegagalan, reproduksi lokal bila memungkinkan, perbaiki dalam cabang yang sama, lalu periksa hasil CI yang baru. Cabang utama dapat dilindungi dengan syarat pemeriksaan status dan review sebelum merge. Aturan tersebut diatur pada repositori; sebuah berkas workflow saja tidak otomatis mencegah merge ketika hasilnya merah. Setelah perubahan disetujui dan pemeriksaan yang diwajibkan lulus, barulah gabungkan menurut tata kelola proyek.

Jangan memberi satu instruksi umum kepada agent untuk membuat issue, menulis kode, mendorong cabang, menggabungkan pull request, dan menerbitkan produksi sekaligus tanpa titik pemeriksaan manusia. Ringkasan satu kalimat boleh dipakai untuk menguraikan tugas, tetapi keputusan atas ruang lingkup, review, dan rilis perlu terlihat. Untuk katalog UMKM, langkah berikutnya setelah merge dapat berupa deployment ke pratinjau dengan konfigurasi aman, uji alur oleh pemilik toko, baru kemudian rilis produksi. Cara deployment bergantung pada hosting yang dipakai dan berada di luar contoh workflow test ini.

Prompt siap pakai dan pemecahan masalah

Prompt untuk memulai fitur:

Baca SPEC.md, README, route, model, dan test yang terkait.
Ringkas kondisi proyek sebelum membuat perubahan. Implementasikan hanya
tahap [nama tahap] dari rencana. Ikuti konvensi yang sudah ada.
Tambahkan pengujian yang memeriksa kriteria penerimaan, jalankan test,
lalu laporkan file yang diubah, hasilnya, dan risiko tersisa.
Jangan ubah fitur lain atau melakukan deployment.

Prompt untuk mencari kesalahan tanpa menebak:

Skenario yang gagal: [langkah yang saya lakukan].
Hasil yang diharapkan: [hasil]. Hasil aktual: [hasil].
Pesan error: [kutipan yang relevan tanpa rahasia].
Periksa perubahan terakhir dan buat hipotesis penyebab yang bisa diuji.
Reproduksi pada lingkungan lokal, lakukan perbaikan paling kecil,
tambahkan test regresi yang relevan, lalu jelaskan bukti perbaikannya.

Prompt untuk review perubahan:

Tinjau diff saat ini terhadap SPEC.md. Fokus pada hak akses antar akun,
validasi sisi server, data draf yang bocor ke publik, migration,
kompatibilitas pola proyek, dan test yang belum mencakup kasus penting.
Laporkan temuan berdasarkan tingkat dampak dan lokasi file.
Jangan mengubah kode dalam tahap review ini.

Prompt untuk penjelasan kepada pemilik usaha:

Jelaskan alur katalog ini tanpa jargon: cara menambah produk,
mengubah harga, menyembunyikan produk, dan mengetahui kesalahan input.
Pisahkan fitur yang sudah diuji dari fitur yang masih rencana.
Sebutkan dua keterbatasan versi pertama secara jujur.

Jika AI mengubah terlalu banyak file, hentikan tahap tersebut dan minta pemetaan perubahan: file, alasan, serta kaitannya dengan kriteria penerimaan. Bila ada perubahan di luar ruang lingkup, tinjau lalu kembalikan bagian itu secara hati-hati tanpa menimpa kerja lain. Jika AI berulang kali mencoba solusi acak, persempit masalah menjadi satu reproduksi yang jelas. Agent lebih mudah memperbaiki “akun B mendapat 200 saat PUT produk akun A” daripada “fitur keamanan masih aneh”.

Jika test lulus tetapi perilaku di browser salah, periksa apakah test memakai route yang sama, konfigurasi yang sama, data dengan status yang benar, dan middleware yang aktif. Jika tampilan bagus tetapi lambat, ukur waktu muat, ukuran aset, dan query sebelum meminta optimasi besar. Jika perubahan database gagal, baca error dan keadaan migration terlebih dahulu. Jangan meminta AI menjalankan reset pada database berisi data kerja sebagai jalan pintas.

Ketika percakapan dengan AI terlalu panjang, buat ringkasan kerja di file proyek: tujuan, keputusan yang sudah diambil, perubahan yang selesai, test yang lulus, dan masalah terbuka. Sesi baru dapat membaca ringkasan ini. Jangan mengandalkan ingatan model tentang seluruh percakapan. Dokumentasi singkat mengurangi pengulangan dan menjaga keputusan produk tetap terlihat oleh manusia.

Contoh satu siklus kerja dari awal sampai selesai

Untuk melihat bagaimana seluruh prinsip tadi menyatu, bayangkan Anda menerima permintaan: “Tambahkan fitur untuk menyembunyikan produk sementara.” Jangan langsung mengubah tombol aktif menjadi draf di antarmuka. Mulailah dengan bertanya apa yang harus terjadi pada alamat produk yang sudah dibagikan. Dalam contoh ini keputusan bisnisnya adalah: produk draf tidak terlihat pada daftar publik, tautan detail yang lama tidak menampilkan produknya kepada tamu, tetapi pemilik tetap dapat menemukannya di dashboard. Sekarang ada perilaku yang dapat diuji.

Tambahkan keputusan itu ke spesifikasi. Periksa apakah kolom status sudah tersedia. Jika sudah, pekerjaan mungkin hanya menyentuh query, controller, tombol dashboard, dan test. Jika belum, dibutuhkan migration. Minta AI memetakan alur yang ada dan mengusulkan perubahan terkecil. Ketika usulan datang, lihat apakah ia menggunakan satu fungsi bersama yang sesuai untuk daftar dan detail publik. Menyaring daftar saja tetapi membiarkan detail terbuka akan menghasilkan kebocoran informasi.

Sebelum implementasi, tulis dua skenario uji: produk aktif bisa dilihat tamu, produk draf tidak bisa dilihat tamu bahkan bila slug diketahui. Tambahkan skenario ketiga: pemilik tetap bisa membuka drafnya melalui dashboard. Minta agent mengubah kode dan menjalankan pengujian tersebut. Setelah selesai, lihat diff. Bila agent mengubah halaman login atau memasang pustaka status baru, tanyakan alasannya karena ruang lingkup awal tidak memerlukannya.

Kemudian uji secara manual. Buat satu produk aktif dan salin tautan detailnya. Ubah menjadi draf dari akun pemilik. Buka tautan tersebut pada jendela yang tidak login. Kembali ke dashboard dan pastikan produk tetap terlihat serta dapat diedit. Perhatikan apakah cache halaman publik masih menunjukkan produk lama. Jika ada cache, tetapkan kapan data diperbarui dan tambahkan pemeriksaan yang relevan. Perilaku ini tidak selalu terungkap dari test controller sederhana.

Terakhir, commit dengan keterangan yang merangkum hasil, bukan hanya “update”. Catat keputusan bisnis bahwa tautan draf tidak dapat dibuka publik. Saat rekan kerja menambahkan fitur promosi beberapa bulan kemudian, ia dapat menemukan alasan mengapa produk draf dikecualikan. Inilah bentuk kecil dari rekayasa: keputusan, perubahan, bukti, dan catatan yang tersambung.

Cara mengevaluasi jawaban AI secara kritis

Jawaban AI terdengar yakin sering kali karena bentuk kalimatnya rapi, bukan karena kondisinya telah diverifikasi. Ketika agent berkata “selesai”, minta tiga jenis bukti: apa yang berubah, perintah apa yang benar-benar dijalankan, dan skenario pengguna apa yang diuji. Jika perintah gagal, kegagalan harus terlihat. Jika test belum dijalankan karena database tidak tersedia, itu adalah keterbatasan yang perlu ditangani, bukan hasil lulus.

Bedakan klaim faktual dengan asumsi. “Proyek memakai Laravel 12” dapat dibuktikan dari berkas dependensi. “Pengguna ingin menghapus produk secara permanen” perlu keputusan pemilik produk. “Sistem aman” terlalu luas untuk dibuktikan dengan satu test. Minta agent mengubahnya menjadi kalimat spesifik, misalnya “permintaan update dari akun selain pemilik menghasilkan penolakan dan tidak mengubah baris produk dalam test X”. Kalimat kedua dapat diperiksa.

Lihat bentuk perbaikannya. Jika satu bug kecil diselesaikan dengan menonaktifkan middleware, mematikan validasi, atau mengganti banyak komponen tanpa alasan, biaya jangka panjangnya mungkin lebih besar daripada bug awal. Minta penjelasan alur request sebelum dan sesudah perubahan. Jalankan skenario yang tadinya berhasil agar regresi terlihat. Gunakan Git untuk melihat dengan jelas apakah kode lama dihapus dan apakah test baru benar-benar menguji perubahan tersebut.

Waspadai dokumentasi yang dibuat otomatis tetapi tidak cocok dengan aplikasi. README yang menulis “fitur unggah gambar tersedia” padahal tidak ada route untuk mengunggah dapat menyesatkan pemilik bisnis. Periksa setiap janji kepada pengguna terhadap perilaku yang benar-benar ada. Begitu pula komentar kode “secure” tidak berarti ada pemeriksaan otorisasi. Bukti selalu berada pada perilaku aplikasi dan cara pengujiannya.

Jika Anda tidak memahami istilah teknis yang dipakai AI, mintalah diagram alur singkat dalam bahasa sehari-hari. Sebagai contoh: “Ketika seseorang menekan Simpan, bagaimana aplikasi mengetahui akun pemilik, menolak produk toko lain, memeriksa harga, dan baru kemudian menyimpan?” Jawaban yang baik mengikuti urutan dan menunjukkan lokasi keputusan. Bila agent tidak bisa menjelaskannya secara konsisten, berhenti sebelum rilis dan minta review manusia yang memahami stack tersebut.

Menjaga proyek tetap sehat setelah versi pertama

Masalah proyek dengan AI sering muncul setelah keberhasilan awal. Setiap permintaan terdengar mudah, sehingga perubahan kecil menumpuk tanpa arah. Untuk menghindarinya, simpan daftar pekerjaan yang memisahkan masalah pengguna, usulan fitur, bug, dan pemeliharaan. Urutkan menurut dampak, bukan menurut kemudahan prompt. Jika tiga pelanggan kesulitan membaca harga di ponsel, perbaikan tampilan mungkin lebih penting daripada menambahkan panel AI baru.

Sediakan definisi selesai yang ringan: kebutuhan jelas, perubahan dibatasi, test relevan lulus, tampilan diperiksa, dokumentasi diperbarui bila perilaku berubah, dan orang yang bertanggung jawab menyetujui hasil. Definisi itu dapat berbeda untuk warna tombol dan perubahan hak akses. Jangan membuat semua pekerjaan harus melalui proses berat yang sama; gunakan pemeriksaan tambahan pada area dengan risiko lebih besar.

Lakukan pembaruan dependensi secara terencana. Framework, paket, dan layanan berubah. Sebelum upgrade, baca catatan rilis resmi, lihat perubahan yang berpotensi memengaruhi aplikasi, jalankan test, lalu uji jalur utama di pratinjau. Agent dapat membantu menelusuri perbedaan versi, tetapi jangan mengasumsikan dokumentasi terbaru berlaku untuk proyek lama. Kecocokan versi adalah bagian dari konteks prompt.

Catat keputusan desain yang tidak terlihat pada kode. Contohnya: “Harga disimpan dalam rupiah utuh karena tidak ada pecahan”; “produk draf tidak tampil melalui tautan publik”; atau “penghapusan belum tersedia agar pemilik tidak kehilangan riwayat”. Beberapa kalimat ini menghemat banyak debat ketika kode dimodifikasi lagi. Jika keputusan berubah, ubah spesifikasi dan pengujian dalam pekerjaan yang sama agar semuanya tetap sejalan.

Ukur hasil dari sudut pengguna. Apakah pemilik dapat memperbarui sepuluh produk tanpa bantuan? Apakah pelanggan menemukan produk yang dicari? Apakah jumlah error turun setelah perubahan? Metrik seperti jumlah baris kode yang ditulis AI atau jumlah prompt per hari tidak menjawab pertanyaan tersebut. Aplikasi bernilai ketika tugas pengguna menjadi lebih mudah dan tetap dapat diandalkan.

FAQ dan checklist akhir

Apakah harus bisa coding untuk memakai vibe engineering?

Anda dapat memulai dengan merumuskan kebutuhan dan mencoba prototipe. Namun, semakin besar dampak aplikasi terhadap pengguna, semakin penting kemampuan menilai keamanan, data, dan perilaku teknisnya. Jika belum dapat memeriksa bagian tersebut, bekerjalah dengan developer atau reviewer yang kompeten sebelum aplikasi dipakai banyak orang. Meminta AI berkata “kode ini aman” bukan pengganti penilaian independen.

Apakah satu prompt panjang lebih baik daripada beberapa prompt pendek?

Satu prompt panjang berguna untuk menyampaikan konteks awal. Implementasi biasanya lebih mudah dikendalikan dalam tahap kecil dengan hasil yang dapat diperiksa. Gunakan dokumen spesifikasi untuk konteks yang menetap, kemudian beri tugas terbatas: rencana, skema, daftar publik, otorisasi, pengujian, dan pratinjau. Perbaiki spesifikasi ketika keputusan berubah.

Apakah setiap perubahan harus mempunyai test otomatis?

Pilih test menurut risiko dan nilai pengulangannya. Perubahan tampilan kecil dapat diperiksa secara visual. Aturan kepemilikan produk dan penyaringan draf sebaiknya mempunyai test otomatis karena kesalahan mudah luput dan dapat muncul kembali setelah perubahan lain. Pemeriksaan manual tetap diperlukan untuk pengalaman pengguna dan kondisi yang sulit direpresentasikan dalam satu test.

Bisakah memakai ChatGPT, Codex, Claude, atau alat lain?

Bisa. Pola kerja bergantung pada kemampuan alat dan akses yang Anda berikan. Ada alat yang hanya mengusulkan potongan kode, ada yang dapat mengubah repo dan menjalankan test. Pastikan Anda memahami file, perintah, dan layanan apa yang dapat diaksesnya. Fitur, biaya, dan kebijakan alat dapat berubah; cek dokumentasi resmi saat memulai proyek.

Apa beda demo yang berjalan dengan aplikasi siap produksi?

Demo menunjukkan bahwa satu jalur dapat diperagakan. Aplikasi produksi harus menangani pengguna dan data yang nyata, kesalahan input, akses yang tidak sah, perubahan versi, pemulihan, dan pemantauan. Tingkat pembuktiannya mengikuti konsekuensi kesalahan. Katalog tanpa transaksi lebih sederhana daripada sistem pembayaran, tetapi hak akses dan kebenaran informasi produk tetap penting.

Bagaimana jika AI membuat test yang semuanya lulus?

Bandingkan test dengan kriteria penerimaan yang ditulis sebelum implementasi. Pastikan ada kasus negatif dan akun berbeda, bukan hanya alur berhasil. Jalankan test sendiri dan lakukan satu pemeriksaan manual yang mewakili penggunaan nyata. Lulusnya test berarti skenario yang ditulis lulus pada lingkungan tersebut; tidak menjamin seluruh aplikasi bebas masalah.

Kapan perlu berhenti menambah fitur?

Saat versi awal memenuhi dua tugas pengguna utama dan pemeriksaan risiko yang disepakati. Dalam contoh ini, pemilik bisa mengelola produknya dan pelanggan melihat produk aktif yang benar. Keranjang, pembayaran, foto, dan analitik dapat dibuat sebagai proyek lanjutan setelah kebutuhan serta biaya pemeliharaannya jelas.

Sebelum Anda menyebut sebuah tahap selesai, gunakan daftar periksa berikut:

• Masalah pengguna dan batas fitur tertulis dalam SPEC.md.
• Kriteria penerimaan mencakup keadaan normal dan kegagalan penting.
• Agent menjelaskan rencana sebelum mengubah file penting.
• Perubahan yang dilakukan sesuai ruang lingkup dan terlihat pada diff.
• Test relevan dijalankan dan hasilnya dicatat.
• Dua akun berbeda telah dipakai untuk memeriksa hak akses.
• Input tidak valid serta status draf diperiksa dari sisi server.
• Tidak ada kredensial atau data pelanggan asli di prompt dan repositori.
• Pratinjau diuji di ponsel dan browser sebelum rilis.
• Cara pemulihan, pemantauan, dan pekerjaan lanjutan dicatat.

Vibe engineering tidak memerlukan upacara rumit. Mulai dengan masalah yang jelas, beri AI pekerjaan yang terbatas, periksa bukti hasilnya, dan buat keputusan rilis sesuai risiko bagi pengguna. Kecepatan AI paling berguna ketika setiap langkah menghasilkan aplikasi yang lebih mudah dipahami dan dipelihara. Untuk UMKM yang hanya memerlukan kehadiran digital sederhana, Anda juga dapat mencoba panduan kartu nama digital Tumbas.in dan QR Code Tumbas.in sebelum membangun aplikasi khusus.

Sumber dan bacaan lanjutan

• Simon Willison, “Vibe engineering”, 7 Oktober 2025; pembaruan istilah 23 Februari 2026.
• Simon Willison, “Vibe coding and agentic engineering are getting closer than I’d like”, 6 Mei 2026.
• Martin Fowler, “Vibe Coding” dan “Agentic Programming”, 21 Mei 2026.
• Laravel 12, dokumentasi Testing, Validation, dan Authorization. Gunakan versi dokumentasi yang sesuai proyek.
• GitHub Docs, PostgreSQL service containers dan protected branches.
• setup-php, rujukan action untuk menyiapkan PHP di GitHub Actions.
• GitHub Docs, “Removing sensitive data from a repository”.
• OWASP, Top 10 untuk memahami kategori risiko keamanan aplikasi web.