Cara Merusak Proyek dengan Terlalu Banyak Berpikir, Perluasan Cakupan, dan diff Struktural

 (kevinlynagh.com)
2 poin oleh GN⁺ 1 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Proyek mudah terpecah menjadi alur langsung dibuat sampai selesai dan alur ketika riset serta perancangan membesar hingga masalah awal justru terlewat; untuk kemajuan nyata, sering kali cukup langsung dikerjakan malah lebih unggul
  • Rak dapur selesai dalam satu akhir pekan, tetapi eksplorasi workflow diff struktural serta gagasan bahasa dan CAD yang sudah lama dipikirkan tidak berujung pada hasil yang langsung menyelesaikan motivasi awal, meski sudah melalui banyak riset dan prototipe
  • Saat membuat pencarian fuzzy path untuk Emacs, fitur tambahan dari library yang bagus justru melahirkan kebutuhan baru sehingga desain membengkak; pada akhirnya seluruh kode fitur anchor yang sebenarnya tidak diperlukan dibuang, dan ini kembali menegaskan YAGNI
  • Dalam code diff, perbandingan per baris tidak bisa menangkap struktur tingkat atas seperti fungsi atau tipe dengan baik, dan tool berbasis treesitter pun bisa menjadi sulit dibaca bila pencocokan entitas meleset sehingga penghapusan dan penambahan ditampilkan panjang lebar
  • Arah yang dibutuhkan adalah lebih dulu membuat tool dengan cakupan minimum yang cocok untuk review per giliran output LLM; mulai dari ekstraksi entitas untuk Rust dan pencocokan sederhana, lalu memprioritaskan workflow untuk cepat melihat ringkasan perubahan tingkat tinggi

Terlalu Banyak Berpikir dan Perluasan Cakupan

  • Proyek mudah terpecah menjadi alur langsung dibuat sampai selesai, dan alur ketika orang menggali contoh-contoh terdahulu lalu cakupannya membesar sehingga masalah asli justru tidak terselesaikan
  • Rak dapur yang dibuat pada akhir pekan diselesaikan dengan menentukan desain sambil minum kopi, merevisi hanger hasil cetak 3D beberapa kali, lalu memakai sisa bahan dan cat hingga selesai dalam satu akhir pekan
    • CAD untuk hanger Ikea bin tersedia secara publik di OnShape CAD
    • Bahannya menggunakan kembali sisa dari meja kerja, dan sudut-sudutnya dihaluskan seadanya dengan palm sander
  • Untuk rak ini, ukuran sukses utamanya bukan membuat benda yang benar-benar pas untuk dapur, melainkan menikmati pengerjaan kayu bersama teman, dan karena itu kebutuhan untuk terlalu memikirkan detail jadi berkurang
  • Sebaliknya, dalam proses mencari tool diff struktural, hasil dari difftastic terasa kurang memuaskan sehingga selama 4 jam dilakukan riset atas tool dan workflow terkait, tetapi pada akhirnya kembali ke kriteria awal, yaitu workflow diff yang lebih baik untuk dipakai di Emacs
  • Ketertarikan lama seperti antarmuka prototyping hardware, bahasa yang mencampur Clojure dan Rust, serta bahasa untuk CAD telah menyita ratusan jam untuk riset latar belakang dan prototipe kecil, tetapi sampai sekarang belum menghasilkan keluaran yang langsung menyelesaikan motivasi awal
  • Dalam proyek bahasa dan CAD, kriteria suksesnya kabur, misalnya apakah akan menggantikan Rust atau Clojure, hanya menangani sebagian masalah, cukup sebagai playground pembelajaran, menggantikan CAD komersial, atau harus berguna juga bagi orang lain
  • Menelaah pertanyaan-pertanyaan seperti ini memang bernilai, tetapi dibanding sekadar menelaah banyak hal, membuat lebih banyak hal nyata tampaknya lebih baik
  • Bahkan bila pada akhirnya hasilnya jelas kurang bagus, secara keseluruhan langsung mencoba mengerjakannya tetap membuat kita melangkah lebih maju

Hukum Kekekalan Perluasan Cakupan

  • Waktu untuk sekadar langsung membuat sesuatu juga punya batas dan perlu keseimbangan; pengalaman menulis banyak kode dengan agent LLM lalu akhirnya membuang semuanya kembali mengingatkan pada YAGNI
  • Ada keinginan membuat pencarian fuzzy path seluruh filesystem bergaya Finda untuk dipakai di Emacs, dan karena fitur serupa pernah dibuat sendiri secara manual, tampaknya dengan mengawasi LLM ini bisa selesai dalam beberapa jam
  • Pada awalnya, dalam percakapan perencanaan, Nucleo direkomendasikan; karena desain dan dokumentasinya bagus, library ini diadopsi untuk mendapatkan fitur smart case dan Unicode normalization
    • Sebagai contoh, query foo akan cocok dengan Foo dan foo, tetapi Foo tidak akan cocok dengan foo
    • Penanganan cafe dan café juga dibahas dalam konteks yang sama
  • Masalahnya bukan pada library yang bagus itu sendiri, melainkan pada fakta bahwa Nucleo juga mendukung fitur anchor
  • Karena pada korpus yang hanya berisi path file anchor awal baris tampak tidak berguna, muncul keinginan untuk menafsirkannya sebagai anchor berbasis segmen path
    • Misalnya, ^foo diharapkan cocok dengan /root/foobar/ tetapi tidak cocok dengan /root/barfoo/
  • Agar ini efisien, indeks perlu menyimpan batas antarsegmen dan bisa memeriksa query dengan cepat untuk tiap segmen
  • Ditambah lagi, query anchor yang mengandung slash seperti ^foo/bar juga harus ditangani, dan pemeriksaan per segmen saja jadi sulit untuk mencocokkan path seperti /root/foo/bar/baz/ dengan benar
  • Beberapa jam tambahan dihabiskan untuk desain ini, bertukar ide dengan LLM, dan membuat kode pembungkus untuk tipe Nucleo, tetapi karena kodenya menjadi terlalu besar dan tidak disukai, pada akhirnya pembungkus yang lebih kecil ditulis ulang langsung
  • Setelah beristirahat, tidak ada lagi ingatan kapan fitur anchor pernah benar-benar dibutuhkan di Finda, dan disadari bahwa pada korpus path, menambahkan / di depan atau belakang query sudah bisa menggantikan sebagian besar peran anchor
    • Satu-satunya pengecualian yang tersisa adalah anchor untuk akhir nama file
  • Pada akhirnya semua kode terkait anchor dibuang, dan sulit memastikan apakah hasilnya masih lebih menguntungkan dibanding jika sejak awal langsung ditulis sendiri tanpa diskusi dengan LLM maupun orang lain
  • Makin cepat kecepatan pemrograman, tampaknya ada semacam hukum kekekalan yang membuat fitur tak perlu, rabbit hole, dan jalan memutar ikut bertambah juga

diff Struktural

  • Dalam kode, diff biasanya berarti ringkasan perubahan per baris antara dua versi file, dan dalam unified view penambahan serta penghapusan ditandai dengan + dan -
  • Diff yang sama juga bisa dirender dalam bentuk perbandingan kiri-kanan, dan ketika perubahannya kompleks bentuk seperti ini bisa lebih mudah dibaca
  • Masalah diff per baris adalah ia tidak mengenali struktur tingkat atas seperti fungsi atau tipe; jika kurung kurawalnya kebetulan selaras, penanda bisa dihilangkan meski sebenarnya potongan itu milik fungsi yang berbeda
  • difftastic mencoba mengurangi masalah ini dengan memanfaatkan concrete syntax tree dari treesitter, tetapi pencocokan entitas antarversi tidak selalu berhasil dengan baik
  • Pada diff yang menjadi pemicu langsung, struct PendingClick tidak dipasangkan sebagai entitas yang sama di kedua sisi, sehingga di kiri ditampilkan sebagai dihapus dan di kanan sebagai ditambahkan
  • Tidak ditelusuri kenapa pencocokannya gagal, tetapi dinilai lebih baik bila PendingClickRequest dan PendingClick tetap dipandang saling berpasangan di kedua sisi, meski seluruh diff menjadi lebih panjang

Tool diff Struktural dan Referensi

  • Tool semantic diff yang dianggap paling matang dan paling hati-hati dipoles adalah semanticdiff.com
    • Tool ini disediakan oleh perusahaan kecil di Jerman, dengan plugin VSCode gratis dan web app untuk menampilkan diff PR GitHub
    • Namun, tool ini tidak menyediakan library kode yang bisa dijadikan dasar workflow yang diinginkan
    • Tulisan semanticdiff vs. difftastic berisi banyak detail yang berguna, termasuk masalah bahwa difftastic bahkan gagal menampilkan perubahan indentasi yang bermakna di Python
    • Salah satu penulisnya menyebut dalam komentar HN bahwa mereka sempat memakai treesitter untuk pemrosesan semantik lalu meninggalkannya; parsing bisa gagal karena keyword yang bergantung konteks dan perilaku lexer, sehingga tool bahkan bisa macet ketika nama seperti async dipakai sebagai parameter
  • diffsitter berbasis treesitter dan menyertakan MCP server
    • Jumlah star GitHub-nya banyak, tetapi dokumentasinya tidak tampak terlalu baik, dan sulit menemukan materi yang menjelaskan cara kerjanya
    • Di wiki difftastic tertulis bahwa ia menjalankan longest-common-subsequence pada leaf dari tree
  • gumtree adalah tool yang lahir dari riset dan latar akademik tahun 2014
    • Karena memerlukan Java, tool ini tidak cocok untuk kebutuhan pribadi sebagai alat yang cepat dipakai dari Emacs
  • mergiraf adalah merge-driver berbasis treesitter yang ditulis dalam Rust
    • architecture overview-nya tersusun rapi, dan secara internal menggunakan algoritme Gumtree
    • Dari dokumentasi dan gambarnya, proyek ini memberi kesan disusun dengan sangat teliti
    • Penulis semanticdiff.com menulis dalam komentar HN bahwa GumTree memang cepat menghasilkan keluaran, tetapi bahkan setelah menerapkan berbagai perbaikan dari paper lanjutan, masih cukup sering mengembalikan pencocokan yang buruk; pada akhirnya mereka beralih ke pendekatan berbasis dijkstra untuk meminimalkan biaya pemetaan
  • weave adalah merge-driver berbasis treesitter lain yang ditulis dalam Rust
    • Landing page yang mencolok, banyak GitHub star, dan MCP server membuat kesan keseluruhannya tampak agak berlebihan
    • Crate ekstraksi entitas sem ikut ditinjau
    • Kode diff intinya cukup baik tetapi agak bertele-tele, dan pencocokan entitas menggunakan algoritme greedy
    • Model datanya tidak dapat mendeteksi perpindahan di dalam file, padahal perpindahan seperti itu bisa bermakna besar
    • Di dalamnya juga banyak analisis impact berbasis heuristic yang tampaknya memerlukan integrasi bahasa yang lebih kuat agar bisa dipercaya
      • Saat menjalankan sem diff --verbose HEAD~4, juga ditemui keluaran bug yang menandai baris yang sebenarnya tidak berubah seolah-olah berubah
    • Terlalu banyak fitur hipotetis yang tampaknya baru sekitar 80% jadi sehingga kurang cocok dijadikan fondasi, tetapi tetap patut diapresiasi bahwa tingkat seperti ini dicapai hanya dalam 3 bulan
  • diffast menghitung tree edit-distance pada AST berdasarkan algoritme dari paper akademik tahun 2008
    • Tool ini mendukung Python, Java, Verilog, Fortran, dan C/C++ melalui parser khusus
    • example AST differences gallery tersusun dengan baik
    • Informasi dapat diekspor dalam bentuk tuple untuk digunakan di datalog
  • autochrome adalah tool diff khusus Clojure yang memakai dynamic programming
    • Penjelasan visual dan walkthrough contohnya sangat baik
  • Tulisan Tristan Hume, Designing a Tree Diff Algorithm Using Dynamic Programming and A*, sangat layak dijadikan referensi untuk perancangan algoritme tree diff

Workflow yang Diinginkan dan Rencana Cakupan Minimum

  • Use case utamanya adalah review per giliran atas output LLM, dan agent tidak dibiarkan menghasilkan lebih dari 10 ribu baris kode sekaligus tanpa kendali
  • Kepada agent diberikan tugas dengan ruang lingkup jelas, lalu beberapa menit kemudian kembali untuk melihat gambaran umum perubahan, setelah itu ingin bisa mengedit langsung di Emacs, membuang semuanya dan mencoba lagi, atau menulis ulang sendiri dari nol
  • Workflow yang diinginkan adalah lebih dulu melihat ringkasan tingkat tinggi tentang tipe, fungsi, dan metode apa yang ditambahkan, dihapus, atau diubah
  • Di atas itu, text diff untuk tiap entitas harus bisa dibuka dengan cepat, sehingga ringkasan dapat meluas secara alami menjadi diff yang rinci
  • Selain itu, perubahan harus bisa diedit langsung tanpa berpindah ke lokasi lain, dan diinginkan inline editing tanpa harus berpindah dari layar diff ke layar file
  • Arah yang dituju adalah memindahkan workflow review perubahan dan staging dari Magit dari unit file dan baris ke unit entitas
  • Sesuai pelajaran terbaru tentang cakupan minimum yang kembali diingat, rencananya adalah terlebih dahulu membuat sendiri secara cepat framework ekstraksi entitas berbasis treesitter yang hanya menargetkan Rust
  • Untuk tahap awal, pencocokan akan dimulai dengan cara greedy yang sederhana, dan diff akan dirender ke command line
  • Jika tingkat ini sudah menghasilkan keluaran yang lebih baik daripada difftastic pada commit tertentu, langkah berikutnya adalah menghubungkannya ke workflow Emacs yang lebih interaktif seperti Magit
    • Kalau memungkinkan, opsi untuk memanfaatkan kembali Magit itu sendiri juga tetap terbuka
    • Dukungan bahasa baru akan ditambahkan hanya saat benar-benar diperlukan
    • Setelah itu, selain greedy sederhana, bisa juga dieksplorasi pencocokan global berbasis skor
  • Jika hasilnya cukup memuaskan, tool ini mungkin akan dipublikasikan, tetapi tujuan utamanya bukan mengumpulkan GitHub star atau karma HN; bisa saja tetap menjadi tool pribadi yang dipakai diam-diam
  • Kalimat penutupnya kembali menegaskan sikap membuat hanya yang dibutuhkan alih-alih memperluas berlebihan: kadang yang dibutuhkan memang cuma sebuah rak

Bacaan terkait

1 komentar

 
GN⁺ 1 hari lalu
Komentar Hacker News

  • Menurutku ini menunjukkan dengan sangat baik kesulitan terbesar dalam riset PhD
    Saat memilih topik yang menarik lalu membaca sebanyak mungkin riset terdahulu yang relevan, kita jadi sadar betapa banyak hal yang mirip dengan yang ingin kita lakukan ternyata sudah pernah dikerjakan, dan di situlah scope creep mudah menjadi parah
    Setelah energi dan antusiasme awal habis, yang tersisa adalah memaksa 20–30% terakhir sampai cukup layak untuk dipublikasikan

    • Di hari ke-1, dimulai dengan ide menerapkan katalis industri yang sudah ada ke penggunaan baru untuk menurunkan biaya produksi prekursor obat esensial
      Di hari ke-400, setelah nyaris menjelaskan teori segalanya, malah mencoba membuat perangkat eksperimen orbit titik Lagrange untuk mendeteksi partikel universal yang memediasi semua gaya di alam semesta yang diketahui
    • Rasanya sangat nyata dan mengena
      Aku penasaran bagaimana cara mengurangi hal ini
    • Menurutku alasan kebanyakan program doktoral mengalami ini adalah karena tujuan PhD pada akhirnya adalah membuktikan bahwa seseorang mampu melakukan normal science
      Pada praktiknya, ini sering cuma pekerjaan seperti meningkatkan observabilitas suatu sistem dari 1% menjadi 1,001%, dan lebih mirip gerbang masuk untuk karier akademik
      Karena itu, aku hampir tidak pernah melihat disertasi yang benar-benar menarik, sangat baru, atau langsung bisa diterapkan pada sains
    • Dan di atas semua itu, kita juga harus bertahan sambil makin dibebani penyesalan karena sejak awal memulai PhD
    • Memulai dengan membaca sebanyak mungkin seluruh riset terdahulu jelas terasa seperti pendekatan yang keliru
      Aku hampir tidak pernah melihat orang benar-benar meneliti dengan cara itu; biasanya lebih masuk akal membaca dua atau tiga paper lalu membangun dari sana
      Menyelami literatur riset secara mendalam lebih baik dilakukan setelah sudah ada hasil, saat mulai menuliskannya

  • Aku terus teringat ungkapan bahwa lebih baik itu sudah cukup
    Perbaikan kecil akan terakumulasi seiring waktu, dan tidak ada sesuatu yang sepenuhnya baru atau sempurna sejak awal, jadi duduk diam berusaha merancang sesuatu yang sempurna justru sering menjadi bumerang
    Ungkapan bahwa rintangan adalah jalan juga sangat cocok di sini

    • Kalimat jangan biarkan kesempurnaan menjadi musuh dari yang cukup baik benar-benar pas
      Rekan kerjaku dulu, saat mengkritik perubahan kode, kalau merasa dia sedang terlalu mempermasalahkan hal kecil, dia akan berkata, "Ini lebih baik dari sebelumnya"
      Dengan begitu dia tetap menunjukkan hal yang bisa diperbaiki, sambil juga memberi izin untuk tetap lanjut meski masih ada cacat kecil, dan aku sangat mendukung sikap seperti ini
    • Ini pada akhirnya adalah perfeksionisme
      Dulu aku mengira perfeksionisme cuma berarti memaksakan diri mengejar pencapaian yang terlalu tinggi, tapi bisa juga berarti tidak mampu menerima apa pun selain yang sempurna lalu menyerah tanpa kemajuan
      Prokrastinasi pada pekerjaan besar juga sering berasal dari akar yang sama

  • Aku suka dengan yang dikatakan CEO Rec Room
    Tim hampir selalu berharap proyek dikerjakan lebih singkat; jarang sekali ada yang bilang seharusnya rilisnya lebih ditunda, dibuat lebih rumit, dan dipoles lebih jauh
    Ini memang tidak 100% cocok untuk semua situasi, tetapi kalau harus membuat kesalahan, menurutku lebih baik membuat sesuatu yang kecil lalu merilisnya lebih awal daripada terlalu membesar-besarkan dan membuang waktu

  • Manusia pada dasarnya mudah memikirkan ide yang mirip, jadi kalau kita menyelesaikan proyek tanpa tahu apa yang sudah ada, hasilnya sering akan menjadi semacam penemuan ulang sampai taraf tertentu
    Sebaliknya, kalau meneliti lebih dulu, kita bisa sadar bahwa sebagian dari itu hanya pengulangan dari sesuatu yang sudah ada dan jadi kehilangan semangat
    Meski begitu, mungkin yang paling penting tetaplah membuatnya sampai selesai demi pembelajaran diri sendiri
    Tentu lebih sulit jika kita harus menghasilkan kontribusi akademik baru atau mencari untung dari proyek yang benar-benar unik, tapi bahkan di ranah seperti itu pun ternyata orang sering cukup toleran selama ada sedikit sentuhan baru pada hal yang sudah ada

  • Aku sedang mengalami situasi seperti ini persis di side project sekarang
    Bidangnya Information Retrieval, jadi pengalamanku masih sedikit dan jelas ada banyak prior art yang bisa dipelajari atau diintegrasikan
    Setelah membaca tulisan ini, aku jadi lebih condong untuk membuat versiku sendiri dulu, lalu hanya melihat contoh terdahulu saat mentok atau butuh ide
    Di sisi lain, dari dokumenter Clojure yang baru keluar, Rich Hickey justru tampak menghabiskan waktu lama mendalami prior art, paper, dan bahasa lain sebelum mulai bekerja
    Tapi dia juga sudah pernah membuat bahasa lain sebelumnya, jadi gambaran besarnya tetap berawal dari belajar dengan cara membuat sendiri
    Mungkin memang jangan terlalu lama hanya berpikir; buat saja dulu, kumpulkan pelajaran dari praktik nyata, tabrak temboknya, lalu lakukan riset yang lebih dalam saat memang mulai diperlukan

  • Menetapkan deadline menyelesaikan sebagian besar masalah scope creep bagiku
    Rasanya proyek dengan tenggat keras seperti game jam atau lomba pemrograman jauh lebih mudah diselesaikan, sedangkan proyek dengan akhir yang terbuka jauh lebih sulit dituntaskan
    Ini terasa mirip dengan alasan standar C++ dirilis tiap 3 tahun alih-alih menunggu sampai semua fitur yang diinginkan benar-benar siap
    https://news.ycombinator.com/item?id=20428703

  • Tulisannya memang menarik, tetapi menurutku pikiran penulis terlihat agak tersebar dan tidak fokus

    • Menurutku inti masalahnya di sini tetap scope creep
    • Ini bukan tulisan blog yang mengupas satu topik tertentu secara tajam, melainkan lebih seperti update newsletter untuk para pembaca yang mengikuti orang ini

  • Untuk seseorang yang bilang kewalahan oleh scope creep, dia justru tampak sangat produktif, sampai di akhir tulisan ada banyak sekali tautan ke berbagai topik
    Pada akhirnya dia tampak seperti tipe orang yang benar-benar suka belajar dan mencoba macam-macam, dan proses masuk ke rabbit hole itu sendiri terasa menstimulasi pikirannya dengan menyenangkan

  • Sebagai orang yang membangun sesuatu sendirian, ada satu kesadaran yang sangat membantuku
    Kebanyakan hal yang terlihat seperti abstraksi yang wajib ternyata hanyalah scope creep dengan nama lain
    Aku terus menambahkan flag untuk setiap fitur baru, lalu melihat pola di kodenya dan membuat satu aturan
    Fitur tidak boleh dirilis jika tidak ada tes untuk perilaku saat flag-off
    Setelah itu, aku mulai melihat flag bukan sebagai jalan keluar, melainkan sebagai bagian dari produk, dan tiga fitur yang ada di backlog menghilang begitu saja setelah kupikirkan dengan cara itu

  • Memang benar bahwa perencanaan berlebihan dan scope creep bisa jadi masalah, tetapi sebaliknya kita juga harus berhati-hati agar tidak terlalu bergeser ke arah pengembangan serba spontan
    Beberapa proyek paling sukses yang pernah kukerjakan justru melibatkan perencanaan dan peninjauan lebih dulu terhadap sebagian besar fiturnya sambil memodelkan data, sebelum benar-benar membuat perangkat lunak yang berjalan
    Pada tahap itu sering sulit tahu apa yang berlebihan, dan jika aku menghilangkan fitur yang tampaknya akan dibutuhkan olehku atau pengguna, nanti aku bisa menghabiskan banyak waktu untuk mendesain ulang inti kode secara besar-besaran
    Sebaliknya, kalau tebakan awalnya meleset, proyeknya malah membesar dan kemudian kita menyebutnya scope creep
    Pada akhirnya, keputusan ini bergantung pada seberapa baik kita memahami domainnya
    Kalau ternyata kita kurang memahami domain dibanding perkiraan, akan banyak pengerjaan ulang; kalau ternyata kita lebih paham dari yang kita kira, mungkin sebenarnya kita bisa melangkah lebih besar tetapi malah membuang waktu dengan baby step
    Ke arah mana pun, penyesalan tetap ada, jadi pada akhirnya ini terasa seperti masalah penilaian yang besar

    • Menurutku cara idealnya adalah meluangkan cukup waktu pada tahap analisis untuk mengisi konteks yang tepat di kepala, tetapi saat mulai membangun, siap membuang solusi yang terlalu didesain dan langsung mengerjakan hal yang terasa paling tepat
      Kita tidak boleh terjebak dalam sunk cost fallacy, dan hanya karena sudah menghabiskan beberapa jam meneliti topik setingkat PhD bukan berarti itu wajib dipakai di proyek
      Kalau tidak benar-benar cocok untuk masalah saat ini, lebih baik buang saja dengan tegas
    • Jangan terlalu takut salah; coba dulu saja, lalu sesuaikan bila perlu