Aturan Proses Universal untuk AI Coding Agent
Tiga file aturan proses yang saya paksa agent ikuti: vertical slice, empat tingkat testing dengan database nyata, debugging sistematis.
Ringkasan
Gue pernah lihat AI ngoding semua layer sekaligus eh hasilnya nggak ada yang jalan. Terus gue bikin aturan tegas biar kerja per irisan fitur vertikal yang bisa dites langsung. Ditambah testing berlapis dan debugging urut jadi agent nggak asal ngasal lagi.
Saya pernah duduk diam menatap layar, nonton AI coding agent dengan antusiasnya men-generate SELURUH file repository dalam satu kali jalan. Semua schema database, semua service, semua halaman frontend dibuat sekaligus. Tapi nggak ada satu endpoint pun yang benar-benar berjalan. Ini jebakan horizontal klasik: semuanya setengah jadi, nggak ada yang bisa dijalanin, nggak ada yang bisa diverifikasi.
Tebakan awal saya salah. Saya kira prompt-nya kurang detail. Saya tambahin instruksi panjang lebar, tapi agent itu tetap aja membangun layer demi layer secara berurutan, bukan berdasarkan fitur yang utuh.
Baru kemudian saya sadar: agent ini cuma mengikuti metode kerja yang tertulis sebagai aturan. Kalau metodenya nggak ditulis sebagai aturan yang tegas, dia bakal pilih jalan termudah, bukan jalan terbaik. Makanya saya bikin tiga file aturan proses yang benar-benar bisa ditegakkan: vertical-slice, testing, debugging.
Satu Irisan Vertikal, Bukan Semua Layer Sekaligus
Aturan pertama yang saya tanamkan adalah vertical slice. Satu irisan fitur harus berjalan dari database sampai ke frontend, beres, bisa dijalanin, dan bisa diverifikasi sebelum pindah ke irisan berikutnya. Jangan bikin semua schema dulu, baru semua service, baru semua halaman.
Kalau irisannya kebesaran, pecah aja. Patokan saya sederhana: kalau pengerjaannya lebih dari satu hari kerja atau menyentuh lebih dari lima file inti, itu kebesaran. Mock data boleh dipakai, tapi cuma sementara. Refactoring di tengah jalan jadi task tersendiri, bukan bagian dari slice yang sedang dikerjakan.
Prinsip ini sejalan dengan arsitektur vertical slice dari Jimmy Bogard: alih-alih menggabungkan kode secara horizontal antar layer, kita gabungkan secara vertikal dalam satu irisan fitur, minimize coupling between slices, maximize coupling in a slice [1].
Empat Tingkatan Testing yang Nggak Bisa Ditawar
Agent sering kali malas nulis test, atau malah nulis test yang salah. Saya menetapkan empat tingkatan testing yang wajib dipenuhi.
Pertama, unit test harus memmock repository lewat interface, bukan implementasi konkretnya. Kedua, integration test wajib jalan di container database yang nyata, bukan substitusi in-memory; build tag memisahkan keduanya, seed data disiapkan per test, dan tabel dibersihkan setelahnya. Ketiga, E2E pakai Playwright cuma mencakup lima sampai sepuluh alur kritis, dan wajib pakai atribut data-testid. Keempat, post-deploy smoke check harus memanggil endpoint /health ditambah satu endpoint list dengan parameter ?limit=1.
Logikanya jelas. Test pyramid mengajarkan kita untuk nulis banyak unit test yang kecil dan cepat, serta mengurangi test yang coarse-grained [2]. Playwright sendiri menekankan bahwa automated test harus memverifikasi aplikasi bekerja untuk pengguna akhir, bukan bergantung pada detail implementasi [3]. Untuk database, kita butuh instance ringan yang bisa dibuang kapan aja kayak yang ditawarkan Testcontainers, bukan mock database yang menipu [4].
Debugging Sistematis dan Change yang Mandiri
Kalau agent melakukan debugging, urutannya nggak boleh acak. Saya mewajibkan urutan ini: reproduksi, tangkap error, cari root cause, perbaiki seminimal mungkin, verifikasi, lalu tambahin test agar nggak terulang. Ditambah checklist isolasi layer: database, repository, service, handler, contract, sampai frontend.
Setiap perubahan harus jadi unit commit yang mandiri dan kecil. Praktik engineering Google menegaskan ukuran change list yang tepat adalah satu perubahan yang self-contained, lengkap dengan kode test yang terkait [5].
Ini bukan cuma soal kerapian. Ini soal kepercayaan. Kita baru punya self-testing code ketika kita bisa ngejalanin serangkaian automated test dan yakin bahwa kalau test lolos, kode tersebut bebas dari cacat yang substansial [6].
Metode-metode klasik ini sebenarnya udah ada jauh sebelum era LLM agent. Jimmy Bogard nulis tentang vertical slice di tahun 2018, dan test pyramid juga udah lama dibahas. Yang baru di sini adalah menuliskannya sebagai aturan yang bisa dibaca mesin dan ditegakkan. Agent-nya nggak jadi lebih pintar; instruksinya jadi lebih susah diabaikan.