Cara Menyiapkan Spec Kit di Claude Code pada 2026: Spesifikasi, Bukan Prompt

Apa yang terjadi pada vibe coding pada Mei 2026?#

Setahun kemudian, pada 4 Februari 2026, ia menerbitkan utas retrospektif:

Dalam ceramahnya di Sequoia Ascent 2026, ia menjelaskannya dengan lebih tepat: “Vibe coding menaikkan batas bawah—seberapa banyak yang bisa dilakukan semua orang dalam perangkat lunak. Agentic engineering mempertahankan batas atas—standar kualitas pengembangan profesional.” Di panggung yang sama, ia melontarkan kalimat yang masuk ke dalam leksikon industri: “Anda tidak boleh menimbulkan kerentanan karena vibe coding. Anda tetap bertanggung jawab atas perangkat lunak Anda, seperti sebelumnya.”

Dua hal terjadi secara bersamaan. Pada September 2025, GitHub menerbitkan alat Spec Kit—yang mengumpulkan 107.000 bintang dalam 8 bulan. Pada Februari 2026, AWS menerbitkan studi kasus penemuan obat yang terperinci yang melaporkan “95% logika bisnis dihasilkan dari spesifikasi, menghemat lebih dari 80 jam.”

Pada akhir Mei 2026, konsensus telah terbentuk di ruang informasi berbahasa Inggris: vibe coding sebagai metode kerja adalah tingkat pemula. Berikutnya adalah Spec-Driven Development. Panduan ini menjelaskan cara memasang dan menerapkan pendekatan tersebut.

Apa itu Spec Kit dan Spec-Driven Development?#

Gagasan inti metodologi ini terangkum dalam satu kalimat dari dokumentasi resmi GitHub:

Dalam praktiknya, proses ini berlangsung dalam 4 fase (Spec Kit menambahkan satu fase lagi, fase nol—constitution, yang dijelaskan di bawah):

1. Specify - tulis spesifikasi tentang apa yang Anda inginkan dalam bahasa alami. APA yang harus dilakukan dan MENGAPA. Bukan BAGAIMANA.
2. Plan - agen mengambil spesifikasi dan menyusun rencana teknis: teknologi apa, arsitektur seperti apa, dan komponen apa.
3. Tasks - agen memecah rencana menjadi tugas-tugas spesifik yang dapat diverifikasi beserta dependensinya.
4. Implement - agen (atau subagennya) mengerjakan tugas-tugas dan menulis kode.

Setelah Implement, versi Spec Kit saat ini memiliki langkah verifikasi bernama Converge: agen memeriksa kode yang sudah selesai terhadap spesifikasi, rencana, dan tugas, lalu menambahkan hal yang terlewat ke tasks.md. Jalankan Implement dan Converge berulang kali sampai Converge merespons “Converged.”

Setiap fase adalah berkas markdown terpisah di repo. Setiap fase merupakan perintah slash terpisah di Claude Code: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, sedangkan pemeriksaannya adalah /speckit-converge. Dokumentasi Spec Kit menulis perintah yang sama dengan titik (/speckit.specify), tetapi di Claude Code Spec Kit memasangnya sebagai skills, dan perintahnya dipanggil dengan tanda hubung. Jika terjadi kesalahan pada langkah mana pun, edit berkas markdown lalu jalankan fase berikutnya.

Spec Kit adalah implementasi khusus dari SDD. Pada Mei 2026, alat ini sudah memiliki lebih dari 30 integrasi dengan agen AI yang berbeda. Di dalam satu repo, Spec Kit bekerja dengan cara yang sama bersama Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose, dan belasan lainnya.

Jadi, setelah satu kali proses, repo Anda berisi bukan hanya kode, tetapi juga spesifikasi, rencana, dan tugasnya. Sebulan kemudian, Anda dapat kembali ke proyek, membaca spec.md, dan memahami apa yang dilakukan dan alasannya. Ini bukan lagi “vibe coding yang melupakan keberadaan kode”—ini adalah memori kerja proyek.

Mengapa vibe coder yang tidak menulis kode membutuhkan ini?#

Spec Kit memformalkan perencanaan dalam beberapa langkah terpisah dengan 4 perintah slash. Logikanya: pisahkan “memikirkannya dengan matang” dari “mengimplementasikannya” agar keduanya berlangsung di jendela konteks yang berbeda. Setiap tahap mendapatkan konteks bersih yang belum dipenuhi hal-hal dari fase sebelumnya.

Tiga manfaat konkret bagi vibe coder:

• Prediktabilitas. Saat Anda memberi tahu agen “buat formulir pendaftaran dengan konfirmasi email,” agen menebak 10 detail sendiri—dan tiga di antaranya keliru dibandingkan dengan yang Anda bayangkan. Jika Anda memiliki spec.md berisi User Stories, Acceptance Scenarios, dan penanda [NEEDS CLARIFICATION] di setiap bagian yang belum pasti, agen tidak perlu menebak.
• Memori proyek. Sebulan kemudian, Anda tidak akan ingat apa yang dibahas dengan agen di chat. Namun, spec.md, plan.md, dan tasks.md ada di repo, di folder specs/###-feature/ bersama kode. Berkas-berkas itu menunjukkan bukan hanya apa yang dilakukan, tetapi juga alasannya.
• Skala. Untuk fitur yang melibatkan 1-2 berkas, perbedaannya hampir tidak terasa. Untuk fitur yang melibatkan 20 berkas dan 5 entitas data, perbedaannya adalah antara “menulis ulang semuanya setelah 4 jam” dan “semuanya sudah masuk ke branch utama setelah 4 jam.” AWS Kiro menunjukkan otomatisasi 95% logika bisnis dari sebuah spesifikasi dalam proyek TargetID.

Ilusi utama vibe coding adalah bahwa pendekatan ini tampak lebih cepat di awal. Baru setengah jam, sudah ada prototipe. Namun, setelah satu minggu, prototipe itu rusak dan lebih mudah dibuang. Spec-Driven Development membutuhkan sedikit lebih banyak waktu di awal (satu jam, bukan setengah jam), tetapi seminggu kemudian Anda masih bekerja di repo yang sama.

Cara memasang Spec Kit di Claude Code (4 langkah)#

Langkah 1. Pasang uv. Anda hanya perlu melakukannya sekali; uv akan tetap ada di sistem Anda.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Periksa apakah uv sudah terpasang:

uv --version

Langkah 2. Pasang Spec Kit. Satu perintah:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Periksa:

specify --version

Langkah 3. Inisialisasi repo. Buka folder proyek Anda (atau buat folder baru) dan jalankan:

specify init --here --integration claude

Flag --integration claude memilih Claude Code secara langsung. Tanpa flag itu, Spec Kit meminta Anda memilih agen dari daftar interaktif, dan mungkin juga menanyakan jenis skrip (untuk macOS dan Linux, biarkan sebagai sh). Jika folder tidak kosong, Spec Kit akan memperingatkan bahwa berkas-berkasnya akan digabungkan dengan berkas Anda: commit pekerjaan Anda terlebih dahulu, lalu ulangi perintah dengan flag --force.

Setelah itu, berikut ini akan muncul di repo:

.specify/
  memory/
    constitution.md        # aturan proyek, diisi melalui /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

Langkah 4. Buka Claude Code dan periksa perintah slash. Jalankan ini di folder yang sama:

claude

Di sesi tersebut, ketik /speckit—perintah speckit-* akan muncul dalam saran. Jika tidak muncul, mulai ulang Claude Code agar membaca ulang .claude/skills/. Jika Anda sudah memiliki CLAUDE.md di akar proyek, Spec Kit tidak akan mengubahnya—alat ini bekerja bersamanya, di .specify/memory/constitution.md.

Spec Kit juga dapat digunakan tanpa Claude Code (mendukung 30+ agen), tetapi panduan ini khusus membahas penyiapan dengan Claude. Jika ingin langsung memasang dua alat, baca panduan terpisah tentang menyiapkan CLAUDE.md dan Plan Mode di Claude Code.

Spec Kit adalah komponen pertama dalam “kontrak kerja agen.” Penyiapan lengkap mencakup ketiganya: klon AI (metodologi Anda dalam bentuk Skills dan subagen), Second Brain (struktur business/ yang dikunjungi agen setiap kali), dan rekayasa konteks (Spec Kit, Plan Mode, /compact). Ketiganya adalah pilar yang tanpanya AI berhalusinasi.

Cara menulis spesifikasi pertama Anda (Specify)#

Di Claude Code, ketik:

/speckit-specify

Kemudian agen akan meminta deskripsi fitur. Pada langkah ini, gunakan bahasa sederhana tanpa jargon teknis:

Saya ingin formulir pendaftaran di aplikasi saya. Pengguna memasukkan email
 dan kata sandi, menerima email konfirmasi, lalu setelah konfirmasi
masuk ke dashboard. Konfirmasi kedaluwarsa setelah 48 jam. Jika email
masih belum dikonfirmasi, hapus akun dalam 5 menit setelah tenggat itu;
jangan pernah hapus akun yang sudah dikonfirmasi.

Dalam contoh ilustratif ini, toleransi penghapusan diklarifikasi menjadi 5 menit setelah tenggat 48 jam. Untuk produk nyata, konfirmasikan toleransi itu sebelum Plan; tenggat tepat 48 jam memerlukan desain serta pengujian yang menegakkan kebutuhan lebih kuat tersebut. Agen akan menyusun specs/001-registration/spec.md. Buka berkas itu, dan Anda akan melihat struktur seperti ini:

# Spesifikasi Fitur: Pendaftaran Pengguna

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "Saya ingin formulir pendaftaran..."

## Skenario Pengguna & Pengujian *(wajib)*

### Kisah Pengguna Utama
Sebagai pengguna baru, saya ingin mendaftarkan akun dengan konfirmasi email,
agar saya dapat mengakses dashboard dengan identitas terverifikasi.

### Skenario Penerimaan
1. **Given** saya berada di halaman pendaftaran,
   **When** saya mengirim email dan kata sandi yang valid,
   **Then** saya menerima email konfirmasi dalam 1 menit.
2. **Given** saya mengeklik tautan konfirmasi dalam 48 jam,
   **When** saya masuk ke dashboard,
   **Then** saya melihat email saya terkonfirmasi di profil.
3. **Given** saya belum melakukan konfirmasi pada tenggat 48 jam,
   **When** pembersihan berjalan dalam 5 menit berikutnya,
   **Then** akun saya dihapus dan email dapat digunakan kembali untuk pendaftaran.
4. **Given** usia akun saya belum mencapai 48 jam atau sudah dikonfirmasi,
   **When** pembersihan berjalan,
   **Then** akun tidak dihapus.

## Persyaratan *(wajib)*

### Persyaratan Fungsional
- **FR-001**: Sistem HARUS menerima pendaftaran melalui [NEEDS CLARIFICATION:
  hanya email/kata sandi, atau juga SSO/OAuth?]
- **FR-002**: Sistem HARUS mengirim email konfirmasi dalam 60 detik
- **FR-003**: Konfirmasi HARUS kedaluwarsa pada 48 jam; sistem HARUS
  menghapus akun yang masih belum dikonfirmasi paling lambat 5 menit setelah
  tenggat itu dan TIDAK BOLEH menghapus akun terkonfirmasi
- **FR-004**: Sistem HARUS mencatat semua upaya pendaftaran selama [NEEDS
  CLARIFICATION: berapa lama log disimpan - 30 hari, 90 hari, selamanya?]

### Entitas Utama
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Kriteria Keberhasilan *(wajib)*
- **SC-001**: 95% email konfirmasi terkirim dalam 60 detik (p95)
- **SC-002**: 0 penghapusan tak sengaja atas akun yang sudah dikonfirmasi
- **SC-004**: Tidak ada penghapusan sebelum 48 jam; setiap akun belum dikonfirmasi
  yang memenuhi syarat dihapus pada usia 48 jam 5 menit pada beban kerja yang diuji
- **SC-003**: Tingkat penyelesaian pendaftaran > 60% (dari formulir dibuka hingga dashboard)

Perhatikan penanda [NEEDS CLARIFICATION: ...]. Spec Kit sengaja menyisipkannya di setiap bagian yang belum mendapatkan jawaban jelas dari teks Anda. Sebelum berpindah ke fase Plan, Anda harus menjawabnya secara manual di spec.md atau menjalankan /speckit-clarify, lalu agen akan menelusuri poin-poin yang belum jelas dan mengajukan pertanyaan dalam dialog.

Di Spec Kit, perintah bawaan /speckit-clarify menggantikan ucapan “ajukan pertanyaan kepada saya.” Efeknya sama: Anda tidak melanjutkan ke Plan sampai tidak ada lagi penanda [NEEDS CLARIFICATION] di spec.md.

Tidak boleh ada teknologi di spec.md. Jangan menyebut React, Postgres, Prisma, atau Redis. Spesifikasi menjelaskan apa yang dilakukan sistem dari sudut pandang pengguna dan bisnis. Tumpukan teknologi dibahas pada fase berikutnya.

Apa yang dilakukan Claude dalam fase Plan?#

Saat spec.md siap, jalankan:

/speckit-plan

Secara opsional, berikan petunjuk teknologi langsung di dalam perintah:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude membaca tiga sumber: spec.md, CLAUDE.md Anda (atau memory/constitution.md), dan kode yang ada di repo. Hasilnya adalah plan.md dengan struktur kira-kira seperti ini:

# Rencana Implementasi: Pendaftaran Pengguna

## Konteks Teknis
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validasi: skema Zod di shared lib
- Autentikasi: NextAuth.js with credentials provider

## Keputusan Arsitektur

### 1. Penyimpanan token
Token disimpan di DB (tabel ConfirmationToken), bukan di JWT.
Alasan: perlu pencabutan di sisi server saat email didaftarkan ulang.

### 2. Pengiriman email
Secara asinkron melalui cron `/api/cron/send-confirmation` yang dijalankan segera
setelah pendaftaran. Percobaan ulang ditangani oleh Resend.

### 3. Cron hapus otomatis
Jalankan `/api/cron/cleanup-unconfirmed` setiap menit. Hapus baris hanya jika
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
Contoh yang diklarifikasi mengizinkan keterlambatan penghapusan maksimum 5 menit.
Verifikasi keterlambatan penjadwal dan waktu penyelesaian terhadap batas itu;
laporkan pelanggaran batas sebagai kegagalan, bukan pembersihan harian berhasil.

## Model Data
Lihat data-model.md

## Kontrak API
Lihat contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Fase Implementasi
1. Migrasi database (skema Prisma + berkas migrasi)
2. Rute API (3 endpoint)
3. UI: formulir pendaftaran + halaman sukses konfirmasi
4. Cron job (pengiriman + pembersihan)
5. Templat email
6. Pengujian integrasi

data-model.md akan menjelaskan entitas dan hubungannya. contracts/ akan berisi kerangka kontrak API (berupa OpenAPI YAML atau tipe permintaan/respons TypeScript). Ini bukan kode—ini adalah maksud yang nantinya akan diubah Claude menjadi rute sungguhan.

Keuntungan utama fase Plan adalah konteks yang bersih. Claude tidak mencoba mengingat spesifikasi dan implementasi sekaligus. Claude memikirkannya terlebih dahulu, mencatat keputusan dalam sebuah berkas, lalu melanjutkan.

Berikutnya ada perintah opsional /speckit-analyze. Perintah ini dijalankan setelah fase Tasks dan sebelum Implement: perintah tersebut meninjau kumpulan spec.md + plan.md + tasks.md untuk mencari kontradiksi dan memeriksa apakah semua persyaratan spesifikasi tercakup dalam rencana dan tugas. Perintah ini tidak mengedit berkas; hanya menghasilkan laporan. Pada dasarnya, ini adalah pemeriksaan kewajaran formal sebelum implementasi.

Cara memecah pekerjaan menjadi tugas (Tasks)#

Setelah memiliki spec.md dan plan.md, jalankan:

/speckit-tasks

Claude mengembangkan rencana menjadi tasks.md:

# Tugas: Pendaftaran Pengguna

## Fase 1: Database (tanpa dependensi)
- [ ] T-001: Tambahkan model User ke prisma/schema.prisma (aman dijalankan paralel)
- [ ] T-002: Tambahkan model ConfirmationToken ke prisma/schema.prisma (setelah T-001)
- [ ] T-003: Buat migrasi `add-user-registration` (setelah T-002)

## Fase 2: Kontrak API (tanpa dependensi)
- [ ] T-004: Buat skema Zod di shared/validation/auth.ts
- [ ] T-005: Definisikan tipe TypeScript di shared/types/auth.ts (setelah T-004)

## Fase 3: Rute (bergantung pada Fase 1+2)
- [ ] T-006: Implementasikan POST /api/auth/register
- [ ] T-007: Implementasikan POST /api/auth/confirm
- [ ] T-008: Implementasikan GET /api/auth/resend-confirmation

## Fase 4: UI (paralel dengan Fase 3)
- [ ] T-009: Buat halaman /register dengan formulir
- [ ] T-010: Buat halaman /register/confirm/[token]
- [ ] T-011: Buat halaman /register/success

## Fase 5: Cron + integrasi (bergantung pada Fase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Templat email registration-confirmation.tsx
- [ ] T-015: Pengujian integrasi (Playwright), termasuk pembersihan tepat
  sebelum 48 jam, tepat pada 48 jam, penghapusan pada 48 jam 5 menit, kegagalan
  pekerjaan tertunda, dan perlindungan akun terkonfirmasi

## Catatan
- T-001, T-004, T-009-T-011 aman dijalankan paralel (berkas berbeda)
- T-002 bertabrakan dengan T-001 (berkas sama: schema.prisma) - jalankan berurutan
- T-006 membutuhkan T-003 (migrasi diterapkan) dan T-005 (tipe)

Perhatikan penanda parallel-safe dan after T-NNN. Ini adalah grafik dependensi yang kelak memungkinkan beberapa fase dijalankan secara paralel. Seluruh pendekatan percepatan Spec Kit bertumpu pada mekanisme ini: beberapa tugas dapat diserahkan kepada lima sesi Claude Code yang berbeda sekaligus, sementara tugas lain harus benar-benar dijalankan berurutan.

Spec Kit melakukannya secara otomatis dengan satu perintah, langsung dari awal.

Perintah opsional /speckit-taskstoissues mengambil tasks.md dan membuat GitHub Issues dari daftarnya, masing-masing dengan tautan kembali ke spec.md. Ini berguna jika Anda bekerja dalam tim atau ingin melacak kemajuan melalui GitHub Projects.

Cara mengimplementasikan dengan subagen (Implement)#

/speckit-implement

Claude memulai dari tugas pertama dalam tasks.md. Setiap tugas melalui siklus singkat: membaca berkas yang relevan, menulis diff, menjalankan pengujian, memeriksa [x]. Subagen dipanggil secara otomatis jika diperlukan: satu untuk tinjauan kode, satu untuk menjalankan linter, dan satu untuk memeriksa regresi.

Dan secara terpisah, tentang aturan:

Di Spec Kit, siklus ini diformalkan. Anda memiliki spec.md sebagai sumber kebenaran, plan.md untuk keputusan teknis, dan tasks.md sebagai daftar periksa. Jika Claude melenceng pada langkah apa pun, Anda kembali ke spesifikasi dan berkata, “Itu tidak sesuai dengan FR-003; kerjakan ulang.” Tidak perlu prompt panjang seperti “ingat apa yang kita bahas...” — seluruh riwayat ada di dalam berkas.

Jika Anda sudah menghubungkan Dynamic Workflows di Opus 4.8, Anda dapat mengatur Spec Kit ke mode otomatis penuh: satu perintah /speckit-implement dan Claude memparalelkan pekerjaan, menggabungkan hasil, dan memeriksanya. Batasnya adalah 1000 subagen sekaligus. Untuk sebagian besar fitur, 10-30 sudah cukup.

Saat semua kotak [x] dicentang dan pemeriksaan di bagian berikutnya menghasilkan “Converged,” tinjau PR (atau serangkaian PR jika ada banyak tugas) lalu gabungkan. Artefaknya—spec.md, plan.md, tasks.md—tetap berada di repo sebagai dokumentasi fitur. Setahun kemudian, Anda tidak perlu merekayasa balik logikanya dari kode.

Cara memeriksa apakah agen melewatkan sesuatu (Converge)#

/speckit-converge

Pertama, agen memberikan ringkasan temuannya beserta tingkat keparahan, lalu memberikan salah satu dari dua hasil. “Converged” berarti tidak ada yang terlewat, tasks.md tetap tidak berubah byte demi byte, dan Anda dapat melanjutkan ke tinjauan. “Tasks appended” berarti ada hal yang terlewat, hal tersebut ditambahkan ke bagian Convergence di tasks.md, dan agen memberi tahu berapa jumlahnya.

Converge tidak mengedit atau menghapus kode; satu-satunya yang ditulis adalah tugas baru di tasks.md. Jadi, Anda dapat menjalankannya tanpa khawatir, tetapi hanya setelah /speckit-implement selesai mengerjakan tasks.md saat ini. Setiap putaran berikutnya menemukan lebih sedikit hal yang terlewat.

Apa perbedaan Spec Kit dengan CLAUDE.md dan Plan Mode?#

Bandingkan ketiganya berdasarkan 5 karakteristik:

Dalam istilah Spec Kit, ini adalah .specify/memory/constitution.md. Saat inisialisasi, Spec Kit dapat menggunakan CLAUDE.md yang sudah ada sebagai dasar constitution atau membuat berkas terpisah di sampingnya. Biasanya saya mempertahankan CLAUDE.md sebagai “kontrak” global (tumpukan teknologi, glosarium, protokol deployment), dan menggunakan constitution Spec Kit untuk aturan khusus fitur—misalnya, “semua formulir divalidasi melalui Zod; tidak ada pemeriksaan manual.”

Hubungannya dengan Plan Mode lebih sederhana. Plan Mode adalah mode singkat “rencana sebelum menulis kode” dalam satu sesi. Mode ini cocok untuk perubahan kecil (memperbaiki bug, memfaktorkan ulang fungsi). Untuk fitur besar, Plan Mode kalah karena jendela konteks satu sesi terlalu kecil untuk rencana sepanjang 3000 baris—seperti yang saya jelaskan langsung dalam sesi:

Spec Kit adalah alat rekayasa konteks yang konkret. Alat ini memindahkan “hamparan arsitektur” dari chat ke berkas. Spec.md tetap berada di repo, dan setiap sesi Claude yang baru membacanya lagi—Anda tidak perlu mengulanginya.

Penyiapan untuk proyek besar:

1. CLAUDE.md - tumpukan teknologi, glosarium, hal yang tidak boleh dilakukan. Berkas ini berada di akar proyek.
2. .specify/memory/constitution.md untuk Spec Kit—aturan khusus untuk alur kerja ini.
3. specs/001-feature-A/spec.md, plan.md, tasks.md - fitur pertama.
4. specs/002-feature-B/spec.md, plan.md, tasks.md - fitur kedua.
5. Untuk pekerjaan harian, gunakan /speckit-implement (untuk tugas siap pakai) atau /plan (pemeriksaan ulang cepat sebelum perubahan).

Kasus nyata apa yang berhasil?#

Kasus spesifik:

• AWS Kiro - agen penemuan obat. Dalam unggahan blog AWS Industries tertanggal 18 Februari 2026, tim menjelaskan proyek TargetID. Tiga pengembang, tiga minggu, satu agen penemuan obat. Angka-angka dalam artikel: Kiro menghasilkan lebih dari 95% kode logika bisnis, menghemat lebih dari 80 jam pengembangan. Selain itu: “Dokumentasi README yang ditulis Kiro menghemat sekitar 8 jam” dan “40% lebih sedikit siklus prompt-dan-perbaikan berulang.”
• Rackspace Technology. Dalam blog AWS yang sama, Rackspace melaporkan: “menyelesaikan pekerjaan yang diperkirakan memerlukan 52 minggu hanya dalam 3 minggu,” “peningkatan efisiensi sebesar 90%.” Ini bukan lagi fitur kecil—ini proyek perusahaan skala penuh.
• Pertumbuhan GitHub Spec Kit. Repo tersebut mengumpulkan 107.000 bintang GitHub dalam 8 bulan.

Bagi pembaca, ini berarti pendekatan tersebut bukan teori: tim-tim serius sudah menggunakannya dalam produksi.

Kapan Spec Kit TIDAK cocok?#

Tidak cocok #1 - perubahan kecil. Jika tugasnya “ganti nama variabel,” “perbaiki salah ketik di teks,” atau “tambahkan log,” menjalani Specify → Plan → Tasks akan lebih lama daripada mengeditnya sendiri. Untuk perubahan kecil, Plan Mode atau cukup memberi prompt langsung di Claude Code lebih cepat.

Tidak cocok #2 - eksperimen langsung. Saat Anda belum tahu apa yang diinginkan dan perlu “menjelajahi” antarmuka atau segera membuat prototipe untuk melihat “apakah ini cocok,” spesifikasi tidak ada gunanya. Nilainya justru terletak pada fakta bahwa Anda sedang berimprovisasi. Pada tahap “bermain-main dengan ide,” vibe adalah pendekatan yang tepat, bukan spesifikasi.

Tidak cocok #3 - kode warisan dengan state yang kompleks. Realitas berubah lebih cepat daripada spesifikasi. Tim dapat menjelaskan siklus penagihan dan aturan pajak, lalu seminggu kemudian bagian Finance meminta PPN Eropa—spesifikasinya sudah usang sebelum rilis. Ketika logika bisnis berkembang cepat, memelihara spesifikasi menjadi beban.

Risiko tambahan adalah rasa kendali yang keliru: strukturnya elegan, tetapi agen sering mengabaikan instruksi atau, sebaliknya, mengikuti templat terlalu harfiah. Hasilnya adalah kode yang benar secara struktural tetapi tidak sesuai dengan repo spesifik Anda—spesifikasi tidak menjamin agen memahaminya seperti yang Anda maksud.

Industri telah memperingatkan tentang waterfall: menulis spesifikasi besar sebelum kode merupakan jalan yang pernah menjatuhkan industri, pada masa persyaratan setebal 200 halaman. Sejak saat itu, para insinyur berhati-hati terhadap pendekatan ini, dan kehati-hatian tersebut beralasan.

Yang perlu dilakukan. Saya menyarankan aturan sederhana: ukuran fitur dibandingkan dengan waktu untuk menulis spesifikasi. Jika implementasi fitur akan memerlukan waktu kurang dari 2 jam, jangan menulis spesifikasi—Plan Mode lebih cepat. Jika fitur akan memerlukan waktu seminggu, gunakan Spec Kit; penghematan waktunya akan membuat spesifikasi satu jam itu terbayar lima kali lipat. Untuk rentang antara 2 jam dan seminggu, gunakan penilaian Anda, meski secara pribadi saya menulis spesifikasi bahkan untuk fitur setengah hari karena artefak di repo lebih berharga daripada menghemat 30 menit.

Selanjutnya: bagaimana mengintegrasikan Spec Kit ke proyek Anda?#

Rencana konkret untuk 7 hari ke depan:

• Hari 1. Pasang uv dan Spec Kit (5-10 menit). Periksa apakah perintah /speckit-* sudah muncul di Claude Code Anda. Jangan mencoba menerapkannya pada proyek yang sudah ada—mulailah dengan proyek baru.
• Hari 2. Pilih fitur nyata yang ingin Anda bangun. Jalankan /speckit-specify dengan deskripsi bebas. Buka spec.md, baca, dan jawab setiap [NEEDS CLARIFICATION]. Jangan terburu-buru ke Plan.
• Hari 3. Jalankan /speckit-plan dengan petunjuk tentang tumpukan teknologi Anda. Baca plan.md, terutama bagian Architecture Decisions. Jika ada yang tidak sesuai, edit secara manual.
• Hari 4-5. Jalankan /speckit-tasks, lalu /speckit-analyze untuk memeriksa ulang kumpulan spec, plan, dan tasks, lalu /speckit-implement. Amati bagaimana Claude mencentang [x] di tasks.md. Claude mungkin tersendat di suatu bagian—itu wajar. Kembali ke spec.md, perjelas persyaratan, dan mulai ulang /speckit-implement dengan tugas yang spesifik. Setelah tugas-tugas selesai, jalankan /speckit-converge dan ulangi rangkaian Implement dan Converge sampai agen merespons “Converged.”
• Hari 6-7. Tinjau PR (atau serangkaian PR). Gabungkan. Baca spec.md dan plan.md Anda—keduanya menjadi dokumentasi fitur untuk tahun mendatang.

Bahan yang saya sarankan untuk dibaca bersamaan:

• Cara menyiapkan CLAUDE.md pada 2026 - dasar bagi constitution Spec Kit.
• Plan Mode di Claude Code - alternatif cepat untuk tugas kecil.
• Rekayasa konteks pada 2026 - alasan Spec Kit dapat berfungsi.
• Skills, Subagents, MCP, atau Plugins - apa yang perlu ditambahkan ke Spec Kit untuk alur kerja Anda.
• Dynamic Workflows di Claude Code - cara meluncurkan banyak subagen sekaligus untuk fase Implement.

Alur kerja konteks lengkap: klon AI + Second Brain + Rekayasa Konteks.

Materi lainnya tersedia di Ailoot.