AI-Assisted Development dengan Disiplin Engineering

AI coding agent kini bisa membaca repository, merencanakan perubahan, mengedit puluhan file, dan menjalankan test. Kalau dipakai sembarangan, hasilnya kode yang meyakinkan tapi tidak sepenuhnya dipahami siapa pun di tim. Kalau dipakai dengan disiplin, satu engineer bisa mengerjakan apa yang dulu butuh tim kecil — tanpa menurunkan standar.

Ini alur kerja yang saya pakai bersama Claude Code di project klien: modul ERP, sistem HR, e-commerce, dan aplikasi React Native. Tool-nya akan berubah. Disiplinnya yang membuat hasilnya bisa dipercaya.

Beri agent sebuah konstitusi

Setiap repository punya file instruksi project — CLAUDE.md — yang dibaca agent di awal setiap sesi. Isinya selalu menjawab pertanyaan yang sama:

• Produk apa ini, dan siapa penggunanya? Satu paragraf sudah cukup.
• Apa sumber kebenarannya? Misalnya, "aplikasi web menentukan perilaku; mobile mengikutinya, tapi tidak pernah meniru bug."
• Apa yang tidak boleh terjadi? Tidak ada secret di kode, tidak ada deploy, tidak ada perintah database yang merusak, tidak ada library baru tanpa bertanya.
• Bagaimana kita berkomunikasi? Saya bicara dengan agent dalam Bahasa Indonesia, tapi semua yang ada di dalam codebase — nama, komentar, pesan commit — dalam bahasa Inggris profesional.
• Apa definisi selesai? Type check, lint, build, dan test spesifik untuk perubahan itu.

Aturan yang singkat dan spesifik lebih baik daripada esai panjang. Kalau sebuah aturan penting, tulis sebagai instruksi yang bisa dijalankan agent, bukan nilai yang perlu "diingat."

Tulis spec sebelum kode

Untuk apa pun yang lebih besar dari perbaikan satu baris, agent lebih dulu menulis atau menerima spec: tujuan, scope, apa yang secara eksplisit di luar scope, perubahan model data, dan kriteria selesai. Saya me-review spec-nya, bukan draf kode pertama. Memperbaiki asumsi yang salah di satu paragraf butuh semenit; memperbaikinya di lima belas file butuh satu sore.

Spec juga bisa menjadi skill yang dipakai ulang. Alih-alih menjelaskan ulang "cara kita membuat halaman CRUD admin" di setiap sesi, satu file skill menyimpan konvensinya sekali — layout, validasi, empty state, hak akses — dan agent memuatnya saat task-nya cocok.

Jaga task tetap kecil dan terarah

Agent paling kuat di task yang batasnya jelas: "tambahkan flag sudah dibayar di invoice beserta ringkasan di halaman list," bukan "perbaiki modul invoice." Task kecil menjaga diff tetap bisa di-review, membuat kegagalan murah, dan memungkinkan saya memilih tingkat effort model yang tepat untuk setiap pekerjaan.

Verifikasi semuanya, jangan percaya begitu saja

"Sudah bisa di-compile" bukan berarti selesai. Setiap perubahan melewati gerbang sebelum saya terima:

1. Pengecekan statis — tsc --noEmit dan ESLint tanpa warning di file yang disentuh.
2. Build production — sebagian error hanya muncul di build yang dioptimasi.
3. Perilaku — unit test di tempat logika berada, dan uji end-to-end di environment terpisah: database dan port sendiri, agar test tidak pernah menyentuh server developer yang sedang jalan atau data asli.
4. Membaca diff — setiap baris, sama seperti saya me-review pull request rekan kerja.

Saat agent bilang sesuatu sudah berfungsi, saya ingin melihat perintah dan output-nya. Saat sebuah pengecekan gagal, perbaikannya bagian dari task, bukan pekerjaan susulan.

Jadikan memory eksplisit

Task panjang bisa melampaui satu sesi. Context window penuh, sesi dimulai ulang, dan kadang pekerjaan pindah ke akun lain atau ke rekan tim. Daripada berharap agent ingat, saya menjadikan memory sebagai file:

• docs/PROGRESS.md — fase dan checklist, diperbarui setiap selesai task.
• docs/DECISIONS.md — keputusan beserta alasan dan tanggalnya.
• docs/HANDOVER.md — apa yang baru dikerjakan, hash commit, apa yang sudah di-push, dan langkah berikutnya yang persis.

Aturannya sederhana: perbarui file ini setiap selesai task, dan berhenti untuk handover lengkap saat penggunaan token sesi mencapai sekitar 92–95%. Sesi baru cukup dimulai dengan "baca CLAUDE.md dan HANDOVER.md, lanjutkan langkah berikutnya" dan tidak ada yang hilang.

Hubungkan tool yang sudah dipakai tim

Lewat MCP (Model Context Protocol), agent bisa bekerja dengan tool yang sama dengan tim. Saya menghubungkan Notion agar agent membuat atau memperbarui task saat pekerjaan dimulai, dan menulis laporan terstruktur saat selesai: apa yang berubah, bagaimana diverifikasi, dan apa yang tersisa. Project manager melihat progres di tempat yang memang biasa dia lihat, tanpa perlu menanyakan status.

Biarkan manusia memegang keputusan yang tidak bisa dibatalkan

Beberapa aksi selalu tetap di tangan manusia:

• Commit dan push kode, terlebih deploy.
• Apa pun yang merusak: menghapus data, force-push, menghapus file di luar task.
• Keputusan produk: apa yang dibangun, apa yang dipotong, apa arti "cukup baik" untuk klien ini.

Agent mengusulkan; saya yang memutuskan. Karena itu juga kredensial tidak pernah masuk ke prompt atau file konfigurasi yang ditulis agent. Kalau sebuah task butuh secret, manusia yang menjalankan langkah itu.

Apa yang berubah untuk tim

Dengan alur kerja ini, peran saya bergeser dari mengetik menjadi merancang, me-review, dan memutuskan. Delivery jadi lebih cepat karena riset, scaffolding, refactor, dan pengecekan regresi berjalan paralel dengan cara berpikir saya — bukan menggantikannya.

AI tidak menggantikan penilaian engineering. AI melipatgandakan penilaian apa pun yang Anda bawa. Bawa spec, pengecekan, dan batasan yang jelas, maka kualitas yang dilipatgandakan. Tanpa itu semua, yang dilipatgandakan adalah kekacauan.