Sebulan Ngoding Harian Pakai Claude Sonnet 5

Saya pindah model default buat coding agent ke Claude Sonnet 5 sekitar sebulan lalu, awalnya karena ini muncul sebagai opsi yang lebih murah buat jalanin agent, dan saya penasaran apa “lebih murah” berarti “lebih jelek” buat jenis kerjaan yang beneran saya lakuin. Sebulan ini saya jalanin di tiga proyek freelance aktif — dashboard Next.js, tool desktop Avalonia, dan situs ini sendiri — jadi tulisan ini bukan benchmark, cuma cerita apa yang berubah di praktiknya.

Hal pertama yang saya sadari bukan kecepatan, tapi konsistensi. Sama model yang saya pakai sebelumnya, saya sering dapet output bagus dalam waktu lama, tapi diselingi miss yang aneh-aneh — rename variabel di tengah file terus lupa nge-update sisanya, atau lupa constraint yang saya sebutin tiga pesan sebelumnya. Sonnet 5 nggak berasa jauh lebih pintar di satu task tertentu, tapi dia jelas lebih jarang “lupa” konteks di sesi yang panjang. Di proyek dashboard, ada satu sesi yang nyentuh sebelas file lewat mungkin empat puluhan-plus tool call, dan dia tetep ngikutin naming convention yang cuma saya sebutin sekali di awal banget. Itu jenis hal yang dulu bikin saya harus ngulang-ngulang constraint tiap beberapa turn, yang justru makan perhatian saya lebih banyak dari coding-nya sendiri.

Harga yang lebih murah ngubah cara saya pakainya, bukan cuma total tagihannya. Karena lebih murah per token, saya jadi berhenti pelit ngasih konteks di awal. Dulu saya suka motong-motong apa yang saya kasih — cuma function yang relevan, bukan seluruh file, bukan test yang terkait — sebagian buat hemat biaya, sebagian lagi karena konteks lebih banyak kadang malah bikin noise. Sekarang saya cuma arahin ke file itu plus dua-tiga file terkait dan biarin dia baca sendiri. Hasilnya: koreksi “eh, di sini caranya bukan gitu” jadi lebih jarang belakangan, karena dia beneran liat pola yang udah ada, bukan nebak-nebak.

Di mana dia beneran lebih bagus: refactor lintas file. Saya suruh dia mindahin logic validasi yang keduplikasi di enam API route ke satu module bareng — persis jenis mess yang saya keluhin di codebase warisan orang lain. Workflow lama buat ini biasanya: agent kerjain satu file, saya cek, agent lanjut file berikutnya, ulang, terus di akhir baru ketauan ada drift antar file. Sama Sonnet 5 saya cukup jelasin bentuk targetnya sekali, terus biarin dia kerja di keenam route itu sekaligus, dan driftnya nyaris nol — signature function sama, pola error handling sama, gaya import sama, di semua file. Saya tetep baca tiap diff baris per baris sebelum commit, karena disiplin itu nggak berubah cuma gara-gara modelnya lebih bagus. Tapi yang perlu dibenerin jauh lebih dikit.

Di mana dia nggak otomatis lebih bagus: keputusan yang butuh judgment. Apapun yang butuh keputusan produk atau arsitektur beneran — ini harus jadi table baru atau kolom JSON aja, state ini harus di store atau cukup local di component — dia tetep cuma milih sesuatu yang masuk akal terus jalan terus, kecuali saya stop dan minta dia jabarin tradeoff-nya eksplisit. Wajar, dan jujur itu memang behavior default yang bener buat sebuah tool, tapi artinya bagian kerjaan saya yang emang dari dulu nggak bakal ilang — mengambil keputusan, bukan cuma produksi — ya tetep nggak ke mana-mana. Malah karena eksekusi jadi lebih cepat dan murah, bagian pengambilan keputusan ini jadi porsi yang sedikit lebih besar dari waktu saya sekarang.

Proyek desktop app yang paling bikin saya kaget. Avalonia/C# itu niche yang lebih kecil dibanding framework web, yang biasanya berarti performa model lebih jelek karena data trainingnya lebih dikit. Saya udah nyiapin diri buat lebih banyak “nuntun tangan” di sini. Ternyata dia handle pola binding XAML dan struktur MVVM yang udah saya bangun kira-kira sebagus dia handle route Next.js — jelas dia ngambil konvensi yang udah ada dari baca codebase-nya, bukan balik ke pola C# generik yang nggak nyambung sama struktur proyeknya. Ini bagian yang paling penting buat solo dev yang kerja di stack yang beneran campur-campur: saya nggak mau tool yang jago di framework populer tapi medioker di semua yang lain, karena minggu kerja saya beneran nggak kayak gitu.

Yang paling lama saya sesuain bukan modelnya, tapi kebiasaan saya sendiri. Minggu pertama-dua saya masih kerja pakai potongan kecil dan hati-hati yang udah jadi kebiasaan gara-gara model lama sering “lupa” konteks — checking in tiap abis satu file, ngulang-ngulang hal yang sebenernya udah nggak perlu diulang lagi. Butuh usaha sadar buat nyadarin saya lagi kompensasi buat limitasi yang sebenernya udah nggak ada lagi. Lag yang aneh — bukan tool-nya yang ketinggalan, tapi saya yang ketinggalan dari tool-nya — dan saya curiga ini faktor yang lebih besar buat seberapa banyak value yang beneran didapet orang dari upgrade model, dibanding yang ditunjukin benchmark.

Apa saya rekomendasiin pindah? Kalau kamu udah jalanin workflow agentic coding dan biaya pernah jadi faktor gimana hati-hatinya kamu ngasih konteks, ya — bagian lebih murah per token ini ngubah behavior kamu ke arah yang bagus, bukan cuma ngubah tagihan. Kalau kamu ngarepin ganti model doang bakal benerin codebase yang emang nggak punya disiplin review di belakangnya, ya nggak bakal — poin yang sama terus saya sampaikan di setiap tulisan AI tooling tahun ini: tool-nya makin bagus, tapi kerjaan buat beneran baca apa yang dia hasilin nggak jadi lebih ringan.