Bayangkan sebuah repositori proyek pribadi yang nomor berurutan Issue dan Pull Request GitHub-nya sudah mendekati empat digit.
Reaksi pertama mudah ditebak:
“Berarti satu orang sudah melakukan hampir seribu pekerjaan pengembangan?”
Hampir, tetapi angka itu tidak bisa diterjemahkan langsung seperti itu. Dalam sistem GitHub, setiap Pull Request diperlakukan sebagai sebuah Issue untuk penomoran, dan nomor Issue serta Pull Request tidak tumpang tindih dalam repositori yang sama. Jadi nomor mendekati 1000 tidak berarti 1000 Pull Request telah selesai.[1]
Pertanyaan yang lebih menarik justru tetap ada:
Jika skala perubahan, pemeriksaan, perbaikan, publikasi, dan operasi seperti ini harus dilakukan manusia sebagian besar secara manual tanpa AI, berapa biayanya dan apakah modelnya masih menguntungkan?
Itulah salah satu pertanyaan inti dalam ekonomi pengembangan solo berbantuan AI.
1. Nomor GitHub bukan penghitung repetisi di gym
Nomor repositori bukan meteran beban kerja.
Satu pengembang bisa memasukkan 2000 baris perubahan ke satu Pull Request. Pengembang lain bisa membuka Pull Request hanya untuk memperbaiki satu baris CSS. Issue juga memakai ruang nomor yang sama: laporan bug, catatan desain, permintaan fitur, investigasi, dan pekerjaan operasional.
Jadi:
nomor yang hampir 1000 bukan berarti kerja setara 1000 orang.
Dan juga bukan:
hampir 1000 fitur selesai.
Angkanya lebih mirip penghitung pintu putar daripada timbangan.
Namun jika banyak perubahan kecil menumpuk dalam waktu singkat, riwayat itu tetap menunjukkan sesuatu: siklus desain → implementasi → verifikasi → perbaikan telah diputar berkali-kali.
Untuk menghitung biaya manusia, variabel pentingnya bukan nomor, melainkan waktu rata-rata yang dibutuhkan satu siklus substantif.
2. Biaya manusia paling mudah diremehkan ketika tiap tugas terlihat kecil
Sebuah laporan yang terbit pada September 2026 berdasarkan daftar proyek engineer freelance di Jepang mencatat rata-rata tarif proyek bulanan Agustus 2026 sebesar 789.000 yen.[2]
Itu bukan gaji semua developer dan bukan tarif per jam seseorang tertentu. Itu hanyalah rata-rata pasar dari proyek yang terdaftar.
Tetapi angka tersebut berguna sebagai salah satu patokan biaya pengganti: kira-kira berapa biaya membeli kapasitas engineering profesional yang sebanding dari luar?
Dengan asumsi 160 jam per bulan, nilainya sekitar 4930 yen per jam.
Sekarang bayangkan ada 1000 unit perubahan substantif. Ini contoh hipotetis dan bukan arti dari nomor GitHub #1000.
| Waktu rata-rata per perubahan | Total waktu | Orang-bulan pada 160 jam/bulan | Biaya pada 789.000 yen/bulan |
|---|---|---|---|
| 15 menit | 250 jam | 1,56 | sekitar ¥1,23 juta |
| 30 menit | 500 jam | 3,13 | sekitar ¥2,47 juta |
| 45 menit | 750 jam | 4,69 | sekitar ¥3,70 juta |
| 1 jam | 1000 jam | 6,25 | sekitar ¥4,93 juta |
| 2 jam | 2000 jam | 12,5 | sekitar ¥9,86 juta |
| 3 jam | 3000 jam | 18,75 | sekitar ¥14,79 juta |
| 4 jam | 4000 jam | 25 | sekitar ¥19,73 juta |
Seribu perubahan yang masing-masing hanya 15 menit tetap menjadi 250 jam.
“Setiap tugas kecil” tidak sama dengan “total biayanya kecil”.
Tugas kecil juga membawa biaya tetap: investigasi, membuat branch, review, testing, merge, mengecek deployment, dan memikirkan rollback.
Jika satu orang melakukan semuanya secara manual, kartu namanya lama-lama harus dilipat: penulis, penerjemah, frontend, backend, QA, infrastruktur, dan editor kepala.
3. “Saya kerjakan sendiri, jadi biaya tenaga kerja nol” bisa benar untuk kas, tetapi berbeda untuk perbandingan ekonomi
Sebuah situs pribadi mungkin membayar hosting 1000 yen per bulan dan menghasilkan 5000 yen dari iklan.
Secara kas, ada surplus 4000 yen.
Tetapi jika pemilik menghabiskan 50 jam per bulan, perbandingan bisnis perlu sudut pandang lain.
Pisahkan setidaknya dua ukuran:
Laba kas = pendapatan − pengeluaran kas
Laba setelah penyesuaian tenaga kerja = pendapatan − pengeluaran kas − jam kerja pemilik × nilai tarif pengganti yang dipilih
Kalau ini hobi, menilai waktu sendiri sebagai nol sangat masuk akal. Orang biasanya tidak mengatakan bahwa bermain gim 50 jam menimbulkan kerugian tenaga kerja.
Masalahnya baru muncul ketika akuntansi hobi dipakai sebagai bukti bahwa bisnis itu sangat menguntungkan.
Belajar, bersenang-senang, reputasi, dan kepuasan membangun sesuatu adalah hasil nyata. Namun itu tidak sama dengan laba bisnis.
Dalam perbandingan ekonomi, waktu tidak menghilang hanya karena tidak ada faktur.
4. Model iklan dapat membutuhkan penyebut yang sangat besar
Rumus sederhana untuk iklan:
Pendapatan iklan = pageview ÷ 1000 × RPM efektif
RPM efektif dapat sangat berbeda menurut negara, perangkat, format iklan, musim, topik, audiens, dan konfigurasi iklan.
Karena itu, di sini tidak ada klaim tentang “RPM pasar yang normal”. Kita hanya memakai angka hipotetis untuk melihat skalanya.
Jika 789.000 yen per bulan harus ditutup hanya dari iklan:
| RPM efektif hipotetis | PV yang dibutuhkan untuk ¥789.000/bulan |
|---|---|
| ¥100 | sekitar 7,89 juta PV |
| ¥300 | sekitar 2,63 juta PV |
| ¥500 | sekitar 1,58 juta PV |
| ¥800 | sekitar 0,99 juta PV |
Ini bukan prediksi pendapatan untuk situs tertentu.
Tabel tersebut menunjukkan bahwa ketika tenaga manusia dinilai dengan biaya pengganti profesional, mengembalikan seluruh biaya hanya lewat iklan dapat membutuhkan trafik yang sangat besar.
Karena itu, banyak situs manual menggabungkan iklan dengan afiliasi, penjualan produk, akuisisi klien, keanggotaan, donasi, nilai merek, atau sekadar nilai hobi.
5. AI mengubah jauh lebih banyak daripada kecepatan menulis
Kalau nilai AI dipersempit menjadi “bisa menulis artikel dalam 30 detik”, sebagian besar ekonominya hilang.
Mengoperasikan media web melibatkan pekerjaan di sekelilingnya:
- menemukan topik,
- riset,
- menulis,
- memeriksa fakta,
- mengubah kode,
- testing,
- lokalisasi,
- publikasi,
- memverifikasi hasil produksi,
- memperbaiki insiden,
- distribusi ke media sosial dan newsletter,
- mengukur lalu memperbaiki.
Dengan operasi manual, setiap proses tambahan biasanya menambah biaya tenaga kerja variabel.
Dengan AI dan otomatisasi, biaya awal membangun sistem bisa lebih tinggi, tetapi biaya marginal untuk item kedua, kesepuluh, dan keseratus dapat turun.
Ini bukan sekadar “penulis menjadi lebih cepat”.
Lebih mirip:
satu orang dapat memiliki sistem operasi untuk sebuah tim editorial kecil dan tim engineering kecil.
Manusia tidak hilang.
Perannya bergeser ke input, keputusan, spesifikasi, standar kualitas, pengecualian, dan tata kelola.
Dari membuat setiap artefak dengan tangan menjadi perancang pabrik sekaligus editor kepala.
6. AI bukan nitro ajaib yang selalu mempercepat pengembangan
Hasil penelitian menarik justru karena arahnya tidak selalu sama.
Eksperimen terkontrol yang dipublikasikan pada 2023 menemukan bahwa peserta dengan GitHub Copilot menyelesaikan tugas server HTTP JavaScript tertentu 55,8% lebih cepat dibanding kelompok kontrol.[3]
Sebaliknya, uji acak METR pada 2025 menemukan bahwa 16 pengembang open-source berpengalaman, ketika mengerjakan repositori matang yang sudah mereka kenal bertahun-tahun, rata-rata membutuhkan waktu 19% lebih lama saat alat AI awal 2025 diizinkan.[4]
Pada Februari 2026, METR menjelaskan bahwa eksperimen lanjutan menjadi sulit ditafsirkan. Semakin banyak developer enggan ikut jika harus bekerja tanpa AI, dan waktu kerja sulit diukur pada orang yang menjalankan beberapa agen secara paralel. Alat yang lebih baru mungkin memang memberi percepatan lebih besar dibanding awal 2025, tetapi data baru tidak mendukung angka efek yang kuat karena masalah seleksi dan pengukuran.[5]
Jadi kesimpulannya bukan:
AI selalu membuat pekerjaan 55% lebih cepat.
Dan juga bukan:
AI membuat ahli 19% lebih lambat.
Dampaknya tergantung tugas, keakraban dengan codebase, alur agen, beban review, paralelisasi, dan lingkungan testing.
AI bisa menghasilkan hal benar dengan cepat. Sistem yang buruk juga bisa menghasilkan bug dengan cepat.
Angka produktivitas yang relevan adalah yang diukur dalam alur nyata proyek sendiri.
7. Situs manual tidak otomatis kalah
Sistem AI yang sangat otomatis tidak dijamin lebih untung daripada situs buatan tangan.
Produksi manual bisa masuk akal ketika:
- hanya menerbitkan beberapa artikel per bulan,
- tulisan pribadi sang ahli adalah produknya,
- satu artikel menjual produk atau jasa bernilai tinggi,
- tidak perlu banyak bahasa dan distribusi luas,
- pembaruan jarang,
- pemilik menikmati proses sebagai hobi,
- atau biaya membangun otomatisasi lebih besar daripada tenaga yang dihemat.
Otomatisasi lebih menarik ketika:
- proses yang sama terus berulang,
- banyak bahasa dipelihara,
- jumlah konten tumbuh,
- setiap publikasi perlu QA dan verifikasi produksi,
- kanal distribusi bertambah,
- dan manusia terus mengulang pemeriksaan yang sama.
Ini pada dasarnya persoalan biaya tetap dan biaya variabel.
Pabrik AI bisa mahal di awal. Bengkel manual bisa mahal per unit.
Dan satu peringatan: pabrik otomatis yang sangat canggih tanpa pembaca bukan masa depan media. Itu gudang yang sangat modern.
8. Untuk memahami ekonomi situs manual tanpa AI, tanyakan angka-angka ini
Tidak perlu menilai orangnya.
Untuk membandingkan sistem, beberapa angka operasional sudah cukup:
- Jam kerja pemilik per bulan
- PV atau pengguna unik bulanan
- Pendapatan dan pengeluaran kas bulanan
- Jumlah artikel dan artikel baru per bulan
- Jumlah bahasa yang didukung
- Lama operasi dan perkiraan jam pembangunan awal
Dari sana bisa dihitung:
Laba kas = pendapatan − pengeluaran kas
Imbal hasil kas per jam pemilik = laba kas ÷ jam kerja
Laba setelah penyesuaian tenaga kerja = laba kas − jam kerja × tarif pembanding
Biaya marginal per artikel = tambahan waktu dan biaya menulis + menerjemahkan + QA + publikasi + distribusi
Ukuran terakhir sangat penting.
Fakta bahwa 1000 jam telah dihabiskan di masa lalu kurang menjelaskan masa depan dibanding berapa jam yang dibutuhkan untuk menerbitkan artikel berikutnya sekarang.
9. Kekuatan utama AI dalam pengembangan solo bukan volume, melainkan keterulangan
Menghasilkan tumpukan besar file dalam semalam bukan lagi bagian tersulit.
Yang sulit adalah membangun sistem di mana:
- standar kualitas yang sama berlaku lagi pada putaran berikutnya,
- hanya bagian yang gagal yang perlu diulang,
- publikasi ganda dicegah,
- revisi terkini dapat diidentifikasi,
- hasil nyata di produksi diverifikasi,
- satu kanal yang terblokir tidak menghentikan pekerjaan lain,
- autentikasi yang benar-benar butuh manusia dikembalikan kepada manusia,
- dan riwayat tetap dapat diaudit.
Itu bukan sekadar volume generasi.
Itu adalah aset operasional.
Situs manual juga bisa membangun aset semacam ini melalui prosedur, template, CMS, backup, dan checklist.
Perbedaan di era AI adalah satu orang kini dapat membangun lapisan operasi tersebut dengan kedalaman yang luar biasa.
10. Kesimpulan: pertanyaan menarik bukan “sudah 1000?” melainkan “berapa biaya unit berikutnya?”
Nomor berurutan Issue dan Pull Request yang mendekati empat digit memang terlihat dramatis.
Tetapi jangan menjadikannya skor produktivitas.
Angka yang lebih berguna adalah:
jam manusia, biaya per perubahan, biaya marginal per artikel, tingkat pengerjaan ulang sebelum publikasi, output per jam pemilik, dan laba setelah penyesuaian tenaga kerja terhadap pendapatan.
Situs manual bisa sangat menguntungkan.
Situs dengan AI juga bisa rugi.
Namun kurva biayanya berbeda tajam antara model yang terus meminta manusia mengulang penulisan, penerjemahan, coding, QA, publikasi, monitoring, dan distribusi dengan model yang lebih dulu membangun sistem untuk menurunkan biaya marginal setelahnya.
Nomor yang mendekati 1000 menarik bukan karena ia medali.
Pertanyaan yang penting adalah:
dari semua putaran coba dan perbaiki itu, berapa banyak yang akhirnya berubah menjadi mekanisme sehingga manusia tidak perlu mengulang pekerjaan yang sama pada putaran berikutnya?
Di situlah ekonomi pengembangan solo berbantuan AI benar-benar berbeda.
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
