Setelah Dua Tahun Vibe Coding, Seorang Engineer Kembali Menulis Kode dengan Tangan

Perjalanan seorang engineer dengan AI coding biasanya dimulai dengan kekaguman. Anda memberikan tugas sederhana ke model, hasilnya memuaskan. Anda memberikan tugas yang lebih besar, hasilnya semakin mengesaskan. Tapi setelah dua tahun menjalani siklus ini, seorang engineer yang menulis di Substack-nya mengambil keputusan yang mengejutkan: kembali menulis kode dengan tangan. Bukan karena AI tidak canggih, melainkan karena ada batas fundamental dalam cara agent memahami konteks dan struktur keseluruhan sistem.

Refleksi ini menjadi peringatan bagi developer yang sedang mengandalkan vibe coding sepenuhnya. AI memang hebat untuk unit of work tertentu, tapi respect untuk arsitektur keseluruhan seringkali tidak ada. Dan ketika kode yang Anda bangun menjadi fondasi produk yang digunakan orang lain, absennya arsitektur yang koheren bisa menjadi masalah serius.

Kurva Belajar Vibe Coding

Sebagian besar engineer serius yang menggunakan AI untuk pekerjaan nyata mengikuti pola perkembangan yang bisa diprediksi. Mereka mulai dengan tugas kecil, lalu mencoba memberikan tugas yang lebih besar secara bertahap. Mungkin refactor yang sudah lama ditakuti, atau fitur kompleks yang membutuhkan sentuhan di banyak file sekaligus. Pada titik awal, produktivitas terasa meningkat drastis. Waktu yang biasanya dihabiskan untuk menulis boilerplate kini bisa dialokasikan untuk desain dan testing.

Namun pada titik tertentu, model mulai menunjukkan perilaku yang membingungkan. Di satu sisi, model terlihat sangat memahami konteks yang diberikan. Di sisi lain, ia membuat keputusan yang bertentangan dengan pemahaman bersama yang telah dibangun dalam sesi panjang sebelumnya. Engineer mulik menyalahkan diri sendiri: prompt yang kurang spesifik, kurangnya konteks, atau spesifikasi yang ambigu.

Akibatnya, banyak yang beralih ke pendekatan spec-driven development dengan AI. Mereka menghabiskan waktu berjam-jam menyusun dokumen spesifikasi yang sangat detail, lalu memberikannya ke agent. Namun pendekatan ini juga menemui jalan buntu yang tidak terduga.

Kegagalan Spec-Driven Development dengan Agent

Dalam dunia nyata, dokumen desain dan spesifikasi adalah living documents. Mereka berevolusi seiring discovery selama implementasi. Bayangkan Anda menulis dokumen arsitektur selama satu jam untuk fitur kompleks, lalu menyerahkannya kepada engineer mid-level dengan instruksi untuk tidak berdiskusi dengan siapa pun, lalu pergi berlibur. Itulah yang sebenarnya terjadi saat kita memberikan spec panjang kepada agent dan mengharapkannya menyelesaikan tugas tanpa iterasi aktif.

Agent tidak memiliki kemampuan untuk mengevolusikan spesifikasi selama periode multi-minggu. Mereka membuat keputusan di awal dan kemudian tidak menyimpang dari jalur tersebut, meskipun temuan selama implementasi seharusnya mengubah arah desain secara fundamental. Hasilnya adalah kode yang terlihat benar secara sintaksis, tapi salah secara semantik dalam konteks sistem yang lebih luas.

Lebih parahnya, agent modern cenderung memaksa diri melewati hambatan daripada mengakui bahwa solusi perlu direvisi. Mereka menghasilkan kode yang terlihat plausible saat ditulis, bahkan saat direview dalam pull request, karena baik manusia maupun agent sudah dilatih untuk membuat PR yang terlihat rapi dan komprehensif.

Fenomena Slop dalam Kode AI

Engineer tersebut menggambarkan pengalamannya dengan istilah slop: kode yang terlihat baik secara isolasi, tapi menjadi kekacauan ketika dibaca sebagai keseluruhan sistem. Agent menulis unit perubahan yang konsisten dengan prompt dan dirinya sendiri, tapi tidak memiliki respect terhadap structural integrity atau neighboring patterns dalam codebase yang sudah ada sebelumnya.

Hasilnya mirip dengan novel yang ditulis AI secara per paragraf. Setiap paragraf terbaca baik secara individual, tapi ketika disatukan menjadi bab, ceritanya tidak masuk akal. Karakter berperilaku inkonsisten, plot hole bermunculan, dan arah narasi terasa seperti digabungkan dari potongan-potongan yang tidak saling berbicara. Ketika engineer tersebut membuka seluruh codebase dan membacanya dari awal hingga akhir, ia terkejut: di mana datangnya semua gunk ini?

Setelah membaca kumulatif berbulan-bulan kode agent yang dihasilkan dari spec yang sangat rinci, engineer ini mengambil keputusan tegas: I am not shipping this. Ia tidak mau membebankan kode tersebut kepada user, tidak mau menjanjikan keamanan data dengan fondasi yang rapuh, dan tidak mau berbohong kepada user dengan produk yang secara internal adalah kekacauan yang tidak bisa diandalkan.

Mengapa Menulis dengan Tangan Lebih Baik

Keputusan untuk kembali menulis kode dengan tangan ternyata membawa hasil yang tidak terduga. Engineer tersebut menyatakan bahwa ia menjadi lebih cepat, lebih akurat, lebih kreatif, lebih produktif, dan lebih efisien dibandingkan dengan menggunakan AI, ketika semua faktor diperhitungkan secara menyeluruh, bukan hanya token per jam.

Alasannya sederhana: menulis kode dengan tangan memaksa otak untuk memahami sistem secara end-to-end. Anda tidak hanya menyusun prompt, Anda menyusun arsitektur. Anda merasakan friction dari desain yang buruk sejak awal, bukan setelah agent menghasilkan ribuan baris kode yang harus direfactor kemudian. Anda memiliki ownership penuh terhadap setiap keputusan desain, dan keputusan itu terintegrasi dengan visi keseluruhan produk.

Apa yang Bisa Dipetik Developer Indonesia?

Bagi developer Indonesia yang sedang dalam fase vibe coding, refleksi ini bukan berarti menolak AI sama sekali. Beberapa takeaway praktis yang bisa diterapkan:

• Gunakan AI untuk scaffolding dan boilerplate, bukan untuk arsitektur kompleks yang memerlukan pemahaman domain mendalam.

• Selalu review keseluruhan codebase setelah agent selesai bekerja, bukan hanya diff per file dalam pull request.

• Jangan percaya PR yang terlihat rapi tanpa memahami konteks sistemik dari perubahan tersebut.

• Pertimbangkan untuk menulis ulang fitur krusial dengan tangan jika agent menghasilkan kode yang terlalu kompleks, tidak intuitif, atau tidak konsisten dengan codebase existing.

• Gunakan AI sebagai pair programmer, bukan sebagai pengganti programmer. Diskusi dan iterasi aktif masih diperlukan.

AI adalah alat yang luar biasa, tapi tetap alat. Arsitektur software yang baik masih memerlukan judgment, konteks historis, dan tanggung jawab manusia. Vibe coding bisa menjadi titik awal yang bagus, tapi jangan biarkan vibe menggantikan pikiran kritis yang menjadi fondasi engineering yang baik.

Sumber: atmoio Substack