Vibe Coding dengan Claude Code: Saya Berhenti Menulis Code

Saya pikir ini cuma hype. Ternyata cara saya ngoding benar-benar berubah.

Beberapa bulan terakhir, istilah vibe coding semakin sering terdengar. Sebuah pendekatan di mana engineer lebih banyak berinteraksi dengan AI melalui prompt, sementara AI menjadi eksekutor utama penulisan code. Artikel ini bukan tentang hype AI, bukan juga tutorial. Ini adalah refleksi jujur dari pengalaman saya menjalani full vibe coding di sebuah project skala besar, dengan real constraint, real bug, dan real pressure.

Masuk di Tengah Badai

Ceritanya dimulai ketika saya di-assign ke sebuah project yang saya sebut Project X. Monorepo besar: Next.js untuk web user, Next.js lagi untuk admin, dan Nest.js di backend. Developer sebelumnya sudah resign, dan saya masuk untuk melanjutkan.

Saat itu, saya tidak punya ekspektasi apa-apa. Bahkan cenderung skeptis. Ini pengalaman pertama saya bekerja full-time dengan Claude Code di project nyata. Yang ada di kepala saya cuma satu: "Ini beneran bisa jalan?"

Hari-hari awal diisi kebingungan. Codebase besar, flow bisnis belum saya pahami, dan saya harus produktif secepat mungkin. Langkah pertama saya sederhana saja. Setup project di local, tanya developer yang masih in charge, dan mulai bertanya langsung ke Claude Code.

Kejutan Pertama: Onboarding dengan AI

Yang tidak saya sangka, Claude Code ternyata sangat membantu proses onboarding. Saya bisa minta dia membaca codebase, menjelaskan flow antar module, bahkan membantu debugging error saat setup. Rasanya seperti punya senior yang sabar dan selalu available.

Pola kerja saya perlahan berubah tanpa saya sadari. Setiap kali ketemu error, alurnya jadi: baca log, kirim ke Claude Code, review hasilnya, test ulang. Bahkan untuk error kecil yang sebenarnya saya pahami, saya tetap minta Claude Code yang memperbaiki.

Di titik ini, saya mulai sadar satu hal: saya tidak lagi menjadi eksekutor utama. Dan anehnya, itu bukan hal yang buruk.

Belajar dari Kesalahan Prompting

Scope utama saya di project ini adalah refactoring module tertentu berdasarkan outstanding issue dari client. Awalnya saya mencoba pendekatan yang mungkin banyak orang lakukan. Satu prompt besar, langsung eksekusi, tanpa Plan Mode. Hasilnya? Sebagian benar, sebagian meleset.

Dari situ saya belajar bahwa task besar wajib pakai Plan Mode. Plan harus di-review sebelum dieksekusi. Ini bukan opsional, ini survival skill.

Keputusan penting lainnya: saya memilih untuk tidak menulis ulang dari nol. Design Figma yang baru tidak terlalu major, code lama sudah berjalan, dan masalah utamanya lebih ke struktur dan componentization. Jadi pendekatan yang lebih masuk akal adalah refactoring bertahap, bukan rewrite.

Yang Benar-Benar Membantu (dan Yang Tidak)

Kecepatan development meningkat drastis, itu fakta. Untuk skenario seperti join mid-project, refactoring bertahap, dan bug fixing dengan repro yang jelas, vibe coding benar-benar powerful. Tapi kecepatan ini punya harga: testing end-to-end harus sangat disiplin. Karena kalau tidak, bug dari AI bisa lolos tanpa terdeteksi.

Dan bicara soal friksi, monorepo Next.js 15 + Nest.js itu sangat memory hungry. Compile time lama, feedback loop melambat. Belum lagi biaya subscription dan limitasi penggunaan model. Kualitas output juga sangat bergantung pada kualitas prompt. Garbage in, garbage out, itu berlaku juga di sini.

Yang paling perlu diwaspadai: AI bisa salah dengan sangat percaya diri. Claude Code cukup sering memberikan solusi yang terlihat benar, tapi salah secara logic. Solusi saya konsisten: copy error atau hasil yang mencurigakan, minta Claude memperbaiki, review ulang. Loop ini harus jadi kebiasaan. AI sangat cepat, tapi dia tidak bertanggung jawab atas dampak dari code yang dia tulis. Itu tetap tanggung jawab kita.

Peran Baru: Bukan Lagi Coder

Di project ini, peran saya bergeser cukup signifikan. Dari coder menjadi reviewer, architect, dan QA. Produktivitas tidak lagi diukur dari seberapa banyak code yang ditulis, tapi dari kualitas arahan, ketajaman review, dan kecepatan validasi hasil.

Ini juga yang membuat saya sadar bahwa prompting bukan no-skill activity. Task besar butuh konteks yang eksplisit, kadang perlu menyertakan link dokumentasi, dan pemilihan model juga berpengaruh. Opus 4.5 lebih akurat tapi mahal, Sonnet 4.5 lebih cepat dan ringan.

Lalu ada satu insight yang mungkin tidak banyak dibahas orang: literasi menjadi bottleneck baru. Prompt itu menulis, review output AI itu membaca. Engineer yang cepat membaca dan menulis akan mendapat leverage AI yang jauh lebih besar. Dan menariknya, bahasa prompt tidak menjadi masalah. Mayoritas prompt saya pakai bahasa Indonesia, dan Claude Code tetap memahami konteks dengan baik. Yang penting bukan bahasanya, tapi kejelasan konteks dan intent.

Dampak ke Karier Engineer

Peran engineer berubah, bukan hilang. Dan dampaknya berbeda di setiap level.

Junior engineer sekarang punya pilihan. Belajar fundamentals dulu baru AI, atau langsung terbiasa dengan AI. Keduanya valid, tapi junior yang melewatkan fundamentals akan kesulitan saat debugging edge case yang AI tidak mengerti, atau saat harus menentukan apakah output AI benar atau hanya terlihat meyakinkan.

Senior engineer justru semakin bernilai. Architecture, system design, decision making under uncertainty, quality control. Ini semua area yang tidak bisa di-outsource ke AI. Skill seperti problem decomposition dan critical thinking jadi lebih valuable daripada syntax recall.

Mid-level engineer berada di posisi paling menarik. Sudah punya cukup fundamentals untuk review AI output, dan bisa leverage AI untuk akselerasi transisi ke senior role.

Penutup

Vibe coding dengan Claude Code membuat kerja jauh lebih cepat. Tapi saya tidak berhenti menjadi engineer. Saya hanya memindahkan energi dari menulis code ke menjaga kualitas keputusan.

Jika ada satu kalimat yang paling menggambarkan pengalaman ini:

Perlakukan AI seperti junior engineer yang sangat cepat dan pintar, tapi tidak bisa membaca pikiran kita.

Semakin jelas konteks yang kita berikan, semakin baik hasil yang kita dapatkan. Tapi lebih penting dari itu: semakin baik kita memahami problem, semakin efektif kita bisa memberikan konteks tersebut.

Konteks adalah segalanya. Dan pemahaman adalah prasyarat untuk konteks yang baik.