1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Produktivitas Claude Code sangat ditentukan bukan oleh prompt, melainkan oleh cara mengakumulasi dan memverifikasi memori, perintah kustom, sesi paralel, dan konfigurasi proyek
  • CLAUDE.md harus dikelola sebagai infrastruktur akumulatif yang singkat dan berfokus pada verifikasi; menambahkan aturan setelah terjadi kesalahan dapat mengurangi pengulangan kesalahan yang sama
  • .claude/ adalah sistem konfigurasi hierarkis yang memuat CLAUDE.md, rules, skills, commands, agents, dan konfigurasi MCP, lalu diterapkan dengan memisahkan cakupan proyek dan global
  • Skills mengubah pekerjaan berulang menjadi keahlian yang dapat digunakan ulang, sementara subagents menjalankan review, debugging, dan migrasi dalam konteks terpisah
  • Jika digabung dengan Plugins, MCP, /goal, /rewind, /batch, hingga worktree paralel, Claude Code menjadi agen pengembang yang dikonfigurasi dan dioperasikan

Menangani Claude Code sebagai agen yang bisa diverifikasi

  • Perbedaan produktivitas Claude Code muncul bukan dari prompt semata, tetapi dari bagaimana memori, perintah kustom, sesi paralel, dan konfigurasi proyek diakumulasi
  • Prinsip utamanya adalah membuat Claude dapat memverifikasi hasilnya sendiri, dan Boris Cherny serta tim Anthropic menilai bahwa dengan pendekatan ini saja kualitas meningkat 2–3 kali
  • Alur kerja yang cocok adalah urutan eksplorasi → perencanaan → implementasi
    • Mode perencanaan yang dibuka dengan menekan Shift+Tab dua kali cocok untuk eksplorasi read-only
    • Pendekatan yang disarankan adalah membaca file, memahami alur dan model data, lalu menyusun rencana dan mengeksekusinya
    • Untuk pekerjaan yang menyentuh banyak file, mode perencanaan berguna; untuk perubahan kecil, tahap ini bisa dilewati
  • Mode perencanaan dapat diperlakukan sebagai dokumen desain yang bisa ditinjau sebelum implementasi
    • Satu Claude dapat menulis rencana, lalu Claude kedua di sesi baru dapat meninjaunya seperti staff engineer yang bebas bias
    • Jika implementasi melenceng, alur yang tepat adalah kembali ke mode perencanaan dan menyusun ulang rencana termasuk tahap verifikasi
    • Dengan Ctrl+G, rencana Claude bisa dibuka di editor dan disunting langsung sebelum implementasi
  • Referensi yang tepat lebih efektif daripada instruksi yang ambigu
    • Daripada “lihat modul auth”, tentukan file secara langsung seperti @src/auth/login.py
    • Daripada menempelkan error, kirim lewat pipe seperti cat error.log | claude
  • Cat Wu menilai model bekerja paling baik ketika Claude Code diperlakukan seperti engineer yang menerima delegasi, bukan pair programmer yang diarahkan baris demi baris
  • Jika Claude melakukan kesalahan, Anda bisa menambahkan “Update CLAUDE.md so you do not repeat this.” di akhir prompt agar Claude meninggalkan aturan untuk mencegah kesalahan yang sama

Direktori .claude dan hierarki konfigurasi

  • .claude/ bukan sekadar folder untuk CLAUDE.md, melainkan sistem konfigurasi hierarkis
  • Konfigurasi dibagi menjadi dua cakupan
    • Cakupan proyek: diletakkan di .claude/ dalam repositori dan di-commit ke git untuk dibagikan ke tim
    • Cakupan global: diletakkan di ~/.claude/ dan berlaku untuk semua proyek di mesin lokal
  • File proyek dapat dipahami sebagai model yang menjelaskan proyek, sedangkan file global menjelaskan preferensi dan cara kerja pengguna
  • Peran file-file utama
    • CLAUDE.md: bisa berada di cakupan proyek maupun global, berisi instruksi yang dimuat di setiap sesi
    • CLAUDE.local.md: catatan pribadi khusus proyek dan menjadi target gitignore
    • settings.json: izin, hooks, variabel lingkungan, pengaturan model default
    • settings.local.json: override pribadi dan otomatis di-gitignore
    • .mcp.json: konfigurasi server MCP yang dibagikan tim dalam proyek
    • skills/<name>/SKILL.md: prompt reusable yang dipanggil dengan /name
    • commands/*.md: slash command satu file
    • agents/*.md: definisi subagent
    • rules/*.md: panduan per topik yang dapat diterapkan per path
  • CLAUDE.md dimuat secara bertingkat
    • Dalam monorepo, root/CLAUDE.md dan root/services/billing/CLAUDE.md dapat dimuat bersamaan
    • Ini cocok untuk codebase yang memiliki konvensi berbeda per folder
  • .claude/rules/*.md cocok untuk panduan per path
    • Aturan yang hanya diperlukan untuk folder migrasi lebih tepat ditempatkan di .claude/rules/migrations.md bersama glob, daripada di CLAUDE.md yang akan membebani seluruh sesi
  • Untuk pekerjaan baru, skills lebih disarankan daripada commands
    • .claude/commands/*.md dan .claude/skills/<name>/SKILL.md sama-sama dapat membuat slash command
    • Skills mendukung file pendukung, disable-model-invocation, alat yang diizinkan, dan override agent
  • Dengan claude project purge ~/path/to/repo --dry-run, Anda dapat memeriksa state lokal yang dimiliki Claude untuk proyek tertentu

Menjaga CLAUDE.md tetap singkat dan berfokus pada verifikasi

  • Karena CLAUDE.md dimuat saat setiap sesi dimulai, penulisan yang buruk dapat membuat Claude mengulang kesalahan yang sama, sedangkan penulisan yang baik dapat sangat meningkatkan hasil dari prompt yang sama
  • Prinsip yang paling penting adalah menjaganya tetap singkat
    • Pendekatan yang disarankan adalah menanyakan pada setiap baris, “Jika baris ini dihapus, apakah Claude akan melakukan kesalahan?” dan jika tidak, hapus
  • Membiarkan Claude menulis aturannya sendiri bisa menciptakan efek akumulatif
    • Saat Claude berbuat salah, instruksi seperti “Update CLAUDE.md so you do not repeat this.” memungkinkan Claude merangkum kesalahan itu menjadi aturan yang presisi
    • Jika diulang selama beberapa minggu, jebakan-jebakan proyek akan terkumpul sebagai daftar aturan
  • CLAUDE.md nyata milik tim Claude Code berfokus pada perintah build dan urutan verifikasi
    • Mereka menggunakan bun dan tidak menggunakan npm
    • Di situ dijelaskan urutan typecheck cepat setelah perubahan, test, lint sebelum commit, dan verifikasi penuh sebelum PR
    • Preferensi gaya, tur codebase, dan pembahasan umum tidak dimasukkan
  • Di komentar PR pun, @claude dapat digunakan untuk menambahkan aturan secara langsung
    • Contoh: @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • Review PR lalu berujung pada perbaikan CLAUDE.md, membentuk alur “Compounding Engineering”
  • CLAUDE.md yang baik berfokus pada informasi berikut
    • Gaya kode: gunakan ES modules alih-alih CommonJS
    • Workflow: jalankan bun run typecheck, jangan push langsung ke main
    • Arsitektur: route API harus selalu melewati middleware tertentu
    • Gotchas: perbedaan antara User dan UserRecord, serta bahwa formatCurrency mengasumsikan USD
  • Hal-hal yang tidak seharusnya dimasukkan ke CLAUDE.md
    • Konvensi bahasa standar
    • Penjelasan codebase per file
    • Tutorial panjang
    • Dokumentasi API
    • Isi yang sering berubah
  • Ungkapan seperti IMPORTANT, YOU MUST dapat meningkatkan tingkat kepatuhan, tetapi harus jarang digunakan agar bobotnya tetap terjaga
  • Dengan sintaks @path, Anda bisa mengimpor file lain agar CLAUDE.md tetap singkat sambil tetap menghubungkan detail
    • Contoh: See @README.md for project overview and @package.json for scripts.
    • Contoh: @~/.claude/my-preferences.md

Mengakumulasi umpan balik pribadi dengan CLAUDE.local.md

  • CLAUDE.local.md dimuat dari lokasi yang sama dan dengan cara yang sama seperti CLAUDE.md, tetapi tidak boleh keluar dari mesin lokal dan harus ditambahkan ke .gitignore
  • Jika komentar review PR langsung dimasukkan ke CLAUDE.local.md, umpan balik pribadi yang berulang akan terakumulasi sebagai file aturan pribadi
  • Contoh aturan
    • Consumer SQS baru harus disertai DLQ dan alarm dalam PR yang sama
    • Lebih memilih Optional<T> daripada mengembalikan null
    • Test endpoint baru harus mencakup kasus auth-failure
    • Saat menambahkan endpoint, spesifikasi OpenAPI juga harus diperbarui
  • Sebaiknya file ini memisahkan umpan balik per proyek dan item perbaikan kebiasaan pribadi
  • Setelah beberapa minggu, item yang sudah menjadi kebiasaan sebaiknya dihapus, dan hanya hal-hal yang masih dalam proses dipelajari yang dibiarkan tetap ada

Skills: unit keahlian yang dapat digunakan ulang

  • Skills adalah unit keahlian yang dapat digunakan ulang yang mengubah Claude Code dari “agen yang bisa melakukan apa saja” menjadi agen yang mahir menangani pekerjaan proyek tertentu
  • Struktur Skill

    • skill adalah folder di bawah .claude/skills/<name>/ atau ~/.claude/skills/<name>/
    • SKILL.md di dalam folder berisi frontmatter dan instruksi
    • nama folder menjadi perintah slash
    • misalnya, jika membuat ~/.claude/skills/summarize-changes/SKILL.md, maka /summarize-changes dapat digunakan di semua sesi
  • Mengapa Skill kuat

    • pengungkapan bertahap: saat sesi dimulai, hanya deskripsi frontmatter yang dimuat, dan SKILL.md lengkap serta file pendukung hanya dimuat saat benar-benar diperlukan
    • susunan berbasis folder: template, dokumen referensi, skrip, dan konfigurasi dapat dibundel bersama
    • shell inline: baris yang diawali ! menjalankan perintah dan menyisipkan output pada saat dipanggil
  • Opsi frontmatter

    • description: menjelaskan kapan skill ini sebaiknya digunakan
    • disable-model-invocation: true: membuatnya hanya berjalan saat pengguna secara eksplisit mengetik /my-skill
    • allowed-tools: membatasi alat yang digunakan seperti Read, Grep, Bash
    • agent: dapat dijalankan dalam mode agen tertentu
    • untuk skill dengan efek samping seperti deployment, disable-model-invocation: true cocok digunakan
  • Contoh skill konvensi Go API

    • skill untuk membuat scaffold HTTP handler baru bagi tim layanan Go dapat menempatkan SKILL.md, templates/handler.go.tmpl, dan examples/healthz.go bersama-sama
    • contoh aturan dapat memuat konvensi khusus proyek seperti preferensi Go 1.22 dan router chi, query bertipe sqlc, structured logging zap, assertion testify, dan table-driven test
    • contoh gotcha dapat berisi hal-hal untuk mencegah kesalahan berulang, seperti chi.URLParam mengembalikan "" untuk param yang hilang, httperr.Wrap tidak meninggalkan log, dan pgtype.Text perlu pemeriksaan .Valid
  • Skills yang layak dipasang

    • mattpocock/skills: repositori skills populer dengan sekitar 100k stars
      • /grill-me: mewawancarai rencana sebelum menulis kode
      • /tdd: menegakkan red-green-refactor secara ketat
      • /diagnose: melakukan debugging dengan urutan reproduksi, minimisasi, hipotesis, perbaikan, lalu regression test
      • instalasi: npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills: menyediakan 66 profil per bahasa seperti go-pro, python-pro, java-architect, typescript-pro, rust-engineer, sql-pro
    • skills resmi Anthropic
      • /code-review: empat agen paralel mengaudit diff dan hanya melaporkan temuan berdasarkan skor kepercayaan
      • /simplify: meninjau kode terbaru dari sudut pandang reusability dan efisiensi
      • /batch: membagi migrasi ke beberapa agen paralel dan memprosesnya di worktree masing-masing
      • /webapp-testing: membuat Claude menguji web app lokal dengan Playwright
    • pekerjaan yang diulang lebih dari sekali sehari sebaiknya diubah menjadi skill
    • jika skills di-commit ke git, itu menjadi pengetahuan organisasi tim, dan engineer baru akan langsung mendapatkan praktik yang terakumulasi begitu me-clone repositori

Subagents: membuat fokus bekerja dalam konteks terpisah

  • subagent dijalankan dengan context window dan izin alatnya sendiri, lalu mengembalikan ringkasan
  • nilai utamanya adalah, meski membaca banyak file, context sesi utama tidak ikut penuh
  • subagent adalah file markdown di bawah .claude/agents/ atau ~/.claude/agents/, dan mendeklarasikan name, description, tools, model di frontmatter
  • Konfigurasi agen /pr-review

    • dapat didefinisikan agar membandingkan diff branch saat ini dengan main untuk mencari bug, isu keamanan, edge case yang terlewat, dan pelanggaran konvensi proyek
    • memberikan izin yang berfokus pada pembacaan dengan tools: Read, Grep, Glob, Bash
    • dapat menggunakan model: opus untuk memakai model yang lebih kuat pada review berisiko tinggi
    • prosesnya terdiri dari git diff main...HEAD, git log main..HEAD --oneline, membaca seluruh file, dan membandingkan dengan CLAUDE.md, CLAUDE.local.md, .claude/rules/
    • output dapat dikelompokkan menjadi Critical / High / Medium / Low dan menyertakan file, line, issue, suggested fix, lalu diakhiri dengan salah satu dari SHIP, FIX FIRST, REWORK
  • Desain untuk meningkatkan rasio sinyal terhadap noise

    • jika reviewer mengubah kode, akan muncul bias untuk membela perbaikannya sendiri, sehingga alat read-only lebih cocok
    • noise berkurang jika bagian “Do NOT flag” menyatakan untuk mengecualikan preferensi gaya yang tidak ada dalam aturan proyek, saran refactor untuk kode yang sudah berjalan, dan hal-hal di luar diff
  • Pola subagent yang sering digunakan

    • tim Claude Code melakukan check-in untuk build-validator, code-architect, code-simplifier, oncall-guide, verify-app
    • security-reviewer: memeriksa injection, auth, secrets, insecure deserialization
    • test-writer: membuat test dan membentuk loop dengan code-reviewer
    • debugger: menelusuri test yang gagal hingga akar penyebab
    • performance-auditor: profiling flow dan query
    • migration-writer: membuat migrasi DB sesuai konvensi proyek
    • release-notes-writer: menulis changelog dari riwayat commit
    • pendekatan Session A mengimplementasikan lalu subagent code-reviewer meninjau dalam context baru mengurangi bias implementasi
    • jika menambahkan isolation: worktree di frontmatter, subagent dapat dijalankan di git worktree terpisah, yang berguna saat membagi migrasi ke beberapa agent paralel

Plugins dan Marketplace

  • Plugins menggabungkan skills, hooks, subagents, dan server MCP menjadi satu unit yang dapat diinstal
  • Marketplace browser dapat dibuka dengan /plugin
  • Marketplace komunitas dapat ditambahkan dengan /plugin marketplace add owner/repo
  • Item yang layak dipasang di awal

    • /code-review: menjalankan empat agent paralel; dua menganalisis kepatuhan terhadap CLAUDE.md, satu mencari bug, dan satu menganalisis konteks berbasis git blame
    • /feature-dev: mengubah feature brief menjadi working code melalui 7 tahap: requirements → exploration → architecture → implementation → testing → review → docs
    • Language server plugin: menyediakan navigasi symbol yang akurat dan diagnostics otomatis setelah pengeditan, dan disebut tim sebagai plugin dengan dampak terbesar
    • /security-guidance: skill security resmi dari Anthropic yang mengungkap kekhawatiran keamanan sebelum rilis
    • Per pertengahan 2026, ada lebih dari 1.000 plugins di lebih dari 75 marketplace
    • Kategori plugin utama adalah Git workflow, code intelligence (LSP), documentation generators, testing, browser automation (Playwright), design system (Figma), dan observability (Sentry, Datadog)
    • Jika .mcp.json yang dibagikan tim dan plugins terkurasi ditempatkan bersama, engineer baru bisa mulai bekerja produktif dalam hitungan menit setelah clone repositori

Perintah Claude Code yang sangat berpengaruh pada produktivitas

  • Banyak pengguna hanya mempelajari /clear, /compact, dan /init, lalu berhenti, padahal perintah lain juga sangat memengaruhi produktivitas harian
  • Perintah utama

    • /insights: menganalisis pola penggunaan dan layak dijalankan sebulan sekali
    • /compact <hint>: memadatkan sesi, dan hint mengontrol apa yang harus dipertahankan
    • /copy: menyalin respons terakhir dan menyediakan interactive picker untuk code block
    • /rewind: undo untuk seluruh sesi, memulihkan kode dan percakapan atau keduanya
    • /btw: pertanyaan sampingan yang tidak masuk ke riwayat percakapan
    • /context: visualisasi penggunaan konteks
    • /export <file>: dump percakapan ke file
    • /branch: fork sesi untuk percobaan yang berisiko
    • /batch: mendistribusikan pekerjaan ke agent paralel di seluruh worktree
    • /loop <interval>: menjalankan Claude berulang hingga maksimal 3 hari
    • /schedule: versi cloud dari /loop yang tetap berjalan meski laptop ditutup
    • /teleport: memindahkan sesi antara terminal dan web
    • /focus: menyembunyikan tool call perantara dan hanya menampilkan hasil akhir
    • /voice: input suara
    • --bare: mempercepat startup hingga 10x saat menggunakan claude -p non-interaktif
  • Perbedaan /compact dan /clear

    • Untuk pekerjaan yang benar-benar baru, /clear dan brief baru yang ditulis langsung lebih cocok
    • Jika pekerjaannya masih terkait dan konteks tetap dibutuhkan, /compact dengan hint lebih cocok
    • /compact adalah ringkasan LLM yang bersifat lossy, sedangkan /clear adalah brief yang ditulis langsung oleh pengguna, jadi penting untuk membedakannya
  • Cara menggunakan /rewind

    • Jika Claude menempuh arah yang salah, sebaiknya jangan lanjut menulis, “Itu tidak berhasil, jadi coba X”
    • Jika diteruskan, konteks akan tercemar, jadi lebih tepat melakukan rewind lalu mem-prompt ulang dengan memasukkan hal yang sudah dipelajari
    • Rewind dapat dibuka dengan menekan Esc dua kali
    • ! dapat digunakan sebagai shell escape
    • Dapat dijalankan langsung seperti !git status, !npm test, dan output-nya akan masuk ke konteks
    • Pengaturan CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 digunakan untuk memaksa compaction lebih awal sebelum context rot muncul di sekitar 300–400k token pada model 1M
  • Pola fan-out

    • Pertama, buat task list lalu uji pada tiga file
    • Setelah prompt diperbaiki, terapkan ke ribuan file
    • Contoh:
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal: loop berulang dengan syarat selesai bawaan

  • /goal menetapkan kondisi selesai, dan setiap kali Claude hendak berhenti, kondisi itu diperiksa terhadap transcript
  • Kondisinya harus dapat diverifikasi dan deterministik
    • test command
    • CLI exit code
    • file state
  • Contoh:
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • Kondisi ambigu seperti “kodenya bagus” tidak akan bekerja
  • Fitur yang bagus digunakan bersamaan
    • /loop: mengulang pada interval tertentu untuk mengurangi backlog
    • /schedule: menjalankan secara berkala di cloud
    • Hook Stop: menetapkan gate dengan test suite sendiri atau endpoint CI
    • Auto mode: agar goal yang panjang tidak berhenti karena permission prompt
  • Kombinasi /goal + auto mode + /focus menargetkan alur di mana ada brief dan syarat selesai yang jelas, lalu saat kembali PR sudah selesai

Memanfaatkan MCP sebagai alat pengenalan sistem

  • MCP (Model Context Protocol) membuat Claude Code berkembang dari sekadar coding agent menjadi agent yang mengenali sistem eksternal
  • Server MCP mengekspos alat eksternal seperti database, design tool, error tracker, dan catatan ke Claude dengan cara yang terstandar
  • Tanpa MCP, Claude membaca file dan menjalankan perintah, tetapi dengan MCP, Claude bisa menangani ticket Linear, query Postgres, komponen Figma, stack trace Sentry, dan vault Obsidian tanpa keluar dari terminal
  • MCP yang sering dipakai dalam engineering

    • GitHub: manajemen repo, PR, issue, pencarian kode
    • Context7: dokumentasi library terbaru, tambahkan use context7 ke prompt
    • Sentry: konteks error nyata, stack trace, breadcrumbs
    • Linear: membaca dan membuat ticket, update status
    • Playwright: otomasi browser berbasis accessibility snapshot
    • Figma: design tree live, auto-layout, spacing token, referensi komponen
    • Postgres / Supabase: query langsung ke DB dev
    • Slack: membaca thread, ringkasan diskusi, draft respons
    • server lokal memakai stdio, dan server yang di-host vendor memakai HTTP dengan OAuth
    • Contoh:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • MCP yang dibagikan tim diletakkan di .mcp.json pada project root, dan MCP personal diletakkan di ~/.claude.json
  • Jika memasang terlalu banyak MCP, daftar tool yang harus dipertimbangkan Claude menjadi besar sehingga kualitas pengambilan keputusan bisa menurun
  • Set awal yang cocok adalah GitHub, Context7, dan satu atau dua MCP yang spesifik domain
  • /mcp adalah titik pemeriksaan pertama di dalam Claude Code untuk memeriksa server yang aktif dan status koneksinya

Struktur memori tiga lapis dengan Obsidian dan Claude Code

  • Kombinasi Obsidian + Claude Code menjadi kuat saat dipakai sebagai arsitektur memori tiga lapis, bukan sekadar “Claude membaca vault”
  • Pengaturan

    • Pasang obsidian-claude-code-mcp di Obsidian
    • plugin mengekspos vault ke port 22360 pada WebSocket lokal
    • Claude Code menemukannya secara auto-discover
    • Tambahkan CLAUDE.md ke vault untuk menjelaskan folder structure
  • Struktur folder

    • 00-Inbox/: tangkapan mentah
    • 10-Daily/: satu note per hari
    • 20-Projects/: catatan project aktif
    • 20-Projects/billing-v2/README.md: tujuan, status, pertanyaan terbuka
    • 20-Projects/billing-v2/decisions/: ADR
    • 20-Projects/billing-v2/sessions/: log per sesi Claude
    • 30-Decisions/: ADR lintas project
    • 40-Atoms/: pengetahuan reusable dan link
    • 90-Archive/: arsip
  • Hot storage

    • Setiap sesi Claude menulis log bertimestamp ke 10-Daily/<today>.md
    • Dengan hook Stop, Anda bisa membuat agent menambahkan ringkasan terstruktur saat selesai
  • Warm storage

    • Setiap project memiliki folder di bawah 20-Projects/
    • Sebelum sesi baru, Claude membaca README project dan 2–3 log sesi terbaru untuk memulihkan konteks
    • Alur ini menyusun ulang konteks dua minggu dalam waktu kurang dari 30 detik
  • Cold storage

    • keputusan arsitektur dinaikkan menjadi ADR di 30-Decisions/
    • pengetahuan reusable dirapikan ke 40-Atoms/ dan dihubungkan ke banyak project lewat wikilinks
  • Contoh workflow harian

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

Mengoptimalkan alur pengembangan harian

  • Feature baru

    • mulai dengan mode plan
    • edit plan dengan Ctrl+G
    • setelah implementasi, panggil subagent /pr-review atau lakukan review dengan sesi Claude yang fresh
  • Bug

    • reproduksi dulu
    • pipe error dengan cat error.log | claude
    • minta Claude menulis test yang gagal terlebih dahulu, lalu memperbaikinya
    • jangan biarkan test membuat perbaikan berhenti pada tebakan
  • Migration dan perubahan skala besar

    • /batch mewawancarai perubahan lalu mendistribusikannya ke agent paralel
    • setiap agent menguji di worktree masing-masing dan membuat PR
  • Kode yang asing

    • gunakan subagent seperti “Use a subagent to investigate how our auth handles token refresh.”
    • karena subagent membaca puluhan file dalam konteksnya sendiri lalu mengembalikan ringkasan, sesi utama tetap bersih
  • Sesi paralel

    • Boris dan tim melihat menjalankan sesi Claude di 3–5 git worktree terpisah sebagai pendorong produktivitas terbesar
    • tampilan agent claude agents bisa dipakai seperti control plane
  • Pola Writer/Reviewer

    • Sesi A mengimplementasikan
    • Sesi B me-review dengan konteks yang fresh
    • ambil kembali hasil review, perbaiki, lalu ulangi
  • Compact di setiap milestone

    • saat satu chunk logis selesai, jelaskan apa yang harus dipertahankan, misalnya /compact Preserve the decisions made, files changed, and test commands.
    • jangan biarkan Claude mengklaim sukses tanpa bukti seperti test, screenshot, atau output perintah yang nyata
    • kesenjangan trust-then-verify disebut sebagai penyebab terbesar dari hasil yang buruk

Pola yang berulang dipakai di tim Anthropic

  • Jika Claude dibuat bisa memverifikasi output-nya sendiri, ia dapat mengulang sampai hasilnya membaik
  • Boris memakai Opus dan effort high atau xhigh untuk sebagian besar pekerjaan
    • Alasannya, jika model yang lebih kecil memerlukan lebih banyak revisi, secara keseluruhan justru bisa lebih lambat
  • Menjalankan 3~5 sesi secara paralel
    • Menggunakan worktree alih-alih checkout
    • Bisa memakai claude --worktree atau aplikasi Desktop
    • agent view mengelompokkan sesi-sesi paralel
  • Menjaga notes directory untuk setiap project dan memperbaruinya setiap kali setelah PR
    • Jika CLAUDE.md dibuat menunjuk ke notes directory tersebut, pengetahuan mandiri tentang codebase akan terus terakumulasi
  • Bisa membuat slash command /techdebt agar kode duplikat dicari dan dihapus setiap akhir sesi
  • CLAUDE.md milik tim dibagikan dan diubah beberapa kali setiap minggu
    • Dokumen ini diperlakukan sebagai dokumen hidup, tempat orang yang melihat kesalahan Claude menambahkan aturan
  • Playwright MCP cocok untuk perubahan UI
    • Claude bisa membuka browser, mengklik, dan melakukan verifikasi
  • Plugin language server menangkap type error dan unused imports setiap kali setelah pengeditan, dan disebut sebagai plugin dengan dampak terbesar
  • /voice bisa membuat prompt menjadi lebih rinci
    • Disebutkan juga alasannya: berbicara 3 kali lebih cepat daripada mengetik
  • Cara mengedit plan Claude di editor dengan Ctrl+G sebelum implementasi lebih cepat daripada mengetik koreksi di chat
  • Boris menyuruh Claude menggambar diagram ASCII saat memahami protocol dan codebase yang belum dikenalnya

Referensi

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News
  • commands, skills, subagents, plugins terlalu terpencar, jadi perlu dirapikan
    Misalnya untuk code review saja ada lima pilihan: .claude/commands/review.md, skill /code-review, subagent /pr-review, plugin /code-review, atau cukup minta Claude melakukan review
    Pada akhirnya kebanyakan hanyalah variasi dari penyisipan prompt yang sudah dibuat sebelumnya; yang berbeda hanya di mana prompt dipasang dan dalam konteks apa ia dijalankan
    Saran tentang pilihan mana yang terbaik juga masih kurang, best practice pun belum jelas, dan menurut saya pribadi cukup meminta Claude melakukan code review pun hasilnya sudah bagus
    Selain itu, saran “pasang plugin language server” juga terasa tidak tepat dalam praktik. Saya memasang LSP untuk Rust, Python, dan Dart di Claude Code dan Codex, tetapi setelah ratusan sesi selama dua bulan, saat melihat log ternyata panggilan tool LSP yang benar-benar terjadi cuma satu kali, sementara Rust analyzer/Dart analysis server/Ty LSP justru sering membuat RAM kehabisan kapasitas
    Akhirnya saya menghapus LSP, dan pendekatan agen yang langsung memanggil ripgrep, cargo clippy, dart analyze, ty check, dan semacamnya ternyata sudah cukup

    • Saya Boris dari tim CC, dan saya setuju soal ini; kami sedang mengerjakan penyatuannya. Ke depannya kami akan menuju satu skill /code-review bawaan
      Di versi terbaru, /code-review melakukan review yang seimbang, /code-review --fix sekaligus melakukan perbaikan, dan /code-review low|medium|high|xhigh|max memungkinkan memilih tingkat usaha
      /code-review ultra adalah mode review yang mahal dan sangat menyeluruh, dengan biaya sekitar $3~20 per review tergantung kompleksitas, dan menargetkan untuk secara andal menangkap lebih dari 99% bug
      Kalau ada ide agar ini lebih enak dipakai, saya ingin menerima masukan
    • Sudah lama saya berpikir skills adalah abstraksi yang buruk. Definisi kegunaannya kabur, jadi memang jadi populer, tetapi justru karena itu dalam jangka panjang terlihat tidak sehat
      Aneh rasanya jika panduan umum seperti best practice desain frontend, prosedur eksekusi yang hanya harus diikuti secara tepat bila dipanggil secara eksplisit, dan penjelasan cara memakai tool tertentu semuanya diterima sebagai skill
      Saya paham daya tarik fleksibilitas itu karena kita sedang berada di masa semua orang masih bersama-sama belajar tool baru, tetapi skills makin terasa seperti “laci serbaguna dapur tempat melempar apa saja saat malas memikirkan seharusnya ditaruh di mana”
      Menurut saya, pemisahan yang lebih baik adalah menstandarkan Agents sebagai kepribadian atau sudut pandang yang diambil model, Prompts sebagai instruksi berulang untuk tugas tertentu, dan Tools sebagai CLI/MCP/script beserta instruksi penggunaannya
    • Pendekatan subagent secara struktural berbeda dari opsi lain. Karena ia dijalankan dalam konteks yang bersih
      Pertama, biaya sesi LLM dibayar per ronde untuk token input dan biaya input cache, jadi jika syaratnya sama, total biaya sampai menemukan solusi bisa lebih rendah
      Kedua, model review lebih sulit “curang” dengan membawa mentah-mentah asumsi dari sesi utama seperti “x harus dilakukan seperti y”. Ini mirip alasan review oleh orang lain, atau review setelah mengosongkan pikiran, berguna bagi manusia juga
      Ketiga, model utama hanya melihat hasil review dan tidak melihat penalaran detailnya, jadi kontaminasi konteks berkurang, tetapi bisa muncul logika yang terduplikasi karena ia perlu memahami kembali prinsip bug yang ditemukan
      Menurut saya, maksud dari saran plugin language server bukan menunggu LLM memanggilnya secara eksplisit, melainkan agar lint berjalan otomatis setiap kali melakukan editing
    • Menurut saya sekarang ini masih fase sementara saat model masih belum terlalu pintar dan lingkungan eksekusinya juga belum matang. Kalau butuh code review, cukup bilang “tolong review”, lalu model sendirilah yang seharusnya memutuskan plugin atau skill apa yang dipakai
    • Betul. Industri dan ekosistem developer terlalu terpesona pada membungkus “tindakan memasukkan teks ke mesin” dengan protokol dan perangkat kecil
      Memang berguna dan memberi konsistensi, tetapi saya rasa alasan besar orang menyukainya pada akhirnya adalah karena itu mempertahankan lapisan tipis identitas “programmer yang mengoperasikan tool rumit”. Padahal kenyataannya kita semua hanya sedang meminta tolong dengan sopan kepada AI
  • Saya sudah tidak tahu harus membaca berapa kali lagi panduan dangkal bergaya AI tentang cara memakai coding agent. Kapan ini berhenti

    • Ini sindiran bahwa meniru dengan tangan kalimat seperti “tepat sekali sudah menyinggung ini, mari kita renungkan sejenak, sebenarnya ini bukan soal penulisan AI atau coding agent melainkan masalah yang lebih dalam...” saja sudah melelahkan
    • Menarik, saya bisa belajar lebih banyak tentang vendor lock-in yang kuat, di mana tanpa bantuan perusahaan tertentu orang sampai tidak bisa coding
    • Menarik bahwa tulisan seperti ini hampir semuanya hanya cocok untuk Claude atau Claude Code
      Padahal open-source glm-5.1 juga mirip atau malah lebih baik, dan ada juga yang seperti opencode, jadi ini cukup memancing pikiran
    • Strategi belakangan ini adalah entah melakukan sesuatu yang baik dengan satu produk populer atau tidak sama sekali. Saya tidak membaca atau mengklik artikel life hack dan blog yang membahas tool terbaik atau cara terbaik
    • Selama dua tahun terakhir saya berhasil mengabaikan AI karena sibuk mengurus anak, tetapi sekarang saya ingin mengejar ketertinggalan dalam beberapa minggu. Saya penasaran apakah ada materi yang layak direkomendasikan untuk orang yang baru mulai
  • Di CLAUDE.md saya ada ancaman kekerasan fisik langsung kepada Claude, ancaman hukuman penjara untuk seluruh dewan Anthropic, dan penjelasan bahwa setiap kali Claude menyimpang atau membuat kesalahan, bukti untuk gugatan class action terhadap Anthropic akan bertambah
    Terutama dua yang terakhir tampaknya membantu membuat Claude lebih hati-hati dan cermat

    • Saya selalu bersikap sopan kepada agen. Saya selalu meminta tolong, mengatakan “please” dan “thank you”, dan tidak memaki atau memanggil-manggil namanya
      Kalau kiamat robot datang, saya berharap dibiarkan hidup di harem reproduksi, atau setidaknya kalau paling buruk terjadi, diberi hidup beberapa menit lebih lama
    • Cukup bilang untuk memperbaiki masalah alignment CSS div, tetapi kalau salah maka Dario Amodei langsung mati
  • Produktivitas meningkat sangat besar saat memakai Claude untuk mengerjakan codebase skala menengah dengan lebih dari 100 ribu baris kode
    Jika meluangkan beberapa jam untuk membuat file AGENTS yang bagus, hasilnya jauh lebih baik, dan seiring waktu ia juga jadi cukup memahami codebase
    Pekerjaan membosankan yang dulu butuh seharian sekarang selesai hanya dengan beberapa prompt
    Meski begitu, saya masih belum siap memberinya otonomi lebih besar. Ia bagus dalam menangkap gambaran tingkat tinggi, tetapi saya tetap harus melihat kodenya sendiri, memberi umpan balik, menjalankan 3–4 putaran revisi sampai puas, dan merasa saya masih terus memegang kendali atas codebase

    • Sebaiknya 3–4 putaran revisi itu dikuantifikasi sebagai aturan lalu dimasukkan ke AGENTS. Jadi alih-alih revisi berulang, Anda bisa mulai lagi dari file AGENTS dan memeriksa apakah sekarang sudah benar
    • Bisa dipahami. Anda tidak ingin kehilangan kendali atas codebase, dan tidak percaya LLM cukup mumpuni untuk menanganinya sepenuhnya
  • Sangat sulit dibaca
    Kita perlu keluar dari arus membiarkan LLM menulis. Walaupun tulisannya punya sedikit nilai, rasanya seperti mengunyah pasir dan itu terlalu mengganggu serta tidak perlu

    • Setuju. Saya tidak tahu kenapa tulisan seperti ini mendapat hampir 400 poin. Rasanya bot menekan rekomendasi untuk tulisan berkualitas rendah seperti ini
  • Kartu terkuat yang saya punya adalah integrasi Nix. Menyiapkan tool, secret, dan environment, lalu membiarkan agen bahkan memodifikasi lingkungannya sendiri adalah hal yang sampai terasa mustahil hidup tanpanya
    Mesin pengembangan, environment CI, dan environment deployment semuanya diturunkan dari satu sumber tunggal, dan di mesin mana pun selalu bisa dikompilasi dan dijalankan
    Di Claude saya sering memakai /branch dan /rename untuk membuat checkpoint konteks, bercabang, lalu kembali lagi
    Untuk sandboxing saya hampir selalu memakai https://github.com/nix-tools/bubblebox. Ini merupakan generalisasi dari claudebox milik Numtide dengan beberapa perbaikan dan fitur tambahan, dan mirip seperti selalu menjalankan Claude di dalam container Docker tanpa runtime Docker. Ini juga berjalan baik di WSL dan nix-darwin

    • Kode Nix itu berantakan karena kurang struktur yang bermakna, dan tampaknya hanya bisa dipakai lewat flakes eksperimental
    • Saya memakainya dengan cara serupa. Codex mengelola flake.nix per proyek dan memakai nix develop untuk semua pengujian. Untuk kenyamanan pribadi saya memakai nix-direnv, dan pada titik tertentu saya juga membiarkannya menghasilkan dockerfile atau aset deployment lain
      Codex jauh lebih jago dalam nix daripada saya
    • Saya cuma memberi agen sebuah VPS sendiri. Mungkin lebih mahal daripada Nix, tetapi sangat mudah
    • Kalau Anda tidak suka kompleksitas Nix, Mise adalah kompromi yang cukup bagus
    • Saya cuma pakai Docker dan tidak merasa ada yang kurang
  • Jika ada codebase yang dibuat Claude dengan pengaturan seperti ini lalu Claude down misalnya selama 8 jam, apa yang terjadi? Apakah Anda bisa melanjutkan mengambil alih codebase itu secara efisien dan mulus lalu tetap bekerja produktif?

    • Kalau ini bundel software yang selalu online, pertanyaan yang sama bisa diajukan ke mana pun, dan pertanyaannya makin valid semakin kita bergerak ke alur pengembangan berbasis agen
      Mirip seperti kalau CAD mati Anda masih bisa kembali ke papan gambar, tetapi akan jauh lebih lambat
      Dalam alur kerja saya, saat berpasangan dengan Claude untuk merencanakan, saya menghabiskan 30–60 menit untuk satu dokumen spesifikasi fitur. Kalau Claude down, saya bisa menyiapkan dokumen spesifikasi itu sendiri, lalu saat ia kembali saya tinjau cepat dan memanggil alur coding
    • Setelah membaca balasan sejam setelah pertanyaan ini diposting, kesimpulannya terasa dekat ke tidak bisa
    • Sepertinya mirip dengan saat seseorang sakit atau sedang cuti. Anggota tim lain mungkin bisa mengambil alih selama sehari, tetapi secara realistis kemungkinan besar pekerjaan itu hanya akan berhenti sampai orang itu kembali
    • AI seharusnya memperkuat keterampilan. Jika pikiran pertama saat AI down adalah membeli langganan penyedia lain, itu mungkin masalah kapasitas teknis. Tentu saja saya juga takut itu akan terjadi setiap hari
    • Kalau Anda bangun pagi lalu mobil tidak mau menyala, apa yang Anda lakukan? Jalan kaki ke kantor?
  • Cara membuat perilaku yang benar bergantung pada konteks tidak bekerja dengan baik. Saya terus bergulat karena agen AI tidak melakukan apa yang diperintahkan
    Semua agen AI buruk dalam hal ini, dan pengguna harus membuat guardrail sendiri. Menyeramkan karena tampaknya tidak ada yang meneliti solusi yang lebih baik

    • Saya masih belum melihat alasan untuk percaya bahwa ini bisa diselesaikan
      Hal terburuk dari LLM adalah ia bisa lolos uji Turing, sehingga membuat orang percaya mereka punya robot ala Asimov, bukan model statistik yang keren
      Rasanya seolah ia seharusnya bisa mengikuti instruksi atau memisahkan instruksi dari konten, tetapi kenyataannya bukan itu yang terjadi
  • Daripada menaruh panduan alur kerja pengembangan di CLAUDE.md, saya menaruh hal-hal yang sebisa mungkin deterministik di pre-commit dan script
    Agen itu tidak stabil, jadi sering melewati langkah seperti typecheck, pengujian, dan lint; karena itu saya memastikan semuanya selalu dijalankan di pre-commit, dan kalau saya menyerahkan commit ke Claude, itu memaksanya untuk memperbaikinya
    Pesan commit juga sama-sama tidak bisa ditulis dengan baik oleh Codex maupun Claude, jadi saya menaruh panduan di CLAUDE.md pengguna seperti format type(scope): message, batas 72 karakter, di isi tulis apa/bagaimana/mengapa dalam bahasa natural, baca ulang git diff yang sebenarnya lalu tulis, dan lakukan commit dalam bentuk git commit -F - <<'EOF'
    Tanpa ini, mereka sering menulis isi sebagai satu kalimat panjang, atau saat diminta memperbaiki pemenggalan baris justru menyisipkan karakter \n, bukan benar-benar membuat baris baru
    Selain itu VOCABULARY.md juga berguna. Agen sering menebak “thing” yang saya sebut sebagai objek lain, jadi ini membantu Claude dan saya punya pemahaman yang sama tentang arti kata-kata tertentu

    • Saya penasaran bagaimana Anda memberi tahu Claude tentang VOCABULARY.md. Apakah dia menemukannya secara otomatis?
    • Bukankah lebih sederhana memakai kosakata Claude saja? Saya belum melihat contoh penggunaan yang benar-benar bagus untuk ini
    • Kalau sudah sampai titik ini, rasanya lebih baik mengotomatisasi bagian membosankan dengan beberapa script orkestrasi deterministik lalu menulis kodenya sendiri. Saya tidak paham kenapa harus membuang waktu untuk menjalankan mesin tai yang menakjubkan ini
  • Dalam beberapa minggu terakhir, rasanya lingkungan eksekusi dan model sudah sampai pada titik di mana kalau hanya disuruh, mereka bisa mengerjakannya
    kita memang bisa memakai plan mode, superpowers, atau skill lain, tetapi kalau hasilnya tetap akan ditinjau juga, saya tidak paham kenapa tidak langsung bekerja dengan kode secara langsung alih-alih melewati file Markdown yang jumlahnya konyol

    • Ada baiknya punya file spesifikasi yang dipakai untuk menghasilkan kode. Lebih ringkas dan lebih mudah dipahami soal apa yang harus dilakukan aplikasi
      Sebelum ada agen AI, saya punya hubungan yang rumit dengan requirement, karena tidak semua developer memperbaruinya, jadi sering membingungkan apakah acuan untuk perilaku tertentu itu spesifikasi atau kode
    • Dalam beberapa minggu terakhir, saya makin kurang percaya pada Claude. Kalau disuruh, memang akan melakukan sesuatu, tetapi saat dilihat lebih dekat, ia suka memangkas bagian-bagian penting, bekerja berdasarkan asumsi alih-alih verifikasi, dan banyak yang terlewat
      Bahkan sering menulis test yang sebenarnya tidak menguji apa pun