CS 319 · Pertemuan 2 dari 10

Dewan
dan Konteks

Mengapa satu otak tidak cukup — dan mengapa window 200k bukan berarti harus diisi penuh.

Agenda · 100 menit

Pola dewan: empat varian, tiga mode kegagalan (30')
Context engineering: lima aturan (25')
Studi kasus: keputusan arsitektur Kirana (10')
Di kelas: jalankan debat dewan (25')
Briefing Tugas A2 (10')

Bacaan: bab 4–5

Konsep inti · bab 4

Mengapa satu otak tidak cukup

Satu panggilan memberi Anda

satu perspektif, satu titik buta
kesepakatan-diri: ia menilai PR-nya sendiri
keyakinan yang tak bisa dibedakan dari kebenaran

Dewan memberi Anda

debat: agen spesialis dengan insentif yang berbenturan
isolasi kegagalan: satu pendapat buruk terkalahkan suara
peningkatan terdokumentasi untuk keputusan berisiko tinggi (SWE-Debate, LLM Council)

Filosofi mandor dalam satu baris: tim spesialis yang saling tidak setuju mengalahkan satu suara yang percaya diri. Bukan untuk semua keputusan — untuk yang berisiko tinggi.

Konsep inti · bab 4

Empat varian dewan

Voting

N agen menjawab independen; mayoritas menang. Murah, paralel, membuang pencilan. Untuk klasifikasi, triage, go/no-go.

Spesialisasi

Tiap agen punya peran — arsitek, security, biaya, UX — dan meninjau hanya lewat kacanya. Untuk design review.

Debat

Dua agen atau lebih berargumen di posisi berlawanan lintas ronde, lalu disintesis. Untuk keputusan arsitektur, tradeoff.

Juri + Hakim

Spesialis memproduksi; hakim terpisah (model berbeda) menilai dengan rubrik yang dipin. Pola chairman ala Karpathy. Untuk gerbang kualitas.

Aturan memilih: salah yang murah → satu model. Salah yang mahal → varian mana, dan mengapa? (Anda akan mempertahankannya di A2.)

Mode kegagalan · terdokumentasi, bukan hipotesis

Cara dewan gagal

Groupthink

Semua agen konvergen tanpa debat nyata; sintesisnya apa pun kata yang paling lantang.

Solusi: anonimkan ronde, campur keluarga model.

Persetujuan paksa

Agen meninggalkan posisinya begitu melihat keyakinan rekan.

Solusi: pass pertama independen sebelum apa pun dibagikan.

Ketidaksetujuan berlarut

Ronde tak kunjung konvergen; token terbakar; tak ada yang landed.

Solusi: batas ronde + chairman berwenang tie-break.

Contoh · bisa di-copy-paste

Dewan spesialisasi, satu prompt per node

# reviewer-security.md — satu node dewan spesialisasi
Anda adalah reviewer SECURITY di sebuah dewan. Anda meninjau HANYA
lewat kacamata Anda. Anda tidak memuji. Anda tidak meninjau gaya/performa.

KONTEKS (dikurasi, bukan di-paste mentah):
  - spec.md       (batasan tugas + kriteria penerimaan)
  - api-contract.yaml

OUTPUT (hanya JSON):
  { "verdict": "pass" | "fail" | "needs-revision",
    "criterion_ids": ["AC-3"],          # ikat ke kriteria bernomor
    "reason": "satu paragraf, berbasis bukti",
    "refusal_conditions_triggered": [] }

ATURAN: bukti tidak ada → verdict needs-revision — jangan menebak.
Keluarga model berbeda dari produsen. Tool read-only.

Perhatikan tiga disiplin dalam satu prompt: kacamata (spesialisasi), kriteria bernomor (spec, Pertemuan 3), model berbeda + read-only (maker-checker, Pertemuan 5).

Konsep inti · bab 5

Context engineering ≠ prompt engineering

Window 200k token adalah anggaran, bukan TPA. Context engineering adalah mengurasi apa yang masuk window, apa yang dikompres, apa yang diambil saat dibutuhkan, dan apa yang dibuang.

5 aturan

anggaran: maks 60–80%
hierarki memori: hot → warm → cold
kompak saat limit
scope tool per peran
offload penalaran ke file

Kebusukan konteks

Konteks panjang, basi, tak relevan menurunkan kualitas walau model "cukup memuatnya". Utilisasi adalah tombol kualitas, bukan hanya biaya.

Isolasi sub-agent

Pekerjaan berisik (dump pencarian, log mentah) diserahkan ke sub-agent yang mengembalikan artefak terdistilasi. Window utama tak pernah melihat rawanya.

Contoh · audit yang akan Anda lakukan di A2

Sebelum / sesudah: konteks satu tugas kode

TPA (sebelum)

repo 40 file di-paste utuh (61k token)
3 transkrip chat lama
stack trace kemarin
"Anda adalah pakar senior 10x…" pemanis
tanpa kriteria penerimaan

Utilisasi 96%. Busuk di menit kedua.

Bundle (sesudah)

spec.md — 40 baris, kriteria bernomor
api-contract.yaml — 2 endpoint relevan
db-schema.sql — 3 tabel, bukan 30
satu contoh "selesai" (PR lampau)
tools.yaml — 4 tool ter-scope

Utilisasi 22%. Agen punya segalanya dan tidak lebih.

Studi kasus · bagian 2 dari 10

Pertanyaan monolit Kirana masuk ke dewan

PM ingin "AI memutuskan" apakah CekFaktur harus memecah monolitnya. Satu model menjawab ya, penuh keyakinan — dua kali. Sebagai gantinya, Kirana menjalankan dewan debat beranggotakan empat: Arsitek (pro-pecah), SRE (kontra, kacamata biaya), Security (kacamata kepatuhan), Chairman (sintesis, tie-break).

Bundle-nya: satu halaman data trafik, dua modul paling panas, skema tabel bersama, satu laporan insiden nyata. Total konteks: 9k token.

Hasil: setelah 2 ronde dewan konvergen ke "modularisasi jalur invoicing saja" — posisi yang tak dipegang siapa pun di ronde nol, dan yang benar-benar di-shipping tim. Pass pertama, sendirian: jawaban salah dengan keyakinan total.

Di kelas · 25 menit

Jalankan dewan, rasakan mode kegagalannya

Persiapan

Kelompok 4 orang. Keputusan: "Portal mahasiswa sebaiknya mengganti pengumuman email dengan feed in-app." Kartu peran: PRO (kecepatan shipping), KONTRA (inklusi/aksesibilitas), SECURITY/PRIVASI, CHAIR.

Aturan

Ronde 1: posisi independen, ditulis dalam diam (anti persetujuan paksa).
Ronde 2: pertukaran anonim, lalu revisi.
Ronde 3: chairman mensintesis atau deadlock. Batas 2 ronde sebelum chair wajib memutus.

Debrief: mode kegagalan terdokumentasi mana yang kena kelompok Anda? Groupthink, persetujuan paksa, atau chair yang memutus terlalu cepat?

Tugas A2 · dikumpulkan sebelum Pertemuan 3

Dewan + audit konteks

Bagian 1 — dewan
Ambil keputusan nyata (Anda, tim Anda, atau Kirana). Pilih varian dan pertahankan pilihannya dalam 3 kalimat. Jalankan dewan 3–4 agen (LLM chat apa pun; model berbeda per peran bila bisa). Catat setiap ronde.

Bagian 2 — audit konteks
Ambil percakapan AI terpanjang Anda. Bangun ulang sebagai bundle: apa yang seharusnya masuk window, apa yang hilang, apa yang redundan. Estimasi utilisasi sebelum/sesudah.

Deliverable
Log debat (ronde + verdict JSON) · pembelaan varian 3 kalimat · tabel konteks sebelum/sesudah.

Rubrik
Justifikasi varian 25% · kualitas debat (apakah terjadi ketidaksetujuan nyata?) 35% · kejujuran audit konteks 40%.

Berikutnya: spec dan loop — tempat intent menjadi bisa dicek mesin. Baca bab 6–7.

Dewandan Konteks