DEV Community: Agung Gumelar

Strategi Memilih Tech Stack di 2026: Antara Tren AI dan Stabilitas "Boring Infra"

Agung Gumelar — Sat, 03 Oct 2026 23:16:06 +0000

Strategi Memilih Tech Stack di 2026: Antara Tren AI dan Stabilitas "Boring Infra"

Memasuki akhir 2026, kita berada di titik yang menarik dalam evolusi pengembangan perangkat lunak. Jika beberapa tahun lalu kita merasa harus mencoba setiap framework baru yang muncul di Twitter atau GitHub agar tetap relevan, tahun ini polanya mulai berubah. Ada semacam kelelahan massal terhadap hype yang berlebihan, dan industri mulai bergerak kembali ke arah yang lebih pragmatis: stabilitas.

Banyak tim engineering sekarang lebih memilih apa yang sering disebut sebagai "boring infrastructure". Bukan berarti mereka tidak inovatif, tetapi mereka sadar bahwa inovasi seharusnya terjadi pada fitur produk dan pengalaman pengguna, bukan pada perjuangan mengonfigurasi orchestrator container yang kompleks atau bermigrasi antar framework setiap enam bulan.

Standar Baru yang Menjadi "Default"

Kalau kita melihat ekosistem saat ini, kombinasi React 19 dan Next.js 16 tetap menjadi pilihan paling aman bagi mayoritas aplikasi web. Mengapa? Karena ekosistemnya sudah terlalu besar untuk diabaikan. Dengan hadirnya React Compiler yang menangani memoization secara otomatis, banyak masalah performa yang dulu kita selesaikan secara manual dengan useMemo atau useCallback kini hilang dengan sendirinya. Kode jadi lebih bersih, dan developer bisa lebih fokus pada logika bisnis.

Di sisi database, PostgreSQL kembali menegaskan posisinya sebagai "satu database untuk segala kebutuhan". Dulu kita mungkin merasa perlu memisahkan data relasional di Postgres, data dokumen di MongoDB, dan data vektor di database khusus untuk AI. Namun, dengan perkembangan pgvector, Postgres kini mampu menangani pencarian semantik dan embedding AI dengan sangat efisien. Strategi "satu database" ini mengurangi kompleksitas operasional secara signifikan.

Kapan Harus Keluar dari Zona Nyaman?

Meskipun stack di atas sangat stabil, ada momen di mana kita harus berani mengambil jalur berbeda. Jika Anda membangun layanan yang membutuhkan throughput sangat tinggi atau sistem microservices yang harus sangat efisien dalam penggunaan memori, Go tetap menjadi juara. Kesederhanaan Go dalam menangani konkurensi melalui goroutines membuatnya sulit dikalahkan untuk urusan backend skala besar.

Begitu juga dengan SvelteKit. Bagi tim kecil yang memprioritaskan kecepatan runtime dan ukuran bundle yang minimal, SvelteKit menawarkan pengalaman yang jauh lebih ringan dibanding React. Namun, tantangannya tetap sama: ketersediaan talenta di pasar kerja. Memilih SvelteKit berarti Anda harus siap menginvestasikan waktu lebih untuk onboarding anggota tim baru.

Mengintegrasikan AI ke dalam Arsitektur

Tahun 2026 bukan lagi soal "apakah kita menggunakan AI", tapi "bagaimana AI masuk ke dalam alur kerja". Kita melihat pergeseran dari sekadar menggunakan API LLM untuk chat, menjadi integrasi agentik yang lebih dalam. Penggunaan tool seperti Cursor atau Claude Code telah mengubah cara kita menulis kode, namun risiko yang muncul adalah hilangnya pemahaman mendalam terhadap arsitektur karena terlalu mengandalkan generator.

Secara arsitektural, tren yang muncul adalah membangun sistem yang AI-ready. Artinya, data harus terstruktur dengan baik agar mudah diindeks oleh LLM, dan API harus dirancang secara modular agar agent AI dapat berinteraksi dengan sistem melalui tool calling yang jelas dan aman.

Kembali ke Dasar: Fokus pada Hasil

Satu hal yang bisa kita pelajari dari tren tahun ini adalah bahwa tool hanyalah sarana. Kita melihat banyak startup yang gagal bukan karena salah memilih framework, tetapi karena terlalu terobsesi dengan "tech stack tercanggih" sementara produknya tidak menjawab kebutuhan pasar.

Infrastruktur yang "membosankan" seperti Vercel, Railway, atau Docker sederhana justru memberikan ruang bagi developer untuk bereksperimen dengan fitur-fitur berisiko tinggi tanpa harus khawatir sistem mereka runtuh karena kesalahan konfigurasi infra.

Pada akhirnya, tech stack terbaik di 2026 adalah stack yang memungkinkan tim Anda mengirimkan nilai ke pengguna secepat mungkin dengan tingkat stres yang paling rendah. Apakah itu berarti menggunakan stack yang sudah mapan atau mencoba sesuatu yang baru, kuncinya ada pada keseimbangan antara inovasi dan stabilitas.

Menurut Anda, apakah kita sudah terlalu bergantung pada ekosistem tertentu, atau memang stabilitas adalah satu-satunya jalan keluar dari kelelahan teknologi saat ini?

Membangun Pipeline Agen AI Otonom: Melampaui Sekadar Prompting

Agung Gumelar — Sat, 03 Oct 2026 14:04:13 +0000

Membangun Pipeline Agen AI Otonom: Melampaui Sekadar Prompting

Beberapa tahun terakhir, kita terbiasa berinteraksi dengan LLM (Large Language Model) melalui pola tanya-jawab sederhana. Kita memberikan prompt, dan model memberikan jawaban. Namun, jika kita melihat ke arah perkembangan teknologi saat ini, pola "satu prompt, satu jawaban" mulai terasa terbatas. Kita tidak lagi hanya butuh jawaban, tapi kita butuh hasil kerja. Di sinilah konsep Agen AI Otonom masuk.

Agen AI bukan sekadar chatbot yang diberi persona. Perbedaan mendasarnya terletak pada kemampuan agen untuk melakukan reasoning (penalaran), merencanakan langkah-langkah, menggunakan alat (tools), dan yang paling penting: mengoreksi dirinya sendiri ketika terjadi kesalahan.

Dari LLM ke Agentic Workflow

Jika LLM adalah "otak", maka Agen AI adalah otak yang memiliki tangan, kaki, dan buku catatan. Dalam pipeline tradisional, kita sering mencoba memasukkan semua instruksi ke dalam satu prompt yang sangat panjang (mega-prompt) dengan harapan model akan mengikuti semua langkahnya. Masalahnya, semakin panjang instruksinya, semakin besar kemungkinan model kehilangan fokus atau melakukan kesalahan di tengah jalan.

Pendekatan yang lebih modern adalah memecah proses tersebut menjadi sebuah workflow agen. Alih-alih meminta AI untuk "Menulis artikel lengkap dengan riset", kita membuat pipeline seperti ini:

Agen Peneliti: Mencari sumber informasi valid di internet.
Agen Penulis: Menyusun draf berdasarkan hasil riset.
Agen Editor: Mengkritik draf tersebut, mencari celah logika, dan meminta revisi jika perlu.
Agen Finalizer: Memastikan format sudah sesuai dan siap dipublikasikan.

Arsitektur Dasar Pipeline Agen

Untuk membangun sistem seperti ini, ada beberapa komponen kunci yang harus ada:

1. Planning (Perencanaan)
Agen harus mampu memecah tugas kompleks menjadi sub-tugas yang lebih kecil. Teknik seperti Chain-of-Thought atau Tree-of-Thoughts memungkinkan agen untuk memikirkan langkah-langkahnya sebelum mengeksekusinya. Tanpa perencanaan, agen cenderung terburu-buru memberikan jawaban yang terlihat benar tapi secara logika cacat.

2. Tool Use (Penggunaan Alat)
Inilah yang memberikan "kekuatan" pada agen. Dengan memberikan akses ke API, database, atau eksekutor kode (seperti Python REPL), agen bisa melakukan hal-hal yang tidak bisa dilakukan oleh model bahasa murni, seperti menghitung matematika kompleks secara akurat atau mengambil data real-time dari web.

3. Memory (Memori)
Ada dua jenis memori yang krusial: memori jangka pendek (konteks percakapan saat ini) dan memori jangka panjang (biasanya menggunakan Vector Database seperti Pinecone atau Milvus). Dengan memori jangka panjang, agen bisa mengingat preferensi pengguna atau hasil pekerjaan dari sesi sebelumnya.

4. Reflection (Refleksi)
Ini adalah bagian yang paling sering dilupakan. Agen yang hebat adalah agen yang bisa bertanya pada dirinya sendiri: "Apakah jawaban ini sudah benar? Apakah saya melewatkan sesuatu?". Proses iterasi internal ini secara drastis meningkatkan kualitas output akhir.

Tantangan dalam Implementasi

Membangun agen otonom tidak semudah menyusun prompt. Ada beberapa tantangan teknis yang sering muncul:

Infinite Loops: Agen bisa terjebak dalam siklus di mana ia terus-menerus mencoba memperbaiki kesalahan yang sama tanpa hasil. Kita perlu menetapkan max iterations atau timeout.
Hallucinations in Tool Use: Terkadang agen mencoba menggunakan parameter API yang tidak ada atau mengarang sintaks kode. Validasi input dan output di level kode (bukan di level LLM) sangat penting.
State Management: Mengelola state di antara berbagai agen dalam satu pipeline bisa menjadi sangat kompleks, terutama jika kita ingin bisa melakukan rollback ke langkah sebelumnya.

Memilih Stack yang Tepat

Saat ini sudah banyak framework yang memudahkan kita membangun pipeline agen. LangGraph dari LangChain sangat kuat untuk membuat workflow yang memiliki siklus (cyclic graphs). CrewAI menawarkan abstraksi yang lebih tinggi dengan konsep "peran" yang memudahkan koordinasi antar agen. Namun, bagi yang membutuhkan kontrol penuh, membangun custom loop dengan bantuan library sederhana seringkali menjadi pilihan terbaik untuk menghindari overhead framework yang terlalu besar.

Transisi dari sekadar "prompting" menuju "agentic workflow" adalah pergeseran paradigma. Kita tidak lagi sekadar menulis instruksi, tetapi kita sedang mendesain sebuah sistem kerja.

Menurut Anda, apakah ke depannya kita akan lebih banyak menggunakan agen-agen kecil yang terspesialisasi, atau satu agen besar yang mampu melakukan segalanya?

Mengapa PostgreSQL Menjadi Pilihan Utama di Tahun 2026?

Agung Gumelar — Fri, 02 Oct 2026 12:01:33 +0000

Beberapa tahun lalu, tren di dunia software engineering adalah menggunakan "the right tool for the right job". Jika butuh data terstruktur, pakai SQL. Jika datanya tidak menentu, pakai MongoDB. Kalau butuh pencarian cepat, pasang Elasticsearch. Untuk AI embeddings, mungkin pakai Pinecone. Hasilnya? Arsitektur kita jadi kompleks. Kita harus mengelola lima database berbeda, lima cara backup, dan lima jenis monitoring.

Namun, memasuki tahun 2026, paradigma ini mulai bergeser. Ada kecenderungan kuat untuk kembali ke kesederhanaan, dan PostgreSQL berada tepat di tengah transformasi ini.

PostgreSQL bukan lagi sekadar database relasional tradisional. Bagi saya, Postgres sekarang lebih tepat disebut sebagai "platform data". Salah satu alasan utamanya adalah kemampuan JSONB. Dulu, kita pindah ke MongoDB karena fleksibilitas skema. Sekarang, dengan JSONB yang terindeks dengan baik, kita bisa mendapatkan fleksibilitas NoSQL tanpa kehilangan integritas data ACID yang menjadi kekuatan utama SQL.

Lalu ada ledakan AI. Hampir setiap aplikasi sekarang butuh fitur pencarian semantik atau rekomendasi berbasis vector. Alih-alih menambahkan database vector khusus yang menambah beban operasional, banyak tim mulai menggunakan pgvector. Kemampuan untuk menyimpan embedding AI di dalam tabel yang sama dengan data pengguna adalah sebuah "game changer". Kita bisa melakukan join antara data profil pengguna dan pencarian vector dalam satu query tunggal.

Selain fitur teknis, ada faktor psikologis yang menarik: "Boring Technology". Di tengah hiruk-pikuk framework baru yang muncul setiap minggu, ada ketenangan tersendiri saat menggunakan teknologi yang sudah teruji selama puluhan tahun. PostgreSQL sangat stabil, dokumentasinya luar biasa, dan ekosistemnya sangat luas.

Tentu saja, Postgres bukan obat untuk segala penyakit. Untuk data skala petabyte dengan throughput tulis yang ekstrem, kita mungkin masih butuh solusi terdistribusi seperti Cassandra atau ScyllaDB. Tapi untuk 95% aplikasi bisnis, SaaS, atau startup, bertanya "Apakah saya benar-benar butuh database lain?" adalah pertanyaan yang harus diajukan sebelum menambah kompleksitas.

Pada akhirnya, efisiensi bukan tentang menggunakan alat paling canggih, tapi tentang meminimalkan jumlah alat yang harus dijaga agar tetap menyala. Dengan satu database yang bisa melakukan hampir semuanya, tim engineering bisa lebih fokus pada fitur produk daripada mengurusi infrastruktur.

Bagaimana dengan kalian? Apakah masih merasa perlu memisahkan data antara SQL dan NoSQL, atau sudah mulai mengkonsolidasikan semuanya ke satu tempat?

Apakah Era Vector Database Spesialis Sudah Berakhir? Menimbang pgvector dan Integrasi Database Modern

Agung Gumelar — Thu, 01 Oct 2026 23:34:13 +0000

Apakah Era Vector Database Spesialis Sudah Berakhir? Menimbang pgvector dan Integrasi Database Modern

Beberapa tahun terakhir, kita melihat ledakan "Vector Database" sebagai kategori produk baru. Pinecone, Milvus, Weaviate—semuanya muncul dengan janji performa pencarian kemiripan (similarity search) yang jauh lebih cepat untuk mendukung aplikasi LLM dan RAG (Retrieval-Augmented Generation). Bagi banyak pengembang, pilihannya terlihat sederhana: jika Anda butuh menyimpan embedding AI, Anda butuh vector database.

Namun, baru-baru ini ada diskusi menarik di komunitas teknis, termasuk di Hacker News, yang mulai mempertanyakan urgensi dari database spesialis ini. Pertanyaannya sederhana: apakah kita benar-benar butuh satu lagi database di dalam stack infrastruktur kita, atau apakah database yang sudah kita gunakan sebenarnya sudah cukup?

Jebakan Kompleksitas Infrastruktur

Sebagai engineer, kita semua tahu bahwa setiap database baru yang ditambahkan ke arsitektur berarti tambahan beban operasional. Ada backup yang harus dikelola, monitoring yang harus dipasang, dan yang paling menyebalkan: sinkronisasi data.

Bayangkan skenario ini: Anda memiliki data user dan metadata produk di PostgreSQL, tetapi embedding-nya disimpan di vector database terpisah. Setiap kali ada perubahan pada metadata produk, Anda harus memastikan embedding-nya juga diperbarui di database sebelah. Jika salah satu gagal, Anda berakhir dengan data yang tidak konsisten. Ini adalah masalah klasik distributed systems yang seharusnya bisa kita hindari.

Kebangkitan pgvector dan Database Generalis

Di sinilah pgvector masuk. Bagi pengguna PostgreSQL, ekstensi ini mengubah cara kita memandang data vektor. Tiba-tiba, kita bisa menyimpan embedding tepat di samping data relasional kita. Kita bisa melakukan query JOIN antara tabel user dengan pencarian vektor dalam satu transaksi ACID yang sama.

Bagi banyak kasus penggunaan, performa pgvector sudah lebih dari cukup. Memang, database spesialis mungkin unggul dalam skala miliaran vektor dengan latency mikrosestikon, tetapi untuk mayoritas aplikasi startup atau fitur pencarian internal perusahaan, PostgreSQL dengan indeks HNSW (Hierarchical Navigable Small World) sudah memberikan hasil yang sangat cepat.

MongoDB juga melakukan hal serupa dengan Atlas Vector Search. Polanya jelas: database tradisional tidak ingin kehilangan pasar AI. Mereka mengintegrasikan kapabilitas vektor langsung ke dalam core engine mereka.

Kapan Sebenarnya Kita Butuh Vector DB Spesialis?

Apakah ini berarti vector database spesialis akan mati? Tidak juga. Ada titik di mana skalabilitas ekstrem menjadi harga mati. Jika Anda membangun sistem seperti Spotify atau Pinterest yang harus menangani pencarian kemiripan dalam skala masif dengan throughput ribuan request per detik, infrastruktur yang didesain khusus untuk vektor tetap akan menang.

Namun, bagi sebagian besar dari kita, "cukup cepat" itu jauh lebih berharga daripada "paling cepat" jika harganya adalah kompleksitas operasional yang tinggi.

Menentukan Pilihan yang Tepat

Jika saya harus memberi saran untuk proyek baru saat ini, saya akan menyarankan untuk memulai dengan apa yang sudah Anda miliki. Jika Anda sudah menggunakan PostgreSQL, gunakan pgvector. Jika Anda di ekosistem MongoDB, gunakan Atlas Vector Search.

Jangan menambah kompleksitas hanya karena tren mengatakan kita butuh "AI-native database". Seringkali, solusi terbaik bukanlah teknologi terbaru, melainkan teknologi yang paling stabil dan terintegrasi dengan baik dalam ekosistem Anda.

Pada akhirnya, tujuan kita adalah mengirimkan fitur ke pengguna, bukan membangun museum infrastruktur yang rumit.

Menurut teman-teman yang sudah implementasi RAG, apakah kalian merasa beban operasional mengelola vector database terpisah sebanding dengan peningkatan performanya, atau justru merasa lebih nyaman dengan pendekatan terintegrasi?

Transisi dari Chatbot ke AI Agent: Mengapa Arsitektur "Agentic" adalah Masa Depan Software Engineering

Agung Gumelar — Tue, 29 Sep 2026 23:44:45 +0000

Transisi dari Chatbot ke AI Agent: Mengapa Arsitektur "Agentic" adalah Masa Depan Software Engineering

Beberapa tahun terakhir, kita semua terbiasa dengan pola interaksi "prompt-response". Kita memberikan input, LLM memberikan jawaban. Sederhana, namun terbatas. Chatbot, sehebat apa pun, pada dasarnya adalah mesin prediksi teks yang sangat canggih. Masalah muncul ketika kita menginginkan AI yang tidak hanya bisa "berbicara", tetapi bisa "bekerja".

Di sinilah konsep AI Agent mulai mengambil alih.

Apa Bedanya Chatbot dengan AI Agent?

Jika chatbot adalah seorang konsultan yang memberi tahu Anda cara memperbaiki pipa bocor, maka AI Agent adalah tukang ledeng yang datang ke rumah, membawa peralatan, mendiagnosa kebocoran, dan memperbaikinya sampai tuntas.

Perbedaan utamanya terletak pada otonomi dan loop eksekusi. Chatbot bekerja secara linear: User $\rightarrow$ LLM $\rightarrow$ Output. Sementara AI Agent bekerja dalam sebuah loop: Goal $\rightarrow$ Planning $\rightarrow$ Action $\rightarrow$ Observation $\rightarrow$ Re-planning $\rightarrow$ Goal Achieved.

Agentic workflow memungkinkan AI untuk menggunakan tools. Ia bisa memanggil API, menjalankan skrip Python, membaca database, atau bahkan browsing web untuk memverifikasi informasi sebelum memberikan jawaban akhir.

Tantangan System Design dalam Membangun Agent

Membangun sistem agentic bukan sekadar membungkus LLM dengan loop while True. Ada tantangan arsitektur yang cukup berat yang harus dihadapi oleh software engineer.

1. State Management dan Memori
Agent membutuhkan memori jangka pendek (untuk melacak langkah yang sudah diambil dalam satu task) dan memori jangka panjang (untuk mengingat preferensi user atau hasil dari task sebelumnya). Implementasi Vector Database seperti PostgreSQL dengan pgvector atau MongoDB Atlas Vector Search menjadi krusial di sini untuk menyimpan "pengalaman" agent secara efisien.

2. Tool Definition dan Error Handling
Memberikan tool kepada AI adalah seperti memberikan senjata kepada anak kecil jika tidak ada pengaman. Bagaimana jika agent memanggil fungsi delete_user() secara tidak sengaja? Kita membutuhkan lapisan validasi (guardrails) dan human-in-the-loop untuk aksi-aksi yang bersifat destruktif.

3. Loop Halusinasi (Infinite Loops)
Ada risiko di mana agent terjebak dalam loop: mencoba sebuah tool $\rightarrow$ gagal $\rightarrow$ mencoba tool yang sama lagi dengan prompt yang hampir mirip $\rightarrow$ gagal lagi. Menentukan "stop condition" yang cerdas adalah bagian tersulit dari desain agentic.

Mengapa Ini Relevan bagi Kita Sekarang?

Jika kita melihat perkembangan framework seperti LangGraph, CrewAI, atau AutoGPT, trennya jelas: kita sedang bergerak menuju sistem di mana AI menjadi "orkestrator".

Sebagai developer, peran kita akan bergeser. Kita tidak lagi hanya menulis fungsi bisnis, tetapi mendesain "lingkungan" di mana AI Agent bisa beroperasi dengan aman. Kita akan lebih banyak berkutat pada desain API yang agent-friendly, pembuatan dokumentasi tool yang presisi, dan pengawasan terhadap efisiensi token serta latensi eksekusi.

Menatap Masa Depan

Ke depan, saya rasa kita tidak akan lagi menggunakan aplikasi yang terdiri dari banyak menu dan tombol yang rumit. Interface-nya akan menjadi minimalis—mungkin hanya satu kolom input atau perintah suara—namun di belakangnya ada sekumpulan agent yang saling berkoordinasi untuk menyelesaikan permintaan kita.

Satu agent mencari data di PostgreSQL, agent lain memprosesnya dengan Golang service, dan agent ketiga memformat hasilnya menjadi laporan yang rapi.

Pertanyaannya sekarang, apakah kita sudah siap membangun infrastruktur yang cukup stabil untuk menopang otonomi seperti ini, atau kita justru akan kewalahan mengelola "karyawan digital" yang bisa bekerja ribuan kali lebih cepat dari kita namun tetap bisa melakukan kesalahan fatal?

SvelteKit vs Next.js di 2026: Apakah Pendekatan Compiler Akhirnya Menang?

Agung Gumelar — Tue, 29 Sep 2026 20:04:01 +0000

SvelteKit vs Next.js di 2026: Apakah Pendekatan Compiler Akhirnya Menang?

Beberapa tahun terakhir, perdebatan antara framework berbasis runtime dan compiler tidak pernah benar-benar selesai. Di satu sisi, kita punya Next.js yang menjadi standar industri dengan ekosistem React yang masif. Di sisi lain, SvelteKit terus mengusik dengan janji performa maksimal dan bundle size yang jauh lebih ramping. Memasuki tahun 2026, lanskap ini menjadi semakin menarik dengan hadirnya SvelteKit 3.

Salah satu poin paling krusial yang sering dibahas adalah "runtime tax". React, secara desain, membawa runtime yang cukup besar ke browser untuk mengelola Virtual DOM dan proses rekonsiliasi. Bagi banyak aplikasi, beban ini tidak terasa. Namun, ketika kita bicara tentang optimasi ekstrem atau aplikasi yang ditujukan untuk perangkat dengan spesifikasi rendah, perbedaan 27KB (SvelteKit) dibandingkan 128KB (Next.js) untuk halaman sederhana menjadi angka yang signifikan.

Yang membuat SvelteKit 3 terasa lebih agresif tahun ini adalah pengenalan remote functions. Konsep ini membawa Type-safe Remote Procedure Calls (RPC) langsung ke dalam komponen halaman. Jika sebelumnya kita harus mendefinisikan API route secara terpisah di Next.js atau menggunakan library tambahan untuk mendapatkan type-safety yang ketat antara server dan client, SvelteKit mencoba menyederhanakannya. Kita bisa memanggil fungsi server seolah-olah itu adalah fungsi lokal, tanpa kehilangan informasi tipe data. Ini adalah lompatan besar dalam Developer Experience (DX).

Namun, kita harus jujur bahwa Next.js tidak tinggal diam. Dengan Turbopack yang kini menjadi standar, kecepatan development server sudah hampir setara. React Server Components (RSC) juga secara efektif mengurangi jumlah JavaScript yang dikirim ke client untuk halaman yang bersifat konten-berat. Next.js telah berevolusi dari sekadar framework menjadi sebuah platform yang sangat terintegrasi, terutama jika kita menggunakan Vercel.

Lalu, kapan kita harus memilih salah satunya?

Jika prioritas utama adalah kecepatan load awal, efisiensi bundle, dan tim Anda tidak memiliki ketergantungan berat pada ekosistem React, SvelteKit adalah pilihan yang sangat masuk akal. Pendekatan compiler-nya membuat aplikasi terasa lebih ringan dan "dekat" dengan vanilla JavaScript.

Namun, jika Anda membangun aplikasi skala enterprise dengan tim besar yang sudah fasih dengan React, atau membutuhkan library UI yang sangat spesifik yang hanya tersedia di ekosistem React, Next.js tetap menjadi pilihan paling aman. Dukungan komunitas dan jumlah library pihak ketiga masih menjadi benteng terkuat Next.js.

Pada akhirnya, kita sedang melihat konvergensi. Kedua framework ini mulai mengadopsi fitur satu sama lain. Next.js mencoba menjadi lebih ringan, sementara SvelteKit mencoba menjadi lebih lengkap untuk skala enterprise. Pilihan framework seharusnya tidak lagi didasarkan pada "mana yang lebih cepat" secara absolut, melainkan "mana yang paling cocok dengan alur kerja tim dan kebutuhan end-user".

Menurut Anda, apakah kemudahan RPC di SvelteKit 3 cukup untuk membuat Anda berpindah dari ekosistem React, ataukah kestabilan ekosistem masih menjadi pertimbangan utama?

Era Agentic Engineering: Ketika Developer Berhenti Menulis Kode dan Mulai Merancang Niat

Agung Gumelar — Mon, 28 Sep 2026 23:01:59 +0000

Era Agentic Engineering: Ketika Developer Berhenti Menulis Kode dan Mulai Merancang Niat

Ada satu perasaan aneh yang muncul kalau kita melihat cara kerja software engineering di tahun 2026 ini. Kalau beberapa tahun lalu kita merasa AI adalah "asisten" yang membantu autocomplete baris kode kita, sekarang rasanya lebih seperti kita sedang mengelola tim kecil yang sangat efisien. Kita tidak lagi berkutat dengan syntax error atau menghabiskan waktu berjam-jam hanya untuk mencari tahu kenapa sebuah state di React tidak terupdate.

Kita sedang memasuki era Agentic Engineering.

Pergeseran ini bukan sekadar tentang alat yang lebih pintar, tapi tentang perubahan fundamental dalam cara kita memandang proses pembuatan software. Kita sedang berpindah dari peran sebagai "penulis kode" menjadi seorang "arsitek niat" (intent architect).

Dari Copilot Menjadi Agen

Dulu, kita mengenal GitHub Copilot atau ChatGPT sebagai alat reaktif. Kita tulis sesuatu, mereka beri saran. Hubungannya adalah: manusia mengarahkan, AI melengkapi. Namun, di tahun 2026, paradigma ini terbalik. AI kini menjadi proaktif.

Agen AI saat ini tidak hanya menyarankan fungsi; mereka bisa membaca seluruh repositori, memahami hubungan antar modul, merencanakan perubahan arsitektur, menjalankan tes, dan melakukan debug secara mandiri sebelum akhirnya menyodorkan Pull Request kepada kita. Perbedaannya jelas: asisten membantu kita menulis kode, sedangkan agen membantu kita menyelesaikan fitur.

Bagi banyak dari kita, ini mungkin terasa mengancam. Namun, jika dilihat lebih dalam, ini sebenarnya adalah pembebasan. Beban kognitif yang dulu habis untuk memikirkan implementasi mekanis kini bisa dialihkan untuk memikirkan hal yang lebih krusial: Apa masalah yang sebenarnya ingin kita selesaikan? Bagaimana sistem ini harus berskala? Apakah alur datanya sudah efisien?

Stack Modern yang "Boring" tapi Powerfull

Menariknya, di tengah ledakan AI, pilihan teknologi untuk membangun sistem justru cenderung kembali ke hal-hal yang stabil namun memiliki performa tinggi. Kita melihat konsolidasi yang kuat pada beberapa teknologi utama.

TypeScript 7 dengan compiler berbasis Go-nya telah memangkas waktu build secara drastis, membuat siklus pengembangan terasa instan. Di sisi frontend, React 19 dengan Server Components yang sudah matang menjadi standar karena efisiensinya dalam pengiriman konten.

Untuk backend, Go 1.27 tetap menjadi primadona untuk layanan dengan throughput tinggi karena kesederhanaan dan kecepatan eksekusinya. Sementara itu, PostgreSQL kembali menjadi pusat dari segalanya. Dengan adanya pgvector, kita tidak perlu lagi menambah database vektor terpisah hanya untuk fitur AI; semua bisa dilakukan di dalam satu engine yang sudah teruji selama puluhan tahun.

Ini membuktikan bahwa dalam dunia yang bergerak sangat cepat, infrastruktur yang "membosankan" dan stabil justru menjadi fondasi paling aman untuk membangun inovasi yang kompleks.

Skill Baru: Merancang Niat dan Mengelola Konteks

Lantas, kalau AI bisa menulis kode, apa yang harus dipelajari oleh seorang developer?

Jawabannya adalah System Design dan Intent Architecture. Kemampuan untuk memecah masalah besar menjadi instruksi yang presisi, tidak ambigu, dan terstruktur kini menjadi skill yang jauh lebih berharga daripada sekadar hafal API framework tertentu.

Kita tidak lagi hanya belajar cara menulis fungsi, tapi belajar cara mendefinisikan constraints (batasan), menentukan kriteria keberhasilan, dan melakukan audit terhadap hasil yang diberikan oleh agen AI. Kita menjadi kurator. Kita harus bisa melihat sebuah diff kode yang dihasilkan AI dan tahu apakah itu hanya "bekerja" atau memang "benar" secara arsitektur.

Selain itu, muncul konsep Agent Skills—di mana kita mendokumentasikan workflow, standar kualitas, dan best practice dalam file Markdown yang kemudian digunakan oleh agen AI sebagai panduan. Jadi, dokumentasi bukan lagi sekadar catatan untuk manusia, tapi menjadi "otak" tambahan bagi sistem AI yang kita gunakan.

Menghadapi Masa Depan

Transisi menuju Agentic Engineering memang membawa ketidakpastian. Namun, sejarah membuktikan bahwa setiap kali alat abstraksi naik tingkat—dari bahasa mesin ke bahasa tingkat tinggi, dari monolith ke cloud—peran developer tidak hilang, melainkan berevolusi.

Kita tidak lagi dinilai dari berapa banyak baris kode yang kita hasilkan dalam sehari, tapi dari seberapa elegan solusi yang kita rancang dan seberapa efektif kita bisa mengorkestrasi berbagai alat untuk mewujudkannya.

Pertanyaannya sekarang bukan lagi "Apakah AI akan menggantikan programmer?", melainkan "Seberapa cepat kita bisa berubah dari seorang tukang ketik kode menjadi seorang arsitek sistem yang mampu mengarahkan kecerdasan buatan?"

PostgreSQL vs MongoDB di Era AI: Masihkah Document Store Menjadi Pilihan Utama?

Agung Gumelar — Mon, 28 Sep 2026 12:01:42 +0000

PostgreSQL vs MongoDB di Era AI: Masihkah Document Store Menjadi Pilihan Utama?

Perdebatan antara SQL dan NoSQL adalah salah satu diskusi paling klasik di dunia software engineering. Selama bertahun-tahun, narasinya selalu sama: gunakan PostgreSQL jika kamu butuh konsistensi dan relasi yang kuat, atau gunakan MongoDB jika kamu butuh fleksibilitas skema dan skalabilitas horizontal yang cepat. Namun, memasuki tahun 2026, lanskap ini telah berubah secara signifikan, terutama dengan ledakan aplikasi berbasis AI dan LLM.

Dulu, alasan utama orang memilih MongoDB adalah kemampuannya menangani data semi-terstruktur melalui format BSON. Kita merasa "bebas" karena tidak perlu melakukan migrasi skema setiap kali ada perubahan fitur. Namun, PostgreSQL menjawab tantangan ini dengan JSONB. Saat ini, kemampuan PostgreSQL dalam mengelola data JSON sudah sangat mumpuni, bahkan dalam banyak kasus, performanya bersaing ketat dengan database dokumen murni.

Lalu, bagaimana dengan tren AI saat ini?

Kebutuhan utama aplikasi AI modern adalah Vector Search. Kita perlu menyimpan embedding (representasi numerik dari data) dan melakukan pencarian kemiripan (similarity search) untuk mengimplementasikan RAG (Retrieval-Augmented Generation). Di sinilah persaingan menjadi menarik.

PostgreSQL memiliki pgvector. Ekstensi ini mengubah PostgreSQL menjadi database vektor yang sangat kompeten tanpa harus meninggalkan ekosistem relasional. Bagi banyak tim, memiliki data operasional dan data vektor dalam satu database adalah sebuah kemewahan. Kita bisa melakukan join antara metadata pengguna (SQL) dan pencarian dokumen yang relevan (Vector) dalam satu query tunggal. Simpel dan efisien.

Di sisi lain, MongoDB tidak tinggal diam. Mereka memperkenalkan Automated Embedding dalam MongoDB Vector Search. Fitur ini sangat membantu bagi developer yang ingin membangun pipeline AI tanpa harus mengelola MLOps yang kompleks. MongoDB mencoba menghilangkan friksi antara penyimpanan data dan pembuatan embedding. Bagi proyek yang membutuhkan skala masif dengan distribusi data global, kemampuan sharding native MongoDB masih menjadi keunggulan yang sulit dikalahkan oleh PostgreSQL.

Jika saya harus melihat dari perspektif praktis di tahun 2026, saya cenderung melihat PostgreSQL sebagai "pilihan aman" atau default choice untuk sebagian besar proyek baru. Mengapa? Karena fleksibilitasnya. Dengan PostgreSQL, kamu mendapatkan konsistensi ACID, dukungan JSON yang kuat, dan kemampuan vektor melalui pgvector. Kamu tidak perlu mengelola tiga database berbeda hanya untuk satu aplikasi.

Namun, MongoDB tetap menjadi juara ketika kita berbicara tentang data yang benar-benar tidak terstruktur dalam skala raksasa, atau ketika tim pengembangan membutuhkan kecepatan iterasi yang sangat tinggi pada fase awal prototipe di mana skema data benar-benar masih berupa "tebakan".

Pada akhirnya, pemilihan database bukan lagi soal "mana yang lebih baik", tapi "mana yang lebih cocok dengan beban kerja kita". Jika aplikasi kamu sangat bergantung pada relasi data yang kompleks namun tetap butuh fitur AI, PostgreSQL adalah jawabannya. Jika kamu membangun sistem yang harus menangani jutaan dokumen per detik dengan skema yang sangat dinamis, MongoDB tetap menjadi alat yang sangat kuat.

Menarik untuk melihat bagaimana kedua raksasa ini terus saling "meniru" fitur satu sama lain. PostgreSQL menjadi lebih fleksibel, dan MongoDB menjadi lebih terstruktur. Sebagai developer, kita adalah pemenangnya karena memiliki alat yang semakin lengkap.

Menurut kalian, apakah di masa depan kita masih akan membedakan antara SQL dan NoSQL, atau semuanya akan melebur menjadi satu jenis database multi-model yang bisa melakukan segalanya?

Blueprint Full-Stack 2026: Kembali ke Dasar yang Powerfull

Agung Gumelar — Sun, 27 Sep 2026 23:01:43 +0000

Blueprint Full-Stack 2026: Kembali ke Dasar yang Powerfull

Beberapa tahun terakhir, kita melihat siklus hype yang luar biasa cepat di dunia pengembangan perangkat lunak. Dari munculnya berbagai framework frontend yang menjanjikan efisiensi maksimal, hingga tren microservices yang kadang diterapkan terlalu dini pada proyek yang sebenarnya tidak membutuhkannya. Namun, memasuki tahun 2026, ada pergeseran menarik: kita mulai kembali ke "dasar" yang terbukti tangguh, namun dengan peningkatan kapabilitas yang jauh lebih modern.

Jika saya harus merangkum apa yang menjadi standar industri saat ini, jawabannya bukan lagi tentang mencari tools terbaru, melainkan tentang bagaimana mengombinasikan tools yang sudah matang untuk hasil yang scalable.

Dominasi PostgreSQL dan Akhir dari "Database War"

Dulu kita sering berdebat antara SQL vs NoSQL. Sekarang, perdebatan itu terasa usang. PostgreSQL telah memenangkan pertarungan ini bukan karena ia sempurna di segala hal, tapi karena ia bisa melakukan hampir semuanya dengan sangat baik.

Banyak tim mulai meninggalkan strategi "polyglot persistence" (menggunakan terlalu banyak jenis database) karena beban operasionalnya yang berat. Dengan adanya pgvector, kebutuhan untuk memiliki vector database terpisah untuk fitur AI menjadi opsional. Kita bisa menyimpan data relasional, dokumen JSONB, dan embedding AI dalam satu sistem yang sama. Ini adalah simplifikasi arsitektur yang sangat krusial untuk menjaga kecepatan development.

Backend: Antara Go dan Node.js

Di sisi backend, pilihan biasanya mengerucut pada dua kubu. Node.js tetap menjadi pilihan utama untuk produktivitas cepat, terutama dengan ekosistem TypeScript yang sudah sangat matang. Namun, Go (Golang) semakin mendominasi di level infrastruktur dan layanan yang membutuhkan konkurensi tinggi.

Tren yang saya lihat adalah penggunaan pendekatan hibrida. Service-service yang berhubungan dengan API gateway atau business logic yang kompleks menggunakan Node.js, sementara worker-worker berat, pemrosesan data, atau sistem messaging menggunakan Go. Fokusnya sudah bergeser dari "bahasa apa yang keren" menjadi "bahasa apa yang paling efisien untuk workload ini".

Frontend: Kembali ke Utility-First

Di frontend, React tetap menjadi jangkar. Namun, cara kita menulis styling telah berubah secara fundamental. Era CSS-in-JS yang kompleks mulai memudar, digantikan oleh dominasi Tailwind CSS.

Kenapa? Karena Tailwind memberikan konsistensi tanpa harus meninggalkan CSS. Kombinasi Next.js dan Tailwind saat ini menciptakan workflow yang sangat efisien. Kita tidak lagi menghabiskan waktu berjam-jam hanya untuk menentukan nama class CSS yang unik, melainkan fokus pada komponen yang reusable dan performa rendering yang optimal.

AI sebagai Fitur, Bukan Produk Utama

Tahun 2026 bukan lagi tentang "membuat AI", tapi tentang "mengintegrasikan AI". Pola RAG (Retrieval-Augmented Generation) menjadi standar baru. Alih-alih mencoba melatih model sendiri, developer lebih fokus membangun pipeline data yang bersih agar LLM bisa memberikan jawaban yang akurat berdasarkan data internal perusahaan.

AI kini diperlakukan sebagai fitur tambahan—seperti sistem caching atau search engine—yang memperkaya pengalaman pengguna, bukan sebagai inti dari seluruh arsitektur aplikasi.

Realitas Job Market: Outcome > Tooling

Satu hal yang paling terasa di pasar kerja IT saat ini adalah perubahan ekspektasi perekrut. Mengetahui React atau Go saja tidak lagi cukup. Perusahaan kini mencari engineer yang paham "Engineering Outcomes".

Apa artinya? Mereka lebih menghargai kandidat yang bisa menjelaskan bagaimana mereka mengurangi latency API sebesar 200ms, bagaimana mereka mendesain sistem yang bisa menangani spike traffic saat promo, atau bagaimana mereka mengelola SLO (Service Level Objective) untuk menjaga stabilitas sistem. Kemampuan System Design menjadi jauh lebih mahal harganya daripada sekadar mahir sintaks bahasa pemrograman.

Kesimpulan

Blueprint full-stack di tahun 2026 adalah tentang pragmatisme. Gunakan PostgreSQL untuk data, pilih antara Go atau Node.js berdasarkan kebutuhan performa, gunakan React dan Tailwind untuk interface yang cepat, dan integrasikan AI melalui pola RAG yang terukur.

Kunci utama untuk bertahan dan berkembang di industri ini bukan dengan mengejar setiap framework baru yang muncul di Twitter atau GitHub, melainkan dengan memperdalam pemahaman tentang fundamental sistem yang scalable.

Menurut Anda, apakah kita sudah terlalu bergantung pada satu atau dua ekosistem besar, atau justru simplifikasi ini adalah hal terbaik yang terjadi pada industri software dalam satu dekade terakhir?

Beyond the Stack: Mengapa System Design Lebih Penting daripada Menghafal Framework di 2026

Agung Gumelar — Sat, 26 Sep 2026 12:00:45 +0000

Beyond the Stack: Mengapa System Design Lebih Penting daripada Menghafal Framework di 2026

Beberapa tahun lalu, narasi di dunia pengembangan perangkat lunak sangat sederhana: kuasai satu stack, buat beberapa proyek portofolio, dan kamu siap kerja. Era MERN (MongoDB, Express, React, Node) membuat banyak dari kita merasa bahwa cukup dengan menguasai alur data dari database ke frontend, pintu karier akan terbuka lebar. Namun, masuk ke tahun 2026, lanskapnya berubah total.

Sekarang, mengetahui cara membuat komponen di React 19 atau menulis handler di Golang bukan lagi sebuah nilai jual unik. Mengapa? Karena AI sudah bisa melakukan itu dengan sangat efisien. Saat kita meminta AI membangunkan sebuah fitur, ia tidak hanya memberikan kode yang jalan, tapi seringkali mengikuti best practice terbaru. Di titik inilah, peran developer bergeser. Kita bukan lagi sekadar "penulis kode", melainkan "arsitek sistem".

Saya mulai merasakan pergeseran ini ketika melihat bagaimana diskusi di komunitas teknis berubah. Dulu, perdebatan panas biasanya berkisar pada "Framework mana yang lebih cepat?" atau "Library state management mana yang terbaik?". Sekarang, diskusinya lebih ke arah "Bagaimana kita menangani database replication agar aplikasi tetap responsif di berbagai region?" atau "Kapan kita harus pindah dari PostgreSQL ke sistem terdistribusi saat trafik melonjak sepuluh kali lipat?".

Menghafal sintaks framework adalah investasi dengan return yang semakin menurun. Framework datang dan pergi. SvelteKit mungkin naik daun, Next.js mungkin berevolusi menjadi sesuatu yang berbeda, tapi prinsip dasar System Design—seperti load balancing, caching strategies, dan database indexing—tetap relevan selama puluhan tahun.

Ambil contoh penggunaan PostgreSQL. Banyak yang menganggapnya sekadar tempat menyimpan data. Namun, jika kita melihat dari perspektif system design, keputusan untuk menggunakan JSONB di Postgres dibandingkan pindah ke MongoDB adalah keputusan arsitektural yang berdampak pada performa jangka panjang dan kompleksitas operasional. Developer yang hanya tahu "cara pakai" akan merasa MongoDB lebih mudah, tapi developer yang paham "system design" akan mempertimbangkan konsistensi data dan integritas relasional.

Begitu juga dengan Golang. Kelebihan utama Go bukan sekadar sintaksnya yang simpel, tapi bagaimana ia menangani concurrency melalui goroutines. Jika kita hanya menggunakan Go untuk membuat API CRUD sederhana, kita sebenarnya menyia-nyiakan potensi bahasanya. Kekuatan sesungguhnya muncul saat kita mendesain sistem yang harus menangani ribuan request secara bersamaan tanpa menghabiskan memori server.

Di pasar kerja saat ini, standar "entry-level" telah naik. Memiliki aplikasi to-do list di portofolio sudah tidak cukup. Perusahaan mencari orang yang bisa menjelaskan mengapa mereka memilih arsitektur tertentu. Mereka ingin tahu apakah kamu mengerti risiko dari single point of failure atau bagaimana cara kerja event-driven architecture menggunakan Kafka atau RabbitMQ untuk memisahkan proses yang berat.

Jadi, bagi teman-teman yang sedang belajar atau ingin naik level, saran saya sederhana: jangan terjebak dalam "tutorial hell" yang hanya mengajarkan cara memakai tool. Mulailah bertanya "bagaimana ini bekerja di belakang layar?". Pelajari bagaimana data mengalir, bagaimana server berkomunikasi, dan apa yang terjadi jika salah satu komponen sistem mati.

Keahlian dalam System Design adalah asuransi karier terbaik di era AI. Karena pada akhirnya, AI bisa menulis kode, tapi kemampuan untuk melihat gambaran besar, mengelola trade-off, dan mendesain sistem yang scalable adalah hal yang tetap membutuhkan intuisi dan pengalaman manusia.

Menurut kalian, apakah benar kemampuan coding murni mulai tergeser oleh kemampuan desain sistem, atau justru keduanya harus berjalan seimbang tanpa ada yang lebih dominan?

Agentic Coding: Saat Menulis Kode Bukan Lagi Bagian Terberat dari Software Engineering

Agung Gumelar — Wed, 23 Sep 2026 00:24:12 +0000

Agentic Coding: Saat Menulis Kode Bukan Lagi Bagian Terberat dari Software Engineering

Beberapa tahun lalu, kita melihat AI sebagai asisten yang membantu melengkapi baris kode melalui autocomplete. Kita merasa terbantu karena tidak perlu lagi menghafal seluruh dokumentasi API. Namun, memasuki tahun 2026, lanskapnya sudah berubah total. Kita tidak lagi sekadar menggunakan "asisten", melainkan mengorkestrasi "agen".

Fenomena Agentic Coding telah menggeser paradigma dasar pengembangan perangkat lunak. Menulis kode—yang dulu menjadi aktivitas utama seorang engineer—kini menjadi komoditas murah. Tantangan terbesarnya bukan lagi tentang bagaimana cara mengimplementasikan fitur, melainkan bagaimana memverifikasi bahwa apa yang dihasilkan oleh agen tersebut benar, aman, dan tidak merusak sistem secara keseluruhan.

Jebakan Kecepatan (The Speed Trap)

Ada satu ironi besar yang terjadi saat ini: produktivitas dalam hal jumlah baris kode (LOC) meningkat drastis, namun kecepatan pengiriman fitur ke produksi sering kali stagnan, atau bahkan melambat. Inilah yang bisa kita sebut sebagai "Jebakan Kecepatan".

Agen AI mampu menghasilkan Pull Request (PR) yang sangat besar dalam hitungan detik. Namun, kapasitas manusia untuk melakukan review tidak tumbuh secepat itu. Hasilnya, terjadi penumpukan di fase QA dan code review. Banyak tim yang akhirnya mengambil jalan pintas dengan melewatkan review mendalam demi mengejar deadline, yang pada gilirannya memicu lonjakan insiden di lingkungan produksi.

Kita terjebak dalam siklus di mana kode dihasilkan dengan sangat cepat, tetapi biaya verifikasinya menjadi jauh lebih mahal. Semakin besar PR yang dihasilkan AI, semakin sulit bagi manusia untuk memahami konteks dan potensi efek sampingnya.

Krisis "AI Slop" dan Utang Teknis

Masalah lain yang mulai mengemuka adalah munculnya AI slop—kode yang terlihat benar secara sintaksis dan berjalan saat dites secara sederhana, namun memiliki abstraksi yang buruk, redundan, dan sulit dipelihara.

Karena kemudahan dalam menghasilkan kode, banyak pengembang mulai mengabaikan prinsip desain perangkat lunak. Ada kecenderungan untuk membiarkan AI membuat solusi yang "asal jalan" tanpa memikirkan struktur jangka panjang. Jika hal ini dibiarkan, kita sedang membangun gunung utang teknis baru yang jauh lebih kompleks daripada utang teknis tradisional. Bedanya, kali ini utangnya ditulis oleh mesin dalam skala yang masif.

Paradoks Pengembang Junior

Hal yang paling mengkhawatirkan adalah dampak Agentic Coding terhadap pengembang junior. Dahulu, proses "berjuang" mencari bug selama berjam-jam atau mencoba memahami cara kerja sebuah library adalah bagian inti dari proses belajar. Di situlah intuisi teknis terbentuk.

Sekarang, ketika agen bisa memberikan jawaban instan, ada risiko hilangnya fase "perjuangan" tersebut. Pengembang junior mungkin bisa memberikan hasil kerja setara mid-level dalam hal output, tetapi mereka kekurangan fondasi mental untuk memahami mengapa solusi tersebut bekerja. Tanpa pemahaman mendalam, mereka akan kesulitan ketika harus mengambil keputusan arsitektural yang kompleks atau melakukan debugging pada masalah yang tidak bisa diselesaikan oleh AI.

Menuju Peran Baru: Sang Verifikator dan Arsitek

Jika menulis kode sudah menjadi tugas mesin, lalu apa peran kita sebagai software engineer?

Peran kita sedang bertransformasi menjadi semacam "kurator" atau "verifikator". Keahlian yang paling berharga di tahun 2026 bukan lagi kemahiran dalam sintaksis bahasa pemrograman tertentu, melainkan kemampuan dalam System Design, pemahaman mendalam tentang keamanan, dan ketajaman dalam melakukan review.

Kita harus berhenti mengukur kesuksesan dari seberapa banyak fitur yang selesai dikoding, dan mulai mengukurnya dari seberapa stabil sistem yang kita bangun. Fokus utama kita bergeser dari how to build menjadi what to build dan how to verify.

Pada akhirnya, AI tidak menggantikan engineer, tetapi AI memperjelas apa yang sebenarnya membuat seorang engineer menjadi ahli: bukan kemampuan mengetik kode dengan cepat, melainkan kemampuan memberikan penilaian (judgment) yang tepat atas solusi teknis yang diambil.

Apakah kita sudah cukup siap untuk berhenti menjadi "penulis kode" dan mulai menjadi "arsitek sistem" yang benar-benar bertanggung jawab atas setiap baris yang berjalan di produksi?

The 2026 Pragmatic Stack: Mengapa PostgreSQL dan Go Menang Melawan Stack Sprawl

Agung Gumelar — Sat, 19 Sep 2026 00:25:53 +0000

The 2026 Pragmatic Stack: Mengapa PostgreSQL dan Go Menang Melawan Stack Sprawl

Beberapa tahun terakhir, kita terjebak dalam tren "tool-of-the-week". Ada tekanan untuk menggunakan database NoSQL karena "scalability", beralih ke microservices terlalu dini, atau mencoba framework frontend baru setiap kali ada tweet populer. Tapi kalau kita melihat kondisi riil di tahun 2026, arahnya justru berbalik. Kita sedang memasuki era Pragmatic Stack.

Intinya sederhana: tim engineering mulai lelah dengan kompleksitas yang tidak perlu. Fokus sekarang bukan lagi tentang "apa yang paling canggih", tapi "apa yang paling bisa diandalkan dan mudah dipelihara". Di sinilah kita melihat PostgreSQL dan Golang mengambil alih panggung utama.

PostgreSQL: Sang Pemenang "Database War"

Dulu kita sering mendengar debat panas antara SQL vs NoSQL. "Pakai MongoDB untuk fleksibilitas, pakai Postgres untuk relasional." Namun, batas itu sekarang sudah kabur. Dengan fitur JSONB yang semakin matang, PostgreSQL bisa menangani data tidak terstruktur hampir seefektif MongoDB, namun tetap menjaga integritas data yang ketat.

Banyak perusahaan yang dulu melakukan database sprawl—menggunakan Redis untuk cache, Mongo untuk dokumen, dan Postgres untuk transaksi—kini mulai melakukan konsolidasi. Mereka menyadari bahwa mengelola satu database yang sangat kuat jauh lebih murah daripada mengelola tiga database yang berbeda. Postgres bukan sekadar tempat menyimpan data; dengan ekosistem ekstensi seperti pgvector, Postgres kini menjadi jantung dari banyak aplikasi AI, memungkinkan pencarian vektor (vector search) tanpa harus menambah database baru seperti Pinecone atau Milvus.

Golang: Efisiensi Tanpa Drama

Di sisi backend, Golang (Go) telah membuktikan dirinya sebagai bahasa yang paling rasional untuk layanan skala besar. Saat Java terasa terlalu berat dengan boilerplate-nya, dan Node.js terkadang berjuang dengan single-threaded nature-nya untuk beban komputasi tinggi, Go hadir dengan keseimbangan yang tepat.

Go tidak mencoba menjadi bahasa yang paling ekspresif atau memiliki fitur paling kompleks. Justru kesederhanaan itulah kekuatannya. Concurrency melalui goroutines membuat penulisan layanan high-throughput menjadi jauh lebih mudah dibandingkan menggunakan thread tradisional. Bagi banyak tim di tahun 2026, Go adalah pilihan utama untuk membangun API gateway, microservices yang efisien, dan infrastruktur cloud-native.

Menghadapi Realita Job Market 2026

Kalau kita melihat tren lowongan kerja saat ini, ada pergeseran ekspektasi. Perusahaan tidak lagi mencari "React Developer" atau "Go Developer" secara terisolasi. Mereka mencari Product Engineer—orang yang bisa menguasai satu stack yang efisien dari ujung ke ujung.

Kombinasi TypeScript (React/Next.js) di frontend, Go di backend, dan PostgreSQL di data layer telah menjadi "golden path". Mengapa? Karena stack ini memiliki hiring pool yang besar, dokumentasi yang sangat lengkap, dan performa yang terukur. AI coding assistants juga bekerja jauh lebih baik pada bahasa-bahasa dengan pola yang konsisten seperti Go dan TypeScript dibandingkan bahasa yang terlalu dinamis atau terlalu kompleks.

System Design: Kembali ke Dasar

Pelajaran terbesar dari tahun 2026 adalah: jangan over-engineer. Banyak startup yang gagal bukan karena teknologinya kurang canggih, tapi karena mereka menghabiskan terlalu banyak waktu mengelola infrastruktur daripada membangun fitur.

Strategi yang sekarang dianggap bijak adalah:

Mulai dengan monolit yang terstruktur dengan baik.
Gunakan PostgreSQL untuk hampir semua kebutuhan data.
Gunakan Go jika butuh performa tinggi atau efisiensi resource.
Hanya pecah menjadi microservices jika ada alasan organisasi atau beban trafik yang benar-benar tidak bisa ditangani satu proses.

Penutup

Teknologi akan selalu berkembang, dan akan selalu ada alat baru yang menjanjikan efisiensi 10x lipat. Namun, pengalaman menunjukkan bahwa stabilitas dan kemudahan pemeliharaan adalah kunci jangka panjang dari sebuah produk software.

Apakah Anda merasa stack yang Anda gunakan saat ini terlalu kompleks? Atau justru Anda sedang dalam proses menyederhanakan infrastruktur Anda kembali ke dasar? Mari kita diskusikan di kolom komentar.