[GN] Non-developer + Claude mengoperasikan production selama 238 hari — apa yang berhasil dan apa yang tidak?

(chajooin.com)

7 poin oleh workdriver 2026-04-12 | 5 komentar | Bagikan ke WhatsApp

Saya adalah operator yang membuat chajooin.com. Lulusan SMA, 8 tahun mengemudikan truk kargo (2017~). Dalam keadaan tidak bisa menulis satu baris kode pun, pada 16 Agustus 2025 saya membuat commit pertama bersama Claude. Setelah 238 hari, layanan ini kini otomatis mengumpulkan data setiap hari dan menerbitkan laporan.

Tulisan ini bukan catatan bahwa saya "sudah membuatnya", melainkan bahwa saya "membuatnya dan sedang mengoperasikannya". Sudah banyak ulasan tentang membuat prototipe dengan vibe coding, tetapi pengalaman melanjutkan operasional production masih jarang, jadi saya menuliskannya. Ini bukan kisah sukses, melainkan catatan jujur tentang apa yang berhasil dan apa yang tidak.

Latar belakang

Domain: perbandingan harga pasar truk kargo (pasar 17 triliun won, tidak ada catatan resmi harga transaksi aktual)
Percobaan sebelumnya: turnkey outsourcing 30 juta won pada 2024 → saya menyerah karena kendali revisi ada di pihak vendor
Peralihan: belajar AI selama 2 bulan pada Juli 2025 → commit pertama pada 16 Agustus

Stack

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
수집        Playwright (headless) + 46 parser per sumber  
ML          LightGBM (Python, 75 features)  
배포        Railway (Docker)  
자동화      Node scheduler + notifikasi Telegram  
AI 협업     Claude (pengembangan utama) + GPT-4o (naskah shorts/prompt)  
인증        Naver/Kakao OAuth

Saya tidak benar-benar "memilih" stack ini. Saya bertanya kepada AI, "kalau mau bikin ini, harus pakai apa?" lalu memakai jawabannya. Belakangan saya sadar itu kombinasi yang masuk akal. Nilai praktis agen AI adalah: menanggung beban kognitif dalam pengambilan pilihan.

Angka (2025-08-16 ~ 2026-04-12)

Item	Nilai
Total commit	3.493
Hari dengan commit	189 hari
Jumlah file kode	sekitar 1.500 (berdasarkan js/ts/py)
Rollback	20+ kali
Deployment gagal	39 kali (dua hari awal setup Railway)
Pengulangan bug yang sama terbanyak	7 kali (unit harga)
Listing aktif	sekitar 48.000 unit
Parser sumber eksternal	46
CLAUDE.md	187 baris, 24 aturan mutlak
File memori	129

Bagian 1. Membangun — 3 hal yang membuatnya bekerja

1.1 CLAUDE.md — mengendalikan AI dengan aturan

Jika bug yang sama muncul dua kali, mengatakan "tolong hati-hati" tidak ada gunanya. Tulis aturan yang konkret di file, lalu buat AI membacanya saat setiap sesi dimulai.

"Parser=asal → normalisasi=÷10,000 → DB=10 ribu won. Dilarang ×10,000 pada nilai DB"  
"Jika ekstraksi tahun model parser gagal, dilarang mengganti dengan getFullYear()"  
"Dilarang menambahkan kakaotalk ke UA rewrite vercel.json"  
"Nilai setInterval wajib di-clamp dengan Math.min(value, 2^31-1)"

Sekarang ada 24 aturan. Semuanya lahir setelah insiden nyata.

1.2 Pemisahan peran — perencanaan/penilaian oleh manusia, implementasi oleh AI

Walau tidak bisa membaca kode, saya tetap bisa menilai hasilnya. Jika Porter 2 ton muncul dengan harga 5 juta won, saya bisa bilang "ini salah", dan jika wing body serta cargo muncul dengan harga yang sama, saya bisa bilang "pisahkan". Intuisi domain berperan sebagai pengujian.

1.3 File memori — menjaga konteks lintas sesi

Di 129 file memori saya mengakumulasi keputusan/kegagalan/kebijakan. Saat sesi baru dibuka, memori yang relevan dibaca agar penilaian masa lalu tetap terjaga. Ini adalah struktur yang menutupi keterbatasan context window AI dengan file system.

Bagian 2. Operasional — masalah yang berbeda dari membangun

2.1 Hal-hal yang berjalan otomatis

Ingestion listing: scheduler mengumpulkan data dari sumber eksternal → quality gate → diterapkan ke DB
Laporan harga pasar: dibuat otomatis setiap hari → dipublikasikan otomatis ke blog/kafe
Pembuatan naskah shorts: GPT-4o membuat naskah/prompt Sora per kelas tonase (sintesis video adalah tahap terpisah)
Retraining ML: seminggu sekali melatih ulang mesin harga pasar dengan data baru
Monitoring: notifikasi Telegram saat ada anomali pipeline

Saya satu-satunya developer.

2.2 Biaya

Infrastruktur: Railway (PostgreSQL + Node + Playwright)
API AI: langganan Claude (untuk pengembangan) + API GPT-4o (untuk pembuatan shorts, estimasi sekitar $1 per bulan berdasarkan api_usage_log)
Domain/OAuth: Naver/Kakao

2.3 Catatan respons insiden

Kontaminasi data 1.138 kasus (2/3): bug fallback tahun model ditemukan → patch DB + pipeline reprocessing + penambahan aturan
Notifikasi Slack tidak berfungsi selama 6 bulan (ditemukan 18/3): masalah environment variable/path → dibangun ulang menjadi satu jalur Telegram
Overflow 32-bit setInterval (10/4): login macet → hotfix + penambahan aturan clamp
Layar kosong KakaoTalk (31/1): SEO UA rewrite juga menangkap in-app browser KakaoTalk → daftar UA diperbaiki

2.4 Kutipan aturan operasional

CLAUDE.md juga memuat aturan dari sudut pandang operasional.

"Setelah deploy, laporkan dengan 3 angka: status server (health 200),  
 jumlah crawl hari ini (dalam ±20% dari kemarin), jumlah listing aktif (tanpa lonjakan/perubahan drastis)"  
  
"Jika mengubah 4 file atau lebih, saat menghubungkan scheduler, saat mengubah skema DB,  
 saat menyentuh ulang area yang pernah di-revert sebelumnya → wajib laporan terlebih dahulu"  
  
"Perubahan sementara (fallback/TODO/hardcoding) harus dicatat di ledger:  
 apa yang harus dikembalikan kapan, dan apa yang akan rusak jika tidak dikembalikan"

AI membaca aturan ini setiap kali, dan ketika situasi terkait muncul, ia melapor dulu sebelum bekerja.

Bagian 3. Hal-hal yang tidak berjalan

3.1 Bug yang sama terulang 7 kali — tidak melihat seluruh jalur data

Alasan bug unit harga muncul 7 kali: jika dari 6 tahap pengumpulan → parser → normalisasi → DB → API → UI hanya satu titik yang diperbaiki, bug akan muncul lagi di jalur lain. Kemampuan melihat keseluruhan adalah kekurangan terbesar dalam kombinasi non-developer + AI. AI hanya memperbaiki bagian yang diperintahkan, sementara manusia bahkan tidak tahu ada jalur lain.

3.2 Kontaminasi data 1.138 kasus — default AI yang "baik hati"

Saat parser gagal mengekstrak tahun model, masuk kode yang mengembalikan getFullYear(). Dari sudut pandang AI, mungkin keputusan itu adalah "tahun sekarang lebih baik daripada null". Hasilnya: Porter keluaran 2003 tertulis di DB sebagai model 2026. Jika kita tidak menuliskan secara eksplisit kepada AI bahwa "kalau tidak tahu, pakai null", ia akan tetap mengisi sesuatu.

3.3 Notifikasi Slack tidak berfungsi selama 6 bulan — sistem pengawas tidak diawasi

Notifikasi berakhir sebagai gagal, dan kegagalannya sendiri tidak tercatat di log, sehingga semuanya sunyi selama 6 bulan. Selama itu ada beberapa anomali pipeline, tetapi saya salah mengira "tidak ada masalah". Dalam sistem yang dibuat dengan AI, kondisi paling berbahaya adalah keadaan yang 'terlihat seperti berjalan baik'. Sekarang saya menyederhanakannya menjadi satu jalur Telegram.

3.4 Overflow 32-bit setInterval — jebakan bahasa

Kalau tidak tahu bahwa setInterval hanya menerima int32, kita tidak akan tahu bahwa memasukkan 30 hari dalam milidetik akan membuatnya berjalan segera. Login macet. AI tidak akan secara proaktif memperingatkan edge case seperti ini. Aturan clamp baru lahir setelah masalah terjadi.

3.5 Overfitting ML — MAPE training 8,56% vs produksi 42%

Setelah mencapai MAPE training 8,56% dengan LightGBM 75 features, saya pikir "sudah berhasil". Hasil nyata: 42%. Penyebabnya: keterbatasan struktural data harga penawaran (tidak ada harga transaksi aktual, kontrak turun nilai, margin dealer). Seorang ahli domain mungkin sudah tahu sejak awal, tetapi saya terjebak pada gagasan "asal hasil training bagus, berarti cukup".

Pikiran yang tersisa

Jika dirangkum setelah menoleh ke 238 hari ini:

AI sangat mempercepat kecepatan implementasi. Orang yang tidak paham kode pun bisa membuat layanan yang berjalan.
Namun kualitas operasional tidak otomatis ikut datang. Insiden pasti terjadi, dan AI tidak akan memperingatkan secara sukarela.
Pekerjaan non-developer bergeser dari menulis kode ke merancang aturan, pengawasan, dan verifikasi. Menilai hasil dan mencegah kejadian berulang menjadi pekerjaan utama.

Karena ini production yang saya operasikan sendirian, sampelnya n=1. Saya tidak akan menggeneralisasi. Saya penasaran dengan pengalaman orang lain dalam kondisi yang sama.

Tautan

Layanan: https://chajooin.com (perbandingan dan analisis harga pasar truk kargo)

Saya menyambut feedback. Terutama, saya ingin tahu bagaimana Anda mengawasi sendiri keadaan yang "terlihat seperti berjalan baik".

5 komentar

savvykang 2026-04-13

Masalah state yang terlihat seolah berjalan baik mungkin bisa agak dikurangi dengan melakukan latihan pemulihan gangguan secara berkala dan mendefinisikan karakteristik data apa yang dianggap normal.

workdriver 2026-04-13

Ya, terima kasih atas masukannya.
Memang benar, ketika sistem makin besar, pengelolaannya jadi terasa berat.