Spec Kit sebagai Kontrak AI Pipeline Golang: Bridge ke Topik Berikutnya

Spec Output sebagai Kontrak dalam Pipeline AI

Menjadikan output Spec Kit sebagai kontrak AI pipeline Golang adalah lompatan perspektif terakhir sekaligus jembatan menuju apa yang datang berikutnya. Ini artikel penutup Topik 2 — dan di sini kita lihat bagaimana spec yang sudah kita buat bukan hanya dokumentasi pasif, tetapi juga kontrak formal yang bisa dikonsumsi oleh AI pipeline yang lebih complex.

Dari LLM-powered validation hingga RAG dan AI agents, spec yang terstruktur menjadi fondasi mesin — bukan sekadar bacaan manusia.

20.1 Pergeseran Perspektif: Spec sebagai Machine-Readable Contract

Selama Topik 1 dan 2, kita membuat spec untuk dibaca manusia dan dikonsumsi Claude Code. Tapi ada perspektif yang lebih powerful: spec yang terstruktur adalah machine-readable contract. Tabel berikut memetakan tiap output Spec Kit ke sistem AI yang bisa mengonsumsinya.

1Spec Kit Output                     Consumed By
2─────────────────────────────────────────────────
3spec.md (ACs, ECs)          →       AI validator
4plan.md (architecture)      →       AI code reviewer
5tasks.md (work units)       →       AI orchestrator
6constitution.md (rules)     →       AI guardrails
7.specify/contracts/         →       AI schema validator

Pemetaan ini adalah inti seluruh artikel: setiap artefak yang kamu hasilkan dari workflow SDD ternyata punya “konsumen” AI di pipeline yang lebih lanjut — sebuah nilai tambah yang tidak kamu bayar ekstra untuk mendapatkannya.

20.2 Spec sebagai Input ke LLM-Powered Validation

Setelah implementasi, spec bisa menjadi input untuk AI validator yang lebih sophisticated. Kode Go berikut memperlihatkan sebuah SpecValidator yang mengirim AC dari spec sebagai ground truth ke LLM untuk memvalidasi perilaku endpoint.

 1// Contoh: AI validator yang menggunakan spec sebagai ground truth
 2// (preview Topik 6: LLM-Powered Applications)
 3
 4package validator
 5
 6type SpecValidator struct {
 7    anthropicClient *anthropic.Client
 8    spec            Spec
 9}
10
11func (v *SpecValidator) ValidateEndpointBehavior(
12    ctx context.Context,
13    endpoint string,
14    request, response json.RawMessage,
15) (ValidationResult, error) {
16
17    // Kirim spec AC sebagai context ke LLM
18    prompt := fmt.Sprintf(`
19        Given this spec for endpoint %s:
20        %s
21
22        Given this request:
23        %s
24
25        And this response:
26        %s
27
28        Does this response comply with all ACs?
29        Return JSON: {"compliant": bool, "violations": [{"ac": "AC{n}", "reason": "..."}]}
30    `, endpoint, v.spec.ACsForEndpoint(endpoint), request, response)
31
32    result := v.anthropicClient.Complete(ctx, prompt)
33    return parseValidationResult(result)
34}

Pola ini menaikkan level validasi dari “cocokkan string” menjadi “apakah response secara semantik memenuhi maksud AC?” — sesuatu yang hanya mungkin ketika spec menjadi input formal ke LLM.

20.3 Spec sebagai OpenAPI Contract

spec.md juga bisa di-transform menjadi OpenAPI spec yang machine-readable. Perintah berikut meng-export fitur menjadi openapi.yaml beserta daftar kegunaannya di downstream.

1# Convert spec ke OpenAPI (akan dibahas lebih detail di Topik 3)
2specify export --feature product-review --format openapi
3
4# Output: .specify/features/product-review/openapi.yaml
5# Yang menjadi:
6# - Source of truth untuk API documentation
7# - Input untuk API gateway configuration
8# - Schema untuk request/response validation middleware
9# - Contract untuk consumer-driven contract testing

Sekali di-export, satu spec.md melahirkan banyak turunan — dokumentasi API, konfigurasi gateway, hingga contract testing — semuanya berangkat dari sumber kebenaran yang sama.

20.4 Tasks sebagai Orchestration Input

tasks.md bisa menjadi input untuk AI orchestrator yang lebih autonomous. Kode Go berikut menunjukkan orchestrator yang mengidentifikasi grup task paralel lalu mengeksekusinya secara concurrent dengan errgroup.

 1// Preview Topik 8: AI Agents + MCP
 2// Tasks dari spec kit → AI agent yang execute secara parallel
 3
 4type SpecKitOrchestrator struct {
 5    tasks      []Task
 6    aiClient   *anthropic.Client
 7    toolClient *mcp.Client
 8}
 9
10func (o *SpecKitOrchestrator) Execute(ctx context.Context) error {
11    // Identify parallel tasks
12    parallelGroups := o.identifyParallelGroups()
13
14    for _, group := range parallelGroups {
15        // Execute parallel tasks concurrently
16        g, ctx := errgroup.WithContext(ctx)
17        for _, task := range group {
18            task := task
19            g.Go(func() error {
20                return o.executeTask(ctx, task)
21            })
22        }
23        if err := g.Wait(); err != nil {
24            return fmt.Errorf("parallel group failed: %w", err)
25        }
26    }
27    return nil
28}

Karena tasks.md sudah memetakan dependensi antar task, orchestrator bisa mengeksekusi task independen secara paralel dengan aman — struktur spec langsung menjadi rencana eksekusi concurrent.

20.5 Constitution sebagai AI Guardrails

constitution.md bisa menjadi guardrails yang menempel di setiap LLM call. Fungsi Go berikut menyuntikkan isi constitution ke dalam system prompt sebagai constraint absolut untuk semua kode yang di-generate.

 1// System prompt dari constitution.md
 2func buildSystemPrompt(constitution string) string {
 3    return fmt.Sprintf(`
 4        You are a Go developer working on this project.
 5
 6        ABSOLUTE CONSTRAINTS (from constitution.md):
 7        %s
 8
 9        You MUST follow these constraints in ALL code you generate.
10        If asked to violate them, explain why you cannot and suggest alternatives.
11    `, constitution)
12}
13
14// Setiap Claude Code session menggunakan ini sebagai foundation

Dengan constitution disuntik sebagai constraint absolut, aturan arsitektur proyek diterapkan konsisten di setiap generasi kode — guardrail yang berjalan otomatis, bukan bergantung pada ingatan developer.

20.6 Spec sebagai RAG Document

Spec yang terstruktur sangat ideal untuk RAG (Retrieval Augmented Generation). Kode Go berikut mengindeks semua file spec ke vector store lalu menjawab pertanyaan dengan konteks spec yang relevan.

 1// Preview Topik 7: RAG + Vector DB
 2// spec.md, plan.md, constitution.md → vector store → AI assistant yang "tahu" codebase
 3
 4type SpecRAGSystem struct {
 5    vectorStore *pgvector.Store
 6    embedder    *anthropic.Embedder
 7}
 8
 9func (s *SpecRAGSystem) IndexSpec(ctx context.Context, specDir string) error {
10    // Index semua spec files ke vector store
11    specs, _ := filepath.Glob(filepath.Join(specDir, "**/*.md"))
12    for _, spec := range specs {
13        content, _ := os.ReadFile(spec)
14        embedding, _ := s.embedder.Embed(ctx, string(content))
15        s.vectorStore.Insert(ctx, spec, embedding, string(content))
16    }
17    return nil
18}
19
20func (s *SpecRAGSystem) AskAboutSpec(ctx context.Context, question string) (string, error) {
21    // Retrieve relevant specs berdasarkan question
22    embedding, _ := s.embedder.Embed(ctx, question)
23    relevant := s.vectorStore.Search(ctx, embedding, 5)
24
25    // Jawab question dengan context dari relevant specs
26    return s.answerWithContext(ctx, question, relevant)
27}

Dengan spec terindeks di vector store, kamu mendapatkan AI assistant yang benar-benar “tahu” codebase-mu — pertanyaan seperti “kenapa fitur X didesain begini?” bisa dijawab dari spec, bukan tebakan.

20.7 Event Contracts sebagai Schema Registry

Folder .specify/contracts/ bisa menjadi source of truth untuk skema Kafka. Kode Go berikut memvalidasi payload event terhadap contract sebelum di-publish, sehingga event yang tidak sesuai gagal lebih awal.

 1// Event contract dari spec kit → schema registry → validation di producer/consumer
 2
 3func ValidateEvent(event OrderCancelled, contractPath string) error {
 4    contract, _ := os.ReadFile(contractPath)
 5    schema := parseContractSchema(contract)
 6
 7    // Validate event payload against schema
 8    return schema.Validate(event)
 9}
10
11// Jika event tidak sesuai contract → fail fast sebelum publish ke Kafka

Menjadikan contract sebagai gerbang publish menerapkan prinsip fail-fast di layer event: skema yang tercatat di spec mencegah event rusak menyebar ke seluruh sistem event-driven.

20.8 Ringkasan Topik 2: Apa yang Sudah Dipelajari

Kita sudah cover semua 20 artikel Topik 2, yang bisa dikelompokkan menjadi empat bagian besar:

Part 1 (Artikel 1-4): Setup dan Pengenalan

• Apa itu Spec Kit dan posisinya di SDD ecosystem
• Instalasi dan konfigurasi untuk Golang project
• Anatomy .specify/ folder
• Integrasi dengan Claude Code

Part 2 (Artikel 5-10): Enam Perintah Inti

• constitution, specify, clarify, plan, tasks, implement
• Setiap perintah dengan contoh production Golang

Part 3 (Artikel 11-15): Workflow Nyata

• Studi kasus CRUD API end-to-end
• Branching strategy dan Git workflow
• CLAUDE.md update otomatis
• Debugging spec deviation

Part 4 (Artikel 16-20): Skala dan Integrasi

• Tim collaboration dan onboarding
• Monorepo Go
• Audit otomatis sebagai continuous validation
• GitHub Actions integration
• Spec sebagai AI pipeline contract (artikel ini)

Empat bagian ini membentuk kurva yang jelas: dari “apa itu Spec Kit” hingga “spec sebagai fondasi AI pipeline” — sebuah perjalanan dari tooling ke arsitektur.

20.9 Perjalanan: Dari Spec Kit ke AI Pipeline yang Lebih Dalam

Untuk melihat gambaran besar, penting memahami posisi Topik 2 dalam keseluruhan seri. Diagram berikut memetakan bagaimana setiap topik membangun di atas yang sebelumnya, dengan spec sebagai benang merahnya.

 1Topik 1: SDD + Claude Code
 2  ↓ Mindset: spec-first development
 3
 4Topik 2: GitHub Spec Kit (← kita sekarang)
 5  ↓ Tooling: otomasi SDD workflow
 6  ↓ Output: structured spec, plan, tasks, audit trail
 7
 8Topik 3: AI Coding Tools Comparison
 9  ↓ Broadening: Claude Code vs Cursor vs Copilot vs Kiro
10
11Topik 4: AI-Assisted DevOps
12  ↓ Pipeline: spec-driven CI/CD, quality gates
13
14Topik 5: E2E SDD Project
15  ↓ Integration: full project dengan semua tools
16
17Topik 6: LLM-Powered Apps    ← spec sebagai contract untuk AI features
18Topik 7: RAG + Vector DB      ← spec sebagai knowledge base
19Topik 8: AI Agents + MCP      ← tasks sebagai agent orchestration input
20Topik 9: LLMOps               ← spec sebagai observability contract
21Topik 10: AI at Scale         ← spec sebagai system contract

Perhatikan bahwa spec muncul di setiap lapisan — dari mindset di Topik 1 hingga system contract di Topik 10 — menegaskan bahwa investasi menulis spec yang baik berbuah sepanjang seri.

20.10 Key Takeaways dari Topik 2

1. Spec Kit adalah multiplier, bukan replacement

Spec Kit mengotomasi eksekusi SDD — bukan menggantikan kemampuan berpikir. Kamu masih perlu memahami domain, menjawab pertanyaan bisnis, dan me-review output.

2. Enam perintah = satu pipeline

constitution → specify → clarify → plan → tasks → implement bukan enam tools terpisah, melainkan satu pipeline yang kohesif. Melewati satu langkah mengurangi value keseluruhan.

3. Audit adalah safety net, bukan afterthought

specify audit setelah setiap implementasi mengubah spec dari dokumentasi pasif menjadi test aktif — perbedaan antara “kita sudah tulis spec” dan “spec selalu terpenuhi”.

4. Git history adalah audit trail

14 commits per feature, masing-masing traceable ke spec dan task, memberi visibility yang tidak ada di single commit “feature/SHOP-789”.

5. Spec Kit scale dengan tim

Dari solo developer hingga tim 30+ orang, framework constitution + shared templates + CI enforcement tetap bekerja — hanya prosesnya yang disesuaikan.

20.11 Tips Final untuk Spec Kit Journey

Mulai kecil: satu fitur dengan Spec Kit, bukan langsung seluruh backlog.

Constitution adalah investment: 2-3 jam menulis constitution yang baik menghemat ratusan jam koreksi ke depannya.

Audit early, audit often: jangan tunggu PR untuk menjalankan audit — jalankan setelah setiap task selesai.

Update CLAUDE.md setelah setiap feature: 15 menit investment mencegah drift yang memengaruhi semua feature berikutnya.

Embrace deviation: ketika audit menemukan deviation, itu adalah informasi berharga tentang spec yang ambigu, context yang kurang, atau edge case yang belum ter-address.

20.12 Apa Selanjutnya?

Di Topik 3, kita akan memperluas horizon: tidak hanya Claude Code, tapi seluruh ekosistem AI coding tools untuk Golang developer di 2026 — Cursor, GitHub Copilot, AWS Kiro, Windsurf, dan bagaimana semuanya bekerja bersama (atau bersaing) dalam satu workflow.

Spec Kit yang kita pelajari di Topik 2 akan menjadi foundation — semua tools yang dibandingkan di Topik 3 akan dievaluasi dari perspektif “seberapa baik mereka mendukung SDD workflow?”

20.13 Tips & Gotchas Final

💡 Tip 1: Document spec evolution — simpan version history spec di git. Ketika requirement berubah bulan depan, kamu bisa lihat mengapa keputusan awal dibuat.

💡 Tip 2: Spec sebagai onboarding untuk AI tools lain — ketika berganti dari Claude Code ke tool lain, spec tetap valid. constitution.md + spec.md + plan.md bisa dikonsumsi oleh Claude, Cursor, maupun Copilot — format yang tool-agnostic.

💡 Tip 3: Celebrate spec quality — ketika spec audit score 95+ atau coverage 90%+, itu achievement yang layak di-share di tim. Positive reinforcement mendorong adoption.

💡 Tip 4: Spec Kit adalah journey, bukan destination — workflow kamu akan terus berkembang; constitution.md minggu 1 berbeda dengan constitution.md bulan ke-6, dan itu bagus.

⚠️ Gotcha Final: Jangan over-spec — tidak semua fitur butuh spec 20-section. Task “show me X” yang selesai dalam 30 menit tidak butuh full speckit workflow. Pragmatisme adalah kunci.

20.14 Spec Kit Maturity Levels

Untuk mengukur di mana posisimu, ada baiknya memetakan tingkat kematangan pemakaian Spec Kit. Diagram berikut menyusun lima level dari basic usage hingga menjadi fondasi AI pipeline.

 1Level 1: Basic Usage
 2- Menjalankan 6 perintah secara sequential
 3- Spec ditulis, kode dihasilkan
 4- Tidak ada audit atau enforcement
 5
 6Level 2: Workflow Integration
 7- Spec Kit jadi bagian dari workflow standar
 8- specify audit dijalankan sebelum PR
 9- Constitution.md ada dan diikuti
10
11Level 3: Team Adoption
12- Semua developer menggunakan Spec Kit
13- CI enforcement (spec audit di GitHub Actions)
14- CLAUDE.md selalu up-to-date
15
16Level 4: Organization Scale
17- Shared templates untuk tipe fitur
18- Cross-team spec review process
19- Metrics tracking dan retrospektif berbasis data
20
21Level 5: AI Pipeline Foundation ← ini tujuan jangka panjang
22- Spec sebagai machine-readable contract
23- Audit sebagai continuous validation dalam AI pipeline
24- Spec Kit terintegrasi dengan LLM-powered validation

Sebagian besar tim realistis menetap di Level 2-3; Level 5 adalah tujuan jangka panjang yang justru menjadi tema topik-topik AI berikutnya di seri ini.

20.15 Community dan Contribution

Spec Kit adalah open source, dan kontribusi dari komunitas Go akan membuatnya lebih baik untuk semua. Perintah berikut menunjukkan beberapa cara berkontribusi — dari melaporkan issue hingga menyumbang template Go-specific.

 1# Laporkan bug atau feature request
 2gh issue create --repo github/spec-kit --title "Support for Indonesian language in constitution"
 3
 4# Contribute Go-specific templates
 5git clone github.com/github/spec-kit
 6# Add template di: templates/go/crud-api.md
 7# Add examples di: examples/go/
 8
 9# Share your constitution.md
10# Community repo: github.com/spec-kit-community/constitutions

Menyumbang template dan contoh Go-specific memberi manfaat berlipat: kontribusimu menghemat waktu setup ratusan developer Go lain yang memakai Spec Kit.

20.16 Final Comparison: Before and After Spec Kit

Cara paling gamblang melihat nilai Spec Kit adalah membandingkan kondisi sebelum dan sesudahnya. Diagram berikut menyandingkan di mana tiap artefak “hidup” pada kedua kondisi tersebut.

 1BEFORE Spec Kit:
 2├── Spec: "di Confluence page yang last edited 6 months ago"
 3├── Clarification: "Slack thread yang sudah archived"
 4├── Plan: "di kepala developer"
 5├── Tasks: "akan dikerjakan nanti"
 6├── Implementation: "langsung coding"
 7├── Review: "PR yang reviewer tidak punya context"
 8└── Audit: "tidak ada"
 9
10AFTER Spec Kit:
11├── Spec: .specify/features/product-review/spec.md (versioned, in git)
12├── Clarification: clarifications.md (5 Q&As, all answered)
13├── Plan: plan.md (APPROVED by @budi, risks identified)
14├── Tasks: tasks.md (14 tasks, parallel map, DoD for each)
15├── Implementation: 14 commits, each traceable to spec + task
16├── Review: PR with full AC compliance table, coverage report
17└── Audit: specify audit — 16/16 ACs, 89% coverage, 93/100 score

Perbedaannya bukan soal “lebih banyak dokumen”, melainkan soal lokasi kebenaran: sebelum Spec Kit, konteks tersebar dan mudah usang; sesudahnya, semuanya versioned di git dan selalu bisa ditelusuri.

20.17 Terima Kasih, dan Selamat Datang di Topik 3

Menyelesaikan Topik 2 berarti kamu sudah:

• Menguasai 6 perintah Spec Kit
• Memahami workflow end-to-end dari spec ke kode
• Setup CI/CD integration untuk spec compliance
• Siap menggunakan spec sebagai foundation untuk AI pipeline yang lebih complex

Di Topik 3, kita akan melihat landscape yang lebih luas: AI Coding Tools untuk Golang Developer — perbandingan komprehensif antara Claude Code, Cursor, GitHub Copilot, AWS Kiro, dan lainnya, dievaluasi dari kacamata SDD.

20.18 Checklist Sebelum Lanjut ke Topik 3

Sebelum beranjak, ada baiknya memastikan fondasi Topik 2 sudah benar-benar terpasang. Checklist berikut merangkum syarat kesiapan dari sisi setup, workflow, integrasi, hingga tim.

 1## Topik 2 Completion Checklist
 2
 3### Setup
 4- [ ] specify CLI installed dan configured
 5- [ ] .specify/ folder ada di project
 6- [ ] constitution.md sudah ditulis
 7
 8### Workflow
 9- [ ] Sudah coba full workflow: specify → clarify → plan → tasks → implement
10- [ ] Sudah menjalankan specify audit
11- [ ] Sudah membuat PR dengan specify pr
12
13### Integration
14- [ ] CLAUDE.md ter-update setelah feature implementation
15- [ ] CI/CD pipeline dengan spec audit (atau plan untuk setup)
16- [ ] Branching strategy documented
17
18### Team (jika apply)
19- [ ] Tim onboarding dengan Spec Kit done
20- [ ] Shared templates untuk tipe fitur common
21- [ ] Spec review process defined

Jika sebagian besar kotak sudah tercentang — terutama full workflow dan specify audit — berarti kamu siap memasuki pembahasan ekosistem tools yang lebih luas di Topik 3.

20.19 Resources

Untuk memperdalam materi, berikut kumpulan tautan penting seputar Spec Kit dan seri ini. Daftar berikut mencakup repositori resmi, dokumentasi, dan sample project studi kasus.

 1GitHub Spec Kit:
 2- Repository: github.com/github/spec-kit
 3- Documentation: spec-kit.github.com
 4- Discord: discord.gg/spec-kit
 5
 6Santekno Blog:
 7- Topik 1: /tutorial/golang/ai-driven/specification-driven-development/
 8- Topik 2: /tutorial/golang/ai-driven/github-spec-kit/ (← kamu di sini)
 9- Topik 3: /tutorial/golang/ai-driven/ai-coding-tools-golang/ (coming soon)
10
11Sample Project:
12- github.com/santekno/santekno-shop (studi kasus dari Topik 1 & 2)

Simpan tautan sample project github.com/santekno/santekno-shop — studi kasus yang sama akan terus dirujuk sebagai contoh nyata di topik-topik berikutnya.

20.20 Ringkasan Topik 2

Topik 2 — GitHub Spec Kit: Otomasi Workflow SDD — selesai.

Kita sudah journey dari “apa itu Spec Kit?” hingga “bagaimana spec menjadi foundation untuk AI pipeline yang lebih complex”. 20 artikel, 6 perintah inti, satu studi kasus end-to-end, tim workflow, monorepo, CI integration, dan akhirnya — spec sebagai machine-readable contract.

Spec Kit bukan tujuan akhir. Ini adalah fondasi yang solid untuk topik-topik selanjutnya di seri ini — LLM-powered applications, RAG, AI agents, LLMOps, dan AI at scale.

Dengan spec yang terstruktur dan selalu up-to-date, kamu sudah siap membangun aplikasi Golang yang benar-benar AI-powered — bukan hanya AI-assisted.