AI’nin uygulama geliştirirken kod ve karar üretirken nasıl çalıştığına dair açıklık: tokenlar, bağlam, araçlar, testler, sınırlamalar ve pratik promptlama ipuçları.
İnsanlar “AI düşünüyor” dediğinde genellikle şu anlama gelir: soruyu anlıyor, üzerinde akıl yürütüyor ve sonra bir yanıt seçiyor.\n\nModern metin tabanlı AI (LLM) için daha kullanışlı bir zihinsel model ise daha basittir: model, bir sonraki metnin ne olması gerektiğini tahmin eder.
Bu kulağa sıradan gelebilir—ta ki “sonraki metin”in neler yapabildiğini görene kadar. Model eğitimden yeterince desen öğrenmişse, bir sonraki kelimeyi (sonrakini ve sonrakini) tahmin etmek; açıklamalar, planlar, kodlar, özetler ve uygulamanızın kullanabileceği yapılandırılmış veriler üretebilir.
İyi AI özellikleri inşa etmek için altta yatan matematiği öğrenmeniz gerekmez. Gerekli olan daha çok davranışı öngörmeyi sağlayan pratik bir yaklaşımdır:
Bu makale bu tür bir model sunuyor: abartı değil, derin teknik makale değil—sadece güvenilir ürün deneyimleri tasarlamanıza yardım eden kavramlar.
Uygulama geliştiricisi bakış açısından modelin “düşünmesi”, sağladığınız girdiye (prompt, kullanıcı mesajları, sistem kuralları ve alınan içerik) karşılık modelin ürettiği metindir. Model varsayılan olarak gerçekleri kontrol etmiyor, webde gezinmiyor ve veritabanınızın ne içerdiğini bilmiyor—o bilgiyi siz geçmediğiniz sürece.
Buna göre beklentileri ayarlayın: LLM’ler taslak oluşturma, dönüştürme, sınıflandırma ve kod-benzeri çıktılar üretmede son derece yararlıdır. Ancak sihirli doğruluk makineleri değildir.
Zihinsel modeli birkaç parçaya ayıracağız:
Bu fikirlerle promptlar, UI ve güvenlik önlemleri tasarlayarak AI özelliklerinin tutarlı ve güvenilir hissetmesini sağlayabilirsiniz.
İnsanlar AI’nin “düşündüğünü” söylediklerinde, bunun bir insan gibi akıl yürüttüğünü hayal etmek kolaydır. Daha kullanışlı olan zihinsel model daha basittir: model son derece hızlı bir otomatik tamamlama yapıyor—bir küçük parça halinde.
Bir token, modelin kullandığı metin parçasıdır. Bazen tam bir kelimedir (“elma”), bazen kelimenin bir parçasıdır (“el” + “ma”), bazen noktalama işareti ya da boşluktur. Kesmenin tam yöntemi modelin tokenizer’ına bağlıdır, ama çıkarım şu: model metni düzgün cümleler olarak değil, tokenlar halinde işler.
Modelin temel döngüsü şudur:
Hepsi bu. Her paragraf, madde işareti ve “akıl yürütme” zinciri, bu sonraki-token tahminini birçok kez tekrarlayarak inşa edilir.
Model eğitim sırasında büyük miktarda metin gördüğü için, açıklamaların nasıl aktığı, kibar bir e-postanın nasıl olduğu veya bir hata düzeltmesinin genelde nasıl tarif edildiği gibi desenleri öğrenir. Bir soru sorduğunuzda, model öğrendiği desenlere uyan ve sağladığınız bağlama uygun bir yanıt üretir.
Bu yüzden model yanlış olduğunda bile kendinden emin ve tutarlı gelebilir: model gerçekliği kontrol etmek yerine hangi metnin sıradaki olması gerektiğini optimize eder.
Kod model için özel değildir. JavaScript, SQL, JSON ve hata mesajları hepsi token dizileridir. Modelin faydalı kod üretmesinin nedeni, uygulamanızı gerçek bir mühendis gibi “anlaması” değil, yaygın kodlama desenlerini öğrenmiş olmasıdır.
“Model bu cevabı nereden aldı?” diye sorulduğunda en faydalı zihinsel model şudur: model devasa sayıda örnekten desenler öğrendi ve şimdi bu desenleri yeniden birleştirerek hangi metnin sıradaki olması gerektiğini tahmin ediyor.
Eğitim sırasında modele kitaplar, makaleler, kod, dokümantasyon, Soru&Cevap’lar ve başka pek çok metin örneği gösterilir. Basit bir görev üzerinde pratik yapar: verilen metnin ardından gelen tokeni tahmin et. Yanlış yaptığında eğitim süreci modelin iç parametrelerini küçük bir miktar kaydırır ki bir dahaki sefer daha iyi tahmin etsin.
Zamanla bu küçük ayarlamalar toplanır. Model şu tür ilişkileri kodlamaya başlar:
Model istatistiksel düzenlilikleri öğrendiği için tek bir sabit metin yerine desenleri yeni biçimlerde birleştirebilir. Eğer “bir kavramı açıklama” örneklerini ve “sizin uygulama senaryonuz” örneklerini çokça gördüyse, bunları birleştirip amaca yönelik bir yanıt üretebilir.
Bu yüzden bir LLM niş bir ürün için makul bir onboarding e-postası yazabilir veya genel bir API entegrasyon açıklamasını belirli bir stack’e uyarlayabilir. Model tek bir saklı paragrafı geri getirmiyor; öğrendiği desenlere uyan yeni bir dizi üretiyor.
Eğitim verilerinde belirli bir gerçek olsa bile (ör. fiyatlandırma katmanı veya dahili politika), modelin bunu güvenilir şekilde “bakıp bulabileceğini” varsaymayın. Eğitim, sorgulanabilir bir bilgi tabanı oluşturmak gibi çalışmaz. Daha çok sıkıştırma gibidir: çok sayıda örnek ağırlıklara dönüştürülür ve bu ağırlıklar gelecekteki tahminleri etkiler.
Bu yüzden model benzer bağlamlarda genellikle görülen şeylere dayanarak ayrıntılar hakkında tahminde bulunup kendinden emin konuşabilir.
Desen öğrenme akıcı ve ilgili metin üretmede güçlüdür, fakat akıcılık doğruluk demek değildir. Model şunları yapabilir:
Uygulama geliştiricileri için kilit çıkarım: LLM’in yanıtları genelde öğrenilmiş desenlerden gelir; doğruluk önemliyse çıktıyı kendi verileriniz ve kontrollerinizle dayandırmalısınız (bunun için sonraki bölümlerde çözümler var).
Bir LLM yanıt yazarken tek bir “doğru cümleyi” veritabanından çekmiyor. Her adımda olası birçok sonraki tokeni (kelime veya kelime parçası) tahmin ediyor ve her birine bir olasılık atıyor.
Model her adımda yalnızca en olası tokeni seçseydi, çıktılar daha tutarlı olurdu—ama aynı zamanda tekrarlayıcı ve bazen garip derecede katı olurdu. Çoğu sistem bunun yerine olasılıklardan örnekleme yapar ve bu kontrollü rastgeleliği getirir.
İki yaygın ayar çıktının ne kadar çeşitli hissettireceğini şekillendirir:
Bir uygulama inşa ediyorsanız, bu ayarlar sanatsal bir anlamda “yaratıcı olmak”tan ziyade şu ikiden birini seçmek gibidir:
Model “makul metin” üretmeye odaklandığı için sert ifadeler kullanabilir—ancak bu, iddianın doğruluğunun kanıtı değildir. Bu yüzden uygulamalarda genellikle retrieval veya doğrulama adımları gerekir.
LLM’e sorun: “Bir dizideki tekrarları kaldıran JavaScript fonksiyonu yaz.” Buna şu seçeneklerden herhangi biri dönebilir, hepsi geçerli olabilir:
// Option A: concise
const unique = (arr) => [...new Set(arr)];
// Option B: explicit
function unique(arr) {
return arr.filter((x, i) => arr.indexOf(x) === i);
}
Farklı örnekleme seçimleri farklı stillere (özlü vs açık), farklı ödünleşimlere (hız, okunabilirlik) ve hatta farklı kenar durum davranışlarına yol açabilir—model “fikir değiştirmiyor”, sadece bir dizi yüksek olasılıklı devam arasında seçim yapıyor.
Modelin konuşmayı “hatırladığını” söylediğinizde, aslında sahip olduğu şey bağlamtir: şu anda görebildiği metin—kullanıcının son mesajı, sistem talimatları ve önceki sohbetin pencerede kalan kısmı.
Bağlam penceresi, modelin aynı anda değerlendirebileceği metnin sabit bir sınırıdır. Konuşma yeterince uzadığında, eski kısımlar pencerenin dışına çıkar ve modelin görüş alanından kaybolur.
Bu yüzden şu tür davranışlarla karşılaşırsınız:
Sohbeti uzattıkça sınırlı alana rekabet yaratırsınız. Önemli kısıtlar, son karşılıklı yazışmalar tarafından iter dışı bırakılır. Özet yoksa model, neyin önemli olduğunu kalan görünür metinden çıkarmaya çalışır—bu yüzden kendinden emin görünürken önemli detayları kaçırabilir.
Pratik bir çözüm periyodik özetlemedir: hedefi, alınan kararları ve kısıtları sıkı bir blok halinde yeniden ifade edin ve oradan devam edin. Uygulamalarda bu genellikle otomatik bir “konuşma özeti”nin prompt’a enjekte edilmesi şeklinde uygulanır.
Modeller, çıktıya yakın olan talimatlara uyma eğilimindedir. Eğer yerine getirilmesi gereken kurallar varsa (format, ton, kenar durumlar), bunları promptun sonuna—tam olarak “Şimdi yanıtı üretin” öncesine—koyun.
Uygulama inşa ediyorsanız, bunu arayüz tasarımı gibi ele alın: hangi gereksinimlerin bağlamda kalması gerektiğine karar verin ve bunları her seferinde dahil edin—ya sohbet geçmişini kırparak ya da sıkı bir özet ekleyerek. Daha fazla yapılandırma için bkz. /blog/prompting-as-interface-design.
LLM’ler, yetkin bir geliştirici gibi görünen metni üretmede çok iyidir. Ancak “doğru gibi görünmek” gerçekte doğru olmakla aynı şey değildir. Model, çıktıyı kod tabanınıza, bağımlılıklara veya gerçek dünyaya karşı kontrol etmiyor—bunu açıkça bağlamazsanız.
Model bir düzeltme, yeniden düzenleme veya yeni bir fonksiyon önerse bile hâlâ sadece metindir. Model, test çalıştırılmadan, paketler içe aktarılmadan, API çağrıları yapılmadan veya projeniz derlenmeden uygulamanızı çalıştırmaz—bunları yapacak bir araca açıkça bağlamadığınız sürece.
Bu temel farktır:
AI yanlış yapınca genellikle öngörülebilir şekillerde başarısız olur:
Bu hataları fark etmek zor olabilir çünkü çevresindeki açıklama genelde tutarlıdır.
AI çıktısını, projeyi yerel olarak çalıştırmamış bir ekip arkadaşından hızlı bir taslak olarak değerlendirin. Güven, şu adımlarla hızla yükselmeli:
Testler geçmezse modelin cevabını son bir düzeltme değil başlangıç noktası olarak kabul edin.
Bir dil modeli neyin işe yarayabileceğini önermek konusunda iyidir—ama tek başına hâlâ metin üretiyor. Araçlar, AI destekli bir uygulamanın bu önerileri doğrulanmış eylemlere dönüştürmesini sağlar: kod çalıştırma, veritabanı sorgulama, doküman çekme veya harici API çağrıları yapma gibi.
Uygulama iş akışlarında araçlar genellikle şunlardır:
Önemli değişim şu: model artık sonucu “biliyormuş gibi davranmıyor”—gerçekten kontrol edebiliyor.
Yararlı bir zihinsel model şudur:
Böylece “tahminden” kaçınırsınız. Linter unused import bildirirse model kodu günceller. Birim testleri başarısız olursa, testlerin ortaya çıkardığı kenar durumlarını düzeltmek için yineleme yapar.
eslint/ruff/prettier çalıştırılarak stil ve hatalar yakalanır.\n- Birim testleri: model bir fonksiyon ve test yazar, testleri çalıştırır, başarısızlıklardan ortaya çıkan kenar durumlarını düzeltir.Araçlar güçlü—ve tehlikeli olabilir. En az ayrıcalık ilkesini uygulayın:
Araçlar modeli “daha akıllı” yapmaz, ama uygulamanızın AI’sını daha dayanaklı kılar—çünkü artık model anlatmak yerine doğrulayabilir.
Dil modeli, görebildiği metin üzerinde yazma, özetleme ve akıl yürütme konusunda çok iyidir. Ancak otomatik olarak en son ürün değişikliklerinizi, şirket politikalarınızı veya spesifik bir müşterinin hesap ayrıntılarını bilmez. Retrieval‑Augmented Generation (RAG) basit bir çözümdür: önce en alakalı bilgileri getirin, sonra modelin bu bilgilerle yazmasını sağlayın.
RAG’i “açık kitap AI” olarak düşünün. Modelden belleğine dayanarak cevap vermesini istemek yerine, uygulamanız hızlıca ilgili pasajları (snippet) güvenilir kaynaklardan çeker ve bunları prompt’a ekler. Model sonra bu verilen materyale dayanarak yanıt üretir.
RAG, doğruluk dış kaynaklara bağlıysa iyi bir varsayılan yaklaşımdır:
Eğer uygulamanızın değeri “işimiz için doğru cevap”a bağlıysa, modele tahmin ettirmeye çalışmaktansa RAG genelde daha iyidir.
RAG, getirdiği içeriklerin kalitesiyle sınırlıdır. Arama güncel olmayan, alakasız veya eksik parçalar döndürürse model kendinden emin ama yanlış bir yanıt üretebilir—şimdi yanlış kaynakla “dayanılmış” bir cevap. Uygulamada retrieval kalitesini iyileştirmek (chunklama, metadata, tazelik, sıralama) genelde prompt ince ayarından daha fazla doğruluk getirir.
“Agent”, LLM’nin döngüsel çalışmasıdır: bir plan yapar, bir adım atar, ne olduğunu görür ve ne yapacağına karar verir. Tek seferlik cevap yerine yineleme yapar ve hedefe ulaşana kadar adım adım ilerler.
Yararlı bir zihinsel model:
Planla → Yap → Kontrol et → Revize et
Bu döngü tek bir promptu küçük bir iş akışına dönüştürür. Agentler daha “bağımsız” hissedebilir çünkü model yalnızca metin üretmiyor, eylemler seçip sıralıyor.
Agentlerin ne zaman duracağını net kural koyun. Yaygın durdurma koşulları:
Guardrail’lar (izin verilen araçlar, izin verilen veri kaynakları, insan onayı) döngünün güvenli ve öngörülebilir kalmasını sağlar.
Bir agent her zaman “bir adım daha” önerebileceği için, bütçeler, zaman aşımı ve adım limitleri tasarlamalısınız. Ayrıca her eylemi loglamak, araç sonuçlarını doğrulamak ve kısmi bir cevapla birlikte denemelerini özetleyerek kibarca başarısız olmak genelde agentsız sürekli döngüye izin vermekten daha iyi bir ürün deneyimidir.
Koder.ai gibi vibe-coding platformlarıyla inşa ediyorsanız, bu “agent + araçlar” zihinsel modeli özellikle pratiktir. Sadece öneri istemezsiniz—özellik planlamasına yardım eden, React/Go/PostgreSQL veya Flutter bileşenleri üretebilen ve anlık kontroller (ör. snapshot ve rollback) ile yineleme yapabilen bir iş akışı kullanırsınız. Bu sayede hızlı ilerlerken değişikliklerin kontrolünü kaybetmezsiniz.
Bir LLM’i uygulama özelliğinizin arkasına koyduğunuzda, prompt artık “sadece metin” değildir. Model ile ürününüz arasındaki arayüz sözleşmesidir: modelin ne yapmaya çalıştığı, ne kullanabileceği ve kodunuzun güvenle tüketebileceği şekilde nasıl yanıt vermesi gerektiği.
İyi bir zihniyet, promptları UI formları gibi görmek: iyi formlar belirsizliği azaltır, seçimleri sınırlarken bir sonraki adımı belirgin kılar. İyi promptlar da aynı şeyi yapar.
Promptu yayına almadan önce şunların net olduğundan emin olun:
Modeller desenleri takip eder. İstediğiniz deseni “öğretmenin” güçlü bir yolu, iyi bir giriş ve iyi bir çıkış örneği eklemektir (özellikle görevin kenar durumları varsa). Bir örnek bile gereksiz yinelemeleri azaltır ve modelin arayüzünüzün gösteremeyeceği formatları uydurmasını engeller.
Başka bir sistem yanıtı okuyacaksa, yapısal isteyin. JSON, tablo veya katı madde kuralları isteyin.
You are a helpful assistant.
Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
"result": "string",
"confidence": "low|medium|high",
"warnings": ["string"],
"next_steps": ["string"]
}
Bu, “promptlama”yı öngörülebilir arayüz tasarımına dönüştürür.
Promptunuza şunu ekleyin: “Ana gereksinimler eksikse, cevaplamadan önce açıklayıcı sorular sorun.”
Bu tek satır, kendinden emin fakat yanlış çıktıları engelleyebilir—çünkü modelin tahmin etmek yerine durup eksik alanları sormasına izin verir.
Pratikte en güvenilir promptlar, ürününüzün inşa ve dağıtım biçimiyle uyumludur. Örneğin platformunuz önce planlama, sonra değişiklik üretme, ardından kaynak kodu dışa aktarma veya dağıtma destekliyorsa, bunu prompt sözleşmesinde (planla → değişiklikleri üret → onayla → uygula) yansıtabilirsiniz. Koder.ai’ın “planning mode”u, süreci açık aşamalara dönüştürerek sürüklenmeyi azaltan ve ekiplerin değişiklikleri göndermeden önce gözden geçirmesini kolaylaştıran bir örnektir.
Güven, modelin “kendinden emin” görünmesinden gelmez. Güven, AI çıktısını ürününüzdeki diğer bağımlılıklar gibi ölçülüp izlenebilir ve sınırlandırılmış olarak ele almaktan gelir.
Küçük bir dizi gerçek görevle başlayın ve bunları tekrarlanabilir kontrollere dönüştürün:
“İyi mi?” sormak yerine “ne sıklıkla geçiyor?” izleyin. Yararlı metrikler:
Bir şey yanlış gittiğinde tekrar oynatabilmelisiniz. (Uygun gizleme ile) loglayın:
Böylece hatayı ayıklamak pratik olur ve “model mi değişti yoksa veri/araç mı?” sorusuna cevap bulabilirsiniz.
Birkaç temel varsayılan yaygın olayları engeller:
Genellikle modelin, anlayış ve muhakeme gibi görünen, hedefe yönelik ve tutarlı metin üretebildiği anlamına gelir. Pratikte bir LLM, sonraki token'i tahmin eder: verdiğiniz prompt, talimatlar ve sağlanan bağlama göre en olası devamı üretir.
Uygulama geliştiricileri için faydalı çıkarım şudur: “düşünme”, modelin davranışını şekillendirip sınırlayabileceğiniz çıktı davranışıdır—içsel olarak gerçekliği garanti eden bir durum değildir.
Token, modelin işlediği ve ürettiği metin parçasıdır (tam bir kelime, kelimenin bir parçası, noktalama işareti veya boşluk olabilir). Modeller cümleler olarak değil tokenlar üzerinden çalıştığı için maliyetler, sınırlar ve kırpılma token bazlıdır.
Pratik olarak:
Çünkü üretim olasılıksaldır. Her adımda model birçok olası sonraki token’e olasılık atar ve çoğu sistem tek en olası seçeneği almaktansa bu dağılımdan örnekleme yapar.
Daha tekrarlanabilir çıktılar için:
LLM’ler, doğruluk kontrolü yapmaktan ziyade inandırıcı metin üretmeye odaklanır. Eğitim verilerinde güvenli, kendinden emin bir ton yaygın olduğundan model kesin ifadeler kullansa bile altta yatan iddia tahmin olabilir.
Ürün tasarımında akıcılığı “iyi yazı” olarak, doğruluğu ise ayrı bir doğrulama gerektiren şey olarak kabul edin; doğruluk gerektiğinde retrieval, araçlar, testler veya onay mekanizmaları ekleyin.
Bağlam penceresi, modelin aynı anda görebildiği maksimum metin miktarıdır (sistem talimatları, sohbet geçmişi, alınan parçalar vb.). Konuşma çok uzadığında önceki kısımlar pencerenin dışına çıkar ve model artık onları “göremez”.
Azaltma yolları:
Hayır—varsayılan olarak model webde gezinmiyor, veritabanınızı okumuyor veya kodunuzu çalıştırmıyor. Modele yalnızca promptta verdiğiniz bilgilerle ve açıkça bağladığınız araçlarla erişim sağlanır.
Cevap dahili ya da güncel bilgilere bağlıysa, bunları retrieval (RAG) veya bir araç çağrısı ile verin—“daha zor sorarak” beklemek yerine.
Araçlara, doğrulanmış sonuçlara veya gerçek eylemlere ihtiyacınız olduğunda kullanın. Yaygın örnekler:
İyi bir örüntü: öner → kontrol et → düzelt, yani model araç çıktısına göre yineleyebilir.
RAG (Retrieval‑Augmented Generation), uygulamanın güvenilir kaynaklardan ilgili parçaları alıp modeli o bağlamla soruya cevap üretmesi için beslemesidir—yani “açık kitap AI” gibidir.
Kullanılmalı olduğunda:
Başarısızlık noktasını çoğunlukla kötü retrieval oluşturur—aranın kalitesi, chunk’lama, tazelik ve sıralama doğruluğu artırmada genellikle prompt ayarlarından daha büyük etkiye sahiptir.
Agent, bir LLM’nin döngü içinde çalışmasıdır: plan yapar, bir adım atar, sonucu kontrol eder ve ne yapacağına karar verir. Tipik bir döngü: planla → yap → kontrol et → düzelt.
Kaçınılması gerekenler:
Promptları bir arayüz sözleşmesi gibi ele alın: amacın, girdilerin, kısıtların ve uygulamanızın güvenle tüketebileceği çıktı biçiminin net olduğu bir kontrat.
Güven inşa eden uygulamalar: