Metode coding AI “tali pendek” yang mengalahkan Fable

• Untuk memakai agen coding AI pada perangkat lunak yang kritis terhadap keamanan, alih-alih menyerahkan eksekusi otonom, diperlukan pendekatan Short Leash di mana developer terus mengendalikan perubahan
• Pendekatan bergaya “vibe”, di mana beberapa agen membuat dan meninjau kode secara paralel, dapat melemahkan pemahaman terhadap codebase dan membuat masalah baru diketahui setelah AI masuk ke kondisi off the rails
• Prosedur intinya berlanjut dari penyusunan rencana, pemecahan tahap, peninjauan diff pada prompt izin, penolakan dan intervensi yang sering, commit per subtugas, hingga review akhir
• Dalam review PR, AI dan manusia harus digunakan bersama untuk mengurangi kesalahan; AI cepat menangkap error umum, sementara manusia menilai masalah dan arah pada level yang lebih tinggi
• PR yang penulisannya melibatkan AI harus ditinjau langsung baris demi baris oleh pengaju, dan model yang digunakan harus dicantumkan dalam deskripsi PR sebagai AI Disclosure agar memperoleh kepercayaan

---

Prasyarat untuk memakai agen coding AI

• Metode ini didasarkan pada pengalaman menggunakan agen AI untuk membuat perangkat lunak berkualitas tinggi pada sistem yang kritis terhadap keamanan
• Sasarannya bukan developer pemula yang harus memandang AI sebagai musuh pembelajaran, melainkan developer profesional yang, di bidang keahliannya sendiri, lebih unggul daripada “frontier AI models”
• Tujuannya adalah memakai AI sebagai alat peningkat kinerja tanpa mengorbankan kualitas perangkat lunak
• Cakupan pengalamannya mencakup eksplorasi batasan agen AI, pembuatan alat review AI sendiri, dan pemeliharaan fork kustom dari agen coding AI Crush

Titik rapuh pendekatan bergaya “vibe”

• Dalam sesi yang memakai agen AI, dua masalah dapat sering muncul
  • Belakangan baru menyadari bahwa ide awalnya buruk dan ada pendekatan yang lebih baik
  • Agen masuk ke kondisi off the rails ke arah yang tidak diinginkan
• Jika beberapa agen paralel dan orkestrator bekerja serentak sementara developer keluar dari proses coding, sulit untuk membangun pemahaman langsung terhadap codebase
• Dalam situasi ketika kualitas tidak diperhatikan, cara seperti ini mungkin masih baik-baik saja, tetapi bila kualitas penting, diperlukan pendekatan lain
• Kode yang ditulis atau ditinjau Fable 5 bisa saja berjalan, tetapi tidak efisien dan tampak buruk
• Di area niche dengan sedikit data pelatihan yang dapat diandalkan model, masalah seperti ini bisa lebih sering terjadi
• Berbeda dari pemasaran beberapa CEO tertentu, dalam sudut pandang ini model tidak dapat berpikir melampaui data pelatihannya

Cara kerja pendekatan Short Leash

• Pendekatan Short Leash bukan metode yang bisa dipakai sembarang orang, dan ditujukan untuk developer perangkat lunak profesional
• Kelebihannya adalah dapat menghasilkan hasil yang mengalahkan Fable meski tanpa memakai frontier model
• Sebelum bekerja, pada tahap perencanaan dilakukan riset terhadap tugas dan penyusunan rencana
  • Tugas besar dilacak progresnya dan dipecah menjadi tahap-tahap menggunakan alat seperti tasks skill
  • Bagian ini memiliki kesamaan dengan berbagai metode “vibe engineering”
• Setelah itu, intinya adalah terus menahan AI dengan tali pendek
  • Tidak memakai mode “YOLO” atau “dangerously skip permissions”
  • Tidak membiarkan AI bekerja sendiri saat pengguna bermain game
  • Menggunakan agen coding yang menampilkan diff perubahan yang akan diterapkan pada prompt izin
  • Developer benar-benar menganalisis perubahan yang diusulkan AI
  • Dengan diff pada prompt izin, developer menjaga pemahaman codebase tetap mutakhir dan mengendalikan AI
  • Jika AI mencoba melakukan pekerjaan yang tidak diinginkan, izin ditolak
  • Sering mengintervensi saat perlu agar AI tidak kehilangan arah
• Setiap kali subtugas selesai, buat commit untuk mencegah AI merusak atau menghapus pekerjaan sebelumnya
  • Hal seperti ini benar-benar bisa terjadi, dan ada kasus yang pernah terlihat pada Opus
• Pada tahap terakhir, lakukan review

Review AI tidak menggantikan review manusia

• Dibanding PR yang direview hanya oleh manusia atau hanya oleh AI, PR yang direview bersama oleh manusia dan AI dapat lebih mengurangi kesalahan
• AI dapat diperlakukan seperti linter
  • Cepat menangkap kesalahan umum
  • Manusia menilai masalah pada level yang lebih tinggi dan kebutuhan perubahan arah
• Semua PR disarankan melalui review AI
• Review AI memerlukan konteks yang cukup
  • Issue
  • Deskripsi PR
  • Codebase
  • Perubahan
• Untuk review, disarankan memakai model terbaru yang tersedia

AI Disclosure dan tanggung jawab pengaju

• Jika AI digunakan dalam penulisan PR, model persis yang digunakan harus diungkapkan di bagian AI Disclosure pada deskripsi PR
• Pengungkapan ini memiliki beberapa tujuan
  • Memberi tahu maintainer bahwa AI digunakan
  • Jika model yang dipakai lemah, memungkinkan mereka menyarankan model yang lebih baik
  • Memberi sinyal bahwa pengaju tidak mencoba menyelundupkan AI secara diam-diam
• PR yang menggunakan AI wajib direview langsung oleh “penulis” PR tersebut
• Karena PR berbantuan AI pada praktiknya lebih dekat dengan PR dari AI yang dibantu manusia, pengaju harus memahami apa yang diajukan
• Pengaju harus melihat PR miliknya seperti PR orang lain dan mereview sendiri secara line-by-line
• Setelah review mandiri selesai, pengaju dapat mengonfirmasi persetujuannya sendiri dan meminta maintainer melakukan peninjauan
• Proses ini berfungsi untuk membangun sekaligus menunjukkan bahwa pengaju memahami codebase

Cara penerapan okTurtles

• okTurtles menggunakan AI dengan cara ini
• Kebijakan resminya dirangkum dalam AI Usage Policy
• Artikel ini sendiri ditulis oleh manusia, dan menyertakan AI Disclosure bahwa sebelum dipublikasikan hanya dilakukan pemeriksaan ejaan bergaya AI

[GN⁺]

Komentar Hacker News

• Pendekatan “tali pendek” ini terlihat lebih seperti kruk daripada alat bantu, dan terasa seperti tanda bahwa sejak awal masalahnya tidak dijelaskan cukup baik ke AI, atau hasil keluarannya tidak ditinjau dan diiterasi
  Menuntun model kuat seperti Fable langkah demi langkah pada tahap implementasi adalah pemborosan waktu sekaligus pemborosan Fable. Justru dengan model yang kuat, kita bisa berdiskusi soal desain yang lebih bernuansa dan menghasilkan kode yang jauh lebih baik daripada dulu. Mendiskusikan desain dan implementasi, mempertanyakan bagian yang tampak aneh, dan benar-benar membaca jawaban AI itu sendiri membantu menemukan solusi yang lebih baik
  Dulu saat mencoba membuat solusi algoritma rakus, lewat diskusi dengan Opus saya mendapat usulan bahwa masalahnya bisa diselesaikan secara tepat dengan library MILP yang sudah ada. Saya bahkan belum pernah mendengar MILP, tetapi implementasi akhirnya jadi lebih baik dan lebih sederhana daripada kalau saya kerjakan sendiri

  • Katanya kita bisa berdiskusi lebih bernuansa dengan model kuat, tetapi ketika saya tanya ke Claude kenapa ia membuat perubahan kecil yang tidak saya pahami, ia menjawab bahwa ia “menalar dari prinsip pertama” berdasarkan jalur kode
    Ternyata itu tidak bekerja, dan ketika saya minta menjelaskan langkah penalaran dari prinsip pertama itu, ia mengaku sebenarnya hanya mengarang. Jadi saya sulit percaya pada gagasan diskusi bernuansa dengan model
  • Secara umum saya setuju
    Jika Anda sudah berinvestasi cukup banyak di tahap perencanaan dan arsitektur yang ada beserta konvensi proyek sudah solid, mungkin tahap implementasi tidak perlu diawasi sebanyak yang dibahas di sini
    Hal seperti “ide awalnya bodoh dan ada cara yang lebih baik” biasanya ditemukan pada tingkat tinggi di tahap perencanaan dan arsitektur
    Masalah agen “keluar jalur” ke arah yang tidak diinginkan juga tidak seburuk dulu, dan perubahan yang berdampak setidaknya harus punya cakupan pengujian minimal. Meski tes itu hanya sebatas “mengunci” perilaku yang telah diimplementasikan, diskusi peninjauan terakhir tetap jadi kesempatan bagus untuk memeriksa hal-hal di luar yang ditemukan review atau agen review yang bersifat adversarial
  • Saya agak bingung sebenarnya bagian mana yang ditentang. Membaca respons AI dan meninjau kode pada akhirnya tampak seperti pendekatan yang sama
    Contoh MILP itu bukan sesuatu yang akan dicegah oleh pendekatan ini, dan kemungkinan akan muncul pada tahap perencanaan
    Pada akhirnya detailnya yang penting, dan cara memberi prompt saat memulai pekerjaan akan berpengaruh. Tetap saja, memeriksa output, terlibat dengan apa yang dilakukan model, dan terus menanyai kenapa ia ingin membuatnya seperti itu adalah hal yang wajib
  • Tulisan ini terasa seperti micromanage AI. Kalau dipikir seperti pegawai junior, dengan micromanage Anda memang bisa membuatnya mengerjakan hal yang diinginkan dengan cara yang diinginkan
    Tetapi ide dari pegawai itu tidak pernah benar-benar muncul, dan dalam jangka panjang kontribusi yang bisa menguntungkan seluruh tim juga hilang
  • Saya memang memakainya dengan cara ini
    Ini membantu saya memahami semua yang dihasilkan dan terus mempertahankan pengetahuan kerja tentang codebase. Mengubah arah juga jadi mudah

• Saya melakukan ini selama dua minggu untuk side project, tetapi akhirnya malah tidak punya model mental terhadap codebase
  Ini justru makin meyakinkan saya bahwa tidak ada cara membangun model itu tanpa membuatnya sendiri secara langsung

  • Sayangnya saya sudah mengalami masalah yang sama bahkan sebelum ada AI
    Karena kurva lupa, model mental saya tidak bertahan lama dibanding masa saat pertama kali membangunnya. Saya masih belum tahu cara membangunnya kembali
  • Kalau Anda manajer proyek besar, bagaimana Anda membangun model itu? Maksud saya, saat pekerjaan menuntut Anda memahami keseluruhan proyek tetapi sebenarnya tidak perlu banyak menulis atau mereview kode
  • Tinggal minta modelnya menjelaskan kode
  • Saya kurang yakin. Menurut saya itu mungkin, tetapi Anda harus sengaja menggali bagian yang tidak dipahami, dan itu memang arah yang dianjurkan
    Namun saya setuju bahwa itu tidak banyak membangun kemampuan “saya bisa membuatnya sendiri” seperti ketika menulisnya langsung
    Misalnya, saya tahu perubahan apa yang harus dilakukan untuk mendapatkan efek tertentu, dan ketika benar-benar saya ubah hasilnya sesuai harapan, jadi saya tahu model mental saya bekerja. Tetapi kalau diminta membuat sesuatu yang mirip dari nol, saya rasa saya tidak bisa. Rasanya pendekatannya berada di tempat yang tidak bisa saya jangkau langsung, tetapi sulit dijelaskan
  • Code review sangat cocok buat saya

• Saya kira orang yang benar-benar bisa ngoding memang memakai AI seperti ini untuk pekerjaan penting
  Apa saya yang salah? Sekarang memang semua orang langsung jalan dengan mode YOLO?

  • Betul. Siapkan satu laptop yang memang tidak terlalu dipedulikan lalu biarkan Claude mengutak-atik sesukanya di dalam WSL
    Itu salah satu kesenangan saat sedang tidak bekerja. Begitu saya mulai kerja lagi, ini mungkin akan jadi perubahan yang cukup menarik
    Sekarang polanya sederhana: saya jalankan saja, lalu sambil minum bir saya luangkan sekitar satu jam untuk kritik arah besar dan menyetel ulang feedback loop self-check/closed-loop, lalu saya biarkan lagi berjalan sesukanya
  • Apakah yang dimaksud ini adalah jangan memakai “mode YOLO”, yaitu “melewati izin secara berbahaya”?
    Saya penasaran bagaimana orang memakai Claude selain dengan bypass-permissions. Saya sudah lama mencoba mengelola daftar alat yang boleh dipakai Claude, tetapi pada akhirnya saya selalu kembali dan mendapati ia berhenti karena mencoba menyalurkan output satu alat ke alat lain dan itu tidak diizinkan secara eksplisit. Padahal cuma hal seperti grep, tetapi tetap berhenti dan itu menjengkelkan
    Dalam bypass-permissions, semuanya “langsung jalan”. Tentu saja saya hanya memakainya untuk menganalisis kode yang ada dan memberi usulan perubahan, dan kalau ada yang rusak, itulah gunanya version control

• Secara umum saya setuju dengan penulisnya. Yang terutama ingin saya tambahkan adalah jangan percaya apa pun yang dilakukan atau dikatakan LLM
  Hari ini saya meminta Claude menyamakan perilaku 3 komponen, dan saya menyuruhnya 5 kali. Setiap kali sampai di akhir, tetap ada bagian yang belum cocok, dan Claude selalu menemukan cara untuk merasionalisasikannya
  Kalau ditanya, ia menjawab “itu tanggung jawab saya” atau “saya menganggap itu pilihan yang disengaja”, tetapi ia tidak pernah sekalipun lebih dulu bertanya apa yang seharusnya dilakukan atau mengungkapkan masalahnya. Jadi memang harus memegang tali pendek, melihat proses berpikirnya, dan segera membetulkan saat ia mulai ngaco. Ini berdasarkan Sonnet 5 hari ini; besok bisa saja lebih baik atau malah lebih buruk. Cara bicara yang berhasil ke Claude hari ini bisa memberi hasil berbeda besok

• Masalah dari tulisan jenis “cara melakukan X dengan AI” adalah setiap situasi sepenuhnya berbeda. Misalnya, pekerjaan menaikkan proyek Symfony dari 3.1 ke 8.1 punya jalur yang jelas
  Cukup ikuti panduan migrasi yang ditulis untuk tiap versi mayor, lalu uji semua route, alur autentikasi, dan semacamnya. Pengujian ini juga bisa dipilih sendiri, dan beberapa bisa mengembalikan 200, yang lain 302
  Secara opsional, bisa lebih dulu menulis jaring pengaman untuk mengurangi pengujian manual, misalnya dengan menyiapkan baseline PHPStan
  Jika route bekerja secara fungsional end-to-end sesuai maksud, maka selesai. Snapshot test juga bisa dipakai di sini
  Dalam kasus seperti ini tidak perlu mengawasi AI. Kodenya bisa direview di akhir, tetapi tidak perlu persetujuan manual di tengah proses, jadi fitur keamanannya dimatikan

  • Ini bukan semata masalah “cara melakukan X dengan AI”, melainkan lebih dekat ke cara kita menerima konten internet
    Kebanyakan orang menulis dari satu sudut pandang, tetapi sudut pandang nyata itu luas, dan apa yang berhasil di satu situasi belum tentu berhasil di situasi lain. Rekayasa perangkat lunak pada akhirnya mirip pekerjaan memahami apa yang diterapkan, di mana, dan kapan, lalu mengabaikan sisanya
    Banyak tulisan blog perusahaan membuat orang percaya seolah ada peluru perak yang berlaku untuk semua kasus, padahal biasanya tidak benar
    Pada akhirnya ini tetap lebih dekat ke “beberapa hal bekerja dalam situasi tertentu”, seperti yang selalu dibahas dalam rekayasa perangkat lunak; bukan soal benar atau salah, melainkan penerapan nyata yang berbeda menurut situasi, dan itu normal
  • pernah pakai rector?

• AI itu setara engineer junior sampai menengah. Jika diperlakukan seperti itu, kita bisa mendapat kelebihan vibe coding dan engineering yang ketat tanpa semua paranoia ini
  Sejak awal saya menjalankan Claude dalam mode YOLO di VM yang terisolasi. Ini sama seperti memberi laptop sendiri kepada seorang engineer. Claude membangun fitur sampai titik yang layak dijadikan PR, lalu saya me-review diff-nya seperti engineer lain, merapikannya seperlunya, lalu lanjut
  Engineer yang belum matang juga membuat kesalahan yang sama. Saya juga pernah melihat rm -rf, meski bukan dijalankan dari root. Kalau harus micromanage seseorang sambil menolak semua izin, saya rasa saya akan jadi gila

  • Saya sangat setuju dengan sudut pandang ini, dan justru karena itu tulisan ini makin sulit saya pahami. Bukankah PR memang sudah menjadi gerbangnya? Apa pun yang dilakukan agen di dalam workspace, selama kontribusinya digating lewat repositori git dan tidak butuh akses produksi aneh untuk development, saya tidak peduli
    Saya juga setuju dengan analogi engineer junior/menengah, tetapi ada catatan besar. AI itu seperti engineer junior yang tidak tahu cara belajar
    Rasanya seperti bekerja dengan tokoh utama di Memento. Setiap hari saat LLM masuk kerja, ia tidak belajar apa pun dari pekerjaan sebelumnya, dan setiap hari terasa seperti hari pertama
    Tentu, seperti tokoh Memento, kita bisa membantu dengan menebar post-it dan pengingat di seluruh workspace. Dengan usaha, ini bisa mendekati sesuatu yang mirip “pembelajaran”, padahal itu secara harfiah adalah sifat terpenting bagi semua developer perangkat lunak dalam tim
    Tetapi ini tidak mudah, dan alatnya juga masih kurang. Yang terbaik yang pernah saya lakukan lebih mirip “otak kedua” yang ditulis dengan alat seperti Obsidian. Sayangnya, menurut saya otak kedua bukan pengganti otak pertama. Sejujurnya, kalau ada engineer yang tidak bisa belajar dan berkembang seperti agen AI, di perusahaan mana pun tempat saya pernah bekerja dia pasti dipecat setelah bulan pertama
    Meski begitu, saya cukup optimistis bahwa penyedia AI besar atau seseorang pada akhirnya akan memperbaiki bagian ini. Jika memori yang baik digabung dengan sistem penalaran yang dirancang baik untuk menyuntikkan ingatan dengan lebih tepat sesuai konteks, dan bisa menangkap pembelajaran nyata tanpa pengawasan, itu tidak terasa seperti tugas yang mustahil
    Saya membaca tulisan seperti ini dengan harapan masalah ini sebenarnya sudah dipecahkan seseorang dan saya hanya terlambat menyadarinya, tetapi untuk saat ini kemampuan saya merancang agen hanya sedikit lebih baik daripada saat awal
  • Pengalaman saya juga sama. Menurut saya ini lebih mirip intern yang sangat pintar dan cepat. Potensinya terlihat besar dan dalam banyak hal sudah jauh lebih baik daripada saya, tetapi tetap perlu arahan dari tangan yang berpengalaman
    Aturan praktis saya adalah proses khusus yang dibuat untuk AI juga harus masuk akal untuk manusia; kalau tidak, itu tidak bernilai. Tool command-line yang baik, rangkuman otomatis untuk output perintah yang panjang, dokumentasi Markdown, dan workflow juga berguna bagi manusia
    Untuk mencegah kesalahan dan penyalahgunaan, yang dipakai bukan micromanagement melainkan sandbox dan izin dengan cakupan terbatas
    Yang ingin saya temukan adalah workflow pair programming yang baik dengan agen AI. Kita bisa memberi tugas besar ke model berperforma tinggi, dan itu bekerja baik. Kita juga bisa memakai model tingkat bawah sebagai pendamping IDE, dan itu juga bekerja baik. Tetapi keduanya adalah workflow yang terpisah
    Yang benar-benar berguna adalah cara bekerja bersama dengan model berperforma tinggi sambil bergantian memakai keyboard. Hanya saja, itu tidak seharusnya dijalankan dalam mode YOLO penuh di mesin saya. Di sinilah letak perbedaan manusia dan LLM. Karena terlalu cepat, saat mulai keluar jalur sulit untuk merebut kembali keyboard-nya
  • Kalau Claude diberi laptop sungguhan, dia juga bisa memperbaiki masalah audio Bluetooth Linux ;)
  • pakai VM/provisioning apa?
  • Ucapan “AI itu engineer junior sampai menengah” sekarang sudah tidak benar, dan salah kaprah seperti itu juga tidak membantu
    Tidak ada yang benar-benar tahu AI itu apa, tetapi jelas bukan engineer junior atau menengah. AI lebih mirip staf engineer bidang nuklir yang tinggal di gubuk, tidak punya konteks domain, dan bangun tiap 5 jam tanpa ingatan

• LLM pada dasarnya masih merupakan prediktor token berikutnya. Fakta bahwa ia bisa menemukan langkah yang benar meski diberi instruksi yang lebih ambigu bukan berarti ia punya kecerdasan. Itu berarti kamu berbicara dalam bahasa yang serupa dengan harness yang dipakai saat melatih model
  Dan ada batasnya. Jika kamu hanya berkutat di tingkat proof of concept atau aplikasi sederhana, kamu mungkin tidak sadar betapa terbatasnya model saat ini. Di situ, pekerjaan harus dipecah-pecah; jangan percaya pada prediktor token yang sekadar bisa menyusun langkah-langkah yang terdengar masuk akal
  Harus selalu ada human-in-the-loop di suatu titik. Kalau kamu mulai melewati batas otorisasi, hasil terbaiknya memang bisa spektakuler, tetapi yang lebih mungkin terjadi adalah solusi kelas dua dan pemborosan token. Yang benar-benar menakutkan adalah ketika model mengabaikan instruksi dan melakukan hal bodoh yang merusak satu hari penuhmu
  Ini setajam mesin CNC. Bukan berarti tidak berguna, tapi bisa berbahaya. Kalau kamu tidak bisa parkir paralel, lebih baik jangan mencoba memahat kayu dengan mesin monster atau memarkir Ferrari di lingkungan yang sempit

  • Prediksi token berikutnya bukan algoritma, melainkan antarmuka. Proses “memprediksi token berikutnya” bisa sekompleks atau sesederhana apa pun, dan kemampuan untuk mengerjakan tugas yang diberikan juga bisa sangat tinggi atau sangat rendah
    Mengatakan bahwa LLM bisa atau tidak bisa melakukan sesuatu karena ia adalah “prediktor token” adalah category error. Antarmuka itu sendiri bukan batas keras
  • Soal “bukan kecerdasan”, saya tidak tahu bagaimana kamu mendefinisikan kecerdasan
    Saya penasaran bagaimana mungkin membuat definisi yang mengecualikan model bahasa tetapi memasukkan manusia, tanpa memakai aksioma yang dari awal sudah menetapkan bahwa LLM tidak punya kecerdasan
  • Kalau begitu, kamu juga cuma orang yang mengucapkan kata berikutnya
  • Menyebut LLM sebagai “prediktor token berikutnya” itu sangat reduksionis dan tidak jujur. Secara teknis memang benar, tapi hal yang sama juga berlaku untukmu
    Biasanya maksud ucapan ini adalah “ia hanya memprediksi token berikutnya dari data pelatihan, yaitu internet”, dan itu mungkin benar untuk model mentah. Tetapi model kemudian menjalani post-training, jadi bahkan penjelasan ini pun tidak lagi tepat
    Pernyataan “ini bukan kecerdasan” juga tidak berguna dan menurut saya salah. Siapa peduli apakah ini cocok dengan definisi kecerdasan versimu. Tetap saja ia melakukan hal-hal yang mengesankan, bahkan jauh lebih hebat daripada yang kamu isyaratkan
  • Harus melewati ambang seperti apa agar kamu mau menyebutnya cerdas?

• Tulisan aslinya terasa seperti masih tertahan di tahun 2025
  Katanya, “AI akan beberapa kali keluar jalur dan kamu baru sadar saat benar-benar mencoba memakai perangkat lunaknya”, tetapi sekarang AI itu sudah bisa memakai perangkat lunak sendiri untuk menemukan dan memperbaiki bug, serta mendorong fitur baru
  Memang masih ada kasus agen mulai mengerjakan hal yang tidak diinginkan, tetapi itu jauh berkurang dibanding dulu, dan argumen untuk agen sepenuhnya otonom bukan melemah, melainkan makin kuat
  Pernyataan “manusia memahami codebase itu mustahil secara manusiawi” juga terdengar usang. Sekarang saya melihat kita bergerak ke arah di mana manusia tidak lagi perlu memahami codebase dan AI yang memimpin

  • Perusahaan AI punya insentif untuk mendorong slopmaxxing sembrono seperti ini. Hasil akhirnya adalah bisnismu akan sepenuhnya bergantung pada mereka, dan seluruh nilai produkmu juga akan berasal dari mereka
    Banyak orang ikut arus ini, tetapi saya menganggapnya tren yang bodoh
  • Betul, memahami sesuatu itu terlalu khas 2025
  • Ini mungkin benar untuk perangkat lunak non-inti seperti hiburan atau media
    Tetapi sama sekali tidak berlaku untuk sistem dengan risiko keamanan tinggi. Di bidang seperti perbankan, penerbangan, dan pertahanan, AI jelas akan berkontribusi, tetapi tidak akan bergerak terlepas dari pemahaman rekayasa manusia
  • Siapa pun yang punya insting yang cukup baik tentang pemrograman dan arsitektur yang efektif tidak akan setuju dengan klaim bahwa AI bisa langsung memakai perangkat lunak untuk menemukan bug dan membuat fitur
    Pendekatan tali pendek adalah cara untuk menjamin hasil yang baik saat bekerja di luar data pelatihan. Menurut saya, bagi programmer yang bahkan sedikit di atas rata-rata, ini adalah satu-satunya cara untuk menjamin pengembangan yang cepat dan berkualitas dengan LLM
    Mengatakan bahwa manusia tidak lagi perlu memahami codebase tampaknya datang dari ketidaktahuan tentang betapa buruknya AI dalam dunia pemrograman saat ini. Saya terus-menerus melihatnya gagal menangani memori dalam bahasa yang punya manual memory management. Ini tidak sesederhana sekadar memasukkannya ke dalam loop Valgrind
  • Saya sama sekali tidak merasa argumen untuk agen sepenuhnya otonom makin kuat. Ini pengalaman saya beberapa minggu lalu dengan Claude Code + Opus 4.8. Tugasnya tidak terlalu rumit: 4 endpoint API baru dan event yang di-stream ke klien lewat websocket
    Saya berulang kali menyempurnakan definisi API, model request/response, skema database, dan alur keseluruhan, sambil sendiri banyak menghapus kontradiksi dan memperbaiki dokumentasi. Opus terus keluar jalur, dan dokumen akhirnya lebih dari 500 baris
    Saya juga harus bolak-balik lagi pada integration test API. AI tidak bisa langsung membuat test dari dokumentasi, jadi saya lebih dulu membuat placeholder dengan komentar Given-When-Then, meninjaunya dan mengoreksinya secara manual, lalu pada iterasi kedua barulah test diimplementasikan. Ada banyak kesalahan yang diperbaiki setelah review
    Pada tahap implementasi, saya menyediakan dokumentasi API, test yang berjalan, hook pencegah perbaikan yang salah, lebih dari 6 skill “best practice”, agen “rubber duck” dan “code simplification”, serta skrip untuk memeriksa error test, linter, dan kompilasi. Setelah perencanaan, eksekusi, review, dan berkali-kali revisi, fiturnya memang terimplementasi dan semua test lulus
    Dalam code review, rata-rata saya menemukan satu masalah per 20 baris kode. Bahkan di luar gaya kode, ada penggunaan semaphore in-memory di layanan Kubernetes, 8 panggilan DB untuk mencoba memperbarui record yang sama dalam satu request, pembaruan satu kolom per sekali jalan, read-modify-save tanpa transaksi, serta kesalahan pada logika bisnis, pemulihan, dan otorisasi
    Hasilnya hampir satu minggu waktu kerja, biaya token lebih dari 100 dolar, dan cuma menyisakan pikiran, “apakah usaha ini sepadan?” Saya punya tim dengan 2 developer, dan barusan saya review PR salah satu dari mereka; 80% isinya slop

• Saya pernah mencoba pendekatan serupa, tetapi tidak terlalu cocok untuk saya. Peningkatan kecepatannya hampir tidak ada atau memang tidak ada. Untuk benar-benar mendapat produktivitas, menurut saya dibutuhkan semacam mode YOLO di dalam sandbox
  Tujuannya haruslah mengalihdayakan sebanyak mungkin pekerjaan ke model, sambil meminimalkan upaya yang diperlukan untuk memahami dan me-review hasilnya
  Misalnya dengan meminta model mencari akar penyebab bug, membuat proof of concept untuk X, mengoptimalkan sesuatu secara bertahap, atau melakukan refactor yang terdefinisi jelas dengan panduan
  Saat orang bilang mereka membangun loop, itu juga sangat mirip. Maksimalkan apa yang dilakukan model, dan minimalkan apa yang harus saya lakukan untuk mengendalikannya

• Tulisan ini nyaris tidak punya isi

  • Hanya mengikuti frasa yang sedang tren
    Tahun lalu: “AI hanyalah beo stokastik”
    Tahun ini: “AI memang bisa menulis kode, tetapi manusia tetap harus meninjaunya!” Tentu saja, AI juga dipakai untuk tinjauan itu
    Setahun lagi, narasinya akan menjadi “Code review hanya bisa dilakukan AI, dan yang bisa meninjau hasil review AI juga hanya AI. Manusia cukup membaca pendapat akhir AI agar tetap mempertahankan pengawasan yang bermakna”
    Tiang gawang terus bergeser, tetapi keyakinannya tidak pernah bergeser