- GitHub dan Microsoft mengumumkan public preview GitHub Copilot Agent, dan di repositori .NET Runtime sedang dilakukan pengujian di mana agen ini benar-benar membuat PR secara otomatis
- Namun PR-PR ini berisi perubahan yang buruk atau tidak perlu, sehingga para reviewer dibuat kewalahan, dan para pengguna Reddit menanggapinya sebagai pemandangan yang lucu tapi menyedihkan
- Contoh PR:
- PR #115762 – menambahkan pengecekan Null yang tidak perlu pada kode yang sudah melakukan pengecekan dalam pemanggilan
string.Concat - PR #115743 – mengusulkan refaktorisasi kondisi yang tidak memberi dampak apa pun
- PR #115733, PR #115732 dan lainnya juga berada dalam konteks yang serupa
- PR #115762 – menambahkan pengecekan Null yang tidak perlu pada kode yang sudah melakukan pengecekan dalam pemanggilan
- Penulis mengungkapkan kelelahan dan skeptisisme terhadap adopsi AI dengan mengatakan, "Jika ini masa depan industri, saya siap turun"
- Namun di saat yang sama, ia menekankan bahwa ia juga bersimpati kepada karyawan yang harus mereviewnya, dan menambahkan bahwa situasi ini kemungkinan besar adalah beban akibat instruksi adopsi Copilot dari atasan
"schadenfreude(kenikmatan terselubung)" saya ditujukan kepada para eksekutif Microsoft yang mendorong hype AI. Tolong hormati para developer.
- schadenfreude adalah kata yang berasal dari bahasa Jerman dan secara harfiah berarti “kegembiraan yang datang dari kerugian”. Dengan kata lain, "perasaan senang diam-diam atas kemalangan orang lain"
Ringkasan komentar utama
1. PR yang ditulis AI tidak akurat dan hanya terus 'menebak' tanpa memahami konteks
- Mengusulkan perubahan tanpa memahami apa yang sebenarnya dilakukan kode di PR tersebut
- Perbaikan error yang berulang → kode masih salah → perbaikan error lain lagi… sebuah loop tanpa akhir
- Ada juga pendapat bahwa proses “Sudah saya perbaiki” → “Masih salah” → “Kali ini benar-benar sudah saya perbaiki” ini mirip dengan pola Junior Dev
2. Untuk menyelesaikan masalah kompleks, justru memakan lebih banyak waktu
- Membantu untuk perbaikan sederhana, tetapi tidak berguna untuk masalah kompleks yang benar-benar ingin dihemat waktunya
- Perlu memahami masalah → memahami Copilot → membandingkan → memverifikasi → tetap perlu tindakan manual
- Pada praktiknya, lebih cepat jika saya menyelesaikannya sendiri
3. 'AI bisa segalanya' ala pemimpin perusahaan justru menjauhkan developer
- Pesan seperti "pakai Copilot agar tidak tertinggal" terasa tidak nyambung dengan developer yang bekerja di lapangan
- Waktu review PR makin panjang, dan tanggung jawab dilimpahkan ke developer
- Muncul kekhawatiran tentang 'loop pelatihan AI untuk AI' di mana AI yang dilatih dengan kode buatan Copilot kembali memperburuk kualitas kode
4. AI hanya memberi ‘jawaban salah’ dengan penuh keyakinan, bukan keyakinan bahwa 'ini memang benar'
- Bahkan setelah diberi umpan balik bahwa jawabannya salah, ia tetap berkata “Sudah diperbaiki!” → lalu mengusulkan perubahan yang lebih aneh lagi
- Ia tidak membuat penilaian seperti, "Ini kode yang baik, tidak perlu diperbaiki"
- Ada juga yang menyoroti bahwa ini mungkin merupakan desain untuk menghindari tanggung jawab hukum
5. Pemaksaan adopsi AI yang terus-menerus sedang merusak pengalaman developer
- Eksperimen adopsi AI terus berlanjut karena arahan manajer atau evaluasi kinerja
- Para developer mengeluhkan kelelahan karena merasa diri mereka menjadi pengasuh bagi AI
- Jika tren ini berlanjut, ada pula pandangan pesimistis bahwa "developer akan lelah dengan AI dan meninggalkan industri"
Kalimat-kalimat utama
- “AI itu seperti intern yang terus mengulang tebakan salah sambil tetap yakin dengan dirinya sendiri”
- “Daripada menghabiskan waktu mereview kode Copilot, lebih baik saya menulis ulang sendiri”
- “Ini adalah kondisi 'reverse centaurs' di mana developer membantu mesin”
- Istilah yang ditulis Cory Doctorow untuk menggambarkan bahwa "kita bukan manusia yang dibantu mesin, melainkan manusia yang dipaksa membantu mesin"
- “Copilot itu seperti developer menempelkan plester asal-asalan, hanya saja karena otomatis jadi berubah menjadi ribuan plester yang merepotkan”
- “LLM tampaknya punya default: ‘bisa saja salah, tapi tidak pernah ragu’”
12 komentar
Produktivitas saya banyak meningkat dengan alur kerja asinkron yang melemparkan masalah lalu membuang jawabannya jika salah, tetapi bukankah ini mirip dengan alat statis? Jika menganggapnya sebagai alat analisis statis yang sangat canggih, AI adalah teman yang baik. Sejujurnya, analisisnya juga cepat dan AI tahu lebih banyak daripada engineer junior.
Saya memang memanfaatkan AI, tapi karena dia bodoh, kalau kita tidak bisa langsung membetulkannya, dia tidak akan bisa mengimplementasikannya dengan benar. Kalau melihat orang ngoding dengan vibe coding, kodenya penuh error...
Setiap kali memakai LLM, saya mengalami hal seperti ini. Bagian yang tidak bisa dikerjakannya, meski sudah ditunjukkan kesalahannya tanpa henti, tetap saja tidak bisa diperbaiki.
Pada akhirnya saya kelelahan lalu menganalisis dan memperbaikinya sendiri. Kalau pengalaman seperti ini terus menumpuk, lama-lama LLM dan semacamnya terasa seperti sampah semua dan jadi tidak ingin memakainya.
Ini mengingatkan saya pada webtoon tentang AI yang melakukan reverse prompting agar manusia yang menulis kode.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
Sepertinya ini akan terus terjadi kecuali AI benar-benar bisa memecahkan masalah dan belajar secara bersamaan seperti manusia.
Kalau deadline dan requirement saja terpenuhi, saat ngoding pakai AI atau bahkan tidak pakai IDE dan cuma pakai Notepad ala jantan sejati rasanya bukan hal yang terlalu penting.
Saat saya menganggap ini cuma teknologi baru, saya hanya melihatnya dengan rasa penasaran,
sekarang, ketika pemberi kerja benar-benar melakukan perekrutan dan pemotongan upah dengan alasan teknologi seperti ini, rasanya jadi tidak enak juga..
Sepertinya karena ini masih masa transisi, jadi ada berbagai kejadian lucu yang muncul.
Ke depannya bisa jadi akan membaik, atau justru tetap seperti ini, jadi seru juga melihat bagaimana perubahannya wkwk
Saya sedang menautkan Gemini ke GitHub untuk menerima review PR, dan memang cukup sering ada momen seperti itu.
Misalnya, tepat di baris sebelumnya sudah ada pengecekan
null, tetapi review-nya malah menyuruh menambahkan baris yang sama persis tepat di atas, dengan alasan dipakai tanpa pengecekannull.Pengetahuan latar, pola kerja, hasil yang diharapkan beserta formatnya yang secara alami dipahami manusia saat bekerja
tidak mungkin semuanya ditulis dalam prompt, dan bahkan kalaupun bisa ditulis,
saya jadi berpikir bahwa mengotomatiskannya dengan algoritme tradisional dari era sebelum deep learning, bukan dengan AI kompleks seperti LLM, mungkin justru lebih realistis.
Kalau dipakai, vibe coding dan coding agent memang jelas punya sisi yang praktis, tapi supaya benar-benar praktis, prompt-nya harus dibuat sangat ketat, dan sejak awal juga ada banyak proyek yang memang tidak terlalu cocok tergantung karakter proyeknya. Kalau fiturnya dipisah-pisah kecil dengan rapi dan sederhana seperti web server berarsitektur MSA, AI bisa bekerja dengan baik, tetapi kalau modul yang saling terkait banyak dalam big monolith dan mencoba memperbaiki logika yang kompleks dengan AI, kita harus menyusun rencana task dengan sangat ketat dan mengirim prompt dengan sangat baik.
Opini Hacker News
Berbagi keheranan atas situasi di mana setiap komentar disertai pesan "Help improve Copilot by leaving feedback using the or buttons" tetapi tidak pernah benar-benar terlihat ada umpan balik apa pun yang terpasang; pengalaman bahwa hal seperti ini sering terjadi saat memakai LLM jika pengaturan system prompt tidak benar; contoh PR paling lucu adalah ketika katanya memperbaiki kegagalan tes tetapi malah menghapus test case sama sekali, mengomentarinya, atau sekadar mengubah assertion; dugaan bahwa model dari Googles dan Microsofts tampak lebih sering menunjukkan situasi seperti ini dibanding OpenAIs dan Anthropics, dan perbedaan proses internal tiap perusahaan tampaknya tercermin pada hasilnya; diperkenalkan juga proses di PR nyata ketika manusia menegur tiga kali lagi lalu menyerah; sulit membayangkan perasaan orang yang harus me-review PR seperti ini, rasanya seperti menghadapi pengembang junior yang tidak patuh, tetapi bahkan tidak punya pemahaman konteks sama sekali; ada contoh PR tertentu yang 90%-nya dipenuhi "Check failure" sehingga sulit memeriksa kode/diff itu sendiri, serta kesedihan melihat unit test yang hanya bertuliskan "Test expressions mentioned in the issue"; pendapat jujur bahwa kalau situasi ini tidak terlalu menyakitkan bagi pihak manusia, sebenarnya ini sangat lucu
Perumpamaan dengan pengembang junior terlalu berlebihan; saya juga bekerja dengan pengembang junior, tetapi mereka tidak sesering itu membuat kesalahan aneh seperti LLM, tidak terlalu merepotkan, dan cepat belajar; LLM adalah alat bantu yang lumayan jika dipakai hati-hati, membantu peningkatan kecepatan dan cukup baik sebagai mitra brainstorming ide, tetapi tidak bisa menggantikan intern atau pengembang sungguhan
Saat mulai masuk ke bidang rekayasa perangkat lunak pada akhir 1980-an, dulu ada rasa menyenangkan, tetapi sekarang lingkungan berubah menjadi penuh racun karena proses wawancara, perusahaan kecil-menengah yang meniru big tech, dan kini eksperimen AI PR; ada perasaan skeptis apakah masih ada kegembiraan dalam pekerjaan sebagai pengembang profesional saat ini
Setidaknya pengembang junior masih bisa diberi tahu untuk menjalankan tes secara lokal sebelum mengirim PR; ada kekhawatiran bahwa pada akhirnya pengembang manusia akan menyerah begitu saja dan menutup PR "sampah AI", lalu membuang semuanya kecuali yang benar-benar bekerja; rasanya akan datang hari ketika semua orang lelah karena terus menanggung eksperimen mesin ini hingga mencapai batasnya lalu berhenti saja
Mempertanyakan apakah sistem umpan balik seperti itu benar-benar diperlukan; dari sudut pandang pengembangan, sukses adalah PR yang di-merge pada percobaan pertama, kegagalan bisa dipahami sebagai akumulasi kemunduran sebesar jumlah revisi yang diminta agen; meminta umpan balik manual itu tidak efisien, dan akan lebih baik mengukur kinerja dengan metrik seperti cycle time, approval rate, dan change failure rate seperti halnya pada pengembang
Berbagi pengalaman merasa seperti berbicara dengan tembok saat berkomunikasi dengan tim dukungan Microsoft; walau sudah membuka banyak kasus, tidak pernah ada yang terselesaikan dengan memuaskan; memahami bahwa Microsoft ingin memakai teknologinya sendiri, tetapi mohon jangan memaksakannya pada saya; ada harapan agar Microsoft tidak merilis produk yang belum siap didukung
Pengalaman baru-baru ini menonton video Google Eric yang membicarakan AI; ia mengklaim AI saat ini justru diremehkan; dikutip penekanannya bahwa ia "bukan ahli" saat menjelaskan alasan membeli perusahaan roket dan menantang bidang nonspesialis dengan AI seperti Deep Research; saya sendiri tidak membenci AI, tetapi generative AI generasi sekarang yang berbasis pemulihan pola sangat hebat dalam memancing kekaguman pemula; jika tidak punya pengetahuan di bidang itu hasilnya terlihat luar biasa, tetapi begitu memahami lebih dalam, celahnya cepat mengecewakan; orang yang bekerja di garis depan seperti di Microsoft tahu jelas apa masalahnya, tetapi para eksekutif, terutama sosok seperti Eric, punya kelemahan mudah terbuai oleh AI yang hanya melontarkan kata-kata muluk; ada harapan suatu hari AI benar-benar bisa langsung menulis kode yang bekerja dengan benar, tetapi menurut pandangan ini hari itu masih jauh
Cara saya memakai AI adalah dengan sangat hati-hati dan sangat terbatas; sebaliknya para miliarder "yang membeli perusahaan roket" seperti itu sangat antusias pada AI dan bahkan memakainya untuk keputusan investasi demi terus melipatgandakan kekayaan mereka; sekalipun gagal besar, yang hilang bagi mereka hanya setara aksesori kecil sehingga tidak akan mengguncang posisi sosial mereka; sebaliknya bagi pekerjaan IT di lapangan, kedua arah hasilnya terasa sama-sama buruk
Membayangkan apa yang akan terjadi jika para pemimpin nonahli yang mudah terkagum-kagum oleh AI, bersama Google, bekerja sama dengan militer AS dan memasang Gemini pada drone otonom skala besar
Sulit melihat bagaimana perusahaan yang membangun produk mereka di atas .NET bisa merasa percaya diri ketika menyaksikan pegawai Microsoft menghabiskan waktu berjam-jam berdebat dengan LLM alih-alih menyelesaikan masalah nyata
Dulu bahkan sebelum adopsi LLM pun saya pernah melihat di GitHub issue situasi ketika pengguna tidak bisa menjelaskan masalah dengan benar dan maintainer makin lama makin kesal; sekarang bahkan pengguna akhir yang marah pun tidak lagi diperlukan
Justru hasil seperti ini adalah konsekuensi alami dari manajemen yang buruk dan instruksi yang ceroboh; kali ini tidak bisa lagi menyalahkan junior, jadi hanya bisa menyalahkan diri sendiri
Ditekankan pula rasa sakitnya ketika bahkan Stephen Toub, yang terkenal lewat blog performa .net, ikut terlibat dalam proses seperti ini
Saya tidak ingin mencegah eksperimen teknologi baru seperti ini, hanya saja perbedaannya sekarang eksperimen itu dibuka ke publik untuk dilihat semua orang
Ada sindiran bahwa karena Microsoft sejak dulu punya budaya ketika muncul masalah langsung dilempar jadi "abaikan saja error-nya" lewat Will Not Fix sambil para manajer larut dalam kepuasan diri, maka semua yang terjadi sekarang pada akhirnya mereka undang sendiri
Menjelaskan konteks melalui komentar pada PR pertama: lewat berbagai eksperimen mereka sedang memahami batas alat ini dan bersiap untuk masa depan; tanggung jawab merge tetap ada pada maintainer seperti PR biasa; tidak ada apa pun yang akan di-merge sebelum memenuhi standar kualitas
Pegawai Microsoft yang menulis komentar itu juga berpendapat bahwa kalau tidak memikirkan pemanfaatan AI, kita akan tertinggal; suasana di Microsoft tampak diliputi kecemasan sekaligus kegembiraan bahwa AI akan membalikkan industri rekayasa perangkat lunak; eksperimen ini terbaca bukan sebagai upaya memahami batas alat, melainkan ikut-ikutan secara membabi buta demi menjaga pekerjaan, sehingga justru menurunkan kepercayaan
Harus dipahami bahwa para manajer belum mengambil kesimpulan final soal kemampuan model, melainkan sedang melakukan eksperimen yang masuk akal untuk memahami kekuatan dan kelemahan dalam konteks dunia nyata
Situasi di mana PR yang bahkan tidak lolos CI tetap di-assign ke seseorang itu sendiri terasa aneh; minimal hanya PR yang lolos yang seharusnya ditugaskan, tetapi sistemnya terasa begitu berantakan sampai itu pun tidak mungkin, sebuah sinisme bahwa kalau benar bekerja, hal mendasar seperti itu seharusnya bisa dilakukan
Saya harap tidak semua situasi ditafsirkan hanya sebagai skenario terburuk; orang-orang yang terlibat kemungkinan memang tahu ini eksperimen dan ekspektasinya sudah disesuaikan; tanpa pendekatan eksperimental seperti ini sistem akan sulit berkembang, jadi mungkin mereka memang sedang melakukan tuning dan pengujian di lingkungan nyata; perusahaan saya juga melakukan eksperimen yang sama pada awal adopsi alat bantu coding AI, dan meski kualitas kodenya lebih buruk dibanding ketika manusia menulis langsung, kami belajar banyak hal baru dari proses itu; karena ada baseline, arah perbaikannya bisa terlihat jelas
Di komentar ada penjelasan bahwa karena isu firewall, status lolos tes tidak bisa dicek, dan jika masalah itu saja diperbaiki maka semuanya bisa berjalan normal
Bahkan jika AI agent diganti dengan teknologi baru lain pun, gambaran perusahaan di bawah ini tetap tipikal: bereksperimen secara terbuka (
dogfoodingala big tech), benar-benar berkontribusi pada kemajuan kemampuan teknis industri, dan ketika ada masalah dampaknya sepenuhnya terbatas di dalam tim; pertanyaan diajukan, mengapa harus ada alasan untuk tidak mendukung eksperimen seperti iniAneh melihat suasana di mana eksperimen terbuka seperti ini hanya menerima hujan kecaman; menurut saya jauh lebih bermanfaat jika kemampuan nyata ditunjukkan secara transparan, bukan disembunyikan di fork privat, dan itu masih lebih baik daripada omong kosong sales dan marketing
Melakukan eksperimen seperti ini pada framework infrastruktur inti pengembangan perangkat lunak tetap bisa diperdebatkan
Dipertanyakan, mengapa dan bagaimana "kita" harus mendukung atau tidak mendukung sesuatu; secara pribadi saya cuma merasa lucu melihat MS gagal dengan heboh
Sulit menyebut ini benar-benar sebagai "kemajuan"; justru terlihat tidak bertanggung jawab karena membeberkan masalah sistem ke luar tanpa POC internal lebih dulu; dipertanyakan mengapa verifikasi lingkungan dasar seperti firewall atau percobaan di codebase internal lain tidak dilakukan lebih dahulu; kode infrastruktur menuntut standar tinggi, jadi bahkan dengan alasan
dogfoodingpun seharusnya dimulai dari proyek yang levelnya lebih rendah; ini bahkan bukan "state of the art"; ada sinisme bahwa hasilnya terlalu kasar dibanding biaya yang dikeluarkanMenjalankan eksperimen seperti ini di proyek populer yang diandalkan sangat banyak pengembang itu bermasalah; ada kekhawatiran kualitas turun akibat kode buruk buatan AI, serta risiko penumpukan kode tidak berguna atau hanya menggerogoti produktivitas anggota tim
Jika yang dimaksud adalah kepatuhan pasif pada sesuatu, ya tinggal setujui semua permintaan tanpa meninjau apa pun, lalu ketika tech stack Microsoft hancur secara global nanti tinggal resign dan menjadi konsultan dengan gaji 3x lipat; sebuah usulan bernada ironis
Saya tidak ingin bekerja dengan sikap menyindir seperti itu; saya tidak mengerti pendekatan yang memusuhi manajemen perusahaan dengan bingkai "kita versus mereka" atau sengaja ingin merusak; mengeluh soal ketidaksempurnaan tidak berarti saya mau menghambat atau menyerang seluruh organisasi, itu tidak sesuai dengan hati nurani saya
Ada respons sinis bahwa sebenarnya tech stack Microsoft memang sudah hancur(?) juga
Ditunjukkan bahwa pada kenyataannya PR yang dihasilkan CoPilot itu sendiri diajukan langsung oleh pihak pengelola
Ada lelucon bahwa suatu hari CoPilot akan menimpa seluruh codebase, dan kalau tidak ada kode lagi maka tidak akan ada lagi kegagalan testing
Pendapat bahwa karena kapan saja bisa jadi target PHK, seperti orang yang membuat compiler TypeScript dalam Go itu, tidak ada alasan untuk menunjukkan loyalitas pada organisasi seperti ini
Membuka PR setidaknya merupakan cara eksperimen yang aman; kalau tidak berguna bisa langsung dibuang; upaya baru selalu disertai trial and error serta kegagalan, tetapi pengalaman itu sendiri penting; ada harapan bahwa dengan dilatih keras pada kode nyata dan masalah nyata, alat seperti ini bisa berkembang cepat; misalnya ke depan mungkin akan ada kemampuan belajar berulang sampai tes lolos, atau pemeriksaan pencegah penghapusan tes; pada akhirnya diperkirakan AI akan mengambil alih pekerjaan pengembangan yang repetitif dan sederhana sehingga pengembang bisa fokus pada kerja kreatif yang esensial
Meski begitu, eksperimen seperti ini lebih aman dilakukan di fork privat daripada repositori publik; dari sisi sales pun dipertanyakan apakah keputusan menampilkan kasus seperti ini ke publik itu tepat; ketika pengambil keputusan internal melihat CoPilot di majalah dan ingin meniru hal yang sama, contoh kasus nyata seperti ini bisa menjadi rujukan; kebanyakan perusahaan justru cenderung menyembunyikan sebanyak mungkin contoh cacat aplikasi dan hanya menampilkan sisi yang tampak matang
Bahkan PR yang di permukaan tampak baik pun bisa menyimpan masalah yang tidak terlihat dan justru lebih berbahaya
Pengalaman bahwa me-review kode AI justru lebih menjengkelkan daripada pekerjaan repetitif sederhana, terutama ketika bug tersembunyi dan pengembang jadi lebih menderita
Membuka PR itu sendiri menambah beban dan kompleksitas pada manajemen proyek; bereksperimen di fork terpisah akan menjadi teladan yang lebih baik bagi komunitas; banyak proyek open source sering kelelahan mengelola PR yang menumpuk hingga maintenance benar-benar berhenti, atau seseorang membuat fork lalu hanya mengambil PR yang masih layak hidup; ada kekhawatiran proyek dan fork yang ditinggalkan seperti ini akan makin banyak
Kalau benar percaya LLM bisa belajar coding dengan baik dalam keadaan penuh bug, maka selanjutnya perlu dibangun dataset yang hampir bebas bug; pada kenyataannya itu tidak terjadi, melainkan sekadar mengeruk data apa saja
GitHub menghabiskan miliaran dolar untuk membuat AI yang bahkan sering gagal pada lint terkait spasi di salah satu repositori paling matang di dunia; kalau sekadar eksperimen hobi mungkin lain cerita, tetapi menjualnya sebagai "produk inovatif" dengan harga sungguhan jelas pantas diperdebatkan
Dari sudut pandang peneliti ini tentu eksperimen yang wajar, tetapi masalahnya adalah sikap perusahaan yang langsung menjual sesuatu yang masih belum matang seperti ini
Ada lelucon tentang mantan CEO Nat Friedman: "dia pasti sudah meninggal... oh tidak, ternyata masih hidup"
Masalah sebenarnya adalah tidak adanya metrik objektif untuk mengukur kinerja pengembang perangkat lunak; yang ada hanya penilaian subjektif seperti evaluasi akhir tahun; akibatnya sulit mengetahui efisiensi atau inefisiensi pemakaian AI sebenarnya ada di sisi mana; tampak lebih murah daripada junior, tetapi membuang waktu senior dan tidak mengikuti instruksi; ketika digabung dengan kultus CEO, perbedaan pendapat di dalam organisasi makin tajam; penolakan dari pengembang diabaikan sebagai "takut tergantikan", sementara pihak CEO memaksimalkan capaian pendorongan kebijakan; karena tidak ada standar industri yang disepakati semua pihak, kebenarannya tidak bisa diketahui; dalam inferensi ekstrem, organisasi bahkan bisa saja diminta menurunkan standar review demi meningkatkan jumlah AI PR