Peran kemampuan developer dalam coding agentik

• Seiring semakin cakapnya asisten coding berbasis agen, respons yang muncul sangat beragam, dan sebagian bahkan mengklaim bahwa "dalam 1 tahun developer tidak akan lagi dibutuhkan"
• Yang lain menyuarakan kekhawatiran tentang kualitas kode yang dihasilkan AI dan cara mempersiapkan developer junior menghadapi lingkungan yang berubah ini
• Selama beberapa bulan terakhir, penulis menggunakan asisten coding berbasis agen seperti Cursor, Windsurf, dan Cline, dan alat-alat ini sangat efektif untuk mengubah codebase yang sudah ada
• Penulis sangat terkesan dengan integrasi IDE-nya, termasuk menjalankan pengujian dan memperbaiki error secara otomatis, mendeteksi dan memperbaiki error lint/kompilasi, pencarian web, hingga fitur pratinjau browser
• Pengalaman kolaborasi antara developer dan AI sangat mengesankan serta membantu penyelesaian masalah dan implementasi fitur dengan cepat

• Namun tetap diperlukan intervensi, koreksi, dan penentuan arah secara terus-menerus dari developer
• Dalam banyak kasus, hasilnya bahkan tidak sampai menjadi commit nyata, dan AI masih kurang mampu menulis kode secara mandiri untuk pekerjaan yang tidak sepele
• Karena itu, keterampilan dan pengalaman developer tetap penting, dan harus terus dilatih ke depannya

Momen-momen ketika developer harus turun tangan langsung

• Alat AI menunjukkan kinerja yang konsisten lemah di area tertentu, dan hal ini berulang kali terkonfirmasi
• Sebagian bisa diredam sebagian dengan prompt tambahan atau aturan kustom, tetapi kontrol penuh tetap tidak mungkin
  • LLM sering kali tidak mengikuti instruksi prompt dengan tepat
  • Semakin panjang sesi coding, konsistensi hasil makin menurun
• Karena itu, contoh-contoh di bawah adalah isu yang sangat mungkin terjadi terlepas dari prompt atau pengaturan
• Kesalahan AI dibagi ke dalam 3 kategori berdasarkan radius dampaknya
  • a. Penurunan kecepatan pengembangan dan waktu menuju commit
    • AI justru memperlambat pekerjaan
    • Dalam beberapa kasus lebih tidak efisien dibanding coding tanpa bantuan
  • b. Menimbulkan friksi pada alur kerja tim
    • Menyebabkan benturan atau masalah kolaborasi dalam satu iteration
  • c. Menurunkan maintainability kode dalam jangka panjang
    • Awalnya tampak tidak bermasalah, tetapi menimbulkan masalah saat perubahan atau ekspansi di masa depan
• Semakin besar radius dampaknya, semakin panjang feedback loop yang dibutuhkan tim untuk menyadari dan memperbaiki masalah tersebut

Radius dampak: keterlambatan waktu hingga commit

• Kategori ini terdiri dari kasus-kasus di mana AI lebih mengganggu daripada membantu
• Karena ini adalah bentuk kegagalan yang paling jelas, biasanya tidak menjadi masalah besar
  • Dalam kebanyakan kasus, developer dapat menyadari dan menghentikannya sebelum tahap commit

• Kode yang tidak berjalan

  • Kode yang dihasilkan AI pada dasarnya tidak berfungsi
  • Developer perlu memperbaikinya sendiri, atau mengakhiri sesi AI dan menyelesaikan masalah secara manual
  • Developer berpengalaman dapat dengan cepat menilai letak kesalahannya dan mengambil tindakan

• Diagnosis masalah yang salah

  • AI salah menilai penyebab masalah dan mencoba solusi ke arah yang keliru
  • Berdasarkan pengalaman sebelumnya, developer bisa menarik AI kembali ke jalur yang benar

    Contoh: error build Docker disalahartikan sebagai masalah pengaturan arsitektur sehingga konfigurasinya diubah
    Penyebab sebenarnya adalah penyalinan node_modules yang dibangun pada arsitektur yang salah
    Karena ini masalah yang sering terjadi sebelumnya, penulis dapat cepat mengenali dan membetulkannya

Radius dampak: alur kerja tim dalam satu iteration

• Kategori ini mencakup kasus ketika friksi dalam tim muncul selama periode iteration akibat kurangnya review atau intervensi developer
• Berkat pengalaman di berbagai tim sebelumnya, penulis dapat menyadari dan menyesuaikan masalah seperti ini sebelum commit
• Developer baru pun bisa mendapatkan pelajaran ini lewat trial and error bersama AI
• Namun, jika kecepatan coding meningkat karena AI, tim mungkin tidak mampu menanggung masalah-masalah ini

• Pekerjaan awal yang berlebihan

  • AI cenderung mencoba mengerjakan keseluruhan fitur secara luas sekaligus, alih-alih implementasi bertahap
  • Akibatnya, jika pilihan teknis tidak tepat atau kebutuhan fitur dipahami keliru, banyak pekerjaan bisa terbuang sia-sia

    Contoh: saat migrasi stack frontend, AI mencoba mengubah seluruh komponen UI sekaligus
    Seharusnya penerapan dilakukan bertahap mulai dari satu komponen yang terintegrasi dengan backend

• Menyelesaikan tanpa analisis akar masalah

  • AI mencoba menyelesaikan masalah tanpa menganalisis akar penyebabnya, hanya memperbaiki error yang tampak di permukaan
  • Akibatnya, anggota tim lain yang kemudian menangani masalah itu harus menganalisis ulang tanpa konteks

    Contoh: saat terjadi error memori pada build Docker, AI hanya menaikkan pengaturan memori alih-alih mencari penyebabnya

• Memperumit workflow developer

  • Cara build/menjalankan yang dihasilkan AI menurunkan pengalaman developer
  • Jika langsung di-commit, ini juga berdampak buruk pada workflow anggota tim lain

    Contoh: menyediakan perintah terpisah untuk menjalankan frontend dan backend
    Contoh: fitur hot reload tidak ada
    Contoh: pengaturan build yang rumit membuat developer dan AI sama-sama bingung
    Contoh: gagal mendeteksi error Docker lebih awal, lalu mencoba menanganinya di tahap akhir build

• Kebutuhan yang disalahpahami atau tidak lengkap

  • Jika kebutuhan fitur tidak dijelaskan dengan jelas, AI bisa salah paham dan mengimplementasikan fitur ke arah yang keliru
  • Idealnya ini diluruskan lewat intervensi awal, tetapi baik pada AI yang otonom maupun developer yang ceroboh, biaya perbaikan lanjutan akan meningkat
  • Implementasi yang keliru ini sering baru ditemukan belakangan saat story berjalan, sehingga menimbulkan banyak pekerjaan revisi dan biaya komunikasi

Radius dampak: penurunan maintainability jangka panjang

• Inilah radius dampak yang paling samar dan berbahaya
  • Pada awalnya kode berjalan tanpa masalah, tetapi belakangan menjadi sulit diubah dan diperluas
• Masalah seperti ini sering kali baru ditemukan setelah beberapa minggu hingga beberapa bulan
• Khususnya di area ini, lebih dari 20 tahun pengalaman pengembangan penulis paling banyak berperan

• Kode pengujian yang bertele-tele dan duplikatif

  • AI cukup baik dalam membuat pengujian, tetapi masalah berikut sering muncul:
    • Membuat fungsi test baru alih-alih mengintegrasikannya ke test yang sudah ada
    • Menambahkan terlalu banyak assertion bahkan untuk bagian yang sudah tercakup
  • Hal yang bisa disalahpahami developer pemula: lebih banyak test ≠ test yang lebih baik
  • Semakin banyak duplikasi, semakin sulit pemeliharaannya, dan saat kode berubah kemungkinan gagalnya banyak test sekaligus meningkat
  • Penulis mencoba meredamnya dengan perintah kustom, tetapi hal ini masih sering terjadi

• Kurangnya reusability

  • Kode yang ditulis AI sering kali kurang modular sehingga sulit digunakan ulang

    Contoh: tidak mengenali komponen UI yang sudah ada lalu membuat implementasi duplikat
    Contoh: memakai inline style secara berlebihan alih-alih CSS class

• Kode yang terlalu kompleks atau bertele-tele

  • AI sering menghasilkan kode lebih banyak dari yang diperlukan, sehingga bagian yang tidak perlu harus dibuang secara manual
  • Hal ini meningkatkan biaya pemeliharaan dan menaikkan kemungkinan error saat ada perubahan

    Contoh: saat mengubah CSS, banyak style duplikat harus dihapus satu per satu
    Contoh: membuat web component yang tidak perlu rumit hanya untuk menampilkan data JSON
    Contoh: saat refactoring, AI gagal mengenali rantai dependency injection yang sudah ada,
    lalu meneruskan nilai yang sudah di-inject lagi sebagai parameter lain sehingga desain jadi lebih rumit

    • value = service_a.get_value(); ServiceB(service_a, value=value)

Kesimpulan: bisakah AI menulis semua kode sebagai pengganti kita?

• Berdasarkan pengalaman sejauh ini, AI yang secara otonom menulis 90% dari seluruh kode dalam 1 tahun ke depan adalah sesuatu yang secara realistis mustahil
• Namun, sebagai alat bantu penulisan kode, ada kemungkinan AI dapat membantu hingga 90% pada tim dan codebase tertentu
• Faktanya, penulis mendapat bantuan AI sekitar 80% pada proyek dengan kompleksitas menengah berukuran 15K LOC

Cara mencegah kesalahan AI

• Hal yang bisa dilakukan di tingkat developer individu

  • Selalu review kode yang dihasilkan AI dengan cermat
    • Hampir tidak pernah ada kasus tanpa bagian yang perlu diperbaiki
  • Segera hentikan jika sesi AI mulai membingungkan
    • Ubah prompt, atau beralih sepenuhnya ke pekerjaan manual (juga disebut "coding buatan tangan")
  • Waspadai solusi yang tampak meyakinkan dan selesai seperti mukjizat dalam waktu singkat
    • Bisa jadi ada biaya maintainability jangka panjang yang tersembunyi
  • Praktikkan pair programming
    • 4 mata dan 2 otak memberikan penilaian yang lebih baik

• Strategi respons di tingkat tim dan organisasi

  • Manfaatkan secara aktif alat pemantauan kualitas kode yang sudah ada
    • Contoh: Sonarqube, Codescene
    • Saat menggunakan alat AI, duplikasi kode, code smell, dan semacamnya perlu diawasi lebih ketat
  • Siapkan pre-commit hook dan code review terintegrasi di IDE
    • Perkuat strategi shift-left untuk menangkap masalah sejak awal pengembangan
  • Bangun kembali kebiasaan kualitas kode yang baik
    • Bagikan contoh masalah yang timbul dari kode AI ("log kesalahan") dalam retrospektif mingguan tim
  • Manfaatkan aturan kustom secara aktif
    • Sebagian besar alat AI memungkinkan pengaturan set aturan yang dikirim bersama prompt
    • Tim dapat mengurangi kesalahan AI dengan memperbaiki ruleset bersama-sama
    • Namun, semakin panjang sesi, kemungkinan aturan diabaikan juga meningkat
  • Bangun budaya tim yang berlandaskan kepercayaan dan komunikasi
    • Adopsi AI adalah perubahan baru, dan perlu disadari bahwa semua orang masih pemula
    • Tekanan seperti "karena ada AI, kerjakan lebih cepat" akan meningkatkan risiko kualitas
    • Tim yang memiliki rasa aman secara psikologis akan lebih aktif berbagi masalah dan belajar

[bus710]

Orang yang memakai alat itu, terlepas dari tingkat kemampuannya, tetap saja semuanya adalah developer.... Agak terasa janggal kalau diiklankan seolah-olah ke depannya developer tidak lagi dibutuhkan.

[prunusnira]

Saya tidak tahu bagaimana nantinya ke depan, tapi untuk saat ini rasanya masih kurang cocok untuk dipakai secara umum... Belakangan saya mencoba Cursor, dan bahkan path import file yang dasar pun tidak bisa dikenali dengan benar. Meski begitu, cukup mengejutkan bahwa ia bisa sampai tingkat tertentu memprediksi apa yang ingin saya buat.

[daddy]

Saat terjadi error memori saat build Docker, alih-alih bertanya sejak awal mengapa begitu banyak memori digunakan, yang dilakukan adalah menaikkan pengaturan memori
-> Ini... karena dalam tak terhitung banyaknya kasus sebelumnya memang selalu dilakukan seperti ini.
-> AI saat ini adalah kita di masa lalu

[GN⁺]

Komentar Hacker News

• Akhir-akhir ini saya memakai Cursor untuk sebagian besar pengembangan. Tulisan ini sangat mirip dengan pengalaman saya

  • Rasanya agen AI seperti berhenti di sekitar tahun 2021. Jika memasang paket baru, Claude kembali ke paket lama atau implementasi yang populer 4 tahun lalu. Memperbaiki hal ini sangat membuat frustrasi. Memberikan instruksi yang jelas bisa mengurangi masalahnya, tetapi tidak menyelesaikannya
  • Ketidakpastian dari kesalahan-kesalahan ini sangat menantang. Beberapa bulan lalu saya memakai Claude untuk membuat web app yang berguna dalam sekali "one-shot". Hasilnya fungsional penuh dan sangat canggih. Jika saya membuatnya sendiri, mungkin butuh beberapa minggu atau akhir pekan. Namun ketika saya memintanya memperbarui favicon menggunakan file yang sudah disediakan, dia berputar-putar tanpa hasil selama satu jam (dan akhirnya saya selesaikan sendiri dalam beberapa menit). Beberapa hari lalu saya mencoba lagi membuat web app dengan cakupan serupa. Setelah sekitar 4 jam berurusan dengan agen itu, saya siap membuang seluruh kodenya
  • Pendekatan ini memberi saya keberanian untuk mengejar proyek yang sebelumnya tidak akan saya coba karena kekurangan waktu, keahlian, atau motivasi. Berkurangnya friksi itu menarik, tetapi membuat sesuatu yang benar-benar berarti tetap sulit. Membuat MVP yang matang masih membutuhkan usaha yang besar
  • Saya terus memikirkan kura-kura dan kelinci. Mempercayai agen AI itu menggoda karena di awal rasanya progres jauh lebih cepat. Namun pada akhirnya tetap ada perasaan bahwa saya sebenarnya bisa membuat kemajuan yang lebih kokoh jika bergerak lambat dan teliti. Saat membangun secara manual, saya jarang harus mundur atau membuang seluruh pendekatan. Dalam pendekatan yang digerakkan AI, saya bisa bergerak 10 kali lebih cepat tetapi mungkin membuang sekitar 70% pekerjaan di sepanjang jalan
  • Pengalaman-pengalaman ini membuat saya tidak percaya bahwa dalam 1 tahun AI akan menulis 90% kode secara otonom. AI mungkin bisa membantu menulis 90% kode
  • Lingkungan saat ini mirip dengan siklus hype mobil swakemudi. Ada banyak janji besar dan kemajuan nyata, tetapi saya tidak melihat dunia di mana dalam 5 tahun ke depan AI menulis software yang berguna sendiri

• Saya memakai AI seperti ini: sebagai alat bantu menulis di IDE, dan ia menjawab saya seperti rubber duck yang sangat keren dan canggih

  • Saya sering mendiskusikan potongan kode tertentu secara berulang. Biasanya saya memberikannya dengan konteks yang sangat minim, menyempurnakannya sampai fungsinya berjalan dengan benar, lalu menyesuaikannya dengan konteks yang lebih luas (atau saya tangani sendiri bagian itu)
  • Saya tidak memakainya seperti ini: sebagai agen yang harus mencapai tujuan luas sendirian
  • Alasannya: terlalu banyak waktu dan usaha yang harus diinvestasikan untuk memastikan output sistem agen itu benar-benar selaras dengan apa yang ingin dicapai. Karena semua alasan yang dijelaskan dalam tulisan bagus ini
  • Ironisnya, memakai AI sebagai alat bantu menulis yang sangat kompeten mempercepat workflow saya secara signifikan. Jadi dalam kadar tertentu, AI yang kurang agentic justru membuat saya lebih kritis, termasuk lebih kritis terhadap waktu tambahan yang perlu diinvestasikan agar sesuai dengan kekhasan AI agentic

• Saya benar-benar tidak paham

  • Saya tidak mengerti kenapa developer berpengalaman begitu antusias mengikatkan diri pada pengalaman yang jelas-jelas buruk dan tidak memuaskan seperti itu
  • Saya suka menulis kode dan memecahkan masalah. Itulah mengapa saya memilih software development sebagai profesi

• Contoh: saat terjadi error memori selama Docker build, alih-alih bertanya sejak awal kenapa begitu banyak memori dipakai, ia malah menaikkan pengaturan memori

  • AI memang benar-benar seperti kita

• Skill developer tetap penting — kalau tidak bisa mengemudi, Anda tidak bisa menyetir. Tapi bagaimana dengan energi developer? Sebelum AI, saya hanya bisa coding sekitar 2 jam per hari (waktu menulis kode yang sebenarnya). Namun dengan Claude Code, saya bisa coding dengan mudah selama 5 jam tanpa henti. Rasanya seperti naik sepeda listrik alih-alih sepeda biasa. AI terasa seperti metafora sepeda untuk pikiran dari Steve Jobs — ia tidak menggantikan saya, tetapi sekarang saya bisa melaju jauh lebih cepat dan lebih jauh

• Diagram ini sangat relatable — tim kami mencentang semua item yang ada di sini. Bahkan tanpa memakai AI sekalipun! Bayangkan saat kami akhirnya memakainya...

  • "Kebutuhan yang disalahpahami" dan "implementasi yang terlalu rumit" pada dasarnya adalah maskot kami. Kami perlahan mengurai kekacauan ini lewat percakapan awal yang lebih baik dan review yang berulang. Tetapi kebiasaan tidak mudah hilang. Adakah orang yang bisa melewati jebakan ini tanpa bantuan AI?

• Bagi saya, yang jelas justru ini: memakai AI untuk hal-hal di sekitar

  • Sering kali saya harus membangun dan memelihara alat seperti developer tooling, introspeksi, logging, transformasi, dan sebagainya. Saya cukup beruntung menggunakan agen untuk membuat dan memodifikasi hal-hal ini. Misalnya, alat untuk mengumpulkan data dan log dari sistem perencanaan kustom
  • Ada banyak boilerplate yang dihasilkan di jalur non-kritis saat membangun alat-alat ini. Di sebagian besar hari, saya tidak ingin mengerjakannya sendiri

• Saya memang harus banyak mengarahkan AI, tetapi saya optimistis bahwa prompt yang lebih baik akan menghasilkan agen yang lebih baik

  • Ambil contoh dari artikel: penggunaan ulang kode. Saat menulis kode, secara bawah sadar saya punya inventaris mental tentang kode yang sudah ada. Tanpa sadar saya bertanya pada diri sendiri, "apakah tugas baru ini sangat mirip dengan kode yang sudah berjalan dan teruji?" Saya belum melihat detail prompt awal yang diterima agen coding, tetapi firasat saya adalah akan lebih baik menambahkan prompt yang memerintahkan agen untuk mempertahankan inventaris tentang apa yang ada di codebase, lalu membandingkan kebutuhan tugas baru dengan apa yang sudah ada saat merencanakan penempatan kode baru
  • Ya, ini menambah banyak siklus komputasi pada proses perencanaan. Tetapi kita harus jujur mengatakan, "itulah harga yang harus dibayar agar agen bisa menulis kode". Perencanaan yang lebih baik > kemampuan memecahkan masalah

• Saya ingin mengawali dengan mengatakan bahwa alat AI tidak selalu buruk untuk hal-hal yang saya daftarkan

  • Sepertinya ada kata "not" yang hilang. Kenapa dia mengawalinya dengan mengatakan mereka selalu buruk? Arah sebaliknya lebih masuk akal
  • Ada juga kesalahan tata bahasa: memakai "effected" alih-alih "affected"

• Apakah Martin Fowler sekarang menyewakan ruang di situs webnya?