Saya sangat sibuk dengan pekerjaan pengembangan outsource sehingga belum bisa posting dalam waktu lama, kemarin saya tidur terlalu awal sehingga bangun terlalu pagi, dan setelah lama akhirnya saya membagikan obrolan kecil yang tidak penting. 😁

Agile yang Terlihat Menggugah Selera

Dalam rekayasa perangkat lunak, jarang ada kata yang dipuji segencar dan dikutuk setatam Agile selama 20 tahun terakhir.

"Merespons perubahan dengan gesit", "Memprioritaskan perangkat lunak yang bekerja daripada dokumentasi", "Menghargai individu dan interaksi". Pernyataan dari Manifesto Agile 2001 begitu mulia. Namun, realitas Agile yang dihadapi di lapangan berbeda.

Banyak organisasi mengimplementasikan Agile dengan menjalankan daily scrum yang setiap pagi mengumpulkan developer untuk menggali apa kesalahan yang mereka buat kemarin, dan terobsesi dengan menggeser tab status ticket di Jira. Yang terburuk adalah "karena kami menggunakan Agile, kami bisa mengubah rencana setiap hari" yang dikombinasikan dengan kontrol "tanggal peluncuran tidak bisa ditunda" gaya Waterfall, menciptakan Agile palsu. Dalam keadaan di mana cakupan dan waktu terikat bersamaan, perubahan persyaratan yang mengamuk diterima dengan tubuh developer melalui lembur dan burnout. Agile palsu tanpa fondasi rekayasa adalah buah yang terlihat menggugah selera namun sebenarnya hambar, cara yang sah untuk memeras developer.

Pada periode yang sama, DDD (Domain Driven Design) dan TDD (Test Driven Development) dianggap sebagai teori menara gading atau barang mewah yang hanya dinikmati big tech. Di medan perang di mana rencana bisa terbalik besok pagi dan tenggat waktu minggu depan, tindakan membagi batas domain secara ketat dan menulis test yang gagal sebelum kode sebenarnya dianggap sebagai overhead.

Pada tahun 2026 saat ini, paradigma telah berubah. Era vibe coding telah tiba di mana LLM memahami perintah bahasa alami dan menuangkan kode yang dapat dijalankan dalam hitungan detik. Ironisnya, dalam era di mana manusia tidak lagi mengetik secara langsung tetapi membangun perangkat lunak hanya dengan niat, Agile palsu yang menyiksa developer di masa lalu dan DDD, TDD yang dianggap barang mewah akhirnya mulai menyatu dalam satu ekosistem dan mendapat substansi.

Mari kita lacak penyatuan itu. Namun ada satu hal, artikel ini bukan membicarakan solusi yang ampuh untuk semua. Ada wilayah di mana metodologi tersebut bekerja, dan ada juga wilayah di mana penerapannya sulit. Kami juga mempertimbangkan batas itu.

DDD (Domain Driven Design), Kompas untuk Menyuntikkan Bahasa Umum ke AI

Di era vibe coding, pekerjaan utama developer bukan mengetik sumber dengan keyboard. Tugas inti adalah mengkomunikasikan persyaratan bisnis dan maksud arsitektur dengan jelas kepada agen AI. Di sini, DDD menjadi kompas yang mengurangi halusinasi AI dan menarik kode yang akurat.

Penemuan Kembali Bahasa Universal

Ada masalah yang dialami setiap developer yang pernah memerintahkan AI. Jika mencampur kata-kata berbeda dalam prompt untuk konsep yang sama, AI salah memahami konteks dan membuat skema dan aliran data yang keliru.

Pertama, bahasa universal (Ubiquitous Language), praktik inti dari DDD, adalah kamus istilah ketat yang digunakan dengan arti sama oleh ahli domain, perencana, dan developer.

Misalnya, katakanlah membuat mesin pencarian lokal yang mencari sesi agen AI. Jika memberitahu AI "potongan percakapan", "skor pencarian", "menggabungkan hasil" secara samar, AI setiap kali mengeluarkan nama variabel sembarangan seperti chunk, segment, score, rank, merge dan aliran data yang kusut.

Namun, ketika mendefinisikan istilah domain dan menyuntikkan ke dalam struktur system prompt AI, semuanya berbeda.

• Session: Satu percakapan yang dibagikan dengan agen terminal

• Chunk: Potongan sesi yang dipotong per unit pencarian. Mencakup tumpang tindih

• BM25 score: Skor kecocokan kata kunci berbasis morfem

• Vector score: Skor kecocokan semantik berbasis embedding

• RRF: Cara penggabungan peringkat yang menyatukan dua skor

Sekarang, jika developer hanya melempar "Saat memotong Chunk, tulis adapter yang mengatur bagian tumpang tindih berdasarkan hasil tokenizer Lindera sehingga batas morfem bahasa Korea tidak rusak", AI menghasilkan kode yang sesuai dengan aturan domain dalam bahasa universal. DDD sangat mengurangi biaya komunikasi dengan AI.

Desain Strategis dan Isolasi Subdomain

Tidak peduli sebaik apa LLM, tidak mungkin memahami seluruh kode monolitik ribuan baris sekaligus dan menghasilkan revisi sempurna. Hal ini karena keterbatasan jendela konteks, konsumsi token, dan penurunan konsentrasi.

Strategi Bounded Context dari DDD membagi sistem besar menjadi batas yang terisolasi secara independen. Mengambil mesin pencarian sebagai contoh, terbagi seperti ini.

• Core Domain: Mesin pencarian hibrida. BM25 + vektor + RRF (src/search/)

• Supporting Domain: Parser sesi. Menangani format log Claude Code / Codex / Gemini masing-masing (src/parser/)

• Generic Domain: Output vault yang kompatibel dengan Obsidian (src/vault/)

Ketika batas terisolasi, tidak perlu memberi AI seluruh proyek untuk dibaca. Dengan hanya memberi tahu definisi tipe dari core domain pencarian, Anda bisa memberikan perintah yang sempit dan mendalam "sesuaikan konstanta k dalam penggabungan RRF di sini dan pisahkan logika normalisasi antara skor BM25 dan vektor".

DDD adalah alat strategis yang mengiris proyek besar menjadi ukuran yang dapat dicerna AI.

Ada satu hal yang perlu diperhatikan di sini. Ada proyek di mana batas domain terbagi dengan rapi, dan ada juga yang tidak. Sistem seperti mesin pencarian dengan tanggung jawab yang jelas memiliki batas yang terbagi dengan baik. Namun, proyek dalam tahap eksplorasi awal di mana domain itu sendiri masih tidak pasti menarik batas sebelumnya malah bisa mengikat tangan. DDD adalah alat yang mengeluarkan kekuatannya setelah domain agak terkunci.

TDD (Test-Driven Development), Sabuk Pengaman untuk Menghentikan Pelarian AI

Berkat terbesar vibe coding adalah kecepatan, tetapi bencana terbesarnya adalah kesalahan regresi yang disemburkan oleh AI. AI menghasilkan puluhan baris kode yang terlihat sempurna secara sintaktis tetapi memuntahkan kesalahan runtime dalam edge case tertentu, atau diam-diam merusak fitur inti yang bekerja dengan baik.

Praktik yang menempatkan rel pengaman pada pelarian ini adalah TDD.

Dari Penulis Teks ke Validator

TDD di masa lalu adalah pengulangan kerja manual di mana developer membayangkan logika → menulis test (Red) → implementasi (Green) → perbaikan (Refactor). Itulah mengapa tidak disambut baik di lingkungan di mana kecepatan adalah kehidupan.

Alur TDD di era vibe coding berubah.

[Manusia] Mendefinisikan tujuan bisnis (prompt test yang gagal)
  │
  ▼
[AI] Menulis implementasi supercepat untuk lulus test (Green)
  │
  ▼
[Manusia+AI] Jalankan semua test yang ada untuk validasi regresi dan refactor

Developer tidak mengetuk keyboard sepanjang malam untuk implementasi. Alih-alih, mereka pertama kali membuat rel pengaman bersama AI dengan mengatakan "tulis unit test yang memvalidasi bahwa ketika menggabungkan skor BM25 berbasis analisis morfem dari query bahasa Korea dan skor vektor BGE-M3 dengan RRF, dokumen jawaban masuk dalam 5 teratas".

Setelah itu, implementasi diserahkan kepada AI. Tidak peduli apakah AI menulisnya dengan berantakan atau cemerlang. Set test yang menjelaskan aturan domain sudah ada. Ketika semua test menjadi Green, Anda mendapatkan kepercayaan untuk mengurangi keraguan dan menerapkan kode yang ditulis AI.

Menghilangkan Ketakutan Refactor

Ketika mengembangkan dengan AI, kode spageti diproduksi dalam jumlah besar dan utang teknis menumpuk. Ketika kode menjadi kompleks, fenomena "tidak bisa memperbaiki yang sudah ada karena takut rusak" terjadi.

Di lingkungan di mana TDD telah dibangun, refactoring menjadi aman. Anda dapat memberikan perintah seperti "ubah indeks vektor dari sqlite-vec ke usearch HNSW sambil mempertahankan semua test pencarian yang ada tetap pass". Ketika AI merevolusi struktur indeks, jalankan test runner untuk validasi. TDD adalah rel pengaman yang menjinakkan kuda liar bernama AI.

Namun ada batas di sini juga. TDD kuat di area di mana input dan output didefinisikan dengan jelas. Area seperti akurasi pencarian, hasil parsing, transformasi data adalah seperti itu. Sebaliknya, di area di mana output subjektif atau jawaban tidak jelas, misalnya kualitas dokumen wiki yang dihasilkan LLM atau perasaan penggunaan UI, sulit untuk menempatkan rel pengaman test. Di daerah seperti itu, mata manusia harus tetap menjadi validator. TDD tidak memvalidasi segalanya secara otomatis.

Agile, Kelincahan yang Mekar dengan Biaya Implementasi yang Menurun

Alasan mendasar mengapa Agile di masa lalu menjadi buah yang terlihat menggugah selera adalah mengabaikan hukum segitiga (cakupan-waktu-biaya), dan kecepatan rencana berubah tidak bisa diikuti oleh kecepatan mengetik developer. Kesenangan perencana adalah bencana bagi developer.

Agile di era vibe coding di mana mengamankan konteks dengan DDD dan mengenakan sabuk pengaman dengan TDD akhirnya menyelesaikan pekerjaan rumahnya.

Penurunan Biaya Perubahan Persyaratan

Dalam rekayasa tradisional, adalah pengetahuan umum bahwa biaya melonjak semakin banyak perubahan persyaratan terjadi di tahap kemudian. Ini karena arsitektur kusut, data rusak, dan manusia harus menganalisis ulang.

Di lingkungan vibe coding, biaya ini turun secara signifikan.

Siklus pengulangan "mengubah rencana dan segera menggabungkan feedback ke produk" yang tidak mungkin di masa lalu menjadi mungkin tanpa mengorbankan darah developer.

Namun, memang benar bahwa AI menulis kode implementasi dengan cepat, tetapi pekerjaan menyempurnakan domain, merancang test, dan memvalidasi hasil masih membutuhkan waktu dan penilaian manusia. Bahkan, proporsi pekerjaan itu menjadi lebih besar. Biaya mengetik yang hilang digantikan oleh biaya desain dan validasi. Botol leher perubahan bergeser dari mengetik ke pemikiran.

Namun transisi ini besar. Agile tidak lagi menjadi alat yang memeras developer, tetapi strategi yang mengurangi ketidakpastian bisnis dengan biaya implementasi yang menurun dan memberikan produk yang berkembang secara real-time.

Skenario Praktis Trinitas

Mari kita lihat bagaimana DDD, TDD, Agile, dan vibe coding benar-benar saling terhubung dalam skenario konkret.

Katakanlah Anda sedang mengembangkan mesin pencarian lokal yang mencari sesi agen AI. Suatu hari, proposal fitur masuk melalui GitHub issue.

Issue: Saat mengingesti sesi, ekstrak baris pertama sebagai ringkasan
dan secara otomatis masukkan ke frontmatter sehingga pratinjau
dimungkinkan di hasil pencarian.

Jika dulu, Anda akan menghabiskan berhari-hari bertanya apakah parser seluruh harus diperiksa ulang. Tim yang siap bergerak berbeda.

Langkah 1: Spesifikasi dengan DDD dan Isolasi

Memurnikan permintaan menggunakan istilah domain. Summary diekstrak dari baris pertama yang sebenarnya dari sesi, melewati baris kosong dan salam, frontmatter menerapkan escape YAML, file vault yang ada hanya memodifikasi wilayah frontmatter dan badan tetap tidak berubah. Suntikkan spesifikasi ini bersama definisi tipe dari domain parser ke AI. Domain inti pencarian dan output vault tidak tersentuh.

Langkah 2: Tulis Rel Pengaman yang Gagal dengan TDD

Minta AI menulis test yang gagal terlebih dahulu. Sesi yang dimulai dengan baris kosong, sesi yang hanya berisi salam, baris pertama yang berisi karakter khusus YAML. Buat set test yang memvalidasi bahwa summary diekstrak dan di-escape dengan benar dalam edge case ini. Implementasi tidak ada, jadi tentu saja Red.

Langkah 3: Implementasi dengan Vibe Coding

Berikan vibe kepada AI. "Buat test ekstraksi summary yang baru saja dibuat lulus dengan menambahkan logika generasi frontmatter ke pipeline ingesti. Jangan bentrok dengan alur reindex yang ada." AI menulis implementasi dalam puluhan detik. Jalankan test runner, dan test lama dan baru semua Green. Terbukti bahwa memodifikasi parser tidak merusak inti pencarian dan output vault.

Langkah 4: Penerapan Agile dan Feedback

Setelah validasi, merge dan deploy. Balas ke orang yang membuka issue "Terima kasih atas saran. Langsung kami implementasikan", dan sarankan perintah backfill yang mengisi summary di vault yang sudah ada. Bahkan jika pengusul melempar permintaan lain, cukup buka prompt window.

Kembali ke Esensi Rekayasa Pengembangan

Kedatangan era vibe coding bukan akhir dari pengembangan perangkat lunak. Ini adalah sinyal bahwa mengetik sebagai pekerjaan sederhana berakhir dan proporsi desain dan rekayasa meningkat.

Agile palsu tetap menjadi buah yang terlihat menggugah selera karena tidak memiliki arsitektur (DDD) dan infrastruktur validasi (TDD) dan kecepatan implementasi (AI) untuk mendukungnya. Ini adalah hasil teknologi yang tidak bisa mengikuti ideal.

Sekarang senjatanya agak terpenuhi.

• Dengan DDD, bangun ketertiban konseptual untuk berkomunikasi dengan AI

• Dengan TDD, buat rel pengaman untuk mengontrol pelarian AI

• Di atasnya, wujudkan Agile dengan mesin implementasi AI untuk menembus ketidakpastian

Namun ketiga hal ini bukan obat mujarab. DDD mengeluarkan kekuatannya setelah domain terkunci, TDD kuat di area di mana jawaban jelas, dan Agile menurunkan biaya perubahan tetapi tidak menghilangkannya. Orang yang mengerti wilayah operasi dan keterbatasan alat adalah orang yang menggunakan alat sebagai alat.

Di tempat biaya mengetik menghilang, desain dan validasi dan penilaian tetap tinggal. Tempat itu pada akhirnya adalah pekerjaan manusia. Menjalankan pengembangan tanpa rencana bukan vibe coding. Ini adalah kolaborasi di mana pengetahuan domain manusia dan pekerjaan AI yang tidak pernah lelah saling terhubung. Saatnya meninggalkan buah yang terlihat menggugah selera dan kembali ke esensi rekayasa.