AI engineer portföyü: işe alımda işe yarayan bir proje neye benzer?

Bir dil modeline soru gönderip cevabı ekrana yazan bir uygulama birkaç yıl önce etkileyiciydi. Bugün bir öğleden sonranın işi ve işe alan kişi bunu biliyor. Portföyünüzdeki tek AI projesi buysa size bir şey kazandırmaz, çünkü her adayda var.

İnandırıcı bir proje daha büyük bir proje demek değil. Aynı küçük fikrin, gerçek bir kullanıcıyla karşılaşmaya hazır hâli demek. Fark, mimaride değil kenarlarda: model cevap vermediğinde, girdi beklenmedik geldiğinde, fatura büyüdüğünde ne olduğunda. Aşağıda önce bir projeyi inandırıcı yapan işaretler, sonra her biri farklı bir beceriyi gösteren beş fikir var.

Bir projeyi inandırıcı yapan altı işaret

Tek komutla çalışıyor. Projeyi klonlayan biri onu README'deki birkaç satırla ayağa kaldırabilmeli: bağımlılıklar sabitlenmiş, örnek bir ayar dosyası var, gereken tek şey kendi API anahtarı. Çalıştırmak için sizinle yazışması gereken bir proje, değerlendirilmeden kapanan bir projedir.

Ne yaptığını ve neyi yapmadığını söylüyor. README'nin ilk paragrafı projenin kimin için olduğunu ve hangi sorunu çözdüğünü anlatmalı. "Şu türde belgelerde çalışıyor, taranmış PDF'lerde çalışmıyor" gibi bir cümle zayıflık değil; konuyu bildiğinizin en hızlı kanıtıdır.

Hata durumunu düşünmüş. Sağlayıcı geçici bir hata döndüğünde bir süre bekleyip yeniden deniyor mu? İstek takılırsa zaman aşımı var mı? Model bozuk JSON döndürdüğünde kullanıcı anlamlı bir mesaj mı görüyor, yoksa bir hata yığını mı? Bu üç durumu ele alan birkaç satır, demo ile ürün arasındaki farkı gösterir.

Bir ölçümü var. Elle hazırlanmış küçük bir test kümesi (otuz soru bile olur) ve bir puan. "Parçalama boyutunu değiştirince doğru kaynağı getirme oranı şuradan şuraya çıktı" diyebilen bir aday, "bence iyi çalışıyor" diyen adaydan her zaman öne geçer. Ölçümün kendisi kadar, ölçümü tekrar çalıştırmanın tek komut olması da önemlidir.

Maliyetini biliyor. Bir isteğin ortalama kaç token tuttuğunu ve günde bin kullanıcıyla ayda neye ulaşacağını tahmin eden kısa bir not. Hesap aritmetiktir: istek başına token × günlük istek × birim fiyat. Çok az aday yapar ve yapan, modeli bir maliyet kalemi olarak gördüğünü göstermiş olur. Bir mimari seçiminin maliyeti nasıl değiştirdiğini maliyet oyununda deneyebilirsiniz.

Sırları güvende. Depoda API anahtarı yok, bir .env.example dosyası var ve anahtarın nereye konacağı yazıyor. Geçmiş commit'lerde bile anahtar olmamalı; silinen bir dosya Git geçmişinde durur ve açık depolar otomatik olarak taranır.

Beş proje fikri

Her biri farklı bir beceriyi gösteriyor. Hepsini yapmanız gerekmiyor; iki tanesi iyi yapılmış hâliyle çoğu portföyden güçlüdür.

1. Kaynak gösteren belge asistanı. Bir kurumun ya da topluluğun belgeleri hakkında soru cevaplayan, her cevabın altında hangi belgenin hangi parçasından geldiğini gösteren bir sistem. Gösterdiği beceri: kendi verinizle cevap vermek (RAG). İşe alan kişinin ilk bakacağı yer: belgede cevabı olmayan bir soru sorduğunda ne olduğu. Uydurmak yerine "bu belgelerde cevap yok" diyebiliyorsa proje ciddiye alınır. Tipik zayıf nokta: belgeleri sabit uzunlukta keserken tabloları ve başlıkları ortadan bölmek.

2. Ölçümü olan bir sınıflandırıcı. Gelen destek mesajlarını konusuna ve aciliyetine göre ayıran küçük bir servis. Gösterdiği beceri: değerlendirme. İşe alan kişinin ilk bakacağı yer: elle etiketlenmiş test kümesi ve prompt değiştikçe puanın nasıl değiştiğini gösteren kısa tablo. Tipik zayıf nokta: yalnızca toplam doğruluğa bakmak; asıl önemli olan, acil bir mesajın yanlışlıkla "acil değil" sayılma oranıdır.

3. Bütçesi olan bir agent. Birkaç aracı (örneğin bir arama fonksiyonu ve bir hesap makinesi) kullanarak bir görevi tamamlayan bir agent. Gösterdiği beceri: araç kullanımı ve döngüyü kontrol etmek. İşe alan kişinin ilk bakacağı yer: durdurma koşulları; adım sınırı, maliyet sınırı ve bir araç hata verdiğinde ne olduğu. Tipik zayıf nokta: aracın hata mesajını modele hiç vermemek; model neyin yanlış gittiğini bilmeyince aynı çağrıyı tekrar tekrar dener.

4. Yapılandırılmış veri çıkarıcı. Fatura ya da özgeçmiş gibi düzensiz belgelerden belirli alanları çıkarıp şemaya göre doğrulanmış JSON üreten bir araç. Gösterdiği beceri: modelden makinenin okuyabileceği çıktı almak. İşe alan kişinin ilk bakacağı yer: doğrulama başarısız olduğunda ne yaptığı. Varsayılan bir değer uydurmak en kötü cevaptır, çünkü hatanın izini siler. Tipik zayıf nokta: tarih ve para birimi gibi alanları biçim kontrolü olmadan kabul etmek.

5. Yayında, gerçek kullanıcısı olan küçük bir uygulama. Yukarıdakilerden birinin, giriş sistemi ve kötüye kullanıma karşı sınırlarıyla internette çalışan hâli. Gösterdiği beceri: yayına almak. İşe alan kişinin ilk bakacağı yer: bir adres, bir izleme ekranı ve "ilk hafta şu bozuldu, şöyle düzelttim" diye başlayan kısa bir not. Tipik zayıf nokta: model çağıran uç noktayı hız sınırı olmadan açık bırakmak. Gerçek projelerin yayından sonra nasıl bozulduğuna dair örnekler arıza vakaları sayfasında.

Projeyi nasıl sunmalı?

README'nin üst kısmı, projenize iki dakika ayıran birinin okuyacağı tek kısımdır. Oraya şunları, bu sırayla koyun: tek cümlelik bir tanım, nasıl çalıştırıldığı, bir ekran görüntüsü ya da örnek çıktı, ölçümün sonucu ve bilinen sınırlar. Teknik ayrıntılar onun altında durabilir.

Sonra projenin neden öyle tasarlandığını anlatan birkaç cümle ekleyin. "Önce şunu denedim, şu yüzden işe yaramadı, sonra bunu yaptım" diye başlayan bir paragraf, kodun kendisinden daha çok şey söyler; çünkü işe alan kişinin asıl merak ettiği şey, işler ters gittiğinde nasıl düşündüğünüzdür.

Bu beceriler birbirine dayanır ve sırayla öğrenildiğinde çok daha kolay gelir. Hangi sırayla öğrenileceğini yol haritası yazımızda, bir eğitimi bu açıdan nasıl değerlendireceğinizi de kurs seçimi yazımızda anlattık.

Kaynaklar

• GitHub: secret scanning: depoya giren anahtarların nasıl tespit edildiği ve neden geçmişten de silinmesi gerektiği. (eklenme: 2026-09)
• The Twelve-Factor App: config: ayarların ve sırların koddan neden ayrı durması gerektiği. (eklenme: 2026-09)
• Anthropic: Reducing hallucinations: modelin "bilmiyorum" diyebilmesi için kullanılan teknikler. (eklenme: 2026-09)
• JSON Schema: Getting started: yapılandırılmış çıktıyı doğrulamanın standart yolu. (eklenme: 2026-09)
• Choose a License: açık bir depoya hangi lisansın konacağına dair sade açıklamalar. (eklenme: 2026-09)