Inilah alur kerja yang menjadi default di setiap tim desain-ke-kode saat ini: ekspor frame dari Figma, tempel PNG ke Claude atau Cursor, ketik "bangun ini", dan iterasi dari output yang dihalusinasi. Ini bekerja cukup baik untuk terasa produktif. Tidak cukup baik untuk di-ship.

Ini bukan masalah kemampuan model. Ini adalah masalah input. Screenshot adalah representasi terburuk yang mungkin dari desain Figma bagi LLM untuk dipikirkan — dan hampir secara universal itulah yang tim raih terlebih dahulu. Context bundle figmascope adalah alternatif terstrukturnya.

Hierarki hilang

File Figma adalah pohon. Frame berisi grup auto-layout, yang berisi instance komponen, yang berisi layer teks dan fill. Pohon tersebut mengkodekan maksud layout: baris ini adalah kontainer flex, kartu ini adalah kotak dengan padding, tiga item ini adalah saudara kandung dengan gap 16px di antara mereka.

Screenshot meratakan pohon itu ke kisi piksel. LLM melihat bentuk dan warna. Ia tidak melihat struktur layout — ia menyimpulkannya. Dan inferensi itu lossy di kedua arah: model mungkin merekonstruksi struktur yang terlihat benar secara visual tetapi salah secara semantik (div lebar tetap alih-alih flex child, positioning absolut alih-alih auto-layout), atau mungkin melihat ambiguitas struktural dan memilih salah satu secara sembarangan.

Anda tidak bisa mengetahui dari PNG apakah baris item horizontal diimplementasikan dengan display: flex, CSS Grid, HStack kustom, atau tiga div yang diposisikan secara absolut. Mereka secara visual identik. LLM memilih satu. Pilihannya berbeda antar run.

Semantik tidak bertahan dari rasterisasi

LLM dapat melihat bahwa persegi panjang dengan sudut membulat berisi beberapa teks dan ikon. Yang tidak bisa dilihatnya:

Semantik di Figma berada dalam pohon layer: nama komponen, properti varian, jenis node. Komponen Button/Primary/Large diketik secara eksplisit. Dalam screenshot, ini adalah persegi panjang membulat dengan bayangan dan label. Model menebak "ini mungkin tombol" dengan benar sebagian besar waktu — dan kemudian menebak "ini mungkin varian primary" berdasarkan warna, yang mungkin atau tidak cocok dengan penamaan sebenarnya sistem desain Anda.

Ketidakcocokan kecil terakumulasi. Tombol ghost dirender sebagai tombol beroutline. Tooltip dirender sebagai pemicu modal. State dinonaktifkan dirender sebagai aktif. Masing-masing ini adalah satu langkah inferensi screenshot jauh dari sumber kebenaran.

Sistem spacing tidak terselesaikan ke angka

Lihat screenshot kartu dengan padding. Berapa paddingnya? Anda tidak bisa mengetahui tanpa mengukur piksel, mengetahui skala kanvas, mengetahui resolusi ekspor, dan melakukan matematika. LLM melakukan matematika dengan buruk — ia memperkirakan, membulatkan, dan tidak ada cara untuk mengetahui apakah sistem spacing Anda menggunakan grid dasar 8px atau 4px atau sesuatu yang kustom.

Jadi ia menebak. Ia menghasilkan padding: 12px ketika desain mengatakan 16. Ia menghasilkan gap: 8px ketika desain mengatakan 12. Angka-angka ini terlihat masuk akal secara terpisah tetapi salah — dan jika sistem desain Anda menggunakan token spacing seperti spacing.md atau Spacing/400, LLM tidak mengetahuinya sama sekali. Ia hardcode literal yang akan menyimpang dari sistem Anda begitu ada yang berubah.

LLM tidak berhalusinasi. Ia melakukan persis apa yang Anda lakukan hanya dengan screenshot: menebak. Anda hanya terkejut ketika tebakannya salah karena Anda bisa melihat jawaban yang benar di file Figma sepanjang waktu.

Hubungan token hilang

Desainer Anda menetapkan latar belakang itu ke #7F5CFE. Di Figma, hex itu terikat ke variabel: color/brand/primary. Binding itu bermakna — itu berarti warna berpartisipasi dalam theming, itu berarti mode gelap menggantinya, itu berarti jika warna merek berubah Anda memperbarui satu variabel dan setiap instance diperbarui.

Dalam screenshot: itu ungu. LLM menghasilkan background-color: #7F5CFE. Hubungan token hilang. Basis kode Anda sekarang memiliki hex hardcoded yang tidak akan pernah mengikuti sistem desain Anda. Kalikan ini dengan setiap komponen di layar.

Hal yang sama berlaku untuk skala tipografi, border radius, dan definisi bayangan. Setiap nilai dalam file Figma yang dipelihara dengan baik berpotensi merupakan token bernama. Setiap nilai dalam screenshot hanyalah angka.

Penggunaan ulang komponen tidak terlihat

Layar yang terdiri dengan baik menggunakan kembali komponen. Empat kartu produk adalah empat instance dari komponen ProductCard yang sama. Avatar di nav dan avatar di thread komentar keduanya adalah instance dari Avatar/Medium. Ini penting untuk kode: Anda menginginkan satu komponen React, bukan empat variasi buatan tangan yang akan menyimpang.

Dari screenshot, LLM melihat empat persegi panjang yang terlihat mirip. Ia mungkin menghasilkan satu komponen yang dapat digunakan kembali — atau ia mungkin menghasilkan empat blok JSX yang hampir identik karena tidak memperhatikan bahwa mereka sama. Tidak ada sinyal dalam gambar untuk memberi tahunya mana yang benar.

IR yang diekspor figmascope membawa componentId pada setiap node instance. Agen tahu: empat node ini semuanya adalah ProductCard. Hasilkan sekali, render empat kali dengan props yang berbeda. Itu adalah output yang Anda inginkan. Itu adalah output yang tidak bisa Anda dapatkan dari piksel.

Identitas string hilang

Anda memiliki tombol "Continue" di tiga layar berbeda. Apakah tiga instance itu adalah string yang sama, atau apakah desainer menulisnya secara independen? Dalam file Figma yang terstruktur dengan baik, mereka mereferensikan kunci string yang sama. Itu berarti satu entri i18n, satu perubahan menyebar ke semana.

Dalam tiga screenshot: tiga kali LLM menghasilkan string hardcoded. Jika Anda membangun aplikasi yang diinternasionalisasi, Anda sekarang memiliki tiga string untuk ditemukan dan diganti alih-alih satu untuk dicari. Hal kecil. Terakumulasi di basis kode nyata.

Mengapa LLM berhalusinasi: ia menderivasi ulang struktur setiap kali

Model tidak memiliki memori tentang run sebelumnya. Setiap kali Anda menempelkan screenshot yang sama, ia merekonstruksi struktur dari awal. Rekonstruksi itu bersifat probabilistik — yang berarti screenshot yang sama + prompt yang sama + model yang sama dapat menghasilkan output yang terukur berbeda pada run yang berbeda. Desain yang sama, kode yang berbeda. Nama komponen berbeda, pola className berbeda, pilihan layout berbeda.

Ini bukan bug model. Ini adalah perilaku yang diharapkan dari model probabilistik yang diberikan batasan yang tidak cukup. Screenshot memberikan batasan yang tidak cukup. Model mengisi celah. Celah diisi secara berbeda setiap kali.

Anda dapat sebagian menyiasati ini dengan prompt yang lebih panjang dan lebih detail — "gunakan Tailwind, gunakan grid 8px, gunakan nama komponen ini..." — tetapi kemudian Anda telah menentukan secara manual struktur yang seharusnya ada dalam file desain sepanjang waktu. Anda melakukan pekerjaan ekstraksi yang seharusnya dilakukan alat.

Masalah reproduksibilitas

Tim yang menggunakan screenshot untuk handoff desain-ke-kode menghadapi masalah yang sama: outputnya tidak dapat direproduksi. Dua pengembang, screenshot Figma yang sama, secara independen meminta Claude — mereka mendapatkan struktur komponen yang berbeda, pola className yang berbeda, keputusan nesting yang berbeda. Sekarang Anda memiliki dua basis kode yang terlihat sama secara visual tetapi tidak konsisten secara arsitektur.

Ini membuat code review lebih sulit. Ini membuat refactoring lebih sulit. Ini membuat audit kepatuhan sistem desain menjadi tidak mungkin. Anda tidak bisa membuat diff "apa yang dihasilkan agen dari desain ini" jika jawabannya berubah setiap run.

Konteks terstruktur memperbaiki reproduksibilitas karena memperbaiki inputnya. Bundel input deterministik — JSON yang sama dengan ID node yang sama, nama komponen, nilai token, dan hubungan spasial — akan menghasilkan output yang jauh lebih konsisten antar run, agen, dan pengembang. Tidak sempurna deterministik: model masih probabilistik. Tetapi variansinya turun drastis ketika strukturnya ditentukan daripada disimpulkan.

Apa yang diberikan screenshot vs. apa yang diberikan IR

Ambil kartu produk: gambar, judul, subjudul, harga, tombol "Tambah ke keranjang". Inilah yang diberikan setiap input ke agen:

Input screenshot: Persegi panjang dengan gambar di atas, dua baris teks, angka, dan tombol. Warna disimpulkan. Padding diperkirakan. Apakah ini komponen atau satu kali tidak diketahui. Varian tombol disimpulkan dari warna. Sistem spacing tidak diketahui.

Input IR: Jenis node FRAME, nama ProductCard, ID komponen yang menautkan ke definisi komponen. Auto-layout dengan arah vertikal, gap 16px, padding horizontal 16px, padding vertikal 12px. Node child: IMAGE (mengisi lebar, tinggi tetap), TEXT dengan stringRef.key: "product.title" dan gaya typography/heading.sm, TEXT dengan stringRef.key: "product.subtitle" dan gaya typography/body.md, TEXT dengan fill color/price, INSTANCE dari Button/Primary/Medium. Fill latar belakang color/surface.card. Border radius radius/card.

IR memberi agen spesifikasi. Screenshot memberinya saran.

Bingkainya: ini adalah masalah dokumentasi

Kami memecahkan masalah persis ini untuk kode sumber beberapa dekade lalu. Anda tidak memberikan agen screenshot basis kode Anda dan memintanya untuk memikirkan arsitektur. Anda memberinya kode — representasi terstruktur, dapat diurai, bermakna secara semantik. Abstract syntax tree, bukan gambar editor.

Desain Figma adalah data terstruktur. Mereka memiliki struktur pohon yang terdefinisi dengan baik dengan node bertipe dan nilai bernama. Figma API sepenuhnya mengekspos struktur ini. Satu-satunya alasan alur kerja screenshot bertahan adalah bahwa mengekstrak struktur dan memformatnya sebagai konteks memiliki gesekan.

Mengurangi gesekan itulah yang dilakukan figmascope. Anda menempelkan URL Figma, ekspor berjalan di browser Anda, dan Anda mendapatkan ZIP dengan konteks terstruktur: CONTEXT.md, tokens.json, IR per-layar, inventaris komponen, manifest string. Semua yang dibutuhkan agen, tidak satu pun yang disimpulkan dari piksel.

Simpan screenshot untuk konfirmasi visual — bundel menyertakan PNG 2x untuk tujuan itu. Gunakan struktur untuk segalanya yang lain. Lihat dalam praktiknya: alur kerja Cursor, alur kerja Claude Code, atau alur kerja Aider.