Kebiasaan Menjalankan AI Coding Assistant Maraton

Beberapa project saya, terutama proses tuning untuk salah satu aplikasi internal saya, dikerjakan dengan bantuan AI coding assistant secara maraton. Bukan sekadar tanya-jawab singkat, tapi sesi kerja panjang, kadang nyaris berjalan 24/7, dengan banyak sub-tugas paralel: riset kecil, review kode, generate variasi eksperimen, sampai validasi hasil. Awalnya cara kerja ini terasa efisien, tapi begitu skalanya membesar saya sadar ada dua masalah yang kalau dibiarkan bisa bikin semuanya berantakan.

Masalahnya: paralel itu murah secara konsep, tapi mahal kalau tidak diatur

Ketika satu sesi kerja memunculkan banyak sub-tugas sekaligus, godaan pertama adalah menjalankan semuanya dengan model AI paling canggih yang tersedia. Rasanya aman, tapi biayanya cepat sekali membengkak, dan sebenarnya tidak semua sub-tugas butuh "otak" sebesar itu. Masalah kedua muncul dari sisi kode: dalam kerja maraton, saya sering sengaja menyederhanakan sebuah bagian dulu supaya progres tidak macet, dengan niat membereskannya nanti. Tanpa catatan yang jelas, "nanti" itu gampang terlupakan, atau lebih buruk lagi, disalahartikan sebagai solusi final oleh saya sendiri di sesi berikutnya, atau oleh AI assistant yang membaca kode tanpa konteks penuh.

Solusi pertama: model tiering untuk tugas pendukung

Kebiasaan yang paling terasa dampaknya adalah memisahkan level model berdasarkan bobot keputusan, bukan berdasarkan "semua harus terbaik". Untuk tugas-tugas pendukung yang dijalankan paralel dalam jumlah banyak, seperti riset kecil, ringkasan, atau generate variasi eksperimen, saya sengaja pakai model yang lebih hemat dan cepat. Model paling mumpuni saya simpan khusus untuk keputusan inti: root cause analysis, desain arsitektur, atau review akhir sebelum sesuatu masuk ke produksi.

Pendekatan ini menghemat biaya dan token secara signifikan, tapi yang lebih penting, kualitas keputusan penting tidak turun sama sekali karena "otak besar" tetap dipakai tepat di titik yang paling butuh penalaran dalam. Aturan sederhananya kira-kira begini:

Tugas paralel / riset kecil / variasi eksperimen -> model hemat & cepat
Keputusan inti / root cause / review final       -> model paling mumpuni

Solusi kedua: kata kunci komentar yang konsisten, bukan sekadar TODO

Kebiasaan kedua lahir dari rasa frustrasi membaca ulang kode saya sendiri beberapa minggu kemudian dan tidak yakin apakah sebuah bagian memang sengaja disederhanakan atau cuma belum sempat dirapikan. Solusinya: saya pakai satu kata kunci komentar khusus yang konsisten di seluruh project, selalu dibarengi kondisi spesifik kapan bagian itu sebaiknya direvisit. Bentuknya kurang lebih seperti ini:

// SIMPLIFIED-FOR-NOW: parsing masih pakai aturan statis.
// Revisit jika: volume data mitra baru masuk dan pola input berbeda
// dari yang sudah ditangani saat ini.

Bedanya dengan TODO biasa jelas: kata kunci ini menyatakan "ini keputusan sadar, bukan kelupaan", dan yang lebih penting, mencantumkan pemicu konkret kapan harus dibongkar lagi. Siapa pun yang membaca kode itu, termasuk saya sendiri, atau AI assistant yang sedang membantu di sesi lain, langsung tahu konteksnya tanpa perlu menebak-nebak riwayat percakapan lama.

Pelajaran yang saya bawa pulang

Kerja maraton dengan AI coding assistant itu paling produktif kalau ada aturan main yang konsisten dan terdokumentasi, bukan cuma soal menulis prompt yang bagus. Dua kebiasaan di atas sebenarnya menyelesaikan masalah yang sama dari dua sisi berbeda: model tiering menjaga efisiensi di level eksekusi, sementara kata kunci komentar menjaga integritas keputusan di level kode. Keduanya sama-sama soal satu hal, membuat sistem yang bisa "diingat" lintas sesi, karena AI assistant tidak punya memori bawaan tentang mengapa sebuah keputusan diambil, dan manusia pun sering lupa.

Kalau harus diringkas dalam satu kalimat: dokumentasikan alasan di balik jalan pintas yang kamu ambil, sedetail kamu mendokumentasikan solusi akhirnya. Jalan pintas itu tidak masalah, asal jejaknya tertinggal.