Agentic Development Part 7: Best Practice — Spec-Driven + Agentic Development

Dua belas artikel telah membangun fondasi yang cukup untuk membahas bagaimana semua ini menyatu. Series Spec-Driven Development membahas cara menulis spec yang baik, kontrak API sebagai sumber kebenaran, workflow praktis dari spec ke kode, dan bagaimana acceptance criteria diturunkan jadi test. Series Agentic Development membahas otonomi agent, komponen internalnya, desain task, context engineering, guardrail, dan orkestrasi multi-agent. Artikel penutup ini bukan ringkasan ulang dari sebelas artikel sebelumnya — tapi sintesis yang menghadapi pertanyaan yang sering dihindari: apakah semua ini berarti pipeline dari requirement sampai deliverable bisa berjalan seperti mesin ajaib yang menghasilkan kode yang benar secara otomatis? Jawabannya tidak, dan memahami kenapa tidak — serta apa konsekuensi praktisnya — justru adalah inti dari seluruh series ini.

Bukan Abracadabra Machine

Ada gambaran yang terlalu mudah terbentuk ketika seseorang pertama kali membaca tentang pipeline PRD → spec teknis → eksekusi agent → deliverable: masukkan requirement, tunggu sebentar, keluar kode yang sudah benar. Gambaran ini salah, dan membiarkannya tidak dikoreksi adalah cara paling cepat untuk merasa kecewa dengan seluruh pendekatan ini setelah mencobanya.

Yang sebenarnya terjadi di dalam pipeline itu bukan satu lintasan linear. Ia adalah kumpulan loop bersarang yang masing-masing mengandung iterasi:

flowchart TD
    A[PRD / Requirement] --> B[Draft Spec Teknis]
    B --> C{Review Manusia}
    C -- Revisi --> B
    C -- Disepakati --> D[Plan / Task]
    D --> E[Agent Eksekusi Task]
    E --> F{Observe / Verify terhadap Spec}
    F -- Gagal Gate --> E
    F -- Lolos Gate --> G{Task Group Selesai?}
    G -- Belum --> D
    G -- Ya --> H{Review Deliverable}
    H -- Spec Mis / Emergent Requirement --> I[Update Spec]
    I --> J{Evaluasi Dampak ke yang Sudah Ada}
    J -- Tidak Terdampak --> D
    J -- Terdampak --> B
    H -- Sesuai Intent --> K[Done]

Iterasi ada di tiga level sekaligus: di dalam satu eksekusi task (agent mengulang loop plan-act-observe sampai gate lolos), di antara task group (checkpoint antar task group yang dibahas di Part 4 SDD dan Part 3 Agentic), dan di level spec itu sendiri (ketika review deliverable mengungkap sesuatu yang perlu diperbarui di spec sebelum iterasi berikutnya dimulai).

Yang berubah dengan spec-driven bukan “iterasi dihilangkan” — iterasi tetap ada dan memang seharusnya ada. Yang berubah adalah kualitas struktural dari iterasi tersebut. Pada vibe coding, iterasi terjadi secara reaktif: lihat hasil yang terlihat salah, prompt ulang dengan kata-kata berbeda, berharap hasilnya lebih baik, tanpa rekaman apa yang berubah dan kenapa. Tidak ada kriteria jelas kapan iterasi bisa berhenti, karena tidak ada definisi “selesai” yang disepakati sejak awal.

Pada spec-driven, setiap iterasi punya kriteria yang jelas kapan dianggap lolos — acceptance criteria yang sudah ditulis sebelum eksekusi dimulai (Part 2 SDD), gate otomatis yang memverifikasinya (Part 5 Agentic). Iterasi berhenti bukan ketika terlihat oke, tapi ketika kondisi yang sudah disepakati sebelumnya terpenuhi.

Jika ekspektasimu adalah “spec yang bagus menghasilkan kode yang benar dalam satu eksekusi tanpa iterasi”, ekspektasi itu perlu disesuaikan sebelum memulai. Ekspektasi yang lebih akurat: “spec yang bagus membuat setiap iterasi terverifikasi terhadap kriteria yang jelas, sehingga iterasi yang terjadi bermakna dan konvergen ke hasil yang benar — bukan berputar tanpa arah.”

Output Agent adalah Hipotesis, Bukan Kebenaran

Ini implikasi yang paling jarang dibahas secara jujur: model bahasa bersifat probabilistik. Dari spec yang sama persis, dijalankan dua kali, bisa menghasilkan dua implementasi yang berbeda kualitasnya. Dari spec yang sangat baik sekalipun, agent bisa menghasilkan kode yang lolos semua test yang ada tapi masih mengandung keputusan desain yang keliru, celah keamanan yang tidak terantisipasi, atau perilaku edge case yang tidak pernah terpikirkan sebagai sesuatu yang perlu ditest.

Data empiris mengkonfirmasi ini bukan kekhawatiran teoretis: sebuah studi besar pada 2026 menemukan lebih dari 110.000 isu yang diintroduksi oleh AI bertahan di production repositories. Studi lain menemukan bahwa lebih dari 70% kode yang dihasilkan model tertentu mengandung kerentanan dengan tingkat keparahan tertinggi dalam konteks security-sensitive. Ini bukan anomali — ini konsekuensi yang dapat diprediksi dari sifat probabilistik sistem yang menghasilkan kode berdasarkan distribusi probabilitas, bukan dari pemahaman deterministik tentang correctness.

Implikasi praktisnya: output agent sebaiknya diperlakukan sebagai hipotesis terbaik yang bisa dihasilkan dari informasi yang tersedia, bukan sebagai jawaban final yang tinggal di-deploy. Framing ini mengubah cara verifikasi diperlakukan — bukan sebagai formalitas yang dilakukan setelah “kode sudah selesai”, tapi sebagai proses konfirmasi hipotesis yang menentukan apakah kode itu benar-benar selesai.

flowchart LR
    A[Spec + Context] --> B[Agent Menghasilkan Kode]
    B --> C[Hipotesis: Kandidat Implementasi]
    C --> D{Verifikasi Berlapis}
    D -- Deterministik: Test, Linter, Contract Test --> E{Lolos?}
    E -- Tidak --> F[Revisi Hipotesis]
    F --> B
    E -- Ya --> G{Probabilistik: Reviewer Agent, Human Review}
    G -- Ada Masalah --> F
    G -- Konfirmasi --> H[Hipotesis Diterima sebagai Deliverable]

Alasan verifikasi berlapis dari Part 5 Agentic (deterministik lalu probabilistik) sekarang lebih jelas motivasinya: test otomatis memverifikasi apa yang sudah diantisipasi, tapi karena agent probabilistik bisa menghasilkan keputusan yang tidak pernah terpikirkan sebagai sesuatu yang perlu ditest, lapisan probabilistik — reviewer agent yang independen dan human review untuk area berisiko — menutupi gap yang secara struktural tidak bisa ditangkap oleh test deterministik saja.

Ini juga menjawab debat yang masih berlangsung soal “apakah human gates masih diperlukan ketika model makin pintar”. Jawabannya bukan soal seberapa pintar modelnya — model yang lebih pintar masih tetap probabilistik. Selama output bersifat probabilistik, verifikasi independen bukan pilihan yang bisa dihilangkan ketika model makin baik, melainkan bagian dari desain yang mengakui sifat fundamental sistem yang dipakai.

Kepercayaan berlebihan pada output agent — menganggap kode yang “terlihat benar” sudah pasti benar — adalah salah satu anti-pattern paling mahal dalam praktik sehari-hari. Test yang lolos membuktikan bahwa kode benar untuk kasus yang sudah diantisipasi. Tidak ada test yang bisa membuktikan tidak ada masalah untuk kasus yang belum terpikirkan.

Iterasi Terstruktur vs Vibe Coding

Dengan dua bagian di atas sudah jelas — iterasi ada dan output bersifat probabilistik — pertanyaan yang tepat bukan “bagaimana menghilangkan iterasi” tapi “bagaimana memastikan iterasi yang terjadi konvergen ke hasil yang benar, bukan berputar tanpa arah”.

Perbedaan struktural antara vibe coding dan spec-driven terletak di empat hal:

Yang paling penting dari empat perbedaan ini adalah “rekaman iterasi”. Setiap kali iterasi terjadi dalam workflow spec-driven, ia meninggalkan jejak: spec yang diupdate, task yang direvisi, keputusan yang terdokumentasi. Sesi berikutnya — baik oleh agent yang sama maupun agent berbeda — tidak perlu menemukan ulang konteks yang sama, karena konteks itu sudah ada dalam bentuk tertulis. Ini yang membuat spec-driven scale seiring waktu, sementara vibe coding cenderung degradasi kualitasnya seiring kompleksitas bertumbuh karena konteks tidak pernah terakumulasi secara persisten.

Ketika Spec Ternyata Mis atau Ada Emergent Requirement

Ini pertanyaan yang paling dekat dengan pengalaman nyata: bagaimana kalau setelah deliverable dieksekusi, ditemukan bahwa ada yang terlewat dari spec, atau bahkan ada kebutuhan baru yang baru kelihatan setelah menyentuh implementasi yang konkret?

Ada dua skenario yang karakternya berbeda dan perlu ditangani berbeda.

Skenario pertama: spec mis — ada yang terlewat, bukan perubahan intent. Agent menghasilkan sesuatu yang benar sesuai spec yang ada, tapi spec-nya sendiri yang tidak lengkap. Ini bukan kegagalan agent — agent mengerjakan dengan benar apa yang diminta. Ini adalah bug di spec. Penanganannya: perbaiki spec dulu, evaluasi apakah kode yang sudah ada melanggar tambahan ini atau tidak, lalu susun task baru berdasarkan gap yang ditemukan. Kode yang sudah ada tidak otomatis harus dibuang — kalau tambahan spec tidak bertentangan dengan implementasi yang ada, cukup tambah task untuk bagian yang kurang.

Skenario kedua: emergent requirement — kebutuhan yang baru bisa diketahui setelah melihat sesuatu yang konkret. Ada kategori requirement yang memang by nature tidak bisa diantisipasi sepenuhnya di awal: edge case bisnis yang baru kelihatan saat flow nyata dijalankan, constraint integrasi yang tersembunyi di balik abstraksi requirement, atau kebutuhan UX yang baru terasa setelah ada sesuatu yang bisa disentuh dan dicoba. Ini bukan kegagalan proses — ini sifat alami dari software development yang diakui bahkan oleh metodologi paling ketat sekalipun.

Yang berubah dengan spec-driven bukan “emergent requirement tidak akan muncul” — ia tetap akan muncul. Yang berubah adalah apa yang terjadi setelahnya:

Tanpa spec-driven:
Emergent requirement ditemukan
→ langsung prompt agent untuk tambah/ubah
→ agent improvisasi di atas kode yang ada
→ inkonsistensi menumpuk diam-diam karena tidak ada kontrak yang diupdate
→ kode makin sulit dipahami seiring waktu

Dengan spec-driven:
Emergent requirement ditemukan
→ update spec terlebih dahulu (intent, constraint, acceptance criteria baru)
→ evaluasi dampak ke task yang sudah selesai
→ baru eksekusi tambahan atau revisi
→ spec tetap mencerminkan keadaan aktual sistem

Bedanya bukan tentang kecepatan menangani requirement baru — spec-driven mungkin lebih lambat di langkah pertama karena ada fase update spec sebelum langsung eksekusi. Bedanya ada di akumulasi utang teknis: pendekatan “langsung prompt tanpa update spec” menciptakan utang dokumentasi yang membengkak seiring waktu, karena spec dan kode aktual makin jauh berpisah. Pada suatu titik, spec itu sendiri menjadi tidak bisa dipercaya lagi sebagai sumber kebenaran — dan begitu spec tidak bisa dipercaya, seluruh fondasi dari kedua series ini runtuh.

Emergent requirement adalah informasi berharga, bukan gangguan. Ia mengungkap sesuatu yang sebelumnya tidak terlihat tentang problem yang sedang dipecahkan. Perlakukan dengan serius: luangkan waktu untuk update spec sebelum langsung eksekusi, meski terasa seperti langkah mundur. Spec yang diperbarui berdasarkan temuan nyata jauh lebih kuat daripada spec yang hanya ditulis berdasarkan perkiraan di awal.

Satu Loop Besar: Peta Lengkap Kedua Series

Dengan semua konteks di atas, berikut diagram yang menyatukan keseluruhan perjalanan dari kedua series — bukan sebagai pipeline linear yang terlihat mudah, tapi sebagai sistem loop bersarang dengan titik kontrol yang eksplisit:

flowchart TD
    PRD[PRD / Requirement Bisnis] --> SpecTeknis

    subgraph SDD["Series 1: Spec-Driven Development"]
        SpecTeknis[Spec Teknis: Intent, Constraint,<br/>Acceptance Criteria, ERD, API Contract]
        Plan[Plan: Task Group dengan Dependency Jelas]
        Test[Test dari Acceptance Criteria]
        SpecTeknis --> Plan
        SpecTeknis --> Test
    end

    subgraph Agentic["Series 2: Agentic Development"]
        TaskDesign[Task Individual: Granularitas Tepat,<br/>Definition of Done Eksplisit]
        Context[Context Engineering: File Konvensi,<br/>Persistent Memory]
        Eksekusi[Agent Eksekusi: Loop Plan-Act-Observe]
        Guardrail[Guardrail: Gate Otomatis,<br/>Reviewer Independen]
        Plan --> TaskDesign
        TaskDesign --> Context
        Context --> Eksekusi
        Eksekusi --> Guardrail
    end

    Guardrail --> Review{Review Deliverable}
    Test --> Guardrail

    Review -- Sesuai Intent --> Done[Deliverable Diterima]
    Review -- Spec Mis --> SpecTeknis
    Review -- Emergent Requirement --> SpecTeknis

    CheckpointManusia[Checkpoint Review Manusia Wajib] -.menjaga.-> SpecTeknis
    CheckpointManusia -.menjaga.-> Review

Setiap koneksi dalam diagram ini merujuk ke artikel yang membahasnya secara mendalam. Spec teknis ke Part 2 dan 3 SDD; plan ke Part 4 SDD; task design ke Part 3 Agentic; context engineering ke Part 4 Agentic; eksekusi agent ke Part 2 Agentic; guardrail ke Part 5 Agentic; orkestrasi multi-agent ke Part 6 Agentic; dan dua panah kembali dari review ke spec teknis merupakan loop yang baru dibahas eksplisit di artikel penutup ini.

Prinsip Inti yang Berulang di Kedua Series

Beberapa prinsip muncul berulang kali di berbagai artikel dengan berbagai konteks berbeda. Ditarik secara eksplisit:

Ambiguitas biayanya proporsional dengan otonomi. Prinsip ini ada di Part 1 SDD (kenapa spec penting), Part 1 Agentic (kenapa spec jadi prasyarat otonomi), dan Part 6 Agentic (kenapa kontrak teknis harus disepakati sebelum eksekusi multi-agent). Makin besar otonomi yang diberikan, makin mahal celah ambiguitas yang tidak diselesaikan di awal.

Checkpoint lebih murah dari perbaikan di akhir. Muncul di Part 4 SDD (review di tengah eksekusi), Part 3 Agentic (definition of done per task), Part 5 Agentic (automated gate sebelum lanjut). Menemukan masalah lebih awal selalu lebih murah daripada menemukan masalah setelah banyak pekerjaan dibangun di atasnya.

Kontrak bersama mencegah drift. Part 3 SDD (OpenAPI sebagai kontrak executable), Part 4 Agentic (context engineering memastikan semua agent merujuk informasi yang sama), Part 6 Agentic (spec teknis sebagai penjaga konsistensi lintas agent). Drift terjadi ketika masing-masing pihak mengisi celah dengan asumsinya sendiri; kontrak eksplisit menghilangkan celah itu.

Output probabilistik membutuhkan verifikasi independen. Part 5 SDD (agent yang lolos test tapi melenceng dari intent), Part 5 Agentic (self-verification tidak cukup karena bias konfirmasi), artikel ini (output sebagai hipotesis yang perlu dikonfirmasi). Sifat probabilistik bukan bug yang akan diperbaiki oleh model yang lebih pintar — ini karakteristik fundamental yang menentukan bagaimana verifikasi harus didesain.

Spec hidup, bukan dokumen statis. Part 4 SDD (update spec sebagai bagian dari definition of done), Part 4 Agentic (file context yang basi lebih berbahaya dari tidak ada), artikel ini (emergent requirement ditangani lewat update spec, bukan patch langsung ke kode). Spec yang tidak dirawat kehilangan fungsinya sebagai sumber kebenaran.

Checklist Kesiapan: Sebelum Menaikkan Level Otonomi

Sebelum menaikkan level otonomi agent (dari approval per langkah ke eksekusi async, atau dari single agent ke multi-agent workflow):

SPEC:
  □ Spec teknis sudah ditulis dengan keempat elemen:
    intent, constraint, acceptance criteria, non-goals
  □ Acceptance criteria ditulis dalam format yang testable
    (bisa diverifikasi pass/fail, bukan pernyataan kualitatif)
  □ Kontrak API/skema data sudah didefinisikan eksplisit
    dan disimpan sebagai file rujukan
  □ Non-goals menyatakan secara eksplisit apa yang di luar scope

TASK:
  □ Task dipecah dengan batas yang selaras dengan dependency nyata,
    bukan sekadar dipotong berdasarkan ukuran
  □ Setiap task punya definition of done yang bisa dicek pass/fail
  □ Dependency antar task sudah dipetakan eksplisit
  □ Scope boundary per task dinyatakan (bukan hanya di level spec)

CONTEXT:
  □ File konvensi project sudah ada dan mencerminkan kondisi aktual
    (bukan basi atau auto-generated tanpa kurasi)
  □ Konvensi project mencakup hal yang perlu diketahui agent
    tanpa harus membaca seluruh codebase dari awal

GUARDRAIL:
  □ Test coverage mencakup semua acceptance criteria utama
  □ Contract test memverifikasi kesesuaian dengan skema yang disepakati
  □ Gate otomatis terpasang sebagai syarat wajib sebelum lanjut task
  □ Kriteria eskalasi ke manusia sudah didefinisikan eksplisit
  □ Lingkungan eksekusi agent terisolasi dari production

MULTI-AGENT (tambahan sebelum membangun orkestrasi):
  □ Single agent dengan task yang didesain baik sudah dicoba
    dan terbukti tidak cukup untuk pekerjaan ini
  □ Sub-pekerjaan yang akan diparalelkan benar-benar independen
  □ State manager tersedia untuk mencegah context hilang di handoff
  □ Pola orkestrasi dipilih berdasarkan kebutuhan, bukan asumsi
    bahwa lebih kompleks berarti lebih baik

Anti-Pattern Lintas Series yang Paling Mahal

Bukan mengulang anti-pattern per artikel, melainkan kombinasi kegagalan yang paling sering muncul bersama dan menghasilkan dampak paling besar:

Spec ambigu + otonomi tinggi + tanpa guardrail. Kombinasi terburuk dari ketiga series — ambiguitas di spec memberi agent ruang interpretasi bebas, otonomi tinggi memungkinkan interpretasi itu dieksekusi jauh sebelum terdeteksi, dan tidak ada guardrail yang menangkap penyimpangan sebelum menjalar. Setiap artikel di kedua series ini pada dasarnya adalah mitigasi untuk satu sudut dari kombinasi ini.

Output agent dipercaya sebagai final tanpa verifikasi independen. Memperlakukan kode yang “terlihat benar” atau “lolos test” sebagai selesai tanpa lapisan verifikasi yang independen dari proses yang menghasilkannya — mengabaikan realita probabilistik yang dibahas di atas.

Spec ditulis sekali, tidak pernah diupdate. Spec yang akurat di awal tapi tidak pernah dirawat seiring kode berubah adalah jebakan yang terlihat baik di awal project tapi memberikan masalah yang makin membesar seiring waktu.

Multi-agent dibangun sebelum single agent dicoba serius. Menambahkan kompleksitas orkestrasi multi-agent sebagai langkah pertama, sebelum ada bukti bahwa satu agent dengan task yang didesain baik tidak cukup — membuang sumber daya untuk koordinasi yang sebenarnya tidak diperlukan.

Emergent requirement ditangani dengan patch langsung tanpa update spec. Setiap requirement baru yang ditangani langsung ke kode tanpa memperbaiki spec terlebih dahulu memperlebar jarak antara spec dan kode aktual, sampai pada titik spec tidak lagi bisa dipercaya sebagai sumber kebenaran.

Context engineering diabaikan sampai ada masalah konsistensi. Mengandalkan agent untuk “tahu sendiri” konvensi project dari membaca kode yang ada, tanpa file context yang eksplisit, menghasilkan konsistensi yang bergantung pada seberapa beruntung eksplorasi awal agent di setiap sesi.

Mengukur Keberhasilan: Sinyal Bahwa Workflow Ini Berjalan Baik

Tidak perlu dashboard yang kompleks. Beberapa sinyal sederhana yang mengindikasikan workflow ini berjalan sehat:

Sinyal positif:

• Spec dan kode tetap sinkron — membaca spec memberi pemahaman akurat tentang perilaku kode, tanpa perlu membaca kode itu sendiri
• Sesi baru bisa dimulai tanpa menjelaskan ulang konteks project dari awal, karena konteks sudah ada dalam file konvensi dan spec
• Ketika ada yang salah, bisa dengan cepat diatribusikan ke spec yang tidak lengkap atau implementasi yang menyimpang dari spec — bukan ke “entah di mana”
• Iterasi yang terjadi konvergen — setiap putaran membawa lebih dekat ke kriteria yang sudah disepakati, bukan berputar di tempat

Sinyal peringatan:

• Spec terakhir diupdate jauh sebelum kode terakhir diubah — kesenjangan ini adalah ukuran seberapa basi spec sudah menjadi
• Agent yang sama menghasilkan inkonsistensi yang sama di sesi-sesi berbeda, yang tidak membaik meskipun sudah “diperbaiki” — tanda perbaikan tidak pernah masuk ke context persisten
• Review deliverable selalu menemukan masalah yang sama berulang kali — tanda acceptance criteria belum cukup spesifik atau gate tidak cukup ketat
• Waktu yang dihabiskan mendebat “apakah ini sudah sesuai requirement” lebih banyak dari waktu yang dihabiskan mengerjakan requirement itu sendiri — tanda spec masih terlalu ambigu

Mulai dari Mana: Jalur Adopsi Bertahap

Untuk tim yang baru memulai, melompat langsung ke multi-agent workflow dengan spec lengkap dan guardrail penuh adalah strategi yang kemungkinan besar akan gagal bukan karena pendekatannya salah, tapi karena terlalu banyak hal baru yang harus dikuasai sekaligus. Urutan yang lebih masuk akal:

Tahap 1 — Mulai dari spec untuk satu fitur kecil. Pilih satu fitur yang scope-nya jelas dan tidak terlalu besar. Tulis spec lengkap dengan empat elemen (intent, constraint, acceptance criteria, non-goals) seperti di Part 2 SDD. Kerjakan dengan cara yang sudah biasa dipakai, tapi gunakan spec itu sebagai rujukan saat mengeksekusi dan memverifikasi. Rasakan bedanya dibanding bekerja tanpa spec.

Tahap 2 — Tambahkan kontrak API/skema data. Begitu spec fitur terasa natural, mulai formalkan kontrak API dan skema data seperti di Part 3 SDD. Ini investasi yang dampaknya langsung terasa ketika bekerja dengan lebih dari satu komponen.

Tahap 3 — Naikkan otonomi agent secara bertahap, dimulai dari task yang paling well-defined. Identifikasi task yang acceptance criteria-nya paling jelas dan coverage test-nya paling kuat. Beri agent otonomi lebih di task ini, sambil tetap menjaga checkpoint review manual untuk task yang lebih kompleks atau berisiko.

Tahap 4 — Bangun file konvensi project. Setelah beberapa fitur dikerjakan, pola apa yang sering perlu dijelaskan ulang ke agent? Dokumentasikan itu di file konvensi seperti di Part 4 Agentic. Ini biasanya investasi yang manfaatnya langsung terasa di sesi berikutnya.

Tahap 5 — Formalisasi guardrail sebagai gate wajib. Pastikan test suite cukup kuat untuk dijadikan gate otomatis yang wajib lolos sebelum task dianggap selesai. Ini kondisi yang harus terpenuhi sebelum menaikkan otonomi lebih jauh.

Tahap 6 — Pertimbangkan multi-agent hanya ketika single agent sudah terbukti tidak cukup. Pada titik ini, sudah ada spec yang matang, context yang terjaga, dan guardrail yang andal — fondasi yang membuat kompleksitas multi-agent bisa dikelola, bukan menambah masalah di atas fondasi yang rapuh.

Tidak ada urutan adopsi yang “wajib” diikuti persis seperti ini. Yang penting adalah prinsipnya: bangun fondasi (spec yang matang dan guardrail yang andal) sebelum menaikkan otonomi, bukan menaikkan otonomi dulu dan berharap fondasi akan terbentuk dengan sendirinya.

Penutup Series

Dua belas artikel ini dimulai dari satu premis sederhana: ambiguitas adalah musuh utama ketika AI agent yang bekerja dengan otonomi makin besar. Spec-Driven Development memberikan mekanisme untuk menyelesaikan ambiguitas itu di depan, dalam bentuk yang persisten dan bisa dirujuk berulang kali. Agentic Development memberikan mekanisme untuk mendelegasikan eksekusi dengan cara yang terstruktur, terverifikasi, dan bisa dikoreksi ketika ada yang salah.

Tapi yang lebih penting dari mekanisme-mekanisme itu adalah pergeseran cara berpikir: dari “saya minta AI menghasilkan X” menjadi “saya mendefinisikan X secara presisi, mendelegasikan eksekusi dengan kontrol yang jelas, dan memverifikasi hasilnya terhadap definisi itu”. Dari “coba sampai terlihat benar” menjadi “iterasi sampai kriteria yang sudah disepakati terpenuhi”. Dari mempercayai output agent sebagai kebenaran menjadi memperlakukannya sebagai hipotesis yang perlu dikonfirmasi.

Pergeseran cara berpikir ini tidak terjadi otomatis dengan menginstal tool tertentu atau mengikuti template tertentu. Ia terjadi ketika, dalam pekerjaan sehari-hari, ada kebiasaan untuk menyelesaikan ambiguitas dalam bentuk tertulis sebelum mendelegasikan eksekusi — dan kebiasaan untuk mengevaluasi hasilnya terhadap kriteria yang sudah ada, bukan terhadap harapan yang terbentuk di kepala setelah melihat hasilnya.

Ringkasan

Dari series Spec-Driven Development:

• Spec adalah sumber kebenaran yang mendahului kode — intent, constraint, acceptance criteria, dan non-goals adalah empat elemen yang selalu ada
• Acceptance criteria yang testable (notasi EARS) bisa langsung diturunkan jadi test case tanpa interpretasi tambahan
• Kontrak API dan skema data (OpenAPI, JSON Schema, Protobuf) adalah spec yang executable — bisa divalidasi otomatis, bukan sekadar dokumentasi
• Spec hidup: update spec adalah bagian dari definition of done, bukan langkah administratif yang bisa ditunda

Dari series Agentic Development:

• Agent coding = loop plan-act-observe dengan tool use; sifatnya probabilistik, bukan deterministik
• Output agent adalah hipotesis, bukan kebenaran — verifikasi berlapis (deterministik + independen) adalah cara mengkonfirmasinya
• Context engineering (file konvensi yang dikurasi, persistent memory, just-in-time retrieval) lebih menentukan konsistensi hasil dibanding prompt engineering per sesi
• Guardrail efektif bekerja sebagai pagar yang membatasi blast radius, bukan penghalang yang mematikan otonomi
• Multi-agent bukan default yang otomatis lebih baik — hanya sepadan ketika kompleksitas pekerjaan benar-benar membutuhkannya

Prinsip yang menyatukan keduanya:

• Pipeline PRD→deliverable bukan abracadabra machine — iterasi tetap ada, tapi terstruktur dan terverifikasi, bukan reaktif dan tanpa arah
• Ambiguitas biayanya proporsional dengan otonomi — selesaikan sebelum mendelegasikan, bukan setelah
• Emergent requirement ditangani lewat update spec terlebih dahulu, bukan patch langsung ke kode
• Bangun spec dan guardrail yang matang sebelum menaikkan otonomi, bukan sebaliknya