Waktu Ketika Kode Harus Ditulis dengan Tangan

Tahun 2001 saya masuk Teknik Elektro UGM, beberapa semester kemudian mengambil konsentrasi Informatika. Dan salah satu kejutan awalnya adalah tugas laboratorium harus dikumpulkan dalam bentuk tulisan tangan. Algoritma, flowchart, bahkan kode program, semua ditulis di atas kertas. Kalau salah satu karakter saja keliru, ya dicoret. Kalau lupa titik koma, harus diselipkan tanda sisip kecil di antara baris. Kadang malah lebih rapi kalau ditulis ulang saja dari awal.

Waktu itu saya merasa ini agak aneh. Kita belajar komputer, tapi justru tidak boleh menggunakan komputer. Tidak ada compile, debugger, dan autocomplete. Yang ada hanya kertas dan pulpen. Saya ingat duduk lama sekali di meja, mencoba menelusuri logika program sebelum menuliskannya. Karena kalau sudah ditulis dan ternyata salah, rasanya malas sekali memperbaikinya. Waktu itu saya menganggapnya sebagai metode yang agak kuno. Dalam hati saya sering berpikir kenapa kok tidak langsung saja pakai komputer?

Belakangan ini saya sering teringat pengalaman itu. Mungkin karena sekarang dunia pendidikan sedang ramai membahas AI. Banyak guru mulai khawatir tugas siswa dikerjakan oleh mesin. Ada yang mencoba memakai AI detector, ada juga yang mulai melarang penggunaan AI sama sekali. Saya tidak terlalu yakin pendekatan itu akan berhasil. AI sudah terlalu mudah diakses. Melarangnya rasanya seperti mencoba melarang kalkulator di kelas matematika. Tapi di tengah semua diskusi itu, ingatan tentang tugas tulisan tangan tadi tiba-tiba terasa relevan lagi.

Dulu, ketika menulis kode di atas kertas, tidak ada tempat untuk “coba-coba”. Setiap baris harus dipikirkan dulu sebelum ditulis. Kadang saya berhenti cukup lama hanya untuk memastikan alur logikanya benar. Dan mungkin di situlah sebenarnya latihan itu terjadi. Bukan pada kertasnya, tapi pada proses berpikirnya.

Beberapa waktu lalu saya juga sempat menulis tentang AI dan pendidikan. Waktu itu saya berpendapat bahwa guru sebaiknya tidak terlalu fokus pada mendeteksi apakah sebuah tugas dibuat oleh AI atau tidak. Lebih baik fokus pada bagaimana siswa menjelaskan proses berpikirnya. Pendapat itu masih saya pegang. Tetapi ada satu hal yang baru terasa jelas belakangan ini.

Beberapa minggu lalu saya melihat beberapa teman mengikuti lomba lari. Ada yang ikut 5K, ada yang 10K, bahkan ada yang half marathon. Sebagai orang yang sudah terlalu lama hidup di dunia teknologi, pikiran pertama saya agak aneh, yaitu 'kenapa tidak naik motor saja?'

Tentu saja itu bercanda. Tapi setelah dipikir-pikir, pertanyaan itu mirip dengan sesuatu yang mungkin juga terjadi di kepala banyak siswa sekarang. Kalau sebuah tugas bisa diselesaikan dalam beberapa detik dengan AI, kenapa harus mengerjakannya sendiri?

Masalahnya, orang tidak ikut lomba lari karena tidak ada kendaraan. Mereka lari karena proses berlarinya itu sendiri. Tubuh dilatih, napas diatur, otot diperkuat. Semua itu tidak terjadi kalau seseorang hanya duduk di atas motor dan langsung sampai di garis finis. Belajar mungkin tidak jauh berbeda. Ketika seseorang menulis kode sendiri, menyusun argumen sendiri, atau memecahkan masalah sendiri, sebenarnya yang sedang dilatih bukan hanya hasil akhirnya. Yang sedang dibangun adalah cara berpikir.

AI jelas akan menjadi bagian dari kehidupan kita. Programmer sudah mulai menggunakan AI coding assistant, penulis menggunakan AI untuk merapikan draft, dan banyak pekerjaan lain akan mengalami hal yang sama. Tapi saya semakin merasa bahwa alat seperti itu paling berguna bagi orang yang sudah memahami proses dasarnya. Editor berpengalaman bisa memakai AI karena dia tahu mana kalimat yang perlu dipotong. Programmer berpengalaman bisa memakai AI karena dia tahu kapan sebuah solusi terlihat benar tapi sebenarnya berbahaya. Tanpa pemahaman itu, AI hanya memberi jawaban yang tampak rapi.

Kadang saya berpikir kembali tentang tugas-tugas tulisan tangan di awal kuliah dulu. Waktu itu terasa merepotkan. Bahkan terasa tidak masuk akal. Tapi mungkin justru di situ ada sesuatu yang penting, yaitu kita dipaksa menjalani prosesnya. Dan sekarang, dua puluh tahun kemudian, saya baru mulai benar-benar memahami kenapa pengalaman itu masih terasa membekas. Mungkin karena belajar memang bukan tentang seberapa cepat mendapatkan jawaban. Sering kali justru tentang berapa lama kita bergumul dengan pertanyaannya.

Meta, Integration Hell, dan Mengapa Sistem Canggih Bisa Terasa Patah

Beberapa waktu terakhir ini, saya merasa sedang melakukan "birokrasi digital" hanya untuk mengirim satu pesan atau memvalidasi satu data bisnis di ekosistem raksasa seperti Meta. Sebagai praktisi sistem, saya sering melihat fenomena menarik di Meta, yaitu sebuah perusahaan memiliki engineer terbaik dunia dan infrastruktur paling canggih, namun produknya terasa fragmented.

Pengguna merasa harus melompat dari satu "dunia" ke dunia lain, dari Facebook, WhatsApp, Instagram, Meta Business Suite, Facebook Developer, dengan aturan dan logika yang berbeda-beda. Saya melihat ini adalah gejala klasik dari Integration Hell.

Masalah di Meta (dan banyak organisasi besar lainnya) biasanya bukan di level teknologi, melainkan pada fragmentasi kendali. Dalam dunia manajemen sistem, kita mengenal Conway’s Law, di mana sistem yang dirancang organisasi cenderung mencerminkan struktur komunikasi internal mereka.

Ketika tim Facebook, Instagram, dan WhatsApp bekerja dengan KPI dan struktur data yang berbeda, hasilnya adalah ekosistem yang terasa seperti kumpulan "negara bagian" dengan aturan visa yang rumit, bukan satu benua yang terintegrasi. Lalu, apa pelajarannya bagi kita yang sedang membangun sistem di pemerintahan atau korporasi?

1. Sistem Harus Mengikuti Alur Kerja, Bukan Struktur Organisasi

Kesalahan fatal yang sering terjadi dalam digitalisasi (terutama di sektor publik) adalah membangun aplikasi berdasarkan Struktur Organisasi (SOTK). Ibarat Pemerintah Daerah, jika ada 5 bidang di satu dinas, maka muncul 5 menu atau bahkan 5 aplikasi berbeda.

Seorang System Analyst yang baik harus mampu membalik logika ini. Seharusnya pengguna tidak peduli siapa yang mengelola datanya, tetapi pengguna hanya ingin urusannya selesai dalam satu alur yang logis.

2. Birokrasi Digital vs "Automated Trust"

Mengapa kita masih diminta mengunggah dokumen fisik di sistem yang mengklaim dirinya pintar? Itu tandanya sistem tersebut belum memiliki Governance UX yang matang. Integrasi sejati bukan sekadar menyambungkan API, tapi membangun kepercayaan otomatis antar sistem. Jika Data A sudah divalidasi oleh Sistem X, maka Sistem Y seharusnya tidak perlu bertanya lagi. Inilah inti dari efisiensi tata kelola.

3. Skala vs Kesederhanaan

Tumbuh besar itu mudah, tapi tumbuh besar sambil tetap sederhana adalah seni tingkat tinggi dalam rekayasa sistem. Banyak sistem menjadi monster karena terlalu banyak fitur yang dipaksakan tanpa adanya single source of truth. Menjaga kesederhanaan di tengah kompleksitas membutuhkan pemahaman mendalam tentang integrasi, memastikan bahwa di balik layar yang rumit, pengguna tetap merasakan pengalaman yang mulus.

Pengalaman saya mendampingi berbagai transformasi digital, mulai dari sistem manajemen informasi pusat hingga tata kelola keuangan di  daerah mengajarkan satu hal, yaitu bahwa teknologi hanyalah alat, tapi integrasi adalah pola pikir.

Apakah kita sedang membangun "pulau-pulau aplikasi" yang saling terisolasi, atau kita sedang membangun satu ekosistem yang saling berbicara? Di situlah letak perbedaan antara sistem yang sekadar jalan dengan sistem yang benar-benar memberi solusi. Mari kita berhenti membangun aplikasi, dan mulai membangun integrasi.