Jebakan AI Coding

• Agen coding AI memang secara dramatis meningkatkan kecepatan penulisan kode, tetapi bagian terpenting dalam proses pengembangan tetaplah pemahaman dan pemecahan masalah
• Dengan memanfaatkan LLM, kode bisa dibuat dengan cepat, tetapi karena kurang memahami konteks secara menyeluruh, justru dibutuhkan lebih banyak waktu untuk pekerjaan pascaproses dan memahami hasilnya
• Hal ini menimbulkan kesenjangan antara ekspektasi produktivitas dan efisiensi nyata, serta membuat pengembang menghabiskan waktu pada pekerjaan berulang dan membebani seperti pengujian, refactoring, dan dokumentasi alih-alih pekerjaan kreatif yang mereka inginkan
• Seperti 'dilema tech lead' di masa lalu, jika pekerjaan kompleks demi hasil jangka pendek dilimpahkan ke AI atau engineer senior, hal itu dapat memicu penurunan kapabilitas tim dalam jangka panjang dan krisis
• LLM perlu dipandang sebagai engineer junior yang sangat kuat, dan dengan menerapkan proses pengembangan yang telah teruji ke dalam kolaborasi dengan AI, kita perlu membangun struktur delivery software yang berkelanjutan

---

Mengenali masalah: Hal yang lebih penting daripada coding itu sendiri

• Pengembangan software adalah pekerjaan yang berpusat pada pemecahan masalah
• Coding yang sesungguhnya hanyalah bagian terakhir dari seluruh proses berpikir dan pertimbangan developer
• Selain menulis kode, developer juga melakukan berbagai pekerjaan seperti memahami domain, merinci requirement, melakukan abstraksi, mempertimbangkan efek samping, pengujian bertahap, dan memperbaiki bug
• Alur pengembangan tradisional: berpikir cukup matang lalu menulis kode
• Di era AI coding: pola berubah menjadi kode dulu, pemahaman belakangan

Pergeseran AI coding: Paradigma di mana kode dibuat lebih dulu

• Agen coding AI seperti Claude Code dapat menghasilkan kode dengan cepat, tetapi tidak dapat sepenuhnya memahami konteks keseluruhan sistem
• Proses review, testing, dan integrasi oleh manusia tetap wajib, dan memahami kode yang ditulis AI setelah fakta membutuhkan banyak waktu
• Pemasaran menekankan peningkatan kecepatan coding, tetapi peningkatan nyata dalam produktivitas delivery software yang berfungsi sangat kecil
• Developer menghabiskan lebih banyak waktu pada pekerjaan berulang dan sulit seperti testing, menghapus duplikasi, dokumentasi, dan pengelolaan infrastruktur atas hasil yang dibuat AI
• Kesenangan nyata dalam coding berkurang, sementara pekerjaan berulang justru meningkat

Dilema lama para pemimpin teknis

• Ketika engineer mengambil peran tech lead, mereka memikul tanggung jawab atas delivery teknis tim
• Saat pengalaman di dalam tim terpusat pada satu orang, muncul ketimpangan produktivitas
• Terjadi tarik-menarik antara dua strategi: distribusi yang adil (mengutamakan pertumbuhan anggota tim) dan pelimpahan terpusat (berfokus pada pengembangan cepat)
  • Pelimpahan terpusat memberi keuntungan jangka pendek yang besar, tetapi menimbulkan risiko jangka panjang bagi tim (tidak ada penopang, burnout, sulit mendapat dukungan) karena pengalaman menjadi terlalu terkonsentrasi
• Untuk budaya tim yang sehat, dibutuhkan cara untuk menyeimbangkan pertumbuhan dan efisiensi

Inti kepemimpinan yang baik: Keseimbangan antara proses dan pertumbuhan

• Agar seluruh tim dapat mempelajari know-how engineer berpengalaman, perlu diterapkan berbagai prinsip pengembangan dan framework
• Contoh: Extreme Programming, code review, deployment bertahap, desain modular, test-driven development, pair programming, dokumentasi, continuous integration, dan lain-lain
• Tujuan akhirnya: meminimalkan kerja ulang, memaksimalkan kolaborasi, dan mendorong pertumbuhan individu

Kolaborasi dengan agen AI: Peran baru pemimpin tim

• Agen coding berbasis LLM terbaru mirip dengan developer junior yang sangat cepat
• Berbeda dengan junior biasa, LLM memiliki perbedaan jelas berupa tidak memiliki kemampuan belajar dan tidak memiliki batas kecepatan
• AI terus berfokus pada peningkatan kecepatan alih-alih peningkatan kualitas, dan kurang memahami konteks serta domain manusia
• Ada dua pola kolaborasi:
  • AI-based engineering: mengarah pada kerja tim yang efisien dan berkelanjutan, meski lebih lambat
  • vibe coding: berfokus pada hasil cepat, tetapi lambat laun menumpuk kekacauan yang sulit dipulihkan
• Ini mirip dengan titik buta tradisional dalam pertumbuhan kode ala Silicon Valley: setelah keuntungan jangka pendek, akhirnya menabrak batas pertumbuhan

Cara praktis bertahan dari jebakan AI coding

• LLM tidak mengetahui situasi spesifiknya sendiri dan memproduksi kode secara membabi buta
• Engineer harus memberi AI struktur, standar, dan proses yang jelas untuk mengubah output mentah menjadi layanan nyata
• Dibutuhkan playbook baru yang menerapkan best practice dari siklus pengembangan tradisional secara erat ke lingkungan kolaborasi dengan AI
• Pemanfaatan AI pada tiap tahap utama:
  • Definisi spesifikasi: analisis edge case, fokus pada cakupan tujuan
  • Dokumentasi: mengamankan panduan dan bukti yang bisa digunakan berulang
  • Desain modular: meningkatkan pemahaman dengan membatasi konteks
  • Test-driven development: membuat test case sebelum implementasi, mencegah regresi
  • Standar coding: menjaga gaya dan kualitas
  • Monitoring: analisis log otomatis dan menghasilkan insight

Kesimpulan

• Delivery software tidak tercapai hanya dengan menulis kode; yang penting adalah membangun struktur kolaborasi yang efisien antara AI dan manusia
• Jika LLM diperlakukan sebagai developer junior supercepat dan proses pengembangan yang telah teruji diterapkan, maka akan memungkinkan penyediaan software berkualitas tinggi yang skalabel

[GN⁺]

Komentar Hacker News

• Saya ingin melihat argumen anti-AI yang tidak sekadar bertumpu pada klaim bahwa “teknologi membuat manusia menjadi malas”. Siapa pun yang benar-benar serius membuat kode dengan LLM pasti merasakan bahwa loop perencanaan-penyusunan-pengujian-retrospektif tetap sangat penting. Jika dijalankan sembarangan tanpa kehati-hatian, hasilnya mudah langsung berantakan. Kalau loop ini diterapkan dengan baik, saya bisa menghabiskan banyak waktu untuk menguji desain arsitektur dan pengalaman hasil yang saya sukai. Karena LLM menangani bagian-bagian yang mudah dengan cepat, pada akhirnya yang tersisa untuk kita tangani adalah pekerjaan yang kurang menarik dan kurang dihargai. Di bidang tempat AI membuat keahlian bersinar, perbedaan pandangan antara orang yang menikmati pekerjaannya sendiri dan orang yang menikmati pengalaman berpikir menjadi sangat jelas. Orang yang suka berpikir jadi bisa hampir sepenuhnya fokus ke area itu berkat AI. Sebaliknya, bagi orang yang suka mengetik dan memanipulasi langsung, AI justru mengambil bagian yang mereka sukai

  • Terkait pembuatan kode dengan AI, menurut saya kritik yang lebih penting daripada gagasan bahwa teknologi membuat orang malas adalah bahwa AI merampas pemahaman mendalam terhadap kode yang dihasilkannya. Inti dari software engineer bukanlah menghasilkan kode, melainkan merancang keseluruhan sistem. Yang penting di sini adalah mental model tentang cara kerja kode dan keahlian domain, sementara kode hanyalah hasil turunan dari mental model tersebut. Pada proyek dengan skala tertentu ke atas, sulit untuk benar-benar mengetahui kode secara menyeluruh jika bukan penulis yang menuliskannya langsung. Jika mental model ini tidak dibangun, masalah lain juga akan ikut muncul. Agen coding berbasis LLM memiliki keterbatasan dalam penalaran pada level sintaks, sehingga menunjukkan kelemahan dalam skalabilitas

  • Kalau bicara pengalaman saya sendiri, saya kadang memakai alat AI seperti Cline, tetapi semakin lama porsi saya menulis kode langsung dengan tangan makin besar. Alasannya, dalam banyak kasus ini hanya mengganti aktivitas coding dengan penulisan prompt. Saya memakai AI jika waktu untuk menulis prompt dan menunggu inferensi lebih singkat daripada waktu saya mengoding langsung, tetapi biasanya ini hanya berlaku saat hambatan kecepatannya ada di level refactoring. Untuk sebagian besar pekerjaan, kalau saya kerjakan sendiri butuh 10 menit, kalau dengan AI saya menulis prompt, menjalankan, lalu butuh 8 menit. Kalau berjalan mulus tanpa kesalahan memang hemat 2 menit, tetapi kalau perlu perbaikan atau re-prompt malah jadi 10~12 menit, ditambah kredit AI juga terpakai, jadi itu skenario terburuk. Setelah sering menghitung seperti ini, saya sampai pada kesimpulan bahwa, jika mempertimbangkan kualitas kode dan waktu yang dibutuhkan, pekerjaan manual lebih aman

  • Soal klaim bahwa teknologi membuat orang menjadi ceroboh, pada umumnya teknologi juga sering membuat orang lebih berhati-hati. Masalahnya, teknologi AI ini punya kemungkinan besar mendorong pengguna menjadi ceroboh. Yang menarik bagi saya bukan bagian coding yang menyenangkan; saya lebih menyukai desain (arsitektur) itu sendiri. Kalau niat bisa langsung tercermin ke dalam kode, saya akan memakai cara itu. Tetapi antarmuka chatbot menyampaikan niat secara tidak langsung dan tidak sempurna, jadi ketika dipakai untuk membangun kode tingkat tinggi, model di kepala saya dan pemahaman atas kode yang sebenarnya cepat menjauh, meninggalkan fondasi yang tidak stabil. Memang bisa direview teliti baris demi baris, tetapi itu justru berlawanan dengan tujuan alatnya. AI coding mendorong jurang antara implementasi detail dan pemahaman makro karena memberi kesan “10 kali lebih cepat”. Faktanya, salah satu manfaat utama yang dipromosikan dari AI coding adalah berkurangnya kebutuhan untuk memikirkan bagian struktural, tetapi celah pemahaman ini nanti menimbulkan masalah. Otomasi yang baik itu andal dan dapat diprediksi, sehingga cukup memahami invariant tingkat atas, tetapi kode chatbot tidak memberi jaminan seperti itu dan akhirnya menciptakan struktur yang memaksa kita memverifikasi semuanya secara manual. Dalam konteks ini, keamanan dan keandalan justru terasa lebih sulit

  • Saya terlalu sering melihat logika “fokuslah pada bagian berpikir” sampai rasanya sekarang sudah basi. Masalahnya, saya ragu seseorang yang belum bertahun-tahun benar-benar bekerja langsung di lapangan bisa melakukan aktivitas berpikir yang mendalam hanya dengan berpikir saja. Pada akhirnya, tanpa pengalaman melakukannya sendiri, bahkan cara berpikir pun berisiko makin dangkal

  • Pandangan saya, karena debugging lebih sulit daripada menulis, lebih baik saya menulis sendiri daripada harus men-debug kode yang tidak saya tulis

• Setiap kali membaca diskusi seperti ini, saya selalu bertanya-tanya apakah penulisnya benar-benar memakai alat yang sama dengan saya. Dengan Claude Code, saya bisa menghasilkan hampir semuanya, dari boilerplate sederhana sampai algoritma yang kompleks, bahkan di codebase besar yang sangat membingungkan. Tentu tidak 100% benar, tetapi sangat mendekati. Selain itu, alat ini sering mengusulkan algoritma yang bahkan tidak terpikir oleh saya. Alat seperti ini menghemat waktu saya setidaknya 10 kali lipat

• Tulisan ini lumayan, tetapi saya melihat dua kekeliruan. Pertama, bahkan ketika developer berpengalaman memakai LLM, eksplorasi yang memadai, pemikiran awal, dan desain tetap mutlak diperlukan. Bahkan, untuk memanfaatkan LLM dengan benar, kita justru harus berpikir lebih banyak daripada biasanya, membandingkan berbagai opsi desain, dan menggambar struktur keseluruhan. Dulu saya tidak mendokumentasikan proses seperti ini, tetapi sekarang saya meninggalkannya dalam bentuk dokumen desain. Kedua, ada klaim bahwa LLM seperti junior developer yang tidak berkembang, padahal keduanya sepenuhnya berbeda. Junior developer manusia adalah manusia, sedangkan LLM adalah alat. Yang sering dianggap penting adalah bahwa bekerja dengan junior akan menghasilkan nilai akumulatif sedangkan dengan LLM tidak, tetapi ini pun tidak tepat. Meski LLM tidak belajar, saya justru belajar menjinakkannya dengan jauh lebih efisien dan memanfaatkannya dengan lebih baik. Kita masih berada di masa awal penerapan LLM secara baik ke produk, jadi wajar kalau terlihat nilai pertumbuhan yang bersifat majemuk

  • Saya setuju dengan “meskipun LLM tidak belajar, saya belajar”, tetapi saya tetap berharap LLM benar-benar belajar dari interaksinya dengan pengguna. Yang saya inginkan adalah bisa menyimpan/memuat isi sesi ke file agar LLM benar-benar memahami seluruh konteks yang sudah dipelajari sebelumnya tanpa ada yang terlewat. Beberapa UI frontend memang bisa menyimpan/memulihkan sesi, tetapi poin pentingnya adalah a) saya ingin “pembelajaran ulang” seperti ini tidak memengaruhi current context window LLM (atau malah semoga konsep itu hilang sama sekali), dan b) caranya harus benar-benar tanpa kehilangan apa pun. Metode seperti melanjutkan setelah ringkasan, RAG, dan sejenisnya memang sudah ada, tetapi semuanya punya keterbatasan mendasar seperti kehilangan informasi atau pemulihan yang hanya bisa terjadi jika dipicu oleh interaksi saat ini. Misalnya, kalau kemarin saya menjelaskan suatu fungsi kepada LLM lalu menyimpan sesi, saya ingin hari ini setelah sesi dipulihkan, meski saya bertanya sesuatu yang sama sekali tidak terkait, LLM tetap menjawab sambil mempertimbangkan konteks lama itu juga. Menurut saya, perlu ada cara yang juga memungkinkan memulai dari awal lagi (clean slate) secara eksplisit saat diinginkan

  • Benar. Karena dalam produktivitas perangkat lunak secara keseluruhan, waktu untuk berpikir mengambil porsi yang jauh lebih besar daripada waktu menulis kode yang sebenarnya, sekalipun LLM mempercepat bagian coding, itu tidak otomatis menciptakan perubahan dramatis pada produktivitas total atau kebutuhan tenaga kerja

  • Memulai dengan prompt DO NOT WRITE ANY CODE YET juga sudah jadi kebiasaan dasar saya. Itu cara untuk lebih dulu memahami apa yang hendak dilakukan LLM dan memastikan kontrol tetap ada di tangan saya. Saya lebih menikmati desain itu sendiri—logika, pemecahan masalah, integrasi sistem—daripada menulis kode

  • Ada fitur seperti mode Ask di Copilot dan mode Plan/Chat di GPT-5 Codex yang memungkinkan perencanaan tanpa mengubah file kode. Saya sudah mencoba Codex beberapa hari, dan kalau diberi instruksi yang cukup, hasilnya sangat hebat

  • Saya juga kebanyakan lebih suka meminta rencana sebelum eksekusi konkret ke LLM, semacam “tolong jelaskan rencananya dulu”

• Tulisan ini mengklaim peningkatan produktivitas 10% dengan hanya mengutip materi pemasaran Microsoft, padahal studi Harvard justru mencatat penurunan produktivitas 10% dalam praktik nyata. Saya lebih suka tulisan yang lebih dulu mengutip hasil riset independen, bukan promosi perusahaan tertentu

• Salah satu inti yang tidak sepenuhnya tersampaikan oleh tulisan ini adalah poin Casey Muratori bahwa “jika Anda memrogram dengan mindset yang berpusat pada pembelajaran, AI justru tidak terlalu berarti”, dan saya setuju dengan itu. Secara pribadi, saya merasa generator kode AI hanya efektif untuk kode sekali pakai yang memang akan dibuang. Untuk area yang benar-benar ingin saya pelajari dengan serius, saya merasa efek belajar akan paling maksimal jika saya tidak menyerahkan pembuatan kode kepada AI. Tentu ada orang yang merasakan “AI-driven engineering” bermakna bagi mereka, tetapi setidaknya bagi saya, menulis blok kode langsung dengan tangan terasa lebih menyenangkan dan pada akhirnya hasilnya juga lebih baik. Video terkait, durasi 5 menit

  • Logika bahwa “kondisi yang memaksimalkan pembelajaran adalah sama sekali tidak menghasilkan kode dengan AI” terasa terlalu ekstrem. Walaupun penting untuk mencoba sendiri demi belajar, rasanya itu klaim yang terlalu kuat, seperti mengatakan kita tidak boleh berkomunikasi atau meminta bantuan dari orang lain sama sekali

• Saat memakai Claude Code, saya jadi menghabiskan jauh lebih banyak waktu untuk berpikir. Dulu saya tidak pernah mendeskripsikan fitur yang ingin dibuat dalam 400~600 kata, tetapi sekarang saya menyusun jauh lebih banyak informasi dengan serius. Berkat pemikiran seperti ini, hasilnya memang jadi lebih cepat dan lebih baik, tetapi pada saat yang sama pemahaman saya terhadap kodenya sedikit lebih rendah daripada sebelumnya. Namun saya tidak bisa setuju dengan klaim bahwa developer berpengalaman akan berpikir lebih sedikit ketika memakai Claude Code. Mungkin banyak orang memakai agen secara tidak efisien, misalnya nyaris hanya menulis prompt saja, tetapi saya tidak melihat itu sebagai kesalahan agennya

• Melihat diskusi seperti ini membuat saya merasa bahwa sekarang kita masih berada di masa transisi yang ambigu. Mungkin sekitar tahun depan, diskusi seperti hari ini akan dianggap terlalu banyak berpikir. Ini terasa mirip masa ketika banyak orang meragukan internet sebelum dan sesudah menjadi umum, dengan pertanyaan seperti “tren sementara” atau “investasi yang salah”

• Hal yang sering terlewat dari tulisan seperti ini adalah sebagai berikut

  1. Tidak semua coding itu sama. Lawan bicara bisa saja membahas sistem produksi, sementara saya mungkin hanya bicara eksperimen sederhana
  2. Cara setiap orang memanfaatkan agen berbeda-beda
  3. Waktu developer hebat juga punya biaya
     Saya berharap ada tulisan yang sekadar merangkum secara sistematis kelebihan, kekurangan, dan trade-off dari AI code assistant. Perlu ada pembahasan tanpa penilaian moral (baik/buruk). Saya akui, ketika “kemampuan coding” adalah bagian dari identitas diri, pendekatan yang dingin dan objektif jadi lebih sulit
  • Teks utama sebenarnya memang sempat menyinggung poin nomor 1 yang kamu sebutkan, yaitu keragaman konteks dalam coding

• Setiap hari saya menyemangati diri sendiri dengan berkata “bertahan 30 tahun lagi lalu pensiun”. Sudah 10 tahun di bidang machine learning, lelah duduk di depan komputer dan juga lelah bekerja. Rasanya cuma ingin berguling-guling di rerumputan

  • Sepertinya kamu butuh istirahat (sabbatical), jadi saya ingin merekomendasikannya sekali saja

• Grafik “berpikir & coding vs berpikir & revisi” menarik. Belakangan ini saat memakai Codex, saya benar-benar berharap AI akan membuat banyak perubahan pada kode saya. Kenyataannya, waktu justru habis besar-besaran ketika penyebab masalah ternyata sama sekali tidak berhubungan dengan kode. Baru-baru ini saya menghabiskan banyak waktu memeriksa kode karena masalah autentikasi, tetapi ternyata penyebabnya adalah kerusakan pada pengaturan ipv6 di VM

[shakespeares]

Saya sangat setuju. Saat menggunakan AI untuk coding, pekerjaan pascaprosesnya terlalu banyak sehingga sangat sulit untuk benar-benar menerapkannya ke bisnis dan memeliharanya.
Bahkan jika dikerjakan sambil saling banyak bertukar konteks dari sudut pandang bekerja bersama, karena sebagian kode bukan ditulis langsung sendiri, sering kali pemahamannya mudah menguap dari kepala.
Menurut saya, batasan memang mutlak diperlukan.