Serverless Korku Hikâyeleri

• Çeşitli SaaS ve serverless hizmetlerinde beklenmedik derecede yüksek faturalar sık sık ortaya çıkıyor; bu sayfa da bu vakaları derli toplu biçimde bir araya getiriyor
• Normal şekilde aylık abonelik ücreti ödeyen kullanıcıların bile DoS saldırıları veya kontrolsüz kaynak kullanımı nedeniyle bir gün içinde on binlerce ila yüz binlerce dolarlık faturalarla karşılaştığı görülüyor
• Bazı hizmetlerde harcama limiti belirlenmiş olmasına rağmen aşım ücretlerinin yine de uygulanması, sistemsel sınırları görünür kılıyor
• Geliştirici topluluğunda bu tür deneyimler paylaşılırken, mantık dışı ücretlendirme yapıları ve şeffaflık eksikliği başlıca sorunlar olarak öne çıkıyor
• Serverless ve bulut ortamlarında küçük bir hata ya da tek bir saldırı yüzünden çok büyük maddi kayıplar yaşanabildiği için dikkat edilmesi gerektiği vurgulanıyor

---

Serverless ve SaaS hizmetlerinde aşırı faturalandırma vakaları derlemesi

#1 Webflow'da ortaya çıkan yüksek tutarlı ücretlendirme

• Aylık 69 dolarlık plan kullanılırken, hiçbir açık neden yokken tek aylık dönem için $1,189.42 fatura çıkarıldı

#2 WebGL oyun sitesine DoS saldırısı vakası

• Orta ölçekli bir WebGL oyun yükleme sitesi işleten kişi, DoS saldırısı sonrasında Google Firebase tarafından bir gün içinde $100,000'ı aşan bir fatura ile karşılaştı

#3 Vercel Pro ve harcama limiti aşımı

• Vercel Pro planı aylık $20 karşılığında kullanılırken ve $120 harcama limiti tanımlanmışken bile beklenmedik ek ücretler çıktı

#4 Proje ücretlendirmesi ve aşırı yüksek fatura

• Ayda $50 ödenen bir projede, bir sabah $70,000 tutarında fatura görüldü

#5 BigQuery kullanımı ve herkese açık veri kümesi ücretlendirme sorunu

• Playground ortamında BigQuery kullanılırken $22,000'ı aşan çok büyük bir ücret yansıtıldı

#6 Düşük ziyaretçi sayısına rağmen aşırı hosting ücreti

• Aylık ziyaretçi sayısı 9,000 olmasına rağmen aylık $250 fatura çıkarıldı; bu da yılda $3,000 harcama anlamına geliyor

#7 Devin(AI)'ın codebase'i değiştirmesinden sonra yaşanan sorun

• AI olan Devin kod değişikliği yaptığında ortaya çıkan beklenmedik sonuçlar deneyimlendi

#8 Ücretsiz kullanım sonrası aniden ücret yansıtılması

• Daha önce hiç ödeme yapılmamış olmasına rağmen bir gün ansızın $530 fatura oluştu

#9 Dokümantasyon sitesi ve diğer küçük projelerde ücretlendirme

• Basit bir dokümantasyon sitesi için bile yaklaşık $400 fatura çıkması gibi, düşük kullanımlı hizmetlerde de çok sayıda yüksek ücret vakası bulunuyor

#10 Ücretsiz katmanın korkusu

• Yaklaşık $103 tutarındaki bir fatura bile sorun olarak görülüyor. Özellikle ücretsiz katman kullanılırken aniden fatura çıkması önemli bir endişe kaynağı

#11 Cloudflare, AWS ve diğer sorunlar

• Cloudflare tarafında 24 saat içinde $120,000 ödenmesi istenerek hizmetin durdurulduğu bir vaka da bulunuyor
• AWS S3'te boş ve private bucket oluşturulduktan sonra bile beklenmedik ücretlendirme yaşandı
• Netlify'dan $104,500 tutarında ödenmemiş fatura alınması gibi, benzer vakalar farklı sağlayıcılarda da tekrarlanıyor

#12 DoS saldırısı, e-posta ve veri kaybı

• DoS saldırısı sırasında e-posta gönderimi yüzünden $11,000 harcandı, ardından veritabanı da kaybedildi

#13 Vercel'de toplu ücretlendirme, hesap ve trial sorunları

• Vercel'de spam saldırısı nedeniyle bir gün içinde $23,000 fatura oluştu; 56,000 hesap ve trial etkinleştirildi

#14 Test/deploy sürecinde beklenmedik ücretlendirme

• Test amacıyla Vercel gibi platformlara özellik deploy edilirken beklenmedik tutarlar yansıtıldı
• sitemap.txt yüzlerce GB bant genişliği tüketerek yüksek faturaya yol açtı

#15 Firebase, Cloud Run test maliyeti

• Firebase ve Cloud Run üzerinde yalnızca iki test ile $72,000 harcandı ve hizmet iflas riskiyle karşı karşıya kaldı

Sonuç ve çıkarımlar

• Serverless ve bulut ortamlarındaki maliyet yapısı şeffaf değil ya da saldırı ve hatalara karşı son derece kırılgan olabiliyor
• Çok sayıda beklenmedik fatura vakası raporlanırken, hizmet işletirken dikkatli izleme, kullanım yönetimi ve limit tanımları zorunlu hale geliyor
• Otomasyon ve izleme özellikleri yetersiz olduğunda, basit bir test ya da tek bir dış saldırı bile on binlerce dolarlık beklenmedik kayıplara yol açabiliyor
• Geliştiriciler, startup'lar ve diğer SaaS kullanıcıları için maliyet yönetimi ve risk farkındalığı giderek daha önemli hale geliyor

[ahwjdekf]

Büyük bir şirketin kurum içi DW’si için geliştirme yapmıştım; mevcut on-premise verileri AWS’ye taşıma işiydi. Ancak aylar süren geliştirme ve testler tamamlanmış olmasına rağmen sonunda proje iptal edildi. Gerekçe, her ay tahsil edilecek ücretin beklenenden çok daha yüksek görünmesiydi. Büyük şirketler için bile bulut harcamalarını karşılamak kolay değil.

[regentag]

Ben de AWS çalışmak amacıyla hesap açmıştım ama küçük bir tutar da olsa ücretlendirilmiştim.
Hesabım ele geçirilmişti ve biri benim hesabımla instance oluşturup çalıştırmıştı... Hızlıca durdurduğum için olay küçük bir tutarla kapandı.
Yönetime zaman ayıramadığım için çözüm olarak hesabı tamamen kapatmayı seçtim.

[ifmkl]

Bence buluta başlamadan önce, son zamanlarda çokça gündeme gelen n100, n150 sınıfında bir mini sunucu ortamı kurup test ya da operasyon deneyimini biraz biriktirmenizi tavsiye etmek isterim.

[crawler]

Çok küçük bir proje olsa bile, bir kez platforma yüklenince bir güvenlik açığı olduğunda bunun maddi kayba yol açabilmesi gerçekten çok korkutucu görünüyor.

İçeriğimin önüne Cloudflare koymuştum ama bir hacker önbelleğe alınmamış nesneleri bulup 100 milyondan fazla istek gönderdi. Ben engelleyince bu kez doğrudan origin bucket adresini bulup saldırdı.

Böyle durumlarda da maliyeti iade edip etmediklerini merak ediyorum.

[GN⁺]

Hacker News görüşü

• Bootcamp'te programlamayı öğrenirken ücretsiz bir Elastic Beanstalk instance'ı oluşturmayı denedim. Kimlik doğrulaması için kredi kartı gerekiyordu ve o zaman bunun sorun yaratacağını düşünmemiştim. Ama sonrasında sunucum bot spam saldırısına uğradı ve Amazon bana 100.000 dolar fatura çıkardı. Sonunda geri ödeme aldım ama o günden beri Amazon'dan nefret ediyorum ve bulut bilişim kullanmam gerekirse başka bir hizmet kullanacağıma söz verdim. Karmaşık panoları ve müşterilerin kafasını karıştırıp para kaybetmelerine yol açan yapıyı hiç sevmedim. Kredi kartını sadece doğrulama aracı olarak kullanıp botları engelleseler yeterdi. Bunu markette kredi kartıyla basitçe kurabiye satın alabilmeye benzetince, finans teknolojisinin gerçekten faydalı biçimde kullanılabileceği halde kullanılmadığını düşünüyorum
  • Bulut barındırmanın korkutucu olmasının sebeplerinden biri bu. Sadece Amazon değil, Azure ya da Google Cloud da "genelde" geri ödeme yapıyor. Ama haftada 5 ziyaretçisi olan demo projem bir anda DDoS yerse ve bu kez barındırma şirketi bunun "genelde" olmayan bir durum olduğunu söyleyip havale isterse, iflasın eşiğine gelebilirim
  • Şu anda 25.000 dolarlık bir ücret yansımış durumda. Eskiden SQS'nin data plane denetimini açmıştım ve yanlışlıkla gerçek zamanlı denetim olay akışını bağlamıştım. Sonuç olarak, her saf denetim olayı için sonsuz döngü gibi kayıt olayları üretildi. Yaklaşık 10 yıl boyunca günde ortalama 2 dolar ödeyen hesap bir gün ansızın günde 3.000 dolar yazmaya başladı ve AWS'den hiçbir uyarı ya da müdahale gelmedi
  • Amazon 100.000 doları iade ettiyse neden onlardan nefret ettiğini merak ediyorum. Benim durumumda AWS, tamamen benim hatam olan pahalı faturaları bile her zaman geri ödedi. Eğer "bütçeyi aşınca her şeyi kapat" gibi bir politika olsaydı, bu sefer de "DDoS yedim, AWS bütün EC2'leri kapattı ve geçici depoda tuttuğum veriyi de sildi" tarzı başka trajediler duyardık
  • "Bu, tek satırlık bir if ile hesap limitini aşınca instance'ları kapatıp hizmeti statik sürücüye dökerek çözülebilecek kadar kolay bir iş. Onlar sadece istemedi; ölçeği müşteriler üzerinden kârı maksimize etmek için kullanmak istiyorlar. Bulut bilişimle herkesi zor durumda bırakanlar şimdi de pazar hakimiyetinden güç alarak yapay zeka maliyetlerinden ekonomik kazanç sağlamaya çalışıyor. Bugün edge compute'un kolaylaşmasının sebebi, kripto yüzünden insanların disk kapasitesine aşırı yatırım yapmış olması. Sonunda piyasa balonları ve kötü davranışları teşvik ediyor; güven inşa etmek yerine gücüyle piyasayı suistimal edenlerin kolayca cirit attığı bir yapı ortaya çıkıyor. 'Sen bunu anlamıyorsun sadece! (bu arada piyasa çökmeden önce biraz daha para ver)' gibi kurnaz bir tavır takınan zeki kötüler sektörün en büyük belası. Taksi şirketleri de seni varış noktasına götürmedikleri için 1.000 dolar kesmiyor. Sunucuya bir if koyamıyoruz demek ne kadar mantıklı? Amazon taksi şirketinden de mi kötü? Belki de öyledir. Zaten 'Waymo'nun başlamasının sebebi de bu' (şaka olabilir)"
• Barındırma/geliştirme/debug süreçlerinde serverless acılarından bahsedeceğini sanmıştım ama konu fiyat patlaması çıktı. Açıkçası bant genişliği maliyetleri bana hiç bu kadar gerçek gelmediği için çoğu yazıyı hızlıca geçiyorum, ama bu ilginçti — boş bir S3 bucket'ının AWS faturasını patlatabildiği bir durum: başkasının S3'üne kimlik doğrulamasız API çağrıları yaparak faturayı karşı tarafa yıkabiliyorsun. Benim için yeniydi
  • Bu konuda blog yazısı gündem olduktan hemen sonra önlem alındığını sanıyorum: Amazon S3, bazı hata kodları için ücretlendirmeyi durdurdu
  • Serverless ortamların asıl problemlerinden biri, platformun kendisinin kara kutu gibi opak olması (ki bu aynı zamanda serverless'ın değer önerisi). Büyük bir Lambda backend'ini devraldık ve gizli uzantıya bağlanırken oluşan aralıklı socket kopmaları gibi platform içi sorunlar yaşandığında iz sürmek inanılmaz zordu. Yerel test ortamının gerçek dağıtım ortamından çok farklı olması da ayrı bir dert. Google Cloud Functions'ı evde oyuncak gibi kullanmak güzel çalışıyor ama gerçek projede HTTP sunucusu/kuyruk tüketicisini doğrudan ECS gibi container'lara koymayı tercih ederim
  • "Diyelim ki sevdiğim bir bölgede boş bir private S3 bucket oluşturdum. Sonra popüler açık kaynak araçlardan birinin varsayılan olarak yedeklerini S3'e yazdığını ve placeholder olarak benim bucket'ımla aynı adı kullandığını fark ettim" deniyor; bunun gerçekte ne kadar sık yaşandığını merak ediyorum — isim çakışmaları pratikte ne kadar yaygın, emin değilim
  • Bunun rakipleri saf dışı bırakmak için kullanılabileceğini düşünmek bile mümkün. AWS'yi pek sevmememin sebeplerinden biri de bu. Küçük müşterileri sürpriz faturalardan korumaya yönelik hiçbir çaba yok. Azure da çok daha iyi değil ama en azından biraz koruma mekanizması var
  • Ben de serverless, Lambda ve DynamoDB ile her şeye bağlanıp aslında 20 dolarlık bir VPS üzerinde sqlite ile çözülebilecek bir işi gereksiz yere şişiren bir bulut kilidi hikâyesi bekliyordum, o çıkmadı
• Serverless'taki gerçek acı, tek bir olay yüzünden dev bir fatura gelmesi değil; faturanın her ay azar azar şişmesi. Kaynakları çok kolay oluşturup öylece bırakabiliyorsun. Birkaç ayda bir birkaç bin dolar daha ekleniyor, COO fark edince bütün şirket alarm durumuna geçip faturayı 10.000 doların altına indirmeye çalışıyor. Sonra aynı döngü tekrar ediyor. Yıllara yayılınca, tek seferde para yakmaktan daha büyük bir israf oluyor
  • Bu aslında AWS'nin iş modeli. Buna hiç "Planet Fitness modeli" dendiğini duydun mu? Kayıt olmak ya da para harcamak aşırı kolay, ama ödemeyi kapatmak aşırı zahmetli
  • Organizasyonların bu pahalı fatura dönemlerinden hiç ders çıkarmıyor gibi görünmesi ilginç. Faturanın sürekli artmasına neyin sebep olduğunu ve bunun önceden nasıl engellenebileceğini gerçekten merak ediyorum
  • Bu sorun on-prem tarafında da sık olur. Kullanılmayan bir uygulamayı çalıştırmaya devam eden sunucuların (genelde VM'lerin) olduğu durumlar çıkıyor. Elbette VM maliyeti de sıfır değil
• Sorumluluğun nerede başladığı çoğu zaman belirsiz. Müşteriler, donanım altyapısını tek tıkla dağıtabildikleri sihirli ve sürtünmesiz araçlar istiyor. Deneyimsiz bir kullanıcı yanlış yapılandırıp dev bir fatura çıkarırsa ve bulut sağlayıcısı bunu aynen tahsil ederse itibarı zarar görüyor; ama kullanıcıları önceden eleyip kısıtlarsa da startup denemek isteyen küçük geliştiricilere kapıyı kapatmış oluyor. Böyle bir durumda aniden 10.000 dolarlık fatura geldiğinde kimin ne kadar ödemesi gerektiğini, yanlışlıkla oluşan maliyetin ne kadarından kimin sorumlu olduğunu felsefi olarak hep merak etmişimdir. Kodum kaynakları 10 kat daha verimsiz kullansa bile, "yanlış yapılandırdıysan suç sende" mi demeliyiz? Ya da kullandığım bulutun AWS gibi dev bir oyuncu mu yoksa küçük bir startup API hizmeti mi olduğu müşterinin hiç umursamaması gereken bir şey mi olmalı, emin değilim
  • Bütçe aşımı/devre kesici (harcama tavanı) gibi sistemler olsa nasıl olurdu? Çözülemez bir problem gibi görünmüyor
  • Cevap aslında basit: bütçe sınırı koymak
  • Zaten bu da gerçek sunucuları, yani serverless olmayan sunucuları kullanma sebeplerinden biri
• Hetzner'de aylık 70 dolara 16TBx2 HDD, 1TBx2 SSD, 64GB RAM ve 20TB ücretsiz trafik alabiliyorsun. Buna karşılık AWS micro instance'ta 1TB trafik kullandığımda 150 dolar ödemiştim diye hatırlıyorum. Buna hiç gerek yok
• "İçeriğimin önüne Cloudflare koydum ama bir saldırgan cache'lenmeyen nesneleri bulup 100 milyondan fazla istek attı. Ben engelleyince bu kez origin bucket adresini doğrudan bulup saldırdı" hikâyesi için, bunun herkesin başına gelebilecek bir şey olup olmadığını merak ediyorum. Cache'lenmeyen nesnenin sızması, 22 numaralı portu zayıf parolayla açık bırakmak kadar ciddi bir hata mı emin değilim; sonuçta S3 kaynaklarını (özellikle görselleri) herkesin istediği kadar erişebileceği şekilde sunmak yaygın değil mi?
  • Kesinlikle değil. S3 bucket mutlaka private olmalı ve güvenlik kuralları yalnızca CDN üzerinden erişime izin verecek şekilde ayarlanmalı. Böylece trafiğin zorunlu olarak CDN'den geçmesi sağlanır
  • Bu bana OWASP Top 10 zafiyetlerini açık bırakmakla övünmek gibi geliyor. Erişim kontrolünü doğru ayarlamak sanıldığı kadar zor değil; böyle temel bir konuda hata yapan birinin başka yerlerde de kestirmeden gitme ihtimali yüksek. Böyle birinin sorumlu olduğu sisteme güvenmem
  • En temel uygulama, S3 nesnelerini private tutup önüne en azından bir CloudFront proxy koymaktır. Özellikle görsellerin mutlaka cache üzerinden servis edilmesi gerekir
• Buna serverless demek bile garip, çünkü pratikte hâlâ bulut altyapısında sunucu çalıştırıyorsun. Temelde yazılımı yine istemci-sunucu modeline göre yazıyor ve kullanıcıların kullanabilmesi için bir yerde sunucu çalıştırıyor oluyorsun. Bana göre gerçek anlamda 'serverless', kullanıcının yazılımı bir kez indirip sonrasında internete ihtiyaç duymadan kullanabildiği yapıdır. Ya da sunucuya veri gönderse bile, geliştiricinin belirlediği tek bir yere bağımlı olmadan çalışabiliyorsa buna serverless denebilir
  • 'Serverless' terimi özünde, yüke göre kaynakların (sunucuların) otomatik olarak artıp azaldığı bir yönetim sistemini anlatır; esas nokta budur. Yük artarsa sunucular artar, düşerse azalır. Ancak tüm kod yapısını bu ortama verimli çalışacak şekilde dönüştürebildiğinde serverless gerçekten değer üretir. Yani gerçekten gerektiğinde kullanılacak bir mimaridir
  • Genelde buna 'yerel' yazılım denir. 'Serverless' çok iyi bir isim değil ama aslında belirli bir backend dağıtım modelinden söz ediyor. Backend'i hiç olmayan bir uygulama anlamına gelmiyor
  • 'Serverless', sanki "çalışanı olmayan şirket" gibi. Aslında hizmeti veren insanlar var ama hepsi taşeron
  • 'Sunucu' dediğimiz şey genelde belirli bir OS ve birçok yazılım katmanının (izleme araçları dahil) üzerinde çalıştığı, kullanıcının iş mantığına erişmesini sağlayan tekil bir makinedir. Kendi sunucun varsa OS seçimi, destek yazılımlarının kurulumu/güncellenmesi ve arıza halinde toparlama gibi her şeyi düşünmek zorundasın. Serverless ise 'function as a service' modelidir; yalnızca iş mantığınla, yani kendi kodunla ilgilenirsin. Sunucuya OS kurman gerekmez, http sunucusu gibi temel yazılımları da düşünmezsin. Güncelleme ve bakım işlerini de yapman gerekmez. Kodu yüklersin, çağrıldığında çalışır. Sunucu işletme stresinden tamamen kurtulma fikri budur. Bu yüzden adına 'serverless' deniyor — gerçekte sunucular var ama onları senin işletmen gerekmiyor
• "Serverless" aslında sunucuların olmadığı değil, sunucuları senin yönetmen gerekmediği ve kodunun hangi sunucuda çalıştığını bilmek zorunda olmadığın anlamına geliyor. Daha çok "Sana biraz kod vereceğim, bunu her saat başı çalıştır; nerede çalıştığıyla ilgilenmiyorum" gibi
  • Bu kelime rahatsız edici gelebilir ama dilbilim açısından Orwellci bir sorun sayılmaz. 1984teki Newspeak, ifade çeşitliliğini azaltmaya dönüktü; 'serverless' ise tersine yeni bir kategoriyi tarif etmek için üretilmiş yeni bir kelime. Elbette sunucuların varlığını perdeleyen bir ifade olabilir ama buna tam olarak Orwellci demek doğru olmayabilir. Belki 'servelet' gibi, "hafif sunucu"yu çağrıştıran bir ad daha iyi olurdu
  • "Cloud diye bir şey yok, sadece başkasının bilgisayarı var" tarzı alaycı ifade de epey yaygın
  • 'Serverless' sonuçta eski 'shared hosting'in "%10.000 kâr marjı" ve "istek başına fiyatlandırma" eklenmiş tech-bro versiyonu gibi hissettiriyor
  • "No-code" sistemler de sonuçta kodla çalışıyor. PaaS ya da her neyse, ortada sonuçta sunucu var diye öfkelenmek biraz bahane aramak gibi
• AWS serverless kullandım; yerel test pratikte imkânsızdı ve serverless run için mutlaka AWS IAM role kullanmak gerektiğinden hesap genelinde geniş yetkiler açılmış oluyordu. Sonuçta neredeyse her seferinde doğrudan prod ortamında test yapıyormuşsun gibi büyük bir sorun ortaya çıkıyor
  • Ben de birkaç yıl serverless projelerde çalıştım ve yerelde neredeyse hiçbir şeyi çalıştıramamak gerçekten büyük bir maliyetti. Debug süreleri de korkunç uzuyordu. Alternatif diye çıkan araçlar da gerçek projelerde neredeyse işe yaramıyor
  • ~/.aws/credentials dosyasını düzgün ayarlarsan AWS security key ile yerelde test yapabilirsin. Makefile ile Lambda dağıtımını otomatikleştiriyor, her Lambda için özel IAM role oluşturup güvenlik gereksinimlerini JSON dosyalarıyla yönetiyoruz. AWS'nin asıl güçlü yanı, her şeyin aynı API üzerinden yönetilebilmesi. Her şeyi programatik olarak oluşturup yönetebilirsin
  • 1. Her şeyi stack'e bağlayıp geliştiriciye ait ayrı bir hesaba dağıtmak (ücretsiz staging ortamı), 2) resmî destekli Docker runtime ile yerelde test etmek, 3) her zamanki gibi unit test yazmak, 4) localstack gibi araçlarla makinede staging ortamını birebir taklit etmek — seçenek çok fazla, bu kadar kötü bir deneyimin nasıl yaşanabildiğini anlamıyorum
  • Gerçeklerle pek örtüşmeyen bir iddia
• Bence 'serverless' her hâlükârda sunucu tabanlı sistemleri farklı bir ambalajla satan Orwellci bir isimlendirme
• Bu şirketlerin 1TB bant genişliği için 550 dolar istemesine inanamıyorum. Garantili 10Gb/s porta sahip bir sunucu kiralasan bile TB başına 3 doların üstü bana soygun gibi geliyor. Serverless'ın bu maliyeti nasıl 150 kat haklı gösterebildiğini anlamıyorum. İnsanlar buna gerçekten para veriyor mu? 10 dolarlık bir VPS ya da GitHub Pages üzerinde bile okuma amaçlı wiki/teknik dokümantasyon/blog gibi işler sorunsuz yürür; biraz düzgün kurulumla aynı anda 10.000 kullanıcıyı bile rahat taşır

[benjamin]

Artık geliştirmeye yeni başlayan insanların yapay zeka aracılığıyla bir şeyler üretirken çoğunun Vercel, Supabase gibi şeylerle servis sunduğunu söyleyemez miyiz?

Ama hizmet büyümeye başladığında bunlara ödemek zorunda kalacakları bedeli pek hesaplamıyor gibiler.
Bunu da o zaman düşünürüz diyerek geçiştiriyorlar.

Vercel ya da Supabase’in kurucuları da sanki “Aynen aynen, onu zamanı gelince düşünseniz yeter!” diye kocaman gülümseyerek buna eşlik edecekmiş gibi.

Elbette bunu o zaman da düşünebilirsiniz. Eğer hızlıca çıkabilecek beceriniz varsa.
Ama bilgisayar bilimi bilgisi olmadan bu kolay olmayacaktır.
Yeni yeni kazanmaya başladığınız parayı onlara tamamen kaptırma durumuna düşebilirsiniz.

Aslında şu anda olan tam da bu.
Yani… bilgisayar biliminden hiç anlamadan işe giren acemilerin parasını alan büyük bir iş modeli açılıyor.

Bilgisayar bilimine derinlemesine inmeyi sürdürmemiz gerekmesinin nedeni burada.
Kimi insanlar ancak gelir getirmeye başlamış bir hizmet için ayda 1 milyon won harcarken, kimi insanlar hiç para ödemeden hizmet işletiyor.
İşletme maliyetini düşürmek de bir beceridir. Bu muazzam bir rekabet avantajı değil mi?
Yapay zeka ile kod yazarak bir şeyler üretmek ve bundan keyif almak güzel, ama daha derine inmeye çalışmazsanız sonunda fark yaratamazsınız.

https://jeho.page/essay/2025/09/08/sucker-developer.html