Kita Harus Berhenti Menyebut Semua Hal sebagai Vibe Coding

Saya kembali ke pemrograman setelah jeda panjang, dan Lovable adalah tempat saya memulainya lagi. Aplikasinya terlihat bagus, berfungsi pada pandangan pertama, dan selesai dalam beberapa jam. Pada awalnya, hal itu terasa luar biasa. Namun itu tidak cukup lagi ketika saya ingin tahu apa yang dilakukan kode – dan mengapa. Saat itulah pendekatan saya mulai berubah.

Perbedaannya bukan tentang alat, atau seberapa banyak kode yang ditulis AI untuk Anda. Ini tentang kontrak yang Anda terima dengan output Anda: apakah Anda dapat menjelaskan apa yang baru saja Anda dirilis ke dunia, atau tidak.

Vibe coding, dalam arti aslinya, berarti menerima perangkat lunak yang dihasilkan AI tanpa memeriksa atau memahami apa yang berada di bawahnya secara tepat. Pengembangan yang dibantu AI berbeda. Model tersebut masih dapat menulis sebagian besar kode, tetapi orang yang membangun sistem tetap bertanggung jawab untuk memahami perilakunya, menguji asumsi-asumsinya, dan memutuskan apakah sudah siap untuk dirilis.

Untuk percobaan sekali pakai yang tidak pernah keluar dari mesin Anda, perbedaan ini mungkin memiliki sedikit konsekuensi. Begitu perangkat lunak dideploy, digunakan orang lain, atau terhubung ke data nyata, hal ini menjadi sangat penting.

Bagaimana “Vibe Coding” Kehilangan Maknanya

The term “vibe coding” was coined pada Februari 2025 by Andrej Karpathy, co-founder of OpenAI. His example was deliberately casual: a “throwaway weekend project” built by automatically clicking “Accept All,” ignoring the diffs and allowing the code to grow beyond his understanding.

Weeks later, developer and tool-maker Simon Willison noticed the term was being used very differently: sebagai pengganti untuk semua pemrograman yang dibantu AI, which he argued dilutes the term and gives a false impression of what responsible AI-assisted development can achieve.

What’s telling is that Karpathy eventually agreed. Setahun kemudian, ia memperkenalkan istilah yang berbeda for more disciplined work with coding agents. He described “agentic engineering” as a workflow in which developers direct and oversee agents rather than simply accepting what they produce. The distinction matters: professional AI-assisted development requires planning, scrutiny and accountability in ways that casual vibe coding does not.

Garisnya Adalah Tanggung Jawab

Willison’s rule is simple, and it works as a test for anyone: don’t commit code you can’t explain to someone else. That doesn’t mean reading every single line: with agents generating hundreds of lines at once, even experienced developers don’t do that anymore. It means understanding the core logic and being able to justify why the code does exactly what it does. If you can, it doesn’t matter whether a model wrote it or you did: that’s not vibe coding, that’s using a tool to build software.

Penelitian yang dipublikasikan pada Desember 2025 supports that distinction. Drawing on field observations and a qualitative survey of professional developers, the researchers found that experienced practitioners retained control over software design and implementation rather than handing the entire process to AI. They treated agents as collaborators, planned their work carefully and remained involved in oversight.

So, experience alone doesn’t explain it. It’s about whether you’re willing to take responsibility for what AI generated. That’s a decision every developer makes over again on every project.

Apa yang Terjadi Ketika Kontrol Hilang

The consequences of releasing software without understanding or verifying its security aren’t abstract. Tea, an app meant to help women stay safe while dating, mengungkapkan puluhan ribu foto ID dan lebih dari satu juta pesan pribadi dalam dua insiden keamanan. The failures included an unsecured storage bucket and a separate database accessible without authentication.

The same underlying problem – software appearing to work while its authorization logic remained dangerously wrong – showed up in an application built on the Lovable platform: penelitian keamanan menemukan logika otorisasi terbalik, locking out logged-in users while letting unauthenticated attackers in freely, affecting more than 18,000 users, including students.

These aren’t isolated cases that only happen to “bad” projects. According to laporan DORA Google 2025, 90% of developers now use AI at work, while roughly a third report little or no trust in what it generates.

AI use is now widespread, even though trust remains limited. And that makes careful review especially important when generated code handles authentication, permissions or sensitive data.

Kontrol Dibangun Berlapis, Bukan Sekaligus

In my case, I didn’t begin with a formal security audit. I simply refused to move on whenever I could not explain why something behaved the way it did – a natural instinct I bring to work as an analyst. I care less about the syntax than whether the result matches what we originally needed. When it doesn’t, I keep digging.

My workflow became more structured as the projects became more serious. Instead of relying on prompts alone, I began preparing specifications before generating anything. I documented the business requirements, tech stack and integrations. Then came unit tests and Playwright tests for the main user journeys.

Security checks were added in much the same way. I reviewed the libraries the AI selected and introduced malware scanning for uploaded files. Each check came from asking what could go wrong next, rather than following a control list I had prepared at the beginning.

That habit caught a problem on one project. The AI introduced a library that was incompatible with the framework version I was using. The application had not failed outright, so the incompatibility could easily have remained unnoticed. Finding it later would have made the cause far harder to identify.

Compared with the Tea and Lovable cases, this was an ordinary problem. I found it early, fixed it and moved on. That is what review usually looks like in practice. Most of the time, it prevents small problems from growing into larger ones.

I don’t distrust code simply because AI produced it. I also don’t trust it simply because the application runs. Tests and review are how I establish whether it behaves as intended.

Dari Vibe Coding ke Agentic Engineering

Karpathy’s own move away from “vibe coding” toward “agentic engineering” isn’t just a change in vocabulary. “Agentic engineering” gives us a more useful name for the direction professional development is taking. Developers may write fewer lines themselves, but that does not reduce their responsibility. It shifts their work toward specifying what the system should do, directing agents, testing their output and deciding what is safe to release.

Bahaya bukan bahwa AI menghasilkan kode dengan cepat. Bahayanya adalah bahwa generasi dapat bergerak lebih cepat daripada pemahaman. Ketika hal itu terjadi, produktivitas yang tampak menyembunyikan risiko yang tidak ada yang memeriksanya dengan tepat.

Aturan yang Patut Dipertahankan

Stop using “vibe coding” as a label for every form of AI-assisted development – it dilutes the term and erases a distinction in control that matters. Set a simple rule: do not ship what you cannot explain. And build control into the project as it grows, layer by layer, adding checks in step with the risks that emerge.

AI dapat menulis sebagian besar kode. Ia tidak dapat mengambil tanggung jawab untuk merilisnya. Itu tetap menjadi tanggung jawab kami.