AI Mampu Menghasilkan 1 Miliar Baris Kode per Bulan, Melonjak 76%—Forum Programmer Heboh: Jumlah Baris Kode Bukan Ukuran Produktivitas

Jika Anda penasaran bagaimana para programmer di Silicon Valley memanfaatkan AI untuk menulis kode, Greptile—agen AI untuk code review yang sudah digunakan oleh lebih dari 2.000 perusahaan—baru saja merilis laporan tahunan tentang AI dalam pemrograman. Berbekal data dari sekitar 1 miliar baris kode yang ditinjau AI setiap bulan, laporan ini menampilkan gambaran produktivitas yang tampak melonjak. Menariknya, banyak programmer justru merasa peningkatan itu tidak sepenuhnya “terasa” dalam realitas kerja sehari-hari.

Sorotan paling mencolok dari laporan ini adalah klaim bahwa, dengan bantuan AI, output kode engineer meningkat tajam.

Rata-rata jumlah baris kode yang dikirim per developer per bulan naik dari 4.450 menjadi 7.839 baris, setara dengan peningkatan 76%. Pada tim berukuran menengah (sekitar 6–15 orang), lonjakannya bahkan nyaris dua kali lipat—naik 89% per developer. Dengan kata lain, alat bantu coding berbasis AI semakin terlihat sebagai pengganda efisiensi bagi tim.

Bukan hanya “lebih cepat”, perubahan kode juga cenderung “lebih besar” dalam satu kali iterasi.

Median jumlah baris yang berubah per file dalam satu commit meningkat 20%, dari 18 menjadi 22 baris. Ini mengindikasikan bahwa engineer bukan sekadar menambah sedikit demi sedikit, melainkan melakukan modifikasi yang lebih luas dalam setiap pembaruan. Bisa jadi ini juga menandakan bahwa AI mulai dipercaya untuk menangani perubahan yang lebih kompleks, seiring kebutuhan produk yang semakin dinamis.

Namun, ketika temuan tersebut dibahas di forum Y Combinator, respons yang muncul justru didominasi nada skeptis.

Sejumlah developer menyoroti bahwa kode yang dihasilkan AI sering membutuhkan waktu ekstra untuk diperbaiki—mulai dari debugging, revisi logika, hingga pembersihan implementasi agar sesuai standar tim. Masalah-masalah kecil seperti edge case, kendala integrasi, dan bug yang “halus” sering tidak tercermin dalam metrik sederhana seperti jumlah baris kode yang lolos review.

Inti keberatan mereka cukup sederhana: lebih banyak baris kode tidak otomatis berarti lebih produktif.

Seorang programmer junior mungkin membutuhkan puluhan baris untuk menyelesaikan satu fitur, sementara senior engineer bisa menyelesaikannya hanya dengan beberapa baris yang lebih tepat sasaran. Selain itu, jika AI membuat lebih banyak kode “masuk” ke dalam repo, bagaimana dengan kode yang kemudian dihapus, ditulis ulang, atau direfaktor? Angka-angka ini sulit dihitung, padahal sering kali justru di situlah terlihat apakah AI benar-benar meningkatkan produktivitas—atau hanya memindahkan beban kerja ke tahap berikutnya.

Ada juga kritik yang menantang asumsi dasar dari perbandingan produktivitas berbasis “jumlah baris”.

Jika semua orang memiliki tingkat kemampuan yang sama dan mengerjakan tugas dengan kompleksitas serupa, maka output baris kode mungkin dapat mendekati produktivitas. Tetapi dalam praktiknya, pekerjaan engineering tidak seragam. Ada tugas yang sangat sulit, butuh pengalaman tinggi, namun hasil kodenya sedikit. Ada pula tugas yang sederhana tetapi memang memerlukan banyak baris. Mengukur kinerja hanya dari volume commit berisiko menyamaratakan semua pekerjaan sebagai “tingkat menengah”, sehingga kesimpulannya bisa bias.

Kualitas kode juga menjadi faktor besar yang tidak tertangkap dalam laporan tersebut.

Laporan menekankan kuantitas, tetapi tidak secara langsung menilai apakah tambahan kode itu lebih baik, lebih aman, atau lebih mudah dirawat. Dari sudut pandang engineering, setiap baris kode tambahan bisa dipandang sebagai beban pemeliharaan, bukan aset—karena harus diuji, ditinjau, didukung, dan diperbaiki di masa depan. Pada akhirnya, tim tetap memerlukan expert domain untuk menentukan “seberapa banyak kode yang memang perlu ada”.

Salah satu analogi yang muncul dalam diskusi cukup menggambarkan masalahnya.

Produktivitas pekerja gudang bisa diukur dari jumlah barang yang dipindahkan per jam. Tetapi jika seseorang asal melempar barang ke gudang, atau memindahkan barang yang sebenarnya tidak perlu dipindahkan, maka metrik itu akan terlihat tinggi—padahal operasionalnya justru memburuk.

AI memang memungkinkan setiap programmer menghasilkan lebih banyak kode. Tetapi pertanyaan yang lebih penting adalah: apakah kode itu benar-benar diperlukan untuk menyelesaikan tujuan yang diinginkan?

Jika organisasi hanya mengapresiasi volume commit, hal itu bisa tanpa sengaja mendorong pekerjaan yang repetitif, over-engineering, atau solusi yang membengkak. Mengukur kinerja hanya dari “jumlah baris yang dikirim” berisiko membuat metrik tersebut menjadi target yang dioptimalkan, bukan cerminan nilai yang dihasilkan.

Karena itu, sebagian orang berpendapat metrik yang lebih seimbang adalah “jumlah baris yang diedit”, bukan semata “jumlah baris yang ditambahkan”.

Dengan pendekatan ini, refactor yang mengurangi ukuran codebase tetap bisa dihitung sebagai produktif. Bahkan ada ide penilaian sederhana: menghapus satu baris bernilai 1 poin, menambah satu baris juga bernilai 1 poin—sehingga perubahan yang bermakna dihargai, bukan sekadar ekspansi.

OpenAI masih memimpin, tetapi jaraknya menyempit

Di balik lonjakan “produktivitas”, laporan juga menyoroti restrukturisasi besar pada tumpukan teknologi pendukung AI. Dengan menggunakan jumlah unduhan SDK dari berbagai penyedia model sebagai indikator adopsi, laporan menemukan bahwa pada modul “AI memory”, mem0 mendominasi dengan 59% pangsa pasar. Sementara itu, pada ranah database vektor, persaingan jauh lebih rapat: Weaviate memimpin dengan 25%, diikuti ketat oleh Chroma, Pinecone, Qdrant, dan lainnya.

Pada lapisan LLMOps, laporan mencatat pertumbuhan pesat infrastruktur.

LiteLLM diklaim tumbuh 4× hingga mencapai 41 juta unduhan, sementara LangSmith naik cepat berkat integrasi erat dengan ekosistem LangChain. Polanya jelas: orkestrasi model, monitoring, dan mekanisme fallback kini bergeser dari “opsional” menjadi komponen infrastruktur standar. Ketika jumlah agent yang dipanggil dalam pemrograman meningkat, kompleksitas operasional ikut naik secara eksponensial—dan LLMOps mulai mengambil peran yang dulu dimainkan Kubernetes dalam era microservices.

Untuk kompetisi antar penyedia model, laporan membandingkan unduhan SDK dari Januari 2022 hingga November 2025, dengan pemain utama OpenAI, Anthropic, dan Google GenAI.

OpenAI tetap dominan, dengan unduhan meningkat dari nyaris nol di awal 2022 menjadi sekitar 130 juta pada November 2025. Anthropic menunjukkan laju pertumbuhan “seperti roket”: meski memulai lebih lambat, sejak paruh kedua 2023 unduhannya meledak, mencapai sekitar 43 juta pada November 2025—disebut sebagai kenaikan 1.547× sejak April 2023. Rasio OpenAI vs Anthropic pun menyusut dari 47:1 menjadi 4,2:1, memberi sinyal bahwa developer mulai berpindah ke antarmuka yang dirasa lebih terbuka, lebih bisa dikontrol, dan lebih “programmable”. Di sisi lain, Google berada pada jalur pertumbuhan yang lebih landai, sekitar 13,6 juta unduhan pada November 2025, masih terpaut cukup jauh dari dua teratas.

Parameter model menentukan skenario pemakaian terbaik

Laporan juga memaparkan benchmark untuk lima model utama sebagai backend coding agent, dengan indikator seperti waktu menuju token pertama, throughput, dan biaya.

Untuk pemrograman interaktif, “time-to-first-token” sangat krusial. Claude Sonnet 4.5 dan Opus 4.5 disebut mampu mengeluarkan token pertama dalam kurang dari 2,5 detik, lebih cepat dibanding keluarga GPT-5 yang lebih dari 5 detik. Dalam kerja coding real-time, sekitar 2 detik kerap dianggap batas antara tetap berada dalam “flow” atau mulai terdistraksi.

Namun untuk skenario batch generation, hasilnya berbeda.

GPT-5-Codex dan GPT-5.1 dilaporkan unggul jauh dalam throughput, cocok untuk kebutuhan seperti pipeline CI/CD yang memerlukan pembuatan kode massal atau pengisian test case. Sementara Gemini 3 Pro dinilai lebih lambat, membutuhkan 10+ detik untuk token pertama dan menghasilkan token per detik yang lebih sedikit, sehingga kurang ideal untuk penggunaan interaktif.

Arah riset berikutnya

Di bagian akhir, laporan merangkum beberapa paper kunci tahun 2025 yang mengisyaratkan arah terobosan selanjutnya.

Contohnya, Self-MoA menantang pendekatan ensemble multi-model tradisional dengan menunjukkan bahwa satu model yang di-sample berkali-kali lalu di-aggregate dapat mengalahkan campuran model heterogen. Ini memberi sinyal pergeseran dari “keragaman model” menuju “keragaman jalur penalaran”. Search-R1 melatih model lewat reinforcement learning agar mampu memutuskan kapan harus mencari, menjadikan search engine sebagai aksi lingkungan yang bisa dipelajari, bukan sekadar tool call statis. RetroLM bahkan mengeksplorasi retrieval langsung pada level KV, melewati teks mentah, yang berpotensi mengubah cara model mengorganisasi memori.

Sebesar apa pun peran AI, review manusia tetap penting

Pada akhirnya, seberapa pun banyaknya AI membantu proses coding, peninjauan manusia sebelum merge tetap tidak tergantikan. Data penggunaan alat AI sulit memasukkan waktu dan tenaga yang dipakai untuk memvalidasi, memperbaiki, dan mengambil keputusan teknis.

Jika sebuah alat AI coding mampu membuktikan bahwa ia membantu tim merilis fitur lebih cepat dengan tingkat keyakinan yang lebih tinggi—bukan hanya membuat lebih banyak baris kode lolos review—maka nilai produknya akan jauh lebih mudah dibuktikan, baik bagi engineer maupun bagi pemangku kepentingan bisnis.