Pengkodean agentic berkembang dengan kecepatan yang belum pernah terjadi sebelumnya bahkan menurut standar dunia teknologi. Tutorial dan sumber daya yang tersedia online sebagian besar mencakup fitur-fitur individual dalam skenario greenfield yang sederhana.

Selama pengembangan Bob dan saat berinteraksi dengan banyak praktisi di lapangan dari berbagai industri, muncul sekumpulan konsep yang membantu meningkatkan efektivitas dan pengalaman penggunaan Bob.

Konsep-konsep tersebut juga berlaku untuk proyek-proyek kompleks yang menggunakan teknologi non-mainstream.

Konsep 1: Siklus — eksplorasi, perencanaan, implementasi, verifikasi

Siklus eksplorasi, perencanaan, implementasi, verifikasi, dengan loop luar untuk peningkatan terus-menerus pada panduan dan sensor

Kegagalan paling umum dalam Software Engineering agentic adalah ketiadaan struktur. Koherensi percakapan menyamarkan struktur dan kita tergoda untuk menggabungkan semua langkah implementasi dalam satu percakapan chat. Sesi terasa produktif, tetapi biayanya baru terlihat saat review.

Menulis kode secara manual memaksakan struktur tersendiri. Implementasi mahal, sehingga merencanakan sebelum mengimplementasi terasa intuitif. Pemahaman terakumulasi saat kamu mengetik, dan asumsi yang salah kemungkinan besar akan terungkap selama proses itu. AI Agent menghilangkan hambatan itu. Kode kini murah dan hal itu juga menghilangkan intuisi kita untuk struktur. Struktur yang dulunya merupakan efek samping dari lambatnya proses kini harus dilakukan secara disengaja.

Menggunakan siklus ini secara sengaja dapat memberikan struktur tersebut:

Eksplorasi menghasilkan pemahaman
Perencanaan menghasilkan keputusan
Implementasi menghasilkan kode
Verifikasi menghasilkan bukti.

Mengikuti siklus ini membantumu tetap fokus, terstruktur, dan mencapai tujuan dengan lebih cepat dan konsisten.

Satu putaran melalui siklus dapat memakan waktu dua puluh menit atau tiga hari. Satu putaran dapat mengandung sub-siklus, dan bagaimana waktu terbagi di antara fase-fase tersebut sangat bervariasi tergantung pada tugasnya.

Panduan lengkap tentang siklus ini dapat ditemukan di bawah dalam Deep Dive: Jalankan Siklus.

Konsep 2: Context window adalah sumber daya yang langka

Bersikap deliberat terhadap context window adalah kebiasaan dengan hasil tertinggi.

Apa itu context window?

Model bersifat stateless. Chat bukan sesi yang berjalan dengan memori: setiap giliran mengirim ulang semua pesan sebelumnya dan menambahkan jawaban baru di akhir. Context window adalah jumlah maksimum input yang dapat diterima model dalam satu giliran tersebut. Di Bob V2, jumlahnya adalah 270k token (pengelolaan context window).

Window sudah mulai terisi sebelum pesan pertama:

Dimuat di awal: Prompt sistem Bob, deskripsi mode yang aktif, agents.md repositori, dan deskripsi setiap alat Model Context Protocol (MCP) yang terhubung (MCP di Bob).
Ditambahkan selama sesi, secara tidak terlihat: pembacaan file, hasil tool, file skill yang ditarik Bob, output subagent.

Context window terisi dan dipadatkan menjadi ringkasan

Ketika window terisi, Bob memadatkan percakapan. Bob menggantikan percakapan sejauh ini dengan sebuah ringkasan, dan pekerjaan dilanjutkan. Hal ini menjaga sesi tetap aktif, dan sifatnya lossy by design. Bob secara otomatis menentukan detail mana yang bertahan, dan tidak ada yang menandai yang tidak bertahan. Sesi yang telah dipadatkan dua kali berjalan berdasarkan ringkasan dari ringkasan.

Satu panggilan MCP dapat mengembalikan puluhan ribu token, dan serangkaian pembacaan file mengencerkan apa yang dibahas sebelumnya dalam sesi. Deskripsi mode, file rules, dan MCP server melakukannya lebih lambat dan kurang terlihat. Bob memecah window berdasarkan sumber, dan layak untuk membuka rincian tersebut kembali seiring berkembangnya pengaturan.

Indikator context window Bob, diperluas untuk menampilkan sesi saat ini yang dipecah berdasarkan sumber

Bobcoin terutama dihitung berdasarkan per-token. Jadi biaya percakapan tumbuh secara kuadratik sesuai panjangnya. Percakapan yang lebih panjang menghabiskan jauh lebih banyak Bobcoin daripada percakapan singkat! (dokumentasi Bobcoin)

Bekerja bersama context window, bukan melawannya

Bagi pekerjaan ke dalam percakapan terpisah. Satu tugas, satu sesi. Alasannya sama seperti single responsibility dalam kode. Sebuah percakapan harus memiliki satu alasan untuk ada, seperti "buat diagram arsitektur komponen X" atau "buat rencana implementasi untuk fitur Y." Semua yang ada di context window memengaruhi apa yang terjadi selanjutnya, termasuk pendekatan yang tidak berhasil. Sesi yang macet cenderung tetap macet, karena upaya yang gagal masih ada di sana, dan model membacanya sebagai bukti tentang tampilan tugas ini (context poisoning).
Rollback daripada berdebat dengan Bob. Ketika percakapan menyimpang ke perilaku yang tidak diinginkan, rollback ke pesan terakhir yang baik, ubah pesannya, dan lanjutkan dari sana. Ini juga membatalkan semua perubahan yang dibuat Bob secara lokal, yang menjaga context window tetap kecil dan bersih (rollback).
Simpan apa pun yang berharga dalam file, bukan dalam chat. Rencana, temuan, dan keputusan ada di file. Seorang kolega bisa me-review dokumen markdown dan meneruskannya ke sesi baru; chat log tidak bisa melakukan keduanya.
Subagent menjaga pekerjaan besar keluar dari context window. Bob memutuskan kapan menjalankannya, dan hanya temuan yang dikembalikan. Memintanya secara langsung juga bisa, ketika sebuah tugas akan menghasilkan output yang tidak perlu dibaca siapapun (subagent).
Perhatikan apa yang masuk ke context window dan apakah itu memberikan nilai. Periksa panduan dan sensor kamu secara teratur, seperti yang dibahas dalam topik berikut, dan luangkan waktu untuk memperbaikinya.

Konsep 3: Dua jenis building block — panduan dan sensor

Dalam proyek jangka panjang, apakah codebase menjadi lebih baik atau lebih buruk kurang bergantung pada Bob dibandingkan dengan apa yang membentuk pekerjaannya dan memeriksa hasilnya. Ada banyak building block yang tersedia: rules, skill, mode, hook, subagent, linter eksternal, dan review agent. Hampir semuanya melakukan salah satu dari dua pekerjaan.

Panduan mengarahkan Bob sebelum atau saat bekerja (Feedforward). Rules, skill, dan mode semuanya adalah panduan.
Sensor melaporkan kembali setelah Bob bertindak (Feedback). Pengujian, linter, type checker, sesi browser interaktif, dan review agent semuanya adalah sensor.

Seorang manusia di depan laptop mengarahkan panah ke Bob, dan Bob mengarahkan panah ke kode. Panah berlabel "panduan" masuk ke Bob dari atas, dianotasi dengan rules, skill, dan mode. Panah berlabel "sensor" berjalan kembali dari kode ke Bob, dianotasi dengan pengujian, linter, dan review agent.

1. Panduan

Apa pun yang diberikan kepada Bob untuk mengarahkan pekerjaan adalah panduan. Ada tiga building block utama yang membantu, dan cara kerjanya adalah dengan memasukkan teks ke dalam context window selain prompt yang kamu ketik. Perbedaannya ada pada kapan teks itu tiba dan apa yang memicunya.

Rules selalu aktif, mode diaktifkan oleh pengguna, skill diaktifkan oleh Bob

Rules selalu aktif. agents.md di root repositori adalah yang utama, dan saran utama tentangnya adalah menjaganya tetap singkat. Setiap baris bersaing untuk mendapat perhatian di setiap giliran, sehingga file rules yang panjang membuat Bob kurang mampu mengikuti rule individual mana pun di dalamnya (rules).
Mode diaktifkan oleh pengguna. Mode bawaan adalah: Ask bersifat read-only. Plan bekerja melalui proses perencanaan dan menyerahkan hasilnya ke Agent, yang mengambil tindakan. Mode kustom bisa ditambahkan dengan mudah (mode, menambahkan mode kustom).
Skill diaktifkan Bob ketika dianggap relevan. Hanya deskripsi skill yang singkat yang selalu aktif. Isi utama skill hanya dimuat ke dalam konteks sesuai permintaan. Ini membuat skill sangat efisien dalam penggunaan token (skill).

Semua yang ada di file rules menggunakan token di setiap giliran, terlepas dari apakah giliran itu membutuhkannya, jadi jaga agar tetap minimal dan biarkan sisanya menunggu sampai diperlukan.

2. Sensor

Apa pun yang memberikan umpan balik kepada Bob tentang pekerjaan yang dihasilkan adalah sensor. Sinyal mana yang berguna bergantung pada codebase dan stack, sehingga kumpulan yang perlu dimiliki berbeda dari proyek ke proyek dan membutuhkan kerja nyata untuk dikumpulkan. Sensor yang paling berharga dapat dijalankan oleh mesin dan dieksekusi oleh Bob selama fase implementasi. Sensor dapat dibagi menjadi dua kategori berbeda.

Sensor komputasional bersifat deterministik: pengujian, linter, type checker, compiler. Verdiknya tepat dan dapat diulang, cukup murah untuk sering dijalankan oleh Bob. Cakupannya dibatasi oleh sistem yang dibangun dan dipelihara tim.
Sensor berbasis AI bersifat fleksibel dan non-deterministik. Review agent membaca untuk maksud, dan untuk hal-hal yang tidak ada rule-nya di linter. Hasilnya adalah penilaian, bukan pengukuran. Hasilnya bervariasi antar sesi dan biaya serta durasi membatasi seberapa sering bisa digunakan (code review).

Menghubungkannya memiliki beberapa opsi, dalam urutan hambatan kasar:

Hook adalah opsi deterministik dengan hambatan paling rendah. Sebuah pemeriksaan berjalan pada titik tetap, setiap saat, terlepas dari apakah Bob menganggapnya relevan. Lihat dokumentasi hook.
Skill sering digunakan sebagai panduan, tetapi skill yang menjalankan review adalah sensor, dan merupakan cara dengan hambatan paling rendah untuk menambahkan pemeriksaan non-deterministik. Lihat dokumentasi skill.
Continuous integration (CI) menempatkan review agent dalam pipeline, di setiap pull request, untuk seluruh tim daripada satu developer. Lihat PR review agent beraksi.

Deep Dive: Jalankan Siklus

Batas fase juga merupakan batas konteks, yang merupakan alasan praktis untuk menjaganya tetap berbeda: obrolan eksplorasi tidak ada urusannya berada dalam percakapan di mana kode ditulis.

1. Eksplorasi

Eksplorasi sangat bervariasi tergantung pada peran dan tugas yang dihadapi. Bisa berarti orientasi ke codebase baru atau memperkirakan blast radius untuk refactoring besar. Beberapa contoh:

Minta Bob membuat diagram arsitektur sistem yang ada sebelum mengubah apa pun. Lihat tutorial menghasilkan diagram arsitektur, atau hal yang sama dalam video.
Minta panduan getting-started yang disesuaikan dari dua sudut pandang, sekali sebagai pengguna yang menjelajahi produk dan sekali sebagai developer yang menjelajahi kode. Memberikan informasi tentang keahlian dan tugasmu membantu menyesuaikan dokumen (memeriksa codebase).
Di IBM Z dan IBM i, gunakan opsi spesifik platform. Masalah eksplorasi di sistem tersebut berbeda dan sangat diuntungkan dari tooling khusus yang disediakan dalam paket premium. Lihat Premium Package untuk Z (docs) dan Premium Package untuk IBM i (docs).

Eksplorasi juga dapat mencakup membangun sesuatu yang kamu niatkan untuk dihapus. Implementasi kini murah, sehingga prototipe sempit adalah cara tercepat untuk mengetahui apakah sebuah pendekatan bertahan saat bersentuhan dengan codebase. Kent Beck menyebut ini spike implementation dua puluh lima tahun lalu, dan disiplinnya sama: bangun untuk belajar sesuatu, pertahankan pelajarannya, buang kodenya.

Implementasi yang murah meningkatkan nilai arsitektur dan kualitas kode daripada menurunkannya. Sekarang mudah untuk menghasilkan banyak kode yang berfungsi tetapi salah.

2. Perencanaan

Fase perencanaan adalah tempat leverage terbesar berada. Semua yang berhasil direncanakan membayar dua kali: sekali dalam implementasi, dan sekali lagi ketika perubahan meninggalkan tangan penulisnya dan seorang kolega harus me-review-nya.

Yang dibutuhkan rencana yang baik:

Singkat dan tepat, keduanya. Rencana perlu dibaca.
Eksplisit tentang hasil yang diinginkan, termasuk bagian yang tidak pasti. Mengetahui apa yang tidak diketahui adalah sebagian besar pekerjaan, dan mencari tahu adalah sisanya.
Dalam sebuah file. Rencana tidak boleh tinggal dalam sesi chat.

Ada banyak cara untuk membuat rencana, tetapi Plan mode bawaan adalah tempat termudah untuk memulai (seperti dalam tutorial ini). Plan Mode dirancang untuk mudah setuju dan cenderung mengisi kekosongan. Meskipun ini memungkinkan iterasi cepat dalam banyak kasus, terkadang diperlukan ketelitian lebih. Mode ini mungkin membangun rencana yang kompeten berdasarkan asumsi yang salah tanpa menantang asumsinya. Skill khusus yang mendebat rencana — grill-me oleh Matt Pocock misalnya — adalah cara termurah untuk mendapat pengawasan sebelum asumsi menjadi kode.

Tentang spec-driven development (SDD). Istilah ini mencakup banyak hal dan masih berkembang. Orang memperlakukannya sebagai keputusan ya-atau-tidak, tetapi lebih mendekati spektrum:

Spec-first: rencana datang sebelum implementasi. Ini hampir tidak bisa ditawar.
Spec-anchored: spec tetap ada setelah implementasi, sebagai dokumentasi dan sebagai standar yang harus dipenuhi implementasi.
Spec-as-source: spec adalah file sumber. Manusia mengedit spec; manusia tidak mengedit kode.

Level mana yang cocok bergantung pada tim, tingkat kekritisan/kematangan codebase, dan industri. Overhead yang menyertai level SDD yang lebih tinggi bisa menyakitkan untuk iterasi cepat. Dalam otomotif, di mana spec-driven development mendahului AI beberapa dekade, SDD sangat cocok dengan praktik yang sudah ada.

3. Implementasi

Implementasi adalah fase yang mudah, dan Bob menangani hampir semuanya.

Mengamati Bob bekerja dan menyela untuk mengklarifikasi bersifat opsional dan sering kali berguna. Perlakukan frekuensinya sebagai sinyal: menyela terus-menerus berarti masalahnya ada di rencana, dan solusinya adalah kembali daripada terus memperbaiki.

Jangan ragu untuk membuang seluruh implementasi dan kembali ke Plan mode. Kode adalah bagian yang murah.

4. Verifikasi

Verifikasi terbagi dalam dua kategori berbeda: verifikasi otomatis dan verifikasi manual.

Verifikasi otomatis didorong oleh sensor yang tersedia bagi Bob atau yang dipaksakan melalui hook. Sensor tersebut dieksekusi secara sering selama fase implementasi tanpa campur tangan manusia. Kategori utama dengan beberapa contoh umum adalah:

Validitas: Apakah bisa dikompilasi, typecheck, parse?
- Terukur: pass/fail, type coverage
- Alat: tsc, mypy, cargo check, javac
Perilaku: Apakah melakukan hal yang benar?
- Terukur: pass rate, branch coverage
- Unit test, Integration test, End-to-end test
- Alat: pytest, Jest, Playwright, Stryker
Maintainability: Apakah kode ini layak dipertahankan?
- Terukur: kompleksitas, duplikasi, pelanggaran batasan
- Alat: ESLint, Ruff, Lizard, ArchUnit
Keamanan: Apakah kode ini aman?
- Terukur: temuan berdasarkan tingkat keparahan, CVE
- Alat: Semgrep, CodeQL, gitleaks, npm audit

Sensor-sensor ini memungkinkan Bob menangkap kesalahannya sendiri dan meningkatkan kualitas selama fase implementasi. Cakupan pengujian yang baik adalah perlindungan penting terhadap regresi: memastikan Bob tidak merusak apa pun.

Dalam siklus ini, verifikasi tercantum sebagai fase terpisah di akhir loop, yang terutama mengacu pada verifikasi manual. Verifikasi manual dimulai dengan menjalankan perubahan dan membandingkan perilaku yang diamati dengan perilaku yang ditentukan dalam rencana. Ketidaksesuaian sebagian besar menyempit ke salah satu dari dua penyebab:

Implementasi menyimpang dari rencana. Perbaikannya ada di kode.
Rencana tidak mencerminkan apa yang kamu niatkan untuk dibangun. Rencana perlu diperhalus. Ini jauh lebih umum.

Pemeriksaan manual oleh karena itu menguji rencana dan implementasi secara bersamaan.

Verifikasi tambahan harus terjadi dalam pipeline CI/CD. Ini adalah praktik yang sudah mapan dalam software engineering, tetapi dapat ditingkatkan dengan menggunakan coding agent tanpa kepala. Satu contoh: review otomatis pada setiap pull request, berjalan melalui Bob Shell, melengkapi reviewer manusia daripada menggantikan mereka. Lihat video PR review agent beraksi dan dokumentasi untuk menjalankan Bob Shell secara non-interaktif.

Bekerja dalam tim

Semua hal dalam bagian sebelumnya menggambarkan inner loop satu developer. Outer loop dimulai ketika perubahan masuk ke antrian review. Setiap diff kini tiba lebih cepat dan dengan lebih sedikit alasannya yang terlampir, sementara reviewer memiliki lebih banyak untuk dibaca dan lebih sedikit konteks untuk membacanya.

Bukti harus mengikuti pekerjaan. Mengapa lebih penting dari sebelumnya, relatif terhadap bagaimana, karena bagaimana bukan lagi bagian yang mahal untuk diproduksi.

Dalam praktiknya, ini berarti rencana mengikuti perubahan: tim melampirkannya ke pull request atau menambahkannya kembali ke issue asli bersama dengan review. Mekanismenya bergantung pada tooling.

Apa yang dilakukan outer loop pada proses tim adalah subjek tersendiri, dan akan dibahas dalam posting berikutnya.

Beberapa pemikiran tentang prompting

Dalam beberapa tahun terakhir, ada penekanan besar pada cara memrompt LLM dengan benar, hingga muncul kategori pekerjaan "prompt engineer". Saat ini, banyak prompting yang ditangani di dalam harness. Pentingnya teknik prompting khusus telah berkurang mendukung pendekatan metodologis. Berikut beberapa panduan:

Iterasi mengalahkan prompting. Ketika Bob melakukan sesuatu selain yang kamu minta, rollback dan tulis ulang pesan yang menyebabkannya. Memperbaiki ke depan meninggalkan jawaban yang salah, keluhan tentangnya, dan percobaan ulang semuanya di dalam window.
Metodologi mengalahkan prompting. Prompt terbatas pada satu sesi. File rules, atau pemeriksaan yang dapat dijalankan Bob sendiri, terus bekerja di setiap sesi setelah sesi yang menghasilkannya, yang merupakan satu-satunya jenis investasi di sini yang terakumulasi.
Berikan Bob brief yang akan didapat seorang senior engineer. Seorang kolega yang kompeten yang diberi tugas samar akan bertanya apa yang dianggap selesai dan apa yang boleh mereka sentuh; Bob tidak akan bertanya, jadi masukkan keduanya dalam pesan.
Katakan apa yang harus dilakukan, bukan apa yang tidak boleh dilakukan. "Jangan gunakan class component" mengesampingkan satu opsi dan membiarkan sisa ruang terbuka, sehingga Bob memilih dari apa pun yang tersisa, yang merupakan tebakan lain. Menyebutkan targetnya — function component dengan hook — menutupnya dalam satu giliran.
Instruksi apa pun yang diberikan lebih dari dua kali termasuk dalam file. Itulah kegunaan agents.md dan skill.
Instruksi prompting yang lebih detail dapat ditemukan dalam tutorial menulis prompt yang efektif.

Poin-poin utama

Ketiadaan struktur adalah masalah terbesar. Mengikuti siklus Eksplorasi → Perencanaan → Implementasi → Verifikasi membantumu tetap fokus dan mencapai tujuan dengan lebih cepat dan konsisten.
Konteks adalah sumber daya yang langka, dan fase adalah batas konteks. Jangan bawa obrolan eksplorasi ke dalam implementasi.
Rencana adalah artefak review. Me-review rencana lebih baik dari me-review diff, baik bagi penulis maupun reviewer.
Apa pun yang berharga dikeluarkan dari chat. Rencana, keputusan, dan temuan ada di file. Kamu bisa diff, review, versioning, dan meneruskan file ke agent lain.
Verifikasi harus dapat dijalankan oleh mesin, yang berarti kamu harus merancangnya selama perencanaan, bukan menemukannya setelahnya.

Sumber dan bacaan lebih lanjut

Simon Willison, Agentic engineering patterns
Birgitta Böckeler, Harness engineering

Dokumentasi dan tutorial IBM Bob: