Codex, .NET projenizde terminalde codex komutuyla başlar ve proje kökündeki AGENTS.md dosyasındaki talimatları okur. Bu rehberde, Codex’i C#, ASP.NET Core, Entity Framework Core ve xUnit/NUnit ile nasıl verimli kullanacağınızı; kurulum, çalışma döngüsü ve sık yapılan hataları adım adım anlatıyorum. Codex hakkında genel bilgi için Codex sayfasına bakabilirsiniz.
Codex .NET işleri için neden uygun
Codex, .NET ekosisteminin komut satırı araçlarıyla doğrudan çalışır: dotnet build, dotnet test, dotnet format, dotnet ef gibi komutları çalıştırabilir, derleyici hatalarını ve test çıktılarını okuyup düzeltebilir. Çoğu .NET projesi çözüm dosyası (.sln), proje dosyaları (.csproj) ve standart klasör yapısı (src, tests, vs.) kullanır; Codex bu yapıyı hızla öğrenir ve sonraki oturumlarda da hatırlar. ASP.NET Core’da middleware, controller, dependency injection kayıtları ve Entity Framework Core konfigürasyonu gibi tekrar eden parçalar, ajanın küçük değişiklikleri güvenle uygulamasına olanak tanır. C# derleyicisinin ayrıntılı hata mesajları (örneğin CS8602, CS1998) Codex’in sorunun kaynağını bulmasını kolaylaştırır; bu, null olabilirlik uyarıları, async/await hataları ve tip uyumsuzluklarında işinizi hızlandırır. Ayrıca Codex, NuGet paket geri yükleme ve proje referanslarını yönetmede de yeterlidir, ancak paket sürümü çakışmalarında dikkatli olunmalıdır. Codex CLI’nin temel kullanımı için Codex CLI nasıl kullanılır? Adım adım rehber rehberine bakın.
Projeyi ajan için hazırlama ve AGENTS.md
Codex her oturumda proje kökündeki AGENTS.md dosyasını okur. Bu dosyaya .NET projenize özel komutları, klasör kurallarını ve stil tercihlerini yazın. Böylece ajan, hangi çözümü derleyeceğini, hangi test projesini çalıştıracağını, nelere dikkat edeceğini bilir. Bağlam mühendisliği hakkında daha fazla bilgi Bağlam mühendisliği: yapay zeka kodlama ajanları rehberi yazısında.
Aşağıdaki örnek, tipik bir ASP.NET Core + EF Core + xUnit projesi için yeterlidir:
# AGENTS.md
## Komutlar
- Build: dotnet build src/MyApp.sln
- Test: dotnet test tests/MyApp.Tests/MyApp.Tests.csproj
- Lint: dotnet format MyApp.sln --verify-no-changes
## Klasör yapısı
- src/MyApp.Api: ASP.NET Core Web API
- src/MyApp.Core: domain ve servisler
- src/MyApp.Infrastructure: EF Core DbContext ve migration'lar
- tests/MyApp.Tests: xUnit birim testleri
## Kurallar
- Nullable ve implicit usings açık.
- Async metodlarda .Result veya .Wait() kullanma; CancellationToken geç.
- EF Core sorgularında AsNoTracking kullan; N+1'den kaçın.
- Yeni servisleri Program.cs veya ilgili modülde DI'a kaydet.
- Migration'ları sadece `dotnet ef migrations add` ile oluştur, elle düzenleme.Bu dosyayı kısa ve net tutun; Codex her komut çalıştırmadan önce bu talimatlara uyar. dotnet format --verify-no-changes biçimlendirme hatalarını kontrol eder; --no-restore gibi bayraklar eklerseniz, build süresini kısaltabilirsiniz. Kurallar bölümünde nullable, async/await, EF Core ve DI ile ilgili projeye özel kısıtları yazın; bu, Codex’in ürettiği kodun kod tabanınızla uyumlu olmasını sağlar. Örneğin, DateTime yerine DateTimeOffset kullanımı, ConfigureAwait(false) gerekip gerekmediği gibi kararları da buraya ekleyebilirsiniz.
Çalışma döngüsü
Codex ile çalışırken şu döngüyü izleyin: önce ne yapılacağını net bir prompt ile planlatın, sonra küçük bir değişiklik yaptırın, ardından dotnet test çalıştırıp sonuçları inceleyin, en son git diff ile değişiklikleri gözden geçirin. Tek seferde büyük bir refactoring istemek yerine, her adımda derleme ve testleri yeşil tutmak hata ayıklamayı kolaylaştırır. Codex’in her turdaki değişikliklerini git diff ile incelemek, istenmeyen dosya değişikliklerini ve gereksiz using eklemelerini yakalamanızı sağlar. Ayrıca Codex’in ürettiği testleri de gözden geçirin; bazen sadece geçmesi için testi zayıflatabilir.
Örnek promptlar:
- “Mevcut ASP.NET Core projesindeki tüm servis kayıtlarını incele, eksik veya yanlış lifetime’a sahip olanları listele.”
- “OrderService içindeki GetOrders metodunu async yap, CancellationToken parametresi ekle ve ilgili testleri güncelle.”
- “EF Core’a yeni Category entity’si ekle, DbContext’e DbSet olarak ekle, migration oluştur ve gerekli endpoint’i yaz.”
- “Şu test neden başarısız? [test adı] Hata mesajını analiz et ve düzelt.”
- “dotnet format çalıştır ve biçimlendirme hatalarını düzelt; değişiklikleri göster.”
Her prompt sonrası ajanın ürettiği diff’i okuyun; Codex bazen istenmeyen using’leri veya proje dosyası değişikliklerini ekleyebilir. Codex’e tek seferde birden çok bağımsız değişiklik vermek yerine her değişikliği ayrı bir adımda isteyin ve her adımda test çalıştırın. Eğer Codex bir hatayı düzeltirken başka bir hataya yol açarsa, hatayı geri alıp daha spesifik talimat verin.
Codex’in iyi yaptığı .NET işleri ve tuzaklar
Codex özellikle standart CRUD endpoint’leri, servis katmanı, EF Core sorguları, xUnit/NUnit testleri ve dotnet CLI komutlarını çalıştırmada başarılıdır. Aşağıdaki tablo, tipik görevler için iyi prompt örneklerini gösterir.
| Görev | Codex’e verilebilecek iyi prompt |
|---|---|
| Yeni endpoint ekleme | “ProductsController’a GET /api/products/{id} endpoint’ini ekle, asenkron olsun, bulunamazsa 404 döndürsün.” |
| EF Core sorgu iyileştirme | “GetOrders metodunu AsNoTracking ve Select projeksiyonu ile yeniden yaz, N+1 sorgusunu gider.” |
| Birim testi yazma | “CheckoutService için xUnit testleri yaz; IOrderRepository ve IPaymentGateway bağımlılıklarını mock’la.” |
| Refactoring | “Controller içindeki iş mantığını ayrı bir OrderService sınıfına taşı, DI’a kaydet ve controller’ı incelt.” |
Buna karşılık Codex’in .NET özelinde en sık tökezlediği noktalar şunlardır:
- EF Core’da lazy loading veya client-side evaluation: Codex bazen tüm entity’yi çekip bellekte filtreleyebilir; bu N+1 sorgusuna veya performans kaybına yol açar. Sorgularda AsNoTracking ve Select projeksiyonu kullanmasını isteyin ve oluşan SQL’i incelemek için
ToQueryString()metodunu eklemesini söyleyebilirsiniz. - async void, Task.Result veya deadlock riskleri: Codex, asenkron metodu sync sarmalamaya çalışabilir; özellikle ASP.NET Core’da
Task.RunveyaGetAwaiter().GetResult()kullanımı ölümcül olabilir. - Nullable reference types uyarılarını bastırmak için
!operatörünü aşırı kullanması: bu, gerçek null hatalarını gizler. Bunun yerine null kontrolü veyaArgumentNullException.ThrowIfNullkullanmasını isteyin. - DI yaşam döngüsü hataları: scoped servisi singleton içine enjekte etmek gibi; Codex böyle bir kayıt ekleyebilir, çalışma zamanında hata alırsınız.
- NuGet paket sürümü uyumsuzlukları: Codex bazen en son sürümü ekleyip diğer bağımlılıkları bozabilir.
- Proje dosyası düzenlemeleri: gereksiz
<PackageReference>ekleyebilir veya hedef framework’ü değiştirebilir.
Bu tür değişiklikleri her zaman diff’te kontrol edin, derleyici uyarılarını sıfırlamaya çalışın ve şüpheli kodda test yazmasını isteyin. Özellikle EF Core migration’larında oluşan Snapshot dosyasını ve migration içindeki Up/Down metodlarını gözden geçirin; Codex bazen yanlış veri tipi seçebilir.
Test ve doğrulama
Codex, testleri çalıştırıp sonuçları yorumlayabilir; ancak doğrulamayı siz yönetin. Her değişiklikten sonra dotnet test çalıştırın, başarısız testleri Codex’e tekrar verin. Belirli bir testi çalıştırmak için dotnet test --filter \"FullyQualifiedName~MyTest\" komutunu kullanın; Codex bu filtreyi prompt’ta isteyebilir. xUnit ve NUnit projelerinde test runner çıktısı farklı olabilir; Codex hangi framework’ün kullanıldığını proje dosyasından anlar. Coverage raporu için dotnet test /p:CollectCoverage=true gibi ek parametreler gerekiyorsa bunu AGENTS.md’ye yazın. Ayrıca dotnet test --no-build ile derleme yapmadan testleri hızla tekrar çalıştırabilirsiniz. Eğer entegrasyon testleri varsa, bunları ayrı bir test projesinde tutun ve Codex’e sadece birim testlerini çalıştırmasını söyleyin; böylece CI süresini kısaltırsınız. Codex’in bir testi geçirmek için üretim kodunu gereksiz yere değiştirmesini önlemek için, test değişikliklerini ayrıca inceleyin ve davranışı değiştiren değişiklikleri reddedin. Ayrıca dotnet test --logger \"trx;LogFileName=testresults.trx\" ile sonuçları dosyaya yazabilirsiniz; Codex bu dosyayı okuyup özet çıkarabilir.
Birden fazla ajanı AgentVera ile çalıştırma
AgentVera, Codex dahil birden çok kodlama ajanını aynı pencerede gerçek terminal panellerinde yan yana çalıştırır. .NET projelerinde en kritik özellik, her ajanın kendi git worktree’sinde çalışabilmesidir; böylece paralel görevler birbirinin dosyalarını ezmez. Ajanın işi bitince ikinci bir model otomatik kod incelemesi yapar ve bulguları dosya:satır olarak gösterir; bu, özellikle EF Core ve DI hatalarını yakalamada faydalıdır. Her turun anlık görüntüsü alınır, tek tıkla geri alınabilir. Token bütçeleri ile ajan başına harcama sınırı koyabilirsiniz; böylece uzun süren derleme/test döngülerinde maliyet kontrolü sağlanır. Kurulum ve ilk proje için AgentVera nasıl kullanılır: ilk proje, ajanlar ve ızgara sayfasına bakın.
Sonuç
Codex, .NET projelerinde AGENTS.md ile yapılandırıldığında derleme, test ve refactoring döngüsünü ciddi şekilde hızlandırır. Küçük adımlarla çalışın, diff’leri inceleyin ve .NET’e özgü tuzakları testlerle yakalayın. Birden fazla ajanı paralel kullanmak istediğinizde AgentVera, worktree ve otomatik inceleme ile güvenli bir ortam sunar.