Codex CLI: Terminalde Yapay Zekâyla Çalışmanın İnce Ayarı

Bakın, Geçen ay, İstanbul’da küçük bir fintech projesinde çalışırken terminale bakıp “şunu bir AI halletsin de ben de kahvemi içeyim” dediğim anı çok net hatırlıyorum (evet, doğru duydunuz). Evet, kulağa biraz tembelce geliyor. Ama dürüst olayım: Codex CLI gibi araçlar tam da bu noktada devreye giriyor — kod yazmayı tamamen bırakmıyorsunuz, daha çok işi tarif eden, yöneten. Son kontrolü yapan tarafa geçiyorsunuz, yani mutfakta malzemeleri doğrulayan değil menüyü belirleyen kişi oluyorsunuz.

İşin aslı şu: yapay zekâ terminale girince olay sadece hızlanmak olmuyor (buna dikkat edin). Disiplin de istiyor. Çünkü AI bazen güzel görünen ama içinde minik bir mayın taşıyan kod üretebiliyor. Ben bunu 2024’ün sonlarında kendi yan projemde bizzat yaşadım; aceleyle üretilmiş bir refaktör sonrası testleri çalıştırmadan merge etmeye kalktım ve sonra iki saatlik ufak bir hata avına döndüm. O yüzden açık konuşayım: Codex CLI faydalı, evet… ama kafayı çalıştırmadan kullanılırsa insanı bayağı uğraştırıyor.

Codex CLI neden bu kadar konuşuluyor?

Olayı aslında bayağı basit. Terminal içinde çalışan bir geliştirme ajanı gibi davranıyor — ayrı bir arayüz açıp sürükle-bırak yapmıyorsunuz, direkt komut satırından “şunu yap” diyorsunuz. Araç projeyi okuyup iş üstleniyor. Bu, özellikle.NET tarafında veya script ağırlıklı işlerde ciddi rahatlık sağlıyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Şunu söyleyeyim, Ben bunu ilk test ettiğimde Ankara’daki ev ofisimdeydim. Dürüstçe söyleyeyim, ilk tepki biraz “haa, fena değilmiş” oldu — ne coşku ne hayal kırıklığı, sade bir “işte bu işe yarıyor” hissi. Mesela basit bir REST uç noktası için iskelet oluştururken ya da mevcut bir serviste validation eklerken zaman kazandırıyor. Ama asıl mesele hız değil; bağlamı doğru bir düşüneyim… verince anlamlı sonuç üretmesi. Bağlam yoksa ortaya çıkan şey çoğu zaman genel geçer, hatta bazen gereksiz özgüvenli oluyor.

Bir de şu var. Codex CLI sadece kod üretmiyor; görev orkestrasyonu yapabiliyor, küçük işleri parçalara bölüp yönetmekte iyi. Tam burada eski alışkanlıkları bırakmak gerekiyor çünkü “ben her satırı kendim yazacağım” dönemi artık biraz değişti — bunu kabullenmek bazen zorluyor,. Öyle.

Klasik editör ile farkı ne?

Normal editörde siz yazarsınız, AI varsa size öneri verir. Codex CLI’de ise akış daha komut odaklı ilerliyor — sanki mutfakta şef sizsiniz ama biri elinizdeki malzemeleri doğrayıp hazırlığı yapıyor gibi düşünün, menüyü hâlâ siz belirliyorsunuz.

Ha bu arada, küçük ekiplerde bu yaklaşım bayağı işe yarıyor. En çok da startup tarafında herkesin aynı anda hem ürün hem altyapı hem test peşinde koştuğu günlerde terminalden destek almak güzel bir rahatlık sağlıyor — bunu yaşayanlar bilir.

Günlük kullanımda nasıl düşünmek lazım?

Şahsen, Bence en kilit zihniyet değişimi şu: “kodu ben yazıyorum” yerine “problemi ben tarif ediyorum” demek gerekiyor. Küçük fark. Ama çok şeyi değiştiriyor. Çünkü AI’ye emir vermekle görev tanımlamak arasında dağlar kadar fark var.

Kendi masamda bunu şöyle denedim: önce belirsiz komutlarla başladım, sonra detay verdim… sonuç geceyle gündüz gibi oldu. “Fix bug” dediğinizde size tahmin yürütüyor — hmm, tahmin de değil aslında, daha çok en olası cevabı atıyor ortaya. Ama “UserService içinde email boş geldiğinde null reference oluşuyor, validation ekle. Unit test yaz” dediğinizde iş toparlanıyor, gerçekten fark ediyor. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.

AI ile kod yazarken en büyük hata acele etmek değil; muğlak konuşmak. Ne istediğinizi net anlatırsanız sonuç daha temiz oluyor.

Neyse uzatmayalım, günlük kullanımda mantık şu üç adımda oturuyor:

• Problemi tanımla
• Küçük parçaya böl
• Çıktıyı test et

Küçük startup ile kurumsal proje aynı değil

Küçük bir detay: Küçük bir startup’ta Codex CLI daha cesur kullanılabiliyor (en azından benim deneyimim böyle). Karar döngüsü kısa çünkü. Bir feature fikri gelir gelmez iskelet çıkarılır, hızlıca test edilir ve gerekirse çöpe atılır — bu çeviklik güzel, bunu seviyorum açıkçası. Ama dikkat edin; teknik borç da aynı hızla büyüyebiliyor, bazen farkında bile olmadan.

Kurumsal tarafta ise durum biraz farklı. Orada güvenlik kuralları, kod standartları, review zinciri ve uyumluluk derdi var. Yani AI’nin ürettiği her şeyi olduğu gibi — itiraz edebilirsiniz tabi — kabul etmek diye bir lüks yok. Hatta bazı şirketlerde prompt bile kayıt altına alınıyor — bayağı ciddiye alınıyor yani, şaka değil.

Bir dakika — bununla bitmedi. Bu konuyla ilgili Claude’daki “Skills” Neden Prompt Değil, Bağlam Tasarımıdır? yazımıza da göz atmanızı tavsiye ederim.

Boş komutla olmaz: bağlam verme sanatı

Lafı gevelemeden söyleyeyim: kötü prompt her zaman kötü sonuç demek değil, ama gereksiz vakit kaybı demek neredeyse kesinlikle öyle. Ben bunu geçen yıl İzmir’deki freelance bir projede bizzat yaşadım; sadece “refactor this service” dedim ve çıkan şey çalıştı ama proje mimarisiyle pek barışık değildi. Çalışıyor ama uyumsuz — en kötü durum bu aslında, çünkü sorunu hemen göremiyorsunuz (kendi tecrübem)

Şöyle söyleyeyim, Daha sonra aynı işi bağlamla verdim. Sonuç gözle görülür biçimde iyileşti: sınıfları ayırdı, isimleri düzeltti, birkaç kenar durumu yakaladı ve üstüne test iskeleti bıraktı. İşte tam burada bağlamın önemi ortaya çıkıyor.

Komut tipi	Sonuç kalitesi	Kullanım önerisi
“fix bug”	Zayıf / tahmini	Sadece acil keşif için
“Fix null reference in UserService when email is missing”	Daha iyi	Kodun niyeti belliyken
“Add validation and unit tests for invalid email input”	İyi / kontrollü	Günlük üretim işleri için ideal

Ana fikir: İstek ne kadar netse çıktı o kadar işe yarar oluyor. Şaşırtıcı değil aslında — ama pratikte çoğu kişi tam burada tökezliyor, kendim dahil.

Taslak istemeden düzeltmeye geçme

Bazen direkt düzeltme istemek cazip geliyor çünkü hızlı hissettiriyor. Fakat önce plan isteyip sonra uygulama yaptırmak çoğu zaman daha güvenli oluyor, özellikle orta ölçekli sistemlerde. Şöyle düşünün: önce — kendi adıma konuşayım — yol haritasını görüyorsunuz, sonra direksiyona geçiyorsunuz. Atlarsanız nereye gittiğinizi bilmeden yol alıyorsunuz. Daha fazla bilgi için Agentic AI: Prompt’tan Özerk Döngülere Geçiş yazımıza bakabilirsiniz.

codex "Plan how to migrate this monolith to microservices"
codex "Implement step 1 of the plan"
codex "Write tests for the new boundary between services"

AGENTS.md neden küçük ama etkili bir hile?

Bazı insanlar AGENTS.md dosyasını görünce omuz silkip geçiyor (evet, doğru duydunuz). Bence hata burada başlıyor. Çünkü bu dosya aslında AI’ye proje kültürünü anlatan mini rehber gibi çalışıyor — ben kendi yan repolarımdan birinde buna temiz mimari notu ekledikten sonra araç çok daha tutarlı davranmaya başladı, özellikle test seçimi ve klasör düzeninde fark ettim bunu, küçük ama gerçek bir fark.

Kısa bir not düşeyim buraya. Daha fazla bilgi için Linux 7.0 Geldi: Numara Değişti, Asıl Hikâye Başka yazımıza bakabilirsiniz.

Eğer takımda herkes farklı alışkanlıklarla kod yazıyorsa AGENTS.md gerçekten toparlayıcı olabiliyor. Bir tür “ev kuralı listesi” gibi düşünün: repository pattern kullan, xUnit tercih et, katmanları karıştırma… Basit şeyler. Ama etkisi büyük.

• Tasarımı sabitlemek için iyi çalışır
• Hızla büyüyen karmaşayı azaltır
• Aynı projede farklı geliştiricilerin dilini ortaklaştırır

Test meselesi: asıl oyun burada başlıyor

Açık konuşayım. Bu konunun yıldızı testler. Tüm hikâye biraz buraya çıkıyor zaten. Kod üretmek kolay; doğru kodu korumak zor. AI’nin güzel görünen. Hatalı olabilen çıktıları yüzünden test disiplini eskisinden çok daha önemli hale geldi — bunu abartmıyorum.

Araya gireyim: Geçen sene Aralık ayında Kadıköy’de katıldığım küçük bir meetup’ta biri bana şunu demişti: “AI ile yazılan kodun maliyeti ilk anda düşüyor,. Testi yoksa borcu iki katına çıkıyor.” Abartılı mı? Biraz olabilir. Ama özü doğru.

Test yoksa kodun tamamlandığını varsaymayın. AI çağında bu cümle klişe değil, bildiğiniz emniyet kemeri gibi bir şey.

Unit test mi integration test mi?

İkisine de ihtiyaç var. Unit test hızlı geri bildirim verir; integration test ise parçaların gerçek hayatta kavga edip etmediğini gösteriyor. Ben olsam yeni üretilmiş her hayati akışta ikisini birlikte isterdim — seçmek zorunda değilsiniz, ikisi farklı şeyleri test ediyor zaten.

[Fact]
public void Should_Return_Error_When_Email_Is_Invalid()
{
var service = new UserService();
var result = service.CreateUser("invalid-email");
Assert.False(result.Success);
}

[Fact]
public async Task Should_Create_User_In_Database()
{
var client = _factory.CreateClient();
var response = await client.PostAsync("/users", content);
Assert.Equal(HttpStatusCode.Created, response.StatusCode);
}

Neyse ki modern pipeline’larda dotnet test gibi kontrolleri otomatik koşturmak kolaylaştı. Ama yine de insan eli değmeli, özellikle edge case’lerde. “Çalışıyor mu?” sorusu yetmiyor — “yanlış durumda ne yapıyor?” sorusu lazım (inanın bana). Bu ikisi arasındaki farkı görmezden gelenler sonradan pişman oluyor.

Nerede parlıyor, nerede tökezliyor?

Bana göre Codex CLI’nin en güçlü yani tekrar eden işleri hafifletmesi. API iskeleti, basit refaktör, test taslağı, dokümantasyon yardımı… Bunlarda gayet tatmin edici, valla işe yarıyor. Ancak kompleks domain logic söz konusu olduğunda temkin şart.

Bazen çok kendinden emin şekilde yanlış çözüm verebiliyor. Beklediğim kadar iyi olmadığı anlar oldu mesela — özellikle bağımlılık zinciri uzun olan servislerde ufak ayrıntıları kaçırdı. Bu noktada onu kıdemsiz. Hızlı bir yardımcı gibi görmek daha doğru; her dediğini kabul etmiyorsunuz, ama işi hızlandırıyor.

Kullanırken akılda kalacak kısa liste

1. Küçük işlerle başla
2. Pozitif örnek ver (ne istediğini göster)
3. Pareto mantığıyla ilerle: önce %80’i çıkar, sonra cilala
4. Zorunlu olarak teste bağla

E tabi, geliştirici olarak bizim rolümüz de değişiyor. Artık yalnızca yazan kişi değiliz; denetleyen, parçalayan, önceliklendiren kişiyiz. Bence bunun en güzel bir düşüneyim… tarafı da bu zaten: tekrar eden angaryadan kurtulup gerçekten problem çözmeye vakit kalması. Az değil, bu.

Sıkça Sorulan Sorular

Codex CLI ne işe yarar?

Terminal üzerinden kod üretmek,refaktör yapmak,test taslağı oluşturmak ve bazı geliştirme görevlerini otomatikleştirmek için kullanılır. Bilhassa bağlam verilen projelerde oldukça işe yarar.Codex CLI kullanırken büyük ihtimalle test gerekir mi?

Evet,bence kesinlikle gerekir. AI’nin ürettiği kod bazen doğru görünür ama kenar durumlarda patlar.En azından unit test ve kritik yerlerde integration test şart.Küçük ekipler için uygun mu?

Evet,hatta bazen daha bile uygun.Kararlar hızlı alındığı için çıktı çabuk doğrulanır. teknik borcu büyütmemek için sık sık review yapmak lazım.AGENTS.md dosyası neden önemli?

Coding standardını AI’ye anlatır: Böylece araç proje tarzınıza daha yakın cevap verir. Temiz mimari, klasör düzeni жәne tect tercihleri konusunda tutarlılık sağlar.Kaynaklar ve İleri Okuma

OpenAI Codex Resmi Dokümantasyonu
Codex GitHub Sayfası
Microsoft.NET Testing Dokümantasyonu