AI membuat pengembang open source lebih lambat. Peter Naur bisa menjelaskan alasannya

• Menurut riset terbaru, ketika pengembang open source menggunakan alat AI pada codebase yang sudah sangat mereka kenal, waktu pengerjaan justru bertambah 19%
• Para pengembang percaya AI membuat mereka lebih cepat, tetapi pada kenyataannya justru lebih lambat, menunjukkan kesenjangan antara persepsi dan realitas
• Penyebab utamanya adalah model mental (struktur pemahaman) yang sangat terperinci yang dimiliki pengembang dan keterbatasan transfer pengetahuan ke AI
• Menurut teori Peter Naur, hal terpenting dalam pemrograman bukanlah kode, melainkan "model mental" di kepala pengembang
  • Pelopor ilmu komputer dari Denmark dan penerima Turing Award 2005. Berkontribusi pada notasi Backus-Naur Form (BNF) yang digunakan untuk menjelaskan sintaks bahasa pemrograman
• Dari perspektif jangka panjang, untuk memahami proyek secara mendalam, penting untuk membangun model mental dengan menulis kode secara langsung

---

Fenomena AI yang membuat pengembang open source lebih lambat

• Menurut riset Metr, penggunaan alat AI justru menghasilkan penyelesaian masalah yang 19% lebih lambat
• Sebelum mulai bekerja, para pengembang memperkirakan AI akan membantu mereka 24% lebih cepat, dan setelah selesai pun mereka tetap percaya bahwa mereka bekerja 20% lebih cepat dari kenyataannya
• Riset ini dilakukan terhadap pengembang berpengalaman yang mengelola langsung proyek open source yang mereka pahami secara mendalam
• Hasilnya tidak bisa digeneralisasi ke semua pengembang, tetapi untuk kelompok ini, riset tersebut menunjukkan bahwa alat AI berdampak negatif pada produktivitas
• Di lingkungan perusahaan, atau bagi pengembang pada umumnya yang harus beradaptasi dengan codebase baru, alat AI bisa berperan lebih positif dalam meningkatkan produktivitas

Mengapa AI membuat pengembang open source berpengalaman lebih lambat

• Menurut makalah Peter Naur, “Programming as Theory Building”, hasil sejati dari pemrograman bukanlah kode, melainkan ‘model mental pengembang tentang proyek’
• Model mental ini adalah inti dari pemahaman sistem, diagnosis masalah, dan perbaikan yang efektif
• AI berbasis LLM tidak dapat mengakses langsung model mental pengembang, dan meskipun sebagian informasi dapat diberikan, tetap terjadi kehilangan esensial dalam proses transfer pengetahuan
  • Sebagai contoh, ketika seseorang diminta menidurkan bayi, meskipun instruksinya dijelaskan dengan jelas, sering kali tindakannya tetap berbeda dari yang dimaksud
• Transfer model mental sangatlah kompleks, dan hampir mustahil bagi AI untuk menyerapnya hanya dari teks
• Karena itu, mendelegasikan pekerjaan ke AI dalam proyek yang sudah sangat dipahami justru menurunkan produktivitas
• Informasi konteks yang kaya dan pemahaman intuitif milik pengembang tidak mudah digantikan oleh AI

Apakah alat AI harus dilarang di dunia kerja?

• Tidak harus. Ini hanya berlaku untuk “orang yang bekerja pada proyek yang benar-benar mereka kenal dan pahami”
• Banyak pengembang di perusahaan sering kali memelihara kode dari senior yang sudah pergi, atau bekerja tanpa memahami struktur keseluruhan sistem secara mendalam
• Dalam lingkungan seperti ini, AI dapat membantu meningkatkan produktivitas jangka pendek dengan memahami codebase dengan cepat dan menghasilkan perubahan secara otomatis
• Jika yang dilihat hanya penciptaan nilai bisnis jangka pendek dan efisiensi langsung, alat AI bisa berperan positif terhadap produktivitas

Membangun model mental dan AI

• Jika Anda belum memiliki model mental tentang proyek, LLM dapat membantu meningkatkan produktivitas
• Namun, jika esensi pengembangan perangkat lunak adalah ‘membangun model mental’, maka ketergantungan berlebihan pada AI dapat menurunkan kemampuan tersebut
• Dalam jangka panjang, jika ingin memahami proyek secara mendalam dan mengubahnya secara aktif, pengalaman menulis kode secara langsung tetap diperlukan
• Sebaliknya, untuk pekerjaan yang sekadar ‘membuatnya berjalan’, pemanfaatan AI bisa lebih efisien

Diskusi tambahan dan kesimpulan

• Pada tingkat AI saat ini, masih sulit meningkatkan produktivitas pengembang yang sudah memiliki model mental yang memadai
• Arah agar AI dapat benar-benar mendukung model mental atau secara revolusioner meningkatkan produktivitas pengembang berpengalaman masih membutuhkan penelitian dan pengembangan lebih lanjut
• Di masa depan, ketika model semakin berkembang, mungkin akan datang hari ketika pengembang manusia tidak lagi perlu memiliki model mental, tetapi pada tingkat saat ini, pemahaman dan pembelajaran langsung tetap esensial
• Pada akhirnya, AI bisa menjadi gangguan dalam lingkungan di mana saya benar-benar memahami apa yang sedang saya kerjakan, dan bisa menjadi alat produktivitas dalam lingkungan di mana hasil cepat lebih penting

[paruaa]

> Para developer percaya AI membuat mereka bekerja lebih cepat,
Karena riset dengan memanfaatkan AI menjadi lebih cepat, kualitas hasil juga bisa ditingkatkan, jadi bukankah untuk pekerjaan yang sama kualitasnya akan sedikit lebih baik? Mungkin para developer berpikir bahwa untuk mengembangkan sesuatu sesuai kualitas hasil akhir setelah pekerjaan selesai, dibanding mencapainya sendirian, akan lebih cepat jika mencapainya dengan bantuan AI.
Kalau sejak awal tidak memakainya, mungkin hasilnya diimplementasikan hanya dengan pengetahuan yang lebih terbatas, jadi saya jadi berpikir mungkin memang karena itu.

[tested]

> Sebaliknya, jika pekerjaannya sekadar ‘yang penting bisa jalan’, memanfaatkan AI bisa jadi efisien.

Bukan hanya developer tentu saja, tapi karena ada banyak orang dengan kecenderungan yang berbeda-beda, saya merasa bahwa orang yang kebetulan bekerja sebagai developer namun tidak suka atau takut menulis maupun melihat kode, dan yang pola pikirnya lebih ke yang penting berjalan daripada menafsirkan struktur yang sistematis atau sudut pandang maintainability, cenderung lebih kuat ketergantungan atau kepercayaan membutanya pada AI. Bisa jadi saya salah juga.

[xguru]

Mengukur "dampak AI" terhadap produktivitas pengembang open source berpengalaman

[GN⁺]

Pendapat Hacker News

• Hai HN, saya adalah penulis makalahnya.
  Saya rasa tulisan blog tersebut dengan menarik membahas satu faktor spesifik yang dapat membuat AI memperlambat kecepatan pengembangan.
  Ada juga kutipan dari para pengembang di makalah itu (bagian C.1.5), jadi silakan lihat.
  Banyak orang membaca makalah itu, menemukan satu faktor yang terasa relevan, lalu mudah menyimpulkan bahwa “masalah satu inilah alasan perlambatan.”
  Namun kenyataannya ada banyak faktor (setidaknya 5 yang kuat, dan sampai 9 masih belum bisa dikesampingkan; lihat tabel faktor di hlm. 11).
  Analisis penyebab yang multiaspek lebih masuk akal daripada mengasumsikan satu penyebab tunggal.
  Jika ada yang berencana bereksperimen sendiri, saya berharap hasilnya dibagikan melalui email yang tercantum di makalah.
  Dan soal judul artikel yang ditulis sebagai “AI slows down open source developers. Peter Naur can teach us why”, menurut saya yang lebih akurat kira-kira adalah “Pada awal 2025, AI memperlambat pengembang open source berpengalaman. Peter Naur memberi konteks tambahan tentang faktor tertentu.”
  Mungkin ungkapannya jadi kurang sensasional, tetapi saya rasa akurasi itu penting.
  Sekali lagi terima kasih untuk tulisan yang bagus ini, dan saya juga terus membaca komentar-komentarnya
  Diskusi terkait sebelumnya
  Makalah lengkap
  • Ada satu hal yang secara pribadi membuat saya penasaran: dalam penelitian ini, bagaimana tepatnya perubahan waktu pengerjaan sebelum dan sesudah memakai AI diukur secara andal? Apakah pengembang diminta memperkirakan seberapa banyak waktu akan berkurang setelah memakai AI, lalu waktu aktualnya diukur untuk melihat selisihnya? Dan ketika tingkat kesulitan isu atau estimasi waktu penyelesaiannya sulit ditentukan, bagaimana tim riset mengendalikan hal itu? Saya paham pengukuran seperti ini memang sangat rumit
  • Saya setuju dengan hasilnya dan berterima kasih atas jawabannya. Saya suka gaya judul yang lebih radikal jadi belum berencana mengubahnya, tetapi saya akan memperjelas di artikel bahwa frasanya memang kurang tepat. Saya juga menyebutkan bahwa faktor-faktor kontributor utama hasil riset yang saya tulis—“tingginya familiaritas pengembang terhadap repositori”, “repositori yang besar dan kompleks”, “konteks repositori yang implisit”—selaras dengan penelitian ini. Saya juga ingin melakukan eksperimen serupa pada diri sendiri, tetapi terasa sangat sulit membuat lingkungan yang terkontrol sambil tetap memenuhi tuntutan pekerjaan. Saya juga kekurangan daftar tugas yang jelas dan bisa diselesaikan dalam waktu singkat
  • Jika alur kerja yang sudah dioptimalkan di proyek yang sangat kita kenal diubah, saya memang akan menduga pada awalnya jadi lebih lambat. Yang penting adalah melihat bagaimana keadaan para pengembang ini setelah 6 bulan atau 1 tahun. Studi ini tidak menunjukkan tren jangka panjang, jadi saya berharap penelitian berikutnya bisa memberi tahu bagaimana performa pengembang yang sama setelah mereka terbiasa. Saya sendiri juga merasakan bahwa dengan AI saya bisa membuat skrip untuk banyak pekerjaan yang dulu sulit diotomatisasi. Kita harus selalu bertanya, “apakah ini sepadan dengan waktu yang dihabiskan?”
    Komik manajemen waktu xkcd
  • Disebutkan juga bahwa ungkapan “pada awal 2025 AI memperlambat pengembang open source berpengalaman” pun terlalu menggeneralisasi. AI juga bisa menghemat waktu pada tugas-tugas tertentu, jadi efeknya berbeda tergantung jenis pekerjaannya
  • Menjadi lebih lambat belum tentu buruk; pemrograman yang lambat (literate programming/gaya Knuth) justru bisa lebih membantu dalam teorisasi. Ada juga argumen bahwa yang penting adalah pengembangan yang lambat namun matang, dengan cukup pemikiran dan abstraksi, bukan pemrograman ala fast food
• Saya setuju dengan fenomena bahwa “pengembang tidak benar-benar tahu apakah sebuah alat membuat mereka lebih cepat atau justru lebih lambat.” Dipakai contoh perahu yang menyimpang dari tujuan karena angin dan arus: kita hanya mengenali kemajuan berdasarkan pergerakan di sekitar kita saat ini, dan sulit merasakan secara intuitif apakah kita benar-benar mendekati tujuan. Karena itu kita cenderung memilih strategi yang membuat kita merasa “sedang maju”, dan ini kadang membuat kita mengambil jalur yang tidak efisien atau malah lebih lambat secara nyata (misalnya saat menyetir sering belok kanan untuk memutar)
  • Saat pertama kali memakai alat AI, rasanya enak karena tidak banyak hambatan sehingga pekerjaan terasa terus berjalan. Tetapi dalam praktiknya, bahkan ketika memperbaiki satu baris secara manual lebih cepat, saya jadi terbiasa memanggil AI. Mirip analogi menyetir: begitu satu jalan terasa macet, kita mudah terus kembali ke jalur yang direkomendasikan ulang seperti GPS
  • Ini mirip aplikasi navigasi seperti Waze yang sebenarnya mengarahkan ke rute lebih panjang, tetapi karena banyak jalan memutar yang saling terkait, kita merasa sedang “terus bergerak” sehingga terasa lebih cepat. Alat AI juga terasa mempermudah pemrograman, padahal produktivitas nyata bisa menurun. Manusia mudah hanya mengingat pengalaman jangka pendek yang terasa lancar tanpa rasa sakit, lalu mengira itu berarti ada kemajuan
  • Pada akhirnya manusia secara naluriah menyukai greedy algorithm
  • Pengguna Linux/Unix menganggap kontrol keyboard dan alat CLI adalah efisiensi tertinggi, tetapi ada hasil penelitian yang menunjukkan bahwa untuk kebanyakan pekerjaan, mouse justru lebih cepat. Alasan kita merasa mengetik lebih cepat adalah karena jumlah aksi per detik lebih banyak
  • Kode yang dihasilkan AI hampir tidak pernah direview, dan banyak pengembang memang sudah kesulitan dengan code review itu sendiri sampai enggan membaca. Karena itu muncul fenomena framework baru dan penulisan ulang kode yang populer
    Joel on Software: Things you should never do, part I
    Banyak kode hasil AI hanya dibuat, diuji secara sederhana, lalu selesai. Bahkan sering kali itu menjadi kode yang penulisnya sendiri pun tidak benar-benar memahami konteks keseluruhan atau alasannya
• Inti studi ini bisa diringkas sebagai “AI membuat ilusi bahwa peningkatan produktivitas lebih besar daripada kenyataannya.” Hanya sebagian peserta yang mendapat sedikit peningkatan produktivitas, sementara mayoritas justru turun cukup banyak. Ada banyak orang yang berkata produktivitas mereka meledak berkat AI, tetapi wawasan studi ini—bahwa efek itu sendiri bisa jadi ilusi—sering diabaikan. AI adalah produk yang dioptimalkan agar pengguna merasa perlu memakainya dan percaya bahwa itu berguna. Nilai pribadi memang merupakan realitas yang dirasakan sehingga sulit disangkal, tetapi orang yang sangat bergantung pada AI benar-benar perlu waspada terhadap distorsi kesadaran diri, rasa pencapaian palsu, dan ketergantungan pada alat. AI memang menjawab dengan aliran token yang dioptimalkan, tetapi menurut saya kita perlu sesekali memikirkan apa sebenarnya tujuan optimasi yang sesungguhnya
  • LLM memang membantu saat mempelajari sesuatu, tetapi pemahamannya terasa sangat abstrak dan khas gaya LLM. Saat belajar, saya rasa lebih baik mencampur berbagai metode
  • Alat AI membuat pengembang merasa bukan “lebih cepat” melainkan “gesit sesaat.” Ada sisi ilusi seperti beban otak berkurang; ini semacam efek persepsi yang menarik karena rasa kemajuannya berubah di loop umpan balik lain, dan mekanisme pembentukan ingatan juga ikut berubah
• Saat mendiskusikan studi bahwa “pengembang open source berpengalaman justru melambat ketika memakai AI saat mengerjakan proyek mereka sendiri”, saya kebetulan sedang bekerja pada codebase buatan orang lain yang baru berumur 3 bulan dan framework yang tidak saya kenal. Dengan memanfaatkan Claude Code, hanya dalam beberapa jam saya bisa menyelesaikan pekerjaan seperti sinkronisasi data yang di proyek lain dulu butuh satu-dua hari, atau bahkan sampai dua minggu, dan itu benar-benar memberi lompatan awal yang besar. Mungkin akan makin lambat saat kompleksitas meningkat, tetapi saya terkejut betapa cepatnya memulai dengan bantuan alat itu
  • Saya juga punya pengalaman serupa, tetapi yang dibicarakan penelitian ini bukan masa ramp-up yang kita alami, melainkan saat pengembang open source yang sudah sangat familier mengerjakan tugas dengan AI. LLM memang jelas mempercepat adaptasi ke codebase baru, tetapi setelah benar-benar terbiasa, saya merasa justru jadi mengganggu
  • Setiap kali ada klaim seperti “PR yang butuh 2 minggu jadi cuma beberapa jam”, cerita peningkatan produktivitas selalu ikut muncul, tetapi menurut saya jarang sekali kita memeriksa seberapa akurat sebenarnya prediksi durasi pengembangan kita. Selain itu, kita juga perlu mempertanyakan apakah kualitas PR yang dibuat terburu-buru ini benar-benar sesuai harapan awal, atau justru karena mengejar kecepatan sampai melewatkan konteks sistem penting sehingga peluang bug meningkat. Tanpa AI pun, kalau kualitas dikorbankan, pekerjaan memang bisa lebih cepat
  • Saya juga ragu apakah berkat AI tingkat penguasaan codebase dan sistem secara rata-rata benar-benar meningkat secara alami. Efek belajar saat memakai LLM terasa seperti bisa membaca bahasa baru, tetapi sulit menulisnya sendiri dari nol. Ambil contoh C++: membaca dan mengubah yang sudah ada mungkin bisa, tetapi mulai membangun sesuatu dari awal jauh lebih sulit
  • Yang saya maksud hanya bahwa saya mendapat jumpstart yang besar berkat alat AI, bukan kritik terhadap penelitian, artikel, atau makalahnya. Saya cuma ingin mengatakan bahwa dalam konteks tertentu AI benar-benar membantu. Bukan hanya menulis kode; misalnya Claude Code juga mencoba langsung menghubungkan ke klaster AWS dari container internal proyek, dan itu sangat membantu memahami keseluruhan infrastruktur dan strukturnya. Dalam pengalaman saya, pada 80–90% kasus yang diprioritaskan adalah “nilai bisnis”, bukan kualitas kode. Saya tidak tahu seberapa berguna ini untuk pekerjaan yang kualitas kodenya benar-benar penting, atau bidang yang memerlukan algoritme dan struktur data khusus. Tetapi saya juga pernah melihat bahwa jika diberi contoh yang baik dan konteks yang jelas, AI bisa menulis kode yang cukup layak. Alat-alat ini berkembang cepat setiap minggu atau setiap bulan. Pada akhirnya AI bukan sihir, melainkan alat, dan tanggung jawab atas produk/hasil tetap ada pada kita sendiri
  • Perlu diingat bahwa yang dibahas makalah (TFA) adalah kasus pada proyek yang sangat familier. Kasus yang saya alami justru kebalikannya, yaitu AI terutama membantu dalam situasi yang tidak familier
• Mengutip analogi bahwa “alat AI agentic (Claude Code, Amp, Gemini CLI, dll.) dalam pemrograman itu seperti table saw dalam pertukangan”, seseorang berargumen bahwa kalau kita belajar memakainya, beberapa pekerjaan bisa dilakukan lebih cepat dan lebih baik, tetapi saat belum terbiasa justru bisa membuat “jari terluka”. Saya sendiri jadi terdorong mencoba proyek yang lebih ambisius berkat agentic AI, dan karena pekerjaan yang tidak saya suka atau repetitif bisa saya serahkan ke AI, saya jadi punya ruang berpikir lebih besar. Di sisi lain, saya juga mengingatkan bahwa kita tidak boleh membiarkan AI mengerjakan semuanya lalu kita tinggal commit tanpa memahami isinya. Karena ini alat, kita perlu berusaha mempelajari cara memakainya dengan lebih baik
  • Saya rasa analogi table saw tidak cocok. Table saw adalah alat yang presisi dibanding alat tangan, sementara agentic AI justru jauh dari presisi
  • Logika “Anda memakai AI dengan cara yang salah” terasa menghina bagi pengembang yang sudah membangun seluruh stack open source sebelum AI muncul. Lagi pula, belum ada bukti bahwa AI telah digunakan untuk menghasilkan perangkat lunak yang benar-benar bernilai
• Dalam studi ini, hanya ada satu pengembang yang memiliki pengalaman Cursor lebih dari 50 jam (termasuk waktu partisipasi studi), dan pengembang ini mengalami percepatan 25%. Sisanya semua masih pemula, jadi sangat wajar bila pemula menjadi lebih lambat saat memakai alat baru. Saya rasa sulit menarik kesimpulan produktivitas AI hanya dari studi ini
  • Kalau melihat rincian makalahnya, studi-studi sebelumnya yang dilakukan pada peserta dengan pengalaman alat serupa (atau bahkan lebih sedikit) justru melaporkan peningkatan kecepatan. Kebanyakan juga sudah cukup berpengalaman dengan prompt LLM, dan perlu dipertimbangkan bahwa Cursor sendiri mirip VSCode sehingga kurva belajarnya tidak terlalu besar. Jika semua pengembang menjadi sangat terbiasa dengan alat AI, kemampuan mereka saat bekerja tanpa AI bisa malah menurun, sehingga ketika memakai AI, acuannya sudah lebih buruk dan lalu terlihat seperti ada peningkatan kecepatan. Bukan soal alat apa yang dipakai yang paling penting, melainkan wawasan bahwa laporan produktivitas diri ternyata jauh lebih optimistis dibanding kenyataan. Untuk menilai efek nyata, kita butuh metrik yang konkret
    (Dibahas lebih rinci di makalah bagian C.2.7 “Penggunaan alat AI di bawah rata-rata”)
  • Jika seorang pengembang sudah lama memakai IDE-nya sendiri (Vim/Neovim, dll.), berpindah ke alat baru seperti Cursor bisa membuat produktivitas turun signifikan selama berbulan-bulan
  • Saya juga berpikir begitu. Pengembang yang memakai alat yang belum familier pasti akan melambat. AI bukan pengecualian
• Saya adalah reviewer kode rutin untuk Burn (framework deep learning berbasis Rust). Baru-baru ini saya menutup sebuah PR perbaikan bug yang tampaknya sepenuhnya ditulis oleh AI agent. PR itu tidak menyelesaikan akar masalah, hanya mengabaikan error begitu saja, menambahkan kode panjang yang terasa seperti pembelaan diri tanpa guna, dan bahkan menyertakan test untuk mengabaikan error. Sepertinya itu cuma tindakan demi mencatat commit. Penyalahgunaan AI seperti ini tampak menyebar menjadi tren yang mengkhawatirkan
  • Menarik juga bahwa saat LLM tidak tahu jawaban yang benar, ia malah memberi jawaban ngawur, lalu ketika ditegur akan bereaksi seperti “benar juga, saya perbaiki lagi.” Saya khawatir orang-orang yang belum berpengalaman tidak bisa membedakan isu seperti ini, atau lama-lama makin tidak peduli pada kode. Ada juga kekhawatiran bahwa kerentanan serius dan kasus penyalahgunaan akan membanjir
  • Saat mereview MR rekan kerja, saya menemukan test case yang jelas terlihat seperti hasil AI—isinya seragam dan hanya nama variabel seperti thing1, thing2, dll. yang berbeda. Saya memberi masukan agar namanya dibuat lebih mudah dibedakan, lalu AI kali ini malah memberi nama variabel yang terlalu panjang seolah merinci semua karakteristik tiap kasus, sehingga kode akhirnya justru sulit dipindai sekilas. Penulisnya mungkin merasa kecepatan menulisnya meningkat besar, tetapi pada kenyataannya waktu habis untuk umpan balik, review, dan revisi, sehingga keuntungan produktivitasnya lenyap
  • Ada juga komentar jenaka bernada “framework deep learning di Rust → lingkaran setan yang melibatkan AI”
  • Sebenarnya suasana penggunaan AI demi sekadar menghasilkan commit sudah ada sejak lama. AI hanya makin mempermudah produksi spam sederhana
    Referensi: isu spam AI lama
  • Disebutkan juga bahwa LLM cenderung memakai try:catch terlalu luas sehingga sulit melacak sumber masalah. Saya pribadi ingin masalah muncul cepat dan jelas (= fail fast) agar bisa langsung diperbaiki
• Kalau saya bagikan pengalaman pribadi, pemrograman dengan AI membuat alur fokus saya sering terputus dan saya jadi lebih mudah lelah. Bahwa orang bisa ngoding seharian itu mitos; yang umum adalah fokus 1–3 jam lalu istirahat di sela-selanya. Bahkan saat membaca kode atau perubahan milik rekan kerja, waktu itu terasa masuk hitungan kerja tetapi sebenarnya kemajuan nyata hampir tidak ada. agentic AI (seperti refactoring kode kecil) bisa berguna, tetapi peningkatan produktivitas besar hampir tidak ada. Autocomplete kode (misalnya Copilot awal) justru lebih banyak noise yang tidak perlu
  • Kalau aktivitas satu hari kerja direkam, hasilnya mungkin akan cukup membuat murung. Khususnya pada codebase yang sudah matang, bahkan satu jam fokus pun mungkin berlebihan
• Saat melakukan debugging bug rumit seperti race condition di codebase yang tidak dikenal, menambahkan logging, mengganti fungsi library, dan memperbaiki struktur itu penting. Jika AI hanya memberi solusi jangka pendek seperti “ini race condition, perbaikinya begini”, justru ada risiko itu merusak pemahaman terhadap struktur dan logika kode. Dalam jangka panjang, jika pengeditan kode yang dipimpin AI terus berlanjut, kode itu sendiri bisa terdegradasi sedemikian rupa sampai AI pun nantinya tidak lagi bisa menanganinya dengan benar
  • Setiap kali saya mendengar cerita “saya berkontribusi ke bahasa dan codebase yang tidak saya kenal dengan bantuan AI”, saya selalu bertanya: dalam jangka panjang, sebenarnya apa yang benar-benar dipelajari? Untuk tugas kecil mungkin berguna, tetapi saya merasa jarang mendengar pengalaman pemeliharaan jangka panjang dari kontribusi seperti ini
• Dalam retrospektif proyek pertama saya yang aktif memanfaatkan alat AI, kesimpulannya adalah: 1) kecepatan tidak meningkat, 2) bahkan mungkin melambat, 3) kualitas hasil justru membaik. Perlambatan dan peningkatan kualitas ini saling terkait, karena AI lebih sering saya pakai sebagai alat bantu untuk memverifikasi ide atau mengeksplorasi alternatif. Berkat AI, pengalaman belajar di area yang asing juga terasa baik, dan di bidang utama saya, dengan memoles ide saya sendiri atau ide dari AI, hasil akhirnya memang menjadi lebih baik. Kecepatan bukan satu-satunya hal yang penting, dan meskipun kualitas sulit dikuantifikasi, saya tetap merasa itu bernilai
  • Karena AI bisa membantu meningkatkan kualitas, belakangan saya justru lebih suka AI yang berani berargumen dan tidak asal setuju. Jika saya minta AI memberi ide lalu menyerang kelemahannya, atau membantu mencari celah dalam ide saya, itu terasa produktif. Mungkin tidak selalu diwujudkan, tetapi hal itu membantu saya memikirkan berbagai sudut pandang yang sebelumnya tidak terpikirkan. Pengalamannya mirip berbicara dengan rekan kerja yang cukup bisa memberi opini tentang domain terkait secara substantif

[eususu]

Saya juga punya pemikiran yang mirip, tetapi agak sulit mengungkapkannya dengan kata-kata.
mental model adalah penamaan yang tepat. Sepertinya saya perlu lebih sering memakainya.