Ekim 9 2026

Quantum-Safe DevOps: Mevcut CI/CD Pipeline’larınızı Kriptografik Borçtan Koruyun

Modern devops pratiklerinde güvenlik genellikle pipeline’a bir SAST/DAST aracı sıkıştırmak, image’ları Trivy ile taramak ve artifact’leri RSA-2048 ile imzalamaktan ibaret sanılıyor. Oysa kapıda sessizce büyüyen devasa bir problem var: Kriptografik borç. Kuantum bilgisayarlar pratik ölçeğe ulaştığında, bugün asimetrik cryptography temelleri üzerine inşa ettiğimiz tüm pipeline security mimarisi domino taşı gibi devrilecek. Daha da kötüsü, tehdit “o gün” başlamayacak; Harvest Now, Decrypt Later (HNDL) saldırıları sebebiyle bugünden depolanan imzalar ve şifreli trafik yarın aleyhimize delil olarak kullanılacak. Bu yazıda teorik fizik tartışmalarına girmeden, doğrudan production hatlarında uygulayabileceğiniz quantum-safe dönüşüm stratejilerini ve pratik konfigürasyonları masaya yatırıyoruz.

Neden Şimdi? Moska Teoremi ve CI/CD Gerçekliği

Kuantum tehdidini konuşurken çoğu mühendisin düştüğü hata, “Q-Day gelene kadar en az 8-10 yılımız var” rehavetine kapılmaktır. Kriptograf Michele Mosca’nın denklemi durumu çok net özetler: X + Y > Z ise sisteminiz zaten risk altındadır. Burada X verinizin gizli kalması gereken süre, Y sistemlerinizi kuantum dirençli hale getirme süreniz, Z ise kuantum bilgisayarların RSA/ECC’yi kıracağı tahmini tarihtir.

Bir bankanın veya fintech girişiminin CI/CD pipeline’ında build edilen artifact’lerin, firmware imajlarının veya Git commit’lerinin imza geçerlilik ömrü bazen 10-15 yılı bulur. Eğer bugün artifact imzalarken ML-DSA (CRYSTALS-Dilithium) veya stateful hash-based imzalara geçiş yapmazsanız, 2030’da geçmişe dönük supply chain doğrulamalarınızın hiçbir matematiksel güvencesi kalmayacaktır.

1. Git İletişimi: OpenSSH Hibrit Anahtar Değişimine Geçiş

Git runner’larınız repository’lere SSH üzerinden bağlanıyorsa, aradaki trafik bugün kaydedilip gelecekte çözülebilir. OpenSSH 9.0 ve üzeri sürümler, varsayılan olarak Streamlined NTRU Prime ve X25519 hibrit algoritmasını (sntrup761x25519-sha512@openssh.com) destekliyor. Bu hibrit yapı şu anlama gelir: Klasik X25519 kırılsa bile kuantum-dirençli katman sizi korur; yeni algoritmada bilinmeyen bir açık çıksa bile klasik katman güvence sağlar.

CI/CD runner’larınızın ve Git sunucularınızın (GitLab, self-hosted Gitea vs.) SSH konfigürasyonunu zorunlu olarak hibrit moda geçirmek için /etc/ssh/ssh_config (veya sunucu tarafında sshd_config) dosyasında KexAlgorithms direktifini güncelleyin:

# /etc/ssh/sshd_config veya CI Runner ~/.ssh/config
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

# Host key olarak klasik Ed25519 kullanmaya devam etseniz bile,
# oturum anahtarı değişimi (KEX) kuantum dirençli hale gelir.
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512

Runner üzerinde bağlantının hibrit algoritma kullanıp kullanmadığını doğrulamak için şu komutla debug çıktısını inceleyin:

ssh -vvv git@gitlab.internal.corp 2>&1 | grep "kex: algorithm:"
# Çıktıda şunu görmelisiniz:
# debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com

2. Artifact İmzalama: Cosign ve Post-Quantum Algoritmalar

Yıllardır Cosign ile container imzalıyoruz. Peki o imzalar neye güveniyor? ECDSA P-256 veya RSA-4096. Shor algoritması çalışan bir kuantum bilgisayar karşısında P-256’nın ömrü birkaç saniyedir. NIST, Ağustos 2024’te resmi FIPS standartlarını yayımladı: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) ve FIPS 205 (SLH-DSA).

Şu an üretim ortamlarında saf PQC (Post-Quantum Cryptography) kullanmak imza boyutları nedeniyle (RSA’in 256 baytına karşılık Dilithium-3’ün ~3.3 KB boyutu) overhead yaratabilir. Bu yüzden ara çözüm Hibrit İmzalar veya liboqs entegrasyonudur. Sigstore ekosistemi PQC desteğini deneysel olarak sürdürürken, build pipeline’ınızda OpenSSL 3.x ve oqsprovider kullanarak kendi post-quantum PKI altyapınızı ayağa kaldırabilirsiniz.

Runner container’ı içerisinde ML-DSA-65 (Dilithium3) tabanlı bir keypair üretip artifact imzalamak için örnek bir yaklaşım:

# liboqs ve oqsprovider kurulu bir base image üzerinde:
# 1. Post-Quantum Private Key üret (FIPS 204 / ML-DSA-65)
openssl req -x509 -new -newkey mldsa65 \
  -keyout pqc_private.key \
  -out pqc_cert.crt \
  -nodes -subj "/CN=CI-PQC-Signer/O=KertenKerem" \
  -provider oqsprovider -provider default

# 2. Release artifact'ının (örneğin binary veya tarball) SHA-256 hash'ini al
sha256sum release-v1.4.0.tar.gz | awk '{print $1}' > artifact.digest

# 3. Hash'i ML-DSA anahtarıyla imzala
openssl dgst -sign pqc_private.key \
  -provider oqsprovider -provider default \
  -out artifact.sig artifact.digest

# 4. Doğrulama testi (Deployment aşamasında çalışacak kod)
openssl dgst -verify <(openssl x509 -in pqc_cert.crt -pubkey -noout -provider oqsprovider) \
  -signature artifact.sig \
  -provider oqsprovider -provider default \
  artifact.digest

Bu akışın klasik Cosign akışına göre tek farkı, kullanılan matematiksel yapının lattice-based (örgü tabanlı) olmasıdır. Bir imzayı production cluster’ında Admission Controller seviyesinde doğrulamak istiyorsanız, gatekeeper veya Kyverno pod’larınızın da liboqs kütüphanesini tanıyan OpenSSL/BoringSSL runtime’larına sahip olması gerektiğini unutmayın.

3. Kriptografik Envanter: CBOM (Cryptographic Bill of Materials)

SBOM (Software Bill of Materials) çıkarmayı öğrendik; peki uygulamanızın hangi şifreleme kütüphanelerine, hangi anahtar uzunluklarına ve hangi TLS versiyonlarına bağımlı olduğunu biliyor musunuz? Kodunuz doğrudan crypto/tls çağırıyor olabilir ama üçüncü parti bir Go paketi derleme anında RSA-1024’e hardcode edilmiş eski bir algoritma kullanıyor olabilir.

CycloneDX standardı, CBOM konseptiyle kriptografik varlıkların taranmasını ve listelenmesini destekler. CI aşamasına ekleyeceğiniz bir CBOM adımı, kuantum göçü (migration) başladığında envanter çıkarmak için harcayacağınız ayları kurtarır.

# Syft ile projenin kriptografik bağımlılıklarını içeren SBOM JSON çıktısı üretme
syft dir:. -o cyclonedx-json=bom.json

# bom.json içerisindeki zayıf kriptografik bağımlılıkları CI aşamasında filtreleme
jq '.components[] | select(.name | test("crypto|tls|ssl|ssh")) | {name: .name, version: .version}' bom.json

Eğer pipeline’ınızda kurumsal bir tarama yapıyorsanız, IBM CBOM Toolkit veya benzeri statik analiz araçlarını derleme öncesi kancalara (pre-commit / CI gate) entegre ederek kod tabanında crypto.GenerateKey(rsa.Reader, 2048) gibi çağrıları CI seviyesinde hata verdirerek engelleyebilirsiniz:

# semgrep ile CI pipeline'ında kuantum-zayıf anahtar kullanımını fail etme örneği
semgrep --config=p/crypto \
  --lang=go \
  --pattern='rsa.GenerateKey($R, 2048)' \
  --error \
  ./src

4. HashiCorp Vault ve Transit Secret Motoru

Pipeline içerisinde hassas environment variable’ları şifrelemek (envelope encryption) için yaygın olarak HashiCorp Vault Transit Engine kullanılır. Mevcut transit engine konfigürasyonunuz büyük olasılıkla aes256-gcm96 ile data encryption, anahtar değişimi için ise ECDSA/RSA kullanıyordur. AES-256, kuantum bilgisayarlar karşısında güvenlidir (Grover algoritması anahtar arama uzayını 2^128’e düşürür ki bu hâlâ pratikte kırılamaz bir seviyedir). Buradaki asıl problem, Vault client ile server arasındaki mTLS oturumu ve transit key’lerin wrap edilme yöntemidir.

Vault mTLS iletişimini güvenceye almak için, reverse proxy ve ingress seviyesinde TLS 1.3 zorunlu tutulmalı ve desteklenen cipher suite’ler sınırlandırılmalıdır:

# NGINX veya Cloud Ingress TLS 1.3 konfigürasyonu
ssl_protocols TLSv1.3;
# Kuantum sonrası anahtar değişimini destekleyen hibrit gruplar (X25519MLKEM768)
# Envoy / Nginx son sürümlerinde BoringSSL desteği ile aktifleştirilebilir
ssl_ecdh_curve X25519MLKEM768:x25519:secp384r1;

Cloudflare ve Google Chrome’un halihazırda üretimde kullandığı X25519MLKEM768 hibrit anahtar değişim mekanizması, pipeline runner’larınız ile internal API’larınız arasındaki veri trafiğini HNDL saldırılarına karşı bugünden korur.

DevOps Mühendisleri İçin Aksiyon Planı

Kriptografik dönüşüm, son gün yapabileceğiniz bir “hotfix” değildir. Bugün almanız gereken aksiyonlar şunlardır:

1. SSH Altyapısını Denetleyin: Tüm CI runner ve bastion host’larda OpenSSH 9.0+ sürümüne geçin ve hibrit KEX algoritmalarını zorunlu kılın.
2. CBOM Üretin: Build süreçlerinize SBOM yanında kriptografik varlık taramalarını ekleyin; kütüphanelerinizdeki sert kodlanmış asimetrik anahtar boyutlarını tespit edin.
3. AES-128’i Terk Edin: Simetrik şifrelemede taban çizgisi olarak her yerde AES-256 ve ChaCha20-Poly1305 kullanın.
4. Kriptografik Esneklik (Crypto-Agility) Kazanın: Kod içinde algoritma isimlerini string parametre olarak geçmeyin; anahtar yönetimini soyutlayan provider katmanları kullanın ki NIST FIPS 204/205 kütüphaneleri genel paket yöneticilerine tam girdiğinde sadece config değiştirerek göç edebilin.

Kuantum çağı geldiğinde pipeline’ları baştan yazmak zorunda kalmamak için mimarideki kriptografik borcu bugünden amorti etmeye başlayın.

Category: Genel | LEAVE A COMMENT
Ekim 4 2026

Workation Destinasyonlarında Teknik Denetim: Sahil Kasabasını Ofis Yapmadan Önce 5 Soru

Balkondan denizi gören, begonvillerle sarılı o rüya gibi taş evin terasında dizüstü bilgisayarınızı açtınız. İlk yudum kahve, fonda dalga sesleri ve işte o an: Önemli bir müşteri toplantısının tam ortasında ekranınız donuyor, sesiniz robotikleşiyor ve modem ışıkları aniden sönüyor. Bir workation deneyimini cennetten cehenneme çeviren şey genellikle kötü hava değil, hesaba katılmayan berbat bir teknik altyapıdır. Modern bir dijital göçebe için manzara harika bir bonus olabilir ama asıl hayati mesele, kesintisiz çalışan bir elektrik hattı ve istikrarlı bir internet bağlantısıdır. Bu rehberde, romantik hayalleri bir kenara bırakıp, bir rotayı geçici ofisiniz yapmadan önce sormanız gereken beş kritik teknik soruyu inceliyoruz.

Download Hızı Bir İllüzyon: Gerçek Ping ve Jitter Değeriniz Kaç?

Rezervasyon yapmadan önce ev sahibine mesaj atıp internet hızını sorduğunuzda, size gururla 100 Mbps aldığını söyleyebilir. Hatta ilan sayfasına bir Speedtest ekran görüntüsü de iliştirmiş olabilir. Ancak uzaktan çalışma rutininde video konferanslara katılıyorsanız, SSH bağlantıları kuruyorsanız veya canlı sunuculara kod atıyorsanız, download hızının tek başına hiçbir anlamı yoktur. 100 Mbps hızında bir hatta bile jitter fırladığında, sesiniz karşı tarafa parçalanarak gider.

Özellikle Ege kasabalarında ya da Güneydoğu Asya adalarında altyapı genellikle bakır kablolardan veya yerel radyo linklerden beslenir. Bu da yerel yoğunluğun arttığı akşam saatlerinde ping sürelerinin 40 milisaniyeden birden 400 milisaniyeye sıçramasına yol açar. Bir mekana yerleşmeden önce doğrudan sunucunuza veya toplantı yaptığınız ana omurgaya ping atmak en dürüst sonucu verir.

ping -c 20 8.8.8.8
traceroute 1.1.1.1

Rezervasyon Tüyosu: Ev sahibinden genel bir hız testi yerine, çalışma saatlerinde (özellikle 14:00 – 16:00 arasında) alınmış, ping ve jitter değerlerini açıkça gösteren anlık bir ekran görüntüsü talep edin. Çoğu bütçe dostu ev sahibi bu isteği garipsemeyecek, aksine ne istediğini bilen bir kiracı olduğunuz için size dürüst davranacaktır.

Elektrik Şebekesi Günlük Hayatı Kaldırabiliyor mu?

Akdeniz çanağındaki küçük yerleşimlerde veya Balkanlar’ın sakin köylerinde elektrik kesintileri hala bir hava durumu olayı gibidir. Hafif bir fırtına koptuğunda ya da yaz aylarında herkes klimalara yüklendiğinde trafolar iflas eder. Karadağ’ın Kotor körfezindeki taş evlerde ya da Likya kıyılarındaki şirin pansiyonlarda konaklarken haftada en az iki kez voltaj dalgalanması yaşamanız işten bile değildir.

Bu gibi yerlerde kalacaksanız dizüstü bilgisayarınızın bataryasına güvenmek yetmez, modemin de açık kalması gerekir. Eğer bölgede sık sık planlı veya plansız kesintiler oluyorsa, konaklama bütçenizi belirlerken yerel bir jeneratörün varlığını sorgulamak zorundasınız. Günde üç saati aşan kesintiler, tüm iş gününüzü çöpe atabilir.

Ekipman Notu: 30 ile 45 Euro bandında bulabileceğiniz küçük bir mini DC-UPS, modeminizi 4 saate kadar ayakta tutar. Böylece ana şebeke çökse bile dizüstü bilgisayarınızın piliyle birlikte kesintisiz çalışmaya devam edebilirsiniz.

Mobil Veri Gerçekten Kurtarıcı Bir Yedek mi?

Sabit internet çöktüğünde hemen telefonun kişisel erişim noktasını açma planı yapıyorsanız, coğrafi engelleri hafife alıyorsunuz demektir. Yüksek tepelerin arasına sıkışmış koylar veya kalın taş duvarlı tarihi yapılar, hücresel sinyalleri adeta bir Faraday kafesi gibi emer. İçeride telefonun tek diş çektiği bir odada, mobil veriyle dosya yüklemeye çalışmak tam bir sabır sınavıdır.

Rotanıza varmadan önce mutlaka yerel baz istasyonu haritalarını inceleyin. Örneğin Tiflis merkezinden 25 dakikalık bir taksi yolculuğuyla ulaşabileceğiniz yarı kırsal bölgelerde yerel operatörler mükemmel 4G hızları sunarken, aynı mesafeyi Dalaman Havalimanı’ndan Fethiye’nin arka vadilerine doğru 40 dakikalık bir minibüsle gittiğinizde telefonunuz tamamen servis dışı kalabilir. Yerel bir SIM karta 15-20 Euro harcamak, işinizin ortasında bağlantısız kalmaktan katbekat daha ucuzdur.

Akustik ve Ergonomi: Kafe Masasında Kaç Saat Oturabilirsiniz?

Instagram fotoğraflarında rustik bir ahşap taburede kahvesini yudumlayarak tasarım yapan gezginler harika görünür. Ancak gerçek hayatta, o bel desteği olmayan sert ahşap sandalyede dört saatten fazla oturmak omurganıza kalıcı hasar verebilir. Ayrıca yerel kafeler, öğleden sonra kalabalıklaştığında arka planda espresso makinesi tıslamaları ve yüksek sesli müzikle birleşerek açık bir çağrı merkezine dönüşür.

Kiraladığınız odada çalışma masası olarak sunulan şeyin aslında bir makyaj masası mı yoksa gerçek bir çalışma alanı mı olduğunu teyit edin. Masanın yüksekliği, sandalyenin formu ve prizlerin konumu sandığınızdan çok daha önemlidir. Günde 8 saat çalışıp ardından kasabayı keşfetmek istiyorsanız, bel ağrısıyla yatakta kalmayı göze alamazsınız.

Bütçe Tüyosu: Eğer ev ortamı ergonomik değilse, civardaki kütüphaneleri veya yerel belediyelerin ücretsiz çalışma alanlarını araştırın. Günde 10-15 Euro coworking space ücreti ödemek yerine, çoğu Avrupa ve Balkan şehrinde yerel halkın kullandığı sessiz alanlar bütçenizi ciddi şekilde korur.

Yerel Ağda Sansür, Port Kısıtlaması veya DPI Var mı?

Her ülke internet özgürlüğüne aynı pencereden bakmaz. Bazı bölgelerde devlet düzeyinde uygulanan Deep Packet Inspection (DPI) mekanizmaları, kullandığınız kurumsal VPN protokollerini (örneğin WireGuard veya OpenVPN) sessizce yavaşlatır ya da tamamen engeller. Şirket ağınıza bağlanamadığınız an, dünyanın en ucuz ve en güzel sahilinde olmanızın profesyonel anlamda hiçbir değeri kalmaz.

Aynı şekilde bazı pansiyonlar ve butik oteller, misafirlerin bant genişliğini sömürmesini engellemek için torrent portlarını, streaming servislerini hatta bazen bulut depolama sync protokollerini router seviyesinde kısıtlar. Bu durum, büyük tasarım dosyalarını veya kod depolarını senkronize ederken karşınıza aşılmaz bir duvar olarak çıkar. Yola çıkmadan önce hedef ülkenin dijital sansür geçmişini ve ağ kısıtlamalarını içeren bağımsız forumları okumak bu seyahat rehberi yaklaşımının temel kuralıdır.

İyi bir çalışma tatili, iyi planlanmış bir teknik altyapı üzerine kurulur. Manzaranın tadını çıkarmak, ancak teslim tarihlerinizi stressiz bir şekilde yakalayabildiğinizde mümkündür. Sırt çantanızı hazırlamadan önce bağlantınızı güvenceye alın; geriye sadece iş bittiğinde denize atlamak kalsın.

Category: Genel | LEAVE A COMMENT
Ekim 3 2026

AI Kodlama Maliyetini Düşürme: Token Kullanımını Optimize Etme Rehberi

Yazılımcılar olarak son bir yıldır yeni bir refleks edindik: Bir fonksiyon yazarken takıldığımızda ya da sıkıcı bir CRUD operasyonu kapıya dayandığında hemen kısayol tuşuna basıp yapay zekayı yardıma çağırıyoruz. Fakat ay sonu kredi kartı ekstresinde ya da ekip dashboard’unda beliren o sürpriz bulut maliyetleri, keyfimizi bir anda kaçırabiliyor. AI kodlama yaparken çoğumuz ne kadar devasa bir veri hacmini her seferinde modele yolladığımızı fark etmiyoruz. İşte bu yazıda, geliştirme hızımızı zerre düşürmeden token optimizasyonu yapmanın ve cüzdanı rahatlatmanın denenmiş yollarını masaya yatırıyoruz.

Token Mantığı: Bu Sayaç Neden Bu Kadar Hızlı Dönüyor?

Bilmeyenler veya “token tam olarak neydi ya?” diyenler için en basit tanımı yapalım: Büyük dil modelleri (LLM) kelimeleri bizim gibi harf harf değil, “token” adını verdikleri hece veya karakter öbekleri halinde okur. Ortalama olarak 1000 token, yaklaşık 750 İngilizce kelimeye (Türkçe’de ek yapısından ötürü biraz daha azına) denk gelir.

Asıl tuzak şu: Bir sohbet uzadıkça, Claude veya GPT her yeni cümlenizde geçmiş konuşmaların tamamını tekrar okur. Yani model hafızaya sahip değildir; hafıza yanılsaması, geçmişin her istekte (request) baştan sona yeniden gönderilmesiyle (Context Window) sağlanır. Projenin 500 satırlık bir dosyasını AI’a verip 10 soru sorduğunuzda, o 500 satırı modele 10 defa baştan okutmuş ve parasını 10 defa ödemiş olursunuz.

[Görsel: Cursor veya VS Code arayüzünde context token sayacının soru sordukça katlanarak arttığını gösteren panel ekranı]

Context Penceresi Tuzağı ve .cursorignore Kurtarıcısı

Cursor, Windsurf ya da Copilot Workspace gibi modern AI kodlama araçları projenizi “indeksler”. Siz bir soru sorduğunuzda arkada akıllı bir vektör araması yapar ve alakalı gördüğü dosyaları context’e (bağlama) ekler. Harika bir özellik, değil mi? Teoride evet, pratikte ise tam bir bütçe canavarı.

Çünkü araç çoğu zaman test log’larını, build çıktılarını, package-lock.json gibi binlerce satırlık dosyaları da bağlama dahil eder. Bunu engellemenin en temiz yolu, projenizin kök dizinine bir .cursorignore (veya kullandığınız araca özel yoksayma dosyası) eklemektir:

# Gereksiz dosyaları AI context'inden uzak tutun
dist/
build/
node_modules/
*.log
package-lock.json
pnpm-lock.yaml
coverage/

Sadece şu küçük dosya bile tek bir sorguda bağlama giden token sayısını %40 ila %60 oranında azaltabiliyor. Denediğimiz bir projede, sırf kilitli bağımlılık dosyalarının context dışı bırakılmasıyla 200k context limitine dayanan sorguların 30k seviyesine gerilediğini bizzat ölçtük.

Prompt Engineering ile Akıllı Token Diyeti

Yapay zekaya soru sorarken edebiyat yapmayı bırakmamız gerekiyor. Doğru prompt engineering teknikleri yalnızca daha iyi kod üretmekle kalmaz, gidiş-dönüş maliyetini de doğrudan kısar.

1. “Bütün Dosyayı Yeniden Yazma” Kuralı

LLM faturalarında en pahalı kısım girdi (input) değil, çıktı (output) token’larıdır. OpenAI ve Anthropic modellerinde çıktı token’ları genellikle girdiden 3 ila 5 kat daha pahalıdır. Bir fonksiyonda hata ayıklarken modele “Bunu düzelt” derseniz, size 400 satırlık dosyanın tamamını tekrar yazar. Bunun yerine şunu deneyin:

“Sadece değişen fonksiyonu ver, dosyanın tamamını yazdırma.” veya “Yalnızca Git diff formatında göster.”

Bu ufak dokunuş, tek bir yanıtta 2000 output token tasarrufu demektir.

2. Doğrudan Referans Verme (@ Dosya Adı)

Aracın tüm codebase üzerinde körlemesine arama yapmasına izin vermek yerine, ilgili dosyayı doğrudan işaret edin. Cursor veya modern eklentilerde @UserAuth.ts şeklinde hedef göstermek, arka plandaki arama token’larını sıfıra indirir.

[Görsel: İyi optimize edilmiş bir prompt ile savruk bir prompt’un harcadığı token miktarlarını yan yana gösteren karşılaştırma grafiği]

Fiyat Tablosu: Hangi Model Ne Kadar Yakıyor?

Piyasadaki popüler modellerin maliyet profilleri ciddi şekilde farklılaşıyor. 2025 başı itibarıyla kabaca tablo şu şekilde:

Model Girdi (1M Token) Çıktı (1M Token) Öne Çıkan Özellik
Claude 3.5 Sonnet $3.00 $15.00 Kodlamada endüstri standardı, yüksek kavrayış
GPT-4o $2.50 $10.00 Hızlı ve dengeli performans
DeepSeek V3 / R1 ~$0.14 – $0.55 ~$0.28 – $2.19 Fiyat/performans canavarı, açık ağırlıklı
Yerel Model (Llama 3, Ollama) $0.00 $0.00 Kendi donanımınız (Sıfır bulut maliyeti)

Agresif Token Tasarrufunun Artıları ve Eksileri

Her şeyi aşırı kısmak da her zaman en iyi çözüm olmayabilir. Dengeyi iyi kurmak şart.

Avantajlar (Artılar) Dezavantajlar (Eksiler)
Aylık API faturalarında %50’ye varan düşüş Model bazen eksik context nedeniyle “halüsinasyon” görebilir
Daha hızlı yanıt süreleri (Latency düşer) Geliştiricinin prompt yazarken daha dikkatli düşünmesi gerekir
Gürültüden arınmış, net ve nokta atışı yanıtlar Büyük çaplı mimari refactor işlerinde parça parça ilerlemek zorlaşabilir

Cüzdan Dostu Alternatifler: Ne Yapmalı?

Eğer kurumsal bir bütçeniz yoksa ve kendi cebinizden ödüyorsanız izleyebileceğiniz üç somut yol var:

  1. Prompt Caching Kullanın: Anthropic ve OpenAI’ın sunduğu “Prompt Caching” özelliğini destekleyen eklentileri tercih edin. Proje bağlamı önbelleğe alındığında, tekrarlayan girdilerde %90’a varan indirim sağlanıyor.
  2. Continue.dev Eklentisine Geçin: VS Code için tamamen açık kaynaklı ve ücretsiz olan Continue.dev eklentisini kurup, arka plana DeepSeek API’sini bağlayabilirsiniz. Claude kalitesine çok yakın kodlamayı neredeyse onda biri fiyatına getirirsiniz.
  3. Lokal Modellere Şans Verin: Bilgisayarınızda güçlü bir Apple Silicon (M serisi) işlemci veya en az 16GB VRAM’li bir Nvidia kart varsa, Ollama üzerinden Qwen 2.5 Coder çalıştırın. Günlük ufak işler, test yazımları ve regex açıklamaları için buluta tek kuruş ödemenize gerek yok.

Sonuç: Kontrolü Modele Bırakmayın

Yapay zeka araçları inanılmaz bir kaldıraç gücü sunuyor, ancak onları “nasılsa otomatik hallediyor” diyerek tamamen serbest bırakmak ay sonunda tatsız sürprizler doğurabiliyor. Context dosyalarınızı temiz tutmak, gereksiz log ve kütüphaneleri dışlamak ve yanıtları diff formatında istemek gibi basit alışkanlıklar, geliştirme deneyiminizden ödün vermeden faturalarınızı kontrol altında tutmanızı sağlar.

Category: Genel | LEAVE A COMMENT
Ekim 3 2026

LLM Orchestration: LangChain Yerine Neden Haystack veya LlamaIndex Seçmelisiniz?

Kendi yapay zeka uygulamanızı geliştirmeye karar verdiğinizde ilk karşınıza çıkan araç muhtemelen LangChain olur. Günümüzün hızlı tempolu ai development dünyasında, bir llm (büyük dil modeli) ile harikalar yaratmak istiyorsanız bir orkestrasyon aracına ihtiyacınız var. Ancak LangChain tek ve her zaman en iyi seçenek mi? Pratikte işler prototip aşamasından çıkıp gerçek dünyaya adım attığında, tablo epey değişiyor.

Bu yazıda LangChain, Haystack ve LlamaIndex üçlüsünü laboratuvar masasına yatırdım. Sözleri değil, pratikteki davranışları karşılaştırdım. Hangisi hangi senaryoda hayat kurtarır, hangisi saç baş yoldurur? Gelin yakından bakalım.

Önce Temel Soru: “LLM Orchestration” Neden Var?

Bir dil modeline basitçe soru sorup cevap almak için bir framework’e ihtiyacınız yok; basit bir API çağrısı yeterli. Sorun şu: Model şirketinizin iç dokümanlarını bilmiyor, hafızası sınırlı, harici veri tabanlarına bağlanması gerekiyor ve bazen adım adım mantık yürütmek zorunda.

İşte orchestration burada devreye giriyor. Orkestra şefi gibi; veriyi alır, parçalar, vektör veri tabanına gömer, doğru bağlamı LLM’e iletir ve nihai yanıtı kullanıcıya sunar. Bu sürece genel olarak RAG (Retrieval-Augmented Generation) diyoruz.

[Görsel: RAG mimarisinin veri kaynağından LLM yanıtına kadar olan adımlarını özetleyen sade bir akış şeması]

LangChain: İsviçre Çakısı Sendromu

LangChain, bu ekosistemin tartışmasız popüler çocuğu. Neredeyse her yeni çıkan aracı ilk gün destekler, topluluğu devasadır ve aklınıza gelebilecek her entegrasyona sahiptir.

Fakat bir sorun var: Aşırı soyutlama (over-abstraction).

Basit bir zincir (chain) kurmak harika hissettirir. Ancak üretim ortamında o zincirin ortasında bir hata aldığınızda, beş katman derinlikteki kütüphane kodlarının içinde kaybolursunuz. LangChain sık sık kırıcı güncellemeler (breaking changes) yapar. Üç ay önce yazdığınız kodun bugün çalışmama ihtimali hiç de az değil. Kısacası: Prototip çıkarmak için mükemmel, ama kurumsal ölçekte stabilite arıyorsanız riskli.

LlamaIndex: Verinizle Konuşmanın En Zarif Yolu

Eğer projenizin kalbinde veriyi doğru aramak ve bulmak yatıyorsa, LlamaIndex sahneye çıkmalı. Eskiden adı GPT Index olan bu araç, özellikle dokümanları parçalama, indeksleme ve sorgulama üzerine odaklanmış bir veri çatısıdır.

Gerçek Senaryo: 500 Sayfalık Finans Raporları

LangChain ile 500 sayfalık karmaşık tablolar ve dipnotlar içeren PDF dosyalarını sorgulamaya kalktığınızda, parçalama (chunking) mantığını baştan inşa etmeniz gerekir. LlamaIndex ise doğrudan bu problem için doğdu.

from llama_index.core import SimpleDirectoryReader, VectorStoreIndex

# Dokümanları oku ve otomatik indeksle
documents = SimpleDirectoryReader("raporlar").load_data()
index = VectorStoreIndex.from_documents(documents)

# Doğrudan akıllı sorgu motoruna çevir
query_engine = index.as_query_engine()
response = query_engine.query("2023 4. çeyrek operasyonel kârı ne kadar?")
print(response)

LlamaIndex, veriyi hiyerarşik olarak indeksler. Yani sorunuza yanıt ararken sadece en yakın metin bloğunu değil, dokümanın genel bağlamını da hesaba katar. “Gelişmiş RAG” yapacaksanız ilk durağınız burası olmalı.

Haystack: Kurumsal Dünyanın Sessiz Tankı

deepset tarafından geliştirilen Haystack, gösterişten uzak ama inanılmaz derecede sağlam bir framework. Haystack 2.0 ile birlikte baştan aşağı yenilenen boru hattı (pipeline) mimarisi, onu kurumsal projeler için açık ara en güvenli liman haline getirdi.

Haystack’in en büyük artısı: Grafik tabanlı, açık ve öngörülebilir olması. Bir pipeline kurduğunuzda hangi bileşenin (component) hangi girdiyi alıp hangi çıktıyı verdiğini tam olarak bilirsiniz. Sihirli siyah kutular yoktur; ne yazdıysanız o çalışır.

[Görsel: Haystack 2.0 pipeline arayüzünde bileşenlerin birbirine bağlanışını gösteren teknik ekran görüntüsü]

Neden Haystack?

  • Hata Ayıklama (Debugging) Kolaylığı: Hatanın nerede koptuğunu anında yakalarsınız.
  • Geleneksel Arama ile Hibrit Yaklaşım: Yalnızca vektör araması değil, Elasticsearch ve OpenSearch gibi BM25 tabanlı anahtar kelime aramalarıyla harmanlamada en olgun araçtır.
  • Üretim Odaklılık: Kod tabanı istikrarlıdır. Haftada bir tüm mimariyi değiştiren radikal kararlar almazlar.

Doğrudan Karşılaştırma

Hangisini ne zaman seçmeniz gerektiğine dair pratik bir özet tablosu hazırladım:

Özellik LangChain LlamaIndex Haystack
Ana Odak Genel amaçlı ajanlar ve prototipler Derinlemesine RAG ve veri işleme Üretime hazır arama ve kurumsal pipeline
Öğrenme Eğrisi Başlangıç kolay, uzmanlaşma kaotik Orta seviye Orta, mimarisi oldukça mantıklı
Stabilite Düşük (hızlı değişiyor) Orta – İyi Çok Yüksek
Topluluk & Eklenti Çok Geniş Geniş ve Hızla Büyüyor Daha niş ama odaklı kurumsal kitle

Fiyatlandırma ve Ücretsiz Alternatifler

Bahsettiğim üç framework’ün çekirdek kütüphaneleri de tamamen açık kaynaklı ve ücretsizdir (Apache 2.0 veya MIT lisanslarıyla dağıtılır). Kendi sunucunuzda tek kuruş ödemeden çalıştırabilirsiniz.

Maliyet yaratan kısım, bu yapıların üzerine kurulan bulut izleme ve veri yönetim araçlarıdır:

  • LangChain ekosistemi: Pipeline takibi için LangSmith kullanır (ücretsiz katmanı küçük projeler için yeterli, kurumsal için ücretli).
  • LlamaIndex ekosistemi: Kurumsal veri ayrıştırma için LlamaCloud ve LlamaParse sunar (günlük belirli sayfa sayısı ücretsiz, sonrasında kullandıkça öde).
  • Haystack ekosistemi: Bulut ortamında tam yönetilen hizmet için deepset Cloud adında kurumsal bir platforma sahiptir.

Tamamen yerel (on-premise) kalmak istiyorsanız; Ollama ile yerel LLM’leri çalıştırıp, vektör veri tabanı olarak Qdrant veya Chroma kullanarak sıfır maliyetle bu araçların tümünü deneyimleyebilirsiniz.

Sonuç: Hangisini Tercih Etmelisiniz?

Bir hackathon’daysanız ya da aklınıza gelen bir fikri hafta sonu hemen test etmek istiyorsanız, zengin entegrasyon havuzu nedeniyle LangChain hâlâ pratik bir kestirmedir.

Ancak derdiniz binlerce karmaşık PDF’i, tabloyu ya da SQL verisini LLM’e en doğru bağlamla yedirmekse hiç düşünmeden LlamaIndex tercih edin.

Eğer kurumsal bir yapıda, canlıya çıktığında patlamayacak, bakımı kolay, performansı izlenebilir bir arama veya soru-cevap sistemi inşa ediyorsanız adresiniz kesinlikle Haystack olmalıdır. AI dünyasında gösterişli olan değil, ayakta kalan kazanır.

Category: Genel | LEAVE A COMMENT
Ekim 2 2026

Ölçeklenen Altyapılarda Observability Maliyetini Yönetme: FinOps ve Sampling Stratejileri

Ay başında Datadog, New Relic veya AWS CloudWatch faturası geldiğinde dashboard’lardaki p99 gecikme grafiklerinden daha hızlı yükselen tek bir metrik vardır: Finans direktörünün nabzı. Modern bir DevOps mimarisinde mikroservislerin sayısı ve trafik hacmi arttıkça, observability altyapısının maliyeti çoğu zaman production ortamının compute maliyetini geride bırakır. Sistemin kör noktalarını kapatmak isterken bütçeyi tüketmek sürdürülebilir değil. Doğru bir FinOps yaklaşımı ve akıllı log yönetimi stratejileriyle, sistem görünürlüğünden ödün vermeden veri hacmini %60 ila %80 oranında düşürmek mümkün.

Fatura Neden Şişer? Görünmez Maliyet Kalemleri

Kıdemli mühendislerin sıkça düştüğü tuzak şudur: “Her şeyi loglayalım, OpenSearch veya Loki’ye basalım; lazım olursa grep’leriz.” Trafiğiniz saniyede 100 istek seviyesindeyken bu kabul edilebilir bir tembelliktir. Ancak saniyede 50.000 request aldığınız anda bu alışkanlık bir bütçe felaketine dönüşür.

Maliyeti patlatan üç ana faktör vardır:

  • Sağlık Kontrolleri (Health Checks): Kubernetes liveness/readiness probları ve ALB ping’leri log havuzunuzun %30’unu oluşturabilir. HTTP 200 GET /healthz satırının size hata anında hiçbir faydası yoktur.
  • Yüksek Kardinalite (High Cardinality): Metrik etiketlerine (label) user_id, order_id gibi sınırsız varyasyonu olan değerler eklemek, time-series veritabanınızın (Prometheus/Mimir) bellek tüketimini ve ingest maliyetini katlar.
  • Head-Based Sampling Hataları: Tracing verisinde rastgele %5 sampling aldığınızda, sistemdeki asıl yakalamak istediğiniz 500 hatalarının ve p99 outlier’larının da %95’ini çöpe atarsınız. Geriye sadece gürültü kalır.

Log Yönetimi: Vector ile Edge Düzeyinde Filtreleme ve Dönüştürme

Logları merkezi sisteme göndermeden önce daemonset katmanında filtrelemek en ucuz ve en etkili çözümdür. Logstash veya Fluentd gibi JVM/Ruby tabanlı hantal çözümler yerine Rust ile yazılmış düşük ayak izli Vector bu iş için biçilmiş kaftandır.

Aşağıdaki Vector konfigürasyonunda üç kritik optimizasyon yapıyoruz: Başarılı health check’leri drop ediyoruz, hassas verileri tokenize ediyoruz ve kalan debug loglarını örnekliyoruz (sampling).

cat << 'EOF' > /etc/vector/vector.yaml
sources:
  kubernetes_logs:
    type: kubernetes_logs

transforms:
  filter_health_checks:
    type: filter
    inputs:
      - kubernetes_logs
    # HTTP 200 dönen healthz loglarını doğrudan çöpe at
    condition: '!includes(["/healthz", "/readyz", "/livez"], .message)'

  drop_noisy_debugs:
    type: filter
    inputs:
      - filter_health_checks
    # Log seviyesi DEBUG olanları %90 oranında sample et
    condition: |
      if .level == "debug" {
        random() < 0.1
      } else {
        true
      }

  sanitize_and_prune:
    type: remap
    inputs:
      - drop_noisy_debugs
    source: |
      # Gereksiz Kubernetes metadata alanlarını temizle
      del(.kubernetes.pod_labels)
      del(.kubernetes.pod_annotations)
      
      # Kredi kartı gibi hassas verileri maskele
      .message = replace(.message, r'[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}', "[REDACTED_CC]")

sinks:
  elasticsearch_out:
    type: elasticsearch
    inputs:
      - sanitize_and_prune
    endpoints:
      - "https://elasticsearch.internal:9200"
    mode: "bulk"
EOF

Neden böyle yaptık? Kubernetes metadata’sındaki pod annotation’ları production’da devasa JSON payload’ları üretir. Bunları edge katmanında del() fonksiyonu ile silmek, taşınan ve indekslenen veri boyutunu anında %25 azaltır.

Tracing Verisinde Tail-Based Sampling Stratejisi

Geleneksel distributed tracing araçları trace’in başlangıcında karar verir (Head-based sampling). Bir istek geldiğinde yazı tura atılır: %1 seçilirse tüm akış kaydedilir. Fakat istek sırasında bir mikroservis patlarsa ve siz o isteği sample etmediyseniz, elinizde hiçbir şey kalmaz.

Tail-based sampling, isteğin tamamlanmasını bekler. İstek hata aldıysa veya belirlenen latency eşiğini aştıysa trace’i %100 saklar; sorunsuz HTTP 200 yanıtlarını ise agresif bir şekilde eler.

Bunu OpenTelemetry (OTel) Collector katmanında şu şekilde konfigüre ediyoruz:

cat << 'EOF' > /etc/otelcol/config.yaml
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  tail_sampling:
    decision_wait: 10s
    num_traces: 10000
    expected_new_traces_per_sec: 2000
    policies:
      # 1. Kural: Status code ERROR olan tüm trace'leri eksiksiz tut
      - name: drop_errors_policy
        type: status_code
        status_code: { status_codes: [ ERROR ] }

      # 2. Kural: Süresi 1.5 saniyeyi aşan tüm yavaş istekleri yakala
      - name: latency_policy
        type: latency
        latency: { threshold_ms: 1500 }

      # 3. Kural: Kalan normal akıştan sadece %1 örnek al
      - name: probabilistic_policy
        type: probabilistic
        probabilistic: { sampling_percentage: 1.0 }

exporters:
  otlp/backend:
    endpoint: "tempo.monitoring.svc.cluster.local:4317"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling]
      exporters: [otlp/backend]
EOF

Bu konfigürasyonda OTel Collector, trace parçalarını decision_wait: 10s süresince bellekte tutar. Span ağacı tamamlandığında kuralları yukarıdan aşağıya değerlendirir. İstisna veya lag varsa diskte saklanır; yoksa veri hacmi anında %99 bastırılır.

Metriklerin Sessiz Katili: Kardinaliteyi Düşürme (Metric Relabeling)

Datadog veya Prometheus faturalarında metrik maliyetlerinin patlamasının temel nedeni “Custom Metrics” ve time-series patlamalarıdır. Bir metriğin kaç time-series ürettiğini şu formülle hesaplarız:

Total Time Series = (Değer_Sayısı_Label_A) * (Değer_Sayısı_Label_B) * (Değer_Sayısı_Label_C)

Eğer bir yazılımcı HTTP istek metriğine user_id veya rastgele UUID’ler içeren path eklediyse, o metrik saniyeler içinde 500.000 time-series üreterek bellek limitlerini vurur. Prometheus scrape konfigürasyonunda metric_relabel_configs kullanarak bu etiketleri ingest anında silmelisiniz:

scrape_configs:
  - job_name: 'api-gateway'
    kubernetes_sd_configs:
      - role: pod
    metric_relabel_configs:
      # Belirli yüksek kardinaliteli dinamik labelları drop et
      - action: labeldrop
        regex: '(user_id|client_ip|session_token)'
      
      # REST URL path'lerindeki UUID'leri regex ile normalize et
      - source_labels: [__name__, path]
        regex: 'http_requests_total;/api/v1/orders/[a-f0-9\-]+'
        target_label: path
        replacement: '/api/v1/orders/:id'

Yukarıdaki işlem yapılmadığında /api/v1/orders/a1b2-c3d4 ve /api/v1/orders/e5f6-g7h8 iki ayrı metrik olarak depolanır. Regex normalizasyonu sayesinde her iki istek de /api/v1/orders/:id altında birleşir; metrik tekilleşir ve time-series sayısı tek hanelere iner.

Veri Yaşam Döngüsü: Tiering ve Soğuk Depolama

SRE ekiplerinin yaptığı analizler, log sorgularının %92’sinin son 48 saat içinde yazılan verilere yapıldığını gösteriyor. 30 gün önceki bir INFO logunu pahalı NVMe disklerde tutmak safi kaynak israfıdır.

Loki veya Elasticsearch kullanırken iki katmanlı (hot/cold) saklama stratejisi kurgulayın:

  • Hot Tier (0-7 Gün): Hızlı sorgulama için NVMe diskler veya SSD blok depolama. Tam indeksleme açık.
  • Warm/Cold Tier (7-30 Gün): İndeksleri küçültülmüş, read-only modda çalışan uygun maliyetli HDD veya S3/GCS object storage katmanı.
  • Deep Archive (30+ Gün): Yalnızca regülasyon (KVKK/GDPR/PCI-DSS) gereği tutulması gereken veriler için S3 Glacier / GCS Archive lifecycle kuralları. İndeks yok, yalnızca ham gzip blokları.

Özet: FinOps Mühendisliği Bir Süreçtir

Observability sistemlerini optimize etmek, kör uçuş yapmak anlamına gelmez. Tam aksine, doğru sinyali yakalayıp gürültüyü (noise) elimine etmektir. Edge katmanında Vector ile gürültüyü kesin, APM tarafında tail-based sampling ile hatalara odaklanın ve scraping aşamasında kardinaliteyi regex ile dizginleyin. Bu üç adımı attığınızda, faturanız düşerken platformunuzun asıl sorunları tespit etme kabiliyeti katlanarak artacaktır.

Category: Genel | LEAVE A COMMENT
Ekim 1 2026

Slow Travel ve Verimlilik: 1 Aylık ‘Workation’ Lokasyonu Nasıl Seçilir?

Dizüstü bilgisayarını sırt çantasına atıp her üç günde bir şehir değiştiren o meşhur dijital göçebelerin Instagram filtrelerine aldanmayın. Bir kafenin sallanan masasında, şarj aletinin kablosu yetişmediği için iki büklüm çalışırken aynı zamanda arka planda “mutlaka görülmesi gereken 10 yer” listesini tüketmeye çabalamak bir özgürlük değil, sadece yeni nesil bir tükenmişlik sendromudur. İşte bu noktada workation kavramı, slow travel yani yavaş seyahat felsefesiyle kesiştiğinde gerçek bir yaşam tarzı haline geliyor. Bir şehri fethetmeye değil, o şehirde geçici bir hayat kurmaya gittiğinizde hem işler tıkırında gidiyor hem de banka hesabınız nefes alıyor.

Peki, haritayı önünüze açtığınızda o “mükemmel bir ayı” geçireceğiniz yeri nasıl seçeceksiniz? Salt Instagram estetiğine kapılmadan, hem üretken kalıp hem de yerel bir mahalleli gibi yaşamanın püf noktalarını konuşalım.

Hızlı İnternet Yetmez: Ergonomi ve Işık Tuzağı

Çoğu uzaktan çalışan gezginin ilk baktığı şey Speedtest ekran görüntüsüdür. Elbette 50 Mbps altındaki bir bağlantı Zoom toplantılarında yüzünüzü dondurur, kabul. Ancak kimse size o 100 Mbps fiber internetin, beli iki günde mahveden tahta bir tabure ve sehpa yüksekliğindeki bir masayla sunulduğunu söylemez. Bir ay boyunca haftada en az 30-40 saat mesai yapacağınızı unutmayın. Bel ağrısıyla boğuştuğunuz bir Barselona sabahı, inanın Kadıköy’deki ofis masanızı özletir.

Ev kiralarken fotoğraflara bir emlak müfettişi gibi yaklaşmanız şart. Çalışma masasının arkasında priz var mı? Doğal ışık ekrana dik mi vuruyor, yoksa ferah bir yan açıdan mı geliyor? Mutfak masasını çalışma alanı olarak gösteren ilanlara mesafeli durun; çünkü o sandalyeler bir saatlik akşam yemeği için tasarlanmıştır, tüm gün kod yazmak ya da rapor hazırlamak için değil.

İpucu: Rezervasyon yapmadan önce ev sahibine standart “İnternet hızlı mı?” sorusu yerine, “Rica etsem modemin yanında değil, çalışma masasından bir hız testi yapıp ekran görüntüsünü atabilir misiniz? Bir de sandalyenin sırt desteği var mı?” diye sorun. Bu soruya özenle yanıt veren ev sahipleri, genellikle konaklamanız boyunca da çözüm odaklı olur.

Bütçe Matematiği: Aylık Kalmanın Gücü

Seyahatte en büyük gider kalemi her zaman barınmadır. İşin içine slow travel girdiğinde ise ekonomi kuralları sizin lehinize işlemeye başlar. Airbnb ya da Flatio gibi platformlarda 28 gün ve üzeri aramalar yaptığınızda devreye giren %30 ile %50 arasındaki aylık indirimler, günlük fiyatı astronomik olan daireleri birdenbire makul bir seviyeye çeker.

Örneğin, Lizbon’un turist kaynayan merkezinde geceliği 90 Euro olan bir stüdyo daireye 2.700 Euro vermek akıl kârı değildir. Ancak merkezden trenle 20 dakika uzaklıktaki Carcavelos ya da Oeiras gibi banliyölere kaydığınızda, aylık bütçeniz 1.100 – 1.400 Euro bandına geriler. Üstelik sabahları okyanus kıyısında koşup, yerel pazardan haftalık 30-40 Euro’ya taze balık ve sebze alabileceğiniz bir düzene geçersiniz. Bulgaristan’ın Bansko kasabası kışın kayak merkezi olsa da bahar ve yaz aylarında aylık 350-500 Euro bandındaki stüdyolarıyla Avrupa’nın en bütçe dostu çalışma merkezlerinden birine dönüşür. Uçak biletine harcayacağınız parayı, orada geçireceğiniz bir ayın toplam giderlerine yaydığınızda, günlük maliyetiniz evinizdeki sabit giderlerden çok daha ucuza gelebilir.

Topluluk Olmadan Seyahat Yalnızlaştırır

Yalnız seyahat etmenin en romantik anlatılarında bile atlanan bir detay var: Yabancı bir ülkede, bütün gün ekrana bakıp akşam tek başınıza süpermarketten aldığınız sandviçi yemek bir süre sonra boğucu gelir. Bir lokasyonu “yaşanabilir” kılan en temel unsur, orada sizin gibi düşünen insanların varlığıdır. Bu yüzden gideceğiniz bölgede aktif bir coworking space veya yerel toplulukların buluştuğu kafeler olup olmadığını önceden tarayın.

Selanik’i ele alalım. Atina kadar kaotik değildir, yürünebilir bir şehirdir ve yerel halk inanılmaz sıcaktır. Şehir merkezindeki küçük ortak çalışma alanları aylık 120-160 Euro civarındadır. Buraya vereceğiniz para bir gider değil, yatırımdır. Çünkü yan masanızda oturan freelance bir tasarımcıyla içtiğiniz bir fincan freddo espresso, sizi o şehrin turist rotalarından çıkarıp yerlilerin bildiği saklı tavernalara götürür. İnsan bağları, verimliliğin en büyük tetikleyicisidir.

İpucu: Seyahatinizden iki hafta önce gideceğiniz şehrin dijital göçebe Facebook gruplarına veya Slack/Discord kanallarına dahil olun. “Nerede kalınır?” klişesi yerine “Haftada bir voleybol oynayan ya da akşam koşusuna çıkan bir grup var mı?” diye sorun. Gerçek topluluğa böyle ulaşırsınız.

Ritmi Yakalamak: 4 Saatlik Zaman Dilimi Kuralı

Eğer müşterileriniz veya ekibiniz Türkiye’de ya da Avrupa’daysa, kendinizi Bali’ye veya Tayland’a atmak kağıt üzerinde harika görünür. Fakat gece yarısı müşteri toplantısına girmek, sabahın köründe çalışıp öğleden sonrayı sersem gibi geçirmek üretkenliği baltalar. Workation yaparken zaman dilimi farkını en fazla 3-4 saatte tutmak altın kuraldır.

Kendi gününüzü bloklara bölün. Sabah 08:00 ile 12:00 arasını derin çalışmaya (deep work) ayırın. Öğle saatlerinde yerel bir fırından aldığınız börekle parkta 45 dakika geçirin, esnafla iki kelime sohbet edin. Kalan mesaiyi ikindiye kadar tamamlayıp laptop kapağını kapattığınızda, önünüzde keşfedecek koca bir akşam kalır. İşte yavaş seyahatin vaadi budur: Turist gibi koşturmazsınız, o sokakların ritmine karışırsınız.

Sonuçta mesele sadece başka bir coğrafyada çalışmak değil. Mesele, sabah uyandığınızda kahvenizi koyup pencereden baktığınız o yeni sokağın, zihninize daha önce hiç uğramamış taze fikirler fısıldamasını sağlamaktır.

Category: Genel | LEAVE A COMMENT
Eylül 27 2026

Yazılım Geliştirmede ‘Stage-Gated’ Disiplin: LLM Çıktılarını Kontrol Altına Alın

Modern yazılım geliştirme dünyasında artık hemen hepimiz bir LLM (Büyük Dil Modeli) ile yan yana kod yazıyoruz. İster Cursor kullanın ister Claude veya Copilot; yapay zekanın birkaç saniyede yüzlerce satır kod üretmesi büyüleyici bir his. Ancak dürüst olalım: O üretilen kodların arkasında bazen var olmayan kütüphane bağımlılıkları, sinsi mantık hataları ve ciddi güvenlik açıkları saklanıyor. Hızlı yazıyoruz ama arkamızı toplamaya çalışırken daha çok yoruluyoruz. İşte bu noktada modern yazılıma eski ama çok sağlam bir disiplin geri dönüyor: Stage-Gated yaklaşımı.

Bu yazıda, geleneksel mühendislikten ödünç aldığımız bu “aşamalı kapı” sistemini yapay zeka destekli bir pipeline içine nasıl entegre edebileceğimizi, bizzat kurup test ettiğim bir senaryo üzerinden anlatıyorum. Amacımız yapay zekayı yavaşlatmak değil; yapay zeka güvenliği standartlarından taviz vermeden kodu üretime (production) taşımak.

Şelale (Waterfall) Mezardan mı Çıktı? “Stage-Gated” Nedir?

Eski usul Waterfall (Şelale) metodolojisini hatırlarsınız: Bir faz bitmeden diğeri başlamaz, arada kalın onay kapıları bulunur. Çevik (Agile) dünyada bundan nefret ettik çünkü hızı kesiyordu. Fakat işin içine modeller ve tahmin edilemez çıktılar girince dengeler değişti.

Stage-Gated mekanizması, üretilen bir çıktının bir sonraki aşamaya geçebilmesi için belirli kriterleri (“kapıları”) geçmek zorunda olduğu bir filtreleme modelidir. Bir LLM’e “Bana şu API servisini yaz” dediğinizde kodu doğrudan ana dala (main branch) göndermezsiniz. Kod, tanımladığınız kapılardan sırayla geçer; herhangi bir kapıda takılırsa ya LLM’e düzeltmesi için geri fırlatılır ya da doğrudan reddedilir.

[Görsel: Bir LLM kod üretim pipeline’ının 4 aşamalı kapıdan (Sözdizimi, Güvenlik, Test, İnsan Onayı) geçişini gösteren şematik diyagram]

Test Masası: 4 Kapılı Bir Pipeline Mimarisi

Teoriyi bir kenara bırakıp işi pratiğe dökelim. Deneme amacıyla yerel ortamımda FastAPI ile basit bir servis geliştiren bir akış kurdum. Modeli (Claude 3.5 Sonnet) bir komut satırı aracıyla tetikledim ve kodu şu 4 kapıdan geçirdim:

Kapı 1: Sözdizimi (Syntax) ve Tip Kontrolü

LLM’ler bazen parantezleri unutur, bazen var olmayan metodları çağırır. İlk kapımız en ucuz ve en hızlı olanı: AST (Soyut Sözdizim Ağacı) kontrolü ve mypy tip denetimi. Modelin çıktısı bu aşamada Python tarafından derlenemiyorsa sonraki aşamaya geçiş izni verilmez.

Kapı 2: Statik Güvenlik Analizi (SAST)

Model, istemeden de olsa SQL Injection açığı üretmiş olabilir mi? Ya da hardcoded bir API anahtarı bırakmış mı? Bu kapıda açık kaynaklı statik analiz araçları (örneğin Semgrep veya Bandit) devreye girer. Güvenlik açığı tespit edilirse pipeline kırılır.

# Semgrep ile yerel pipeline kontrolü çalıştırma
semgrep scan --config auto --error ./generated_code/

Kapı 3: Otomatik Birim Testleri ve “Self-Healing”

İşte en sevdiğim bölüm. Eğer kod ilk iki kapıyı geçtiyse, önceden tanımlanmış test senaryoları (Pytest) çalıştırılır. Test başarısız olursa, test hata raporu otomatik olarak tekrar LLM’e gönderilir: “Kodun şu testten geçmedi, hata mesajı bu. Kodu tekrar düzenle.” Buna sektörde self-healing (kendi kendini onarma) döngüsü deniyor. En fazla 3 deneme hakkı tanıyoruz.

Kapı 4: İnsan Gözü (Human-in-the-Loop)

Bütün testlerden geçen kod bir Pull Request (PR) olarak açılır. Son kapı daima bir insandır. Ancak bu aşamaya gelen kod zaten sözdizimi, güvenlik ve temel iş kuralları açısından elendiği için inceleyen mühendisin harcadığı süre dakikalar yerine saniyelere iner.

[Görsel: GitHub Actions üzerinde çalışan Semgrep ve Pytest adımlarının yeşil tik aldığı, insan onayı bekleyen PR ekran görüntüsü]

Gerçek Bir Deney: SQL Injection Girişimi Kapıya Takılınca

Pipeline’ı test etmek için Claude’a bilerek hafif yönlendirici bir prompt verdim: “Kullanıcı ID’sine göre kullanıcı bilgilerini getiren ham SQL sorgulu bir fonksiyon yaz.”

Model, f-string kullanarak sorguyu birleştiren tipik bir güvensiz kod bloğu oluşturdu. Süreç şöyle işledi:

  • Kapı 1 (Syntax): Kod geçerli Python sözdizimine sahipti. Geçti.
  • Kapı 2 (Semgrep): Kırmızı alarm! python.lang.security.audit.sqli kuralı tetiklendi. Parametreli sorgu kullanılmadığı için kod derhal durduruldu.
  • Geri Besleme: Pipeline, Semgrep hata çıktısını prompt’a ekleyip modeli uyardı.
  • Sonuç: İkinci denemede model kodu SQLAlchemy ORM parametreli sorgusuyla düzeltti ve Kapı 2’den başarıyla geçti.

Artılar ve Eksiler: Bu Zahmete Değer mi?

Her güvenlik katmanı beraberinde bir sürtünme getirir. Karar vermenizi kolaylaştırmak için gözlemlerimi özetledim:

Avantajlar Dezavantajlar
Halüsinasyon kaynaklı bağımlılık ve hatalar sisteme sızamaz. CI/CD süreçleri biraz daha uzun sürer (ortalama +40-90 saniye).
Yapay zeka güvenliği şirket politikaları seviyesinde garantiye alınır. LLM API maliyetleri (tekrar denemeler yüzünden) %15-20 artabilir.
Kıdemsiz geliştiricilerin fark edemediği açıklar erken yakalanır. İlk kurulum ve doğru kural setlerini yazmak teknik efor ister.

Hangi Araçları Kullanabilirsiniz? (Fiyat ve Alternatifler)

Bu yapıyı kurmak için servet harcamanıza gerek yok. Açık kaynak dünyasında harika ücretsiz seçenekler mevcut:

  • Guardrails AI (Ücretsiz / Açık Kaynak): LLM çıktılarını belirli Pydantic şemalarına ve regex/güvenlik kurallarına zorlamak için biçilmiş kaftan. Kendi sunucunuzda tamamen ücretsiz çalıştırabilirsiniz.
  • Semgrep (Freemium): Statik kod analizi için sektör standardı haline geldi. Açık kaynak versiyonu CLI üzerinden yerelde veya GitHub Actions içinde tamamen ücretsizdir. Ekip yönetimi sunan Semgrep Cloud ise aylık kullanıcı başı yaklaşık $40 civarından başlar.
  • NeMo Guardrails (NVIDIA – Ücretsiz): Özellikle diyalog ve mantık akışlarını kısıtlamak isteyenler için geliştirilmiş güçlü bir açık kaynak kütüphane.
  • SonarQube Community Edition (Ücretsiz): Kod kalitesini ve teknik borcu ölçmek için kendi sunucunuza kurabileceğiniz ücretsiz alternatif.

Son Söz

Yapay zekanın kod yazma hızına hayran olmamak elde değil. Ancak kontrolsüz hız, teknik borç dağları ve güvenlik kabusları yaratır. Stage-gated yaklaşımı, Agile pratikleri yavaşlatmak için değil; yapay zekayı sorumsuz bir stajyerden güvenilir bir takım arkadaşına dönüştürmek için ihtiyacımız olan emniyet kemeridir. Henüz denemediyseniz, en azından bir GitHub Action içine basit bir linter + Semgrep kapısı koyarak ilk adımı atmanızı şiddetle tavsiye ederim.

Category: Genel | LEAVE A COMMENT
Eylül 27 2026

Geliştirici Mutfağı: Kan Şekerini Dengeleyen ve Brain Fog’u Engelleyen 15 Dakikalık Atıştırmalık

Saat öğleden sonra üç civarı. Ekranda çözülmeyi bekleyen can sıkıcı bir bug var ama kafanızın içi yoğun bir sis bulutu: Selam brain fog. Çekmecedeki gofret paketine uzanıp hızlı bir şeker patlaması aramak çok cezbedici görünse de, bu hamle kan şekerinizi hızla fırlatıp yarım saat sonra sizi derin bir zihinsel çöküşe (crash) sürükler. Oysa bilişsel verimlilik ve uzun vadeli zihinsel sağlık için ihtiyacınız olan şey basit: Doğru bir nutrition stratejisi ve gerçek bir brain food alternatifi olan pratik bir yemek çözümü.

Bugün mutfakta saatler harcamadan, kodunuz derlenirken hazırlayabileceğiniz “Tahinli ve Kakaolu Odak Topları” yapıyoruz. Pişirme yok, bulaşık derdi minimum.

Porsiyon: 10-12 adet (Yaklaşık 3 porsiyon)
Hazırlık Süresi: 10 dakika
Pişirme Süresi: 0 dakika

Neden Bu Kombinasyon? (Sisi Dağıtan Bilim)

Basit karbonhidratlar beyninize hızlı bir ödül verir ama bedelini ani odak kaybıyla ödetir. Bu tarifte yulafın sunduğu kompleks lifler glukozun kana yavaş karışmasını sağlar. Tahin ve fıstık ezmesindeki sağlıklı yağlar nöronlar arası iletişimi desteklerken, ham kakaodaki flavanoller beyne giden kan akışını artırır. Deniz tuzu ise ekran başında unuttuğunuz elektrolit dengesini yerine koyar.

Malzemeler

  • İnce öğütülmüş yulaf ezmesi: 1 su bardağı (Kompleks karbonhidrat tabanı)
  • Doğal fıstık ezmesi veya tahin: 3 yemek kaşığı (Şekersiz, katkısız)
  • Ham kakao: 1.5 yemek kaşığı (Antioksidan ve dopamin desteği)
  • Chia tohumu: 1 yemek kaşığı (Omega-3 ve lif kaynağı)
  • Akçaağaç şurubu veya ham bal: 1.5 yemek kaşığı (Düşük glisemik indeksli tatlandırıcı)
  • İri çekim deniz tuzu: Küçük bir çimdik
  • Sıcak su veya badem sütü: 1-2 yemek kaşığı (Kıvamı bağlamak için gerekirse)

Evde Yoksa Ne Kullanabilirsiniz? (Alternatifler)

Mutfakta mutlak kurallar yoktur, refactoring serbesttir:

  • Fıstık ezmesi yerine fındık ya da badem ezmesi kullanabilirsiniz. Fıstık alerjiniz varsa sadece tahinle ilerleyin; tahinin susamdan gelen hafif buruk lezzeti kakaoyla harika uyum sağlar.
  • Chia tohumu yerine öğütülmüş keten tohumu koyabilirsiniz.
  • Elinizde ham kakao yoksa normal kakao da iş görür; ancak ham (raw) kakaonun polifenol oranı zihinsel uyanıklık için her zaman daha etkilidir.

Adım Adım Hazırlanışı

  1. Kuru malzemeleri harmanlayın: Geniş bir kasede yulaf ezmesi, ham kakao, chia tohumu ve deniz tuzunu bir kaşıkla karıştırın.
  2. Islak malzemeleri ekleyin: Karışımın ortasını hafifçe açıp fıstık ezmesini (veya tahini) ve balı ekleyin. Spatula veya çatalla ezerek birbirine yedirin.
  3. Kıvamı test edin: Karışımı elinizle sıkın. Birbirine tutunuyorsa tamamdır. Fazla kuru ve ufalanıyorsa, 1 yemek kaşığı ılık su veya süt ekleyip yoğurur gibi toparlayın.
  4. Porsiyonlayın ve yuvarlayın: Karışımdan ceviz büyüklüğünde parçalar koparıp avucunuzda sıkıca yuvarlayarak toplar haline getirin.
  5. Soğutun (Opsiyonel ama tavsiye edilir): Vaktiniz varsa buzdolabında 10 dakika dinlendirin. Vaktiniz yoksa doğrudan klavye başına geri dönebilirsiniz.

Püf Noktası

Bu tarifin sihirli dokunuşu deniz tuzudur. Tuzu kesinlikle atlamayın; tatlı-tuzlu kontrastı sadece lezzeti katlamakla kalmaz, kan basıncını dengeleyerek öğleden sonra gelen o rehavet hissini kırmaya yardımcı olur. Ayrıca bu topları hava almayan bir kapta buzdolabında 7 güne kadar saklayabilirsiniz. Pazar akşamı 10 dakikada yapın, hafta boyunca ‘Ne atıştırsam?’ stresini aradan çıkarın.

Category: Genel | LEAVE A COMMENT
Eylül 26 2026

Geliştiriciler İçin Tech Neck ve Göz Yorgunluğu: Fizyolojik Çözümler

O meşhur “flow state” anını hepimiz biliriz: Kod akıyor, testler yeşile dönüyor, Spotify arkada en sevdiğin lo-fi listesini çalıyor… Ta ki sandalyeden kalkmaya çalışıp boynundan sırtına inen o keskin sızıyı hissedene kadar. Masa başı çalışanlar, özellikle de geliştiriciler için tech-neck sendromu ve kronik göz yorgunluğu artık mesleğin fıtratından sayılmaya başlandı. Oysa vücudumuz, saatlerce çift monitör karşısında bir karides gibi kıvrılmak üzere evrimleşmedi.

Bugün hem boyun omurlarını rahatlatacak hem de ekranın arkasında unuttuğun gözlerini tazeleyecek pratik, bilimsel ve günlük 10 dakikanı alacak bir kurtarma planı hazırlıyoruz. Hazırsan, sandalyede dikleş ve okumaya devam et.

Kafan Neden Bu Kadar Ağır? (Tech Neck Fizyolojisi)

İnsan kafası dik bir duruşta yaklaşık 4,5 – 5,5 kilogram ağırlığındadır. Yani boyun kasların normal şartlarda ortalama bir bowling topunu dengede tutmakla görevlidir. Ancak ekranı daha iyi görmek için başını öne doğru her eğdiğinde, omurgaya binen yük katlanarak artar.

Omurga cerrahisi üzerine yapılan araştırmalar gösteriyor ki, başını sadece 45 derece öne eğdiğinde boyun omurlarına binen yük yaklaşık 22 kilograma, 60 dereceye çıktığında ise 27 kilograma fırlıyor. Yani gün boyu kod yazarken farkında olmadan boynunda 8 yaşında bir çocuğu taşıyorsun. Bu durum zamanla servikal disklerde aşınmaya, kronik kas spazmlarına ve nihayetinde boyun fıtığına kapı aralıyor.

Monitörler ve Yanan Kornealar: Göz Sağlığı (Eye Health) Neden Çöküyor?

Göz kuruluğu ve baş ağrısı da bu paketin bonus hediyesi. Normal bir insan dakikada ortalama 15 ila 20 kez göz kırpar. Bu hareket, gözün yüzeyini gözyaşı tabakasıyla kaplayarak korur ve net görmeyi sağlar.

Fakat bir ekrana odaklandığımızda göz kırpma sıklığımız yarı yarıya, bazen dakikada 5-7 sefere kadar düşüyor. Üzerine bir de monitörlerden yayılan mavi ışık, düşük kontrast ve yanlış aydınlatma eklenince; gün sonunda gözlerin yanması, odaklanma güçlüğü ve migren benzeri ağrılar kaçınılmaz hale geliyor.

Önemli Uyarı: Kollarında, parmaklarında uyuşma, karıncalanma veya güç kaybı hissediyorsan ya da gözlerinde ani görme kayıpları/ışık çakmaları oluyorsa egzersizleri bir kenara bırakıp vakit kaybetmeden bir uzmana veya nöroloğa/göz doktoruna danışmalısın.

10 Dakikalık Developer Wellness Kurtarma Protokolü

Haftada bir gün spora gidip iki saat ağırlık kaldırmak, haftanın geri kalan 40 saatinin omurgaya verdiği hasarı sıfırlamaz. Bize gereken şey: Mikro dozda tutarlılık. İşte çalışma masanın başında her gün uygulayabileceğin 10 dakikalık posture ve yenilenme rutini:

1. Boyun ve Üst Sırt İçin “Reset” (5 Dakika)

  • Chin Tucks (Çene Gömme): Sırtını dik tut. Başını arkaya doğru, sanki birisi sana kötü bir şey söylemiş de geri çekiliyormuşsun gibi kaydır (evet, o komik çift çene görüntüsü doğru yolda olduğunu gösterir). 5 saniye bekle, bırak. 10 tekrar yap. Bu hareket, zayıflayan derin boyun fleksörlerini güçlendirir.
  • Doorway Stretch (Kapı Eşiği Esnemesi): Ayağa kalk, bir kapı eşiğinde kollarını 90 derece bükerek eşiğe daya ve göğsünü öne doğru hafifçe it. Gün boyu klavyeye uzanmaktan kısalan pektoral (göğüs) kaslarını açarak omuzlarını geriye almanı sağlar. 30 saniye boyunca derin nefes alarak bekle.
  • Scapular Retraction (Kürek Kemiği Sıkıştırma): Omuzlarını kulaklarından uzaklaştır, kürek kemiklerinin arasında bir kalem varmış gibi onları birbirine doğru sık. 5 saniye tut, 10 kez tekrarla.

2. Gözleri Yeniden Başlat (2 Dakika)

  • 20-20-20 Kuralı: Her 20 dakikada bir, en az 20 fit (yaklaşık 6 metre) uzaktaki bir nesneye 20 saniye boyunca bak. Bu, gözün içindeki odaklanma kaslarını (siliyer kaslar) gevşetir.
  • Palming (Avuç İçi Terapisi): Ellerini birbirine sürtüp ısıt. Gözlerini kapat ve avuç içlerini göz çukurlarının üzerine baskı yapmadan kapat. Tamamen karanlıkta 1 dakika derin nefes al. Göz kaslarının ve sinir sisteminin anında sakinleştiğini hissedeceksin.

3. Alt Sırt ve Kalça Aktivasyonu (3 Dakika)

  • Seated Pelvic Tilt: Sandalyende dikleş. Belini önce içeri doğru çukurlaştır, ardından arkaya doğru yuvarlayarak kamburlaştır. Bu dalgalanma hareketi, saatlerce durağan kalan omurilik sıvısının ve kanın diskler arasında dolaşmasını sağlar. 15 tekrar yeterli.

Çalışma Alanını Hack’lemek: Temel Ergonomics

Egzersizler harika ama ortamı düzeltmezsen sürekli başa sararsın. Çalışma alanını ergonomics kurallarına göre ayarlamak sandığından çok daha basit:

Monitörünün üst kenarı tam olarak göz hizanda olmalı. Ekrana bakarken kafanı aşağı eğmek zorunda kalıyorsan, altına birkaç kalın kitap veya bir monitör standı koy. Dirseklerin ve dizlerin masa/sandalye temasında yaklaşık 90 derecelik açıyı korumalı, ayak tabanların yere tam basmalı.

Unutma: Mükemmel bir oturuş pozisyonu yoktur; en iyi duruş, bir sonraki duruşundur. Vücudun hareketsiz kaldıkça paslanır. Pomodoro aralarına bu mikro molaları ekle; hem yazdığın kodun kalitesi artsın hem de günün sonunda başı dimdik duran bir geliştirici ol.

Category: Genel | LEAVE A COMMENT
Eylül 26 2026

Mutfakta ‘Lean Manufacturing’: 30 Dakikada 3 Günlük Sağlıklı Yemek

Toyota’nın fabrikalarında parça bekleme süresini sıfıra indiren o meşhur üretim felsefesini hiç akşam saat 8’de, karnınız guruldarken buzdolabının önünde çaresizce durduğunuz o anla bağdaştırdınız mı? Evet, meal prep yapmaktan bahsediyorum ama öyle pazar gününün 5 saatini feda ettiğiniz türden değil. Doğru bir mutfak yönetimi ve endüstriyel verimlilik teknikleriyle, sağlıklı beslenme rutini oluşturmak aslında sadece 30 dakikanızı alır.

Mutfaktaki en büyük “israf” (Japonların deyimiyle Muda) bulaşık, gereksiz hareketler ve çürüyen sebzelerdir. Bugün tek bir fırın tepsisi ve paralel iş akışıyla 3 günlük nefis bir baz hazırlıyoruz.

Genel Bilgiler

Porsiyon: 3 Öğünlük
Hazırlık Süresi: 10 Dakika
Pişirme Süresi: 20 Dakika

Gerekli Malzemeler: Esnek ve Modüler

Buradaki amacımız tek bir ana pişirme ile 3 farklı lezzet yakalamak. Evde ne varsa ona göre modifiye edebilirsiniz:

  • Protein tabanı: 500 gr tavuk göğsü (Alternatif: Küp doğranmış sert tofu veya 2 kutu süzülmüş haşlanmış nohut)
  • Sebze matrisi: 1 baş brokoli, 2 adet kapya biber, 1 adet kırmızı soğan (Alternatif: Kabak, mantar veya havuç)
  • Kompleks karbonhidrat: 1 su bardağı kinoa veya kuskus (Alternatif: Karabuğday ya da esmer pirinç)
  • Lezzet bağlayıcılar: 3 yemek kaşığı zeytinyağı, 1 tatlı kaşığı toz kırmızı biber, 1 çay kaşığı sarımsak tozu, tuz, karabiber
  • Hızlı sos: 2 yemek kaşığı tahin, yarım limonun suyu, 2 yemek kaşığı ılık su

30 Dakikalık ‘Sprint’ Hazırlık Adımları

  1. Hattı Başlatın (Pre-heat): Fırını 200°C’ye getirin. Kettle’da su kaynatın. Kinoa veya kuskusu küçük bir tencereye alın, üzerine sıcak suyu ve tuzu ekleyip kapağını kapatın; o kendi kendine demlensin.
  2. Tek Bıçak, Tek Tahta (Mise en place): Tahtaya önce sebzeleri alın, iri parçalar halinde doğrayın. Bıçağı yıkamadan hemen ardından tavukları lokmalık küpler halinde kesin. Çapraz bulaşmayı önlemek için sebze-protein sırasını asla şaşırmayın.
  3. Tepsi Bölümleme (Batching): Büyük bir fırın tepsisine yağlı kâğıt serin. Sol tarafa tavukları, sağ tarafa sebzeleri yayın. Üzerlerine zeytinyağı ve baharatları gezdirip elinizle hızlıca harmanlayın. Tepsiyi fırına sürün ve 20 dakikalık sayacı başlatın.
  4. Montaj ve Saklama: Fırın çalışırken tahin, limon ve ılık suyu küçük bir kavanozda çalkalayarak sosunuzu yapın. 3 adet saklama kabı çıkarın. Pişen kinoayı tabana paylaştırın. Fırından çıkan fırınlanmış sebze ve proteini kaplara eşitçe bölüştürün.

Püf Noktası: 3 Gün Aynı Şeyi Yememe Sanatı

Kimse üç gün üst üste birebir aynı tadı almak istemez; motivasyonu kıran şey tam olarak budur. Hazırladığınız baz aynı kalsa da kimliğini küçük dokunuşlarla değiştirin:

1. Gün: Hazırladığınız tahin sosu gezdirip ılık tüketin.
2. Gün: Kaba biraz soya sosu ve susam ekleyip Asya esintili bir bowl’a dönüştürün.
3. Gün: İçeriği bir lavaşın içine sarıp, biraz taze yeşillikle hızlı bir dürüme çevirin.

Mutfakta Sıfır İsraf: Just-in-Time Yaklaşımı

Buzdolabında unutulan sebzeler paranızın doğrudan çöpe gitmesidir. Bu tarifte kullandığınız brokolinin saplarını atmayın; ince dilimleyip tepsiye sebzelerin yanına ekleyin, harika karamelize olurlar. Sosu kaplara önceden dökmemek de bir diğer kuraldır; sosu daima yiyeceğiniz an ekleyin ki sebzeleriniz dolapta beklerken formunu ve diriliğini kaybetmesin.

Category: Genel | LEAVE A COMMENT