Cara Memrogram Bersama Agen

• Tulisan ini adalah bagian kedua yang membahas proses menyesuaikan pengalaman pemrograman yang sudah ada ke dunia komputer percakapan (LLM, agen)
• Pada bagian pertama, "Cara Memrogram Bersama LLM", dijelaskan cara menggabungkan LLM ke alat yang sudah ada untuk digunakan sebagai pelengkapan otomatis atau pengganti pencarian
• Kali ini, dibagikan pengalaman dan wawasan praktis tentang pemrograman berbasis agen yang sedikit lebih sulit tetapi juga lebih memuaskan

Definisi dan kenyataan agen

• Dalam konteks LLM (large language model), mendefinisikan istilah "agen" itu bermakna
• Istilah ini sudah lama digunakan seperti kata tren di industri AI, tetapi baru belakangan benar-benar menjadi struktur yang berguna
• Selama proses itu, banyak retorika pemasaran dan nuansa mistis ikut menempel

• Dari sudut pandang insinyur, sekarang ini bisa didefinisikan dengan jelas dan sederhana: agen adalah 9 baris kode, yaitu sebuah for loop yang mencakup pemanggilan LLM
• Di dalam loop ini, LLM dapat menjalankan perintah dan langsung memeriksa hasilnya, lalu bekerja berulang kali tanpa campur tangan manusia
• Ini mungkin terdengar sederhana, tetapi dalam praktiknya konfigurasi seperti ini membuat kemampuan pemrograman meningkat drastis dibanding hanya memakai LLM murni

Perbedaan antara pemrograman whiteboard dan agen

• Bayangkan berdiri di depan whiteboard dan menulis fungsi C untuk memeriksa validitas string UTF-8 dengan spidol
  • (Ini adalah situasi wawancara yang benar-benar pernah dialami penulis dan juga tugas interview yang umum)
  • Keberhasilan atau kegagalan tugas ini bergantung pada pengalaman sebagai programmer, serta kemampuan menutupi keterbatasan karena tidak bisa merujuk bahan luar
  • Kita harus mengingat aturan encoding UTF-8, dan berhati-hati agar sintaks C tidak tertukar dengan bahasa turunan C lain (urutan nama-tipe, tipe-nama, dan seterusnya)
  • Dalam keseharian nyata, kode bisa diverifikasi dan kesalahan bisa dicari lewat umpan balik compiler, pencarian dokumentasi, printf, dan banyak cara lain
• Meminta LLM menulis kode tanpa agen itu mirip menulis kode di whiteboard tanpa bantuan luar
  • Ini adalah pekerjaan yang menuntut mengorek ingatan samar, bersusah payah mencocokkan sintaks dengan cara yang tidak efisien, dan menghindari kesalahan membayangkan antarmuka yang keliru
  • Pencapaian teknis bahwa LLM dapat menghasilkan program yang benar-benar baru memang mengagumkan, tetapi whiteboard virtual yang terhubung ke GPU saja tidak banyak meningkatkan produktivitas pemrograman secara nyata
• Tetapi bagaimana jika LLM diberi lebih dari sekadar whiteboard virtual?
  • Misalnya, jika ia bisa memanggil compiler, melihat error kompilasi, lalu memperbaikinya sendiri?
  • Jika ia bisa membaca file yang ada dengan grep, cat, menambal banyak file (termasuk unit test), dan mengulang pengujian?
• Agen adalah LLM berbasis umpan balik seperti itulah.

Agen = LLM yang bekerja dalam lingkungan umpan balik

• LLM yang bekerja baik dalam lingkungan umpan balik seperti manusia dapat menunjukkan kemampuan pemrograman yang nyata hanya dengan beberapa alat yang familier
  • bash(cmd): menjalankan perintah terminal (find, cat, grep, dan lain-lain)
  • patch(hunks): menambal file, menerapkan perubahan kode
  • todo(tasks): mengelola daftar tugas
  • web_nav(url), web_eval(script), web_logs(), web_screenshot() dan sebagainya: penelusuran web, evaluasi, log, screenshot, dan lain-lain
  • keyword_search(keywords): pencarian kata kunci
  • codereview(): code review
• Dengan memanfaatkan alat bash, agen dapat menjelajahi codebase secara efisien dan bahkan mengotomatiskan version control seperti git add/commit
• Berbeda dari LLM yang hanya menghasilkan kode tanpa alat-alat ini, agen memiliki keunggulan pembeda berikut
  • Ketepatan penggunaan API meningkat besar (mencari dokumentasi dan langsung memasukkannya ke konteks)
  • Umpan balik compiler mengurangi kesalahan sintaks dan kekeliruan antarmuka
  • Kemampuan mengelola dependensi/versi menjadi lebih kuat (dapat memahami karakteristik versi tertentu)
  • Deteksi kesalahan melalui kegagalan test dan kebiasaan menulis kode test menjadi lebih baik
  • Mampu menangani codebase melampaui batas context window (hanya membaca bagian yang diperlukan secara selektif)
  • Bereksperimen langsung dengan hasil eksekusi: menjalankan kode, menerima umpan balik screenshot halaman browser, menyesuaikan CSS secara otomatis, melacak error lewat log server, dan menambah test
• Tentu ada kekurangannya
  • Satu permintaan kalimat bisa menghasilkan puluhan ribu token perantara (pemanggilan alat, pencarian web, pengulangan test, dan lain-lain), sehingga waktu kerja bisa memakan beberapa menit atau lebih
  • Biaya pemanggilan API juga ada, tetapi diperkirakan akan makin memudar seiring kemajuan hardware
• Pada akhirnya, tenaga kerja perantara digantikan oleh CPU/GPU, menghemat waktu developer dan memungkinkan lebih banyak program yang ingin dibuat benar-benar selesai
• Dalam praktiknya, cukup mudah memperkenalkan agen ke proyek dan memberinya tugas kecil lalu memeriksa hasilnya

Contoh: pengembangan autentikasi Github App

• Ini adalah contoh nyata implementasi alur autentikasi Github App di sketch.dev dengan memanfaatkan agen
  • Hanya dengan 3~4 kali umpan balik, seluruh alur autentikasi selesai dengan cepat
  • Saat ditemukan error atau syarat baru, cukup dijelaskan dalam satu kalimat sederhana dan agen langsung memperbaiki kode serta perilakunya
  • Dengan meminimalkan "pekerjaan remeh" praktis seperti integrasi API yang berulang dan membosankan, build system/package management/library setup, agen sangat membantu menjaga momentum produktivitas
• Dalam kebutuhan awal, dimasukkan syarat "hanya menggunakan informasi autentikasi global aplikasi tanpa menyimpan token per pengguna", dan agen mengimplementasikannya sesuai itu
  • Tetapi hasilnya menimbulkan kerentanan keamanan yang serius (siapa pun bisa melihat semua repo)
  • Ketika penjelasan masalah diberikan sebagai umpan balik dalam satu kalimat, agen langsung memperkenalkan pemeriksaan izin per pengguna dan membuat commit perbaikannya
• Lalu muncul masalah performa
  • Dengan struktur seperti di bawah, panggilan API terjadi untuk semua kombinasi pengguna-repo sehingga muncul masalah skalabilitas

    for install := range allAppInstallations {  
    	for r := range install.Repositories() {  
    		if r.IsCollaborator(user) {  
    			// add to available repositories  
    		}  
    	}  
    }  
    

  • Disadari bahwa akar masalah ini adalah syarat yang saya tetapkan, yaitu "tidak menyimpan token per pengguna"
  • Ketika syarat diubah (penyimpanan token per pengguna diizinkan), agen merancang ulang dengan cara pemanggilan API yang efisien
• Bahkan, jumlah kata yang dipakai untuk menjelaskan proses ini dalam tulisan lebih banyak daripada total kata yang dimasukkan untuk mendapatkan kode autentikasi di Sketch
• Singkatnya, agen belum berada pada level yang bisa menggantikan developer saat ini, tetapi membantu menyelesaikan pekerjaan berulang yang secara tradisional memakan beberapa hari menjadi satu hari saja
• Otomatisasinya sampai pada titik pekerjaan bisa tetap berjalan bahkan saat developer sedang membersihkan kamar anak

Contoh: menerapkan aturan SQL berbasis JSON

• Salah satu tugas yang sering ditangani agen adalah menerapkan gaya SQL yang tidak biasa, dipelajari dari Tailscale
  • Pada semua tabel, hanya ada satu kolom nyata (data JSON), dan kolom lain diperlakukan sebagai generated column yang diturunkan dari JSON tersebut
  • Contoh struktur tabel:

    CREATE TABLE IF NOT EXISTS Cookie (  
      Cookie   TEXT    NOT NULL AS (Data->>'cookie')  STORED UNIQUE, -- PK  
      UserID   INTEGER NOT NULL AS (Data->>'user_id') STORED REFERENCES User (UserID),  
      Created  INTEGER NOT NULL AS (unixepoch(Data->>'created')) STORED,  
      LastUsed INTEGER AS (unixepoch(Data->>'last_used')) CHECK (LastUsed>0),  
      Data     JSONB   NOT NULL  
    );  
    

  • Cara ini berfungsi seperti poor man’s ORM, memudahkan perluasan skema, dan constraint SQL membantu memvalidasi kualitas data JSON
  • Kekurangannya, data yang disimpan per baris bertambah, dan semua INSERT/UPDATE harus dilakukan pada unit JSON
• Namun agen tidak selalu bisa mengikuti gaya ini secara konsisten
  • Saat membuat tabel baru biasanya cukup baik, tetapi jika ada pengecualian, kadang ia bingung atau mengubah gaya secara sewenang-wenang
• Solusi sederhana: tambahkan penjelasan 3 kalimat di bagian atas file skema SQL
  • Tambahkan kalimat kunci bahwa "setiap tabel hanya memiliki satu kolom JSON Data yang nyata, dan semua kolom lain diturunkan dari sana"
  • Untuk tabel yang tidak mengikuti aturan ini, tandai sebagai pengecualian dengan komentar terpisah
  • Setelah itu, perilaku agen membaik secara nyata
• Menariknya, penjelasan dan komentar seperti ini biasanya diabaikan oleh insinyur manusia atau dinilai kurang berguna, tetapi
  • agen berbasis LLM justru secara aktif mencerminkan komentar dan penjelasan dalam penulisan kode
  • Hanya dengan memberi penjelasan yang baik, kualitas pembuatan kode meningkat jelas

Model kode “aset” dan “utang”

• Salah satu kritik umum terhadap alat pembuat kode berbasis LLM adalah bahwa pembuatan kode itu sendiri hanya bagian yang sangat kecil dari total biaya software
  • Pada kenyataannya, sebagian besar waktu habis untuk mengelola dependensi kode yang sudah ada, keterikatan antarbagian, dan antarmuka yang kompleks
  • Produk yang besar, lama, dan punya banyak pengguna memiliki biaya maintenance yang sangat dominan
  • Dalam lingkungan seperti ini, meminta LLM "tolong buat bubble sort dalam Fortran" bisa terasa seperti mainan atau gangguan yang merepotkan
  • Ada juga diskusi yang membandingkannya dengan konsep finansial "aset/utang", tetapi ini pun tidak sepenuhnya pas
• Namun, tidak semua software engineering hanya berlaku untuk proyek besar dan jangka panjang seperti itu
  • Sebagian besar program memiliki sedikit pengguna atau berumur pendek
  • Pengalaman maintenance skala besar tidak boleh diekstrapolasi sebagai hakikat seluruh industri
• Nilai agen tidak terbatas pada pembuatan kode
  • Agen menggabungkan banyak alat dan LLM untuk mengotomatiskan perubahan itu sendiri, seperti membaca kode, mengedit file, menghapus/memodifikasi kode
  • Sama alaminya dengan menambah kode, agen juga melakukan penghapusan kode/refactoring
• Pada akhirnya, tujuan insinyur adalah perubahan (change)
  • Memang ada pekerjaan tambahan agar pengemudi perubahan memahami modifikasi yang dibuat, tetapi agen sudah menunjukkan kemampuan menciptakan perubahan bertahap bahkan pada proyek skala menengah
  • Meski saat ini belum cukup, agen berkembang cepat ke arah yang benar
• Selain itu, ada juga pandangan bahwa bahasa dan build system yang kompleks berfungsi sebagai hambatan masuk proyek
  • Ada argumen bahwa jika alat yang memudahkan penulisan kode (LLM, type safety, garbage collection, package management, agen, dan lain-lain) menurunkan hambatan masuk, kualitas bisa menurun
  • Jika tujuan Anda adalah memperlambat laju perubahan atau meningkatkan kontrol, maka alat otomasi seperti agen memang tidak cocok

Mengapa agen sekarang?

• Berbeda dari prinsip AI yang kompleks seperti transformer, memasukkan feedback loop ke LLM adalah pendekatan yang secara intuitif jelas
  • Dari sudut pandang pengembang alat developer, ini terasa sebagai arah perkembangan yang alami
  • Bahkan versi pertama sketch.dev setahun lalu hanya sebatas menghubungkan alat go ke LLM, tetapi dibanding agen yang dipakai sekarang, perbedaannya sangat besar dalam hal kepraktisan
  • Di bidang ML pun, reinforcement learning (pembelajaran berbasis umpan balik) sudah menjadi prinsip dasar selama lebih dari 50 tahun
• Munculnya agen secara nyata berkaitan langsung dengan evolusi LLM
  • LLM pada 2023 belum punya kemampuan pemanggilan alat yang memadai sehingga peran agen terbatas
  • LLM pada 2025 dioptimalkan untuk pemanggilan alat dan pekerjaan berulang, sehingga pemanfaatan agen secara nyata menjadi mungkin
  • Model frontier (komersial mutakhir) jauh lebih unggul dibanding open model dalam kemampuan memanfaatkan alat
  • Diharapkan open model akan menyusul dalam 6 bulan ke depan
  • Kemampuan melakukan pemanggilan alat berulang yang berguna adalah perubahan terbesar pada LLM modern

Arah selanjutnya: container dan eksekusi paralel

• Bidang agen LLM masih berada pada tahap awal dan berubah cepat, yang belum benar-benar diadopsi oleh kebanyakan insinyur
• Saat ini agen terutama digunakan agar bekerja di IDE atau repositori lokal
  • Memulainya mudah, misalnya dengan fork VSCode atau memasang alat command line
  • Tetapi ada dua keterbatasan penting
    • Pertama, kurangnya pengaman: ada risiko tereksposnya informasi sensitif seperti kredensial produksi nyata yang tersimpan di komputer asli
      • Jika agen menjalankan perintah tak terduga seperti script deploy, bisa terjadi insiden keamanan yang fatal
      • Walau tiap eksekusi perintah meminta konfirmasi manual, kemungkinan kebocoran informasi sensitif karena kesalahan tetap ada
    • Kedua, keterbatasan eksekusi paralel dan otomasi: karena setiap developer harus menjalankan agen satu per satu di lingkungannya sendiri
      • Satu kali kerja agen memakan beberapa menit, sehingga sulit dan tidak efisien menangani banyak tugas sekaligus
• Di sketch.dev, keterbatasan ini sedang dicoba diatasi dengan lingkungan container
  • Untuk setiap tugas dibuat development container yang terisolasi, source code disalin, dan hanya hasil seperti commit git yang diekstrak ke luar
  • Banyak agen dapat dijalankan secara bersamaan, dan agen lain juga sedang mengeksplorasi pendekatan ini
• Contoh nyata: saat mengerjakan autentikasi Github, perbaikan UI form juga ditangani secara paralel dalam sesi agen terpisah
  • Tanpa mendaftarkannya ke issue tracker terpisah, umpan balik perbaikan desain form ditangani hanya dengan screenshot dan satu baris permintaan singkat
  • Memberikan pengalaman mendapatkan hasil di atas level tertentu hanya dengan investasi 30 detik
• Hasil eksperimen UX selama 6 bulan terakhir:
  • Disimpulkan bahwa container (lingkungan eksekusi terisolasi) adalah pendekatan paling praktis untuk pengembangan berbasis agen

Akan menjadi apa IDE?

• Dalam lingkungan pengembangan berbasis agen, peran IDE (integrated development environment) masih menjadi pertanyaan terbuka
  • Memasukkan instruksi ke agen untuk memulai pekerjaan, menjalankannya di lingkungan container, memeriksa perubahan lewat diff, lalu mendorongnya sebagai branch/PR bisa menjadi alur kerja nyata
• Dalam praktiknya, sebagian besar commit yang dihasilkan agen memerlukan sentuhan manusia pada tingkat tertentu
  • Pada awalnya hampir semua commit perlu diperbaiki manual, tetapi saat keterampilan menulis prompt meningkat, jumlah koreksinya makin berkurang
  • Isi perbaikannya beragam, dari hal sederhana seperti mengedit komentar dan mengganti nama variabel, hingga refactoring yang lebih kompleks
  • Kuncinya adalah bagaimana melakukan koreksi ini secara efisien di lingkungan container
• Alur kerja yang sedang diuji di sketch.dev dan tempat lain
  • Menyediakan antarmuka yang memungkinkan tampilan diff diedit langsung
    • Jika kode diedit langsung di sisi kanan layar diff Sketch, perubahan itu diterapkan ke commit tersebut dan bisa langsung di-push
    • Ini sangat efisien untuk perbaikan kecil satu baris
  • Menyediakan akses SSH ke container
    • Masuk langsung lewat shell atau memanipulasi kode lewat terminal web
    • Bisa dibuka dengan URL vscode:// untuk bekerja di IDE tradisional
  • Meninggalkan komentar bergaya code review langsung di atas diff untuk diteruskan sebagai umpan balik ke agen
    • Dengan memanfaatkan pengalaman code review, penjelasan/syarat yang diperlukan dapat disampaikan dengan input seminimal mungkin
• Kesimpulan umum
  • Lingkungan container memungkinkan pembuatan-perbaikan-verifikasi-review kode dilakukan secara terpadu,
    sehingga melampaui sekadar penulisan kode dan memungkinkan pengembangan berbasis agen yang sesungguhnya
  • Dulu saya tidak ingin mengembangkan di dalam container,
    tetapi pengalaman merapikan/memperbaiki diff yang dibuat agen di container sangat menarik dan produktif

Penutup

• Proses mempelajari dan bereksperimen dengan teknologi berbasis LLM adalah waktu untuk belajar rendah hati
  • Di masa lalu, setiap kali esensi pemrograman berubah karena hadirnya multicore, SSD, ekspansi jaringan, dan lain-lain, itu terasa menyenangkan,
    tetapi LLM, khususnya agen, sedang sepenuhnya mengubah "proses itu sendiri" dari coding
  • Berbeda dari perubahan yang memengaruhi algoritme, bahasa, atau pemilihan library,
    agen membuat kita meninjau ulang secara mendasar semua asumsi tentang cara kerja itu sendiri
  • Bahkan perubahan ini begitu besar hingga kadang muncul pikiran, "mungkin lebih baik belajar lagi dari awal seolah sama sekali tidak tahu pemrograman"
  • Dan perubahan ini masih terus berlangsung saat ini juga
• Cara kita mengalaminya sekarang sudah sepenuhnya berbeda dibanding 6 bulan lalu, dan bahkan belum stabil
  • Standar budaya pengembangan seperti kolaborasi tim dan review tampaknya juga akan segera berubah besar
  • Misalnya, code review yang hanya dijalankan secara formal tidak lagi mampu menyelesaikan masalah nyata
    • Sudah saatnya proses code review itu sendiri diciptakan ulang
  • IDE juga, berbeda dari integrasi yang selama ini diklaimnya, akan sampai pada titik harus dirombak total
  • Industri memang menyadari perubahan ini, tetapi pendekatan yang berpusat pada agen baru benar-benar mulai
  • Perubahan besar lain sudah menanti di depan, dan
    hanya rasa ingin tahu dan kerendahan hati yang akan membantu melewati perubahan ini dengan baik
  • Bahkan, saat ini mungkin lebih baik menjauh dari forum internet bertema teknologi,
    dan menyerahkan diskusi serta ringkasan seperti ini kepada agen

[GN⁺]

Komentar Hacker News

• Saya kebanyakan menulis kode hanya untuk alat saya sendiri, jadi saya kurang melihat manfaat besar ketika orang lain atau sesuatu yang bukan saya menulis kode lalu saya harus membacanya, memahaminya, dan memperbaikinya; tentu, kalau saya minta LLM menemukan bagian yang saya butuhkan dari dokumentasi API itu sangat berguna dan menghemat waktu, jadi terlepas dari apakah performa LLM di masa depan akan membaik atau tidak, saya memang tidak terlalu suka membaca kode orang lain

  • Buat saya ada kasus di mana LLM membantu, misalnya pada kode yang terformalisasi, efeknya bisa menghilangkan kebutuhan akan makro atau code generator; memang lambat dan sulit melakukan pembaruan keseluruhan sekaligus seperti makro, tetapi untuk struktur kode yang berulang dengan sedikit perbedaan, LLM justru lebih berguna daripada makro; lalu saat memakai API yang sudah familiar tapi saya tidak hafal kodenya, saya bisa langsung bekerja tanpa harus googling dan membongkar dokumentasi; karena saya memakai bahasa bertipe, kalau LLM ngaco biasanya bisa tersaring oleh type checker atau test jadi tidak terlalu khawatir; dan saat perlu perubahan di lebih dari 10 file, ketika ia menyusun rencana perubahan dalam Markdown itu benar-benar sangat menghemat waktu; terakhir, saat lelah saya mudah mengabaikan aturan style atau penamaan, tetapi LLM cukup bagus menjaga style yang sudah ada di proyek
  • Akhir-akhir ini saya makin suka bekerja dengan cara seperti ini: pertama merencanakan desain coding secara keseluruhan, lalu menjelaskan langkah-langkah konkret ke LLM, dan sementara saya membaca, memahami, memperbaiki kode, serta merencanakan langkah berikutnya, saya biarkan LLM mengerjakan lebih dulu kode untuk bagian berikutnya; bisa dibilang saya dan LLM bekerja paralel masing-masing; ini seperti chef di restoran yang begitu pesanan masuk langsung memikirkan seluruh tahapan memasak, lalu saat steak dipanggang ia tidak menunggu saja tetapi mengerjakan persiapan lain; LLM lebih mirip alat dapur seperti oven atau food processor; misalnya keju bisa diparut dengan tangan, tetapi kalau dimasukkan ke food processor bisa menghemat beberapa menit; koki profesional meningkatkan efisiensi dengan multitasking memakai berbagai alat, dan saya pikir ke depan coding juga bisa berubah dari kerja baris demi baris menjadi struktur multitasking
  • Soal pertanyaan apa manfaatnya menyerahkan tanggung jawab menulis kode ke sesuatu yang lain lalu pada akhirnya tetap harus saya baca lagi, pahami, dan perbaiki sendiri, saya memakai istilah "friction"; banyak orang kesulitan memulai pekerjaan baru, seperti writer's block, dan jika sudah ada solusi awal buatan pihak lain, ambang masuk untuk mengubahnya sesuai cara kita dan memodularkannya jadi jauh lebih rendah; banyak rekan saya dan saya sendiri merasa beban besar saat harus men-setup proyek dari nol, menyusun toolchain, dan bootstrap; LLM, jika diberi konteks dan resource yang cukup, bisa dengan cepat memindai seluruh codebase dan menemukan hal seperti "sudah ada dua mekanisme audit di kode ini, mari ekstrak bagian bersama"; ia bisa menangkap bagian yang sebelumnya saya lewatkan sendiri
  • Dalam salah satu codebase yang saya tangani, ada banyak tugas yang mengharuskan perubahan kecil berulang di banyak file; pekerjaan seperti ini bukan soal kreativitas atau tantangan, melainkan sekadar membuka banyak file dan mengeditnya berulang-ulang; dulu butuh 3~4 jam, tetapi kalau saya jelaskan tugasnya ke AI agent, 99% bisa ditangani sendiri dan hanya memakan 3~4 menit
  • Ada orang-orang yang memang tidak bisa berbuat banyak tanpa alat; orang seperti ini menjadi early adopter dan power user yang menyebarkan penemuan baru; nilai GitHub adalah menyediakan lingkungan di mana developer biasa bisa tampak produktif melalui PR, review, green square, daftar todo, dan semacamnya; LLM juga disukai manajer karena memungkinkan developer biasa tampak produktif sambil menjalankan berbagai alat dan agent yang sebenarnya tidak terlalu penting

• Saya sepenuhnya setuju dengan bagian penulis yang mengatakan code review itu lemah dan hampir tidak benar-benar berfungsi; di era agent yang menulis kode, bottleneck yang sesungguhnya bukan penulisan melainkan membaca kode; jika orang melakukan review asal-asalan atau hanya memakainya sebagai sarana menunjukkan selera pribadi, agent bisa dengan mudah menyisipkan masalah keamanan atau performa yang serius; terus terang, masalah sebenarnya sering tidak terlihat hanya dari membaca kode, dan perlu debugging langsung atau verifikasi asumsi secara manual

  • Saya juga bertanya-tanya bagaimana tepatnya kode agent/AI menyelesaikan masalah "review yang buruk" ini; orang memang tidak suka melakukan code review dan menganggapnya membosankan; saya khawatir kita justru akan menyerahkan bagian yang menyenangkan, yaitu "menulis kode", kepada AI lalu sebagai gantinya harus menerima pekerjaan membaca dan memeriksa kode tanpa akhir
  • Bagian yang saat ini paling kurang di pasar adalah bagaimana cara membaca, me-review, dan memahami kode, diff, dan seluruh codebase yang dihasilkan LLM secara efisien; jika jumlah orang di proyek sangat sedikit, saya khawatir apakah orang-orang yang tersisa benar-benar membaca kodenya atau hanya melewatinya begitu saja
  • Inti agent adalah bahwa jika test coverage cukup, AI bisa menulis kode dan sekaligus mendapatkan umpan balik keamanan/performa, dan AI itu juga membantu menulis test

• Rasanya akhirnya melihat tulisan yang menganalisis LLM secara realistis; istilah "agent" itu sebenarnya cuma nama untuk for loop yang secara rekursif memanggil LLM, jadi agak membuat frustrasi, tapi selera penamaan di industri ini memang rata-rata rendah, jadi ya diterima saja

  • Saya tidak sepenuhnya sama dengan penulis soal definisi "agent"; yang sebenarnya adalah struktur di mana LLM ber-loop sambil memanggil tool dan resource secara berulang; perbedaannya halus, tetapi menyangkut penentuan siapa subjek utamanya
  • Saya suka ungkapan "agent adalah tool di dalam loop"; rasanya saya ingat Simon pernah mengatakan ini
  • Saya agak berbeda pendapat dengan definisi agent dari OP; ciri sebenarnya bukan sekadar LLM yang ber-loop, tetapi bahwa tindakan LLM dibatasi atau diarahkan oleh komponen logis lain; sebagian deterministik dan sebagian lagi berbasis ML, termasuk LMM; artinya, kita bisa mendapat kegunaan tambahan dengan memaksa LLM menyusun rencana dalam sistem yang dirancang tertentu, atau memicu build dan menjalankan test setelah edit kode, dan sebagainya; penjelasan "agent bergerak sendiri setelah menerima input" tidak sepenuhnya salah, tetapi yang lebih esensial sebenarnya adalah niat agar berbagai komponen terus-menerus mengawasi dan membimbing perilaku LLM
  • Penamaan "Agent" sendiri menurut saya tidak masalah karena intuitif dan mudah dipahami orang, tetapi kalau mencari alternatif lain, saya sempat berpikir nama seperti LoopGPT mungkin bagaimana

• Terkait bagian "kita setuju bahwa container berguna dan diperlukan dalam pemrograman", dijelaskan mengapa Solomon Hykes, pembuat Docker, baru-baru ini merilis open source proyek Container Use: agar agent bisa dijalankan secara aman dan paralel; beberapa platform seperti Sketch memang punya environment development lokal yang terisolasi, tetapi agent coding lain tidak; sebagai tambahan ada juga rekomendasi video YouTube

• Agentic loop, otak di dalam mesin, pada dasarnya tampak seperti pengganti rule engine; memang masih punya kekurangan khasnya sendiri, tetapi menurut saya beberapa tokoh besar sudah menangkap esensinya dengan baik; "hubungkan tool agent, beri prompt berdasarkan permintaan pengguna, jalankan saja secara berulang, dan prompt-nya sendiri juga berubah dinamis sesuai situasi"; tanpa harus meniru interaksi manusia atau cara manusia memecahkan masalah, ini sudah cukup berguna untuk orkestrasi/multitahap, penggantian tugas samar, atau otomasi; dulu ambiguitas harus diimplementasikan langsung dengan kode, tetapi sekarang itu bisa hilang; di lingkungan produksi nyata masih ada kekhawatiran soal menjalankannya tanpa dry run, tetapi saya kira tool dan layanannya sendiri akan berevolusi; jika lebih dari 100 layanan serupa terhubung ke dunia luar dengan antarmuka yang konsisten, misalnya SMS, email, cuaca, sosial, dan lain-lain, saya berharap akan muncul assistant yang jauh lebih kuat, atau bahkan lebih dari itu

  • Ada proyek mainan yang menarik yang menghubungkan agent ke berbagai layanan seperti kalender dan cuaca lalu membuat antarmuka game, tautan
  • Jika abstraksi untuk semua tool yang digunakan bisa diseragamkan, hasilnya bisa jauh lebih hebat daripada assistant yang ada sekarang, tetapi kenyataannya kita juga harus menanggung kemungkinan gangguan dan kesalahan yang luar biasa besar; isu seperti reliability engineering, quality assurance, kontrol izin, keamanan, dan privasi akan makin penting; saya menduga ini juga bisa jadi alasan Apple belum meluncurkan voice assistant terbaru yang benar-benar melampaui keterbatasan Siri, karena manajemen risiko seperti ini

• Membaca kode selalu sama pentingnya dengan menulis, tetapi sekarang kenyataannya menjadi semakin penting; ini mimpi buruk saya; menulis kode kadang menyenangkan, sedangkan membaca kode selalu kerja keras

  • Meski begitu, "serunya memperbaiki" bisa tetap ada, atau malah bertambah

• Saya penasaran berapa banyak orang yang memakai agent benar-benar menyukai "pemrograman" itu sendiri, yaitu memikirkan cara menyelesaikan masalah dan kesenangan mengekspresikannya dalam kode; melihat banyak pekerjaan agent belakangan ini, proses itu sendiri seperti hilang, dan yang tersisa justru struktur di mana kita hanya menjelaskan requirement dalam bahasa alami lalu berharap LLM tidak membuat bug

  • Saya tipe orang yang memang menikmati coding, dan ketika LLM sekali jadi membuat parser yang seharusnya menyenangkan untuk saya buat sendiri, saya malah merasa agak hampa; meski begitu, saya jadi bisa fokus pada tujuan yang lebih besar daripada menghabiskan waktu membuat parser; cukup menulis tipe/function signature yang saya inginkan lalu membiarkan LLM mengisi implementasi detailnya membuat saya bisa langsung lanjut ke tahap berikutnya; dulu perubahan menyeluruh yang rasanya "akan bagus kalau diperbaiki, tapi terlalu merepotkan" adalah beban besar, tetapi sekarang LLM membantu dalam perapian kode, pembuatan test, sinkronisasi README, sampai ide refactoring, sehingga tingkat penyelesaian dan ambisi proyek justru meningkat; kalau cara pandangnya tepat, bagi builder yang menikmati software ini bisa dibilang surga
  • Sebaliknya, untuk masalah yang sudah ribuan kali diulang, saya memang tidak terlalu ingin mengimplementasikannya sendiri; dalam situasi seperti itu saya pakai dictionary, bukan membuat hash table baru; jika saya bisa berkata "tolong buat compiler untuk bahasa ini" atau "coba selesaikan dengan DFS" lalu hasil sempurna datang, itu justru tidak akan mengurangi kesenangan saya dalam pemrograman; ada keterbatasan bahwa mendeskripsikan proses komputasi dalam bahasa alami pada tingkat kompleks mudah menjadi tidak akurat atau kontradiktif; tetap saja, siapa pun tidak menyarankan memakai LLM tanpa berpikir, dan pada akhirnya tanggung jawab atas hasilnya tetap ada pada saya
  • Sebagai dasar bahwa bahasa alami tidak cocok untuk pemrograman, saya merujuk pada dokumen EWD667; memang LLM berguna untuk tanya-jawab bergaya stackoverflow, tetapi jika ke depan data SO berkurang, bahkan kemampuan itu pun bisa mencapai batasnya
  • Saya pribadi tidak setuju; sebagian besar yang dilakukan LLM adalah pekerjaan implementasi yang repetitif dan membosankan; saya tetap tidak kehilangan bagian yang menyenangkan, seperti arsitektur proyek atau merancang sendiri bagian-bagian kreatif dan sulit yang bahkan sukar bagi LLM; mungkin setahun lagi situasinya berbeda, tetapi untuk sementara saya puas karena bisa fokus hanya pada bagian yang benar-benar butuh pemikiran
  • Saya penulis postingannya sendiri, dan saya suka pemrograman maupun agent

• Ada beberapa area saat coding di mana saya senang memakai AI (ini benar-benar tulisan saya sendiri!):

  • CSS: saya selalu tidak suka mengerjakan CSS di situs web mana pun, tetapi AI mengingat semua trik CSS yang rumit sehingga waktu kerja lebih singkat; misalnya di WordPress yang kompleks pun, memusatkan div tertentu bisa cepat dilakukan setelah beberapa kali trial and error
  • Unit test: ketika data kode bawaan AI belum usang, membuat test juga jadi pengalaman yang menyenangkan
  • Ringkasan commit: setidaknya untuk draf awal sudah cukup layak
  • Tugas yang sangat kecil setingkat mahasiswa tahun pertama juga bisa diselesaikan cepat
  • Menariknya, dari sudut pandang saya AI justru terasa tidak terlalu bagus menulis CSS sehingga pernah terasa tidak berguna, tetapi saya sangat setuju dengan gagasan bahwa ia membantu mengerjakan tugas yang tidak kita sukai; dalam kasus saya contohnya menulis deskripsi tiket, dan AI melakukannya jauh lebih baik daripada saya
  • Maaf kalau saya salah paham, tetapi kalau Anda belum terlalu akrab dengan tren CSS terbaru, CSS sekarang jauh lebih tidak rumit dan lebih mudah dikelola daripada dulu, jadi saya juga merekomendasikan meluangkan beberapa jam untuk mempelajari CSS modern; meski begitu, saya sendiri juga banyak memakai AI untuk styling

• Bagian tentang "aset" dan "utang" menarik, tetapi saya tidak setuju; banyak program berawal untuk segelintir pengguna lalu tanpa diduga menjadi proyek besar; di masa lalu saya terlalu sering melihat kode ilmiah yang ditulis asal untuk sekali pakai lalu tanpa sengaja berkembang jauh lebih lama dan lebih luas; karena itu saya menulis kode saya dengan mempertimbangkan bahwa ia bisa dipakai jauh lebih lama dan dalam cakupan lebih luas, bahkan sebagai bentuk perhatian pada diri saya sendiri dan orang lain; kalau Anda pernah melihat side project pribadi rekan kerja diangkat manajer menjadi proyek departemen, Anda pasti paham masalah ini

  • Tetap saja, pertanyaannya adalah "apa alternatifnya?"; orang memang buruk dalam memprediksi apa yang akan diadopsi luas; malah lebih umum proyek yang dikerjakan dengan sungguh-sungguh tidak dipakai ke mana-mana, sementara proyek yang dibuat cepat dan agak serampangan justru sukses, karena ada tekanan evolusioner ke arah itu; untuk bagian ini bisa merujuk ke esai klasik "worse is better" (tautan)

• Menurut saya, memakai LLM bukan untuk menulis/merancang kode melainkan untuk code review bisa menjadi killer feature yang sesungguhnya; saat ini code review sendiri sudah rusak di banyak aspek, dan ke depan saya berharap pemanfaatan LLM akan besar untuk keamanan, undefined behavior, penyalahgunaan fitur, dan pemeriksaan ganda isu compiler warning; secara pribadi saya lebih sering memakai LLM seperti search engine untuk diagnosis error atau debugging, dengan tingkat jawaban benar sekitar 50%, dan itu sudah cukup memuaskan bagi saya

  • ChatGPT sudah sangat bagus untuk debugging jika masalahnya memang sudah banyak dibahas di web; ia merangkum dan mengintegrasikan pengetahuan stack overflow sehingga sangat menghemat waktu mencari kasus satu per satu; hanya saja jawaban LLM tetap bercampur halusinasi sehingga masih ada noise, dan jika dipakai me-review seluruh kode ia memang bisa cukup baik menemukan tipe error atau fungsi/panggilan yang bermasalah, tetapi di sisi lain false positive pasti juga banyak; saya penasaran apakah orang benar-benar memanfaatkan LLM dengan tepat untuk review kode otomatis
  • Kalau kita berulang kali meminta "tolong review kode ini", kadang chatbot mengubah X menjadi Y, lalu tak lama kemudian mengubah Y kembali menjadi X; untuk code review memang ada efeknya sampai taraf tertentu, tetapi tetap harus menilai sendiri mana hasil yang diterima dan mana yang ditolak; bagi orang yang punya ketajaman penilaian memadai, ini benar-benar berperan sebagai pemberi usulan perubahan kandidat yang sangat meningkatkan produktivitas
  • Saya penasaran mengapa topik seperti ini tidak dibahas lebih besar; developer di sekitar saya punya tingkat minat teknologi yang beragam, dan biasanya yang lebih junior cenderung lebih aktif memakainya sementara yang senior kurang tertarik; saya hampir tidak pernah mendengar pembicaraan tentang memakai AI untuk review/verifikasi kode, jadi mungkin yang dibutuhkan adalah fitur yang berjalan otomatis saat commit
  • Dibanding code review/design, LLM yang dikhususkan untuk code review sebenarnya sudah tersedia di GitHub Copilot dalam reviewer mode; memang belum level terbaik, tetapi kualitasnya sudah cukup layak untuk dipakai dalam loop
  • Setuju, kami mengerjakan hal seperti ini di sourcery.ai