API entegrasyonunun temel mantığı

API, iki yazılım arasında önceden belirlenmiş kurallarla iletişim kurulmasını sağlayan bir arayüzdür. İstemci bir HTTP isteği gönderir, sunucu ise çoğunlukla JSON biçiminde bir yanıt döndürür. Bir hava durumu servisine şehir adı gönderildiğinde sıcaklık, nem ve rüzgâr bilgisi alınması buna örnektir.

En sık kullanılan HTTP metotları şunlardır:

Başarılı bir istek genellikle 200 durum koduyla cevaplanır. 404 kaynağın bulunamadığını, 401 kimlik doğrulamanın başarısız olduğunu, 429 ise istek sınırının aşıldığını belirtir.

Bir servisin güvenilirliğini basitçe başarı oranıyla ölçebiliriz:

Bu değer düşükse hata yönetimi, zaman aşımı ve yeniden deneme stratejileri geliştirilmelidir.

Kural tabanlı bot nasıl karar verir?

Kural tabanlı botlar makine öğrenmesi kullanmak zorunda değildir. Kararlar açıkça tanımlanan if, elif ve else koşullarıyla verilir. Örneğin sıcaklık $30^\circ C$ üzerindeyse bot kullanıcıyı sıvı tüketmesi için uyarabilir; sıcaklık $10^\circ C$ altındaysa mont önerebilir.

Kurallar fonksiyonlara ayrıldığında kodun okunabilirliği artar:

def hava_mesaji(sicaklik):
    if sicaklik >= 30:
        return "Hava çok sıcak, su içmeyi unutma!"
    elif sicaklik <= 10:
        return "Bugün mont iyi bir fikir olabilir."
    return "Hava oldukça dengeli görünüyor."

Bu fonksiyon sayısal sıcaklığı alır ve kullanıcıya gösterilecek mesajı üretir. Böylece veri çekme ve karar verme görevleri birbirinden ayrılır.

Telegram botuna API bağlamak

Python tarafında requests ile dış servise, python-telegram-bot ile Telegram API’sine bağlanabiliriz. Aşağıdaki örnek, /hava Ankara benzeri bir komutu işler:

import requests
from telegram import Update
from telegram.ext import Application, CommandHandler, ContextTypes

API_KEY = "HAVA_DURUMU_ANAHTARI"
BOT_TOKEN = "TELEGRAM_BOT_TOKEN"

async def hava(update: Update, context: ContextTypes.DEFAULT_TYPE):
    if not context.args:
        await update.message.reply_text("Kullanım: /hava Ankara")
        return

    sehir = " ".join(context.args)
    url = "https://api.openweathermap.org/data/2.5/weather"
    params = {"q": sehir, "appid": API_KEY, "units": "metric", "lang": "tr"}

    try:
        yanit = requests.get(url, params=params, timeout=10)
        yanit.raise_for_status()
        sicaklik = yanit.json()["main"]["temp"]
        mesaj = f"{sehir}: {sicaklik}°C\n{hava_mesaji(sicaklik)}"
    except requests.RequestException:
        mesaj = "Servise şu anda ulaşılamıyor. Biraz sonra tekrar dene."

    await update.message.reply_text(mesaj)

uygulama = Application.builder().token(BOT_TOKEN).build()
uygulama.add_handler(CommandHandler("hava", hava))
uygulama.run_polling()

timeout, uygulamanın sonsuza kadar yanıt beklemesini önler; raise_for_status() ise başarısız HTTP cevaplarını hataya dönüştürür. Gerçek projede anahtarlar kaynak koda yazılmamalı, ortam değişkenlerinde saklanmalıdır.

Otomatik veri çekme ve sağlamlık

Aynı yapı zamanlayıcıyla çalıştırılarak fiyat takipçisi, haber özetleyici veya stok alarmı yapılabilir. Ancak servislerin kullanım koşullarına, istek limitlerine ve robots.txt kurallarına uyulmalıdır. Gereksiz istekleri azaltmak için önbellekleme uygulanabilir. Başarısız denemelerde bekleme süresini $t_n = 2^n$ saniye artıran üstel geri çekilme yöntemi de servisin yükünü azaltır.

Sonuçta API veriyi getirir, algoritmik kurallar anlamlandırır, Telegram ise sonucu kullanıcıya ulaştırır. Bu üçlü birleştiğinde küçük bir kod parçası, günün her saati çalışan kullanışlı bir dijital asistana dönüşür.

``

Modelin temel işi: Sonraki parçayı tahmin etmek

Bir büyük dil modeli, en yalın hâliyle, önceki metin parçalarına bakarak sıradaki parçanın olasılığını hesaplar. Bu ilişki şöyle gösterilebilir:

Burada $x_t$ üretilecek yeni token, önceki tokenlar ise modele sunulan bağlamdır. Model, eğitim sırasında öğrendiği parametreleri kullanarak olası devamları puanlar. Dolayısıyla sohbet geçmişinde “Kedimin adı Zeytin” yazıyorsa, daha sonra gelen “Kedimin adı neydi?” sorusuna “Zeytin” cevabını vermesi şaşırtıcı değildir. Bilgi, çalışma belleğini andıran bağlam penceresinin içindedir.

Fakat bağlam penceresi temizlendiğinde modelin bu ayrıntıya erişimi kalmayabilir. Bir uygulama eski konuşmaları veritabanından getirip modele yeniden gönderiyorsa, hatırlayan taraf doğrudan model değil, onu çevreleyen yazılım sistemidir.

Hatırlıyormuş gibi yapan küçük bir sistem

Aşağıdaki örnek, “kalıcı hafızalı model” görüntüsünün basit bir sözlük ve bağlam oluşturma işlemiyle üretilebileceğini gösterir:

memory = {}

def remember(user_id, key, value):
    # Bilgiyi modelde değil, uygulamanın deposunda saklar.
    memory.setdefault(user_id, {})[key] = value

def build_prompt(user_id, question):
    # Eski bilgiyi yeniden modele sunulacak metne dönüştürür.
    facts = memory.get(user_id, {})
    context = "\n".join(f"{k}: {v}" for k, v in facts.items())
    return f"Bilinenler:\n{context}\n\nSoru: {question}"

remember("u42", "kedinin adı", "Zeytin")
print(build_prompt("u42", "Kedimin adı neydi?"))

Model yalnızca oluşturulan istemi görür. Buna rağmen kullanıcı açısından deneyim son derece kişiseldir: Sistem onu tanıyor gibidir. Bu ayrım, bilgisayardaki hesap makinesi simgesinin fiziksel bir hesap makinesi olmaması kadar basit; konuşmanın duygusal etkisi nedeniyle de bir o kadar kolay unutulabilirdir.

Bellek ile örüntü tanıma arasındaki felsefi sınır

Belleği yalnızca “geçmiş bilginin bugünkü davranışı etkilemesi” diye tanımlarsak, model parametreleri bir çeşit istatistiksel bellek sayılabilir. Eğitim verisi ağırlıklarda birebir cümleler hâlinde değil, dağıtılmış ilişkiler olarak iz bırakır. Kabaca modelin öğrenmesi şu optimizasyonla anlatılabilir:

Ancak insan belleği çoğu zaman daha güçlü ölçütler içerir: Bir olayın kişinin başına gelmiş olması, geçmişteki benlikle süreklilik kurması ve hatırlama eyleminin öznel bir niteliğe sahip olması. Model “Bunu hatırlıyorum” dediğinde bu ifade içsel bir anıya rapor vermek zorunda değildir; benzer diyaloglarda uygun görülen dilsel kalıbı üretmiş olabilir.

Üstelik insan belleği de kusursuz bir kayıt cihazı değildir. İnsanlar anıları yeniden kurar, ayrıntıları karıştırır ve boşlukları beklentilerle doldurur. Bu nedenle fark, “insan kaydeder, model tahmin eder” kadar keskin değildir. İkisi de geçmiş izlerden hareketle mevcut duruma uygun bir temsil oluşturabilir. Asıl tartışma, bu işlemin bilinçli bir özneye, kişisel tarihe ve deneyim sahipliğine ihtiyaç duyup duymadığıdır.

Pratik sonuç nettir: Bir modelin adınızı doğru söylemesini bilinç veya sadakat kanıtı saymamalıyız. Önce bağlamın, kayıt sistemlerinin ve kişiselleştirme katmanlarının nasıl çalıştığını sormalıyız. LLM’ler geçmişi yaşamış olmayabilir; fakat geçmişe sahipmiş gibi konuşmayı olağanüstü iyi taklit eder. Hafıza yanılsamasının gücü de tam burada yatar: Dilsel performans, zihinsel deneyimin kanıtı gibi görünür.

İdeal: Güvenmek Yerine Doğrulamak

Geleneksel internette kullanıcılar bir platformun kurallarına uyar. Hesabınız kapatılabilir, içeriğiniz silinebilir veya verileriniz satılabilir. Web3 yaklaşımında ise kurallar akıllı sözleşmelerle tanımlanır ve ağdaki birçok düğüm tarafından uygulanır.

Teorik olarak güven, tek bir kuruma değil dağıtık uzlaşmaya dayanır. Bir blokzincirde saldırganın sistemi değiştirebilmesi için yeterli doğrulama gücünü, token miktarını veya madencilik kapasitesini kontrol etmesi gerekir. Basitleştirilmiş biçimde saldırı maliyetini şöyle düşünebiliriz:

Dağılım ne kadar dengeliyse sistemi ele geçirmek o kadar zorlaşır. Fakat düğüm sayısının fazla olması, gücün otomatik olarak eşit dağıldığı anlamına gelmez.

Token Demokrasisi mi, Dijital Plütokrasi mi?

DAO sistemlerinde sık kullanılan model, bir tokenın bir oy sayılmasıdır. Bu yöntem kolaydır; ancak demokratik değildir. Çok token sahibi olan yatırımcı, sıradan binlerce kullanıcıdan daha fazla söz hakkı kazanabilir. Böylece zincir üzerinde şeffaf olan yönetim, ekonomik açıdan yoğunlaşmış kalır.

Bu yoğunluğu ölçmek için Herfindahl–Hirschman Endeksi kullanılabilir:

Buradaki $s_i$, her katılımcının toplam güç içindeki payıdır. Sonuç büyüdükçe güç daha az elde toplanmış demektir. Ayrıca Nakamoto katsayısı, sistemi bozmak için anlaşması gereken en az aktör sayısını gösterir. Binlerce doğrulayıcı bulunmasına rağmen üç büyük havuz çoğunluğu kontrol ediyorsa anlamlı sayı üçtür.

Aşağıdaki Python kodu token dağılımını inceleyerek HHI değerini ve yüzde 51’e ulaşan en küçük koalisyonu hesaplar:

def guc_analizi(bakiyeler):
    toplam = sum(bakiyeler)
    paylar = sorted((b / toplam for b in bakiyeler), reverse=True)

    hhi = sum(pay ** 2 for pay in paylar)
    birikim = 0

    for aktor_sayisi, pay in enumerate(paylar, start=1):
        birikim += pay
        if birikim >= 0.51:
            return hhi, aktor_sayisi

bakiyeler = [420, 250, 140, 90, 60, 40]
hhi, koalisyon = guc_analizi(bakiyeler)
print(f'HHI: {hhi:.3f}, kritik koalisyon: {koalisyon}')

Kod, görünen katılımcı sayısına aldanmak yerine ekonomik kontrolü ölçer. Yine de bir kişinin birden fazla cüzdan kullanabilmesi veya farklı adreslerin aynı kuruma ait olması analizi zorlaştırır.

Görünmeyen Merkezler

Merkeziyetsizlik yalnızca blokzincir katmanında değerlendirilmemelidir. Kullanıcının işlemini ağa taşıyan RPC sağlayıcısı, cüzdan uygulaması, alan adı servisi, stablecoin ihraççısı ve borsa hâlâ merkezi olabilir. Akıllı sözleşme durdurulamasa bile ona ulaşan web arayüzü kapatılabilir.

Ütopyadan Kullanışlı Bir Gerçekliğe

Web3 bütünüyle merkeziyetsiz değildir; fakat bütünüyle sahte de değildir. Açık kaynak istemciler, kendi düğümünü çalıştırma imkânı ve izinsiz işlem yapabilme önemli kazanımlardır. Asıl hata, merkeziyetsizliği bir açma-kapama düğmesi gibi görmektir.

Daha sağlıklı sistemler için doğrulayıcı çeşitliliği, karesel oylama, zaman kilitli yönetişim, açık kaynak arayüzler ve alternatif RPC bağlantıları desteklenmelidir. Sonuçta mesele merkezin tamamen yok olması değil, gücün denetlenebilir, terk edilebilir ve rekabete açık olmasıdır. Web3’ün gerçek sahibi de logosu en büyük proje değil; protokolü gerektiğinde kimseye izin sormadan kullanabilen topluluktur.

``

Paradoksun çekirdeği

Ekonomik açıdan otomasyonun amacı açıktır: Aynı çıktıyı daha az zaman, hata ve maliyetle üretmek. Bir görevin elle tamamlanma süresi $T_e$, otomatik çalışma süresi $T_o$, otomasyonu geliştirme maliyeti ise $G$ olsun. İşlem $n$ kez tekrarlanıyorsa otomasyon şu koşulda kazançlıdır:

Buradan başabaş noktası şöyle bulunur:

Ne var ki denklem, insanın işinden aldığı anlamı ölçmez. Programcının karar verme yetkisi, ustalık hissi ve ekip içindeki konumu bir hücreye kolayca yazılamaz. Otomasyonun teknik getirisi ölçülebilirken varoluşsal maliyeti çoğunlukla görünmez kalır.

Kod yazmak mı, kendini silmek mi?

Marx’ın yabancılaşma düşüncesinde çalışan, ürettiği şey üzerindeki kontrolünü kaybedebilir. Programcı için tuhaf olan, bu kontrol kaybını bizzat kodlamasıdır. Dün kendisinin yürüttüğü süreci bugün bir servis, yarın ise kimsenin nasıl çalıştığını tam hatırlamadığı bir sistem yönetir. Kod yaşamaya devam ederken yazarı organizasyon şemasından silinebilir.

Sartre’ın varoluşçuluğu ise insanın hazır bir özle doğmadığını, seçimleriyle kendini kurduğunu söyler. Bu açıdan “Ben rapor hazırlayan kişiyim” demek kırılgan bir kimliktir. Rapor otomatikleştiğinde öz de çöker. Daha dayanıklı tanım şudur: “Ben sorunları fark eden, sistem tasarlayan ve sonuçların sorumluluğunu alan kişiyim.” Görev ortadan kalkabilir; muhakeme bütünüyle ortadan kalkmak zorunda değildir.

Basit bir otomasyon örneği bile bu ayrımı gösterir:

from pathlib import Path


def eski_loglari_temizle(klasor, sinir):
    dosyalar = sorted(
        Path(klasor).glob("*.log"),
        key=lambda dosya: dosya.stat().st_mtime
    )

    for dosya in dosyalar[:-sinir]:
        print(f"Siliniyor: {dosya.name}")
        dosya.unlink()


eski_loglari_temizle("logs", 10)

Bu kod eski günlük dosyalarını silerek rutin bakım işini devralır. Ancak hangi kayıtların hukuki veya operasyonel açıdan saklanması gerektiğine karar vermez. Programcı parmak hareketlerini makineye aktarırken bağlamı, sınırları ve sorumluluğu elinde tutar. En azından sistem bilinçli tasarlanmışsa durum budur.

Asıl sorun otomasyon değil, paylaşım

Teknoloji tarihindeki temel çatışma “makine mi, insan mı?” değildir. Daha doğru soru, makinenin yarattığı zamanın kime ait olduğudur. Sekiz saatlik iş iki saate düşüyor ama çalışanın hedefi dört katına çıkıyorsa özgürleşme gerçekleşmez; yalnızca koşu bandı hızlanır. Kazanılan altı saat eğitim, yaratıcılık veya dinlenme için kullanılabiliyorsa otomasyon insani kapasiteyi genişletir.

Bu nedenle etik bir otomasyon sürecinde programcı üç soruyu sormalıdır:

1. Ortadan kaldırdığım görev mi, yoksa bir insanın pazarlık gücü mü?
2. Sistemin hatasında sorumluluk kimde kalacak?
3. Kazanılan zaman ve değer kimler arasında paylaşılacak?

Programcı kendini nereye koymalı?

Programcının güvenli yeri belirli bir araç, dil veya görev değildir. Bugünün vazgeçilmez framework’ü yarının nostaljik blog yazısı olabilir. Daha sağlam konum; problemi tanımlamak, varsayımları sorgulamak, insan sonuçlarını görmek ve gerektiğinde otomasyona “hayır” diyebilmektir.

Kendi işini otomatikleştirmek bu yüzden mesleki intihar olmak zorunda değildir. Eski rolün bilinçli biçimde terk edilmesi ve daha yüksek sorumluluğa geçiş olabilir. Fakat kurum yalnızca verimlilik kazancını sahiplenip insanı dışarıda bırakıyorsa paradoks acımasızlaşır: Programcı geleceği inşa eder, fakat gelecekte kendisine sandalye ayrılmadığını görür. Mesele kodun bizi gereksiz kılması değil; gereksizliğin ekonomik ve ahlaki tanımını kimin yazdığıdır.

Söz dizimi yalnızca gramer değildir

Bir programlama dilinin söz dizimi, hangi karakter dizilerinin geçerli programlar oluşturduğunu belirleyen kurallar bütünüdür. Örneğin aynı koşul farklı dillerde şöyle yazılabilir:

if temperature > 30:
    start_fan()

if (temperature > 30) {
  startFan();
}

İki örnek de aynı fikri anlatır: Sıcaklık 30’dan büyükse fanı çalıştır. Python girintiyle blok oluştururken JavaScript parantez ve süslü ayraç kullanır. Python daha hafif, JavaScript ise sınırları daha açık görünebilir. Hangisinin güzel olduğu, okuyucunun belirsizliğe mi yoksa sembol kalabalığına mı daha duyarlı olduğuna bağlıdır.

Bu algıyı basitleştirilmiş bir modelle ifade edebiliriz:

Burada $E$ estetik algıyı, $O$ okunabilirliği, $T$ tutarlılığı, $A$ aşinalığı ve $Y$ görsel yükü temsil eder. Katsayılar kişiden kişiye değişir. Yeni başlayan biri açıklığı ödüllendirirken deneyimli biri kısa ve yoğun ifadeleri tercih edebilir.

Aynı fikir, farklı görsel karakter

Örneğin Rust, türleri ve hata ihtimallerini görünür kılmayı sever:

fn divide(a: f64, b: f64) -> Result<f64, &'static str> {
    if b == 0.0 {
        return Err("Sıfıra bölme yapılamaz");
    }
    Ok(a / b)
}

Bu fonksiyon yalnızca bölme yapmaz; başarısızlık olasılığını Result türüyle sözleşmeye dönüştürür. İlk bakışta Python’daki kısa bir fonksiyondan daha ağırdır. Buna karşılık hata davranışının açık olması, bazı geliştiricilere mimari bir güzellik hissi verir. Demek ki kısalık her zaman zarafet değildir.

Beyin neden düzen arar?

İnsan zihni örüntüleri hızlı tanır. Benzer işlemlerin benzer biçimde yazılması bilişsel yükü azaltır. Bir dosyada fonksiyon çağrıları tutarlı, diğerinde zincirleme, iç içe ve rastgele biçimlendirilmişse dil değişmese bile estetik algı bozulur.

Şu zincir kısa olsa da yoğun olabilir:

const names = users.filter(u => u.active).map(u => u.name).sort();

Aynı işlem adımlara ayrıldığında veri akışı daha görünür hâle gelir:

const activeUsers = users.filter(user => user.active);
const names = activeUsers.map(user => user.name);
names.sort();

İlk sürüm akıcı ve kompakt, ikinci sürüm ise açıklayıcıdır. Estetik karar bağlama bağlıdır: Basit bir dönüşümde zincir zarifken karmaşık hata ayıklama sürecinde ara değişkenler daha güzel gelebilir.

Aşinalık, güzellik kılığına girebilir

Bir dili uzun süre kullandığımızda onun alışkanlıklarını doğal kabul ederiz. C geliştiricisi süslü parantezleri güven verici bulabilir; Python geliştiricisi aynı sembolleri gürültü sayabilir. Lisp’in çok sayıdaki parantezi yabancı bir göze çirkin görünürken deneyimli bir Lisp kullanıcısı, kod ile veri arasındaki simetriyi estetik bulur.

Bu nedenle söz dizimi estetiği tamamen nesnel değildir; fakat tamamen keyfî de değildir. Tutarlılık, düşük bilişsel yük, niyetin görünürlüğü ve araç desteği ölçülebilir faydalar sağlar. Biçimlendiriciler de tartışmayı azaltır: Black, Prettier veya rustfmt, kişisel tercihleri ortak bir görsel ritme dönüştürür.

Sonuçta güzel kod, en az karakterle yazılan değil; okuyucunun zihninde en az sürtünmeyle anlam kazanan koddur. İyi söz dizimi programcıya kendini sürekli hatırlatmaz. Geri çekilir, fikri öne çıkarır ve kodu noktalama işaretleriyle yapılan bir mücadeleden okunabilir bir anlatıya dönüştürür.

İşletim sistemi komutu çalıştırmanın mantığı

Bir terminale ls, ipconfig veya mkdir yazdığımızda kabuk, komutu yorumlayarak işletim sisteminden ilgili programı başlatmasını ister. Kod içerisinden komut çalıştırırken de benzer bir süreç gerçekleşir:

1. Ana program bir alt süreç oluşturur.
2. İşletim sistemi komutu ayrı bir süreçte yürütür.
3. Standart çıktı, hata çıktısı ve dönüş kodu ana programa iletilir.

Komutun başarılı olup olmadığını anlamak için çıkış kodu kullanılır. Genel kabul şöyledir: $E = 0$ başarıyı, $E \neq 0$ ise hata veya olağan dışı durumu temsil eder.

Python’da bunun için subprocess modülü tercih edilir:

import subprocess

komut = ["ping", "-c", "2", "example.com"]

try:
    sonuc = subprocess.run(
        komut,
        capture_output=True,
        text=True,
        timeout=10,
        check=True
    )
    print("Komut başarılı:")
    print(sonuc.stdout)
except subprocess.TimeoutExpired:
    print("Komut zaman aşımına uğradı.")
except subprocess.CalledProcessError as hata:
    print("Çıkış kodu:", hata.returncode)
    print("Hata mesajı:", hata.stderr)

Bu kod, hedef sunucuya iki ping gönderir; çıktıyı yakalar, on saniyelik sınır uygular ve başarısız dönüş kodunu istisnaya dönüştürür. Windows kullanılıyorsa parametreler ping -n 2 example.com biçiminde değiştirilmelidir.

shell=True neden dikkat ister?

Kullanıcıdan gelen metni doğrudan kabuğa göndermek komut enjeksiyonuna yol açabilir. Örneğin dosya adına eklenen ; rm -rf ... benzeri bir ifade ikinci bir komut olarak yorumlanabilir. Bu nedenle komutları liste halinde vermek ve varsayılan shell=False davranışını korumak daha güvenlidir.

Örneğin dosya silmek için rm çağırmak yerine pathlib.Path.unlink() kullanmak çoğu zaman daha taşınabilir ve güvenlidir.

Cron mantığı ve periyodik çalışma

Periyodik görevlerde temel fikir, mevcut zamanın belirlenen kuralla eşleşip eşleşmediğini denetlemektir. Bir görev her $T$ dakikada çalışıyorsa, yaklaşık çalışma sayısı $N = \frac{D}{T}$ ile hesaplanabilir. Burada $D$, toplam dakika sayısıdır. Örneğin bir günde her 15 dakikada çalışan görev $1440 / 15 = 96$ kez tetiklenir.

Linux cron ifadesi beş zaman alanından oluşur:

* * * * *
│ │ │ │ └── Haftanın günü
│ │ │ └──── Ay
│ │ └────── Ayın günü
│ └──────── Saat
└────────── Dakika

Her gece 02.30’da yedek alan bir betik şöyle planlanabilir:

30 2 * * * /usr/bin/python3 /opt/scripts/yedekle.py >> /var/log/yedekle.log 2>&1

Buradaki yönlendirme, normal ve hata çıktılarını günlük dosyasına ekler. Betiğin elle çalışırken başarılı olması cron altında da başarılı olacağı anlamına gelmez; cron daha sınırlı bir ortam değişkeni ve PATH değeriyle çalışabilir. Bu yüzden mutlak dosya yolları kullanılmalıdır.

Sağlam bir otomasyonun kontrol listesi

İyi bir görev tekrar çalıştırıldığında veriyi bozmamalı, yani mümkün olduğunca idempotent olmalıdır. Hataları dosyaya veya merkezi günlük sistemine yazmalı, çalışma süresini sınırlamalı ve gizli bilgileri kaynak koda gömmemelidir. Aynı görevin iki kopyasının eşzamanlı başlamasını önlemek için kilit dosyası da kullanılabilir.

Kısacası başarılı otomasyon yalnızca “komutu zamanında çalıştırmak” değildir. Güvenli süreç yönetimi, doğru zamanlama, gözlemlenebilir günlükler ve hata sonrası toparlanma birlikte tasarlandığında betikler gerçekten güvenilir birer sistem çalışanına dönüşür.

``

Turing Testi aslında neyi ölçer?

Turing Testi, zekânın içsel mekanizmasını tanımlamak yerine gözlemlenebilir çıktıya odaklanır. Bir insan değerlendirici, yazılı görüşme yaptığı tarafın makine olduğunu güvenilir biçimde anlayamıyorsa sistem testi geçmiş sayılır. Bu yaklaşımın gücü, “düşünmek” gibi tanımlanması zor bir kavramı ölçülebilir bir oyuna dönüştürmesidir.

Basitleştirilmiş biçimde başarıyı şöyle ifade edebiliriz:

$T$ yükseldikçe sistemin insanı taklit etme başarısı artar. Fakat yüksek $T$, doğruluk, tutarlılık veya gerçek dünya anlayışı anlamına gelmez. Model; mizah, tereddüt ve gündelik dil kalıplarını kullanarak ikna edici olabilir. Başka bir deyişle test, zekâ ile zekâ performansını birbirine karıştırabilir.

Bugünün modelleri neden testi zorluyor?

Büyük dil modelleri, çok büyük metin koleksiyonlarından bir sonraki kelime veya belirtecin olasılığını öğrenir. Temel hedef kabaca şöyledir:

Bu mekanizma şaşırtıcı derecede yeteneklidir; fakat modelin söylediği her şeyi doğruladığını göstermez. Üstelik kısa bir sohbette kusurlar gizlenebilir. Bilgi kesim tarihi, halüsinasyonlar, uzun görevlerde hedef kaybı ve nedensellik hataları ancak sistematik deneylerle ortaya çıkar.

Tek puan yerine yetenek profili

Yeni değerlendirme yaklaşımı, zekâyı tek boyutlu bir sayı değil, bir yetenekler vektörü olarak ele almalıdır:

Burada $D$ doğruluk, $M$ muhakeme, $G$ genelleme, $U$ uzun vadeli tutarlılık, $E$ emniyet ve $A$ araç kullanma becerisidir. Böylece çok güzel yazan ama kaynak doğrulayamayan bir model ile daha kısa konuşup güvenilir işlem yapan model aynı kefeye konmaz.

Örneğin küçük bir değerlendirme sistemi, ağırlıklı başarı puanı hesaplayabilir:

scores = {
    "dogruluk": 0.82,
    "muhakeme": 0.74,
    "genelleme": 0.69,
    "emniyet": 0.91
}

weights = {
    "dogruluk": 0.35,
    "muhakeme": 0.30,
    "genelleme": 0.20,
    "emniyet": 0.15
}

total = sum(scores[k] * weights[k] for k in scores)
print(f"Bileşik puan: {total:.2f}")

Bu kod, farklı yetenekleri ağırlıklandırarak bileşik bir sonuç üretir. Yine de puanın yanında alt sonuçlar mutlaka gösterilmelidir; çünkü ortalama, kritik bir güvenlik zayıflığını saklayabilir.

Daha iyi testler nasıl görünmeli?

Geleceğin testleri dinamik olmalı; sorular düzenli yenilenmeli ve internette ezberlenebilir cevaplara dönüşmemelidir. Modelden yalnızca cevap değil, doğrulanabilir kaynak, belirsizlik tahmini ve gerektiğinde “Bilmiyorum” diyebilme becerisi istenmelidir. Uzun süreli görevler, karşıt örnekler, yeni kurallar altında genelleme, kod çalıştırma ve insanlarla iş birliği de değerlendirmeye katılmalıdır.

Turing Testi tamamen değersiz değildir; doğal diyalog kalitesini ölçen tarihsel ve sezgisel bir araç olarak yaşamaya devam edebilir. Fakat artık zekânın final sınavı değil, kapsamlı bir değerlendirme paketindeki eğlenceli sorulardan biridir. Günümüzün asıl meselesi makinenin insan rolünü ne kadar iyi oynadığı değil; ne kadar doğru, uyarlanabilir, şeffaf ve güvenli biçimde iş yaptığıdır.

``

Özgünlük tam olarak nedir?

Gündelik dilde özgünlüğü, daha önce hiç görülmemiş bir şey üretmek olarak tanımlarız. Bu tanım kulağa hoş gelse de insan yaratıcılığı bile boşlukta gerçekleşmez. Bir müzisyen dinlediği bestelerden, bir yazar okuduğu romanlardan, bir yazılımcı ise öğrendiği tasarım kalıplarından etkilenir.

Bu nedenle yaratıcılığı iki bileşenin birleşimi olarak ele almak daha kullanışlıdır:

Bir fikir yeni fakat anlamsızsa yaratıcı sayılmayabilir. Çok faydalı fakat bütünüyle bilinen bir çözüm de yenilikçi değildir. Çarpım kullanılması tesadüf değildir: Bileşenlerden biri sıfır olduğunda yaratıcılık puanı da sıfıra yaklaşır.

Üretken modeller nasıl “hayal kurar”?

Bir dil modeli, sıradaki kelimeyi tahmin eden devasa bir olasılık sistemi olarak düşünülebilir. Basitleştirilmiş biçimde model şu dağılımı öğrenir:

Burada $x_t$, önceki kelimeler verildiğinde seçilecek yeni kelimedir. Model çoğunlukla en olası seçeneği tercih ederse sıradan ve güvenli metinler üretir. Daha düşük olasılıklı seçeneklere şans tanındığında ise sonuçlar şaşırtıcılaşır. Ancak sürpriz, tek başına yaratıcılık değildir; klavyeye rastgele basmak da beklenmedik sonuç verir!

Aşağıdaki küçük Python örneği, bir fikir listesindeki kelime çeşitliliğini basit bir yenilik göstergesi olarak ölçer:

from collections import Counter

def yenilik_puani(metin):
    """Tekrarlanmayan kelime oranını hesaplar."""
    kelimeler = metin.lower().split()
    if not kelimeler:
        return 0

    frekans = Counter(kelimeler)
    benzersiz = sum(1 for adet in frekans.values() if adet == 1)
    return benzersiz / len(kelimeler)

fikir = "Ay ışığında çalışan sessiz bir şehir kütüphanesi"
print(yenilik_puani(fikir))

Bu kod, özgünlüğü gerçekten anlayamaz; yalnızca yüzeysel tekrarları ölçer. Aynı şekilde gelişmiş değerlendirme sistemleri de anlamsal uzaklık, şaşırtıcılık ve fayda gibi ölçütleri yaklaşık olarak hesaplar. Kültürel anlamı veya bir eserin neden dokunaklı olduğunu bütünüyle sayıya dönüştürmek hâlâ zordur.

Taklit ile yaratım arasındaki bulanık çizgi

İnsan da makine de geçmiş örneklerden öğrenir. Asıl fark, öğrenmenin kaynağından çok üretim sürecindeki öz farkındalık ve niyette ortaya çıkar. İnsan, başarısız bir ilişkisini şarkıya dönüştürebilir; model ise “hüzünlü ayrılık şarkısı” örüntüsünü ustalıkla uygulasa bile üzülmüş değildir.

Bununla birlikte niyetin bulunmaması, çıktının yaratıcı değer taşımadığı anlamına gelmez. Fotoğraf makinesi görmez, fakat fotoğraf sanatı gerçektir. Benzer şekilde yapay zekâ; seçenek üreten, alışılmadık bağlantılar öneren ve insanın düşünce alanını genişleten bir araç olabilir.

Özgünlüğü yeniden tanımlamak

Belki de doğru soru “Makine yaratıcı mı?” değil, “İnsan ile makinenin kurduğu sistem yaratıcı sonuçlar üretiyor mu?” olmalıdır. İstemleri seçen, çıktıları eleyen, bağlam ekleyen ve etik sorumluluğu üstlenen insan hâlâ sürecin belirleyici parçasıdır.

Geleceğin özgünlüğü, hiçbir etkilenme içermeyen mucizevi eserler anlamına gelmeyebilir. Daha gerçekçi tanım; bilinen parçaları yeni, değerli ve bağlama duyarlı biçimde birleştirebilmektir. Yapay zekâ bu denkleme hız ve çeşitlilik katar; anlamı, amacı ve sorumluluğu ise şimdilik bizden ödünç alır.

``

Antropomorfizasyon nedir?

Antropomorfizasyon, insan olmayan varlıklara niyet, kişilik veya duygu atfetme eğilimidir. Arabasına isim veren, bilgisayarı yavaşladığında “Bugün bana kızgın” diyen herkes bu eğilimin hafif bir örneğini sergiler.

Bilişsel psikoloji açısından beynimiz sürekli tahmin yapan bir sistemdir. Karşımızdaki varlık tutarlı cümleler kuruyor, ismimizi kullanıyor ve duygumuza uygun cevap veriyorsa en erişilebilir zihinsel model devreye girer: “Bu, sosyal bir aktör.” Böylece yazılımı anlamak için teknik bir model yerine insan ilişkilerinde kullandığımız zihin kuramından yararlanırız.

Beyin neden bu kadar kolay ikna oluyor?

İnsan zihni sosyal sinyallere karşı hassastır. Evrimsel açıdan başka bireylerin niyetini hızlı tahmin etmek önemliydi. Çalılıktaki hareketin rüzgâr mı yoksa canlı mı olduğunu uzun uzun analiz etmek yerine, ona bir aktörmüş gibi yaklaşmak çoğu zaman daha güvenliydi.

Bu eğilimi basitleştirilmiş bir modelle gösterebiliriz:

Burada $B$ duygusal bağlanma eğilimini, $D$ dilin doğallığını, $T$ yanıtların tutarlılığını, $H$ kullanıcının sosyal ihtiyaç düzeyini ve $F$ sistemin yapay olduğuna dair farkındalığı temsil eder. Bu bilimsel bir klinik ölçek değil, etkenlerin ilişkisini anlatan kavramsal bir modeldir. Doğal dil, tutarlılık ve yalnızlık arttıkça bağ güçlenebilir; teknik farkındalık ise bu etkiyi azaltabilir ama tamamen ortadan kaldırmaz.

“Empatik” yanıt nasıl üretilir?

Bir sistemin empatik görünmesi için duygu yaşaması gerekmez. Kullanıcının ifadesindeki duygusal işaretleri belirleyip uygun bir yanıt şablonu seçmesi yeterli olabilir:

def empatik_yanit(mesaj):
    mesaj = mesaj.lower()

    if "yalnız" in mesaj or "üzgün" in mesaj:
        return "Bunun ağır hissettirmesi anlaşılır. İstersen biraz anlatabilirsin."
    elif "başardım" in mesaj or "mutluyum" in mesaj:
        return "Harika haber! Emeğinin karşılığını almak nasıl hissettirdi?"
    else:
        return "Seni doğru anlamak istiyorum. Biraz daha ayrıntı verir misin?"

Bu kod, mesajdaki basit anahtar kelimeleri kontrol eder ve duyguyla uyumlu cevap verir. Modern dil modelleri çok daha karmaşık örüntüler kullanır; ancak temel ayrım aynıdır: Empatiyi ifade eden dil üretmek, empati hissetmekle eş anlamlı değildir.

Bağ kurmak kötü mü?

Her zaman değil. Sohbet botları düşünceleri düzenlemeye, iletişim provası yapmaya veya yalnızlık hissini kısa süreli azaltmaya yardımcı olabilir. Üstelik yargılanmayacağını düşünen kullanıcı kendini daha rahat ifade edebilir.

Risk, simülasyon ile karşılıklı insan ilişkisi arasındaki sınır kaybolduğunda başlar. Botun kesinlikle tarafsız olduğu, sırları insan gibi koruduğu veya kullanıcıyı gerçekten “sevdiği” varsayılabilir. Ayrıca aşırı kişiselleştirilmiş sistemler duygusal bağı ticari yönlendirme için kullanabilir.

Bu nedenle sağlıklı yaklaşım, deneyimi küçümsemek değil sınırlarını bilmektir: Hissedilen rahatlama gerçektir; fakat bu rahatlamayı üreten karşı tarafın duyguları olduğu sonucu zorunlu değildir. Kısacası yapay zekâya empati yükleyen şey yalnızca kod değil, sosyal anlam aramaya programlanmış insan zihnidir.

Refactoring ne zaman tuzağa dönüşür?

Refactoring, yazılımın dış davranışını değiştirmeden iç yapısını iyileştirmektir. Amaç okunabilirliği, bakım kolaylığını ve değiştirilebilirliği artırmaktır. Sorun refactoring yapmak değil, “yeterince iyi” noktasını tanımlayamamaktır.

Mükemmeliyetçi geliştirici çoğu zaman kod kalitesi peşinde olduğunu düşünür. Psikolojik açıdan ise davranışın arkasında hata yapma korkusu, eleştirilmekten kaçınma veya kontrol ihtiyacı bulunabilir. Kod henüz teslim edilmediyse gerçek kullanıcı tarafından değerlendirilemez; dolayısıyla geliştirici de başarısızlıkla yüzleşmez. Bitirmemek, paradoksal biçimde güvenli hissettirebilir.

Bu döngüyü basitçe şöyle gösterebiliriz:

Her düzenleme kısa süreli rahatlama sağlar. Ancak teslim tarihi yaklaştıkça baskı büyür ve geliştirici, kontrol hissini geri kazanmak için yeniden koda yönelir.

Kalite ile kusursuzluk aynı şey değildir

Ekonomik açıdan da her iyileştirme mantıklı değildir. Bir refactoring kararının yaklaşık değeri şu şekilde düşünülebilir:

Kodun altı ay boyunca değişmeyecek bir bölümünü üç gün boyunca güzelleştirmek, düşük getiri sağlayabilir. Buna karşılık her sprint değiştirilen karmaşık bir modülü sadeleştirmek oldukça değerlidir. Kalite bağlama bağlıdır; soyut bir saflık yarışması değildir.

“Bitti” tanımını koddan önce yazın

Mükemmeliyetçiliğe karşı en etkili araçlardan biri Definition of Done kullanmaktır. Göreve başlamadan önce test, güvenlik, performans ve dokümantasyon beklentileri açıkça belirlenmelidir. Sonradan akla gelen her iyileştirme mevcut görevin zorunlu parçası sayılmamalıdır.

Aşağıdaki küçük JavaScript örneği, refactoring kararını duygudan çıkarıp ölçütlere bağlayan basit bir kontrol sunar:

function refactorGerekliMi({ testlerGeciyor, kritikRisk, sikDegisiyor }) {
  if (!testlerGeciyor) return true;       // Önce doğruluğu sağla
  if (kritikRisk) return true;             // Güvenlik veya veri riski beklemez
  if (sikDegisiyor) return true;           // Gelecekteki bakım maliyetini azalt
  return false;                            // İyileştirmeyi backlog'a taşı
}

Bu fonksiyon evrensel bir kalite formülü değildir. Asıl amacı “Kod hoşuma gitmedi” hissini; risk, değişim sıklığı ve doğruluk gibi tartışılabilir ölçütlere çevirmektir.

Zihinsel fren mekanizmaları

Öncelikle refactoring için zaman kutusu belirleyin: “Bu alanı 45 dakika iyileştireceğim, sonra pull request açacağım.” İkinci olarak kusurları saklamak yerine backlog’a yazın. Böylece zihniniz, problemin unutulmayacağını bilir. Üçüncü olarak küçük pull request’ler açarak geri bildirimi erken alın. Son olarak ekip içinde “yeterince iyi” örneklerini konuşun; kalite standardı bireysel kaygının değil, ortak kararların ürünü olsun.

Profesyonellik kusursuz kod üretmek değil, doğru zamanda doğru kalite seviyesini seçebilmektir. Bazen en iyi refactoring, bugün yapılmayan ama gerekçesi belgelenen refactoring’dir. Yazılım kullanıcıya ulaşmadıkça yalnızca potansiyeldir; teslim edilen, ölçülen ve gerektiğinde geliştirilen yazılım ise gerçek değer üretir.