Ini adalah post pertama di blog Bob. Tulisan ini dibuat oleh tim yang membangun Bob, untuk para developer yang menggunakannya. Kami akan menggunakannya untuk menjelaskan keputusan engineering, membagikan apa yang kami pelajari saat menghadirkan partner pengembangan AI di dalam codebase nyata, dan sesekali berargumen untuk sebuah posisi. Ini bukan dokumentasi dan ini bukan marketing — jika kamu mencari salah satunya, kami akan arahkan kamu ke tempat yang tepat.

Untuk post pertama kami, alih-alih membahas semua hal yang Bob lakukan, kami ingin melakukan tiga hal:

Melihat beberapa kemampuan inti Bob.
Membagikan sekumpulan tips praktis untuk menyiapkan repository agar Bob bisa bekerja sebaik mungkin.
Menjelaskan bagaimana kami mendekati keamanan dalam tool yang punya tingkat akses seperti ini ke kodemu.

1. Apa yang sebenarnya menghabiskan waktu developer

Model AI modern bisa menulis sebuah function dari deskripsi. Itu sudah benar sejak beberapa waktu lalu, dan itu bukan lagi pertanyaan yang menarik. Pertanyaan yang menarik adalah apa yang terjadi ketika pekerjaannya bukan "hasilkan kode baru" melainkan "ubah sistem yang sudah ada" — menemukan tempat yang tepat untuk membuat perubahan, memahami konvensi yang sudah disepakati tim, menjaga perilaku tetap konsisten lintas file yang sudah berkembang selama bertahun-tahun. Ini adalah sebagian besar bentuk pengembangan perangkat lunak profesional. Bob dibangun untuk jenis pekerjaan ini, dan pilihan desain yang kami jelaskan di bagian lain post ini berangkat dari fokus tersebut.

1.1. Modes: memberi tahu Bob jenis pekerjaan yang sedang kamu lakukan

Bob bukan satu interaksi "lakukan sesuatu yang berguna". Mode saat kamu memulai sesi memberi tahu Bob jenis pekerjaan yang akan kamu lakukan, tool apa yang bisa dipakai, dan seberapa proaktif Bob seharusnya.

Ask — read-only. Cocok untuk “fase eksplorasi”. Bob menjelaskan arsitektur dan logika tanpa membuat perubahan. Gunakan ini saat menyelami sistem legacy atau melakukan sanity check pada logika yang bukan kamu tulis.
Plan — Bob menghasilkan rencana untuk perubahan yang akan kamu buat: file yang perlu disentuh, edge case yang perlu dipertimbangkan, urutan kerja yang disarankan. Outputnya adalah rencana, bukan kode.
Code — untuk benar-benar membuat perubahan. Bob membaca, menulis, dan menguji di dalam proyekmu, mengikuti konvensi dan rule yang sudah kamu tetapkan.
Advanced — memperluas Code mode melalui Model Context Protocol (MCP), memberi Bob akses ke tool dan layanan khusus organisasimu: API internal, database, tooling proprietary.
Orchestrator — untuk pekerjaan multi-langkah yang melintasi mode. Bob berpindah mode sendiri berdasarkan kebutuhan langkah saat ini, dan merupakan pilihan yang tepat untuk pekerjaan lebih besar yang mencampur eksplorasi, perencanaan, dan eksekusi.

Memilih mode yang tepat di awal sesi adalah salah satu cara termurah untuk mendapatkan output yang lebih baik. Kebiasaan yang bagus, terutama pada codebase yang belum kamu kenal atau perubahan yang punya permukaan kerja cukup luas, adalah memulai di Ask atau Plan lalu baru berpindah ke Code setelah kamu punya gambaran yang jelas tentang pekerjaannya. Langsung masuk ke Code terasa lebih cepat saat itu juga, tetapi di situlah asumsi cenderung lolos menjadi perubahan nyata lalu menumpuk menjadi technical debt.

1.2. Bob tips: metrik kompleksitas, secara real time

Kita semua pernah mengalaminya: kamu sedang sangat fokus, menambahkan satu conditional terakhir untuk menangani edge case, dan tiba-tiba satu function tumbuh menjadi labirin tiga puluh baris. Dalam workflow biasa, labirin itu baru terurai saat rekan setim menunjukkannya di pull request beberapa jam kemudian. Bob Tips mengubah narasi itu dengan menawarkan proposal refactoring saat logikanya masih segar di pikiranmu. Saat kamu mengetik, analisis statis berkelanjutan diam-diam memantau file yang sedang terbuka. Ketika sebuah function melewati batas kompleksitas siklomatik tinggi atau menjadi sulit dirawat, Bob langsung menandainya dengan garis bawah ungu. Linter tradisional hanya memberi tahu bahwa kamu melakukan sesuatu yang salah; Bob Tips memberi jalan keluarnya. Fokus tool ini sepenuhnya pada penyampaian proposal refactoring yang bisa langsung ditindaklanjuti:

Contextual Intelligence: Mengarahkan kursor ke garis bawah ungu tidak hanya menampilkan peringatan—itu juga menawarkan strategi spesifik yang dihasilkan AI untuk mengurai logika tersebut saat itu juga. Seamless Execution: Mengklik Fix with Bob langsung membuka chat khusus. AI sudah memegang konteks function tersebut dan siap menjalankan pembersihan bersamamu.

Metrik yang berjalan di background hanyalah plumbing. Bagian yang bernilai adalah bahwa sinyal kualitas kode yang sudah lama dikenal sekarang memicu saran AI tepat saat developer sedang ada di file itu, alih-alih baru muncul dalam code review tiga hari kemudian.

1.3. Review mode: code review, dengan sistem ikut membaca

Code review telah berkontribusi pada kualitas perangkat lunak sebesar praktik apa pun dalam dua dekade terakhir, dan itu juga tempat tim kehilangan momentum. Bob tidak menggantikan human review. Bob mengerjakan bagian-bagian yang mekanis, sehingga mereka bisa fokus pada arsitektur tingkat tinggi dan niat perubahan alih-alih memburu bug "low-hanging".

Review dijalankan dari Review Panel di sidebar atau lewat /review di chat. Ada dua mode:

Branch comparison. Mode ini menangani diff "klasik". Gunakan /review untuk mengaudit pekerjaan yang belum di-commit terhadap head saat ini, atau /review <branch> untuk menargetkan remote tertentu. Ini adalah langkah pencegahan terhadap "nitpick" yang biasanya memenuhi thread review.
Issue coverage. /review <issue-url> --issue-coverage memvalidasi bahwa perubahan lokalmu benar-benar menjawab apa yang diminta issue GitHub. Ini adalah mode yang menurut developer tidak mereka sadari mereka butuhkan sampai mereka mencobanya. Temuan muncul di panel khusus, sehingga kamu bisa meninjaunya lalu memutuskan memperbaikinya dengan Bob. Ini adalah sanity check yang memastikan kamu bukan hanya menulis kode yang bagus, tetapi juga kode yang tepat.

1.4. Literate coding: niat, ditulis di sebelah kode

Saat kamu sedang dalam fitur yang kompleks, merujuk banyak file di jendela chat adalah pekerjaan yang merepotkan. Kamu mendapati dirimu mengetik "Lihat interface di types.ts dan service di api.ts, lalu perbarui logikanya di sini..." Bob membalik dinamika ini. Dengan memindahkan interaksi langsung ke source file melalui Literate Coding, editor itu sendiri menjadi antarmuka. Ini bukan sekadar menghindari side-panel; ini soal memberi AI peta niatmu yang canggih dan lintas file.

Express Intent Naturally: Aktifkan mode ini dengan Cmd+M lalu tulis logikamu dalam bahasa sehari-hari atau pseudocode. Instruksimu muncul di editor dalam warna biru, tepat di tempat implementasinya seharusnya berada.
Beyond the Single Line: Sementara chat tradisional sering kehilangan "alur" proyek kompleks, literate coding Bob terus berkembang untuk menjembatani jarak antar file. Developer sekarang bisa memberi konteks lintas modul, sehingga perubahan pada model data tercermin dengan akurat di controller terkait.
Immediate Verification: Tekan Cmd+Enter dan Bob menghasilkan implementasi langsung di tempat. Karena hasilnya ditampilkan sebagai inline diff, kamu bisa mengaudit logikanya terhadap kode di sekitarnya sebelum menyetujui perubahan.

Manfaatnya sederhana: prompt berada di tempat kode berada, dengan file di sekitarnya sudah berfungsi sebagai konteks. Cakupan saat ini masih single-file; dukungan multi-file ada di roadmap.

1.5. Bob di terminal

Bob Shell membawa kemampuan Bob ke command line, dan ada dua cara menggunakannya yang menurut kami sangat layak.

The Terminal as a Workspace: Bekerja dengan assistant pengembangan AI di dalam shell telah muncul sebagai bentuk penggunaan yang memang cocok dengan sendirinya — ini berpadu alami dengan cara banyak developer sudah menjalankan Git, build, dan test, dan telah menjadi bagian dari workflow harian banyak tim. Ini adalah cara paling andal untuk membawa AI ke server remote atau lingkungan yang tidak punya integrasi IDE native: Di mana pun kamu punya terminal, kamu bisa punya Bob.
From Deterministic to Adaptive Automation: Bob Shell sangat menonjol dalam sesi non-interaktif seperti scheduled job dan deployment script di pipeline CI/CD. Di mana pun sebuah script saat ini memanggil tool deterministik, script itu bisa memanggil Bob dengan konteks penuh repository di sekitarnya — dan automasi yang dihasilkan menjadi lebih adaptif daripada pipeline yang tetap.

Kami akan menerbitkan post lanjutan tentang apa yang kami pelajari saat menjalankan Bob secara non-interaktif di CI: pola-pola yang bekerja baik dalam praktik, termasuk ringkasan PR, penandaan risiko, dan integrasi ke automasi yang sudah ada.

2. Buat repository-mu siap untuk Bob

Repository tempat Bob menghasilkan pekerjaan terbaik punya beberapa kesamaan. Tidak ada satupun yang khusus untuk AI — semuanya adalah hal yang sama yang membuat repository nyaman dipakai developer mana pun — tetapi masing-masing memberi Bob lebih banyak hal untuk dimanfaatkan.

Test yang cepat dan andal. Jika npm test (atau yang setara) butuh lima menit atau kadang gagal tanpa alasan, loop iterasi melambat dan sinyal umpan balik menurun. Test di bawah satu menit adalah pengali untuk developer mana pun; untuk assistant AI yang bekerja dalam siklus rapat, itu sangat penting.

Build dan test command yang terdokumentasi. Makefile, bagian scripts tingkat atas di package.json, atau blok README — di suatu tempat Bob bisa menemukan "bagaimana saya menjalankan ini." Tanpanya, Bob harus menyimpulkan, dan di situlah kesalahan masuk.

Style yang bisa dieksekusi. Linter dan formatter yang berjalan saat save atau di CI. Bob menangkap konvensimu dari sini. Rule yang eksplisit dan bisa diperiksa mesin selalu mengungguli konvensi implisit.

File agents.md di root repository. Struktur proyek, file penting, coding standard, hal yang boleh dan tidak boleh dilakukan. Ini adalah satu file dengan leverage tertinggi yang bisa kamu tambahkan untuk bantuan AI. Cara terbaik memikirkannya adalah sebagai CONTRIBUTING.md yang ditulis untuk LLM, bukan untuk karyawan baru.

Dokumentasi arsitektur dalam markdown, di samping kode. Bahkan dokumen singkat pun membantu. docs/architecture.md yang menjelaskan modul dan batas-batasnya membuat Bob bisa menjawab "ini seharusnya diletakkan di mana?" tanpa harus menurunkan desain lagi dari import.

Beberapa hal yang kami pelajari sepanjang jalan:

File rule yang terlalu besar mengurangi sinyal. Setelah beberapa ratus baris, performa model menurun. Pisahkan rule per area — agents.md di root repository, readme.md terlingkup per package — alih-alih menumpuk semuanya ke satu file.
Compound your engineering. Saat kamu selesai mengerjakan sebuah tugas, minta Bob merangkum pembelajaran yang relevan kembali ke file rule atau ke sebuah skill. Repository akan menjadi lingkungan yang lebih produktif seiring kamu memakainya.
Iterate, do not one-shot. Percakapan multi-turn yang secara konsisten menghasilkan perubahan yang tepat akan mengungguli satu prompt panjang yang hanya mencapai delapan puluh persen.

3. Keamanan dan kontrol

Bob punya beberapa lapisan perlindungan yang bekerja bersama-sama, bukan satu guardrail tunggal yang mengerjakan semuanya. Versi singkatnya, cocok untuk post pertama:

Setujui setiap tindakan secara manual, atau auto-approve berdasarkan kelas tool (read-only versus write) setelah kamu memercayai workflow-nya.
.bobignore menjaga Bob tetap keluar dari file yang tidak seharusnya dibaca — credential, artefak hasil generate, apa pun yang sensitif.
Rule kustom menegakkan coding standard pada Bob dengan cara yang sama seperti pada developer.
Checkpoint otomatis membuat pemulihan dari perubahan yang tidak diinginkan menjadi tindakan sekali klik.
Prompt-mu tidak digunakan sebagai data pelatihan!

Auto-approval khususnya layak dipikirkan dengan sengaja. Ini adalah salah satu kontrol utama yang kamu punya atas seberapa banyak Bob bisa lakukan di antara checkpoint bersamamu, dan memperluasnya memang memberi keuntungan produktivitas tetapi juga meminta sedikit lebih banyak pertimbangan darimu dalam menentukan apa yang masuk dalam batas itu dan apa yang tidak. Default yang masuk akal untuk kebanyakan developer adalah mengaktifkan auto-approve untuk tool read-only, membiarkan tindakan write tetap pada approval manual setidaknya selama beberapa minggu pertama, dan sangat berhati-hati pada apa pun yang menjalankan shell command atau menjangkau sistem di luar working tree lokalmu. Kontrol lain dalam daftar ini — .bobignore, rule kustom, checkpoint — dirancang untuk berpadu dengan auto-approval, bukan menggantikannya.

4. Memulai

Install IBM Bob dari website kami, atau install Bob Shell melalui terminal pilihanmu.
Tinjau panduan best practice kami dan baca panduan keamanan kami.
Mulailah dengan tugas nyata — Kamu belajar paling baik saat Bob membantu menyelesaikan masalah nyata.

Links