Grafik kontribusi GitHub saya pada 2025 terlihat seperti milik dua developer yang berbeda. Paruh pertama tahun itu nyaris kosong. Pada paruh kedua ada lebih dari 4.000 commit.
Saya tidak tiba-tiba memiliki lebih banyak waktu luang. Saya masih menyeimbangkan pekerjaan full-time dengan side project. Yang berubah adalah friction antara ide dan versi yang benar-benar berjalan: saya mulai menggunakan AI coding tools dengan jauh lebih serius.
Angka itu perlu dibaca dengan hati-hati. Jumlah commit bukan metrik produktivitas dengan sendirinya. Empat ribu commit tidak membuktikan bahwa saya membuat empat ribu perbaikan yang berarti atau bahwa kualitas kodenya bagus. Namun grafik itu memang menunjukkan perubahan nyata pada pola kerja saya: saya jauh lebih konsisten membangun, melakukan iterasi, dan membawa sesuatu ke versi yang berjalan.
Bottleneck sebenarnya adalah energi untuk memulai eksperimen
Dalam side project saya terus menemui masalah yang sama: versi pertama yang berguna sering berada di balik banyak pekerjaan rutin. Routing, validasi, script, test, configuration, dan cleanup dapat menghabiskan momentum bahkan sebelum saya tahu apakah sebuah ide layak diteruskan.
Dulu saya menunda eksperimen ketika versi awal tampak membutuhkan beberapa malam setup. AI coding tools tidak menghapus pekerjaan itu, tetapi menurunkan biaya first pass dan membantu saya mencapai versi yang bisa diuji lebih cepat.
Jadi keuntungan terbesarnya bukan mengetik lebih cepat. Keuntungan utamanya adalah activation energy yang lebih rendah: lebih banyak ide benar-benar sampai pada tahap di mana saya bisa mengumpulkan evidence.
Bagaimana workflow Node.js saya berubah
Saya tidak mengganti proses development dengan jendela chat. Dalam side project Node.js, saya memakai DeepSeek sebagai second pair of hands untuk task yang ruang lingkupnya jelas: membuat draft implementasi pertama, membaca code yang asing, mengusulkan test, menjelaskan stack trace, memecah refactor besar, dan meninjau asumsi deployment.
- Scaffolding: membuat versi awal yang membosankan dari handler, validation, script, atau test.
- Code reading: menelusuri request atau value sebelum mengedit.
- Refactoring: memecah perubahan mekanis menjadi diff kecil yang mudah direview.
- Debugging: menghasilkan beberapa hipotesis dari log.
- Verification: mencari edge case dan regression setelah happy path bekerja.
Semakin jelas input, output, constraint, dan convention yang ada, semakin mudah output diverifikasi. Task yang kabur lebih sering menghasilkan abstraction yang terdengar masuk akal tetapi salah.
Karena itu saya memperlakukan output AI sebagai candidate patch, bukan jawaban akhir. Type checking, test, build, dan real flow adalah evidence; penjelasan yang percaya diri bukan.
Di mana DeepSeek paling membantu — dan di mana tidak
DeepSeek paling berguna bagi saya karena praktis dipakai berulang kali untuk task programming yang konkret. Saya bisa meminta first pass, menolak sebagian, mengirim error yang sebenarnya, mempersempit scope, lalu iterate dengan cepat.
Saya tidak menyebutnya benchmark. Saya tidak melakukan studi terkontrol terhadap setiap model kompetitor dan model berubah cepat. Klaim yang lebih tepat adalah: DeepSeek cukup cocok dengan workflow saya sehingga saya memakai AI assistance jauh lebih sering.
Ia paling kuat ketika feedback murah: ada function, test, dan error nyata. Ia lebih lemah ketika task bergantung pada product context yang tidak tertulis atau trade-off architecture yang halus. Dalam situasi itu, output yang fasih bisa membuat asumsi buruk terlihat selesai.
AI mengubah biaya eksperimen
Perubahan terbesar bukan “AI menulis code, berarti development otomatis”. Banyak bagian kecil menjadi cukup murah untuk dicoba. Feature side project yang sebelumnya terasa membutuhkan terlalu banyak setup bisa berubah menjadi prototype selagi saya masih tertarik pada idenya.
Perbedaan itu penting. AI menurunkan biaya untuk mencapai versi yang bisa diuji. AI tidak menghilangkan architecture, product judgment, deployment, atau correctness. Implementasi hasil generasi masih bisa salah; build yang sukses masih bisa gagal saat runtime; prototype yang sudah deploy masih bisa menjadi produk yang buruk.
Bagi saya, manfaat praktisnya adalah momentum. Setelah melihat keseluruhan sistem bekerja, saya jauh lebih terdorong untuk terus memperbaikinya.
Apa yang dibutuhkan benchmark yang lebih kuat
Untuk benchmark yang reproducible, saya akan mencatat exact model versions, fixed programming tasks, repository snapshots, prompts, raw outputs, elapsed time, accepted/rejected patches, review time, test results, dan rework.
Saya juga akan mengukur lebih dari commit: waktu dari ide ke verified version, defect, rollback, dan pekerjaan yang harus ditulis ulang. Tanpa konteks itu, 4.000 commit adalah evidence aktivitas dan perubahan perilaku, bukan bukti kualitas software.
Apa yang berubah bagi saya
2025 adalah tahun ketika saya berhenti memandang setiap side project sebagai gunung setup yang harus saya daki secara manual. AI membuat versi pertama yang berjalan cukup murah sehingga saya lebih sering mencapai tahap ketika keputusan produk benar-benar mulai penting.
Itulah alasan paruh kedua grafik GitHub saya terlihat sangat berbeda. Bukan karena AI memberi saya lebih banyak jam dalam sehari, dan bukan karena setiap baris yang dihasilkan selalu bagus. AI mengurangi friction yang dulu membunuh ide sebelum menjadi nyata.
Pada 2026 fokus saya ada pada sisi yang kurang glamor: menyempurnakan workflow, mengukur quality dengan lebih serius, dan memastikan development yang lebih cepat menghasilkan software yang lebih baik, bukan sekadar lebih banyak commit.