BAB 4: Mengeksekusi Plan

Spec sudah ada. Plan sudah diverifikasi, dimodifikasi kalau perlu, dan di-commit ke Git. Checkpoint yang bersih sudah terbentuk. Sekarang tinggal satu pertanyaan: bagaimana cara memerintahkan Claude untuk mengeksekusinya?

Jawabannya lebih nuanced dari sekadar “ketik implement dan tekan enter.” Ada dua keputusan yang perlu dibuat terlebih dahulu — pilihan model dan konfigurasi thinking depth — dan keduanya punya dampak nyata pada kualitas hasil implementasi.

Memilih Model yang Tepat

Claude Code tidak terikat pada satu model. Kamu bisa ganti model kapan saja menggunakan perintah /model, dan pergantian itu berlaku untuk semua prompt di sesi tersebut.

Sampai di titik ini — membuat spec, menjalankan plan mode — Sonnet sudah lebih dari cukup. Tapi saat hendak mengeksekusi plan yang kompleks, ada alasan kuat untuk mempertimbangkan Opus.

Perbedaan utama bukan di kecepatan atau biaya, tapi di kepatuhan terhadap instruksi. Model Opus dikenal jauh lebih disiplin mengikuti dokumen panduan yang panjang — seperti file plan yang sudah kita buat. Ia lebih jarang mengambil shortcut, lebih jarang “berimprovisasi” di luar yang tertulis, dan lebih konsisten dalam mengeksekusi langkah demi langkah sesuai urutan.

Panduan praktisnya sederhana: untuk fitur kecil dengan plan yang ringkas, Sonnet sudah memadai. Untuk fitur multi-step yang plannya panjang dengan banyak dependensi antar komponen, ganti ke Opus. Biayanya memang lebih tinggi, tapi biaya mengoreksi implementasi yang melenceng biasanya jauh lebih mahal.

Extended Thinking

Extended thinking adalah mode di mana model mengalokasikan waktu dan token ekstra untuk bernalar secara internal sebelum menghasilkan output. Bayangkan perbedaan antara menjawab pertanyaan tanpa berpikir versus memikirkannya dulu di atas kertas — hasilnya bisa sangat berbeda untuk masalah yang kompleks.

Di versi lama Claude Code, extended thinking dipicu dengan kata kunci khusus seperti ultrathink di akhir prompt. Cara ini sekarang sudah deprecated. Sejak awal 2026, extended thinking aktif secara default dengan budget maksimal — setiap prompt yang kamu kirim sudah mendapat kapasitas penalaran penuh tanpa perlu keyword tambahan.

Kontrol yang tersedia sekarang lebih granular melalui perintah /effort:

• low — Penalaran minimal, cocok untuk perubahan sederhana
• medium — Penalaran standar
• high — Penalaran mendalam
• max — Budget maksimal, untuk masalah yang paling kompleks

Untuk implementasi plan yang sudah disiapkan dengan baik, setting high atau max adalah pilihan yang tepat. Extended thinking memungkinkan model menemukan “lubang” dalam plan — bagian yang ambigu atau langkah yang saling bertentangan — dan menemukan solusi alternatif sebelum kode ditulis.

Cara Memulai Implementasi

Setelah model dipilih dan thinking depth dikonfigurasi, langkah selanjutnya adalah memastikan file plan terbuka di editor — ini membuatnya otomatis masuk sebagai konteks saat prompt dikirim.

Kemudian aktifkan auto-accept edits mode dengan menekan Shift+Tab satu kali dari mode normal. Dalam mode ini, Claude tidak menunggu konfirmasi untuk setiap perubahan file — ia langsung menulis dan melanjutkan. Ini penting untuk implementasi yang melibatkan banyak file: menunggu konfirmasi satu per satu akan memutus alur dan menyulitkan Claude mempertahankan konteks.

Setelah itu, promptnya cukup singkat:

can you implement this plan?

Sesederhana itu. Claude sudah punya semua yang dibutuhkan: plan terbuka sebagai konteks, CLAUDE.md dengan konvensi proyek, dan struktur kodebase yang sudah ia eksplorasi saat plan dibuat.

Biarkan proses berjalan. Untuk fitur seukuran authentication forms, implementasi biasanya selesai dalam dua sampai empat menit. Berikan izin yang diminta Claude selama masuk akal — membaca file, menjalankan linter, mengeksekusi test.

Iterasi Otomatis pada Error

Salah satu hal yang perlu diperhatikan selama implementasi: Claude tidak berhenti saat menemukan error. Jika linter mengeluh tentang format kode, ia memperbaikinya dan melanjutkan. Jika test gagal karena import path yang salah, ia merevisi dan menjalankan ulang. Perilaku ini adalah fitur, bukan bug — ia mencerminkan bagaimana developer nyata bekerja.

Yang perlu diwaspadai adalah iterasi yang berulang pada error yang sama. Kalau Claude sudah mencoba tiga kali memperbaiki satu masalah dan terus gagal, lebih baik intervensi manual: baca pesan errornya, pahami akar masalahnya, dan berikan petunjuk yang lebih spesifik.

Review Setelah Implementasi Selesai

Saat implementasi selesai, jangan langsung commit. Luangkan waktu — minimal setengah jam, bisa lebih — untuk membaca setiap file yang dibuat atau dimodifikasi.

Yang perlu dicek bukan hanya “apakah kodenya jalan?” tapi juga:

• Apakah kamu mengerti setiap bagian dari kode yang ditulis?
• Apakah ada pola atau keputusan yang tidak kamu kenali dalam konteks proyek ini?
• Apakah ada komponen yang dibuat ulang padahal sudah ada yang serupa?

Poin ketiga ini penting. Karena proyek terus berkembang, ada kemungkinan Claude membuat abstraksi baru yang sebenarnya duplikat dari yang sudah ada. Plan yang baik biasanya sudah menangani ini — tapi review tetap perlu.

Setelah yakin dengan hasil implementasi, commit semua perubahan ke branch feature yang sudah dibuat sejak spec dijalankan:

git add .
git commit -m "feat: implement authentication forms"

Atau gunakan command /commit kalau sudah dikonfigurasi — Claude akan menyusun commit message yang deskriptif berdasarkan perubahan yang ada.

Satu Siklus yang Lengkap

Kita baru saja menyelesaikan satu siklus penuh spec-driven workflow: spec → plan → implementasi. Tiga langkah yang terstruktur, masing-masing dengan checkpoint verifikasi sebelum melanjutkan ke langkah berikutnya.

Tapi ini baru fondasi. Workflow ini bisa diperluas — menambahkan design references sebelum planning, menambahkan automated code review setelah implementasi, atau memecah implementasi menjadi tugas-tugas atomik yang dikerjakan secara bertahap. Untuk fitur yang lebih besar dan tim yang lebih banyak, lapisan-lapisan tambahan ini bukan kemewahan tapi kebutuhan.

Salah satu lapisan yang paling berguna adalah tasks.md — cara memecah plan menjadi daftar tugas yang bisa dilacak satu per satu, sehingga implementasi besar bisa dikerjakan dalam beberapa sesi tanpa kehilangan konteks. Itulah yang akan dibahas selanjutnya.