Menjadikan Claude Code mitra desain terbaik

• Saat pertama kali menggunakan Claude Code, pendekatannya hanyalah instruksi prompt dan revisi berulang, tetapi pada pekerjaan yang kompleks muncul masalah ketergantungan pada riwayat percakapan dan keterbatasan konteks
• Untuk mengatasinya, sebelum implementasi fitur dimulai, AI diminta menulis dokumen rencana (plan document), lalu dokumen ini dijadikan single source of truth (SSOT) untuk sesi baru
• Dokumen rencana mencakup penyusunan ulang kebutuhan, penjelasan detail implementasi, perintah untuk memeriksa kualitas kode, dan terus diperbarui selama implementasi sebagai living document
• Dengan cara ini, masalah hilangnya konteks dapat diatasi, dan bahkan di sesi baru proyek bisa dilanjutkan hanya dengan satu dokumen
• Hasilnya, AI bukan sekadar alat eksekusi, melainkan berperan sebagai mitra desain kolaboratif yang mendorong developer berpikir dan mendokumentasikan desain dengan lebih mendalam

---

Kesadaran masalah: batas pendekatan percakapan sederhana

• Saat bekerja secara interaktif dengan Claude Code, pendekatan ini cocok untuk tugas sederhana, tetapi ketika pekerjaan kompleks membesar, muncul beberapa batasan penting
  • Percakapan menjadi satu-satunya sumber kebenaran, sehingga pesan baru dapat dengan mudah menimpa instruksi sebelumnya, dan sulit menyadari dengan jelas kapan itu terjadi
  • Karena batas ukuran konteks AI, semakin panjang percakapan, semakin besar kemungkinan informasi sebelumnya terlewat
  • Claude Code memang memiliki fitur kompresi percakapan, tetapi itu tidak sepenuhnya menghilangkan keterbatasan ini

Eksperimen pendekatan berpusat pada dokumen rencana

• Untuk menyelesaikan masalah ini, dicoba pendekatan berbasis dokumen rencana
  • Di awal, Claude Code diberi penjelasan sedetail mungkin tentang fitur yang akan diimplementasikan atau bug yang perlu diperbaiki
  • File sumber yang sudah ada atau dokumen rencana yang pernah ditulis sebelumnya juga disebutkan sebagai referensi
  • Instruksi implementasi yang terlalu spesifik dihindari, agar AI terdorong berperan memberi usulan desain
• Jika dokumen rencana sudah cukup memuaskan, riwayat percakapan dihapus dan pekerjaan dimulai lagi dengan hanya rencana tersebut sebagai konteks
  • Rencana mencakup ringkasan fitur, rencana implementasi, kode dan pseudocode, serta perintah type/lint/test

Proses desain kolaboratif

• Saat desain yang diusulkan AI tidak sesuai, diberikan umpan balik yang spesifik untuk mendorong pendekatan yang direvisi
• Dalam proses diskusi, kadang disadari bahwa usulan awal AI justru lebih cocok, dan ini lebih efisien dibanding menulis kode hanya dengan desain sendiri
• Percakapan yang terstruktur memberi pengalaman yang mirip dengan mendiskusikan rencana bersama rekan developer
• AI memang tidak selalu mengajukan pendekatan yang sepenuhnya berbeda dengan sendirinya, tetapi jika ditanya, ia juga dapat menawarkan alternatif lain

Pendekatan Living Document

• Dokumen rencana tidak ditulis sekali lalu selesai, melainkan terus diperbarui bahkan selama implementasi fitur berlangsung
  • Perubahan yang terungkap selama proses implementasi, type check, lint, dan test langsung dicerminkan secara real time
• Terbentuk kebiasaan meminta pemeriksaan status terbaru rencana setiap kali melakukan commit kode
• Karena rencana selalu dijaga dalam keadaan terbaru, pada sesi percakapan baru pun pekerjaan dapat dilanjutkan tanpa kehilangan konteks cukup dengan melampirkan rencana tersebut

Code review dan perubahan kebiasaan pengembangan

• Setelah implementasi dimulai, perubahan ditinjau secara berkala, dan jika hasilnya memuaskan, pekerjaan AI pun bisa lebih dipercaya
• Saat meninjau kode akhir, dokumen rencana yang telah diperbarui membantu memahami dasar pengambilan keputusan teknis
• Dengan menyusun dan mendokumentasikan rencana secara teliti sejak awal, diperoleh pengalaman bertumbuh menjadi developer yang lebih baik
  • Karena harus menjelaskannya kepada AI, proses pengambilan keputusan sendiri menjadi tersusun lebih jelas

Dari kekacauan menuju keteraturan

• Pendekatan ini membuat dokumen rencana menjadi single source of truth, mengatasi masalah hilangnya konteks, dan mendorong pemikiran arsitektural
• Dokumen rencana mencakup sekaligus spesifikasi dan log implementasi, merekam bukan hanya ‘apa’, tetapi juga ‘mengapa’ dan ‘bagaimana’
• Hasil akhirnya adalah proses pengembangan yang terencana, terdokumentasi dengan baik, dan andal
• AI menempatkan diri bukan sebagai implementor semata, melainkan sebagai mitra desain kolaboratif

[jamsya]

Sepertinya dalam alur kerja developer, porsi peran PM dan arsitek menjadi semakin besar.

[GN⁺]

Komentar Hacker News

• Selama 2 minggu terakhir, setiap malam saya sangat fokus membuat "prompt sempurna" agar bisa menyelesaikan proyek sekaligus dengan claude code. Akhirnya saya menyusun struktur agar satu CLAUDE.md merujuk ke 8 file markdown berbeda berisi arsitektur proyek, spesifikasi model, urutan build, lapisan pengujian, skenario, dan lain-lain. Proyek ini untuk tata kelola berbasis model di Databricks Unity Catalog; saya punya banyak pengalaman terkait, tetapi merasa alat yang ada belum cukup fleksibel. Pada akhirnya saya mendapat bantuan dari 3 subagen nyata, seperti pakar Databricks, pakar Pydantic, dan pakar prompt, untuk mengerjakan file perencanaan. Berkat itu, kualitas file markdown meningkat besar di banyak bagian, mulai dari masalah versi Pydantic lama sampai kesalahpahaman saya tentang Unity Catalog. Kemarin saya benar-benar mencobanya, dan selain beberapa kali saya menyetujui penggunaan alat, sebagian besar alat dan pengujian selesai dalam 2 jam. Cara ini terasa sangat berbeda dari sebelumnya dan cukup menakjubkan; saya merasa ada masa depan nyata dalam menulis dokumentasi teknis dengan teliti dan membuat semua pihak melihat ke arah yang sama. Saya juga merasa produktivitasnya lebih baik daripada menggali kode secara langsung. Namun saat mengerjakan kode saya bisa sangat fokus, sedangkan ketika menangani banyak dokumen markdown, konsentrasi lebih mudah buyar. Zaman yang benar-benar menarik

  • Terasa seperti pola yang memaksa kita merancang sistem lebih dulu, mirip Test-Driven Development, sedang muncul kembali. Dulu kita menggambar sistem secara bertahap sambil membuat kode, tetapi pengembangan berbasis AI seperti ini mendorong kita merancang dan memetakan domain lebih dulu, sehingga kode aktual menjadi seperti pekerjaan boilerplate untuk mewujudkan desain. AI memang sangat kuat di boilerplate seperti itu

  • Saya juga mengalami hal yang sama: lebih produktif, tetapi konsentrasi jadi lebih tercecer. Rasanya aneh, tetapi untuk saat ini efektif. Dalam jangka panjang sepertinya perlu dicari solusinya. Cara yang paling cocok saat ini adalah membiarkan banyak agen mengerjakan tugas berbeda di berbagai repositori proyek sambil saya terus memberi persetujuan. Rasanya seperti manajer proyek yang memimpin tim besar. Memang zaman yang menarik

  • Ini benar-benar pendekatan yang segar. Saya penasaran framework apa yang dipakai agar agen bisa berjalan dalam eksperimen nyata

  • Akhir-akhir ini saya juga merekam detail produk, perjalanan pengguna, dan sebagainya lewat suara, lalu memulai proses dokumentasi teknis dari situ. CLAUDE.md seminimal mungkin, pengembangan software memakai workflow Github, tetapi membuat workflow CI yang bagus itu sulit. Playbook saya ada di https://nocodo.com/playbook/

• Saya tidak terlalu terhubung dengan klaim bahwa “hasil akan lebih baik jika membuat rencana dulu”. Dari dulu, untuk fitur besar atau proyek, saya memang selalu memikirkan struktur, alasan, dan caranya lebih dulu, entah di kepala, di kertas, di Confluence, atau di whiteboard. 80% dari software engineering adalah proses memikirkan dan menetapkan ‘apa, mengapa, dan bagaimana’. Kita mengonfirmasi ide dan tujuan dengan para pemangku kepentingan, dan juga melakukan riset. Hanya 20% terakhir yang benar-benar coding. Dari dulu memang begitu, dan saya tidak yakin AI benar-benar dibutuhkan untuk perencanaan atau pendefinisian tujuan yang baik

  • Itu mungkin benar di tim besar atau lingkungan dengan budaya yang sudah mapan, tetapi cukup banyak pengembangan berfokus pada proyek pribadi, tim kecil, side project, POC cepat, atau alat otomasi sekali pakai. Pekerjaan seperti ini biasanya tidak dimulai dari dokumentasi/spesifikasi/pengujian, melainkan berjalan sambil mencampur kode dengan proses berpikir dan implementasi. Ada tempat yang cocok untuk TDD, tetapi ada juga yang tidak perlu. Namun sejak agen coding AI hadir, proses mendefinisikan ide dengan jelas dan merapikannya menjadi spesifikasi menjadi jauh lebih penting. Menjabarkan semua yang ada di kepala saya ke dalam kata-kata jadi sama pentingnya. Bahasa pemrograman terpanas saat ini adalah bahasa Inggris

  • Saya cenderung mencampur pengembangan dan perancangan. Saya mulai coding dulu lalu terus menyempurnakan dan mengembangkannya. Dalam kebanyakan kasus, cara penyelesaiannya sudah cukup jelas sehingga rasanya tidak perlu menghabiskan waktu untuk perencanaan mendalam

• Dulu prompt engineering jadi bahan lelucon, tetapi sekarang saya benar-benar merasakannya. Kadang saya menghabiskan 10~20 menit untuk prompt yang sangat teliti dan perencanaan awal agar bisa memakai Claude Code secara sistematis. Mirip OP, saya juga menyimpan rencana dalam file lalu menjalankannya di konteks baru. Yang benar-benar saya inginkan adalah CLI yang bagus (saat ini memakai charm dan cc). Akan ideal jika model untuk implementasi, perencanaan, dan tiap subagen bisa dipisah. Misalnya implementasi dengan model lokal, perencanaan dengan model cloud, atau ditukar sesuai kebutuhan untuk menghemat biaya. Charm sejauh ini paling bagus untuk berpindah bolak-balik tanpa kehilangan konteks. Fitur subagen paralel juga salah satu fitur terbaik claudecode. (Saya sempat mencoba CCR, tetapi kecewa karena tidak bisa lebih baik dari model bawaan)

  • Prompt engineering jadi isu sekarang karena hot take Twitter atau isu produksi konten. Tetapi sebenarnya prompt engineering sudah penting sejak dulu. GIGO ("Garbage In, Garbage Out") adalah kebenaran di semua proyek machine learning. Karena itu saya terus menyarankan rekan kerja atau teman untuk “coba sendiri”. Sesuatu yang 6 bulan lalu tidak mungkin, sekarang bisa jadi mungkin. Harus benar-benar terbiasa menggunakannya agar tahu apa yang berubah dan apa yang bisa dilakukan. Bagi saya, contoh sukses nyata, blog, gist, dan contoh konkret jauh lebih berharga daripada sikap negatif. Kalau cuma untuk hitungan sederhana atau mencari typo, itu tidak terlalu penting; yang dibutuhkan adalah sesuatu yang benar-benar bisa membantu dan memperbaiki workflow saya. Prompt engineering mirip seperti dulu mendalami kemampuan Google 10~15 tahun lalu, sambil terus mempelajari perubahan baru dan pola yang efektif

  • Untuk bisa berkolaborasi dengan AI, prompt engineering benar-benar inti utamanya

  • Proyek yang memakai AI justru menjadi proyek saya yang paling terdokumentasi dan paling baik pengujiannya. Untuk mendapatkan performa dari LLM, konteks itu wajib, sehingga dokumentasinya jadi lebih baik; dan karena biaya membuat pengujian menurun, jumlah pengujian pun bertambah. Alih-alih kualitas kode menurun seperti yang diprediksi, saya justru melihatnya akan membaik

  • Sejujurnya istilah "prompt engineering" adalah perancangan arsitektur dengan media baru. Dulu skill seperti “merancang diagram” pernah sangat dihargai; sekarang ini adalah bentuk baru dari arsitektur

• Saya baru sebentar mencoba Claude Code, dan berencana mencoba workflow yang direkomendasikan. Sepertinya pendekatan yang cukup bagus. Tapi biaya CC ternyata lebih mahal dari perkiraan. Untuk refaktor sederhana, cuma 5 menit kerja + 15 menit review saja sudah habis $4. Kalau saya kerjakan sendiri, mungkin selesai dalam 15~20 menit. Saya penasaran biasanya orang habis berapa untuk satu fitur dengan CC. Tidak ada yang membicarakan harga

  • Kalau berlangganan, ada biaya flat $20~$200 dengan batas penggunaan token harian/mingguan. https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan

  • Arah yang diinginkan investor AI adalah struktur di mana pasar tenaga kerja digantikan AI dengan margin 15%. Akan datang masa ketika anggaran untuk pengembang dan AI setara 1:1. Misalnya, porsi satu pengembang senior bergaji $100 ribu akan digantikan oleh anggaran AI $100 ribu. Anggaran AI akan diambil dari biaya pengembangan, gaji senior kemungkinan turun, dan ukuran tim pengembang bisa menyusut drastis. Saat ini kita masih berada di tahap 'merebut wilayah' yang seluruhnya disubsidi VC, tetapi melihat suasana VC di Twitter, tahap ini tampaknya akan segera berakhir. Terus menarik lagi ratusan juta dolar untuk operasional 9 bulan juga ada batasnya

  • Setelah sebagian berpindah dari Cursor ke Claude Code, biaya saya naik banyak. Karena kebanyakan dipakai di kantor, mudah meyakinkan atasan, tetapi untuk side project saya jadi ragu. Saya tidak ingin membayar $20 setiap kali sekadar ingin bootstrap aplikasi untuk bersenang-senang

  • Kita bisa memilih dan berlangganan dua model: Sonnet (20 euro/bulan) dan Opus (100 euro/bulan). Saya dulu memakai Sonnet lalu belakangan pindah ke Opus. Sonnet pun sudah cukup layak dipakai. Selama masih dalam batas token, untuk kebutuhan saya sejauh ini tidak terasa kurang. Tetapi saya tidak yakin ke depan bagaimana

  • Anda bilang, "Kalau saya kerjakan sendiri juga selesai dalam 15~20 menit", tetapi mungkin 15~20 menit itu bisa dipakai untuk pekerjaan lain

• Cara saya memakai kombinasi Visual Studio Code/ChatGPT5 preview mirip dengan workflow ini {mungkin saya membayar lewat langganan Github Copilot, tetapi belakangan saya tidak terlalu yakin}. Saya merasa LLM non-agen sangat mudah membuat kode cepat berantakan. Sejak memakai mode agen, cara membangun kode berubah drastis. Saya bukan pengembang Python, tetapi melihat LLM menyusun bongkahan kode baru sungguh cukup mengesankan. Setelah selesai, saya berencana menjalankan LLM kecil di BitGrid dan memahami kode sepenuhnya belakangan. Polanya adalah mengulang tahap eksplorasi kecil lalu hanya mengedit sebagian agar desain keseluruhan tetap seperti yang saya inginkan. Ini membuat saya yakin pada masa depan di mana LLM menjadi partner pemrograman. Saya penasaran apakah ada orang lain yang juga memakai kombinasi Visual Studio Code/ChatGPT5

• Menarik melihat bahwa saat orang berusaha mengoptimalkan alat AI, para pengembang tampaknya menemukan kembali nilai dari 'komunikasi yang baik' dan 'penetapan ekspektasi'. Sudah waktunya citra developer 10x selama ini, yakni sosok outsider atau eksentrik, ditinjau ulang

• Saya punya pengalaman serupa di Replit. Saat ukuran aplikasi membesar, kalau dokumen desain tidak menjadi sumber kebenaran untuk tugas dan sistem, semuanya cepat runtuh. OpenAI membuat chat melambat dan cepat macet, jadi membuat dokumen terpisah lalu mengimpornya ke chat baru sangat membantu. Pada level manusia pun, saya merasa kita juga memang harus begitu. Dengan merefleksikan diri, mendokumentasikan, dan mencatat ‘memori’ ke dokumen desain, kita bisa membebaskan diri kita sendiri maupun LLM

• Saya juga baru-baru ini menemukan workflow ini dan sangat terkejut. Yang penting adalah memberi kebutuhan minimum saja ke claude dan membiarkan mode perencanaan berjalan bebas. Kalau misalnya laporan metrik penjualan, cukup katakan "Ultrathink relevant sales metrics" dan ia akan memberi beragam metrik, memeringkatnya, lalu membantu menyaringnya. Saya membuat direktori terpisah untuk setiap fitur baru dan menyuruhnya menulis rencana fitur itu dalam file. Setelah itu saya minta bertahap: rencana implementasi, query data yang diperlukan, implementasi nyata, pengujian, dokumentasi pengguna, lalu kirim ke QA. Dulu membuat satu fitur prediksi penjualan saja butuh tim besar dan waktu lama, tetapi claude mengimplementasikannya sebagai container Docker dalam setengah hari. Perubahan ini sedang mengubah cara pandang saya terhadap software. Dulu perusahaan sama sekali tidak mau mengeluarkan source code karena NDA, IP, dan sebagainya. Tetapi sekarang, bahkan sistem ERP kompleks yang butuh 20 tahun pun bisa direimplementasikan dengan cepat oleh claude lengkap dengan dokumentasi dan pengujian. Secara realistis memang belum sempurna, tetapi kecepatannya benar-benar luar biasa

• Untuk mendapatkan fitur bagus dari Claude Code, kuncinya adalah menulis rencana dengan benar terlebih dahulu. Belakangan ini saya memakai GPT-5 High di Cursor untuk membuat rencana, lalu memasukkannya ke Claude Code untuk implementasi. Kalau kita memintanya mendokumentasikan lebih dulu bagian kodebase yang akan diubah, hasilnya bisa 15~20% lebih baik. Jika model perencana mendokumentasikan cara kerja, arsitektur, pola, dan desain fitur di sana, hasil akhirnya lebih baik. Terakhir, sangat membantu jika kita benar-benar meninjau dan mengedit sendiri dokumen dan rencananya

  • Di perusahaan kami memakai Google Workspace, jadi Gemini sangat kuat untuk tulisan “bergaya akademik”, tetapi lebih lemah dalam menulis kode dibanding CC. Karena itu saya minta Gemini menyusun rencana dengan cukup rinci, lalu saya serahkan ke CC untuk mengubah dan mengimplementasikannya di codebase saya. Dengan cara ini, saya melihat hasil yang mengejutkan untuk pengembangan fitur baru maupun perluasan fitur lama. Dalam 8 minggu, produk yang saya buat sendiri kini sudah berjalan di produksi nyata dan bahkan dipakai untuk demo pelanggan. Saya sangat puas dengan pengalaman dan hasil CC. Seperti yang pernah saya sampaikan di HN, dengan SDM tim kami sendiri pun sebagian besar hal ini sebenarnya bisa dilakukan, tetapi pekerjaan frontend bahkan tidak berani kami bayangkan. Hal yang tadinya akan memakan waktu lebih dari 1 tahun dan membutuhkan upaya lebih banyak engineer serta data scientist kini sebagian besar selesai hanya dalam 2 bulan. Menambahkan fitur jadi hampir bisa dilakukan dalam ‘hitungan detik’, bukan waktu yang berarti. Berkat CC, menarik bagi saya melihat pengalaman saya ternyata dibagikan juga oleh banyak orang lain

• Saya penasaran apakah ada yang sudah menemukan cara bagus untuk memasukkan desain frontend ke proses seperti ini dengan elegan. Kebanyakan hanya berhenti di penyebutan framework frontend, atau sekadar gambar figma. Dengan itu saja, rasanya belum seperti solusi desain yang terintegrasi sepenuhnya