Spec-Driven Development: Saat AI Menulis Kode Enterprise

Artificial intelligence mengubah salah satu bagian paling mahal dalam software development: menulis kode.

Developer sekarang dapat meminta AI membuat komponen, menulis test, memperbaiki bug, melakukan refactoring, bahkan mengerjakan perubahan yang melibatkan beberapa file sekaligus.

Hasilnya dapat sangat cepat.

Namun, ketika kemampuan menulis kode meningkat, masalah lain menjadi semakin terlihat.

Bagaimana jika AI membangun fitur yang secara teknis bekerja tetapi tidak sesuai kebutuhan bisnis?

Bagaimana jika dua developer memberikan konteks berbeda dan menghasilkan implementasi yang tidak konsisten?

Bagaimana jika AI mempercepat pembangunan arsitektur yang sejak awal salah?

Di sinilah Spec-Driven Development menjadi semakin relevan.

Spec-Driven Development atau SDD adalah pendekatan yang menempatkan specification sebagai sumber utama untuk menjelaskan apa yang harus dibangun, constraint yang harus dipenuhi, serta bagaimana hasil akhirnya akan divalidasi.

Microsoft menggambarkan pendekatan ini sebagai perubahan dari prompt first, align later menjadi align first, then let AI accelerate execution. Requirement, scenario, constraint, acceptance criteria, architecture, dan validation dipertahankan dalam konteks yang sama sebelum AI menghasilkan implementasi.

Prinsipnya sederhana:

Ketika coding menjadi semakin murah, ambiguity menjadi semakin mahal.

AI Bisa Menulis Kode, Tetapi Tidak Mengetahui Intent Bisnis

Bayangkan perusahaan ingin membangun fitur approval purchase request.

Instruksinya:

“Buat fitur approval purchase request dengan tiga level approval.”

AI kemungkinan dapat menghasilkan:

• Database schema.
• API.
• User interface.
• Approval workflow.
• Notification.
• Unit test.

Secara teknis, hasilnya mungkin terlihat selesai.

Namun, masih ada banyak pertanyaan:

• Apakah semua purchase request memiliki tiga approval?
• Bagaimana jika nilainya di bawah Rp10 juta?
• Siapa yang boleh mengganti approver?
• Apa yang terjadi ketika approver sedang cuti?
• Apakah request dapat diedit setelah approval pertama?
• Bagaimana audit trail disimpan?
• Apakah finance dapat melakukan override?
• Apa yang terjadi pada transaksi existing?
• Apakah approval harus sequential atau parallel?

AI tidak dapat mengetahui jawabannya jika perusahaan sendiri belum mendefinisikannya.

AI hanya membuat proses menerjemahkan asumsi menjadi kode menjadi jauh lebih cepat.

Karena itu, risiko AI coding bukan hanya menghasilkan kode buruk.

Risiko yang lebih besar adalah:

menghasilkan kode yang salah dengan sangat cepat, tetapi terlihat meyakinkan.

Apa Itu Spec-Driven Development?

Dalam software development tradisional, specification sering dibuat di awal kemudian perlahan kehilangan relevansi.

Tim memiliki PRD, design document, diagram, ticket, dan catatan meeting. Namun, setelah development berjalan, kode menjadi sumber kebenaran terakhir.

GitHub Spec Kit menggambarkan Spec-Driven Development dengan pendekatan berbeda: specification menjadi artefak utama yang mendefinisikan intent, kemudian implementation plan dan kode menjadi ekspresi dari specification tersebut.

Workflow sederhananya dapat berupa:

Business Intent
↓
Specification
↓
Clarification
↓
Architecture Plan
↓
Implementation Tasks
↓
AI-assisted Development
↓
Validation terhadap Specification

GitHub Spec Kit saat ini menggunakan alur inti:

Spec → Plan → Tasks → Implement

Setiap tahap menghasilkan artefak terstruktur yang menjadi konteks tahap berikutnya, bukan sekadar prompt terpisah.

Specification Bukan Daftar Fitur

Kesalahan umum adalah menganggap specification sebagai daftar:

• Login.
• Dashboard.
• User management.
• Approval.
• Report.
• Notification.

Daftar tersebut menjelaskan apa yang terlihat, tetapi belum menjelaskan bagaimana sistem harus berperilaku.

Specification yang berguna untuk AI setidaknya perlu mencakup beberapa lapisan.

1. Business Intent

Mengapa fitur dibangun?

Contoh:

Mengurangi purchase request yang diproses tanpa otorisasi sesuai nilai transaksi.

Intent membantu tim membedakan kebutuhan inti dengan implementasi tambahan.

2. User Scenario

Siapa yang melakukan apa?

Contoh:

Procurement staff membuat purchase request dan sistem menentukan approval path berdasarkan nilai transaksi serta cost center.

3. Business Rules

Contohnya:

• Di bawah Rp10 juta: satu approval.
• Rp10–100 juta: manager dan finance.
• Di atas Rp100 juta: director approval.
• Request tidak dapat diubah setelah final approval.
• Perubahan setelah approval membuat proses dimulai kembali.

4. Acceptance Criteria

Bagaimana tim mengetahui implementasi benar?

Contohnya:

Purchase request Rp150 juta tidak dapat berpindah ke status approved sebelum seluruh approval yang diwajibkan selesai.

Acceptance criteria dapat langsung menjadi dasar test.

5. Architecture Constraints

AI juga perlu mengetahui batas teknis.

Misalnya:

• Authentication harus menggunakan existing SSO.
• Semua perubahan harus memiliki audit log.
• Tidak boleh mengakses database secara langsung.
• Integrasi menggunakan existing procurement API.
• PII tidak boleh ditulis ke application log.
• API response maksimum 2 detik pada kondisi normal.

Tanpa constraint, AI akan memilih implementasi yang menurutnya paling mudah—belum tentu yang sesuai dengan arsitektur perusahaan.

Kenapa Ini Semakin Penting di Era AI Coding?

1. Kecepatan Coding Tidak Lagi Menjadi Bottleneck Utama

OpenAI melaporkan penggunaan Codex dalam engineering workflow sudah mencakup perencanaan perubahan, penulisan kode, testing, refactoring, migration, dan preparation untuk review. Dalam eksperimen internal OpenAI, tim bahkan membangun produk dengan kode aplikasi, test, CI, dokumentasi, observability, dan tooling yang ditulis oleh agent, sementara manusia lebih banyak menentukan intent dan feedback loop.

Ini mengubah economics software development.

Jika implementasi dapat dipercepat secara signifikan, proporsi waktu yang dihabiskan untuk memahami masalah dan memvalidasi hasil menjadi semakin penting.

2. Prompt Tidak Cukup untuk Sistem Kompleks

Prompt seperti:

“Buat sistem inventory enterprise yang scalable.”

tidak menjelaskan cukup banyak hal.

Apa arti scalable?

Berapa jumlah warehouse?

Berapa transaksi per detik?

Bagaimana stock reservation bekerja?

Apa source of truth?

Apakah negative inventory diperbolehkan?

Bagaimana concurrency ditangani?

Microsoft mencatat bahwa workflow prompt-first dapat bekerja untuk pekerjaan sederhana, tetapi semakin sulit ketika requirement, constraint, dan edge case bertambah. Ketika konteks hanya hidup dalam prompt yang tersebar, tim dapat mengalami architectural drift, inconsistent implementation, dan rework.

SDD vs Vibe Coding

Vibe coding sangat berguna untuk:

• Prototype.
• Internal tools sederhana.
• Eksperimen.
• Personal project.
• Proof of concept.
• Validasi ide.

Namun, enterprise system memiliki karakter berbeda.

Ini bukan berarti perusahaan harus memilih salah satu secara absolut.

Prototype dapat dimulai secara eksploratif. Ketika use case sudah terbukti dan sistem masuk menuju production, tingkat specification perlu meningkat.

Specification Harus Menjadi Living Artifact

Masalah documentation tradisional adalah dokumen cepat usang.

Tim membuat specification pada bulan pertama. Development berubah pada bulan kedua. Enam bulan kemudian, tidak ada yang mengetahui dokumen mana yang masih benar.

SDD tidak akan menyelesaikan masalah tersebut apabila specification kembali diperlakukan sebagai dokumen mati.

Specification harus ikut berubah ketika:

• Requirement berubah.
• Business rule berubah.
• API berubah.
• Constraint berubah.
• Edge case baru ditemukan.
• Implementasi menghasilkan pembelajaran baru.

GitHub sendiri menekankan bahwa SDD merupakan proses iteratif dan specification perlu terus berkembang mengikuti perubahan kebutuhan.

Dengan demikian, pertanyaannya bukan:

“Apakah kita sudah punya dokumen requirement?”

Tetapi:

“Apakah AI dan manusia masih bekerja berdasarkan intent yang sama?”

AI Tidak Menghilangkan Kebutuhan Developer

Spec-Driven Development bukan berarti product manager menulis specification lalu AI menggantikan engineering team.

Peran developer justru bergerak ke level keputusan yang lebih tinggi.

Developer perlu:

• Menilai feasibility.
• Menentukan architecture.
• Memeriksa security.
• Mengelola dependency.
• Membuat quality guardrail.
• Mengevaluasi output AI.
• Menangani edge case.
• Mengelola technical debt.
• Menentukan trade-off performa dan maintainability.

Studi implementasi enterprise juga mulai menunjukkan AI coding dapat mempercepat engineering secara signifikan, tetapi tetap ditempatkan dalam workflow testing, review, security, governance, dan human control. Pada implementasi Codex di Cisco, misalnya, AI digunakan dalam sistem engineering production yang kompleks dengan requirement security dan compliance enterprise.

Nilai developer bergeser dari:

“siapa yang paling cepat menulis kode”

menuju:

“siapa yang paling baik mendefinisikan, membatasi, mengevaluasi, dan mengembangkan sistem.”

Framework Specification untuk Enterprise

Perusahaan tidak membutuhkan dokumen ratusan halaman untuk setiap fitur.

Gunakan framework sederhana:

Untuk fitur sederhana, specification mungkin hanya beberapa halaman.

Untuk sistem kritis, detailnya dapat berkembang jauh lebih dalam.

Tujuannya bukan menghasilkan dokumentasi sebanyak mungkin.

Tujuannya adalah mengurangi keputusan penting yang secara tidak sengaja diserahkan kepada AI.

Cara Memulai Spec-Driven Development

1. Pilih Satu Feature

Jangan langsung mengubah seluruh engineering workflow.

Pilih fitur dengan requirement cukup jelas tetapi memiliki beberapa business rule.

2. Tulis Intent Sebelum Implementation

Jangan mulai dengan framework atau database.

Tuliskan perubahan yang ingin dialami pengguna dan bisnis.

3. Dokumentasikan Constraint

Masukkan security, architecture, performance, data, dan integration requirement.

4. Buat Acceptance Criteria

Pastikan hasil dapat diuji.

Acceptance criteria yang baik membuat AI lebih mudah membantu menghasilkan test sekaligus implementation.

5. Gunakan AI untuk Clarification

AI tidak hanya digunakan untuk menulis kode.

Gunakan AI untuk bertanya:

• Requirement apa yang masih ambigu?
• Edge case apa yang belum dipikirkan?
• Rule mana yang bertentangan?
• Dependency apa yang perlu diklarifikasi?

6. Generate Plan sebelum Code

Minta AI menjelaskan rencana perubahan, file yang terdampak, data migration, test, dan risiko sebelum implementasi.

7. Validate terhadap Spec

Code review tidak hanya menanyakan:

“Apakah kode ini bagus?”

Tetapi juga:

“Apakah sistem yang dihasilkan masih memenuhi specification?”

Kesimpulan

AI membuat penulisan software jauh lebih cepat.

Namun, kecepatan tersebut tidak otomatis membuat software lebih tepat.

Ketika AI mampu menghasilkan banyak kode dalam waktu singkat, kualitas requirement, specification, architecture constraint, dan validation menjadi semakin penting.

Spec-Driven Development menawarkan pendekatan di mana intent bisnis tidak hanya menjadi dokumen pembuka proyek, tetapi tetap menjadi sumber konteks sepanjang development lifecycle.

Bukan berarti semua perubahan membutuhkan specification yang kompleks.

Semakin kecil risikonya, semakin ringan prosesnya.

Namun, untuk sistem enterprise yang menyentuh data, transaksi, approval, keamanan, dan integrasi, perusahaan perlu memastikan AI tidak membuat keputusan penting hanya karena requirement tidak pernah didefinisikan.

Masa depan software engineering mungkin bukan tentang siapa yang dapat menulis paling banyak kode.

Masa depan software engineering adalah tentang siapa yang paling jelas menentukan software apa yang seharusnya dibangun.

Bangun Enterprise Software dengan Intent yang Jelas Bersama Crocodic

Crocodic membantu perusahaan menerjemahkan kebutuhan bisnis menjadi sistem melalui proses strategic discovery, workflow mapping, specification, architecture, dan iterative development.

Melalui layanan Custom Enterprise Software, sistem dibangun berdasarkan proses, data, role pengguna, business rule, integrasi, dan target bisnis—bukan sekadar daftar fitur.

Untuk sistem yang sudah berjalan, Enterprise System Upgrade membantu perusahaan memperbaiki arsitektur, integration layer, scalability, dan automation tanpa selalu membangun ulang seluruh sistem.

AI dapat mempercepat development.

Namun, nilai akhirnya tetap ditentukan oleh seberapa jelas perusahaan mendefinisikan apa yang harus dibangun, bagaimana sistem harus bekerja, dan bagaimana hasilnya akan divalidasi.

Diskusikan kebutuhan dan specification enterprise software Anda bersama Crocodic.