Jumlah Baris Kode Mendapat Humas yang Lebih Baik

• Penilaian produktivitas developer seharusnya didasarkan pada metrik hasil seperti nilai bagi pelanggan, pendapatan, dan keandalan, bukan jumlah kode
• Angka promosi AI coding terbaru dari Google, Anthropic, OpenAI, dan Cursor semuanya berfokus pada klaim kuantitatif seperti rasio kode yang dihasilkan atau jumlah baris kode
• Klaim lama GitHub Copilot tentang peningkatan kecepatan kerja 55% adalah hasil yang bisa diverifikasi, tetapi “persentase kode yang ditulis AI” bisa terus naik terlepas dari ada tidaknya perbaikan
• Riset nyata menunjukkan hasil yang bercampur, dari +26% tingkat penyelesaian pada Cui et al. hingga "19% lebih lambat" dari METR dan pencabutan sikap setelahnya, serta survei bahwa 90% perusahaan tidak melihat efek yang terukur, sehingga efek pada tingkat organisasi sekitar 10%
• Adopsi AI memang perlu, tetapi pengukuran kinerja harus didasarkan pada standar yang sudah terbukti seperti metrik DORA, keandalan, kecepatan perubahan yang bermakna, pendapatan, dan nilai bagi pelanggan

---

Kebangkitan Metrik Jumlah Baris Kode

• Fakta bahwa satu dari dua developer senior di sebuah perusahaan SaaS 15 tahun lalu menulis 40% lebih banyak kode daripada yang lain tidak serta-merta berarti ia developer yang lebih unggul
  • Yang benar-benar penting adalah apa yang dirilis (ship) dan bagaimana itu berkontribusi pada pelanggan, pendapatan, dan stabilitas; jumlah baris kode dan jumlah PR telah lama dipelajari sebagai cara ukur yang buruk selama puluhan tahun
• Angka utama yang diusung industri pada 2026 semuanya berfokus pada persentase kode yang ditulis AI
  • Google: 75% dari kode baru dihasilkan oleh AI
  • Anthropic: sekitar 80% kode produksi yang di-merge ditulis oleh Claude, dan engineer menerapkan "8 kali lebih banyak kode" per kuartal
  • OpenAI: juga sekitar 80%
  • Cursor: “menulis lebih dari 100 juta baris kode enterprise per hari”
• Semua angka ini adalah klaim volume kuantitatif, dan "persentase kode yang ditulis AI" tidak lebih dari jumlah baris kode yang mendapat kalimat promosi yang lebih canggih
  • Fakta bahwa semua perusahaan tersebut adalah vendor AI membuat pembesaran tingkat adopsi menjadi motivasi yang penting

Dulu yang Diklaim adalah Hasil

• Beberapa tahun lalu, angka kuncinya berbeda bukan hanya skalanya, tetapi jenisnya
  • Klaim utama GitHub adalah bahwa dengan Copilot, pekerjaan bisa diselesaikan 55% lebih cepat
  • Meski banyak dikritik, ini adalah klaim hasil (outcome): berani, bisa dibantah, dan berbicara soal nilai — jika salah, bisa dibuktikan salah
• Klaim pada 2026 dibuat dengan struktur yang nyaris tak bisa gagal
  • "75% kode ditulis AI" bisa tetap benar dan terus naik tanpa kaitan dengan perbaikan nyata seperti rilis lebih cepat, berkurangnya insiden, atau kepuasan pelanggan
  • Angka volume hanya mengecewakan ketika adopsi mandek, dan kebanyakan orang memang sudah sepakat bahwa adopsinya nyata
• Klaim makin besar, tetapi maknanya justru berkurang

Bagian yang Tidak Pernah Masuk Billboard

• Yang terjadi di antaranya adalah bukti hasil menjadi jauh lebih rumit

• Hasil yang Mendukung Adopsi

  • Cui et al.: sekitar 5.000 developer menunjukkan +26% pekerjaan selesai, dengan peningkatan terbesar pada developer junior — hampir tidak menimbulkan perdebatan

• Bukti ke Arah Sebaliknya

  • GitClear: semakin dalam adopsi Copilot, code churn meningkat, dan refactoring runtuh
  • METR: developer open source berpengalaman yang memakai AI pada codebase mereka sendiri menjadi 19% lebih lambat, meski mereka percaya dirinya 20% lebih cepat

• Pembalikan Sikap METR

  • Pada Februari 2026, METR pada dasarnya menarik kembali posisinya — estimasi lanjutan berbalik menjadi peningkatan kecepatan (speedup), walau rentang galatnya sangat lebar
  • Para developer kini menolak bekerja tanpa AI dan tidak dapat melaporkan sendiri durasi kerja agen secara andal, sehingga desain risetnya sendiri dibuang
  • Posisi terbaru: pada 2026 AI kemungkinan besar meningkatkan kecepatan developer, tetapi besarnya tidak bisa diukur secara rapi

• Efek pada Tingkat Perusahaan

  • Survei NBER terhadap sekitar 6.000 eksekutif: 69% perusahaan menggunakan AI, dan sekitar 9 dari 10 melaporkan tidak ada efek produktivitas yang dapat diukur
  • Konsensus lintas studi berada di kisaran peningkatan sekitar 10% pada tingkat organisasi — berguna, tetapi jauh dari tingkat "developer tidak lagi dibutuhkan"
• Mereka yang masih hanya mengutip "19% lebih lambat" juga sedang cherry-picking; riset terus diperbarui dan industri hanya mengganti apa yang diukur

Versi AI dari Vanity Metric

• Ini bukan hanya masalah klaim vendor AI

• Model Kematangan dan Tangga

  • Carnegie Mellon SEI dan Accenture beberapa hari lalu meluncurkan AI Adoption Maturity Model — 5 tingkat, 8 dimensi, dan memakai statistik "95% organisasi tidak menghasilkan keuntungan" untuk pemasaran
  • "8 levels of AI-assisted development" dari Steve Yegge memberi peringkat berdasarkan alat apa yang dipakai dan seberapa besar pengawasannya
  • Semua vendor alat merilis tangga kematangan, dan puncaknya biasanya berarti "lebih banyak memakai produk mereka sendiri"
  • Tangga ini pada dasarnya adalah pengganti yang sama dengan bungkus berbeda: mengukur intensitas adopsi tetapi menyebutnya kematangan

• Kekacauan Definisi

  • Ketika Augment bertanya kepada 219 pemimpin engineering apa arti "AI-native engineering", mereka mendapatkan 219 jawaban yang berbeda

• Dua Wajah Anthropic

  • Di satu sisi mengklaim "8 kali lebih banyak kode dirilis", di sisi lain menyajikan salah satu riset paling ketat tahun ini
  • Hasil RCT menunjukkan developer yang dibantu AI mendapatkan skor pemahaman 17% lebih rendah untuk kode yang baru saja mereka rilis, tanpa peningkatan produktivitas yang signifikan secara statistik
  • Divisi riset memperbarui temuannya sementara divisi pemasaran menghitung volume; keduanya bisa benar pada saat yang sama

Mengapa Masalah Ini Perlu Diperhatikan

• Angka-angka ini bukan sekadar hiasan, tetapi menggerakkan anggaran, ekspektasi kinerja, dan perencanaan tenaga kerja

• PHK dengan Alasan AI

  • Pada Februari, Jack Dorsey memangkas lebih dari 40% tenaga kerja Block (4.000+ orang), dengan AI sebagai argumen inti yang eksplisit — "tim yang lebih kecil bisa melakukan lebih banyak hal, dan melakukannya lebih baik, dengan alat yang kami bangun"
  • Beberapa minggu kemudian, Atlassian memangkas 10% (sekitar 1.600 orang), sambil mengakui bahwa berpura-pura AI tidak mengubah komposisi keterampilan atau jumlah peran yang dibutuhkan adalah tidak jujur
  • Dalam pengumuman yang sama, Dorsey menyebut bisnisnya tetap kuat dan laba kotor terus tumbuh

• Keraguan terhadap Klaim Produktivitas

  • Jika "AI membuat semua orang lebih produktif sehingga tenaga kerja yang dibutuhkan lebih sedikit", maka seharusnya ada buktinya, tetapi saat ini bukti itu dinilai belum ada
  • Harus dibuktikan bahwa sebagian tenaga kerja benar-benar menganggur atau kurang dimanfaatkan; perusahaan produk/SaaS memiliki roadmap tanpa akhir, sehingga kapasitas ekstra semestinya dipakai untuk nilai pelanggan dan kecepatan — dan itu harus terlihat pada MAU, konversi, atau pendapatan
  • Memilih PHK adalah sinyal bahwa klaim produktivitas sudah berfungsi sebagai PR untuk keputusan yang sebenarnya diambil karena alasan lain seperti overhiring atau tekanan investor
• Pemangkasan berbasis efisiensi kadang memang sah, tetapi jika demikian maka yang harus dipakai adalah sistem evaluasi kinerja individu yang sudah berjalan, bukan jumlah token, "persentase kode yang ditulis AI", atau peringkat tangga kematangan
  • Jika dasar seleksinya adalah vanity metric, maka seleksi itu hanyalah "lotere yang dipoles"

Kesimpulan

• Ini bukan posisi anti-AI; justru posisinya adalah semua engineer harus menggunakan AI setiap hari
  • Entah disebut AI-first atau AI-proficient, yang penting adalah menguji alat baru dan model terbaru dengan rasa ingin tahu
  • Industri telah menyerap bahasa tingkat tinggi, IDE, autocomplete, agile, dan devops; selalu ada pihak yang nostalgis terhadap masa lalu, tetapi pada akhirnya ikut juga
  • Yang berbeda kali ini adalah kecepatannya — adopsi "cloud" masih bisa ditunda beberapa tahun dan tetap bertahan hidup, tetapi untuk AI mungkin hanya beberapa bulan
• Adopsi AI adalah garis start, bukan papan skor
  • Cara mengukur kinerja engineering sebenarnya sudah diketahui — metrik DORA, keandalan, rasio perubahan yang bermakna, dan pada akhirnya pendapatan serta nilai pelanggan
  • Tidak ada alasan meninggalkan cara yang sudah terbukti demi skor vanity AI
• Pertanyaan yang perlu dilemparkan dalam vendor pitch, review eksekutif, dan feed LinkedIn adalah: "Apakah itu hasil, atau volume?"
• Cara bekerja harus AI-first, tetapi cara mengukurnya harus memakai metode yang sudah teruji (battle-tested)

[GN⁺]

Komentar Hacker News

• Arus aneh ini tampaknya mencapai puncaknya pada Februari 2026 lewat tulisan blog OpenAI [1]. Ini postingan yang baru-baru ini naik ke halaman depan [2], membahas proses membuat sesuatu yang ditulis 100% oleh agen
  Namun anehnya tidak dijelaskan benda itu sebenarnya apa, atau nilai apa yang diberikannya kepada pengguna. Penjelasan yang paling mendekati hanya, “Produk ini telah digunakan oleh ratusan orang secara internal, dan ada power user internal yang memakainya setiap hari”
  Tetapi fakta bahwa ini adalah 1 juta baris kode bahkan diulang dua kali dalam beberapa ratus kata pertama
  [1] https://openai.com/index/harness-engineering/
  [2] https://news.ycombinator.com/item?id=48416264

  • Kalau “produk ini telah digunakan oleh ratusan orang secara internal, dan ada power user internal yang memakainya setiap hari”, kemungkinan besar itu filter email
    Kalau “1 juta baris kode” dan “100% ditulis agen”, makin terasa begitu. Atau mungkin menu JS untuk wiki departemen, yang pada praktiknya cuma membuat ulang jquery dengan MS JScript lalu mengubahnya ke JS 5
  • Seluruh kernel Linux sekitar 40 juta baris, dan tanpa driver kira-kira 16 juta baris. Sulit membayangkan bahwa hanya karena sesuatu yang disebut OpenAI itu memiliki jumlah baris kode sebesar 6% dari kernel Linux, kegunaannya juga akan mendekati 6%
    Sehebat apa pun LLM, rasanya itu juga hampir tidak akan bisa dirawat
  • Reality distortion field di sekitar Anthropic juga kuat. Anthropic juga terus mengunggah banyak tulisan blog omong kosong yang terdengar seperti sepenuhnya ditulis AI dan tidak mengatakan apa-apa, tetapi tetap masuk halaman depan dan konsisten mendapat ratusan upvote
  • Bukannya ini?
    https://github.com/openai/symphony
  • Saya kecewa karena detailnya terlalu sedikit. Jadi saya pikir sebentar lagi akan muncul proyek open source atau upaya yang menunjukkan seberapa efektif hal-hal seperti ini dalam praktik
    Dalam wawancara podcast, disebutkan bahwa ini adalah aplikasi Electron yang diunduh pengguna, dan karena itu mereka membuat build baru secara berkala. Lihat bagian “Autonomous Merging Flow” di sini: https://www.latent.space/p/harness-eng

• Saya terus teringat seseorang dari Microsoft yang pernah memposting sesuatu seperti, “kami ingin 1 juta baris kode per engineer per bulan”. Bagi sebagian besar engineer yang saya ceritakan, itu terdengar seperti sindiran, tetapi ternyata sama sekali bukan sindiran, dan tampaknya cukup akurat mencerminkan sikap banyak CEO terhadap pembuatan kode dengan LLM
  Meski begitu, dalam beberapa bulan terakhir rasanya antusiasme berlebihan terhadap menghasilkan jumlah baris kode yang tidak mungkin dirawat mulai sedikit mereda. Pandangan yang lebih praktis dan realistis lebih sering dibagikan secara terbuka, dan tampaknya sedikit demi sedikit juga sampai ke kalangan tertinggi di beberapa perusahaan teknologi. Mungkin semuanya belum sepenuhnya hancur

  • Dulu saya pernah bekerja di perusahaan yang punya persyaratan cakupan kode 80%. Ada kontraktor cerdik yang punya skrip untuk menghasilkan satu file yang ukurannya bisa disesuaikan agar total codebase mencapai 80%, beserta test suite untuk file itu sendiri
    Kenyataannya, sebagian besar kode tetap tidak diuji
  • 1,000,000 / 25 / 8 / 60 = lebih dari 83 baris per menit
    1 juta per bulan / 25 hari kerja per bulan / 8 jam per hari / 60 menit per jam
    Bagi orang yang melakukan code review, ini terlihat seperti masalah yang cukup besar
  • Sangat lucu melihat para eksekutif tiba-tiba sadar bahwa token itu butuh biaya, lalu langsung memperbaiki pedoman penggunaan AI untuk karyawan
    Membuat setiap engineer menghasilkan 1 juta baris kode per bulan, tanpa memikirkan bagaimana baris-baris itu akan menghasilkan uang bagi perusahaan atau berapa banyak token yang akan terbakar dalam proses itu dengan biaya sebesar apa, tampaknya memang bukan rencana yang terlalu matang
  • Kata slop memang pilihan yang bagus untuk menyebut kode yang dihasilkan AI dalam jumlah besar. Bahkan orang nonteknis pun bisa langsung menangkap kesan menjijikkannya. Jelas bahwa slop itu harus dihindari
    Sementara utang teknis tidak pernah benar-benar menggigit manajemen dengan cara yang sama. Utang memang umumnya bisa menjadi masalah, tetapi dianggap tidak perlu dihindari atau ditangani sampai benar-benar menjadi masalah, jadi terus saja ditunda
  • Saya juga penasaran apakah menurunnya antusiasme berlebihan terhadap produksi baris kode yang tidak dapat dirawat dalam beberapa bulan terakhir sebagian dipengaruhi oleh orang-orang di sisi bisnis dan produk yang mulai benar-benar mencoba memasukkan AI ke pekerjaan sehari-hari mereka
    Saya melihat ini di dua perusahaan kecil tempat saya bekerja. Beberapa bulan lalu semua orang mendapat Claude Cowork dan sangat bersemangat, dan mereka masih memakainya setiap hari, tetapi menurut saya hasilnya cukup mengecewakan dibanding keajaiban yang diharapkan
    Keluhannya adalah hasilnya biasa saja dan bertele-tele, salah bahkan untuk hal yang sangat mendasar, terus mentok limit token, dan pada akhirnya lebih cepat dikerjakan sendiri dengan tangan
    Mungkin pada awalnya memang ada unsur salah memakai alat, tetapi orang-orang mulai sadar bahwa masih ada jarak antara apa yang dikatakan CEO AI, pedagang LinkedIn, dan penjual suplemen AI di YouTube dengan kenyataan

• Jika perusahaan berkata “AI telah membuat semua orang lebih produktif sehingga kami butuh lebih sedikit orang”, saya ingin melihat buktinya. Saat ini saya tidak percaya bukti seperti itu ada
  Pada kenyataannya, mereka hanya asal bicara dan memakai AI sebagai alasan untuk membalikkan perekrutan berlebihan pada masa COVID. Sekaligus membuat investor merasa bahwa mereka telah mengadopsi teknologi tren terbaru dan menjadi organisasi yang lebih ramping serta efisien biaya

  • Membuat investor merasa bahwa perusahaan telah mengadopsi teknologi tren terbaru dan menjadi lebih ramping serta efisien biaya bukanlah hal baru. Hanya namanya saja yang baru
  • Menyebut ini sebagai perekrutan berlebihan pada masa COVID adalah alasan yang cukup murah hati. Di mata saya, ini terlihat lebih seperti upaya menurunkan upah secara umum. Sejak itu sudah ada beberapa gelombang PHK, jadi alasan yang sudah berumur 6 tahun itu terdengar sangat kosong
    Saya tadinya mengira investor lebih peduli pada laba daripada penerimaan teknologi tren terbaru
    Dan perusahaan yang berkata, “Kami juga memakai teknologi berkilau yang bisa dipakai sembarang orang bodoh dari kamar tidur mereka!” juga adalah perusahaan yang sama sekali tidak punya daya saing

• Sudah puluhan tahun industri kita menjelaskan bahwa “apa yang kita kerjakan itu kompleks dan memakan waktu lama, jadi produktivitas tidak bisa diukur dengan mudah,” tetapi begitu AI muncul, tiba-tiba jumlah baris kode, pengali N kali lipat, jumlah tiket per minggu, dan semacamnya dipuja seolah itu metrik yang berguna atau objektif, dan itu terasa lucu tanpa habis
  Alasan kita menolak metrik seperti jumlah baris kode tidak berubah. Yang penting bukan output kode, melainkan output berkualitas. AI juga membawa masalah yang sama seperti manusia. Tapi entah kenapa kita malah membuang pelajaran yang sudah kita dapat, dan itu agak memalukan

  • Orang nonteknis sedang memegang kuasa, dan mereka tidak terikat pada realitas seperti para engineer. Pada akhirnya realitas objektif yang akan menang, tetapi itu tidak mencegah kerusakan dalam jangka pendek
  • Benarkah selama puluhan tahun kita menjelaskan bahwa produktivitas tidak mudah diukur? Selama 10 tahun terakhir, yang saya lihat justru engineer dan non-engineer sama-sama makin memuja grafik aktivitas GitHub. Menurut saya, bazar ini sudah tersesat bahkan sebelum AI
  • Mungkin beberapa kelompok software engineer memang menumbuhkan kebutuhan akan pengukuran yang hati-hati. Tetapi bidang pemrograman secara keseluruhan tidak pernah benar-benar lepas dari gagasan metrik sederhana
    Karena selalu ada atasan yang keterlibatannya longgar, tetapi agresif dan banyak menuntut. Sayangnya, bahkan atasan yang tugas utamanya memeras lebih banyak usaha dari karyawan dan tidak berkontribusi pada hal seperti koordinasi pun tetap punya nilai ekonomi
    Karena itu selalu ada awan dari dua pendekatan yang saling tumpang tindih: hasil nyata, dan pengukuran seperti jumlah baris kode
    AI menyediakan semua alat untuk memuaskan atasan seperti ini: longgar keterlibatannya, tetapi banyak tuntutan. Jadi sekarang akan makin banyak orang yang menyukai jumlah baris kode dan penambahan fitur sebagai metrik. Karena sekarang itu jadi lebih mudah
  • Pada dasarnya semua ini dilakukan agar kelas miliarder bisa mendorong mesin slop yang dapat melempar orang ke jalanan

• Jika seorang developer senior A+ membuat fitur selama 8 bulan tetapi pada akhirnya tidak dirilis atau MVP-nya dibuang, maka developer senior A+ itu telah terbuang, dan produktivitasnya menjadi setara dengan dua engineer B+ yang ikut dalam proyek yang sama
  Ini sebenarnya masalah yang sangat umum, tetapi biasanya diabaikan dalam perekrutan atau alokasi sumber daya proyek. AI tampaknya tidak akan mengubah ini secara berarti
  Tim mungkin bisa menyelesaikan pekerjaan jauh lebih cepat, tetapi lapisan birokratis di atas kemungkinan besar tetap sama, dan kalau begitu keuntungan dari AI coding akan menjadi kecil. Agar cocok dengan AI, perusahaan harus dibangun ulang dari atas, dan itu hampir pasti tidak akan terjadi

  • Engineer cenderung terlalu melihat ini sebagai pemborosan. Investasi itu bukan terbuang; yang dibayar adalah opsi untuk bisa merilis fitur atau MVP tersebut, serta biaya riset untuk mengetahui apakah perilisannya memang masuk akal
  • Apa kamu yakin 8 bulan itu benar-benar hanya dipakai untuk “coding”? Ada desain, masukan dari tim produk, iterasi, dan sebagainya. Saya tidak tahu dari mana datangnya gambaran bahwa engineer A+ masuk sendirian ke bilik, lalu X bulan kemudian keluar dalam keadaan terisolasi sambil membawa MVP

• Dorongan AI di bagian akhir terasa aneh karena nyaris tanpa dasar. Tidak ada alasan, tidak ada tujuan, tidak ada klaim manfaat yang didukung apa pun; nadanya cuma “pokoknya pakai AI, developer harus menerima hal baru”
  Baru-baru ini saya juga membaca tulisan yang berpura-pura mengkritik AI dengan konteks singkat, tetapi akhirnya berubah menjadi iklan AI, dan tidak ada isi yang menghubungkan keduanya

  • AI adalah cloud yang baru. Tidak ada pasar bagi orang atau perusahaan yang tidak sepenuhnya berfokus pada AI. Developer yang menolak memakai AI tidak akan dipekerjakan oleh perusahaan mana pun, dan jika ada perusahaan memutuskan untuk tidak memakai AI, mereka akan kesulitan mempertahankan developer. Karena mereka akan membutuhkan lebih banyak developer
    Investor dan pelanggan besar juga akan berpikir ulang sebelum menandatangani kontrak besar
    Jadi AI harus digunakan. Jangan terlalu memperhitungkan biaya dan manfaatnya secara remeh. Dunia bergerak ke arah ini, dan jika ingin mencari nafkah dari pengembangan software, kamu juga harus berada di arah itu
  • Tetap saja, nilai AI lebih besar dari 0. Itu bukan pernyataan yang kontroversial

• Bagian “kali ini perbedaannya adalah kecepatan. Cloud masih bisa diterima terlambat beberapa tahun dan Anda tetap bertahan. AI mungkin cuma beberapa bulan” terasa aneh
  Penulis tampak mengerti bahwa klaim pro-AI dari perusahaan AI tentang betapa pentingnya produk mereka itu tidak bisa dibantah, tetapi lalu langsung mundur dengan nada “tunggu, jangan kira saya anti-AI”
  Bagaimana klaim di atas lebih ketat dibanding klaim produktivitas yang ia kritik di bagian lain tulisan? Maksudnya, kalau tidak mengadopsi AI dalam beberapa bulan Anda tidak akan bisa “bertahan”?
  Kalau CEO AI yang bilang pun itu bukan fakta, maka ketika orang yang menunjukkan omong kosong CEO AI mengatakan hal yang sama, itu juga tetap bukan fakta

  • CEO AI mengatakan itu untuk mengerek harga saham. Saya tidak pernah percaya CEO AI karena mereka membuat klaim yang tidak bisa diverifikasi tanpa dukungan apa pun
    Mengatakan bahwa orang di-PHK karena AI membuka ruang tafsir yang terlalu luas, dan memindahkan tanggung jawab dari diri sendiri ke AI. Secara realistis, kalau CEO melakukan sesuatu, jangan salahkan AI. Mereka sebenarnya bisa melatih ulang karyawan agar cocok dengan AI, tetapi tidak melakukannya. Kenapa? Mungkin karena penyebabnya memang bukan AI
  • Dia sedang membicarakan pertimbangan budaya yang terkait dengan kemungkinan untuk direkrut, bukan produktivitas
  • Saya penulisnya. Kritiknya masuk akal, dan terima kasih sudah membaca. Yang saya maksud dengan “beberapa bulan” itu bukan kelangsungan hidup perusahaan, melainkan kebiasaan kerja praktis individu, tetapi saya tidak menuliskannya dengan cukup jelas
    Saya benar-benar menulisnya sendiri, dan tidak membuatnya dengan “AI slop” seperti yang saya katakan di tempat lain, jadi mungkin bagian akhirnya memang menjadi “sloppy” secara manusiawi
    Benar bahwa saya tidak cukup mendukung bagian “tunggu” itu dengan dasar yang kuat, tetapi saya tetap berpikir orang-orang harus mencoba memakai AI. Bereksperimenlah, dan cari cara yang membantu diri sendiri. Bahkan di antara engineer yang mirip pun, spektrum cara mereka mendapatkan nilai dari AI sangat luas
    Biaya untuk benar-benar mencoba alat ini nyaris tidak ada, dan posisi “adopsi dengan sengaja dan ukur dengan metode membosankan yang sudah terbukti” tidak sama dengan “kalau tidak mengadopsi, Anda akan mati”
  • Memang benar orang mempertimbangkan motif di balik sebuah pernyataan. Dalam kasus ini saya rasa motifnya cukup berbeda sehingga ada perbedaan. CEO AI punya motif yang jelas untuk berbohong, sedangkan orang yang menyebutnya omong kosong tidak punya motif yang sama jelasnya

• Ketika perusahaan berkata, “AI telah membuat semua orang lebih produktif, jadi kebutuhan tenaga kerja berkurang,” secara implisit itu berarti perusahaan tidak ingin menjadi lebih produktif.
  Artinya mereka ingin produktivitas yang sama dengan lebih sedikit orang, dengan membayar lebih sedikit kepada segelintir orang yang lebih produktif.
  Mengapa ada ketimpangan antara uang yang diterima pemberi kerja per unit produktivitas dan uang yang diterima karyawan?

  • Karena tenaga kerja dieksploitasi untuk membuat pemilik semakin kaya. Itulah fakta dasarnya, dan kelas pemilik telah lama mendanai banyak propaganda untuk membenarkan dan menutupi hal itu.
  • Bukankah yang dimaksud bukan “produktivitas yang sama,” melainkan hasil output yang sama dengan lebih sedikit orang? Secara definisi, itu berarti produktivitas perusahaan meningkat. Produktivitas di tingkat perusahaan atau negara adalah rasio output dibagi input.
    Jika Anda mendapatkan output yang sama dengan lebih sedikit orang, maka produktivitas perusahaan atau negara membaik.
    Jika yang dimaksud adalah produktivitas yang sama dengan lebih sedikit orang, maka output juga akan turun sebanding, sehingga tidak ada keuntungan bagi perusahaan, dan jika ada biaya tetap, itu bahkan bisa lebih buruk.
    https://www.mckinsey.com/featured-insights/mckinsey-explaine...

• Menurut saya, jumlah baris kode tidak jauh berbeda dari lama waktu berada di kantor. Sebelum pandemi, orang selalu berkata, “Kalau tidak ada di kantor, bagaimana kita tahu mereka benar-benar bekerja?”
  Sederhana. Lihat saja apa kontribusi mereka pada bisnis melalui metrik output yang dipakai untuk menilai semua karyawan.

• Saya rasa para engineer juga sangat bertanggung jawab atas fakta bahwa jumlah baris kode masih diperlakukan seperti aset, bukan utang. Kita bangga pada apa yang kita buat, tetapi untuk menjelaskan seberapa “besar” sesuatu, kita butuh metrik, dan akhirnya kembali ke metrik yang paling mudah dihitung.
  Kita perlu mengubah istilahnya. Khususnya, kita harus lebih sering memakai ungkapan seperti, “...dan biayanya adalah N baris kode.” Kita juga harus mengatakan untuk apa baris-baris kode itu dipakai.
  “Kami mengimplementasikan fitur baru X, dan hanya butuh 200 baris.”
  “Bug itu benar-benar sulit ditemukan, tetapi pada akhirnya hanya butuh 6 baris kode.”
  “Dalam kasus X kami melakukan sesuatu yang berbeda dari kasus Y, tetapi ternyata pembedaan itu sendiri tidak diperlukan. Jadi sambil memperbaiki masalahnya, kami sekaligus menghemat 20 baris kode.”
  Baris kode adalah harga yang kita bayar. Kita tidak membanggakan telah menghabiskan 200 dolar tanpa mengatakan apa yang kita beli. Jadi mengapa kita melakukannya untuk baris kode?
  “Saya terlambat mendaftar jadi harus membayar 200 dolar ekstra” dan “Saya membeli gantungan lampu keramik buatan tangan yang dilukis tangan hanya seharga 200 dolar; versi buatan pabrik di Amazon harganya lebih dari 1.200 dolar” adalah dua pernyataan yang sama sekali berbeda, dan dalam kode perbedaannya persis sama.