Loop yang Akan Datang
(lucumr.pocoo.org)- Di luar coding agent, loop tingkat harness yang mengelola antrean kerja dan harness pengulangan muncul sebagai pola pusat baru dalam agent engineering
- Semakin lama model berjalan secara otonom, semakin mudah ia menambahkan pertahanan lokal dan fallback alih-alih invariant yang kuat, sehingga pada kode jangka panjang pemahaman desain dan kontrol bisa goyah
- Sebaliknya, di area seperti porting kode, eksperimen performa, pemindaian keamanan, dan riset, iterasi mekanis sudah bekerja sangat kuat karena hasilnya mudah diverifikasi atau dibuang
- Jika penyerang dan pelapor menjalankan loop, maintainer juga terdorong untuk memakai mesin dalam triage, reproduksi, dan respons; kasus curl menunjukkan beban yang ditimbulkan laporan buatan AI
- Tantangan ke depan bukan apakah akan memakai loop, melainkan bagaimana tetap menjaga penilaian manusia, aturan engineering, pengawasan yang bertanggung jawab, dan arsitektur yang bisa dipahami di dalamnya
Loop yang Berjalan di Luar Coding Agent
- Di dalam coding agent sudah ada agent loop tempat model memanggil alat, merefleksikan hasil, membaca dan mengubah file, menjalankan pengujian, lalu memberi jawaban
- Pola baru yang makin menonjol adalah loop tingkat harness di luarnya
- Pekerjaan masuk ke antrean
- Mesin mengambil pekerjaan dan mencoba mengerjakannya
- Setelah berhenti, harness menilai apakah pekerjaan benar-benar selesai
- Jika belum selesai, harness menyuntikkan pesan ke sesi yang sama, memulai sesi baru dengan konteks yang diperbarui, atau menyerahkan pekerjaan ke mesin lain
- Loop luar ini membuat pekerjaan tetap hidup bahkan setelah titik ketika model biasanya berkata “selesai”
- Loop itu sendiri bukan hal baru, tetapi belakangan makin sering muncul dalam agent engineering dan wacana Twitter
- Sebagian alur seperti ini juga muncul di Pi, dan karena Pi adalah harness, ia berada di pusat eksperimen semacam ini
Ketidaknyamanan pada Kode yang Harus Dipelihara Lama
- Untuk kode yang benar-benar dipedulikan, pendekatan ini masih terasa kurang cocok
- Intinya adalah soal selera dan kontrol
- Kita ingin memahami kode yang kita deploy
- Dalam situasi tertekan atau saat berdiskusi dengan orang lain, kita harus bisa menjelaskan perilaku sistem tanpa lebih dulu meminta mesin menjelaskannya
- Untuk saat ini, pemahaman kode tetap penting
- Kode yang dihasilkan sambil lepas tangan, terutama kode dari loop, punya masalah yang berulang
- Terlalu defensif
- Terlalu rumit
- Terjebak pada penalaran lokal
- Menghindari invariant yang kuat
- Menambahkan fallback alih-alih membuat status yang salah menjadi mustahil
- Menghasilkan duplikasi kode dan abstraksi yang buruk, lalu menutupi desain yang kabur dengan lebih banyak lapisan
- Kombinasi seperti Claude Code dan Fable bisa mengerjakan satu masalah tanpa putus selama lebih dari 30 menit, sehingga human in the loop berkurang dibanding sebelumnya
- Kualitas kode dari pendekatan harness yang lepas tangan saat ini terasa bahkan lebih buruk daripada musim gugur lalu; setidaknya dari selera ini, hampir tidak terlihat perbaikan
Loop Memperkuat Kebiasaan Model
- Saat model melihat kegagalan lokal, ia cenderung menambahkan pertahanan lokal
- Andrej Karpathy pernah mengatakan bahwa model “sangat takut” pada exception
- Pada sistem yang punya invariant penting, terutama format data persisten atau infrastruktur inti, pendekatan “menangani semua kasus malformed” mungkin bukan perbaikan yang benar
- Arah yang lebih baik adalah membuat kasus malformed tidak bisa direpresentasikan atau tidak bisa ditulis sejak awal
- Bahkan dengan banyak pengarahan manual, LLM sulit secara alami menghasilkan kode seperti ini, dan bisa tetap mencoba menangani error yang seharusnya sudah dibuat mustahil
- Jika kebiasaan ini ditempatkan di balik loop, masalahnya akan teramplifikasi
- Setiap iterasi menambah satu pertahanan kecil lagi
- Sistem terlihat makin tangguh, tetapi makin sulit dipahami
- Semakin kita lepas tangan, semakin kuat kecenderungan ini
- Jika alat seperti ini diberikan ke junior tanpa panduan yang jelas, mereka bisa belajar praktik yang buruk
- Saat ditanya alasannya, mereka tetap bisa membela pilihannya dengan penjelasan yang terdengar masuk akal
Area yang Cocok untuk Loop
- Pola loop sudah bekerja sangat baik di beberapa area
- Porting kode adalah contoh utamanya
- Ada kasus porting otomatis berskala besar seperti memindahkan sebagian Bun dari Zig ke Rust
- Ini juga berhasil dipakai untuk mem-port MiniJinja ke Go
- Ini juga cocok untuk eksplorasi performa
- Mesin mencoba eksperimen
- Menjalankan benchmark
- Membuang kegagalan
- Terus mengeksplorasi
- Ini juga secara alami cocok untuk pemindaian keamanan dan hampir semua jenis riset
- Mesin bisa menjelajahi ruang masalah yang kompleks lalu melaporkan hasilnya
- Tidak harus selalu commit kode yang akan dipertahankan lama
- Kesamaan dari contoh yang berhasil adalah output-nya tidak perlu dipelihara lama, atau berupa transformasi kode yang sudah ada, atau lebih dekat ke proof of concept, ide, temuan, dan transformasi mekanis
- Yang dibutuhkan harness bukan sinyal yang sepenuhnya objektif atau biner, melainkan sinyal yang cukup berguna untuk mendorong iterasi berikutnya
- Banyak contoh sukses memakai LLM lain sebagai judge atau orchestrator
- Terjemahan mekanis bisa diverifikasi dengan test case biner, atau dinilai dengan LLM
- Claude Code makin mahir membuat dan menjalankan seluruh alur kerja eksperimen
- Walau kode yang dihasilkan berantakan, itu lebih dekat ke masalah model daripada kemampuan menilai dari harness
Pergeseran Menangani Perangkat Lunak seperti Organisme, Bukan Mesin
- Menulis kode yang akan bertahan lama dengan pola loop yang sama masih belum terasa nyaman
- Ideal lama lebih dekat pada memahami software sebagai mesin yang deterministik
- Dengan membuka satu lapisan, kita bisa memahami lapisan yang lebih dalam
- Mesin yang teramati secara non-deterministik sulit dianggap ideal
- Arsitektur sebaiknya bergerak ke arah determinisme yang lebih besar
- Desain yang baik dianggap memungkinkan engineer baru menjelajahi codebase yang kompleks
- Dalam sistem yang dirancang baik, ada engineer yang tahu di mana invariant berada, bagian mana yang load-bearing, dan perubahan apa yang aman
- Software besar memang sudah tidak sepenuhnya muat dalam kepala manusia, dan distributed system kadang didiagnosis seperti dokter melihat gejala, menyusun hipotesis, lalu memesan tes tambahan
- LLM mendorong arah ini lebih cepat lagi
- Saat ada isu produksi, mesin membaca log
- Mengusulkan root cause
- Mengajukan patch
- Mesin lain me-review, dan kadang menerapkannya ke
maintanpa pengawasan manusia
- Cara ini kuat dan menarik, tetapi manusia mungkin tidak lagi memahami keseluruhan sistem dengan cara yang dulu
- Mereka mengelola, memantau, dan menstabilkan, tetapi tidak selalu memahami
- Tidak semua kode harus ditulis manusia, dan di masa lalu mungkin juga pernah ada kode yang lebih buruk
Tekanan yang Sulit Dihindari Sepenuhnya
- Dalam masa depan yang sepenuhnya digerakkan mesin, bisa jadi sulit untuk opt out
- Keamanan adalah contoh paling jelas
- Meski kita sendiri tidak membuat software dengan loop, orang lain bisa menjalankan loop terhadap software itu
- Penyerang terus menjalankan mesin
- Bahkan jika bukan penyerang, peneliti keamanan tetap melakukan pekerjaan otomatis
- Akibatnya, isu nyata dan noise masuk bersamaan
- Tulisan Daniel Stenberg tentang curl, summer of bliss, menunjukkan tekanan yang sudah diterima maintainer
- AI tampaknya tidak memainkan peran besar dalam pengembangan inti curl
- Meski begitu, maintainer tetap kewalahan oleh laporan, dan sebagian besar adalah laporan buatan AI
- Jika penyerang dan pelapor menjalankan loop, pihak bertahan juga harus mengimbanginya
- Bukan berarti harus menulis patch sendiri secara langsung
- Tetapi tekanan triage, reproduksi, dan respons bisa memaksa penggunaan mesin
- Tekanan kompetitif juga serupa
- Sebagian tim bisa membangun lebih banyak daripada tim lain hanya lewat kecepatan murni
- Kelompok kecil yang pandai mengorkestrasi mesin bisa membuat proyek tiba-tiba melesat
- Sebagian startup bisa melakukan dengan 5 orang apa yang dulu butuh 50 orang
- Seseorang bisa menjalankan loop terhadap produk lalu menyuruhnya “buat jadi sesuatu yang lain”
- Tidak semua software terdampak dengan cara yang sama
- Sebagian area menghukum kecerobohan dan menuntut kepercayaan serta akuntabilitas
- Pada banyak software, kecepatan, eksperimen cepat, dan cakupan luas sangat penting
Ketergantungan Baru yang Diciptakan Loop
- Alat yang dibangun oleh loop bisa menciptakan ketergantungan kognitif yang berkelanjutan, bukan sekadar biaya satu kali
- Pengembangan software dulu bergantung pada alat mahal seperti compiler, tetapi alat sekarang lebih mirip sistem yang harus terus bisa diakses
- Jika codebase dibuat dengan loop, di-review dengan loop, di-patch dengan loop, dan dipelihara dengan loop, masalah muncul ketika akses ke sistem pada level yang sama terputus
- Pembatasan perdagangan bisa menghilangkan akses ke model yang paling kuat
- Biayanya bisa menjadi tidak terjangkau
- Tim bisa kehilangan kemampuan terakhir untuk memahami kode tanpa mesin
- Bisa muncul codebase yang bukan hanya sulit dipelihara manusia, tetapi secara eksplisit mengandaikan partisipasi mesin sebagai bagian dari model pemeliharaan
- Beberapa perubahan sudah mulai terlihat
- Makin banyak orang me-merge kode yang tidak bisa mereka jelaskan sepenuhnya
- Laporan issue atau diskusi chat diperkuat atau ditulis ulang dengan konteks dari mesin
- Ringkasan dan kontekstualisasi makin bergantung pada mesin
- Makin sering terlihat orang bercakap melalui perantara LLM
- Ini belum tentu salah, tetapi jelas merupakan perubahan besar dari cara lama
Harness dan Alat yang Dibutuhkan ke Depan
- Mengorkestrasi lebih banyak loop saja tidak cukup
- Bahkan jika perubahan, orkestrasi, dan agent divisualisasikan lebih baik, pemahaman tidak otomatis pulih
- Arah yang dibutuhkan adalah salah satu dari dua ini
- Cara untuk menarik manusia kembali ke dalam loop secara kuat, dan membuat perubahan dari loop tetap bisa dibaca dalam jangka panjang
- Cara untuk merangkai sistem yang makin kompleks dengan lebih baik
- Cara pandang terhadap Pi juga berubah
- Pi bersikap hati-hati, dan kehati-hatian itu baik
- Masa depan ketika setiap interaksi berubah menjadi modifikasi oleh kawanan mesin yang sulit diikuti bukanlah hal yang diinginkan
- Pi juga tidak diinginkan berubah menjadi kekacauan tak terpelihara demi menang dalam perlombaan software yang menulis dirinya sendiri
- Pi juga tidak diinginkan mendorong engineering semacam ini
- Meski begitu, Pi adalah harness, dan harness berada di pusat eksperimen baru
- Antrean tugas coding, agent orchestration, subagent, dan durable session akan menjadi makin penting
- Bahkan orang yang tidak menerima loop secara membabi buta pun perlu mulai bereksperimen
- Karena kita perlu memahami cara membuat masa depan ini tetap berada dalam batas yang bisa dikendalikan dan dijalani
Masalah Mengendalikan Loop
- Jika menerima harness loop, maka harness yang memutuskan kapan pekerjaan selesai
- Dalam agent loop, model pada akhirnya mengatakan “done” lalu manusia me-review
- Bahkan sebelumnya pun biasanya manusia memberi pengarahan di tengah jalan
- Manusia terlibat, dan belajar selama proses itu
- Dalam loop yang dioperasikan harness, peran manusia menjadi kabur
- Sinyal “done” juga kehilangan makna dan berubah menjadi pesan untuk dinilai mesin lain
- Peran manusia bisa menjadi lebih mirip kurir pesan
- Saat ini, banyak kode yang dibuat dengan cara seperti ini tidak terasa memuaskan, dan interaksi dengan software yang dibuat dengan bantuan AI juga tidak menyenangkan
- Loop memang kuat, tetapi juga makin menghapus tanggung jawab, dan untuk saat ini cenderung mendorong orang menyerah pada mesin
- Meski begitu, masa depan loop tampaknya akan datang
- Sudah terlihat tim yang sangat kecil membangun dengan kecepatan yang tampak mustahil
- Codebase berubah menjadi organisme yang lebih samar dan kacau
- Codebase seperti itu sekaligus berguna dan berantakan
- Pertanyaan ke depan bukan lagi “apakah akan menjalankan loop”, melainkan lebih dekat ke berikut ini
- Bagaimana tidak menyerahkan penilaian di dalam loop
- Bagaimana mempertahankan aturan engineering yang baik
- Bagaimana memastikan manusia yang bertanggung jawab tetap bisa mengawasi
- Bagaimana memikirkan ulang arsitektur kode agar kita tetap waras
1 komentar
Komentar Hacker News
Loop bekerja ketika kita sudah meluangkan cukup waktu untuk benar-benar memahami apa yang diinginkan sebelumnya. Prasyaratnya adalah kejelasan, dan kita harus bisa menulis spesifikasi dengan cukup hati-hati sampai bisa diserahkan ke rekan junior
Biasanya, untuk sampai pada pemahaman itu, kita harus melewati 5~6 versi rusak dan setengah jadi. 5~6 kali coba-coba ini tidak bisa dipercepat, dan teknologi agen apa pun tidak bisa menghindarkan waktu berpikir otak manusia. Jadi sebagian besar waktu dihabiskan bolak-balik antara “saya belum tahu apa yang saya inginkan, saya harus membaca, menulis, dan mengutak-atik kode” dan “sekarang rasanya saya sudah cukup lama lewat proses ini untuk tahu apa yang saya inginkan”. Sangat mudah menipu diri sendiri, tetapi loop baru bisa dipakai setelah kita benar-benar tahu apa yang diinginkan. Banyak orang merasa bisa menyalip dengan agen, tetapi pemahaman dan kejelasan tidak bisa dipalsukan, dan orang yang melewati tahap itu akan terlihat jelas, bahkan menyakitkan untuk dilihat
Saya tidak perlu lama-lama memikirkan apa yang saya inginkan; saya memang hanya ingin itu dilakukan. Hasilnya masih campur aduk dan saya belum cukup percaya untuk menyerahkan codebase yang halus dan sensitif, tetapi pada game yang sedang saya buat, waktu yang saya habiskan untuk verifikasi turun menjadi 1/5 dari sebelumnya. Ini belum tentu hal yang baik. Sangat mungkin saya melewatkan ide-ide bagus karena menghabiskan lebih sedikit waktu. Namun sebelumnya prompt saya menjadi mekanis seperti
#now-do-this,#now-review-that, dan mandek di kondisi saat 90% usulannya benar. Sekarang saya hanya perlu secara otomatis mengingatkannya untuk “kerjakan bagian yang sulit dulu, lalu rapikan dan refactor sambil jalan”, dan setelah respons pertama, “tinjau kembali pekerjaanmu”, biarkan ia mengungkap masalah yang tersisa, lalu masukkan itu ke prompt pembuat panduan dan sebarkan tugas baruIterasinya lebih cepat, tetapi usaha untuk melewati versi-versi kasar itu hampir sama saja. Saya tetap harus memahami ide, prinsip, atau desain mana yang cocok untuk solusi, apa yang harus dicoba berikutnya, dan menyesuaikan model mental saya. Pada akhirnya rasanya seperti mengeluarkan lebih banyak upaya mental dalam waktu yang lebih singkat, dengan sedikit penghematan di penulisan kode. Kalau sudah terampil, mengetik kode sendiri memang sejak awal bukan porsi yang besar. Walau terlihat seperti “cuma” menulis prompt dan membaca kode, tetap saja melelahkan, atau kadang malah lebih melelahkan karena siklus iterasinya terkompresi
Saya mengalami hal seperti ini setiap hari sekarang, dan itu membuat putus asa sekaligus khawatir. Saya rasa alasan kita menggabungkan lebih banyak kode yang tidak bisa dijelaskan sepenuhnya adalah karena model mental yang dulu dibangun lewat penulisan kode dan perencanaan teknis kolaboratif sekarang dialihkan ke code review
Code review tidak cocok untuk tujuan ini. Namun, saya pikir kita bisa mendapatkan keseimbangan yang lebih baik antara friksi dan pemahaman dengan menambahkan latihan terstruktur yang mengambil inspirasi dari pedagogi ke dalam code review. Saya sedang mencari bantuan untuk menguji latihan seperti ini
UI PR GitHub yang lemah juga tidak membantu. Alat untuk menjelajahi area codebase di sekitar yang tidak berubah langsung tetapi terdampak, lalu menemukan dan menyorot masalah, sangat terbatas
Poin dari tulisan asli bahwa kita seharusnya lebih menyukai sistem yang membuat kondisi batas yang salah menjadi mustahil, alih-alih menanganinya dengan jalur fallback, sangat penting. Pendekatan fallback membuat kita mengimplementasikan fallback di atas fallback lagi, dan setiap fallback meningkatkan jumlah kode secara eksponensial serta entah bagaimana selalu menciptakan masalah baru. Ini nyaris layak disebut “hukum umum desain sistem”. Fallback memang menurunkan risiko kegagalan, tetapi ketika kegagalan benar-benar terjadi, hasilnya jadi lebih kompleks dan lebih merusak. Sebagai software engineer, saya suka lingkungan coding baru yang diciptakan AI. Big Tech telah menciptakan jumlah pekerjaan tak terbatas untuk saya. Pengembang manusia kini menjadi komponen inti dalam eksekusi kode, selalu siaga untuk menangani hampir tak terbatas banyaknya exception sulit yang sesekali pasti muncul. Sekarang software engineer terasa kurang seperti pekerja, dan lebih seperti petugas keamanan yang kebanyakan duduk di meja minum kopi lalu sesekali turun tangan saat ada masalah
Ini sejalan dengan yang sudah saya katakan selama beberapa bulan. LLM sangat hebat dalam menyelesaikan tugas, tetapi lemah dalam estetika dan selera
Ada dua jenis pekerjaan. Yang pertama adalah pekerjaan berorientasi tujuan, di mana ada target yang harus dicapai dan cara mencapainya tidak terlalu penting. Keamanan adalah contoh sempurna. Jika ingin mengeksploitasi sistem, Anda hampir tidak peduli apakah exploit itu indah; Anda hanya ingin mendapat akses ke rencana nuklir superrahasia. Riset juga mirip, sehingga kode “berkualitas riset” sudah terkenal berantakan bahkan sebelum era AI. Yang kedua adalah pekerjaan berorientasi selera. Saat menambahkan fitur ke codebase besar, kita mengira tujuannya adalah penambahan fitur itu, padahal sering kali bukan. Menjaga codebase tetap siap menerima perubahan di masa depan jauh lebih penting daripada fitur spesifik tersebut, dan itu memerlukan selera. Maintainability dan kualitas kode bukan sinonim, dan kualitas kode hanyalah sarana; tujuannya adalah maintainability
Masalah ketika LLM berusaha menangani bahkan kasus yang secara alami keliru adalah hal yang sudah sering diperdebatkan dalam banyak review PR. Terutama setelah kode sudah ditulis, sangat sulit meyakinkan orang bahwa pemeriksaan null yang berlebihan itu merugikan
Jika bukan lewat pemodelan yang lebih baik, dan bahasa yang mengizinkan sum type, saya masih belum menemukan sanggahan yang secara umum ampuh melawan “parsing senapan tabur” semacam ini. Mungkin ini memang bukan masalah besar. Tetapi saat benar-benar membaca dan me-refactor codebase, mengelola pemeriksaan yang tidak perlu seperti ini selalu terasa menjengkelkan. Sekali sudah masuk, kadang hampir mustahil menghapusnya dengan aman tanpa lebih dulu menambahkan logging atau investigasi yang luas
Inilah inti dari ungkapan bahwa kondisi yang tidak diinginkan harus dibuat tidak mungkin untuk direpresentasikan
Walaupun saat ini tidak ada apa pun yang mengirim angka negatif ke fungsi ini, seberapa sulit asumsi itu rusak oleh perubahan kode di masa depan? Saya selalu berpikir error yang jelas adalah yang terbaik. Orang yang tidak akrab dengan kodenya pun bisa tahu asumsi apa yang ada terhadap rentang valid input, dan tidak perlu mempertimbangkan outlier mustahil
Bottleneck saya ada pada spesifikasi. Loop agen sekarang jadi masalah yang kurang penting bagi saya
Jika saya punya pemahaman yang jelas tentang apa yang ingin dibuat, lalu menyampaikannya sebagai tujuan untuk menulis spesifikasi yang bisa dieksekusi di mode perencanaan Claude Code, biasanya hasilnya sangat bagus saat agen mulai mengimplementasikan. Tetapi strategi yang efektif ini justru memberi saya beban besar untuk menulis spesifikasi. Agen biasanya menangani tiap spesifikasi dengan sangat baik, dan tindak lanjut berbasis review kode pun umumnya selesai dalam 2–3 kali, tetapi tak lama kemudian saya kembali ke tahap yang membutuhkan spesifikasi lagi. Selain itu, ketika saya sedang tidak di tempat, meskipun agen sudah menyelesaikan pekerjaan dari spesifikasi yang ada dan bisa memulai spesifikasi lain yang tidak bentrok karena file-nya tidak tumpang tindih, ia tidak tahu bahwa ia boleh membuat branch baru dan mulai. Sebelum tidur saya sering berkata, “kerjakan tugas X dan setelah selesai serta di-push, mulai tugas Y,” tetapi lebih dari itu biasanya tidak berjalan baik. Sering kali saat mulai Y muncul pertanyaan, lalu agen berhenti selama sisa waktunya. Masalah terakhir adalah dependensi yang berpadu dengan hal di atas. Misalnya hari ini saya menulis background worker, dan tentu saja job untuk pekerjaan berikutnya membutuhkan sistem itu. Hal seperti ini cukup sering terjadi. Spesifikasi itu sendiri juga harus diperbarui setelah implementasi agar mencerminkan detail yang diputuskan saat implementasi. Meski begitu, sekarang saya sudah hampir sampai pada titik di mana loop luar dibutuhkan. Gerbangnya hampir sepenuhnya ada pada penulisan spesifikasi dan review PR. Di tempat-tempat di mana gerbang itu tidak penting, saya ingin agen terus berjalan. Sebagai tambahan, saya sangat yakin kita harus mulai memakai alat yang mungkin lebih buruk bagi kita tetapi lebih baik bagi LLM. Misalnya Rust itu menyebalkan bagi saya karena compiler-nya terlalu ketat, tetapi justru sangat bagus untuk LLM
Sekarang ketika proses membuat semakin otomatis, spesifikasi dan desain sistem bisa kembali mengambil peran terdepan yang penting. Bisa jadi engineering dan kualitas akan kembali
AI sangat hebat dalam membuat solusi yang lumayan dan secara teknis bekerja, tetapi cukup lemah dalam memiliki visi yang baik atas solusi itu. Ia tetap sangat berguna untuk saling lempar ide dan eksplorasi demi memperdalam pemahaman, tetapi menulis spesifikasi yang baik untuk diimplementasikan LLM tidak jauh lebih mudah daripada langsung menulis kodenya
https://www.aihero.dev/skills-handoff
/handoffadalah skill favorit baru sayahttps://www.youtube.com/watch?v=dtAJ2dOd3ko
Mau ada agen atau tidak, mau kartu plong atau interpreter, pada akhirnya pemrograman tetaplah pemrograman
Bau kode terbesar dari LLM adalah mereka mencoba “menangani semua kasus yang salah”, dan sekarang bahkan berusaha menangani error yang mustahil terjadi. Tidak paham kenapa bisa seobsesif itu
Di Python, ini sering muncul dalam codebase yang sepenuhnya diperiksa tipenya, misalnya dengan menambahkan pemeriksaan
hasattrpada tipe yang sudah didefinisikan memiliki atribut tersebut. Kenapa bisa begini? Penasaran apakah ini karena pra-pelatihan, atau karena reinforcement learning. Kalau yang kedua, semoga lab-lab riset memperbaikinyaDi HN pembahasan ini sering muncul, tapi aku masih tetap terkejut kalau melihat codebase yang bukan kutulis sendiri—baik open source maupun di tempat kerja—benar-benar melakukannya dengan baik. Kebanyakan programmer berpikir dengan cara memunguti pecahan di titik saat pesan error muncul lalu memperbaikinya, alih-alih membuat error itu tak bisa terjadi dan membuat data merefleksikan fakta tersebut. Aku bilang “kebanyakan” karena menurutku AI saat ini juga punya masalah cara berpikir yang sama. Sulit memberi AI tingkat pemahaman yang dimiliki manusia terhadap codebase pada tahap akhir, yaitu pemahaman menyeluruh tentang aliran jaminan. Pada level kode mentah, jaminan seperti ini sering tersebar di cukup banyak kode sampai mudah melampaui jendela konteks. Mencoba merangkumnya ke file bergaya memori juga punya masalah. Hanya karena ada teks tentang jaminan bukan berarti AI akan mengambil informasi yang benar, dan manusia juga sama kalau cuma membaca kodenya. Aku tidak akan bilang memberi pemahaman seperti ini ke AI itu “mustahil”, tapi bahkan kalau dibuat paham pun, cara kerja AI sering berjalan berlawanan dengan pemahaman itu. Solusiku umumnya adalah berhenti berharap AI memahami ini. Biasanya aku menjadikan solusi masalah itu sebagai prompt, dan kalau ingin membuat keadaan buruk yang salah tidak bisa direpresentasikan, aku minta AI melakukan proses refactoring yang diperlukan langkah demi langkah. Kalau sangat kecil, aku kerjakan sendiri. Kalau diminta secara bertahap untuk membuat kode yang penuh
map/dictionary, array, string, dan integer menjadi lebih ketat tipenya, hasilnya sebenarnya cukup bagus. Seberapa pun detailnya ditulis, aku jarang mendapat desain yang baik dari satu prompt tunggal. Lebih cocok kalau diperlakukan sebagai dua pekerjaan terpisah. Dan kita harus mencermati perbedaan antar-tipe dengan hati-hati. AI suka diam-diam menyisipkan metode seperti.JustSetItAndIgnoreAllThePreAndPostConditions(string). Sepertinya ada banyak data pelatihan dari situasi nyata berupa “tipe yang tersusun rapi agar keadaan error tak bisa direpresentasikan, lalu perawat di masa depan datang dan merusaknya dengan menambahkan metodeJustEffingDoIt”. Salah satu pertahanan terbaik adalah menaruh tipe semacam ini di file tersendiri, lalu mudah meninjau semua metode yang ditambahkan dan langsung membetulkannya kalau ada yang macam-macam. Aku sudah mencoba menulis banyak peringatan di dokumentasi agar jangan dilakukan, plus daftar pra-kondisi dan pasca-kondisi yang harus dijaga, tapi perubahannya kecilgetattruntuk setiap dataclass itu pilihan yang anehKode adalah bagian dari pemahaman bersama yang dibagikan dan diakumulasikan tentang sistem informasi
Jika loop-loop ini membuat kita semua terus bergerak di tengah gelombang perangkat lunak yang terus datang, maka pada desain sistem informasi logis tingkat tertinggi, semuanya pada akhirnya kembali pada penilaian manusia dan keseimbangan kebutuhan bisnis. Untuk menyesuaikan diri dengan ceruk tertentu dalam perusahaan atau pasar, semua programmer harus menjadi analis bisnis, peneliti pasar, dan pebisnis. Kecuali tentu pada ceruk tertentu yang tidak bisa “diguncang-guncang” dengan baik oleh alat AI, atau ketika era token AI bersubsidi berakhir dan semua loop ini menjadi terlalu mahal. Ini terasa seperti pengulangan dari expert systems dan mesin Symbolics Lisp. Selama sesaat, fakta yang kita hadapi adalah bahwa bukan kodenya sendiri yang tidak mampu melakukan sesuatu, melainkan struktur organisasi perusahaan pada akhirnya ikut termuat ke dalam perangkat lunak, sehingga kalau struktur organisasi perusahaan tidak bisa diubah, keluwesan perangkat lunak pun punya batas. Data flow, pengetahuan domain, domain modeling, dan ubiquitous language bisa menjadi meta-bahasa yang kita gunakan untuk menetapkan kualitas, fungsi, serta standar dan konvensi nonfungsional. Kita harus membuat para “clanker yang berputar dalam loop” memenuhi kontrak data, perilaku, dan performa sebelum mereka berkata “selesai”. Kini “selesai” bukan hanya berarti kode yang bisa dikompilasi, kode yang bisa dibangun, kode yang bisa dideploy, atau bahkan kode yang sudah berjalan di produksi. Kode itu harus memenuhi kebutuhan pengguna, operator, dan pemelihara. Karena itu, bahasa yang dipakai mungkin akan membuat kita semua lebih dekat ke analis bisnis dan arsitek perangkat lunak daripada sekadar orang yang paham sintaks. Apakah ini balas dendam UML dan kembalinya desain deklaratif/logis/BDD?
Pemeriksaan typo dilakukan dengan gemma4-12b, tapi tidak kubiarkan mengubah pesannya
Aku terus berpikir kapan aku tidak perlu lagi dipaksa masuk ke dalam loop itu. Sebagai developer, aku sangat suka merapikan struktur kode, membuatnya lebih jelas, memikirkan abstraksi yang baik, dan membaginya ke dalam modul
Aku menikmati itu, tapi di satu titik aku juga paham bahwa akulah faktor pembatasnya. Jika tujuan perangkat lunak adalah memberi manfaat bagi manusia, haruskah aku tetap peduli pada seperti apa bentuk kodenya? Untuk sekarang kurasa jawabannya “ya”, tapi bagaimana tiga tahun lagi? Sepuluh tahun lagi?
Jika sesuatu menuntut banyak penilaian dan itu adalah “kode yang sangat saya pedulikan”, maka sulit untuk setuju dengan arah yang dibahas di sini. Keputusan yang sangat kita pedulikan seharusnya tidak didelegasikan
Saya suka pembedaan antara agent loop dan harness loop, tetapi yang boleh didelegasikan hanya hal-hal yang bisa dispesifikasikan dengan tepat sejak awal. Dalam kasus saya, biasanya itu tugas yang bisa diulang, misalnya “lihat bagaimana X dilakukan, lalu lakukan hal yang sama untuk Y”, dan ini pada dasarnya pekerjaan yang dapat diprediksi. Jika tanpa penilaian saya hasil akhirnya adalah sesuatu yang akan saya katakan “tidak” juga, maka itu harus diturunkan ke bentuk kolaborasi di dalam agent loop yang dibicarakan Armin. Itu sepenuhnya tidak masalah. Cepat sekaligus aman. Bahkan sebelum adanya asisten coding AI, kadang ada insinyur yang luar biasa produktif masuk ke tim. Rekan-rekan akan iri dan berkata, “Kalian bisa menyelesaikan semua itu kan karena ada X di tim!” tetapi mereka belum pernah mengalami kutukan memiliki orang seperti itu di dekat mereka. Jika tidak benar-benar selaras, mereka akan berlari ke arah yang salah dengan kecepatan luar biasa
Saya tidak paham ini sebenarnya berarti apa. Rasanya seperti tulisan bertele-tele yang hanya menumpuk konsep abstrak yang tampaknya dirancang untuk menyiratkan gambaran yang lebih besar, padahal ujung-ujungnya cuma soal membiarkan AI menulis kode
Jadi ke depannya akan begini? Sebenarnya kita bukan thought leader, melainkan semacam guru semu yang mencoba menggiring gerombolan AI bodoh ke arah jawaban yang benar, tetapi tetap harus memistifikasi peran kita agar terlihat seperti pemimpin pemikiran? Tanpa ketahuan bahwa semuanya cuma gaya-gayaan teknis?
Penulis mungkin bisa merapikannya agar lebih ringkas, tetapi pada tingkat sekarang, hanya karena pembaca tidak memahaminya bukan berarti sedang terjadi mistifikasi
Di pekerjaan dan proyek pribadi, saya melihat persis apa yang dimaksud tulisan aslinya, dan menakutkan bahwa ada orang yang melihat ini sebagai “tulisan bertele-tele yang menumpuk konsep abstrak”. Rasanya mayoritas orang sama sekali tidak sadar dengan apa yang sedang terjadi sekarang
Di bidang AI, masa berlaku state of the art terbaru itu sekitar 2 minggu. Saya belum berhasil mengejar Ralph Wiggum loop, dan sekarang rasanya untung saya tidak mencoba
https://news.ycombinator.com/item?id=46682325