Menggunakan AI untuk Menulis Kode yang Lebih Baik dengan Lebih Lambat

 (nolanlawson.com)
43 poin oleh GN⁺ 2026-05-26 | 2 komentar | Bagikan ke WhatsApp
  • AI untuk coding dapat dimanfaatkan bukan hanya untuk menghasilkan kode berkualitas rendah dalam jumlah besar dengan cepat, tetapi juga untuk meninjau PR secara mendalam dan membuat kode berkualitas tinggi secara perlahan
  • Agen LLM kuat dalam mendeteksi bug di codebase, tetapi tantangan sebenarnya ada pada penentuan prioritas dan verifikasi terhadap temuan tersebut
  • Claude skill yang menggunakan beberapa model sekaligus meninjau PR dengan Claude sub-agent, Codex, dan Cursor Bugbot lalu membuat laporan akhir yang mengurangi false positive
  • Alur pemrosesannya adalah memperbaiki masalah critical/high secara berulang, melewati item yang manfaatnya rendah dibanding biayanya, dan membatalkan PR jika ada terlalu banyak masalah fatal
  • Pendekatan ini lebih mengutamakan kesehatan codebase daripada kecepatan, serta memperkuat pemrograman yang hati-hati dengan memahami failure mode dan bug yang sudah ada

Cara lambat menggunakan AI untuk coding

  • Pandangan bahwa AI untuk coding hanya berguna untuk menghasilkan kode berkualitas rendah dalam jumlah besar dengan cepat meremehkan fleksibilitas LLM
  • LLM dapat digunakan secara efektif bukan hanya untuk pembuatan kode cepat, tetapi juga untuk menulis kode berkualitas lebih tinggi dengan lebih lambat
  • Berlawanan dengan pendekatan seperti slop cannons yang membanjiri dengan PR besar tanpa verifikasi, ada juga cara untuk meninjau PR lebih dalam dan dengan gigih memeriksa kemungkinan kegagalan

Verifikasi dan prioritas lebih penting daripada deteksi bug

  • Mythos menunjukkan bahwa agen LLM sangat mampu menemukan bug di codebase
  • Dalam contoh lain, model selain Mythos juga dapat menemukan banyak bug di codebase yang belum ditinjau
  • Model publik terbaru dari Anthropic dan OpenAI memang berbeda dalam kemampuan mendeteksi bug yang subtil dan menghindari false positive, tetapi tetap mampu menemukan cukup banyak bug
  • Kesulitan yang sebenarnya bukan pada menemukan bug itu sendiri, melainkan pada penentuan prioritas dan verifikasi

Claude skill yang meninjau PR dengan beberapa model

  • Pendekatan AI code review yang membandingkan dan memperdebatkan beberapa model berfokus pada gagasan bahwa semakin banyak model berbeda yang dilibatkan, semakin kecil kemungkinan halusinasi atau laporan bug yang keliru
  • Claude skill yang digunakan menjalankan Claude sub-agent, Codex, dan Cursor Bugbot untuk meninjau PR
  • Setiap alat memberi peringkat bug dalam PR sebagai critical/high/medium/low, lalu hasilnya digabungkan untuk membuat laporan akhir yang sudah menyaring false positive
  • Cakupan “bug” dapat diperluas sesuai standar proyek
    • Pelanggaran prinsip KISS dan DRY
    • Apakah HTML/JSX ditulis dengan aksesibilitas yang baik
    • Apakah query SQL menggunakan indeks yang tepat
    • Standar kualitas spesifik proyek lainnya

Workflow nyata dan kriteria pengambilan keputusan

  • Pendekatan ini dapat menemukan banyak bug di PR, dengan tingkat false positive yang bisa ditekan hingga hampir nol
  • Masalah yang ditemukan beragam, mulai dari bug fatal terkait keamanan dan akurasi, masalah performa, hingga masalah dengan tingkat keparahan rendah seperti “komentarnya menyesatkan”

  • Alur penanganan umum

    • Masalah dengan peringkat critical dan high diperbaiki oleh agen, tetapi solusi yang tepat diarahkan oleh manusia
    • Proses ini diulang sampai tidak ada lagi critical/high
    • Masalah high/medium yang manfaatnya rendah dibanding biaya perbaikannya dilewati
    • Contoh khasnya adalah ketika dibutuhkan 100 baris kode untuk memperbaiki edge case yang sempit
    • Jika ada terlalu banyak masalah critical hingga pendekatan keseluruhannya dianggap salah, PR dibatalkan

Fokus pada kesehatan codebase, bukan produktivitas

  • Teknik ini tidak selalu meningkatkan kecepatan pengembangan
  • Selama proses review, bug lama yang sudah ada sebelum PR dapat ditemukan, lalu berujung pada penulisan unit test dan perbaikan cacat yang subtil
  • Pendekatan ini nyaris kebalikan dari gaya pengembangan “produktivitas 10x” yang sering diasosiasikan dengan “vibe coding”
  • Dalam arsitektur yang kompleks, failure mode bisa lebih menarik daripada jalur normal, dan proses memahami serta memperbaiki titik kegagalan itu dapat menjadi cara untuk mempelajari codebase
  • Berguna untuk memperbaiki kesehatan seluruh codebase sambil mempelajari bagian-bagian yang kurang dikenal

Praktik untuk vibe coding yang lambat

  • Jika Anda adalah developer yang memakai agen untuk membuat PR ratusan baris yang bahkan belum sepenuhnya Anda pahami, Anda bisa mencoba pendekatan yang lebih lambat
  • Anda dapat bertanya kepada agen bagaimana PR tersebut bekerja dan di mana ia bisa gagal
  • Jika perlu, Anda dapat memintanya menulis dokumen Markdown yang menyertakan Mermaid charts
  • Anda dapat memakai skill Matt Pocock /grill-me sampai benar-benar memahami PR dari awal sampai akhir
  • “Produktivitas” yang diukur berdasarkan jumlah baris kode mungkin tidak meningkat, dan setelah menghabiskan banyak token, Anda bisa saja sampai pada kesimpulan bahwa rencana awal memang salah
  • Pendekatan ini lebih dekat pada bentuk yang memperkuat pemrograman yang hati-hati, sistematis, dan terobsesi pada kualitas yang sudah lama diupayakan bahkan sebelum era LLM

Bacaan terkait

2 komentar

 
GN⁺ 2026-05-26
Pendapat Hacker News

  • Saat bekerja dengan AI, prosesnya kini bukan lagi satu kali langkah sederhana, melainkan loop review bolak-balik yang panjang
    Untuk fitur berskala menengah yang melintasi beberapa area, pertama-tama saya menyusun desain implementasi dengan AI, lalu meninjau detailnya, kemudian mengimplementasikannya dengan Claude 4.7 Max yang lambat tetapi hasilnya bagus
    Setelah itu saya meninjau implementasinya dan meminta Codex GPT 5.5 xhigh fast untuk me-review lagi, dan hampir selalu ia menemukan edge case. Perbaikannya saya serahkan ke Claude; Codex kuat dalam mencari bug dan review, tetapi codenya cenderung over-engineered atau mencampurkan jalan pintas, sedangkan Claude menulis kode yang lebih intuitif dan mudah dipelihara
    Lalu saya minta instance Claude/Codex baru untuk meninjau ulang perubahan yang sudah di-stage, menerapkan feedback, lalu menambahkan test juga. Ini masih lebih cepat daripada menulis manual, tetapi sebagian besar waktu habis untuk review dan menangani edge case, dan hasilnya membuat fitur v1 terasa seperti implementasi mirip v3 yang sudah diulang berkali-kali

    • Sebelum implementasi, cocok juga untuk mendiskusikan masalah dengan AI sampai bosan
      Rasanya produktif, hasil AI juga bagus, dan biasanya saya tetap memahami kodenya. Setelah seharian berdebat dengan robot soal desain dan arsitektur, saya merasa justru di sinilah revolusi AI membuat saya menjadi engineer yang lebih baik
    • Menurut saya memang persis begitu. Terlalu banyak orang meminta AI menyelesaikan pekerjaan kompleks sekaligus lalu kaget karena AI bertingkah seperti junior yang diberi tugas mendadak
      Cara saya adalah menjalankan 5 putaran riset/perencanaan/rencana pengujian, dan pada setiap keputusan penting saya masuk ke dalam loop. Saya mulai dari bentuk besar lalu turun ke detail; perencanaan saja bisa memakan 2–3 hari waktu saya, dan agen implementasi (Opus 4.7) bisa butuh berjam-jam
      Implementasi dibagi ke beberapa tahap/commit dan tiap tahap punya loop perbaikan code review. Deep code review terakhir juga bisa memakan 1–2 jam, dan saat PR dibuka Gemini akan me-review, lalu saya membaca hasilnya dan menyelesaikannya
      Proyeknya tetap butuh beberapa hari atau beberapa minggu, tetapi dibanding melakukan semuanya sendiri, ini 5 kali lebih cepat
      Tambahan: skill itu ada di https://github.com/scosman/vibe-crafting
    • Saat coding dengan AI, alur saya juga cukup mirip, tetapi bahkan ketika berjalan baik, sering kali waktunya tetap mirip dengan menulis sendiri
      Dalam beberapa kasus saya membuang hasil buatan AI dan langsung mengerjakannya sendiri. Menurut saya ini keterampilan yang perlu dipelajari orang. Pada titik tertentu kita harus tahu kapan harus berhenti. Saya pernah melihat rekan kerja terus berdebat dengan LLM untuk menyuruhnya melakukan sesuatu, bahkan untuk perubahan sederhana
    • Pendekatannya mirip, tetapi saya juga menyiapkan arsitektur manual/kontrak tingkat atas/stub dasar lebih dulu agar konsisten dengan sistem lain dan lebih mudah dibaca
    • Lalu kalau Anthropic sedang outage, apa tinggal minum kopi sambil menunggu?
      Dengan terus menjaga AI agar tetap berjalan dan hanya sedikit lebih cepat, bukankah pengetahuan dan kendali atas apa yang dikerjakan AI justru berkurang?

  • Tulisan tentang membuat LLM saling mengkritik code review satu sama lain[1], tool magpie[2], dan tulisan terbaru Cloudflare tentang stack code review mereka[3] cukup meyakinkan
    Saya skeptis terhadap AI, tetapi alasannya lebih ke apakah ini “baik untuk dunia” daripada sekadar “apakah ini bekerja”. Pekerjaan review seperti ini terasa sebagai kasus langka yang tidak mengalihdayakan proses berpikir atau menurunkan kemampuan pekerja. Rasanya tidak menyalakan alarm yang sama seperti membiarkan AI menulis kode, atau membiarkan AI memperbaiki masalah yang ditemukan AI
    Tentu saja, masalah lingkungan dan kekhawatiran etis lainnya tetap besar
    Saya terkesan dengan kualitas code review AI belakangan ini, tetapi pengalaman berinteraksi terpisah dengan tiga reviewer AI di GitHub PR itu mengerikan. Akan lebih baik jika ada putaran review yang lebih lokal dan memahami jj/rebase
    Konteks: backend PHP/Laravel yang cukup besar dan frontend Vue
    [1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
    [2]: https://github.com/liliu-z/magpie
    [3]: https://blog.cloudflare.com/ai-code-review/

  • Waktu yang dipakai untuk loop review/perbaikan LLM rata-rata justru lebih lama daripada menulis kode langsung dengan tangan
    Salah satu alasannya, ketika saya sedang masuk flow, saya bisa menulis kode sangat cepat, dan kadang kode mengalir keluar lebih cepat dari perkiraan. Selain itu, kode yang dikeluarkan LLM pada beberapa percobaan pertama biasanya memang jelek sekali
    Meski begitu, yang menarik adalah jika saya meninjaunya sendiri dan memberi instruksi review serta perbaikan berkali-kali, hasilnya rata-rata lebih berkualitas daripada kode yang akan saya tulis sendiri dalam waktu yang sama. Dengan melihat kode orang lain diiterasi berkali-kali, saya merasa jadi memahami tujuan yang ingin saya capai secara lebih menyeluruh daripada hasil yang muncul spontan saat sedang larut dalam pekerjaan

    • Kalau AI menulis kode yang buruk, berarti AI-nya yang harus diganti. AI tingkat tinggi saat ini seharusnya tidak menghasilkan kode buruk

  • Tulisan ini bukan tentang menulis kode dengan AI, melainkan hanya membahas code review
    Masalah yang saya alami dalam agentic coding adalah saat memrogram, kita membuat sangat banyak keputusan arsitektur mikro. Hampir tidak pernah ada spesifikasi yang lengkap sejak awal; spesifikasi itu dibangun sambil melihat apa yang ditulis
    Jika memakai Claude Code atau Codex, proses itu hilang. Claude Code terlalu berhasrat mencapai tujuan akhir, sehingga pengalaman pair coding dengannya terasa seperti mimpi demam. Akhirnya kepercayaan diri terhadap edge case atau seberapa cocok hasilnya dengan tujuan arsitektur/desain proyek jadi menurun
    Selain itu, saya memang menikmati pemrograman, reverse engineering, dan semacamnya. LLM mungkin bisa menyelesaikan suatu masalah atau mengirimkan sebuah fitur, tetapi rasanya seperti merampas kesenangan itu. Saya sedang berusaha menemukan alur kerja yang bisa saya gunakan dengan percaya diri, tetapi saya khawatir pada akhirnya alur itu hanya akan menjadi peran rubber duck untuk chat, pencarian, dan pikiran saya

  • Sebaliknya, beberapa perusahaan mendorong agar engineer membuat pipeline agen evaluasi mandiri yang tangguh dengan memasukkan umpan balik manusia ke dalam loop, sehingga agen menulis sebagian besar kode produksi
    CEO Creao mengatakan pada Januari tahun ini bahwa mereka melakukan re-arsitektur seluruh sistem produksi hanya dalam 2 minggu. Ia juga mengklaim bahwa para agen mengimplementasikan terlalu banyak fitur terlalu cepat sehingga mereka harus menunggu sisi pengembangan bisnis mengejar ketertinggalan
    Saya penasaran bagaimana menilai pilihan antara meningkatkan output 100x dengan AI dan menggunakan AI untuk mengembangkan kemampuan diri sendiri
    Di sisi lain, peningkatan produktivitas dari AI itu nyata. Misalnya, satu organisasi engineering di Snowflake untuk pertama kalinya dalam sejarah perusahaan mencapai semua OKR kuartal pertama lebih awal. Biasanya mencapai 70% dari OKR yang direncanakan saja sudah dianggap bagus, jadi saya bisa membayangkan stres yang dirasakan para engineer setelah melihat hasil seperti ini

  • Judul tulisan ini terlihat seperti akan lebih mendalam, dan saya mengharapkan contoh kode yang nyata
    Namun isinya mirip tulisan opini lain. Sekadar menyarankan prompt yang berhasil untuk penulis, yakni cara menyuruh AI mencari bug, lalu menganjurkan semua orang melakukan hal yang sama
    Saya memakai alat seperti ini baik di pekerjaan maupun proyek sampingan pribadi, jadi saya berharap bisa melihat dan belajar, tetapi tulisan opini tanpa contoh sekarang sudah terlalu banyak

    • Saya penasaran apakah alur yang diusulkan itu benar-benar sudah dicoba sendiri. Menurut saya ini alur yang berguna, dan kalau saya belum menemukan alur serupa sebelumnya, saya akan berterima kasih atas petunjuk seperti ini
      Penulis bisa saja membuat harness kode untuk ini atau merangkainya dengan cepat, tetapi saat ini pengemasan menjadi alat seperti itu tampaknya lebih dekat ke wilayah Anda sebagai praktisi. Jika Anda ingin mengotomatiskan dan bereksperimen, jujur saja kemungkinan lebih cepat jika Anda sendiri yang mendeskripsikan apa yang diinginkan daripada harus menangani kodenya

  • Saat membaca ini saya sedang mengerjakan fitur yang cukup padat, dan butuh banyak iterasi
    Hasil akhirnya justru menjadi kode yang jauh lebih sedikit dibanding kode yang ada di tengah proses. Jadi saya sempat bertanya-tanya apakah AI benar-benar membantu. Dengan waktu yang dihabiskan untuk iterasi, saya mungkin saja bisa menulis kodenya sendiri
    Tetapi berkat AI, saya bisa dengan cepat membuat secara kasar 4 variasi fitur yang tidak saya sukai, dan sama cepatnya membuangnya tanpa beban

    • Salah satu peningkatan terbesar yang saya dapat dari memakai AI justru hal ini
      Dulu sebelum mulai mengimplementasikan fitur baru, saya harus sangat banyak memikirkan rencananya, dan ketidakselarasan dengan kode yang sudah ada sering baru terlihat setelah cukup banyak implementasi ditulis. Sekarang saya bisa meminta AI membuat rencana implementasi terperinci dan menemukan masalah detail kecil seperti ini dalam beberapa jam, atau bahkan kurang
    • Jadi kesimpulannya? Apakah ini layak dilakukan?

  • Hal yang menarik selama beberapa tahun terakhir adalah melacak batas kemalasan saya dalam ngoding
    Sebagai programmer, saya tidak suka kode boilerplate. Saya tidak suka menulisnya dan tidak suka merawatnya. Karena itu saya sering menentukan desain dan arsitektur dengan preferensi tersebut sebagai pusatnya; kadang itu bijak, kadang tidak. Bagaimanapun itu preferensi saya, dan saya menghindari hal-hal yang sulit saya kerjakan
    Beberapa tahun lalu ketika LLM mulai cukup berguna untuk coding, saya menyadari bahwa model-model itu pada dasarnya sangat hebat untuk boilerplate, dan sekitar 2023 hampir hanya itu yang mereka lakukan dengan baik. Itu membuat saya berpikir tentang betapa banyaknya perhatian yang telah kita berikan dalam desain dan arsitektur sistem berdasarkan pemahaman implisit atas kekuatan dan kelemahan orang-orang yang bekerja bersama kita
    Model terbaru punya kekuatan dan kelemahan yang sangat berbeda dibanding manusia, dan menempatkannya dengan tepat adalah latihan yang menarik yang menuntut jenis arsitektur dan keterampilan engineering yang berbeda. Saya menikmatinya dan berharap tetap begitu

    • Boilerplate menjadi opsional atau ditulis otomatis jika ada library atau framework yang bagus
      Jauh lebih baik mendapatkan output yang deterministik dari django-admin startproject, npm init, meteor create daripada melempar prompt ke LLM tanpa tahu apa yang akan keluar
      Dalam ekosistem web yang matang, boilerplate diminimalkan. Sekarang setelah pekerjaan ini diserahkan ke LLM, saya khawatir upaya pengembangan untuk membuat CLI jenis startproject dan default yang baik akan berkurang

  • Saya suka ini. Saya juga memakai pendekatan ralph-loop yang mirip
    Dimulai dari rencana yang sudah disetujui lalu diteruskan ke koordinator, dan jika disederhanakan diproses lewat 2 sesi, build dan review, dengan model terpisah untuk tiap sesi

  • Penghalang bagi saya untuk memakai agen coding adalah bahwa saya harus bergantung pada layanan eksternal berbayar
    Apakah ada model lokal yang cukup bagus untuk dipakai coding?

    • Per bulan ini, Qwen3.6 (27B atau 35B-A3B) dan Gemma 4 sering disebut
      Ini juga mungkin membantu: https://hnup.date/hn-sota
      Model Qwen adalah model harian saya minggu ini
 
GN⁺ 2026-05-26
Opini Lobste.rs

  • Di tempat kerja saya, kami sudah menyerah pada mimpi bergerak lebih cepat dengan AI. Dalam kasus kami, coding bukan bottleneck
    Meski begitu, hal yang bagus dari agen coding adalah ia membuat kami bekerja seperti insinyur yang selalu ingin kami jadi
    Misalnya, membuat test harness yang layak agar bisa mendorong kode sedikit lebih jauh, menambahkan tahap CI yang memverifikasi apakah kode hasil generasi sesuai dengan sumber aslinya, dan memantau deployment perubahan dengan benar
    Dulu hal-hal seperti ini tidak mungkin saya tanggung dari sisi jadwal, karena saya harus membaca manual GitLab CI, mencari tahu cara memenuhi kondisinya, dan memahami cara kerja perusahaan kami yang berbelit-belit; sekarang itu jadi mungkin, dan menurut saya inilah masa depannya

  • Saya cukup sukses menggunakan LLM sebagai partner spike yang paham API atau alat refactoring mekanis, terutama di bahasa yang strongly typed. Ini juga bagus untuk menulis test, tetapi perlu ada prosedur berlapis untuk memastikan test itu benar-benar punya daya paksa
    Mutation testing cukup membantu, dan seperti yang disarankan tulisan aslinya, peninjauan berulang juga diperlukan
    Dulu saya jauh lebih negatif terhadap LLM, dan kalau dipikir-pikir sampai agak tidak rasional, tetapi sebagian besar itu karena software berkualitas rendah yang terus dimuntahkan LLM
    Setelah saya menggali sendiri, ternyata yang tepat adalah memperlakukannya sebagai alat prototyping dari kardus dan juru ketik yang jauh lebih cepat. Misalnya, kalau saya bilang “cari pola ini di semua teorema pada proyek Lean ini lalu ubah jadi pola itu, dan tandai yang tidak langsung berhasil lalu beri saya daftar sisanya”, ia akan memperbaiki lebih dari 100 teorema per chunk dalam waktu yang biasanya saya habiskan untuk satu-dua percobaan awal dengan campuran vim, sed, awk, dan akal-akalan
    Lean sangat cocok karena, berkat karakteristik bahasa dan jenis pekerjaan saya, jarak antara “berhasil dikompilasi” dan “berfungsi” itu sempit, dan di Rust saya merasakan hal serupa jika dipasangkan dengan test suite yang bagus dan mutation testing
    Ekor panjang dari alat-alat ini bukanlah “tekan tombol lalu produk jadi”, melainkan insinyur yang baik menerima alat ini, memusatkan energinya pada hal-hal penting, dan mendelegasikan banyak pekerjaan remeh yang dulu harus dilakukan sendiri kepada mesin

    • Awalnya saya juga sangat negatif terhadap LLM, tetapi sekarang menurut saya kualitasnya sudah membaik sampai titik di mana lebih sering membantu daripada mengganggu
      Contohnya menarik; dulu ketika saya bekerja di tim framework JavaScript, saya menulis sendiri codemod untuk pekerjaan seperti upgrade atau migrasi. Itu pekerjaan berat mengutak-atik AST
      Kalau sekarang, rasanya saya bisa menyerahkannya ke LLM dan mencapai sekitar 90%

  • Saya suka sudut pandang seperti ini. Kelihatannya sudah jelas bahwa alat ini fleksibel dan tidak harus selalu menghasilkan keluaran berkualitas rendah, tetapi baik pihak yang mendukung maupun yang menolak sering mengabaikan pandangan ini
    Saya belum pernah mencoba code review dengan LLM, tetapi sepertinya perlu saya masukkan ke daftar hal yang harus dicoba. Sejauh ini saya memakainya untuk menghasilkan ide, membantu SQL atau VimScript, dan menulis kode sendiri
    Salah satu risikonya adalah code review juga merupakan keterampilan, jadi kalau terlalu bergantung pada model, kemampuan itu bisa menurun. Namun, di lingkungan komersial, bahkan code review terbaik pun biasanya adalah gabungan dari “waktu yang cukup” dan “apakah saya memercayai orang ini”, bukan sesuatu yang mendekati ketepatan matematis

    • Itu juga benar, tetapi saya justru merasa alur kerja ini meningkatkan kemampuan code review saya. Soalnya saya harus menilai apakah “bug” itu benar-benar mungkin terjadi atau hanya teoritis, apakah layak diperbaiki, atau sebaiknya dipindahkan ke PR berikutnya
      Untuk bug yang rumit, saya cenderung tetap memikirkannya sendiri sampai tuntas, karena 1) halusinasi masih kadang ikut masuk, dan 2) memang ada nilai dalam memahami sistem secara end-to-end

  • Sedikit meta, tapi saya tidak paham dengan flag yang dipasang pada tulisan ini. Ada 1 off-topic dan 3 spam, aneh sekali
    Tulisan paling atas di halaman depan juga tentang penggunaan LLM, dan karena itu tulisan tentang penulisan umum, fokus topiknya malah tampak lebih lemah daripada tulisan ini yang berfokus pada coding, tetapi sepertinya tidak kena flag

    • Mungkin dianggap promosi diri, jadi diberi flag spam

  • Menyegarkan melihat sudut pandang seperti ini di Lobsters. Sentimen anti-AI yang menyapu rata makin melelahkan. Saya rasa semua orang bisa sepakat bahwa tidak ada yang suka hasil berkualitas rendah
    Tetapi orang-orang yang memboikot AI sepenuhnya dan mengambil sikap menggurui akan lebih sulit menerima masa depan dibanding mereka yang mengambil sikap lebih praktis
    Sejak awal saya selalu mengatakan AI mirip dengan penemuan alat listrik. Kalau Anda ingin mengganti ban dengan kunci roda manual, tidak masalah, tetapi para montir tidak memboikot saat impact drill muncul. Dalam konteks tulisan ini mungkin itu bukan analogi terbaik, tetapi menurut saya tetap relevan
    Saya belajar lebih banyak saat menggunakan AI daripada saat membaca dokumentasi, karena pada dokumentasi Anda tidak bisa bertanya ketika butuh konteks tambahan, penjelasan, atau contoh. Anda bisa saja bilang “buat sesuatu, jangan salah”, tetapi saya lebih suka pendekatan yang lambat untuk benar-benar belajar

    • Saya tidak melihat sentimen anti-AI yang menyapu rata di sini. Bisa beri tautan contohnya?
      Yang saya lihat adalah kritik terhadap perubahan dengan LLM pada jutaan baris kode sekaligus lalu mengirimkannya tanpa review manusia. Secara spesifik, misalnya thread tentang porting Bun dari Zig ke Rust
      Tulisan ini juga mengkritik hal itu