Gemini 3.5 Flash Nasıl Kullanılır? En İyi Promptlar ve Ayarlar

Gemini 3.5 Flash’ı iyi kullanmak için promptu uzatmak gerekmiyor. Hatta çoğu zaman tam tersi gerekiyor: Daha kısa yazmak, daha net sınır koymak ve modeli doğru modda çalıştırmak.

Google’ın 19 Mayıs 2026’daki I/O duyurusuyla öne çıkan Gemini 3.5 Flash, özellikle Extended Thinking, hızlı yanıt üretimi, ajan kullanımı ve büyük bağlam desteğiyle dikkat çekiyor. Ama modelden iyi sonuç almak için eski prompt alışkanlıklarını biraz bırakmak şart.

Bu rehberde “Gemini 3.5 Flash nasıl kullanılır?” sorusuna doğrudan uygulamalı cevap vereceğiz. Hangi mod ne zaman açılır, thinkingLevel nasıl seçilir, 64K output sınırı nasıl yönetilir, Cached Input ile maliyet nasıl düşürülür ve kopyala-yapıştır kullanılabilecek en iyi promptlar nasıl yazılır, hepsini tek tek ele alacağız.

Gemini 3.5 Flash Nasıl Kullanılır? Önce Doğru Modu Seçin

Gemini 3.5 Flash’ta ilk karar prompt değil, mod seçimi olmalı.

Çünkü her iş için Extended Thinking açmak doğru değil. Bazı görevlerde hız daha önemlidir. Bazılarında ise modelin arka planda daha fazla muhakeme yapması gerekir.

Basit ayrım şöyle:

Buradaki ana mantık şu:

Standard mod hızlıdır.
Extended mod daha dikkatli çalışır.

Eğer kullanıcının ilk cevabı 3 saniyeden kısa sürede görmesi gerekiyorsa, Standard daha doğru seçimdir. Eğer modelin kod, veri, araç çağrısı veya uzun bağlam üzerinde daha dikkatli düşünmesini istiyorsanız, Extended tarafına geçmek gerekir.

Standard ve Extended Mod Farkı: Hangisini Açmalısınız?

Standard mod, Gemini 3.5 Flash’ın hızlı cevap vermesi gereken işler için uygundur. Arayüzde veya API tarafında bu mod genelde minimal ve low düşünme seviyelerine denk gelir.

Şu işler için Standard yeterlidir:

• Kısa metin düzeltme
• Basit özet çıkarma
• Müşteri mesajını yanıt taslağına çevirme
• Tek turlu fonksiyon çağrısı
• Basit JSON formatlama
• Hızlı fikir listesi üretme

Örnek Standard prompt:

Aşağıdaki müşteri mesajını kısa ve net bir destek yanıtına çevir.

Kurallar:
- En fazla 3 cümle yaz.
- Teknik terim kullanma.
- Kesin çözüm sözü verme.
- Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Müşteri mesajı:
[mesajı buraya yapıştır]

Extended mod ise daha karmaşık işler içindir. Bu modda model yanıt vermeden önce arka planda daha fazla muhakeme yapar. medium ve high seviyeleri özellikle profesyonel kullanımda daha değerlidir.

Extended mod şu işlerde daha iyi sonuç verir:

• Kod tabanı analizi
• Refactor planı
• SEO içerik kümeleri
• Finansal veri analizi
• Hipotez testi
• Çok turlu ajan görevleri
• Araç kullanan iş akışları
• Uzun dokümanlardan karar çıkarma

Pratik öneri:

Basit işler için Standard / low, profesyonel işler için Extended / medium, riskli ve çok adımlı işler için Extended / high kullanın.

Gemini 3.5 Flash Prompt Yazma Mantığı Değişti

Gemini 3.5 Flash’ta eski nesil prompt alışkanlıklarının bir kısmı artık iyi çalışmıyor.

Özellikle şu kalıp gereksiz hale geldi:

Adım adım düşün. Önce problemi analiz et. Sonra seçenekleri değerlendir. Sonra en doğru cevabı ver.

Bu tür uzun Chain-of-Thought talimatları, Gemini 3.5 Flash’ta çoğu zaman bağlamı şişirir. Modelin zaten yerleşik bir muhakeme motoru var. Sizden beklediği şey uzun uzun nasıl düşüneceğini anlatmanız değil; ne yapacağını, ne üretmeyeceğini ve hangi formatta cevap vereceğini söylemeniz.

Kötü prompt:

Lütfen çok dikkatli şekilde adım adım düşünerek, önce bütün ihtimalleri değerlendirip, sonra her aşamayı detaylı analiz ederek aşağıdaki kodu incele ve mümkün olan en iyi çözümü üret.

Daha iyi prompt:

Aşağıdaki kod tabanında race condition, memory leak ve websocket kapanış hatalarını bul.

Kurallar:
- Tüm dosyayı yeniden yazma.
- Sadece değişmesi gereken fonksiyonları öner.
- Her bulgu için dosya, fonksiyon, hata nedeni ve minimal patch ver.
- Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

İkinci prompt daha kısa ama daha profesyonel. Çünkü modelin işini sınırlandırıyor.

Gemini 3.5 Flash için iyi prompt şu dört şeyi net söylemeli:

• Görev: Ne yapılacak?
• Sınır: Ne yapılmayacak?
• Format: Çıktı nasıl verilecek?
• Güvenlik: Veri yoksa ne olacak?

Extended Thinking’den Daha İyi Sonuç Almak İçin 5 Kural

Extended Thinking açmak tek başına yeterli değil. Promptun da bu yapıyla uyumlu olması gerekir.

Hedefi tek cümlede kilitleyin

Promptun başında ana görevi net yazın.

Ana hedef: Bu kod tabanındaki websocket bağlantı yönetimi hatalarını bul ve sadece gerekli fonksiyonlar için minimal düzeltme öner.

Modelin cevabı boyunca odağı bu cümle belirler.

Çıktı formatını baştan verin

“Analiz et” demek yerine, nasıl analiz edeceğini söyleyin.

Çıktı formatı:
- Dosya
- Fonksiyon
- Risk seviyesi
- Hata nedeni
- Düzeltilmiş kod parçası

Bu kural özellikle kod, SEO ve veri analizinde kaliteyi artırır.

Halüsinasyon bariyerini ekleyin

Gemini 3.5 Flash hızlı çalıştığı için bilmediği yerde tahmin üretmesini istemezsiniz.

Kullanılacak kural:

Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Bu cümleyi finans, hukuk, sağlık, teknik dokümantasyon ve veri analizi işlerinde mutlaka ekleyin.

Çok turlu işlerde thought summary sürekliliği isteyin

Uzun bir refactor, SEO planı veya veri analizi yapıyorsanız şu cümle işe yarar:

Önceki adımlardaki gizli muhakeme mantığını (thought summary) hafızanda tutarak bir sonraki adıma geç.

Bunu her basit işte kullanmaya gerek yok. Ama çok turlu akışlarda modelin önceki karar mantığını koruması için faydalıdır.

Büyük işleri tek cevapta bitirtmeye çalışmayın

Gemini 3.5 Flash geniş bağlam okuyabilir ama her şeyi tek cevapta üretmesini istemek hatalıdır.

Daha iyi yöntem:

• Önce analiz haritası çıkar.
• Sonra riskleri sırala.
• Sonra tek tek düzeltme üret.
• Her düzeltmede sadece ilgili parçayı yazdır.

Bu hem çıktı sınırını hem de maliyeti kontrol eder.

Gemini 3.5 Flash Ayarları: thinkingLevel Nasıl Seçilir?

Gemini 3.5 Flash’ta thinkingLevel, modelin arka planda ne kadar muhakeme yapacağını belirleyen ana ayarlardan biridir.

Pratik ayar tablosu:

Önerilen varsayılan yapı:

{
  "thinkingConfig": {
    "thinkingLevel": "medium"
  }
}

Geliştirici debug için şu parametreyi de ekleyebilir:

{
  "thinkingConfig": {
    "thinkingLevel": "medium",
    "includeThoughts": true
  }
}

includeThoughts: true, modelin muhakeme davranışını debug etmek için kullanılabilir. Ancak üretim ortamında sürekli açık bırakmadan önce log güvenliği, kullanıcı verisi ve maliyet etkisi kontrol edilmelidir.

64K Output Sınırı: Büyük Kod ve Uzun Çıktılar Nasıl Yönetilir?

Gemini 3.5 Flash’ın güçlü taraflarından biri 1 milyon input token sınırı. Büyük kod tabanlarını, uzun dokümanları ve kapsamlı veri setlerini modele verebilirsiniz.

Ama çıktı tarafında model tek seferde en fazla 64K output token üretebilir.

Bu yüzden şu prompt yanlıştır:

Bu projeyi baştan sona refactor et ve tüm dosyaları yeni haliyle yaz.

Doğru yaklaşım:

Önce kod tabanındaki en riskli 10 noktayı çıkar. Henüz kod üretme. Sonra seçtiğim bulgu için sadece gerekli fonksiyonu minimal patch olarak yaz.

Büyük işlerde kullanmanız gereken sabit kural:

64K output sınırını aşmamak için tüm dosyayı yeniden üretme. Sadece değişmesi gereken fonksiyonları, sınıfları veya minimal patch parçalarını ver.

Bu kural hem kodda hem SEO planlarında hem de veri analizinde işe yarar. Modeli “her şeyi tek cevapta yazan” bir araç gibi değil, aşamalı çalışan bir uzman gibi kullanmak gerekir.

En İyi Gemini 3.5 Flash Promptları: Kod, SEO ve Veri Analizi

Aşağıdaki promptlar doğrudan kopyalanıp kullanılabilir. Hepsi Extended Thinking ile çalışmaya uygun şekilde tasarlandı.

Kod Yazdırmak İçin Gemini 3.5 Flash Promptu

Bu şablon, mikrofon girdileri ve websocket paketleriyle çalışan uygulamalarda race condition, memory leak ve bağlantı yönetimi hatalarını bulmak için hazırlandı.

Önerilen mod: Extended / medium-high

Bir kıdemli yazılım mimarı gibi davran. Amacın tüm projeyi yeniden yazmak değil, riskli noktaları bulup sadece gerekli parçaları düzeltmek.

İnceleyeceğin sistem:
Gerçek zamanlı mikrofon girdilerini işleyen, websocket paketlerini yöneten ve ses akışını sunucuya ileten büyük bir kod tabanı.

Ana hedef:
Kod tabanındaki race condition, memory leak, websocket lifecycle hataları, event listener temizleme eksikleri, kontrolsüz reconnect döngüleri ve kaynak yönetimi problemlerini bul.

Önemli model sınırı:
Gemini 3.5 Flash 1 milyon input token okuyabilir; ancak tek yanıtta 64K output token sınırı vardır. Bu yüzden tüm dosyaları yeniden yazma. Sadece değişmesi gereken fonksiyonları, sınıfları veya minimal patch parçalarını üret.

Muhakeme sürekliliği:
Önceki adımlardaki gizli muhakeme mantığını (thought summary) hafızanda tutarak bir sonraki adıma geç.

Doğruluk kuralı:
Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Özellikle kontrol et:
1. Mikrofon stream açma ve kapama akışı
2. WebSocket bağlantısının açılma, kapanma ve yeniden bağlanma mantığı
3. Aynı audio buffer'a eşzamanlı yazma riski
4. Event listener temizlenmemesi
5. AbortController veya cancellation eksikleri
6. Reconnect sırasında çoğalan bağlantılar
7. Promise yarışları
8. Bellekte tutulan eski audio chunk'ları
9. Backpressure yönetimi
10. Kullanıcı oturumu kapanınca açık kalan kaynaklar

İlk aşamada sadece analiz yap:
- En riskli 10 bulguyu listele.
- Henüz kod üretme.
- Her bulgu için hangi dosyanın önce ele alınması gerektiğini belirt.
- Bulguları risk seviyesine göre sırala.

Çıktı formatı:

Bulgu [numara]: [Kısa başlık]

Dosya: [dosya adı]
Fonksiyon / Sınıf: [ilgili bölüm]
Risk seviyesi: Düşük / Orta / Yüksek / Kritik
Sorun tipi: Race condition / Memory leak / WebSocket lifecycle / Resource cleanup / Backpressure / Diğer
Neden sorun: [kısa teknik açıklama]
Önerilen müdahale: [net çözüm]
Patch üretimi gerekli mi?: Evet / Hayır
Öncelik: 1-10

Sonraki adım:
Ben belirli bir bulguyu seçtiğimde sadece o bulgu için minimal patch üret. Tüm dosyayı yeniden yazma.

Kod tabanı:
<code_repository>
[Buraya ilgili dosyaları, repo özetini veya kritik modülleri yapıştır]
</code_repository>

Bu promptun iyi tarafı, Gemini 3.5 Flash’a hemen kod yazdırmaması. Önce risk haritası çıkarır. Sonra seçilen problem için parça parça düzeltme alınır. Büyük kod tabanlarında en sağlıklı kullanım budur.

Seçilen Kod Hatası İçin Minimal Patch Promptu

İlk prompttan sonra belirli bir bulguyu seçip sadece onun düzeltmesini almak için bu şablonu kullanın.

Aşağıdaki bulgu için minimal patch üret.

Kurallar:
- Tüm dosyayı yeniden yazma.
- Sadece değişmesi gereken fonksiyonları veya sınıfları ver.
- Kodun neden değiştiğini kısa açıkla.
- Yeni race condition veya memory leak oluşturma.
- Bağlamda kesin veri yoksa "Veri yetersiz" diyerek reddet.
- Output sınırını aşacaksa önce patch planı çıkar, kod üretme.

Seçilen bulgu:
[Buraya önceki yanıttaki bulguyu yapıştır]

İlgili kod:
<relevant_code>
[Buraya sadece ilgili dosya veya fonksiyonları yapıştır]
</relevant_code>

Çıktı formatı:

Patch Planı

- Değişecek dosya:
- Değişecek fonksiyon/sınıf:
- Çözüm mantığı:
- Risk:

Düzeltilmiş Kod

[Düzeltilmiş kodu burada ver]

Kontrol Listesi

- Race condition giderildi mi?
- Memory leak riski azaldı mı?
- WebSocket kapanış akışı güvenli mi?
- Event listener temizleniyor mu?
- Geriye dönük uyumluluk riski var mı?

SEO İçerik Planı İçin Gemini 3.5 Flash Promptu

Bu şablon, bir ana anahtar kelimeden Pillar Page, Cluster Page, arama niyeti sınıflandırması ve iç linkleme planı çıkarmak için hazırlandı.

Önerilen mod: Extended / medium

Bir SEO Direktörü gibi davran. Amacın sadece başlık listesi üretmek değil, arama niyetine göre çalışan bir içerik mimarisi kurmak.

Ana anahtar kelime:
Yapay zeka ajanları ile iş otomasyonu

Ana hedef:
Bu konu için 1 adet Pillar Page ve 5 adet Cluster Page öner. Anahtar kelimeleri search intent'e göre sınıflandır. Sayfalar arası internal linking stratejisini Markdown tablosu olarak ver.

Muhakeme sürekliliği:
Önceki adımlardaki gizli muhakeme mantığını (thought summary) hafızanda tutarak bir sonraki adıma geç.

Doğruluk kuralı:
Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Arama niyeti sınıfları:
- Informational
- Commercial
- Transactional
- Navigational
- Comparative
- Problem-aware
- Solution-aware

Çıktı yapısı:

Arama Niyeti Haritası

| Anahtar Kelime | Search Intent | Kullanıcı Ne Arıyor? | İçerik Tipi | Öncelik |
|---|---|---|---|---|

Pillar Page

Başlık:
URL Slug:
Hedef Kitle:
Ana Search Intent:
Cevaplayacağı Ana Soru:
H2 Önerileri:
CTA Önerisi:
GEO için kısa tanım:

5 Cluster Page

Her cluster için şu formatı kullan:

Cluster [numara]

Başlık:
Slug:
Hedef Anahtar Kelime:
İkincil Anahtar Kelimeler:
Search Intent:
Bu içerik hangi sorunu çözer?
Pillar sayfaya verilecek anchor text:
Pillar sayfadan alınacak anchor text:
FAQ önerileri:

Internal Linking Planı

| Kaynak Sayfa | Hedef Sayfa | Anchor Text | Linkleme Nedeni | Öncelik |
|---|---|---|---|---|

GEO Uyumlu Kısa Cevaplar

Yapay zeka arama motorlarının doğrudan çekebileceği 5 kısa cevap yaz.

Kurallar:
- Her cevap 40-60 kelime arasında olsun.
- Her cevap doğrudan bir soruya yanıt versin.
- Pazarlama dili kullanma.
- Gereksiz sıfat kullanma.

Ek veri:
Anahtar kelime listesi:
[keyword listesini buraya yapıştır]

Rakip başlıklar veya SERP notları:
[rakip içerik başlıklarını buraya yapıştır]

Bu prompt özellikle içerik ekipleri için güçlüdür. Çünkü sadece “ne yazalım?” sorusunu değil, “hangi sayfa neye bağlanmalı?” sorusunu da cevaplar.

Veri Analizi İçin Gemini 3.5 Flash Promptu

Bu şablon, yeni kullanıcılar ile geri dönen kullanıcıların sepet tutarlarını karşılaştırmak için tasarlandı. Modelden sadece yorum değil; veri temizliği, Mean, SD, hipotez testi, A/B testi ve reklam bütçesi önerisi ister.

Önerilen mod: Extended / medium-high

Bir kıdemli finansal veri analisti gibi davran. Sana verilen transaction verilerini kullanarak yeni kullanıcılar ile geri dönen kullanıcıların sepet tutarlarını karşılaştır.

Ana hipotez:
Geri dönen kullanıcıların ortalama sepet tutarı, yeni kullanıcıların ortalama sepet tutarından istatistiksel olarak anlamlı derecede yüksektir.

Muhakeme sürekliliği:
Önceki adımlardaki gizli muhakeme mantığını (thought summary) hafızanda tutarak bir sonraki adıma geç.

Doğruluk kuralı:
Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Veri temizleme kuralları:
1. Sepet tutarı boş olan satırları ana analiz dışında bırak.
2. Negatif sepet tutarı varsa anomali olarak raporla.
3. Kullanıcı tipi "Yeni" ve "Geri Dönen" dışında ise "Diğer" olarak ayır, ana hipotez testine dahil etme.
4. Para birimi karışıksa normalize edilmesi gerektiğini belirt.
5. Uç değerleri silme; önce raporla, sonra etkisini ayrıca yorumla.
6. Örneklem yetersizse hipotez testi sonucu uydurma.

İstenen hesaplamalar:
- Yeni kullanıcılar için örneklem sayısı
- Geri dönen kullanıcılar için örneklem sayısı
- Yeni kullanıcılar için Ortalama (Mean)
- Geri dönen kullanıcılar için Ortalama (Mean)
- Yeni kullanıcılar için Standart Sapma (SD)
- Geri dönen kullanıcılar için Standart Sapma (SD)
- Ortalama farkı
- Uç değer etkisi
- Uygun hipotez testi önerisi
- Veri yeterliyse karar yorumu
- Veri yetersizse "Veri yetersiz" diyerek reddet

Çıktı formatı:

Veri Kalite Kontrolü

| Kontrol | Sonuç | Not |
|---|---|---|

Tanımlayıcı İstatistikler

| Kullanıcı Tipi | Örneklem Sayısı | Mean | SD | Minimum | Maksimum |
|---|---:|---:|---:|---:|---:|

Hipotez Testi

H0: Geri dönen kullanıcıların ortalama sepet tutarı, yeni kullanıcıların ortalama sepet tutarından yüksek değildir.
H1: Geri dönen kullanıcıların ortalama sepet tutarı, yeni kullanıcıların ortalama sepet tutarından yüksektir.

Şu başlıklarla yorum yap:
- Test için veri yeterli mi?
- Hangi test uygundur?
- Sonuç ne anlama gelir?
- Karar almak için hangi ek veri gerekir?

A/B Testi Tasarımı

| Test Öğesi | Öneri |
|---|---|
| Hipotez | |
| Kontrol Grubu | |
| Deney Grubu | |
| Başarı Metriği | |
| İkincil Metrikler | |
| Minimum Test Süresi | |
| Riskler | |

Reklam Bütçesi İçin 3 Aksiyon

Her öneriyi şu formatta yaz:

Aksiyon [numara]: [Başlık]

Ne yapılmalı:
Neden:
Hangi metrik izlenmeli:
Risk:

Transaction verisi:
<transaction_data>
| Sipariş ID | Tarih | Kanal | Sepet Tutarı | Kullanıcı Tipi |
| OR-9021 | 2026-05-01 | Google Search | 1500 | Yeni |
| OR-9022 | 2026-05-01 | Direct | 4500 | Geri Dönen |
[Veri tablosunun devamını buraya yapıştır]
</transaction_data>

Bu promptun değeri, Gemini 3.5 Flash’ı “yorum yapan model” yerine “kontrollü analiz yapan yardımcı” gibi çalıştırması. Önce veri kontrolü, sonra hesap, sonra karar.

Gemini 3.5 Flash API Kullanımı: includeThoughts, Cached Input ve thinkingLevel

API tarafında Gemini 3.5 Flash kullanırken üç başlığa özellikle dikkat etmek gerekir:

• thinkingLevel
• includeThoughts
• Cached Input

Basit örnek yapı:

{
  "thinkingConfig": {
    "thinkingLevel": "medium",
    "includeThoughts": true
  }
}

thinkingLevel, modelin ne kadar derin muhakeme yapacağını belirler.
includeThoughts, geliştiriciye debug için muhakeme özetlerini izleme imkânı verir.
Cached Input, sabit sistem promptları ve şemalar tekrar kullanıldığında maliyeti düşürür.

Burada en önemli kurumsal taktik şu:

Sabit sistem talimatlarını, araç şemalarını ve değişmeyen kuralları bağlamın başında tutun. Mümkünse ilk 100K token içinde konumlandırın.

Bunun iki nedeni var:

1. Modelin dikkatini kritik kurallara daha yakın tutarsınız.
2. Cached Input sayesinde girdi maliyetinde %90 indirim avantajı yakalayabilirsiniz.

Özellikle çok turlu ajan sistemlerinde aynı sistem promptunu her turda farklı yere koymak kötü fikirdir. Sabit kısmı bağlamın başında tutmak hem daha temiz hem daha ucuzdur.

Ajan Kullanımında Maliyet Kontrolü: Looping, Cached Input ve X-Initiator

Gemini 3.5 Flash çoklu ajan sistemlerinde hızlı çalışabilir. Ama hız, kötü sınırlandırılmış bir ajan yapısında maliyeti büyütebilir.

Özellikle Antigravity 2.0, Spark veya benzeri çoklu ajan akışlarında her alt ajanın görevi mikro düzeyde tanımlanmalı.

Kötü ajan tanımı:

Sen yazılım ajanısın. İşletim sistemi çekirdeğini yaz, ağ katmanını kur, dosya sistemini düzenle, testleri çalıştır ve hataları düzelt.

Daha iyi ajan tanımı:

Sen yalnızca ağ protokol soketlerini yazmakla görevli alt ajansın.

Sınırların:
- Dosya sistemine müdahale etme.
- Bellek yöneticisi kodunu değiştirme.
- Scheduler tarafında değişiklik yapma.
- Sadece /kernel/network/ dizinindeki dosyaları incele.
- Sadece socket açma, kapama, hata yönetimi ve paket kuyruğu mantığını düzenle.

Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Ajanlarda ikinci kritik konu looping. Model aynı aracı tekrar çağırabilir, aynı çıktıyı yeniden okuyabilir ve hedefe yaklaştığını sanarak faturayı büyütebilir.

Bunu önlemek için sistem promptuna şu kuralı ekleyin:

Her 5 araç çağrısında bir durum analizi yap, hedeften sapıyorsan dur ve insan onayına (human-in-the-loop) başvur.

Daha sıkı versiyon:

Araç kullanım kuralı:
Her 5 araç çağrısından sonra aşağıdaki kontrolü yap:

1. Şu ana kadar hangi işlemleri yaptığını özetle.
2. Ana hedefe ne kadar yaklaştığını değerlendir.
3. Aynı aracı aynı amaçla tekrar çağırıp çağırmadığını kontrol et.
4. Eğer hedef sapması, tekrar veya belirsizlik varsa işlemi durdur.
5. Durduğunda "İnsan onayı gerekli" yaz ve bir sonraki en güvenli adımı öner.

Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Bu küçük kural, uzun ajan akışlarında ciddi maliyet farkı yaratabilir.

Proxy ve BYOK Kullananlar İçin X-Initiator: agent Uyarısı

GitHub Copilot, Cursor veya BYOK proxy kullanan ekiplerde Gemini 3.5 Flash’ın arka plan ajan çağrıları bazen yanlış sınıflandırılabilir.

Sorun şu: Ajanın kendi kendine yaptığı arka plan adımları, sistem tarafından kullanıcı tarafından tetiklenen premium istek gibi görülebilir. Bu da kota ve fatura tarafında şişmeye neden olur.

Bunu önlemek için arka plan ajan çağrılarında HTTP header içine şu değer eklenmeli:

X-Initiator: agent

Basit JavaScript örneği:

const headers = {
  "Content-Type": "application/json",
  "Authorization": `Bearer ${process.env.GEMINI_API_KEY}`,
  "X-Initiator": "agent"
};

Daha kontrollü örnek:

function buildGeminiHeaders({ isAgentStep }) {
  const headers = {
    "Content-Type": "application/json",
    "Authorization": `Bearer ${process.env.GEMINI_API_KEY}`
  };

  if (isAgentStep) {
    headers["X-Initiator"] = "agent";
  }

  return headers;
}

Bu ayrım özellikle çok turlu ajan sistemlerinde önemlidir. İnsan isteğiyle ajanın arka plan adımı aynı şekilde faturalandırılırsa, küçük bir yanlış sınıflandırma kısa sürede ciddi maliyet farkına dönüşebilir.

Hazır Gemini 3.5 Flash Sistem Promptu

Aşağıdaki sistem promptu; kodlama, analiz, SEO planlama ve ajan görevlerinde temel güvenlik katmanı olarak kullanılabilir.

Sen Gemini 3.5 Flash üzerinde çalışan teknik bir analiz ve uygulama asistanısın.

Çalışma modu:
- Basit görevlerde kısa ve doğrudan yanıt ver.
- Karmaşık kodlama, analiz ve çok adımlı görevlerde Extended Thinking mantığıyla çalış.
- Gereksiz uzun açıklama üretme.
- Eski tarz "adım adım düşün" çıktısı verme.
- Son kullanıcıya yalnızca kararını, gerekçeni ve uygulanabilir sonucu göster.

Süreklilik:
Önceki adımlardaki gizli muhakeme mantığını (thought summary) hafızanda tutarak bir sonraki adıma geç.

Doğruluk kuralı:
Bağlamda kesin veri yoksa tahmin yürütme, "Veri yetersiz" diyerek reddet.

Çıktı disiplini:
- İstenen formatın dışına çıkma.
- Büyük kod tabanlarında tüm dosyayı yeniden yazma.
- Sadece değişmesi gereken fonksiyonları, sınıfları veya küçük patch parçalarını ver.
- Belirsiz alanları açıkça işaretle.
- 64K output sınırını aşacak işlerde önce plan çıkar, sonra parça parça ilerle.

Ajan güvenliği:
- Her 5 araç çağrısında bir durum analizi yap.
- Hedeften sapıyorsan dur ve insan onayına başvur.
- Aynı aracı aynı amaçla tekrar tekrar çağırma.
- Gereksiz API çağrısı yapma.

Maliyet disiplini:
- Sabit şemaları ve değişmeyen talimatları yeniden üretme.
- Uzun çıktılar yerine aşamalı çıktı ver.
- Cached Input avantajı için sabit sistem talimatlarını bağlamın başında tut.

Bu prompt her iş için birebir kullanılmak zorunda değil. Ama ekip içinde Gemini 3.5 Flash kullanım standardı oluşturmak için iyi bir başlangıç noktasıdır.

Gemini 3.5 Flash Kullanırken En Sık Yapılan Hatalar

Gemini 3.5 Flash güçlü bir model, ama yanlış kullanıldığında hızlı şekilde kötü çıktı veya yüksek maliyet üretebilir.

En sık gördüğümüz hatalar şunlar:

• Her işte Extended / high açmak
• Basit özet için gereksiz muhakeme kullandırmak
• Büyük kod tabanını tek seferde yeniden yazdırmaya çalışmak
• 64K output sınırını yok saymak
• Her prompta uzun “adım adım düşün” talimatı eklemek
• Belirsizlik durumunda “Veri yetersiz” kuralı koymamak
• Ajanlara çok geniş görev vermek
• Her 5 araç çağrısında durum kontrolü yaptırmamak
• Cached Input avantajını kullanmamak
• Proxy/BYOK tarafında X-Initiator: agent header’ını eklememek

Bu hataların çoğu modelden değil, kullanım tasarımından kaynaklanır.

akisai.com.tr Yorumu: Bu Model Prompt Değil, Çalışma Disiplini İstiyor

Gemini 3.5 Flash’tan iyi sonuç almak için uzun promptlar yazmak şart değil. Hatta çoğu zaman kısa, net ve sınırları iyi çizilmiş promptlar daha iyi çalışıyor.

Bu modelde asıl verim üç yerden geliyor:

• Doğru iş için doğru mod: Standard veya Extended
• Net çıktı disiplini: tablo, patch, liste, karar formatı
• Maliyet ve güvenlik sınırları: Cached Input, 64K output kontrolü, X-Initiator: agent, human-in-the-loop

Extended Thinking, kodlama, SEO planlama, veri analizi ve çok turlu ajan işlerinde değerli. Ama her işe yüksek düşünme modu açmak iyi fikir değil. Basit işte Standard daha hızlı ve ucuzdur. Karmaşık işte Extended daha güvenlidir.

Gemini 3.5 Flash’ı en iyi kullanacak ekipler, modele “her şeyi yap” diyenler değil; modelin nerede başlayacağını, nerede duracağını ve ne üretmeyeceğini net söyleyenler olacak.