Sepertinya ada kasus seperti itu karena x jadi agak sulit untuk di-crawl. Akan kami perbaiki.

Ini pertama kalinya saya melihat kesalahan ringkasan yang mengatakan tidak ada isi..

Bidang yang saya kerjakan juga tidak sampai se-ekstrem itu, tetapi saya melakukan riset dan pengembangan di bidang AI.
Selain framework yang umum dipakai, kadang lingkungan target tempat model benar-benar dideploy berbeda dengan lingkungan saat model dilatih.
Ada juga kasus ketika operation tertentu tidak didukung, sehingga kami harus membuat custom operation untuk tiap platform. Dalam kasus seperti ini, sering kali tidak bisa langsung dites di lingkungan pengembangan.
Kadang saya juga memodelkan modelnya secara langsung; meskipun kita bisa menulis kode uji dengan data tertentu, nilainya bisa berubah secara probabilistik tergantung dataset, dan fenomena seperti nilai yang meledak pada titik tertentu sulit dicakup dengan kode uji.
Sepertinya ada cukup banyak lingkungan yang pengujiannya bahkan lebih sulit daripada yang saya hadapi.

Pendekatan SQLite memang sangat mengesankan. Menjaga suite pengujian yang besarnya mencapai 590 kali kode tetap tertutup pada akhirnya berarti bahwa "nilai sesungguhnya dari perangkat lunak ada pada spesifikasi perilakunya".

Faktanya, belakangan ini kalau mencoba membangun proyek dengan alat AI coding, selama ada README + dokumentasi API + kode pengujian dari proyek yang sudah ada, fitur intinya bisa direplikasi dengan sangat cepat, sampai tingkat yang mengejutkan. Ini saya rasakan sendiri sambil menjalankan 7 proyek; ironisnya, semakin baik pengujiannya, semakin mudah pula proyek itu direplikasi.

Namun, ada bagian yang terlewat dalam kasus Cloudflare vs Vercel, yaitu bahwa "mereplikasi" dan "mengoperasikan" adalah dua hal yang sepenuhnya berbeda. Untuk mereproduksi edge case Next.js, ekosistem plugin, sampai ketergantungan pada komunitasnya, kode pengujian saja tidak cukup. Pada akhirnya, saya merasa moat itu adalah kombinasi dari kode pengujian + komunitas + know-how operasional.

Wow

Proyek ini tampaknya tidak sampai pada titik di mana GC menjadi masalah. Menurut saya, di antara “kebanyakan proyek belakangan ini”, adopsi bahasa pemrograman sering kali lebih merupakan soal preferensi daripada kelebihan atau keterbatasan bahasa tertentu. Meski begitu, jika ditanya apa keunggulan komparatif Rust dibanding Go sebagai bahasa pemrograman serbaguna, saya rasa jawabannya adalah tingkat abstraksi yang disediakan Rust serta kemampuannya menangkap berbagai kesalahan saat waktu kompilasi. Tentu saja, Go juga punya kelebihan dibanding Rust, seperti pemrograman asinkron yang lebih mudah, waktu kompilasi yang cepat, dan sintaks yang ringkas.

Bahkan untuk kontrak dengan tingkat yang sama, rasa percaya atau citranya terasa sangat berbeda. Sepertinya aku harus membatalkan langganan GPT.

Menyebalkan, maaf.

Wah, keren sekali. Sepertinya ini memungkinkan berkat RustPython. Semoga hasilnya bagus!

Karena Rust cenderung menangkap banyak error saat kompilasi, rasanya kegagalan kompilasi justru membantu AI tetap berada di jalur yang benar.

Saya sudah mencoba mendaftar.

Yah, ini cuma dugaan, tapi mungkin karena hambatan untuk mulai memakai Rust sudah hilang.
Kesulitan terbesarnya adalah setelah menulis kode, kompilasi terus gagal, tapi sekarang AI yang menggantikannya.

Ternyata itu tes Joke, ya.

DIY, gerakan maker, indie, punk, dan open source semuanya adalah sanggahan terhadap industrialisasi, kapitalisme, dan konsumerisme, tetapi ternyata cara untuk mengatasi batasannya justru dengan menerima konsumerisme.

Saya setuju bahwa vibe coding cocok dengan kerangka konsumsi. Saya merasa ini adalah versi coding dari tren Temu-kkang, Ali-kkang (https://www.asiae.co.kr/article/2024053117460950053) yang sempat populer belakangan ini.
Namun, jika yang dimaksud adalah bahwa kerangka konsumsi merupakan cara untuk tidak mengulangi kegagalan gerakan maker, maka seperti komentar di HN, saya sulit setuju dalam banyak hal.

Vibe coding sedang melanjutkan sejarah panjang para pengembang warga.
Saya melihat vibe coding kini bergerak menuju sesuatu yang membuat coding semudah listrik: cepat, mudah, dan tak tergantikan.
Bahkan sudah banyak programmer jenius di berbagai perusahaan yang terus membuat kode hanya dengan prompt dan agent tanpa menulis satu baris kode pun.
Ada juga orang-orang yang mencoba meremehkannya, tetapi saya rasa sulit untuk membantah bahwa vibe coding ala Andrej Karpathy adalah sebuah peristiwa yang akan menorehkan satu garis penting dalam sejarah komputer.

Pertanyaan yang bagus. Sebenarnya kondisi "hibrida" dalam eksperimen kami memang tepat mengarah ke sana — yaitu konfigurasi yang menyediakan ringkasan yang sudah dirapikan bersama log pengalaman mentah.

Hasilnya, hibrida mencatat skor tertinggi, yaitu 4.95/5.0. Jika hanya diberi ringkasan nilainya 2.65, tetapi ketika catatan proses seperti "gagal" dan "penyebab tidak diketahui" ditambahkan, kelemahan ringkasan justru terkompensasi.

Jadi kesimpulannya adalah "bukan ringkasannya yang buruk, melainkan proses dan ketidakpastian juga harus disertakan".

Namun karena N=1, masih diperlukan penelitian lanjutan untuk mengetahui apakah ini bisa digunakan secara umum pada beragam kelompok pengguna.

Kalau begitu, apakah hasilnya akan berbeda jika memori sintetis dikonfigurasi agar memuat proses, kegagalan, dan keberhasilan dari tugas-tugas tersebut?

Betul. Saya juga awalnya memperkirakan memori sintetis setidaknya akan lebih baik daripada baseline, tetapi saya terkejut setelah melihat hasilnya.

Setelah dianalisis, kuncinya ternyata adalah "pelestarian ketidakpastian". Dalam log mentah masih ada jejak seperti "sudah coba ini tapi tidak berhasil" atau "tidak tahu penyebabnya", sehingga agen menjawab bahwa ia memang tidak tahu apa yang tidak diketahuinya. Namun, dalam ringkasan, konteks semacam itu justru terhapus, dan akhirnya malah menyampaikan jawaban yang salah dengan penuh keyakinan.

Ini memang sesuatu yang selama ini terasa secara empiris, tetapi memori sintetis ternyata jauh lebih buruk dari yang saya bayangkan.