Cara menggunakan Claude Code: memisahkan perencanaan dan eksekusi

 (boristane.com)
86 poin oleh GN⁺ 2026-02-23 | 4 komentar | Bagikan ke WhatsApp
  • Cara menggunakan alat coding AI direstrukturisasi secara mendasar dengan menghadirkan workflow yang mewajibkan tahap peninjauan rencana secara eksplisit sebelum menulis kode
  • Prinsip utamanya adalah "jangan biarkan Claude menulis kode sebelum rencana disetujui", sehingga tercapai kontrol yang terstruktur dan penggunaan token yang efisien
  • Seluruh proses berjalan dalam struktur siklik Research → Plan → Annotation → Todo List → Implementation → Feedback
  • Pada setiap tahap, kolaborasi berpusat pada dokumen markdown (research.md, plan.md), sambil mengulang komentar dan revisi untuk meningkatkan kualitas hasil
  • Pendekatan ini berfokus pada pemisahan sekaligus penggabungan daya eksekusi AI dan penilaian manusia agar memperoleh hasil yang stabil dan konsisten bahkan pada sistem yang kompleks

Gambaran umum seluruh workflow

  • Selama sekitar 9 bulan menggunakan Claude Code sebagai alat pengembangan utama, dibangun prosedur sistematis yang memisahkan perencanaan dan eksekusi, alih-alih pola umum “masukkan prompt → hasilkan kode → ulangi revisi”
  • Sebelum Claude menulis kode, eksekusi hanya boleh dilakukan berdasarkan dokumen rencana (plan.md) yang telah ditinjau dan disetujui oleh penulis
  • Pendekatan ini mengurangi trial and error yang tidak perlu, mempertahankan kendali atas keputusan arsitektur, dan memaksimalkan kualitas dibanding penggunaan token

Phase 1: Research

  • Semua pekerjaan dimulai dari analisis codebase yang mendalam
    • Claude diarahkan untuk membaca dan menganalisis folder atau fitur tertentu secara mendalam (detailed, intricacies)
    • Hasilnya wajib didokumentasikan dalam file research.md
  • Dokumen ini berfungsi sebagai review surface untuk memverifikasi tingkat pemahaman Claude, sehingga jika ada salah paham dapat diperbaiki pada tahap ini
  • Karena riset yang keliru akan berujung pada rencana dan implementasi yang salah, tahap ini mencegah faktor kegagalan yang paling mahal sejak awal
  • Contohnya, mencegah masalah seperti mengabaikan lapisan caching, tidak mengikuti aturan ORM, atau membuat logika yang duplikatif

Phase 2: Planning

  • Setelah riset ditinjau, Claude diminta menulis rencana implementasi yang rinci (plan.md)
    • Mencakup snippet kode aktual, path file yang akan diubah, dan trade-off
    • Alih-alih mode plan bawaan, digunakan file markdown yang bisa dikelola langsung
  • Jika turut diberikan reference implementation dari open source, kualitas rencana Claude meningkat secara signifikan
  • Yang lebih penting daripada dokumen rencana itu sendiri adalah siklus Annotation setelahnya

Siklus Annotation

  • Penulis membuka plan.md lalu menambahkan komentar inline secara langsung
    • Memperbaiki asumsi yang salah, menolak pendekatan tertentu, menambahkan pengetahuan domain, dan sebagainya
    • Contoh: “ini harus PATCH”, “caching tidak perlu”, “field visibility dipindahkan ke level list”
  • Setelah itu, Claude diarahkan untuk “memperbarui dokumen dengan mencerminkan komentar tersebut, tetapi jangan implementasikan dulu”
  • Siklus komentar-pembaruan ini diulang 1–6 kali, dengan perintah “don’t implement yet” untuk mencegah eksekusi prematur
  • Dokumen markdown berfungsi sebagai state bersama yang dapat dibagikan, lebih jelas dan lebih terstruktur dibanding instruksi percakapan
  • Melalui pengulangan, rencana yang semula umum berkembang menjadi spesifikasi yang sepenuhnya sesuai dengan sistem nyata

Membuat Todo List

  • Sebelum implementasi, Claude diminta menambahkan todo list tugas yang terperinci
    • Mencakup task detail untuk tiap tahap agar progres dapat dilacak
    • Karena Claude menandai item yang sudah selesai, status pekerjaan tetap mudah dipahami bahkan dalam sesi yang panjang

Phase 3: Implementation

  • Setelah semua keputusan dipastikan, eksekusi diarahkan dengan prompt yang distandardisasi
    • “jangan berhenti sampai semua task selesai”, “jangan tambahkan komentar yang tidak perlu”, “jangan gunakan tipe any/unknown”, “lakukan type-check terus-menerus”, dan sebagainya
  • Perintah ini adalah tahap mekanis untuk mengeksekusi rencana apa adanya, karena penilaian kreatif sudah diselesaikan sebelumnya
  • Jika langsung mengimplementasikan tanpa rencana, kode akan dibangun di atas asumsi yang salah, sehingga aturan “don’t implement yet” menjadi pengaman inti

Feedback During Implementation

  • Saat eksekusi berlangsung, penulis beralih menjadi pengawas
    • Feedback disampaikan singkat dan jelas: “fungsi ini belum ada”, “pindahkan ke aplikasi admin”, dan sebagainya
    • Untuk perubahan frontend, digunakan instruksi singkat seperti “wider”, “2px gap”, atau screenshot
  • Referensi ke kode yang sudah ada sering digunakan untuk menjaga konsistensi UI/UX
  • Jika pekerjaan bergerak ke arah yang salah, pendekatan yang lebih efektif adalah git revert lalu coba lagi dengan ruang lingkup yang dipersempit, dibanding perbaikan bertahap

Staying in the Driver’s Seat

  • Claude tidak diberi otonomi penuh, keputusan akhir selalu diambil manusia
  • Hanya sebagian usulan Claude yang dipilih; sisanya bisa diubah, dihapus, atau pilihan teknologinya didefinisikan ulang
    • Contoh: “yang pertama pakai Promise.all”, “yang keempat dan kelima abaikan”
    • “hapus fitur download”, “jangan ubah function signature”, “gunakan method dari library tertentu”, dan sebagainya
  • Claude menangani eksekusi mekanis, sementara manusia bertanggung jawab atas penilaian dan penentuan prioritas

Single Long Sessions

  • Dari riset sampai implementasi, semuanya dijalankan berkesinambungan dalam satu sesi panjang
    • Selama sesi, Claude terus mengakumulasi konteks dan mempertahankan konteks yang memadai lewat auto-compaction
    • plan.md dipertahankan dalam bentuk utuh sepanjang sesi dan bisa dirujuk kapan saja

Ringkasan inti

  • “Baca secara mendalam, tulis rencana, rapikan dengan komentar, lalu eksekusikan sekaligus.”
  • Bahkan tanpa prompt yang rumit atau instruksi sistem, kualitas tinggi dapat dicapai lewat pipeline disiplin yang memisahkan Thinking dan Typing
  • Research mencegah perubahan yang dilakukan tanpa pemahaman, Plan mencegah perubahan yang keliru, dan Annotation menyuntikkan penilaian manusia
  • Eksekusi akhir dilakukan sebagai prosedur otomatis setelah semua keputusan dipastikan, membentuk struktur kolaborasi yang efisien

Bacaan terkait

4 komentar

 
naka98 2026-02-25

Saya juga terus mengalami masalah serupa. Kalau berkolaborasi dengan AI hanya berbasis chat, pemecahan unit kerja (WBS), progres, dan catatan keputusan jadi terasa kabur.
 
pcj9024 2026-02-23

Kalau file rencana langsung dimasukkan ke dalam repositori lalu perubahan yang muncul dari menjalankan rencana itu disimpan, ternyata konteksnya cukup terjaga.
 
geekbini 2026-02-23

Konten ini tidak terbatas hanya pada Claude; tampaknya ini juga bisa diterapkan secara umum pada layanan AI berbasis CLI lainnya.
 
GN⁺ 2026-02-23
Komentar Hacker News

  • Inti sebenarnya bukan “apakah membuat rencana atau tidak”, melainkan memaksa asumsi-asumsi muncul ke permukaan sebelum model mengeras menjadi kode
    LLM gagal bukan pada sintaks, melainkan pada premis tak terlihat seperti arsitektur atau batasan. Karena itu, rencana yang terdokumentasi menjadi permukaan tempat premis-premis itu bisa di-debug

    • Dalam hal ini, struktur sub-agent sangat membantu. Jika satu menangani perencanaan, satu implementasi, dan satu lagi review, perannya jadi jelas. Bisa juga model blue team/red team. Pada akhirnya yang penting adalah membantu LLM bernalar dengan benar lewat instruksi yang lebih jelas
    • Jika seluruh alur use case dimasukkan ke dalam panduan, model jadi tidak melakukan hal-hal aneh
    • Tapi tindakan menyingkap asumsi ini sendiri juga bisa mengubah perilaku model. Mirip ketika menambahkan satu baris printf() lalu Heisenbug-nya malah hilang
    • Katanya hampir tidak ada error sintaks? Pengalaman saya berbeda. Saat mencoba menambahkan backend S3 ke proyek Rust kecil, Claude masuk ke loop halusinasi API dan menghabiskan $20 dalam 30 menit. Padahal masalahnya cuma sintaks sederhana
    • Jangan-jangan tulisan ini dibuat dengan ChatGPT?

  • Ada yang bilang Claude tidak akan membaca secara dangkal kalau kita memakai kata seperti “mendalam” atau “detail”, tapi jujur saya tidak bisa memahaminya secara intuitif

    • Itu karena mekanisme attention. LLM dilatih pada seluruh internet, dan tulisan yang memuat ungkapan seperti “perhatikan detail masalah” biasanya berisi jawaban tingkat ahli. Jadi ketika kata-kata seperti itu muncul, model memberi bobot lebih besar pada data tersebut. Alasan prompt seperti “bertindaklah seperti profesor MIT” bisa berhasil juga sama
    • Tapi penjelasan seperti ini terasa seperti takhayul. Tidak ada dasar yang terverifikasi secara statistik, dan rasanya seperti pemikiran magis setingkat mempersembahkan kurban pada dewa matahari. Kalau memang efektif, seharusnya bisa dibuktikan sebagai masalah optimisasi, tapi tidak ada yang membuka datanya
    • Sekarang ini memang zaman yang sangat aneh untuk pengembangan perangkat lunak. Tidak ada yang benar-benar tahu kenapa LLM bertindak seperti itu. Kita cuma berharap prompt bisa menggeser probabilitas ke arah yang tepat. Dulu bidang ini deterministik, sekarang kita menulis perintah tebal-tebal di file AGENTS.md seperti orang tua berbicara pada anak
    • Aneh juga melihat hal seperti ini masih dianggap serius. Hampir seperti astrologi untuk para insinyur
    • Kalau latent space model dibayangkan sebagai medan, itu lebih mudah dipahami. Prompt seperti menjatuhkan bola di titik tertentu, dan pilihan kata menentukan ke lembah mana bola itu akan menggelinding. Ungkapan seperti “secara mendalam” membantu bola itu tetap berada di wilayah yang diinginkan. Mungkin bukan penjelasan sempurna, tapi dengan cara pikir itu, praktiknya memang bekerja cukup baik

  • Saya memakai struktur yang terdiri dari tiga jenis dokumen dan dua skill
    Specs adalah dokumen desain statis proyek, Plans adalah rencana eksekusi yang dibuat LLM, dan file Working memory melacak status progres.
    Saya membuat rencana baru dengan planner skill milik Gemini Pro, lalu mengeksekusinya dengan implementer skill milik Codex.
    Dengan begini, konteks tetap ringan dan fokus sehingga efisien. Bahkan dengan paket $20 Codex/Gemini pun progresnya cukup cepat

    • Saya juga memakai pendekatan serupa. Saya membuat file spec berdasarkan paper lalu mengembangkan rencananya sambil berinteraksi dengan Claude. Saya mengelola requirement–test–definition seperti dokumen system engineering bergaya IEEE. Claude cukup patuh kalau diberi guardrail. Dibanding Codex, Claude lebih cocok dengan gaya saya
    • Pendekatan yang bagus. Tapi saya penasaran apakah monorepo memang pilihan yang lebih baik di era AI. Di perusahaan kami, aplikasi Next.js dipisah ke beberapa repo, dan kami sedang mempertimbangkan apakah lebih baik digabung jadi satu

  • Ide meninggalkan komentar langsung di dokumen rencana terasa segar. Saya penasaran apakah ada cara untuk menyimpan komentar-komentar itu secara terpisah atau mengelolanya agar bisa ditinjau lagi nanti

  • Ada beberapa hal yang saya kurang suka dari pendekatan ini
    Pertama, pendekatan big bang yang menghasilkan semua kode sekaligus akan membuat gumpalan kode besar yang sulit dipahami. Menurut saya lebih baik merencanakan dan mengeksekusinya bertahap.
    Kedua, meski memberi feedback, pendekatan ini tidak memperbarui knowledge base. Penyebab error seharusnya dicatat agar tidak terulang lagi nanti.
    Terakhir, tidak ada penyebutan soal testing. Setidaknya sebagian test-driven development (TDD) perlu dimasukkan. Menarik melihat bagaimana pengembangan berbantuan AI akan berbaur dengan metodologi seperti ini

    • Saya juga punya pengalaman serupa. Saya membagi PLAN.md per tahap, lalu menulis prompt dengan hati-hati agar hanya tahap itu yang dieksekusi. Testing juga saya masukkan sebagai bagian dari rencana, meski saat ini biasanya saya tambahkan di tahap akhir

  • Workflow ini sebenarnya adalah cara standar Claude Code yang direkomendasikan Anthropic. Tapi kekurangannya, kalau rencananya tidak sempurna, kita harus mengulang dari awal.
    Karena itu saya membagi desain → rencana → eksekusi ke dalam beberapa batch. Jika unit rencana dijaga di bawah 1.500 baris, kompleksitasnya lebih mudah dikendalikan.
    Aplikasi saya yang 30 ribu LOC punya 100 ribu baris rencana. Mustahil membuatnya sekaligus

    • Saya juga mengalami hal yang sama. Karena itu saya membaginya ke unit rencana yang lebih kecil dan mengelola commit dengan branch per fitur. Berkat AI, kebiasaan development saya malah jadi lebih baik
    • Sebenarnya agak memalukan kalau workflow yang katanya “sangat berbeda” ternyata cuma memakai mode Plan bawaan
    • Saya juga merasa eksekusi bertahap adalah jawaban yang tepat. Menyelesaikan proyek raksasa sekaligus masih sebatas fantasi
    • Tidak masalah kalau rencananya tidak sempurna. Cukup rollback bagian yang diubah AI lalu iterasi lagi dari tahap sebelumnya. Kuncinya adalah mengurangi kompleksitas lewat perubahan unit kecil
    • 100 ribu baris rencana itu hampir sejuta kata. Hanya untuk membacanya saja butuh 66 jam. Secara realistis itu mustahil

  • Alih-alih plan.md, saya bekerja dengan berfokus pada scaffold yang bisa dijalankan dan loop verifikasi
    Saya membangun sistem pembayaran nyata bernama Kolibri Tickets bersama AI. Intinya bukan model bisa mengetik kode dengan cepat, tetapi merancang loop verifikasi

    • menjaga kerangka yang bisa dijalankan sejak awal
    • menambahkan hanya vertical slice tipis setiap kali
    • memaksa keluaran yang bisa diverifikasi seperti test, type, state machine, dan sebagainya
    • menjadikan refactoring sebagai kebiasaan sehari-hari
      Dengan begitu, kita bisa deploy lebih cepat secara nyata, bukan sekadar “ilusi kecepatan”. Dokumen Plan adalah salah satu cara menjaga shared state, dan harness yang dapat diverifikasi adalah cara lainnya
    • Saya juga menargetkan 100% test coverage di zaman ketika biaya kode makin murah. Saya sedang mengadopsi static typing di Python, test Playwright, sampai mutation testing. Sekarang agent bisa menjalankan loop selama 1 jam dan menghasilkan kode yang hampir tidak perlu diperbaiki

  • Saya memakai Claude Code untuk persiapan mengajar
    Saya menulis catatan kuliah dengan Quarto, lalu meminta Claude mengubahnya menjadi slide Slidev. Setelah itu saya memberi feedback dengan menambahkan komentar di slide seperti “yang ini dibagi jadi dua slide” atau “tambahkan gambar di sini”.
    Feedback berbasis komentar seperti ini sangat kuat. Ini sangat membantu untuk jarak token dan menjaga konteks

    • Quarto sendiri juga mendukung banyak format seperti PowerPoint, PDF, HTML, dan lain-lain, jadi saya penasaran kenapa memakai Slidev. Bukankah bisa saja meminta Claude membuat ulang dokumen Quarto?
    • Saya penasaran apakah feedback-nya ditinggalkan sebagai komentar inline. Misalnya seperti # ubah bagian ini menjadi X?
    • Apakah skill Claude itu sudah pernah di-open-source?

  • Sudah ada alat seperti Kiro dari Amazon, Antigravity dari Google, Spec Kit dari GitHub, dan OpenSpec yang menyediakan fungsi seperti ini

  • Kegagalan paling mahal dalam AI-assisted coding bukanlah error sintaks, melainkan implementasi yang sebagian bekerja dengan baik tetapi merusak keseluruhan sistem
    Karena itu saya menambahkan brief.md di awal untuk menjelaskan definisi masalah, metrik tujuan, kriteria penghentian fitur, dan sebagainya. Dengan begitu, biaya ketidaksesuaian antara tujuan bisnis dan implementasi teknis bisa dikurangi