Menggunakan Claude Code: Efisiensi HTML yang Mengejutkan

 (twitter.com/trq212)
5 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Jika HTML digunakan sebagai format output alih-alih Markdown di Claude Code, hasilnya bisa memuat visualisasi, warna, diagram, dan interaksi yang lebih kaya sehingga lebih mudah dibaca dan ditinjau manusia
  • HTML dapat merepresentasikan sebagian besar informasi yang bisa dibaca Claude secara efisien melalui tabel, CSS, SVG, script, interaksi JavaScript, gambar, kanvas, dan posisi absolut
  • Claude Code dapat membaca konteks seperti sistem file, MCP, browser, dan riwayat Git lalu merangkainya menjadi hasil HTML, dan bisa dimulai hanya dengan meminta, “buatkan file HTML”
  • Cara pemanfaatan utamanya terbagi menjadi spesifikasi·rencana·eksplorasi, code review dan pemahaman kode, desain dan prototipe, laporan·riset·pembelajaran, serta antarmuka edit sekali pakai yang disesuaikan
  • HTML membutuhkan waktu pembuatan 2–4 kali lebih lama dibanding Markdown dan diff-nya berisik sehingga version control menjadi lebih sulit, tetapi kelebihan dalam daya ekspresi, kemudahan berbagi, dan kemungkinan benar-benar dibaca dianggap lebih besar

Alasan mulai lebih memilih HTML daripada Markdown

  • Markdown telah menjadi format file dominan bagi agen untuk berkomunikasi dengan manusia: sederhana, portabel, mampu mengekspresikan sedikit pemformatan, dan mudah diedit langsung oleh manusia
  • Claude juga cukup baik membuat diagram ASCII di dalam Markdown, tetapi seiring agen menjadi lebih kuat, Markdown terasa sebagai format yang membatasi
  • File Markdown yang melebihi 100 baris sulit dibaca, dan muncul keinginan untuk membagikan visualisasi, warna, dan diagram yang lebih kaya dengan mudah
  • Karena makin sering meminta Claude untuk mengedit file secara langsung alih-alih mengeditnya sendiri, nilai keunggulan utama Markdown—mudah diedit langsung—menjadi berkurang
  • Bahkan di dalam tim Claude Code sendiri, penggunaan HTML sebagai format output makin meningkat, dan contohnya dapat dilihat di html-effectiveness

Daya ekspresi dan kemudahan berbagi HTML

  • HTML dapat mengekspresikan bukan hanya struktur dokumen seperti judul dan pemformatan, tetapi juga jauh lebih banyak jenis informasi daripada Markdown
  • Informasi yang bisa direpresentasikan mencakup data tabel melalui tabel, data desain melalui CSS, ilustrasi SVG, potongan kode melalui tag script, serta interaksi menggunakan JavaScript dan CSS
  • Alur kerja dapat ditampilkan dengan SVG dan HTML, data spasial dapat diekspresikan dengan posisi absolut dan kanvas, dan gambar dapat dimasukkan dengan tag img
  • Sebagian besar himpunan informasi yang bisa dibaca Claude dapat direpresentasikan cukup efisien dalam HTML, sehingga format ini efisien baik untuk model dalam menyampaikan informasi mendalam maupun untuk manusia saat meninjaunya
  • Tanpa HTML, Claude bisa saja terpaksa membuat diagram ASCII di Markdown atau menggunakan representasi tidak efisien seperti menebak warna lewat karakter Unicode
  • Saat Claude mengerjakan tugas yang lebih kompleks, ia juga menulis spesifikasi dan rencana yang lebih besar, dan faktanya file Markdown dengan lebih dari 100 baris memang tidak terlalu terbaca
  • Dokumen HTML dapat disusun secara visual menggunakan tab, ilustrasi, dan tautan sehingga mudah dinavigasi, serta dapat dibuat responsif untuk seluler agar terbaca berbeda sesuai ukuran layar
  • File Markdown tidak dirender dengan baik secara bawaan oleh browser sehingga sering perlu dilampirkan ke email atau pesan, sedangkan HTML mudah dibagikan lewat tautan jika diunggah ke tempat seperti S3
  • Spesifikasi, laporan, dan penjelasan PR berbentuk HTML jauh lebih mudah dibuka dan dirujuk oleh rekan kerja, sehingga peluang benar-benar dibacanya jauh lebih tinggi
  • Dokumen HTML juga dapat mendukung interaksi dua arah seperti slider atau knob untuk menyesuaikan desain atau mengganti opsi algoritme dan melihat hasilnya
  • Bisa juga dibuat fitur untuk menyalin hasil penyesuaian sebagai prompt yang kemudian ditempel kembali ke Claude Code; contoh terkait dibahas di playgrounds post

Mengapa menggunakan HTML bersama Claude Code

  • Claude Code dapat membaca beragam konteks seperti sistem file, MCP, browser, dan riwayat Git lalu merangkainya menjadi hasil HTML
  • Misalnya, ia bisa menemukan semua file HTML yang dihasilkan di dalam folder kode, mengelompokkan dan mengklasifikasikannya, lalu membuat file HTML berisi diagram yang mewakili tiap jenis
  • Selain sistem file, konteks tambahan juga bisa diambil dari MCP seperti Slack dan Linear, browser web melalui Claude in Chrome, serta riwayat Git
  • Proses membuat dokumen HTML bersama Claude terasa lebih menyenangkan, sekaligus memberi kesan bahwa pengguna lebih terlibat dan berinvestasi dalam hasilnya
  • Tidak perlu membuat skill /html terpisah; cukup mulai dengan meminta “buatkan file HTML” atau “buatkan artifact HTML”
  • Kuncinya adalah mengetahui apa yang harus dilakukan artifact tersebut dan bagaimana ia akan digunakan; pada awalnya lebih baik menulis prompt dari nol setiap kali agar terbiasa dengan berbagai kegunaannya

Cara pemanfaatan utama

  • Spesifikasi, rencana, eksplorasi

    • HTML menjadi kanvas kaya bagi Claude untuk menggali masalah, dan pekerjaan dapat dimulai sebagai kumpulan beberapa file HTML alih-alih satu rencana Markdown saja
    • Alurnya bisa dimulai dengan brainstorming beberapa arah, lalu memperluas satu arah menjadi mockup atau potongan kode, dan akhirnya menulis rencana implementasi
    • Jika rencananya sudah memuaskan, sesi baru bisa dibuat lalu file-file itu diteruskan untuk implementasi, sementara agen verifikasi juga dapat membaca file yang sama untuk memperoleh konteks yang lebih luas
    • Untuk layar onboarding, Claude bisa diminta membuat 6 pendekatan berbeda dengan layout, tone, dan kepadatan berbeda dalam satu grid HTML, lengkap dengan trade-off tiap pilihan
    • Ia juga bisa diminta membuat rencana implementasi HTML yang mudah dibaca, mencakup mockup, alur data, dan potongan kode yang perlu ditinjau
    • Ini dapat digunakan untuk mengeksplorasi cara implementasi kode dan membandingkan beberapa desain visual

  • Code review dan pemahaman kode

    • Kode bisa sulit dibaca dalam file Markdown, tetapi di HTML dapat dirender dalam bentuk diff, anotasi, diagram alur, struktur modul, dan lain-lain
    • Ini dapat digunakan untuk memahami kode yang ditulis agen, menerima code review, atau menjelaskan perubahan kepada orang yang meninjau PR
    • Dalam beberapa kasus, hasilnya bekerja lebih baik daripada tampilan diff GitHub bawaan, dan alur melampirkan file penjelasan kode HTML di setiap PR juga dimungkinkan
    • Bisa dibuat artifact HTML untuk review PR yang berfokus pada logika streaming/backpressure yang belum familier, sambil memberi anotasi margin pada diff aktual dan memberi warna berdasarkan tingkat keparahan
    • Dapat digunakan untuk penulisan PR, review PR, dan pemahaman topik kode

  • Desain dan prototipe

    • Claude Design berbasis HTML, dan HTML memiliki daya ekspresi desain yang tinggi meskipun permukaan akhir bukan HTML
    • Claude dapat membuat sketsa desain dalam HTML lalu menuliskannya dalam bahasa yang diinginkan seperti React atau Swift
    • Interaksi seperti animasi dan aksi dapat diprototipekan, dan slider atau knob bisa ditambahkan untuk menyesuaikan nilai yang diinginkan
    • Misalnya, ia bisa diminta membuat tombol checkout yang setelah diklik menjalankan animasi lalu cepat berubah menjadi ungu, lengkap dengan beberapa slider, opsi, dan tombol untuk menyalin parameter yang paling pas
    • Ini dapat digunakan untuk membuat artifact design system, menyesuaikan komponen, memvisualisasikan pustaka komponen, dan membuat prototipe animasi yang menyenangkan

  • Laporan, riset, pembelajaran

    • Claude Code kuat dalam menggabungkan informasi dari berbagai sumber data lalu mengubahnya menjadi laporan yang mudah dibaca
    • Ia bisa diminta menelusuri Slack, codebase, riwayat Git, internet, dan lainnya, lalu menghasilkan laporan yang mudah dibaca untuk diri sendiri, pimpinan, atau tim
    • Hasilnya bisa berupa dokumen HTML panjang, panduan interaktif, atau format slide maupun deck
    • Jika diminta membuat diagram dengan SVG, hal itu membantu visualisasi
    • Saat menyiapkan tulisan tentang prompt caching, pendekatan yang dipakai adalah meminta Claude membaca riwayat Git dan membuat file riset HTML mendalam yang mencakup keseluruhan perubahan prompt caching
    • Ia juga bisa diminta membaca kode terkait rate limiter dan membuat satu halaman penjelasan HTML yang mencakup diagram alur token-bucket, 3–4 potongan kode inti beranotasi, serta bagian gotchas di bagian bawah
    • Dapat digunakan untuk ringkasan cara kerja fitur, penjelasan konsep, laporan status mingguan, laporan insiden, serta ilustrasi SVG, flowchart, dan diagram teknis

  • Antarmuka edit khusus

    • Ketika sulit menjelaskan keinginan hanya dengan kotak teks, kita bisa membuat editor HTML sekali pakai yang disesuaikan dengan data yang sedang dikerjakan
    • Ini bukan produk atau alat yang dapat dipakai ulang, melainkan satu file HTML yang dibuat khusus untuk satu potong data tertentu
    • Kuncinya adalah menambahkan ekspor di bagian akhir seperti “copy as JSON” atau “copy as prompt”, sehingga hasil manipulasi di UI bisa ditempel ke Claude Code
    • Misalnya, 30 tiket Linear bisa dijadikan kartu yang dapat diseret dalam kolom Now / Next / Later / Cut, lalu urutan akhirnya disalin sebagai Markdown beserta alasan satu baris per bucket
    • Pengaturan feature flag dapat dijadikan editor berbasis formulir yang dikelompokkan per area, menunjukkan dependensi, memberi peringatan jika flag dinyalakan saat prerequisite flag mati, dan menyalin hanya key yang berubah sebagai diff
    • Saat menyesuaikan system prompt, sisi kiri bisa berisi prompt yang dapat diedit dan slot variabel yang disorot, sementara sisi kanan merender tiga input sampel secara real time, lengkap dengan penghitung karakter·token dan tombol salin
    • Ini dapat digunakan untuk mengurutkan ulang tiket·test case·feedback, mengedit pengaturan terstruktur, menyesuaikan prompt·template·copywriting, kurasi dataset, anotasi dokumen·transkrip·diff, serta memilih nilai yang sulit diekspresikan sebagai teks seperti warna, easing curve, crop region, cron schedule, atau regex

Pertanyaan umum dan keterbatasan

  • Markdown biasanya memakai token lebih sedikit, tetapi HTML memiliki daya ekspresi dan kemungkinan dibaca yang lebih tinggi sehingga hasil keseluruhannya menjadi lebih baik
  • Dalam 1MM context window milik Opus 4.7, peningkatan penggunaan token tidak terlalu terasa besar di jendela konteks
  • Penggunaan Markdown hampir dihentikan untuk hampir semua kebutuhan, tetapi ini adalah gaya penggunaan yang sangat condong memaksimalkan preferensi pada HTML
  • File HTML dapat dibuka di browser lokal, bisa juga meminta Claude untuk membukanya, dan jika perlu tautan yang bisa dibagikan, file itu dapat diunggah ke S3
  • Pembuatan HTML memang memakan waktu lebih lama daripada Markdown, bisa 2–4 kali lebih lama, tetapi hasilnya dinilai sepadan
  • Salah satu kekurangan terbesar adalah version control, karena diff HTML lebih berisik dan lebih sulit ditinjau dibanding Markdown
  • Agar Claude menghasilkan HTML yang sesuai selera, frontend design plugin dapat membantu
  • Untuk menyesuaikan dengan gaya perusahaan, Claude dapat diberi akses ke codebase agar membuat satu file HTML design system, yang kemudian bisa dijadikan referensi untuk file HTML lain
  • Dengan memakai HTML, kekhawatiran bahwa rencana yang ditulis Claude tidak akan dibaca mendalam dan keputusan harus diserahkan begitu saja menjadi berkurang, sehingga proses bekerja bersama Claude terasa lebih mengalir

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Komentar Hacker News

  • Saya khawatir jika beralih ke HTML, kita akan kehilangan kemampuan agar manusia dan LLM mudah menulis dan mengedit dokumen bersama
    Kalau hanya penjelasan sederhana mungkin tidak masalah, tetapi untuk spesifikasi yang lebih kompleks, kemampuan masuk langsung ke hasil yang dihasilkan lalu memperbaikinya sendiri sangat penting. Dokumen HTML jauh lebih sulit untuk diedit seperti itu dibanding Markdown, dan memang kita bisa meminta LLM mengubah HTML lagi, tetapi ketika isi yang ingin disampaikan sudah jelas di kepala, itu sendiri menjadi hambatan tambahan. Jika pola ini menjadi umum, kolaborasi kreatif manusia/LLM akan makin berkurang, dan kita akan bergerak ke arah menyerahkan gaya bahasa, nada, bahkan pemilihan isi kepada LLM. Saya terkejut FAQ blog itu tidak membahas kekhawatiran ini

    • Markdown mendukung inline HTML untuk elemen interaktif, jadi dokumen Markdown yang dipadukan dengan template HTML yang sudah dikenal dan langkah build sederhana bisa menjadi alternatif yang menarik
      Misalnya dengan perintah pandoc satu baris
    • Menurut saya ada satu langkah lagi di atas ini. Dengan HTML, hampir semua hal bisa dilakukan, tetapi membiarkan LLM mendefinisikan bahasanya sendiri juga ternyata sangat efektif
      Saat ini saya sedang membuat game mobile kecil dengan sudut pandang isometrik dan suara, dan saya meminta Codex membuat alat yang menaruh blok ke dokumen three.js yang sudah disiapkan lalu mengambil screenshot dengan Chromium developer tools; hasilnya ia membuat struktur JSON kecil yang mendefinisikan blok, warna, dan efek untuk menghasilkan tileset 2.5D. Saya juga memintanya mendefinisikan suara dan musik lewat skrip Python uv, dan ia membuat format YAML yang bisa menghasilkan noise. Ini sudah jauh melampaui uji SVG pelican, dan Codex bahkan membuat prototype art yang cukup untuk prajurit, ksatria, dan pendeta, plus soundtrack prototipe
    • Kita sudah menulis HTML dengan tangan dengan mudah selama puluhan tahun. Editor teks sangat bagus untuk menulis HTML, dan ada banyak perintah seperti word wrap otomatis dan penutupan tag otomatis, jadi membaca dan menulisnya itu sederhana
    • Itu sepertinya hanya berlaku kalau Anda sengaja mengurung diri di emulator teletype mentah. Dalam lingkungan coding yang layak, mengedit HTML seharusnya sangat mudah, dan jika arahnya memang ke keluaran model yang lebih kaya, editor WYSIWYG bawaan juga bisa menjadi opsi
    • Saya mulai memakai HTML untuk laporan belakangan ini, tetapi selalu menaruh file Markdown sebagai format perantara, lalu meminta LLM membuat versi yang lebih bagus dengan grafik dan ilustrasi SVG berdasarkan tabel di Markdown

  • Ironis bahwa ini adalah postingan Twitter yang mengunggah gambar hasil render HTML, bukan halaman HTML interaktif
    Lucu juga pada akhirnya membela HTML di platform yang struktur semantiknya lebih miskin daripada Markdown

  • Prompt yang sering saya pakai saat mengeksplorasi ide atau alat baru adalah seperti ini

    In a single index.html, no dependencies, sparse styling, create an app that

    Bahkan sebelum era AI saya sudah membuat alat kecil seperti ini, dan saya suka bisa mengirim alat itu ke teman lewat email sambil bilang, “kalau mau diubah, coba lempar ke LLM”

    • Pendekatan ini memang tepat
      Untuk dashboard, aplikasi kecil, utilitas yang berinteraksi dengan API atau mengambil data dari suatu tempat, jangkauan hal yang bisa diwujudkan hanya dengan satu file HTML yang berisi style dan JS ternyata sangat luas. Tinggal taruh di folder pribadi ~ pada server bersama kantor, dan semua orang bisa langsung melihat serta memakainya
    • Saat mengiterasi desain klien baru pun saya membuatnya dalam index.html sederhana dengan inline CSS, lalu kalau hasilnya sudah saya suka, file itu saya taruh di samping file template proyek dan meminta LLM menuangkan desain dari index.html ke file template tersebut
    • Agak konyol rasanya karena saya belum benar-benar memikirkan use case ini sebelumnya. Kegunaannya terlalu jelas
      Selama ini saat memakai LLM, fokus saya adalah “aplikasi”-nya sendiri, bukan alat bantu di sekitar aplikasi itu. Padahal alat bantu seperti itu tidak perlu polished atau menangani semua kasus; cukup bekerja secukupnya agar berguna. Setelah selesai dipakai, buang saja dan besok bikin lagi yang baru
    • Dulu saya menemukan trik ini dan membuat banyak kalkulator untuk rangkaian elektronik analog: https://cofree.coffee/~solomon/calculators/
      Sangat praktis bisa merakit alat seperti ini dengan cepat lalu mengunggahnya ke situs statis
    • Saya juga melakukan ini di Claude web saat meminta HTML. Karena ia membuatkannya sebagai artifact, besar kemungkinan modelnya sudah terlatih dengan baik pada pola ini

  • Teknologi web benar-benar melakukan banyak hal dengan sangat benar. Banyak orang mengeluh, tetapi ini luar biasa
    Di pekerjaan sebelumnya saya menangani aplikasi hasil vibe coding dan akhirnya keluar karena itu; arsitekturnya frontend single-page Next.js dan backend API terpisah, sehingga URL untuk pengguna tidak cocok dengan endpoint backend. Karena AI memakai React hooks untuk semua hal, state berada di memori, dan routing berbasis URL tidak ada kecuali memang dirancang dengan sengaja. Akibatnya tautan tidak muncul secara cuma-cuma, dan pengguna tidak punya cara menautkan ke mana pun selain titik masuk tingkat atas. Maksud saya, tautan. Terutama pada alat internal, semuanya harus bisa ditautkan agar kolaborasi dan pemecahan masalah lebih mudah. Gagasan desain tentang perlunya uniform resource locations dan verbs itu benar-benar sudah dipikirkan dengan sangat baik 30–40 tahun lalu

    • Maksudnya URL tidak diperbarui saat berpindah ke halaman atau tab lain?

  • Ada beberapa hal yang hilang di sini sebagai titik kompromi antara HTML dan Markdown. HTML jauh lebih tidak efisien dalam token, dan memberi umpan balik yang presisi pada rancangan HTML lebih sulit daripada Markdown
    Kedua trade-off ini menguntungkan Anthropic. Jika HTML dipakai sebagai medium, pemakaian token meningkat, dan mungkin mereka juga berinvestasi dalam alat untuk memberi anotasi atau penanda pada HTML sebagai bagian dari Claude Design, sehingga lock-in bisa makin kuat. Kebetulan, atau strategi yang cemerlang

    • Memang sedikit kurang efisien, tetapi kalau struktur atau elemen visualnya tidak terlalu banyak, bedanya tidak sebesar itu
      Saya juga kurang paham kenapa umpan balik presisi akan lebih sulit daripada di Markdown. Kita bisa memberi id, section, dan sebagainya pada tag
    • HTML juga punya cakupan kerentanan eksekusi kode yang lebih luas. Teks biasa tidak berbahaya

  • Saya sudah berkutat dengan HTML selama puluhan tahun, tetapi untuk dokumen sederhana Markdown tetap lebih cepat. Akan bagus kalau ada titik tengah, dan sebenarnya hal yang lebih kaya fitur seperti GitHub Markdown juga sudah ada
    Kita bisa menyematkan Mermaid, dan juga memakai sesuatu seperti MDX yang mencampur komponen saat diperlukan. Setahu saya readme.com juga memakai MDX secara internal. Jika butuh kartu atau layout, kita bahkan bisa menambahkan komponen berbasis sesuatu seperti Bootstrap. Yang kurang sekarang cuma dukungan antarmuka. HTML mentah sudah bisa dirender, jadi rasanya menambahkan Markdown yang lebih kuat juga tidak akan terlalu sulit

    • Menurut saya MDX adalah titik tengah yang sempurna. Gara-gara komentar ini saya jadi ingin mulai memakai MDX alih-alih Markdown biasa

  • Baik spesifikasi Markdown asli [1] maupun CommonMark [2] secara jelas menetapkan dukungan inline HTML. Jadi tergantung kebutuhannya, kita bisa mendapatkan sebagian kelebihan dari keduanya
    Sebagian besar waktu cukup pakai header dan paragraf Markdown biasa, lalu tambahkan gambar dan tabel sehingga tetap enak dibaca dalam bentuk sumber tanpa tag HTML. Kalau ingin memasukkan sesuatu seperti SVG yang dicontohkan penulis, tinggal embed SVG secara langsung, dan pembaca bisa merender Markdown itu dengan viewer pilihan mereka. Saat melihat file Markdown mentah di VS Code lalu menemukan tag HTML, cukup buka preview dengan Cmd+Shift+V. Tentu saja ini sulit diwujudkan jika yang diinginkan adalah halaman web penuh dengan tombol interaktif dan styling kustom menyeluruh, tetapi kalau mayoritasnya teks, gambar, dan tabel lalu hanya ditambah elemen ekstra di sana-sini, pendekatan ini bisa melangkah cukup jauh
    [1] https://daringfireball.net/projects/markdown/syntax#html
    [2] https://spec.commonmark.org/0.31.2/#html-blocks

    • Menurut saya dokumen Markdown seharusnya tidak membutuhkan preview. Kalau begitu, sekalian saja buat dokumen HTML

  • Sejak Januari saya sangat mendorong pendekatan ini untuk penggunaan non-coding. Sifat pentingnya adalah bahwa ini merupakan single source of truth yang bisa diedit, dipahami LLM dan manusia, bisa dirender, dan bisa dimodifikasi secara bertahap
    Saya sering berbicara dengan orang biasa tentang pekerjaan AI, dan kalau di jalan bertemu percakapan soal AI saya suka ikut menyela seperti antropolog. Artifact HTML itu seperti bilah alamat URL browser yang baru. Mirip seperti beberapa pengguna menganggap bilah alamat itu sebenarnya adalah Google. Belakangan banyak orang berkata bahwa mengerjakan hal seperti “spreadsheet”, “presentasi”, “ringkasan pemasaran satu halaman”, “slideshow”, “analisis kompetitor”, atau “diagram sistem HVAC” di web ChatGPT atau Claude terasa kurang memuaskan, tetapi membuat dokumen baru dengan Claude Code atau OpenClaw terasa seperti keajaiban
    Saat ditanya sebenarnya dokumennya apa dan apa bedanya pengalaman itu, saya biasanya harus cukup banyak menggali atau minta mereka menunjukkannya karena kosakata komputasinya belum ada, tetapi ujung-ujungnya selalu sampai pada kesimpulan bahwa artifact tersebut adalah HTML. Pengalaman yang menyenangkan datang dari iterasi terhadap file HTML di filesystem (+CSS+gambar) dengan render instan berkualitas tinggi, dan kalau perlu bisa ditaburi sedikit JavaScript. Jika ada sistem git, mereka bahkan bisa mendapat version control tanpa sadar. Kalau belum ada, saya sarankan membuat checkpoint. Mungkin version control adalah tahap belajar berikutnya bagi pengguna umum
    Sebaliknya, pengalaman yang tertanam di web adalah menusuk-nusuk DOCX/PPTX/XLSX yang tersisa di dalam context window berulang kali, sambil berurusan dengan gagasan yang kabur tentang penyimpanan lokal. Padahal sebenarnya tetap dirender sebagai HTML di sidebar. Workflow HTML juga memudahkan pengintegrasian medium lain. Pada akhirnya, pekerjaan presentasi seperti ini adalah vibe coding untuk masyarakat umum, dan kita tidak perlu tahu semua kura-kura yang menopangnya di bawah. Meski begitu, kalau mau, kita bisa membukanya, memperbaikinya, atau dengan mudah menyerahkannya ke agen lain. Sistem yang dibuat untuk komunikasi multimedia kolaboratif ternyata berguna ketika kecerdasan mesin membantu komunikasi kita

  • Dulu kami di https://www.definite.app/) membiarkan agen kami menulis laporan dan dashboard dalam bentuk spesifikasi YAML yang kemudian dirender oleh framework frontend
    Misalnya saat pengguna berkata, “buatkan laporan yang menampilkan pendapatan bulanan dan jumlah pesanan, lalu tampilkan 100 pesanan terbaru”, agen akan menulis spesifikasi yang akan dirender di frontend. Cara ini cepat, tetapi kami tenggelam dalam permintaan fitur yang harus didukung framework. Permintaan seperti “label di sini ingin dihilangkan”, “di sana justru perlu label”, atau “bisakah chart ini dibuat jadi heatmap”. Beberapa bulan lalu kami membiarkan agen langsung menulis HTML, dan meskipun generasinya lebih lama, kustomisasinya jadi tidak terbatas. Pendekatan baru ini juga punya masalah, misalnya pengguna nonteknis harus men-debug aplikasi monster yang mereka buat sendiri, tetapi secara keseluruhan pelanggan jauh lebih menyukainya

    • Dalam kasus seperti ini, bagaimana kalian mencegah prompt injection?

  • Untuk keluaran agen yang panjang, saya membacanya dengan VIM dan macOS Quick Look (dengan ekstensi render Markdown), atau menempelkannya ke MarkEdit yang punya panel preview
    Dalam kasus terburuk, kita bisa menyuruh agen membuat halaman web lokal sederhana yang mengurai dan merender Markdown. Markdown ditemukan sebagai bentuk singkat dari sintaks web [0], dan memang untuk kegunaan itu. Rasanya token dan waktu yang dibutuhkan untuk menyuruh agen mengubah Markdown dasar menjadi HTML akan lebih besar daripada memakai cara-cara ini
    0. https://daringfireball.net/projects/markdown/

    • Kemungkinan besar memang memakai lebih banyak token, tetapi penulisnya bekerja di Anthropic jadi sepertinya tidak pernah benar-benar merasakan biaya token sendiri
    • Kalau mau vibe sampai tuntas, bukankah keluaran panjang itu juga bisa langsung diminta diringkas ke bot?
      Pemakaian bot benar-benar terasa semrawut dan serba mereferensikan dirinya sendiri
    • Saya penasaran ekstensi Quick Look yang mana. Saya sedang mencari yang bagus