Sejak dirilis, nasib Fable 5 terasa mistis seperti nama model itu sendiri.
Dari "momen deifikasi AI" yang ditunggu-tunggu semua orang, hingga dilarang paksa oleh pemerintah AS dan diblokir untuk pengunjung non-Amerika, dapat dikatakan telah menarik perhatian global.
Kini, badai perlahan mereda. Model pada akhirnya harus kembali ke produktivitas.
Untuk itu, insinyur Claude Code, Thariq Shihipar, merilis blog panjang di media sosial, menjelaskan secara detail teknik menggunakan Fable 5.
Artikel ini menjawab kebingungan yang telah lama dialami banyak orang. Mengapa, ketika menggunakan model, saya masih merasa tidak mampu menyelesaikan tugas dengan benar meskipun kemampuannya sudah sangat maju?
Blog Thariq memberikan pencerahan. Singkatnya: terdapat kesenjangan informasi antara manusia dan model, yaitu perbedaan antara prompt, Skill, konteks yang diberikan pengguna, dan eksekusi tugas sebenarnya.
Untuk itu, keseluruhan blog mengajarkan cara menghilangkan kesenjangan informasi ini. Di bawah ini, Heart of Machine akan menyertakan teks lengkap blog untuk dinikmati pembaca.
Judul Blog: A Field Guide to Fable: Finding Your Unknowns
Tautan Blog: https://x.com/trq212/status/2073100352921215386
Bekerja dengan Claude Fable 5 terus-menerus mengingatkan saya pada pepatah lama: peta tidak sama dengan wilayah.
Yang disebut "peta" adalah representasi pekerjaan yang akan diselesaikan, yaitu prompt, keterampilan, dan konteks saya, yang saya berikan kepada Claude. Yang disebut "wilayah" adalah tempat di mana pekerjaan sebenarnya harus dilakukan: basis kode, dunia nyata, dan kendala nyata yang ada di dalamnya.
Saya menyebut perbedaan antara peta dan wilayah sebagai "hal yang tidak diketahui". Ketika Claude menemukan hal yang tidak diketahui, ia harus membuat keputusan berdasarkan tebakan terbaiknya tentang maksud saya. Semakin kompleks pekerjaannya, semakin banyak hal yang tidak diketahui yang mungkin dihadapi Claude.
Fable adalah model pertama yang membuat saya merasa jelas bahwa kualitas pekerjaan bergantung pada kemampuan saya untuk menjelaskan hal-hal yang tidak diketahui.
Yang penting, hanya merencanakan sebelumnya tidak selalu cukup. Anda mungkin menemukan hal-hal yang tidak diketahui di kedalaman implementasi; atau mungkin menemukan bahwa hal-hal ini mengarah pada fakta bahwa sebenarnya Anda harus menyelesaikan masalah ini dengan cara yang sama sekali berbeda.
Saya menemukan bahwa berkolaborasi dengan Fable pada dasarnya adalah proses iteratif untuk menemukan hal-hal yang tidak diketahui sebelum, selama, dan setelah implementasi.
Penulis memberikan beberapa contoh untuk menemukan "hal yang tidak diketahui", yang dapat dilihat bersama dengan teks lengkap.
Tautan Contoh: https://thariqs.github.io/html-effectiveness/unknowns/
Kenali Hal-Hal yang Tidak Anda Ketahui
Apa itu hal yang tidak diketahui? Ketika saya mendatangi Claude dengan sebuah masalah, saya biasanya memecahnya dari empat sudut pandang:
Yang diketahui diketahui: Ini pada dasarnya adalah apa yang saya tulis di prompt. Saya memberi tahu agen apa yang saya inginkan?
Yang diketahui tidak diketahui: Hal-hal apa yang belum saya pahami, tetapi saya tahu bahwa saya belum memahaminya?
Yang tidak diketahui diketahui: Hal-hal apa yang begitu jelas bagi saya sehingga saya bahkan tidak akan menuliskannya, tetapi begitu melihatnya, saya bisa mengenalinya?
Yang tidak diketahui tidak diketahui: Hal-hal apa yang sama sekali tidak saya pertimbangkan? Pengetahuan apa yang belum saya ketahui? Apakah saya tahu seberapa baik sesuatu bisa dilakukan?
Pemrogram agen terbaik biasanya memiliki lebih sedikit hal yang tidak diketahui. Mereka sangat jelas tentang apa yang mereka inginkan, dan detailnya sangat lengkap. Mereka sangat selaras dengan basis kode dan perilaku model.
Tetapi mereka juga akan mengasumsikan adanya hal-hal yang tidak diketahui. Dalam banyak hal, mengurangi dan merencanakan hal-hal yang tidak diketahui terlebih dahulu adalah kemampuan inti dari pemrograman agen. Untungnya, ini adalah keterampilan yang dapat ditingkatkan melalui kolaborasi dengan Claude.
Bantu Claude untuk Membantu Diri Anda Sendiri
Memberi instruksi kepada Claude adalah keseimbangan yang halus. Jika Anda terlalu spesifik, Claude akan mengikuti instruksi Anda dengan ketat, meskipun beralih ke solusi lain mungkin lebih tepat. Jika Anda terlalu samar, Claude cenderung membuat pilihan dan asumsi berdasarkan praktik terbaik industri, yang tidak selalu sesuai dengan tugas Anda.
Kedua kasus ini gagal ketika Anda belum cukup mempertimbangkan hal-hal yang tidak diketahui. Anda tidak tahu kapan jalan di depan penuh rintangan, atau kapan sebenarnya jalan itu mulus, tetapi Anda masih ingin Claude dapat melakukan penyesuaian bila diperlukan.
Claude dapat membantu Anda menemukan hal-hal yang tidak diketahui lebih cepat. Ia dapat mencari basis kode dan internet dengan sangat cepat, dan memiliki pengetahuan umum yang lebih banyak daripada Anda dalam sebagian besar topik. Ia juga dapat beriterasi dari kegagalan dengan lebih cepat.
Yang terpenting dalam proses ini adalah memberikan konteks awal yang cukup kepada Claude. Misalnya, beri tahu di mana posisi pemikiran Anda saat ini; jelaskan seberapa akrab Anda dengan masalah dan basis kode ini; biarkan ia berkolaborasi dengan Anda seperti mitra berpikir.
Saya sebelumnya pernah menulis tentang cara membuat HTML dengan Claude. Di hampir semua skenario ini, artefak HTML adalah cara terbaik untuk memvisualisasikan dan mengekspresikan ide.
Dalam artikel ini, saya akan menjelaskan secara detail beberapa pola yang saya gunakan untuk menemukan hal-hal yang tidak diketahui ini. Saya tidak selalu menggunakan semua teknik ini setiap kali, tetapi menyimpannya sebagai satu set metode yang dapat dipanggil sangat berguna.
Sebelum Implementasi
Pemindaian Titik Buta
Salah satu hal paling berguna saat memulai pekerjaan adalah memahami titik buta Anda sendiri. Misalnya, jika Anda menulis fitur di modul baru dalam basis kode, atau meminta Claude menangani pekerjaan yang tidak Anda kenal, seperti mengiterasi desain, kemungkinan besar Anda akan memiliki banyak "yang tidak diketahui tidak diketahui".
Anda mungkin tidak tahu pertanyaan apa yang harus diajukan, tidak tahu apa yang dianggap baik, tidak tahu pekerjaan sejarah apa yang telah dilakukan, dan tidak tahu jebakan apa yang harus dihindari.
Untuk melakukan ini, Anda dapat meminta Claude membantu menemukan "yang tidak diketahui tidak diketahui" dan menjelaskannya kepada Anda. Saya suka langsung menggunakan istilah "blindspot pass" dan "unknown unknowns". Biasanya, penting juga untuk memberi tahu siapa Anda dan apa yang Anda ketahui.
Contoh prompt:
"Saya sedang menambahkan penyedia autentikasi baru, tetapi saya tidak tahu apa-apa tentang modul autentikasi di basis kode ini. Bisakah Anda melakukan blindspot pass, membantu saya menemukan unknown unknowns terkait, dan membantu saya menulis prompt yang lebih baik untuk Anda?"
"Saya tidak tahu tentang color grading, tetapi saya perlu melakukan color grading untuk video ini. Bisakah Anda mengajari saya untuk memahami unknown unknowns saya dalam color grading, sehingga saya dapat menulis prompt yang lebih baik?"
Brainstorming dan Prototipe
Ketika saya bekerja di bidang dengan banyak "yang tidak diketahui diketahui", yaitu hal-hal yang hanya setelah melihatnya saya tahu bagaimana mendefinisikan standar, saya akan meminta Claude untuk melakukan brainstorming dan membuat prototipe bersama saya.
Mengidentifikasi dan mengekspresikan "yang tidak diketahui diketahui" ini sedini mungkin pada tahap prototipe sangat berharga, karena jika ditemukan pada tahap implementasi, biayanya seringkali relatif lebih tinggi. Perubahan kecil dalam fungsionalitas atau spesifikasi dapat menyebabkan perbedaan besar dalam implementasi kode, dan lebih sulit untuk membuat agen mundur dari modifikasi sebelumnya.
Misalnya, Anda mungkin hanya ingin melihat seperti apa efek menambahkan tombol dalam framework tertentu, tanpa benar-benar menghubungkan rute backend atau mempertahankan status ekstra di frontend.
Desain visual adalah sesuatu yang sulit saya ekspresikan dengan jelas, tetapi saya tahu apa yang saya inginkan setelah melihatnya. Dalam kasus seperti ini, saya akan meminta Claude memberikan beberapa arah desain yang berbeda untuk sebuah artefak.
Saya hampir selalu memulai setiap sesi coding dengan eksplorasi atau brainstorming. Ini membantu saya mendefinisikan ruang lingkup proyek dengan niat yang jelas. Claude sering menemukan solusi bernilai tinggi yang mungkin saya lewatkan, tetapi terkadang ia juga hanya melihat pohon dan bukan hutan. Brainstorming dapat mencegah saya memulai dengan ruang lingkup yang terlalu sempit atau terlalu luas.
Contoh prompt:
"Saya ingin membuat dasbor untuk set data ini, tetapi saya tidak punya selera visual dan tidak tahu seberapa jauh ini bisa dilakukan. Buatkan saya halaman HTML dengan 4 arah desain yang sangat berbeda dalam gaya, agar saya dapat memberikan umpan balik berdasarkan hasilnya."
"Sebelum benar-benar menghubungkan, buat file HTML terpisah dengan data palsu untuk mensimulasikan toolbar editor baru. Saya ingin memberikan umpan balik tentang tata letak terlebih dahulu, baru kemudian Anda dapat mengubah aplikasi nyata."
"Ini masalah kasar saya: pengguna churn setelah onboarding. Cari basis kode, brainstorming 10 tempat di mana kita dapat melakukan intervensi, dari yang paling murah hingga yang paling ambisius. Saya akan memberi tahu arah mana yang lebih terasa."
Pertanyaan Balik
Setelah melakukan brainstorming yang cukup, saya biasanya masih memiliki hal-hal yang tidak diketahui.
Dalam situasi seperti ini, saya akan meminta Claude mewawancarai saya seputar area mana pun yang tidak jelas atau ambigu. Saat meminta Claude mewawancarai Anda, cobalah memberikan konteks tentang masalahnya agar ia dapat mengajukan pertanyaan yang lebih terarah. Berikut adalah beberapa contoh.
Contoh prompt:
"Tolong ajukan satu pertanyaan kepada saya pada satu waktu, wawancarai saya seputar area mana pun yang ambigu. Prioritaskan pertanyaan yang jawaban saya akan mengubah desain arsitektur."
Referensi
Terkadang, Anda tidak dapat menjelaskan secara detail apa yang Anda inginkan. Misalnya, Anda mungkin tidak memiliki bahasa ekspresi yang sesuai, atau hal ini terlalu kompleks sehingga akan memakan waktu lama untuk dijelaskan sepenuhnya.
Dalam kasus seperti ini, jawaban terbaik adalah referensi. Anda dapat memberikan diagram, dokumen, atau gambar, tetapi referensi terbaik sebenarnya adalah kode sumber.
Jika Anda memiliki pustaka yang mengimplementasikan fungsi tertentu dengan cara tertentu, atau memiliki komponen desain yang sangat Anda sukai, arahkan langsung Fable ke folder tersebut dan beri tahu apa yang harus dilihat. Bahkan jika kode referensi ditulis dalam bahasa lain, tidak masalah.
Ini juga cara kerja Claude Design. Anda tidak harus memberinya file, meskipun Anda juga bisa melakukannya. Anda dapat mengarahkannya ke modul situs web yang Anda sukai, dan ia akan membaca kode dasarnya, bukan hanya tangkapan layar. Ini memberikan detail yang lebih kaya, termasuk struktur markup, cara komponen diorganisir, dan bagaimana komponen ini sebenarnya dibangun.
Contoh prompt:
"Crate Rust di vendor/rate-limiter ini mengimplementasikan perilaku coba ulang dengan backoff yang persis saya inginkan. Tolong baca, dan implementasikan kembali semantik yang sama di klien API TypeScript kami."
Rencana Implementasi
Ketika saya merasa siap untuk mulai mengimplementasikan, saya biasanya meminta Claude untuk menyusun rencana implementasi terlebih dahulu untuk saya tinjau, dengan fokus pada bagian yang paling mungkin berubah, seperti model data, antarmuka tipe, atau alur UX. Ini memungkinkan Claude untuk mengungkapkan lebih awal beberapa hal yang mungkin memang perlu saya sesuaikan.
Contoh prompt:
"Tulis rencana implementasi dalam HTML, tetapi awali dengan menyajikan titik keputusan yang paling mungkin saya ubah: perubahan model data, antarmuka tipe baru, dan konten apa pun yang berorientasi pengguna. Letakkan refaktor mekanis di paling bawah, bagian itu saya percayakan pada Anda."
Selama Implementasi
Catatan Implementasi
Ketika saya puas dengan rencana tersebut, saya akan memulai sesi baru dan memasukkan artefak terkait ke dalam prompt. Misalnya, saya mungkin memasukkan file spesifikasi dan prototipe, lalu meminta agen untuk mengimplementasikannya.
Namun kenyataannya, tidak peduli seberapa banyak Anda merencanakan, selalu ada hal-hal yang tidak diketahui yang mengintai. Selama bekerja, agen mungkin menemukan bahwa ia harus berpikir dengan cara yang berbeda karena kasus tepi tertentu dalam kode.
Saya akan meminta Claude Code untuk mempertahankan file implementation-notes.md sementara, atau file .html, untuk mencatat keputusan yang diambilnya, sehingga kita dapat belajar dari percobaan berikutnya.
Contoh prompt:
"Tolong pertahankan file implementation-notes.md. Jika Anda menemukan kasus tepi yang mengharuskan Anda menyimpang dari rencana awal, pilih opsi konservatif, catat alasannya di bawah 'Deviations', dan lanjutkan."
Setelah Implementasi
Dokumentasi Presentasi dan Penjelasan
Salah satu hal terpenting saat merilis sesuatu adalah mendapatkan pemahaman, dukungan, dan persetujuan orang lain. Membangun artefak presentasi dan penjelasan dalam dokumentasi akhir membantu:
Mempercepat pemahaman mereka ketika peninjau awalnya juga membawa hal-hal yang tidak diketahui yang sama dengan Anda.
Mempercepat persetujuan ketika para ahli ingin memastikan Anda telah mempertimbangkan hal-hal yang tidak diketahui dan titik kegagalan umum yang mereka prediksi.
Contoh prompt:
"Bungkus prototipe, spesifikasi, dan catatan implementasi menjadi satu dokumen yang dapat saya kirim langsung ke Slack untuk mendapatkan dukungan. Awali dengan GIF demonstrasi."
Ujian
Setelah sesi kerja yang panjang, Claude mungkin telah menyelesaikan lebih banyak pekerjaan daripada yang saya sadari. Hanya melihat diff kode seringkali hanya memberi saya pemahaman dangkal tentang apa yang terjadi, karena banyak perilaku bergantung pada jalur kode yang sudah ada.
Meminta Claude untuk menguji saya seputar perubahan ini setelah memberikan banyak konteks dapat membantu saya benar-benar memahami apa yang terjadi. Saya hanya akan menggabungkan kode setelah lulus ujian dengan sempurna.
Contoh prompt:
"Saya ingin memastikan saya memahami semua yang terjadi dalam perubahan ini. Berikan saya laporan HTML untuk membantu saya membaca dan memahami perubahan ini, termasuk konteks, penjelasan intuitif, apa yang sebenarnya dilakukan, dll., dan sertakan ujian yang harus saya lulus di bagian bawah."
Merangkai Metode: Contoh Merilis Fable
Video rilis Fable sepenuhnya diedit oleh Claude Code. Ini adalah bidang yang sama sekali baru bagi saya, dan saya sama sekali bukan ahli di bidang ini.
Jadi saya mulai dengan apa yang saya ketahui. Saya tahu Claude dapat mengedit video dengan kode dan melakukan transkripsi, tetapi saya tidak yakin akurasinya cukup. Jadi saya meminta Claude menjelaskan bagaimana teknologi transkripsi seperti Whisper bekerja, dan apakah saya dapat memotong filler words seperti "um" atau jeda panjang dengan akurat menggunakan ffmpeg.
Saya ingin Claude membuat UI dan menyinkronkannya dengan kata-kata yang saya ucapkan dalam waktu, tetapi saya tidak yakin apakah ini bisa dilakukan. Jadi saya meminta Claude membuat prototipe video menggunakan Remotion dan teks transkripsi, untuk melihat apakah ide ini layak.
Akhirnya, video itu sendiri terlihat agak suram. Saya tahu ini masalah color grading, tetapi saya tidak benar-benar memahami apa itu color grading. Percobaan pertama saya adalah meminta Claude membuat beberapa versi untuk saya pilih, tetapi saya menyadari bahwa dalam hal color grading, saya tidak tahu apa yang dianggap "bagus". Jadi, alih-alih terus membuat versi secara membabi buta, saya meminta Claude mengajari saya color grading, untuk menemukan hal-hal yang tidak saya ketahui.
Cocokkan Peta dengan Wilayah
Semakin kuat modelnya, semakin banyak yang dapat Anda selesaikan dengan metode yang benar. Ketika tugas jangka panjang mengembalikan hasil yang salah, kemungkinan besar Anda perlu menghabiskan lebih banyak waktu untuk mendefinisikan hal-hal yang tidak diketahui Anda, atau membuat rencana implementasi yang memungkinkan Claude untuk beradaptasi dengan hal-hal yang tidak diketahui ini.
Setiap dokumen penjelasan, brainstorming, wawancara, prototipe, dan referensi adalah metode biaya rendah untuk menemukan hal-hal yang sebelumnya tidak Anda ketahui, sebelum biaya perbaikan menjadi tinggi.
Jadi, saat memulai proyek berikutnya, minta Claude membantu Anda menemukan hal-hal yang tidak Anda ketahui terlebih dahulu.
Artikel ini berasal dari akun WeChat "Heart of Machine", editor: Redaksi Heart of Machine
