Category: Vibe Coding

Saya pernah push kode ke production yang 80% di-generate AI tanpa review yang proper. Seminggu kemudian ada bug yang malu-maluin — bukan karena AI-nya salah, tapi karena saya tidak review dengan teliti.

Cerita ini probably familiar buat developer yang sekarang heavy pakai Cursor, Claude, atau tools sejenisnya. Kode datang cepat, kelihatan masuk akal, test lokalnya jalan — lalu masuk production dan… surprise.

Artikel ini soal bagaimana saya sekarang approach review kode yang di-generate AI. Bukan paranoid, bukan reject semua — tapi punya filter yang sistematis.

Kenapa Kode AI Perlu Review Khusus?

Kode yang di-generate AI punya karakteristik yang beda dari kode yang ditulis manusia:

AI optimize untuk kelihatan benar, bukan untuk benar secara kontekstual. Model ditraining untuk generate kode yang syntactically valid dan secara umum correct — tapi dia tidak tau spesifik konteks bisnis, constraint sistem, atau legacy quirk di codebase kamu.

AI sering “confident” walau salah. Tidak ada tanda tanya atau disclaimer. Kode yang salah keluar dengan format yang sama rapinya seperti kode yang benar.

AI bisa pakai pattern yang outdated. Kalau training data-nya banyak kode 2022, dia mungkin generate pattern yang di 2026 sudah ada cara yang lebih baik atau bahkan deprecated.

AI tidak tau apa yang kamu tidak bilang. Kalau kamu tidak mention bahwa “ini akan dipanggil bersamaan oleh ribuan user,” dia tidak akan concern soal race condition atau thread safety.

Framework Review: CSPE

Saya pakai akronim sederhana buat ingat checklist ini: CSPE — Correctness, Security, Performance, Edge Cases.

C — Correctness (Kebenaran Logika)

Ini layer pertama dan paling obvious, tapi sering dilewat karena kode kelihatan benar.

Pertanyaan yang perlu dijawab:

• Apakah logic-nya sesuai dengan requirement yang sebenarnya? (Bukan requirement yang kamu tulis di prompt, tapi requirement bisnis yang sebenarnya)
• Apakah tipe data di-handle dengan benar? (Integer vs float, null vs undefined, dll)
• Apakah urutan operasi sudah benar?
• Kalau ada loop, apakah boundary condition-nya tepat?

Red flag umum: Kode yang pakai == padahal butuh === (di JavaScript), atau asumsi bahwa array selalu ada isinya, atau integer division yang harusnya float division.

S — Security

Ini area paling berbahaya dari kode AI-generated karena security vulnerability sering tidak ketahuan sampai dieksploit.

Checklist security dasar:

• SQL/NoSQL injection: Apakah input user langsung dimasukkan ke query tanpa sanitasi?
• XSS (Cross-Site Scripting): Apakah output di-render langsung ke HTML tanpa escape?
• Hardcoded credentials: AI kadang masukkan example credential di kode yang lupa dihapus
• Insecure deserialization: Hati-hati kalau ada eval() atau deserialization dari input untrusted
• Path traversal: Operasi file system yang terima input user perlu validasi ketat
• Overexposed API: Endpoint yang harusnya authenticated tapi dibiarkan open

Tips: Untuk codebase production, run SAST (Static Application Security Testing) tool setelah generate kode AI. Ini bukan paranoia — ini standard practice.

P — Performance

Kode yang functionally benar bisa tetap jadi masalah kalau performance-nya buruk.

Yang perlu dicek:

• N+1 query problem: Terutama di ORM — AI sering generate kode yang query database di dalam loop
• Unnecessary loops: O(n²) algorithm padahal ada cara O(n log n) atau lebih baik
• Memory leak: Terutama di listener, interval, atau subscription yang tidak di-cleanup
• Blocking operation: Operasi sync yang harusnya async, terutama di environment Node.js
• Missing index: Query yang efisien di kode tapi lemot di database karena kolom yang di-query tidak di-index

E — Edge Cases

AI generate kode untuk “happy path” — input yang normal dan expected. Edge cases sering dilewat.

Edge cases yang sering miss:

• Input kosong (empty string, null, undefined, empty array)
• Input yang sangat besar (what happens kalau array-nya punya 1 juta item?)
• Concurrent access (apa yang terjadi kalau dua request datang bersamaan?)
• Network failure (kalau API call gagal, apa yang terjadi?)
• Timezone dan locale issues (tanggal dan waktu sering jadi source bug)
• Unicode dan special characters

Mindset yang Benar: Trust but Verify

Saya pernah terlalu paranoid — review setiap baris kode AI sekomprehensif kode yang saya tulis sendiri. Itu terlalu lambat dan menghilangkan benefit dari AI.

Sekarang saya pakai gradasi berdasarkan risiko dan kompleksitas:

Kode boilerplate / utility sederhana: Light review. Kalau logic-nya straightforward (sort array, format string, simple calculation), cukup scan sekilas dan test.

Business logic: Full CSPE review. Ini yang handle aturan bisnis, kalkulasi kritis, atau user data — harus di-review teliti.

Security-sensitive code: Extra paranoid. Authentication, authorization, encryption, data sanitasi — ini di-review dua kali dan kalau bisa minta second opinion.

Infrastructure / deployment code: Jangan terlalu rely on AI. Kode yang manage server, database migration, atau infra — ini area di mana AI paling sering beri saran yang terlihat valid tapi ada subtle issue.

Workflow Review yang Praktis

1. Baca dengan Tujuan, Bukan Sekadar Scan

Jangan sekadar baca kode dari atas ke bawah sambil angguk-angguk. Baca dengan pertanyaan spesifik di kepala: “Di mana titik yang bisa fail?” “Input apa yang bisa membuat ini rusak?”

2. Trace Execution Path Secara Mental

Pilih satu atau dua input kasus, trace step by step apa yang terjadi. Ini exercise yang powerful untuk temukan bug logika.

3. Minta AI untuk Review Kode-nya Sendiri

Ini underutilized tapi efektif:

> “Review kode yang baru kamu generate ini. Fokus ke: potential security vulnerabilities, edge cases yang mungkin tidak di-handle, dan performance bottleneck yang mungkin ada. Be critical.”

AI yang bagus akan menemukan masalah di kode-nya sendiri kalau kamu minta dengan prompt yang tepat.

4. Run Tests

Ini obvious tapi perlu disebut. Kalau belum ada unit test untuk bagian yang di-generate, tulis minimal beberapa test case — termasuk edge cases — sebelum merge.

5. Deploy ke Staging Dulu

Jangan pernah langsung ke production. Environment staging itu bukan formalitas — itu safety net.

Yang Paling Sering Saya Temukan

Dari pengalaman review kode AI, ini pattern masalah yang paling sering muncul:

1. Missing error handling — Try/catch yang tidak ada, atau error yang di-catch tapi tidak di-handle dengan benar
2. Async/await yang salah — Promise yang tidak di-await, atau await yang dipakai di tempat yang salah
3. Mutasi state yang tidak disengaja — Terutama di objek yang di-pass by reference
4. Hardcoded values — Magic number atau string yang harusnya jadi constant atau config
5. Missing input validation — Asumsi bahwa input selalu valid dan dalam format yang diharapkan

Kesimpulan

Review kode AI bukan soal paranoia atau tidak percaya teknologi. Ini soal tanggung jawab profesional. Kamu yang push kode ke production — kamu yang bertanggung jawab atas kode tersebut, bukan AI yang generate-nya.

Dengan framework CSPE dan mindset “trust but verify”, kamu bisa dapat keuntungan kecepatan dari AI tanpa mengorbankan kualitas dan keamanan kode.

---

Tim kamu mulai heavy pakai AI untuk coding dan butuh panduan review process yang solid? Atau mau diskusi soal best practice vibe coding yang aman untuk production? Yuk ngobrol — hubungi mafadev dan kita susun prosesnya bareng.

Saya ingat persis momen itu. Jam 11 malam, habis selesaikan revisi ke-7 untuk klien yang sama, untuk fitur yang jujur saja menurut saya tidak perlu ada. Dan saya duduk di sana, menatap layar, dengan pikiran yang cuma satu: “Kapan saya kerja untuk sesuatu yang benar-benar saya percaya?”

Itu bukan keluhan soal kliennya — orangnya baik, bayarannya oke. Tapi ada yang kosong. Saya eksekutor. Bukan kreator.

Dari situ mulai perjalanan panjang dari freelancer full-time ke apa yang sekarang saya sebut sebagai indie dev.

Apa Bedanya Freelancer dan Indie Dev?

Sebelum saya cerita perjalanannya, penting klarifikasi dulu karena istilah ini sering dipakai overlapping:

Freelancer: Bekerja untuk klien, dibayar per project atau per jam. Income dari melayani kebutuhan orang lain. Waktu = uang, dan waktu kamu bukan milik kamu sepenuhnya.

Indie Developer: Membangun produk atau tool sendiri, mencoba memonetisasinya. Income dari produk, bukan dari jam kerja. Risk lebih tinggi, tapi ownership penuh.

Keduanya bukan yang lebih baik secara absolut — tergantung fase hidup dan prioritas kamu. Tapi buat saya, ada panggilan yang kuat ke arah indie.

Fase Transisi: Kaki di Dua Perahu

Saya tidak langsung berhenti freelance. Itu naif. Yang saya lakukan adalah mulai alokasi waktu secara sadar:

• 70% waktu: freelance projects (buat bayar tagihan)
• 20% waktu: eksperimen dan belajar teknologi baru
• 10% waktu: side project / produk sendiri

Fase ini berat. Sering ada perasaan bersalah kalau lagi kerja di project sendiri padahal ada task klien yang belum selesai. Dan sebaliknya, kalau lagi di project klien, pikiran sering melayang ke ide-ide yang pengen dieksplor.

Tapi ini perlu. Karena membangun produk sendiri butuh runway — waktu tanpa tekanan finansial yang terlalu mencekik — dan runway itu saya beli dengan income dari freelance.

Masuknya Vibe Coding: Game Changer yang Tidak Saya Ekspektasi

Di tengah transisi ini, saya mulai eksperimen dengan apa yang komunitas sekarang sebut vibe coding — cara coding yang lebih fluid, lebih berdasarkan intuisi dan flow, dengan AI sebagai teman ngobrol dan pair programmer.

Bukan berarti saya stop mikir arsitektur atau asal-asalan. Tapi prosesnya berubah drastis. Alih-alih duduk blank di depan file kosong, saya mulai dengan obrolan — sama AI, sama diri sendiri dalam bentuk tulisan, atau sama teman sesama developer.

“Saya mau membuat tool yang bisa X, dengan batasan Y, untuk user Z. Apa approach paling sederhana yang bisa jalan dulu?”

Dan dari sana, kode mulai tumbuh organik. Tidak selalu cantik di awal. Tapi jalan, dan itu yang penting buat iterasi awal.

Vibe coding mengubah cara saya mulai project. Dulu: desain sistem dulu, baru kode. Sekarang: kode explorasi dulu (dengan AI), temukan bentuknya, baru refactor dan strukturkan. Untuk indie dev yang kerja solo dengan resource terbatas, ini approach yang jauh lebih pragmatis.

Project Pertama yang Benar-benar Jadi

Setelah beberapa kali gagal (project yang terlalu ambisius, produk yang saya bangun tapi tidak ada yang butuh), akhirnya ada yang jalan.

Bukan produk besar. Cuma tool kecil — utility sederhana yang memecahkan masalah yang saya sendiri punya dan ternyata orang lain juga punya. Launch kecil-kecilan. Feedback organik. Beberapa orang mau bayar.

Yang berubah dari project-project sebelumnya: saya build untuk masalah yang saya sendiri rasakan, bukan untuk “kayaknya orang butuh ini.” Dan proses build-nya pakai pendekatan vibe coding — iterasi cepat, test early, dengerin feedback.

Pelajaran Pahit yang Harus Diakui

Membangun produk jauh lebih susah dari menerima project. Sebagai freelancer, ada klien yang beri requirement. Sebagai indie dev, kamu yang harus tau apa yang perlu dibangun. Ini beda skill yang signifikan.

Marketing itu separuh pekerjaan, bukan afterthought. Kode yang bagus tapi tidak ada yang tau itu produk yang tidak eksis. Saya harus belajar “jual” — dan ini uncomfortable banget untuk introvert yang lebih suka di balik layar.

Income yang tidak konsisten itu menegangkan. Freelance punya ritme payment yang bisa diprediksi. Indie dev punya bulan yang kering dan bulan yang lebih baik. Butuh mental yang berbeda, dan butuh financial buffer yang cukup.

Komunitas itu penting banget. Solo dev bisa sangat isolated. Bergabung dengan komunitas indie maker, ikut build-in-public di Twitter/X, atau sekadar punya teman yang juga di jalur yang sama — ini bukan luxury, ini necessity.

Kenapa Saya Tetap di Jalur Ini

Meski susah, ada sesuatu yang berbeda soal bangun produk sendiri. Ketika ada user yang bilang “ini tool sangat membantu workflow saya” — kepuasannya beda sama dapat approval dari klien. Karena ini sesuatu yang saya percaya dan saya bangun atas inisiatif sendiri.

Dan dengan vibe coding + AI tools yang makin powerful, kapasitas seorang indie dev solo sekarang jauh lebih besar dari beberapa tahun lalu. Yang dulu butuh tim kecil, sekarang bisa dikerjakan satu orang dengan leverage yang tepat.

Bukan berarti semua bisa. Tapi scope yang bisa dijangkau solo developer di 2026 jauh lebih luas dari yang orang bayangkan.

Untuk Kamu yang Lagi di Persimpangan

Kalau kamu freelancer yang lagi merasakan hal yang sama seperti yang saya rasakan malam itu — perasaan bahwa ada sesuatu yang lebih yang ingin kamu bangun — saran saya:

1. Jangan quit freelance tiba-tiba. Bangun runway dulu.
2. Mulai kecil. Side project mingguan lebih baik dari grand vision yang tidak pernah jalan.
3. Build untuk masalah yang kamu sendiri rasakan. Ini validasi paling mudah.
4. Pakai AI untuk leverage. Ini era di mana solo dev bisa compete dengan tim kecil.
5. Ship early, iterate often. Kesempurnaan adalah musuh dari product yang jadi.

Perjalanannya panjang dan tidak linear. Tapi tiap langkah kecil dari freelancer ke indie dev itu worth it — setidaknya untuk saya.

---

Lagi di fase transisi dari freelancer ke indie dev, atau punya ide produk yang ingin dikembangkan? Mau ngobrol soal strategi atau butuh partner teknis untuk mulai? Yuk — hubungi mafadev dan kita explorasi bareng.

Tahun 2026 dan AI coding tools sudah berkembang jauh dari sekadar autocomplete. Kita sekarang punya tools yang bisa baca seluruh codebase, menulis file, jalankan command, bahkan debug error secara otonom.

Tapi justru karena pilihannya banyak, bingung mau mulai dari mana. Cursor vs Windsurf? Claude vs GPT-4? Pakai IDE yang ada atau pindah ke yang baru?

Artikel ini breakdown jujur tools vibe coding yang paling relevan di 2026 — bukan berdasarkan hype, tapi berdasarkan apa yang benar-benar berguna dalam pekerjaan sehari-hari.

---

Kategori Tools Vibe Coding

Sebelum masuk ke tools spesifik, penting untuk tahu ada beberapa kategori:

1. AI-powered IDE — editor kode yang built-in dengan AI (Cursor, Windsurf, Zed)
2. AI Assistant CLI — tools yang berjalan di terminal (Claude Code, Aider, Continue)
3. AI dalam IDE existing — extension untuk VS Code, IntelliJ, dll (GitHub Copilot, Codeium)
4. No-code/low-code AI builder — untuk yang fokus pada output bukan kode (Bolt, Lovable, v0)

---

AI-Powered IDE

Cursor

Status: Masih raja untuk mayoritas developer.

Cursor adalah VS Code fork dengan AI yang deeply integrated. Kamu masih familiar dengan VS Code environment, tapi dengan kemampuan AI yang jauh lebih dalam dari sekadar extension.

Kelebihan:

• Composer yang bisa edit multiple files sekaligus berdasarkan instruksi natural language
• Context awareness yang sangat baik — dia “baca” seluruh codebase kamu
• Shortcut yang intuitif dan tidak mengganggu workflow VS Code yang sudah ada
• Support berbagai AI model (Claude, GPT-4o, dan model mereka sendiri)

Kekurangan:

• Subscription berbayar untuk fitur penuh ($20/bulan untuk Pro)
• Bisa lambat ketika codebase sangat besar
• Masih occasional hallucination, terutama untuk library yang tidak populer

Cocok untuk: Developer yang sudah pakai VS Code dan mau upgrade experience ke AI coding tanpa belajar tool baru.

---

Windsurf (oleh Codeium)

Status: Challenger serius, makin kuat.

Windsurf datang dengan pendekatan yang sedikit berbeda: mereka punya konsep “Cascade” yang bisa execute multi-step tasks secara lebih otonom. Bukan cuma suggest kode, tapi benar-benar plan dan execute sequence of actions.

Kelebihan:

• Cascade mode yang lebih otonom untuk task multi-langkah
• Gratis tier yang cukup generous
• Performa yang kompetitif dengan Cursor untuk banyak use case
• Integrasi dengan Codeium yang sudah matang

Kekurangan:

• Ekosistem extension masih kalah dari VS Code/Cursor
• UI masih terasa less polished
• Community dan resource masih lebih kecil dari Cursor

Cocok untuk: Developer yang mau coba AI IDE tanpa commitment finansial awal, atau yang butuh autonomous task execution yang lebih dalam.

---

Zed

Status: Alternatif yang menarik untuk performance-first developer.

Zed bukan primarily AI tool — ini text editor yang sangat cepat (written in Rust) yang kemudian menambahkan AI capabilities. Kalau kamu selalu merasa VS Code terlalu berat, Zed bisa jadi jawaban.

Kelebihan:

• Performa luar biasa, rendering hampir instant
• Collaborative editing real-time built-in
• AI integration yang terus berkembang
• Open source

Kekurangan:

• Ekosistem extension masih terbatas
• Kurva belajar untuk yang datang dari VS Code
• AI features masih belum se-mature Cursor

Cocok untuk: Developer yang prioritas performance dan tidak terlalu bergantung pada extension ekosistem VS Code.

---

AI Assistant CLI

Claude Code

Status: Game changer untuk terminal-first developer.

Claude Code (dari Anthropic) adalah AI assistant yang berjalan di terminal dan bisa interact langsung dengan filesystem, menjalankan command, membaca dan menulis file. Ini bukan sekadar chatbot — ini agent yang bisa execute multi-step task dengan cukup sedikit intervensi.

Kelebihan:

• Kemampuan agentic yang kuat — bisa baca, tulis, jalankan, debug secara berurutan
• Sangat baik untuk task yang butuh context panjang (refactoring besar, debugging kompleks)
• Bisa diintegrasikan ke workflow apapun — tidak terikat editor tertentu
• Model Claude yang sangat baik untuk reasoning

Kekurangan:

• Tidak ada visual editor — murni terminal
• Perlu setup dan familiarization
• Bisa mahal kalau tidak dikelola penggunaan token-nya

Cocok untuk: Developer yang nyaman di terminal, atau yang punya task yang butuh banyak file changes koordinat.

---

Aider

Status: Open source favorite, sangat customizable.

Aider adalah CLI tool open source yang koneksi ke berbagai AI model dan bisa edit kode langsung di repository kamu. Sangat fleksibel dan bisa diintegrasikan dengan model dari mana saja.

Kelebihan:

• Open source, bisa self-host dengan model lokal
• Bisa pakai model apapun (GPT, Claude, Ollama local models)
• Git integration yang bagus — setiap edit otomatis jadi commit
• Tidak ada subscription tambahan kalau kamu sudah punya API key

Kekurangan:

• Setup lebih manual
• UX lebih kasar dibanding Cursor
• Butuh pemahaman tentang context management

Cocok untuk: Developer yang mau kontrol penuh dan tidak keberatan dengan setup yang lebih teknis.

---

AI Extension untuk IDE Existing

GitHub Copilot

Status: Masih relevan, terutama kalau sudah bayar.

Kalau kamu sudah subscribe GitHub Copilot (atau dapat lewat GitHub Education/Enterprise), ini masih pilihan solid yang terintegrasi mulus ke VS Code, JetBrains, dan lainnya.

Kelebihan:

• Integrasi ekosistem GitHub yang excellent
• Support banyak IDE
• Copilot Chat yang makin bagus
• Copilot Workspace untuk project-level tasks

Kekurangan:

• Lebih mahal dibanding alternatif kalau beli tersendiri
• Autocomplete quality kadang kalah dari Cursor
• Fitur agentic masih kalah dari Cursor/Claude Code

Cocok untuk: Tim yang sudah di ekosistem GitHub dan butuh AI coding yang tidak perlu setup tambahan.

---

No-Code AI Builder

Bolt.new dan Lovable

Kalau tujuan kamu adalah launch produk, bukan belajar koding, tools ini layak dipertimbangkan.

Bolt.new — generate full-stack web app dari deskripsi, deploy langsung ke StackBlitz atau platform cloud.

Lovable — sama konsepnya, dengan fokus pada beautiful UI dan user experience.

Cocok untuk: Founder yang mau validate idea cepat, atau developer yang mau buat internal tool tanpa buang waktu untuk setup.

---

Perbandingan Cepat

| Tool | Tipe | Harga | Autonomy | Learning Curve |

|——|——|——-|———-|—————-|

| Cursor | IDE | $20/bln | Tinggi | Rendah |

| Windsurf | IDE | Gratis / $15/bln | Sangat Tinggi | Rendah |

| Zed | IDE | Gratis | Sedang | Sedang |

| Claude Code | CLI | Pay per token | Sangat Tinggi | Sedang |

| Aider | CLI | API key only | Tinggi | Tinggi |

| Copilot | Extension | $10-19/bln | Sedang | Rendah |

| Bolt/Lovable | No-code | Freemium | Penuh | Sangat Rendah |

---

Rekomendasi Berdasarkan Profil

Developer pemula yang mau belajar sambil pakai AI:

Cursor dengan Claude model. Kamu tetap bisa baca dan pahami kode yang dihasilkan, tapi dengan bantuan yang signifikan.

Freelancer yang butuh kecepatan development:

Cursor atau Windsurf + Claude Code untuk task yang lebih besar. Kombinasi ini sangat powerful untuk solo developer.

Tim kecil (2-5 orang):

Cursor dengan shared konteks + GitHub Copilot untuk yang prefer autocomplete ringan. Tentukan satu standar agar semua pakai hal yang sama.

Developer yang mau kontrol penuh dan tidak mau locked in:

Aider dengan Ollama (model lokal) untuk data sensitif, API Claude/GPT untuk task yang butuh model kuat.

Non-developer yang mau buat produk:

Bolt.new atau Lovable untuk MVP, Cursor ketika kamu mulai butuh kustomisasi lebih dalam.

---

Kesimpulan

Tidak ada satu tools yang sempurna untuk semua orang. Yang terbaik adalah yang kamu pakai setiap hari dan membuat kamu lebih produktif — bukan yang paling hype atau paling mahal.

Saran praktis: coba dua tools secara serius selama dua minggu, lakukan task riil (bukan toy project), dan pilih yang paling fit dengan cara kamu bekerja.

---

Bingung pilih tools yang tepat untuk project atau tim kamu? Atau mau setup workflow vibe coding yang efisien? Yuk ngobrol — hubungi mafadev dan kita tentukan bareng.

Kalau kamu sudah beberapa bulan terakhir mengikuti dunia developer, pasti sudah pernah dengar istilah vibe coding. Konsep yang dipopulerkan Andrej Karpathy ini membuat banyak orang berdebat: ada yang bilang ini masa depan, ada yang bilang ini jalan menuju bencana teknis.

Jujur? Dua-duanya ada benarnya. Tergantung konteks.

Di artikel ini kita bedah perbedaan vibe coding vs traditional coding secara jujur — bukan untuk membela salah satu, tapi untuk bantu kamu memilih yang tepat sesuai situasi.

---

Apa Itu Vibe Coding?

Vibe coding adalah cara menulis kode di mana kamu lebih banyak mendeskripsikan apa yang mau dibangun dalam bahasa natural, lalu membiarkan AI (biasanya model seperti Claude, GPT-4, atau tools seperti Cursor/Windsurf) yang menghasilkan kodenya.

Kamu tidak terlalu peduli setiap baris kode yang dihasilkan. Kamu flow. Kamu merasakan vibe-nya. Kalau ada error, kamu beri ke AI lagi dan bilang “tolong fix ini.”

Karpathy bilang: “I fully give in to the vibes, embrace it, and don’t fight it.”

Karakteristik Vibe Coding:

• Lebih banyak pakai bahasa natural daripada syntax
• Iterasi cepat, trial and error tanpa rasa takut
• Fokus pada outcome bukan implementation detail
• AI jadi pair programmer utama (bahkan lebih dominan)
• Cocok untuk eksplorasi dan prototyping

---

Apa Itu Traditional Coding?

Traditional coding adalah cara lama yang kita tahu: kamu yang menulis setiap baris, kamu yang review logic-nya, kamu yang debug dengan sabar, dan kamu benar-benar paham apa yang terjadi di setiap layer.

Ini bukan berarti tidak pakai tools — linter, formatter, bahkan AI-assist seperti GitHub Copilot tetap masuk. Bedanya, kamu tetap memegang kendali penuh dan punya pemahaman mendalam tentang kode yang ada.

Karakteristik Traditional Coding:

• Pemahaman mendalam setiap baris kode
• Debugging yang lebih teliti dan sistematis
• Lebih peduli dengan arsitektur jangka panjang
• Cocok untuk sistem production yang complex
• Review code yang ketat sebelum merge

---

Perbandingan Head-to-Head

1. Kecepatan

Vibe coding menang telak untuk kecepatan awal. Dalam waktu satu jam kamu bisa punya UI yang berjalan, API endpoint yang merespons, bahkan integrasi database yang basic. Ini luar biasa untuk validasi ide atau membuat demo.

Traditional coding lebih lambat di awal, tapi biasanya lebih predictable — kamu tahu persis kenapa sesuatu berjalan (atau tidak).

2. Kualitas Kode

Traditional coding lebih unggul di sini. Kode yang kamu tulis sendiri (dengan penuh kesadaran) cenderung lebih bersih, lebih konsisten, dan lebih mudah di-maintain oleh orang lain.

Kode hasil vibe coding sering kali “works but ugly” — berhasil, tapi kalau ada yang baca, mereka mungkin mengernyit.

3. Skalabilitas

Ini yang paling kritis. Vibe coding punya utang teknis yang tidak kelihatan — kamu mungkin tidak tahu ada 3 cara berbeda untuk handle error di codebase yang sama, atau ada N+1 query problem yang belum ketahuan.

Traditional coding, justru karena kamu paham setiap bagian, lebih mudah di-scale dan di-refactor.

4. Learning

Kalau kamu mau belajar, traditional coding masih juaranya. Kamu tidak bisa benar-benar menguasai TypeScript kalau semua TypeScript-mu ditulis AI.

Tapi untuk developer yang sudah berpengalaman, vibe coding justru mempercepat eksplorasi teknologi baru — kamu bisa membuat proof of concept teknologi yang belum pernah kamu sentuh dalam waktu setengah hari.

5. Debugging

Ini trade-off yang nyata. Kalau kode dihasilkan AI dan kamu tidak terlalu paham isinya, debugging bisa jadi mimpi buruk. Kamu tidak tahu harus mulai dari mana.

Traditional coding: debugging tetap menyakitkan, tapi kamu setidaknya punya mental model tentang sistem kamu.

---

Kapan Pakai Vibe Coding?

Gunakan vibe coding ketika:

• Prototyping dan validasi ide — mau lihat apakah konsep ini bisa jalan sebelum invest waktu lebih besar
• Side project personal — yang tidak butuh maintainability jangka panjang, kamu yang pakai sendiri
• Eksplorasi teknologi baru — mau coba framework yang belum pernah kamu sentuh, tanpa harus baca 200 halaman dokumentasi dulu
• Deadline gila-gilaan — demo besok, fitur harus jadi malam ini (tapi bayar utang teknisnya nanti ya)
• Automasi script sederhana — one-off tools yang selesai setelah dipakai sekali

---

Kapan Pakai Traditional Coding?

Gunakan traditional coding ketika:

• Sistem production — yang dipakai banyak user, harus reliable, dan ada yang maintain jangka panjang
• Security-sensitive code — autentikasi, payment, data pribadi — kamu harus paham setiap baris
• Tim besar — kode yang dibaca dan dimodifikasi banyak orang butuh konsistensi dan kejelasan
• Performa kritis — kalau latency atau memory usage adalah faktor utama
• Kamu sedang belajar — jangan skip proses ini, investasi jangka panjangmu ada di sini

---

Atau… Kombinasikan Keduanya

Ini yang sebenarnya paling banyak terjadi di lapangan. Developer yang bagus tidak pilih salah satu — mereka tahu kapan switch mode.

Resep yang sering berhasil:

1. Gunakan vibe coding untuk skeleton awal — struktur folder, boilerplate, API endpoint dasar
2. Review dan pahami hasilnya — jangan langsung lanjut sebelum kamu mengerti apa yang dihasilkan
3. Tulis bagian kritis secara manual — logic bisnis penting, keamanan, dan query database yang complex
4. Gunakan vibe coding lagi untuk fitur minor — UI component, helper function, test case

Analoginya seperti menggunakan GPS di kota baru. Awalnya kamu 100% ikutin GPS (vibe coding). Setelah sering lewat jalan yang sama, kamu mulai tahu jalan sendiri (traditional coding). Combinasi keduanya yang membuat kamu navigator yang efisien.

---

Kesimpulan

Vibe coding bukan ancaman buat programmer — justru senjata baru yang powerful kalau dipakai dengan sadar. Traditional coding bukan sesuatu yang kuno — ini fondasi yang membuat kamu bisa vibe code dengan aman.

Yang berbahaya adalah pilih salah satu secara ekstrem: vibe coding saja tanpa pemahaman = bom waktu teknis. Traditional coding saja tanpa eksplorasi = kehabisan kecepatan di era yang bergerak cepat.

Kamu perlu keduanya. Dan kamu perlu tahu kapan pakai yang mana.

---

Lagi eksplorasi pendekatan baru buat project kamu? Atau butuh bantuan menentukan arsitektur yang tepat sebelum mulai build? Yuk ngobrol — hubungi mafadev dan kita diskusi bareng.

Batas Baru Developer: Kode yang Ditulis AI, Dibimbing Manusia

Ada percakapan yang sering terjadi di komunitas developer sekarang: “Apakah kita akan digantikan AI?”

Saya tidak akan menjawab dengan klise “AI hanya alat, manusia tetap dibutuhkan”. Itu jawaban yang terlalu mudah dan tidak jujur. Yang sebenarnya terjadi lebih nuanced dari itu — dan lebih menarik.

---

Apa yang Sebenarnya Terjadi

Saya habiskan satu hari penuh minggu lalu untuk membangun fitur yang sebelumnya butuh seminggu. Bukan karena saya tiba-tiba jadi programmer yang lebih pintar. Tapi karena AI menulis sebagian besar kodenya.

Yang saya lakukan:

• Desain arsitektur dan definisi interface
• Review setiap kode yang dihasilkan AI
• Debug ketika AI salah (dan itu terjadi)
• Pastikan kode konsisten dengan kebutuhan bisnis yang AI tidak “tahu”
• Buat keputusan trade-off yang membutuhkan konteks lebih dari sekadar spesifikasi teknis

Yang AI lakukan:

• Tulis 70-80% kode aktualnya
• Generate test case
• Suggest edge case yang mungkin saya lewatkan
• Tulis dokumentasi awal

Ini bukan tentang AI menggantikan saya. Ini tentang pergeseran proporsi pekerjaan.

---

Konsep “Vibe Coding” dan Realitanya

Istilah “vibe coding” dipopulerkan Andrej Karpathy — ide bahwa kamu bisa describe apa yang kamu mau dalam bahasa natural, AI yang eksekusi, dan kamu tinggal “vibe” sambil cek hasilnya.

Untuk prototype cepat dan proyek kecil? Ini nyata berjalan. Saya sendiri sudah buat beberapa script automation dan tools internal dengan cara ini.

Tapi ada batasan yang sering tidak disebutkan:

Vibe coding bekerja ketika:

• Domain problemnya well-defined dan familiar bagi AI
• Ukuran proyek kecil sampai medium
• Kamu tidak terlalu peduli dengan optimasi detail
• Kamu bisa review dan understand semua kode yang dihasilkan

Vibe coding breakdown ketika:

• Kamu perlu integrasi dengan sistem legacy yang kompleks
• Business logic sangat spesifik dan unik
• Security adalah critical concern
• Kamu perlu maintain kode ini 2 tahun ke depan

---

Skill yang Bergeser Nilainya

Ini yang menarik untuk direnungkan. Beberapa skill yang dulu sangat dihargai, nilainya bergeser karena AI:

Menurun relevansinya:

• Hafal syntax dan API (AI tahu lebih banyak dari kamu)
• Menulis boilerplate cepat
• Implementasi algoritma standar dari scratch

Naik relevansinya:

• System thinking — memahami bagaimana potongan-potongan besar sistem berinteraksi
• Problem framing — mendefinisikan masalah dengan tepat sebelum AI mulai “solve”
• Code reading dan review — memvalidasi kode yang dihasilkan AI, mendeteksi bug subtle
• Domain knowledge — AI tidak tahu bisnis kamu sebaik kamu
• Judgment calls — memutuskan trade-off yang tidak ada jawaban teknis murninya

Yang menarik: skill-skill yang naik nilainya ini adalah skill yang selama ini dianggap “soft” atau “senior” — bukan yang teknis sempit.

---

Model Mental Baru: Developer sebagai Arsitek dan Reviewer

Saya mulai berpikir peran developer seperti ini:

Bayangkan arsitek yang mendesain bangunan. Arsitek tidak memasang sendiri setiap batu bata. Mereka merancang, mengawasi, memvalidasi, dan membuat keputusan teknis yang menentukan. Worker yang actual construction melakukan eksekusinya.

Dalam konteks AI: developer adalah arsiteknya, AI adalah workernya.

Ini bukan degradasi peran. Justru sebaliknya — arsitek adalah posisi yang lebih strategis dari tukang batu. Tapi butuh skill yang berbeda: kemampuan design, kemampuan komunikasi kebutuhan, kemampuan quality control.

---

Yang Berbahaya: Kehilangan Kemampuan Dasar

Ada risiko nyata yang perlu diakui: kalau kamu terlalu bergantung pada AI tanpa benar-benar memahami kode yang dihasilkan, kamu membangun di atas fondasi yang rapuh.

Ini analog dengan kalkulator di pelajaran matematika — alat yang sangat berguna, tapi kalau kamu tidak paham konsep dasarnya, kamu tidak akan tahu kapan kalkulator memberikan hasil yang salah.

Beberapa developer — terutama yang baru masuk industri — mulai skip pemahaman fundamental dan langsung mengandalkan AI. Ini berbahaya karena:

• AI membuat kesalahan yang terlihat sangat convincing
• Debug kode yang kamu tidak pahami strukturnya itu mimpi buruk
• Kamu tidak bisa evaluate apakah solusi AI itu “best” atau “cukup acceptable”

Kesimpulannya: Pakai AI untuk akselerasi, bukan untuk bypass pemahaman.

---

Pergeseran yang Sedang Terjadi di Industri

Dari observasi dan diskusi dengan developer lain, ini tren yang saya lihat:

Tim yang beradaptasi mulai reorganize peran. Satu “AI orchestrator” yang bertanggung jawab atas flow prompting dan review, beberapa developer yang fokus di domain-specific knowledge dan architecture decisions.

Tim yang struggle adalah yang mencoba pakai AI sebagai gimmick tanpa mengubah cara kerja fundamentalnya. Hasilnya: kode yang dihasilkan lebih cepat tapi dengan technical debt yang menumpuk karena tidak ada review yang proper.

Developer solo punya keuntungan adaptasi lebih cepat — tidak ada organizational inertia. Kalau kamu developer solo yang baca ini, kamu sebenarnya di posisi yang baik untuk eksperimen dan temukan workflow yang optimal.

---

Apa yang Harus Dilakukan Sekarang

Bukan jawaban yang dramatis — tapi beberapa hal praktis:

1. Pakai AI secara aktif, tapi selalu review. Jangan accept kode AI tanpa baca dan pahami. Setiap kode yang masuk ke production adalah tanggung jawab kamu, bukan AI.

2. Tingkatkan skill di area yang AI tidak bisa gantikan. System design, domain expertise, stakeholder communication, technical judgment.

3. Belajar cara “brief” AI dengan efektif. Prompt engineering untuk developer adalah skill nyata yang membedakan output yang mediocre dari yang excellent.

4. Eksperimen dengan workflow baru. Tidak ada playbook yang baku. Coba, iterasi, temukan apa yang bekerja untuk kamu dan project kamu.

5. Jaga curiosity. Landscape ini berubah cepat. Developer yang adapt paling baik adalah yang tetap curious dan mau belajar cara kerja baru.

---

Refleksi Akhir

Saya percaya ini bukan akhir dari era developer. Ini awal dari era developer yang berbeda — yang berpikir lebih strategis, yang lebih fokus pada masalah daripada implementasi teknis murni, yang menjadi jembatan antara kebutuhan manusia dan kemampuan mesin.

Itu lebih menarik, bukan?

Mau diskusi lebih dalam soal bagaimana AI mengubah cara kamu bekerja, atau butuh partner yang sudah navigating perubahan ini? Hubungi mafadev — kita ngobrol dan saling belajar.

“Sekarang siapapun bisa membuat aplikasi, bahkan tanpa bisa coding!”

Kalimat ini sudah beredar selama beberapa tahun terakhir — dulu dikaitkan dengan no-code tools, sekarang dengan vibe coding dan AI. Dan setiap kali saya denger ini, saya punya pertanyaan yang sama: benar-benar? Sampai sejauh mana?

Jadi saya lakukan sesuatu yang lebih konkret dari sekadar opini: saya minta seorang teman — seorang desainer grafis yang sama sekali tidak bisa coding — untuk mencoba build aplikasi sederhana pakai vibe coding. Saya duduk di sampingnya, observasi, tapi tidak bantu kecuali diminta.

Ini laporan jujurnya.

---

Subjek dan Setup

Teman saya ini — sebut saja Rini — adalah desainer yang fasih dengan Figma, Photoshop, Notion, tapi belum pernah menulis satu baris kode pun. Dia bukan orang yang takut teknologi, tapi juga bukan yang biasa berinteraksi dengan terminal atau file sistem.

Goal eksperimennya: build aplikasi web sederhana yang bisa:

• Simpan daftar buku yang sudah dan mau dibaca
• Beri rating dan review singkat
• Tampilkan list dalam tampilan yang bersih

Kami pakai Cursor dengan model Claude Sonnet. Saya sudah install dan setup semua di laptop-nya sebelumnya — ini perlu dicatat karena setup itu sendiri sudah ada learning curve-nya.

Waktu yang dialokasikan: 2 jam.

---

Jam Pertama: Antusiasme dan Kejutan Pertama

0-15 menit: Awal yang Lancar

Rini mulai dengan deskripsi yang sangat jelas — mungkin karena dia terbiasa brief klien. Instruksi pertamanya ke Cursor sangat bagus:

> “Membuat website sederhana untuk track buku. Saya mau bisa tambahkan judul buku, pengarang, status (sudah baca/mau baca), rating bintang 1-5, dan catatan singkat. Tampilannya harus clean dan minimalis. Pakai warna putih dan aksen biru.”

Instruksi itu sangat spesifik dan Cursor merespons dengan baik. Dalam 5 menit, ada scaffold HTML, CSS, dan JavaScript yang di-generate.

Rini terlihat excited. “Wah, sudah ada tampilannya!”

15-40 menit: Masalah Pertama Muncul

Ketika Rini mau coba jalankan, dia stuck. File HTML sudah ada, tapi dia tidak tau caranya “buka di browser”. Dia double-click file-nya dari file explorer, berhasil — tapi kemudian saat coba tambah buku, data tidak tersimpan setelah refresh.

Ini di mana keterbatasan pertama muncul: memahami gap antara “HTML statis” dan “aplikasi yang punya persistence”.

Rini minta AI untuk jelaskan kenapa data hilang. AI menjelaskan dengan baik tentang localStorage vs database. Tapi kemudian AI mulai suggest menggunakan backend dengan Node.js — dan di sini Rini mulai kehilangan benang merahnya.

Istilah seperti “terminal”, “npm install”, “port 3000”, “server” — semua itu asing dan menciptakan anxiety.

---

Jam Pertama Bagian Kedua: Di Mana Non-Programmer Mulai Struggle

40-70 menit: Terminal dan Konsep yang Asing

Ketika AI suggest untuk buka terminal dan jalankan command, Rini berhenti. “Terminal itu yang hitam-hitam itu ya? Bagaimana bukannya?”

Saya bantu buka terminal — tapi sesuai rules eksperimen, saya tidak bisa jelaskan lebih dari “klik ini”.

Rini tanya ke AI bagaimana buka terminal. AI jelaskan. Dia berhasil buka. Tapi kemudian perintah npm install gagal karena Node.js belum terinstall di laptop-nya.

Error message yang muncul — panjang, dalam bahasa Inggris, teknis — membuat Rini frustasi. Dia tanya ke AI. AI jelaskan cara install Node.js. Ini butuh waktu 15 menit tambahan.

Pelajaran: Setup environment adalah barrier yang significant untuk non-programmer, dan ini sesuatu yang vibe coding tools belum selesaikan sepenuhnya.

70-90 menit: Breakthrough Kecil

Setelah setup beres, Rini kembali ke jalur. Dia berhasil jalankan server lokal dan aplikasinya berjalan — dengan database sederhana menggunakan localStorage (bukan backend penuh).

Wajahnya ketika aplikasinya pertama kali jalan dengan data yang tersimpan: genuinely excited.

Dari situ, dia mulai lebih lancar. Dia minta AI untuk:

• Ubah warna tombol (“jadi lebih soft, bukan biru tua”)
• Tambah animasi sederhana saat buku ditambahkan
• Buat tampilan rating bintang yang visual

Semua ini berjalan dengan sangat baik. Di domain visual dan UX, instruksi Rini sangat kuat — dan hasilnya menunjukkan itu.

---

Hasil Akhir: Apa yang Berhasil, Apa yang Tidak

Yang Berhasil

Dalam 2 jam, Rini berhasil build aplikasi book tracker yang:

• Berfungsi di browser
• Punya tampilan yang cukup menarik (lebih bagus dari yang biasanya saya membuat, jujur)
• Bisa tambah, lihat, dan hapus buku
• Data tersimpan di localStorage (persisten selama tidak hapus browser data)

Itu bukan hasil yang buruk. Untuk aplikasi personal yang dia pakai sendiri, ini sudah sangat fungsional.

Yang Tidak Berhasil atau Butuh Bantuan

• Setup environment — butuh bantuan eksternal
• Memahami error teknis — banyak error yang dia tidak bisa debug sendiri dan instruksi ke AI kurang tepat karena dia tidak tau apa yang harus dijelaskan
• Konsep backend — setiap kali AI mention server, database, atau API, dia lost
• Deploy — ini tidak sempat dicoba, tapi sudah bisa diprediksi bahwa ini akan jadi barrier besar berikutnya

---

Jadi, Mungkinkah Vibe Coding untuk Non-Programmer?

Jawaban saya: Ya, dengan asterisk besar.

Yang mungkin:

• Build aplikasi sederhana untuk kebutuhan personal
• Prototyping ide — melihat “apakah ini kira-kira seperti yang saya bayangkan”
• Kustomisasi visual dari template yang sudah ada
• Script sederhana untuk otomasi task personal

Yang masih butuh programmer:

• Aplikasi yang butuh backend dan database yang proper
• Deploy ke production supaya bisa diakses orang lain
• Keamanan dan privacy yang serius
• Scalability dan maintenance jangka panjang
• Debugging ketika sesuatu tidak berjalan dan errornya tidak obvious

Yang Berubah vs Yang Belum Berubah

Yang berubah dengan AI: Menulis kode — non-programmer sekarang bisa “generate” kode tanpa bisa nulisnya sendiri.

Yang belum berubah: Memahami sistem — konsep seperti client-server, database, environment, deployment masih perlu dimengerti pada level tertentu untuk bisa build sesuatu yang meaningful dan bisa di-maintain.

---

Untuk Non-Programmer yang Mau Coba

Kalau kamu bukan programmer tapi ingin coba:

1. Mulai dari yang sangat sederhana. Bukan aplikasi web dengan backend — mungkin spreadsheet otomatis, atau script Python sederhana, atau webpage statis.

1. Sediakan waktu untuk setup. Ini akan makan waktu lebih dari yang kamu ekspektasi.

1. Pelajari istilah dasarnya. Bukan berarti harus bisa coding, tapi mengerti apa itu “file”, “folder”, “terminal”, “browser vs server” akan sangat membantu dalam instruksi ke AI.

1. Pair dengan programmer untuk sesi pertama. Bukan supaya programmer yang kerja, tapi supaya ada yang bisa jelaskan ketika kamu encountered concept yang asing.

1. Ekspektasi yang realistis. Kamu mungkin bisa build sesuatu yang “jalan”. Tapi “jalan untuk kamu” dan “production-ready” adalah dua hal yang berbeda.

---

Untuk Programmer yang Diberi Tahu Posisinya Terancam

Eksperimen ini justru memperkuat keyakinan saya bahwa programmer masih sangat relevan — bukan karena AI lemah, tapi karena ada kedalaman pemahaman yang dibutuhkan untuk build sesuatu yang serius.

Yang berubah bukan kebutuhan akan programmer. Yang berubah adalah apa yang programmer habiskan waktunya. Lebih banyak arsitektur, lebih banyak review, lebih banyak keputusan produk — kurang boilerplate.

---

Kamu non-programmer yang punya ide tapi tidak tau mulai dari mana? Atau programmer yang ingin bantu client-nya build prototype cepat? Hubungi mafadev — kita cari pendekatan yang paling pas untuk situasimu.

Jam 11 malam. Saya lagi di dapur nunggu air rebus — bukan setup yang ideal untuk mulai membuat aplikasi.

Tapi saya punya masalah kecil yang sudah lama mengganggu: saya sering lupa deadline invoice ke klien karena saya track semuanya di spreadsheet yang berantakan. Saya mau sesuatu yang simpel — input nama klien, nominal, due date, dan dapat reminder di waktu yang tepat.

Saya lihat jam. “Paling 30 menit setup spreadsheet yang lebih rapi,” pikir saya.

Kemudian saya ingat artikel yang baru saya baca soal vibe coding. “Oke, eksperimen malam ini.”

Satu jam kemudian, ada aplikasi web kecil yang jalan di localhost saya. Bukan spreadsheet.

Ini cerita lengkapnya — termasuk bagian-bagian yang tidak semulus yang biasa diceritain di thread Twitter.

---

Setup: Apa yang Saya Pakai

Untuk eksperimen ini:

• Cursor sebagai editor utama
• Claude Sonnet sebagai model (via Cursor)
• Python + Flask untuk backend (karena ini yang paling saya familiar)
• HTML/CSS sederhana untuk frontend — saya sengaja tidak pakai framework berat
• SQLite untuk database — overkill mungkin, tapi biar ada persistence

Total setup: sudah terinstall semua, tidak perlu install apapun baru.

---

Menit 0-10: Mendeskripsikan Ide

Saya buka Cursor, buka folder kosong, dan langsung buka Composer (fitur AI Cursor yang bisa edit multiple file).

Instruksi pertama saya:

> “Membuat aplikasi web sederhana dengan Python Flask. Fungsinya: bisa tambah invoice (nama klien, nominal, due date, status). Ada halaman list invoice, bisa filter yang sudah lewat deadline. Simpan ke SQLite. Tidak perlu tampilan fancy, prioritaskan fungsi.”

Cursor mulai generate. Dalam beberapa detik, dia mulai buat beberapa file: app.py, templates/index.html, templates/add_invoice.html, database.py.

Saya baca sekilas kodenya sambil dia generate. Strukturnya masuk akal. Flask route-nya rapi. SQLite schema-nya simpel tapi fungsional.

Waktu: sekitar 3 menit untuk generate initial code.

---

Menit 10-25: Jalankan, Error, Iterate

Saya jalankan python app.py. Ada error.

ImportError: cannot import name 'datetime' from 'flask'

Saya copy error-nya, paste ke Cursor chat.

> “Ada error ini: [error message]. Tolong fix.”

Cursor fix dalam 10 detik. Ternyata di kode yang di-generate, ada import yang salah cara penulisannya.

Jalanin lagi. Kali ini jalan — tapi halaman index-nya blank. Saya inspect di browser, ada console error JavaScript yang kecil.

Lagi, paste ke Cursor. Fix. Refresh. Halaman muncul.

Form “tambah invoice” muncul, saya coba isi dan submit — dan dapat error 500.

Buka terminal, baca traceback. Ternyata schema database ada kolom yang tidak match dengan yang diproses di route Flask. Ini jenis bug yang kadang di-generate AI karena dia “lupa” konsistensi antara beberapa file yang dia buat.

Pelajaran pertama: AI kadang membuat inkonsistensi antar file yang dia generate sendiri. Harus dicek.

Saya jelaskan ke Cursor: “Column name di database.py adalah due_date tapi di app.py kamu pakai deadline. Tolong konsistenkan.”

Fix, jalanin lagi. Form bisa submit. Data masuk ke database.

---

Menit 25-45: Tambah Fitur yang Saya Butuhkan

Setelah core functionality jalan, saya mulai tambah hal-hal spesifik yang saya mau:

Filter invoice overdue:

> “Tambah logika di halaman list: invoice yang due date-nya sudah lewat hari ini, beri highlight merah.”

Selesai dalam 2 menit.

Sort by due date:

> “By default, sort invoice by due date ascending, yang paling dekat deadline di atas.”

Selesai dalam 1 menit.

Status toggle:

> “Tambah tombol di setiap baris invoice untuk toggle status antara ‘Unpaid’ dan ‘Paid’ tanpa reload halaman.”

Ini sedikit lebih complex karena butuh JavaScript dan endpoint baru. Cursor generate keduanya — JavaScript fetch ke endpoint Flask baru yang di-create juga.

Waktu pertama jalan, CORS-nya berantakan (karena saya buka via localhost tapi port berbeda). Paste error ke Cursor, dia fix dengan tambahkan flask-cors.

---

Menit 45-60: Polish dan Sanity Check

Di 15 menit terakhir, saya:

1. Review semua kode yang di-generate — bukan karena tidak percaya AI, tapi ini harus jadi kebiasaan. Saya cek logika filtering-nya, pastiin tidak ada SQL injection vulnerability di query-nya.

1. Tambah basic validation — saya minta Cursor tambah validasi di form supaya nominal harus angka dan due date harus format yang valid.

1. Coba edge case — bagaimana kalau nominal di-input text? Bagaimana kalau due date di masa lalu? Semua saya test manual.

1. Tambahkan file .gitignore — kebiasaan.

Jam 12 malam kurang beberapa menit, saya punya aplikasi yang:

• Bisa tambah invoice dengan nama klien, nominal, dan due date
• List semua invoice dengan highlight merah untuk yang overdue
• Bisa toggle status paid/unpaid tanpa reload
• Sorted by due date otomatis

---

Apa yang Saya Pelajari dari Eksperimen Ini

Yang berjalan sangat baik:

• Generasi kode awal itu genuinely cepat. Yang dulu butuh setup 1-2 jam (buat folder, init project, install dependencies, buat skeleton) sekarang jadi 10 menit.
• Iterasi dengan paste error ke AI sangat efisien untuk error yang straightforward.
• Bisa fokus ke “apa yang saya mau” daripada “bagaimana cara nulisnya”.

Yang tetap butuh perhatian:

• AI membuat inkonsistensi antar file. Kamu harus review, bukan langsung trust.
• Security adalah tanggung jawab kamu — AI tidak otomatis membuat kode yang aman. Saya harus explicitly minta dan verify.
• AI kadang over-engineer untuk usecase sederhana. Saya minta “simpel”, tapi beberapa bagian kodenya lebih complex dari yang perlu. Saya simplify manual.

Yang tidak bisa digantikan:

• Pemahaman tentang apa yang saya bangun. Karena saya paham Flask dan SQLite, saya bisa evaluate kode yang di-generate dengan cepat.
• Keputusan produk. AI tidak tau invoice apa yang paling penting buat saya. Saya yang tentukan itu.

---

Apakah Satu Jam Itu Realistic?

Untuk ukuran aplikasi ini — ya. Tapi ada beberapa catatan:

• Saya familiar dengan stack yang dipakai. Kalau saya pakai stack baru, estimasi waktunya beda.
• Aplikasinya sederhana. Kalau ada requirement yang lebih complex (auth, multi-user, real-time), butuh lebih lama.
• Saya belum deploy ke production. Itu cerita lain.

Tapi angka “1 jam” itu bukan fiksi. Dan yang lebih penting: kualitas hasilnya bisa saya pertanggung jawabkan karena saya review sendiri.

---

Punya ide aplikasi kecil yang pengen kamu build tapi tidak tau mulai dari mana? Atau mau coba vibe coding tapi butuh teman untuk diskusi prosesnya? Hubungi mafadev — saya senang bantu kamu dari ide sampai aplikasi jalan.

Pertama kali dengar istilah “vibe coding”, jujur saya pikir ini istilah lebay yang diciptain orang biar kedengeran keren. Ternyata tidak. Ini adalah pergeseran nyata dalam cara orang — programmer maupun bukan — berinteraksi dengan kode.

Definisi Singkat: Vibe Coding Itu Apa?

Vibe coding adalah pendekatan pengembangan software di mana kamu mendeskripsikan apa yang kamu mau dalam bahasa natural, lalu membiarkan AI — bisa Cursor, GitHub Copilot, Claude, atau tool lain — yang menghasilkan kodenya. Kamu lebih banyak mengarahkan daripada mengetik.

Istilah ini dipopulerkan oleh Andrej Karpathy di awal 2025. Intinya: kamu masuk ke “mode vibe” — kamu fokus ke apa yang mau dibangun, bukan bagaimana cara nulisnya baris per baris.

Bukan berarti kamu tidak perlu ngerti kode sama sekali. Tapi proporsinya berubah drastis.

Sebelum Vibe Coding: Cara Lama Ngoding

Dulu — bahkan setahun yang lalu — alur kerja standar programmer itu kira-kira begini:

1. Buka dokumentasi
2. Cari sintaks yang pas
3. Ketik kode
4. Error
5. Google error-nya
6. Stack Overflow
7. Coba lagi
8. Berhasil (atau frustrasi dulu)

Prosesnya banyak overhead yang sebetulnya tidak berkaitan langsung dengan problem yang mau diselesaikan. Kamu mau bikin fitur login, tapi 40 menit habis buat debugging kenapa token JWT-nya expired duluan.

Setelah Vibe Coding: Cara Baru

Dengan vibe coding, alurnya lebih ke:

1. Deskripsikan apa yang mau dibangun
2. Review kode yang di-generate AI
3. Coba jalankan
4. Kalau ada error, paste error-nya ke AI
5. Iterasi sampai jalan

Bukan berarti lebih gampang. Tapi energinya beda. Kamu lebih banyak berpikir di level arsitektur dan keputusan produk, bukan di level sintaks dan boilerplate.

Ini Bukan Soal “Tidak Perlu Bisa Coding”

Satu hal yang perlu dilurusin: vibe coding bukan magic button yang bikin orang awam jadi bisa bikin software enterprise dalam semalam.

Yang berhasil paling efektif dengan pendekatan ini justru programmer yang sudah punya fondasi. Mereka bisa:

• Review kode yang di-generate — apakah logikanya benar? Ada security hole tidak?
• Kasih instruksi yang tepat — AI perlu prompt yang jelas untuk output yang bagus
• Debugging ketika AI salah — dan AI sering salah, terutama di kasus-kasus edge

Yang berubah adalah leverage. Satu programmer sekarang bisa deliver sebanyak yang dulu butuh tim kecil.

Contoh Nyata: Dari Nol ke Fitur Jalan dalam 30 Menit

Saya kasih contoh konkret. Minggu lalu saya perlu bikin script Python untuk scraping data dari sebuah halaman web, parsing hasilnya, dan simpan ke CSV.

Dulu ini mungkin butuh 2-3 jam — install dependencies, baca dokumentasi BeautifulSoup, handle pagination, format CSV yang benar.

Dengan vibe coding pakai Cursor:

• Saya jelaskan kebutuhannya dalam 3-4 kalimat
• AI menuliskan scaffolding-nya
• Saya review, tambahkan beberapa instruksi spesifik
• Iterasi 2-3 kali untuk handle edge cases
• Total: sekitar 25 menit

Kodenya bukan masterpiece, tapi fungsinya benar dan saya paham cara kerjanya.

Tool yang Paling Populer untuk Vibe Coding

Kalau mau mulai, ini beberapa pilihan yang banyak dipakai:

• Cursor — IDE berbasis VS Code dengan AI built-in yang sangat terintegrasi
• GitHub Copilot — Cocok kalau kamu sudah nyaman di VS Code
• Claude (Anthropic) — Bagus untuk diskusi arsitektur dan problem solving
• Windsurf — Alternatif Cursor yang lagi naik daun
• Claude Code — CLI tool dari Anthropic untuk vibe coding di terminal

Masing-masing punya kelebihan. Cursor bagus untuk editing inline yang cepat. Claude bagus untuk berpikir bareng soal arsitektur.

Apa yang Berubah di Cara Berpikir

Yang paling menarik buat saya bukan soal tool-nya — tapi soal mental model yang berubah.

Dulu kamu berpikir: “Gimana cara implementasi ini?”

Sekarang kamu berpikir: “Apa yang sebetulnya mau saya capai? Bagaimana cara saya menjelaskan ini ke AI dengan jelas?”

Itu skill yang berbeda. Dan yang mengejutkan: kemampuan komunikasi dan berpikir jernih jadi sama pentingnya dengan kemampuan teknis.

Apakah Vibe Coding Akan Gantiin Programmer?

Pertanyaan klise, tapi penting dijawab. Pendapat saya: tidak, tapi akan mengubah definisi “programmer”.

Yang akan tersingkir adalah pekerjaan yang sifatnya pure boilerplate — nulis CRUD endpoint yang sama berulang-ulang, setup konfigurasi standar, dan sejenisnya. AI sudah jauh lebih cepat dari manusia untuk hal-hal itu.

Yang tetap butuh manusia: pemahaman bisnis, keputusan arsitektur jangka panjang, nuance dalam user experience, dan — yang paling penting — tanggung jawab atas produk yang dibangun.

Mulai dari Mana?

Kalau kamu penasaran dan mau coba:

1. Install Cursor (gratis dengan limit) atau aktifkan GitHub Copilot
2. Ambil project kecil yang sudah kamu pahami
3. Coba deskripsikan satu fitur dalam bahasa natural dan lihat apa yang di-generate
4. Jangan langsung percaya output-nya — review dulu
5. Iterasi, eksperimen, rasakan sendiri bedanya

Vibe coding bukan tentang percaya buta ke AI. Ini tentang berkolaborasi dengan AI secara efektif — kamu yang punya visi, AI yang bantu eksekusi.

---

Tertarik eksplorasi lebih jauh soal vibe coding atau mau ngobrol soal bagaimana cara ini bisa diterapkan di project kamu? Yuk ngobrol — hubungi mafadev