Machikoba no Techo

Hanya orang yang sanggup menulisnya sendiri yang bisa melihat bahayanya.

September. Musim cumi malam untuk cumi pedang (Kensaki) — salah satu penanda musim panas di sini — mulai mendekati akhirnya. Mereka yang selama ini melaut pada malam hari perlahan beralih ke apa yang kami sebut budouika, si “cumi anggur”. Kami sungguh berterima kasih atas dukungan Anda yang tiada henti.

Dan ada satu hal lagi tentang September: inilah musim ketika cumi karang (aori) berkumpul. Begitu suhu air turun dari puncak musim panasnya, ikan-ikan umpan hidup kembali serentak. Cumi berubah bersama mereka, dan kelompok cumi muda masuk ke perairan dangkal — joran melengkung di sepanjang pemecah ombak dalam jendela waktu yang singkat saat fajar dan senja. Mungkin inilah saat paling mendebarkan sepanjang tahun. Bagi siapa pun yang berpikir untuk mulai eging, inilah juga musim yang paling ramah untuk memulai.

Bulan ini, izinkan saya kembali menulis tentang bagian belakang pabrik. Bulan lalu saya menulis bahwa sekalipun AI yang menuliskannya, berhenti sejenak untuk memeriksa tetap pekerjaan manusia. Ini kelanjutannya. Selama setahun terakhir, dengan memakai apa yang disebut “vibe coding” secara intensif di lantai kerja, saya merasakan kekuatannya sekaligus bahaya yang persis sebesar itu. Dan saya sampai pada pertanyaan yang saya duga sedang dihadapi banyak orang: bisakah kode yang dihasilkan AI dibawa masuk ke lantai kerja sebagai kotak hitam, tanpa dilihat isinya?

■ Katakan “saya ingin sesuatu seperti ini”, dan ia pun bekerja

Vibe coding berarti melewati spesifikasi yang rinci: Anda menjelaskan apa yang Anda inginkan dengan bahasa sehari-hari, membiarkan AI menuliskannya, lalu menerima kembali sesuatu yang berjalan. Selama setahun terakhir kami membangun sejumlah perkakas kecil untuk lantai kerja persis dengan cara ini. Atau lebih tepatnya, kami memproduksi perkakas seperti kami bernapas.

Perlu saya katakan lebih dulu bahwa ini sungguh ampuh. Apa yang dulu selalu tertunda dengan alasan “ingin sih, tapi tidak ada waktu untuk mendalaminya” kini berjalan pada hari yang sama saat terpikirkan. Apa yang dulu harus dimulai dengan penawaran harga dari perusahaan luar kini terbentuk dalam satu jam istirahat makan siang. Bagi pabrik kecil seperti kami, tidak ada perubahan yang lebih disambut daripada itu.

■ Berjalan dan benar adalah dua hal yang berbeda

Namun justru karena ia berjalan-lah hal paling menakutkan tahun ini muncul. Yang keluar biasanya bekerja. Layarnya terlihat rapi, angkanya muncul. Karena ia berjalan, dari luar Anda tidak bisa membedakan apakah ia sehat atau berbahaya.

Pembulatan yang sedikit berbeda di satu tempat. Perilaku yang tak terdefinisi ketika sebuah nilai datang di luar rentang yang diperkirakan. Kesalahan yang ditelan diam-diam sehingga semuanya berlanjut seolah tidak terjadi apa-apa. Tak satu pun dari ini terlihat dengan menatap layar yang bekerja. Satu-satunya orang yang melihatnya adalah mereka yang pernah menulis kode semacam itu sendiri dan pernah terbakar karenanya.

Pada akhirnya Anda tidak akan tenang sebelum menelusuri seluruh kode yang keluar. Waktu yang mestinya Anda hemat dengan mendelegasikan kembali lagi sebagai waktu membaca. Ambang untuk membangun turun luar biasa; ambang untuk menyadari bahaya tidak. Ketimpangan itulah pelajaran paling jernih yang saya dapat tahun ini. Dalam istilah kami, itu seperti berdiri di depan machining center seharga 40 juta yen lalu berkata “toh berjalan, jadi tidak apa-apa”. Itu tidak pernah boleh.

■ Di pabrik kecil tidak ada benda kerja yang ideal

Jadi, apakah ini perkakas yang tidak terpakai? Sama sekali tidak. Di sebagian pekerjaan kami, ia lebih pas daripada apa pun. Tetapi untuk menjelaskannya saya perlu memutar sejenak lewat kenyataan sebuah pabrik kecil.

Dalam kasus saya, saya rutin melakukan sesuatu yang agak ganjil: saya menghasilkan NC — bahasa mesin — lewat vibe coding. Untuk menulis kode yang mengeluarkan NC, Python biasanya dipilih secara otomatis; dalam banyak kasus saya menggantinya dengan Ruby. Itu gaya saya.

Mesin perkakas NC masa kini sangat presisi. Berikan mereka material ideal, bentuk ideal, dan dimensi ideal, dan mereka akan memotong hasil akhir yang membuat Anda takjub. Tetapi di bengkel kami hal-hal ideal itu hampir tidak pernah tersedia. Anda harus menyelesaikannya dengan apa pun yang ada di tangan. Materialnya tidak seragam; bentuk dan ukurannya berbeda setiap kali. Premis “sesuai gambar” itu sendiri tidak ada di hadapan kami.

Saya menyebutnya “semangat menyelesaikan dengan apa yang ada”. Itu kekuatan sebuah pabrik kecil dan kebanggaan kami, tetapi dari sudut pandang orang yang menulis program, itu sungguh merepotkan. Karena dimensinya berbeda setiap kali, Anda tidak bisa menulis prosedur dengan angka yang dipatok mati. Alih-alih “potong bentuk ini sampai dimensi ini”, ia harus ditulis ulang menjadi “ukur apa yang ada di depan Anda dan turunkan pemotongannya dari nilai itu”. Dengan kata lain, tingkat abstraksinya harus dinaikkan cukup jauh. Itulah bagian tersulit dari pemrograman di sebuah pabrik kecil.

■ Sempurna untuk menyesuaikan diri pada benda kerja, dan untuk reverse engineering

Dan cara kerja ini — menyesuaikan diri pada benda yang sebenarnya — ternyata mirip sekali dengan vibe coding. Tidak ada spesifikasi sempurna lebih dulu; Anda mendekati benda di hadapan Anda, memotong lalu mencobakannya, mencobakan lalu memotong lagi. Suruh ia menghasilkan sesuatu yang berjalan, tunjuk apa yang salah, minta diperbaiki, lalu coba lagi. Karena Anda bisa menggerakkan tangan sebelum spesifikasinya mengendap, ia sangat cocok dengan lantai kerja yang “selesaikan dengan apa yang ada”.

Di atas segalanya, vibe coding adalah pelengkap yang baik untuk bagian tersulit tadi: menaikkan tingkat abstraksi. Tunjukkan satu versi yang angkanya dipatok mati dan mintalah sesuatu yang tetap bekerja ketika dimensinya berubah, dan ia akan memilah apa yang seharusnya menjadi variabel. Bagian dari generalisasi yang dulu memakan waktu berhari-hari bagi seseorang — menemukan sudut masuknya — tersapu bersih sekaligus. Justru itulah kemampuan yang selama ini tidak dimiliki lantai kerja “selesaikan dengan apa yang ada” kami.

Kecocokan baik yang lain adalah reverse engineering: mencolek dari luar sebuah mekanisme yang tidak Anda pahami lalu menyusun ulang logika di baliknya. Untuk membaca format data yang asing, atau kode panjang yang ditulis seseorang bertahun-tahun lalu, dan mencari tahu apa yang dilakukannya, ia sungguh dapat diandalkan. Ini wilayah yang memang sejak awal tidak kami pahami, jadi sebuah kekeliruan tidak mahal harganya. Begitu sudut masuknya didapat, selebihnya bisa diverifikasi manusia.

Contoh yang dekat: program NC yang dikeluarkan sendiri oleh para pembuat mesin. Sejujurnya, saya kurang menyukainya. Tanpa indentasi, komentar yang tidak menolong, tidak ada cara membaca apa yang sedang dilakukannya. Program yang tidak bisa Anda baca adalah program yang tidak bisa Anda hentikan dan periksa. AI mengisi celah itu. Mintalah ia menambahkan indentasi dan komentar karena kodenya sulit dibaca, dan ia kembali persis seperti itu. Katakan abstraksinya terlalu rendah dan mintalah dipecah menjadi subrutin, dan ia membagi kode itu menjadi blok-blok yang bermakna. Perilaku yang sama, ditata dalam bentuk yang bisa dibaca manusia — mungkin itulah pemakaian yang paling sering kami raih saat ini.

Yang paling merepotkan kami adalah tidak ada satu pun catatan tentang variabel mana saja yang terkena efek samping sebuah subrutin. Anda memanggilnya dan sesuatu berubah. Tetapi apa yang berubah tidak diketahui sampai Anda membaca keseluruhannya. Suruh AI membacanya dan mintalah ia mendaftar, dalam komentar di bagian atas, variabel-variabel yang ditulisi di dalamnya — dan ia memilahnya. Itu pekerjaan yang dulu menghabiskan setengah hari seseorang.

Satu contoh konkret. Kami sering meminta AI menata ulang program NC untuk mesin wire EDM kami. Begitu praktisnya sampai hampir membuat hidung saya berdarah. Di dunia NC, meskipun semua orang menyebutnya “G-code”, tiap pembuat mesin punya kebiasaan penulisannya sendiri — dialek, pada praktiknya. Model ini ditulis begini; yang itu perlu perintah ini. Bagi manusia, itu soal membandingkan manual dan belajar di lantai kerja.

AI membaca hal itu dari gaya program yang Anda serahkan kepadanya. Ia merasakan konvensi siapa yang diikuti kode itu, lalu menulis tambahannya dengan konvensi yang sama. Berikan pula manual dari pembuat mesinnya, dan ia mulai memakai makro khusus model tersebut tanpa diminta. Ia membaca bahwa “mesin ini menyediakan instruksi ini” lalu menuliskannya dengan wajah datar. Pengetahuan tak tertulis yang menumpuk di lantai-lantai pabrik selama bertahun-tahun ternyata bisa ditarik keluar seperti ini — sejujurnya, itu membuat saya merinding.

Tetapi kami tidak pernah mengirim program yang dihasilkan seperti itu langsung ke mesin. Kami men-debug-nya. Ia selalu dijalankan di mesin sungguhan, ditelusuri baris demi baris, dengan nilai variabel dan gerak kawatnya diperiksa dengan mata. Di sinilah M01 (optional stop) yang saya tulis bulan lalu membuktikan gunanya. Sebagus apa pun hasilnya terlihat, jika Anda tidak punya kemampuan men-debug-nya di mesin sungguhan, Anda tidak bisa memakai perkakas ini. Atau lebih tepatnya, saya yakin Anda tidak boleh. Dipakai sebagai perkakas penghasil jawaban benar, ia berbahaya; dipakai sebagai perkakas pencari sudut masuk, ia luar biasa. Tetapi memastikan sudut itu selalu ada di pihak manusia.

■ Haruskah ia menjadi kotak hitam?

Yang membawa kita kembali ke pertanyaan pembuka. Bisakah kode yang dihasilkan AI dibawa ke lantai kerja tanpa dilihat isinya? Sejujurnya, kami membedakan antara kasus yang boleh dan kasus yang tidak boleh. Untuk sekarang garis yang kami tarik adalah berdasarkan di mana ia berada. Di tempat kekeliruan masih bisa disadari dan diperbaiki belakangan, di tempat yang hilang hanyalah waktu, kami memakainya tanpa menelusuri semuanya. Di tempat mesin bergerak, dimensi ditetapkan, dan material terpakai — di tempat tidak ada percobaan kedua — seorang manusia membaca semuanya, sepanjang apa pun jalan memutarnya.

Bagian yang canggung adalah bahwa kotak hitam itu bukan hanya bagian yang ditulis AI. Perangkat lunak masa kini dibangun dengan memanggil sejumlah besar komponen — pustaka yang diterbitkan seseorang, di suatu tempat, dari GitHub dan tempat lain. Baru-baru ini ada insiden besar di dunia JavaScript. (Sebenarnya, backdoor tampaknya muncul hampir setiap hari.) Sebuah pustaka yang menjadi tumpuan banyak sekali perangkat lunak diambil alih dan disisipi mekanisme yang berjalan saat pemasangan lalu menyebarkan dirinya ke paket berikutnya. Ratusan paket tampaknya terkontaminasi dalam hitungan jam. Tidak lama sebelum itu ada kasus penyadapan di tengah jalan untuk menukar tujuan pembayaran — yaitu, mengutak-atik bagian yang menangani uang.

Mintalah AI “sesuatu seperti ini” dan ia dengan sendirinya akan memilih dan menyertakan komponen-komponen yang praktis. Salah satu sebab ia cepat adalah karena ia tidak menulis sendiri komponen-komponen itu. Maka yang kita terima adalah struktur ganda: di dalam kotak yang ditulis AI, ia memanggil kotak milik orang lain. Tidak ada perajin yang memotong material tanpa tahu apa yang tercampur di dalamnya. Menurut saya perangkat lunak sama saja.

Pertanyaan ini — apakah Anda bisa memercayai kotak orang lain — bukanlah hal baru. Pada pertengahan 1990-an, D. J. Bernstein, yang menulis program pengirim surat qmail (kami sendiri menjalankannya lebih dari sepuluh tahun lalu), bahkan tidak memercayai pustaka standar C — komponen bawaan bahasa itu, yang dipakai semua orang tanpa dipertanyakan. Dalam catatan rancangannya ia menyatakan bahwa ia sebagian besar telah menyerah pada pustaka standar, dan mengganti bagian-bagian yang paling mudah menimbulkan kecelakaan, seperti penanganan string dan pengelolaan memori, dengan komponen kecil buatannya sendiri yang ia kembangkan bertahun-tahun. Ia tidak sampai membangun ulang sistem operasinya, tetapi pada satu hal ia tuntas: taruh bagian-bagian yang berbahaya di bawah kendali Anda sendiri.

Yang mengalir di sepanjang qmail adalah gagasan mengurangi, sejauh mungkin, apa yang harus Anda percayai. Selain menulis komponennya sendiri, ia membagi bagian dalam programnya menjadi bagian-bagian kecil menurut peran, dibangun sedemikian rupa sehingga bagian-bagian buatannya sendiri pun tidak saling memercayai. Jika salah satunya diambil alih, ia tidak bisa melangkah lebih jauh. Ada orang yang sudah memikirkan hal ini tiga puluh tahun lalu. Tentu saja kami tidak bisa menirunya dengan menulis sendiri setiap pustaka. Tetapi gagasannya — tarik batas-batas Anda dengan andaian bahwa hal-hal yang tak dapat dipercaya akan tercampur masuk — berlaku langsung sampai hari ini.

Dan yang menakutkan adalah, jika kotaknya terlalu besar, tidak ada jalan kembali. Ambil sesuatu yang tidak Anda pahami jauh di dalamnya sebagai satu gumpalan besar, dan Anda tidak bisa memisahkannya ketika terjadi sesuatu. Maka penangkalnya harus diambil pada tahap perancangan: pertahankan dalam bentuk yang selalu bisa Anda tukar. Bagian ini bisa diganti dengan yang lain; cabut komponen ini dan keseluruhannya tetap berjalan. Bangun dengan cara itu, dan pada hari sesuatu terjadi, Anda bisa membuang kotak itu saja.

Yang dituntut oleh hal itu adalah keterampilan merancang dalam pengertian berorientasi objek. Apa yang Anda perlakukan sebagai satu satuan, apa yang Anda tampakkan ke luar, seberapa banyak isinya Anda sembunyikan? Di mana Anda menarik batasnya? Apa yang dulu dianggap sekadar “menulis dengan rapi” kini menjadi kebutuhan praktis agar tidak memasukkan hal berbahaya ke dalam. Justru karena AI yang menulis isinya, kemampuan menentukan batas itulah yang dibutuhkan.

Dan garis ini bergeser jika dibiarkan. Setelah serangkaian hal berjalan lancar, orang pasti ingin membuat kotaknya lebih besar. Lebih buruk lagi, kemampuan menyadari bahaya menumpul persis sebanding dengan makin sedikitnya yang Anda tulis sendiri. Perkakas ini punya sifat: makin sering dipakai, makin sulit Anda menembus pandangan ke dalamnya. Maka garis itu harus ditarik ulang dari sisi manusia, bukan dari sisi perkakasnya.

■ Systems engineering, lebih dari sekadar coding

Menengok kembali setahun ini, di sinilah kesan saya paling berubah: yang benar-benar tak tergantikan mulai sekarang bukanlah coding itu sendiri, melainkan systems engineering.

Memutuskan apa yang dibangun dan apa yang tidak. Menarik garis antara apa yang didelegasikan kepada mesin dan di mana penilaian manusia mengambil alih. Menyiapkan, sebelum Anda membangun, bagaimana Anda akan kembali ketika ia berhenti bekerja. Memutuskan di mana datanya berada dan siapa yang bertanggung jawab atasnya. Secerdas apa pun ia nanti, AI tidak akan memutuskan hal-hal ini untuk Anda — karena memutuskannya menuntut pengetahuan tentang pekerjaan di lantai kerja.

Seiring berkurangnya waktu untuk menulis kode, kami mulai memakai waktu untuk perancangan, untuk pengoperasian, dan untuk menilai kapan harus berhenti. Ironisnya, lenyapnya kerja keras menulis justru membuat bobot pekerjaan yang datang sebelum menulis jauh lebih mudah terlihat.

■ Setiap proses dikerjakan sendiri, di Arita

Di perusahaan kecil, orang yang membangunnya juga yang memakainya, dan ketika rusak orang yang sama pula yang memperbaikinya. Maka “bisakah kita membangunnya?” jauh kurang penting dibanding “apakah ini masih dalam batas yang bisa kita rawat sendiri?” Jaga agar skalanya tetap bisa Anda pulihkan dengan tenaga sendiri pada hari ia berhenti. Tidak mentereng, tetapi saya percaya inilah arti DX yang dipotong sesuai ukuran sendiri.

Ini cerita yang persis sama dengan membuat egi. Purwarupa terwujud jauh lebih cepat daripada dulu. Tetapi langkah memastikannya di laut tidak bisa dipersingkat dengan cara apa pun. Yang menentukan baik dan buruk, pada akhirnya, selalu laut. Makin cepat kami bisa membangun, makin banyak waktu yang kami tanamkan untuk memastikan — itulah pemakaian yang kami pilih.

Di sebuah kota kecil di daerah — Arita, di Prefektur Saga, Jepang — kami terus membuat egi sendiri melalui setiap proses, dari perancangan sampai pemotongan cetakan, produksi massal, dan penjualan. Itulah yang membuat saya berpikir sepanjang Agustus. Komponen yang ditulis seseorang di suatu tempat di dunia berjalan di dalam pabrik kami sendiri, dan sebuah AI membaca dialek mesin-mesin kami. Di tengah semua itu, apa yang harus tetap berada di tangan manusia? Jawabannya belum setengah tiba, tetapi saya berniat untuk tidak berhenti memikirkannya.

■ Melaut bulan ini

September membawa deretan warna dan produk baru bagi kami. Akazamurai Meteor Glow Orange adalah oranye yang berubah wajah di antara pendaran fosfor dan penyinaran UV; peluncurannya dijadwalkan bulan ini. JetChaser Purple Edition, yang ditujukan untuk tip-run dari pantai, juga bulan ini. Selain itu, JetChaser size 3.0 dan size 3.1 akan dijual umum, dengan pengiriman direncanakan pada akhir September.

Tahun ini juga menandai tahun kelima belas sejak warna “Akazamurai” dari EgiSharp lahir. Pada akhir bulan lalu kami merilis gambar-gambar warna peringatan lima belas tahun itu. Kenyataan bahwa ia terus dipilih selama lima belas tahun bukanlah kepercayaan diri kami sendiri — itu jawaban yang diberikan orang-orang yang memakainya.

Secerdas apa pun perkakasnya nanti, yang menilai pada akhirnya adalah manusia, dan yang menentukan baik dan buruk adalah laut. Kami akan mengingat itu dan terus membuat barang, selangkah demi selangkah. Terima kasih sekali lagi atas dukungan Anda bulan ini.

September 2026
KeyStone Corporation
Nobuhide Kanagawa, Direktur Utama