Sekarang saya lebih sering mendesain dengan Claude daripada Figma

• Alur kerja desain sedang bergeser dari cara meninjau implementasi lewat dokumen spesifikasi dan mockup Figma, menjadi alur pembuatan fitur prototipe yang berjalan di codebase nyata
• Copilot, Cursor, dan Gemini tidak memenuhi harapan pada pekerjaan seperti modifikasi game, product brief, dan wireframe yang sebelumnya sudah dikuasai, tetapi di lingkungan OCaml dan Bonsai yang harus dipelajari dari nol, dukungan AI menjadi elemen yang esensial
• Setelah masalah dan usulan diberikan sebagai prompt, proses berlanjut ke implementasi nyata: membangun fungsi dasar, revisi berulang, deployment ke environment pengembangan, memeriksa pendapat pengguna, lalu mengajukan feature
• Prototipe yang menambahkan prompting LLM pada input JSQL membuat tombol, shortcut, copy, prompt, dan pesan konfirmasi disempurnakan berkali-kali, sehingga upaya bisa difokuskan pada hasil nyata alih-alih komponen Figma atau format dokumen
• Kini desainer bisa langsung mewujudkan ide ke bentuk yang dapat dipakai, tetapi prototipe yang tampak seperti fitur jadi juga membawa tantangan baru untuk cara review dan eksplorasi kreatif

---

Dari skeptis terhadap LLM menjadi alat dukungan yang wajib

• Selama lama menggunakan LLM, hasilnya sering mengecewakan, dan setiap kali diterapkan pada pekerjaan yang sebenarnya sudah dikuasai, kualitasnya terasa lebih rendah daripada mengerjakannya sendiri
• Tahun lalu, saat mencoba memodifikasi game yang dibuat sebelumnya, Copilot dan Cursor sama-sama gagal menghasilkan perubahan yang benar-benar berjalan; di perusahaan sebelumnya, Gemini juga dicoba untuk membuat kerangka product brief dan wireframe, tetapi semuanya dibuang
• Setelah bergabung dengan Jane Street musim panas lalu, ada banyak hal baru yang harus dipelajari, dan karena teknologi seperti OCaml dan Bonsai masih belum akrab, dukungan AI menjadi bagian yang sangat penting
• Perubahan besarnya adalah AI kini mengubah bahkan alur kerja desain yang paling dikuasai sekalipun

Prototipe di codebase nyata, bukan Figma atau dokumen

• Alih-alih menulis dokumen spesifikasi, membuat mockup Figma, menulis proposal, lalu meninjau implementasi bersama developer, kini yang dibuat adalah fitur prototipe yang melakukan persis fungsi yang ada di kepala
• Alur nyatanya adalah menulis kalimat yang menjelaskan masalah dan usulan, lalu menjalankan build, server, dan Claude di editor, dengan penjelasan yang ditulis tadi dipakai sebagai prompt
  • Menjalankan fungsi dasarnya terlebih dahulu untuk memeriksa kemungkinan, lalu merevisi berulang kali sebanyak yang diinginkan
  • Mengunggah perubahan ke environment pengembangan, meminta pendapat pengguna, lalu mengajukan feature yang sudah memiliki bentuk dan perilaku yang diinginkan
  • Di Jane Street, feature adalah proses yang setara dengan pull request
• Fitur prototipe di dalam codebase nyata memberikan pengalaman yang lebih baik hampir dalam semua hal dibanding mockup dan dokumen
• Salah satu contoh terbaru adalah prototipe yang menambahkan prompting LLM ke input JSQL, yang benar-benar berfungsi dan diuji dengan dipakai langsung selama beberapa hari
  • JSQL adalah dialek SQL internal yang digunakan pada alat untuk banyak pengguna
  • Claude memberi ruang iterasi yang bebas dan nyaris tak terbatas, tanpa keberatan meski ada perubahan pikiran ke-50 atau permintaan revisi kecil
  • Tombol Submit, shortcut keyboard, copy, prompt, hingga pesan konfirmasi yang dihasilkan semuanya ikut diperbaiki
• Di tempat kerja sebelumnya, perbaikan alur kerja seperti ini akan membutuhkan bolak-balik selama berhari-hari atau berminggu-minggu antara engineering dan desain, atau bahkan lebih besar kemungkinannya tidak terjadi sama sekali
• Upaya yang dicurahkan ke fitur ini terfokus pada peningkatan hasil nyata, bukan pada output antara seperti membuat komponen Figma atau menyesuaikan format dokumen

Cakupan yang meluas dalam dua bulan terakhir

• Butuh waktu untuk sampai ke alur seperti ini, dan pada masa awal bergabung, AI hanya dipakai untuk pekerjaan kecil seperti memperbaiki gangguan UX yang minor
• Untuk ide besar, Figma dan dokumen masih dipakai, dan upaya membuatnya dengan Claude terus gagal
• Dalam 2 bulan terakhir, situasi yang membuat Figma perlu dibuka menurun drastis, dipengaruhi oleh model yang makin baik, keterampilan memakai alat yang meningkat, dan pemilihan cakupan yang tepat
• AI bekerja bukan hanya untuk prompt JSQL, tetapi juga pada sekitar enam prototipe yang membuat perubahan untuk pengguna, model data, dan library
  • Beberapa prototipe memiliki diff lebih dari 2000 baris
  • Juga dipakai untuk mengimplementasikan prototipe interaktif dari aplikasi baru yang dirancang di Figma
  • Beberapa aplikasi baru bahkan melewati Figma dan langsung mengiterasi desain visual dengan Claude sejak awal

Memperluas peran desainer dan mendefinisikan ulang cara review

• Saat engineer punya ide, mereka bisa membuat proof of concept yang berjalan, tetapi desainer berada dalam struktur yang mengharuskan mereka meyakinkan orang lain untuk membuatkannya
• Ide seperti “prompting LLM langsung di dalam input JSQL” belum jelas kelayakannya pada saat awal, sehingga jika prototipe didelegasikan ke orang lain, ada risiko membuang waktu mereka
• Sebagian usulan mungkin tidak benar-benar memenuhi kebutuhan pengguna, dan ketika ide diwujudkan lewat Claude ke bentuk nyata, orang lain jadi lebih mudah menilai dengan memakainya langsung
• Sisi buruknya, reviewer bisa merasa seperti menerima fitur yang sudah jadi, sehingga menjadi tidak jelas apakah mereka diminta meninjau kode saja tanpa memberi masukan pada fiturnya
• Dalam analogi desain, ini mirip PM yang memberikan wireframe sangat detail lalu meminta agar dibuat terlihat bagus, yang bukan pekerjaan review yang menyenangkan
• Usulan memang harus jelas dan lengkap, tetapi rekan engineer juga perlu memperlakukannya seperti mockup Figma: sesuatu untuk diiterasi bersama di dalam ruang desain
• Solusi saat ini adalah menambahkan pemberitahuan singkat pada deskripsi feature
  • Prototipe adalah dokumen usulan yang hidup
  • Kodenya bisa dibuang
  • Peran reviewer adalah memberi umpan balik tentang desain dan pengalaman pengguna
• Pada akhirnya, reviewer mengambil alih idenya lalu mengimplementasikannya dalam feature terpisah, merujuk ke prototipe, sementara kode produksi tetap dimiliki oleh reviewer
• Dalam pekerjaan nyata, masih terus dicari tahu apa yang terasa masuk akal dan baik dalam alur kerja baru ini

Batasan kerja iteratif dan rasa kembali ke medium yang nyata

• Ada kekhawatiran bahwa mendesain dengan Claude bisa menjauhkan dari pola pikir yang cair dan kreatif, lalu membuat iterasi terjebak dalam hasil yang dianggap Claude mungkin dibuat
• Jika perubahan yang dilakukan bersifat iteratif seperti pada alat yang sudah matang, ini tidak masalah, tetapi saat membuat hal baru, ada risiko ide-ide tertentu terlewat
• Saat memulai karier profesional pada 2011, banyak diskusi tentang designers should code, dan para pengkritiknya berargumen bahwa begitu mulai memprogram, akan sulit membuat perubahan besar pada ide
• Karena menyukai pembuatan website dan pemrograman, penulisan kode terus dilanjutkan, tetapi setelah framework frontend seperti React menjadi umum dan pengembangan frontend makin kompleks, akhirnya dipilih jalur spesialisasi
• Proyek pribadi dengan React membantu saat berinteraksi dengan developer, tetapi di tempat kerja hampir seluruh waktu dihabiskan di Figma dan dokumen
• Jika bergabung dengan Jane Street sebelum era LLM, kemungkinan besar akan makin terikat pada Figma, dan berbeda dengan JavaScript, OCaml dan Bonsai terasa benar-benar baru sehingga kontribusi teknis akan terasa seperti sesuatu yang berada di luar jangkauan
• Sekarang, hasil nyata kembali dibuat secara langsung, bekerja di dalam medium itu sendiri, dengan perasaan memiliki kebebasan lebih besar untuk mencoba apa pun

[GN⁺]

Komentar Hacker News

• Dari sisi bisnis, mereka sudah sering datang membawa solusi yang mereka pikirkan sendiri sebagai bentuk requirement, dan biasanya seperti alat Rube Goldberg, jadi harus di-reverse-engineer lewat percakapan dulu untuk sampai ke requirement yang sebenarnya
  Ke depannya, sepertinya mereka akan datang membawa solusi yang sudah “siap” dan “berfungsi”, dan akan makin tidak terbuka terhadap ajakan untuk melihat desain dan arsitektur secara menyeluruh
  Kemungkinan akan jadi, “Kan tinggal dibuat begini saja. Sudah hampir selesai, kenapa masih perlu X engineer?”

  • Saya sudah melihat yang seperti ini, dan memang dibuat dari awal sampai akhir dengan vibe coding
    Kekurangannya, pihak bisnis tidak paham kenapa aplikasi itu tidak bisa langsung dijalankan di produksi begitu saja
    Tekanan seperti “kan bisa dipercepat pakai AI” akan makin besar, dan pada akhirnya ini akan bergantung pada dinamika organisasi yang sehat atau tidak
    Sisi positifnya, idenya sudah diuji jauh lebih menyeluruh dibanding sketsa di atas serbet
    Claude kemungkinan besar sudah menanyakan edge case dan keputusan desain, dan ada peluang besar pada titik tertentu mereka secara eksplisit bilang, “anggap saja itu tidak penting” atau “setelah dicoba beberapa kali, interaksi ini kurang bagus, tolong ubah”
    Saat ini tekanan “apa masalahnya, tinggal deploy saja” masih kuat, bodoh, dan mematahkan semangat sehingga nyaris jadi rugi bersih, tapi kalau nanti stabil, bisa saja menjadi keuntungan bersih untuk proyek-proyek masa depan
  • Terlalu sering masuk dalam bentuk “ini sudah hampir selesai, cuma perlu beberapa perbaikan kecil sebelum deploy ke produksi”
    Perbaikan kecil itu misalnya layout rusak kalau lebar browser tidak tepat 1920px, filter dan sorting kadang tidak jalan dengan benar, atau nilai baru tidak terbarui dengan benar di aplikasi setelah tindakan tertentu
    Terlepas dari masalahnya, pihak bisnis mengira mereka sudah menyelesaikan 95%, jadi dari awal berasumsi bahwa “developer berpengalaman pasti bisa cepat membereskannya”
  • Hal seperti ini sudah lama umum di dunia audio engineering sejak musik demo rumahan mulai mendekati kualitas profesional
    Orang jadi terbiasa dengan hasil yang mereka punya, dan makin sulit menerima perubahan dari mixing profesional yang baru
  • Di tempat kami juga begitu: pihak bisnis membawa solusi yang mereka pikirkan sendiri seolah itu requirement, padahal biasanya itu bukan yang diinginkan pelanggan
    Memang ada PM, CSM, dan TAM yang punya insting untuk menerjemahkan masalah pelanggan menjadi fitur produk yang usable, tetapi kalau definisi masalah dilewati dan organisasi fungsi lain dipaksa membuat solusi, biasanya itu berakhir jadi bencana yang membuang banyak sumber daya engineering dan sumber daya lain
    Kalau seseorang datang membawa solusi, ada risiko besar baru setelah berbulan-bulan membangun software yang layak dioperasikan kita sadar bahwa pelanggan membencinya, tidak menyelesaikan masalah mereka, atau malah menciptakan masalah baru
  • Ini benar-benar sedang terjadi sekarang
    Bukan di tempat saya sekarang, tetapi di tempat lama saya, hal seperti ini bahkan sampai dideploy ke produksi meski membawa kehilangan data dan masalah keamanan

• Setahu saya Jane Street adalah investor Anthropic, jadi hal itu perlu diperhitungkan

  • Ini harus ditanggapi dengan skeptisisme yang sangat besar
    Ada juga fakta bahwa pada Juli 2025, regulator pasar modal India SEBI menuduh Jane Street melakukan manipulasi pasar lewat beberapa entitas dan melarang akses mereka ke pasar
  • Sepemahaman saya, Jane Street banyak berkontribusi pada OCaml dan juga membuat framework web internal mereka sendiri
    Wajar saja, peti uang yang besar pasti butuh banyak dashboard
    Di sini, si desainer tampaknya mengambil pendekatan yang keliru dan terlihat terjebak dalam kekaguman pada engineer, ingin membuat prototipe sedalam dan serealistis mungkin
    Padahal itu bukan bagian terpenting dari pekerjaan desain
    Yang paling penting adalah memastikan yang dibuat itu memang hal yang benar
    Pertanyaan seperti “kenapa perlu kotak input JSQL? sebenarnya yang diinginkan apa? alternatifnya apa?” sering kali lebih baik dipecahkan lewat sketsa pena dan kertas, rapat, observasi, dan diskusi
    Itu lebih baik daripada terlalu cepat mengerucut ke desain tertentu lalu masuk ke perdebatan seperti tombolnya di kiri atau kanan, atau detail perilaku LLM seperti apa
  • Bahkan kalaupun bukan investor, saya juga tidak yakin seberapa penting kita harus peduli pada pandangan desain frontend dari perusahaan quantitative trading
  • Seluruh HN sekarang terasa seperti papan iklan AI raksasa
  • Mungkin tidak perlu melihat bahkan tulisan blog yang lumayan menarik dari karyawan acak sebagai bentuk perang psikologis
    Meski tentu saja, bisa jadi memang itulah yang mereka ingin orang pikirkan

• Kadang saya melihat ini juga
  Saat ini LLM tidak bisa melihat melampaui pengulangan, jadi saya harus berpikir out of the box dan berkata, “bagaimana kalau dilihat dari sudut pandang ini?” baru tiba-tiba muncul cara desain yang baru
  Kadang saya harus membuat diagram alur agar LLM bisa melihat melampaui tahap progresnya sendiri

• Dari kalimat “Claude memberi saya iterasi gratis tak terbatas yang tidak peduli kalau saya berubah pikiran untuk ke-50 kalinya atau meminta revisi kecil,” memangnya dia tidak membayar Claude?

  • Di sini, “gratis, iterasi tak terbatas, tidak peduli” tampaknya lebih mendekati arti bahwa saat bekerja dengan proyek pihak ketiga atau desainer lepas, biasanya harganya adalah “draft + 1 revisi”, lalu setiap perubahan setelah itu kena biaya tambahan
    Studio desain kecil juga mirip, dan sering kali bukan ditagih per jam seperti developer
  • Pada 2025, laba bersih per karyawan Jane Street berada di kisaran beberapa juta dolar per orang, itu pun berdasarkan laba, bukan pendapatan
  • Sepertinya yang dimaksud gratis bukan soal harga, melainkan kebebasan kreatif tanpa kerja manual
  • Sedikit terkait, saya pernah berada di wawancara dengan CEO, lead developer, dan lead designer, lalu mendapat pertanyaan klise “apa kelemahanmu”
    Saya menjawab dengan jujur bahwa saya benar-benar buruk dalam desain, dan bahkan kesulitan mengekstrapolasi design system
    Sangat sulit bagi saya untuk mencapai titik yang terlihat oke, dan dalam prosesnya hampir selalu malah saya buat lebih buruk
    Desainer yang mewawancarai saya menganggapnya personal dan menekan saya
    Sebelumnya juga pernah mirip begitu
    Para desainer tidak suka dengan pertanyaan yang terus-menerus tentang tampilannya harus seperti apa, dan maunya serah-terima sekali lewat lalu selesai
    Bahkan di agensi marketing dan periklanan, saya harus terus berdebat untuk meminta contoh bagaimana hal-hal yang tidak ada di spesifikasi desain itu seharusnya terlihat
    Bukan berarti saya pasti benar, tetapi itu memang tumit Achilles besar bagi saya
    Jadi ketika saya mendengar “gratis, iterasi tak terbatas, tidak peduli”, yang terlintas duluan bagi saya adalah waktu dan kesabaran, bukan uang
    Bolt yang saya pakai untuk prototyping tidak pernah marah
    Mungkin tidak menghasilkan desain terbaik, tetapi jauh lebih baik daripada yang bisa saya buat sendiri, dan setelah selesai bisa diberikan ke desainer sungguhan untuk diperbaiki lagi
    Sampai saat itu, saya tidak perlu khawatir membuat seseorang kesal

• Saya sudah memakai Claude Design untuk frontend.
  Bentuk dan nuansa hasilnya sudah cukup bagus, tetapi desainnya sering terlihat mirip dan umumnya mengikuti pola klise web modern.
  Saya penasaran apakah ada yang pernah mencoba eksperimen kreatif yang tidak lazim dengan ini.

  • Coba lihat situs portofolio ini, paling bagus dilihat di desktop.
    Sejauh ini saya menghabiskan sekitar 3 minggu dan masih belum selesai, tetapi Anda akan menangkap maksudnya.
    Seperti halnya ada boilerplate SaaS selama 10 tahun terakhir, ada juga boilerplate LLM yang dipelajari dari internet.
    Meski begitu, jika cukup banyak campur tangan manual, apa pun tetap mungkin dilakukan.
  • Saya juga punya pengalaman seperti itu, jadi saya mulai menguji prompt dan input yang berbeda.
    Menarik bahwa ia bisa menyesuaikan saat diberi kebutuhan, dan membuat pilihan aman saat tidak diberi arahan.
    Jika Anda akan menilai estetika output serta pengalaman pengguna dan kontennya, tetapi hampir tidak memberi prompt soal estetika, ya yang Anda dapat hanya default aman.
    Ia bagus dalam membuat desain yang terasa seperti tiruan bootstrap/tailwind, tetapi bagian itu memang perlu didorong secara sadar.
    Untuk halaman web sederhana, saya mulai menjadikan gaya visual sebagai satu-satunya fokus pada iterasi awal.
  • Sebagian besar aplikasi tidak memerlukan kreativitas yang tidak lazim.
  • Saya juga mirip.
    Tinggal beri instruksi spesifik agar tidak terlihat standar, lalu beri contoh gaya situs web yang diinginkan.
    Kalau sedikit diutak-atik, hasilnya terasa lebih kreatif, tetapi tetap perlu rekayasa prompt.
  • Saya juga memakai Claude Design.
    Ini direkomendasikan oleh desainer yang sangat dihormati dan berpengalaman, dan sekarang mereka hampir sepenuhnya membuat prototipe di Claude lalu menyempurnakannya di Figma jika sudah suka.
    Wajar saja kalau meminta UI umum tanpa prompt gaya yang detail, hasilnya juga desain umum.

• Keuntungan di sini adalah desainer belajar coding.
  Selalu terasa aneh bagi saya bahwa desainer membentuk software tanpa tahu bagaimana software dibuat.
  Sebagai catatan, saya juga seorang desainer.
  Hanya saja, mendesain lewat kode adalah pendekatan berpusat pada teknologi.
  Jika tujuan desain adalah membentuk keluaran agar sesuai dengan tujuan manusia, bisa juga dikatakan lebih baik tidak memulai dari aturan kaku kode.
  Bukan karena hasil yang enak dilihat, tetapi untuk mendorong pemikiran ke depan, pena dan kertas masih sulit dikalahkan.

  • Setelah 6 tahun bekerja sebagai engineer full-stack dan berfokus pada frontend, saya bosan menulis kode dengan tangan lalu pindah ke desain.
    Sekarang kita pada dasarnya bisa coding dengan suara, jadi saya kembali lagi ke vibe coding dan membangun produk, dan rasanya luar biasa.
    Atasan saya masih mencoba memahami situasi baru ini, tetapi pembagian peran lama tampaknya mulai mati.
    Menurut saya, berada di persimpangan itu adalah posisi terbaik saat ini.
    Rasanya seluruh hidup saya telah mempersiapkan momen ini.
  • Memahami batasan medium itu membantu, tetapi tidak perlu tahu setiap lapisan sampai ke level elektron bergerak di dalam silikon.
  • LLM biasanya membuat orang melupakan coding, jadi saya ragu apakah memakainya seperti ini akan bagus untuk belajar.
    Bagi desainer, ini mungkin seperti Figma di mana Anda melihat hasil lalu merevisinya dengan bahasa alih-alih editor visual.
  • Ini bukan berarti para desainer belajar coding.
    Istri saya adalah manajer produk di FAANG, dan timnya sangat mengandalkan AI untuk vibe coding potongan software yang tadinya akan mereka kerjakan dengan Word atau Excel.
    Mereka tidak belajar coding, dan tidak pernah melihat kode itu sedetik pun.
  • Anda tetap butuh desainer yang pernah bekerja dekat dengan engineer dan punya penilaian yang matang.

• Pendekatan bahwa “prototipe adalah dokumen usulan yang hidup, kodenya boleh dibuang, dan tugas reviewer adalah memberi umpan balik pada desain serta pengalaman pengguna.
  Pada akhirnya reviewer mengambil idenya lalu mengimplementasikannya sebagai fitur terpisah, menjadikan prototipe sebagai referensi, tetapi tetap memiliki kode produksi sendiri” menyelesaikan masalah yang selalu saya alami di semua POC.
  Ini pendekatan yang sangat bagus.

  • Tulisan itu bukan ditulis oleh orang yang mencari nafkah dengan Figma.
    Saat membahas isu spesifik dari produk tertentu, memang mudah menyebutnya “dokumen usulan”.
    Namun tetap ada sangat banyak desainer yang memakai Figma untuk mendefinisikan dan memelihara sistem desain lintas produk dan platform, dan dalam kasus itu Figma adalah sumber kebenaran.

• Tim kami juga bekerja seperti ini, dan saya seorang engineer frontend, tetapi sejujurnya saya sangat merindukan cara lama.
  Karena spesifikasi tertulis digantikan oleh prototipe yang berjalan, sekarang ada beban kognitif tambahan: saya harus membaca kodenya dan menilai perubahan mana yang memang dimaksudkan, dan mana noise yang harus dibuang.
  Saya menerima PR yang dihasilkan lalu harus memutuskan apakah akan melakukan perubahan yang diperlukan atau membangunnya ulang dari nol, dan apa pun pilihannya tetap menimbulkan gesekan.
  Pernah juga banyak perubahan tak disengaja ikut dihasilkan, lalu setelah saya menghabiskan waktu memindahkannya lewat implementasi ulang, belakangan saya mendengar, “Oh, maaf, itu sebenarnya bukan yang mau diubah.”
  Saya paham bahwa ini memberi lebih banyak kuasa, tetapi juga merampas sebagian kesenangan yang dulu saya rasakan dalam pekerjaan ini dan mengubahnya jadi sumber pusing.

  • Saya juga ada di posisi serupa.
    Tim desain dan produk melakukan vibe desain dan coding fitur atau pengalaman dengan Claude, membuat prototipe dengan cepat, lalu membawanya ke hadapan pelanggan untuk mendapat masukan dengan waktu engineering yang minimal.
    Itu hebat.
    Namun mungkin mengejutkan bahwa secara keseluruhan ini tidak terlalu membantu peluncuran jadi lebih cepat.
    Menurut saya alasannya adalah karena kita kehilangan proses berpikir di sepanjang jalan.
    Tidak sedikit pemikiran yang sekarang dialihdayakan ke model bahasa.
    Ia menutupi celah dalam prompt dan mengisi perilaku yang tidak disebutkan secara eksplisit dengan halusinasi.
    Dulu kita akan berhenti di titik-titik seperti “ini kurang pas”, “bagaimana saya menyampaikan ide ini”, atau “bagaimana dengan kasus ini”, tetapi sekarang itu menghilang, dan detail-detail seperti itu ditunda sampai setelah semuanya dibuat dengan rapi.
    Tentu kita bisa memperbaiki proses dan meninjau cara memanfaatkan teknik baru ini dengan lebih baik, tetapi apakah ini lebih baik daripada sebelumnya? Saya tidak yakin.
  • Apakah tidak bisa meminta Claude Design menulis dokumen yang sepenuhnya menspesifikasikan prototipenya?
  • Cara lama itu lamban, siklus umpan baliknya panjang, dan melakukan gatekeeping pada UI.
    Itu sedang ditinggalkan.
    Sekarang orang backend juga mengerjakan frontend.
  • Kode sekarang bukan dibuat untuk dibaca.
    Itu salah pahamnya.
    Apakah Anda memelototi assembly yang dihasilkan compiler? Tidak.
    Lalu kenapa Anda melihat kode ini?
    Kita hanya menaikkan lapisan abstraksi.

• Saya juga sering memakai pendekatan yang sama
  Bahkan sebelum AI pun saya melakukannya secara manual
  Mula-mula duduk bersama pengguna hanya dengan pena dan kertas, lalu cepat membuat POC atau demo frontend, membiarkan pengguna mencobanya, lalu menyesuaikannya sampai berjalan sesuai yang diinginkan
  Bagi saya, membuat demo frontend cepat dalam bentuk kode, bukan kualitas produksi, sering kali sudah lebih cepat daripada membuat interaksi yang presisi di Figma
  Karena interaksinya bisa sepenuhnya berjalan, saya bisa menangkap jauh lebih banyak kasus tepi dari sisi pengalaman pengguna
  Sekarang berkat Claude Code, membuat prototipe sekali pakai jadi lebih cepat, tetapi bedanya tidak terlalu besar
  Karena 80% dari keseluruhan waktu dipakai untuk berdiskusi dengan pengguna dan memikirkan bagaimana seharusnya sesuatu bekerja, Claude kira-kira hanya memangkas separuh dari 20% sisanya dibanding saat saya membuatnya sendiri dengan cepat
  Versi pertama memang lebih cepat, tetapi iterasinya lebih lambat ketika belum benar-benar memahaminya

• Edwin, senang melihat tulisanmu terbit
  Saya ingat kita pernah ikut hackathon bersama sekitar 2012/2013
  Kemampuan untuk mencapai prototipe yang berfungsi dengan lebih cepat sangat memberdayakan, meskipun ada godaan untuk langsung merilis ide yang belum matang begitu saja
  Kebutuhan desain dan pengalaman pengguna mendapat manfaat besar ketika kita bisa melampaui storyboard dan wireframe untuk benar-benar menyentuh dan mengalami alur yang nyata