Pengalaman 6 minggu menggunakan Claude Code

• Sejak mengadopsi Claude Code, cara menulis dan memelihara kode dalam skala besar berubah drastis—bahkan bisa diibaratkan seperti “masuknya fotografi ke dunia coding”, karena kini implementasi cepat dan kebebasan berekspresi menjadi mungkin
• Pekerjaan yang berulang dan dulu dianggap sebagai ‘utang teknis’ (migrasi, penggantian framework, dll.) kini bisa ditangani dengan cepat seorang diri secara paralel, hampir tanpa beban meski dikerjakan bersamaan dengan pekerjaan utama
• Pola pengembangan eksperimental dengan pendekatan “coba dulu, nilai belakangan”, sambil dengan mudah membuat dan menghapus kode pengujian/abstraksi/eksperimen, memberi peningkatan produktivitas dan wawasan pengembangan
• Prototyping game, kolaborasi, dan deployment eksperimental melesat jauh lebih cepat—desainer game bisa mewujudkan ide hingga eksekusi dalam hitungan jam tanpa menulis kode sendiri
• Dalam lingkungan yang ramah Claude Code seperti monorepo, tech stack yang jelas, dan codebase yang mutakhir, kecepatan serta fleksibilitas pekerjaan pengembangan nyata meningkat besar

---

Pendahuluan: perubahan setelah mengadopsi Claude Code

• Selama 6 minggu terakhir menggunakan Claude Code, terasa ada perubahan besar dalam cara menulis dan memelihara kode
• Terasa seperti memperoleh "kebebasan berekspresi" karena tidak harus menulis seluruh kode secara langsung sendiri
• Dengan Claude Code, kita bisa merancang struktur keseluruhan sekaligus lalu menghasilkan output melalui kemampuan review dan editing
• Seperti ketika fotografi muncul dan daya tarik menggambar dengan tangan berkurang, proses input dan produksi dalam pemrograman kini juga sedang berubah besar
• Perubahan ini bisa terasa mengkhawatirkan, tetapi kemunculan alat berbasis LLM sedang memicu pergeseran paradigma dalam pemrograman

1. Cara Claude Code mengubah penulisan dan pemeliharaan kode

• Pekerjaan migrasi, refactoring, dan pelunasan utang teknis yang dulu memakan waktu berminggu-minggu hingga berbulan-bulan, semuanya bisa dikerjakan paralel dan diselesaikan dalam 6 minggu setelah mengadopsi Claude Code
• Contoh: mengonversi ratusan komponen React Native ke React, mengganti sistem RedwoodJS, migrasi Jest→Vitest, server-side rendering, refactoring design system, upgrade ke Node 22, dan lain-lain
• Side project/backlog yang sebelumnya harus dijadwalkan dan ditangani terpisah, kini bisa dikerjakan di waktu senggang sambil tetap menjalankan pekerjaan utama, nyaris tanpa beban tambahan
• Rumus lama “utang teknis = amankan jadwal → kerahkan sumber daya besar” pun runtuh, digantikan oleh kesegeraan: mulai saat itu juga → lanjutkan → selesaikan

2. Budaya pengembangan eksperimental: “coba dulu, nilai belakangan”

• Saat muncul ide, penulis lebih dulu mencobanya dengan Claude Code, sambil belajar lewat pengulangan membuat dan menghapus hal-hal seperti test code sejak tahap awal
• Meski belum punya strategi testing frontend, Claude Code dapat langsung membuat/menghapus berbagai jenis test untuk tiap PR, membantu mengumpulkan pengalaman dan menentukan arah secara keseluruhan
• Pemikiran tentang ide/abstraksi juga bisa diverifikasi dan dieksplorasi dengan cepat lewat pendekatan “coba langsung → gagal pun tidak masalah”
• Karena biaya kegagalan turun drastis, siklus eksperimen-pembelajaran-keputusan pun melaju jauh lebih cepat

3. Perubahan dalam pengembangan paralel dan kolaborasi

• Dengan memanfaatkan dua git clone/profil VSCode, pekerjaan independen bisa dijalankan pada masing-masing clone (misalnya satu untuk menulis PR, satu lagi untuk pengembangan eksperimental)
• Saat Claude Code sedang bekerja di satu clone, pengguna bisa bekerja paralel di clone lain, atau membedakan masing-masing clone secara jelas lewat tema/port yang berbeda
• Pull Request bisa ditulis secara paralel, sambil menghindari bentrokan port development server dan meningkatkan efisiensi kerja

4. Inovasi proses pengembangan eksperimen/prototipe game

• Proses membuat prototipe game → mendistribusikan internal → menerima feedback → merilis atau membuangnya yang sebelumnya memakan waktu berminggu-minggu hingga berbulan-bulan, setelah adopsi Claude Code kini memungkinkan bahkan desainer menulis kode dan men-deploy ke situs sendiri dalam hitungan jam
• Siklus deployment seperti ide → eksekusi → feedback tim → mengakhiri eksperimen/beralih ke produksi (menulis ulang) menjadi jauh lebih singkat secara dramatis
• Namun, ini juga menghadirkan pertimbangan operasional baru seperti pengelolaan game sementara serta kriteria untuk memformalkan atau menghentikannya

5. Pemanfaatan Claude Code dalam coding dan kolaborasi sehari-hari

• Saat triage mingguan, GitHub Action Claude Code dimanfaatkan untuk langsung membuat PR/menjalankan eksperimen, dan issue kecil bisa segera diterapkan
• Anggota tim yang punya kemampuan di sisi produk dan teknis sekaligus, serta memiliki inisiatif tinggi adalah yang paling efektif memanfaatkan Claude Code, yaitu ‘full-breadth developer’
  • "Full-breadth developers" : membantu satu developer memimpin keseluruhan alur kerja dengan leluasa
• Selama manusia tetap memegang review kode, penyediaan konteks, perbaikan, dan pengambilan keputusan, produktivitas dan kreativitas seluruh tim meningkat

6. Lingkungan codebase yang ramah Claude Code

• Monorepo: seluruh kode/skema DB/API/logika layar ada di satu tempat, sehingga optimal bagi Claude Code untuk memahami konteks dan mengotomatisasi pekerjaan
• Dengan mengadopsi tech stack terstandarisasi (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap, dll.), LLM lebih mudah memahami dan mengotomatisasi
• Menjaga codebase tetap mutakhir dan meminimalkan legacy memaksimalkan efisiensi penggunaan LLM

7. Batasan Claude Code dan perubahan nyata yang terasa

• Perubahan kuantitatif seperti jumlah PR/commit mungkin tidak besar, tetapi kecepatan, fleksibilitas, dan produktivitas kerja yang dirasakan meningkat signifikan
• Claude Code berperan sebagai pair programmer setingkat ‘junior berpengalaman+’—jika engineer mengelola kualitas kode, logika, dan konteks, ia menjadi partner yang sangat baik
• Untuk pekerjaan berulang, pelunasan utang teknis, dan pendorongan side project dengan cepat, Claude Code memberi pengalaman kerja yang berbeda secara kualitatif

8. Strategi ‘implementasi paralel’ yang direkomendasikan untuk junior/pembelajar

• Tidak perlu terlalu terobsesi dengan tren terbaru dalam ekosistem LLM
• Untuk developer pemula, direkomendasikan menulis kode sendiri terlebih dahulu, lalu meminta Claude Code mengerjakan tugas yang sama untuk dipelajari lewat perbandingan/analisis
  • Dengan merujuk pada solusi Claude Code, berbagai abstraksi dan pola kerja nyata bisa dipelajari dengan cepat
  • Manfaatkan LLM sebagai 'kompetitor+mentor' sambil meningkatkan kemampuan praktik dan kepekaan terhadap ekosistem terbaru secara bersamaan
• Claude Code seperti ponsel, jadi tidak harus selalu dinyalakan
  • Yang penting pada akhirnya adalah tetap memegang kendali dan menggunakannya secara efisien

9. Ledakan side project dan eksperimen jangka pendek

• Eksperimen kecil/pengembangan alat/perbaikan blog yang sebelumnya sulit dicoba karena keterbatasan waktu dan energi, kini bisa diwujudkan dengan Claude Code hanya dalam beberapa jam
• Ide → langsung diwujudkan → gagal pun tidak jadi beban—mudah menjalankan eksperimen kreatif/proyek pribadi secara paralel di luar produksi

10. Contoh nyata percakapan Claude Code dan code review

• Ada contoh nyata proses permintaan spesifik → pembuatan kode → eksekusi → perbaikan → review untuk hal-hal seperti skrip pembersihan DB, puzzle REPL, dan layout PDF teka-teki silang
• Kesalahan LLM (penalaran, pembesaran, hardcoding, dll.) tetap mungkin terjadi—engineer wajib melakukan verifikasi logis dan bertanggung jawab atas kualitas agar nilai nyatanya benar-benar tercapai

11. Posisi Claude Code dalam engineering dan kesimpulan

• Claude Code sangat baik dalam menerima konteks yang luas seperti reference code, screenshot, dan penjelasan tambahan
• Claude Code adalah programmer pendamping setingkat 'post-junior' (di atas junior terampil)—dengan kesabaran dan kecepatan tanpa batas, sangat efisien sebagai partner kerja nyata
• Desain/kualitas/kendali akhir tetap ditangani engineer manusia, sementara Claude Code sangat memperluas cakupan dan kecepatan implementasi, eksperimen, dan otomasi
• Dengan lepas dari batasan “harus menulis kode baris demi baris sendiri”, tercipta lingkungan pengembangan yang memungkinkan fokus lebih besar pada desain, pengendalian kualitas, dan inovasi

[benjamin]

Saya juga sangat puas menggunakan Claude Code.
Sepertinya saya juga sudah memakainya sekitar 6 minggu sekarang.
Sebagian besar isinya terasa sangat relevan bagi saya.

https://jeho.page/essay/2025/07/15/claude-code.html

[zxavi]

Perasaan saya persis sama seperti penulis postingan aslinya, haha
Saya membayar $200 dan dalam satu jam berhasil menyelesaikan masalah pelik yang sudah 4 tahun tidak terpecahkan.
Mungkin kalau sendirian... dengan Cursor saya benar-benar tidak bisa menyelesaikannya.

[beoks]

Apakah ada yang bisa menjelaskan perbedaan saat menggunakan Claude Code dibanding Cursor + Claude LLM?
Saya sedang memakai Cursor, tetapi sedang mempertimbangkan untuk beralih ke Claude Code.

[zxavi]

Kalau yang dimaksud Claude LLM, apakah maksudnya API key?
Atau yang dimaksud adalah model Agent yang ada di bawah jendela chat?

Saya juga cukup puas memakai Cursor, tetapi karena batas pemakaian sering kena, meski pakai paket $60 pun saya terus waswas apakah akan kena limit lagi.
Karena itu saya sampai selang-seling memakai gemini cli, dan cukup stres karenanya.

Cursor + Claude 4 Sonnet saja sebenarnya sudah sangat bagus, tetapi masalah terbesarnya adalah setelah lewat sehari kena limit, dan kalau sudah kena limit jadi tidak bisa dipakai selama sebulan.

Cursor + Claude 4 Opus bahkan tidak berani saya coba.

Karena Claude Code pada akhirnya berbasis CLI, dan tidak terlalu terikat pada karakteristik IDE, saya memutuskan untuk mencobanya.

Awalnya saya pakai yang $20, tetapi ternyata yang ini juga tidak ada Opus.

Jadi ketika limitnya mulai mau kena, dengan pikiran "coba pakai sebulan saja" saya bayar $200 dan mencobanya.

Dunia baru pun terbuka. Opus ... kelasnya memang berbeda...

Sekarang baru hari ke-4 sejak pakai yang $200, dan saya sedang menyelesaikan semua masalah sulit yang selama ini tertunda haha

[zxavi]

Tulisannya ternyata tidak bisa diedit.

Cursor + Claude 4 sonnet juga sudah cukup bagus, tetapi masalah terbesarnya adalah setelah sehari kena limit, dan kalau sudah kena limit jadi tidak bisa dipakai selama sebulan.

Sepertinya bukan sebulan, melainkan sehari. Selama sebulan penuh saya terus was-was.
Dan saya juga sering sekali berantem dengan Cursor,
tetapi dengan Claude Code saya tidak terlalu sering berantem.

[beoks]

Wah, terima kasih atas jawaban yang sangat detail.
Saya juga kena limit jadi mau tidak mau memakai Cursor dalam mode Auto, sepertinya saya juga harus beralih.

[GN⁺]

Opini Hacker News

• Setelah memakai Claude Code sekitar 2 minggu, saya yang biasanya skeptis terhadap AI coding benar-benar terkejut. Untuk membangun pengalaman memang ada sedikit kurva belajar, dan sangat penting memberi konteks yang tepat serta memecah pekerjaan dengan baik. Tentu tetap perlu kemampuan pemrograman, dan kalau semua hal yang tidak kita pahami langsung dilempar ke AI, pasti akan timbul masalah. Karena saya punya pengalaman lebih dari 25 tahun, saya cukup yakin bisa meninjau apa pun hasil Claude Code dan langsung membetulkannya kalau salah. Sekitar 10~15 tahun lalu saya pernah membayangkan semacam antarmuka saraf yang membuat kita tak perlu lagi menulis kode sendiri, dan Claude Code terasa seperti sedikit banyak mewujudkan itu. Kadang saya kena batas penggunaan harian, jadi saya cukup sering mencoba Gemini CLI model 2.5 pro sebagai pengganti, tetapi itu sama sekali tidak sebanding dengan Claude Code. Gemini terlalu membuat frustrasi untuk dipakai. Dulu saya tak pernah membayangkan akan menggunakan tool pengembang yang biayanya lebih dari 100 dolar per bulan, tetapi sekarang saya serius mempertimbangkan upgrade ke paket Max

  • Menurut saya tool ini sangat cocok bila ada situasi di mana developer senior bisa memberi saran dan membimbing developer junior. Dari cerita para developer senior di sekitar saya, banyak keluhan bahwa para junior justru memakai LLM untuk membuat kode yang lebih aneh, lebih lambat, rentan keamanan, atau benar-benar berantakan, lalu mengajukan PR tanpa memahami kodenya. Bagi saya yang paling berguna adalah pembuatan boilerplate (cukup beri penjelasan lalu ia bisa menyusun desain kelas), mengubah JSON menjadi class atau format lain, dan pertanyaan seperti “apa masalah kode ini? kalau engineer level Staff yang mengubahnya, akan seperti apa?” Bahkan Claude Code pernah menemukan bug lebih awal pada kode yang saya tulis sendiri

  • Yang menarik, orang-orang yang skeptis terhadap “vibe coding” biasanya punya ekspektasi sangat rendah sampai mereka benar-benar mencoba tool-nya. Banyak orang mengira kode yang dihasilkan LLM pasti sampah, lalu menganggap contoh-contoh ekstrem sebagai rata-rata. Namun setelah mencobanya sendiri, mereka kaget karena hasilnya jauh lebih baik dari dugaan. Tentu mustahil tiba-tiba membangun SaaS bernilai 1 miliar dolar dengan tim 10 orang hanya dengan Claude Code, tetapi tetap saja banyak yang meremehkan kekuatan nyata tool ini

  • Sebenarnya, kalau bicara secara ketat, Anda bukan sedang melakukan vibe coding. Ini lebih dekat ke software engineering dengan memanfaatkan AI. Vibe coding berarti menerima apa pun kode yang dikeluarkan AI begitu saja dan terus maju tanpa benar-benar memahaminya. Karena definisi istilah ini berbeda-beda untuk tiap orang, sebaiknya jangan terlalu mempercayai istilah vibe coding itu sendiri

  • Saya sendiri sampai beberapa bulan lalu tidak pernah membayar layanan langganan apa pun lebih dari 20 dolar, tetapi sekarang saya membayar 200 dolar per bulan untuk paket Max 20. Mungkin karena saya pengembang asal Slovakia yang tinggal di AS dengan pengalaman 20 tahun, saya sendiri juga terkejut. Saya sudah mencoba tool lain, tetapi sulit merasakan produktivitas dan efisiensi yang sedemikian langsung seperti ini. Claude Code benar-benar di level yang berbeda. Tentu tetap harus diawasi secara detail, tetapi alur saya adalah memakai Plan Mode untuk menyusun requirement dan rencana perubahan kode secara menyeluruh, lalu kalau saya sudah 100% setuju saya eksekusi, setelah itu hasilnya saya code review. (Error compiler, unit test, dan masalah lint diperbaiki sendiri oleh AI.) Rasanya seperti punya engineer junior yang sedikit nyeleneh tetapi berpengetahuan luas dan sangat cepat. Arah pengembangan software jelas bergerak ke sini, dan inilah masa depan

  • Belakangan saya merasa model Claude kurang bisa diandalkan untuk menulis/mengubah SQL. Misalnya clause kondisionalnya dibuat dengan baik, tetapi AND/OR tidak diberi tanda kurung, lalu Gemini pro justru bisa menandai itu sebagai bug dengan benar

• Saya sangat setuju bahwa Claude Code memang jelas lebih unggul dibanding semua tool pesaing. Sejak 2023 saya membuat sendiri tool cli untuk generasi kode AI, jadi bisa dibilang saya sudah mencoba hampir semua opsi utama. Saya sangat relate dengan berbagai metode penulis:

  1. Monorepo sangat menghemat waktu
  2. Mulai dengan spesifikasi yang jelas, dan investasikan cukup banyak waktu pada spesifikasi itu. Dengan outline yang baik saja, AI bisa menulis sebagian besar spesifikasi
  3. Sejak awal harus ada test. Ini yang paling penting. Dengan test dan spesifikasi yang baik, AI bisa menelusuri solusi yang lebih baik secara rekursif. Rasanya seperti TDD kembali lagi
  4. Type dan linter sangat membantu
  5. Dokumentasi eksternal sebaiknya dirapikan dalam direktori terpisah di dalam proyek (misalnya: docs/external-deps)
  6. Seperti semua tool, butuh sedikit waktu untuk mempelajari teknik yang cocok untuk diri sendiri. Sekarang memang lebih mudah dari dulu, tetapi tetap ada hal yang harus dipelajari. Workflow tiap orang sedikit berbeda, jadi justru rasanya mirip proses coding itu sendiri Belakangan saya juga membuat server GraphQL RBAC super sederhana bernama Permiso(https://github.com/codespin-ai/permiso) dengan vibe coding. Proyek ini belum diuji/review secara stabil, tetapi mungkin sudah berguna bagi orang yang butuh sesuatu yang sederhana

  • Untuk poin kedua (mulai dengan spesifikasi yang baik), saya penasaran bagaimana tepatnya Anda menyusun spesifikasi itu. Apakah dipisahkan dalam dokumen markdown, seberapa detail isinya, dan seterusnya. Saya juga setuju dengan saran “siapkan test sejak awal”, tetapi dalam praktiknya saat Claude punya hooking test, kadang justru proses menulis test lebih dulu terlewat dan ia hanya mengulang perubahan tanpa validasi bug/asumsi. Saya bahkan kadang membuat flag untuk menyalakan dan mematikan perilaku terkait test

  • Monorepo memang bisa menghemat waktu Anda, tetapi tool call dan konsumsi token Claude jadi jauh lebih besar. Saya rasa pendekatan seperti Aider, yang memilih hanya file yang dibutuhkan lalu mengirimkannya ke AI, lebih baik. Saya kurang paham kenapa Claude begitu populer. Aider adalah tool yang lebih baik dalam hampir semua hal, dan juga bisa dipakai dengan berbagai LLM

  • Untuk memakai CC dengan benar, struktur proyek harus sudah rapi. Dalam proyek Django yang test, type, dan dokumentasinya tertata baik, CC mengerjakan hampir semuanya dengan baik, meski tetap perlu arahan sesekali. Belakangan saya juga mengerjakan side project untuk menjalankan CC secara offline dengan model lokal. Versi pertamanya saya buat dengan bantuan ChatGPT, tetapi begitu pindah ke CC, CC malah cenderung berputar-putar di isu inti, menghindari kesalahan, dan alih-alih merefaktor kode lama atau memperbaiki bug, ia terus punya kebiasaan membuat file/skrip baru

  • Saya penasaran apakah Anda benar-benar memformat dokumentasi eksternal langsung di dalam proyek. Kebanyakan proyek hanya punya dokumentasi di website, jadi saya ingin tahu apakah Anda benar-benar meluangkan waktu untuk membuat file markdown yang rapi secara terpisah

• Kekuatan sejati Claude Code adalah ia bisa mengendalikan seluruh komputer, bukan cuma menulis kode. Kalau ada tool CLI, Claude bisa memakainya, dan kalau tidak ada pun, sering kali tetap mengejutkan kalau kita bertanya kepadanya. Misalnya, saya menyerahkan berbagai pekerjaan kecil seperti crop/resize gambar, mengekstrak mp3 dari video YouTube, menghapus bagian sunyi dari file audio, dan sebagainya. Berkat itu saya menghemat waktu luar biasa banyak. Saya bahkan hampir tak ingat bagaimana dulu melakukannya. Rasanya saya tak akan bisa kembali ke cara lama

  • Daripada menghubungkan Claude ke komputer utama Anda, lebih baik memberinya komputer terpisah (yang bukan komputer pribadi Anda). Dalam kasus saya, IDE berjalan di VM cloud, lalu saya menghubungkan Claude ke sana dan mengaksesnya lewat browser (https://brilliant.mplode.dev). Menurut saya ini UX paling optimal yang paling mendekati pengoperasian agen. Tanpa perlu terminal atau persiapan ssh, cukup login saja dan instance otomatis dibuat/dijeda. Hasilnya, Claude + instance Linux pribadi + IDE langsung terbuka lewat sebuah tautan. Ke depan saya berencana menjalankan banyak instance sesuai kebutuhan dan mengontrol permission, filesystem, serta permission container (JWT, dsb.) dengan lebih rinci. Jika terjadi gangguan atau situasi yang perlu ditinjau, saya bisa langsung masuk ke IDE dan menyelesaikannya. Bahkan UI khusus pun tidak perlu; bisa dilihat lewat beberapa panel di IDE atau langsung menjalankan webapp di container. Sudah lama saya tidak merasa segembira ini terhadap perkembangan teknologi

  • Meski semuanya terlihat bagus, kalau hanya melihat output kode yang nyata, datanya hampir tidak berbeda sebelum/sesudah. Walau bekerja dengan Claude, jumlah commit, PR, dan baris kode tidak jauh berbeda dari sebelumnya. Artinya AI coding memang memberi perasaan “produktivitas meningkat” dan “senang karena sesuatu dibuat tanpa banyak campur tangan saya”, tetapi pada praktiknya tetap perlu banyak review, perbaikan, dan re-prompting, sehingga total output akhirnya mirip. Dan saat bagian sulit diserahkan ke AI, kemampuan desain dan berpikir kita sendiri perlahan melemah. Setelah sebulan hanya memakai LLM seperti Claude lalu mencoba membuat aplikasi kecil dengan tenaga sendiri, bukan hanya kodenya, tetapi desain struktur keseluruhannya juga terasa lebih sulit. Dalam jangka panjang, ada risiko codebase perlahan rusak dan akhirnya menjadi minus (setidaknya dengan generasi LLM saat ini)

  • Dulu saya membuat sendiri satu per satu command ImageMagick (mogrify) dengan cara lama. Dengan bantuan tool AI, waktu yang dihemat terasa gila-gilaan

  • Saya pernah meminta Claude mendiagnosis penyebab Linux PC saya yang terus crash, dan ia sangat membantu dengan mengambil log lewat journalctl sampai menemukan akar masalahnya. Itu pengalaman yang langsung membantu pemecahan masalah

  • Contoh lain, pembuatan static site jadi sangat mudah. Saya bisa menulis dalam sintaks apa pun, lalu cukup minta Claude Code mengubah post ini ke format blog dan semuanya beres. Misalnya saya hanya menulis “tolong masukkan gambar image.jpeg” dan ia langsung menanganinya. Sangat nyaman karena saya tidak perlu terikat pada markdown atau format Hugo

• Sebagai orang yang memakai Claude code 12~16 jam sehari, saya menemukan beberapa tip berikut:

  1. Begitu dijalankan, langsung ganti ke model sonnet (kualitasnya jauh berbeda dari opus)
  2. Compacting (kompresi log percakapan) menurunkan kualitas secara signifikan saat proses berjalan, jadi timing-nya harus tepat
  3. Prompt pertama sangat penting dan menentukan sifat sesi. Kalau instance Claude mulai ragu-ragu atau jadi kurang membantu, lebih baik akhiri saja sesi itu dan buka yang baru
  4. Kalau meminta dengan sopan seperti “ini mungkin ide yang kurang bagus, tapi saya ingin mengimplementasikan ~”, ia cenderung membantu jauh lebih aktif
  5. Produktivitas saya terasa naik 10 kali lipat ketika orkestrasi Docker saya serahkan ke Claude. Menjalankan container baru, mengecek error log, menghapus/rebuild, dan seluruh flow saya serahkan ke Claude sehingga dengan satu prompt saya bisa menyalakan seluruh layanan

  • Poin 5 juga bisa diperluas di luar Docker jika dihubungkan dengan server MCP playwright, sehingga UI dan request bisa langsung diperiksa. 6. Mulai dengan plan mode dan revisi berulang sampai rencananya terasa cocok. 7. Manfaatkan fitur slash command (/command) secara aktif sebagai mini prompt untuk perbaikan berkelanjutan, pemberian konteks, dan instruksi memanfaatkan tool eksternal seperti gh. Compacting sebaiknya jangan dilakukan mendadak saat masih 0%, tetapi diterapkan di titik tengah yang tepat. Soal poin 1 (rekomendasi sonnet), ada juga yang mungkin tidak setuju

  • Saya cenderung menghindari Docker, tetapi saya sangat penasaran dengan tip nomor 5 (mengorkestrasi Docker dengan Claude). Saya ingin tahu format prompt seperti apa yang Anda gunakan

  • Saya juga pernah berhasil memakai pendekatan membuat file plan.md yang sangat detail lebih dulu (koneksi antarsistem, komposisi keseluruhan, dsb.), lalu menjalankannya semalaman dengan tool seperti claude-loop(https://github.com/DeprecatedLuke/claude-loop), dan pagi harinya saya lakukan patch manual

  • Saya penasaran bagaimana seseorang bisa memakai Claude Code sampai 16 jam sehari

  • Kadang Claude terlalu banyak mengutak-atik bagian dalam container. Padahal saya hanya ingin ia memahami kode, tetapi ia malah mencoba menjalankan kode di dalam container dengan terlalu banyak cara dan justru membuat keadaan jadi aneh. Dulu juga pernah mem-pipe file ke command cli tanpa ada tindakan apa pun; contoh bahwa ia punya kecenderungan obsesif untuk mengeksekusi sesuatu

• Saya tidak tahu seberapa bagus Claude Code sebenarnya (karena belum pernah mencobanya sendiri), tetapi ada satu hal yang secara pribadi membuat saya bimbang. Saya ingin merefaktor gdscript saya yang sangat lambat dan berantakan (keluarga Python) menjadi C#. Ini proyek pribadi yang ingin saya buat lebih bersih dan cepat. Pekerjaan ini adalah tantangan baru bagi saya dan juga sangat edukatif. Kalau memakai Claude, saya merasa seperti merampas kesempatan belajar yang berharga dari diri sendiri (dan mungkin bagus untuk pertumbuhan jangka panjang), tetapi kalau tidak memakainya, saya merasa sedang menghabiskan waktu berharga untuk pekerjaan membosankan yang sebenarnya akan diautomasi di masa depan. Dilema ini terus berulang

  • Dalam 35 tahun pengalaman sebagai developer, saya menggunakan AI hanya untuk hal-hal yang sebenarnya bisa saya selesaikan sendiri tetapi tidak ingin saya lakukan (membosankan, repetitif). Misalnya memperbaiki skema Open API 3.0 tidak memberi pembelajaran apa pun jika saya kerjakan sendiri, jadi saya serahkan ke Claude, dan pembuatan contoh kode juga saya minta ke AI. Saat ada poin yang benar-benar baru saya pelajari, saya rangkum ke flashcard di aplikasi seperti Anki SRS atau saya tulis di blog TIL. Atau saya mengimplementasikan contoh-contohnya sendiri beberapa kali agar jadi pengalaman. Kuncinya, pembelajaran baru harus dikaitkan ke otak setidaknya dua kali agar efektif. Mirip seperti saat mempelajari kosakata baru dalam bahasa alami, lalu menggunakannya di 3 kalimat

  • Kalau Anda tidak me-review kode yang dihasilkan sendiri (artinya, kalau Anda tidak benar-benar menguasai C#), codebase akan hancur dalam sekejap. LLM coding cenderung menumpuk error, jadi perbaikan mutlak diperlukan; kalau tidak, hasilnya jadi tumpukan sampah yang tak bisa dipelihara. Teman-teman saya bilang mereka membiarkan AI menghasilkan test code yang cukup untuk menemukan masalah sejak awal, tetapi saya sendiri belum sampai memakai cara itu. Kode saya lebih banyak logika daripada algoritme, jadi menulis test juga agak ambigu

  • Setelah 16 tahun bekerja sebagai developer profesional, saya merasa Claude Code membantu menyelesaikan hal-hal yang sebelumnya membuat saya mentok dan pusing. Saat mempelajari hal baru dengan cepat, tool AI (terutama mode tanya-jawab seperti "ask") sangat efektif; saya aktif memakai analogi, kasus, dan teknik menghafal. Jika tujuan Anda adalah pembelajaran mendalam lewat pertumbuhan yang lambat, maka cara klasik yang lebih lambat tetap lebih baik. Tetapi jika tujuan Anda belajar cepat, memanfaatkan AI juga bukan pilihan buruk. Kalau Anda hanya ingin hasil, penting untuk menulis spesifikasi yang baik dan menyiapkan test yang memadai. Pada akhirnya, apa pun caranya, saya rasa yang bermakna adalah terus membuat sesuatu

  • Dulu pernah ada tren blog yang menyuruh “buat library x versimu sendiri”. Kita belajar paling banyak justru saat benar-benar mengimplementasikan sesuatu. Misalnya kalau penasaran dengan client-side router, buatlah router sendiri. Di era LLM, apa pun bisa digantikan oleh kode library, tetapi kalau saya benar-benar ingin belajar C#, lebih baik saya melakukan porting itu sendiri. Kalau Anda hanya butuh hasil akhirnya dan ingin fokus ke bagian lain, silakan serahkan ke Claude. Dalam belajar selalu ada fase yang menyakitkan, dan kalau semuanya terlalu mudah, sebenarnya kita tidak belajar apa pun

  • Sebelum AI, budaya copy-paste sudah dominan. Teman-teman yang menyalin kode dari Stackoverflow tanpa memahami alasannya pada akhirnya tidak belajar apa-apa. Menurut saya tidak masalah meminta saran atau penjelasan konsep kepada AI. Tetapi kalau semua hal diminta untuk dituliskan sepenuhnya, jelas tidak ada pembelajaran. Meski begitu, menjaga waktu saya sebagai developer juga bijak. Ada sangat banyak hal yang harus dipelajari, jadi kalau tujuan Anda adalah pengembangan game, mungkin pekerjaan porting GDscript bukan pengalaman yang wajib. Tentu tetap ada hal yang bisa dipelajari dari sana

• Dari pengalaman coding sekitar 3 minggu dengan Claude Code, saya adalah developer 10 tahun pengalaman yang banyak bekerja di Python ML/data engineering, dan ada beberapa alasan:

  1. Menghilangkan rasa sakit saat memulai, jadi tak ada hambatan untuk menulis baris pertama
  2. Saat ia berjalan, saya bisa memakai kepala saya sepenuhnya untuk berpikir
  3. Banyak pekerjaan bisa dijalankan paralel pada saat yang sama
  4. Kalau tiba-tiba teringat “ada lagi yang harus diperhatikan”, saya langsung membuka sesi Claude baru dan mencobanya saat itu juga (tidak ada lagi TODO yang tertinggal)
  5. Analisis/visualisasi, plotting, dan hal sejenis juga mudah dijalankan otomatis dengan script
  6. Masalah lint/type/test yang sederhana akan diperbaiki otomatis olehnya Secara keseluruhan, saya jadi bisa fokus hanya pada hakikat kode—apa yang harus dilakukan, apakah output-nya benar, dan bagaimana membuatnya lebih baik

  • Menghilangkan rasa sakit saat memulai itu benar-benar besar. Dulu ada banyak hal yang saya pikir “akan saya kerjakan kalau punya waktu”, tetapi sekarang cukup dengan beberapa prompt saja sudah bisa dijalankan. Saya bahkan ingin membuat game NYT Connections di terminal, dan selesai hanya dalam 3 prompt (https://github.com/jleclanche/connections-tui)

  • Poin 4 sangat berkesan. Dulu meninggalkan test atau utang teknis terasa normal, tetapi sekarang bahkan test suite pun bisa otomatis dibuat cukup baik hanya dengan berkata “ini perlu”. Memang tidak selalu sempurna, tetapi setidaknya pekerjaan tingkat menengah kini jauh lebih bisa ditangani

• Sebagai salah satu dari sedikit orang penasaran yang terus mencoba agent-based coding, saya sudah lama memikirkan kenapa pengalaman saya berbeda dari arus utama. Penjelasan di bawah ini tampaknya inti masalahnya:

  "Dengan Claude Code, kita sedang berada di 'momen fotografi bagi pemrograman'. Suasana menggambar dengan tangan menghilang karena satu ide bisa langsung diwujudkan, lalu dibentuk sesuai keinginan lewat kemampuan saya dalam code review dan editing" Analogi ini memang cocok, tetapi tetap saja orang masih melukis, ada yang membayar untuk membeli lukisan, dan ada juga yang menikmati coding itu sendiri sebagai seni. Saya menjadikan coding langsung sebagai hobi, sementara saya tidak suka code review tetapi tetap terpaksa melakukannya. Kalau diberi pilihan, saya akan memilih membuat sendiri (mungkin itu sebabnya saya tetap menjadi IC). Banyak orang bilang agen coding AI terasa seperti developer junior intern, tetapi bagi saya justru terasa menakutkan

  • Saya ingin bertanya apakah lingkungan di mana orang masih melukis dan membayar lukisan itu memang masih bertahan. Banyak kerajinan tangan yang tersingkir oleh proses modular dan produksi massal, dan kini tampaknya nilai penting bukan lagi barang itu sendiri, melainkan pengalaman bersama yang dibayangkan antara pembuat dan pembeli. Bukan sekadar memesan barang di Amazon, tetapi hubungan dengan perajin dan narasi proses kreatifnya yang dikonsumsi. Mungkin coding juga perlu bergerak ke arah itu agar bisa bertahan ke depan

  • Saya juga sangat memahami posisi ini. Saya mengakui kegunaan agent coding untuk tugas kecil, bug fix, dan draft awal. Tetapi saya tidak paham kenapa perdebatan pro/kontra menjadi begitu panas hanya karena ada bermacam interface yang membungkus segelintir model. Dampaknya untuk junior dev juga masih saya pikirkan. Kalau AI bisa mengotomatisasi code review juga, hidup saya mungkin akan jauh lebih bahagia

  • Saya tidak yakin analogi itu sepenuhnya valid. Secara historis, painting dulu adalah satu-satunya cara merepresentasikan dunia nyata, sedangkan seni bukan sekadar peniruan, melainkan interpretasi pembuatnya. Itulah alasan orang masih melukis. Kalau coding itu sendiri dianggap seni, tentu kita bisa terus melakukannya. Namun banyak orang tujuannya adalah membangun produk, dan produknya itulah seni. Jika AI bisa membantu mencapai tujuan itu lebih cepat, bukankah wajar memilih AI? Di sisi lain, saya juga sedikit merindukan masa “code monkey” (saat hanya fokus ngoding murni). Sepertinya akan datang masa di mana semua orang lebih mirip lead developer: memberi arahan, melakukan code review, dan mengambil keputusan teknis. Ada sedikit rasa sayang karena di pekerjaan nyata kita jadi makin jarang benar-benar menyentuh kode

  • Analogi yang lebih tepat mungkin adalah peralihan dari hand-tool ke power tool. Analogi painting-fotografi terasa terlalu dilebarkan karena berbeda dengan kemunculan medium baru. Agent coding tidak serevolusioner itu

• Saya sudah berusaha banyak memakai Claude Code, tetapi terlalu lambat dan selalu ada yang meleset sehingga terasa sangat membuat frustrasi. Untuk sebagian besar pekerjaan, saya tidak merasa ada penghematan energi mental. Memang ada beberapa tugas yang terbantu, tetapi saya juga berkali-kali merasa dikhianati hasilnya sehingga tidak ingin sering memakainya. Misalnya saya memintanya mengonversi .zshrc ke nushell, tetapi setelah bergulat selama 30 menit hasilnya tetap tidak jalan, padahal melihat dokumentasi resmi sendiri bahkan tidak butuh 10 menit. Karena pengalaman mengecewakan seperti ini, saya jadi enggan kembali memakai Claude

  • Pengalaman ini juga mirip dengan saya. Saya mencoba meminta bantuan untuk menulis test code, tetapi pada akhirnya saya hampir selalu harus menulis ulang semuanya sendiri. Untuk debugging saya belum pernah mendapatkan hasil berarti. Yang lumayan berguna hanya konversi skrip sangat sederhana (misalnya parsing output command) atau scaffolding proyek baru (tetapi seberapa sering pekerjaan seperti itu muncul?). Untuk porting kode sederhana memang lumayan, tetapi pengalaman gagal saya jauh lebih banyak

  • Saya penasaran apakah Anda pernah mencoba sesuatu seperti context7 MCP. Di bahasa yang kurang populer atau domain yang asing, LLM memang cenderung lemah. Pendekatan seperti context7, yang memanggil referensi langsung dari source terbaru, terasa lebih baik

• Karena RSI dan carpal tunnel syndrome, saya jadi lebih jarang coding, tetapi berkat Claude saya bisa memrogram lagi (karena rasa sakitnya turun sampai sepersepuluh). Ini teknologi yang tadinya ingin saya tolak, tetapi kalau ingin melanjutkan karier, sekarang justru terasa wajib

  • Saya sering mendengar cerita serupa. Untuk orang-orang dengan RSI, tool seperti Claude benar-benar game changer, karena pekerjaan paling berat dan membosankan seperti boilerplate dan tugas repetitif jadi jauh lebih ringan. Dulu setiap melihat kode berulang, pergelangan tangan dan mental saya sama-sama sakit, tetapi sekarang tidak perlu terlalu dipikirkan dan justru bisa fokus pada masalah yang abstrak dan baru, sehingga pemrograman itu sendiri jadi lebih menyenangkan. Ada kekhawatiran bahwa tool seperti ini bisa mengakhiri karier, tetapi saya justru percaya kebalikannya: ini bisa menyelamatkan karier saya

  • Sejak mulai memakai Claude, nyeri RSI saya hampir hilang. Terutama karena banyak tugas berulang bisa digantikan oleh instruksi dan kalimat yang sangat presisi. Saya juga sering mendengar use case pengenalan suara, dan rasanya ini membuka pintu aksesibilitas

  • Saya rasa akan lebih membantu lagi kalau Claude Code bisa langsung dimanfaatkan lewat suara. Di MacOS ada opsi TTS/ASR gratis, dan dengan BYOK kita juga bisa menambahkan engine suara lain (https://github.com/robdmac/talkito)

  • Kalau memakai aplikasi STT/pengenalan suara yang cukup akurat dan nyaman, menyampaikan konteks detail ke Claude Code juga bisa sangat efektif. Setelah mencoba berbagai aplikasi pengenalan suara, saya paling cocok dengan Wispr Flow karena punya mode hands-free berbasis shortcut keyboard sekaligus akurasi dan kecepatan yang bagus. Hanya saja saya berharap ada dukungan untuk aplikasi lokal juga

  • Saya penasaran apakah Anda juga melakukan input teks itu sendiri lewat suara

• Dari sudut pandang maintainability, saya sangat setuju dengan pemikiran penulis. Dulu untuk refactoring atau pengingat, saya hanya membuat TODO atau tiket, tetapi sekarang berkat Claude saya langsung mengimplementasikannya saat itu juga. Akibatnya, kerja berulang jadi jauh berkurang. Ide refactoring juga bisa diuji dengan cepat, dan kalau tidak cocok, mudah dibuang. Energi aktivasi untuk pekerjaan semacam ini turun drastis. Saya juga setuju bahwa kalau agen AI dijalankan secara paralel/offline tanpa pengawasan, justru bisa berujung pada burnout dan penurunan kualitas kode, jadi harus tetap dijaga dalam mode human supervision. Tulisan tambahan yang saya rangkum ada di https://www.modulecollective.com/posts/agent-assisted-coding...