Merancang Context Loading yang Efisien untuk AI Coding Assistant

Ditulis oleh : adigarst, 30 Juli 2026

Daftar isi

Bagaimana Mengurangi Pemborosan Token Tanpa Mengorbankan Pemahaman Proyek

AI coding assistant seperti Claude Code, Codex, Cursor, dan berbagai agent berbasis LLM dapat mempercepat proses pengembangan aplikasi secara signifikan.

Namun, ketika proyek mulai membesar, muncul sebuah masalah yang sering tidak terlihat pada tahap awal:

Semakin besar proyek, semakin banyak konteks yang harus dibaca oleh AI sebelum bisa mulai bekerja.

Pada proyek kecil, kita mungkin cukup memberikan satu file instruksi, beberapa dokumentasi, lalu meminta AI mengerjakan sebuah fitur.

Tetapi seiring waktu, proyek biasanya mulai memiliki:

dokumentasi arsitektur,
aturan coding,
business rules,
struktur database,
keputusan teknis,
dokumentasi setiap modul,
prosedur deployment,
panduan testing,
catatan keamanan,
dan berbagai informasi lainnya.

Masalahnya, tidak semua informasi tersebut relevan untuk setiap pekerjaan.

Ketika AI harus membaca semuanya setiap memulai sesi, kita menghadapi beberapa konsekuensi:

Penggunaan token menjadi lebih besar.
Waktu orientasi agent menjadi lebih lama.
Informasi penting mudah tenggelam di antara informasi yang tidak relevan.
Risiko instruksi saling bertentangan meningkat.
AI bisa kehilangan fokus terhadap pekerjaan yang sedang dilakukan.

Artikel ini membahas sebuah pendekatan untuk mengatur konteks proyek secara bertingkat, sehingga AI hanya membaca informasi yang benar-benar diperlukan.

Konsep utamanya sederhana:

Jangan memuat seluruh pengetahuan proyek sejak awal. Muat konteks secara bertahap berdasarkan kebutuhan.

Masalah Context Loading pada Workflow AI Coding

Bayangkan kita memiliki proyek aplikasi yang cukup besar.

Di dalamnya terdapat beberapa dokumen seperti:

CLAUDE.md
architecture.md
database-schema.md
security-guidelines.md
api-conventions.md
deployment-guide.md
testing-guide.md
module-auth.md
module-payment.md
module-notification.md

Cara paling sederhana adalah meminta AI membaca semua file tersebut sebelum mulai bekerja.

Workflow-nya menjadi seperti ini:

Agent memulai sesi
↓
Membaca instruksi utama
↓
Membaca seluruh dokumentasi
↓
Mencari file yang berkaitan
↓
Membaca source code
↓
Memahami konteks
↓
Mulai mengerjakan task

Pendekatan ini memang memberikan konteks lengkap, tetapi tidak selalu efisien.

Ketika task-nya hanya memperbaiki tombol pada halaman tertentu, apakah AI benar-benar perlu membaca dokumentasi deployment, sistem pembayaran, struktur notifikasi, dan seluruh keputusan arsitektur?

Kemungkinan besar tidak.

Yang sebenarnya kita butuhkan adalah mekanisme seperti ini:

Agent memulai sesi
↓
Membaca instruksi global yang ringkas
↓
Mengidentifikasi konteks task
↓
Mengambil aturan dan dokumentasi yang relevan
↓
Membaca source code terkait
↓
Mulai bekerja

Perbedaannya terlihat kecil, tetapi pada proyek besar dampaknya bisa sangat signifikan.

Kesalahpahaman tentang Memecah CLAUDE.md

Salah satu ide yang cukup alami adalah memecah satu file CLAUDE.md besar menjadi banyak file Markdown kecil.

Contohnya:

CLAUDE.md
docs/
├── architecture.md
├── security.md
├── database.md
├── testing.md
└── deployment.md

Kemudian CLAUDE.md dijadikan semacam index:

@docs/architecture.md
@docs/security.md
@docs/database.md
@docs/testing.md
@docs/deployment.md

Struktur tersebut memang jauh lebih rapi untuk manusia.

Namun, berdasarkan dokumentasi Claude Code, file yang dimasukkan menggunakan mekanisme @import tetap dimuat ke dalam context window.

Artinya:

Satu CLAUDE.md besar

dan:

CLAUDE.md yang mengimpor banyak file

dapat menghasilkan penggunaan context yang hampir sama.

Memecah file menggunakan @import bermanfaat untuk:

organisasi dokumentasi,
kemudahan maintenance,
pembagian tanggung jawab file,
kenyamanan membaca.

Tetapi bukan untuk mengurangi token.

Kesimpulannya:

@import adalah alat organisasi, bukan mekanisme lazy loading.

Untuk menghemat context, kita membutuhkan mekanisme yang benar-benar hanya memuat informasi ketika diperlukan.

Tiga Mekanisme Lazy Loading di Claude Code

Claude Code menyediakan beberapa mekanisme yang lebih cocok untuk context loading bertahap.

1. Path-Scoped Rules

Claude Code mendukung file aturan di dalam folder:

.claude/rules/

Aturan tersebut dapat diberi frontmatter paths.

Contoh:

---
paths:
  - "app/api/**/*.ts"
---

# API Route Conventions

- Semua input harus divalidasi.
- Response harus menggunakan format standar.
- Error internal tidak boleh ditampilkan kepada user.
- Setiap endpoint sensitif harus memiliki authorization check.

Rule tersebut hanya relevan ketika Claude bekerja dengan file yang cocok dengan pattern:

app/api/**/*.ts

Jika Claude hanya mengedit komponen frontend, rule untuk API tidak perlu masuk ke context.

Contoh struktur:

.claude/
└── rules/
    ├── api-routes.md
    ├── components.md
    ├── database.md
    ├── migrations.md
    └── testing.md

Setiap rule memiliki cakupan path masing-masing.

Path-scoped rules cocok untuk menjawab pertanyaan:

Ketika mengedit jenis file ini, aturan apa yang harus dipatuhi?

Contohnya:

aturan API route,
aturan React component,
aturan database query,
aturan migration,
aturan testing,
aturan server action,
aturan keamanan file tertentu.

Hal penting yang perlu diperhatikan, rule tanpa paths dapat tetap dianggap sebagai instruksi global.

Jadi, jika tujuan kita adalah lazy loading, pastikan aturan tersebut benar-benar memiliki cakupan path yang sesuai.

2. Nested CLAUDE.md

Selain CLAUDE.md utama di root proyek, kita juga dapat menempatkan CLAUDE.md di dalam subfolder tertentu.

Contohnya:

project/
├── CLAUDE.md
└── src/
    └── modules/
        ├── authentication/
        │   ├── CLAUDE.md
        │   └── ...
        ├── payment/
        │   ├── CLAUDE.md
        │   └── ...
        └── notification/
            ├── CLAUDE.md
            └── ...

CLAUDE.md utama berisi aturan yang berlaku untuk seluruh proyek.

Sementara itu, CLAUDE.md di dalam modul payment hanya dibutuhkan ketika agent bekerja di dalam modul payment.

Nested CLAUDE.md cocok untuk menjelaskan:

tanggung jawab modul,
batas modul,
invariant domain,
entry point utama,
hubungan dengan modul lain,
hal-hal yang tidak boleh dilakukan modul tersebut.

Contohnya:

# Payment Module

## Responsibility

Modul ini menangani pembuatan transaksi, komunikasi dengan payment provider,
callback, reconciliation, dan perubahan status pembayaran.

## Boundaries

- Tidak menangani entitlement user.
- Tidak mengirim email secara langsung.
- Tidak mengakses komponen UI.
- Semua komunikasi provider harus melalui adapter.

## Main Entry Points

- createPayment()
- handlePaymentCallback()
- reconcilePayment()

Nested CLAUDE.md menjawab pertanyaan:

Apa fungsi modul ini dan bagaimana batas tanggung jawabnya?

Ini berbeda dengan path-scoped rule.

Path-scoped rule menjelaskan aturan saat mengedit jenis file tertentu, sedangkan nested CLAUDE.md menjelaskan mental model dari sebuah area atau modul.

3. Skills

Tidak semua instruksi perlu aktif setiap saat.

Beberapa instruksi hanya dibutuhkan ketika kita menjalankan workflow tertentu, misalnya:

membuat migration,
menambahkan payment provider,
melakukan deployment,
menjalankan security review,
membuat release,
memperbaiki CI,
memperbarui dokumentasi,
melakukan audit repository.

Instruksi seperti ini lebih cocok dijadikan skill.

Contoh struktur:

.claude/
└── skills/
    ├── deploy-production/
    │   └── SKILL.md
    ├── create-migration/
    │   └── SKILL.md
    ├── security-review/
    │   └── SKILL.md
    └── update-documentation/
        └── SKILL.md

Skill cocok untuk prosedur yang memiliki:

kondisi awal,
urutan proses,
checkpoint,
validasi,
output akhir.

Sebagai contoh, prosedur deployment mungkin mencakup:

Periksa status Git
↓
Jalankan test
↓
Build aplikasi
↓
Buat backup
↓
Deploy
↓
Verifikasi production
↓
Buat laporan

Prosedur ini tidak perlu berada di context setiap kali agent hanya memperbaiki tampilan tombol.

Skill dapat dimuat ketika:

dipanggil secara eksplisit,
atau dianggap relevan dengan task yang sedang dikerjakan.

Dengan demikian, skills menggunakan konsep progressive disclosure, yaitu informasi lengkap baru diberikan ketika benar-benar diperlukan.

Auto Memory sebagai Catatan Pembelajaran Agent

Claude Code juga memiliki mekanisme auto memory.

Secara konseptual, strukturnya menyerupai:

memory/
├── MEMORY.md
├── debugging.md
├── api-conventions.md
├── environment-notes.md
└── testing-notes.md

MEMORY.md berfungsi sebagai index ringkas yang dibaca saat sesi dimulai.

Sementara file topik lain dapat dibaca ketika dibutuhkan.

Pola ini menunjukkan bahwa konsep berikut memang valid:

Index kecil selalu tersedia, detail dibaca on-demand.

Namun, auto memory sebaiknya tidak dianggap sebagai dokumentasi resmi proyek.

Auto memory lebih cocok untuk menyimpan pembelajaran seperti:

command tertentu bermasalah pada sistem operasi tertentu,
test tertentu membutuhkan environment khusus,
kebiasaan lokal dalam repository,
koreksi yang berulang kali diberikan kepada agent,
shortcut atau teknik debugging tertentu.

Auto memory sebaiknya diperlakukan sebagai inbox pembelajaran.

Jika sebuah informasi sudah:

terbukti benar,
berlaku untuk semua anggota tim,
penting untuk konsistensi proyek,
dan perlu menjadi aturan resmi,

maka informasi tersebut sebaiknya dipindahkan ke salah satu tempat berikut:

CLAUDE.md
Path-scoped rule
Nested CLAUDE.md
Skill
Canonical documentation

Memisahkan Instruksi dan Pengetahuan

Salah satu kesalahan yang sering terjadi adalah mencampurkan semua jenis informasi ke dalam CLAUDE.md.

Padahal, tidak semua informasi memiliki fungsi yang sama.

Ada perbedaan antara:

instruksi,
fakta sistem,
prosedur,
hubungan source code,
dan konteks task.

Sebagai contoh:

Semua perubahan status pembayaran harus melalui PaymentService.

Ini adalah invariant atau aturan sistem.

Informasi tersebut cocok ditempatkan dalam rule atau dokumentasi modul.

Namun informasi seperti:

PaymentService berada di file tertentu dan dipanggil oleh empat file lain.

adalah hubungan source code yang dapat berubah sewaktu-waktu.

Jika hubungan tersebut ditulis manual dalam dokumentasi, informasinya mudah menjadi basi.

Untuk jenis pengetahuan seperti ini, knowledge graph dapat membantu.

Memanfaatkan Knowledge Graph dengan Graphify

Graphify adalah tool yang dapat memetakan source code, dokumentasi, PDF, gambar, dan berbagai jenis file menjadi sebuah knowledge graph.

Untuk source code, Graphify menggunakan parsing berbasis AST atau Abstract Syntax Tree.

Dari source code, Graphify dapat menemukan hubungan seperti:

file mengimpor file lain,
fungsi memanggil fungsi lain,
class menggunakan interface,
class mewarisi class lain,
route terhubung ke service,
service terhubung ke database,
test berhubungan dengan modul tertentu.

Hasilnya disimpan dalam beberapa file:

graphify-out/
├── graph.json
├── GRAPH_REPORT.md
└── graph.html

graph.json menjadi indeks hubungan proyek yang bisa ditanya kembali.

Contoh query:

graphify query "Bagaimana alur authentication bekerja?"

graphify query "Apa yang terpengaruh jika struktur user diubah?"

graphify path "CheckoutPage" "PaymentProvider"

graphify explain "PaymentService"

Alih-alih membaca seluruh repository, agent dapat menggunakan graph untuk menemukan bagian yang kemungkinan besar relevan.

Workflow-nya menjadi:

Task diberikan
↓
Agent menanyakan task kepada graph
↓
Graph mengembalikan konsep dan file terkait
↓
Agent membaca file yang relevan
↓
Agent melakukan perubahan

Graphify tidak menggantikan dokumentasi.

Graphify menjawab pertanyaan:

Apa yang berhubungan dengan bagian ini?

Sementara dokumentasi menjawab:

Mengapa sistem ini dirancang seperti ini dan aturan bisnis apa yang berlaku?

Keduanya memiliki fungsi berbeda.

Perbedaan Path Rules dan Knowledge Graph

Path-scoped rules dan knowledge graph sering terlihat mirip, tetapi sebenarnya menyelesaikan masalah yang berbeda.

Path-scoped rule

Menjawab:

Ketika mengedit file ini, aturan apa yang harus dipatuhi?

Contoh:

---
paths:
  - "src/modules/payment/providers/**/*.ts"
---

# Payment Provider Rules

- Semua request wajib memiliki timeout.
- Jangan mencatat credential ke log.
- Response provider harus divalidasi.
- Callback harus idempotent.

Knowledge graph

Menjawab:

File dan konsep apa yang terhubung dengan perubahan ini?

Contoh query:

graphify query "Apa yang terdampak jika callback payment diubah?"

Graph dapat menemukan hubungan:

Callback Handler
→ Payment Service
→ Transaction Table
→ Billing UI
→ Notification
→ Integration Tests

Jadi:

Rules
= bagaimana agent harus bekerja

Knowledge graph
= di mana agent harus melihat

Canonical Documentation Tetap Menjadi Source of Truth

Meskipun knowledge graph sangat membantu, dokumentasi sistem tetap diperlukan.

Ada banyak informasi yang tidak bisa diketahui hanya dengan membaca source code.

Contohnya:

alasan sebuah keputusan dibuat,
business rules,
batasan produk,
kebijakan keamanan,
permission model,
lifecycle sebuah entitas,
risiko yang telah dipertimbangkan,
trade-off arsitektur,
keputusan yang sengaja tidak diimplementasikan.

Informasi tersebut sebaiknya disimpan di dalam canonical documentation.

Contoh struktur:

docs/
└── canonical/
    ├── system-overview.md
    ├── architecture.md
    ├── business-rules.md
    ├── database-schema.md
    ├── security-model.md
    ├── modules/
    └── decisions/

Canonical documentation menjadi sumber resmi yang dapat dibaca oleh manusia dan AI.

Knowledge graph kemudian dibuat dari:

Source code
+
Canonical documentation

Dengan demikian, graph dapat menghubungkan implementasi teknis dengan alasan dan keputusan di baliknya.

Prinsip pentingnya:

Dokumentasi kanonik diedit secara langsung. Graph dan index lainnya dihasilkan secara otomatis.

Enam Lapisan Context Architecture

Setelah memisahkan fungsi masing-masing mekanisme, kita dapat merancang arsitektur konteks dalam enam lapisan.

1. Core Session Context

Media:

CLAUDE.md

Berisi informasi yang harus diketahui dalam hampir setiap sesi:

identitas singkat proyek,
stack utama,
command penting,
source of truth,
larangan global,
aturan Git,
prinsip keamanan,
cara mencari konteks,
format laporan akhir.

CLAUDE.md sebaiknya berfungsi sebagai bootstrap atau bootloader agent, bukan ensiklopedia proyek.

2. Path Context

Media:

.claude/rules/
Nested CLAUDE.md

Berisi konteks yang hanya relevan ketika agent menyentuh bagian tertentu.

Contohnya:

aturan API,
aturan component,
aturan migration,
mental model modul,
batas tanggung jawab domain.

3. Procedural Context

Media:

Skills

Berisi workflow multi-langkah yang hanya digunakan pada situasi tertentu.

Contohnya:

deployment,
release,
security review,
migration,
integrasi baru,
audit repository.

4. Canonical Knowledge

Media:

docs/canonical/

Berisi pengetahuan resmi proyek:

arsitektur,
business rules,
database schema,
API contract,
keputusan teknis,
security model,
dokumentasi modul.

5. Repository Knowledge

Media:

Graphify

Berisi hubungan yang ditemukan atau dihitung dari source code dan dokumentasi:

dependency,
call flow,
import,
hubungan lintas file,
hubungan kode dengan dokumentasi,
kemungkinan area terdampak.

6. Task Context

Media:

Task Context Package

Task Context Package adalah kumpulan konteks yang dipilih secara khusus untuk satu pekerjaan.

Contohnya:

Task:
Tambahkan logout pada menu profil.

Relevant context:
- authentication architecture,
- session lifecycle,
- UI component terkait,
- fungsi sign out,
- security rule,
- test yang relevan,
- acceptance criteria.

Task Context Package dapat dihasilkan dari:

Task
+
Canonical documentation
+
Knowledge graph
+
Relevant rules

Hasil akhirnya adalah context kecil yang sangat spesifik.

Alur Context Loading yang Ideal

Dengan seluruh lapisan tersebut, context loading dapat berlangsung secara bertahap.

CLAUDE.md utama
↓
Identifikasi task
↓
Query knowledge graph
↓
Temukan source code dan dokumentasi terkait
↓
Buka file yang relevan
↓
Path-scoped rules aktif
↓
Nested CLAUDE.md modul aktif
↓
Skill dimuat jika diperlukan
↓
Task Context Package terbentuk
↓
Agent mulai bekerja

Pendekatan ini jauh lebih efisien dibandingkan memuat semua dokumentasi sejak awal.

Kerangka Keputusan: Informasi Ini Harus Diletakkan di Mana?

Berikut checklist yang dapat digunakan setiap kali ada instruksi atau pengetahuan baru.

Masukkan ke CLAUDE.md jika:

informasi wajib diketahui dalam hampir semua sesi,
ketidaktahuan terhadap informasi tersebut dapat menyebabkan kesalahan besar,
isinya singkat dan relatif stabil,
berlaku untuk seluruh repository.

Contoh:

jangan menambah dependency tanpa persetujuan,
dokumentasi resmi berada di docs/canonical,
semua perubahan database harus memakai migration,
jangan pernah mencatat secret,
jalankan test utama sebelum menyelesaikan task.

Masukkan ke path-scoped rule jika:

instruksi hanya berlaku pada pola file tertentu,
aturan dapat dipetakan ke glob path yang stabil,
tidak relevan untuk sebagian besar task lain.

Contoh:

konvensi API route,
aturan React component,
standar migration,
validasi database query,
aturan test.

Gunakan nested CLAUDE.md jika:

informasi menjelaskan satu modul atau domain besar,
seluruh file dalam folder tersebut memerlukan mental model yang sama,
informasi membahas responsibility dan boundary.

Contoh:

tanggung jawab modul authentication,
batas modul payment,
invariant domain order,
entry point utama modul media.

Jadikan skill jika:

informasinya merupakan prosedur multi-langkah,
hanya digunakan pada situasi tertentu,
memiliki checkpoint dan validasi,
dapat dipanggil sebagai workflow.

Contoh:

deploy,
release,
audit keamanan,
membuat migration,
menambahkan provider baru.

Masukkan ke canonical documentation jika:

merupakan fakta resmi sistem,
perlu dibaca manusia dan AI,
menjelaskan alasan, keputusan, atau aturan bisnis,
harus menjadi rujukan jangka panjang.

Contoh:

arsitektur,
business rules,
schema database,
permission model,
keputusan teknis.

Serahkan kepada knowledge graph jika:

informasi dapat dihitung dari repository,
hubungan tersebut sering berubah mengikuti kode,
menulisnya secara manual akan mudah basi.

Contoh:

fungsi mana memanggil fungsi tertentu,
file mana menggunakan sebuah service,
test apa yang berkaitan dengan suatu modul,
route mana terhubung ke database tertentu.

Masukkan ke auto memory jika:

merupakan pembelajaran lokal atau sementara,
belum layak menjadi aturan resmi,
berasal dari pengalaman agent selama bekerja.

Contoh:

command tertentu gagal pada environment tertentu,
fixture tertentu sering terlupakan,
teknik debugging lokal.

Gunakan hook, lint, test, atau CI jika:

aturan harus benar-benar dijalankan,
kegagalannya tidak boleh hanya bergantung pada ingatan AI.

Contoh:

Instruksi:
Jalankan type check sebelum commit.

Enforcement:
Pre-commit hook atau CI menjalankan type check.

Instruksi menjelaskan perilaku yang diharapkan.

Hook dan CI memastikan perilaku tersebut benar-benar terjadi.

Struktur Folder yang Dapat Digunakan

Berikut salah satu contoh struktur yang dapat direplikasi pada berbagai proyek:

project/
├── CLAUDE.md
├── AGENTS.md
│
├── .claude/
│   ├── rules/
│   │   ├── frontend/
│   │   ├── backend/
│   │   ├── security/
│   │   ├── testing/
│   │   └── documentation/
│   │
│   ├── skills/
│   │   ├── deploy/
│   │   ├── release/
│   │   ├── create-migration/
│   │   ├── security-review/
│   │   └── update-documentation/
│   │
│   └── settings.json
│
├── docs/
│   ├── canonical/
│   │   ├── system-overview.md
│   │   ├── architecture.md
│   │   ├── business-rules.md
│   │   ├── database-schema.md
│   │   ├── security-model.md
│   │   ├── modules/
│   │   └── decisions/
│   │
│   └── generated/
│       ├── task-context/
│       ├── summaries/
│       └── indexes/
│
├── graphify-out/
│   ├── graph.json
│   ├── GRAPH_REPORT.md
│   └── graph.html
│
└── src/
    └── modules/
        ├── authentication/
        │   └── CLAUDE.md
        ├── payment/
        │   └── CLAUDE.md
        └── notification/
            └── CLAUDE.md

Struktur ini tidak harus diterapkan secara lengkap sejak hari pertama.

Pada proyek kecil, kita mungkin hanya membutuhkan:

CLAUDE.md
docs/
src/

Ketika proyek berkembang, kita dapat menambahkan:

Path-scoped rules
Nested CLAUDE.md
Skills
Graphify
Task Context Package

Arsitektur konteks sebaiknya tumbuh mengikuti kompleksitas proyek.

Contoh CLAUDE.md sebagai Bootstrap Agent

Berikut contoh sederhana:

# Project Agent Bootstrap

## Project

Aplikasi ini adalah platform manajemen workflow berbasis web.

## Source of Truth

- Source code berada di repository ini.
- Dokumentasi resmi berada di `docs/canonical/`.
- Keputusan arsitektur berada di `docs/canonical/decisions/`.
- File generated tidak boleh diedit secara langsung.

## Core Commands

- Development: `npm run dev`
- Test: `npm test`
- Type check: `npm run typecheck`
- Build: `npm run build`

## Mandatory Rules

- Jangan menambah package tanpa persetujuan.
- Jangan mengubah database tanpa migration.
- Jangan membaca atau menampilkan secret.
- Jangan push sebelum pengujian utama lulus.
- Jaga backward compatibility kecuali task menyatakan sebaliknya.

## Context Loading

Sebelum membaca repository secara luas:

1. Gunakan knowledge graph untuk memetakan konteks task.
2. Baca hanya dokumentasi kanonik yang relevan.
3. Baca source code yang berkaitan dengan task.
4. Muat skill jika task membutuhkan prosedur khusus.
5. Verifikasi keputusan penting terhadap source code atau dokumentasi resmi.

## Task Completion

Laporan akhir harus mencakup:

- perubahan yang dilakukan,
- file yang berubah,
- pengujian,
- risiko,
- status Git.

File ini tidak mencoba menjelaskan seluruh proyek.

Fungsinya adalah memberi tahu agent:

di mana sumber kebenaran berada,
bagaimana cara mencari konteks,
aturan global apa yang wajib dipatuhi,
seperti apa definisi task selesai.

Mengurangi Beban Maintenance

Arsitektur modular memang dapat menghemat context, tetapi juga bisa menciptakan maintenance baru.

Untuk menghindarinya, ada beberapa prinsip yang dapat digunakan.

1. Pisahkan Berdasarkan Tingkat Kestabilan

Sangat stabil
→ CLAUDE.md utama

Stabil per modul
→ Nested CLAUDE.md

Stabil per jenis file
→ Path-scoped rules

Berubah mengikuti source code
→ Knowledge graph

Prosedural
→ Skills

Pengetahuan resmi
→ Canonical documentation

Jangan menaruh hubungan source code yang cepat berubah ke dalam instruksi global.

2. Gunakan Glob Berdasarkan Boundary

Lebih baik:

paths:
  - "src/modules/payment/**/*.ts"

Daripada:

paths:
  - "src/modules/payment/services/payment-service.ts"

Rule berbasis boundary modul lebih tahan terhadap perubahan struktur internal.

3. Hindari Duplikasi

Satu aturan idealnya memiliki satu lokasi utama.

Contohnya:

Aturan global keamanan
→ CLAUDE.md

Aturan keamanan API
→ api-security rule

Security architecture
→ canonical documentation

Security review workflow
→ skill

Jangan menyalin seluruh isi security documentation ke semua tempat.

Cukup letakkan prinsip dan referensi sesuai fungsinya.

4. Audit Secara Berkala

Tidak perlu mengaudit context setiap hari.

Audit dapat dilakukan pada:

akhir sprint,
akhir milestone,
setelah refactor besar,
setelah perubahan struktur folder,
sebelum onboarding agent baru.

Hal yang dapat diperiksa:

apakah CLAUDE.md terlalu panjang,
apakah ada rule yang tidak pernah digunakan,
apakah ada skill yang tumpang tindih,
apakah auto memory perlu dipromosikan menjadi aturan resmi,
apakah graph masih sesuai dengan commit terbaru,
apakah terdapat instruksi yang bertentangan.

Apakah Pendekatan Ini Benar-Benar Menghemat Token?

Jawabannya, ya, terutama pada proyek yang:

berumur panjang,
memiliki banyak modul,
dikerjakan dalam banyak sesi,
menggunakan beberapa AI agent,
memiliki dokumentasi cukup besar,
sering mengalami perpindahan konteks.

Namun penghematannya tidak selalu langsung terlihat pada hari pertama.

Knowledge graph, rules, skills, dan dokumentasi modular membutuhkan investasi awal.

Secara sederhana:

Tanpa arsitektur context:

20 sesi
×
membaca banyak dokumentasi dan source code

Dengan arsitektur context:

1 kali membangun struktur context
+
20 sesi
×
membaca context terpilih

Semakin panjang umur proyek, semakin besar manfaatnya.

Hal yang Perlu Diwaspadai

Knowledge Graph Bukan Sumber Kebenaran

Graph dapat memiliki hubungan hasil inferensi.

Karena itu:

Graph membantu menemukan sumber.
Source code dan dokumentasi resmi tetap menjadi bukti.

Keputusan penting tetap harus diverifikasi.

Graph Dapat Menjadi Basi

Jika source code berubah tetapi graph tidak diperbarui, agent dapat menerima informasi lama.

Solusinya dapat berupa:

incremental update,
Git hook,
CI check,
pencatatan commit SHA,
pencatatan versi graph,
validasi graph terhadap repository HEAD.

Terlalu Banyak Rules Juga Menjadi Masalah

Memecah satu file besar menjadi puluhan aturan kecil tidak otomatis menghasilkan sistem yang lebih baik.

Terlalu banyak rule dapat menyebabkan:

duplikasi,
konflik,
kesulitan menemukan sumber aturan,
maintenance yang berat.

Setiap rule sebaiknya memiliki boundary yang jelas.

Instruksi Tidak Sama dengan Enforcement

Menulis:

Selalu jalankan test.

tidak menjamin test benar-benar dijalankan.

Aturan kritis sebaiknya didukung oleh:

hooks,
CI,
lint,
type checking,
permission,
automated tests.

Kesimpulan

Efisiensi context loading bukan hanya soal memperpendek satu file instruksi.

Masalah sebenarnya adalah menentukan:

informasi apa yang harus selalu tersedia,
informasi apa yang hanya relevan untuk path tertentu,
prosedur apa yang hanya perlu dimuat ketika digunakan,
pengetahuan apa yang menjadi sumber resmi,
hubungan apa yang sebaiknya dihitung otomatis,
dan konteks apa yang dibutuhkan untuk satu task tertentu.

Arsitektur yang saya anggap cukup ideal adalah:

CLAUDE.md
= konteks inti setiap sesi

Path-scoped rules
= aturan berdasarkan file yang sedang dikerjakan

Nested CLAUDE.md
= mental model modul

Skills
= prosedur multi-langkah

Canonical documentation
= sumber kebenaran proyek

Knowledge graph
= peta hubungan source code dan dokumentasi

Auto memory
= inbox pembelajaran lokal

Hooks dan CI
= enforcement

Task Context Package
= konteks terpilih untuk satu pekerjaan

Dengan pendekatan tersebut, AI coding assistant tidak harus mengetahui seluruh proyek sejak awal.

Ia hanya perlu mengetahui:

di mana mencari informasi,
bagaimana memilih informasi yang relevan,
aturan apa yang berlaku,
dan sumber mana yang harus dipercaya.

Tujuan akhirnya bukan sekadar mengurangi token.

Tujuan yang lebih penting adalah membuat AI bekerja dengan konteks yang:

lebih fokus,
lebih akurat,
lebih mudah diverifikasi,
lebih mudah dirawat,
dan lebih konsisten di berbagai sesi.

Saya masih terus mengeksplorasi pendekatan ini dan kemungkinan akan memperbarui artikel ini seiring bertambahnya pengalaman penggunaan di proyek nyata.

Apabila Anda menggunakan Claude Code, Codex, Cursor, atau AI coding assistant lainnya, saya tertarik mengetahui bagaimana Anda mengatur context proyek.

Apakah Anda menggunakan satu file instruksi besar, dokumentasi modular, skills, knowledge graph, atau pendekatan lain?

Silakan bagikan pengalaman, kendala, dan struktur yang Anda gunakan di kolom komentar. Diskusi dari berbagai pengalaman mungkin dapat membantu kita menemukan pola kerja AI-assisted development yang lebih efektif dan efisien.

Referensi

Catatan: Fitur dan perilaku tool AI dapat berubah dengan cepat. Penjelasan teknis dalam artikel ini mengacu pada dokumentasi yang tersedia pada Juli 2026. Periksa dokumentasi resmi terbaru sebelum menerapkan konfigurasi pada proyek produksi.

Salam Berkarya!
Putu Adi.