Cara Menggunakan AI untuk Coding: Alur Kerja Praktis

Anda membuka tiket, menempelkan deskripsinya ke jendela chat, lalu mendapat 200 baris kode yang kelihatannya masuk akal. Kodenya bisa dikompilasi. Dua hari kemudian, reviewer bertanya kenapa kode itu mengabaikan wrapper retry di proyek Anda, dan tidak ada orang di tim yang bisa menjelaskannya. Itulah kegagalan umum saat orang belajar cara menggunakan AI untuk coding: tahap generate berjalan baik, sementara semua yang ada di sekitarnya tidak.

Berikut alur kerja yang saya berikan kepada engineer baru. Model diperlakukan sebagai junior yang cepat dan sangat percaya diri, tetapi belum pernah melihat repo Anda. Alur ini dibangun di sekitar waktu review, bukan waktu mengetik.

Apakah AI benar-benar membuat Anda lebih cepat ngoding?

Kadang iya, dan jawabannya bergantung pada jenis tugasnya. Survei Developer Stack Overflow 2025 menemukan bahwa 84% responden sudah menggunakan atau berencana menggunakan alat AI, tetapi hanya 33% yang percaya pada keluarannya sampai batas tertentu. Keluhan terbesar, yang disebut 66% responden, adalah kode yang "almost right, but not quite" atau hampir benar tetapi belum tepat. Sebanyak 45.2% lainnya mengatakan men-debug kode hasil AI memakan waktu lebih lama dari perkiraan.

Data yang terkontrol justru kurang menyenangkan. Dalam studi 2025 dari METR, 16 pengembang open-source berpengalaman mengerjakan 246 isu nyata di repo yang mereka kenal baik. Ketika AI diizinkan, mereka menyelesaikan pekerjaan sekitar 19% lebih lambat, padahal mereka yakin sudah sekitar 20% lebih cepat. METR sudah menerbitkan data yang lebih baru, jadi anggap angka ini sebagai potret alat awal 2025, bukan vonis.

Pelajarannya bukan bahwa AI itu lambat. Perasaan cepat adalah alat ukur yang buruk. Ukur dalam menit dari tiket sampai PR yang di-merge, bukan dari seberapa cepat draf pertama muncul.

Apa yang perlu Anda tulis sebelum memberi prompt?

Sebuah rencana, dengan kata-kata Anda sendiri, maksimal sepuluh baris. Jika dilewati, model akan mengisi celah dengan tebakannya sendiri, dan tebakan itu bersifat generik menurut definisinya.

Template saya sederhana:

1. Perubahan perilaku, dalam satu kalimat.

2. File yang Anda perkirakan akan disentuh, meski belum yakin.

3. Fungsi atau pola yang sudah ada dan harus dipakai ulang oleh kode baru.

4. Satu hal yang tidak boleh dilakukan, misalnya tanpa dependensi baru atau tanpa perubahan skema.

5. Cara memastikan hasilnya benar: tes, curl, atau tangkapan layar.

Poin 3 paling sering dilewati, dan dari situlah sebagian besar kode yang "hampir benar" berasal. Model tidak tahu bahwa helper withRetry Anda ada, kecuali Anda menyebutkannya atau model bisa membaca kodenya.

Lewati prompt "bangunkan saya seluruh aplikasi". Pemula maupun senior akan mendapat hasil yang sama darinya: diff besar yang tidak dipahami siapa pun, dan proyek yang setengah jadi.

Seperti apa prompt yang baik dalam praktik?

Ambil pekerjaan rutin yang nyata: pengirim webhook menjatuhkan event saat penerima timeout. Prompt yang lemah berbunyi "perbaiki reliabilitas webhook". Prompt yang bisa dipakai terbaca seperti tiket:

Tambahkan retry dengan exponential backoff ke sendWebhook() di src/webhooks/sender.ts.
Gunakan ulang withRetry() dari lib/http.ts. Maksimal 4 percobaan, jitter aktif.
Jangan ubah signature publik atau menambah dependensi.
Tambahkan kasus vitest untuk penerima yang gagal dua kali, lalu berhasil.

Prompt itu menyebut file, helper yang harus dipakai, batasan, dan cara pengecekan. Hasilnya adalah diff sekitar 30 baris yang bisa Anda baca dalam sekali duduk. Jika diff-nya kembali dengan 150 baris, model sudah melebar, dan lebih baik Anda tolak daripada mengeditnya.

Dua trik kecil membantu di sini. Minta rencana dulu dan baca sebelum ada file yang berubah: rencana yang salah memakan tiga puluh detik, diff yang salah memakan sepuluh menit. Dan saat jawabannya meleset, sebutkan batasan yang dilanggar, bukan berdebat panjang. "Anda menambah dependensi baru, padahal aturannya tidak boleh ada" jauh lebih efektif daripada satu paragraf penjelasan.

Konteks juga perlu disengaja. Sebagian besar keluaran buruk berasal dari model yang tidak pernah melihat file yang relevan. Ada tiga kebiasaan yang membantu. Pertama, lampirkan dua atau tiga file yang mendefinisikan pola, bukan seluruh direktori. Kedua, tempelkan tes atau error yang gagal secara utuh, jangan dideskripsikan. Ketiga, simpan file aturan singkat di repo, berisi penamaan, penanganan error, dan library yang dilarang, yang dibaca alat setiap kali dijalankan. Sebagian besar alat agen sudah mendukung ini.

# AI-RULES.md
- Error: kembalikan Result, jangan throw di services/
- Panggilan HTTP lewat lib/http.ts (sudah ada retry dan tracing)
- Tanpa dependensi baru tanpa catatan di deskripsi PR
- Tes: vitest, diletakkan berdampingan sebagai *.test.ts

Empat baris seperti ini menghilangkan sebagian besar komentar review. Manusia pun terbantu olehnya.

Di repo yang belum Anda kenal, ajukan pertanyaan sebelum meminta perubahan. "Di mana masa berlaku sesi ditegakkan, dan apa yang memanggilnya?" adalah prompt pertama yang lebih baik daripada "tambahkan refresh token". Anda membaca jawabannya, membuka dua file yang disebutkan, lalu baru memutuskan apa yang perlu diubah. Ini loop yang sama seperti grep, blame, lalu bertanya ke rekan, hanya saja lebih cepat.

Jenis alat AI coding mana yang cocok untuk pekerjaan apa?

Ada tiga bentuk, dan mencampuradukkannya adalah kesalahan kedua yang paling sering terjadi.

Komplesi inline memprediksi baris berikutnya saat Anda mengetik. Ini bagus untuk boilerplate dan tes ketika polanya sudah terlihat di layar. Chat di dalam editor menjawab pertanyaan tentang kode yang dipilih dan mengusulkan perubahan yang bisa Anda terima per potongan. Agen menerima sebuah tugas, membaca file, menjalankan perintah, lalu kembali dengan sebuah branch.

Pilih berdasarkan seberapa murah Anda bisa memverifikasinya. Komplesi yang bisa dibaca dalam dua detik berisiko rendah. Agen yang menyentuh 14 file memberi imbalan tinggi, tetapi biaya review-nya juga tinggi.

Cursor adalah pilihan yang berpusat di editor: fork VS Code dengan komplesi Tab yang kuat dan sesi agen paralel. Layak dipertimbangkan jika Anda hampir seharian di editor. Lewati jika tim Anda sudah terpaku pada JetBrains dan tidak akan pindah.

GitHub Copilot adalah pilihan dengan gesekan rendah untuk tim yang sudah memakai GitHub, karena PR, issue, dan review ada di satu tempat. Perhatikan tagihannya: sejak Juni 2026 ia beralih ke kredit AI berbasis pemakaian, jadi penggunaan agen yang berat lebih mahal daripada yang terlihat dari harga kursinya.

Claude Code berbasis terminal dan agentik: Anda mendelegasikan refactor atau perburuan bug, lalu meninjau hasilnya. Ia tidak punya autocomplete inline dan hanya menjalankan model Claude. Itu pertukaran yang wajar jika Anda menginginkan delegasi per tugas.

Aider adalah pilihan yang bisa di-script dan berbasis git. Ia melakukan commit otomatis untuk setiap perubahan dengan pesan, sehingga rollback cukup dengan git revert. Anda hanya membayar token model, cocok untuk orang yang ingin mengontrol biaya.

Bagaimana cara me-review kode hasil AI?

Lebih lambat daripada meninjau kode rekan. Rekan punya rekam jejak dengan codebase Anda. Model tidak punya.

Checklist saya, berurutan:

• Jalankan dulu sebelum dibaca. Tes yang Anda tulis dan lulus lebih berharga daripada penjelasan yang terdengar yakin.

• Baca impor. Paket yang mengada-ada dan helper yang tidak dikenal biasanya terlihat di sana lebih dulu.

• Cari yang hilang. Jalur error, penanganan null, dan pembersihan sumber daya. Model menulis jalur bahagia dengan baik.

• Periksa ukuran diff. Jika Anda meminta perbaikan 10 baris dan mendapat 120 baris, ada sesuatu yang ditulis ulang tanpa diminta.

• Hapus apa yang tidak bisa Anda jelaskan. Jika Anda tidak bisa mempertahankan sebuah baris saat review, baris itu tidak di-merge.

Buat commit kecil dan pesannya jujur. "Tambah retry ke webhook sender (dibantu AI, tes ditambahkan)" sudah cukup. Menyembunyikan keterlibatan AI tidak membantu siapa pun dan membuat debugging di kemudian hari lebih sulit.

Apa yang sebaiknya tidak pernah Anda serahkan ke AI?

Apa pun yang salahnya diam-diam tetapi mahal. Logika autentikasi, alur pembayaran, migrasi data, dan pengecekan izin adalah tempat "hampir benar" lolos tes lalu gagal di produksi.

Anda tetap bisa memakai AI di area ini, tetapi dengan mode yang berbeda: minta ia meninjau kode Anda dan mendaftar risikonya, bukan menulis kodenya. Membaca daftar lima kemungkinan masalah memakan tiga menit. Membaca migrasi yang dihasilkan memakan separuh sore, yang akan Anda habiskan untuk meragukannya.

Jika Anda sedang belajar, ada satu pengecualian lagi. Tulis versi pertama sendiri, lalu minta model mengkritiknya. Junior yang selalu menerima versi hasil generate belajar memberi prompt, bukan membuat program, dan kesenjangan itu biasanya muncul saat insiden pertama mereka.

Bagaimana ini berubah untuk sebuah tim?

Perbedaan antara individu dan tim adalah beban review. Satu pengembang yang memakai agen bisa membuka lebih banyak PR per hari daripada yang sanggup dibaca reviewer. Sepakati tiga hal sejak awal:

1. Batas ukuran. PR di atas beberapa ratus baris yang berubah dipecah, siapa pun atau apa pun yang menulisnya.

2. Norma pengungkapan. Katakan kapan sebuah perubahan dibantu AI, supaya reviewer bisa menyesuaikan perhatian mereka.

3. Satu file aturan bersama. Satu sumber kebenaran untuk konvensi lebih baik daripada lima prompt pribadi.

Untuk onboarding, pemakaian terbaik yang pernah saya lihat adalah membaca yang digerakkan oleh pertanyaan. Karyawan baru bertanya ke asisten di mana sesuatu berada, lalu memverifikasinya di kode. Ini memangkas minggu pertama yang biasanya habis untuk "ini siapa yang pegang?", tanpa memberi mereka kode yang tidak bisa mereka pelihara.

Rencana satu minggu yang bisa langsung ditiru, dan mulai dari membaca

Hari 1: pakai komplesi inline saja, untuk tes dan boilerplate. Hari 2: ajukan tiga pertanyaan tentang codebase per hari di chat dan verifikasi setiap jawabannya. Hari 3: biarkan chat mengusulkan satu perubahan kecil per tugas dan baca setiap potongannya. Hari 4: coba agen pada pekerjaan rutin berisiko rendah, misalnya mengganti nama kunci konfigurasi di beberapa file, di sebuah branch. Hari 5: tulis file aturan Anda dari hal-hal yang mengganggu saat review.

Pantau satu angka sepanjang minggu: menit dari mulai mengerjakan tiket sampai PR di-merge, termasuk perbaikan dari review. Jika angka itu tidak turun, Anda sudah tahu di bagian mana alat ini tidak cocok dengan pekerjaan Anda, dan itu juga sebuah hasil.

Keuntungan nyata tercepat yang pernah saya lihat bukan berasal dari generate, melainkan dari pemahaman: memahami modul asing dalam sepuluh menit, bukan satu jam. Menulis kode tidak pernah menjadi bagian paling lambat dari pekerjaan. Yang lambat adalah membaca, memutuskan, dan memverifikasi. Arahkan alatnya ke sana, simpan penilaian Anda sendiri untuk tombol merge, dan sisanya akan mengikuti.