- Membagikan metodologi konkret untuk pengembangan software dengan LLM, menggunakan workflow multi-agen arsitek-developer-reviewer agar proyek berskala puluhan ribu baris tetap terjaga dengan tingkat cacat yang rendah
- Ia lebih tertarik pada membuat sesuatu daripada pemrograman itu sendiri, dan kini bisa fokus pada proses membuat karena LLM sudah sangat mahir menulis kode
- Dibanding kemampuan menulis kode, skill engineering untuk merancang arsitektur sistem dan mengambil keputusan yang tepat kini menjadi jauh lebih penting
- Kualitas code review ditingkatkan dengan mencampur model yang berbeda dan memanfaatkan kekuatan serta kelemahan masing-masing model menurut peran
- Seluruh sesi nyata saat menambahkan fitur email dibuka ke publik, dan proses kolaborasi LLM yang dipimpin manusia dari keputusan arsitektur hingga QA didokumentasikan secara rinci
Keuntungan membangun dengan LLM
- Ia semula mengira dirinya menyukai pemrograman, tetapi sebenarnya lebih menyukai proses membuat itu sendiri; sekarang, karena LLM sudah pandai memrogram, ia terus membuat berbagai hal tanpa henti
- Sekitar saat rilis Codex 5.2, dan kini hingga Opus 4.6, menulis software dengan tingkat cacat yang sangat rendah menjadi mungkin. Dalam beberapa kasus, tingkat cacatnya bahkan bisa jauh lebih rendah daripada saat menulis kode sepenuhnya dengan tangan
- Dulu, setelah bekerja 2~3 hari, kode sering masuk ke kondisi yang tidak bisa dirawat; sekarang ia bisa bekerja terus selama berminggu-minggu dan secara stabil menumbuhkan puluhan ribu baris kode yang berguna
- Skill engineering bukan menjadi tidak berguna, melainkan bergeser: bukan lagi terutama soal menulis kode dengan benar, tetapi soal menata arsitektur sistem dengan benar dan membuat keputusan yang membuatnya benar-benar bisa dipakai
- Pada proyek dengan teknologi yang sangat ia pahami, seperti backend, puluhan ribu SLoC bukan masalah. Tetapi pada teknologi yang kurang ia kuasai, seperti aplikasi mobile, kode masih bisa berantakan karena akumulasi keputusan yang salah
- Di masa awal LLM (setelah davinci), ia harus memeriksa setiap baris kode. Pada generasi berikutnya, cukup per tingkat fungsi, dan sekarang tren bergerak ke titik di mana pengecekan hanya perlu di level arsitektur keseluruhan. Tahun depan, bahkan itu pun mungkin tidak diperlukan
Proyek yang dibuat dengan cara ini
- Stavrobot: asisten pribadi LLM yang berfokus pada keamanan. Bisa mengelola kalender, menilai ketersediaan waktu, melakukan riset, memperluas dirinya lewat penulisan kode, memberi pengingat, serta mengelola pekerjaan rumah secara otonom. Nilai utamanya bukan satu fitur killer, melainkan menghilangkan ribuan ketidaknyamanan kecil
- Middle: perangkat liontin kecil yang merekam memo suara, mentranskripsikannya menjadi teks, lalu mengirimkannya melalui webhook. Nilai utamanya adalah selalu bisa dibawa dan digunakan tanpa friksi
- Sleight of Hand: proyek seni jam dinding yang berdetak tidak teratur per detik, tetapi selalu akurat per menit. Menyediakan berbagai mode seperti tick variabel 500ms~1500ms, perubahan kecepatan yang sulit disadari lalu berhenti secara acak, atau melaju dua kali lebih cepat lalu menunggu 30 detik
- Pine Town: kanvas multiplayer tanpa batas, tempat setiap orang mendapat sebidang tanah kecil untuk menggambar, sebuah proyek padang rumput interaktif
- Semua proyek ini dibuat dengan LLM, dan meskipun ia belum pernah membaca sebagian besar kodenya secara langsung, ia tetap sangat memahami arsitektur dan cara kerja internal tiap proyek
Tool harness
- Saat ini ia menggunakan OpenCode sebagai harness, dan juga punya pengalaman baik dengan Pi
- Dua syarat wajib untuk harness:
- Bisa memakai beragam model dari banyak perusahaan: sebagian besar harness first-party (Claude Code, Codex CLI, Gemini CLI) hanya mendukung model milik sendiri, sehingga tidak memenuhi syarat ini
- Agen kustom bisa saling memanggil secara otonom
Mengapa perlu memakai banyak model
- Model tertentu bisa dianggap seperti satu orang; bahkan setelah konteks di-reset, ia cenderung mempertahankan pendapat, kekuatan, dan kelemahan yang sama
- Jika sebuah model diminta me-review kode yang ditulisnya sendiri, ada kecenderungan untuk menyetujui diri sendiri sehingga hampir tidak berguna. Tetapi jika review diserahkan ke model lain, kualitasnya meningkat drastis
- Saat ini, Codex 5.4 cocok untuk review karena teliti dan cerewet, Opus 4.6 sangat selaras dengan keputusan yang akan ia ambil sendiri, dan Gemini 3 Flash kadang memberi solusi yang luput dari model lain
- Untuk hasil terbaik, perlu menggabungkan semua model
Workflow: arsitek → developer → reviewer
- Workflow terdiri dari arsitek, developer, dan 1~3 reviewer. Mereka dikonfigurasi sebagai agen OpenCode (file skill)
- Tiga alasan memakai banyak agen:
- Model mahal (Opus) dipakai untuk menyusun rencana, sedangkan model lebih murah (Sonnet) dipakai untuk menulis kode, sehingga hemat token
- Jika review dilakukan oleh model yang berbeda, masing-masing bisa menangkap masalah yang berbeda
- Memungkinkan pemisahan hak akses berdasarkan peran (misalnya read-only vs bisa menulis)
- Memakai dua agen dengan model yang sama dan hak akses yang sama pada dasarnya hanya seperti satu orang memakai topi berbeda, sehingga tidak terlalu bermakna
- File skill ditulis manual secara langsung. Jika skill ditulis oleh LLM, rasanya seperti meminta seseorang menulis “cara menjadi engineer hebat”, lalu mengembalikan petunjuk itu kepadanya sambil berkata “sekarang jadilah hebat”
Peran arsitek
- Arsitek (saat ini Claude Opus 4.6) adalah satu-satunya agen yang diajak bicara langsung, dan harus menjadi model terkuat
- Ia memberikan target fitur atau perbaikan bug yang sangat spesifik, lalu berdiskusi hingga 30 menit sampai tujuan, batasan, dan trade-off benar-benar jelas
- Hasil akhirnya adalah rencana yang cukup low-level sampai ke level file dan fungsi individual
- Ini bukan sekadar prompting, melainkan proses membentuk rencana dengan bantuan LLM. Saat LLM salah atau berbeda dari cara yang ia inginkan, ia banyak mengoreksi, dan inilah kontribusi utama yang membuat proyek tersebut benar-benar “miliknya”
- Diatur agar tidak mulai implementasi sampai ia secara eksplisit mengucapkan kata “approved”. Beberapa model cenderung terburu-buru mulai mengimplementasikan begitu merasa sudah paham
- Setelah disetujui, arsitek membagi pekerjaan menjadi beberapa task, mencatatnya secara rinci dalam file rencana, lalu memanggil developer
Peran developer
- Developer bisa memakai model yang lebih lemah namun lebih efisien dalam token (Sonnet 4.6)
- Karena rencananya meminimalkan ruang diskresi, perannya secara ketat adalah mengimplementasikan perubahan sesuai rencana
- Setelah implementasi selesai, developer memanggil reviewer
Peran reviewer
- Setiap reviewer meninjau rencana dan diff secara independen, lalu memberi kritik
- Ia selalu memakai minimal Codex, kadang menambahkan Gemini, dan untuk proyek penting juga menambahkan Opus
- Umpan balik dikirim kembali ke developer, dan jika ada ketidaksepakatan antar-reviewer, masalahnya dieskalasikan ke arsitek
- Opus unggul dalam memilih umpan balik yang benar, dan kadang mengabaikan feedback yang terlalu cerewet bila kecil kemungkinan menimbulkan masalah nyata dibanding biaya implementasinya
Pendekatan umum dan mode kegagalan
- Dengan cara ini, ia memahami semua keputusan di atas level fungsi, dan memakai pengetahuan itu untuk pekerjaan lanjutan
- Ketika LLM punya blind spot dan melewatkan elemen tertentu di codebase, memberi tahu “harus memakai Y” membuat LLM menyadari keberadaan Y dan beralih ke pendekatan yang lebih baik
- Jika tidak akrab dengan teknologinya, ia tidak bisa menangkap keputusan salah yang diambil LLM, lalu keputusan salah itu menumpuk sampai akhirnya mencapai kondisi yang tak bisa diselesaikan
- Pola kegagalan yang khas adalah terus berkata “kodenya tidak jalan”, lalu LLM menjawab “baik, akan saya perbaiki” sambil justru membuatnya lebih rusak
- Karena itu, bahkan bila tidak terlalu paham dengan teknologi tertentu, ia tetap berusaha memahami sebanyak mungkin pada tahap perencanaan
Sesi nyata: menambahkan dukungan email ke Stavrobot
- Ia merilis transkrip lengkap sesi nyata yang sudah diberi anotasi. Pemanggilan tool dan bagian yang bertele-tele dihilangkan, tetapi percakapan dan proses pengambilan keputusan dipertahankan apa adanya
- Percakapan awal: memberi tujuan tingkat tinggi (“saya ingin menambahkan dukungan email ke bot ini”) → LLM membaca kode dan memahami pola yang ada saat ini (webhook masuk → enqueueMessage → pemrosesan LLM → respons), lalu mengajukan pertanyaan desain
- Metode inbound (polling IMAP, webhook, server SMTP), metode outbound, apakah dua arah, arsitektur (container terpisah vs in-process), penanganan email HTML, pelacakan thread, lampiran, dan lain-lain
- Keputusan desain: inbound memakai webhook Cloudflare Email Worker, outbound memakai klien SMTP, percakapan dua arah penuh, pemrosesan in-process, konversi ke Markdown, email diperlakukan sebagai entitas independen, serta dukungan lampiran
- Usulan desain detail dari LLM: memberi 7 concern dan rancangan konkret, termasuk parsing MIME (memakai
mailparser), autentikasi webhook (shared secret), kebutuhan subject line outbound, penanganan email HTML-only, identitas alamat From, penanganan email yang diteruskan, dan lampiran outbound
- Mengusulkan payload Worker disederhanakan menjadi
{ from, to, raw }, lalu parsing dilakukan di sisi server
- Merapikan struktur config, alur inbound/outbound, daftar file yang diubah, dan item non-goal eksplisit (YAGNI)
- Penyempurnaan rencana: manusia menunjukkan hal-hal yang terlewat seperti pembaruan
README.md dan config.example.toml, serta penghapusan validasi E.164 di halaman allowlist email → LLM lalu mengintegrasikannya
- Dibagi menjadi 6 task: config/dependensi, allowlist, validasi UI/backend allowlist, email inbound, email outbound, README/test
- Perbaikan tambahan: muncul ide untuk membuat field SMTP opsional agar email inbound tetap bisa berfungsi tanpa konfigurasi SMTP → lalu diimplementasikan
- Bug yang ditemukan saat QA: email pemilik tidak terdaftar sehingga pesan dibuang → penyebabnya
seedOwnerInterlocutor tidak memasukkan channel email → lalu diperbaiki
- Usulan perbaikan kode: melakukan refactor dari blok
if yang hardcoded per channel menjadi iterasi atas daftar channel bersama. Setelah membahas special case konversi numerik di Telegram, diputuskan hanya menerapkan loop pada seedOwnerInterlocutor, sedangkan getOwnerIdentities tetap dipertahankan karena perbedaan tipenya memang esensial
- Allowlist email wildcard: ditambahkan dukungan wildcard tingkat domain berbentuk
*@example.com, dibutuhkan untuk use case nyata yang memakai alamat email sekali pakai
- Pertimbangan keamanan: untuk mencegah serangan seperti
"me@mydomain.com"@evildomain.com, * diubah menjadi [^@]* agar tidak bisa melintasi batas @
- Juga mendukung wildcard parsial seperti
myusername+*@gmail.com
- Manusia juga menekankan bahwa saat memakai regex, semua karakter lain dalam alamat email harus di-escape
- Dikonfirmasi bahwa wildcard berfungsi baik di field pemilik maupun allowlist, dan keduanya memakai helper function
matchesEmailEntry yang sama
- Seluruh fitur selesai diimplementasikan dalam sekitar 1 jam
Epilog
- Setup-nya memang tidak terlalu mencolok, tetapi bekerja sangat baik, dan ia puas dengan keandalan prosesnya
- Stavrobot telah dijalankan hampir sebulan penuh 24/7 dan sangat stabil
10 komentar
Seperti lebih dari 20 tahun lalu ketika editor web atau blog massal sedang tren dan bertebaran homepage atau postingan yang tidak akan dilihat siapa pun, di era kecerdasan buatan pun ada pola yang mirip. Namun, membuat aplikasi kustom dan membagikan proses atau rutinitasnya jelas merupakan aset yang sangat bagus dan besar. Secara pribadi, saya melihat era sekarang bukan tentang membuat aplikasi atau layanan berbasis kecerdasan buatan yang menghasilkan uang, melainkan tentang dengan mudah membuat alat kustom yang saya butuhkan untuk meningkatkan produktivitas.
Sebenarnya rasanya manusia juga begitu. Mungkin bukankah ini juga alasan manusia perlu mengejar keberagaman...
Karena ini adalah model bahasa, model yang mahal memang sebaiknya digunakan untuk menyusun rencana.
> Model mahal (Opus) digunakan untuk perencanaan, model murah (Sonnet) untuk menulis kode agar hemat token
Banyak juga yang melakukan sebaliknya: Sonnet untuk perencanaan, Opus untuk implementasi kode, tetapi di sini justru kebalikannya.
Saya juga menyuruh opus dan codex saling lempar rencana.
Untuk coding saya serahkan ke opus, lalu code review saya minta opus lain dan codex yang mengerjakan.
Yang saya rasakan sambil menjalani ini, entah AI atau manusia, sama-sama jago sekali mengkritik orang lain..
https://code.claude.com/docs/ko/model-config#opusplan-model-settings
Saya juga menggunakan Claude dengan pengaturan model
opusplan.Dalam setelan default Oh my opencode, perencanaan memang dilakukan oleh opus dan implementasinya dikerjakan oleh model yang lebih ringan
Di sekitar saya, banyak yang memakai Sonnet untuk perencanaan/desain lalu menulis kode dengan GLM-5..
Saya juga biasanya membuat rencana dengan Sonnet dan mengerjakan implementasi kode dengan Opus, tetapi metode penulis mungkin lebih efisien.
Saya juga membuat rencana dengan Opus dan menggunakan Codex high untuk review, sedangkan coding sebenarnya saya jalankan dengan sonet atau codex medium.