Pola Rekayasa Agentik

• Panduan yang merangkum cara pengembangan di era agen coding seperti Claude Code dan Codex, serta menawarkan pola rekayasa baru untuk berkolaborasi dengan agen
• Menjelaskan dengan berbagai pola bagaimana kebiasaan pengembangan dan alur kerja perlu berubah di lingkungan ketika biaya menulis kode turun drastis
• Menata secara terstruktur area inti pengembangan berpusat pada agen seperti prinsip, pengujian, pemahaman kode, dan desain prompt
• Setiap pola disajikan dalam bentuk dokumen pola yang berfokus pada praktik nyata, lengkap dengan contoh kode, cara kerja, dan contoh penggunaan prompt
• Referensi praktis bagi pengembang di era agen coding untuk merancang lingkungan coding berbasis agen secara sistematis dan menjaga kualitas

---

Ikhtisar Agentic Engineering Patterns

• Panduan yang merangkum metode rekayasa yang efektif saat mengembangkan bersama agen coding (Claude Code, OpenAI Codex, dan lainnya)
• Lihat juga tulisan pengantar Writing about Agentic Engineering Patterns
  • Dokumen disusun agar dapat terus menambahkan berbagai pattern (bab) seperti format “Design Patterns” yang sudah dikenal
  • Berfokus pada perubahan alur kerja dan cara mengambil keputusan bagi pengembang di lingkungan ketika biaya penulisan kode jauh lebih rendah
  • Dikelola bukan sebagai posting blog, melainkan konten panduan yang dapat diperbarui dan akan terus diperluas

1. Principles

• Writing code is cheap now

  • Dengan hadirnya agen coding AI, biaya penulisan kode awal turun hingga nyaris gratis
  • Di masa lalu, penulisan kode mahal sehingga pengembangan berpusat pada desain dan perencanaan, tetapi kini ide dapat langsung diuji lewat kode
  • Meski biaya menghasilkan kode turun, kode yang baik (pengujian, kemudahan perawatan, dan sebagainya) tetap memiliki biaya

• Hoard things you know how to do

  • Aset penting bagi pengembang adalah akumulasi pengetahuan tentang “apa yang mungkin dilakukan”
  • Menekankan kebiasaan menyimpan dan mengumpulkan berbagai contoh penyelesaian masalah serta eksperimen kode kecil dalam bentuk yang bisa dipakai ulang
  • Kode dan contoh yang terkumpul ini dapat menjadi bahan masukan yang sangat kuat saat memberi instruksi kepada agen coding untuk membuat fitur baru

• Anti-patterns: things to avoid

  • Bahkan jika kode dibuat oleh agen, membagikannya atau mengirim PR tanpa review adalah anti-pattern yang harus dihindari
  • Deskripsi PR yang ditulis agen juga harus diverifikasi dan diperbaiki langsung oleh manusia
  • Agar tidak membuang waktu reviewer kode, pengujian, proses verifikasi, dan alasan pemilihan implementasi perlu disertakan bersama perubahan

2. Testing and QA

• Red/green TDD

  • Pengembangan berbasis test-first (TDD) adalah pola yang sangat efektif terutama saat digunakan bersama agen coding
  • Jika tes ditulis lebih dulu, agen dapat menghasilkan kode yang bergerak ke arah memenuhi tes tersebut
  • Bahkan dengan prompt minimal, ini membantu menghasilkan kode yang akurat dan dapat diandalkan

• First run the tests

  • Saat bekerja dengan agen coding, pengujian otomatis bukan pilihan melainkan unsur wajib
  • Di lingkungan ketika biaya menulis tes menurun, agen dapat dengan cepat membuat dan memperbaiki tes
  • Karena tidak ada jaminan kode benar-benar bekerja sebelum dijalankan, tes menjadi sangat penting

3. Understanding code

• Linear walkthroughs

  • Pola untuk memahami struktur proyek atau kode buatan agen dengan membacanya berurutan dari awal hingga akhir
  • Bahkan pada proyek sederhana, kita tetap bisa mempelajari teknologi dan struktur baru dengan mengikuti alur kode
  • Menanggapi kekhawatiran bahwa AI code generation memperlambat pembelajaran, pola ini menunjukkan penjelajahan kode itu sendiri bisa menjadi kesempatan belajar

• Interactive explanations

  • Cara memahami kode atau sistem dengan berdialog dengan agen dan meminta penjelasan
  • Dengan terus bertanya, kita dapat memahami prinsip kerja dan struktur kode secara bertahap
  • Pola yang memperluas proses memahami kode menjadi metode belajar interaktif

4. Annotated prompts

• GIF optimization tool using WebAssembly and Gifsicle

  • Mencakup contoh prompt untuk membuat alat optimasi GIF berbasis WebAssembly dan Gifsicle
  • Menunjukkan pendekatan implementasi alat satu halaman yang mencakup HTML, JavaScript, dan CSS
  • Menjelaskan cara memanfaatkan agen coding melalui prompt nyata dan contoh kode

5. Appendix

• Prompts I use

  • Kumpulan contoh prompt agen coding yang benar-benar digunakan
  • Merangkum berbagai pola prompt praktis yang dipakai untuk beragam tugas
  • Menyediakan template praktis yang dapat digunakan saat berkolaborasi dengan agen

[GN⁺]

Opini Hacker News

• Sepertinya kita akan mengulang hal yang sama lagi
  Konsep-konsep sederhana dan masuk akal — misalnya “tulis tes terlebih dahulu”, “buat modul yang kecil dan bisa dikombinasikan” — dibungkus dengan nama yang rumit, lalu darinya akan lahir industri konsultan
  Bedanya, kali ini sasarannya adalah “mesin yang bisa berbicara”. Seolah-olah cukup disuruh dengan kata-kata saja

  • COBOL juga pernah menjanjikan hal serupa. Katanya itu bahasa yang mudah dibaca manusia sehingga programmer tidak lagi dibutuhkan, tetapi pada akhirnya untuk memecah masalah dan menyelesaikannya, manusia tetap harus berpikir seperti programmer. Jadi, hanya karena bahasanya ramah bagi manusia bukan berarti programmer akan hilang
  • Kali ini pun tampaknya siklus boom AI akan terulang. Sekarang jika dikritik, responsnya adalah “kamu tidak paham”, tetapi sebentar lagi masalah-masalahnya akan bermunculan. Terutama situasi ketika “AI menghasilkan terlalu banyak kode sehingga manusia maupun AI sendiri tidak mampu menanganinya”. Pada saat itu, lagi-lagi akan muncul pola dan antipola, serta para konsultan yang mengklaim bisa menyelesaikannya
  • Karena AI berbicara dan memahami bahasa Inggris, kejelasan antarmuka menjadi berkurang. Ia kuat seperti CLI, tetapi tidak jelas pendekatan mana yang efektif. Karena itu, penting untuk mendokumentasikan dan berbagi “apa yang harus diminta dan bagaimana memintanya agar hasilnya bagus”. Namun, itu juga jangan sampai berubah menjadi seperti industri coaching OOP sekali lagi
  • Benar. Dan itu akan terjadi lagi, kali ini jauh lebih cepat. Siklus 10 tahun yang biasanya bergerak dari blogger → pembicara → buku → konsultan → lembaga sertifikasi akan muncul dalam bentuk yang dipadatkan hanya dalam beberapa tahun
  • Saya tidak setuju dengan kritik bahwa judul tulisannya terlalu rumit. Namun, kesalahpahaman bahwa “tinggal disuruh dengan kata-kata saja” memang masalahnya. Dalam praktiknya, hasil tiap orang sangat berbeda. Pada akhirnya, pelajarannya adalah “kebiasaan pengembangan yang baik untuk manusia juga baik untuk AI”. AI memang mirip manusia, tetapi bukan manusia. Karena itu, ia justru membutuhkan lebih banyak penjelasan

• Saya ingin bertanya kepada Simon — “bagaimana seharusnya code review dilakukan di dunia tempat kode menjadi murah?”
  Anggota tim mendekatinya dengan pola pikir “yang penting jalan”, tanpa benar-benar memahami strukturnya. Review jadi makin besar, dan saya menjadi bottleneck. Saya juga sempat memikirkan cara memakai reviewer AI sebagai delegasi, tetapi saya tidak suka jika nuansa manusianya hilang

  • Ini topik yang sangat menarik. Jika kecepatan pembuatan kode meningkat, maka review menjadi bottleneck. Jika kode itu murah, mungkin standar review bisa diturunkan, tetapi saya justru menginginkan kualitas yang lebih baik. Terutama peninjauan keamanan sama sekali tidak bisa dihilangkan. Mungkin dibutuhkan pendekatan yang sistematis seperti tim keamanan di organisasi besar
  • Jika ingin memakai review berbasis agen, pengaturan konteks itu penting. Jika menjalankan loop perencanaan → eksekusi → tes/perbaikan → review/refactor → pembuatan panduan QA, maka bukan hanya kode, tetapi juga dokumentasi dan panduan pengujian ikut berevolusi bersama
  • “Yang penting jalan” bukan masalah teknis, melainkan masalah budaya organisasi. Ada perusahaan yang masih sangat menekankan kode yang mudah dibaca. Itu bahkan bisa menjadi daya saing
  • Saya berinvestasi pada otomatisasi analisis statis dan dinamis. Saya aktif memanfaatkan alat kualitas seperti aturan lint kustom, pemeriksaan tipe yang ketat, dan mutation testing. Mengandalkan review saja itu lambat dan tidak efisien, jadi kuncinya adalah otomatisasi umpan balik dini
  • Sikap seperti ini tidak mudah diubah. Mungkin justru lebih baik pindah ke tim yang benar-benar menghargai kualitas perangkat lunak

• Saya terutama memakai AI untuk kode boilerplate atau pemecahan masalah dokumentasi
  Saya juga sudah mencoba pekerjaan bergaya agen, tetapi hasilnya masih sulit dipercaya. Namun, ada orang yang bilang “sekarang saya hampir tidak menulis kode lagi”. Kesenjangan itu menarik

  • Bagi saya, sering kali menulis kode langsung lebih cepat daripada AI. Proses merencanakan, menjalankan, dan memverifikasi justru lebih lambat. Tetapi untuk refactor skala besar, AI jauh lebih cepat
  • Dalam beberapa bulan terakhir, kemampuan agen meningkat tajam. Sekarang sudah melampaui sekadar autocomplete sederhana dan bahkan mampu mengimplementasikan fitur secara utuh
  • Mungkin ini bisa dijelaskan lewat perbedaan antara developer yang merasakan “kesan aneh (eww)” ketika melihat kode AI dan yang tidak
  • Pada akhirnya, tergantung jenis pekerjaannya, ada kasus yang jelas cocok untuk AI dan ada yang tidak
  • Saya juga sering tidak suka hasil pertama, tetapi jika loop review dijalankan beberapa kali, kualitasnya benar-benar naik. Hasilnya jauh lebih baik jika AI saling mereview atau jika kriteria tes dibuat jelas

• Akhir-akhir ini saya sedang bereksperimen dengan loop coding bergaya agen
  Misalnya, di proyek fesh, tujuannya adalah “mengompresi binary Linux agar lebih kecil”. Karena masalahnya memiliki tes yang jelas, itu cocok untuk loop AI
  Hal-hal yang saya pelajari adalah sebagai berikut:

  • Test harness adalah segalanya. Tanpa loop verifikasi, arahnya akan melenceng
  • Penting untuk membiarkan AI mencoba secara eksperimental
  • Kita perlu meninggalkan scratchpad .md antar sesi agar pembelajaran bisa berlanjut
  • Tes benar-benar penting. AI gagal dengan cara yang aneh, jadi kita harus aktif memanfaatkan pembuatan tes otomatis
  • Tanpa tes, hasil loop tidak bisa dipercaya. Prosedur verifikasi deterministik itu wajib
  • Mencatat log keputusan dan log penolakan secara terpisah itu berguna. Khususnya rejections.md ternyata lebih bernilai. Kita harus meninggalkan catatan “mengapa pendekatan ini dibuang” agar AI tidak mengulangi kesalahan yang sama
  • Dalam otomasi browser juga mirip. Bukan hanya verifikasi fungsional, kita juga perlu menambahkan verifikasi perilaku (apakah terlihat seperti manusia) agar hasilnya benar-benar berguna. Dan log .md sangat meningkatkan kualitas sesi berikutnya

• Saya berharap bagian tes membahas masalah ‘tes yang self-fulfilling’ buatan LLM
  Kadang tes itu sebenarnya tidak memverifikasi apa-apa, atau bahkan lolos dengan nilai yang di-hardcode. Manusialah yang harus mengarahkan AI menuju kebiasaan pengujian yang ketat

  • Saya penasaran dengan contoh konkretnya. Sepertinya yang dimaksud bukan sekadar kesalahan logika sederhana, tetapi tes yang di permukaan tampak baik-baik saja padahal sebenarnya tidak berarti
  • Tes yang buruk lebih berbahaya daripada tidak ada tes sama sekali. Begitu kepercayaan rusak, keyakinan terhadap seluruh test suite ikut runtuh
  • Itulah sebabnya mutation testing penting. Jika tes tetap lolos meski kodenya dimutasi, berarti itu tes yang buruk
  • Kita bisa meminta AI sengaja mengubah sebagian kode lalu memeriksa apakah tes gagal. Jika tidak gagal, berarti tes itu tidak berguna
  • Tentu saja, tidak mudah juga membuat manusia menulis tes seperti ini

• Setiap kali generasi baru LLM muncul, rasanya semua pelajaran lama langsung tidak berlaku
  Struktur rumit seperti LangChain, yang dibuat untuk mengakali keterbatasan model lama, menjadi tidak perlu lagi setelah GPT-3.5. Bisa jadi tak lama lagi agen tunggal saja sudah cukup untuk menangani semuanya

  • Karena itu saya mencoba merangkum pola yang tidak bergantung pada versi model. Misalnya, red/green TDD mungkin nanti akan dilakukan sendiri oleh model, tetapi konsepnya sendiri tetap berguna
  • Pada akhirnya, semua hal mungkin akan berkonsolidasi ke bentuk seperti ClaudeVM
    Lihat tulisan terkait

• Ada hal yang sering terlewat dalam diskusi tentang agent engineering
  Kebanyakan pelajaran disampaikan seolah-olah itu kebenaran universal, padahal kenyataannya bergantung pada ukuran tim, kematangan codebase, tingkat pengujian, dan toleransi risiko. Yang penting adalah menjelaskan dengan jelas “kapan pola ini benar-benar bekerja”

  • Karena itu saya menyusun polanya dalam bentuk website, bukan buku. Saya berencana terus memperbaruinya sambil menjelaskan cakupan penerapannya
  • Sebagai konsultan yang menangani berbagai codebase, saya melihat kinerja Claude Code sangat berbeda secara ekstrem tergantung kualitas codebase. Pada proyek dengan tipe yang kuat dan tes yang baik, hasilnya hampir sempurna, tetapi di lingkungan JavaScript yang longgar hasilnya kurang bagus
  • Meski begitu, beberapa pola memang universal. Misalnya, memiliki source of truth yang independen (harness) itu berlaku di mana-mana. Alat seperti showboat dan rodney membantu untuk hal itu

• Belakangan ini, puluhan “framework tim agen” bermunculan setiap hari
  Ini adalah masa eksperimen yang kacau, mirip awal-awal rekayasa perangkat lunak. Namun pada akhirnya, beberapa pola akan menetap sebagai standar.
  Di tim kami, pendekatan seperti tim manusia terbukti efektif — pertama menulis spesifikasi produk (spec), lalu memolesnya dengan AI, kemudian berdasarkan itu menyerahkannya ke alur agen dengan peran yang terpisah

• Hari ini saya mengajar kelas sarjana tentang evolusi arsitektur CPU dan GPU
  Di masa lalu, Moore’s Law membuat hardware menyelesaikan segalanya, tetapi sekarang paralelisme adalah kuncinya.
  Konsep “kode itu murah” yang dibicarakan Simon juga merupakan pergeseran paradigma yang serupa.
  Sebagaimana kode yang efisien berubah total di era hardware paralel, di era AI proses pengembangan itu sendiri akan berubah. Siapa yang memahami ini lebih dulu akan mendapat keuntungan 10–100 kali lipat

• Di tim kami, ‘loop dengan verifikasi manusia di titik-titik tertentu’ adalah yang paling praktis
  Agen yang sepenuhnya otonom sering kali lolos tes tetapi melanggar invarian implisit.
  Karena itu, kami memastikan manusia ikut campur tepat sebelum keputusan yang tidak bisa dibalikkan.
  Namun, membuat AI memahami “apa yang tidak bisa dibalikkan” adalah tantangan lain.
  Selain dokumen seperti CLAUDE.md, kami sedang mencari cara sistematis untuk menyampaikan aturan codebase yang implisit