Geçen yaz, Kadıköy’de bir kafede otururken önümde açık duran not defterime şunu yazmıştım: “AI entegrasyonu = zor iş.” Hani insan bazen bir konuyu gözünde büyütür ya… işte tam öyleydi. Sonra bir akşam, sırf meraktan, küçük bir demo projede AI çağrısı denedim. Iki saat sonra çalışan bir özellik elimdeydi. Açık konuşayım, beklediğim kadar karmaşık çıkmadı.
Burada kritik nokta şu: çoğu geliştirici “AI eklemek” deyince sanki model eğitmekten, GPU kümesine bağlanmaktan, matris çarpıp sabaha kadar loss izlemekten bahsediyoruz sanıyor (şaşırtıcı ama gerçek). Oysa günlük işlerin büyük kısmında yaptığınız şey çok daha sade — bir API’ye istek atıyorsunuz, metin gönderiyorsunuz, cevap alıyorsunuz. Hepsi bu. Ama dur bir saniye, bu kadar basit demek de biraz haksızlık aslında; doğru kurgu yapmazsanız maliyet patlıyor, güvenlik açıkları çıkıyor, ürün saçmalamaya başlıyor.
Bu yazıda Devraj Singh’in fikrinden ilham alıp konuyu kendi yerli yerine oturtacağım: AI’yi sıfırdan nasıl “büyülü” değil de kullanışlı hale getirirsiniz? Neleri abartmamak lazım? Küçük startup ile kurumsal ekip aynı yolu mu izlemeli? Gel gelelim pratik tarafa…
Önce Şu Yanılgıyı Kaldıralım: AI Eklemek Ne Demek?
Bak şimdi. En büyük karışıklık şu: “AI geliştirmek” ile “AI entegrasyonu yapmak” aynı şey değil. Birincisi araştırma işi, ikincisi ürün işi (kendi tecrübem). Ürün tarafında siz modelin beynini inşa etmiyorsunuz — o beyne soru soruyorsunuz. Bu ayrım önemli. Çoğu kişi tam da kapının önünde takılıp kalıyor; oysa içeride gayet tanıdık web geliştirme alışkanlıkları var, yabancı bir şey yok.
2023 sonbaharında Beşiktaş’ta çalışan küçük bir SaaS ekibiyle konuşmuştum. Takımdan biri “biz buna giremeyiz” diyordu çünkü (belki yanılıyorum ama) ML bilgileri yokmuş. Sonra beraber basit bir özetleme özelliği kurduk; asıl zor kısım prompt tasarımı değil, kullanıcı verisini doğru biçimde parçalamaktı. Yani mesele bazen algoritma değil, veri düzeni oluyor. Peki bunu neden söylüyorum? Şaşırdım açıkçası.
Kısa bir not düşeyim buraya.
E tabi bunun parlak olmayan tarafı da var. API çağrıları ucuz görünür ama kullanım arttıkça fatura büyür. Bir de modeli fazla özgür bırakırsanız halüsinasyon başlıyor — sistem kendinden emin bir tavırla yanlış konuşuyor. Baya sinir bozucu, inanın.
AI eklemek çoğu zaman yeni bir bilim dalı öğrenmek değil; mevcut ürüne dışarıdan akıllı görünen ama kontrollü çalışan bir servis bağlamak demek.
İki Saatlik Kurulumun Mantığı
Şimdi gelelim asıl işe. İlk kez denediğimde şunu fark ettim: kurulumu üç parçaya ayırınca korku azalıyor. Birinci parça API anahtarı almak (ben de ilk duyduğumda şaşırmıştım). İkinci parça istemci ya da sunucu tarafında SDK kurmak. Üçüncüsü ise — ve bu aslında en eğlenceli kısım — kullanıcı girdisini düzgünce yollayıp cevabı ekrana basmak.
Hani, İstanbul’da masaüstü başında bunu test ederken güldüm doğrusu. İnsanlar “AI projesi” deyince devasa mimari bekliyor; oysa kodun büyük bölümü normal HTTP akışı gibi çalışıyor. Hava durumu API’sine istek atmakla neredeyse aynı his — sadece dönen metnin tonu biraz daha havalı. Daha fazla bilgi için 2026’da Kod Asistanı Seçimi: Tek Araç Değil, Set yazımıza bakabilirsiniz. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili Express.js Güvenlik Testinde Dört Araç Birbirini Nasıl Doğruladı? yazımıza da göz atmanızı tavsiye ederim.
Ha, bu arada küçük ama önemli bir not: üretimde doğrudan istemciden anahtar kullanmayın. Ben bunu ilk denemede local’de yapmıştım tabii… sonra kendime epey kızdım ve sunucu tarafına taşıdım. Güvenlik keyfi kaçırmayı sever, özellikle anahtar bir kere sızarsa geri dönüşü yok.
Temel Akış Nasıl Görünüyor?
Aşağıdaki yapı çok basit görünüyor ama iş görüyor: Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
// app/api/explain/route.js
import OpenAI from "openai";
const openai = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
});
export async function POST(request) {
try {
const { text, level } = await request.json();
if (!text || !level) {
return Response.json({ error: "Eksik alan var" }, { status: 400 });
}
const completion = await openai.responses.create({
model: "gpt-4o-mini",
input:
`Aşağıdaki metni ${level} seviyesinde açıkla:
${text}`,
});
return Response.json({
result: completion.output_text,
});
} catch (error) {
return Response.json(
{ error: "Bir şey ters gitti" },
{ status: 500 }
);
}
}
Kodu kısa diye hafife almayın. Esas olay kontrol noktaları — girdi boş mu, model ne dönduruyor, hata olursa kullanıcıya ne gösteriyorsunuz? Bunlar çözülmezse demo güzel görünür. Gerçek hayatta tam çuvallar. Söyleyeyim dedim.
Nerede İşe Yarıyor, Nerede Can Sıkıyor?
Bir dakika, şunu da ekleyeyim. AI her problemi çözmüyor. Bazen en iyi çözüm hiç AI kullanmamak oluyor çünkü basit regex ya da kural tabanlı mantık daha hızlı. Daha ucuz çalışıyor. Mesela form doğrulama için dev model çağırmak bana hâlâ gereksiz geliyor — dümdüz validation yap, geç.
Yine de bazı senaryolarda bayağı iyi sonuç veriyor: Bu konuyla ilgili Yerel OSINT ajanı kurmak: Bulut yok, veri sızıntısı da yok yazımıza da göz atmanızı tavsiye ederim.
- Karmaşık metinleri sadeleştirme
- Kullanıcı yorumlarını sınıflandırma
- E-posta taslakları üretme
- Dökümanlardan kısa özet çıkarma
- Soru-cevap botu oluşturma
Bunun zayıf yani ne peki? Tutarlılık meselesi. Aynı soruya farklı zamanlarda farklı tonlarda cevap verebilir. Bu durum ürününüzde garip bir his yaratır — kullanıcı “bu sistem ne istiyor ya” diye düşünmeye başlıyor (ki bu çoğu kişinin gözünden kaçıyor). En çok da müşteri destek tarafında bunu bizzat gördüm; Temmuz 2024’te Ankara’daki küçük bir e-ticaret ekibiyle yaptığımız denemede bot bazen aşırı resmi konuşuyor, bazen sanki eski arkadaşınızmış gibi davranıyordu ve kullanıcılar da haklı olarak şaşırıyordu.
| Senaryo | Küçük Startup | Kurumsal Ekip |
|---|---|---|
| Maliyet | Düşük giriş maliyeti ama dikkat edilmezse hızlı artar | Bütçe var ama onay süreçleri uzun olabilir |
| Hız | Çabuk dener, çabuk iter | Kontrollü ilerler, test süresi uzar |
| Güvenlik | Temel önlemler yeterli olabilir | Loglama, erişim kontrolü, uyumluluk şart |
Daha Temiz Bir Uygulama İçin Küçük Ama Önemli Ayrıntılar
Aslında burada işin en can sıkıcı kısmı prompt yazmak değil; sınırlar koymak. Kullanıcıdan gelen her şeyi olduğu gibi modele verirseniz hem maliyet hem risk artar. Bu haberi editör masasında incelerken ilk aklıma gelen de buydu zaten. Mantıklı değil mi? Çünkü çok basit görünen örneklerde bile kötü niyetli girişimler olabiliyor — görmezden gelmek mümkün değil.
Açık konuşayım, Mesela rate limiting koymazsanız biri sayfanızı delice spam’leyebilir. Cevapların uzunluğunu sınırlamazsanız model gereksiz gevezelik yapabilir, token yakar. Ve çıktı formatını net tanımlamazsanız front-end tarafında saçma sapan parse hatalarıyla uğraşırsınız — bunu yaşadım, anlatmayayım.
Pratik Kontrol Listesi
- Girdi doğrulama yapın
- Anahtarı asla istemciye gömmeyin
- Yanıt uzunluğunu sınırlayın
- Hata mesajlarını kullanıcı dostu tutun
- Loglara hassas veri düşürmeyin
Vallahi, Bu liste kulağa sıkıcı geliyor olabilir. Evet, sıkıcı. Ama üretimde hayat kurtarıyor — hele ki şirket içinde birkaç kişi aynı endpoint’i kullanacaksa disiplin şart, yoksa iki gün sonra kim hangi isteği attı kimse bilmiyor.
Kod Güzel de Maliyet Ne Olacak?
Maliyet konusu genelde sonradan fark ediliyor. İlk hafta herkes heyecanlı, ikinci hafta kullanım artınca tablo değişiyor. Bilhassa viral olabilecek özelliklerde talep sıçraması ciddi fatura yaratabiliyor — ve o faturayı açtığınızda yüzünüzdeki ifadeyi görmek isterdim.
Ben buna ilk kez geçen yıl İzmir’de küçük bir içerik aracını test ederken takıldım (ben de ilk duyduğumda şaşırmıştım). Deneme ortamında gayet makul görünen istek sayısı canlıda artınca ay sonu sürprizi çıktı. O yüzden token limiti koymak ve cache mekanizmasını düşünmek şart; ertelemek işe yaramıyor.
En pahalı AI özelliği genelde en havalı olan değildir; çoğu zaman kontrolsüz bırakılan özelliktir.
Sıkça Sorulan Sorular
AIddevam?>
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.



