Hermes dalam Praktik: Brief, Kontrol, Review

Brief yang baik = otomasi yang tidak mengejutkan

Kualitas otomasi Hermes ditentukan sebelum kamu menekan enter — di brief. Struktur brief yang terbukti:

1. Konteks: file/folder/data apa yang relevan (jangan biarkan ia menebak).
2. Tujuan: hasil akhir seperti apa — format, tempat penyimpanan, panjang.
3. Batas: apa yang TIDAK boleh disentuh, berapa lama maksimal, kapan harus berhenti bertanya.
4. Definisi selesai: "selesai" itu apa persisnya? Satu paragraf, bukan vibes.

Pagar keselamatan yang layak dipasang

• Sandbox direktori — jalankan di folder kerja khusus; yang di luar itu read-only.
• Approval untuk aksi destruktif — hapus/kirim/kirim-email harus lewat konfirmasi.
• Log yang bisa dibaca manusia — apa yang ia lakukan, urutan, dan keputusan yang diambil.
• Kunci API terpisah per agen — mudah dicabut, mudah diaudit.

Ritual review hasil

Jangan hanya mengecek output akhir — baca log jalannya. Dua alasan: (1) menangkap aksi aneh sebelum jadi kebiasaan; (2) log adalah materi belajar terbaik untuk menulis brief lebih baik minggu depan.

Duet yang sudah terbukti

Kombinasi yang dipakai banyak builder: Hermes untuk eksplorasi/otomasi teknis, Claude Code untuk menulis kode — keduanya sama-sama CLI, mindset-nya saling melengkapi. Hermes menyiapkan riset dan bahan; Claude Code men-shipping alatnya.

Latihan terstruktur

Berikan Hermes satu tugas mingguanmu yang paling membosankan — dengan brief 4 bagian di atas. Setelah selesai, nilai: menit berapa yang benar-benar tersimpan? Catat — itu angka yang akan kamu akumulasikan sepanjang tahun.

Otonomi tanpa review itu risiko. Otonomi dengan review itu compound interest waktu.