The Innovation Gap: Mengapa AI “Gagap” Menulis Svelte 5 Analisis Arsitektural Mendalam
Minggu lalu, saya melakukan eksperimen sederhana.
Saya meminta asisten AI untuk membuat sebuah komponen di Next.js.
Hasilnya bersih. Type-safe. Hampir siap masuk ke produksi.
Lalu saya beralih ke Svelte 5.
Tiba-tiba, AI yang sama menghasilkan kode yang bahkan tidak bisa dikompilasi.
Sintaks JavaScript-nya valid. Tapi Svelte menolak semuanya.
Error di mana-mana.
Awalnya, saya berpikir:
“Apakah framework ini aneh?”
Ternyata, tidak.
Masalahnya jauh lebih struktural.
Saya menyebut fenomena ini:
The Innovation Gap.
Ini terjadi ketika teknologi berkembang lebih cepat daripada model AI yang dilatih untuk menulisnya.
Dan Svelte 5 adalah contoh yang sempurna.
Mari kita bedah alasannya.
Bagi pemilik bisnis, persoalannya bukan memilih framework yang sedang ramai. Yang perlu diperhatikan adalah apakah tim dapat membangun, menguji, dan merawat fitur dengan konsisten. Kode yang cepat dihasilkan AI belum tentu mengurangi biaya jika setiap perubahan memerlukan banyak perbaikan.
1. The Great Semantic Reset
Reaktivitas berubah makna
Di Svelte 3/4, reaktivitas bersifat implisit.
let count = 0
Compiler secara otomatis memperlakukan ini sebagai state reaktif.
Pola ini sudah ada selama bertahun-tahun. Masuk akal jika contoh lama masih memengaruhi keluaran AI, tetapi jumlah kemunculannya dalam data pelatihan model tertentu tidak saya ketahui.
Lalu Svelte 5 mengubah aturannya.
Reaktivitas sekarang bersifat eksplisit:
Lebih tepatnya, ini berlaku pada runes mode. Svelte 5 tetap mendukung komponen dengan sintaks legacy. Panduan migrasi resmi menjelaskan keduanya; masalah muncul ketika pola dari dua mode dicampur tanpa memahami batasnya.
let count = $state(0)
Sekarang let hanyalah JavaScript normal lagi.
Tidak reaktif.
Jadi makna dari simbol yang sama telah berubah.
Bagi manusia, ini lebih jelas. Bagi AI, ini membingungkan.
Karena AI tidak memahami niat (intent). Ia memprediksi token berdasarkan probabilitas.
Ketika makna dari pola inti berubah, prediksi tersebut rusak.
Hasilnya seringkali berupa kode "hibrida" seperti ini:
export let count = 0
let doubled = $derived(count * 2)
Ini mencampuradukkan paradigma lama dan baru.
- JavaScript: valid
- Svelte: tidak valid
Inilah yang saya maksud dengan reset semantik.
2. Runes Bukanlah Sekadar Library
Mereka adalah bahasa primitif
Kesalahan AI yang sangat umum:
import { $state } from 'svelte'
Terlihat masuk akal. Tapi sepenuhnya salah.
Mengapa?
Karena Runes bukanlah fungsi runtime.
Mereka adalah compiler primitives.
Sintaks runes diproses compiler, tanpa perlu diimpor seperti fungsi library. Hasil kompilasinya tetap dapat memakai mekanisme reaktivitas saat aplikasi berjalan. Jadi ini bukan berarti seluruh pekerjaan reaktivitas hilang dari runtime.
Bandingkan:
- React Hooks → fungsi JavaScript biasa
- Runes → instruksi untuk compiler
Maka secara mental:
- React = library
- Svelte 5 = ekstensi bahasa
LLM sangat baik dalam mempelajari pola library.
Namun, mereka lebih kesulitan dengan transformasi di tingkat bahasa.
Ketidakcocokan itulah yang menyebabkan banyak halusinasi.
3. Terikat Komponen → Reaktivitas Universal
Arsitekturnya sendiri telah berubah
Sebelum Svelte 5:
state hidup di dalam komponen
Setelah Svelte 5:
state bisa hidup di mana saja (.svelte.js / .svelte.ts)
State tidak lagi terikat pada komponen.
Penyederhanaan di atas perlu konteks: sebelum runes pun, stores sudah dapat berbagi state antarkomponen. Yang berubah adalah cara menggunakan reaktivitas berbasis runes di file yang didukung compiler, bukan kebebasan menaruh sintaks runes dalam sembarang file JavaScript.
Ini adalah pergeseran arsitektural yang nyata.
Bukan sekadar fitur kecil.
Data pelatihan lama berasumsi:
“state selalu berada di dalam komponen”
Asumsi itu sekarang salah.
Jadi AI terus menyelesaikan masalah baru menggunakan model mental yang sudah usang.
Seperti developer yang melewatkan panduan migrasi.
4. Mengapa Next.js Terlihat Lebih Mudah bagi AI?
Dalam percobaan saya, pola Next.js lebih mudah dihasilkan dengan benar. Itu pengamatan pada tugas tersebut, bukan benchmark yang membuktikan semua model selalu lebih baik di Next.js.
Salah satu dugaan yang masuk akal adalah perbedaan contoh dan pola yang dikenali model. Namun, tanpa mengetahui komposisi data pelatihannya, saya tidak bisa menyatakan perbandingan jumlah contoh secara pasti. Versi model, konteks proyek, dan instruksi juga memengaruhi hasil.
5. “Tapi Svelte 5 Sudah Keluar Selama Setahun…”
Tanggal rilis saja tidak menjamin sebuah model sudah memahami perubahan framework. Sebaliknya, model juga dapat dibantu dokumentasi terbaru, contoh proyek yang benar, dan umpan balik compiler meskipun pengetahuan awalnya tertinggal.
Saat meminta perubahan, jelaskan apakah komponen memakai mode legacy atau runes. Berikan versi dependensi dan satu contoh komponen proyek. Lalu periksa hasil kompilasi serta perilaku fitur. Dokumentasi What are runes? menjadi titik awal yang lebih kuat daripada meminta AI menebak sintaks terbaru.
6. The Innovation Gap
Inilah ide intinya.
Setiap LLM dilatih pada cuplikan masa lalu.
Jadi selalu ada:
- teknologi hari ini
- pengetahuan AI dari hari kemarin
Perubahan kecil cenderung lebih mudah dicocokkan dengan pola yang sudah dikenal. Perubahan fundamental bisa memperbesar jarak itu, terutama jika agent tidak diberi dokumentasi dan contoh yang sesuai.
Svelte 5 memilih jalan kedua:
- reaktivitas eksplisit
- compiler primitives
- sintaks baru
- model mental baru
Hasilnya:
- Pilihan model reaktivitas yang berbeda
- Peluang menyusun state dengan lebih konsisten
- Kebutuhan memeriksa apakah bantuan AI mengikuti pola proyek
Ini bukan bug.
Ini hanyalah biaya dari bergerak lebih cepat daripada dataset.
Saya menyebutnya:
The Innovation Tax.
Kesimpulan: Sebuah Trade-off Engineering
Jika AI terasa “gagap” menulis Svelte 5, jangan langsung menyimpulkan framework-nya buruk. Periksa dulu apakah contoh, mode komponen, dan dokumentasi yang digunakan sudah selaras.
Itulah yang saya sebut Innovation Tax: waktu tambahan untuk menjembatani teknologi yang berubah dengan alat bantu yang belum selalu tepat. Besarnya berbeda pada setiap model, tugas, dan tim.
Pilihan framework tetap harus mengikuti kebutuhan produk, keahlian tim, dan rencana perawatan. Jangan memindahkan website yang sudah bekerja hanya karena satu percobaan AI lebih lancar di stack lain. Uji satu fitur yang representatif, lalu nilai hasilnya: dapatkah tim memahami, menguji, dan meneruskan pekerjaannya?
Pengalaman ini sejalan dengan catatan saya tentang vibe coding: bantuan AI bernilai ketika keputusan tekniknya tetap bisa dipertanggungjawabkan.
References
[1] Svelte Core Team, "Svelte 5 Migration Guide," Svelte Documentation. https://svelte.dev/docs/svelte/v5-migration-guide
[2] R. Harris, "Introducing Runes," Svelte Blog. https://svelte.dev/blog/runes
[3] Svelte Core Team, "The Omnisite," Svelte Blog. https://svelte.dev/blog/the-omnisite
