LLM telah menjadi hampir sempurna dalam menghasilkan kode, tetapi itu bukan akhir dari cerita. Hanya karena kode secara formal benar bukan berarti kode tersebut tidak memperkenalkan abstraksi yang tidak perlu, membuat duplikat, atau hanya membuat keputusan buruk secara keseluruhan. Ini bukan pengamatan yang terobosan; sebagian besar orang yang pernah melakukan vibe-coding pada suatu proyek menyadari bahwa setiap fitur tambahan terkadang dapat menyebabkan ledakan baris kode (LOC). Hal ini mengakibatkan hilangnya agensi manusia, karena dalam proyek yang menambahkan jutaan LOC per bulan, sulit bagi manusia untuk mengikutinya. Beberapa orang mungkin mengatakan bahwa itu bukan masalah sama sekali, karena mereka mempercayai agen mereka untuk menanganinya. Saya punya kabar buruk untuk Anda: agen juga tidak benar-benar dapat menangani kelalaian tersebut.

Berasal dari latar belakang fisika, saya selalu memiliki pendekatan eksperimental/kuantitatif untuk memecahkan masalah. Ketika saya mulai di Earendil, dengan tugas mencari cara mengukur kelalaian kode, insting alami saya adalah pertama-tama menyelami literatur dan kemudian memeriksa apa yang dilakukan perusahaan lain. Sejujurnya, kecuali beberapa makalah penelitian yang berwawasan, saya kecewa dengan betapa "berbasis vibes" industri ini tampaknya saat ini. Dalam penelitian saya dan di X, saya terus-menerus dibombardir dengan pesan seperti "Agen coding end-to-end", "AI yang tidak hanya menyarankan kode—tetapi mengirimkannya" atau "Evaluasi tingkat manusia tanpa biaya tingkat manusia". Yang seperti semua kisah yang bagus, memiliki sebutir kebenaran di dalamnya. LLM mampu menulis kode yang hampir sempurna. Ini karena skalabilitas dan verifiabilitas kode. Cukup mudah untuk membiarkan LLM menghasilkan kode dan kemudian membiarkan kode itu diperiksa oleh tes tersembunyi, yang menghasilkan sinyal hadiah yang jelas. Sangat kontras dengan itu, memeriksa 'kelalaian' kode ini sering membutuhkan intuisi dan selera manusia, dan secara umum merupakan tugas yang sangat sulit.

Saya pikir cara terbaik untuk menggambarkan mengapa demikian adalah dengan menelusuri kemungkinan cara mengukur kelalaian. AI sebagai juri: Ini mungkin cara paling umum untuk mengevaluasi kualitas kode di industri dan dari pengamatan saya jarang berhasil. Cara paling naif untuk melakukannya, yaitu menanyakan kepada model seberapa baik kode pada skala 1-10, pada dasarnya setara dengan generator angka acak. Pendekatan yang lebih canggih, yaitu mencoba memberikan model juri dua solusi A dan B, dan kemudian membiarkannya memutuskan mana yang lebih disukai, memiliki kelemahan yaitu model mengubah preferensinya ketika Anda mengganti nama solusi. Saya sedikit bercanda di sini dan efeknya tidak begitu jelas dengan model yang lebih besar, tetapi poin utamanya tetap berlaku. Meminta LLM untuk menilai kode yang mereka tulis bukanlah pengganti evaluasi yang tepat. Meskipun ada beberapa pendekatan menarik dengan rubrik atau LLM yang menulis tes, mereka masih jauh dari benar-benar menghilangkan kelalaian.

Manusia menilai AI: Jika kita mengabaikan fakta bahwa ada keragaman besar dalam kualitas insinyur perangkat lunak, ini akan menjadi solusi terbaik untuk memastikan kode tetap dapat dibaca manusia. Dengan kelemahan bahwa ini tidak skalabel untuk melatih AI atau memiliki benchmark besar dengan beberapa penyedia model dan harness. Metode paling sederhana: Dalam penelitian dan pengujian saya, hanya mengambil perubahan jumlah LOC telah menjadi