Kita Perlu Meninjau Ulang Literate Programming di Era Agen

 (silly.business)
14 poin oleh GN⁺ 2026-03-11 | 2 komentar | Bagikan ke WhatsApp
  • Literate Programming yang merangkai kode dan penjelasan bahasa alami dalam satu narasi tidak banyak dipakai luas karena beban menjaga dua hal sekaligus—kode dan penjelasan—namun agen coding AI dapat menghilangkan pekerjaan inti ini
  • Melalui org-babel di Org Mode Emacs, literate programming multibahasa dimungkinkan, tetapi pada proyek besar proses ekstraksi kode sumber (tangling) yang merepotkan menjadi batasan
  • Jika agen diminta menulis runbook berbasis file Org, dimungkinkan alur kerja untuk menguraikan niat lewat penjelasan, menjalankan blok kode secara interaktif, dan menyimpan hasilnya ke dokumen
  • Karena agen menangani sinkronisasi antara penjelasan dan kode serta tangling secara otomatis, upaya menulis ulang penjelasan saat kode berubah hilang, sambil memanfaatkan kemampuan terjemahan dan peringkasan yang paling dikuasai LLM
  • Di tengah pergeseran peran engineer dari menulis kode menjadi berfokus pada membaca kode, kepraktisan codebase bernarasi yang dipelihara agen muncul sebagai pertanyaan kunci

Konsep dan keterbatasan literate programming

  • Literate Programming adalah gagasan mencampur kode dan penjelasan bahasa alami agar pembaca tanpa pengetahuan awal pun bisa membaca codebase sebagai satu narasi dan memahami cara kerjanya
  • Ini konsep yang menarik, tetapi dalam praktik muncul beban mempertahankan dua narasi paralel: kode itu sendiri dan penjelasannya, yang menjadi alasan mendasar adopsinya terbatas
  • Bentuk yang paling umum di praktik adalah Jupyter Notebook di komunitas data science, tempat penjelasan, komputasi, dan hasil ditampilkan bersama di browser web

Emacs Org Mode dan literate programming

  • Org Mode di Emacs mendukung literate programming multibahasa melalui paket org-babel, sehingga bahasa apa pun bisa dijalankan dan hasilnya ditangkap ke dokumen
    • Namun pendekatan ini tetap menjadi pola niche yang bertahan di kalangan sedikit pengguna fanatik
  • Jika file Org dipakai sebagai source of truth dalam proyek perangkat lunak skala besar, maka kode sumber pada dasarnya menjadi keluaran hasil kompilasi, dan setelah setiap edit kode harus diekstrak ("tangle") lalu ditempatkan ke tujuan
    • Ini bisa diotomatisasi, tetapi mudah menimbulkan masalah ketika pengguna atau agen mengedit source aktual lalu perubahan itu tertindih pada proses tangle berikutnya

Pola pemakaian sebelum era agen

  • Ada hasil yang cukup baik dari memakai literate programming untuk mengelola konfigurasi pribadi, sehingga gagasan ini tidak ditinggalkan bahkan sebelum hadirnya LLM
  • Pola memakai Org Mode untuk pengujian manual dan pencatatan: alih-alih command line, perintah ditulis dan dijalankan di editor, lalu diedit sampai tiap langkah benar, dan hasilnya disimpan langsung di tempatnya
    • "Jika pencatatan dan eksekusi tes digabungkan, maka saat tes selesai catatannya tercipta gratis"

Alur kerja baru bersama agen

  • Agen coding seperti Claude dan Kimi memahami sintaks Org Mode dengan baik, dan Org adalah bahasa markup yang longgar sehingga sangat mudah ditangani LLM
    • Sintaks Org Mode yang sangat luas adalah kekurangan bagi manusia, tetapi bukan masalah bagi model bahasa
  • Saat melakukan uji fitur, jika agen diminta membuat runbook Org maka:
    • Penjelasan memuat refleksi model tentang maksud tiap langkah
    • Blok kode, setelah ditinjau, dapat dijalankan satu per satu atau seluruhnya secara interaktif seperti skrip
    • Hasilnya disimpan di bawah kode seperti pada Jupyter Notebook
  • Kita bisa mengedit penjelasan lalu meminta model memperbarui kode, atau mengedit kode lalu model merefleksikan maknanya ke penjelasan, atau agen mengubah keduanya sekaligus
    • Masalah menjaga dua narasi paralel pun hilang

Pekerjaan inti yang dihapus agen

  • Jika proses tangling diserahkan ke agen, maka masalah ekstraksi kode juga teratasi
  • Melalui file AGENTS.md, agen dapat diarahkan untuk memperlakukan file Org sebagai source of truth, selalu menulis penjelasan, dan melakukan tangle sebelum eksekusi
    • Agen mahir melakukan semua ini, dan tidak pernah lelah menulis ulang penjelasan setelah kode diubah
  • Agen menghapus kerja tambahan mendasar yang membuat literate programming tidak dipakai luas, sambil memanfaatkan kemampuan terjemahan dan peringkasan yang paling dikuasai LLM

Manfaat yang diharapkan

  • Codebase bisa diekspor (export) ke berbagai format agar lebih nyaman dibaca
    • Ini особенно penting jika peran utama engineer memang sedang bergeser dari menulis ke membaca
  • Memang belum didukung data, tetapi diperkirakan kualitas kode yang dihasilkan juga bisa meningkat karena narasi yang menjelaskan maksud tiap blok kode muncul bersama kode dalam konteks
  • Hingga kini pendekatan ini belum dicoba pada codebase besar dan serius, dan saat ini dipakai pada alur kerja pengujian serta dokumentasi proses manual

Keterbatasan Org Mode dan alternatif

  • Format Org terintegrasi erat dengan Emacs sehingga menjadi faktor pembatas, dan sudah lama ada keyakinan bahwa Org perlu keluar dari Emacs
  • Ingin merekomendasikan Markdown sebagai alternatif, tetapi Markdown kurang memiliki kemampuan menyertakan metadata
    • Konsep Properties di Org Mode memungkinkan dokumen dimanipulasi secara terprogram dengan Emacs Lisp, dan kini LLM bahkan bisa menulis fitur kustom khusus dokumen itu dalam Emacs Lisp di bagian file variables
    • Markdown juga tidak punya fitur seperti header arguments di Org Mode untuk menentukan detail eksekusi blok kode, seperti lokasi menjalankan atau mesin jarak jauh
  • Yang benar-benar menggugah bukan implementasi spesifik Emacs, melainkan idenya sendiri

Pertanyaan kunci

  • "Dengan agen, mungkinkah menjadi praktis untuk memiliki codebase skala besar yang bisa dibaca seperti narasi, sementara sebuah mesin yang tak kenal lelah menjaga sinkronisasi antara perubahan kode dan penjelasannya?"

Bacaan terkait

2 komentar

 
GN⁺ 2026-03-11
Opini Hacker News

  • Saya rasa cara paling sederhana adalah membiarkan LLM menulis komentarnya sendiri
    Dengan begitu, saat LLM membaca ulang kode tersebut nanti, ia bisa merujuk ke komentarnya sendiri, sehingga berfungsi seperti memori jangka panjang just-in-time
    Di <summary> tulis ringkasannya, di <remarks> alasan dan konteksnya, di <params> batasannya, lalu minimalkan komentar inline
    Dengan cara ini, saat review PR kita bisa langsung memeriksa proses berpikir LLM di <remarks>, sehingga lebih mudah menemukan bagian yang dipahami tidak sesuai niat aslinya

    • Dalam pengalaman saya, komentar yang ditambahkan LLM itu terlalu bertele-tele dan kekanak-kanakan
      Pada akhirnya ia malah mengotori konteksnya sendiri dengan informasi yang tidak perlu dan membuat pemahamannya menurun
      Masih jauh dari literasi setara manusia
    • Bagi manusia, komentar LLM sering terasa berisik dan penuh informasi yang tidak perlu
      Tapi justru komentar seperti inilah yang membuat LLM terbantu saat membaca ulang kode yang sama, jadi bisa jadi itu informasi yang berharga
    • Manusia mengingat alasan mengapa kode ditulis, tetapi LLM punya context window yang terbatas, jadi informasi seperti itu cepat hilang
      Karena itu komentar seperti ini berfungsi untuk mempertahankan ingatan tersebut
    • Melihat hal seperti ini, saya jadi berpikir bahwa komentar yang ditulis agen seharusnya diberi tanda tangan agar bisa dibedakan

  • Saya rasa bahasa pemrograman muncul karena ambiguitas dalam bahasa alami
    Karena itu komentar kode pada akhirnya juga menjadi ambigu, dan karena tidak dieksekusi, cepat usang
    LLM kuat dalam menerjemahkan kode, tetapi masih terasa sulit untuk mengubah prompt bahasa alami menjadi kode
    Kode yang baik harus mengekspresikan niat dengan jelas, dan banyaknya komentar bisa jadi sinyal bahwa kualitas kodenya rendah

    • Jika kode yang baik saja sudah cukup, maka kita tak perlu membaca dokumentasi dan cukup melihat source code
      Namun perangkat lunak yang baik juga harus mencakup dokumentasi yang baik
      Literate programming adalah penulisan yang berpusat pada penjelasan, bukan detail implementasi
    • Seperti alasan munculnya gaya bahasa hukum, semakin spesifik prompt, semakin efektif hasilnya
      Dengan kode kita mendefinisikan “bagaimana” secara sempit, tetapi bahasa alami bisa mengekspresikan “apa”, sehingga memberi ruang bagi LLM untuk menyarankan cara yang lebih baik
    • Kode dan dokumentasi harus bekerja bersama seperti kode koreksi kesalahan timbal balik
      Harus ada informasi yang saling tumpang tindih agar kesalahan bisa dideteksi dan diperbaiki
    • Bahasa pemrograman juga tidak sepenuhnya tidak ambigu
      Hanya saja ia memberi aturan untuk mempersempit kebebasan interpretasi
      Kadang metafora atau ambiguitas justru menjadi bentuk ekspresi yang lebih tepat
    • Saya tidak menyuruh LLM melakukan literate programming, tetapi saya memintanya menjelaskan trade-off
      Jika diberi template berupa contoh kode dan dokumentasi, halusinasi berkurang

  • Ada riset yang menunjukkan bahwa komentar bergaya literate programming membantu manusia memahami kode
    Peneliti Google menguji apakah LLM bisa memperbarui komentar semacam ini, dan apakah itu membantu pemahaman manusia
    Kesimpulannya, komentar tingkat blok yang menjelaskan niat adalah yang paling efektif
    (Referensi: paper arXiv 2024 "Natural Language Outlines for Code")

  • Fenomena menarik belakangan ini adalah, dulu orang malas menulis README atau dokumen arsitektur untuk manusia
    tetapi sekarang jika dibilang itu ditulis untuk LLM, orang jadi jauh lebih antusias

    • Manusia hampir tidak membaca dokumentasi dan hanya bertanya saat perlu
      Namun LLM merujuk dokumentasi di setiap tugas, sehingga motivasi untuk mendokumentasikan jadi jauh lebih kuat
    • Kebiasaan yang dulu diabaikan sebagai “engineering hygiene” kini memberi manfaat besar bagi agen
      Commit message, catatan seperti ADR, mungkin tidak dibaca manusia, tetapi semuanya dibaca LLM
      Pada akhirnya kebiasaan ini juga membantu engineer junior manusia
    • Saya pernah mendengar kalimat seperti ini
      Orang-orang yang belajar berbicara dengan komputer sampai lupa cara berbicara dengan manusia justru tertinggal setelah lulus
    • Dokumentasi membusuk lebih cepat daripada kode
      Karena agar kode berjalan, akurasi dokumentasi tidak diperlukan
      Jadi sering kali terasa lebih baik melihat kode langsung daripada dokumentasinya
    • Mungkin kebiasaan seperti ini memang lebih alami dari sudut pandang manajer

  • Saya melihat kombinasi literate programming ringan dan bahasa yang berpusat pada konvensi sangat cocok untuk era agen
    Bahasa seperti Go, yang punya kompilasi cepat dan style guide yang jelas, terasa bagus
    Jika agen dirujukkan ke Google Go Style Guide saat menulis kode, hasilnya cukup baik

  • Karena LLM adalah model bahasa, maka berinvestasi pada penulisan yang jelas sangat bernilai
    Tidak harus sampai literate programming, tetapi nama yang baik, docstring, type signature, komentar yang menjelaskan “mengapa” itu penting
    Pada akhirnya inti persoalannya adalah membangun pola komunikasi untuk manusia dan LLM sekaligus

    • Yang dibutuhkan adalah titik tengah antara docstring dan literate programming
      Dokumentasi yang menjelaskan struktur tingkat atas pada level file, direktori, dan proyek sangat penting
      Namun konsep seperti ini melintasi banyak file, jadi selalu muncul masalah soal harus ditulis di mana dan sinkronisasi dokumentasi-kode
    • Saya rasa Notebook sendiri adalah salah satu bentuk literate programming

  • Selama 10 tahun terakhir saya menulis hampir semua kode dengan gaya literate programming
    Saya membuat nbdev untuk mengelola kode, dokumentasi, dan test bersama-sama berbasis notebook
    Belakangan saya juga membuat tool bernama Solveit yang mengintegrasikan LLM dan sedang digunakan di seluruh perusahaan
    (tautan Solveit)
    Literate programming juga berguna untuk pekerjaan di luar pemrograman

    • Hanya saja nama Solveit terlalu umum sehingga sulit dicari, dan video perkenalannya terlalu panjang
      Akan lebih baik jika ditambahkan demo singkat atau screenshot

  • Gagasan menggunakan LLM untuk secara otomatis mendeteksi ketidaksesuaian antara komentar dan kode terasa menarik
    Dokumentasi pada akhirnya pasti menyimpang dari kode seiring waktu, dan jika ini bisa dideteksi otomatis, nilainya besar
    Rasanya bahkan bisa dibuat startup dari hal seperti ini

    • Sejak 2023 sudah ada lebih dari 10 startup di bidang ini (penulisnya adalah technical writer)
    • Ini ide yang pernah saya pikirkan sebelumnya, yaitu sistem yang mewajibkan DocString/JSDoc untuk setiap direktori, modul, kelas, dan fungsi
      Perubahan dimulai dari PR dokumentasi, lalu developer merefleksikannya ke kode
      Saat review, dokumentasi dan kode ditampilkan berdampingan untuk diverifikasi
      Juga dirancang agar penelusuran konteks dimungkinkan melalui tautan antar dokumen
    • Sudah ada startup serupa seperti Promptless.ai
    • AI juga bisa dihubungkan ke CI untuk secara berkala mendeteksi ketidaksesuaian dokumentasi-kode atau architecture drift
      Contoh: GitHub gh-aw, Continue.dev
    • Tetapi ada juga pertanyaan, “bukankah kita bisa langsung bertanya ke AI apa yang dilakukan kode itu?”

  • Struktur berpasangan antara test code dan production code berguna seperti pembukuan berpasangan dalam akuntansi
    Test menjelaskan niat kode, dan kode melengkapi makna test
    Saat review, jika satu sisi membingungkan, kita bisa melihat sisi lainnya
    Kekurangannya adalah jumlah kode bertambah, tetapi peningkatan keterbacaan sebanding dengan biayanya

  • Saya juga baru-baru ini menulis tentang intent-based coding, dan itu terhubung dengan diskusi ini
    (tautan blog)
    Yang penting adalah bahwa codebase bisa diubah ke berbagai format agar mudah dibaca
    Ke depan, orang non-teknis juga akan semakin dekat dengan kode, dan penyertaan bahasa alami akan sangat membantu produktivitas dan pembelajaran mereka
 
xguru 2026-03-11

Wikipedia - Literate programming
> Pemrograman literer (literate programming) adalah salah satu metodologi pemrograman yang menekankan pembuatan kode yang mudah dipahami manusia, alih-alih sekadar membuat kode yang dapat dikompilasi oleh komputer. Dengan kata lain, tujuannya adalah melakukan pemrograman seolah-olah menulis dokumen agar orang dapat membaca dan memahaminya. Karena sasarannya adalah 'membuat pemrograman dapat dibaca seperti membaca karya sastra', maka metode ini dinamai 'pemrograman literer'.