Ekosistem Tools SDD 2026: Claude Code, Kiro, Cursor vs Spec Kit untuk Golang

Memilih tools SDD 2026 untuk Golang terasa membingungkan karena landscape AI coding tools berubah sangat cepat. Apa yang terbaik enam bulan lalu mungkin sudah ada alternatif yang lebih baik sekarang. Dan berbeda dari pilihan framework atau database yang biasanya lock-in, pilihan AI tools jauh lebih fluid — kamu bisa ganti kapan saja tanpa merombak arsitektur.

Di artikel ini, kita petakan ekosistem tools yang relevan untuk SDD workflow di 2026: bukan hanya fitur-fiturnya, tapi bagaimana masing-masing cocok (atau tidak cocok) dengan pendekatan spec-first yang sudah kita bahas.

03.1 Kenapa Pilihan Tool Penting dalam SDD

Tidak semua AI coding tools diciptakan sama dalam konteks SDD. Ada tools yang:

• Bisa membaca file spec dan menggunakannya sebagai context
• Punya mekanisme untuk menjaga konsistensi arsitektur
• Support agentic mode untuk eksekusi multi-step task
• Bisa diinstruksikan via CLAUDE.md atau file konfigurasi serupa

Dan ada tools yang bagus untuk code completion tapi kurang cocok untuk spec-driven code generation yang kita butuhkan. Pemilihan tool yang tepat bisa secara dramatis meningkatkan atau menurunkan efektivitas SDD workflow kamu.

03.2 Claude Code: Tool Utama dalam Seri Ini

Claude Code (dari Anthropic) adalah tool yang akan kita gunakan sebagai primary tool sepanjang seri ini. Bukan karena ini “yang terbaik secara objektif” — tapi karena memiliki karakteristik yang paling cocok untuk SDD workflow.

Instalasi dan Setup

Langkah pertama adalah memasang Claude Code, yang tersedia lewat npm maupun Homebrew tergantung platform kamu. Perintah berikut menutup ketiga skenario itu sekaligus memverifikasi hasil instalasi.

1# Instalasi via npm
2npm install -g @anthropic-ai/claude-code
3
4# Atau via native installer (macOS/Linux)
5curl -fsSL https://claude.ai/install.sh | bash
6
7# Verifikasi
8claude --version

Jika claude --version mencetak nomor versi, tool sudah siap dipakai dari direktori mana pun di terminal kamu.

Cara Claude Code Mendukung SDD

1. File Context yang Persisten

Keunggulan pertama Claude Code adalah kemampuannya membaca seluruh codebase beserta file spec sebagai context. Sesi interaktif berikut menunjukkan cara menanyakan status implementasi langsung terhadap sebuah spec.

1# Jalankan di root project, Claude Code membaca semua file
2cd santekno-shop/
3claude
4
5# Di dalam session:
6> Berdasarkan specs/order/cancel-order.md, apa saja AC yang belum diimplementasikan?

Dengan pola ini, spec bukan lagi dokumen mati — ia menjadi sumber kebenaran yang bisa langsung dikorelasikan dengan kode aktual oleh AI.

2. CLAUDE.md sebagai Project Memory

Mekanisme kedua adalah file CLAUDE.md di root project yang dibaca secara otomatis di setiap sesi. Contoh berikut memperlihatkan cara memberikan “persistent context” tentang arsitektur, conventions, dan rules proyek.

 1# CLAUDE.md
 2## Arsitektur
 3Clean architecture: domain → usecase → repository → handler
 4Tidak boleh ada direct DB call dari handler layer.
 5
 6## Stack
 7- Go 1.25, Echo v4, pgx/v5
 8- ID: uuid.UUID dari github.com/google/uuid
 9- Error: selalu wrap dengan %w
10
11## Spec
12Setiap implementasi fitur harus referensikan spec di specs/domain/[feature].md

Karena file ini dibaca otomatis, kamu tidak perlu mengulang penjelasan arsitektur di setiap sesi baru — cukup tulis sekali, berlaku seterusnya.

3. Agentic Mode

Kapabilitas ketiga adalah agentic mode: Claude Code bisa menjalankan command, menulis file, dan melakukan task multi-step dalam satu alur. Cuplikan berikut merangkum rangkaian aksi yang bisa dilakukan dalam satu sesi.

1# Claude Code bisa:
2# - Baca spec file
3# - Generate kode
4# - Jalankan test
5# - Analisis error
6# - Fix error
7# Semua dalam satu sesi interaktif

Kemampuan menutup loop kode–test–fix inilah yang membuat Claude Code cocok untuk implementasi spec secara end-to-end, bukan sekadar autocomplete.

Keterbatasan Claude Code

Meski powerful, Claude Code punya trade-off yang perlu kamu sadari sejak awal:

• Cost: Per-token pricing, intensive usage bisa mahal
• Internet required: Tidak bisa dipakai offline
• Context window: Ada batas ukuran codebase yang bisa di-load sekaligus
• Learning curve: Butuh waktu untuk menemukan prompt style yang efektif

03.3 GitHub Spec Kit: Otomasi SDD Workflow

GitHub Spec Kit adalah CLI tool yang dirancang khusus untuk SDD workflow. Dikembangkan oleh GitHub, tool ini mengotomasi siklus: clarify → plan → implement.

Instalasi

Spec Kit berbasis Python dan dipasang lewat uv — atau dijalankan sekali pakai lewat uvx untuk sekadar mencoba. Perintah berikut menyediakan kedua opsi tersebut; detail persistent vs one-time setup kita bedah di Topik 2.

1# One-time, tanpa install permanen (uvx)
2uvx --from git+https://github.com/github/spec-kit.git specify init
3
4# Atau persistent via uv
5uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
6specify init

Setelah init dijalankan, struktur direktori spec akan tergenerate dan kamu siap memakai keenam perintah intinya.

Enam Perintah Inti

Kekuatan Spec Kit ada pada enam perintah yang memandu siklus SDD dari konstitusi hingga implementasi. Daftar berikut menjelaskan peran masing-masing perintah secara berurutan.

1# Dijalankan sebagai slash command di dalam Claude Code (setelah `specify init`):
2
3/speckit.constitution   # 1. Tetapkan "konstitusi" proyek — rules yang tidak boleh dilanggar
4/speckit.specify        # 2. Tulis kebutuhan dalam bahasa natural
5/speckit.clarify        # 3. AI mengajukan pertanyaan klarifikasi
6/speckit.plan           # 4. Generate rencana teknis
7/speckit.tasks          # 5. Breakdown ke task-task yang executable
8/speckit.implement      # 6. Eksekusi implementasi berdasarkan tasks

Urutan enam perintah ini memaksa disiplin spec-first: kamu tidak bisa lompat langsung ke implement tanpa melewati klarifikasi dan perencanaan lebih dulu.

Contoh Workflow Lengkap

Agar terasa konkret, mari lihat satu sesi penuh dari specify hingga implement untuk fitur cancel order. Transkrip berikut memperlihatkan bagaimana Spec Kit menuntun setiap tahap secara interaktif.

 1# Di root project Santekno Shop
 2> /speckit.specify "Customer harus bisa cancel order yang masih pending"
 3
 4📝 Spec Kit: Klarifikasi diperlukan sebelum kita lanjut.
 5
 6> /speckit.clarify
 7
 8🤔 Pertanyaan klarifikasi:
 91. Apakah ada batas waktu untuk cancel? (contoh: hanya dalam 15 menit)
102. Apa yang terjadi dengan stok produk setelah cancel?
113. Apakah user mendapat notifikasi setelah cancel berhasil?
124. Siapa yang bisa cancel — hanya customer atau juga admin?
13
14> Jawab: 1) Ya 15 menit, 2) Stok dikembalikan otomatis, 
15> 3) Ya via email, 4) Hanya customer untuk spec ini
16
17> /speckit.plan
18
19📋 Technical Plan:
20- New usecase: CancelOrderUseCase
21- Repository method: CancelOrderWithStockRestore (atomic)
22- Handler: DELETE /orders/:id
23- Kafka event: ORDER_CANCELLED
24- Email notification: via downstream Notification Service (event-driven)
25
26> /speckit.tasks
27
28✅ Tasks generated:
291. [domain] Add StatusCancelled to order.Status enum
302. [usecase] Implement CancelOrderUseCase with 15min window validation
313. [repository] Implement CancelOrderWithStockRestore (tx)
324. [handler] Add DELETE /orders/:id
335. [test] Unit tests for all ACs
346. [integration] Test concurrent cancel scenario
35
36> /speckit.implement

Perhatikan bahwa setiap keputusan desain muncul dari jawaban klarifikasi, bukan asumsi AI — inilah nilai jual utama alur terstruktur Spec Kit.

Kapan Gunakan Spec Kit vs Claude Code?

Karena keduanya sama-sama SDD-aware, pertanyaan praktisnya adalah kapan memilih yang mana. Tabel berikut memetakan situasi umum ke rekomendasi tool yang paling pas.

Pola umumnya jelas: Spec Kit unggul untuk pekerjaan greenfield yang terstruktur, sedangkan Claude Code menang saat butuh fleksibilitas menjelajahi kode yang sudah ada.

03.4 Cursor: IDE dengan AI Terintegrasi

Cursor adalah fork dari VS Code yang menambahkan AI capabilities langsung ke IDE. Berbeda dari Claude Code (terminal-based), Cursor terintegrasi dengan editor experience.

Fitur Relevan untuk SDD

Composer Mode (Cmd+I) memungkinkan kamu menulis instruksi panjang dengan referensi ke banyak file sekaligus. Contoh prompt berikut mereferensikan spec dan file pola sebagai konteks implementasi.

1@specs/order/cancel-order.md @internal/usecase/order/create_order.go
2Implementasikan CancelOrderUseCase mengikuti pola di file referensi
3dan memenuhi semua AC di spec.

Dengan mereferensikan spec dan file contoh secara eksplisit, kamu mengarahkan Cursor untuk konsisten dengan konvensi proyek alih-alih menebak sendiri.

Rules for AI hadir lewat file .cursorrules yang perannya mirip CLAUDE.md. Konfigurasi berikut menegakkan aturan arsitektur di setiap interaksi.

1# .cursorrules
2Always follow clean architecture: domain -> usecase -> repository -> handler
3Never write business logic in handler layer
4Always use uuid.UUID for IDs
5Always reference spec before implementing any feature

Aturan yang ditulis sekali di .cursorrules ini akan diterapkan otomatis, sehingga habit spec-first tidak bergantung pada ingatan kamu di tiap sesi. Selain itu, keyword @codebase bisa dipakai untuk memberi context seluruh project ke AI.

Keterbatasan Cursor untuk SDD

Cursor lebih fokus ke code completion dan editing daripada spec-driven generation. Tidak punya mekanisme native untuk “baca spec dulu, baru code.” Ini harus dibangun lewat habits dan .cursorrules yang baik.

03.5 Kiro: IDE Agentic dari AWS

Kiro adalah IDE agentic dari AWS — GA sejak akhir 2025 setelah masa preview — yang didesain khusus untuk “agentic coding” — AI yang bisa merencanakan dan mengeksekusi task multi-step secara mandiri.

Filosofi Kiro

Kiro memperkenalkan konsep “spec-first by design” — setiap fitur dimulai dengan spesifikasi yang di-generate oleh AI dari requirement yang diberikan user. Diagram alur berikut menunjukkan bagaimana pendekatan ini sangat aligned dengan SDD.

1User input: "Add product search with filters"
2↓
3Kiro generates: Requirements doc + Design doc + Tasks breakdown
4↓
5User reviews and approves
6↓
7Kiro implements: Code, tests, documentation

Yang menarik dari alur ini, spesifikasi bukan opsi tambahan melainkan titik mulai wajib — persis prinsip yang kita anut sepanjang seri SDD ini.

Fitur Khusus Kiro

Steering Files adalah padanan CLAUDE.md di Kiro, tapi lebih terstruktur dalam format YAML. Contoh berikut menetapkan gaya arsitektur dan pola yang harus dipatuhi AI.

1# .kiro/steering/product-rules.md
2architecture: clean-architecture
3patterns:
4  - domain-first
5  - interface-based-dependency
6language: golang
7version: "1.25"

Format terstruktur ini membuat aturan proyek mudah divalidasi mesin dibanding prosa bebas di CLAUDE.md.

Hooks memungkinkan otomasi yang berjalan saat event tertentu terjadi. Contoh hook berikut memverifikasi ketersediaan spec sebelum implementasi dimulai.

1# .kiro/hooks/pre-implement.yaml
2# Verifikasi spec tersedia sebelum implementasi dimulai

Dengan hook seperti ini, disiplin spec-first ditegakkan secara otomatis oleh tooling, bukan mengandalkan kedisiplinan manual developer.

Status di 2026

Kiro sudah GA dengan tier pricing sendiri di ekosistem AWS. Cukup matang untuk dipakai serius, meski ekosistem plugin dan komunitasnya masih lebih muda dibanding Claude Code atau Cursor. Kalau tim kamu sudah hidup di AWS, Kiro kini alternatif nyata — bukan sekadar eksperimen.

03.6 Aider: CLI Tool untuk Pair Programming

Aider adalah CLI tool yang memposisikan dirinya sebagai “AI pair programmer.” Berbeda dari Claude Code yang lebih conversational, Aider lebih fokus ke git-integrated workflow. Cuplikan berikut menunjukkan instalasi hingga pemakaian dengan file spec sebagai context.

 1# Instalasi
 2pip install aider-chat
 3
 4# Jalankan di project
 5aider --model sonnet   # alias untuk model Claude Sonnet terbaru
 6
 7# Contoh usage dengan spec
 8> /add specs/order/cancel-order.md internal/usecase/order/
 9> Implement CancelOrderUseCase based on the spec file above.
10> After implementing, run the tests and fix any failures.

Perhatikan perintah /add: Aider mewajibkan kamu menentukan secara eksplisit file mana yang boleh diubah, sebuah guardrail yang mencegah AI menyentuh file di luar cakupan.

Keunggulan Aider untuk SDD

Beberapa karakteristik membuat Aider menonjol untuk workflow yang berpusat di git:

• Auto-commit: Setiap perubahan kode auto-committed dengan pesan yang deskriptif
• Git aware: Bisa lihat diff, revert, branch management
• File explicit: Harus eksplisit menentukan file mana yang boleh diubah
• Multi-model: Bisa ganti antara OpenAI, Anthropic, local models

Keterbatasan Aider

Di sisi lain, Aider punya beberapa kekurangan dibanding tool SDD-native:

• Tidak punya native CLAUDE.md/constitution mechanism
• Lebih cocok untuk developer yang sudah comfortable dengan CLI
• Context management perlu dilakukan manual

03.7 Copilot dan Tabnine: Completion vs Generation

Ada dua kategori tool yang sering dicampur aduk, padahal perannya sangat berbeda dalam SDD.

AI Code Completion (GitHub Copilot, Tabnine, Supermaven):

• Mengisi kode berdasarkan konteks sekitar
• Reaktif — merespons apa yang kamu tulis
• Tidak cocok untuk SDD (tidak bisa “baca spec dulu”)
• Bagus sebagai pelengkap, bukan sebagai primary SDD tool

Catatan 2026: Copilot kini juga punya agent mode dan model picker multi-model, tapi kekuatan utamanya tetap completion — posisinya di SDD workflow tidak berubah.

AI Code Generation (Claude Code, Cursor Composer, Aider):

• Bisa menerima instruksi kompleks dengan referensi ke banyak file
• Proaktif — bisa generate kode dari spesifikasi
• Cocok untuk SDD workflow
• Yang kita fokuskan di seri ini

Kesimpulannya: jangan ganti GitHub Copilot dengan Claude Code — keduanya punya use case berbeda dan bisa dipakai bersamaan.

03.8 Perbandingan Komprehensif Tool SDD

Setelah membahas masing-masing tool satu per satu, tabel berikut menyandingkan kelimanya berdasarkan kriteria yang paling relevan untuk SDD.

Dari tabel ini terlihat tidak ada satu tool yang unggul di semua kolom — pilihan selalu soal trade-off antara kematangan, kemudahan, dan gaya kerja yang kamu sukai.

03.9 Setup Optimal untuk Santekno Shop

Untuk proyek Santekno Shop sepanjang seri ini, kita akan menggunakan Claude Code sebagai primary tool (terminal-based). Struktur direktori berikut menata spec, kode, dan template agar mudah dibaca AI maupun manusia.

 1santekno-shop/
 2├── CLAUDE.md              ← Claude Code memory
 3├── specs/
 4│   ├── README.md
 5│   ├── _templates/
 6│   │   └── feature-spec.md
 7│   └── domain/
 8│       ├── product/
 9│       ├── order/
10│       └── user/
11├── internal/
12│   ├── domain/
13│   ├── usecase/
14│   ├── repository/
15│   └── delivery/
16└── .github/
17    └── PULL_REQUEST_TEMPLATE.md

Dengan spec hidup berdampingan dengan kode di dalam repo yang sama, setiap perubahan spec ter-version bersama implementasinya. Alur kerja harian di atas struktur ini kita rangkum dalam langkah berikut.

11. Tulis spec di specs/domain/[feature].md
22. Review spec (manual atau dengan Claude Code)
33. Buka Claude Code: `claude`
44. "Berdasarkan specs/domain/[feature].md, buat plan implementasi"
55. Review plan, konfirmasi
66. "Lanjut implementasi sesuai plan"
77. Review kode, test
88. Commit dengan referensi ke spec

Urutan delapan langkah ini menjadikan spec sebagai gerbang: kode baru selalu berangkat dari spesifikasi yang sudah di-review, bukan dari improvisasi di editor.

03.10 CLAUDE.md: Project Memory untuk Claude Code

File CLAUDE.md di root project adalah cara paling efektif untuk memberikan persistent context ke Claude Code. Setiap sesi baru, Claude Code membaca file ini secara otomatis. Template berikut menunjukkan isi CLAUDE.md yang komprehensif untuk Santekno Shop.

 1# CLAUDE.md — Santekno Shop
 2
 3## Project Overview
 4E-commerce platform menggunakan microservice architecture.
 5Terdiri dari: Order Service, Product Service, User Service.
 6
 7## Tech Stack
 8- Go 1.25+ (gunakan fitur modern: iterator range-over-func, generic type alias)
 9- Echo v4 untuk HTTP handler
10- pgx/v5 untuk PostgreSQL (bukan database/sql)
11- github.com/google/uuid untuk semua ID
12- golang-jwt/jwt/v5 untuk JWT
13- testify/suite + gomock untuk testing
14
15## Architecture Rules
16- Clean architecture: domain → usecase → repository → handler
17- TIDAK BOLEH: direct DB call dari handler
18- TIDAK BOLEH: import usecase dari domain layer
19- HARUS: dependency injection via constructor
20- HARUS: error wrapping dengan fmt.Errorf("context: %w", err)
21
22## Spec Rules
23- Setiap fitur baru HARUS punya spec di specs/domain/[nama-fitur].md
24- Implementasi HARUS bisa di-trace ke AC di spec
25- Jika spec tidak ada, tanyakan dulu sebelum implement
26
27## Naming Conventions
28- File: snake_case (create_order.go, cancel_order.go)
29- Package: lowercase singular (order, product, user)
30- Interface: Verb-er pattern (OrderRepository, ProductService)
31- Error var: ErrPascalCase (ErrOrderNotFound, ErrInsufficientStock)
32
33## Common Patterns
34Lihat contoh di:
35- Handler: internal/delivery/http/handler/order_handler.go
36- Usecase: internal/usecase/order/create_order.go
37- Repository: internal/repository/postgres/order.go

Semakin spesifik aturan yang kamu tulis di sini, semakin sedikit koreksi yang perlu kamu lakukan atas kode yang di-generate AI — ini investasi sekali tulis dengan manfaat sepanjang proyek.

03.11 Memilih Tool Berdasarkan Kebutuhan

Tidak ada “best tool for everyone” — pilihan yang tepat bergantung pada konteks kerja kamu.

Pilih Claude Code jika:

• Kamu nyaman di terminal
• Butuh flexibility tinggi dalam interaction
• Proyek sudah punya banyak kode existing yang perlu dipahami AI
• Budget per-usage lebih predictable dari subscription

Pilih Spec Kit jika:

• Tim baru mulai dengan SDD dan butuh guided workflow
• Mau otomasi siklus spec → plan → implement
• Prefer tool yang opinionated tentang cara kerja

Pilih Cursor jika:

• Prefer IDE experience vs terminal
• Tim sudah familiar dengan VS Code
• Butuh integration yang mulus antara AI dan editing

Pilih Kiro jika:

• Ingin cutting-edge agentic capabilities
• Tim ready untuk early-adopter experience
• AWS ecosystem sudah dipakai

Pakai keduanya (Claude Code + Cursor) jika:

• Cursor untuk day-to-day coding
• Claude Code untuk complex spec implementation session

03.12 Integrasi Tool dengan Git Workflow

Apapun tool yang dipilih, penting untuk mengintegrasikannya dengan git workflow yang mendukung SDD. Contoh berikut menunjukkan konvensi penamaan branch dan commit message yang mereferensikan spec.

 1# Branch naming untuk SDD
 2git checkout -b spec/cancel-order        # untuk spec review
 3git checkout -b feature/cancel-order     # untuk implementasi
 4
 5# Commit message format
 6git commit -m "feat(order): implement cancel order usecase
 7
 8Implements specs/order/cancel-order.md v1.3
 9- AC1-AC6: cancel endpoint dengan 15 menit window
10- AC7-AC10: semua error case di-handle
11- EC1: concurrent cancel via SELECT FOR UPDATE
12- EC2: Kafka failure adalah best-effort
13
14Closes #123"

Commit message yang mereferensikan spec membuat git log bisa dijadikan audit trail: “kapan fitur X diimplementasikan dan berdasarkan spec versi berapa?” — sesuatu yang tak ternilai saat menelusuri regresi berbulan-bulan kemudian.

03.13 Tool untuk Quality Gates: Spec Compliance Check

Selain tools untuk generate kode, ada tools yang membantu menjaga kualitas spec compliance. golangci-lint hebat untuk static analysis kode Go, tapi tidak bisa cek spec compliance secara native — di sinilah script kustom berperan. Script berikut memanfaatkan Claude Code untuk memeriksa apakah setiap AC dan EC sudah terimplementasi.

 1#!/bin/bash
 2# scripts/check-spec-compliance.sh
 3# Usage: ./scripts/check-spec-compliance.sh specs/order/cancel-order.md
 4
 5SPEC=$1
 6echo "🔍 Checking spec compliance for: $SPEC"
 7
 8claude --no-interactive "
 9Berdasarkan spec di $SPEC, cek apakah semua AC dan EC sudah diimplementasikan
10di direktori internal/. 
11
12Output format:
13- ✅ AC1: [implemented di file X, line Y]
14- ❌ AC2: [NOT implemented]
15- ⚠️ EC1: [partially implemented — missing X]
16
17Terakhir, berikan summary: berapa persen AC yang sudah covered.
18"

Script ini mengubah pertanyaan subjektif “apakah kode sudah sesuai spec?” menjadi laporan terstruktur yang bisa dijalankan kapan saja. Agar berjalan otomatis, kita bisa menaruhnya di pre-commit hook seperti berikut.

 1# .git/hooks/pre-commit
 2#!/bin/bash
 3
 4# Jika ada spec yang berubah, cek consistency
 5CHANGED_SPECS=$(git diff --cached --name-only | grep "^specs/")
 6
 7if [ -n "$CHANGED_SPECS" ]; then
 8    echo "📋 Spec files changed — running compliance check..."
 9    for spec in $CHANGED_SPECS; do
10        ./scripts/check-spec-compliance.sh $spec
11    done
12fi

Dengan hook ini, setiap perubahan spec otomatis memicu pengecekan konsistensi sebelum commit — quality gate yang berjalan tanpa perlu kamu ingat menjalankannya.

03.14 Model AI yang Digunakan Tool-tool Ini

Pilihan tool seringkali juga berimplikasi pada model AI yang digunakan. Tabel berikut merangkum default model tiap tool dan apakah bisa diganti.

Untuk SDD workflow yang membutuhkan pemahaman context yang dalam dan mengikuti instruksi kompleks, model kelas atas (Claude Opus 4.8, GPT-5) biasanya memberikan hasil yang lebih baik dibanding model yang lebih kecil.

03.15 Cost Estimation untuk SDD Workflow

Cost adalah pertimbangan nyata yang sering dilebih-lebihkan. Estimasi kasar berikut menunjukkan biaya sesungguhnya untuk satu SDD session yang typical.

 1Claude Code (per session implement 1 fitur medium):
 2- Membaca spec + codebase context: ~10K tokens input
 3- Generate implementasi + test: ~5K tokens output
 4- Beberapa iterasi review: ~15K tokens total
 5- Estimasi cost: $0.15 - $0.50 per fitur
 6- Untuk 10 fitur/bulan: $1.5 - $5/bulan
 7
 8Cursor (subscription):
 9- $20/bulan per seat (Pro)
10- Unlimited AI usage
11- Worth it jika > 5 fitur/bulan dengan heavy AI usage

Angka ini jauh lebih kecil dari cost of bug — satu bug production yang serius bisa menghabiskan 8+ jam engineer time, dan dengan rate $100/jam itu setara $800 nilai waktu yang bisa dicegah.

03.16 Tool untuk Testing: Complement SDD Workflow

Setelah kode dihasilkan, kita butuh tools untuk verify bahwa implementasi sesuai spec. Stack testing berikut adalah yang kita pakai di Santekno Shop sepanjang seri.

1// Testing stack yang kita gunakan di Santekno Shop
2import (
3    "testing"
4    "github.com/stretchr/testify/suite"    // test suite organization
5    "github.com/stretchr/testify/assert"   // assertions
6    "github.com/stretchr/testify/require"  // fatal assertions
7    "github.com/golang/mock/gomock"         // mock generation
8)

Dengan gomock, kita bisa mengisolasi unit under test dari dependensi eksternal — dan mock itu sendiri di-generate otomatis oleh mockgen seperti berikut.

1# Generate mock dari interface
2mockgen -source=internal/domain/order/repository.go \
3        -destination=internal/domain/order/mock/repository_mock.go \
4        -package=mock_order

Mock yang tergenerate ini selalu sinkron dengan interface aslinya, sehingga test tidak mudah rapuh saat kontrak berubah. Terakhir, jalankan test dengan race detector dan ukur coverage lewat perintah berikut.

1# Selalu jalankan dengan -race untuk detect concurrent issue
2go test ./... -race -timeout 30s
3
4# Test coverage
5go test ./internal/usecase/... -coverprofile=coverage.out
6go tool cover -html=coverage.out

Flag -race wajib karena banyak bug SDD yang lolos review justru muncul di skenario konkuren — race detector menangkapnya sebelum sampai production.

03.17 Evolusi Tools: Apa yang Akan Berubah

Landscape ini bergerak sangat cepat — dan paruh pertama 2026 sudah mengonfirmasi beberapa arah:

Spec-first sudah mainstream: Spec Kit stabil, Kiro GA, dan pola “spec dulu, code menyusul” kini jadi default di tim yang serius dengan AI coding.

Multi-agent jadi nyata: Claude Code kini punya subagents dan orkestrasi bawaan — satu agent menulis spec, agent lain implementasi dan testing, berjalan paralel.

MCP jadi lem standar: Model Context Protocol dipakai lintas tool untuk menyambungkan AI ke data dan sistem internal — konteks tidak lagi terkunci di satu vendor.

Berikutnya — spec verification built-in: tools akan otomatis memverifikasi kode terhadap spec, tanpa script kustom seperti yang kita tulis di 03.13.

Tetapi satu hal yang tidak berubah: nilai dari spesifikasi yang ditulis dengan baik. Apapun tool-nya, AI yang punya spec yang jelas akan selalu menghasilkan kode yang lebih baik dari AI yang tidak punya spec.

03.18 Tips & Gotchas

💡 Tip 1: Mulai dengan satu tool saja — jangan coba semua tool sekaligus. Pilih satu (rekomendasi: Claude Code), kuasai selama sebulan, baru coba yang lain.

💡 Tip 2: CLAUDE.md adalah investasi satu kali, manfaat seumur proyek — luangkan 2-3 jam untuk menulis CLAUDE.md yang komprehensif. Investasi ini akan menghemat ratusan “explain again” di setiap sesi baru.

💡 Tip 3: Simpan prompt yang efektif sebagai snippet — ketika menemukan prompt yang menghasilkan output sangat baik, simpan sebagai snippet (VS Code snippets, atau file di docs/prompts/).

💡 Tip 4: Audit tool usage setiap bulan — cek: tool mana yang paling sering dipakai? Tool mana yang menghasilkan kode yang paling banyak di-reject? Ini feedback berharga untuk optimasi workflow.

⚠️ Gotcha 1: Tool baru bukan solusi untuk spec yang buruk — ganti tool tidak akan memperbaiki spec yang ambigu. Fix spec-nya dulu, baru evaluate apakah butuh ganti tool.

⚠️ Gotcha 2: Jangan bergantung pada satu vendor — struktur spec kamu (markdown files di git) harus independen dari tool. Jika Claude Code tutup besok, spec kamu masih bisa dipakai dengan Cursor atau Kiro.

⚠️ Gotcha 3: AI coding tools bisa menulis kode yang “terlihat benar” tapi logic-nya salah — tool yang lebih canggih bukan berarti butuh review lebih sedikit. Justru sebaliknya, semakin banyak kode yang dihasilkan, semakin penting review yang teliti.

⚠️ Gotcha 4: Perhatikan data privacy — kode kamu dikirim ke server AI provider. Pastikan tidak ada API key, credentials, atau data sensitif pelanggan yang masuk ke context yang dikirim ke AI.

03.19 Setup Checklist untuk Mulai

Sebelum lanjut ke artikel berikutnya, pastikan setup sudah siap. Checklist berikut memastikan Claude Code, struktur proyek, dan git setup sudah terpasang benar.

 1## Setup Checklist: SDD Tools
 2
 3### Claude Code
 4- [ ] Install: `npm install -g @anthropic-ai/claude-code`
 5- [ ] Configure API key: `claude config set api_key YOUR_KEY`
 6- [ ] Test: `claude "hello"` harus response
 7
 8### Project Structure
 9- [ ] Buat folder `specs/` di root project
10- [ ] Buat `specs/README.md` dengan panduan cara baca/tulis spec
11- [ ] Buat `specs/_templates/feature-spec.md`
12- [ ] Buat `CLAUDE.md` (template di artikel berikutnya)
13
14### Git Setup
15- [ ] Buat `.github/PULL_REQUEST_TEMPLATE.md` dengan kolom spec reference
16- [ ] Opsional: setup pre-commit hook untuk spec compliance check
17
18### Verifikasi
19- [ ] Buka Claude Code di root project Santekno Shop
20- [ ] Coba: "Baca CLAUDE.md dan jelaskan arsitektur proyek ini"
21- [ ] Claude harus bisa menjawab sesuai isi CLAUDE.md

Jika semua kotak sudah tercentang — terutama verifikasi terakhir di mana Claude bisa menjelaskan arsitektur dari CLAUDE.md — berarti fondasi tooling kamu sudah siap untuk seri ini.

03.20 Ringkasan

Ekosistem tools SDD di 2026 sudah cukup mature untuk production use:

Claude Code adalah primary tool pilihan kita — flexible, powerful, dan punya mekanisme CLAUDE.md yang sangat cocok untuk SDD.

GitHub Spec Kit adalah companion yang bagus jika butuh guided, opinionated workflow.

Cursor adalah alternatif terbaik jika prefer IDE experience vs terminal.

Kiro sudah GA — alternatif serius kalau tim kamu hidup di ekosistem AWS.

Yang paling penting bukan tool mana yang dipilih, tapi konsistensi dalam menggunakannya dengan spec sebagai titik mulai. Tool adalah enabler, bukan pengganti cara berpikir yang benar.

Di artikel berikutnya, kita akan setup fondasi paling penting dalam workflow kita: CLAUDE.md — memori proyek yang membuat AI selalu paham konteks tanpa perlu dijelaskan berulang-ulang di setiap sesi.