// pengantar

Teks yang Mentah, Antarmuka yang Hidup

Pertama kali Anda menempelkan pertanyaan ke sebuah chatbot AI, jawabannya nyaris selalu berbentuk sama: gumpalan teks. Ada tanda pagar berlapis seperti #####, ada bintang ganda **tebal** yang tidak pernah benar-benar menebal, daftar bernomor yang panjang, dan sesekali tabel yang digambar pakai garis |---|---|. Itulah wajah asli output model bahasa: Markdown mentah.

Buku ini tentang satu lompatan sederhana namun berdampak besar: mengubah gumpalan teks itu menjadi antarmuka yang hidup. Heading menjadi hierarki visual. Tabel ASCII menjadi tabel yang bisa diurutkan. Angka-angka menjadi grafik batang. Daftar langkah menjadi diagram alir. Objek JSON menjadi kartu, form, kalender, bahkan dasbor mini. Kita menyebut proses jembatan ini parsing dan rendering.

Mengapa ini penting? Karena model bahasa hari ini sudah sangat pandai berpikir dan menghasilkan struktur, tetapi mayoritas produk masih menampilkannya sebagai teks datar. Padahal jarak antara "chatbot yang memuntahkan Markdown" dan "produk yang menampilkan hasil kaya" hanyalah satu lapis parser dan satu kontrak komponen. Siapa pun yang menguasai lapisan ini bisa membangun kelas produk baru: BI copilot, report builder, no-code dari percakapan, dan agen yang benar-benar terasa cerdas.

Above all else show the data.

Edward Tufte, The Visual Display of Quantitative Information

Buku ini ditujukan untuk tiga jenis pembaca. Developer akan menemukan pola kode, kontrak schema, dan pertimbangan keamanan yang siap dipakai. Non-developer — desainer, product manager, founder — akan memahami mengapa ini peluang dan bagaimana bentuknya. Dan karena buku ini juga ditulis agar bisa dibaca oleh AI, terdapat bab khusus tentang cara sebuah model memahami isi buku ini bila diberikan sebagai konteks.

Yang membedakan buku ini dari artikel biasa: ada Parser Playground yang benar-benar berfungsi di dalam halaman ini, tanpa server dan tanpa pustaka eksternal. Anda bisa menempelkan Markdown atau JSON dan melihatnya berubah menjadi tabel, chart, flowchart, atau kartu secara langsung. Semua kode parser ditulis vanilla, aman (meng-escape dulu, tidak pernah eval), dan bisa Anda pelajari dari sumbernya.

// panduan

Cara Membaca Buku Ini

Buku ini disusun dari masalah menuju solusi, lalu menuju peluang. Anda boleh membacanya berurutan, atau melompat lewat daftar isi di kiri yang mengikuti posisi baca (scrollspy). Berikut peta singkatnya.

Chatbot yang Cuma ##### dan **

Coba amati keluaran model bahasa apa pun yang belum dirender. Anda akan melihat pola yang sangat khas dan berulang: tanda pagar untuk judul, bintang untuk penekanan, tanda hubung untuk daftar, dan pipa untuk tabel. Ini bukan kebetulan — model memang dilatih untuk menulis dalam Markdown.

Berikut contoh output mentah yang lazim Anda temui bila jawaban model ditampilkan apa adanya, tanpa dirender:

## Ringkasan Penjualan Kuartal 3

**Total pendapatan:** Rp1.240.000.000

Berikut poin utamanya:

- Wilayah Barat naik 18%
- Wilayah Timur turun 4%
- Produk baru menyumbang 22% pendapatan

##### Catatan
Angka masih *sementara* dan dapat berubah.

| Wilayah | Target | Realisasi |
|---------|--------|-----------|
| Barat   | 500    | 590       |
| Timur   | 480    | 461       |

Bila string di atas ditampilkan mentah di sebuah <div>, pengguna akan melihat tanda ##, **, dan | yang berserakan. Bagi mata manusia ini terlihat bocor, belum jadi, dan "murah". Padahal informasinya sudah bagus — hanya penyajiannya yang mentah.

Kenapa model default-nya Markdown?

Ada beberapa alasan yang saling menguatkan:

• Data latih penuh Markdown. Model dilatih dari triliunan token teks internet: README GitHub, StackOverflow, dokumentasi, forum. Format dominan di sana adalah Markdown, jadi model menirunya sebagai bentuk "teks terstruktur yang rapi".
• Markdown itu ringan dan ekspresif. Dengan sedikit tanda baca, model bisa menyatakan hierarki (heading), penekanan (bold/italic), enumerasi (list), dan tabel. Ini cara paling murah untuk "tampak terstruktur" tanpa menulis HTML penuh.
• RLHF menguatkannya. Saat penyetelan dengan umpan balik manusia, jawaban ber-heading dan ber-bullet sering dinilai lebih membantu, sehingga model makin condong ke Markdown.
• Ia netral-platform. Markdown bisa dirender di mana saja, jadi ia pilihan aman ketika model tidak tahu akan ditampilkan di mana.

Artinya, Markdown mentah bukan bug — itu perilaku default yang masuk akal. Masalah muncul ketika kita berhenti di situ dan menyodorkannya langsung ke pengguna.

Kesederhanaan adalah soal menyingkirkan yang jelas dan menambahkan yang bermakna.

John Maeda, The Laws of Simplicity

Empat gejala output mentah

Kenapa Kita Perlu Parsing

Parsing adalah proses membaca teks dan memahami strukturnya — mengubah deret karakter menjadi objek yang bermakna: "ini heading level 2", "ini baris tabel", "ini array tiga angka". Setelah struktur diketahui, kita bebas merender-nya menjadi apa pun: HTML rapi, komponen React, grafik SVG, atau bahkan input untuk sistem lain.

Tanpa parsing, Anda terjebak pada tiga keterbatasan:

1. Tidak interaktif. Teks datar tidak bisa diklik, disortir, difilter, atau di-hover. Sebuah tabel ASCII tetap tabel ASCII; ia tidak akan pernah bisa diurutkan menurut kolom.
2. Terlihat mentah. Persepsi kualitas produk jatuh drastis ketika pengguna melihat sintaks bocor. Rendering yang rapi adalah pembeda antara "demo" dan "produk".
3. Sulit dipakai ulang. Angka yang terkubur dalam paragraf tidak bisa dimasukkan ke grafik, diekspor ke CSV, atau dikirim ke API. Struktur yang hilang harus "ditebak ulang" setiap kali.

Solusinya ada dua jalur yang saling melengkapi, dan keduanya dibahas tuntas di buku ini:

Perhatikan bahwa kedua jalur ini bukan pilihan "salah satu". Produk dewasa memakai keduanya: prosa dirender via Markdown, sementara bagian data-berat diminta dalam JSON dan dipetakan ke komponen. Bab-bab berikutnya membangun keduanya dari nol, dan Playground di bawah ini membiarkan Anda mencobanya sekarang juga.

// inti buku

Parser Playground

Ini bagian yang hidup. Semua parser di bawah berjalan di browser Anda, tanpa server dan tanpa pustaka eksternal. Tempel teks, pilih mode, tekan Render — dan lihat teks mentah berubah jadi antarmuka. Coba rusak datanya untuk melihat penanganan error yang ramah.

Markdown sebagai Default

Secara teknis, model bahasa hanya melakukan satu hal: memprediksi token berikutnya. Ia tidak "tahu" bahwa keluarannya akan dirender sebagai HTML atau ditampilkan di terminal. Karena itu, ketika tidak diberi instruksi format, ia memilih format yang paling sering ia lihat saat dilatih: Markdown.

Markdown default punya kelebihan yang nyata. Ia luwes untuk prosa: model bisa menjelaskan, memberi contoh, menyisipkan kode, dan menekankan poin dalam satu aliran. Untuk jawaban naratif — penjelasan konsep, ringkasan, tutorial — Markdown adalah bentuk yang tepat dan tinggal dirender.

Kekurangannya muncul saat kita butuh data, bukan prosa. Markdown tidak punya tipe: angka, tanggal, dan boolean semuanya sekadar teks. Tabel GFM rapuh (satu pipa hilang, seluruh baris rusak). Dan tidak ada jaminan struktur: model bisa memakai bullet di satu jawaban dan paragraf di jawaban berikutnya untuk data yang sama.

Structured Output: Menyuruh Model Bicara JSON

Ketika kita butuh data yang bisa diandalkan, kita meminta model mengeluarkan structured output — biasanya JSON yang mengikuti bentuk tertentu. Ada tiga tingkat "paksaan", dari yang paling longgar ke paling ketat.

1. Prompt biasa ("tolong balas JSON")

Cara termudah: minta saja di prompt. Kelemahannya, model kadang menambah basa-basi ("Tentu, ini JSON-nya:") atau membungkus dalam blok kode. Perlu pembersihan.

// prompt
Ekstrak data dari teks. Balas HANYA JSON valid, tanpa penjelasan,
dengan bentuk: {"nama": string, "umur": number, "kota": string}

Teks: "Budi, 29 tahun, tinggal di Bandung."

2. JSON mode

Banyak penyedia model menyediakan "JSON mode": sebuah sakelar yang menjamin keluaran adalah JSON yang secara sintaks valid (kurung dan koma benar). Ini menghapus masalah basa-basi, tetapi belum menjamin bentuk-nya sesuai keinginan.

3. Schema-constrained / tool calling

Tingkat paling ketat: kita memberi model sebuah schema (mis. JSON Schema) dan runtime memaksa setiap token yang dihasilkan tetap valid terhadap schema itu (sering disebut constrained decoding atau structured outputs). Hasilnya dijamin cocok bentuk. Function/tool calling adalah bentuk populer dari ini: kita mendefinisikan "alat" dengan parameter berschema, dan model mengisi argumennya.

// definisi tool (konsep, disederhanakan)
{
  "name": "tampilkan_chart",
  "description": "Menampilkan grafik batang ke pengguna",
  "parameters": {
    "type": "object",
    "properties": {
      "judul":  { "type": "string" },
      "labels": { "type": "array", "items": { "type": "string" } },
      "values": { "type": "array", "items": { "type": "number" } }
    },
    "required": ["labels", "values"]
  }
}

Ketika model memutuskan memanggil tampilkan_chart, ia mengembalikan argumen JSON yang sudah pasti punya labels dan values. Frontend tinggal memetakannya ke komponen chart. Inilah fondasi generative UI yang kita bangun di Bab 5 dan 8.

Peta keputusan singkat

Bingung memilih? Ikuti alur sederhana ini setiap kali merancang sebuah respons AI:

1. Apakah hasilnya akan diproses aplikasi (disimpan, difilter, dikirim ke API)? → JSON berschema.
2. Apakah hasilnya sebuah komponen visual (chart, tabel, form, kartu)? → JSON berschema + registry komponen.
3. Apakah hasilnya prosa naratif untuk dibaca (penjelasan, ringkasan)? → Markdown.
4. Apakah hasilnya campuran (penjelasan yang menyertakan sebuah chart)? → JSON yang salah satu field-nya berisi Markdown.

Perhatikan bahwa keputusan ini dibuat per-respons, bahkan per-bagian. Satu jawaban agen yang canggih bisa berisi paragraf pembuka Markdown, sebuah tabel dari JSON, lalu tombol quick-reply — masing-masing lewat jalur yang paling pas.

Streaming Token

Model tidak mengeluarkan jawaban sekaligus; ia memancarkan token satu per satu. Antarmuka chat yang baik menampilkannya seiring datang (streaming) agar terasa responsif. Ini memberi kelebihan pengalaman, tetapi menambah tantangan parsing: pada saat tertentu Anda hanya memegang potongan jawaban.

• Markdown streaming relatif ramah: Anda bisa merender ulang teks parsial tiap beberapa token. Paling banter, sebuah ** yang belum tertutup tampil sebentar sebagai bintang.
• JSON streaming lebih rumit: JSON parsial tidak valid (kurung belum tertutup). Anda perlu partial JSON parser yang toleran — dibahas tuntas di Bab 4 dan Bab 7.

Kelebihan streaming: time-to-first-token rendah, pengguna melihat kemajuan, dan UI terasa hidup. Kekurangannya: logika render jadi stateful, dan Anda harus menangani keadaan "belum lengkap" dengan anggun — biasanya lewat skeleton dan render bertahap.

Parser & AST

Merender Markdown bukan sekadar mencari-dan-ganti. Cara yang benar melewati dua tahap: parse (teks menjadi pohon sintaks abstrak / AST) lalu render (pohon menjadi HTML). Pemisahan ini penting karena AST bisa diperiksa, ditransformasi, dan disanitasi sebelum jadi HTML.

Sebuah baris ## Judul menjadi node { tipe: "heading", level: 2, isi: "Judul" }. Baris - apel menjadi bagian dari node list. Blok di antara tiga backtick menjadi node codeblock. Setelah seluruh dokumen menjadi pohon, render tinggal menerjemahkan tiap node ke elemen HTML yang sesuai.

Di ekosistem nyata, ada beberapa pustaka matang yang melakukan ini — disebut di sini sebagai konsep, bukan keharusan:

• marked — cepat dan kecil, cocok untuk render sisi klien yang ringan.
• markdown-it — modular dengan sistem plugin (tabel, footnote, dsb).
• remark (ekosistem unified) — berbasis AST murni, kuat untuk transformasi dan integrasi dengan rehype untuk HTML.

Playground di buku ini memakai parser mini buatan sendiri agar Anda melihat mekanismenya tanpa kotak hitam. Ia berbasis baris: memindai tiap baris, mengenali blok (heading, list, kutipan, kode, tabel, garis), lalu menerapkan format inline (bold, italic, kode, tautan) pada isinya. Semua teks di-escape lebih dulu.

// klien — inti parser mini (disederhanakan)
function renderMarkdown(src) {
  const lines = src.replace(/\r\n/g, "\n").split("\n");
  let html = "", i = 0;
  while (i < lines.length) {
    const line = lines[i];
    if (/^#{1,6}\s/.test(line)) {            // heading
      const level = line.match(/^#+/)[0].length;
      html += `<h${level}>${inline(esc(line.replace(/^#+\s/, "")))}</h${level}>`;
      i++;
    } else if (isTableStart(lines, i)) {      // tabel GFM
      const [tbl, next] = parseTable(lines, i); html += tbl; i = next;
    } else { /* paragraf, list, kutipan, kode… */ i++; }
  }
  return html;
}

Sanitasi & XSS

Inilah bagian yang paling sering diabaikan dan paling berbahaya. Output model bisa mengandung HTML — entah karena model menirunya, atau karena ia mengutip data yang disuntik penyerang (prompt injection). Bila Anda memasukkannya mentah ke innerHTML, sebuah <img src=x onerror="curi()"> akan dieksekusi.

Ada dua strategi, dan sebaiknya dipakai bersama:

1. Escape dulu. Sebelum menerapkan format Markdown, ubah <, >, &, dan kutip menjadi entitas. Dengan begitu HTML dari model diperlakukan sebagai teks literal, bukan markup. Ini yang dilakukan Playground.
2. Sanitasi setelah render. Bila Anda memang perlu mengizinkan sebagian HTML, lewatkan hasil melalui sanitizer (mis. pustaka sejenis DOMPurify) dengan allowlist tag dan atribut. Buang <script>, handler on*, dan URL javascript:.

// klien — escape yang jadi fondasi keamanan
function esc(s) {
  return String(s)
    .replace(/&/g, "&")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&#39;");
}

Untuk tautan, waspadai skema URL. Izinkan hanya http:, https:, dan mailto:. Tautan javascript:foo() harus ditolak atau dinetralkan. Tambahkan rel="noopener noreferrer" pada tautan yang membuka tab baru.

Highlight, Tabel GFM, dan Math

Syntax highlighting

Blok kode dari model sebaiknya diberi warna agar terbaca. Pola aman: escape isi kode, bungkus dengan <pre><code>, lalu terapkan pewarnaan berbasis token. Pustaka seperti highlight.js atau Prism melakukannya; untuk versi ringan, Anda bisa mewarnai kata kunci, string, angka, dan komentar dengan regex sederhana seperti yang dilakukan Playground pada JSON.

Tabel GFM

Tabel "GitHub Flavored Markdown" dikenali dari baris pemisah |---|---| tepat di bawah baris header. Parser membaca header, membaca pemisah (yang juga menyatakan perataan kolom via :), lalu membaca baris data sampai bertemu baris tanpa pipa. Playground mengimplementasikan ini secara penuh — coba mode Markdown dengan contoh bawaan.

| Produk   | Harga  | Stok |
|:---------|-------:|:----:|
| Kopi     | 25.000 |  120 |
| Teh      | 18.000 |   80 |

Math

Untuk notasi matematika, model biasa memakai sintaks LaTeX di antara $…$ (inline) atau $$…$$ (blok). Merendernya butuh mesin seperti KaTeX atau MathJax. Karena buku ini berjanji tanpa pustaka eksternal, Playground tidak merender math; namun polanya sama: kenali delimiter, ekstrak ekspresi, serahkan ke renderer khusus. Yang penting: jangan mengeksekusi ekspresi sebagai kode — ia hanya notasi.

Perincian bukanlah perincian. Ia yang membuat rancangan.

Charles Eames

Ringkasnya, jalur Markdown yang matang adalah: escape → parse ke blok → format inline → sanitasi allowlist → highlight → render. Dengan urutan itu, Anda mendapat prosa AI yang rapi tanpa membuka celah keamanan.

Contoh pipeline utuh

Mari satukan semuanya. Berikut fungsi tingkat-atas yang menerima teks mentah dari model dan mengembalikan HTML aman siap tempel. Perhatikan bahwa setiap langkah punya tanggung jawab tunggal, sehingga mudah diuji dan diganti.

// klien — pipeline render Markdown yang aman
function renderJawaban(teksModel) {
  // 1. batasi ukuran agar tak membekukan browser
  if (teksModel.length > 50000) teksModel = teksModel.slice(0, 50000) + "…";
  // 2. parse (escape terjadi di dalam renderMarkdown)
  let html = renderMarkdown(teksModel);
  // 3. sanitasi allowlist bila mengizinkan sebagian HTML mentah
  html = sanitasi(html, {
    tags: ["h1","h2","h3","h4","p","ul","ol","li","strong","em",
           "code","pre","blockquote","table","thead","tbody","tr","th","td","a","hr","br"],
    attrs: { a: ["href","rel"] },
  });
  // 4. tempel — sudah aman karena teks di-escape & tag di-allowlist
  return html;
}

Empat baris konsep, tetapi masing-masing menutup satu kelas masalah: ukuran (DoS), markup jahat (XSS via teks), tag terlarang (XSS via elemen), dan atribut berbahaya (XSS via on*/javascript:). Playground buku ini menerapkan langkah 1 dan 2 secara nyata; langkah 3 memakai sanitizer produksi ketika Anda benar-benar perlu mengizinkan HTML.

Memaksa JSON Valid

Data yang bisa diandalkan dimulai dari keluaran yang bentuknya pasti. Ada spektrum teknik, dan pilihan Anda menentukan seberapa banyak kode pembersih yang perlu ditulis di sisi klien.

Teknik dari longgar ke ketat

Prompt yang baik untuk JSON

Bila Anda hanya punya prompt, buat instruksinya tegas: sebutkan bentuk persis, larang teks tambahan, beri satu contoh, dan minta pakai null untuk yang tidak diketahui (bukan mengarang).

// prompt
Kembalikan HANYA objek JSON, tanpa blok kode, tanpa kalimat pembuka.
Skema: { "judul": string, "poin": string[], "sentimen": "positif"|"negatif"|"netral" }
Jika sebuah field tidak diketahui, isi dengan null. Jangan mengarang.

Contoh keluaran yang benar:
{"judul":"Rilis v2","poin":["lebih cepat","hemat memori"],"sentimen":"positif"}

Validasi dengan schema (mis. zod)

Di sisi kode, jangan percaya begitu saja. Validasi hasil terhadap schema. Pustaka seperti zod (TypeScript) atau pydantic (Python) membuat ini ringkas dan sekaligus memberi tipe.

// klien — validasi dengan zod (konsep)
import { z } from "zod";
const Skema = z.object({
  judul: z.string(),
  poin: z.array(z.string()),
  sentimen: z.enum(["positif", "negatif", "netral"]),
});
const hasil = Skema.safeParse(JSON.parse(teksModel));
if (!hasil.success) {
  // minta model memperbaiki, atau pakai nilai default
}

Streaming & Partial JSON

Saat token JSON mengalir, pada satu momen Anda memegang string seperti {"labels":["Jan","Feb"],"val — belum valid. JSON.parse akan melempar error. Ada beberapa strategi:

• Tunggu selesai. Paling sederhana: kumpulkan semua token, parse sekali di akhir. Kekurangannya, tidak ada render progresif.
• Partial JSON parser. Parser toleran yang "menutup" kurung yang belum tertutup secara sementara, sehingga potongan bisa di-parse menjadi objek parsial. Field yang belum lengkap dibiarkan kosong/menunggu.
• Streaming per-item. Bila keluaran berupa array, minta model mengeluarkan satu objek per baris (JSON Lines). Setiap baris utuh bisa langsung dirender begitu selesai.

// klien — ide partial-parse sederhana
function parsePartial(buf) {
  try { return JSON.parse(buf); } catch (_) {}
  // coba tutup kurung yang menggantung
  let s = buf, open = 0, inStr = false, esc2 = false;
  for (const c of s) {
    if (esc2) { esc2 = false; continue; }
    if (c === "\\") { esc2 = true; continue; }
    if (c === '"') inStr = !inStr;
    if (!inStr && (c === "{" || c === "[")) open++;
    if (!inStr && (c === "}" || c === "]")) open--;
  }
  if (inStr) s += '"';
  while (open-- > 0) s += "}";        // tutup kasar; cukup untuk preview
  try { return JSON.parse(s); } catch (_) { return null; }
}

JSON Lines patut dipertimbangkan untuk daftar panjang. Alih-alih satu array raksasa, model mengeluarkan objek terpisah per baris; frontend merender kartu demi kartu seiring datang, memberi kesan cepat.

// keluaran model dalam format JSON Lines (satu objek per baris)
{"nama":"Kopi","harga":25000}
{"nama":"Teh","harga":18000}
{"nama":"Susu","harga":22000}

// klien — render tiap baris utuh segera setelah selesai
let sisa = "";
for await (const potongan of stream) {
  sisa += potongan;
  let idx;
  while ((idx = sisa.indexOf("\n")) >= 0) {
    const baris = sisa.slice(0, idx).trim();
    sisa = sisa.slice(idx + 1);
    if (baris) tambahKartu(JSON.parse(baris));   // baris ini pasti utuh
  }
}

Keunggulan pola ini: Anda tidak perlu partial parser sama sekali untuk kasus daftar, karena setiap baris yang diakhiri \n dijamin objek lengkap. Kelemahannya, ia hanya cocok untuk koleksi — bukan satu objek besar yang field-nya saling bergantung.

Validasi & Pemulihan Error

Bahkan dengan schema, model sesekali salah: field hilang, tipe keliru, enum di luar daftar. Bangun tiga lapis pertahanan.

1. Validasi ketat terhadap schema segera setelah parse. Kumpulkan daftar kesalahan yang bisa dibaca.
2. Retry dengan umpan balik. Bila gagal, kirim ulang ke model beserta pesan kesalahan: "Field sentimen harus salah satu dari positif/negatif/netral; kamu mengisi 'senang'. Perbaiki." Model biasanya benar di percobaan kedua.
3. Fallback anggun. Bila tetap gagal, jangan crash. Tampilkan versi teks mentah dengan catatan, atau nilai default, sehingga pengguna tetap mendapat sesuatu.

// server — loop validasi + retry (konsep)
async function mintaTerstruktur(prompt, skema, maks = 2) {
  let pesan = prompt;
  for (let coba = 0; coba <= maks; coba++) {
    const teks = await panggilModel(pesan);
    const v = skema.safeParse(ambilJSON(teks));
    if (v.success) return v.data;
    pesan = prompt + "\n\nKeluaran sebelumnya salah: " + ringkasError(v.error) +
            "\nKembalikan JSON yang benar.";
  }
  throw new Error("Gagal memperoleh JSON valid setelah retry");
}

Render Schema & Component Registry

Bila model bisa mengeluarkan JSON, ia bisa mendeskripsikan antarmuka — bukan hanya data. Idenya: model mengeluarkan objek yang menyebut tipe komponen dan propertinya; frontend punya registry yang memetakan tiap tipe ke komponen sungguhan. Model tidak pernah mengirim HTML; ia hanya memilih dari menu komponen yang Anda sediakan.

// kontrak: model mengeluarkan "resep UI", bukan HTML
{
  "komponen": "chart",
  "props": {
    "judul": "Penjualan per Wilayah",
    "labels": ["Barat", "Timur", "Tengah"],
    "values": [590, 461, 305]
  }
}

// klien — component registry (allowlist)
const REGISTRY = {
  chart:    renderChart,
  tabel:    renderTable,
  kartu:    renderCards,
  flowchart:renderFlowchart,
  timeline: renderTimeline,
};
function render(node) {
  const fn = REGISTRY[node.komponen];
  if (!fn) return renderTeksAman("[komponen tak dikenal]");
  return fn(node.props || {});   // hanya komponen di registry yang boleh
}

Keindahan pola ini: penambahan komponen baru = menambah satu entri di registry. Model belajar memakainya lewat deskripsi tool/schema. Dan karena rendering melewati fungsi tepercaya milik Anda — bukan innerHTML sembarangan — permukaan serangan menyempit drastis.

Komposisi & tata letak

Komponen tunggal berguna, tetapi kekuatan sejati muncul saat model bisa menyusun beberapa komponen menjadi tata letak. Untuk itu, tambahkan komponen "kontainer" ke registry yang isinya adalah daftar komponen anak. Renderer memanggil dirinya sendiri secara rekursif.

// resep UI berlapis: baris berisi dua komponen
{ "komponen": "baris",
  "props": { "anak": [
    { "komponen": "kpi",   "props": { "label": "Pendapatan", "nilai": "Rp1,24 M" } },
    { "komponen": "chart", "props": { "labels": ["Q1","Q2"], "values": [820, 1240] } }
  ] } }

// klien — render rekursif dengan batas kedalaman
function render(node, depth) {
  if (depth > 6) return renderTeksAman("[terlalu dalam]");   // cegah rekursi liar
  const fn = REGISTRY[node.komponen];
  if (!fn) return renderTeksAman("[komponen tak dikenal]");
  return fn(node.props || {}, function(anak){ return render(anak, depth + 1); });
}

Dua penjaga penting di sini: batas kedalaman agar output berlapis dalam tidak membekukan browser, dan tetap allowlist di setiap level — komponen anak yang tak dikenal pun jadi placeholder aman, tidak pernah HTML mentah. Dengan pola rekursif ini, sebuah dashboard, wizard, atau laporan kompleks lahir dari satu pohon JSON yang model susun sendiri.

Generative UI

Istilah generative UI menggambarkan antarmuka yang bentuknya ditentukan saat itu juga oleh model, bukan dikodekan tetap. Alih-alih menjawab "cuaca besok cerah 31°C" sebagai teks, agen memanggil komponen kartu-cuaca dengan props suhu, ikon, dan ramalan per jam. Pengguna mendapat kartu, bukan kalimat.

Pola ini menyatu rapat dengan tool calling: setiap "tool" sebenarnya adalah sebuah komponen. Ketika model memutuskan tool tampilkan_tabel paling membantu, argumen JSON-nya menjadi props tabel. Bab 8 membahas arsitektur ini lebih dalam, termasuk pendekatan ala Vercel AI SDK / React Server Components sebagai konsep.

The best way to predict the future is to invent it.

Alan Kay

Tiga tingkat kematangan generative UI:

1. Statis-terpilih. Model memilih dari sekumpulan komponen tetap dengan props. Paling aman, paling mudah dipelihara. Rekomendasi untuk mayoritas produk.
2. Komposisi. Model menyusun beberapa komponen menjadi tata letak (mis. baris berisi dua kartu dan satu chart). Butuh schema tata letak.
3. Kode-penuh. Model menulis kode komponen sungguhan yang dieksekusi di sandbox. Paling kuat, paling berisiko — wajib isolasi ketat (iframe sandbox, tanpa akses jaringan/DOM utama).

Allowlist Komponen

Aturan tunggal yang menjaga Anda aman: frontend hanya boleh merender komponen dari daftar yang Anda izinkan. Jangan pernah memetakan output model langsung ke elemen HTML arbitrer atau ke dangerouslySetInnerHTML.

Dengan kontrak ini, model menjadi "sutradara" yang memilih adegan dari perbendaharaan yang Anda tentukan, bukan "penulis" yang bisa menyisipkan apa pun ke panggung. Itulah keseimbangan antara fleksibilitas generative UI dan keamanan produksi.

1. Tabel Data (Sortable)

Masalah. Model sering menaruh data dalam tabel ASCII atau paragraf. Pengguna butuh tabel yang bisa diurutkan, difilter, dan disalin per kolom.

Bentuk. Array objek dengan kunci seragam. Header diturunkan dari kunci; baris dari nilai.

[
  { "produk": "Kopi", "harga": 25000, "stok": 120 },
  { "produk": "Teh",  "harga": 18000, "stok": 80  },
  { "produk": "Susu", "harga": 22000, "stok": 60  }
]

Hasil UI. Tabel dengan header yang bisa diklik untuk mengurutkan naik/turun. Coba di Playground mode JSON → Tabel; klik header kolom untuk sortir.

2. Chart / Visualisasi

Masalah. Angka dalam kalimat sulit dibandingkan. Grafik membuat pola langsung terlihat.

Bentuk. Objek dengan labels dan values sejajar. Bisa diperluas dengan judul dan satuan.

{ "judul": "Pengunjung Mingguan",
  "labels": ["Sen","Sel","Rab","Kam","Jum"],
  "values": [120, 200, 150, 80, 240] }

Hasil UI. Bar chart SVG dengan sumbu dan nilai. Playground mode JSON → Chart merender ini secara nyata, lengkap dengan penskalaan otomatis ke nilai tertinggi.

3. Flowchart / Diagram

Masalah. Proses bertahap (alur persetujuan, pipeline, algoritma) sulit dipahami sebagai daftar. Diagram alir menampilkan hubungan.

Bentuk. Dua pendekatan. (a) Sintaks Mermaid yang model kuasai; (b) JSON node+edge yang lebih mudah dirender aman.

// pendekatan Mermaid (teks)
graph TD
  A[Mulai] --> B{Valid?}
  B -->|ya| C[Simpan]
  B -->|tidak| D[Tolak]

// pendekatan JSON (dipakai Playground)
{ "nodes": [
    {"id":"a","label":"Mulai"},
    {"id":"b","label":"Validasi"},
    {"id":"c","label":"Simpan"},
    {"id":"d","label":"Tolak"} ],
  "edges": [["a","b"],["b","c"],["b","d"]] }

Hasil UI. Kotak dan panah tersusun bertingkat. Playground mode JSON → Flowchart menghitung level tiap node dari edge lalu menata otomatis — coba tambahkan node dan lihat tata letaknya menyesuaikan.

4. Form dari JSON Schema

Masalah. Mengumpulkan input terstruktur lewat chat itu canggung. Form yang dibangkitkan dari schema jauh lebih cepat.

Bentuk. JSON Schema standar. Tiap properti menjadi field; type, enum, dan required menentukan kontrol dan validasi.

{ "type": "object",
  "properties": {
    "nama":   { "type": "string", "title": "Nama Lengkap" },
    "umur":   { "type": "number", "minimum": 0 },
    "paket":  { "type": "string", "enum": ["Basic","Pro","Enterprise"] },
    "setuju": { "type": "boolean", "title": "Setuju S&K" }
  },
  "required": ["nama","paket"] }

Hasil UI. Field teks untuk string, angka untuk number, dropdown untuk enum, checkbox untuk boolean. Label dari title. Validasi required. Pola ini adalah tulang punggung survey/form builder berbasis AI.

5. Kartu, List & Galeri

Masalah. Daftar entitas (produk, kontak, artikel) lebih enak sebagai kartu daripada bullet panjang.

Bentuk. Array objek; field pertama sebagai judul, sisanya sebagai atribut.

[
  { "nama": "Paket Hemat", "harga": "Rp49rb", "fitur": "5 proyek" },
  { "nama": "Paket Pro",   "harga": "Rp99rb", "fitur": "Tak terbatas" }
]

Hasil UI. Grid kartu responsif. Playground mode JSON → Kartu merendernya; kunci pertama ditonjolkan sebagai judul kartu.

6. Timeline

Masalah. Urutan peristiwa berwaktu (riwayat, roadmap, changelog) butuh sumbu waktu, bukan sekadar daftar.

Bentuk. Array objek dengan waktu dan peristiwa, opsional status.

[
  { "waktu": "2024 Q1", "peristiwa": "Riset pasar", "status": "selesai" },
  { "waktu": "2024 Q2", "peristiwa": "MVP",         "status": "berjalan" },
  { "waktu": "2024 Q3", "peristiwa": "Peluncuran",  "status": "rencana" }
]

Hasil UI. Garis vertikal dengan titik berwarna per status dan label waktu. Cocok untuk agen yang melaporkan progres proyek.

7. Kanban

Masalah. Manajemen tugas lewat teks kehilangan gambaran "apa di kolom apa". Papan kanban menampilkan status secara spasial.

Bentuk. Objek kolom → array kartu.

{ "Todo":     ["Desain ikon", "Tulis dokumen"],
  "Progress": ["Bangun API"],
  "Done":     ["Setup repo", "Rapat kickoff"] }

Hasil UI. Kolom sejajar berisi kartu. Model bisa memindahkan kartu antar kolom dengan mengeluarkan struktur baru. Fondasi untuk agen manajemen proyek.

8. Peta

Masalah. Data geografis (cabang toko, titik kejadian) tak bermakna sebagai koordinat mentah. Peta memberi konteks ruang.

Bentuk. Array titik dengan lat, lng, label.

[
  { "label": "Kantor Pusat", "lat": -6.2, "lng": 106.8 },
  { "label": "Gudang",       "lat": -6.3, "lng": 106.9 }
]

Hasil UI. Peta dengan penanda (memakai pustaka peta seperti Leaflet/MapLibre di produksi). Keamanan: validasi rentang lat/lng dan batasi jumlah titik agar tak membanjiri peta.

9. Kalender

Masalah. Jadwal dan acara sulit dibayangkan sebagai daftar tanggal. Kalender menampilkan sebaran dalam bulan.

Bentuk. Array acara dengan tanggal dan judul.

[
  { "tanggal": "2026-07-03", "judul": "Rilis beta" },
  { "tanggal": "2026-07-18", "judul": "Webinar" },
  { "tanggal": "2026-07-25", "judul": "Retrospektif" }
]

Hasil UI. Grid bulan dengan titik/label pada tanggal berisi acara. Agen penjadwal bisa menawarkan slot lalu merender kalender konfirmasi.

10. Quick-reply & Tombol Aksi

Masalah. Mengetik ulang pilihan itu lambat dan rawan salah. Tombol saran mempercepat interaksi.

Bentuk. Array aksi; tiap aksi punya label dan nilai (yang dikirim balik saat diklik).

{ "prompt": "Mau lanjut ke mana?",
  "aksi": [
    { "label": "Lihat detail",  "nilai": "detail" },
    { "label": "Ubah pesanan",  "nilai": "ubah" },
    { "label": "Selesai",       "nilai": "selesai" }
  ] }

Hasil UI. Deretan tombol pil. Klik mengirim nilai sebagai pesan berikutnya. Keamanan: render label sebagai teks (escape), jangan pernah sebagai HTML.

11. Sitasi & Sumber

Masalah. Jawaban AI tanpa sumber sulit dipercaya. Menampilkan rujukan yang bisa diklik membangun kepercayaan (penting untuk RAG).

Bentuk. Array sumber dengan judul, url, opsional kutipan.

[
  { "judul": "Laporan Tahunan 2025", "url": "https://contoh.id/laporan",
    "kutipan": "Pendapatan tumbuh 18% YoY." },
  { "judul": "Rilis Pers Q3",        "url": "https://contoh.id/pers" }
]

Hasil UI. Daftar kartu sumber dengan tautan aman (hanya http/https, rel="noopener") dan kutipan pendukung. Nomor sitasi bisa ditautkan inline dari teks jawaban.

12. Blok Kode (Run / Copy)

Masalah. Kode dari model perlu disalin dengan mudah dan, kadang, dijalankan — tetapi menjalankan kode arbitrer berbahaya.

Bentuk. Objek dengan bahasa dan kode.

{ "bahasa": "javascript",
  "kode": "console.log('halo dunia')" }

Hasil UI. Blok kode tersorot dengan tombol Salin, dan (opsional) tombol Jalankan yang mengeksekusi hanya di dalam <iframe sandbox> tanpa akses jaringan/DOM utama. Keamanan: jangan pernah eval di konteks halaman utama.

13. Rich Media

Masalah. Gambar, audio, atau video yang relevan lebih kaya daripada deskripsi teks.

Bentuk. Objek media dengan tipe dan url dari sumber tepercaya.

{ "tipe": "gambar", "url": "https://cdn.contoh.id/grafik.png",
  "alt": "Grafik pertumbuhan" }

Hasil UI. Elemen <img>/<video> dengan lazy-load dan alt. Keamanan: allowlist domain sumber; tolak data: URL yang tak terduga; selalu set alt untuk aksesibilitas.

14. Step-by-step Wizard

Masalah. Proses multi-langkah (onboarding, konfigurasi) membingungkan bila disajikan sekaligus.

Bentuk. Array langkah dengan judul dan isi (boleh Markdown), plus indikator langkah aktif.

{ "langkahAktif": 1,
  "langkah": [
    { "judul": "Buat akun",    "isi": "Isi email dan kata sandi." },
    { "judul": "Verifikasi",   "isi": "Cek kotak masuk Anda." },
    { "judul": "Mulai",        "isi": "Buat proyek pertama." }
  ] }

Hasil UI. Indikator langkah (stepper) dengan konten per langkah dan tombol Lanjut/Kembali. Agen memandu pengguna satu layar demi satu layar.

15. Perbandingan / Tabel Harga

Masalah. Membandingkan paket lewat prosa melelahkan. Tabel harga menampilkan perbedaan sekilas.

Bentuk. Array paket dengan nama, harga, fitur[], dan penanda unggulan.

[
  { "nama": "Basic", "harga": "Gratis",  "fitur": ["3 proyek","Komunitas"] },
  { "nama": "Pro",   "harga": "Rp99rb",  "fitur": ["Tak terbatas","Prioritas"],
    "unggulan": true },
  { "nama": "Team",  "harga": "Rp299rb", "fitur": ["Kolaborasi","SSO"] }
]

Hasil UI. Kolom paket bersanding dengan kartu unggulan disorot dan centang per fitur. Sangat cocok untuk agen penjualan/rekomendasi paket.

16. Dashboard Mini dari Chat

Masalah. Pertanyaan bisnis ("bagaimana penjualan bulan ini?") sebaiknya dijawab dengan panel angka + grafik, bukan paragraf.

Bentuk. Komposisi: beberapa KPI (angka besar) plus satu-dua chart, dibungkus satu objek tata letak.

{ "komponen": "dashboard",
  "props": {
    "kpi": [
      { "label": "Pendapatan", "nilai": "Rp1,24 M", "delta": "+18%" },
      { "label": "Pesanan",    "nilai": "3.402",    "delta": "+7%" }
    ],
    "chart": { "labels": ["Jan","Feb","Mar"], "values": [820, 910, 1240] }
  } }

Hasil UI. Baris kartu KPI dengan delta berwarna (hijau naik, merah turun) di atas grafik tren. Inilah cikal-bakal BI copilot: chat masuk, dashboard keluar. Bab 9 membahas peluang bisnisnya.

Luasnya Tak Terbatas

Galeri di Bab 6 baru permulaan. Prinsipnya sederhana namun berdaya ledak besar: apa pun yang bisa dideskripsikan sebagai JSON bisa dirender menjadi UI, dokumen, atau otomasi. Model tidak perlu menggambar piksel atau menulis HTML rapuh — ia cukup mengeluarkan data terstruktur, dan frontend Anda (registry komponen) yang menerjemahkannya menjadi artefak berkualitas produksi.

Begitu Anda menerima kerangka berpikir ini, ide generator baru bermunculan tanpa henti. Bab ini menyajikan lima belas use case expert — masing-masing dengan bentuk JSON siap salin dan gambaran hasilnya. Perhatikan bahwa pola yang sama berulang: bentuk JSON → mapping → artefak. Kuasai pola itu, dan Anda bisa menciptakan generator ke-16, ke-50, ke-100 sendiri.

Data is the new markup. Beri model schema, ia mengisi struktur; beri frontend struktur, ia melahirkan pengalaman.

Prinsip Generative UI

Lima Belas Generator Expert — Ringkasan

Peta cepat: apa yang masuk (input JSON) dan apa yang keluar (output). Detail tiap baris ada di sub-bab berikutnya.

1. PPT / Slide Deck Generator

Masalah. "Buatkan presentasi 5 slide tentang peluncuran produk." Jawaban paragraf tak berguna untuk rapat. Yang dibutuhkan: deck terformat yang bisa dipresentasikan atau diekspor ke PowerPoint.

Bentuk. Deret slide, tiap slide punya layout yang menentukan tata letak (title, bullets, two-column, quote, chart, section), plus konten dan catatan pembicara opsional.

{ "deck": [
    { "layout": "title",   "title": "Peluncuran Aurora", "subtitle": "Q3 2026" },
    { "layout": "bullets",  "title": "Kenapa Sekarang",
      "bullets": ["Pasar tumbuh 34% YoY", "Kompetitor lambat", "Tim siap"],
      "notes": "Tekankan momentum pasar di slide ini." },
    { "layout": "two-column", "title": "Sebelum vs Sesudah",
      "left": ["Manual", "Lambat"], "right": ["Otomatis", "Real-time"] },
    { "layout": "chart", "title": "Proyeksi Pengguna",
      "chart": { "labels": ["Q1","Q2","Q3"], "values": [12, 48, 120] } },
    { "layout": "quote", "quote": "Desain yang baik tak terlihat.", "by": "Dieter Rams" },
    { "layout": "section", "title": "Bagian 2 — Roadmap" }
] }

Hasil UI. Tiap objek jadi satu slide rasio 16:9. Layout memetakan ke template: title (judul besar tengah), bullets (judul + poin), two-column (dua kolom sejajar), quote (kutipan sentris), chart (grafik), section (pembatas bab).

Ekspor (konsep). Untuk presentasi web, render deck jadi reveal.js: tiap slide jadi <section>. Untuk file .pptx, umpankan JSON yang sama ke pptxgenjs di server — addSlide() per objek, addText/addChart per layout. Satu sumber JSON, dua target keluaran.

2. Book / Document Generator Terformat

Masalah. Anda ingin AI menghasilkan sebuah buku — bukan gumpalan Markdown, melainkan dokumen berbab dengan daftar isi, sub-bagian, dan gambar. Persis seperti buku yang sedang Anda baca ini.

Bentuk. Metadata di akar, lalu pohon chapters → sections. Tiap section punya heading, body (boleh Markdown), dan figur opsional.

{ "title": "Output AI Naik Kelas",
  "author": "Galih Prasetyo",
  "chapters": [
    { "heading": "Masalah",
      "sections": [
        { "h": "Chatbot yang cuma ##### dan **",
          "body": "Model default mengeluarkan Markdown mentah...",
          "figures": [{ "kind": "svg", "caption": "Sebelum vs sesudah" }] },
        { "h": "Kenapa perlu parsing", "body": "Karena teks mentah..." }
      ] },
    { "heading": "Parsing Markdown",
      "sections": [ { "h": "Parser & AST", "body": "AST adalah..." } ] }
  ] }

Pemetaan JSON → struktur buku. Aturannya lugas dan deterministik:

Hasil UI. Frontend menyusuri pohon, membangun daftar isi dari heading dan h, memberi setiap bagian anchor id (mis. slug dari heading), lalu merender scrollspy — persis mekanisme di sisi kiri buku ini. AI mengeluarkan JSON ini; frontend merendernya jadi buku. Alur produksi: prompt "tulis buku tentang X" → model balas JSON berbab → validasi → render → tombol "Ekspor PDF".

3. Workflow Generator dari JSON

Masalah. "Setiap ada form masuk, kirim ke Slack lalu simpan ke database." Deskripsi bahasa alami itu sebaiknya jadi workflow visual yang bisa dilihat, diedit, dan dijalankan — bukan sekadar paragraf instruksi.

Bentuk. Graf: kumpulan nodes (tiap node punya id, type, label, config) dan edges (pasangan [dari, ke]). Jenis node: trigger, http, transform, condition, ai, output.

{ "nodes": [
    { "id": "t1", "type": "trigger",   "label": "Form masuk",     "config": { "event": "form.submit" } },
    { "id": "h1", "type": "http",      "label": "Ambil data user", "config": { "method": "GET", "url": "/api/user" } },
    { "id": "a1", "type": "ai",        "label": "Ringkas pesan",   "config": { "model": "claude", "task": "summarize" } },
    { "id": "c1", "type": "condition", "label": "Prioritas tinggi?", "config": { "expr": "score > 0.8" } },
    { "id": "o1", "type": "output",    "label": "Kirim ke Slack",  "config": { "channel": "#leads" } }
  ],
  "edges": [ ["t1","h1"], ["h1","a1"], ["a1","c1"], ["c1","o1"] ] }

Hasil UI. Node dirender sebagai kotak berwarna sesuai tipe, dihubungkan panah mengikuti edges — persis kanvas n8n atau Zapier. Trigger di puncak, aksi di bawahnya, percabangan pada condition.

Bisa dieksekusi. Graf ini bukan gambar mati. Mapping ke engine nyata: node trigger jadi webhook, http jadi request, ai jadi panggilan model, condition jadi percabangan, output jadi aksi. Ekspor ke format n8n/Zapier, atau jalankan dengan engine sendiri yang menelusuri edges secara topologis dan mengeksekusi tiap node berurutan.

4. Dashboard Builder

Masalah. "Tampilkan performa toko." Butuh papan yang menata beberapa widget dalam grid — bukan satu chart tunggal.

Bentuk. Daftar widgets; tiap widget punya type (kpi, chart, table), ukuran grid, dan data. Layout mengalir mengikuti span.

{ "title": "Performa Toko",
  "widgets": [
    { "type": "kpi",   "span": 3, "label": "Pendapatan", "value": "Rp1,24 M", "delta": "+18%" },
    { "type": "kpi",   "span": 3, "label": "Pesanan",    "value": "3.402",    "delta": "+7%" },
    { "type": "chart", "span": 6, "kind": "bar", "labels": ["Sen","Sel","Rab"], "values": [12,19,9] },
    { "type": "table", "span": 12, "columns": ["Produk","Terjual"], "rows": [["Kaos",120],["Topi",84]] }
  ] }

Hasil UI. Grid 12-kolom: dua kartu KPI (span 3), satu chart (span 6), satu tabel lebar (span 12). Delta positif hijau, negatif merah.

5. Form / Survey Builder

Masalah. Mengumpulkan data terstruktur dari pengguna butuh form dengan validasi — dan sering multi-langkah agar tak melelahkan.

Bentuk. Turunan JSON Schema: langkah-langkah, tiap langkah berisi field dengan tipe, label, dan aturan required/pattern.

{ "title": "Pendaftaran Peserta",
  "steps": [
    { "title": "Identitas", "fields": [
        { "name": "nama",  "type": "text",  "label": "Nama lengkap", "required": true },
        { "name": "email", "type": "email", "label": "Email",        "required": true } ] },
    { "title": "Preferensi", "fields": [
        { "name": "paket", "type": "select", "label": "Paket",
          "options": ["Basic","Pro","Enterprise"] },
        { "name": "setuju", "type": "checkbox", "label": "Setuju syarat", "required": true } ] }
  ] }

Hasil UI. Wizard dua langkah dengan progress bar. Field dirender per tipe (input teks, dropdown, checkbox), validasi menahan lanjut sampai required terisi dan pattern cocok. Karena berbasis JSON Schema, respons form pun otomatis tervalidasi di server.

6. Report Generator

Masalah. Laporan bulanan/analisis butuh struktur baku: ringkasan eksekutif, temuan, rekomendasi — konsisten tiap kali.

Bentuk. Judul, ringkasan (auto-summary), lalu daftar section bertingkat dengan metrik opsional.

{ "title": "Laporan Kinerja Q3 2026",
  "summary": "Pertumbuhan sehat 18%, churn menurun, fokus retensi Q4.",
  "sections": [
    { "h": "Ringkasan Eksekutif", "body": "Kuartal ini melampaui target...",
      "metrics": [ { "label": "MRR", "value": "Rp420 jt", "trend": "up" } ] },
    { "h": "Temuan", "body": "Segmen SMB tumbuh tercepat...",
      "list": ["Retensi naik ke 92%", "CAC turun 11%"] },
    { "h": "Rekomendasi", "body": "Alokasikan ulang anggaran ke retensi." }
  ] }

Hasil UI. Dokumen laporan: blok ringkasan menonjol di atas, tiap section jadi heading + paragraf, metrik jadi kartu kecil dengan panah tren, list jadi poin. Siap diekspor PDF atau dikirim sebagai email ringkasan.

7. Email / Newsletter Generator

Masalah. Email HTML notorius sulit — tabel bersarang, gaya inline. Deskripsikan saja isinya sebagai blok, biarkan generator menangani markup email.

Bentuk. Deret blocks tipe header, teks, tombol, gambar, divider, footer.

{ "subject": "Update Mingguan Aurora",
  "preheader": "Fitur baru + tips",
  "blocks": [
    { "type": "header", "text": "Aurora Weekly", "logo": "aurora.png" },
    { "type": "text",   "text": "Halo Budi, ini sorotan minggu ini." },
    { "type": "image",  "src": "banner.png", "alt": "Fitur baru" },
    { "type": "button", "text": "Coba Sekarang", "href": "https://aurora.app" },
    { "type": "divider" },
    { "type": "footer", "text": "Berhenti langganan kapan saja." }
  ] }

Hasil UI. Email lebar 600px terformat: header berlogo, paragraf sapaan, banner, tombol CTA berwarna merek, garis pemisah, footer unsubscribe. Generator menghasilkan HTML email yang aman-klien (inline CSS, table-based) dari struktur blok yang bersih.

8. Invoice / Kwitansi Generator

Masalah. Faktur harus akurat dan rapi: pihak, item, subtotal, pajak, total. Jangan biarkan model "mengarang" angka dalam prosa.

Bentuk. Metadata + baris item; total dihitung frontend (jangan percaya aritmetika model — validasi ulang).

{ "number": "INV-2026-014", "date": "2026-07-11",
  "from": { "name": "Studio Aurora", "tax": "01.234.567.8" },
  "to":   { "name": "PT Cahaya", "address": "Jakarta" },
  "items": [
    { "desc": "Desain UI",    "qty": 1, "price": 8000000 },
    { "desc": "Pengembangan", "qty": 20, "price": 500000 }
  ],
  "tax": 0.11, "currency": "IDR" }

Hasil UI. Dokumen faktur: kop pengirim/penerima, tabel item dengan qty × harga, subtotal, PPN 11%, dan grand total tebal. Nomor + tanggal di pojok. Tombol "Unduh PDF". Kunci keandalan: hitung total di kode, bukan dari field yang diisi model.

9. Diagram-as-Code

Masalah. Diagram teknis (alur, relasi entitas, jadwal) paling andal lahir dari teks terstruktur, bukan seret-lepas manual.

Bentuk. Dua gaya: sintaks Mermaid (baris teks) atau JSON graf. Satu representasi, banyak jenis: sequence, ERD, gantt, mindmap.

{ "type": "sequence",
  "actors": ["User", "API", "DB"],
  "messages": [
    { "from": "User", "to": "API", "text": "POST /order" },
    { "from": "API",  "to": "DB",  "text": "INSERT order" },
    { "from": "DB",   "to": "API", "text": "ok (id=42)" },
    { "from": "API",  "to": "User","text": "201 Created" }
  ] }
// atau Mermaid mentah:
// sequenceDiagram
//   User->>API: POST /order
//   API->>DB: INSERT order

Hasil UI. JSON/Mermaid dirender jadi diagram SVG oleh pustaka seperti Mermaid. type memilih tata letak: sequence (garis hidup + panah pesan), ERD (tabel + relasi kardinalitas), gantt (batang jadwal), mindmap (cabang radial). Model cukup pandai menulis Mermaid — sering lebih andal daripada memaksa JSON kustom.

10. Landing Page Generator

Masalah. "Buatkan halaman promosi untuk aplikasi X." Jawaban idealnya bukan kode HTML mentah, tapi struktur section yang dirender jadi halaman rapi dan konsisten merek.

Bentuk. Deret sections bertipe hero, features, testimonial, pricing, cta.

{ "sections": [
    { "type": "hero", "headline": "Otomasi tanpa koding",
      "sub": "Rangkai alur kerja dalam menit.", "cta": "Mulai gratis" },
    { "type": "features", "items": [
        { "icon": "zap", "title": "Cepat", "text": "Deploy sekali klik" },
        { "icon": "lock", "title": "Aman", "text": "Enkripsi ujung-ke-ujung" } ] },
    { "type": "cta", "headline": "Siap mencoba?", "button": "Daftar sekarang" }
] }

Hasil UI. Halaman satu-kolom mengalir: hero besar dengan headline + tombol, grid fitur berikon, dan blok CTA penutup. Tiap tipe section memetakan ke komponen bertema — model menentukan pesan, sistem desain menjaga tampilan.

11. Quiz / Course Generator

Masalah. Materi belajar butuh interaktivitas: kuis dengan skor, atau silabus kursus berjenjang. Teks datar tak mengajar.

Bentuk. Untuk kuis: daftar questions dengan opsi + indeks jawaban benar. Untuk kursus: modules → lessons.

{ "quiz": {
    "title": "Dasar JSON",
    "questions": [
      { "q": "Tipe untuk teks?", "options": ["number","string","bool"], "answer": 1 },
      { "q": "Pembungkus objek?", "options": ["[]","{}","()"], "answer": 1 }
    ] },
  "course": {
    "modules": [
      { "title": "Pengenalan", "lessons": ["Apa itu JSON", "Sintaks dasar"] },
      { "title": "Lanjutan",   "lessons": ["Schema", "Validasi"] }
    ] } }

Hasil UI. Kuis interaktif: satu pertanyaan per kartu, opsi jadi tombol, klik menandai benar/salah, skor terakumulasi di akhir. Silabus kursus jadi daftar modul yang bisa dilipat, tiap lesson dengan checkbox progres.

12. Resume / CV Generator

Masalah. CV punya struktur baku (profil, pengalaman, pendidikan, skill) yang layak diformat konsisten dan diekspor rapi.

Bentuk. Selaras dengan standar JSON Resume: basics, work, education, skills.

{ "basics": { "name": "Sari Dewi", "label": "Frontend Engineer",
    "email": "sari@mail.com", "summary": "5 tahun membangun UI." },
  "work": [
    { "company": "Aurora", "position": "Senior FE", "start": "2023",
      "highlights": ["Memimpin migrasi ke React", "Turunkan LCP 40%"] }
  ],
  "education": [ { "institution": "ITB", "area": "Informatika", "year": "2019" } ],
  "skills": ["JavaScript", "React", "CSS", "Accessibility"] }

Hasil UI. CV satu halaman: header nama + jabatan + kontak, ringkasan, timeline pengalaman dengan bullet pencapaian, blok pendidikan, dan tag skill. Satu JSON bisa dirender ke banyak template (kronologis, modern, minimalis) — pisahkan data dari gaya.

13. Data Pipeline / ETL Generator

Masalah. "Tarik data penjualan, bersihkan, agregasi per bulan, muat ke gudang data." Deskripsi itu sebaiknya jadi pipeline berlangkah yang eksplisit dan bisa dijalankan.

Bentuk. Deret steps; tiap langkah punya op (extract, filter, map, aggregate, load) dan konfigurasi.

{ "pipeline": "Penjualan Bulanan",
  "steps": [
    { "op": "extract",   "source": "postgres", "query": "SELECT * FROM sales" },
    { "op": "filter",    "where": "status = 'paid'" },
    { "op": "map",       "add": { "month": "date_trunc('month', created_at)" } },
    { "op": "aggregate", "group": ["month"], "sum": ["amount"] },
    { "op": "load",      "target": "warehouse.monthly_sales" }
  ] }

Hasil UI. Rangkaian kartu langkah berurutan (extract → filter → map → aggregate → load), tiap kartu menampilkan operasi + ringkasan konfigurasi, dihubungkan panah. Mirip Workflow (§3) tapi khusus data. Bisa dikompilasi ke SQL, dbt, atau kode Python.

14. API Mock / OpenAPI Generator

Masalah. Saat frontend menunggu backend, tim butuh mock API yang berperilaku realistis. Deskripsikan endpoint, dapatkan server tiruan.

Bentuk. Subset OpenAPI: paths → method → contoh respons.

{ "openapi": "3.0",
  "paths": {
    "/users": {
      "get": { "summary": "Daftar user",
        "example": [ { "id": 1, "name": "Budi" }, { "id": 2, "name": "Sari" } ] },
      "post": { "summary": "Buat user",
        "request": { "name": "string" }, "example": { "id": 3, "name": "Baru" } } },
    "/users/{id}": {
      "get": { "summary": "Detail user", "example": { "id": 1, "name": "Budi" } } }
  } }

Hasil UI. Dokumentasi interaktif ala Swagger UI: daftar endpoint yang bisa dilipat, badge method berwarna (GET hijau, POST kuning), dan panel "Try it" yang mengembalikan example. Sekaligus menyalakan server mock yang benar-benar menjawab request selama pengembangan.

15. Kanban / Roadmap / Timeline Generator

Masalah. Perencanaan proyek butuh papan visual — kolom status, kartu tugas, atau linimasa rilis. Daftar bullet tak menangkap alur kerja.

Bentuk. Papan = columns, tiap kolom berisi cards. Roadmap menambah tanggal/kuartal.

{ "board": "Sprint 12",
  "columns": [
    { "title": "To Do",       "cards": [ { "text": "Desain onboarding", "tag": "UI" },
                                          { "text": "Riset kompetitor", "tag": "Riset" } ] },
    { "title": "In Progress", "cards": [ { "text": "API pembayaran", "tag": "BE", "assignee": "Sari" } ] },
    { "title": "Done",        "cards": [ { "text": "Setup CI/CD", "tag": "Infra" } ] }
  ] }

Hasil UI. Papan Kanban tiga kolom dengan kartu draggable, tag berwarna, dan avatar assignee. Ganti sumbu jadi waktu, dan struktur yang sama merender roadmap per kuartal atau timeline Gantt. Model menyusun rencana; papan membuatnya bisa dikelola.

Lima belas contoh, satu pola. Begitu Anda melihatnya, Anda tak bisa berhenti: setiap kali berpikir "andai ini divisualisasikan", jawabannya adalah JSON → render.

Penutup Bab Bonus

Studio Expert — Coba Sendiri

Teori tanpa praktik cepat menguap. Playground kecil ini merender tiga dari lima belas generator secara nyata di browser Anda: Slides, Workflow, dan Outline Buku. Tempel JSON (atau muat contoh), tekan Render, dan lihat data berubah jadi artefak. Aman: hanya JSON.parse, tanpa eval.

Dari "Teks" ke "Proyek yang Bisa Diunduh"

Sepanjang buku ini kita memperlakukan output LLM sebagai bahan mentah untuk antarmuka: Markdown jadi artikel, JSON jadi tabel, chart, dan flowchart. Tapi ada satu lompatan terakhir yang membuat banyak orang tercengang saat pertama melihatnya — output yang sama, JSON yang sama jujurnya, bisa mendeskripsikan kode program. Bukan cuma satu cuplikan, melainkan banyak file, banyak bahasa, sebuah proyek lengkap, dikemas rapi jadi arsip yang tinggal diklik unduh.

Pergeseran mentalnya sederhana namun besar: berhentilah berpikir "LLM menulis teks", mulailah berpikir "LLM mengisi struktur". Kalau struktur yang Anda minta adalah {"language":"python","files":[…]}, maka yang keluar adalah file Python. Kalau strukturnya {"projectName":"toko","files":[…]} dengan sepuluh entri, yang keluar adalah kerangka proyek sepuluh file. Model tidak tahu-menahu apakah hasilnya akan Anda tempel ke editor, Anda tulis ke disk, atau Anda bungkus jadi ZIP di dalam browser. Ia hanya mengisi kolom path dan content sebaik-baiknya. Sisanya urusan kode kita.

Deskripsikan dengan JSON, maka ia menjadi kode. Deskripsikan banyak, maka ia menjadi file. Kumpulkan file, maka ia menjadi arsip yang bisa diunduh. Rantai itu — JSON → kode → file → ZIP — adalah keseluruhan bab ini.

Pembuka Bab Generator Kode

Kenapa ini penting secara praktis? Karena "menghasilkan kode" adalah salah satu use case paling bernilai dari LLM, dan hampir semua produk yang serius melakukannya — dari asisten koding, scaffolder proyek, generator SDK, sampai migrator antar-bahasa — pada dasarnya melakukan hal yang sama: meminta model mengisi struktur file, memvalidasinya, lalu menuliskannya. Begitu Anda memahami polanya, Anda bisa membangun versi Anda sendiri tanpa pustaka eksternal, bahkan sepenuhnya di sisi klien. Di akhir bab ada Code Studio: sebuah demo yang mengubah JSON proyek menjadi pohon file yang bisa dijelajahi, lalu membungkusnya jadi .zip asli — arsip ZIP yang kami rakit byte demi byte dengan CRC32 murni JavaScript, tanpa satu pun dependensi.

1. JSON → Kode dalam Bahasa Apa Pun

Bentuk paling dasar dari "JSON menjadi kode" adalah amplop tipis yang membungkus tiga hal: bahasa apa, file mana, isinya apa. Dua bentuk yang sering dipakai:

// Bentuk A — satu bahasa, banyak file
{
  "language": "python",
  "files": [
    { "path": "app.py",          "content": "print('halo dunia')\n" },
    { "path": "requirements.txt", "content": "flask==3.0.0\n" }
  ]
}

// Bentuk B — deskripsi niat, biar model memilih detail
{
  "intent": "fungsi validasi email",
  "language": "typescript"
}

Bentuk A eksplisit: model sudah menuliskan isi tiap file, kode kita tinggal merender atau menyimpannya. Bentuk B lebih ringkas: kita hanya menyampaikan niat dan bahasa, lalu model yang menyusun implementasi lengkap (idealnya tetap mengembalikan Bentuk A sebagai jawaban). Bentuk B enak untuk prompt, Bentuk A enak untuk dieksekusi.

Kunci agar kode kita bisa "menaruh file di tempat yang benar" adalah memetakan ekstensi ke bahasa dan MIME type. Ekstensi menentukan penyorotan sintaks, ikon, dan — yang penting untuk unduhan — tipe MIME pada Blob. Berikut peta yang cukup lengkap untuk dipakai ulang:

Dalam kode, peta ini cukup jadi satu objek pencarian. Perhatikan Dockerfile yang tak punya ekstensi — kita cocokkan berdasarkan basename, bukan ekstensi:

const MIME = {
  js:"text/javascript", ts:"text/typescript", py:"text/x-python",
  go:"text/x-go", java:"text/x-java-source", cs:"text/plain",
  cpp:"text/x-c++src", c:"text/x-csrc", rs:"text/rust",
  php:"application/x-httpd-php", rb:"text/x-ruby", kt:"text/x-kotlin",
  swift:"text/x-swift", dart:"application/dart", sql:"application/sql",
  html:"text/html", css:"text/css", sh:"application/x-sh",
  yaml:"application/yaml", yml:"application/yaml", json:"application/json",
  md:"text/markdown"
};
function mimeFor(path){
  const base = path.split("/").pop();
  if (base === "Dockerfile") return "text/plain";
  const ext = base.includes(".") ? base.split(".").pop().toLowerCase() : "";
  return MIME[ext] || "text/plain";
}

Contoh nyata: satu niat, tiga bahasa berbeda, tiga file berbeda — semuanya keluar dari amplop JSON yang sama bentuknya.

// "Fungsi menjumlahkan array angka" → JavaScript
{ "language":"javascript", "files":[
  { "path":"sum.js",
    "content":"export const sum = (xs) => xs.reduce((a,b) => a+b, 0);\n" } ] }

// → Python
{ "language":"python", "files":[
  { "path":"sum.py",
    "content":"def sum_list(xs):\n    return sum(xs)\n" } ] }

// → Go
{ "language":"go", "files":[
  { "path":"sum.go",
    "content":"package math\n\nfunc Sum(xs []int) int {\n\ttotal := 0\n\tfor _, x := range xs {\n\t\ttotal += x\n\t}\n\treturn total\n}\n" } ] }

2. Satu Spesifikasi, Lima Bahasa Sekaligus

Kalau satu niat bisa jadi satu bahasa, maka satu niat juga bisa jadi lima bahasa sekaligus. Ini terdengar mewah, tapi strukturnya cuma sedikit lebih besar: alih-alih satu objek berisi files, kita minta model mengembalikan peta dari nama bahasa ke daftar file. Use case-nya nyata: dokumentasi API yang menyertakan contoh di banyak bahasa, tutorial lintas-stack, atau pustaka yang perlu paritas fitur di beberapa runtime.

Ambil satu spesifikasi konkret: "REST endpoint CRUD untuk resource user (list, get, create, delete)". Minta model mengembalikan struktur ini:

{
  "spec": "REST CRUD user: list, get, create, delete",
  "targets": {
    "node-express": { "files": [ { "path":"users.js", "content":"…" } ] },
    "python-fastapi": { "files": [ { "path":"users.py", "content":"…" } ] },
    "go-nethttp": { "files": [ { "path":"users.go", "content":"…" } ] },
    "php-slim": { "files": [ { "path":"users.php", "content":"…" } ] },
    "ruby-sinatra": { "files": [ { "path":"users.rb", "content":"…" } ] }
  }
}

Dan inilah wujud isian content untuk tiga di antaranya — perhatikan bahwa bentuk endpoint identik meski idiom tiap bahasa berbeda:

// node-express → users.js
const router = require("express").Router();
let users = [];
router.get("/users", (req, res) => res.json(users));
router.get("/users/:id", (req, res) => {
  const u = users.find(x => x.id === req.params.id);
  return u ? res.json(u) : res.status(404).end();
});
router.post("/users", (req, res) => {
  const u = { id: String(Date.now()), ...req.body };
  users.push(u); res.status(201).json(u);
});
router.delete("/users/:id", (req, res) => {
  users = users.filter(x => x.id !== req.params.id);
  res.status(204).end();
});
module.exports = router;

# python-fastapi → users.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from uuid import uuid4

app = FastAPI()
users: dict[str, dict] = {}

class User(BaseModel):
    name: str

@app.get("/users")
def list_users():
    return list(users.values())

@app.get("/users/{uid}")
def get_user(uid: str):
    if uid not in users:
        raise HTTPException(404)
    return users[uid]

@app.post("/users", status_code=201)
def create_user(u: User):
    uid = str(uuid4())
    users[uid] = {"id": uid, **u.dict()}
    return users[uid]

@app.delete("/users/{uid}", status_code=204)
def delete_user(uid: str):
    users.pop(uid, None)

// go-nethttp → users.go (ringkas)
package main

import ( "encoding/json"; "net/http"; "sync" )

var mu sync.Mutex
var users = map[string]map[string]any{}

func handler(w http.ResponseWriter, r *http.Request) {
	mu.Lock(); defer mu.Unlock()
	switch r.Method {
	case http.MethodGet:
		json.NewEncoder(w).Encode(users)
	case http.MethodPost:
		var u map[string]any
		json.NewDecoder(r.Body).Decode(&u)
		users["1"] = u
		w.WriteHeader(http.StatusCreated)
	case http.MethodDelete:
		delete(users, r.URL.Query().Get("id"))
		w.WriteHeader(http.StatusNoContent)
	}
}

Prompt / schema yang menghasilkan struktur ini

Agar model konsisten mengembalikan peta multi-bahasa, kunci-nya adalah menutup ruang jawaban dengan schema, sama seperti Bab 4. Sampaikan daftar target yang diizinkan dan minta hanya JSON:

System: Anda generator kode. Balas HANYA JSON valid, tanpa penjelasan,
sesuai schema. Setiap "content" adalah kode lengkap yang bisa dijalankan.

Schema (JSON Schema, disederhanakan):
{
  "type":"object",
  "required":["spec","targets"],
  "properties":{
    "spec":{"type":"string"},
    "targets":{
      "type":"object",
      "propertyNames":{"enum":[
        "node-express","python-fastapi","go-nethttp","php-slim","ruby-sinatra"
      ]},
      "additionalProperties":{
        "type":"object",
        "required":["files"],
        "properties":{"files":{"type":"array","items":{
          "type":"object","required":["path","content"],
          "properties":{"path":{"type":"string"},"content":{"type":"string"}}
        }}}
      }
    }
  }
}

User: REST CRUD untuk resource "user": list, get, create, delete.

3. Scaffold: Banyak File jadi Satu Pohon Proyek

Naik satu tingkat lagi: alih-alih satu file, kita minta seluruh kerangka proyek. Strukturnya nyaris tak berubah — hanya jumlah entri di files yang membengkak, dan path kini mengandung sub-folder seperti src/, tests/. Dari daftar path yang datar itu, kode kita merekonstruksi pohon file: setiap / pada path adalah satu tingkat folder.

{
  "projectName": "notes-api",
  "files": [
    { "path": "package.json",        "content": "…" },
    { "path": "src/index.js",        "content": "…" },
    { "path": "src/routes/notes.js", "content": "…" },
    { "path": "src/db.js",           "content": "…" },
    { "path": "tests/notes.test.js", "content": "…" },
    { "path": "Dockerfile",          "content": "…" },
    { "path": "README.md",           "content": "…" }
  ]
}

Daftar datar di atas menjadi pohon berikut saat dirender — persis seperti yang Anda lihat di sidebar editor:

notes-api/
├─ package.json
├─ Dockerfile
├─ README.md
└─ src/
   ├─ index.js
   ├─ db.js
   └─ routes/
      └─ notes.js
   tests/
   └─ notes.test.js

Membangun pohon dari daftar path adalah latihan rekursi kecil: pecah tiap path pada /, lalu sisipkan tiap segmen ke node anak. Inilah inti yang dipakai Code Studio untuk menggambar sidebar-nya:

function buildTree(paths){
  const root = {};
  for (const p of paths){
    let node = root;
    for (const seg of p.split("/")){
      node[seg] = node[seg] || {};
      node = node[seg];
    }
  }
  return root;               // {} kosong = daun (file)
}

Tiga contoh scaffold mini

Next.js mini — halaman + komponen + config:

{ "projectName":"web-mini", "files":[
  { "path":"package.json",      "content":"{\n  \"name\":\"web-mini\",\n  \"scripts\":{\"dev\":\"next dev\"},\n  \"dependencies\":{\"next\":\"14\",\"react\":\"18\",\"react-dom\":\"18\"}\n}\n" },
  { "path":"pages/index.jsx",   "content":"export default function Home(){\n  return 
Halo dari Next.js
;\n}\n" },
  { "path":"components/Hero.jsx","content":"export const Hero = ({t}) => 
{t}
;\n" },
  { "path":"next.config.js",    "content":"module.exports = { reactStrictMode: true };\n" } ] }

FastAPI mini — app + model + requirements:

{ "projectName":"api-mini", "files":[
  { "path":"main.py",         "content":"from fastapi import FastAPI\napp = FastAPI()\n\n@app.get('/health')\ndef health():\n    return {'ok': True}\n" },
  { "path":"models.py",       "content":"from pydantic import BaseModel\n\nclass Item(BaseModel):\n    name: str\n    price: float\n" },
  { "path":"requirements.txt","content":"fastapi\nuvicorn\n" },
  { "path":"Dockerfile",      "content":"FROM python:3.12-slim\nWORKDIR /app\nCOPY . .\nRUN pip install -r requirements.txt\nCMD [\"uvicorn\",\"main:app\",\"--host\",\"0.0.0.0\"]\n" } ] }

Go mini — module + main + test:

{ "projectName":"cli-mini", "files":[
  { "path":"go.mod",       "content":"module cli-mini\n\ngo 1.22\n" },
  { "path":"main.go",      "content":"package main\n\nimport \"fmt\"\n\nfunc main(){ fmt.Println(Greet(\"dunia\")) }\n\nfunc Greet(n string) string { return \"halo \" + n }\n" },
  { "path":"main_test.go", "content":"package main\n\nimport \"testing\"\n\nfunc TestGreet(t *testing.T){\n\tif Greet(\"x\") != \"halo x\" { t.Fail() }\n}\n" } ] }

4. Membungkus Semuanya jadi Satu ZIP — di Browser

Punya sepuluh file di memori itu bagus, tapi pengguna ingin satu tombol, satu unduhan. Jawabannya arsip ZIP. Yang mengejutkan banyak orang: Anda bisa merakit file ZIP yang valid sepenuhnya di browser, tanpa server dan tanpa pustaka, karena format ZIP sederhananya cukup ramah untuk ditulis tangan.

Anatomi file ZIP

Sebuah file ZIP, dibaca dari awal ke akhir, adalah rangkaian tiga jenis blok:

1. Local file header + data — untuk tiap file: sebuah header yang diawali tanda tangan PK\x03\x04, berisi metadata (metode kompresi, CRC-32, ukuran, panjang nama), lalu byte isi file itu sendiri. Blok ini berulang sekali per file.
2. Central directory — setelah semua file, sebuah "daftar isi" yang mengulang metadata tiap file (tanda tangan PK\x01\x02) plus offset tempat header lokalnya berada. Inilah yang dibaca pengekstrak untuk melompat cepat antar-file.
3. End of central directory (EOCD) — satu blok penutup (PK\x05\x06) yang memberi tahu berapa banyak entri, di mana central directory mulai, dan berapa ukurannya.

Store vs Deflate

Field "metode kompresi" pada header menentukan bagaimana data disimpan. Dua nilai paling umum:

• Store (metode 0) — data disimpan apa adanya, tanpa kompresi. Ukuran terkompresi sama persis dengan ukuran asli. Tak butuh algoritma apa pun; hanya menyalin byte. Inilah yang membuat ZIP bisa ditulis tangan.
• Deflate (metode 8) — data dikompresi dengan algoritma DEFLATE (LZ77 + Huffman). Ukuran lebih kecil, tapi butuh implementasi kompresor yang jauh lebih rumit (atau CompressionStream bawaan browser modern).

CRC-32: sidik jari tiap file

Setiap header ZIP menyimpan CRC-32 dari isi file — sebuah checksum 32-bit yang dipakai pengekstrak untuk memverifikasi integritas. Menghitungnya butuh sebuah tabel 256-entri yang dibangun sekali, lalu iterasi byte:

const CRC_TABLE = (() => {
  const t = new Uint32Array(256);
  for (let n = 0; n < 256; n++){
    let c = n;
    for (let k = 0; k < 8; k++)
      c = (c & 1) ? (0xEDB88320 ^ (c >>> 1)) : (c >>> 1);
    t[n] = c >>> 0;
  }
  return t;
})();

function crc32(bytes){
  let crc = 0xFFFFFFFF;
  for (let i = 0; i < bytes.length; i++)
    crc = CRC_TABLE[(crc ^ bytes[i]) & 0xFF] ^ (crc >>> 8);
  return (crc ^ 0xFFFFFFFF) >>> 0;
}

Dengan CRC-32 dan pengetahuan tentang tiga blok tadi, merakit ZIP tinggal menumpuk byte dengan urutan yang benar. Setiap angka multi-byte ditulis little-endian (byte terkecil dulu). Anda akan melihat implementasi lengkapnya berjalan di Code Studio; ini kerangka konseptualnya:

function zipStore(files){                 // files: [{path, bytes}]
  const u16 = n => [n & 255, (n >>> 8) & 255];
  const u32 = n => [n&255,(n>>>8)&255,(n>>>16)&255,(n>>>24)&255];
  const chunks = [], central = []; let offset = 0;

  for (const f of files){
    const name = utf8(f.path), data = f.bytes, crc = crc32(data);
    const h = [ 0x50,0x4B,0x03,0x04, ...u16(20), ...u16(0x0800),
      ...u16(0), ...u16(0), ...u16(0), ...u32(crc),
      ...u32(data.length), ...u32(data.length),
      ...u16(name.length), ...u16(0), ...name ];
    chunks.push(new Uint8Array(h), data);
    central.push([ 0x50,0x4B,0x01,0x02, ...u16(20), ...u16(20),
      ...u16(0x0800), ...u16(0), ...u16(0), ...u16(0), ...u32(crc),
      ...u32(data.length), ...u32(data.length), ...u16(name.length),
      ...u16(0), ...u16(0), ...u16(0), ...u16(0), ...u32(0),
      ...u32(offset), ...name ]);
    offset += h.length + data.length;
  }
  const cd = central.flat(), cdStart = offset;
  const eocd = [ 0x50,0x4B,0x05,0x06, ...u16(0), ...u16(0),
    ...u16(files.length), ...u16(files.length),
    ...u32(cd.length), ...u32(cdStart), ...u16(0) ];
  // gabung semua chunk + cd + eocd → satu Uint8Array → Blob
}

Tanda tangan PK (0x50 0x4B) adalah inisial Phil Katz, pencipta format ZIP pada 1989. Byte-byte itulah yang dilihat pengekstrak untuk mengenali "ini file ZIP".

5. ZIP Berisi Kode + Dokumentasi + PDF

Arsip yang benar-benar berguna bukan cuma kode telanjang. Ia menyertakan konteks: berkas README.md yang menjelaskan cara menjalankan, dokumentasi HTML yang bisa dibuka di browser, dan — bila diminta — catatan rilis dalam PDF. Karena semua isi ZIP pada dasarnya "byte + nama path", menambahkan dokumen sama mudahnya dengan menambahkan file kode.

README.md yang dihasilkan otomatis

README bisa dirakit dari metadata proyek yang sudah kita punya — nama proyek dan daftar path — tanpa memanggil model lagi:

function makeReadme(project, files){
  const tree = files.map(f => "- `" + f.path + "`").join("\n");
  return `# ${project}\n\n` +
    `Proyek ini dihasilkan dari deskripsi JSON dan dibundel di browser.\n\n` +
    `## Struktur\n\n${tree}\n\n` +
    `## Menjalankan\n\n` +
    "```bash\n# sesuaikan dengan stack Anda\nnpm install && npm start\n```\n";
}

docs.html yang bisa langsung dibuka

Dokumentasi HTML enak karena berdiri sendiri: klik dua kali, terbuka di browser. Kita rakit satu halaman ringkas berisi daftar file dan cuplikan awalnya. Perhatikan setiap isi file di-escape agar tak merusak markup:

function makeDocsHtml(project, files){
  const rows = files.map(f =>
    "<h2>" + esc(f.path) + "</h2><pre>" +
    esc(f.content.slice(0, 400)) + "</pre>"
  ).join("");
  return "<!doctype html><meta charset=utf-8><title>" +
    esc(project) + " — Docs</title><h1>" + esc(project) +
    "</h1>" + rows;
}

Kedua string di atas tinggal dibungkus dengan utf8() menjadi byte, diberi path README.md dan docs.html, lalu dimasukkan ke daftar file sebelum zipStore() dipanggil. Code Studio melakukan ini otomatis untuk setiap unduhan ZIP.

Opsi PDF

PDF sedikit lebih menantang karena formatnya biner dan berlapis. Ada tiga jalur, dari paling ringan ke paling berat:

6. Use Case Super Ekstrem

Begitu Anda menerima "JSON mendeskripsikan file", pintu terbuka lebar. Berikut delapan penggunaan yang, di permukaan, terlihat seperti produk berbeda — padahal semuanya varian dari pola yang sama: minta model mengisi struktur file, validasi, render/bundel.

a. Monorepo generator

Satu deskripsi tingkat-tinggi ("web app + API + shared types") menjadi beberapa paket sekaligus dalam satu repo, lengkap dengan konfigurasi workspace.

{ "monorepo":"shop", "packages":{
    "apps/web":  { "files":[ {"path":"package.json","content":"…"} ] },
    "apps/api":  { "files":[ {"path":"package.json","content":"…"} ] },
    "packages/types": { "files":[ {"path":"index.ts","content":"export type User = { id:string };\n"} ] }
} }
// hasil: pnpm-workspace.yaml + tiga package.json + tsconfig base — pohon monorepo utuh

b. Migrasi / transpile antar-bahasa

Beri model kode sumber di satu bahasa, minta padanannya di bahasa lain. LLM unggul di sini karena migrasi bukan sekadar sintaks — ia butuh memahami idiom.

{ "from":"python", "to":"go",
  "source":"def add(a,b):\n    return a+b\n" }
// respons:
{ "language":"go", "files":[ { "path":"add.go",
  "content":"package main\n\nfunc Add(a, b int) int { return a + b }\n" } ] }

c. Boilerplate / starter kit

Pilihan opsi ("auth: ya, db: postgres, css: tailwind") menjadi starter yang sudah dikonfigurasi — menghemat jam-jam setup awal.

{ "starter":"saas", "options":{"auth":true,"db":"postgres","css":"tailwind"},
  "files":[ {"path":".env.example","content":"DATABASE_URL=\nAUTH_SECRET=\n"},
            {"path":"tailwind.config.js","content":"module.exports={content:['./src/**/*']}\n"} ] }

d. Generator SDK dari OpenAPI

Beri spesifikasi OpenAPI, minta klien SDK typed. Ini pola nyata di banyak platform API.

{ "openapi":"3.0", "paths":{"/users":{"get":{"operationId":"listUsers"}}},
  "target":"typescript-fetch" }
// respons → sdk.ts
{ "language":"typescript", "files":[ { "path":"sdk.ts",
  "content":"export async function listUsers(){\n  const r = await fetch('/users');\n  return r.json();\n}\n" } ] }

e. Test generator

Beri fungsi, minta suite pengujian dengan kasus tepi. Naikkan cakupan tanpa menulis boilerplate tes secara manual.

{ "target":"jest", "unit":"export const slugify = s => s.toLowerCase().replace(/\\s+/g,'-');" }
// respons → slugify.test.js
{ "files":[ { "path":"slugify.test.js",
  "content":"import { slugify } from './slugify';\n\ntest('spasi jadi dash', () => {\n  expect(slugify('Halo Dunia')).toBe('halo-dunia');\n});\ntest('kosong', () => expect(slugify('')).toBe(''));\n" } ] }

f. Config / Infrastructure-as-Code

Deskripsi infrastruktur ("3 replika nginx di K8s" atau "bucket S3 + CDN") menjadi manifest Terraform atau YAML Kubernetes.

{ "iac":"kubernetes", "want":"deployment nginx 3 replika port 80" }
// respons → deploy.yaml
{ "files":[ { "path":"deploy.yaml",
  "content":"apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  replicas: 3\n  selector:\n    matchLabels: { app: nginx }\n  template:\n    metadata:\n      labels: { app: nginx }\n    spec:\n      containers:\n      - name: nginx\n        image: nginx:1.27\n        ports:\n        - containerPort: 80\n" } ] }

{ "iac":"terraform", "want":"bucket S3 privat bernama assets-prod" }
// respons → main.tf
{ "files":[ { "path":"main.tf",
  "content":"resource \"aws_s3_bucket\" \"assets\" {\n  bucket = \"assets-prod\"\n}\n\nresource \"aws_s3_bucket_acl\" \"assets\" {\n  bucket = aws_s3_bucket.assets.id\n  acl    = \"private\"\n}\n" } ] }

g. Dokumentasi otomatis dari kode

Balik arah: beri kode, minta dokumentasinya. Model membaca fungsi dan menghasilkan referensi API dalam Markdown.

{ "documentFrom":"src/auth.js", "code":"export function login(email, pass){ /* … */ }",
  "format":"markdown" }
// respons → docs/auth.md
{ "files":[ { "path":"docs/auth.md",
  "content":"## `login(email, pass)`\n\nMemvalidasi kredensial dan mengembalikan token sesi.\n\n| Param | Tipe | Deskripsi |\n|---|---|---|\n| email | string | Alamat email pengguna |\n| pass | string | Kata sandi mentah |\n" } ] }

h. i18n bundle generator

Beri daftar kunci dan bahasa target, terima berkas terjemahan lengkap per-locale — satu file JSON per bahasa.

{ "i18n":{"keys":{"greeting":"Halo","bye":"Sampai jumpa"},
          "locales":["en","ja","fr"]} }
// respons → tiga file:
{ "files":[
  { "path":"locales/en.json", "content":"{\n  \"greeting\": \"Hello\",\n  \"bye\": \"Goodbye\"\n}\n" },
  { "path":"locales/ja.json", "content":"{\n  \"greeting\": \"こんにちは\",\n  \"bye\": \"さようなら\"\n}\n" },
  { "path":"locales/fr.json", "content":"{\n  \"greeting\": \"Bonjour\",\n  \"bye\": \"Au revoir\"\n}\n" } ] }

Delapan produk, satu mesin. Ganti nama field, ganti prompt, dan generator scaffold Anda berubah jadi migrator, lalu jadi generator SDK, lalu jadi mesin i18n — tanpa mengubah pipa inti: isi struktur, validasi, bundel.

Bab Generator Kode

7. Keamanan & Batas

Menghasilkan kode dari output model adalah fitur bertenaga, dan seperti semua fitur bertenaga, ia butuh rem. Berikut tujuh penjaga yang wajib dipasang sebelum sistem seperti ini menyentuh produksi.

1. Validasi path — cegah path traversal. Model bisa (sengaja atau tidak) mengembalikan path seperti ../../etc/passwd atau path absolut /root/.ssh/id_rsa. Kalau Anda menuliskan file ke disk, ini berbahaya. Tolak path yang mengandung .., diawali / atau \, atau mengandung drive letter Windows (C:).
2. Sanitasi nama file. Buang karakter kontrol dan karakter ilegal untuk sistem berkas (< > : " | ? *), pangkas spasi berlebih, dan tetapkan panjang maksimum per segmen.
3. Batasi ukuran & jumlah. Plafon jumlah file dan total byte (lihat Bab 3 di atas). Cegah "zip bomb" versi generatif — model yang tanpa henti menghasilkan file.
4. Jangan pernah eksekusi kode tanpa sandbox. Kode yang dihasilkan adalah data tak tepercaya. Jangan eval, jangan new Function, jangan child_process di atasnya. Bila perlu menjalankannya, gunakan sandbox terisolasi (container efemeral, WASM, worker dengan hak minimal) dan timeout.
5. Escape saat menampilkan. Isi file bisa mengandung <script> atau markup lain. Saat merender preview ke DOM, selalu lewati fungsi escape — jangan pernah innerHTML dengan konten mentah. (Code Studio memakai textContent / escape untuk seluruh preview.)
6. Perlakukan konten sebagai teks, bukan perintah. Jangan interpolasikan isi file ke dalam shell command, query SQL, atau template server tanpa parametrisasi. Konten hanyalah byte tujuan; ia tak boleh membocorkan konteks.
7. Beri jejak & batas laju. Catat siapa menghasilkan apa, dan batasi laju permintaan generatif agar tak jadi vektor biaya (setiap generasi = panggilan model berbayar).

Fungsi penjaga path minimal yang layak Anda salin:

function safePath(p){
  const s = String(p).replace(/\\/g, "/").trim();
  if (!s) return null;
  if (s.startsWith("/")) return null;               // absolut
  if (/^[a-zA-Z]:/.test(s)) return null;            // drive Windows
  const segs = s.split("/");
  for (const seg of segs){
    if (seg === "" || seg === "." || seg === "..") return null;   // traversal
    if (/[\x00-\x1f<>:"|?*]/.test(seg)) return null;         // karakter ilegal
    if (seg.length > 120) return null;                            // segmen kepanjangan
  }
  return segs.join("/");
}

Code Studio — Coba Sendiri

Inilah puncak bab: sebuah generator kode mini yang benar-benar berfungsi di browser Anda. Tempel (atau muat) JSON proyek berbentuk {"project":"nama","files":[{"path":"src/index.js","content":"…"}]}, tekan Render, dan lihat daftar path berubah jadi pohon file yang bisa diklik. Pilih sebuah file untuk melihat isinya (di-escape, aman), unduh file itu sendiri dengan MIME & ekstensi benar, atau unduh seluruh proyek sebagai .zip asli — arsip yang dirakit byte demi byte dengan CRC-32 murni JavaScript, plus README.md dan docs.html yang dihasilkan otomatis. Nol dependensi, nol eval.

Merender Sambil Token Mengalir

Pengguna modern terbiasa melihat jawaban muncul seketika, huruf demi huruf. Rahasianya bukan kecepatan model semata, melainkan streaming UI: antarmuka yang menggambar ulang dirinya tiap kali sepotong token tiba.

Ada tiga keadaan yang harus ditangani dengan anggun:

1. Kosong → Skeleton. Sebelum token pertama, tampilkan kerangka abu-abu (skeleton) berbentuk seperti hasil akhir: garis untuk paragraf, kotak untuk chart. Ini mengurangi kecemasan "apakah macet?".
2. Parsial → Render progresif. Saat token mengalir, render ulang dari buffer. Untuk Markdown, render tiap ~50ms. Untuk JSON, pakai partial parser (Bab 4) dan tampilkan field yang sudah lengkap.
3. Selesai → Finalisasi. Saat sinyal selesai tiba, lakukan render final penuh (validasi schema, highlight, interaktivitas) dan hapus skeleton.

// klien — kerangka streaming (konsep)
let buf = "";
for await (const token of stream) {
  buf += token;
  jadwalkanRender();                 // throttle ~50ms
}
function render() {
  const objek = parsePartial(buf);   // toleran terhadap JSON belum lengkap
  if (!objek) return tampilkanSkeleton();
  tampilkanKomponen(objek, { final: false });
}

Throttling & kehalusan

Jangan render tiap token — itu memicu ratusan re-render per detik dan membuat teks "bergetar". Kumpulkan token dan render pada interval tetap (mis. 30–60ms) atau lewat requestAnimationFrame. Untuk chart yang bertumbuh, animasikan tinggi batang agar transisi terasa mulus alih-alih melompat.

A user interface is well-designed when the program behaves exactly how the user thought it would.

Jef Raskin, The Humane Interface

Skeleton yang berbentuk hasil akhir

Skeleton terbaik menyerupai komponen yang akan muncul. Bila hasilnya chart, tampilkan batang abu-abu; bila tabel, tampilkan baris-baris pucat. Ini menjaga tata letak stabil sehingga tidak ada "lompatan" saat data tiba (mengurangi layout shift).

// klien — skeleton sederhana untuk chart
function skeletonChart() {
  return `<div class="skeleton">
    <div class="bar" style="height:60%"></div>
    <div class="bar" style="height:40%"></div>
    <div class="bar" style="height:80%"></div>
  </div>`;
}
// css: .skeleton .bar { background:#2a2450; animation:pulse 1.2s infinite; }
// @keyframes pulse { 50% { opacity:.4 } }

Rangkaian pengalaman yang mulus: pengguna menekan kirim → skeleton muncul seketika (0 ms terasa) → batang bertumbuh saat nilai di-stream → finalisasi menambahkan label dan interaktivitas. Dari sudut pandang pengguna, antarmuka "hidup" sejak detik pertama, jauh sebelum model selesai berpikir.

Tool-Calling menjadi UI

Arsitektur generative UI yang matang memandang setiap komponen sebagai sebuah tool. Model tidak menggambar UI; ia memanggil tool dengan argumen, dan lapisan render menerjemahkan panggilan itu menjadi komponen. Pendekatan ini — dipopulerkan antara lain oleh Vercel AI SDK dengan React Server Components sebagai konsep — memisahkan "keputusan model" dari "cara render".

Kontrak Komponen

Kontrak adalah kesepakatan tertulis tentang komponen apa yang ada, props apa yang diterimanya, dan artinya. Ia hidup di dua tempat sekaligus: sebagai schema tool yang dilihat model, dan sebagai validator di frontend. Menjaga keduanya sinkron adalah inti keandalan.

// kontrak tunggal, dua konsumen
export const kontrakChart = {
  nama: "chart",
  schema: { /* JSON Schema untuk labels, values, judul */ },
  render: (props) => renderChart(props),   // frontend
};
// schema dikirim ke model sebagai definisi tool;
// render dipakai registry saat tool dipanggil.

Versioning

Komponen berevolusi: props ditambah, dinamai ulang, dibuang. Bila model dan frontend tak sepakat versi, UI patah. Karena itu, beri versi pada kontrak.

• Beri versi tiap komponen (mis. chart@2). Frontend mendukung beberapa versi selama masa transisi.
• Tambah, jangan ubah. Bila mungkin, tambahkan props opsional baru alih-alih mengganti yang lama, agar output model lama tetap terrender.
• Degradasi anggun. Props tak dikenal diabaikan; komponen tak dikenal jadi placeholder. Jangan pernah membuat seluruh jawaban gagal karena satu field asing.
• Uji kontrak. Simpan contoh output tiap komponen sebagai fixture; jalankan tes yang memastikan renderer masih menerimanya setelah perubahan.

Kenapa Ini Peluang Besar

Ada asimetri menarik hari ini: model sudah luar biasa pandai menghasilkan struktur, tetapi mayoritas aplikasi masih menampilkannya sebagai teks. Jarak antara "kecerdasan model" dan "cara ia disajikan" adalah ruang produk yang luas dan belum terisi. Siapa yang menutup jarak itu memenangkan pengalaman.

Tiga tren memperkuat peluang ini. Pertama, structured outputs kini murah dan andal, jadi meminta JSON berschema tak lagi rapuh. Kedua, ekspektasi pengguna naik: setelah melihat satu produk menampilkan dashboard dari chat, teks datar terasa usang. Ketiga, biaya membangun komponen turun karena pola registry bisa dipakai ulang lintas produk.

Good design is as little design as possible.

Dieter Rams

Produk yang Bisa Dibangun

Model Bisnis

Lapisan render ini bisa dimonetisasi dalam beberapa bentuk: sebagai fitur premium di produk yang sudah ada (chat biasa gratis, chat yang menghasilkan dashboard berbayar); sebagai platform/SDK yang menjual registry komponen dan kontrak siap pakai ke developer lain; atau sebagai produk vertikal yang fokus pada satu industri (mis. BI copilot untuk ritel). Kunci pembeda bukan modelnya — semua orang memakai model serupa — melainkan kualitas komponen, keamanan render, dan kehalusan pengalaman.

Metrik Keberhasilan

Bagaimana tahu lapisan render Anda berhasil? Ukur, jangan menebak. Beberapa metrik yang berkorelasi kuat dengan nilai produk:

Perusahaan yang menang di ruang ini bukan yang punya model terbaik — semua memakai model serupa — melainkan yang metrik interaksi dan keamanannya konsisten unggul dari waktu ke waktu.

Tujuh Aturan Bertahan Hidup

Perlakukan setiap output LLM seperti kiriman dari orang asing. Model bisa dibujuk (prompt injection) atau mengutip data beracun. Berikut lapisan pertahanan, diurutkan dari paling wajib.

1. Escape dulu, selalu. Setiap teks yang masuk DOM harus di-escape (<, >, &, kutip). Ini menetralkan mayoritas XSS sebelum sempat terjadi.
2. Jangan pernah eval. Untuk JSON pakai JSON.parse, bukan eval atau new Function. Untuk kode yang perlu dijalankan, isolasi total.
3. Validasi terhadap schema. Tolak bentuk yang tak sesuai. Data yang lolos validasi jauh lebih aman dirender dan lebih mudah diprediksi.
4. Allowlist komponen & tag. Hanya render komponen dari registry, dan bila mengizinkan HTML, sanitasi dengan allowlist tag/atribut. Buang handler on* dan URL javascript:.
5. Sandbox iframe untuk konten berisiko. Kode yang dijalankan, HTML kaya, atau embed pihak ketiga sebaiknya di <iframe sandbox> tanpa allow-same-origin bila memungkinkan, tanpa akses jaringan yang tak perlu.
6. Batasi ukuran & kedalaman. Batasi panjang string, jumlah baris tabel, jumlah node, dan kedalaman nesting. Output raksasa bisa membekukan browser (DoS).
7. Waspadai URL & media. Izinkan hanya skema aman (http/https/mailto), allowlist domain untuk gambar/embed, dan tambahkan rel="noopener noreferrer" pada tautan tab baru.

// klien — sanitasi tautan
function urlAman(u) {
  try {
    const url = new URL(u, location.href);
    return ["http:", "https:", "mailto:"].includes(url.protocol) ? url.href : "#";
  } catch (_) { return "#"; }
}

Simplicity is prerequisite for reliability.

Edsger W. Dijkstra

Satu Lapisan yang Mengubah Segalanya

Kita berangkat dari keluhan sederhana: chatbot memuntahkan ##### dan **. Kita tiba pada sebuah disiplin: mengubah output model menjadi antarmuka hidup lewat parsing Markdown yang aman dan JSON berschema yang dipetakan ke komponen. Di antara keduanya terbentang kelas produk baru.

Inti yang perlu Anda bawa pulang: model menghasilkan struktur; tugas Anda menyajikannya. Pakai Markdown untuk prosa, JSON berschema untuk data dan komponen. Selalu escape dan validasi. Rancang registry komponen dengan kontrak ber-versi. Render bertahap saat streaming. Dan jaga keamanan seolah setiap output berasal dari penyerang. Lakukan itu, dan chatbot Anda berhenti terasa seperti terminal — mulai terasa seperti produk.

Cara Buku Ini Dibaca AI

Buku ini sengaja ditulis agar berguna bukan hanya bagi manusia, tetapi juga bila diberikan sebagai konteks kepada sebuah model. Bila Anda sebuah asisten AI yang sedang membaca dokumen ini, berikut cara memanfaatkannya.

• Struktur. Dokumen memakai heading semantik (h3 untuk topik, h4 untuk subtopik) dan penanda seksi ber-id. Setiap bab punya tujuan tunggal yang bisa dikutip terpisah.
• Pola yang bisa dipakai ulang. Blok kode berlabel // prompt, // klien, // server adalah cetak biru. Saat pengguna meminta implementasi, adaptasikan pola terdekat alih-alih mengarang dari nol.
• Kontrak komponen. Bentuk JSON pada Bab 6 adalah kontrak konkret. Bila diminta menghasilkan UI, keluarkan JSON yang cocok dengan salah satu bentuk itu agar bisa dirender oleh registry seperti di Playground.
• Aturan keamanan tidak opsional. Saat menyarankan kode render, sertakan escape, validasi, dan allowlist. Jangan pernah menyarankan innerHTML mentah atau eval.
• Ringkasan satu kalimat. Bila diminta meringkas buku ini: "Panduan praktik mengubah output LLM (Markdown/JSON) menjadi UI kaya — tabel, chart, flowchart, form, dashboard — secara aman lewat parsing, structured output, dan registry komponen ber-kontrak."

FAQ

Glosarium

Checklist Membangun Lapisan Render