[GN] Geliştirici olmayan biri + Claude ile prodüksiyonda 238 gün — neler işe yaradı, neler yaramadı?

(chajooin.com)

7 puan yazan workdriver 2026-04-12 | 5 yorum | WhatsApp'ta paylaş

Chajooin.com'u yapan işletmeciyim. Lise mezunuyum, 8 yıldır kamyonculuk yapıyorum (2017~). Tek satır kod yazmayı bilmez durumdayken 16 Ağustos 2025'te Claude ile birlikte ilk commit'imi attım. Aradan 238 gün geçti ve bu servis şimdi her gün otomatik olarak veri topluyor ve rapor yayımlıyor.

Bu yazı, "yaptım" değil, "yapıp işletiyorum" kaydıdır. Vibe coding ile prototip çıkarma deneyimi çok, ama prodüksiyon işletmeyi sürdürme deneyimi nadir olduğu için yazıyorum. Bu bir başarı hikâyesi değil, neyin çalıştığı ve neyin çalışmadığına dair dürüst bir kayıt.

Arka plan

Alan: Kamyon fiyat karşılaştırması (17 trilyon wonluk pazar, fiilî işlem fiyatlarına dair resmî kayıt yok)
Önceki deneme: 2024'te anahtar teslim dış kaynak geliştirme için 30 milyon won → değişikliklerde kontrol dış kaynak tarafında olduğu için vazgeçildi
Geçiş: 2025 Temmuz'da 2 ay yapay zeka öğrenimi → 16 Ağustos'ta ilk commit

Stack

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
sujip       Playwright (headless) + kaynak bazlı parser 46 adet  
ML          LightGBM (Python, 75 features)  
baepo       Railway (Docker)  
otomasyon   Node scheduler + Telegram bildirimi  
AI iş birliği Claude (ana geliştirme) + GPT-4o (Shorts metni/prompt)  
auth        Naver/Kakao OAuth

Bu stack'i ben "seçmedim". Yapay zekaya "Bunu yapmak için ne kullanmalıyım?" diye sordum ve verdiğini uyguladım. Sonradan bakınca bunun makul bir kombinasyon olduğunu gördüm. Yapay zeka ajanlarının pratik değeri şu: seçim yapmanın bilişsel yükünü sizin yerinize üstleniyorlar.

Sayılar (2025-08-16 ~ 2026-04-12)

Öğe	Değer
Toplam commit	3,493
Commit atılan gün	189 gün
Kod dosyası sayısı	yaklaşık 1,500 (js/ts/py bazında)
Rollback	20+ kez
Dağıtım başarısızlığı	39 kez (Railway ilk kurulumunda 2 gün)
Aynı bug'ın en fazla tekrarı	7 kez (fiyat birimi)
Aktif ilan	yaklaşık 48,000 araç
Harici kaynak parser'ı	46 adet
CLAUDE.md	187 satır, 24 mutlak kural
Memory dosyası	129 adet

1. Bölüm. Yapım — çalışır hâle getiren 3 şey

1.1 CLAUDE.md — yapay zekayı kurallarla kontrol etmek

Aynı bug ikinci kez patlıyorsa "dikkatli ol" demenin anlamı yok. Somut kuralları bir dosyaya yazıp yapay zekanın her oturum başında okumasını sağlıyorum.

"Parser=ham değer → normalizasyon=÷10,000 → DB=10 bin won. DB değerine ×10,000 yasak"  
"Parser model yılını çıkaramazsa getFullYear() ataması yasak"  
"kakaotalk'ı vercel.json UA rewrite'a eklemek yasak"  
"setInterval değeri için Math.min(value, 2^31-1) ile clamp zorunlu"

Şu anda 24 madde var. Hepsi gerçek bir olaydan sonra eklendi.

1.2 Rol ayrımı — planlama/karar insanda, uygulama yapay zekada

Kodu okuyamasam da sonucu değerlendirebilirim. Porter 2 ton kamyon 5 milyon won görünüyorsa "bu yanlış" diyebilirim; wing body ile cargo aynı fiyatta çıkıyorsa "ayır" diyebilirim. Alan sezgisi test görevi görüyor.

1.3 Memory dosyaları — oturumlar arasında bağlamı korumak

129 memory dosyasında kararları/başarısızlıkları/politikaları biriktiriyorum. Yeni oturum açıldığında ilgili memory'ler okunuyor ve geçmişteki kararlar korunuyor. Bu, yapay zekanın context window sınırını dosya sistemiyle telafi eden bir yapı.

2. Bölüm. Operasyon — bir şey yapmakla işletmek farklı problemler

2.1 Otomatik çalışan şeyler

İlan ingestion'ı: Scheduler harici kaynaklardan veri topluyor → kalite kapısından geçiriyor → DB'ye yansıtıyor
Fiyat raporu: Her gün otomatik üretiliyor → blog/kafeye otomatik yayımlanıyor
Shorts senaryo üretimi: GPT-4o tonaj sınıfına göre senaryo/Sora prompt'u üretiyor (video sentezi ayrı aşama)
ML yeniden eğitimi: Haftada 1 kez yeni verilerle fiyat motoru yeniden eğitiliyor
Monitoring: Pipeline'da anormallik olursa Telegram bildirimi

Geliştirici olarak sadece ben varım.

2.2 Maliyet

Altyapı: Railway (PostgreSQL + Node + Playwright)
AI API: Claude aboneliği (geliştirme için) + GPT-4o API (Shorts üretimi için, api_usage_log bazında aylık yaklaşık $1 tahmini)
Domain/OAuth: Naver/Kakao

2.3 Olay müdahalesi kayıtları

1,138 kayıtlık veri kirlenmesi (3/2): model yılı fallback bug'ı bulundu → DB patch + yeniden işleme pipeline'ı + kural eklendi
Slack bildirimi 6 ay çalışmadı (3/18'de fark edildi): environment variable/path sorunu → tek Telegram hattında yeniden birleştirilerek sadeleştirildi
setInterval 32-bit overflow (4/10): giriş sistemi kilitlendi → hotfix + clamp kuralı eklendi
KakaoTalk'ta boş ekran (1/31): SEO UA rewrite, KakaoTalk in-app browser'ı da yakalıyordu → UA listesi düzeltildi

2.4 Operasyon kurallarından alıntı

CLAUDE.md içinde operasyon bakış açısından kurallar da var.

"Deploy sonrası 3 sayıyla rapor ver: sunucu durumu (health 200),  
 bugünkü crawl sayısı (düne göre ±%20 içinde), aktif ilan sayısı (ani dalgalanma yok)"  
  
"4 veya daha fazla dosya değiştiğinde, scheduler bağlantısı olduğunda, DB schema değiştiğinde,  
 daha önce revert edilen bir alan tekrar düzenlendiğinde → önceden rapor zorunlu"  
  
"Geçici değişiklikleri (fallback/TODO/hardcoding) kayıt altına al:  
 neyin ne zamana kadar geri alınması gerektiği ve geri alınmazsa neyin patlayacağı"

Yapay zeka bu kuralları her seferinde okuyor ve ilgili durum geldiğinde işe başlamadan önce önce rapor veriyor.

3. Bölüm. Çalışmayan şeyler

3.1 Aynı bug'ın 7 kez tekrarlanması — veri yolunun tamamını görememek

Fiyat birimi bug'ının 7 kez patlamasının nedeni şu: toplama → parser → normalizasyon → DB → API → UI şeklindeki 6 aşamadan sadece birini düzeltirseniz, başka bir yolda tekrar patlıyor. "Bütünü görebilme yeteneği", geliştirici olmayan biri + yapay zeka kombinasyonunda en eksik olan şey. Yapay zeka sadece söylenen yeri düzeltir; insan ise başka yol olduğunu bilmez.

3.2 1,138 kayıtlık veri kirlenmesi — yapay zekanın "nazik" varsayılanları

Parser model yılını çıkaramadığında getFullYear() döndüren bir kod eklenmişti. Yapay zekanın bakış açısından muhtemelen "null yerine mevcut yıl daha iyidir" diye düşündü. Sonuç: 2003 model Porter, DB'ye 2026 model olarak yazıldı. "Bilmiyorsan null döndür" ifadesini yapay zekaya ayrıca yazmazsanız, bir şekilde bir şeyi dolduruyor.

3.3 Slack bildirimi 6 ay çalışmadı — izleme sistemini izlememek

Bildirim başarısızlıkla bitiyordu ve bu başarısızlığın kendisi log'a düşmüyordu; bu yüzden 6 ay sessiz kaldı. Bu sırada pipeline'da birkaç anormallik oldu ama ben "sorun yok" sanıyordum. Yapay zekayla yapılmış sistemlerde en tehlikeli durum, 'iyi çalışıyor gibi görünen' durumdur. Şu anda tek Telegram hattına indirgenerek sadeleştirildi.

3.4 setInterval 32-bit overflow — dil tuzağı

setInterval'ın sadece int32 aldığını bilmiyorsanız, 30 günü milisaniye cinsinden verdiğinizde bunun anında çalışacağını da bilmezsiniz. Giriş sistemi kilitlendi. Yapay zeka bu tür edge case'ler için kendiliğinden uyarı vermiyor. Ancak patladıktan sonra clamp kuralı eklendi.

3.5 ML overfitting — eğitim MAPE %8.56'ya karşı gerçek kullanımda %42

LightGBM 75 features ile eğitimde MAPE %8.56 elde edip "oldu" sandım. Gerçekte %42 çıktı. Sebep: teklif fiyatı verisinin yapısal sınırları (fiilî işlem fiyatı yok, düşük bedelli sözleşmeler, bayi marjı). Bunu alan uzmanı olan biri en baştan bilebilirdi ama ben "eğitim sonucu iyiyse yeter" düşüncesine takıldım.

Kalan düşünceler

238 güne dönüp baktığımda özet şu:

Yapay zeka uygulama hızını ciddi biçimde artırıyor. Kod bilmeyen biri bile çalışan bir servis yapabilir.
Ama operasyon kalitesi otomatik olarak peşinden gelmiyor. Olaylar istisnasız yaşanıyor ve yapay zeka kendiliğinden uyarı vermiyor.
Geliştirici olmayan kişinin işi kod yazmaktan çok kural, gözetim ve doğrulama tasarlamaya kayıyor. Sonucu değerlendirmek ve tekrarını önlemek asıl işe dönüşüyor.

Bu, tek başıma işlettiğim bir prodüksiyon olduğu için örneklem n=1. Genelleme yapmayacağım. Aynı koşullarda başkalarının deneyimlerini merak ediyorum.

Bağlantı

Servis: https://chajooin.com (kamyon fiyat karşılaştırma ve analiz)

Geri bildirimlere açığım. Özellikle "iyi çalışıyor gibi görünen durumu" tek başınıza nasıl izlediğinizi merak ediyorum.

5 yorum

savvykang 2026-04-13

İyi çalışıyormuş gibi görünen durum sorunları, düzenli olarak arıza kurtarma tatbikatı yapmak ve veride hangi özelliklerin normal olduğunu tanımlamakla bir ölçüde hafifletilemez mi diye düşünüyorum

workdriver 2026-04-13

Evet, güzel görüşünüz için teşekkürler.
Sistem büyüdükçe yönetmenin zorlaştığı gerçekten doğru.