Setelah SDD Golang: Tools yang Lebih Dalam dan Masa Depan AI-Driven Development

Setelah SDD: Tools yang Lebih Dalam untuk Go Developer

Kamu sudah menempuh perjalanan panjang mempelajari Specification-Driven Development. Kamu sudah punya CLAUDE.md yang baik, spec yang terstruktur, test yang trace ke AC/EC, dan workflow tim yang solid. Pertanyaan besarnya sekarang: apa selanjutnya?

Artikel ini membahas golang AI driven development tools lanjutan — dimensi-dimensi yang lebih dalam dari AI-assisted Go development yang akan menjadi semakin penting dalam 1-2 tahun ke depan. SDD adalah fondasi, bukan tujuan akhir.

20.1 SDD Mastered: Tanda-Tanda yang Sudah Benar

Sebelum bicara “apa selanjutnya,” penting untuk tahu kapan SDD sudah benar-benar berjalan di tim kamu. Checklist berikut adalah indikator konkret yang bisa kamu cocokkan dengan kondisi tim saat ini.

 1✅ Tanda SDD sudah mature di tim kamu:
 2
 31. Developer tidak pernah tanya "bagaimana cara implement X?" 
 4   sebelum baca spec-nya dulu
 5
 62. Code review berfokus pada business logic dan architecture,
 7   bukan pada "kenapa return 409 bukan 422?"
 8
 93. Onboarding developer baru bisa produktif dalam 3-5 hari
10   karena spec + CLAUDE.md sudah cukup sebagai context
11
124. Bug report yang masuk bisa di-trace ke "AC mana yang miss" 
13   atau "EC mana yang tidak ter-handle"
14
155. Ketika ada pertanyaan "apakah ini sudah correct?",
16   jawabnya selalu "buka specnya"

Jika kelima tanda ini sudah tercapai, SDD di tim kamu sudah mature dan siap untuk naik ke level berikutnya yang dibahas di bawah. Jika belum, fokuskan energi untuk mencapai tanda-tanda ini dulu sebelum menambah kompleksitas baru.

20.2 Level Berikutnya: Observability-Driven Development

Di SDD, spec adalah source of truth untuk behavior. Di tingkat berikutnya, observability data menjadi umpan balik untuk spec — membuat proses menjadi circular alih-alih satu arah. Diagram alur berikut merangkum siklus tertutup itu.

1Spec → Implementasi → Production → Data → Update Spec

Alur di atas mengubah spec dari dokumen statis menjadi living document yang dikoreksi oleh realita production. Contoh Go berikut memperlihatkan bagaimana sebuah NFR di spec bertabrakan dengan data nyata dari Prometheus.

 1// NFR di spec:
 2// NFR-P2: p95 latency < 300ms untuk cancel order
 3
 4// Di production, Prometheus menunjukkan:
 5// cancel_order_duration_seconds{quantile="0.95"} = 0.847
 6// → Kita MISS NFR-P2!
 7
 8// Observability data → trigger spec review:
 9// "NFR-P2 di cancel-order.md tidak realistis dengan current architecture.
10//  Perlu either: optimize implementation ATAU update NFR target."

Perhatikan bahwa angka 847ms bukan opini — ia adalah bukti terukur yang memicu review spec. Untuk mendapatkan angka itu, kita menjalankan query Prometheus yang memverifikasi NFR secara langsung.

1# Prometheus query untuk verify NFR
2histogram_quantile(0.95, 
3  rate(cancel_order_duration_seconds_bucket[5m])) * 1000
4# Output: 847ms — miss NFR target of 300ms

Query ini menutup jarak antara “apa yang dijanjikan spec” dan “apa yang benar-benar terjadi.” Ketika ada gap, Claude Code bisa membantu menganalisis akar penyebabnya lewat prompt berikut.

 1Saya punya data production untuk cancel order:
 2- p50: 45ms ✅ 
 3- p95: 847ms ❌ (NFR target: 300ms)
 4- p99: 2100ms
 5
 6Stack trace dari slow requests:
 7[paste stack trace atau profiling data]
 8
 9Bantu analisis:
101. Apa kemungkinan penyebab p95 jauh lebih tinggi dari p50?
112. Bagian kode mana yang paling likely menjadi bottleneck?
123. Apakah ada yang bisa di-optimize tanpa mengubah behavior?

Dengan memberi AI data terukur dan bukan sekadar keluhan “lambat”, analisis yang dihasilkan jauh lebih tajam dan bisa langsung ditindaklanjuti menjadi optimasi atau revisi NFR.

20.3 Advanced Claude Code: Multi-Agent Workflow

Claude Code saat ini bekerja dalam single-agent mode. Masa depannya adalah multi-agent, di mana beberapa AI agent bekerja paralel untuk task berbeda. Cuplikan berikut memperlihatkan preview yang sudah bisa dilakukan hari ini dengan menjalankan beberapa sesi terminal sekaligus.

1# Terminal 1: Claude Code untuk implementasi
2claude --spec specs/order/create-order.md --task "implement usecase"
3
4# Terminal 2: Paralel — Claude Code untuk test generation
5claude --spec specs/order/create-order.md --task "generate tests for usecase"
6
7# Terminal 3: Paralel — Claude Code untuk documentation
8claude --spec specs/order/create-order.md --task "generate OpenAPI spec"

Pola tiga terminal ini mensimulasikan pembagian kerja: satu agent membangun, satu menulis test, satu mendokumentasikan — semua dari spec yang sama. Pendekatan yang lebih terprogram bisa memakai batch processing lewat goroutine seperti contoh berikut.

 1// tools/batch-spec-review/main.go
 2// Review multiple specs in parallel
 3
 4func main() {
 5    specs := []string{
 6        "specs/order/cancel-order.md",
 7        "specs/order/create-order.md",
 8        "specs/product/update-stock.md",
 9    }
10    
11    results := make(chan ReviewResult, len(specs))
12    
13    for _, spec := range specs {
14        go func(specPath string) {
15            result := reviewSpec(specPath)
16            results <- result
17        }(spec)
18    }
19    
20    for range specs {
21        result := <-results
22        printResult(result)
23    }
24}

Kode ini adalah pola fan-out/fan-in klasik Go: banyak spec di-review paralel lewat goroutine, hasilnya dikumpulkan lewat channel. Prinsip yang sama nanti akan menjadi fondasi orkestrasi multi-agent yang sesungguhnya.

20.4 Platform Engineering dengan AI: Internal Developer Platform

Di tim yang lebih mature, SDD berkembang menjadi Internal Developer Platform (IDP) yang di-power oleh AI. Perbandingan berikut menunjukkan bagaimana IDP tradisional bertransformasi ketika AI dimasukkan ke dalamnya.

1Traditional IDP:
2- CLI tools untuk scaffold service baru
3- Templates untuk common patterns
4- Documentation portal
5
6AI-Enhanced IDP:
7- "Create new microservice with auth and logging" → AI generates CLAUDE.md, boilerplate, initial spec template
8- "Add feature X to service Y" → AI reads existing spec, generates spec template dengan context yang sudah diisi
9- "What's the pattern for rate limiting?" → AI searches codebase + specs, shows examples

Perbedaan intinya: IDP tradisional memberi template statis, sedangkan AI-enhanced IDP menghasilkan artefak yang sudah terisi konteks proyek. Implementasi paling sederhana bisa dibangun hanya dengan sebuah shell script yang memanggil Claude API.

 1#!/bin/bash
 2# tools/ai-scaffold.sh
 3# Usage: ./ai-scaffold.sh "create cancel order feature for order service"
 4
 5PROMPT="$1"
 6CODEBASE_CONTEXT=$(cat CLAUDE.md specs/README.md)
 7
 8curl -X POST https://api.anthropic.com/v1/messages \
 9  -H "x-api-key: $ANTHROPIC_API_KEY" \
10  -H "Content-Type: application/json" \
11  -d "{
12    \"model\": \"claude-sonnet-4-20250514\",
13    \"max_tokens\": 4096,
14    \"system\": \"You are a platform engineering tool for Santekno Shop. Context: $CODEBASE_CONTEXT\",
15    \"messages\": [{\"role\": \"user\", \"content\": \"$PROMPT\n\nGenerate: spec template, CLAUDE.md additions, and task list.\"}]
16  }"

Perhatikan bahwa isi CLAUDE.md dan specs/README.md di-inject sebagai system context — inilah yang membuat output relevan dengan konvensi proyek, bukan boilerplate generik. Dari script sederhana ini, sebuah IDP internal bisa tumbuh secara bertahap.

20.5 Spec-Driven Testing: Beyond Unit Tests

SDD mendorong test yang trace ke AC/EC. Level berikutnya adalah property-based testing yang bersifat generatif dari spec — bukan menguji satu contoh, tapi ribuan kombinasi input. Contoh Go berikut memakai gopter untuk memverifikasi AC3 dan AC4 dari fitur cancel order.

 1// Menggunakan gopter (property-based testing)
 2// Dari spec AC4: CanBeCancelled hanya true jika dalam 30 menit
 3
 4func TestCanBeCancelled_PropertyBased(t *testing.T) {
 5    parameters := gopter.DefaultTestParameters()
 6    properties := gopter.NewProperties(parameters)
 7    
 8    // Property 1: Spec AC4 — order bisa cancel jika CreatedAt < 30 menit lalu
 9    properties.Property("PENDING order within 30 min is cancellable", 
10        prop.ForAll(
11            func(minutesAgo int) bool {
12                order := &Order{
13                    Status:    StatusPending,
14                    CreatedAt: time.Now().Add(-time.Duration(minutesAgo) * time.Minute),
15                }
16                if minutesAgo < 30 {
17                    return order.CanBeCancelled() == true
18                }
19                return order.CanBeCancelled() == false
20            },
21            gen.IntRange(0, 100), // test dari 0-100 menit
22        ),
23    )
24    
25    // Property 2: Spec AC3 — non-PENDING selalu tidak bisa cancel
26    properties.Property("Non-PENDING order is never cancellable",
27        prop.ForAll(
28            func(status string) bool {
29                if Status(status) == StatusPending {
30                    return true // skip PENDING
31                }
32                order := &Order{
33                    Status:    Status(status),
34                    CreatedAt: time.Now().Add(-1 * time.Minute),
35                }
36                return order.CanBeCancelled() == false
37            },
38            gen.OneConstOf("CONFIRMED", "SHIPPED", "DELIVERED", "CANCELLED"),
39        ),
40    )
41    
42    properties.TestingRun(t)
43}

Property-based test seperti ini jauh lebih powerful dari example-based test karena gopter secara otomatis mencoba banyak nilai (0-100 menit, semua status non-PENDING) dan menemukan edge case yang belum terpikir. Ketika sebuah properti gagal, gopter bahkan memberikan input minimal yang memicunya.

20.6 AI-Assisted Database Optimization

Setelah SDD mature, area berikutnya yang sering jadi fokus adalah performance — dan database biasanya menjadi tersangka utama. Prompt berikut menunjukkan cara memberi Claude Code data slow query yang lengkap agar analisisnya presisi.

 1Dari production, saya punya slow query log:
 2
 3Query: GetByIDAndUserID (cancel order)
 4Execution time: p95 = 120ms, p99 = 800ms
 5Rows scanned: ~50,000 (seharusnya 1 row)
 6
 7Current query:
 8SELECT id, user_id, status, total_amount_cents, created_at, updated_at
 9FROM orders
10WHERE id = $1 AND user_id = $2 AND deleted_at IS NULL
11
12EXPLAIN ANALYZE output:
13[paste EXPLAIN output]
14
151. Identifikasi kenapa query tidak pakai index
162. Suggest index yang lebih efektif
173. Apakah ada query rewrite yang lebih baik?
184. Buat migration yang safe (zero-downtime) untuk fix ini

Kunci prompt ini adalah menyertakan EXPLAIN ANALYZE dan angka rows scanned — tanpa data itu, AI hanya bisa menebak. Dengan konteks terukur, saran index atau query rewrite yang dihasilkan bisa langsung diuji terhadap production plan.

20.7 Governance AI: Automated ADR Generation

Architectural Decision Records (ADR) adalah dokumentasi keputusan arsitektur yang sering terlupakan ditulis. AI bisa membantu men-generate ADR dari diskusi atau code review lewat prompt terstruktur seperti berikut.

 1Kami baru memutuskan untuk menggunakan pgx/v5 sebagai database driver
 2daripada database/sql standar Go.
 3
 4Alasan diskusi:
 5- database/sql: generic, portable tapi kurang fitur PostgreSQL-specific
 6- pgx/v5: PostgreSQL native, lebih cepat, support batch operations
 7- Benchmark internal menunjukkan pgx 30% lebih cepat untuk write workload kita
 8
 9Generate ADR dalam format standar:
10- Title
11- Status (Accepted)
12- Context
13- Decision
14- Consequences (positive dan negative)
15- References
16
17Simpan sebagai: docs/adr/001-postgresql-driver.md

Dengan memberi AI konteks keputusan dan format target, ADR yang biasanya ditunda karena “tidak sempat menulis” bisa dihasilkan dalam hitungan detik — mengubah keputusan lisan menjadi jejak tertulis yang bisa dirujuk tim di masa depan.

20.8 Shift-Left Security dengan AI

Di level advanced, pertimbangan security masuk lebih awal dalam workflow, bukan setelah kode jadi. Prompt threat modeling berikut menempatkan analisis keamanan sebelum implementasi endpoint dimulai.

 1Sebelum implementasi create order endpoint, lakukan security threat modeling:
 2
 3Endpoint: POST /api/v1/orders
 4Auth: JWT Bearer
 5Input: { cart_id, shipping_address_id }
 6
 7Identifikasi:
 81. OWASP Top 10 yang relevant (injection, broken auth, etc.)
 92. Business logic abuse (order bombing, inventory manipulation)
103. Data exposure risk (PII dalam response)
11
12Untuk setiap threat:
13- Severity (High/Medium/Low)
14- Mitigation yang diperlukan
15- Apakah mitigasi ini sudah ada di spec?
16- Jika belum, tambahkan sebagai NFR
17
18Output format: Threat Model Report untuk dimasukkan ke spec NFR section.

Yang membuat prompt ini efektif adalah instruksi terakhir: setiap ancaman yang belum termitigasi diubah menjadi NFR di spec. Dengan begitu, keamanan bukan checklist terpisah, melainkan bagian dari kontrak yang akan diverifikasi test.

20.9 AI-Generated Architecture Documentation

Setelah beberapa bulan SDD, dokumentasi arsitektur yang biasanya cepat basi bisa di-generate otomatis dari spec dan kode. Prompt berikut meminta AI merangkai empat artefak dokumentasi sekaligus dari folder specs/ dan internal/.

 1Dari specs/ folder dan internal/ folder, generate:
 2
 31. Architecture overview (Mermaid diagram)
 4   - Layer diagram (domain → usecase → repository → delivery)
 5   - Service dependency diagram
 6   
 72. Domain model (ERD dari entity files)
 8   - Order, OrderItem, Product, User relationships
 9   
103. API catalog (table dari semua OpenAPI specs)
11   
124. Decision log (summary dari semua ADR)
13
14Output: docs/architecture/README.md yang bisa di-render di GitHub

Karena sumbernya adalah kode dan spec yang selalu up-to-date, dokumentasi hasil generate ini jauh lebih kecil risikonya untuk basi dibanding dokumen yang ditulis manual sekali lalu dilupakan.

20.10 Future: Kiro dan Tools yang Berkembang

Di dunia AI-coding tools yang berkembang cepat, ada beberapa tools yang worth diperhatikan sebagai pelengkap atau alternatif Claude Code. Ringkasan berikut memetakan posisi masing-masing.

 1Kiro (dari Amazon):
 2- Steering files (YAML-based) sebagai versi lain dari CLAUDE.md
 3- Built-in spec management dengan AI review
 4- Tighter IDE integration
 5
 6Cursor dengan Custom Rules:
 7- .cursorrules sebagai analog CLAUDE.md
 8- Project-level instruction sets
 9
10Gemini Code Assist:
11- Integrasi dengan Google Cloud ecosystem
12- Useful jika stack di Google Cloud

Meski nama dan format tiap tool berbeda, benang merahnya sama — dan prinsip inilah yang perlu kamu pegang saat mengevaluasi tool baru mana pun.

Spec-first, konvensi yang explicit, dan iterasi yang terukur adalah prinsip yang agnostic terhadap tool. Siapapun yang menyediakan “the context,” prinsipnya sama.

20.11 Evolusi CLAUDE.md: Living Architecture Document

CLAUDE.md yang mature tidak hanya berisi conventions — dia menjadi living architecture document yang merekam denyut proyek. Template berikut menunjukkan bentuk CLAUDE.md yang sudah berevolusi jauh melampaui daftar aturan.

 1# CLAUDE.md v2.0 — Santekno Shop
 2
 3## Quick Stats
 4- Go version: 1.22+
 5- Services: 8 (order, product, user, payment, notification, analytics, search, admin)
 6- Daily active users: ~500K
 7- Peak QPS: 10K (flash sale)
 8
 9## Architecture Philosophy
10
11"We build for correctness first, performance second. 
12Spec-first development ensures correctness. Profiling ensures performance."
13— From ADR-000 (founding principles)
14
15## Known Performance Characteristics
16- p50 latency create order: 45ms
17- p95 latency create order: 180ms
18- p99 latency cancel order: 250ms
19(Updated: 2025-07-01, per monitoring dashboard)
20
21## Current Tech Debt
22| Debt | Impact | Priority | Tracked |
23|------|--------|----------|---------|
24| pgx/v5 upgrade to v6 | Medium | Low | JIRA-890 |
25| Remove deprecated CartService | High | Medium | JIRA-891 |
26| Migrate to slog from logrus (product service) | Low | Low | JIRA-892 |
27
28## Architecture Evolution Log
29[brief history of major architecture changes]

Perhatikan bagian Quick Stats, performance characteristics, dan tech debt — informasi ini membuat AI (dan developer baru) langsung paham skala dan kondisi nyata sistem, bukan sekadar aturan idealnya. CLAUDE.md seperti ini menjadi peta hidup, bukan monumen statis.

20.12 Measuring SDD ROI

Untuk meyakinkan stakeholder bahwa SDD layak dilanjutkan, kamu perlu angka before-after yang konkret. Template metrik berikut membandingkan kondisi sebelum dan sesudah enam bulan SDD.

 1## SDD ROI Metrics — Santekno Shop (Q3 2025)
 2
 3### Before SDD (Q1 2025)
 4- Avg bugs per feature: 2.3
 5- Avg code review rounds: 2.8
 6- Avg onboarding time: 3 minggu
 7- Spec coverage (tests to requirements): ~30%
 8- Production incidents dari spec drift: 3 per bulan
 9
10### After SDD (Q3 2025, 6 months later)
11- Avg bugs per feature: 0.7 (-70%)
12- Avg code review rounds: 1.4 (-50%)
13- Avg onboarding time: 5 hari (-76%)
14- Spec coverage: 87%
15- Production incidents dari spec drift: 0 per bulan
16
17### Investment vs Return
18Investment: ~20% overhead per developer sprint
19Return:
20- 70% reduction in post-release bugs
21- 50% faster code review cycles
22- 3x faster onboarding
23- 0 spec-drift incidents in production

Angka-angka ini menceritakan trade-off yang jujur: SDD menambah sekitar 20% overhead per sprint, tapi menukarnya dengan 70% pengurangan bug dan onboarding tiga kali lebih cepat. Bagi stakeholder, inilah bahasa yang paling meyakinkan.

20.13 SDD untuk Non-Go Projects

Prinsip SDD tidak terbatas pada Go — kerangka yang sama berlaku lintas bahasa. Untuk Node.js/TypeScript, kamu menulis CLAUDE.md dengan konvensi TypeScript, spec yang merujuk Zod schema, dan Jest tests yang trace ke spec. Untuk Python/FastAPI, CLAUDE.md berisi konvensi Python, spec merujuk Pydantic model, dan pytest memakai spec markers. Untuk Kotlin/Spring, CLAUDE.md memuat idiom Kotlin dan spec dipetakan ke JUnit test.

Yang membuat semua ini konsisten adalah empat core principle yang berlaku di mana saja:

1. Spec-first (tulis spec sebelum kode)
2. Test dari spec (setiap AC = test)
3. AI dengan context (CLAUDE.md equivalent)
4. Spec compliance check (sebelum merge)

Tool dan sintaksnya berbeda, tapi disiplinnya identik — inilah alasan SDD layak dipelajari sebagai keterampilan yang portable, bukan trik khusus satu bahasa.

20.14 Komunitas dan Resources

Untuk terus berkembang di AI-driven Go development, kamu tidak perlu jalan sendirian. Di sisi komunitas, ada Gophers Slack (channel #claude-code dan #ai-tools), subreddit r/golang, serta meetup Go lokal yang bisa dicari di meetup.com dengan kata kunci “Golang Indonesia”.

Di sisi resources, tiga sumber ini layak di-bookmark: anthropic.com/docs untuk dokumentasi Claude Code yang selalu update, github.com/anthropics/anthropic-cookbook untuk pola AI engineering, dan go.dev/blog untuk update resmi Go. Untuk pemahaman yang lebih dalam, paper “Specification-Driven Development”, “Large Language Models for Code”, dan “Constitutional AI” memberikan fondasi konseptual yang berguna.

Menggabungkan komunitas dan resources ini memastikan kamu tetap update di bidang yang bergerak sangat cepat — dan bisa berkontribusi balik ketika menemukan pola yang lebih baik.

20.15 Roadmap Personal untuk Go Developer

Agar perkembangan tidak acak, ada baiknya memetakan roadmap belajar per kuartal. Contoh roadmap berikut menyusun perjalanan dari SDD mastery hingga observability-driven development.

 1## Go Developer AI Roadmap (2025-2026)
 2
 3### Quarter 1: SDD Mastery
 4- ✅ CLAUDE.md setup
 5- ✅ Spec writing dan review
 6- ✅ Test dari spec
 7- ✅ Code review dengan AI
 8- Target: 100% fitur baru punya spec
 9
10### Quarter 2: Advanced Tooling
11- [ ] Property-based testing (gopter)
12- [ ] Contract testing (Pact)
13- [ ] AI-assisted performance analysis
14- Target: 0 NFR violations di production
15
16### Quarter 3: Platform Engineering
17- [ ] Internal developer platform prototype
18- [ ] AI-generated ADRs
19- [ ] Multi-service spec governance
20- Target: Onboarding < 3 hari untuk developer baru
21
22### Quarter 4: Observability-Driven
23- [ ] Spec update loop dari production data
24- [ ] AI-assisted incident post-mortem
25- [ ] Predictive spec violation detection
26- Target: Proactive spec maintenance, bukan reaktif
27```

Roadmap ini sengaja bertingkat: setiap kuartal membangun di atas fondasi kuartal sebelumnya, dengan target terukur yang bisa dijadikan bahan evaluasi. Sesuaikan tempo dan urutannya dengan kebutuhan tim kamu.

20.16 Filosofi untuk AI-Native Engineering

Di balik semua tools dan teknik, penting untuk merefleksikan apa yang sebenarnya berubah dengan AI-assisted development — dan apa yang tidak. Yang berubah adalah kecepatan eksekusi yang meningkat drastis, first draft spec/kode/test yang bisa dihasilkan dalam menit, serta context yang dulu harus disimpan di kepala kini bisa di-externalkan ke CLAUDE.md. Yang tidak berubah adalah engineering judgment, business understanding, code review, dan accountability — kamu tetap yang sign-off kode ke production.

Untuk menjaga keseimbangan itu, framework mental berikut membantu memetakan di mana AI kuat dan di mana ia lemah.

 1AI adalah:
 2✅ Sangat baik dalam eksekusi keputusan yang sudah jelas
 3✅ Sangat baik dalam finding pattern dan inconsistency
 4✅ Sangat baik dalam generating boilerplate dari template
 5✅ Sangat baik dalam cross-referencing dokumen
 6
 7AI kurang baik dalam:
 8❌ Memahami business context yang implicit
 9❌ Mengetahui konvensi tak tertulis dalam tim
10❌ Menilai trade-off yang melibatkan political dan organizational factors
11❌ Mengetahui apa yang "benar" ketika spec ambigu
12
13Kamu yang tahu hal-hal yang AI tidak tahu. Itulah mengapa kamu masih diperlukan.

Peta ini menjelaskan mengapa SDD bekerja: dengan menuliskan spec yang jelas, kamu mengubah keputusan ambigu (kelemahan AI) menjadi keputusan eksplisit (kekuatan AI). Kamu tetap driver-nya; AI adalah akseleratornya.

20.17 Surat untuk Go Developer yang Membaca Ini

Setelah menempuh seluruh topik ini, ada satu pesan yang ingin saya tinggalkan.

SDD bukan tentang AI. AI adalah tools yang membuat SDD lebih efisien. SDD adalah tentang clarity — kejelasan tentang apa yang dibangun, kenapa, dan bagaimana memverifikasinya.

Specification-driven development bukan workflow baru — developer terbaik sudah melakukan ini sejak dulu. Perbedaannya, sekarang ada tools yang membuat proses ini lebih cepat, lebih konsisten, dan lebih accessible untuk seluruh tim. Empat hal yang perlu kamu ingat: spec yang baik adalah investasi bukan overhead; test yang trace ke spec adalah dokumentasi yang executable; AI adalah pair programmer yang sangat produktif asalkan kamu yang drive; dan tooling akan terus berubah tapi prinsip tetap sama.

Santekno Shop dalam contoh-contoh ini adalah fiktif, tapi masalahnya nyata — e-commerce Indonesia, Golang untuk high-traffic, clean architecture, dan kebutuhan scale dengan tim yang terus bertumbuh. Semoga apa yang kita bahas berguna. Build something great.

20.18 Tips & Gotchas Final

💡 Tip 1: Jangan berhenti di SDD sebagai tujuan akhir

SDD adalah fondasi yang memungkinkan iterasi lebih cepat. Gunakan stabilitas itu untuk explore: property-based testing, platform engineering, observability-driven development.

💡 Tip 2: Benchmark sebelum optimasi

Ketika SDD sudah solid dan ingin pindah ke performance work, selalu benchmark dulu. Intuisi tentang bottleneck sering salah.

💡 Tip 3: Stay skeptical terhadap AI tools baru

Ada banyak “next best AI coding tool” yang muncul setiap bulan. Evaluasi berdasarkan prinsip: apakah ini mendukung spec-first workflow? apakah ini meningkatkan atau menurunkan visibility ke behavior yang di-specify?

💡 Tip 4: Teach what you learn

Menulis tentang apa yang kamu pelajari — blog post, internal documentation, talk di meetup — memperkuat pemahaman dan membangun reputasi.

⚠️ Gotcha 1: AI fatigue adalah nyata

Terlalu bergantung pada AI untuk setiap keputusan kecil bisa mengurangi kemampuan problem-solving kamu sendiri. Gunakan AI untuk accelerate, bukan untuk replace thinking.

⚠️ Gotcha 2: Context drift di long-running projects

Setelah 1-2 tahun, CLAUDE.md mungkin sudah tidak akurat lagi karena codebase berevolusi tapi file tidak di-update. Schedule regular CLAUDE.md audit.

⚠️ Gotcha 3: Jangan biarkan SDD menjadi birokrasi

Jika SDD di tim kamu terasa lebih seperti compliance exercise daripada genuine value, evaluasi dan simplify. Proses yang menghalangi delivery adalah proses yang perlu direformasi.

⚠️ Gotcha 4: Vendor lock-in untuk AI tools

Claude Code sangat efektif hari ini. Pastikan prinsip (spec-first, test dari spec) tidak terikat ke tool tertentu — sehingga jika ada tool yang lebih baik, kamu bisa migrate tanpa kehilangan workflow.

20.19 Satu Langkah Konkret Setelah Artikel Ini

Jika kamu hanya bisa melakukan satu hal setelah membaca topik ini, lakukan ini: buat CLAUDE.md untuk proyek utama kamu hari ini. Bukan yang sempurna — cukup yang menangkap tech stack dengan versi, tiga architecture rules terpenting, naming convention yang konsisten, dan satu spec rule. Skrip berikut memberikan starter yang bisa langsung kamu jalankan.

 1# Start now
 2cd /path/to/your-project
 3cat > CLAUDE.md << 'EOF'
 4# CLAUDE.md — [Your Project Name]
 5
 6## Tech Stack
 7[Language and version]
 8[Main frameworks and versions]
 9
10## Architecture Rules
111. [Most important rule]
122. [Second rule]
133. [Third rule]
14
15## Spec Rule
16Every new feature needs a spec at specs/[feature].md BEFORE implementation.
17If no spec exists: create one first.
18EOF
19
20git add CLAUDE.md
21git commit -m "docs: add CLAUDE.md for AI-assisted development context"

Satu file, satu commit — dan itulah awal dari perjalanan SDD kamu. Iterasi dari titik itu; kesempurnaan datang belakangan, yang penting kamu mulai hari ini.

20.20 Ringkasan Topik dan Penutup

Kita sudah menempuh perjalanan panjang dalam topik pertama ini. Rangkuman berikut memetakan keempat bagiannya agar kamu punya peta mental yang utuh.

 1Part 1 — Fondasi Mindset:
 2Mengapa SDD, spesifikasi sebagai source of truth, ekosistem tools, dan CLAUDE.md.
 3
 4Part 2 — Menulis Spesifikasi Efektif:
 5Anatomi spec, prompt engineering, pola interview yourself, OpenAPI, dan NFR.
 6
 7Part 3 — Dari Spec ke Kode:
 8Plan Mode, task breakdown, code generation, unit test, code review, dan refactoring.
 9
10Part 4 — SDD di Skala Tim:
11Microservice contracts, spec drift detection, SDD di tim, studi kasus, dan apa selanjutnya.

Keempat bagian di atas sebenarnya bermuara pada satu gagasan yang bisa dirangkum dalam satu kalimat.

SDD adalah disiplin mengekspresikan apa yang ingin dibangun dengan cukup jelas sehingga AI bisa membantu membangunnya, dan cukup jelas sehingga tim bisa memverifikasinya.

Terima kasih sudah mengikuti topik ini sampai tuntas. Fondasi SDD yang sudah kamu kuasai kini menjadi pijakan untuk melangkah ke ekosistem tool yang lebih spesifik. Di topik berikutnya, kita akan menyelami salah satu tool SDD-native yang paling menjanjikan secara mendalam.