Dikte yang Bertahan di Terminal

Developer yang mencoba alat dikte sering menemui kegagalan dengan bentuk yang sangat khas. Alatnya bekerja indah di demo. Ia bekerja di Notes, di Slack, di browser. Lalu kamu memfokuskan sebuah terminal, mendiktekan satu kalimat, dan entah tidak ada yang muncul, atau muncul sesuatu yang bukan apa yang kamu ucapkan, atau separuhnya muncul dan separuh lagi entah kenapa sekarang ada di clipboard-mu. Kadang ia bekerja secara lokal lalu mati begitu kamu SSH ke sebuah mesin.

Polanya cukup konsisten sampai saya rasa ini bukan bug di satu produk mana pun. Ini konsekuensi dari cara kategori ini menyisipkan teks — dan ia gagal persis di tempat-tempat seorang developer tinggal.

Itu lebih penting sekarang dibanding dua tahun lalu. Kalau kamu mengendalikan Claude Code lewat suara — workflow yang saya gambarkan di mengendalikan Claude Code dengan suaramu — maka terminal bukan salah satu aplikasi di antara banyak aplikasi. Ia adalah aplikasinya. Di situlah prompt-mu mendarat, di situlah agent-mu menunggu arahan ulang, di situlah seluruh urusan lane paralel itu berhasil atau tidak. Alat dikte yang labil di terminal, bagi seorang vibecoder, labil pada satu-satunya tugasnya.

Kenapa paste rusak persis di tempat developer tinggal?

Inilah mekanika di level kategori. Kebanyakan alat dikte menyisipkan teks dengan cara yang sama: mereka menaruh kalimat hasil transkripsimu di clipboard sistem, lalu mensintesis ketukan Cmd+V di aplikasi yang sedang fokus. Itu default yang masuk akal — paste itu instan, ia bekerja di hampir semua kolom teks GUI, dan ia nyaris tidak butuh rekayasa per aplikasi.

Masalahnya adalah semua hal yang diam-diam diandalkan asumsi itu.

Ia bergantung pada aplikasi yang sedang fokus memperlakukan Cmd+V sebagai "paste". Terminal sering tidak begitu — banyak yang memakai Cmd+V untuk hal lain atau tidak sama sekali, tmux dan vim punya gagasan sendiri tentang apa arti paste, dan sesi SSH remote bisa menafsirkan semburan teks yang di-paste dengan cara yang tidak bisa diprediksi mesin lokal. Bracketed paste, copy-mode, insert-mode versus normal-mode: dunia terminal penuh keadaan di mana paste sintetis mendarat salah atau tidak mendarat sama sekali.

Ia bergantung pada clipboard yang tersedia dan tidak dijaga. Clipboard manager menulis ulang isinya. Password manager sengaja mengosongkan atau memproteksinya — fitur keamanan yang mengubah "paste dikte saya" menjadi "paste tidak ada apa-apa", tanpa suara. Dan bahkan saat semuanya bekerja, alat itu baru saja menimpa apa pun yang tadi kamu salin. SHA commit yang kamu bawa antar jendela hilang, digantikan kalimatmu sendiri. Bagi orang yang menjuggle beberapa lane, itu bukan luka kecil; clipboard tadi sedang mengerjakan sebuah tugas.

Dan ia bergantung — ini yang mengejutkan banyak orang — pada tata letak keyboard-mu. Saat sebuah alat jatuh ke simulasi ketukan tombol, cara naifnya adalah mengirim kode tombol: posisi fisik tombolnya. Kode tombol dipetakan ke karakter lewat tata letakmu. Di QWERTY, kode untuk "V" menghasilkan V. Di Dvorak, posisi fisik yang sama adalah huruf yang berbeda. Jadi alat yang mensimulasikan scancode di tata letak Dvorak, AZERTY, atau Colemak menghasilkan teks yang terlihat seperti melewati sandi substitusi. Pengguna melaporkan teks kacau dan mengira pengenalan suaranya gagal. Bukan — ucapannya sempurna, penyisipannya yang mengacaukannya.

Tidak ada niat jahat atau kemalasan dari pihak mana pun di sini. Paste lewat clipboard adalah default yang tepat untuk 90% kasus. Hanya saja developer menghabiskan harinya di 10% sisanya.

Apa arti "ketik saja" yang sebenarnya

Keebye punya pengaturan bernama insert_mode dengan dua nilai: paste, yang merupakan default, dan type.

Mode ketik tidak mem-paste. Di macOS ia memakai CGEventKeyboardSetUnicodeString — sebuah API yang melekatkan teks Unicode yang sesungguhnya ke event tombol sintetis. Karakternya dibawa di dalam event itu sendiri, bukan dicari lewat tata letak keyboard-mu. Itu membuatnya independen dari tata letak secara konstruksi: Dvorak, AZERTY, Colemak, apa pun yang kamu pakai mengetik, teks yang tiba adalah teks yang ditranskripsi, karena tidak pernah ada penerjemahan scancode-ke-karakter yang bisa salah.

Properti kedua mode ketik adalah yang dipedulikan pengguna terminal: ia tidak pernah menyentuh clipboard. Nol operasi clipboard di jalur kode itu. Isi clipboard-mu tetap milikmu — SHA-nya selamat, password manager tidak punya apa pun untuk dijaga, clipboard manager tidak punya apa pun untuk dicatat.

Dan karena terminal serta sesi remote bisa tersedak oleh teks yang datang lebih cepat daripada ketikan manusia mana pun, mode ketik sengaja mengatur lajunya sendiri: teks masuk sebagai potongan 16 karakter dengan jeda 4 milidetik antar potongan. Cukup cepat sehingga satu kalimat mendarat jauh di bawah satu detik; cukup terukur sehingga panel tmux lewat SSH menerimanya sebagai ketukan tombol yang bisa ia ikuti, bukan sebagai gumpalan yang harus ia tafsirkan.

Mode paste masih ada, dan masih menjadi default, karena ia memang benar-benar lebih cepat untuk blok teks besar di aplikasi GUI biasa — pesan Slack tiga paragraf tiba sebagai satu paste alih-alih aliran potongan. Meski begitu, mode paste pun mendapat pelajaran soal tata letak: Cmd+V sintetisnya memakai keycode V fisik, jadi paste itu sendiri tidak rusak di tata letak non-QWERTY seperti yang bisa terjadi pada pendekatan pencarian karakter.

Setup praktis untuk kerja dengan agent itu sederhana: ubah insert_mode ke type, fokuskan terminal yang menjalankan Claude Code, tahan tombolnya, ucapkan arahan ulangnya, lepaskan. Prompt-nya tiba seperti ketukan tombol biasa, karena sejauh yang bisa dilihat terminal, memang itulah dia. Ada versi langkah demi langkah dari setup ini, termasuk hal-hal spesifik SSH dan tmux, di dikte suara untuk terminal macOS.

Batas yang jujur

Mode ketik lebih lambat daripada paste untuk teks panjang — itu aritmetika, bukan cacat. Ketukan tombol terpotong-potong dengan jeda penataan laju butuh waktu lebih lama daripada satu event paste, dan kalau kamu mendiktekan beberapa paragraf ke sebuah dokumen, mode paste akan terasa lebih gesit. Persis karena itulah paste tetap jadi default dan mode ketik adalah sesuatu yang kamu aktifkan sendiri di pengaturan; mode yang tepat bergantung pada ke mana teksmu pergi.

Sebagian aplikasi membatasi laju atau menyaring input sintetis, biasanya demi alasan keamanan, dan tidak ada strategi penyisipan yang sepenuhnya lolos dari itu — aplikasi yang menolak event sintetis menolaknya dari setiap alat dikte.

Dan supaya jelas soal apa yang diklaim dan tidak diklaim artikel ini: keluhan paste-rusak-di-terminal adalah pola di seluruh kategori dikte, bukan cacat unik milik pesaing mana pun. Alat lain punya jawaban dan kekuatannya sendiri — kami menulis perbandingan yang jujur di Keebye vs Superwhisper dan Keebye vs Wispr Flow, termasuk di mana masing-masing mungkin lebih cocok untukmu.

Penyisipan adalah separuh dikte yang tidak glamor

Pengenalan suara mendapat semua perhatian — nama model, klaim akurasi, jumlah bahasa. Tapi alat dikte punya dua tugas: mendengarmu dengan benar, lalu membawa teksnya ke tempat kursormu berada tanpa kehilangan atau merusaknya. Tugas kedua terdengar sepele dan justru di situlah kategori ini diam-diam mengecewakan developer, karena tugas kedua itu mudah di TextEdit dan sulit di panel tmux pada mesin remote di bawah tata letak Dvorak.

Kalau prompt-mu mendarat di terminal — dan kalau kamu mengendalikan agent coding, memang begitu — penyisipan bukan catatan kaki. Ia adalah selisih antara alat yang kamu demokan dan alat yang kamu pakai. Ngomong-ngomong, mode kegagalan terkait punya rasa yang sama: kata pertama sebuah dikte dimakan oleh cold start mikrofon adalah keluhan lain yang menyeluruh di kategori ini dengan penjelasan mekanis, dan yang itu kami tulis di kenapa aplikasi dikte memakan kata pertamamu.

Keebye ada dalam akses awal untuk macOS. Kalau dikte kamu pernah lenyap di suatu tempat antara mulutmu dan sebuah terminal, mulai uji coba gratismu di bawah, aktifkan mode ketik, dan ulangi prompt yang sama. SHA yang kamu salin tetap ada di clipboard sementara kata-katanya tiba sebagai Unicode yang diketik.