DEV Community: Agung Gumelar

SvelteKit vs React di 2026: Berhenti Membandingkan, Mulai Memilih Berdasarkan Kebutuhan

Agung Gumelar — Sun, 11 Oct 2026 13:15:07 +0000

Sudah beberapa tahun ini kita terjebak dalam debat tanpa akhir tentang mana yang lebih baik antara React dan Svelte. Kalau kita melihat kondisi ekosistem di tahun 2026, sebenarnya perdebatan "siapa yang menang" sudah tidak lagi relevan. Yang jauh lebih penting sekarang adalah memahami trade-off teknis dari masing-masing pendekatan karena kebutuhan aplikasi modern sudah semakin spesifik.

Paradigma Berbeda: Compiler vs Runtime

Hal mendasar yang sering terlupakan adalah perbedaan filosofi antara keduanya. React adalah runtime library. Artinya, React membawa "mesin" virtual DOM ke browser pengguna, melakukan diffing di memori, dan kemudian mengupdate DOM asli. Ini memberikan fleksibilitas luar biasa, tapi ada harga yang harus dibayar: bundle size yang lebih besar dan overhead CPU di sisi klien.

Di sisi lain, SvelteKit menggunakan pendekatan compiler. Svelte melakukan sebagian besar pekerjaannya saat proses build. Ia mengubah kode deklaratif menjadi manipulasi DOM yang sangat efisien dan spesifik. Hasilnya? Bundle JavaScript yang jauh lebih kecil dan performa first load yang terasa instan.

Di tahun 2026, ketika pengguna semakin tidak sabar dengan loading screen—terutama di perangkat mobile dengan koneksi yang tidak stabil—perbedaan ini menjadi sangat terasa.

React Server Components (RSC): Upaya React Mengejar Efisiensi

React tidak tinggal diam. Munculnya React Server Components (RSC) melalui Next.js adalah jawaban React terhadap masalah bundle size. Dengan RSC, kita bisa memindahkan logika pengambilan data dan rendering komponen ke server, sehingga browser hanya menerima HTML minimal dan sedikit JavaScript untuk interaktivitas.

Ini adalah pergeseran besar. Sekarang, pilihan bukan lagi "di mana aplikasi saya berjalan", tapi "per komponen, di mana bagian ini harus dirender?".

Namun, implementasi RSC membawa kompleksitas baru. Kita harus sangat hati-hati memisahkan antara Server Components dan Client Components. Bagi banyak tim, kurva pembelajaran ini cukup curam dan seringkali menimbulkan bug yang sulit dilacak jika tidak memahami aliran datanya dengan benar.

SvelteKit: Kecepatan Pengembangan dan Sederhananya DX

SvelteKit menawarkan Developer Experience (DX) yang menurut saya jauh lebih intuitif. Kita tidak perlu berurusan dengan useMemo, useCallback, atau aturan ketat tentang dependensi useEffect yang sering membuat pusing pengembang React. State management di Svelte terasa sangat natural karena menggunakan variabel JavaScript biasa.

Bagi tim kecil atau startup yang mengejar velocity, SvelteKit adalah senjata yang mematikan. Kita bisa membangun fitur dengan lebih sedikit boilerplate dan mendapatkan performa yang sudah optimal secara default tanpa harus melakukan tuning manual yang melelahkan.

Jadi, Kapan Harus Menggunakan Yang Mana?

Jika saya harus memberikan rekomendasi berdasarkan pengalaman mengelola berbagai project, pertimbangannya adalah sebagai berikut:

Pilih SvelteKit jika:

Anda membangun aplikasi yang mengutamakan performa loading awal, seperti landing page, e-commerce, atau PWA yang target penggunanya sangat luas.
Anda bekerja dalam tim kecil yang ingin bergerak cepat tanpa terbebani boilerplate yang kompleks.
Bundle size adalah metrik utama keberhasilan aplikasi Anda.

Pilih React jika:

Anda membangun aplikasi enterprise skala besar dengan dashboard yang sangat kompleks dan interaktivitas yang intens di sisi klien.
Anda membutuhkan ekosistem library yang sangat luas (hampir semua library UI terbaru pasti mendukung React terlebih dahulu).
Kemudahan mencari tenaga kerja (hiring pool) menjadi pertimbangan utama perusahaan.

Penutup

Pada akhirnya, tidak ada tools yang sempurna untuk semua kasus. Memaksakan satu framework untuk semua jenis project hanya akan menambah beban teknis di masa depan. SvelteKit unggul dalam efisiensi dan kesederhanaan, sementara React unggul dalam ekosistem dan skalabilitas organisasi.

Pertanyaannya sekarang, apakah kita memilih framework karena kita menyukainya, atau karena framework tersebut memang mampu menyelesaikan masalah bisnis kita dengan cara yang paling efisien?

Melampaui Hype: Membangun Sistem AI yang Bisa Diandalkan di Tahun 2026

Agung Gumelar — Sat, 10 Oct 2026 23:27:11 +0000

Melampaui Hype: Membangun Sistem AI yang Bisa Diandalkan di Tahun 2026

Beberapa tahun terakhir, kita semua terpesona dengan kemampuan LLM yang bisa menulis puisi atau membuat kode dalam hitungan detik. Tapi kalau kita bicara di level produksi, "trik sulap" seperti itu tidak ada harganya. Bagi banyak perusahaan saat ini, pertanyaan besarnya bukan lagi "apa yang bisa dilakukan AI?", melainkan "bagaimana kita memastikan AI ini tidak berhalusinasi saat mengolah data finansial?" atau "bagaimana cara mengontrol biayanya agar tidak membengkak?".

Kita sedang berada di titik transisi yang menarik. Kita mulai bergeser dari sekadar mengandalkan kapabilitas model mentah menuju apa yang saya sebut sebagai AI System Design. Di sini, model AI tidak lagi dianggap sebagai produk akhir, melainkan hanya salah satu komponen dalam arsitektur yang lebih besar.

Era Agentic Workflows: Antara Otonomi dan Determinisme

Istilah "AI Agent" ada di mana-mana. Janjinya adalah sistem yang bisa berpikir, merencanakan, dan mengeksekusi tugas secara mandiri. Namun, realitanya di lapangan menunjukkan bahwa agen yang sepenuhnya otonom seringkali terlalu berisiko untuk lingkungan produksi. Mereka bisa terjebak dalam loop tak berujung atau mengambil keputusan yang tidak terduga.

Solusi yang paling efektif saat ini adalah pendekatan hibrida. Kita memadukan LLM untuk bagian yang membutuhkan penalaran fleksibel, namun membungkusnya dalam sistem deterministik. Artinya, kita memberikan batasan yang jelas: "Kamu boleh mencari informasi menggunakan tool A, tapi hasil akhirnya harus divalidasi oleh fungsi B."

Strategi ini mengubah peran developer backend. Kita tidak lagi hanya membuat API wrapper, tapi menjadi orkestrator. Kita mendesain alur kerja di mana AI hanya bergerak dalam koridor yang sudah ditentukan, sehingga reliabilitas sistem tetap terjaga tanpa mengorbankan kecerdasan modelnya.

GraphRAG dan Evolusi Pencarian Informasi

Kita juga melihat evolusi dari Vector Search sederhana menuju GraphRAG (Graph-based Retrieval Augmented Generation). Kalau dulu kita hanya mengandalkan kemiripan semantik (mencari paragraf yang kata-katanya mirip), sekarang kita mulai membangun peta hubungan yang nyata.

Bayangkan sistem yang tahu bahwa "Perusahaan A adalah supplier bagi Perusahaan B, yang kemudian mengirim barang ke Wilayah C". Dengan menggabungkan Knowledge Graphs dan Vector Search, AI tidak lagi menebak-nebak berdasarkan probabilitas kata, tapi benar-benar "mengerti" struktur data yang ada. Ini adalah kunci untuk mengurangi halusinasi secara signifikan, karena jawaban AI dipaksa untuk berdasar pada fakta relasional yang valid.

Pergeseran ke Local SLM dan "Private by Design"

Tren menarik lainnya adalah munculnya Small Language Models (SLMs) yang dijalankan secara lokal. Dulu, kita berpikir semakin besar model, semakin pintar. Tapi sekarang, efisiensi menjadi prioritas. Model yang lebih kecil, teroptimasi, dan memiliki open-weight (seperti varian Llama atau Mistral terbaru) ternyata sudah cukup untuk tugas-tugas spesifik.

Selain masalah biaya dan latensi, ada faktor privasi. Banyak industri yang tidak bisa mengirim data sensitif ke cloud. Pendekatan Private by Design memastikan bahwa data tidak pernah meninggalkan infrastruktur perusahaan. Dengan menjalankan SLM secara lokal, kita mendapatkan kontrol penuh atas keamanan data sekaligus performa yang lebih cepat karena tidak ada round-trip ke server eksternal.

Mendesain untuk Kegagalan

Satu hal yang paling penting dalam membangun sistem AI di tahun 2026 adalah berhenti berasumsi bahwa model akan selalu memberikan jawaban yang benar. Kita harus mendesain sistem dengan asumsi bahwa model akan gagal.

Ini berarti kita perlu membangun observability yang sangat detail pada setiap jalur keputusan AI. Kita harus bisa melacak mengapa sebuah agen mengambil langkah tertentu dan di mana tepatnya letak kesalahannya. Observabilitas bukan lagi sekadar log error, tapi analisis terhadap penalaran model (reasoning path).

Pada akhirnya, tantangan terbesar saat ini bukan lagi soal seberapa pintar model yang kita gunakan, tapi seberapa kokoh sistem yang kita bangun di sekitarnya. AI hanyalah mesin; kitalah yang harus membangun rem, setir, dan navigasinya agar mesin tersebut sampai ke tujuan dengan selamat.

Menurut kalian, apakah kita akan sampai pada titik di mana agen otonomi penuh benar-benar aman untuk produksi, ataukah pendekatan hibrida deterministik ini akan selalu menjadi standar utama?

Navigasi Karir Software Engineer 2026: Saat Framework Menjadi Standar dan AI Menjadi Rekan Kerja

Agung Gumelar — Fri, 09 Oct 2026 13:15:06 +0000

Navigasi Karir Software Engineer 2026: Saat Framework Menjadi Standar dan AI Menjadi Rekan Kerja

Kalau kita melihat tren lowongan kerja IT belakangan ini, ada satu pola yang cukup mencolok: kemampuan teknis yang dulu dianggap sebagai "nilai tambah" kini sudah bergeser menjadi "syarat minimum".

Beberapa tahun lalu, bisa menggunakan React atau PostgreSQL mungkin sudah cukup untuk membuat resume kita terlihat menarik. Tapi di tahun 2026, kondisinya berbeda. React bukan lagi sekadar pilihan framework, melainkan asumsi dasar. Begitu juga dengan PostgreSQL yang seolah-olah sudah memenangkan "perang database" untuk sebagian besar proyek baru.

Lalu, di mana letak pembedanya sekarang?

Pergeseran dari "Bisa Coding" ke "Bisa Shipping"

Salah satu perubahan paling terasa adalah bagaimana perusahaan melihat peran Junior Developer. Ada penurunan permintaan untuk peran yang hanya bisa menulis kode berdasarkan instruksi detail. Kenapa? Karena boilerplate code dan fungsi-fungsi sederhana sekarang sudah bisa dihasilkan oleh AI dalam hitungan detik.

Yang dicari sekarang adalah shipping ability. Kemampuan untuk mengambil sebuah ide, merancangnya, menulis kode (dengan bantuan AI), melakukan debugging, hingga memastikan fitur tersebut sampai ke tangan pengguna dengan stabil.

AI memang membantu kita menulis kode lebih cepat, tapi AI juga memperkenalkan jenis bug baru yang lebih halus dan sulit dideteksi. Di sinilah kemampuan debugging yang fundamental menjadi sangat mahal. Engineer yang bisa mengidentifikasi mengapa sebuah sistem distribusi mengalami race condition atau mengapa query database menjadi lambat saat data mencapai jutaan baris tetap akan jauh lebih dihargai daripada mereka yang hanya bisa melakukan copy-paste dari LLM.

Stack Backend: Dominasi Go dan Python

Di sisi backend, kita melihat pembagian peran yang semakin jelas. Python tetap merajai berkat ekosistem AI/ML yang tak tertandingi. Jika Anda ingin masuk ke dunia LLM, RAG, atau data engineering, Python adalah harga mati.

Namun, untuk urusan infrastruktur, cloud-native, dan sistem yang membutuhkan performa tinggi, Go (Golang) telah mengambil posisi yang sangat kuat. Go menjadi standar baru untuk membangun microservices dan tool developer karena efisiensinya dan kemampuannya menangani konkurensi dengan sangat baik.

Menariknya, kombinasi Go + Kubernetes + PostgreSQL kini menjadi "Golden Stack" bagi banyak startup dan perusahaan skala menengah. Jika Anda menguasai kombinasi ini, Anda tidak hanya sekadar bisa membuat API, tapi Anda paham bagaimana sistem tersebut berjalan di atas infrastruktur modern.

Menghadapi Era AI-Assisted Development

Pertanyaan yang sering muncul adalah: "Apakah AI akan menggantikan kita?"

Jawabannya mungkin bukan menggantikan, tapi mendefinisikan ulang. Kita sedang bergerak dari peran sebagai "penulis kode" menjadi "editor kode" dan "arsitek sistem".

Keahlian yang akan menjadi sangat krusial adalah System Design. Saat implementasi kode menjadi semakin murah karena AI, nilai dari sebuah keputusan arsitektur menjadi semakin tinggi. Memilih antara konsistensi atau ketersediaan (CAP Theorem), menentukan kapan harus menggunakan NoSQL dibandingkan Relational, atau merancang strategi caching yang tepat adalah hal-hal yang belum bisa diserahkan sepenuhnya kepada AI.

Selain itu, kemampuan komunikasi teknis menjadi jauh lebih penting. Anda harus bisa menjelaskan mengapa sebuah keputusan diambil kepada stakeholder non-teknis, sesuatu yang tidak bisa dilakukan oleh bot.

Kesimpulan

Tahun 2026 menuntut kita untuk menjadi lebih dari sekadar spesialis framework. Jangan terjebak hanya pada satu library atau bahasa pemrograman. Fokuslah pada pemahaman fundamental: bagaimana data mengalir, bagaimana sistem berkomunikasi, dan bagaimana membangun produk yang benar-benar menyelesaikan masalah.

AI adalah rekan kerja yang luar biasa, tapi ia tetap membutuhkan pilot yang tahu persis ke mana arah tujuannya.

Menurut Anda, skill apa yang paling sulit digantikan oleh AI dalam pekerjaan sehari-hari sebagai engineer? Mari diskusikan di kolom komentar.

Menavigasi Lanskap Teknologi Indonesia 2026: Antara Modular Monolith dan Gelombang AI

Agung Gumelar — Fri, 09 Oct 2026 02:37:37 +0000

Menavigasi Lanskap Teknologi Indonesia 2026: Antara Modular Monolith dan Gelombang AI

Beberapa tahun terakhir, kita melihat pergeseran yang cukup drastis dalam cara kita membangun perangkat lunak di Indonesia. Kalau dulu kita terobsesi dengan "skala" sampai-sampai banyak startup yang langsung melompat ke arsitektur microservices di hari pertama, tahun 2026 membawa kita pada sebuah realita yang berbeda: efisiensi adalah mata uang baru.

Saat ini, banyak tim engineering di Jakarta dan Bandung mulai merasakan apa yang bisa disebut sebagai "microservices hangover". Kompleksitas jaringan, biaya observabilitas yang membengkak, dan koordinasi antar-tim yang melelahkan membuat banyak dari kita mulai melirik kembali ke arah monolith—tapi bukan monolith yang berantakan, melainkan Modular Monolith.

Pendekatan modular monolith ini menarik karena memberikan kita batas-batas domain yang jelas (bounded contexts) seperti pada microservices, namun tetap berjalan dalam satu unit deployable. Kita mendapatkan kecepatan pengembangan dan kemudahan debugging, tanpa harus berurusan dengan latensi jaringan atau kegagalan RPC yang aneh. Bagi banyak perusahaan yang sedang mengoptimalkan biaya operasional, kembali ke modular monolith adalah keputusan strategis yang sangat masuk akal.

Namun, ketika sistem benar-benar harus didistribusikan, tantangan terbesarnya tetaplah konsistensi data. Di sinilah pemahaman tentang Saga Pattern menjadi krusial. Kita tidak bisa lagi mengandalkan transaksi dua fase (2PC) yang sinkron dan lambat. Pilihan antara Saga Choreography (desentralisasi melalui event) dan Saga Orchestration (central manager) bukan sekadar masalah teknis, tapi masalah trade-off antara fleksibilitas dan visibilitas. Untuk flow yang kompleks seperti sistem pembayaran atau pemesanan tiket, orchestration biasanya menjadi pemenang karena memudahkan kita melacak di mana sebuah transaksi tersangkut.

Di sisi lain, kita tidak bisa mengabaikan gelombang AI yang sudah bukan lagi sekadar "fitur tambahan". Integrasi AI di tahun 2026 telah bergeser dari sekadar memanggil API LLM menjadi pembangunan infrastruktur data yang lebih cerdas. Munculnya Vector Databases membawa konsep baru seperti HNSW (Hierarchical Navigable Small World) dan Vector Quantization ke dalam diskusi harian backend engineer.

Kini, tantangannya bukan lagi bagaimana menyimpan data, tapi bagaimana melakukan pencarian semantik yang efisien di atas jutaan vektor. Menggabungkan pencarian keyword tradisional (BM25) dengan semantic search melalui Reciprocal Rank Fusion (RRF) menjadi standar baru dalam membangun sistem informasi yang relevan. Bagi backend engineer yang terbiasa dengan PostgreSQL atau MongoDB, memahami bagaimana indeks vektor bekerja menjadi pembeda antara sekadar "pemakai API" dan seorang "system designer".

Melihat kondisi pasar kerja saat ini, permintaan terhadap peran Backend Engineer yang menguasai Go atau Node.js tetap tinggi, namun ekspektasinya telah berubah. Perusahaan tidak lagi mencari orang yang sekadar bisa menulis kode, tapi engineer yang bisa melakukan reasoning atas pilihan arsitekturnya. Apakah kita butuh Kafka untuk case ini? Apakah Redis cukup? Mengapa memilih PostgreSQL daripada MongoDB untuk modul ini?

Pada akhirnya, menjadi engineer yang relevan di tahun 2026 adalah tentang menjadi "T-shaped". Kita perlu memiliki pemahaman yang luas tentang berbagai pola sistem (System Design), namun memiliki kedalaman spesialisasi di satu atau dua area, entah itu dalam optimasi database, infrastruktur cloud, atau AI engineering.

Dunia teknologi bergerak cepat, tapi prinsip dasar engineering—simplicity, reliability, dan scalability—tetap tidak berubah. Pertanyaannya sekarang, apakah kita membangun sistem untuk memecahkan masalah bisnis, atau kita membangun sistem hanya karena pola tersebut sedang trending?

Menavigasi Tech Stack Modern di Tahun 2026: Antara Efisiensi dan Hype

Agung Gumelar — Thu, 08 Oct 2026 00:28:37 +0000

Menavigasi Tech Stack Modern di Tahun 2026: Antara Efisiensi dan Hype

Beberapa tahun terakhir, dunia pengembangan perangkat lunak terasa seperti perlombaan senjata. Setiap minggu ada framework baru, library state management baru, atau pendekatan arsitektur yang diklaim sebagai "penyelesai segala masalah". Namun, memasuki tahun 2026, ada pergeseran paradigma yang cukup terasa. Kita tidak lagi berada di fase "menambah alat baru", melainkan fase "konsolidasi".

Tren saat ini bukan lagi tentang siapa yang menggunakan tool paling banyak, tapi siapa yang bisa membangun sistem yang stabil dengan jumlah tool paling minimal.

Konsolidasi di Sisi Frontend: React 19 dan Melampauinya

React masih mendominasi, namun cara kita menggunakannya telah berubah. Hadirnya React Compiler di versi 19 adalah titik balik yang signifikan. Masalah klasik seperti useMemo dan useCallback yang seringkali membingungkan pengembang junior—dan terkadang bahkan senior—kini mulai teratasi secara otomatis. Kita bisa kembali fokus pada logika bisnis daripada pusing memikirkan kapan komponen harus render ulang.

Next.js 16 juga membawa angin segar dengan Turbopack yang sudah matang, membuat siklus pengembangan terasa jauh lebih instan. Tapi menariknya, saya melihat banyak tim mulai melirik SvelteKit atau Astro untuk proyek yang lebih spesifik. Astro, dengan arsitektur islands-nya, menjadi pilihan utama untuk situs yang mengutamakan SEO dan kecepatan load, sementara SvelteKit memberikan pengalaman developer (DX) yang jauh lebih ringkas bagi tim kecil yang ingin bergerak cepat tanpa beban boilerplate yang berat.

Backend: Go vs Node.js dalam Perang Efisiensi

Di sisi server, perdebatan antara Node.js dan Golang masih berlanjut, namun batasannya kini lebih jelas. Node.js dengan TypeScript tetap menjadi pilihan paling rasional untuk tim yang ingin satu bahasa di seluruh stack. Kecepatan iterasi yang ditawarkan sangat sulit dikalahkan, terutama dengan framework seperti Fastify yang kini jauh lebih efisien dibandingkan Express.

Namun, untuk layanan yang membutuhkan throughput tinggi atau sistem yang sangat terdistribusi, Go (Golang) telah menjadi standar industri. Kemampuannya dalam menangani konkurensi melalui goroutines membuat Go sangat superior untuk membangun API gateway atau microservices yang harus melayani jutaan request per detik dengan konsumsi memori yang minimal.

Bagi saya, pilihan terbaik saat ini adalah pendekatan hybrid: gunakan Node.js untuk lapisan API yang sering berubah dan membutuhkan integrasi cepat, lalu pindahkan logika berat atau service yang bottleneck ke Go.

PostgreSQL: Satu Database untuk Segalanya

Jika ada satu tool yang benar-benar menang dalam hal konsolidasi, itu adalah PostgreSQL. Dulu kita mungkin merasa perlu MongoDB untuk data dokumen, Redis untuk caching, dan database vektor terpisah untuk AI. Sekarang, PostgreSQL dengan ekstensi seperti pgvector telah mengubah permainan.

Kita bisa menyimpan data relasional, JSONB untuk fleksibilitas dokumen, dan vektor untuk pencarian semantik AI dalam satu tempat. Ini mengurangi kompleksitas infrastruktur secara drastis. Tidak ada lagi drama sinkronisasi data antar database yang berbeda atau biaya operasional yang membengkak hanya untuk menjaga lima jenis database tetap hidup.

AI dalam Workflow: Bukan Lagi Sekadar Copilot

Cara kita menulis kode juga telah berevolusi. AI bukan lagi sekadar alat untuk melengkapi baris kode (autocomplete), melainkan partner dalam berpikir. Tool seperti Cursor atau Claude Code memungkinkan kita melakukan refactoring skala besar atau migrasi codebase hanya dengan instruksi tingkat tinggi, asalkan kita paham arsitekturnya.

Namun, ada jebakan di sini. Banyak pengembang mulai terlalu bergantung pada AI sehingga melewatkan pemahaman fundamental. Di tahun 2026, nilai seorang engineer bukan lagi terletak pada kemampuan menulis sintaks—karena AI bisa melakukannya—melainkan pada kemampuan mendesain sistem (System Design), memastikan keamanan, dan melakukan debugging pada masalah-masalah edge case yang tidak dipahami oleh model bahasa besar.

Kondisi Market dan Mentalitas Baru

Kondisi pasar kerja IT saat ini menuntut apa yang saya sebut sebagai "T-Shaped Developer". Perusahaan tidak lagi mencari seseorang yang "hanya bisa React" atau "hanya bisa Go". Mereka mencari engineer yang punya spesialisasi mendalam di satu bidang, namun memiliki pemahaman luas tentang bagaimana seluruh sistem bekerja—mulai dari CSS di browser, optimasi query di database, hingga konfigurasi CI/CD di cloud.

Kesimpulannya, teknologi akan terus berkembang, tapi fundamental tetap sama. Fokuslah pada pemecahan masalah, bukan pada tool-nya. Pilihlah stack yang memungkinkan Anda mengirimkan nilai ke pengguna secepat mungkin dengan risiko kegagalan sekecil mungkin.

Menurut kalian, apakah konsolidasi stack ini akan membuat kita menjadi developer yang lebih produktif, atau justru membatasi inovasi karena kita terlalu nyaman dengan tool yang itu-itu saja?

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?"