Mengubah Buku Resep Belanda 1866 Jadi Data dengan Bantuan AI

Akhir pekan ini saya iseng menguji beberapa AI lewat CLI untuk satu tugas yang kelihatannya sepele, yaitu mengubah buku tua hasil scan menjadi referensi data yang rapi. Bukunya Oost-Indisch Kookboek terbitan Van Dorp, Semarang, cetakan tahun 1866, lengkap dengan istilah bahan yang sudah tidak kita pakai lagi. Salinannya saya ambil dari koleksi domain publik Perpustakaan Universitas Leiden.

Kelihatannya tugas sederhana karena ada bahan PDF, ada AI, tinggal proses. Ternyata justru di sinilah pelajaran pentingnya muncul. Catatan ini saya tulis untuk berbagi prosesnya, termasuk bagian yang gagal lebih dulu sebelum jadi.

Sebelum cerita teknisnya, perlu saya ceritakan dulu kenapa buku ini menarik sebagai bahan uji. Oost-Indisch Kookboek tahun 1866 ini bukan buku resep biasa. Dalam sejarah kuliner Hindia-Belanda, ia tercatat sebagai buku masak berbahasa Belanda pertama tentang masakan Indis. (Buku masak Indis paling awal sebenarnya Kokki Bitja tahun 1854, tapi itu ditulis dalam bahasa Melayu.) Penulis edisi 1866 ini bahkan anonim, dan judul panjangnya menyebut 456 resep "teruji" untuk dapur Belanda maupun pribumi.

Di tahun 1866, resep ditulis sebagai paragraf mengalir, bukan format "daftar bahan dulu, lalu langkah-langkah" seperti yang kita kenal sekarang. Format terstruktur yang kita anggap standar itu baru dipopulerkan beberapa dekade kemudian sebagai metode baru yang lebih praktis. Artinya, tantangannya bukan cuma scan yang kotor. Sumbernya sendiri memang tidak terstruktur. Mengubah prosa resep abad ke-19 menjadi data berarti membongkar bahan, takaran, dan langkah yang menempel jadi satu di dalam kalimat panjang, sebelum OCR-nya pun ikut bermasalah.

Garbage In, Garbage Out

Scan mentah yang langsung di-OCR hasilnya kacau:

• Baris patah di tengah kata, karena kolom dan margin halaman tua tidak terbaca rapi.
• Resep terpotong antar-halaman, sehingga satu resep terbelah jadi dua fragmen yang seolah tidak berhubungan.

Di titik ini saya menyadari sesuatu yang sering dilupakan orang ketika bicara soal AI , yaitu kalau input-nya berantakan, secanggih apa pun modelnya, output-nya tetap sampah. Model bahasa tidak menyulap. Ia bekerja di atas apa yang kita beri. Memberi teks rusak lalu berharap hasil bersih sama saja dengan menyuruh juru masak hebat memasak dari bahan busuk.

Dari sinilah pendekatannya berubah. Prosesnya bukan "lempar ke satu AI lalu selesai", tapi secara bertahap, di mana tiap tahap punya tugas yang berbeda dan tiap alat dipakai untuk hal yang paling dikuasainya.

OCR dengan ocrmypdf + pdftotext

Tahap paling dasar, ocrmypdf saya pakai untuk membuat lapisan teks ke dalam PDF scan, lalu pdftotext untuk menariknya keluar. Di sinilah kualitas keseluruhan ditentukan, yaitu setiap kesalahan di tahap ini akan diwariskan ke semua tahap berikutnya. Ini bagian yang paling banyak butuh percobaan ulang, tapi bagian yang menentukan apakah AI nantinya punya bahan yang layak.

DeepSeek

Setelah ada teks mentah yang sudah "lumayan", saya pakai DeepSeek untuk pemeriksaan tahap awal untuk memberi gambaran kasar struktur isinya

Claude

Tahap penyuntingan dokumen dan penataan tata letak saya serahkan ke Claude untuk menyusun kembali resep yang terpotong, merapikan struktur, dan membentuk dokumen yang konsisten dan enak dibaca. Di tahap inilah kumpulan teks mentah mulai berubah wujud menjadi sesuatu yang menyerupai dokumen referensi.

NotebookLM

Terakhir, dokumen hasil suntingan saya uji ulang dengan NotebookLM, semacam tinjauan akhir untuk menelusuri isinya, mengecek konsistensi, dan memastikan tidak ada bagian yang melenceng jauh dari sumber.

Inti dari empat tahap ini bukan soal "AI mana yang paling jago", melainkan soal memecah satu pekerjaan besar menjadi tugas-tugas kecil yang bisa diperiksa. Tiap tahap menghasilkan keluaran yang bisa saya lihat, koreksi, dan perbaiki sebelum diteruskan. Itu sebabnya saya menyebutnya 'tuning', bukan otomasi sekali jalan.

Hal yang Tidak Boleh Saya Lewatkan: Disclaimer

Ada satu hal yang harus saya tulis terus terang, yaitu saya tidak bisa bahasa Belanda. Maka sebersih apa pun tampilan dokumen akhirnya, saya tetap menyertakan disclaimer terbuka, bahwa kemungkinan salah baca dan salah tafsir belum diverifikasi oleh penutur asli.  Ini bagian yang menurut saya paling penting dan paling sering dilewati. Ketika output AI terlihat mulus, godaan terbesarnya adalah berhenti bertanya. Padahal di teks berbahasa asing yang berumur 150 tahun lebih, dengan istilah bahan yang sudah punah dari pemakaian, peluang salahnya justru besar, dan saya tidak punya kompetensi untuk menangkap kesalahan itu sendirian.

Eksperimen kecil dengan buku resep tua ini mengajari saya tiga hal yang sebenarnya berlaku jauh di luar urusan dapur abad ke-19. Beberapa kesimpulan yang saya dapatkan:

1. Kualitas input menentukan segalanya. Investasi terbesar justru di tahap paling awal, yaitu membersihkan bahan.
2. Pecah pekerjaan jadi tahap yang bisa diperiksa melalui satu pipeline bertahap dengan titik koreksi di tiap simpul jauh lebih andal daripada satu lompatan besar dari mentah ke jadi.
3. Kenali batas Anda, dan tulis terus terang. Output yang rapi bukan output yang benar. Selama belum ada validasi manusia yang tepat, status pekerjaan adalah "membantu", bukan "selesai".

Inilah inti dari eksperimen ini. Bukan untuk membuktikan AI bisa menggantikan kita, tapi untuk menunjukkan dengan jelas di mana batasnya, supaya kita memakainya sebagai alat percepat yang jujur, bukan kotak hitam yang kita percaya buta.

Link hasil: https://static.wahyu.com/uploads/2026/Oost-Indisch_Kookboek_1866-R4.pdf

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.