Satu Fitur Sekali Jalan: Cara Kerja dengan AI

Setelah aplikasi pertama jalan, godaannya selalu sama: “Sekarang tambahkan kategori, grafik bulanan, ekspor ke Excel, login, dan mode gelap.” AI akan mencoba mengerjakan semuanya, dan sering kali hasilnya setengah jadi: sebagian fitur jalan, sebagian tidak, dan fitur lama ikut rusak tanpa kamu tahu sejak kapan.

Aturan satu fitur sekali jalan mencegah itu. Ini kebiasaan paling penting saat membangun dengan AI, dan juga inti dari cara kami belajar: secangkir kopi, satu fitur jadi. Di tutorial ini kamu akan melihat siklusnya dengan contoh nyata: menambahkan fitur “total bulan ini” ke aplikasi pencatat pengeluaran.

Kenapa permintaan besar gagal

• AI mengubah terlalu banyak sekaligus. Banyak file berubah, dan makin besar perubahannya, makin besar peluang ada yang salah.
• Kamu tidak bisa memeriksanya. Perubahan ratusan baris tidak akan benar-benar kamu baca. Delapan baris bisa.
• Bug saling bertumpuk. Kalau tiga fitur ditambahkan sekaligus lalu ada yang rusak, mana penyebabnya? Memperbaiki satu bisa merusak yang lain.
• Tidak ada titik aman untuk kembali. Tanpa versi terakhir yang pasti jalan, pilihanmu hanya terus menambal, dan di sinilah banyak proyek mulai menabrak masalah 70%.

Apa itu “satu fitur”

Satu fitur adalah perubahan yang bisa kamu uji dalam beberapa menit, dan bisa dijelaskan dengan satu kalimat:

“Setelah ini, pengguna bisa …”

• ✅ “Setelah ini, pengguna bisa melihat total pengeluaran bulan ini.”
• ✅ “Setelah ini, pengguna bisa memilih kategori untuk setiap catatan.”
• ❌ “Setelah ini, aplikasinya jadi aplikasi keuangan lengkap.”

Kalau kalimatnya butuh kata “dan” lebih dari sekali, itu kemungkinan besar lebih dari satu fitur.

Memecah permintaan besar

Ambil permintaan besar tadi dan pecah menjadi urutan fitur kecil. Urutkan dari yang paling berguna dan paling sedikit bergantung pada fitur lain:

Setiap baris punya kriteria selesai jika, sama seperti di spesifikasi aplikasi. Kriteria itulah yang kamu uji.

Siklusnya: minta, periksa, uji, simpan

1. Pastikan ada titik aman

Sebelum meminta perubahan, pastikan versi yang sekarang tersimpan dan jalan. Dengan Git, itu berarti semua perubahan sudah di-commit. git status harus menunjukkan tidak ada perubahan yang tertunda. (Belum memakai Git? Pelajari di Git dan GitHub untuk kerja tim. Sementara itu, minimal simpan salinan file-nya.)

2. Minta satu fitur, dengan batasan yang jelas

Tambahkan satu fitur: total pengeluaran bulan ini, tampil di bawah total hari ini.

Selesai jika:
- Hanya catatan bulan ini yang dihitung, catatan bulan lalu tidak.
- Total bulan ini ikut berubah saat catatan ditambah atau dihapus.

Jangan ubah bagian lain. Jelaskan singkat apa saja yang kamu ubah.

Kalimat “jangan ubah bagian lain” terdengar sepele, tapi sering menyelamatkan fitur yang sudah jalan dari ikut “dirapikan” oleh AI.

3. Baca perubahannya

Ini perubahan untuk fitur tersebut. Diff ini kami buat dan uji pada aplikasi contoh:

  .total { font-size: 2rem; font-weight: 800; margin: 0 0 20px; }
  .total { font-size: 2rem; font-weight: 800; margin: 0 0 4px; }
  .bulanan { color: #59636e; margin: 0 0 20px; }

<p class="total" id="total">Rp0</p>
<p class="bulanan">Bulan ini: <span id="total-bulan">Rp0</span></p>

    document.getElementById('total').textContent = rupiah.format(total);
    const bulanIni = hariIni().slice(0, 7); // "YYYY-MM"
    const totalBulan = semua
      .filter((c) => c.tanggal.startsWith(bulanIni))
      .reduce((jumlah, c) => jumlah + c.jumlah, 0);
    document.getElementById('total-bulan').textContent = rupiah.format(totalBulan);

Seperti inilah ukuran yang sehat untuk satu fitur: tiga tempat yang berubah, sekitar delapan baris. Kamu bisa membacanya dalam satu menit dan mengerti garis besarnya. Ambil tanggal bulan ini (misalnya "2026-05"), saring catatan yang tanggalnya diawali bulan itu, lalu jumlahkan. Tidak ada file lain yang tersentuh, dan tidak ada library baru. Panduan membaca perubahan seperti ini ada di memahami kode buatan AI.

4. Uji fitur baru, dan uji ulang fitur lama

Uji kriteria “selesai jika”, ditambah uji dari versi sebelumnya. Fitur baru yang merusak fitur lama bukan kemajuan. Pengujian ulang ini disebut regression testing. Ini hasil uji kami di Chrome:

Tip: simpan daftar uji ini di file UJI.md di proyekmu. Setiap fitur baru menambah beberapa baris, dan sebelum commit kamu tinggal menjalankan daftar itu dari atas.

5. Simpan

Kalau semua uji lulus, simpan sebagai titik aman baru:

git add .
git commit -m "Tambah total bulan ini"

Baru setelah itu, lanjut ke fitur berikutnya, dan ulangi siklusnya dari langkah 1.

Kalau perubahannya gagal

Ini bagian yang paling sering salah. Saat hasil AI tidak jalan, jangan menumpuk permintaan perbaikan di atas perubahan yang sudah berantakan. Kembali ke titik aman, lalu coba lagi dengan permintaan yang lebih kecil atau lebih jelas.

Dengan Git:

git restore .

Perintah ini membuang semua perubahan yang belum di-commit pada file yang sudah dilacak Git, dan mengembalikannya ke commit terakhir. File baru yang dibuat AI tidak ikut terhapus, jadi cek dengan git status dan hapus manual kalau perlu. Kalau perubahan yang bermasalah sudah terlanjur di-commit, pakai git revert <id-commit> untuk membatalkannya dengan commit baru, tanpa menghapus riwayat.

Setelah kembali, perbaiki permintaannya: apakah fiturnya terlalu besar? Apakah kriteria “selesai jika” kurang jelas? Apakah ada informasi yang belum kamu berikan ke AI?

Template permintaan fitur

Tambahkan satu fitur: [satu kalimat "pengguna bisa …"].

Konteks: [file atau bagian yang relevan, kalau tahu].

Selesai jika:
- [hal yang bisa diuji]
- [hal yang bisa diuji]

Jangan ubah bagian lain, jangan tambahkan library baru tanpa bertanya.
Setelah selesai, jelaskan file apa saja yang diubah dan cara saya mengujinya.

Pertanyaan yang sering diajukan

Bukankah lebih lambat kalau satu per satu?

Per permintaan, ya. Untuk keseluruhan proyek, tidak. Waktu yang dihemat dari tidak perlu membongkar perubahan besar yang gagal jauh lebih banyak daripada waktu tambahan untuk beberapa permintaan kecil. Kamu juga selalu punya versi yang jalan.

Bagaimana kalau satu fitur memang butuh banyak perubahan?

Pecah lagi menjadi langkah-langkah yang masing-masing bisa diuji. Fitur login, misalnya, bisa dipecah menjadi: halaman daftar, halaman masuk, keluar, lalu membatasi data per pengguna. Setiap langkah diuji dan di-commit sendiri.

Perlukah membuat branch untuk setiap fitur?

Untuk proyek pribadi yang kecil, commit di main sudah cukup. Begitu aplikasimu sudah online atau dikerjakan bersama orang lain, buat branch per fitur dan gabungkan lewat pull request, supaya versi online selalu yang sudah diuji. Caranya ada di Git dan GitHub untuk kerja tim.

Kesimpulan

Satu fitur sekali jalan berarti: titik aman dulu, minta satu perubahan dengan kriteria selesai yang jelas, baca perubahannya, uji fitur baru dan fitur lama, lalu simpan. Kalau gagal, kembali ke titik aman alih-alih menambal. Perubahan kecil bisa dipahami, diuji, dan dibatalkan. Perubahan besar sering tidak bisa ketiganya.

Langkah berikutnya di jalur Vibe Coding: fitur yang paling sering membuat orang panik, menambahkan database dan login.