Percobaan pertama 95% sampah: perjalanan seorang Staff Engineer bersama Claude Code

• Seorang staff engineer membagikan pengalamannya bereksperimen selama 6 minggu dengan workflow pengembangan bersama AI menggunakan Claude Code
• Pola pikir menganggap AI sebagai ‘junior developer yang tidak belajar’ adalah kunci integrasi yang berhasil
• Percobaan pertama pada umumnya 95% gagal, tetapi melalui proses berulang perlahan disempurnakan menjadi kode yang berguna
• Masalah kurangnya konteks pada AI diatasi dengan memanfaatkan file konteks per proyek (Claude.md) dan integrasi tool berbasis MCP
• Peran developer bergeser dari menulis kode ke pemecahan masalah dan perancangan arsitektur, yang menjadi pola produktivitas baru di era pemanfaatan AI

---

Latar belakang dan pendekatan

• Penulis awalnya menulis semua kode sendiri, tetapi belakangan 80% ditulis oleh AI dan ia berfokus pada arsitektur, review, serta pengelolaan pengembangan multithread
• Tulisan ini bukan narasi optimistis bahwa 'AI akan memimpin inovasi', melainkan berbagi kebingungan dan metodologi realistis saat mengintegrasikan AI ke workflow pengembangan produksi yang nyata
• Memperlakukan AI sebagai 'junior developer yang tidak belajar' adalah inti pemanfaatan yang berhasil

Proses perubahan paradigma pengembangan

• Selama 5 tahun awal, tetap menggunakan cara pengembangan dengan merujuk buku dan dokumentasi SDK
• Setelah itu, selama 12 tahun beralih ke pemanfaatan pengetahuan kolektif berbasis pencarian (google)
• Dalam 18 bulan terakhir, bereksperimen dengan coding berbantuan AI melalui Cursor
• Dalam 6 minggu terakhir, mengalami perubahan drastis melalui delegasi AI secara menyeluruh dengan Claude Code
• Adaptasi terhadap Claude Code terasa meningkatkan produktivitas hanya dalam hitungan beberapa jam

Workflow produksi berbasis AI yang nyata

• Saat mengerjakan kode untuk produksi, AI terutama digunakan untuk "berpikir"
• Menghasilkan kode sempurna dalam sekali jalan tidak mungkin. Tugas seorang engineer adalah menemukan solusi terbaik untuk masalah yang ada
  • Percobaan pertama (95% gagal): AI membangun konteks sistem dan developer merumuskan masalah, tetapi kodenya hampir semuanya salah
  • Percobaan kedua (50% gagal): Pemahaman konteks meningkat dan pendekatan menjadi lebih spesifik, tetapi setengahnya masih tidak berguna
  • Percobaan ketiga (kode yang bisa dipakai): Melalui iterasi dan review, muncul kode dasar yang benar-benar dapat digunakan lalu ditingkatkan lebih lanjut
• Proses ini bukan kegagalan, tetapi eksperimen yang memang direncanakan dan proses optimasi berulang

Masalah konteks dan solusinya

• AI tidak dapat mempertahankan memori antar sesi, sehingga ada keterbatasan karena penjelasan yang sama harus diulang setiap kali
• Sebagai solusi, digunakan file Claude.md untuk mencatat keputusan arsitektur, pola, tautan dokumentasi, dan sebagainya
• Melalui integrasi MCP, AI dihubungkan ke Linear, Notion, GitHub, codebase, dan database agar konteks diberikan secara otomatis
  • Menggunakan Linear untuk menyediakan konteks tiket
  • Menggunakan Notion atau Canvas untuk akses dokumentasi
  • Menggunakan database non-produksi untuk memeriksa struktur data
  • Memanfaatkan informasi latar dari PR lama di GitHub

Menjalankan instance Claude paralel dan strategi utama

• Menjalankan beberapa instance Claude secara paralel didekati seperti mengelola ‘tim developer kecil yang kehilangan memori setiap hari’
• Disusun strategi seperti melarang paralelisasi pada area masalah yang sama, mencatat semua pekerjaan di alat manajemen proyek seperti Linear, dan menandai dengan jelas kode yang diubah langsung oleh manusia
• AI dimanfaatkan secara aktif bukan hanya untuk menulis kode tetapi juga dalam code review: menemukan tes yang terlewat, bug yang jelas, dan titik perbaikan dengan cepat sehingga mengurangi pekerjaan berulang
• Menurut kebijakan perusahaan penulis (Sanity), tanggung jawab akhir atas kualitas tetap ada pada engineer meskipun kodenya dihasilkan AI
• Dalam lingkungan pembuatan kode di mana sulit membedakan AI dan manusia, keterikatan emosional berkurang sehingga code review bisa lebih kritis dan objektif

Proses code review 3 tahap

• Menulis kode adalah bagian dari pekerjaan, tetapi meninjau kode juga sama pentingnya
• Review tahap 1: tinjauan awal oleh Claude
  • Mendeteksi cakupan tes yang kurang dan bug yang jelas
  • Menghemat waktu review rekan melalui usulan perbaikan
• Review tahap 2: saya meninjau
  • Memeriksa maintainability, arsitektur, logika bisnis, dan integrasi
  • Walau kode dibuat AI, engineer tetap memikul tanggung jawab akhir
• Review tahap 3: review umum oleh tim
  • Tim tidak mengetahui bagian mana yang dibuat AI. Standar kualitas yang sama tetap diterapkan
  • Review objektif dimungkinkan tanpa keterikatan emosional
• Karena keterikatan emosional terhadap kode buatan AI berkurang, review objektif menjadi lebih mudah

Eksperimen agen yang dipicu Slack dan otomasi pekerjaan

• Mempilotkan agen terintegrasi Slack dengan Cursor: berhasil untuk perubahan logika bisnis sederhana, tetapi gagal pada layout CSS yang kompleks
• Saat ini masih ada keterbatasan seperti tidak mendukung paket NPM privat, commit tanpa signature, dan melewati pelacakan resmi
• Meski begitu, ada antusiasme terhadap skenario masa depan ketika agen menangani tiket repetitif sederhana pada malam hari

Biaya dan ROI

• Biaya penggunaan Claude Code merupakan jumlah yang tidak kecil yang dibayarkan perusahaan kepada engineer
• Namun, investasi itu menghasilkan peningkatan produktivitas
  • Kecepatan rilis fitur meningkat 2~3x
  • Dapat mengelola banyak thread pengembangan secara bersamaan
  • Tidak perlu lagi menulis langsung kode repetitif dan boilerplate
• Pada fase awal adopsi AI, senior engineer memerlukan anggaran bulanan $1000~1500, dan efisiensi biaya diharapkan membaik seiring meningkatnya kemahiran

Masalah dan keterbatasan yang terus ada dalam pengembangan berbantuan AI

• Masalah pembelajaran: AI tidak belajar dari kesalahan sehingga mengulang salah paham yang sama; solusinya adalah dokumentasi yang kaya dan instruksi yang lebih eksplisit
• Masalah kepercayaan: AI bisa dengan yakin memberikan kode yang salah sehingga verifikasi wajib dilakukan, terutama pada manajemen state yang kompleks, performa, dan area keamanan
• Masalah keterbatasan konteks: codebase besar melampaui jendela konteks AI, sehingga masalah harus dipecah menjadi unit kecil dan diberi konteks yang jelas

Perubahan emosional dari kode ke masalah

• Melepaskan keterikatan pada kode dan beralih ke cara berpikir yang berpusat pada pemecahan masalah
• Menghapus cepat kode yang salah, review yang lebih objektif, dan berkurangnya beban terhadap refactoring => perubahan positif
• Jika muncul tool AI yang lebih baik, ia bersedia langsung menggantinya
• Intinya bukanlah ‘kode itu sendiri’, melainkan nilai dari masalah yang harus diselesaikan

Saran adopsi AI dari sudut pandang engineer

• 1. Izinkan eksperimen dengan berbagai solusi AI: tim perlu mencoba langsung beragam tool untuk meningkatkan kemampuan praktis
• 2. Terapkan AI terlebih dahulu pada pekerjaan repetitif dan sederhana: efek cepat lebih mungkin didapat
• 3. Siapkan anggaran untuk trial and error: bulan pertama harus siap menghadapi kebingungan
• 4. Rancang ulang proses review: perkuat pemeriksaan yang sesuai dengan karakteristik kode AI
• 5. Dokumentasi yang menyeluruh: konteks yang baik melipatgandakan produktivitas

• Engineer yang beradaptasi dengan workflow AI baru akan menyadari ada pisau tajam baru di kotak alat mereka
• Engineer yang menerima workflow AI akan berevolusi ke peran baru yang mengorkestrasi banyak agen AI sambil berfokus pada arsitektur, review, dan pemecahan masalah kompleks

Langkah Anda berikutnya

• Pilih satu fitur kecil yang terdefinisi dengan baik,
• beri AI tiga kesempatan untuk mengimplementasikan fitur itu, dan
• tinjau hasilnya seolah Anda sedang membimbing developer pemula

• Itu saja. Tidak perlu perubahan besar atau perombakan proses
• Cukup satu fitur, tiga percobaan, dan review yang jujur

• Masa depan bukanlah AI menggantikan developer
  • melainkan developer bekerja lebih cepat, mengembangkan solusi yang lebih baik, dan memanfaatkan tool terbaik

[helio]

"Kalau prosedurnya serumit ini, rasanya lebih baik menulis kodenya sendiri saja"

[skageektp]

Sikap bos tim yang tidak menyuruh anggota tim mengerjakannya dan malah menangani pekerjaannya sendiri wkwkwk

[greenbhj]

Kelihatannya begitu, tapi sama sekali tidak. Selama 6 bulan terakhir saya sudah mencoba eksperimen berulang dalam skala kecil maupun besar.

[iolothebard]

Pilih satu fitur kecil yang terdefinisi dengan baik,
beri AI tiga kesempatan untuk mengimplementasikan fitur tersebut,
lalu tinjau hasilnya seolah-olah Anda sedang membimbing pengembang pemula
Kalau dia bisa melakukannya tanpa saya, itu “untung”… tapi kalau saya tetap harus terlibat… ya lebih “untung” kalau saya kerjakan sendiri.

[GN⁺]

Opini Hacker News

• Terasa penting untuk memberi instruksi dengan mempertimbangkan batas kognitif agen; misalnya jangan meminta perubahan besar sekaligus, tetapi buat rencana lalu minta eksekusi dalam langkah-langkah kecil sambil menguji tiap tahap, dan pada tahap yang kompleks akan lebih baik jika diminta menulis kode untuk memvisualisasikan masalah dan solusinya. Jika gagal di suatu tahap, efektif untuk berulang kali mencoba proses menambahkan logging ke kode, menyimpan log, menjalankan tes, lalu meninjau log untuk menemukan penyebabnya. Jika model dibuat memahami bagian yang harus diubah melalui pola desain kode yang sudah ada, AI bisa dicegah agar tidak menumpuk semuanya ke dalam satu file. Saya pernah melihat blog yang membagikan tip-tip semacam ini, dan meski masih belum sempurna, setidaknya hasil sampahnya tidak sampai 95%.

  • Saya sudah mencoba semua hal seperti ini, tetapi tetap saja sebagian besar yang keluar adalah kode yang tidak berguna, dan bahkan saat kadang benar-benar berjalan, pada akhirnya tetap harus saya rapikan sendiri agar layak dipakai. Memang ada saat-saat ketika hasilnya benar-benar bagus dan itu menyenangkan, tetapi secara pribadi saya belum merasa ada peningkatan efisiensi yang besar.
  • Untuk pekerjaan kompleks berskala besar, terasa efektif memberi instruksi seperti, "Jangan tulis kode dulu sekarang. Saya akan menjelaskan tiap langkah secara rinci." Misalnya dengan memberi gambaran bertahap seperti membaca input, menghasilkan kandidat, memberi skor pada kandidat, menentukan prioritas dan pengurutan, membuat struktur data output, menyimpan ke DB, dan seterusnya. Claude merangkum tahap-tahap ini menjadi daftar TODO dan dokumentasi sehingga mudah dilanjutkan nanti. Saya benar-benar pernah bekerja satu jam lalu berhenti, kemudian berkata “untuk stage yang sudah selesai, buatkan kode dan tinggalkan komentar supaya lain kali bisa dilanjutkan,” dan pekerjaan beruntun bisa diteruskan dengan mudah.
  • Meski sudah lama memakai berbagai LLM/agen, tetap sulit mendapatkan hasil yang benar-benar berguna. Untuk menghindari output yang tidak perlu, saya malah harus menghabiskan lebih banyak energi untuk menulis prompt dibanding jika mengerjakan langsung sendiri. Karena harus memikirkan frasa prompt, gaya bahasa, dan mencegah asosiasi yang tidak diinginkan, saya jadi cemas tanpa alasan. Akan bagus jika ada alat yang mengelola prompt LLM seperti framework frontend terpisah, yang merapikan struktur prompt umum atau menerapkan best practice secara default, sehingga ketika mencari sesuatu di kode, merancang fitur baru, atau menulis tes, beban berpikir bisa jauh berkurang.
  • Jika prosedurnya harus serumit ini, saya rasa lebih baik menulis kodenya sendiri saja.
  • Saat mencoba AI dan vibe coding di proyek pribadi, saya merasa pendekatan test-driven development sangat cocok dengan vibe coding. Saya merekomendasikan memecah masalah menjadi unit-unit kecil yang bisa diuji, lalu meminta AI menulis unit test terlebih dahulu sebelum mengimplementasikan kode sebenarnya.

• Rasanya sekarang artikel-artikel seperti ini seharusnya sudah memuat contoh pekerjaan konkret yang benar-benar “didistribusikan oleh agen”, bukan sekadar refactoring sederhana atau boilerplate React. Katanya ada fitur-fitur yang sudah lama diminta di Sanity, dan mereka mengklaim agen memparalelkan cukup banyak pekerjaan itu. Namun, klaim seperti “80% kodenya ditulis oleh junior developer yang tidak belajar” sulit dipercaya.

  • Menurut saya, ungkapan “junior developer yang tidak belajar” itu keliru. Claude justru lebih mirip senior berpendidikan tinggi yang hanya tahu jawaban benar dari literatur tetapi tidak punya pengalaman lapangan. Pengetahuan ensiklopedisnya luar biasa, tetapi naluri praktiknya kurang. Belakangan saya membangun codebase komersial dengan Claude, dan sebagian besar input justru berfokus pada 'rasa kode' dan definisi keberhasilan, sementara kode itu sendiri hanyalah sesuatu yang sekali pakai.
  • AI code seperti ini makin banyak, tetapi open source masih dipenuhi issue yang belum terselesaikan. Itu cukup ironis.
  • Jika mereka menunjukkan contoh pekerjaan nyata yang diserahkan ke AI beserta hasilnya, itu akan memberi kesempatan untuk mempertanyakan ekspektasi yang dibesar-besarkan. Kenyataannya, tanpa contoh praktik nyata, yang terus muncul hanya cerita bahwa Claude Code itu hebat.
  • Setiap kali melihat blog teknis dari engineer yang sudah terdorong ke arah sales dan memakai istilah seperti "learnings" alih-alih "lessons", saya merasa jalur itu berlawanan dengan jalur saya sendiri yang, seiring bertambahnya pengalaman, justru makin jarang bergantung pada Google dan lebih banyak langsung membaca dokumentasi.

• Penulis memang bilang ada peningkatan produktivitas, tetapi karena juga menyebutkan keterbatasan yang umum disorot, pada praktiknya rasanya tidak banyak yang benar-benar disampaikan. Saya yakin tidak ada yang akan menyerahkan pengembangan fitur inti kepada Claude Code.

  • Saya rasa ada tulisan dari Anthropic yang memberi pandangan realistis tentang arah yang memang memungkinkan diwujudkan, terutama yang berfokus pada prototyping https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf

• Menghindari boilerplate adalah bagian dari pekerjaan developer sekaligus bentuk abstraksi yang memudahkan diri sendiri di masa depan. Jika boilerplate dibuat dengan AI, nanti saat semua instance harus diubah satu per satu, justru ketidaknyamanannya akan lebih besar, dan jika kode boilerplate yang tersebar di berbagai tempat tidak konsisten, masalahnya akan makin besar.

  • Framework atau tool pada dasarnya sudah banyak yang menyertakan generator boilerplate otomatis, jadi saya ragu ada nilai sebesar itu dalam menyuruh AI melakukan ini sambil menghabiskan token dan biaya.

• Yang menarik, orang ini mencoba menggunakan AI untuk implementasi dasar, sedangkan saya justru sebaliknya: fondasinya harus saya bangun sendiri dulu. Dengan begitu saya bisa benar-benar memahami struktur dan cara kerjanya, lalu setelah itu baru menyerahkan boilerplate yang repetitif ke AI. AI bagus dalam meniru dan meneruskan, tetapi sangat lemah dalam merancang arsitektur.

  • LLM sangat lemah dalam merencanakan arsitektur yang mudah dirawat. Seiring perkembangan kode, ia tidak mampu merombak struktur lewat refactoring, dan keterbatasan pemahaman konteks mungkin memang menjadi batasnya di sini.

• Gaji pokok developer saja sudah mahal, lalu masih harus menambah biaya $1.000 sampai $1.500 per bulan untuk masalah kecil yang mungkin saja meningkatkan produktivitas atau mungkin tidak; saya meragukan klaim itu. Setidaknya bos saya tidak akan menyukainya.

  • Perusahaan hardware setiap tahun membeli berbagai lisensi tool EDA yang lebih mahal daripada gaji developer. Jika produktivitasnya benar-benar meningkat secara nyata, maka sekitar $1.000 itu bukan apa-apa.
  • Kalau gaji developer memang semahal itu, justru tidak berinvestasi adalah keputusan yang tidak rasional. Jika $1k-1.5k per bulan benar-benar bisa meningkatkan produktivitas secara pasti, maka yang ragu justru tidak efisien. Dari sudut pandang ini, hanya menghitung biaya investasi AI adalah cara pandang yang terlalu disederhanakan. Jika AI bisa mengurangi jumlah developer yang dibutuhkan, itu juga merupakan penghematan nyata.
  • Saya sendiri bahkan belum menghabiskan $20 per bulan dengan intellij pro AI, jadi saya penasaran apakah Claude benar-benar semahal itu, lalu setelah mencari tahu ternyata memang bisa saja. Bagaimanapun, kenyataannya langganan AI akan menambah pos anggaran di suatu tempat, dan seperti perusahaan yang sudah membayar internet cepat, biaya AI juga mulai menjadi hal dasar.
  • Dan perlu diingat juga bahwa harga ini sebenarnya berbasis subsidi.
  • Menarik melihat bagaimana perusahaan akan berubah ke depan. Yang jelas, pada akhirnya pertanyaannya adalah dengan standar apa developer akan dinilai. Apakah penggunaan AI meningkatkan risiko dirugikan dalam penilaian kinerja/PHK, dan bagaimana seseorang membuktikan bahwa dirinya, bukan LLM, adalah aktor utama di balik hasil kerja itu, akan menjadi isu penting.

• Saya kurang paham dengan cara pemakaian MCP(Multi-Channel Processor) yang disebut di teks. Claude Code sebenarnya bisa memakai shell seperti curl atau gh untuk memanggil hampir semua layanan pihak ketiga, jadi kalau memakai MCP justru bisa menimbulkan masalah (misalnya server MCP untuk Linear memotong issue yang terlalu panjang, sedangkan bila memanggil API langsung batasan seperti itu tidak ada). Saya penasaran apakah ada sesuatu yang saya lewatkan.

• Anthropic mengunggah wawancara dengan Boris Cherny (pencipta Claude Code), dan di sana juga dibagikan ide tentang masa depan agent coding Claude Code serta cara memanfaatkannya https://youtu.be/iF9iV4xponk

• Saat melihat penyebutan "anggaran $1000-1500/bulan", saya jadi berpikir jangan-jangan orang itu hanya memakai API key dan tidak tahu soal paket bulanan seperti claude MAX. Menurut saya, $100~200 per bulan sudah cukup menutup kebutuhan selama tidak sekadar mengulang query tanpa arah.

  • $1k-1.5k terasa terlalu mahal. Bahkan paket Max 20x seharga $200 per bulan sudah mencakup pemakaian yang cukup besar, dan kuotanya di-reset tiap 5 jam. Meski begitu, jika batasnya tetap terlampaui setiap hari, bisa jadi model bayar per token justru memang akan lebih mahal.

• Jika berencana memakai Claude atau agen lain, saya sangat menyarankan logging. Jika seluruh file log dimasukkan ke AI, peluang untuk merangkum masalah dan mendapatkan jawaban atau masuk ke langkah berikutnya jadi lebih besar. Logging benar-benar adalah segalanya.