Blog

  • Notion AI vs Obsidian: Tools Mana yang Cocok untuk Developer?

    Notion AI vs Obsidian: Tools Mana yang Cocok untuk Developer?

    Pertanyaan “Notion atau Obsidian?” ini seperti pertanyaan “tabs atau spaces?” di dunia PKM (Personal Knowledge Management) — semua orang punya pendapat kuat dan sering debatnya tidak ada habisnya.

    Saya bukan mau beri jawaban dogmatis. Saya mau beri konteks yang berguna untuk developer yang lagi milih antara keduanya — atau yang mau evaluate apakah perlu switch.

    Saya pakai Notion intensif sekitar 2 tahun. Lalu migrasi ke Obsidian hampir setahun. Sekarang hybrid, dengan use case yang berbeda untuk masing-masing. Ini pengalaman nyata, bukan review spekulatif.

    High-Level: Filosofi yang Berbeda

    Sebelum fitur dan perbandingan teknis, penting mengerti filosofi di balik masing-masing tools karena ini yang paling ngaruh ke keputusan akhir.

    Notion adalah all-in-one collaborative workspace. Database, wiki, project management, document — semuanya dalam satu platform. Cloud-first, kolaborasi mudah, barrier to entry rendah.

    Obsidian adalah local-first knowledge base berbasis markdown. Data kamu di lokal (atau sync manual ke cloud kamu sendiri). Filosofinya: kamu own data kamu, dan kamu build sistem pengetahuan yang customizable sepenuhnya.

    Beda filosofi → beda trade-off → beda cocoknya untuk siapa.

    Notion AI: Yang Membedakan di 2026

    Notion AI sudah jauh berkembang dari sekedar “AI yang bisa menulis di dalam Notion.” Beberapa fitur yang relevan untuk developer:

    Q&A Across Workspace

    Kamu bisa tanya ke seluruh konten workspace kamu. “Di mana catatan saya soal setup Kubernetes kemarin?” atau “Apa yang saya catat tentang keputusan arsitektur project X?” — AI akan cari dan rangkum dari semua halaman yang relevan.

    Ini killer feature untuk yang workspace Notion-nya sudah besar dan dense.

    Autofill di Database

    Notion AI bisa auto-populate field di database berdasarkan konten. Misalnya: kamu punya database artikel, AI bisa auto-generate summary, ekstrak key points, atau kategorisasi dari konten artikel.

    Untuk developer yang maintain project tracker, bug database, atau knowledge base tim — ini signifikan.

    Draft dan Summarize

    Standar: generate tulisan, summarize halaman panjang, translate. Berguna tapi ini sudah ada di mana-mana.

    Obsidian: Kenapa Developer Suka Ini

    Obsidian punya fanbase yang loyal, dan ada alasan teknis yang solid di baliknya:

    Data Ownership

    File markdown tersimpan di lokal. Kamu bisa buka dengan text editor apapun, bisa version control dengan Git, bisa backup sesuka hati. Obsidian bisa hilang besok pagi dan data kamu tetap aman dan accessible.

    Untuk developer yang paham pentingnya data portability, ini bukan detail kecil.

    Graph View dan Linking

    Kemampuan untuk link antar note (dengan [[note name]]) dan visualisasi koneksi antar catatan dalam graph view. Ini powerful untuk membangun knowledge base yang interconnected — konsep, referensi, dan pemikiran yang saling terhubung.

    Plugin Ecosystem yang Gila

    Community Obsidian develop ratusan plugin. Ada plugin untuk Kanban board, Daily notes yang sophisticated, Dataview (semacam query database dari note kamu), Git integration, dan banyak lagi.

    Sebagai developer, kemampuan untuk extend tool sendiri — bahkan menulis plugin dengan JavaScript — itu resonan banget.

    Speed dan Offline

    Karena file lokal, Obsidian cepat banget. Open, search, navigate — semua instant. Dan sepenuhnya offline.

    Di Mana AI Fit ke Obsidian?

    Obsidian sendiri tidak punya built-in AI seperti Notion, tapi komunitas sudah solve ini:

    Plugin Copilot for Obsidian memungkinkan integrasi langsung dengan OpenAI, Anthropic, atau model lokal (via Ollama) langsung dari dalam Obsidian. Kamu bisa chat dengan AI yang punya konteks dari vault kamu.

    Smart Connections plugin menggunakan embeddings untuk buat semantic search — bukan hanya text search, tapi cari berdasarkan makna. “Show notes related to microservices architecture” akan cari konten yang secara semantic relevan, meski kata-katanya tidak persis sama.

    Jadi Obsidian bisa punya AI capability yang comparable, tapi setup-nya butuh usaha lebih.

    Perbandingan Head-to-Head untuk Developer

    | Aspek | Notion AI | Obsidian |

    |——-|———–|———-|

    | Data ownership | Cloud (Notion’s servers) | Local file |

    | Kolaborasi tim | Excellent | Butuh setup tambahan |

    | Speed | Tergantung internet | Very fast (local) |

    | Customizability | Moderate | Very high |

    | Mobile experience | Good | Decent |

    | Learning curve | Low | Medium-High |

    | Cost | $10-20/mo untuk AI features | Free (inti), plugin berbayar ada |

    | Offline access | Terbatas | Full |

    | Git integration | Tidak native | Via plugin |

    | AI features | Built-in, seamless | Via plugin, perlu setup |

    Use Cases: Mana yang Lebih Cocok?

    Gunakan Notion (dengan AI) kalau:

    • Kamu kerja di tim dan kolaborasi real-time itu penting
    • Kamu butuh project management + documentation dalam satu tempat
    • Kamu suka all-in-one dan tidak mau repot konfigurasi
    • Work notes kamu lebih sering berupa database/tabel (task tracker, bug tracker, dll)
    • Kamu OK dengan data di cloud orang lain

    Gunakan Obsidian kalau:

    • Data ownership dan privacy itu prioritas tinggi
    • Kamu suka customize dan tinker dengan workflow sendiri
    • Kamu ingin build long-term knowledge base yang tumbuh seiring waktu
    • Kamu comfortable dengan markdown dan file-based workflow
    • Kamu suka integrasi dengan Git untuk version control catatan
    • Kamu lebih sering menulis long-form notes dan punya banyak interkoneksi konsep

    Kenapa Saya Akhirnya Hybrid

    Setup saya sekarang:

    Obsidian untuk: daily notes, pembelajaran teknis personal (artikel, konsep, referensi), catatan yang saya mau keep long-term, dan knowledge base pribadi yang saya bangun selama bertahun-tahun.

    Notion untuk: project management dengan klien (collaborative), tracking task tim, dokumentasi yang perlu dishare dan diedit bareng, dan database-style organization seperti pipeline project atau content calendar.

    Ini bukan karena salah satu kurang bagus — tapi karena use case-nya memang berbeda.

    Rekomendasi Akhir

    Kalau harus pilih satu:

    Solo developer, self-taught, privacy-conscious, suka tinker: Coba Obsidian dulu. Gratis, dan kalau kamu suka file-based workflow, ini akan bukan sekadar tool tapi jadi sistem berpikir yang berkembang.

    Developer yang kerja di tim, atau yang mau langsung produktif tanpa setup lama: Notion lebih pragmatis. AI features-nya juga sudah lumayan matang dan terintegrasi.

    Kalau budget dan waktu ada: Eksperimen keduanya selama sebulan masing-masing, lalu decide. Karena honestly, tool yang terbaik adalah yang kamu actually gunakan secara konsisten.


    Lagi setup sistem knowledge management untuk tim development, atau mau diskusi workflow produktivitas yang lebih efektif? Yuk ngobrol — hubungi mafadev dan kita cari setup yang paling pas.

  • Belajar Backend Otodidak: Roadmap Realistis 2026

    Belajar Backend Otodidak: Roadmap Realistis 2026

    Saya backend developer otodidak. Tidak ada gelar ilmu komputer, tidak ada bootcamp formal yang mahal. Yang ada: laptop, koneksi internet, dan keinginan kuat untuk figure things out sendiri.

    Jalan itu bisa ditempuh. Tapi saya juga lihat banyak orang yang frustrasi di tengah jalan karena ikut roadmap yang terlalu panjang, terlalu teoritis, atau tidak sesuai dengan kondisi nyata pasar kerja.

    Artikel ini buat kamu yang mau belajar backend secara otodidak di 2026 — dengan ekspektasi yang realistis dan urutan belajar yang pragmatis.

    Dulu vs Sekarang: Belajar Backend di Era AI

    Perlu saya acknowledge dulu: belajar backend di 2026 beda dari 5 tahun lalu, dan itu mostly bagus untuk kamu yang baru mulai.

    Yang berubah: AI sebagai learning companion. Kalau kamu stuck, kamu bisa nanya ke Claude atau ChatGPT dan dapat penjelasan yang kontekstual — jauh lebih cepat dari googling dan baca Stack Overflow satu-satu. Debugging juga lebih cepat karena AI bisa bantu identify masalah.

    Yang tidak berubah: Konsep fundamental tetap sama. HTTP, database, authentication, API design — ini tidak berubah karena AI ada. Yang berubah adalah cara kamu belajar dan cara kamu bekerja, bukan apa yang perlu kamu pelajari.

    Mindset Sebelum Mulai

    Jangan kejar semua. Salah satu jebakan paling umum: coba belajar terlalu banyak hal sekaligus. Node.js + Python + Go + Rust + semua framework + semua database. Hasilnya: tahu sedikit tentang banyak hal, tapi tidak bisa build apapun dengan proper.

    Progress > Perfection. Kode pertama kamu akan jelek. Itu normal. Yang penting jalan dulu, refactor dan improve nanti.

    Build sesuatu yang nyata. Tutorial tanpa project nyata = pengetahuan yang cepat menguap. Tiap konsep yang kamu pelajari, aplikasikan ke project yang sedang kamu bangun.

    Roadmap: Phase by Phase

    Phase 1: Fondasi (Bulan 1-2)

    Sebelum backend spesifik, ada fondasi yang perlu solid:

    Pilih satu bahasa, kuasai dulu:

    • JavaScript/Node.js — Paling accessible kalau kamu sudah kenal JavaScript dari frontend. Ekosistemnya besar.
    • Python — Syntax yang bersih, banyak resource belajar, kuat untuk data processing juga.
    • Go — Lebih steep learning curve, tapi performa excellent dan semakin populer untuk backend.

    Rekomendasi untuk pemula: mulai dengan Node.js atau Python.

    Yang harus dikuasai di fase ini:

    • Variables, functions, conditionals, loops — benar-benar paham, bukan sekadar bisa copy-paste
    • Tipe data dan struktur data dasar (array, object/dict)
    • Error handling
    • Baca dan tulis file
    • Konsep async (promises, async/await di JS, atau concurrent programming dasar di Python)

    Project fase 1: Script CLI sederhana. Bisa untuk rename file, process CSV, atau generate laporan sederhana. Tidak perlu web — mulai dari command line.

    Phase 2: HTTP dan Web Fundamentals (Bulan 2-3)

    Backend pada dasarnya adalah: terima request HTTP, proses, kirim response. Pahami ini dengan dalam.

    Yang harus dipelajari:

    • Cara kerja HTTP: method (GET, POST, PUT, DELETE), status code, headers, body
    • JSON: format dan cara parse/stringify
    • REST API: konsep dan desain dasar
    • Framework pertama:

    – Express.js untuk Node.js

    – FastAPI untuk Python

    Jangan skip: Coba build server tanpa framework dulu — Node.js built-in http module atau Python socket. Ini buat kamu mengerti apa yang sebenarnya dilakukan framework.

    Project fase 2: Simple REST API. Bisa to-do list, simple blog posts API, atau pencatat pengeluaran. CRUD dasar — Create, Read, Update, Delete.

    Phase 3: Database (Bulan 3-4)

    Backend tanpa database itu setengah matang.

    Mulai dengan SQL:

    • PostgreSQL adalah pilihan solid (free, powerful, production-ready)
    • Pelajari: SELECT, INSERT, UPDATE, DELETE, JOIN, index dasar, transaction
    • Belajar ORM juga: Prisma (untuk Node.js) atau SQLAlchemy (untuk Python) — tapi tetap mengerti raw SQL-nya

    Kenalan dengan NoSQL:

    • MongoDB untuk document database — bagus untuk data yang skema-nya fleksibel
    • Redis untuk caching dan session storage

    Yang sering dilewat: Database design. Bagaimana cara desain tabel yang proper, relasi antar tabel, normalisasi dasar. Ini skill yang bedakan backend dev junior dan yang lebih senior.

    Project fase 3: Extend API kamu dari fase 2 dengan persistent storage (data tersimpan ke database, bukan hilang saat server restart).

    Phase 4: Authentication dan Authorization (Bulan 4-5)

    Hampir semua aplikasi real butuh ini, dan ini adalah area yang paling banyak security issue-nya kalau salah implement.

    Yang harus dipelajari:

    • Session-based authentication vs token-based (JWT)
    • Cara hash password yang benar (bcrypt, argon2 — jangan pernah store plain text!)
    • OAuth 2.0 konsep dasar
    • Role-based access control (RBAC) dasar

    Project fase 4: Tambahkan auth ke API kamu — register, login, logout, protected routes.

    Phase 5: Deployment dan DevOps Dasar (Bulan 5-6)

    Kode yang cuma jalan di laptop kamu bukan produk. Belajar deploy.

    Yang minimal harus dikuasai:

    • Git (kalau belum) — ini wajib, bukan opsional
    • Linux command line dasar
    • Deploy ke platform seperti Railway, Render, atau Fly.io (lebih mudah dari AWS untuk pemula)
    • Environment variable dan config management
    • Basic logging

    Bonus tapi sangat worth it: Docker dasar. Containerization sudah jadi standard industry.

    Project fase 5: Deploy API kamu dari fase sebelumnya ke public internet. Share URL ke teman, itu milestone yang meaningful.

    Phase 6: Pendalaman (Bulan 6+)

    Setelah fondasi solid, ini area pendalaman berdasarkan arah yang ingin kamu ambil:

    • Performance: Caching strategy, database optimization, profiling
    • Scale: Message queue (RabbitMQ, Redis Pub/Sub), microservices concept
    • Security: Lebih dalam tentang OWASP Top 10, penetration testing dasar
    • Testing: Unit test, integration test, API testing

    Tools yang Perlu Kamu Kenal

    • VS Code — Editor yang paling umum, ekosistem extension-nya kaya
    • Postman atau Insomnia — Untuk test API
    • TablePlus atau DBeaver — GUI untuk database
    • Git + GitHub — Version control, wajib

    Cara Belajar yang Efektif

    Jangan hanya tonton tutorial. Tonton sekali, tutup video, coba implement sendiri dari ingatan. Buka video lagi hanya kalau benar-benar stuck.

    Dokumentasi resmi adalah teman terbaik. Express docs, PostgreSQL docs, MDN untuk HTTP — ini primary source. Biasakan baca dokumentasi, bukan selalu cari tutorial.

    Build project, bukan latihan soal. LeetCode itu penting untuk interview, tapi untuk belajar backend, project nyata jauh lebih efektif.

    Pakai AI sebagai mentor, bukan jawaban instan. “Tolong explain kenapa race condition bisa terjadi di kasus ini” lebih valuable dari “tolong fix bug ini.”

    Berapa Lama Sampai Bisa Kerja?

    Jujur: 6-12 bulan dengan belajar konsisten (minimal 2-3 jam per hari) untuk sampai ke level yang bisa dapat junior backend developer role. Ini variasi tergantung background, intensitas, dan jenis peran yang dituju.

    Yang penting: portofolio yang terdiri dari project nyata yang bisa diakses publik jauh lebih berharga dari sertifikat atau list course yang kamu selesaikan.

    Kesimpulan

    Belajar backend otodidak itu kerja keras, tapi sangat feasible di 2026. Ekosistem resource belajar belum pernah sebaik ini, dan dengan AI sebagai learning companion, kurva belajar bisa dipersingkat.

    Kuncinya: pilih satu jalur, build project nyata, dan jangan berhenti di tengah jalan ketika stuck — itu bagian dari prosesnya.


    Lagi di perjalanan belajar backend dan butuh panduan atau mentor? Atau punya project yang ingin dikembangkan sambil belajar? Yuk ngobrol — hubungi mafadev dan kita cari jalur yang paling cocok buat kamu.

  • Cara Review Kode yang Digenerate AI Supaya Tidak Salah Kaprah

    Cara Review Kode yang Digenerate AI Supaya Tidak Salah Kaprah

    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.

  • AI Agent: Apa Itu dan Kenapa Developer Harus Tahu?

    AI Agent: Apa Itu dan Kenapa Developer Harus Tahu?

    Kalau kamu mengikuti dunia AI dalam beberapa bulan terakhir, kamu pasti sering dengar kata “AI Agent.” Di LinkedIn, di Twitter, di konferensi tech — semua orang ngomong soal agent. Tapi kalau kamu tanya definisi yang konkret ke orang yang sama, jawabannya sering blur.

    Artikel ini saya tulis buat developer yang mau mengerti benar-benar — bukan sekadar buzzword, tapi: apa itu AI agent secara teknis, bedanya apa sama chatbot biasa, dan kenapa ini penting buat kamu sebagai developer.

    Definisi yang Tidak Membuat Bingung

    AI Agent adalah sistem AI yang bisa:

    1. Menerima tujuan (goal) dari manusia
    2. Merencanakan langkah-langkah untuk mencapai tujuan itu
    3. Mengeksekusi langkah-langkah tersebut menggunakan tools yang tersedia
    4. Bereaksi terhadap hasil dari setiap langkah dan adjust rencana kalau perlu
    5. Melakukan ini secara otonom (minimal supervision)

    Keyword-nya: otonom dan multi-langkah.

    Kalau chatbot biasa adalah “tanya → jawab, tanya → jawab” — loop sederhana, satu langkah, satu respons — AI agent lebih seperti: “saya dikasih tujuan, saya figure out cara mencapainya, saya eksekusi, saya handle kalau ada yang berubah.”

    Analogi yang Gampang Dipahami

    Bayangkan kamu punya asisten:

    Chatbot biasa = Asisten yang bisa jawab pertanyaan apapun yang kamu tanyain, tapi kamu harus tanya satu-satu dan dia tidak lakuin apapun tanpa kamu minta.

    AI Agent = Asisten yang kalau kamu bilang “tolong rencanakan perjalanan saya ke Bali minggu depan, cari tiket paling murah, pesan hotel dekat pantai, dan buat itinerary 5 hari” — dia akan pergi, cari tiket sendiri, compare hotel, buat itinerary, dan balik ke kamu dengan hasil yang sudah siap.

    Bedanya bukan cuma soal seberapa pintar, tapi soal autonomy dan kemampuan menggunakan tools.

    Komponen Utama AI Agent

    Secara teknis, agent terdiri dari beberapa komponen:

    1. LLM sebagai “Otak”

    Model bahasa (GPT-4, Claude, Gemini, dll) yang handle reasoning, planning, dan decision making. Ini yang “berpikir.”

    2. Tools / Functions

    Kemampuan yang bisa digunakan agent untuk berinteraksi dengan dunia luar. Contoh tools:

    • Search web
    • Baca/tulis file
    • Eksekusi kode
    • Panggil API eksternal
    • Query database
    • Kirim email

    LLM tanpa tools = pintar tapi terisolir. LLM dengan tools = bisa take action.

    3. Memory

    Kemampuan menyimpan dan mengakses informasi. Ada beberapa tipe:

    • Short-term memory: Context dalam satu session/percakapan
    • Long-term memory: Database yang bisa diakses lintas session (vector DB, dll)
    • Working memory: State saat ini dalam proses eksekusi task

    4. Planning & Reasoning

    Kemampuan untuk break down tujuan besar menjadi sub-task yang bisa dieksekusi. Ini yang membuat agent beda dari sekadar “call API.”

    Pola Arsitektur Agent yang Populer

    ReAct (Reason + Act)

    Pattern paling sederhana: agent berpikir tentang apa yang perlu dilakukan, bertindak dengan menggunakan tool, mengobservasi hasilnya, dan loop sampai tujuan tercapai.

    Thought: Saya perlu cari harga tiket Jakarta-Bali untuk tanggal 15 Agustus
    

    Action: search_flights(origin="CGK", dest="DPS", date="2026-08-15")

    Observation: [hasil search]

    Thought: Harga paling murah adalah X dari maskapai Y. Saya perlu check ketersediaan kursi.

    Action: check_availability(flight_id="...")

    ...

    Multi-Agent System

    Beberapa agent yang bekerja bersama dengan spesialisasi berbeda. Satu agent sebagai “orchestrator” yang delegate task ke agent-agent spesialis. Cocok untuk task yang kompleks dan butuh expertise berbeda.

    Plan-and-Execute

    Agent pertama-tama membuat rencana lengkap, lalu eksekusi step by step. Berbeda dengan ReAct yang lebih reactive, ini lebih deliberate dan predictable.

    Kenapa Developer Harus Mengerti Ini?

    Bukan karena kamu harus langsung membuat AI agent dari nol. Tapi karena:

    1. Landscape Tools Development Berubah

    Cursor, GitHub Copilot, Claude Code — tools coding yang kamu pakai sekarang berbasis agent architecture. Mengerti cara kerjanya membuat kamu bisa pakai lebih efektif dan debug lebih mudah ketika ada yang salah.

    2. Klien Akan Minta “AI Agent” untuk Bisnis Mereka

    Ini sudah terjadi. “Buatkan AI agent yang bisa handle customer service,” atau “kami mau agent yang bisa monitor inventory dan auto-reorder.” Sebagai developer, kamu perlu bisa evaluate, design, dan implement request-request ini.

    3. Skill ini Langka dan Dicari

    Mengerti orchestration agent, prompt engineering untuk agent behavior, dan evaluasi agent output — ini masih skill yang langka tapi demand-nya tinggi.

    4. Ini Arah Komputasi ke Depan

    Model interaksi “manusia ketik, AI jawab” akan semakin dilengkapi (bukan diganti total) dengan “manusia beri tujuan, agent kerjain.” Software architecture pun akan berubah.

    Contoh Implementasi Sederhana

    Untuk yang mau coba hands-on, beberapa framework yang bagus:

    LangChain / LangGraph — Populer, banyak dokumentasi, cocok untuk eksperimen awal.

    AutoGen (Microsoft) — Powerful untuk multi-agent setup.

    CrewAI — Abstraksi yang lebih tinggi, cocok kalau mau cepat prototype.

    Claude dengan Tool Use API — Kalau mau lebih control dan langsung pakai Anthropic API.

    Contoh agent sederhana dengan konsep dasar:

    # Pseudo-code konsep dasar agent loop
    

    def run_agent(goal, tools):

    messages = [{"role": "user", "content": goal}]

    while True:

    response = llm.complete(messages, available_tools=tools)

    if response.type == "final_answer":

    return response.content

    if response.type == "tool_call":

    result = execute_tool(response.tool_name, response.tool_args)

    messages.append({"role": "tool", "content": result})

    Hal yang Perlu Diperhatikan

    Hallucination dan error propagation — Kalau satu langkah dalam chain agent salah, error bisa cascade ke langkah berikutnya. Validasi output setiap step itu penting.

    Cost — Setiap langkah agent = LLM call = biaya. Agent yang looping banyak bisa mahal. Monitoring usage itu wajib.

    Security — Agent yang punya akses ke tool external (file system, database, API) butuh permission management yang ketat. Jangan beri agent akses lebih dari yang dia butuhkan.

    Evaluation — Susah evaluate agent behavior karena output-nya non-deterministic. Butuh framework evaluasi yang jelas.

    Kesimpulan

    AI Agent bukan sekadar trend — ini paradigma baru dalam cara kita berinteraksi dengan software dan AI. Untuk developer, mengerti konsep dasar ini bukan opsional lagi. Ini literasi teknis yang makin penting.

    Mulai dengan memahami konsepnya (sudah kamu lakukan dengan baca artikel ini), lalu eksperimen dengan framework yang ada, dan bangun intuisi soal kapan agent tepat dipakai dan kapan overkill.


    Penasaran cara implement AI agent untuk kebutuhan spesifik bisnis atau project kamu? Atau mau diskusi soal arsitektur yang tepat? Yuk ngobrol — hubungi mafadev dan kita explorasi teknologinya bareng.

  • Dari Freelancer ke Indie Dev: Perjalanan dengan Vibe Coding

    Dari Freelancer ke Indie Dev: Perjalanan dengan Vibe Coding

    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.

  • Cara Membuat CLI Tool Sendiri dengan Bantuan AI

    Cara Membuat CLI Tool Sendiri dengan Bantuan AI

    Salah satu hal yang membuat saya produktif naik drastis beberapa bulan belakangan bukan apps baru yang mahal, bukan workflow mewah — tapi CLI tools kecil yang saya membuat sendiri untuk automasi hal-hal repetitif di pekerjaan sehari-hari.

    Dan yang membuat saya bisa membuat tools itu lebih cepat? AI sebagai pair programmer.

    Artikel ini bukan tutorial akademis. Ini lebih ke: “gini cara saya benar-benar membuat CLI tool dari nol dengan bantuan AI, langkah demi langkah.”

    Kenapa CLI Tool?

    Sebelum masuk ke cara membuat, validasi dulu kenapa CLI tool worth it:

    • Speed: Satu command untuk menjalankan serangkaian aksi yang biasanya butuh 5-10 langkah manual
    • Repeatable: Jalankan hal yang sama persis berkali-kali tanpa error manusia
    • Composable: Bisa di-pipe dengan tools lain di terminal
    • Shareable: Bisa dishare ke tim, bisa masuk ke repo, bisa di-versioning

    Contoh nyata yang saya membuat: tool untuk rename file markdown sesuai konvensi tertentu, tool untuk generate boilerplate project structure, tool untuk batch resize gambar dengan preset tertentu. Kecil-kecil tapi efeknya besar.

    Pilihan Stack

    Untuk CLI tool, ada beberapa pilihan populer:

    Node.js — Paling accessible kalau kamu JavaScript/TypeScript developer. Library seperti commander.js, yargs, atau oclif membuat ini mudah.

    Python — Bahasa scripting yang paling natural untuk automasi. Click dan Typer adalah library CLI yang elegant.

    Go — Kalau mau binary yang compiled, single-file, dan fast. cobra adalah library CLI standar di ekosistem Go.

    Bash — Untuk yang simple dan tidak perlu distribusi. Tapi scaling-nya terbatas.

    Untuk artikel ini, kita pakai Node.js dengan TypeScript karena paling gampang di-demo dan banyak developer sudah familiar.

    Setup Project

    Mulai dari scratch:

    mkdir my-cli-tool
    

    cd my-cli-tool

    npm init -y

    npm install commander chalk ora

    npm install -D typescript @types/node ts-node

    npx tsc --init

    Struktur direktori dasar:

    my-cli-tool/
    

    ├── src/

    │ ├── index.ts # Entry point

    │ ├── commands/ # Command handlers

    │ └── utils/ # Helper functions

    ├── package.json

    └── tsconfig.json

    Di Sini AI Masuk: Cara Efektif Pakai AI untuk Build CLI

    Ini bagian intinya. Bukan sekadar “tanya AI terus copy paste” — ada cara yang lebih efektif.

    Langkah 1: Describe Tool Kamu dengan Jelas

    Sebelum minta AI menulis kode, definisikan dulu dengan jelas:

    • Apa yang tool ini lakukan?
    • Input apa yang diterima?
    • Output apa yang dihasilkan?
    • Edge case apa yang perlu di-handle?

    Contoh prompt yang bagus:

    > “Bantu saya membuat CLI tool di Node.js dengan TypeScript. Tool ini bernama imgopt dan fungsinya: menerima path folder sebagai argument, scan semua file JPG dan PNG di folder tersebut, resize ke max-width 1200px (maintain aspect ratio), compress dengan quality 80%, dan simpan ke subfolder /optimized. Tampilkan progress bar saat processing. Kalau folder /optimized sudah ada, tanya konfirmasi sebelum overwrite.”

    Prompt spesifik seperti gini akan beri output yang jauh lebih berguna dari sekadar “membuat CLI tool untuk resize gambar.”

    Langkah 2: Generate Skeleton, Bukan Final Code

    Saya biasanya minta AI untuk buat skeleton/struktur dulu, bukan langsung kode lengkap:

    > “Dulu kamu beri prompt di atas — sekarang generate struktur folder dan file yang dibutuhkan, dengan function signatures yang perlu diimplementasi. Jangan tulis implementasi detailnya dulu.”

    Ini membuat kamu mengerti arsitekturnya sebelum detail kode ada. Lebih mudah untuk review dan understand.

    Langkah 3: Implement Bagian per Bagian

    Setelah struktur clear, implement satu command atau satu fungsi sekaligus:

    // src/index.ts — yang AI generate sebagai starting point
    

    import { Command } from 'commander';

    import { optimizeImages } from './commands/optimize';

    const program = new Command();

    program

    .name('imgopt')

    .description('CLI tool untuk optimasi gambar')

    .version('1.0.0');

    program

    .command('optimize <folder>')

    .description('Optimize semua gambar di folder')

    .option('-w, --width <number>', 'Max width (default: 1200)', '1200')

    .option('-q, --quality <number>', 'Quality 1-100 (default: 80)', '80')

    .option('-o, --output <folder>', 'Output folder (default: optimized)', 'optimized')

    .action(optimizeImages);

    program.parse();

    Lalu untuk setiap bagian yang perlu diimplementasi, tanya AI dengan konteks yang spesifik.

    Langkah 4: Iterasi dengan Error

    Ini yang sering dilewat. Ketika ada error, jangan langsung fix sendiri atau langsung paste ke AI tanpa konteks. Cara yang lebih efektif:

    1. Jalankan kode
    2. Kalau ada error, screenshot atau copy error message-nya
    3. Paste ke AI dengan konteks: “Ini error yang muncul ketika saya run dengan input [X]. Ini adalah kode yang saya jalankan: [kode]. Ini error-nya: [error]. Tolong explain kenapa terjadi dan bagaimana fix-nya.”

    Minta explanation, bukan sekadar fix. Ini membuat kamu belajar dan mengerti, bukan cuma copy-paste.

    Contoh Real: Tool Rename Markdown Files

    Ini tool sederhana yang benar-benar saya membuat. Masalahnya: saya punya banyak file markdown yang nama filenya inkonsisten, dan saya mau standardize jadi format YYYY-MM-DD-judul-kebab-case.md.

    Prompt ke AI:

    > “Membuat CLI tool Node.js TypeScript bernama mdren yang bisa rename file markdown. Command: mdren rename . Behavior: scan semua file .md di folder, extract tanggal dari frontmatter YAML (field date), extract title dari frontmatter (field title), convert title ke kebab-case, rename file ke format YYYY-MM-DD-judul-kebab-case.md. Tampilkan preview rename sebelum eksekusi dan minta konfirmasi. Kalau file tidak punya frontmatter, skip dan beri warning.”

    Dalam 2-3 iterasi dengan AI, tool ini jadi. Sesuatu yang kalau saya tulis manual dari nol mungkin butuh setengah hari.

    Publish ke npm (Opsional)

    Kalau mau share ke tim atau publik:

    // package.json
    

    {

    "name": "your-cli-tool",

    "bin": {

    "mytool": "./dist/index.js"

    },

    "scripts": {

    "build": "tsc",

    "prepublish": "npm run build"

    }

    }

    Setelah build dan npm publish, orang lain bisa install dengan npm install -g your-cli-tool.

    Tips Tambahan

    Tambahkan --dry-run flag untuk operasi yang destructive (rename, delete, overwrite). Jalankan dulu tanpa benar-benar eksekusi, lihat apa yang akan terjadi.

    Gunakan chalk untuk colored output — ini membuat CLI kamu jauh lebih readable, terutama untuk error (merah), success (hijau), dan warning (kuning).

    Error handling yang proper — jangan biarkan tool crash dengan stack trace mentah. Catch error dan beri pesan yang human-readable.

    Simpan di PATH kamu — entah via npm global install atau symlink manual, pastikan tool kamu bisa dipanggil dari mana saja di terminal.

    Kesimpulan

    CLI tool kustom adalah investasi produktivitas yang underrated. Dan sekarang dengan AI sebagai pair programmer, barrier untuk membuat tool sendiri jauh lebih rendah.

    Kuncinya: jangan minta AI menulis semua sekaligus. Iterate, tanya per bagian, minta explanation bukan cuma code dump. Treat AI seperti junior developer yang sangat cepat, tapi tetap butuh diarahkan dan di-review hasilnya.


    Punya ide CLI tool yang mau kamu membuat tapi tidak tahu mulai dari mana? Atau butuh partner untuk develop tools custom untuk workflow tim kamu? Yuk ngobrol — hubungi mafadev dan kita bangun bareng.

  • Perplexity AI untuk Riset Teknis: Lebih Efektif dari Google?

    Perplexity AI untuk Riset Teknis: Lebih Efektif dari Google?

    Waktu pertama kali coba Perplexity AI, saya pikir ini cuma ChatGPT yang dikasih akses internet. Simpel saja. Tapi setelah beberapa bulan ngandelin dia buat riset teknis — dari cari solusi bug, baca dokumentasi, sampai ngulik konsep baru — saya sadar: ini beda, dan bedanya signifikan.

    Pertanyaannya sekarang bukan “apakah Perplexity lebih baik dari Google?” tapi lebih ke: untuk use case apa Perplexity menang, dan kapan Google masih lebih masuk akal?

    Apa yang Membuat Perplexity Beda?

    Sebelum masuk ke perbandingan, penting mengerti cara kerja Perplexity. Kalau Google beri kamu daftar link dan kamu harus klik satu-satu, Perplexity langsung sintesis informasi dari beberapa sumber dan beri jawaban yang kohesif — dengan sitasi di sampingnya.

    Jadi prosesnya: kamu tanya → Perplexity crawl web real-time → dia rangkum → kamu dapat jawaban + bisa verifikasi ke sumber aslinya.

    Untuk riset teknis, ini game changer dalam beberapa skenario tertentu.

    Kapan Perplexity Menang Telak

    1. Pertanyaan “Bagaimana Cara X dengan Y versi Z”

    Ini use case favorit saya. Misalnya: “Cara setup authentication dengan Next.js 15 dan Supabase Auth v2”

    Di Google, kamu akan dapat 10 artikel, setengahnya outdated, setengahnya pakai versi berbeda. Kamu harus filter manual, buka tab banyak, komparasi sendiri.

    Di Perplexity, dia akan langsung syntesis dari dokumentasi resmi + artikel terbaru, beri kamu jawaban yang kontekstual dengan versi spesifik yang kamu tanyain. Lebih cepat, lebih relevan.

    2. Riset Perbandingan Library atau Framework

    “Redis vs Memcached untuk caching di 2026” — tipe pertanyaan ini cocok banget buat Perplexity. Dia akan beri tabel perbandingan, pro-cons, dan konteks kapan masing-masing lebih cocok, semua dalam satu jawaban.

    3. Memahami Konsep Teknis yang Kompleks

    Kalau kamu lagi belajar sesuatu yang baru — misalnya cara kerja CRDT (Conflict-free Replicated Data Types) atau konsep event sourcing — Perplexity bisa explain dengan bahasa yang lebih natural sambil tetap akurat secara teknis. Lebih enak dari baca Wikipedia atau whitepaper langsung.

    4. Debugging dengan Error Message Spesifik

    Paste error message ke Perplexity → dia langsung beri konteks kenapa error itu terjadi, dari beberapa sumber sekaligus. Kadang lebih cepat dari Stack Overflow karena dia sudah agregasi jawaban-jawaban yang relevan.

    5. Riset Ekosistem Tool Baru

    Mau tau tool apa yang lagi populer untuk observability di stack tertentu? Atau library terpopuler untuk task queue di Go? Perplexity bagus banget untuk snapshot “state of the ecosystem” karena dia bisa akses info terkini.

    Kapan Google Masih Lebih Baik

    Tapi ada situasi di mana saya masih balik ke Google:

    1. Dokumentasi Resmi

    Kalau kamu butuh dokumentasi resmi yang exact — API reference, parameter spesifik, method signature — langsung ke docs resminya atau Google ke sumber tersebut. Perplexity bisa sintesis tapi kadang detail teknis bisa ter-paraphrase dan subtle error bisa masuk.

    2. Cari Artikel atau Tutorial Spesifik

    “Tutorial TRPC dari creator-nya sendiri” atau “artikel dari Kent C. Dodds soal React Server Components” — untuk cari konten spesifik dari author tertentu, Google tetap lebih baik.

    3. Stack Overflow Thread dengan Context Panjang

    Kadang solusi ada di comment ke-7 dari pertanyaan 5 tahun lalu. Google masih lebih baik untuk nemuin thread Stack Overflow spesifik dengan konteks percakapan utuh.

    4. SEO dan Konten Marketing Research

    Untuk cek ranking, SERP features, atau riset keyword — ini bukan domain Perplexity.

    5. Real-time Info yang Sangat Sensitif Waktu

    Harga, status server, breaking news — untuk ini Google News atau sumber langsung lebih reliable.

    Workflow Saya Sekarang

    Setelah eksperimen beberapa bulan, saya punya workflow yang cukup konsisten:

    Mulai dengan Perplexity untuk:

    • Orientasi konsep baru yang belum saya kenal
    • Pertanyaan “bagaimana cara X” yang butuh jawaban cepat
    • Perbandingan tools/library
    • Debugging error yang tidak obvious

    Switch ke Google ketika:

    • Perplexity beri jawaban yang saya ragukan akurasinya (lalu verifikasi ke sumber)
    • Butuh dokumentasi resmi yang sangat detail
    • Cari konten dari author atau platform spesifik

    Verifikasi ke sumber primer sebelum implementasi kode yang kritikal — ini satu hal yang tidak boleh di-skip, apapun tools yang dipakai.

    Tips Dapetin Hasil Maksimal dari Perplexity

    Berikan konteks yang spesifik. Jangan tanya “cara pakai Redis”, tapi tanya “cara setup Redis sebagai session store di Express.js dengan TypeScript, versi Redis 7+”. Makin spesifik, makin presisi jawabannya.

    Gunakan follow-up questions. Perplexity punya memory dalam satu thread. Kalau jawaban pertama kurang dalam, follow up: “Bisa elaborasi lebih soal bagian X?” atau “Apa alternatifnya kalau pakai Y?”

    Cek sitasi. Ini yang membuat Perplexity beda dari ChatGPT biasa — ada sitasi yang bisa diklik. Biasakan verifikasi ke sumber, terutama untuk info teknis yang akan langsung diimplementasi.

    Mode “Academic” untuk deep research. Kalau kamu riset topik yang butuh sumber yang lebih terpercaya (paper, jurnal teknis), ada mode Pro di Perplexity yang prioritas ke sumber-sumber tersebut.

    Verdict: Bukan Pengganti, Tapi Upgrade

    Perplexity bukan pengganti Google. Tapi untuk riset teknis spesifik — yang jadi mayoritas kebutuhan developer sehari-hari — Perplexity konsisten lebih efisien dari Google.

    Google masih raja untuk discovery dan cari sumber spesifik. Tapi untuk “saya butuh jawaban dari pertanyaan teknis ini sekarang” — Perplexity sering menang di kecepatan dan relevansi.

    Kalau kamu belum coba: daftar, pakai versi free dulu, dan test dengan pertanyaan teknis yang biasa kamu Google-in. Bandingkan sendiri hasilnya. Saya hampir yakin kamu akan temukan minimal 2-3 use case di mana Perplexity jauh lebih enak.


    Lagi eksplorasi tools AI untuk workflow development kamu, atau ada project yang butuh integrasi AI search dan riset? Yuk ngobrol — hubungi mafadev dan kita diskusi bareng.

  • Freelance Dev di Era AI: Peluang atau Ancaman?

    Freelance Dev di Era AI: Peluang atau Ancaman?

    Jujur saja, tiap kali ada tools AI baru yang viral, saya reflek buka Twitter/X dan liat dua kubu yang langsung perang. Kubu pertama: “AI akan gantiin programmer!” Kubu kedua: “AI cuma tools, developer tetap dibutuhkan!” Dan saya? Duduk di tengah sambil ngupi, mikir: kenyataannya lebih ribet dari kedua narasi itu.

    Kalau kamu freelance developer — atau lagi mikirin terjun ke dunia freelance — pertanyaan ini bukan cuma filosofis. Ini soal duit, soal karir, soal apakah laptop kamu masih relevan dua tahun lagi.

    Spoiler: AI bukan ancaman kalau kamu tahu cara mainnya. Tapi juga bukan murni peluang kalau kamu diam saja.

    Kenyataan di Lapangan: Apa yang Berubah?

    Saya ngobrol sama beberapa klien dalam beberapa bulan terakhir, dan ada pola yang mulai keliatan:

    Klien kecil makin pede membuat sendiri. Mereka pakai Claude, ChatGPT, atau Cursor buat membuat landing page sederhana, form kontak, bahkan aplikasi CRUD dasar. Yang dulu butuh hire dev, sekarang mereka coba dulu sendiri. Ini fakta, bukan asumsi.

    Tapi klien yang lebih serius justru makin banyak minta bantuan. Mereka sadar AI bisa generate kode, tapi tidak bisa handle kompleksitas bisnis, integrasi antar sistem, atau debugging yang butuh konteks domain yang dalam.

    Harga project kecil turun, harga project kompleks naik. Ini yang paling kena rasanya. Kalau kamu biasanya survive dari project-project kecil — buat website profile, landing page, toko online sederhana — margin kamu akan makin tipis karena kompetisi dari tools AI itu sendiri.

    Segmen yang Tergerus

    Mari jujur soal ini. Ada beberapa tipe pekerjaan freelance yang memang lagi dalam tekanan:

    1. Website Statis / Landing Page Sederhana

    Builder seperti Framer, Webflow, plus AI assistant di dalamnya, sudah bisa handle ini dengan cukup baik. Klien yang budget-conscious akan milih jalan ini.

    2. Kode Boilerplate dan Template

    Dulu bisa charge lumayan buat membuat starter project atau template custom. Sekarang AI bisa generate ini dalam menit. Nilai jual kamu harus lebih dari sekadar “bisa menulis kode.”

    3. Debugging Sederhana

    Stack overflow error yang cuma butuh googling? AI sudah handle itu. Klien yang tech-savvy bisa solve sendiri dengan modal paste error ke ChatGPT.

    Segmen yang Justru Tumbuh

    Tapi di sisi lain, ada ruang yang makin terbuka:

    1. AI Integration Specialist

    Klien banyak yang mau “pakai AI” tapi tidak tau caranya. Integrate LLM ke dalam workflow bisnis mereka, membuat chatbot yang benar-benar nyambung ke data mereka, atau automasi proses dengan AI — ini peluang nyata yang butuh orang yang mengerti teknis.

    2. Arsitektur dan Konsultasi

    Makin banyak yang bisa membuat kode tapi sedikit yang bisa mikirin sistem secara keseluruhan. Kalau kamu bisa duduk bareng klien dan bantu mereka ngerancang solusi — bukan sekadar eksekusi — nilaimu naik drastis.

    3. Review dan Audit Kode AI-generated

    Ini yang menarik. Banyak tim kecil dan startup yang kodenya sekarang campuran antara ditulis manusia dan di-generate AI. Mereka butuh orang yang bisa audit kualitas, keamanan, dan maintainability-nya. Ini skill yang jarang.

    4. Niche yang Butuh Domain Knowledge Dalam

    Kalau kamu punya keahlian di industri spesifik — kesehatan, logistik, fintech, pendidikan — kombinasi domain knowledge + coding skill masih sangat susah digantiin AI. AI tidak tau konteks bisnis klienmu.

    Cara Freelance Dev Survive (dan Thrive) di Era Ini

    Jangan Lawan AI, Pakai AI

    Ini yang paling penting. Kalau kompetitor kamu yang sesama freelancer pakai AI untuk deliver 3x lebih cepat, sementara kamu ngotot manual, kamu kalah di rate dan di waktu.

    Gunakan AI sebagai pair programmer. Cursor, GitHub Copilot, atau Claude langsung — pilih yang cocok buat workflow kamu. Target: deliver lebih cepat dengan kualitas yang sama atau lebih baik.

    Reframe Value Kamu

    Stop jual “saya bisa menulis kode.” Mulai jual “saya bisa solve masalah bisnis kamu dengan teknologi.” Ini beda banget. Klien bayar untuk solusi, bukan untuk baris-baris kode.

    Bangun Relasi, Bukan Sekadar Transaksi

    Di era di mana klien bisa generate kode sendiri, yang membuat mereka tetap balik ke kamu adalah kepercayaan, pemahaman konteks bisnis mereka, dan komunikasi yang baik. AI tidak bisa telepon klien jam 9 malam kalau ada bug production menjelang peluncuran.

    Spesialisasi Bukan Pilihan, Ini Keharusan

    Generalis akan lebih susah. Pilih niche — bisa industri vertikal, bisa teknologi spesifik (edge computing, AI integration, real-time systems) — dan jadilah go-to person di niche itu.

    Upgrade ke “Strategic Partner”

    Freelancer terbaik yang saya kenal bukan lagi sekadar “orang yang membuat kode.” Mereka diundang rapat, dimintai pendapat soal product roadmap, dan jadi bagian dari keputusan bisnis klien. Posisi ini hampir impossible digantiin AI dalam waktu dekat.

    Kesimpulan: Bukan Peluang atau Ancaman — Ini Transisi

    Saya tidak mau beri jawaban yang oversimplified. AI di dunia freelance dev itu seperti internet di tahun 2000-an bagi industri travel — beberapa bisnis travel agent collapse, tapi yang adaptasi malah jadi lebih besar.

    Freelance dev yang akan struggling: yang jual komoditas (kode generik, project template), yang tidak upgrade skill, yang tidak mau pakai AI dalam workflow mereka sendiri.

    Freelance dev yang akan berkembang: yang upgrade dari “coding service” ke “problem solving partner”, yang mengerti cara pakai AI untuk leverage output mereka, yang punya domain expertise + tech skill.

    Pertanyaannya bukan “apakah AI ancaman?” Pertanyaannya: kamu di posisi mana sekarang, dan kamu mau gerak ke mana?


    Lagi navigasi karir freelance di tengah banjir tools AI ini? Atau ada project yang butuh developer yang mengerti cara kerja bareng AI, bukan melawannya? Yuk ngobrol — hubungi mafadev dan kita diskusi bareng.

  • Refactoring Legacy Code dengan Bantuan AI

    Refactoring Legacy Code dengan Bantuan AI

    Kamu membuka file yang terakhir disentuh 3 tahun lalu. Tidak ada komentar. Variable bernama data2, tempVar, dan flag. Function sepanjang 400 baris. Tidak ada test. Dan ini harus kamu modify sekarang.

    Selamat datang di dunia legacy code.

    Setiap developer pasti pernah menghadapi ini — entah itu codebase warisan dari developer sebelumnya, project lama milik sendiri, atau “temporary solution” yang sudah jadi permanent. Dan sekarang, dengan bantuan AI, kita punya tools yang lebih baik untuk menghadapi situasi ini.

    Tapi AI bukan tongkat ajaib. Refactoring yang ceroboh bisa merusak sistem yang sebelumnya “jelek tapi jalan.” Artikel ini adalah panduan praktis dan realistis.


    Mengapa Legacy Code Itu Susah Disentuh?

    Sebelum bicara solusi, penting memahami masalahnya:

    Tidak ada test — tidak ada safety net. Kamu tidak tahu apakah perubahan kamu merusak sesuatu sampai ada yang laporan bug di production.

    Tight coupling — semua hal terhubung ke semua hal. Ubah satu bagian, tiga bagian lain ikut rusak.

    Context yang hilang — kenapa kode ini ditulis seperti ini? Ada bisnis rule tersembunyi? Ada workaround untuk bug di library tertentu? Dokumentasinya: tidak ada.

    Fear of change — “kalau masih jalan, jangan disentuh” adalah wisdom yang populer tapi juga trap yang membuat sistem makin susah di-maintain.


    Strategi Dasar: Understand Before You Change

    Rule nomor satu refactoring: jangan ubah kode yang tidak kamu mengerti.

    Ini bukan tentang paham setiap baris — tapi paham apa yang sistem ini lakukan secara keseluruhan, input apa yang masuk, output apa yang keluar, dan apa saja side effects-nya.

    Di Sinilah AI Sangat Membantu: Code Comprehension

    Sebelum ubah apapun, minta AI untuk bantu kamu memahami kodenya.

    Prompt yang efektif:

    Ini adalah fungsi [nama] dari codebase lama kami.
    

    Tolong jelaskan:

    1. Apa yang fungsi ini lakukan secara high-level
    2. Apa saja edge cases yang di-handle
    3. Ada tidak pola yang tidak umum atau mungkin workaround untuk bug tertentu
    4. Apa yang mungkin akan rusak kalau fungsi ini diubah

    [paste kode]

    AI tidak akan selalu benar — dia tidak tahu konteks bisnis kamu. Tapi dia bisa membantu kamu melihat pola yang mungkin terlewat ketika membaca cepat, dan mengajukan pertanyaan yang tepat.


    Framework Refactoring: Langkah Demi Langkah

    Fase 1: Characterization Tests

    Sebelum refactor, tulis test yang mendokumentasikan behavior saat ini — bukan behavior yang seharusnya. Ini yang disebut characterization tests atau approval tests.

    Tujuannya bukan memvalidasi kebenaran kode, tapi memastikan behavior tidak berubah setelah refactoring.

    Minta AI untuk bantu generate characterization test:

    Berikut adalah fungsi yang mau saya refactor:
    

    [paste kode]

    Tolong buatkan characterization tests menggunakan Jest yang:

    1. Capture behavior saat ini (bukan yang seharusnya)
    2. Cover semua branch yang ada
    3. Gunakan input yang realistis berdasarkan kode yang ada
    4. Tambahkan komentar yang menjelaskan KENAPA test ini ada

    Fokus pada mendokumentasikan apa yang terjadi sekarang, bukan apa yang seharusnya terjadi.

    Fase 2: Safe Zone Analysis

    Identifikasi bagian mana yang aman diubah dan mana yang berisiko:

    Relatif aman diubah:

    • Nama variable dan function (dengan rename yang proper)
    • Formatting dan whitespace
    • Extract method untuk blok kode yang ada
    • Komentar dan dokumentasi
    • Tipe data (dengan hati-hati)

    Butuh sangat hati-hati:

    • Logic bisnis yang ada
    • Urutan operasi
    • Error handling
    • Anything menyangkut database transactions
    • Code yang menyentuh external API

    Fase 3: Refactoring Bertahap

    Jangan lakukan big bang refactoring. Lakukan perubahan kecil, jalankan test setelah setiap perubahan.

    Urutan yang disarankan:

    1. Rename — perbaiki nama variable dan function yang tidak jelas
    2. Extract — pindahkan code blocks ke function terpisah tanpa mengubah logic
    3. Inline — hapus abstraksi yang tidak perlu
    4. Simplify conditionals — sederhanakan if-else yang complex
    5. Remove duplication — setelah kamu paham, baru konsolidasi yang duplikat

    Teknik Spesifik dengan AI

    1. Explain Complex Logic

    Tolong explain code ini baris per baris.
    

    Kemudian identifikasi bagian yang paling complex dan suggest cara

    untuk membuatnya lebih readable tanpa mengubah behavior.

    [paste kode]

    2. Rename Suggestions

    Variable dan function names berikut tidak cukup descriptive.
    

    Berikan suggestion nama yang lebih baik berdasarkan apa yang kode ini lakukan:

    • data2 → ?
    • tempVar → ?
    • processIt() → ?
    • flag → ?

    Konteks: [jelaskan apa yang kode ini lakukan]

    3. Extract Function

    Ini adalah fungsi yang terlalu panjang (400+ baris).
    

    Tolong identifikasi logical boundaries yang bisa di-extract

    menjadi function terpisah tanpa mengubah behavior.

    Berikan output dalam format:

    • Nama function baru yang disarankan
    • Baris mana yang masuk ke function tersebut
    • Parameter yang dibutuhkan
    • Return value

    [paste kode]

    4. Detect Patterns dan Antipatterns

    Review kode berikut dan identifikasi:
    
    1. Design patterns yang sudah diimplementasikan (bahkan kalau tidak disengaja)
    2. Antipatterns yang perlu diaddress
    3. Coupling yang berlebihan antara komponen
    4. Violation dari SOLID principles

    [paste kode]


    Trap yang Harus Dihindari

    Jangan Minta AI untuk “Rewrite Everything”

    Ini godaan terbesar. Kamu paste seluruh file dan bilang “tolong rewrite ini jadi clean code.”

    Masalahnya: AI tidak tahu business rules tersembunyi. Dia tidak tahu bahwa if (status === 3) itu sebenarnya adalah “kondisi khusus untuk merchant yang join sebelum tahun 2023.” Kode yang dihasilkan mungkin lebih bersih tapi kehilangan logic penting.

    Selalu refactor satu bagian kecil pada satu waktu, dan verify setelah setiap langkah.

    Jangan Abaikan Test yang Fail

    Kalau characterization test yang kamu tulis fail setelah refactoring, itu signal bahwa kamu mengubah behavior — baik sengaja maupun tidak. Investigasi dulu sebelum lanjut.

    Jangan Percaya AI 100% untuk Security-Critical Code

    Autentikasi, otorisasi, enkripsi, validasi input — review ini secara manual. AI mungkin menghasilkan kode yang terlihat bersih tapi punya subtle security issue.


    Toolkit Refactoring dengan AI

    Untuk Code Understanding:

    • Claude atau GPT-4 — explain dan analyze kode
    • GitHub Copilot Chat — inline explanation di editor

    Untuk Automated Refactoring:

    • Cursor / Windsurf — multi-file refactoring dengan konteks
    • JetBrains IDE — built-in refactoring tools yang kuat (rename, extract, inline)
    • VS Code refactoring tools — lebih basic tapi cukup untuk banyak kasus

    Untuk Testing:

    • Jest / Vitest — unit testing untuk JavaScript/TypeScript
    • Stryker — mutation testing untuk verify test quality

    Untuk Code Analysis:

    • SonarQube — static analysis untuk detect code smells
    • ESLint/TSLint dengan rule sets yang comprehensive

    Kasus Nyata: Refactoring God Function

    God function adalah function yang melakukan terlalu banyak hal — bisa ratusan bahkan ribuan baris. Ini salah satu yang paling umum di legacy code.

    Pendekatan step by step:

    1. Minta AI jelaskan apa yang function ini lakukan
    2. Identifikasi “natural sections” di dalam function
    3. Extract setiap section ke function terpisah dengan nama yang descriptive
    4. Test bahwa behavior sama
    5. Baru, kalau perlu, refactor lebih dalam di masing-masing function yang sudah di-extract

    Perlu diingat: tujuan awal bukan membuat kode sempurna — tapi membuat kode yang cukup dapat dipahami untuk bisa dimodifikasi dengan aman.


    Kapan Rewrite vs Refactor?

    Pertanyaan yang tidak ada jawaban universal:

    Pilih refactor ketika:

    • Sistem masih jalan dan ada user yang bergantung padanya
    • Business logic tersembunyi di kode, susah untuk didokumentasikan ulang dari awal
    • Risk of rewrite lebih tinggi dari benefit
    • Tim tidak punya waktu untuk rewrite total

    Pertimbangkan rewrite ketika:

    • Teknologi yang digunakan sudah tidak supported
    • Biaya maintenance lebih tinggi dari biaya rewrite
    • Kode sudah terlalu korup untuk diperbaiki secara incremental
    • Ada clear spec yang bisa jadi foundation untuk versi baru

    Rewrite total hampir selalu lebih susah dari yang diperkirakan. Mulai dari refactor, dan escalate ke rewrite hanya kalau refactor benar-benar tidak feasible.


    Kesimpulan

    Legacy code bukan musuh — ini aset yang perlu dirawat. AI sangat membantu untuk mempercepat pemahaman dan menemukan pola, tapi judgment dan kehati-hatian tetap di tangan kamu.

    Pendekatan yang benar: pelan, terstruktur, selalu ada test, dan ubah satu hal kecil pada satu waktu. Hasilnya mungkin tidak secepat yang diinginkan, tapi jauh lebih aman daripada refactoring yang tergesa-gesa.


    Punya codebase lama yang perlu dimodernisasi tapi tidak tahu harus mulai dari mana? Atau butuh bantuan merencanakan strategi refactoring yang aman? Yuk ngobrol — hubungi mafadev dan kita tackle bareng.

  • Buat Aplikasi AI Sendiri: Dari Nol sampai Deploy

    Buat Aplikasi AI Sendiri: Dari Nol sampai Deploy

    “Pengen membuat aplikasi AI tapi bingung mulai dari mana.”

    Ini yang paling sering saya dengar dari developer yang ingin masuk ke dunia AI. Banyak yang terjebak di fase research: baca terlalu banyak artikel, nonton terlalu banyak tutorial, tapi tidak ada yang dibangun.

    Artikel ini berbeda. Kita akan benar-benar build aplikasi AI sederhana tapi fungsional, dari nol sampai deploy. Bukan teori — ini praktek.


    Aplikasi yang Akan Kita Buat

    AI Document Q&A — sebuah aplikasi web di mana user bisa upload dokumen (PDF atau teks) dan bertanya tentang isinya. Sederhana tapi ini adalah foundation dari banyak use case enterprise nyata.

    Stack yang digunakan:

    • Backend: Node.js dengan Hono (lightweight, fast)
    • Frontend: HTML + vanilla JS (sesimpel mungkin agar fokus ke AI logic)
    • AI: Anthropic Claude API
    • Vector Database: Upstash Vector (free tier)
    • Deploy: Railway atau Fly.io

    Konsep yang Perlu Dipahami Dulu

    Sebelum coding, dua konsep penting yang perlu kamu mengerti:

    RAG (Retrieval-Augmented Generation)

    Masalah dengan langsung kirim dokumen ke LLM: dokumen besar tidak muat dalam context window, dan mahal kalau harus kirim seluruh dokumen setiap pertanyaan.

    Solusinya: RAG. Alurnya:

    1. Dokumen dipotong jadi chunk-chunk kecil
    2. Setiap chunk dikonversi jadi embedding (representasi numerik)
    3. Embedding disimpan di vector database
    4. Ketika ada pertanyaan, pertanyaan juga dikonversi jadi embedding
    5. Cari chunk yang paling relevan (nearest neighbor search)
    6. Kirim chunk relevan + pertanyaan ke LLM

    Embeddings

    Embedding adalah cara mengkonversi teks ke vektor angka di mana teks yang “maknanya mirip” akan punya vektor yang dekat satu sama lain. Model embedding yang populer: text-embedding-3-small dari OpenAI, atau embedding dari Voyage AI.


    Langkah 1: Setup Project

    mkdir ai-document-qa
    

    cd ai-document-qa

    npm init -y

    npm install hono @anthropic-ai/sdk @upstash/vector pdf-parse dotenv

    npm install -D typescript @types/node tsx

    Buat file .env:

    ANTHROPIC_API_KEY=sk-ant-xxx
    

    UPSTASH_VECTOR_REST_URL=https://xxx.upstash.io

    UPSTASH_VECTOR_REST_TOKEN=xxx


    Langkah 2: Setup Vector Database

    Daftar di upstash.com, buat Vector database baru dengan dimension 1536 (sesuai dengan model embedding yang akan kita pakai).


    Langkah 3: Document Processing

    Buat file src/document.ts:

    import Anthropic from '@anthropic-ai/sdk';
    

    import { Index } from '@upstash/vector';

    import pdfParse from 'pdf-parse';

    const anthropic = new Anthropic();

    const vectorIndex = new Index();

    // Potong teks jadi chunk dengan overlap

    function chunkText(text: string, chunkSize = 500, overlap = 50): string[] {

    const words = text.split(' ');

    const chunks: string[] = [];

    for (let i = 0; i < words.length; i += chunkSize - overlap) {

    const chunk = words.slice(i, i + chunkSize).join(' ');

    if (chunk.trim()) chunks.push(chunk);

    }

    return chunks;

    }

    // Generate embedding menggunakan Voyage AI via Anthropic

    async function generateEmbedding(text: string): Promise<number[]> {

    // Gunakan OpenAI embedding API atau Voyage AI

    // Untuk simplicity, kita gunakan mock 1536-dimension vector

    // Di production, integrasikan dengan embedding model yang proper

    const response = await fetch('https://api.voyageai.com/v1/embeddings', {

    method: 'POST',

    headers: {

    'Authorization': Bearer ${process.env.VOYAGE_API_KEY},

    'Content-Type': 'application/json'

    },

    body: JSON.stringify({

    input: text,

    model: 'voyage-3'

    })

    });

    const data = await response.json() as any;

    return data.data[0].embedding;

    }

    // Process dokumen: extract teks, chunk, embed, simpan

    export async function processDocument(

    buffer: Buffer,

    filename: string,

    mimeType: string

    ): Promise<{ chunks: number }> {

    let text = '';

    if (mimeType === 'application/pdf') {

    const pdfData = await pdfParse(buffer);

    text = pdfData.text;

    } else {

    text = buffer.toString('utf-8');

    }

    const chunks = chunkText(text);

    console.log(Processing ${chunks.length} chunks from ${filename});

    // Generate embeddings dan simpan ke vector database

    const vectors = await Promise.all(

    chunks.map(async (chunk, i) => {

    const embedding = await generateEmbedding(chunk);

    return {

    id: ${filename}-${i},

    vector: embedding,

    metadata: { text: chunk, filename, chunkIndex: i }

    };

    })

    );

    await vectorIndex.upsert(vectors);

    return { chunks: chunks.length };

    }

    // Cari chunk yang relevan dengan pertanyaan

    export async function searchRelevantChunks(

    query: string,

    topK = 5

    ): Promise<string[]> {

    const queryEmbedding = await generateEmbedding(query);

    const results = await vectorIndex.query({

    vector: queryEmbedding,

    topK,

    includeMetadata: true

    });

    return results

    .filter(r => r.metadata)

    .map(r => (r.metadata as any).text);

    }


    Langkah 4: Chat dengan Dokumen

    Buat file src/chat.ts:

    import Anthropic from '@anthropic-ai/sdk';
    

    import { searchRelevantChunks } from './document';

    const anthropic = new Anthropic();

    export async function askDocument(question: string): Promise<string> {

    // Ambil chunk yang relevan

    const relevantChunks = await searchRelevantChunks(question);

    if (relevantChunks.length === 0) {

    return 'Saya tidak menemukan informasi yang relevan dalam dokumen yang diupload.';

    }

    const context = relevantChunks.join('\n\n---\n\n');

    // Kirim ke Claude dengan konteks yang relevan

    const response = await anthropic.messages.create({

    model: 'claude-sonnet-4-5',

    max_tokens: 1024,

    messages: [

    {

    role: 'user',

    content: Kamu adalah asisten yang membantu menjawab pertanyaan berdasarkan dokumen yang diberikan.

    Berikut adalah bagian-bagian dokumen yang relevan dengan pertanyaan:

    ${context}

    Berdasarkan informasi di atas, jawab pertanyaan berikut:

    ${question}

    Kalau jawabannya tidak ada dalam dokumen, katakan dengan jelas bahwa informasi tersebut tidak ada dalam dokumen.

    }

    ]

    });

    return response.content[0].type === 'text'

    ? response.content[0].text

    : 'Tidak dapat menghasilkan respons.';

    }


    Langkah 5: API Server

    Buat file src/server.ts:

    import { Hono } from 'hono';
    

    import { serve } from '@hono/node-server';

    import { processDocument } from './document';

    import { askDocument } from './chat';

    const app = new Hono();

    // Upload dokumen

    app.post('/upload', async (c) => {

    try {

    const formData = await c.req.formData();

    const file = formData.get('file') as File;

    if (!file) {

    return c.json({ error: 'No file provided' }, 400);

    }

    const buffer = Buffer.from(await file.arrayBuffer());

    const result = await processDocument(buffer, file.name, file.type);

    return c.json({

    success: true,

    message: Dokumen diproses: ${result.chunks} chunks

    });

    } catch (error) {

    return c.json({ error: 'Gagal memproses dokumen' }, 500);

    }

    });

    // Tanya dokumen

    app.post('/ask', async (c) => {

    try {

    const { question } = await c.req.json();

    if (!question) {

    return c.json({ error: 'Question is required' }, 400);

    }

    const answer = await askDocument(question);

    return c.json({ answer });

    } catch (error) {

    return c.json({ error: 'Gagal mendapatkan jawaban' }, 500);

    }

    });

    // Serve static files untuk frontend

    app.get('/', (c) => {

    return c.html(

    <!DOCTYPE html>

    <html>

    <head>

    <title>AI Document Q&A</title>

    <style>

    body { font-family: sans-serif; max-width: 800px; margin: 50px auto; padding: 20px; }

    textarea { width: 100%; height: 100px; margin: 10px 0; }

    button { background: #0070f3; color: white; border: none; padding: 10px 20px; cursor: pointer; border-radius: 5px; }

    #answer { margin-top: 20px; padding: 15px; background: #f5f5f5; border-radius: 5px; }

    </style>

    </head>

    <body>

    <h1>AI Document Q&A</h1>

    <h2>1. Upload Dokumen</h2>

    <input type="file" id="fileInput" accept=".pdf,.txt">

    <button onclick="uploadFile()">Upload</button>

    <p id="uploadStatus"></p>

    <h2>2. Tanya tentang Dokumen</h2>

    <textarea id="question" placeholder="Tulis pertanyaan kamu..."></textarea>

    <button onclick="askQuestion()">Tanya</button>

    <div id="answer"></div>

    <script>

    async function uploadFile() {

    const file = document.getElementById('fileInput').files[0];

    if (!file) return alert('Pilih file dulu');

    const formData = new FormData();

    formData.append('file', file);

    const res = await fetch('/upload', { method: 'POST', body: formData });

    const data = await res.json();

    document.getElementById('uploadStatus').textContent = data.message || data.error;

    }

    async function askQuestion() {

    const question = document.getElementById('question').value;

    if (!question) return alert('Tulis pertanyaan dulu');

    document.getElementById('answer').textContent = 'Mencari jawaban...';

    const res = await fetch('/ask', {

    method: 'POST',

    headers: { 'Content-Type': 'application/json' },

    body: JSON.stringify({ question })

    });

    const data = await res.json();

    document.getElementById('answer').textContent = data.answer || data.error;

    }

    </script>

    </body>

    </html>

    );

    });

    serve({ fetch: app.fetch, port: 3000 });

    console.log('Server running at http://localhost:3000');


    Langkah 6: Deploy

    Deploy ke Railway (paling mudah):

    # Install Railway CLI
    

    npm install -g @railway/cli

    Login dan deploy

    railway login

    railway init

    railway up

    Railway akan otomatis detect Node.js project dan deploy. Set environment variables melalui Railway dashboard.

    Atau deploy ke Fly.io:

    # Install Fly CLI
    

    curl -L https://fly.io/install.sh | sh

    Deploy

    fly launch

    fly secrets set ANTHROPIC_API_KEY=xxx

    fly secrets set UPSTASH_VECTOR_REST_URL=xxx

    fly secrets set UPSTASH_VECTOR_REST_TOKEN=xxx

    fly deploy


    Apa Selanjutnya?

    Ini adalah foundation. Dari sini kamu bisa extend ke:

    • Multi-document support — track dokumen per user dengan metadata filtering
    • Conversation history — chat yang ingat context percakapan sebelumnya
    • Streaming responses — jawaban muncul per token, bukan nunggu selesai semua
    • Authentication — user management dengan Supabase Auth
    • Document management — list, delete, organize dokumen yang sudah diupload

    Kesimpulan

    Membangun aplikasi AI tidak harus menunggu sampai kamu “siap” atau sampai kamu mengerti semuanya. Foundation dari semua aplikasi AI berbasis dokumen adalah sama: chunk, embed, retrieve, generate.

    Mulai dari yang sederhana, deploy ke production (walaupun belum sempurna), lalu iterate berdasarkan feedback nyata.


    Punya ide aplikasi AI yang mau dibangun tapi bingung bagaimana arsitekturnya? Atau butuh bantuan dari proof of concept sampai production-ready? Yuk ngobrol — hubungi mafadev dan kita wujudkan bareng.