Plan Mode Claude Code: Membuat Rencana Implementasi Golang yang Solid
Kuasai Plan Mode di Claude Code untuk membuat rencana implementasi Golang yang solid sebelum menulis kode. Dari feature spec ke implementation plan yang detail dan terstruktur.
Plan Mode di Claude Code: Rencana Sebelum Baris Pertama
Ada temptation besar saat punya spec yang jelas: langsung minta AI generate kode. Kenapa tidak? Spec sudah ada, tinggal bilang “implementasikan” dan tunggu. Tapi menguasai plan mode claude code golang justru dimulai dari menahan dorongan itu — karena ada satu step yang sering di-skip yang secara dramatik meningkatkan kualitas output: membuat plan terlebih dahulu.
Plan Mode adalah fase di mana kita meminta Claude Code untuk menghasilkan rencana implementasi yang detail — file apa yang perlu dibuat, interface apa yang perlu didefinisikan, sequence implementasi yang optimal, dan potential issues — sebelum satu baris kode pun ditulis. Investasi kecil di depan ini yang membedakan implementasi yang terarah dari implementasi yang penuh rework.
10.1 Mengapa Plan Sebelum Code Menghasilkan Output yang Lebih Baik
Untuk memahami nilai Plan Mode, bandingkan dua pendekatan secara langsung. Tanpa plan, AI cenderung:
- Langsung menulis implementasi yang pertama terlintas di pikiran
- Membuat keputusan arsitektur yang mungkin tidak optimal
- Melewatkan dependency antar komponen yang perlu dibuat
- Generate kode yang kemudian perlu di-refactor karena tidak mengikuti pola proyek
Sebaliknya, dengan plan yang eksplisit kita mendapatkan keuntungan yang konkret:
- Kita bisa review dan koreksi arah sebelum investasi besar di kode
- AI tahu urutan yang benar: interface dulu, implementasi kemudian
- Potensi masalah teridentifikasi sebelum jadi masalah nyata
- Estimasi effort lebih akurat
Ini mirip dengan prinsip “measure twice, cut once” di carpentry — tapi untuk software. Sedikit waktu di fase perencanaan menyelamatkan berjam-jam rework di fase implementasi.
10.2 Prompt untuk Memulai Plan Mode
Kunci mengaktifkan Plan Mode adalah prompt yang memaksa Claude menghasilkan rencana terstruktur dan menahan diri dari menulis kode. Gunakan prompt lengkap berikut sebagai titik awal.
1Sebelum kita mulai implementasi, saya ingin membuat rencana yang solid dulu.
2
3Berdasarkan spec berikut, buat implementation plan yang mencakup:
4
51. FILE YANG PERLU DIBUAT (baru)
6 - Nama file dan path lengkap
7 - Package name
8 - Tipe: entity, interface, usecase, repository, handler, test
9 - Satu-dua kalimat tentang isinya
10
112. FILE YANG PERLU DIMODIFIKASI (existing)
12 - Path file
13 - Apa yang perlu ditambahkan atau diubah
14 - Apakah ada breaking change?
15
163. DATABASE CHANGES (jika ada)
17 - Migration script yang perlu dibuat
18 - Indeks baru yang perlu ditambahkan
19 - Constraint baru
20
214. INTERFACE BARU (jika ada)
22 - Nama interface dan method signatures
23 - Package tempat interface didefinisikan
24
255. IMPLEMENTATION SEQUENCE
26 - Urutan implementasi yang optimal (dengan dependency consideration)
27 - Mana yang perlu selesai dulu sebelum yang lain bisa dimulai
28
296. POTENTIAL ISSUES
30 - Hal yang mungkin rumit atau perlu perhatian khusus
31 - Dependencies ke kode existing yang perlu dicek
32 - Pertanyaan yang perlu dikonfirmasi sebelum implementasi
33
34Jangan tulis implementasi sekarang — hanya plan.
35Saya akan review plan-nya dulu, konfirmasi, baru kita lanjut implementasi.
36
37---
38Spec: @specs/order/cancel-order.md
39
40Kode referensi (untuk pola yang harus diikuti):
41- Handler: internal/delivery/http/handler/order_handler.go
42- Usecase: internal/usecase/order/create_order.go
43- Repository: internal/repository/postgres/order_repository.goPerhatikan dua instruksi penting di akhir prompt: larangan menulis implementasi dan penyertaan kode referensi. Keduanya adalah pembeda antara plan yang berguna dan plan yang mengabaikan pola codebase-mu.
10.3 Contoh Plan Mode Output: Cancel Order
Agar terlihat konkret seperti apa hasil yang baik, berikut contoh output Plan Mode yang dihasilkan Claude untuk fitur cancel order.
1📋 IMPLEMENTATION PLAN: Cancel Order
2Spec: specs/order/cancel-order.md v1.3
3Date: 2025-07-15
4
5═══════════════════════════════════════════════════════
6
71. FILE YANG PERLU DIBUAT (BARU)
8
9📄 internal/domain/order/errors.go (BARU)
10 Package: order
11 Type: domain errors
12 Isi: Tambah error variables dan custom error types
13
14 [PERTANYAAN]: Apakah file ini sudah ada? Jika ya, saya akan
15 tambahkan ke file existing, bukan buat baru.
16
17📄 internal/usecase/order/cancel_order.go (BARU)
18 Package: order
19 Type: usecase
20 Isi: CancelOrderUseCase struct + Execute method
21 Validasi: ownership, status PENDING, 15-menit window
22 Side effects: stock restore (via repo), Kafka event (via publisher)
23
24📄 internal/usecase/order/cancel_order_test.go (BARU)
25 Package: order_test
26 Type: unit test dengan testify/suite + gomock
27 Test cases (dari spec):
28 - TestCancelOrder_PendingOrder_Success (AC1-AC6)
29 - TestCancelOrder_OrderNotFound_Returns404 (AC8)
30 - TestCancelOrder_ConfirmedOrder_Returns409 (AC9)
31 - TestCancelOrder_ExpiredWindow_Returns409 (AC10)
32 - TestCancelOrder_ConcurrentCancel_OnlyOneSucceeds (EC1)
33 - TestCancelOrder_KafkaFailure_StillSucceeds (EC2)
34 - TestCancelOrder_PartialStockRestore_Rollback (EC4)
35
362. FILE YANG PERLU DIMODIFIKASI (EXISTING)
37
38📝 internal/domain/order/entity.go
39 Tambahkan: StatusCancelled constant (jika belum ada)
40 Tambahkan: Method CanBeCancelled() bool
41 Tambahkan: Method IsCancelWindowOpen() bool (cek 15 menit)
42 ⚠️ CEK DULU: apakah StatusCancelled sudah ada?
43
44📝 internal/domain/order/repository.go
45 Tambahkan ke interface OrderRepository:
46 - GetByIDAndUserID(ctx, orderID, userID uuid.UUID) (*Order, error)
47 - CancelWithStockRestore(ctx context.Context, orderID uuid.UUID) error
48 ⚠️ Breaking change untuk mock yang sudah ada!
49
50📝 internal/repository/postgres/order_repository.go
51 Implementasikan 2 method baru:
52 - GetByIDAndUserID: SELECT + user_id filter
53 - CancelWithStockRestore: BEGIN; SELECT FOR UPDATE; UPDATE orders;
54 UPDATE products (batch); COMMIT
55
56📝 internal/delivery/http/handler/order_handler.go
57 Tambahkan: field cancelOrderUC *cancelorder.CancelOrderUseCase
58 Tambahkan: method CancelOrder(c echo.Context) error
59 Update: NewOrderHandler constructor
60
61📝 internal/delivery/http/router/router.go
62 Tambahkan route: e.DELETE("/orders/:id", handler.CancelOrder,
63 middleware.AuthMiddleware(jwtKey))
64
653. DATABASE CHANGES
66
67📄 db/migrations/20250715_cancel_order.sql (BARU)
68 -- Tidak ada schema change untuk cancel order
69 -- Status CANCELLED sudah ada jika kita gunakan enum atau check constraint
70
71 ⚠️ CEK DULU: apakah kolom status di tabel orders sudah include CANCELLED?
72 Query untuk cek: SELECT column_default FROM information_schema.columns
73 WHERE table_name='orders' AND column_name='status';
74
75 Jika belum: ALTER TABLE orders DROP CONSTRAINT IF EXISTS orders_status_check;
76 ALTER TABLE orders ADD CONSTRAINT orders_status_check
77 CHECK (status IN ('PENDING','CONFIRMED','SHIPPED','DELIVERED','CANCELLED'));
78
794. INTERFACE BARU
80
81Interface di domain/order/repository.go (update existing):
82 GetByIDAndUserID(ctx context.Context, orderID, userID uuid.UUID) (*Order, error)
83 // Returns nil, nil jika tidak ditemukan atau bukan milik user
84
85Interface baru di usecase layer:
86 type OrderCancelledPublisher interface {
87 PublishOrderCancelled(ctx context.Context, orderID, userID uuid.UUID) error
88 }
89
905. IMPLEMENTATION SEQUENCE
91
92Step 1: Update domain/order/entity.go (StatusCancelled, methods)
93Step 2: Update domain/order/repository.go (tambah interface methods)
94Step 3: Update domain/order/errors.go atau buat baru (custom errors)
95Step 4: Update repository/postgres/order_repository.go (implementasi)
96Step 5: Buat usecase/order/cancel_order.go
97Step 6: Buat usecase/order/cancel_order_test.go
98Step 7: Update handler/order_handler.go
99Step 8: Update router/router.go
100Step 9: Update di tempat yang perlu inject dependency baru
101
1026. POTENTIAL ISSUES
103
104⚠️ Issue 1: Mock update
105 Setelah menambahkan methods ke OrderRepository interface,
106 semua mock file (generated atau manual) perlu di-update.
107 Jika menggunakan mockgen: jalankan ulang generate.
108
109⚠️ Issue 2: Circular dependency risk
110 OrderCancelledPublisher di usecase layer — pastikan tidak import
111 dari delivery layer.
112
113⚠️ Issue 3: Clock mocking untuk 15-menit window test
114 TestCancelOrder_ExpiredWindow_Returns409 perlu mock time.Now().
115 Pertimbangkan inject clock interface ke usecase.
116
117⚠️ Issue 4: SELECT FOR UPDATE behaviour di test
118 Test ConcurrentCancel perlu real DB atau test yang sangat careful
119 dengan mock — pertimbangkan integration test untuk EC1.
120
121═══════════════════════════════════════════════════════
122
123PERTANYAAN SEBELUM LANJUT:
1241. Apakah StatusCancelled sudah ada di entity.go?
1252. Apakah OrderRepository mock sudah ada? (mockgen atau manual?)
1263. Apakah kita inject clock interface untuk testability, atau pakai time.Now() langsung?
1274. Apakah EC1 (concurrent cancel) akan jadi unit test atau integration test?
128
129Ketik "lanjut" untuk mulai implementasi sesuai plan ini,
130atau berikan jawaban/koreksi untuk pertanyaan di atas.Perhatikan bahwa plan yang baik tidak hanya melisting file — ia menandai breaking change, mengangkat risiko konkret (mock update, clock mocking, SELECT FOR UPDATE), dan mengakhiri dengan pertanyaan klarifikasi. Justru bagian pertanyaan inilah yang paling berharga karena mencegah asumsi salah sebelum kode ditulis.
Satu langkah yang mudah terlewat: simpan plan ini ke berkas, jangan biarkan menguap di riwayat chat.
1Simpan plan di atas apa adanya ke docs/plans/cancel-order-2025-07-15.md.
2Tambahkan header: spec yang dirujuk, tanggal, dan status (DRAFT/APPROVED).
3Jangan ubah isi plannya.Alasannya bukan sekadar kerapian. Plan yang tersimpan bisa dirujuk balik dari prompt implementasi — di artikel 12 kita membuka setiap prompt dengan menunjuk spec dan plan ini, sehingga kode yang dihasilkan bisa ditelusuri ke rencana yang sudah disepakati, bukan ke ingatan orang yang mengetik. Plan yang hanya ada di riwayat chat tidak bisa dilakukan itu. Format berkas dan lokasinya dibahas di bagian 10.12.
10.4 Review Plan: Cara Merespons Output Plan Mode
Setelah Claude menghasilkan plan, kualitas hasil akhir sangat bergantung pada cara kita merespons. Ada tiga tipe respons yang efektif, masing-masing untuk situasi berbeda.
Tipe pertama adalah konfirmasi disertai koreksi — kita menjawab pertanyaan dan menambal celah yang terlihat.
1Jawaban pertanyaan:
21. StatusCancelled belum ada di entity.go
32. Mock ada, generated dengan mockgen — perlu regenerate setelah update interface
43. Inject clock interface — ya, buat ClockProvider interface
54. EC1 jadikan integration test di test/integration/
6
7Koreksi plan:
8- Step 6: setelah buat mock baru, baru jalankan test
9- Tambahkan Step 10: update mock (mockgen)
10
11Lanjut dengan plan yang sudah dikoreksi.Respons semacam ini paling umum: plan sudah 90% benar dan hanya perlu penyesuaian kecil sebelum implementasi dimulai.
Tipe kedua adalah mengajukan pertanyaan lebih lanjut — ketika ada keputusan desain yang belum matang dan perlu didiskusikan sebelum committed ke kode.
1Satu pertanyaan sebelum lanjut:
2Untuk CancelWithStockRestore — apakah ini lebih baik jadi method di repository
3atau kita buat TransactionManager terpisah?
4
5Pertimbangkan bahwa kita mungkin akan butuh pattern yang sama
6untuk operasi lain yang juga butuh multi-table atomic operation.Pertanyaan seperti ini mengangkat trade-off arsitektur yang lebih murah didiskusikan di fase plan daripada di-refactor setelah kode jadi.
Tipe ketiga adalah menolak dan mengarahkan ulang — ketika plan terlalu granular, terlalu dangkal, atau melewatkan sesuatu yang penting.
1Plan ini terlalu granular di bagian Step 3-4.
2Implementasi repository bisa digabung.
3
4Lebih penting: kamu tidak mention bahwa kita perlu update
5wireup di cmd/api/main.go untuk inject dependency baru.
6Tolong update plan, tambahkan dependency injection setup.Jangan ragu menolak plan; iterasi di level rencana selalu lebih murah daripada iterasi di level kode.
10.5 Plan Mode untuk Fitur yang Lebih Complex
Untuk fitur yang span multiple service, satu plan sederhana tidak cukup — rencana perlu mencakup kontrak antar service dan urutan deploy yang aman. Prompt berikut menunjukkan cara meminta plan lintas service.
1Buat implementation plan untuk fitur "order confirmation notification"
2yang melibatkan:
31. Order Service (publisher): publish event setelah order created
42. Notification Service (consumer): terima event, kirim email
53. Email Template Service: provide email template
6
7Untuk setiap service, plan harus mencakup:
8- Files yang dibuat/dimodifikasi
9- Event contract (Kafka message schema)
10- Interface yang perlu dibuat
11- Dependency yang perlu di-inject
12- Test strategy (unit vs integration)
13
14Tentukan juga:
15- Urutan implementasi yang aman (mana yang bisa paralel, mana yang sequential)
16- Rollback plan jika salah satu service gagal deploy
17
18---
19Spec order service: [specs/order/create-order.md]
20Spec notification service: [specs/notification/order-confirmation.md]Pada fitur lintas service, event contract dan rollback plan adalah dua hal yang paling sering terlupa — pastikan keduanya eksplisit di plan.
10.6 Menggunakan Plan sebagai Checklist
Setelah plan diapprove, ubah plan menjadi checklist yang bisa di-track agar progres implementasi terlihat jelas dan tidak ada step yang terlewat.
1# Implementation Checklist: Cancel Order
2Spec: specs/order/cancel-order.md v1.3
3Engineer: @[nama]
4Started: 2025-07-15
5
6## Status
7- [x] Plan di-review dan di-approve
8- [ ] Implementation selesai
9- [ ] PR dibuat
10- [ ] PR di-merge
11
12## Task List
13
14### Domain Layer
15- [x] Step 1: Update entity.go — tambah StatusCancelled ✅ (commit: abc123)
16- [x] Step 2: Update repository.go — tambah interface methods ✅ (commit: def456)
17- [ ] Step 3: Update/buat errors.go
18
19### Repository Layer
20- [ ] Step 4: Implementasi GetByIDAndUserID dan CancelWithStockRestore
21
22### Usecase Layer
23- [ ] Step 5: Buat cancel_order.go
24- [ ] Step 6: Buat cancel_order_test.go
25- [ ] Step 10: Update mock setelah interface update
26
27### Delivery Layer
28- [ ] Step 7: Update order_handler.go
29- [ ] Step 8: Update router.go
30
31### Wiring
32- [ ] Step 9: Update main.go dependency injection
33
34### Verification
35- [ ] go test ./... -race → semua pass
36- [ ] go vet ./... → clean
37- [ ] golangci-lint run → clean
38- [ ] Spec compliance check: ./scripts/spec-audit.sh specs/order/cancel-order.mdChecklist ini menjembatani plan dan eksekusi: setiap step punya jejak commit, dan bagian Verification memastikan definisi “selesai” tidak kabur.
10.7 Plan untuk Refactoring: Plan Mode Khusus
Ketika melakukan refactoring, plan perlu extra caution karena taruhannya adalah tidak mengubah behavior sambil mengubah struktur. Prompt berikut menegaskan constraint yang wajib dijaga.
1Saya ingin refactor cara kita handle error di OrderHandler.
2Saat ini setiap handler punya switch statement sendiri untuk error mapping.
3Saya ingin centralize ini ke satu middleware atau helper.
4
5Buat refactoring plan yang:
61. Identifikasi semua tempat yang perlu diubah
72. Definisikan interface/abstraction baru yang akan dipakai
83. Strategy: big bang (ganti semuanya sekaligus) atau incremental?
94. Pastikan: setiap langkah refactoring tetap bisa di-test
105. Risk assessment: apa yang bisa break?
116. Rollback plan: bagaimana jika harus revert?
12
13CONSTRAINT PENTING:
14- Zero behavioral change — refactoring hanya mengubah structure, bukan behavior
15- Setiap commit harus green (semua test pass)
16- Tidak boleh ada PR yang > 200 baris changedConstraint “zero behavioral change” dan “setiap commit harus green” adalah pengaman yang membuat refactoring besar tetap reversible dan reviewable.
10.8 Plan Mode untuk Database Migration
Database migration punya plan yang lebih specific karena menyentuh state persisten yang tidak bisa di-rollback semudah kode. Prompt berikut memastikan aspek backward compatibility dan zero downtime ikut direncanakan.
1Buat database migration plan untuk menambahkan fitur "order cancellation reason".
2
3Requirements dari spec:
4- Order yang dicancel bisa punya optional reason (string, max 500 chars)
5- Reason bisa diset saat cancel atau setelahnya (dalam 24 jam)
6- Perlu audit trail: siapa yang set reason dan kapan
7
8Plan harus mencakup:
91. Migration script (forward dan rollback)
102. Pengaruh ke existing queries yang perlu diupdate
113. Go struct changes
124. Repository method changes
135. Cara deploy yang aman (zero downtime)
14
15Pertimbangkan:
16- Migration ini backward compatible tidak? (existing rows tidak punya reason — NULL ok?)
17- Perlu ada index untuk reason field? (jika sering di-query/filter)
18- Apakah perlu data migration untuk rows existing?Tiga pertimbangan di akhir — backward compatibility, index, dan data migration — adalah pertanyaan yang menentukan apakah migration bisa dijalankan tanpa downtime di production.
10.9 Iteration dalam Plan Mode
Plan Mode bukan satu kali; sering kali dibutuhkan beberapa iterasi dengan kedalaman yang meningkat. Round pertama biasanya high-level: file apa saja dan sequence umum.
Round kedua adalah deep dive ke satu komponen yang paling complex, di mana kita meminta detail SQL, transaction flow, dan error handling.
1Dari plan tadi, mari detail lebih lanjut untuk CancelWithStockRestore
2di repository layer.
3
4Ini adalah operasi paling critical karena:
5- Harus atomic (data integrity)
6- Ada concurrent access concern (EC1)
7- Jika gagal parsial, harus rollback sempurna (EC4)
8
9Buat detailed plan untuk method ini:
101. SQL queries yang diperlukan (beserta parameter)
112. Transaction flow yang exact
123. Error handling untuk setiap step
134. Test cases yang diperlukan (unit vs integration)
145. Potential performance issue dan solusinyaDeep dive semacam ini fokus pada bagian yang paling berisiko, sehingga effort review terkonsentrasi di tempat yang paling menentukan.
Round ketiga adalah review dan approval final, biasanya dengan meminta perspektif yang lebih kritis.
1Plan sudah lengkap. Sebelum implementasi, satu final check:
2Review plan ini dari perspektif senior engineer yang berpengalaman
3dengan production issues. Apa yang paling berisiko?Iterasi bertingkat ini memastikan plan matang secara bertahap tanpa harus sempurna sejak percobaan pertama.
10.10 Plan untuk Estimasi yang Lebih Akurat
Plan Mode juga berguna untuk menghasilkan estimasi implementasi yang lebih akurat karena estimasi dibangun di atas breakdown task yang konkret, bukan tebakan kasar.
1Berdasarkan implementation plan untuk cancel order,
2buat estimasi effort yang realistic:
3
4Untuk setiap task/step:
5- Effort estimate (dalam jam, bukan story points)
6- Confidence level: high (sudah pernah buat ini) / medium / low (hal baru)
7- Potential blocker yang bisa delay
8
9Asumsi:
10- Engineer sudah familiar dengan codebase (3+ bulan di project ini)
11- Unit test di-tulis bersamaan dengan kode, bukan setelah
12- Code review oleh 1 senior engineer
13
14Output format:
15| Task | Hours | Confidence | Potential Blocker |
16|------|-------|------------|-------------------|
17| ... | ... | ... | ... |
18
19Total dan buffer recommendation.Dengan menyertakan confidence level dan potential blocker per task, estimasi menjadi lebih jujur dan buffer bisa dialokasikan tepat pada bagian yang paling tidak pasti.
10.11 Plan Mode vs Langsung Implementasi: Kapan Masing-masing?
Tidak semua pekerjaan butuh Plan Mode; memaksakannya pada bug fix kecil justru membuang waktu. Tabel berikut membantu memutuskan kapan plan sepadan dengan usahanya.
| Situasi | Plan Mode | Langsung Implementasi |
|---|---|---|
| Fitur baru yang complex | ✅ | - |
| Menyentuh 5+ files | ✅ | - |
| Ada concurrent/transaction concern | ✅ | - |
| Fitur dengan spec yang sudah sangat jelas + pattern established | - | ✅ |
| Bug fix yang scope-nya kecil | - | ✅ |
| Simple CRUD mengikuti existing pattern | - | ✅ |
| Anggota tim baru yang implementasi | ✅ | - |
Aturan praktisnya: semakin besar blast radius perubahan dan semakin tidak familiar engineer dengan area kode, semakin besar nilai Plan Mode.
10.12 Integrasi Plan Mode dengan Git
Plan sebaiknya bukan artifact yang hilang setelah dipakai — simpan sebagai bagian dari workflow git agar keputusan implementasi terdokumentasi. Rangkaian perintah berikut menunjukkan alur dari spec, plan, hingga branch implementasi.
1# Buat branch untuk spec
2git checkout -b spec/cancel-order
3# Commit spec
4git add specs/order/cancel-order.md
5git commit -m "spec: add cancel order specification v1.0"
6
7# Buat branch untuk plan (opsional, jika plan perlu review tim)
8git checkout -b plan/cancel-order
9# Commit plan sebagai dokumen
10cat > docs/plans/cancel-order-2025-07-15.md << 'EOF'
11[isi plan dari Claude]
12EOF
13git add docs/plans/cancel-order-2025-07-15.md
14git commit -m "plan: implementation plan for cancel order"
15
16# Review plan, approve, baru buat branch implementation
17git checkout -b feature/cancel-orderDengan menyimpan plan di git, tim mendapatkan jejak audit tentang “kenapa implementasi diputuskan seperti ini” yang berguna berbulan-bulan kemudian saat kode perlu dipahami ulang.
10.13 Plan Mode untuk Pair Programming
Ketika dua developer bekerja pada fitur yang sama, plan berfungsi sebagai kontrak koordinasi yang meminimalkan blocking dan merge conflict. Prompt berikut meminta plan yang membagi kerja secara paralel.
1Kami adalah dua developer yang akan pair-implement fitur cancel order.
2Developer A akan handle: domain layer + usecase layer
3Developer B akan handle: repository layer + handler layer
4
5Buat plan yang:
61. Mendefinisikan interface yang harus disepakati dulu (sebelum masing-masing mulai)
72. Membagi task yang bisa dikerjakan paralel
83. Mengidentifikasi integration point yang perlu koordinasi
94. Menyarankan urutan testing (siapa mock siapa)
10
11Tujuan: minimize blocking antar developerKunci pair programming yang lancar adalah menyepakati interface lebih dulu, sehingga masing-masing developer bisa bekerja di sisinya dengan mock tanpa saling menunggu.
10.14 Contoh Plan Mode untuk Dependency Injection Setup
Salah satu area yang sering missed dalam plan adalah dependency injection wiring — usecase baru dibuat tapi lupa di-wire di main.go. Prompt berikut memaksa plan mencakup perubahan DI secara eksplisit.
1Saya sering lupa update dependency injection saat tambah usecase baru.
2Tolong plan juga mencakup perubahan di cmd/api/main.go.
3
4Saat ini pattern DI di main.go adalah:
5@cmd/api/main.go
6
7Untuk cancel order usecase, apa yang perlu ditambahkan?
8Include:
9- Import yang perlu ditambahkan
10- Inisialisasi publisher (OrderCancelledPublisher)
11- Inisialisasi usecase
12- Inject ke handler
13- Inject handler ke router
14
15Tunjukkan sebagai code diff (sebelum/sesudah) bukan full file.Meminta output sebagai diff sebelum/sesudah membuat perubahan DI mudah di-review dan mengurangi risiko wiring yang terlewat saat implementasi.
10.15 Validasi Plan dengan Claude Second Opinion
Setelah mendapat plan, meminta “second opinion” sebelum approval sering mengungkap celah yang tidak obvious. Prompt berikut meminta Claude mereview plan-nya sendiri dengan lensa yang lebih kritis.
1Ini adalah implementation plan yang sudah di-draft.
2Tolong review sebagai senior engineer yang pernah maintain
3codebase Go selama 3 tahun dan sering debug production issues.
4
5Identifikasi:
61. Apa yang mungkin terlewat?
72. Urutan implementasi yang bisa dioptimalkan?
83. Potensi issue yang tidak obvious?
94. Apakah ada langkah yang unnecessary (over-engineering)?
10
11Plan: @docs/plans/cancel-order-2025-07-15.mdSecond opinion ini murah tetapi berdampak besar: satu putaran review kritis sering menemukan asumsi berbahaya sebelum berubah menjadi bug production.
10.16 Plan Mode untuk Legacy Code
Ketika harus menambahkan fitur ke legacy code, plan perlu mempertimbangkan koeksistensi pola lama dan baru tanpa memaksakan big bang refactoring. Prompt berikut mengarahkan Claude ke strategi yang pragmatis.
1Saya harus menambahkan cancel order ke codebase yang sudah lama.
2Codebase ini menggunakan pattern yang berbeda dari yang ideal:
3- Handler langsung query DB (tidak ada usecase layer)
4- Error handling tidak consistent
5- Tidak ada unit test
6
7Plan harus mempertimbangkan:
81. Haruskah refactor existing code dulu, atau tambahkan feature dengan pattern baru?
92. Jika tambahkan dengan pattern baru: bagaimana coexistence dengan pattern lama?
103. Minimal refactoring yang diperlukan agar fitur baru bisa follow best practice
114. Strategy untuk mulai introduce test secara incremental
12
13Tujuan: delivery fitur baru tanpa big bang refactoring
14@internal/usecase/order/cancel_order.goPada legacy code, tujuan realistisnya adalah men-deliver fitur baru dengan pola yang lebih baik sambil memperkenalkan test secara incremental — bukan membersihkan seluruh codebase sekaligus.
10.17 Output Plan Mode ke Jira/Linear
Plan Mode output bisa langsung dijadikan Jira tickets atau Linear issues, menghemat waktu grooming manual. Prompt berikut mengubah plan menjadi daftar task yang siap dimasukkan ke tracker.
1Ubah implementation plan berikut menjadi daftar tasks yang siap
2dimasukkan ke Jira/Linear.
3
4Format untuk setiap task:
5**Title:** [maksimum 60 karakter, actionable]
6**Description:** [2-3 kalimat context + acceptance criteria singkat]
7**Labels:** [domain/repository/usecase/handler/test]
8**Estimate:** [S/M/L - Small < 2 jam, Medium 2-4 jam, Large > 4 jam]
9**Dependencies:** [task mana yang harus selesai dulu]
10
11Plan: @docs/plans/cancel-order-2025-07-15.mdDengan menyertakan dependencies antar task, board langsung mencerminkan urutan kerja yang benar dan tim tahu apa yang bisa dimulai lebih dulu.
10.18 Tips & Gotchas
Beberapa praktik berikut memisahkan Plan Mode yang benar-benar berguna dari yang sekadar formalitas. Mulai dari tips positif yang perlu dibiasakan.
💡 Tip 1: Pisahkan Plan Mode dan Implementation Mode secara tegas
Saat Plan Mode, instruksikan Claude untuk TIDAK menulis implementasi. Banyak developer yang minta plan tapi kemudian AI langsung menulis kode — dan review plan jadi kurang mendalam.
💡 Tip 2: Ajukan pertanyaan ke plan sebelum approve
Jangan approve plan yang ada hal yang tidak kamu mengerti. Lebih baik tanya sekarang dari harus refactor nanti.
💡 Tip 3: Simpan plan bersama spec dan kode
Plan adalah documentation tentang “bagaimana kita memutuskan implementasi ini.” Simpan di git sebagai bagian dari project artifacts.
💡 Tip 4: Update plan jika ditemukan hal tak terduga saat implementasi
Jika saat implementasi ditemukan sesuatu yang tidak ada di plan — stop, update plan, lanjut. Jangan “work around” tanpa update plan.
Selanjutnya, beberapa gotcha yang perlu diwaspadai agar Plan Mode tidak berbalik merugikan.
⚠️ Gotcha 1: Plan yang terlalu detail bisa jadi constraint
Plan harus mencakup “apa” dan “urutan”, bukan detail implementation. Jangan plan yang terlalu prescriptive — beri developer ruang untuk memilih approach terbaik.
⚠️ Gotcha 2: Claude bisa membuat plan tanpa membaca kode existing
Pastikan provide referensi ke existing code patterns. Tanpa ini, plan mungkin propose hal yang tidak konsisten dengan codebase yang ada.
⚠️ Gotcha 3: Dependency injection sering dilupakan dari plan
Selalu tanyakan secara explicit: “Apa yang perlu diupdate di main.go atau DI setup?”
⚠️ Gotcha 4: Concurrent implementation tanpa plan = conflict
Jika dua developer bekerja pada fitur yang overlap, plan yang explicit membantu avoid merge conflict yang menyakitkan.
Intinya, Plan Mode paling efektif ketika disiplin dijaga: batasi cakupan plan, selalu sertakan referensi kode, dan jangan pernah lewatkan wiring dependency.
10.19 Plan Mode untuk Onboarding Developer Baru
Plan Mode adalah tool yang sangat bagus untuk onboarding karena memaksa developer baru memahami codebase sebelum menyentuh kode. Prompt berikut memandu mereka dari spec ke plan yang bisa didiskusikan dengan senior.
1[Untuk developer baru yang akan implementasi cancel order]
2
3Gunakan spec ini untuk membuat plan implementasi:
4- specs/order/cancel-order.md
5
6Sebelum coding, baca dan pahami:
7- internal/usecase/order/create_order.go (pola yang sama)
8- internal/domain/order/entity.go (domain types)
9- CLAUDE.md (conventions)
10
11Kemudian buat plan implementasi dan diskusikan dengan senior engineer
12sebelum mulai coding.
13
14Pertanyaan yang harus bisa dijawab dalam plan:
151. File apa saja yang akan kamu buat/modifikasi?
162. Interface baru apa yang akan kamu definisikan?
173. Apa saja test cases yang akan kamu tulis?
184. Apa yang paling tidak kamu mengerti dan perlu didiskusikan?Bagi developer baru, plan yang harus mereka pertahankan di depan senior adalah cara belajar codebase yang jauh lebih cepat daripada langsung terjun menulis kode.
10.20 Ringkasan
Plan Mode adalah investasi kecil yang memberikan return besar: lebih sedikit rework, lebih sedikit bug arsitektur, dan implementasi yang lebih terarah.
Komponen plan yang baik mencakup files baru dan modified, database changes, interface baru, implementation sequence, dan potential issues. Workflow yang efektif berjalan dalam lima langkah berurutan:
- Buat plan dari spec
- Review dan koreksi plan
- Jawab pertanyaan clarification
- Approve plan
- Baru mulai implementasi
Plan Mode wajib dipakai untuk fitur baru yang complex, perubahan yang menyentuh 5+ files, operasi dengan concurrent atau transaction concern, dan saat developer baru yang akan implementasi. Sebagai bonus, plan yang sama bisa diolah menjadi implementation checklist, estimasi yang lebih akurat, hingga tickets untuk Jira/Linear.
Di artikel berikutnya, kita akan membahas Task Breakdown — teknik memecah spec menjadi unit kerja Golang yang bisa diimplementasikan satu per satu dengan hasil yang verifiable di setiap langkah.