Yapay zekayla kod yazmak artık gündelik bir iş oldu. Hatta bazen fazla gündelik. Ama konu JavaScript, — ki bu tartışılır — özellikle de Node.js olunca, modelin önünüze koyduğu ilk taslak çoğu zaman “çalışır” gibi duruyor; sonra arka planda sessizce bir sürü risk bırakıyor, eski paketler, gevşek bağımlılık yaklaşımı, yanlış modül seçimi… Hani şu “sonra bakarız” denilen şeyler var ya, işte tam orada patlıyor.
Geçen ay Kadikoy’de bir startup ekibiyle yaptığım sohbette bunu yine gördüm. Ekip ChatGPT’den alınmış bir Express örneğini kullanmıştı; kod fena değildi ama CommonJS üstünden gidiyordu, paket seçimi eskiydi. Güvenlik taraması gereksiz birkaç bağımlılığı işaret etti. Küçük bir prototip için idare ederdi belki ama production ortamında? Açık konuşayım, pek iç acıcı değildi.
Durun, bir saniye.
Bir şey dikkatimi çekti: Isin aslı şu ki: yapay zeka size “ortalama internet”i getiriyor. Ortalama da güvenli demek değil. Hele Node.js ekosisteminde hiç değil (yanlış duymadınız)
Neden Yapay Zeka Ortalamayı Sever?
Modelin doğası bu. Internette en çok görülen desenleri öne çıkarıyor; güncel olanı değil, yaygın olanı seviyor. Bu yüzden eski bloglardan sızmış CommonJS örnekleri, yıllardır güncellenmeyen kutuphaneler veya “her yerde kullanılıyor diye iyi sanılan” paketler karşınıza çıkabiliyor.
Garip gelecek ama, 2024 sonbaharında İzmir’de kendi test ortamımda bunu bilerek denedim. “Basit bir API yaz” dedim; gelen cevapta güzel fikirler vardı ama yarısı fazladan bağımlılıkla doluydu. Bir yandan da built-in Node API’lerini atlamıştı. Yani kağıt üstünde süper görünen ama pratikte biraz şişkin duran bir çözüm çıktı ortaya… böyle şeylerde insanın kaşı kalkıyor ister istemez (yanlış duymadınız)
Açıkçası, Node.js tarafında risk büyüyor çünkü npm dünyası hızlı dönüyor. Bir paket bugün temiz görünürken altındaki zincirde yarın sorun çıkabiliyor (ciddiyim). AI ise bu farkı her zaman hissetmiyor; çünkü onun gözünde tarih yok, sadece olasılık var.
AI ile kod üretmek hız kazandırır; ama kuralsız kullanılırsa güvenlik borcunu daha ilk günden büyütür.
Sert Kurallar Neden Sart?
Bakın şimdi, burada mesele AI’yi yasaklamak değil. Tam tersine, doğru çerçeveyi kurarsanız bayağı verimli oluyor. Ama çerçeve yoksa model sizi geçmişten gelen alışkanlıklara çekiyor ve siz fark etmeden teknik borcu büyütüyorsunuz.
Küçük bir detay: Ben bunu ilk kez 2023’te Berlin’de küçük bir SaaS projesinde net gördüm. Ekip çok hızlı ilerliyordu, AI destekli kodlama da bayağı iş görüyordu; fakat runtime sürümü, test standardı ve dependency politikası net olmayınca aynı özellik üç farklı tarzda yazılmıştı. Sonuç? Bakımı zorlaştı, güvenlik incelemesi uzadı ve release günü tatsız geçti… maalesef. Hyundai IONIQ 6 N, yılın performans otomobili oldu: İşte perde arkası yazımızda bu konuya da değinmiştik.
Sert kuralların amacı modeli boğmak değil; onu rayda tutmak. Tıpkı trafik ışığı gibi düşünün: ışık olmazsa akış var gibi görünür. Kavşağın ortasında saçma sapan bir karmaşa başlar. Bu konuyla ilgili Bilibili Akışı Nasıl Çözülür: DASH ve FFmpeg Sırrı yazımıza da göz atmanızı tavsiye ederim.
Node.js Projesinde Neleri Sabitlemelisiniz?
1) Runtime sürümü
Önce bunu netleştirin: hangi Node sürümü? Eğer proje ESM-first ise ve siz hala belirsiz bırakırsanız model her seferinde başka tarafa kayabilir. Ben genelde ekip toplantısında ilk soruyu buradan açıyorum çünkü en sessiz hata burada başlıyor.
Peki, garip gelecek ama, Küçük ekiplerde bile bu karar önemli; enterprise tarafta ise şart gibi düşünün. Çünkü sürüm sabit değilse test sonuçları da kayar, deploy davranışı da değişir.
2) Modul sistemi
Şöyle söyleyeyim, CommonJS mi ESM mi? İkisini aynı projede harmanlamak bazen mecburiyet olur — AI’nın bunu gelişigüzel yapmasına izin vermeyin. Hele bir de yeni projelerde modern yaklaşımı seçip buna sadık kalmak daha temiz sonuç veriyor.
Birkaç hafta önce Ankara’da inceleme yaptığım bir backend taslağında model require() ile import’u yan yana koymuştu… çalışıyordu evet ama düzen hissi yoktu. Bir projede düzen hissi yoksa sonra güven de zedeleniyor. Bu konuyla ilgili Discord Botu ile Rakip Paylaşımlarını Anında Yakala yazımıza da göz atmanızı tavsiye ederim.
3) TypeScript beklentisi
Eğer TypeScript kullanıyorsanız bunu açıkça söyleyin; yoksa model bazen tipleri yarım bırakıyor ya da büyük ölçüde JS’e kaçıyor. Bu da özellikle ekip büyüdükçe can sıkıyor çünkü tip güvenliği yarım kalınca hata ayıklama maliyeti artıyor.
| Kural Alanı | Zayıf Yaklaşım | Daha Sağlam Yaklaşım |
|---|---|---|
| Runtime | Sürümsüz bırakmak | Paket içinde sabitlemek |
| Modül sistemi | CJS/ESM karışık kullanım | Açık tek tercih belirtmek |
| Bağımlılıklar | Maksimum paket kullanımı | Nativeleri önce değerlendirmek |
| Testler | Tatlı tatlı ertelemek | Zorunlu kabul etmek |
| Güvenlik | “Sonra bakarız” | SCA + lint + audit zorunlu yapmak |
Paket Secimi Konusunda Acimasiz Olun
Neyse uzatmayalım: npm’de her parlak paket iyi paket değildir (inanın bana). Bazıları sadece popülerdir, o kadar. Yapay zekadan gelen önerilerde özellikle şuna dikkat ediyorum — gerçekten lazım mı? Yoksa Node’un kendi API’siyle halledilir mi?
Birkaç ay önce Bursa’daki bir e-ticaret takımında tam bunu konuştuk. Model dosya okuma için üçüncü parti paket önermişti. Yerleşik fs/promises ile işi tertemiz çözdük (hem daha az saldırı yüzeyi hem daha az bakım) (buna dikkat edin). İşte burada “built-in first” kuralı devreye giriyor; güzel özellik ama biraz ham kalmış paketi almak yerine yerel araçları kullanmak çoğu zaman daha mantıklı oluyor.
- Mümkünse önce Node’un kendi API’lerini deneyin.
- Zorunlu olmadıkça yeni bağımlılık eklemeyin.
- Paket ekliyorsanız bakım durumu ve yayın sıklığını kontrol edin.
- Transitive dependency sayısını küçültmeye çalışın.
- Sadece çalışan değil, uzun ömürlü çözüm isteyin. — ciddi fark yaratıyor
Kural-Oncelikli Prompt Nasıl Yazılır?
Bence asıl oyun burada başlıyor. Modelden ne istediğiniz kadar nasıl istediğiniz de önemli.
Bir prompt’a “backend oluştur” yazıp geçerseniz size genel-geçer bir örnek verir.
Ama aynı işi kurallarla isterseniz bambaşka sonuç alırsınız.
Aynı araba — bence çok yerinde bir karar —. farklı direksiyon yani.
İşin püf noktası bu:
Modern Node.js projesi oluştur:
- Node.js 22.x kullan
- ESM tercih et
- TypeScript zorunlu olsun
- Yerleşik API'leri önce değerlendir
- Yeni dependency eklemeden önce gerekçesini yaz
- Test olmadan kodu tamamlanmış sayma
- Güvenlik odaklı varsayılanlar uygula
- Outdated package önerme
- Production-ready yapı hedefle
Böyle yazınca model de biraz hizaya geliyor tabi… Peki bunu neden söylüyorum? hemen mucize olmuyor ama yön değiştiriyor.
Bu arada benzer yaklaşımı Claude Code ayarlarını sabit tutmaya çalışırken de kullandım; makineler arasında kaybolan kurallar meselesini çözmek için prompt kadar konfigürasyonun da net olması gerekiyor.Claude Code Ayarları Makinenizle Birlikte Kaybolmasın: (evet, doğru duydunuz)
Çok konuştum, örnekle göstereyim.
.cursorrules veya custom instructions mantığı işe yarar mı?
Evet, hem de bayağı işe yarar! Bilhassa ekip içinde aynı standartları korumak istiyorsanız tek seferlik prompt yerine kalıcı talimat seti çok daha sağlam duruyor.
Ben geçen yıl Sisli’deki küçük bir ürün ekibinde buna benzer bir yapı gördüm; herkes aynı kuralları kullandığında code review süresi bile kısaldı.
Kısacası mesele süslü prompt değil… tutarlı disiplin.
Biraz sıkıcı mı? Evet.
Ama faydalı mı? Kesinlikle.
Bu konuda yapay zeka kodlamanın neden adım adım kazandığını anlatan yaklaşım da aynı yere çıkıyor:Yapay Zeka Kodlamada Neden Adım Adım Kazaniyor?: YouTube Premium’da Gizli Hız Deneyi: Auto Speed Geliyor yazımızda da bu konuya değinmiştik.
Küçük Startup ile Kurumsal Takim Ayni Değil!
Küçük startup’ta öncelik hızdır; anladım.
Ama enterprise seviyede hız tek başına yetmez.
Bir bankacılık entegrasyonu ya da sağlık verisi taşıyan servis düşünün…
orada güvenlik testi yapılmadan geçen her satır ileride masraf olarak geri dönüyor.
Startup tarafında basit kural seti yeter:
sabit runtime,
tek modul sistemi,
minimum dependency,
zorunlu test.
Kurumsalda ise bunlara SBOM takibi, policy enforcement ve otomatik security gate eklenmeli.
Aksi halde AI size hız verirken siz içeriden delinirsiniz.
Bir ürün yöneticisinin bana geçen mart ayında Levent’te söylediği şeyi unutmadım:
“Kod hızlı çıktı ama denetimde yavaşladık.”
Tam olarak mesele bu işte.”
Tasarimi Dusunmeden Kodu Kabul Etmeyin
Ana ders şu:
AI’nın verdiği kodu teslim edilmiş iş gibi görmeyin;
ilk taslak gibi görün.
Bunu kafaya koyunca süreç rahatlıyor çünkü beklenti düzeliyor.
Kod güzel olabilir…
ama mimari uyumlu mu?
güvenli mi?
bakımı kolay mı?
Asıl sorular bunlar.
Hatta bazen bilerek geri çekilip yeniden soruyorum:
“Bu çözüm native API ile yapılabilir mi?”
“Bu dependency gerçekten gerekli mi?”
“Test senaryosu nerede?”
Bu üç soru çoğu kötü öneriyi elemek için yetiyor.
Ha bu arada…
bir şey daha söyleyeyim:
AI’ın sunduğu cevabı körlemesine kabul etmeyen ekipler genelde daha az kriz yaşıyor.
Sade gerçek bu.”
Sıkça Sorulan Sorular
A I üretilmiş JavaScript kodu neden riskli olabilir?
Cünkü model eski desenlere ve yaygın örneklere yaslanabiliyor.
Bu da outdated package seçimi veya gereksiz bağımlılık anlamına gelebiliyor.
Mesela üretim ortamında bu ciddi problem yaratır.
NNode.js projelerinde hangi kuralları baştan koymalıyım?
İlk olarak runtime sürümü, modül sistemi (ESM/CJS), TypeScript zorunluluğu ve dependency politikası belirleyin.
Buna test standardını ve security audit sürecini de ekleyin.
Builtin API’leri neden önce düşünmeliyim?
Cünkü yerleşik API’ler genelde daha az saldırı yüzeyi sunar ve ekstra bakım yükü çıkarmaz.
Basit işleri üçüncü parti pakete taşımak çoğu zaman gereksiz risk yaratır.
Kurumlar için AI coding workflow’da en kritik konu nedir?
Tutarlılık ve denetlenebilirlik.
Yani model ne üretirse üretsin sizin standartlarınıza uymalı;
aksi halde hız kazanırken kontrol kaybedersiniz.
Kaynaklar ve İleri Okuma
Node.js Resmi Sitesi ve Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
