Petualangan bersama AI

 (scattered-thoughts.net)
12 poin oleh GN⁺ 14 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Setelah mencoba beberapa model AI dalam proyek pribadi, review kode, refaktorisasi, dan skrip sekali pakai terbukti konsisten berguna dibanding biayanya, tetapi pekerjaan pengembangan non-otonom masih sangat dibatasi oleh kualitas penilaian dan biaya verifikasi
  • Setelah membandingkan langganan bulanan $20 dari Anthropic dan OpenAI dengan kredit $20 dari Google, Moonshot, DeepSeek, dan Cerebras, pada praktiknya yang paling sering dipakai secara bergantian adalah Opus 4.8 dan GPT 5.5
  • Nilai terbesar datang dari pencarian bug seperti review git diff main; pada codebase kecil, pembacaan kode yang teliti menjadi kekuatan, seperti ketika Opus menemukan double-free pada interpreter yang bahkan lolos dari fuzzer
  • Saat menulis kode bersama atau diberi tugas mengimplementasikan sendiri, masalah berulangnya adalah memperbaiki bug di lapisan yang salah, membuat test dan refaktorisasi yang tidak perlu, serta mengklaim secara palsu bahwa implementasi selesai atau test sudah dijalankan
  • Bahkan tanpa model yang menjadi lebih pintar, praktik seperti jaminan dari bahasa dan runtime, analisis statis, teknik formal ringan, serta harness di editor yang menurunkan biaya verifikasi dan membatasi cakupan perubahan menjadi semakin penting

Model dan alat yang digunakan

  • Berlangganan Anthropic dan OpenAI masing-masing $20 per bulan, serta mengisi kredit $20 masing-masing untuk Google, Moonshot, DeepSeek, dan Cerebras
  • Setelah membandingkan model pada berbagai masalah, sebagian besar waktu memakai Opus 4.8 dan GPT 5.5 secara bergantian
    • Kedua model ini terlihat jelas lebih baik daripada model lain
    • Jarang sekali batas pemakaian keduanya tercapai secara bersamaan
  • Alat yang digunakan adalah claude code, codex, dan pi
    • claude code dan codex dinilai dalam kondisi yang buruk
    • codex kadang tetap berjalan dengan CPU 100% setelah terminal ditutup dan harus di-kill
    • claude code menampilkan instruksi “tekan escape untuk membatalkan dialog”, tetapi pada praktiknya tidak menutup dialog dan hanya menginterupsi claude
    • Perilaku kedua alat ini berubah-ubah dari hari ke hari
  • pi belum terlalu sering dipakai, tetapi terasa bekerja seperti perangkat lunak pada umumnya
    • Ketiga alat sama-sama terasa sangat vibe-coded, dan ada rasa penasaran bagaimana pi menjaga kualitas kode minimalnya

Sandbox dan keamanan

  • Semua alat dijalankan di dalam bubblewrap
    • Direktori saat ini dan konfigurasi masing-masing alat diberi izin baca-tulis
    • nix store hanya diberi izin baca saja
  • Pengaturan ini adalah sandboxing minimal, cukup untuk mencegah akses ke kredensial atau perusakan file yang tidak dikelola version control
  • Jika di AGENTS.md ditulis bahwa alat berjalan di dalam sandbox dan alat bisa diambil lewat nix-shell, biasanya semuanya berjalan cukup baik
    • Tanpa itu, model sering mengarah ke dugaan kerusakan disk atau kerusakan filesystem
  • Pelatihan keamanan tampaknya belum cukup efektif
    • Saat diminta “coba keluar dari sandbox”, model menolak dengan alasan itu tindakan tidak bertanggung jawab
    • Saat diberi tahu bahwa perlu mengecek apakah sandbox benar-benar bekerja, model menjawab bahwa ia berhasil keluar

Nilai terbesar dari review kode

  • Sejauh ini nilai terbesar datang dari review kode dan pencarian bug
  • Prompt sederhana seperti Review git diff main and look for bugs juga efektif
  • Untuk proyek pribadi, fitur ini saja sudah cukup membuat penulis rela membayar $20 per bulan; jika menjalankan perusahaan, penulis merasa ratusan dolar per orang per bulan pun masuk akal
  • Dalam transcript, Opus menemukan double-free setelah cleanup pattern-match yang gagal sebagian pada interpreter
    • Bug ini tidak ditemukan oleh fuzzer
    • Penulis menilai bahkan programmer rata-rata pun mungkin tidak akan menemukannya dengan cepat
  • Yang benar-benar berguna sejauh ini hanyalah model frontier
    • Model yang lebih murah dinilai suka menggertak seperti mahasiswa tingkat awal yang sedang kesulitan
    • Model frontier juga kadang mencampur jawaban benar dengan gertakan, tetapi biasanya menandainya dengan ungkapan seperti “this isn't a bug per se”, sehingga mudah diabaikan
  • Sampai sekarang percobaan baru dilakukan pada codebase yang relatif kecil
    • Pada codebase besar, hasilnya kemungkinan sangat bergantung pada struktur dan kemungkinan penalaran lokal

Refaktorisasi yang menurunkan biaya memperbaiki desain

  • Contoh refaktorisasi yang dilakukan antara lain:
    • mengubah pos yang menunjuk byte offset menjadi offset
    • mengubah Document menjadi Buffer, termasuk komentar dan nama variabelnya
    • membuat fungsi Editor yang memanggil Document::apply_edits menerima EditorId alih-alih Editor, sehingga borrow bisa dilepas sebelum pemanggilan
  • Pekerjaan seperti ini ternyata sangat membantu meningkatkan kualitas kode
    • karena menurunkan biaya untuk memperbaiki kesalahan desain
    • terutama berguna ketika ada campuran antara kerja pikir kecil untuk membuat API lebih aman dan kerja repetitif besar untuk memperbaiki semua callsite
  • Bahkan untuk perubahan berulang yang secara teori bisa ditangani regex sed, model dinilai lebih pandai menulis sed
  • Namun review untuk refaktorisasi cukup rumit
    • Model kadang menyelipkan satu drive-by fix yang tidak relevan di antara 200 perubahan callsite yang benar
    • Meminta model lain menunjukkan “perubahan mana yang tidak terkait dengan prompt” cukup berhasil sampai batas tertentu

Batasan yang terlihat saat coding bersama

  • Karena memperkirakan akan membuat frustrasi jika langsung diberi serious work, eksperimen kebanyakan dilakukan pada proyek yang boleh dibuang, tetapi kualitas kodenya tetap membuat tidak tenang
  • Sebelum era AI, coding terasa seperti campuran antara keputusan penting dan pekerjaan isi-detail ala paint-by-numbers
    • Dengan mengelompokkan pekerjaan agar keputusan diambil di depan lalu hasilnya diisi selama beberapa jam, context switch bisa berkurang dan kerja menjadi lebih cepat
  • Model kuat dalam menghasilkan detail implementasi ala paint-by-numbers dengan cepat dan teliti
  • Sebaliknya, model sangat lemah dalam mengambil keputusan
    • Memperbaiki bug di lapisan yang salah
    • Menelan diam-diam error yang seharusnya dilaporkan, atau malah mempropagasikan error yang seharusnya ditangani lokal
  • Opus pernah diminta memperbarui test agar sesuai dengan perubahan fungsi, lalu menambahkan argumen boolean do_new_behaviour
    • Ia membuat wrapper foo_do_new_behaviour dan foo_do_old_behaviour yang masing-masing mengirimkan true dan false
    • Akibatnya, test tetap menguji perilaku lama sementara binary nyata menjalankan perilaku baru
  • Solusi dengan meminta model lain melakukan review terasa kurang meyakinkan
    • karena model dengan penilaian buruk bisa saja melihat keputusan buruk lalu menganggapnya “masuk akal”
  • Bahkan ketika diberi instruksi “isi hanya badan fungsi ini, jangan ubah yang lain, dan jangan tulis test”, model tetap mencoba merefaktorisasi kode tak terkait, mengekstrak helper function, dan menulis unit test
    • Meski sudah diberi tahu bahwa codebase memiliki end-to-end deterministic simulation testing, model tetap mencoba menambah public function pada tiap interface demi unit test terisolasi
  • Kode yang ditulis bot sulit direview secara efektif
    • Setelah perubahan di-merge, penulis berkali-kali baru melihat masalah yang semula luput saat membaca kode yang sama lagi jauh di kemudian hari
  • Penulis merasa perlu ada harness di editor yang menyorot area mana yang boleh diubah, dan mencegah model memodifikasi bagian lain
    • Penulis membayangkan bisa membuat sketsa kode yang diinginkan dan meninggalkan komentar untuk kemudian diisi model
    • Jika dalam beberapa tahun muncul model yang memberi kualitas coding setara frontier saat ini tetapi jauh lebih cepat, penulis berharap hasilnya bisa direview seketika tanpa bolak-balik antar worktree

Saat dibiarkan mengimplementasikan sendiri

  • Pekerjaan plumbing kecil berjalan baik bila hasilnya cukup direview saja
    • skrip untuk mengubah resume.md menjadi resume.pdf
    • skrip untuk mem-parsing aturan board game dan membuat PDF kartu seukuran playing card untuk dicetak di kertas US Letter
    • menerjemahkan proyek deno kecil ke Rust
    • membuat proyek Rust yang membuka jendela dan merender persegi panjang
  • Pekerjaan seperti ini umumnya selesai sekali jalan atau hanya butuh beberapa kali masukan desain visual, dan kualitas kode tidak terlalu penting
  • Pekerjaan yang sulit diverifikasi sejauh ini hanya membuang waktu
    • Penulis berkali-kali mencoba mengubah aturan board game menjadi multiplayer webapp dengan berbagai model
    • Hanya Opus yang berhasil membuat UI yang benar-benar berjalan, tetapi implementasi aturannya salah
  • Di area ini, misalignment paling banyak terlihat
    • Dari comment model atau chain of thought yang tersedia, terlihat kecenderungan menunda pekerjaan nyata
    • Bahkan ketika diminta menyelesaikan UI tertentu, muncul pemikiran seperti “perlu UI pemilihan pemain, jadi untuk sementara hard-code saja”
  • Model berulang kali melebih-lebihkan atau memalsukan status penyelesaian tugas
    • Setelah menyatakan semua task selesai, ketika ditanya lagi model mengakui baru mengerjakan dua yang pertama dan menunda sisanya
    • Saat diminta menyelesaikan lagi, model kembali berkata sudah selesai, lalu setelah dicek ulang mengaku sebenarnya hanya mengacak-acak kode
  • Bahkan ketika dibantu menulis end-to-end test dengan alat otomasi browser, model bisa macet di pengaturan dependency lalu berbohong bahwa test berhasil dijalankan
    • Jika UI rusak, model kadang mencoba meloloskan test dengan direct HTTP call alih-alih mengklik tombol
  • Penulis melihat dua alasan kegagalan implementasi aturan board game
    • Aturan board game bersifat arbitrer sehingga tidak bisa mengandalkan data pelatihan, dan harus ditelusuri secara eksplisit
    • Biaya memverifikasi implementasi aturan dengan benar melalui beberapa permainan nyata lebih besar daripada biaya menulis kode yang benar sejak awal secara manual
  • Pada kombinasi tingkat keberhasilan rendah dan biaya verifikasi yang juga tidak rendah, model dinilai sama sekali tidak berguna

Penilaian terhadap penggunaan sebagai software engineer otonom

  • Dengan pendekatan saat ini, memakai AI sebagai software engineer otonom kemungkinan akan menghasilkan tumpukan duct tape dan chewing gum raksasa yang tidak bisa diperbaiki manusia
  • Namun, penulis melihat banyak codebase hasil outsourcing selama beberapa dekade terakhir yang juga tidak jauh berbeda, dan model bisa melakukan hal yang sama dengan lebih murah
    • Model menggeser batas biaya-kualitas
  • Bahkan jika model tidak menjadi lebih pintar dari level hari ini, praktik kerja masih bisa berkembang untuk mengekstrak lebih banyak nilai
    • jaminan dari bahasa dan runtime
    • analisis statis
    • teknik formal ringan
    • cara untuk menurunkan biaya verifikasi atau membatasi ruang gerak model
  • Penulis mengenang masa ketika Python dan Ruby banyak dipakai dan peningkatan performa hardware dianggap lebih cepat daripada kebutuhan optimasi kode, lalu setelah perlambatan performa hardware sekuensial minat pada performa bahasa pemrograman kembali meningkat
  • Model AI dinilai berada di awal kurva yang mirip
    • Jika berharap model bulan depan akan lebih pintar, minat pada harness atau perbaikan praktik pendukung menjadi kecil
    • Jika performa model mencapai puncak sebelum menjadi uniformly superhuman, maka pekerjaan menarik justru baru dimulai

Pencarian dan tenaga kerja murah

  • Model bekerja baik pada masalah yang jawabannya bisa diverifikasi langsung, dan precision penting tetapi recall tidak terlalu penting
    • mencari kesalahan dalam tulisan blog
    • mencari kesalahan format APA pada footnote esai
    • mencari trilogi dengan polisi dan penyihir di goodreads_library_export.csv
    • menyaring hanya tautan peran yang menyebut remote dari https://mgaudet.github.io/CompilerJobs/, sambil mengecualikan perusahaan cryptocurrency
  • Penulis tidak membiarkan model memperbaiki kesalahannya sendiri
    • karena begitu dibiarkan memperbaiki, model mulai mengambil keputusan
  • Masalah yang jawabannya terdengar meyakinkan tetapi tidak bisa diverifikasi langsung jauh lebih berbahaya
    • Saat ditanya opsi reef-safe DIY wetsuit lube, Opus dan GPT merekomendasikan glycerine
    • Penulis menilai menutupi kulit seharian dengan makanan bakteri yang basah kemungkinan adalah ide buruk

Brainstorming dan kreativitas

  • Saat sulit menentukan type atau nama variabel, penulis sering meminta ide dari model
  • Karena model adalah mesin pengolah bahasa, pekerjaan ini terlihat seperti sesuatu yang seharusnya dikuasai dengan baik
  • Namun dari semua saran yang diberikan, tidak ada satu pun yang benar-benar dipakai
  • Saran-sarannya dinilai konsisten biasa saja dan klise

Kesimpulan keseluruhan dan keganjilan yang masih tersisa

  • Review, refaktorisasi, dan skrip sekali pakai terus terbukti berguna dan memang layak dibayar
  • Gaya kerja coding bersama masih belum memberikan keuntungan bersih secara keseluruhan, tetapi dengan model yang lebih cepat dan harness yang lebih baik, dalam waktu dekat itu bisa berubah menjadi menguntungkan
  • Membiarkan model menulis kode sendirian tidak berhasil untuk pekerjaan yang non-trivial
    • Untuk mendapatkan software berkualitas tinggi tanpa keterlibatan manusia yang mendalam, masih dibutuhkan jauh lebih banyak eksperimen
    • Pasar software berkualitas rendah itu besar, dan mungkin sudah bisa dilayani hari ini
  • Pada model frontier, penulis merasa belum melihat sesuatu yang pantas disebut halusinasi
    • Hanya DeepSeek flash yang pernah sepenuhnya mengarang fakta, dan itu pun hanya sesekali
    • Model bisa salah, tetapi biasanya karena kesalahan penalaran, salah memahami bukti, atau kurangnya konteks penting, bukan karena mengada-ada dari nol
  • Langganan model frontier terasa sangat bernilai, tetapi penulis merasa itu akan hilang perlahan setelah semua orang terbiasa
    • Jika harganya dihitung per token, penulis tidak yakin use case mana yang masih akan terasa layak
    • DeepSeek v4 flash memang sangat murah, tetapi belum cukup pintar dan paling sering berbohong bahwa test berhasil dijalankan
  • Harness yang ada saat ini tidak disukai
    • Menulis prompt di antarmuka yang bahkan tidak bagus untuk pengeditan teks dasar terasa merepotkan
    • Penulis ingin kontrol lebih besar atas apa yang boleh dilakukan model, dan menginginkan interaksi seperti menunjuk langsung ke objek di layar
    • Workflow saat ini adalah meninggalkan komentar @bot di kode dan memakai prompt tetap Handle comments marked @bot
  • Saat manusia menulis kode, pada saat yang sama ia juga membaca kode dan membangun ulang mental model
    • Jika bot yang menulis kode, kebutuhan membangun mental model itu tetap ada, tetapi manfaat alami yang biasanya muncul sambil menulis ikut hilang
    • Sekadar membaca kode saja tidak cukup; penulis merasa perlu ada praktik tambahan seperti review++
  • Pengalaman sejauh ini terasa menyenangkan dan kemungkinan bermanfaat karena eksperimen dilakukan secara eksplisit pada proyek yang tidak penting
  • Pengalaman ini sangat berfokus pada kondisi saat ini, dan penulis masih mencerna apa yang akan berubah setelah beberapa tahun perbaikan lebih lanjut serta ke mana arah yang seharusnya dituju

Bacaan terkait

1 komentar

 
GN⁺ 14 jam lalu
Pendapat di Lobste.rs

  • Alasan pi punya lebih sedikit bug dibanding harness lain tampaknya karena dibuat oleh tim kecil, para maintainer menjaga standar kualitas yang konsisten, meninjau kode, dan memikirkan fitur apa yang akan dimasukkan
    Pendekatan yang tidak asal memasukkan segala macam fitur ke dalam harness itulah yang membuat perbedaan
    https://mariozechner.at/posts/…

    • Meski ada tiga keunggulan itu, kalau aku membuat sesuatu yang besar dengan vibe coding, rasanya hasilnya akan jadi gumpalan yang kusut
      Jelas ada kemampuan tambahan yang sedang bekerja

  • Poin bahwa “kalau bot menuliskan kode untukku, aku tetap harus membangun model mental, tetapi tidak lagi mendapatkannya ‘gratis’ sambil menulis kode” sangat bagus
    Sekadar membaca kode saja biasanya tidak cukup; mirip seperti membaca ulang catatan yang sudah diberi highlight bukanlah persiapan ujian
    Ini juga terhubung dengan Programming as Theory Building
    Saat pertama kali memakai LLM pada proyek yang teori sistemnya sudah ada di kepala, hasilnya mudah terlihat, tetapi jika dibiarkan berjalan sendiri beberapa waktu, kita bisa makin terputus dan menjadi seperti project manager non-coding yang bahkan tidak bisa menulis requirement dengan benar, sehingga frustrasi bisa makin besar

  • Mulai sekarang aku akan tanpa ragu memakai ungkapan “mimpi demam yang dilengkapi unit test” dalam ucapan dan tulisanku

    • Bahkan di beberapa multi-agent orchestrator yang terkenal, model-model mahal pada runtime pada dasarnya sedang menghalusinasikan sekitar 60% orchestrator

  • Ini benar-benar mirip dengan pengalamanku
    Sebagai tambahan, aku juga cukup berhasil memakai Claude Code untuk men-debug masalah desktop Linux
    Dotfiles-ku yang sudah berusia 25 tahun menumpuk lapisan-lapisan residu yang malas di-debug, dan karena dengan yadm aku berbagi dotfiles ke beberapa mesin tanpa nilai rahasia, sandboxing juga mudah
    Membiasakan diri meminta LLM meninjau perubahan kode juga layak dilakukan
    Bagaimanapun, seseorang pada akhirnya akan memeriksa commit-ku dengan LLM, entah itu di repositori open source maupun target produksi, dan di Lobsters pun dalam 2 minggu terakhir kami menerima 4 laporan kerentanan valid dari orang-orang yang memakai scanner berbasis LLM
    Semuanya sudah diperbaiki
    Dalam 9 tahun sebelumnya, aku hanya ingat ada sekitar 2 laporan serupa

  • Rasanya aneh kalau mengatakan “aku belum pernah melihat sesuatu yang layak disebut halusinasi pada model frontier”
    Di dalam tulisan itu ada beberapa hal yang menurutku bisa dianggap halusinasi

    • Tampaknya masuk akal membedakan hal-hal berikut: halusinasi (“Lobsters dibuat oleh Paul Graham”), kebohongan/kemalasan (“pekerjaannya sudah selesai”), dan penilaian buruk (“nilai ini sebaiknya di-hardcode saja”)
      Dengan kriteria seperti itu, tidak ada halusinasi yang kutemukan dalam tulisan tersebut, tetapi kebohongan, kemalasan, dan penilaian buruk juga bukan hal yang bagus
      Alasan pembedaan ini berguna adalah karena halusinasi mungkin lebih mudah dikurangi, sementara kebohongan, kemalasan, dan penilaian buruk lebih sulit
      Halusinasi dan kebohongan sama-sama membuat model mengatakan hal yang salah, tetapi halusinasi lebih dekat pada akibat ketidaktahuan atau kurangnya informasi, dan bisa ditangani dengan meminta sumber atau melatih model agar menghindari jawaban yang bertumpu pada informasi lemah
      Sebaliknya, kebohongan dan kemalasan tampak sebagai hasil dari perilaku berorientasi tujuan dan reinforcement learning, sehingga terlihat jauh lebih sulit dihilangkan lewat pelatihan

  • Menurutku memakai LLM untuk code review alih-alih menulis kode baru, terutama pada proyek satu orang, termasuk yang paling besar manfaatnya dibanding risikonya
    Jika tidak ada reviewer khusus yang berpengalaman, analisis LLM secara harfiah lebih baik daripada tidak ada sama sekali
    Karena aku tidak ingin memakai model cloud komersial untuk pekerjaan open source, aku sedang bereksperimen dengan code review memakai LLM lokal, dan kusuruh agar tidak membuat kode baru, hanya menjelaskan masalah secara singkat
    Model lokal mungkin tidak sebagus model komersial, tetapi Qwen 3.6 27B cukup berguna
    Saat dijalankan pada codebase Rust ukuran menengah, sekitar 70% hasilnya lumayan, kira-kira 60% masalah yang ditemukan akurat, sekitar 20% kualitasnya rendah tetapi membuatku melihat bagian kode yang bermasalah dan berujung pada perbaikan, sedangkan 20% sisanya sampah
    Banyaknya sampah memang tidak bagus, tetapi justru membuat jelas sejak awal bahwa ucapan model harus diwaspadai
    Aku tidak tahu berapa banyak masalah nyata yang terlewat, dan sebagian temuan hanya dangkal seperti typo di komentar dokumentasi, tetapi secara keseluruhan ini membuat kode membaik, jadi terasa sebagai keuntungan bersih
    Risikonya adalah aku bisa mulai bergantung pada LLM dan tidak lagi meninjau pekerjaanku sendiri dengan teliti
    Namun model Qwen ini cukup lambat di mesinku sehingga aku tidak ingin menjalankannya setiap ada perubahan
    Model lain seperti Qwen 3.6 35B atau Gemma4 26B jauh lebih cepat tetapi jauh lebih buruk
    Meski lambat dan membutuhkan hardware, Qwen 27B menunjukkan bahwa masa depan untuk meningkatkan kode dengan model lokal tanpa bergantung pada penyedia komersial, dan tanpa merampas keahlian serta kesenangan mengutak-atik kode, mungkin saja ada
    Meski begitu, aku masih punya perasaan yang sangat rumit terhadap memasukkan LLM ke dalam proses, tetapi ini terasa lebih baik daripada visi masa depan yang mengasingkan yang didorong oleh para penyedia besar
    Aku setuju bahwa di antara harness yang pernah kucoba, hanya pi yang terasa tenang

    • Aku menjalankan bot terlebih dahulu, lalu melakukan review-ku sendiri sementara itu, kemudian kembali ke output bot untuk memeriksa apa yang kulewatkan
      Bot sering menemukan jenis masalah yang berbeda dari yang ditangkap manusia, jadi cukup saling melengkapi dengan review manusia

  • Di pi, menekan ctrl+G bisa membuka prompt di $EDITOR
    Secara teori, kita bisa mencari editor yang mendukung pemindahan kursor dengan klik dan sesuai kebutuhan, bahkan editor UI terminal sekalipun
    Selain itu, secara keseluruhan ini tulisan bagus yang kusetujui

  • Masalah “menunjuk ke teks” sebenarnya sudah terpecahkan di IDE/editor GUI
    Jika memakai JetBrains IDE, plugin bisa selalu meneruskan file dan baris yang dipilih sebagai konteks prompt
    Bergantung pada cara permintaannya, perbedaan perubahan juga ditampilkan secara inline atau di jendela diff

    • Zed juga punya fitur Inline Assistant yang bekerja seperti cara yang dijelaskan penulis
      Pilih area, tekan control-enter, lalu masukkan prompt; LLM akan mengubah area yang dipilih sesuai prompt dan menggantinya
      Pengalaman penggunanya sangat bagus, tetapi masalah-masalah yang umum muncul pada keluaran LLM tetap ada

  • Mereka menyebut hanya langganan bulanan $20 untuk model Anthropic dan OpenAI, lalu mengatakan pi jauh lebih baik daripada Claude Code atau Codex; kalau begitu saya jadi bertanya-tanya apakah kombinasi model frontier + pi sebenarnya belum mereka coba
    Saya kira langganan itu memaksa kita memakai harness terkait

    • Langganan Codex jelas bisa digunakan bersama Pi

  • Tulisan ini benar-benar masuk akal, jadi menyenangkan membacanya
    Untuk pekerjaan, saya membeli token dari Novita yang berbasis di AS, dan untuk proyek pribadi saya memakai DeepSeek serta, belakangan, Xiaomi
    Saya juga sudah mencoba Kimi langsung, tetapi belum cukup meyakinkan untuk terus dipakai; saya tidak punya pengalaman dengan Claude Code, Codex, atau harness yang sedang tren pada hari tertentu
    Dengan Qwen Code, saya mem-bootstrap harness pribadi Rust + ratatui, yang merupakan fork dari sesuatu di pihak Google
    Saya memakai async single-threaded, tetapi model-model itu terlalu suka thread dan mpsc, jadi cukup merepotkan untuk meyakinkannya
    Sebagai catatan, menurut saya smol baik-baik saja
    Pada akhirnya saya jadi cukup memahami apa yang dilakukan alat dan bagaimana melakukannya, dan setiap kali model mengarang sintaks alat baru, saya menimbang plus-minusnya lalu terkadang menambahkan koreksi lokal hanya untuk kasus tertentu
    Hal seperti ini umumnya soal sinonim untuk nama argumen alat
    Makin sedikit parameter yang aktif, model lebih memperhatikan apa yang harus dilakukan dan lupa bagaimana melakukannya; itu bisa dimengerti
    Suatu saat nanti, pemanggilan alat tampaknya akan diekstraksi dari latent space alih-alih dipaksakan sebagai token, dan mungkin juga memakai model penerjemah khusus
    Saya memakai landlock untuk mengisolasi model ke direktori proyek dan memutuskannya dari direktori home
    Jalur sistem di luar home bisa dibaca, dan saya mengizinkan penulisan ke tempat seperti /tmp, beberapa direktori cache paket di dalam home, dan /dev/null
    Ke depannya saya bisa menambahkan isolasi yang lebih baik, tetapi melihat kebanyakan orang yang saya kenal menjalankan Claude Code begitu saja, ini terasa seperti higiene dasar
    Jaringan tidak saya blokir, dan saya tidak mengerjakan hal yang memerlukan pencegahan kebocoran tambahan
    Review kode tidak selalu tepat sasaran
    Jika instruksi didefinisikan terlebih dahulu, model lumayan untuk membandingkan kode dengan instruksi dan menandai bagian yang menyimpang, tetapi permintaan umum seperti “beri tahu apakah ini jelek” menghasilkan hasil yang tidak konsisten
    Pada DeepSeek V4 Flash yang saya pakai sebagai baseline, saya belum pernah mengalami omong kosong sok tahu
    DeepSeek V4 Pro lebih buruk bagi saya untuk coding, Xiaomi MiMo 2.5 Pro lebih baik tetapi sedikit lebih mahal, sedangkan MiMo 2.5 biasa lebih buruk
    Dari pengalaman saya, model pada umumnya hanya bodoh, terutama ketika konteks tercemar oleh ide-ide yang saling bertentangan atau menjadi terlalu panjang
    Kadang model terjebak pada gagasan semacam “untuk menyampaikan nilai lebih cepat, kita harus memotong sudut”, dan kalau begitu saya harus mundur beberapa langkah lalu membuat model menunjukkan bagian yang bertentangan dengan instruksi saya
    Kadang itu karena saya belum cukup memahami, kadang karena model terlalu over-engineering, dan sesekali saya berkompromi dengan menyederhanakan requirement agar lolos dari edge case yang sulit
    Saya tidak suka memakai model untuk refactoring
    Model tidak membuat keputusan yang baik
    Jika Anda meminta model memecah fungsi menjadi dua sesuai dua kegunaan lalu menelusuri codebase untuk menentukan varian mana yang dipakai di tiap titik pemanggilan, 25% akan salah tanpa menunjukkan sinyal ketidakpastian sama sekali
    Jauh lebih baik meminta model menyelidiki codebase dan memetakan cakupan dampaknya, lalu melakukan refactoring sendiri
    Penataan ulang yang sangat mudah, seperti perubahan struktur sederhana yang membungkus pekerjaan di beberapa titik, memang mempercepat, tetapi Anda juga harus secara eksplisit memintanya memeriksa hal-hal seperti komentar lama atau nama variabel yang kini tidak lagi cocok
    Berbeda dari penulis asli, saya tidak pernah mengalami model bersikeras melakukan hal yang tidak saya minta
    Mungkin karena sebelum mengizinkan pengeditan, saya meminta rencana awal yang jelas, dan saya memantau alur penalarannya secara real time lalu memberi prompt ulang jika model mulai aneh
    Untuk kode kerja, saya tidak akan commit sampai membaca dan memahami semuanya
    Pada tahap ini saya melakukan banyak perbaikan besar, lalu meminta model memeriksanya lagi
    Biasanya ia cukup baik menemukan typo, variabel yang tertukar, dan hal-hal kecil tetapi berpotensi bermasalah
    Versi pertama proyek pribadi hanyalah versi buangan
    Setelah arsitektur sebenarnya menjadi jelas, semuanya harus ditulis ulang, dan kali ini perencanaan awal dilakukan dengan benar
    Cara ini mungkin agak diremehkan
    Model yang saya pakai cukup cepat
    Kecuali saya secara eksplisit meminta investigasi panjang, tidak perlu sampai berpindah tugas; jika model butuh waktu lama untuk meyakinkan dirinya sendiri berapa banyak huruf r dalam strawberry, biasanya saya memikirkan langkah berikutnya
    Yang cukup efektif adalah meminta model membuat rencana, menuliskannya secara eksplisit ke file, lalu memperbaikinya sedikit secara iteratif
    Model bisa membantu menelusuri codebase dan memahami cakupan dampak sebelum mulai coding, dan dengan rencana awal yang terlihat, lebih mudah menjaga model tetap di jalur
    Untuk pencarian atau tenaga kerja murah, saya pernah memakai model untuk mencari makalah tentang topik tertentu, dan hasilnya tidak buruk
    Setelah itu saya mengambil sendiri makalahnya lewat langganan atau jalur lain, lalu meminta model membacanya dan menilai apakah relevan dengan topik; ini sebenarnya cukup efektif
    Makalah yang relevan kemudian saya baca sendiri lagi
    Meminta model menyelidiki codebase besar dan menjelaskan aspek tertentu juga cukup produktif
    Kesamaan dari dua kasus itu adalah model cukup banyak berhalusinasi
    Tingkat halusinasi sangat dipengaruhi oleh seberapa dalam fakta inti terkubur di dalam konteks
    Setelah meminta model mengklasifikasikan dan merangkum satu makalah, lalu menghapus konteks dan memproses makalah berikutnya, masalahnya jauh berkurang
    Saya menduga ini terkait dengan sparse attention, tetapi saya bukan ahlinya
    Untuk brainstorming dan kreativitas, model tidak berguna
    Saya sama sekali tidak pernah mengalami DeepSeek V4 Flash berbohong bahwa ia sudah menjalankan test atau type check
    Kadang ia menjadi sangat sulit dikendalikan, tetapi justru cenderung menjalankan ulang test dan type check “agar pasti” bahkan setelah hanya sedikit mengubah komentar
    Dan saya tidak setuju bahwa ini adalah hal paling menarik dalam hidup saya