Untuk waktu yang lama, saya bahkan tidak yakin situs ini membutuhkan blog.
Sebagian besar waktu kerja saya memang sudah habis untuk menyelesaikan masalah. Ada yang berupa tugas frontend atau backend biasa. Ada pula yang menjadi sangat spesifik: encoding gambar, perilaku browser, eksperimen SEO, kegagalan infrastruktur, pengembangan dengan bantuan AI, pemrosesan media, atau masalah production aneh yang dimulai dari pertanyaan sederhana lalu berubah menjadi investigasi selama beberapa hari.
Setelah itu, menulis beberapa ribu kata lagi bisa terasa tidak perlu.
Siapa yang akan membacanya?
Apa yang saya dapatkan?
Mengapa tidak menyelesaikan masalahnya lalu lanjut?
Akhirnya saya menemukan jawaban yang cukup bagi saya: sebagian pekerjaan ini terlalu mahal untuk dibuang begitu saja.
Masalah yang sulit bisa berisi satu artikel penuh sebelum saya menyadarinya
Artikel saya biasanya tidak dimulai dari pikiran, “Saya harus menulis satu posting blog minggu ini.”
Semuanya dimulai dari masalah.
Kadang masalah itu berasal dari pekerjaan saya. Kadang dari proyek pribadi. Kadang saya sekadar tertarik pada sesuatu yang tidak saya pahami lalu terus menggali sampai memahaminya jauh lebih baik.
Image processing berkali-kali membawa saya ke lubang kelinci seperti itu.
Pada awalnya, tugasnya bisa terdengar nyaris terlalu sederhana:
Ambil gambar-gambar ini dan buat ukurannya lebih kecil.
Anda dapat meminta sebuah script kepada model AI dan mendapatkannya hampir seketika.
Itu tidak berarti Anda sudah memiliki image-processing pipeline yang bagus.
Versi pertama mungkin mengabaikan perbedaan JPEG, PNG, WebP, dan konten animasi. Mungkin memakai satu nilai quality untuk semuanya, melakukan upscale yang tidak perlu, menangani transparansi dengan buruk, mempertahankan metadata yang ingin dibuang atau justru menghapus metadata yang ingin dipertahankan. Mungkin hanya mengejar ukuran file tanpa mengukur kerusakan visual. Bahkan bisa bekerja sempurna pada sepuluh file pengujian lalu menjadi kesalahan yang sangat mahal pada skala yang jauh lebih besar.
Script yang berhasil dijalankan tidak sama dengan sistem yang saya percayai.
Banyak artikel saya lahir dari perbedaan itu.
Workflow AI saya jauh lebih lambat daripada “tanya ChatGPT jawabannya”
Saya banyak memakai akun ChatGPT berbayar ketika mengerjakan masalah seperti ini.
Satu percakapan bisa bertahan selama berhari-hari atau berminggu-minggu. Saya bertanya, menguji saran, memasukkan hasil kembali, menantang asumsi, memeriksa code, menemukan edge case lain, mengubah implementasi, menjalankannya ulang, membandingkan hasil, lalu mengulang semuanya.
Untuk investigasi yang sangat dalam, saya pernah mengumpulkan lebih dari 100 jam pekerjaan di sekitar satu masalah besar yang sama.
Itu tidak berarti saya menghabiskan 100 jam menunggu model AI secara ajaib menemukan jawabannya.
Prosesnya iteratif.
Urutannya lebih mirip seperti ini:
- Saya menjelaskan masalah.
- Model mengusulkan solusi awal.
- Saya menjalankannya dengan data nyata.
- Ada sesuatu yang lemah, tidak efisien, atau memang salah.
- Saya membawa buktinya kembali.
- Kami mengubah pendekatan.
- Saya mengujinya lagi.
- Edge case lain muncul.
- Ulangi.
Siklus itu dapat terjadi berkali-kali.
Hasil yang berguna sering kali bukan script pertama, melainkan kumpulan kegagalan, pengukuran, koreksi, dan keputusan yang terakumulasi di sekitarnya.
AI membuat titik awal menjadi murah. Verifikasi tetap mahal
Ini salah satu alasan saya merasa perdebatan umum tentang konten teknis buatan AI terlalu sederhana.
Ya, model AI dapat menghasilkan tutorial yang terlihat masuk akal dengan sangat cepat.
Ia juga dapat menghasilkan code yang terlihat sepenuhnya wajar tetapi salah tepat pada situasi yang paling penting.
Untuk masalah teknis yang sempit, saya hampir tidak pernah menginginkan jawaban pertama yang terlihat masuk akal. Saya ingin tahu apa yang terjadi ketika benar-benar menjalankannya.
Jika saya membuat image pipeline, saya ingin memeriksa ukuran output dan kualitas visual. Saya ingin tahu apa yang terjadi dengan berbagai source format. Saya ingin menguji dimensi yang tidak biasa, alpha, animasi, dan input yang rusak. Saya juga ingin memahami asumsi apa yang dibuat oleh implementasi tersebut.
Jika script itu nantinya menyentuh koleksi yang sangat besar, pekerjaan ini menjadi lebih penting lagi.
Sepuluh juta gambar adalah contoh ekstrem yang sengaja saya pilih, bukan klaim tentang ukuran dataset tertentu milik saya. Namun contoh itu menggambarkan masalah dengan baik: kesalahan sistematis kecil yang dikalikan sepuluh juta kali tidak lagi kecil.
Biaya menghasilkan code telah jatuh drastis.
Biaya untuk menentukan apakah code itu layak dijalankan pada skala besar belum.
Chat adalah bahan riset, bukan artikel jadi
Setelah investigasi panjang seperti itu, riwayat chat dapat berisi jumlah informasi yang luar biasa besar.
Di dalamnya bisa ada:
- pendekatan yang gagal;
- code yang kemudian diganti;
- hasil benchmark yang berguna;
- log;
- kesalahpahaman;
- koreksi;
- penjelasan perilaku yang tidak jelas;
- perbandingan alternatif;
- edge case yang tidak terpikirkan pada awalnya;
- serta aturan akhir yang akhirnya saya percaya.
Membiarkan semua itu tertinggal di satu percakapan pribadi terasa mubazir.
Karena itu saya mengambil bagian yang berguna dan mengubahnya menjadi artikel.
Artikel bukan transkrip percakapan. Sebagian besar isi percakapan seharusnya memang tidak masuk ke artikel.
Artikel teknis yang berguna memerlukan satu tahap lagi: membuang jalan buntu yang tidak mengajarkan apa pun, mempertahankan jalan buntu yang menjelaskan sesuatu yang penting, memverifikasi klaim, membangun ulang kronologi, memisahkan observasi dari penjelasan, lalu mengubah hasil akhirnya menjadi sesuatu yang benar-benar dapat digunakan developer lain.
Tahap editorial itu penting.
AI dapat ikut membantu, tetapi bukti tetap berasal dari pekerjaan nyata.
Image processing mengajari saya seberapa dalam masalah yang terlihat “sederhana” bisa berkembang
Optimasi gambar mungkin merupakan contoh paling jelas dari pekerjaan saya sendiri.
Saya sudah menghabiskan cukup banyak waktu sehingga sesuatu yang awalnya terlihat seperti sekumpulan pengaturan encoder perlahan berubah menjadi masalah sistem yang jauh lebih besar.
Pertanyaannya cepat berubah.
Source format apa yang sedang saya tangani?
Apakah animated?
Apakah dimensinya perlu berubah?
Bagaimana memilih quality?
Metric apa yang seharusnya menentukan apakah penurunan kualitas dapat diterima?
Apakah satu quality threshold bekerja untuk gambar yang sangat berbeda?
Bagaimana menghindari upscaling?
Metadata apa yang harus dipertahankan?
Apa yang terjadi dengan transparansi?
Bagaimana output harus divalidasi?
Apakah ukuran file yang lebih kecil benar-benar sepadan dengan biaya encoding tambahan?
Apa yang terjadi jika populasi input berubah?
Karena itu saya skeptis terhadap script lima baris “ultimate image optimization”.
Script seperti itu tentu bisa memproses sebuah gambar.
Namun itu berbeda dari membangun pipeline yang trade-off-nya benar-benar Anda pahami.
Untuk workload saya saat ini yang sangat bergantung pada gambar, AVIF biasanya menjadi format pertama yang ingin saya pertimbangkan. Itu adalah aturan berdasarkan jenis proyek yang saya kerjakan, bukan klaim bahwa setiap website di dunia harus menghapus semua format lama besok. Persyaratan kompatibilitas, source material, latency, biaya encoder, dan delivery architecture dapat mengubah jawabannya.
Hal yang menarik bukanlah menyatakan satu format sebagai pemenang.
Yang penting adalah memahami workload dengan cukup baik untuk membuat keputusan secara sadar.
Saya ingin masuk sedalam itu juga ke video processing. Saya belum sampai ke sana. Itu salah satu hal yang membuat topik-topik ini tetap menarik: setiap kali saya merasa sudah mencapai dasar suatu masalah, muncul lapisan lain.
Lalu sebuah situs Jepang menemukan blog ini
Saya tidak mengharapkan hasil tertentu dari menerbitkan artikel-artikel ini.
Blog ini tidak menghasilkan keuntungan finansial yang berarti bagi saya. Saya melakukannya karena menyukai prosesnya dan lebih memilih menyimpan pekerjaan yang berguna daripada membiarkannya menghilang di chat lama dan riwayat terminal.
Lalu terjadi sesuatu yang benar-benar tidak saya duga.
Pada 17 September 2026, situs Jepang Levtech Freelance menerbitkan sebuah kumpulan dengan judul yang kurang lebih berarti “Blog yang Direkomendasikan untuk Engineer yang Ingin Meningkatkan Kemampuan”.
Artikel Levtech Freelance tersebut mencantumkan JSVar bersama beberapa blog engineering lainnya.
Levtech merupakan bagian dari ekosistem karier IT besar di Jepang, sementara Levtech Freelance berfokus pada dukungan dan pencocokan freelance IT engineer dengan peluang kerja. Bagi saya, hal yang menarik bukan sekadar mendapatkan backlink. Yang lebih menarik adalah melihat bagian mana dari pekerjaan saya yang dianggap cukup bernilai oleh tim editorial eksternal untuk dijelaskan kepada pembacanya.
Bagian mereka tentang JSVar secara khusus menyoroti tiga artikel.
Salah satunya membahas alasan saya merasa Codex dan TypeScript bekerja baik bersama dalam development production, terutama karena type dan feedback compiler TypeScript dapat mengungkap masalah pada generated code.
Artikel lain membahas penerjemahan blog ke 20 bahasa dengan ChatGPT dan bagaimana pengunjung dari search dari berbagai negara tiba langsung di halaman yang telah dilokalkan.
Artikel ketiga adalah eksperimen saya menerbitkan 10.000 halaman SEO buatan AI, yang akhirnya menjadi cerita tentang kegagalan alih-alih pertumbuhan yang mudah.
Pilihan itu membuat saya tersenyum karena ketiga artikel tersebut sangat berbeda, tetapi semuanya memiliki pola yang sama.
Semuanya berdasarkan sesuatu yang benar-benar saya lakukan.
Saya tidak tahu persis bagaimana Levtech menemukan saya
Ada cerita yang sangat menggoda di sini.
Saya tidak bisa berbahasa Jepang.
Situs saya memiliki versi Jepang.
Sebuah publikasi engineering Jepang menemukan situs tersebut.
Jadi, menerjemahkan blog ke bahasa Jepanglah yang menyebabkan Levtech menemukannya.
Saya tidak dapat membuktikan itu.
Mungkin halaman Jepang membantu.
Mungkin search membawa mereka ke artikel berbahasa Inggris.
Mungkin seseorang membagikan sebuah link.
Mungkin mereka menemukan situs melalui jalur yang sama sekali berbeda.
Saya tidak memiliki attribution data tersebut, jadi saya tidak akan membuat sebuah SEO case study yang rapi dari sesuatu yang tidak dapat dibuktikan oleh datanya.
Hal yang dapat saya konfirmasi jauh lebih sederhana: saya menerbitkan blog dalam beberapa bahasa, lalu sebuah publikasi Jepang menganggapnya cukup menarik untuk dimasukkan ke dalam pilihan editorial.
Itu sendiri sudah merupakan hasil yang baik.
Dan terasa lebih memuaskan karena localization juga merupakan eksperimen yang pada awalnya terlihat seperti pekerjaan besar dengan hasil yang belum pasti.
Penyebutan itu berarti karena menjadi validasi independen
Saya tidak menggunakan kata “validasi” dalam arti Levtech membuktikan bahwa semua yang saya tulis benar.
Mereka tidak mengaudit codebase saya atau mereproduksi setiap eksperimen.
Hal yang penting jauh lebih sederhana.
Seseorang di sisi lain dunia, yang menulis untuk audiens yang tidak bisa saya jangkau sendiri dalam bahasa mereka, menemukan cukup nilai dalam pekerjaan saya untuk merangkumnya bagi pembacanya.
Saya tidak pernah melakukan pitch kepada mereka.
Saya tidak menulis artikel asli itu untuk Levtech.
Saya juga tidak mengharapkan muncul di kumpulan artikel Jepang.
Karena itu hasilnya bermakna bagi saya.
Ini menunjukkan bahwa artikel teknis yang sangat spesifik tidak selalu membutuhkan audiens besar agar layak diterbitkan.
Artikel itu hanya perlu berguna bagi pembaca yang tepat.
Haruskah developer memulai blog pada 2026?
Bagi saya, ya — dengan satu syarat penting.
Anda harus benar-benar ingin menuliskan sesuatu.
Saya tidak akan menyarankan memulai blog teknis hanya karena seseorang mengatakan setiap developer memerlukan “personal brand”.
Saya juga tidak akan memulainya karena mengharapkan passive income.
Dan saya tidak akan mengisinya hanya dengan penjelasan generik tentang teknologi yang sudah memiliki dokumentasi lebih baik.
Namun jika pekerjaan Anda berkali-kali menghasilkan sesuatu yang dulu ingin Anda temukan ketika baru memulai, itu berbeda.
Tuliskan.
Tulis tentang production failure yang aneh.
Tulis tentang optimasi yang membutuhkan tiga hari lebih lama dari perkiraan.
Tulis tentang benchmark yang bertentangan dengan asumsi Anda.
Tulis tentang pendekatan yang terlihat elegan lalu gagal.
Tulis tentang implementasi akhirnya, tetapi jelaskan juga mengapa implementasi yang paling jelas tidak cukup.
Bagian seperti itulah yang sulit dibuat dari pengetahuan generik.
AI memberi saya lebih banyak bahan untuk ditulis, bukan lebih sedikit
AI tidak membuat saya menganggap blog teknis sudah tidak relevan.
Bagi saya, yang terjadi hampir sebaliknya.
Saya dapat menyelidiki lebih banyak ide karena mendapatkan implementasi atau penjelasan awal kini lebih cepat daripada sebelumnya.
Namun iterasi yang lebih cepat juga menghasilkan lebih banyak evidence: lebih banyak varian, log, benchmark, percobaan gagal, dan lebih banyak hal yang perlu diperiksa.
Bahan mentah itu baru bernilai setelah seseorang melakukan pekerjaan untuk menentukan mana yang benar dan mana yang penting.
Percakapan AI berisi 500 pesan tidak otomatis menjadi pengetahuan.
Sebuah script yang akhirnya lolos dari pengujian nyata, bersama penjelasan tentang 20 versi yang gagal, bisa menjadi pengetahuan.
Perbedaan itulah yang ingin saya tangkap dalam blog.
Menerbitkan adalah cara saya mencegah pekerjaan berguna menghilang
Sebagian besar pekerjaan teknis ternyata sangat sementara.
Bug yang sulit diperbaiki.
Terminal ditutup.
Deployment berhasil.
Chat turun semakin jauh di riwayat.
Enam bulan kemudian, bahkan saya sendiri mungkin tidak ingat mengapa implementasi akhirnya terlihat seperti itu.
Menulis mengubah keadaan tersebut.
Menulis memaksa saya membangun kembali reasoning ketika evidence masih ada.
Ia menciptakan sesuatu yang dapat dicari.
Ia memberi saya referensi untuk pekerjaan saya sendiri di masa depan.
Dan sesekali, ternyata tulisan itu mencapai orang yang sama sekali tidak saya duga — termasuk sebuah publikasi engineering dalam bahasa yang tidak saya kuasai.
Sampai sekarang saya tetap tidak memiliki alasan yang canggih untuk mempertahankan blog ini.
Saya suka belajar.
Saya suka membuat sesuatu.
Saya suka masuk terlalu dalam ke masalah yang pada awalnya terlihat sederhana.
Dan setelah menghabiskan puluhan, atau kadang lebih dari seratus jam, untuk mencapai sebuah jawaban yang berguna, saya tidak lagi ingin jawaban itu mati di dalam jendela chat.
Bagi saya, itu sudah cukup sebagai alasan untuk menerbitkannya.
Jika pekerjaan Anda juga menghasilkan pengetahuan yang diperoleh dengan susah payah seperti itu, saya rasa mungkin itu cukup sebagai alasan bagi Anda juga.