CS 319 · buku: pangmandorin.kamil.web.id
EN ↗

CS 319 · Pertemuan 5 dari 10

Orkestrasi
dan Verifier

Pola untuk banyak agen — dan satu-satunya hal antara loop Anda dan kegagalan senyap.

Agenda · 100 menit

  1. Empat pola orkestrasi + anti-pattern klasiknya (25')
  2. Disiplin verifier: tiga lapis, maker-checker (25')
  3. Studi kasus: bug yang nyaris terkirim (10')
  4. Workshop desain verifier (30') · briefing A5 (10')

Bacaan: bab 10–11

Konsep inti · bab 10

Empat pola mengoordinasikan agen

Supervisor (paling umum)

Satu orkestrator mendelegasikan ke spesialis dan mensintesis. Alur kerja dewan adalah ini. Saat satu hub bisa memegang seluruh masalah.

Hierarki

Supervisor dari supervisor — pohon berlapis. Saat organisasi melampaui satu hub; jaga span-of-control kecil.

Group Chat

Rekan berdebat bergiliran; sintesis chairman menutupnya (dewan ala Karpathy). Untuk penalaran terbuka, bukan throughput.

Pipeline

Jalur perakitan: spec → implement → review → deploy, artefak mengalir antar tahap. Saat tahap punya tool/model berbeda.

Primitif framework yang tetap Anda butuhkan: state machine · message bus · tool allowlist per peran.

Anti-pattern · dan obatnya

Satu agen mengerjakan lima pekerjaan

System prompt 3000 token

"Anda arsitek DAN backend DAN reviewer DAN penulis DAN DevOps…" Tiap peran mengencerkan yang lain; tiap kapabilitas berarti kontradiksi baru; menilai pekerjaan sendiri sudah terpasang di dalamnya.

Jalur migrasi

  1. tiap bagian peran di prompt → kandidat agen
  2. ekstrak prompt per peran
  3. tambahkan supervisor
  4. definisikan message bus
  5. tool allowlist per peran
  6. tambahkan verifier (selalu terakhir, tak pernah opsional)

Penandanya: "agen" Anda punya sub-judul. Sub-judul adalah spesialis yang memohon diekstrak.

Jembatan · pembahasan penuh di Pertemuan 9

Nama terkininya: graph

Wacana pertengahan 2026 menamai lapisan di atas loop: graph engineering: pola-pola slide sebelumnya adalah bentuk graf — supervisor adalah hub, pipeline adalah rantai, message bus adalah state bersama.

Kosakata baru menambah satu hal: edge sebagai objek desain kelas satu — routing kondisional, fan-out, fan-in, digambar sebelum dikodekan.

Simpan pikiran ini dua minggu. Fokus hari ini adalah bagian yang dimiliki semua pola dan tak diperbaiki pola mana pun untuk Anda: verifier.

Konsep inti · bab 11

Verifier: tiga lapis

1 · Deterministik

Compiler, test, linter, validator skema, exec-output matcher. Murah, cepat, biner. Selalu ini dulu.

2 · LLM-as-judge

Menilai dengan rubrik. Butuh calibration set (contoh baik/buruk yang diketahui) dan versi model yang dipin — atau gerbang Anda melenceng diam-diam.

3 · Manusia

Gerbang eksplisit hanya di momen leverage-tinggi (Pertemuan 6). Manusia pemeriksa termahal; belanjakan untuk penilaian, bukan pola.

Aturan yang menjalankan mata kuliah ini

Model yang menulis kodenya terlalu lunak menilai PR-nya sendiri. Pisahkan secara fisik maker dari checker — agen berbeda, konteks berbeda, idealnya keluarga model berbeda.

Contoh · pipeline verifier untuk satu loop perubahan kode

Cek murah dulu, cek mahal belakangan

verify(out):
  1  npm ci                    # deterministik: env ter-reproduksi
  2  npm test -- --bail        # deterministik: unit + e2e
  3  eslint + tsc --strict     # deterministik: statis
  4  validasi api-diff vs api-contract.yaml   # kecocokan skema
  5  exec-match: jalankan input emas, diff output
  6  judge(model=pinned-v2, rubric.md, calibration/)  # lapis LLM
  7  gerbang manusia: review PR                    # hanya setelah 1–6 lolos

urutan penting: gagal cepat di 1–5 biayanya receh; gagal di 7 biayanya satu manusia.

Kebanyakan loop yang "jalan di demo" gagal di produksi karena langkah 4–6 tidak ada — maker menilai pekerjaannya sendiri di langkah 7.

Studi kasus · bagian 5 dari 10

Bug yang nyaris terkirim

Loop refund Kirana (Pertemuan 4) menghasilkan PR #212. Test hijau. Self-review LLM: "LGTM, 9/10." Nyaris di-merge.

Node verifier terpisah — model berbeda, read-only, rubrik dipin ke kontrak API — menangkapnya: pembulatan diterapkan sebelum cek jendela 30 hari di satu jalur, sehingga refund hari-31 senilai Rp 99.500 lolos sebagai hari-30 Rp 100.000 pada satu kasus tepi. Exec-match deterministik pada input emas mengonfirmasi ketidakcocokannya.

Kalimat retro yang masuk playbook perusahaan: "Maker bilang LGTM. Checker bilang tunjukkan."

Workshop · 30 menit

Rancang verifier tiga lapis

Kriteria yang diverifikasi (dari spec nyata)

AC-3: "Email digest mingguan memuat semua perubahan status invoice 7 hari terakhir, dikelompokkan per pelanggan, dengan total yang benar."

Hasil (berpasangan)

  1. Lapis 1: cek deterministik apa? (petunjuk: diff terhadap change-log DB, bukan teks email)
  2. Lapis 2: rubrik judge — maks 4 poin + 2 contoh kalibrasi (satu baik, satu buruk).
  3. Lapis 3: apa yang sebenarnya dilihat gerbang manusia? (bukan emailnya — sampel apa?)

Jebakan: kalau cek lapis-1 Anda memeriksa HTML email, Anda memverifikasi formatnya, bukan kelengkapannya. Verifikasi terhadap sumber kebenaran.

Tugas A5 · dikumpulkan sebelum Pertemuan 6

Bangun verifier untuk spec A3 Anda

Tugas
Untuk tiap kriteria penerimaan di spec A3 Anda: tetapkan lapis (1/2/3), sebutkan mekanismenya, dan urutkan cek murah→mahal. Pisahkan maker dan checker secara fisik (percakapan berbeda, model berbeda bila bisa).

Deliverable
Pipeline verifier (bernomor, terurut, dengan biaya) · jalankan pada 3 output nyata: satu baik, satu salah-halus, satu sampah · pasangan kalibrasi untuk judge Anda bila pakai lapis 2.

Rubrik
Ketepatan penempatan lapis 35% · disiplin pengurutan 15% · kasus salah-halus: tertangkap pipeline? 50%.

Berikutnya: lab — Anda membangun dan menjalankan loop lengkap pertama, di bawah persetujuan manusia. Bawa laptop. Baca bab 12–13.