Di tengah gelombang transformasi digital tata kerja dan birokrasi, lanskap kerja para pengembang teknologi di lingkungan pemerintah daerah kini berada di persimpangan jalan yang menarik. Tantangan keterbatasan kompetensi teknis, tuntutan percepatan layanan publik, dan efisiensi anggaran mendorong instansi pemerintah untuk mengevaluasi ulang cara membangun sistem digital. Manakah yang lebih relevan dan cenderung aman untuk jangka panjang? Dalam artikel ini diulas ringkas komparasi gaya-gaya pengembangan yang cukup populer.
Hari ini, dinamika di balik cakupan pengelola teknis TI Pemda tidak lagi seragam. Ada Vanilla Coding yang mengandalkan ketelitian murni individu pengembang dari baris pertama hingga akhir. Ada AI-Assisted Coding di mana kecerdasan buatan hadir sebagai rekan diskusi untuk membedah bug dan mempercepat troubleshooting, hingga Prompt-Driven Development yang revolusioner dan memungkinkan pembuatan aplikasi instan bermodal instruksi bahasa alami melalui platform seperti Claude AI, Emergent dan yang semisal. Ketiga pendekatan ini menawarkan spektrum produktivitas yang kontras, sekaligus membuka perdebatan krusial mengenai sejauh mana kesiapan SDM IT pemda dalam mengadopsi inovasi tanpa mengorbankan keamanan data dan kemandirian sistem jangka panjang.
1. Gaya Pengembangan Aplikasi
Dalam kaitannya dengan eksistensi AI, gaya pengembangan aplikasi yang populer sekurang-kurangnya ada 3:
1.1 Vanilla Coding atau Manual Coding
Penulisan baris kode secara murni oleh manusia dari awal hingga akhir tanpa bantuan alat otomasi atau asisten berbasis kecerdasan buatan. Ini gaya yang sudah mulai ditinggalkan sejumlah pengembang, sebab kemudahan yang ditawarkan AI menjadikan sejumlah tahun pengalaman akademis serta sejumlah tahun pengalaman pengembangan seperti tidak/kurang bernilai. Apa yang disuguhkan AI sebagai 'pengembang', tak jarang lebih baik, lebih profesional daripada apa yang dapat diberikan manusia sebagai pengembang. Namun gaya coding ini mungkin akan selalu 'laku'/merupakan satu-satunya pilihan oleh praktisi Cyber Security, apalagi untuk urusan otomatisasi dan pemrograman client side rendering seperti JavaScript.
1.2 AI-Assisted Coding atau AI Pair Programming
Praktik penulisan kode di mana kecerdasan buatan dilibatkan sebagai rekan pendamping (seperti menggunakan GitHub Copilot atau ChatGPT, Gemini, Copilot, dsb pada browser pengembang) untuk membantu menulis sintaks, mendeteksi celah, dan melakukan troubleshooting atau debugging. Ini adalah gaya yang paling logis untuk implementasi yang minim risiko kontrol.
1.3 Prompt-Driven Development atau Prompt Engineering
Metode pengembangan aplikasi, pembuatan logika, atau penyusunan konten di mana seluruh proses diarahkan menggunakan instruksi bahasa alami (prompt) melalui LLM Platform seperti Claude AI, sering kali tanpa perlu menulis kode secara konvensional (no-code atau low-code berbasis teks). Ini adalah idaman bagi pelaku-pelaku transformasi digital yang mendambakan kompetensi pengembangan dan menghasilkan prototype yang instan.
Dari sisi awam, ini seperti oase di padang tandus di tengah-tengah perjalanan yang sangat panjang dan tak berujung, disebabkan tidak perlu melalui prosesi D3/S1 akademis di bidang kekomputeran, tidak perlu memiliki super tim inti (Project Manager, System Analyst, Full Stack Developer & Designer, QA, dsb), hanya perlu textfield untuk menaruh prompt, aplikasi 'profesional' jadi.
Dari sisi profesional, ini sangat berguna untuk prototyping. Begitu konsep sudah oke dari sisi klien, sudah lulus oleh system analyst, pengembangan tinggal dieksekusi Full Stack Developer. Sehingga prompt-driven development ini sesuatu yang tidak dapat ditolak oleh pihak manapun kecuali anggaran adalah kendalanya.
2. Keseimbangan antara Kondisi Unit dan Pemilihan Gaya
Tak jarang, kondisi suatu unit pemerintahan itu berbeda dengan unit pemerintahan lainnya, sehingga gaya pengembangan perlu dipetakan berdasarkan kondisi unit yang hendak melakukan transformasi. Berikut beberapa kondisi unit pemerintahan yang dapat ditemukan per 1 September 2026.
2.1 Tak Ada Pengelola Teknis
Unit diisi sejumlah jabatan administrasi dan pejabat struktural. Bagitu ada jabatan fungsional rumpun kekomputeran, SKP Individu di awal tahun tidak diisi untuk pembuatan/pengembangan aplikasi. Begitu tahun berjalan, diarahkan untuk melakukan pengadministrasian anggaran/kegiatan. Ini duduk persoalannya memang dari sisi regulasi. Di mana regulasi membentuk jabatan kepemimpinan yang pintar belanja namun kurang untuk fungsi supervisi teknis atas perkara-perkara teknis dalam cakupan keilmuan masing-masing unitnya. Jika berhasil hidupkan fungsi supervisi tidak ada reward, jika gagal tidak ada pengembangan/evaluasi. Penyelesaian untuk masalah ini yakni penetapan/pengadaan pengelola teknis. JA/JF yang ada, ditentukan sebagai pengelola teknis, banyak kekurangan di awal itu adalah sebuah kepastian, namun evaluasi dan perbaikan itu adalah pilihan. Dari sana gaya pemrograman yang harus dikuasai adalah tidak ada. Yang diperlukan adalah pengelola teknis memahami masing-masing Tusi Unornya pada SOTK dan menginterpretasikannya ke dalam suatu draft SOP dalam kondisi dari atas belum menentukan SOP yang inklusif untuk Unornya. Dari draft SOP itu jadilah BPMN. Kalau siklusnya dibalik, BPMN dulu baru SOP, maka kerjanya jadi banyak, sebab SOP tidak mengakomodasi sistem sebagai entitas pelaksana, melainkan entitas-entitas pemerintahan.
Adapun hal teknis TI yang berguna dalam kondisi ini yakni blogging. Dari belajar blogging itu dapat diuraikan komponen/standar pelayanannya. Sampai di sini seharusnya SDLC dari tahap perencanaan, analisis, rancangan, seharusnya sudah ada, dan DevOps engineering itu menjadi terbuka jalan kompetensinya karena sudah melalui proses 'pengantar' (SOP, BPMN, Standar Pelayanan, blogging/kapabilitas informasional SPBE v1).
2.2 Ada Pengelola Teknis, Internal Pemerintah
Bisa jadi ada JA/JF yang sudah dilayangkan Surat Tugas Pengelola Teknis perihal Penata Kelolaan Penyelenggaraan Aplikasi Daerah tertentu. SKP awal tahun sudah ada butirnya yang menunjang. Ini kondisi di mana permasalahan terbesarnya sudah dilalui (legal standing) aktor digitalisasi. Hanya tinggal meluncur. Untuk kondisi ini, ada dua pendekatan gaya pembuatan/pengembangan.
Anggaran. Jika anggaran bukan kendalanya, maka prototyping awal lebih mudah jika menggunakan prompt-driven development. Ini sangat memangkas waktu untuk analisis kebutuhan yang dilakukan oleh system analyst bersama dengan klien. System analyst dalam hal ini dapat semisal pengelola teknis, klien dalam hal ini juga dapat merupakan pengelola teknis atau siapa pihak yang paling menggunakan sistem. Jika bahasa pemrograman untuk framework yang digunakan dalam prompt-driven development cocok dengan pengelola teknis, maka tinggal melanjutkan pengembangan, jika tidak membangun dari awal, bukan kesalahan sepanjang memang tidak pernah ada aplikasi sejenis sebelumnya.
Tidak ada alokasi anggaran. Ai-assisted coding adalah hal yang paling logis untuk kondisi ini, sepanjang tahapan-tahapan awal SDLC hingga perancangan sistem sudah ada kecukupan untuk memulai prototyping. Jika kompetensi masalahnya maka dapat memulai dengan pendekatan pembelajaran "Tak Ada Pengelola Teknis" (SOP, BPMN, Standar Pelayanan, Blog untuk capaian kapabilitas informasional SPBE v1).
2.3 Ada Pengelola Teknis, Konsultan IT/Outsource
Lumrahnya konsultan IT/Outsource lebih menguasai kinerja yang hybrid. Jika perlu manual, maka ia jalankan vanila, jika perlu asisten AI maka ia jalankan AI-assisted, jika perlu LLM ia menjalankan prompt-driven development. Lumrahnya Konsultan IT/Outsource menyesuaikan anggaran, selebihnya apapun yang diperlukan klien ia sudah ada. Ini menjadi mungkin karena Konsultan IT/Outsource tidak terlibat dalam peliknya administratif birokrasi sebagai seorang pegawai pemerintahan, hanya perlu fokus pada eksekusi teknis dalam menjalani kehidupan DevOps Engineering.
3. Risiko
3.1 Vanilla Coding
- waktu penggarapan. Waktu penggarapan untuk coding manual tidak seringkas coding dengan bantuan AI, apalagi tanpa framework. Kecuali membuat framework sendiri dan memiliki dokumentasi penggunaan serta memiliki penguasaan yang cukup dalam untuk semua perilaku dan semua instrumen penyusun framework-nya;
- nyaris tidak dapat diwariskan. Jika developer tidak melanjutkan programnya, maka kemungkinan besar tidak ada yang dapat/mampu melanjutkan. Seperti mewariskan motor prototype rakitan yang benar-benar dari nol dan tidak punya standar pembuatan, begitu diwariskan, maka bengkel mana yang mampu merawat? Kecuali ahli waris merupakan engineer yang memiliki semua ilmu yang diperlukan untuk melakukan perawatan.
3.2 AI-Assisted Coding
- jika pengembang benar-benar awam dalam bahasa pemrograman native suatu framework, maka kemungkinan tidak ada bedanya dengan prompt-driven development. Aplikasinya berwujud, namun tidak ada yang benar-benar dimengerti jika ada suatu hal kecil yang perlu dibenahi dalam konteks MVC-R. Mitigasi untuk hal ini adalah pengembang membuat suatu jadwal belajar untuk native programming atas framework yang akan dipelajari. Saat pengembang telah cukup familiar dengan bahasa pemrograman native-nya, maka masuk ke framework adalah suatu keringanan beban pengembangan, bukan masuk ke dalam beban;
- dominasi cacat logika hanya dalam kondisi terlalu menggantungkan (copy-paste) semuanya dari AI. Ada bedanya AI-Assisted dengan Artificial Super Intelligent (ASI) dan Artificial General Intelligence (AGI). Jika AI-Assisted, maka hasil akhir bergantung pada konteks dan source yang anda berikan. Hasil memang objektif, namun kualitas benar-benar bergantung dari sisi konteks dan source yang Anda berikan kepada AI. Jika anda bukan seorang dengan kompetensi dasar system analyst, maka anda tidak mampu memberikan konteks dan informasi cukup, dan output-nya kemungkinan akan berjalan namun terlalu berantakan, semua model ditaruh di controller, semua routing logic tidak ditempatkan di-controller, tabel database tidak ada yang berelasi sehingga menyebabkan masalah integritas data yang tidak rigit, dan lainnya.
secara garis besar, AI-Assisted memang merupakan opsi terbaik dan paling logis untuk diimplementasi secara umum jika memang ada cukup kompetensi pada fundamental SDM. Seharusnya risiko-risiko fundamental ini tidak lagi ditemukan jika SDM merupakan D3/S1 kekomputeran atau orang yang telah berpengalaman selama 2 tahun lebih pengembangan sistem.
3.3 Prompt-Driven Development
Di balik efisiennya pengembangan, risiko terbesar sebenarnya ada di sini, sekali lagi ini hanya dapat terjadi dalam kondisi SDM tidak familiar/tidak memiliki penguasaan pada fundamental bahasa pemrograman yang digunakan menggunakan AI.
- semua pengembangan/perbaikan yang diperlukan berhenti total ketika kuota kredit telah habis, sebab tidak memiliki penguasaan atas bahasa pemrograman/framework walaupun sebenarnya yang perlu diperbaiki hanya satu atau dua baris kode program saja di antara ribuan baris kode program;
- saat yang diperlukan adalah perbaikan kode sumber, yang terjadi malah perpanjangan learning curve atau malah baru mau masuk titik awal pembelajaran fundamental bahasa pemrograman.
4. Content Management System (CMS)
Sedari tadi hanya dibahas coding dan framework untuk digitalisasi. Di mana posisi CMS? CMS memang ideal sebagai pengantar atau 'pemanasan' untuk masuk ke dalam Full Stack Development, bahkan untuk operasi, CMS seperti wordpress dan blogspot itu jauh lebih baik/efektif untuk suatu domain Instansi atau sistem yang masuk ke dalam cakupan kapabilitas informasional untuk suatu Unit yang tidak memiliki talenta DevOps. Namun dalam pemerintahan, kesinambungan itu menuntut fleksibilitas arsitektur data, sebab cepat atau lambat semuanya akan bermuara kepada domain layanan, tidak bisa hanya berhenti hanya pada domain instansi saja. Jika kebutuhannya sudah arsitektur data, maka pilihannya hanya SQL atau No SQL, dan tidak ada pilihan di antara keduanya kecuali hybrid. Dan untuk implementasi antar muka serta perilaku aplikasi yang berangkat dari SQL/No SQL itu, diperlukan app. Jika kebutuhannya sudah app dengan arsitektur database, Maka pilihannya hanya 3: web yang populer, mobile yang kuat, atau desktop yang sudah banyak ditinggalkan.
Sebenarnya ada opsi keempat, namun tidak disematkan ke dalam pilihan sebab belum dapat digeneralisir karena belum ada jaminan untuk ketersediaan dan kesinambungannya, yakni satu super app tingkat nasional dengan Tier IV yang mengakomodasi seluruh layanan publik dan seluruh layanan administrasi IPPD dari pusat hingga pada tingkat Unor di daerah dari sabang sampai merauke dengan optimalisasi skema micro-services, containerization dan API.
Sehingga atas kondisi tersebut, maka terjawablah mengapa CMS itu hanya stop pada domain Instansi atau sistem yang sifatnya hanya informasional? Karena kebutuhan jangka panjangnya adalah fleksibilitas pengembangan arsitektur database dan arsitektur proses bisnis.
Penutup
Sepanjang infrastruktur langit terbentang (dan dapat digunakan) dan belum ada suatu aplikasi yang mengakomodasi kebutuhan digitalisasi seluruh Unor di Indonesia dengan Tier IV, transformasi digital di lingkungan pemerintah daerah tidak akan pernah benar-benar berhenti pada sebatas adopsi teknologi tercanggih, melainkan tentang bagaimana kesiapan manusia di baliknya menyikapi perubahan. Pilihan antara vanilla coding, AI-assisted coding, atau prompt-driven development pada akhirnya bukan sekadar memilih alat bantu kerja, melainkan strategi bertahan hidup birokrasi dalam meramu keterbatasan anggaran, regulasi, dan kapasitas SDM. Kehadiran kecerdasan buatan dan platform berbasis LLM terbukti mampu membawa pandangan baru atas paradigma selama ini bahwa pengembangan hanya dapat dilakukan oleh profesional. Namun di sisi lain, tanpa fondasi tata kelola yang matang—mulai dari inklusivitas peta proses bisnis, profesionalisme fungsi supervisi, hingga pengamanan kedaulatan data—inovasi digital hanya akan berujung pada tumpukan aplikasi instan yang rapuh. Keberhasilan transformasi SPBE di daerah tidak diukur dari seberapa cepat sebuah baris kode atau prompt dieksekusi, tetapi dari mutu komunikasi, kerja sama dan sinergi antar pihak terkait, konsistensi pengelolaan teknis dalam merawat kemandirian sistem dan menjawab esensi layanan.
12