TDD di Era Vibe Coding: Kenapa Tim yang Skip Test Duluan Selalu Bayar Mahal Saat Merge
Catatan peer-to-peer untuk CTO dan engineering lead yang timnya ship cepat — kadang terlalu cepat untuk satu reviewer manusia mengikuti — dan mulai merasakan biaya tersembunyi dari mindset “test belakangan aja.”
1. Skenario Senin Pagi yang Terlalu Familiar
Senin, jam 09:42. Dev A merge PR fitur notifikasi email. CI lolos, review lolos, semua aman. Dua menit kemudian Dev B merge PR fitur preferensi user. Sama: CI hijau, review oke, tidak ada warning.
Jam 10:15 customer support mulai ramai di Slack: user yang baru mengubah preferensi email ternyata tidak menerima notifikasi sama sekali.
Setelah diusut:
- PR Dev A menambahkan field
secondary_emailuntuk routing notifikasi. - PR Dev B mengubah UI preferensi, tapi hanya menyimpan ke
primary_email.
Masing-masing PR benar dalam konteksnya sendiri. Tidak ada error. Tidak ada conflict. Tapi ketika dua asumsi berbeda bertemu di production, hasilnya rusak diam-diam — dan baru ketahuan dari user.
Ini bukan kasus langka. Ini Senin pagi di banyak startup yang merge lebih dari lima PR per hari.
Dan di era vibe coding — ketika setiap developer punya beberapa sesi AI berjalan paralel dengan konteks yang berbeda-beda — kasus seperti ini bukan pengecualian lagi. Ini pola default.
Saya sebelumnya pernah menulis soal kredensial yang di-hardcode sebagai salah satu sumber breach paling umum, dan tentang SAST otomatis sebagai safety net di pipeline. Artikel ini membahas lapisan yang lebih mendasar: bagaimana tim memastikan behavior aplikasi tidak berubah diam-diam saat banyak manusia dan AI menulis di codebase yang sama.
Jawabannya mungkin tidak terdengar trendy, tapi sampai 2026 masih tetap relevan: Test-Driven Development.
2. Kenapa Era Vibe Coding Membuat Masalah Ini Meledak
Sebelum AI coding tools jadi mainstream, masalah koordinasi masih relatif sederhana. Lima developer berarti lima konteks. Masih mungkin satu reviewer memahami sebagian besar keputusan teknis yang ada di codebase.
Sekarang?
Lima developer × beberapa sesi AI per hari × agent paralel = puluhan konteks sementara yang menyentuh codebase yang sama setiap minggu.
Setiap sesi AI mulai dari nol. Ia tidak tahu keputusan arsitektur minggu lalu. Tidak tahu kenapa validateOrder muncul di tiga tempat berbeda. Tidak tahu bahwa user.email dipisah dari user.contact_email karena kebutuhan compliance enam bulan lalu.
Dan reviewer manusia juga tidak mungkin mengingat semuanya.
Di titik ini, tidak ada satu manusia atau satu agent pun yang benar-benar punya gambaran utuh.
Yang punya konteks paling konsisten justru test suite.
Test adalah satu-satunya artefak yang bertahan lintas sesi AI, lintas developer, lintas sprint, dan lintas keputusan yang sudah terlupakan. Ia menjelaskan — dalam bentuk yang bisa dieksekusi mesin — behavior apa yang memang harus tetap benar.
Kalau tidak ada test, satu-satunya “spesifikasi” yang tersisa hanyalah kode yang sedang berjalan. Dan itu tidak membantu siapa pun.
3. TDD Itu Sebenarnya Apa?
TDD pada dasarnya sederhana:
- Tulis test untuk behavior yang belum ada.
- Jalankan → test gagal (red).
- Tulis implementasi paling minimal supaya test lulus (green).
- Rapikan/refactor sambil memastikan test tetap lulus.
Yang membedakan TDD dari “nulis test nanti belakangan” adalah urutannya.
Kalau test ditulis setelah implementasi selesai, test cenderung hanya mengonfirmasi apa yang sudah tertulis — termasuk bug dan asumsi salah yang ikut terbawa.
Kalau test ditulis duluan, developer dipaksa menjawab satu pertanyaan penting sebelum coding:
“Behavior yang sebenarnya kita inginkan itu apa?”
Di era AI coding, ini jauh lebih penting dibanding sebelumnya.
AI sangat bagus menulis kode untuk spesifikasi yang jelas.
AI sangat buruk menebak spesifikasi.
Kalau Anda memberikan test yang jelas ke Claude, Cursor, Copilot, atau agent lain, mereka biasanya bisa menghasilkan implementasi yang benar dalam hitungan detik.
Tapi kalau input-nya cuma:
“Buat fitur notifikasi email”
…AI akan menebak. Dan sering kali tebakannya berbeda dengan asumsi yang ada di kepala tim Anda.
TDD adalah cara termurah untuk mengubah intent manusia menjadi kontrak yang bisa dieksekusi mesin.
Begitu kontraknya jelas, AI bekerja sangat efektif. Tanpa kontrak, AI hanya improvisasi.
4. Bagaimana TDD Menyelamatkan Proses Merge
Balik ke skenario Senin pagi tadi.
Kalau Dev A dan Dev B bekerja dengan pola test-first, kemungkinan ceritanya berbeda:
- Test Dev A:
“Ketika user punyasecondary_email, notifikasi terkirim ke kedua alamat.” - Test Dev B:
“Ketika user mengubah preferensi email, semua field email terkait ikut ter-update.”
Saat kedua PR di-merge, CI menjalankan seluruh test suite.
Mungkin masing-masing unit test masih hijau. Tapi begitu ada integration test yang mensimulasikan user flow nyata:
“User update preferensi → user menerima notifikasi”
…barulah konflik antar asumsi muncul.
Dan itu idealnya terjadi sebelum merge, bukan setelah customer komplain.
Di sinilah nilai sebenarnya dari test: ia menjadi frozen intent.
Asumsi Dev A tersimpan di test. Asumsi Dev B juga tersimpan di test. Ketika dua asumsi itu tidak kompatibel, CI yang berteriak lebih dulu.
Bukan production.
5. “TDD Memperlambat Tim” Sudah Tidak Relevan Lagi
Ini keberatan yang paling sering muncul dari CTO:
“Kita harus ship cepat. TDD bikin lambat.”
Argumen itu mungkin masuk akal tahun 2015.
Tidak terlalu relevan di 2026.
Dulu bottleneck utama memang menulis kode. Sekarang AI bisa menghasilkan implementation dalam detik. Yang mahal justru memastikan bahwa implementation tersebut benar.
Dengan kata lain, bottleneck sekarang bukan mengetik kode — tapi mendefinisikan behavior.
Dan TDD membantu memperjelas behavior sebelum AI menghasilkan bug dengan kecepatan tinggi.
Kecepatan tanpa arah bukan progress. Itu cuma cara lebih cepat menumpuk technical debt.
Tim yang merge 50 PR per minggu tanpa test biasanya juga sedang mempercepat akumulasi masalah yang suatu hari harus dibayar mahal:
- outage production,
- customer churn,
- sprint refactor besar,
- atau roadmap yang mandek berbulan-bulan.
Data lama dari NIST dan IBM Systems Sciences Institute masih relevan sampai sekarang: biaya bug naik drastis semakin telat ditemukan. Bug yang ketahuan saat commit mungkin selesai dalam 5 menit. Bug yang sama di production bisa berubah jadi dua hari debugging, customer call, post-mortem, dan kelelahan tim.
CTO yang matang menghitung total cost, bukan cuma biaya di depan.
6. “AI Sudah Bisa Generate Test” — Ya, Tapi Itu Belum Cukup
Banyak tim sekarang bilang:
“Kami sudah pakai AI untuk generate test.”
Masalahnya bukan di siapa yang menulis test. Masalahnya di urutan kerjanya.
Kalau alurnya:
kode dulu → AI generate test
…maka test hanya akan menyesuaikan diri dengan implementasi yang sudah ada. Termasuk bug dan asumsi yang salah.
AI tidak tahu mana behavior yang memang diinginkan dan mana yang kebetulan tertulis di kode.
Sebaliknya, kalau alurnya:
test dulu → AI generate implementation
…dinamikanya berubah total.
Manusia fokus mendefinisikan intent lewat test. AI fokus memenuhi kontrak tersebut.
Implementation salah → test gagal.
Implementation benar → test lulus.
Sederhana.
Test-first juga menjaga manusia tetap memegang kendali pada level yang paling penting: mendefinisikan behavior.
Karena begitu spesifikasi dan implementasi sama-sama diserahkan ke AI, pada akhirnya tidak ada lagi yang benar-benar tahu apa yang sedang dibangun.
7. Workflow yang Benar-Benar Jalan di 2026
Ini workflow yang realistis dipakai tim modern — bukan versi akademis yang hanya bagus di conference slide.
- Developer (atau AI dengan supervisi manusia) menulis test dulu.
- Test dijalankan dan harus gagal.
- AI generate implementation sampai test hijau.
- Refactor sambil menjaga test tetap lolos.
- Reviewer fokus memeriksa apakah test sudah merepresentasikan intent yang benar.
- CI memblok merge kalau ada failed test atau coverage turun.
Yang menarik: workflow seperti ini justru semakin cocok dengan vibe coding.
Karena AI mempercepat implementasi, sementara test menjaga arah supaya kecepatan itu tidak berubah jadi kekacauan.
8. Kenapa Banyak Tim Tetap Gagal Menerapkan Ini
Masalahnya jarang ada di tooling.
Masalahnya hampir selalu ada di eksekusi.
Membangun culture test-first di codebase yang sudah berjalan memang butuh usaha nyata:
- membuat baseline coverage,
- mengatur CI gate,
- memasang pre-commit hook,
- mengubah template PR,
- melatih reviewer untuk membaca intent lewat test,
- dan mengubah prompt AI supaya mulai dari test, bukan implementation.
Ini biasanya makan waktu 4–8 minggu fokus.
Dan di startup, pekerjaan seperti ini hampir selalu kalah prioritas dari feature, sales, fundraising, hiring, atau customer escalation.
Makanya banyak tim tahu pentingnya testing, tapi tetap tidak pernah benar-benar menjalankannya secara konsisten.
9. Apa yang Erasys Kerjakan
Di sinilah engagement Improve Your Vibe-Code App kami biasanya membantu.
Vibe-Code Health Check
Durasi 1–2 minggu.
Kami audit:
- baseline coverage,
- gap di test suite,
- area rawan regresi,
- kualitas CI gate,
- dan pola bug yang kemungkinan besar lolos saat merge.
Output-nya berupa backlog prioritas yang konkret — bukan slide presentasi generik.
Hardening Sprint
Durasi 4–8 minggu.
Kami membantu membangun fondasi:
- baseline test coverage,
- enforcement di CI,
- coverage delta gate,
- pre-commit hooks,
- AI-assisted test scaffolding,
- PR template untuk test-first workflow,
- plus SAST, secret scanning, dan logging structure.
Bukan jualan framework tertentu. Kami sudah bekerja dengan Jest, Vitest, Pytest, Go test, RSpec, sampai JUnit. Fokusnya bukan ideologi tooling — fokusnya memastikan workflow engineering tetap stabil di era AI-assisted development.
10. Mulai dari Audit 30 Menit
Kalau Anda membaca sampai bagian ini, kemungkinan besar Anda sudah curiga coverage dan CI pipeline tim Anda belum cukup kuat untuk volume merge saat ini.
Cara tercepat untuk memastikannya sederhana.
Kirim:
- snippet konfigurasi CI (
.github/workflows,.gitlab-ci.yml, dll), - plus read-only access ke satu branch representatif.
Kami akan review selama 30 menit dan kirim balik:
- tiga risiko terbesar yang kami lihat,
- blind spot di test coverage,
- dan jenis regresi yang saat ini kemungkinan besar lolos ke production.
Audit tertulis. Tanpa sales deck. Tanpa meeting berjam-jam.
Atau email sales@erasysconsulting.com dengan subject:
TDD Audit
Pada akhirnya, biaya mulai testing sekarang hampir selalu jauh lebih murah dibanding biaya Senin pagi ketika production sudah keburu rusak.
Senin pagi itu akan datang ke semua tim.
Pertanyaannya cuma satu: apakah test suite Anda menemukan masalahnya duluan — atau customer Anda?
