Gemini CLI, Django projenizin kök dizininde gemini komutuyla başlattığınız bir terminal ajanıdır; doğru hazırlanmış bir GEMINI.md ve küçük adımlı bir çalışma döngüsüyle model, migration, ORM ve DRF işlerini hızlandırır. Aşağıda kurulumu, görev döngüsünü ve Django’ya özgü tuzakları pratik biçimde ele alıyorum.
Neden Gemini CLI Django işlerine uygun
Django projeleri tekrarlayan ve birbirine bağlı dosyalardan oluşur: model değişince migration, serializer, view ve testler etkilenir. Gemini CLI bu zinciri proje bağlamıyla birlikte değerlendirir; GEMINI.md’deki komutları çalıştırarak test ve lint çıktısını kendi döngüsüne alır. Örneğin python manage.py makemigrations sonrası oluşan dosyayı görebilir, pytest çıktısındaki hataya göre düzeltme yapabilir. Bu, Django’nun ORM katmanındaki ilişkili değişiklikleri tek seferde yürütmek için uygundur. Gemini CLI’nın genel çalışma biçimi için Gemini CLI sayfasına bakabilirsiniz.
Ajan aynı zamanda views, templates ve DRF serializer’larındaki tekrarlayan kalıpları üretebilir. Asıl değeri, siz pytest-django ile testleri çalıştırdıkça hataları geri beslemesidir; böylece Django’ya özgü import ve uygulama kurulum hatalarını erkenden yakalar. Örneğin yeni bir apps/orders uygulaması oluşturulurken ajan; models.py, admin.py, apps.py, migrations klasörü ve test dosyalarını birlikte düzenleyebilir, apps.py içindeki default_auto_field ayarını ve __init__.py dosyasını unutmaz. Django’nun request/response döngüsü, middleware sırası ve template bağlamı hakkında yaygın bilgiye sahip olduğundan, view ve şablon düzeltmelerinde de işe yarar. Yine de projenizin özel context processor’ları veya middleware’leri varsa bunları GEMINI.md’de belirtmek gerekir. Ayrıca AUTH_USER_MODEL, app_label ve related_name gibi projeye özgü kabullerin altını çizmek gerekir; ajan bu bilgileri GEMINI.md’den okumadıkça varsayılan ayarlarla çalışabilir.
Projeyi ajan için hazırlamak
Gemini CLI proje talimatlarını GEMINI.md dosyasından okur; bu yüzden dosyayı Django’ya göre netleştirmek gerekir. Aşağıdaki örnek, build, test, lint komutlarını, klasör kurallarını ve Django’ya özgü beklenen davranışları gösterir. Daha geniş bir başlangıç için Gemini CLI nasıl kullanılır? Adım adım rehber adım adım rehberine de bakılabilir.
# GEMINI.md
# Build/test komutları
- Test: pytest -q
- Lint: ruff check .
- Format: ruff format --check .
- Tip kontrolü: mypy .
# Klasör kuralları
- Django projesi `config/` içinde settings, `apps/` içinde her uygulama.
- Migration dosyalarını elle düzenleme; her model değişikliğinde `python manage.py makemigrations` çalıştır.
- API uçları `apps/<app>/api/` altında serializer.py, views.py, urls.py olarak tutulur.
# Django'ya özel kurallar
- Her model için `__str__` yaz, `Meta.ordering` ekle.
- ForeignKey/OneToOneField/ManyToManyField alanlarında `related_name` açıkça belirt.
- DRF serializer'larında `fields = '__all__'` kullanma, açık liste yaz.
- Testler pytest-django ile `pytest.mark.django_db` kullanılarak yazılır.Bu dosya sayesinde ajan, pytest komutunu bilir, apps/<app>/api/ yapısına uyar ve __all__ serializer alanları gibi tuzaklardan kaçınır. Dosyayı sürüm kontrolüne ekleyin ve ajan başlatıldığında güncel olduğundan emin olun. Örneğin yeni bir uygulama eklediğinizde klasör kuralını güncellerseniz ajan yanlış yere dosya üretmez. Ayrıca DJANGO_SETTINGS_MODULE gibi ortam değişkenlerini komut satırına yazmak yerine .env dosyasında tanımlayıp GEMINI.md’de referans vermek daha temiz olur. pytest-django için pytest.ini içinde DJANGO_SETTINGS_MODULE = config.settings.local gibi bir satır bulunuyorsa, bunu da GEMINI.md’ye ekleyin; ajan testleri doğru ayarlarla çalıştırabilsin. mypy ve django-stubs kullanıyorsanız, model alanları için tip kontrolü yapılacağını belirtmek faydalıdır.
Çalışma döngüsü
Django’da güvenli bir döngü şöyle işler: görevi tek bir modül veya davranışla sınırlandırın, ajanın plan yapmasını isteyin, üretilen kodu uygulayın, pytest -q ile testleri çalıştırın ve git diff üzerinde migration, serializer ve import değişikliklerini inceleyin. İyi prompt yazımı için Kodlama ajanları için prompt nasıl yazılır? sayfasındaki kalıpları uygulayabilirsiniz.
Önce ajanın plan yapmasını isteyin; örneğin “Order modeline status alanı eklemeden önce hangi dosyaları değiştireceğini ve migration adını listele” demek işe yarar. Ajan dosya listesini verince, onayladıktan sonra uygulama adımına geçin. Küçük adım önemlidir: tek seferde hem modeli hem serializer’ı hem view’i değiştirmek yerine, önce modeli ve migration’u halledin, testleri çalıştırın, ardından serializer’ı ekleyin. Her adımdan sonra pytest -q apps/orders/tests/ gibi hedefe odaklı test komutu çalıştırıp sonucu ajana geri bildirin. Son olarak git diff ile migration dosyasındaki operations listesini, serializer’daki fields listesini ve import değişikliklerini gözden geçirin.
Aşağıdaki promptlar sık kullanılan Django görevleri için başlangıç noktasıdır.
apps/ordersiçindekiOrdermodelinestatusalanı ekle; seçenekleriCharFieldile tanımla, migration üret ve ilgili testleri çalıştır.- DRF’de
ProductSerializerveProductViewSetoluştur; router’ıconfig/urls.pyiçine bağla,Productiçin list/create/retrieve testleri yaz. Customer.emailalanına unique constraint ekle; önce duplicate kayıtları tespit eden bir management command yaz, sonra migration üret ve testleri koş.cartuygulamasındaki N+1 sorgularını bul,select_related/prefetch_relatedekleyip testleri yeşil tut.OrderSerializer’da nestedOrderItemgösterimini ekle, ancak performans içinPrefetchkullan ve mevcut testleri güncelle.
Hangi Django görevlerinde iyi, nerelerde dikkat
Tablo, sık kullanılan görevlerde ajanın nerede verimli olduğunu ve hangi noktalarda denetim gerektiğini özetler.
| Görev | İyi prompt | Dikkat edilecek nokta |
|---|---|---|
| Model ve migration | Order modeline status alanı ekle, migration üret ve testleri çalıştır | Migration dosyasında veri kaybı veya geri alınamaz RunPython adımı olmasın. |
| DRF serializer/view | ProductSerializer ve ProductViewSet oluştur, router bağla ve test yaz | fields listesi açık olsun; nested serializer performansı ve source kullanımı doğru mu? |
| ORM sorgu optimizasyonu | N+1 sorgularını tespit et, select_related/prefetch_related ekle | Gereksiz prefetch_related ekleyip bellek kullanımını artırmasın; queryset’i testle doğrula. |
| Şablon ve view | OrderDetailView şablonunu oluştur, context adlarını düzelt | View’da get_context_data içinde gereksiz veritabanı sorgusu yapmasın. |
Ajan, model alanı ekleme, temel serializer oluşturma, viewset yazma ve şablon düzeltme gibi işlerde oldukça başarılıdır. Ancak Django’ya özgü bazı bölgelerde yakın takip gerekir. Migration üretiminde, ajan bazen AlterField ile RemoveField + AddField arasında karışıklık yaşayabilir veya RunPython adımını geri döndürülemez biçimde yazabilir. Signals kullanıyorsanız, ajan models.py içine sinyal tanımı eklediğinde apps.py içindeki ready() metoduna kayıt koymayı unutabilir; bu da testlerde sinyalin çalışmamasına yol açar. Admin panellerinde list_display, search_fields ve readonly_fields gibi seçenekleri atlayabilir. Soyut model kalıtımı, proxy model veya GenericForeignKey gibi ileri düzey ORM konularında ajanın önerdiği kodu mutlaka gözden geçirin; bazen yanlış app_label veya yanlış veritabanı tablosu kullanabilir. DRF’de permission_classes, authentication_classes ve nested serializer performansı gibi konuları test etmek önemlidir.
Django’da test ve doğrulama
pytest-django, ajanla çalışırken en güvenilir doğrulama katmanıdır. GEMINI.md’ye pytest -q --reuse-db gibi bir test komutu yazarsanız ajan her değişiklikten sonra hızlı geri bildirim alır. Ancak --reuse-db şeması değiştiğinde yanıltabilir; migration sonrası tam veritabanı kurulumu için pytest --create-db çalıştırmak güvenli olur. Ajanın ürettiği migration dosyasını python manage.py makemigrations --check ile doğrulayın; git diff üzerinde operations listesini okuyun. DRF için testlerde APIClient ve force_authenticate kullanımı standarttır; ajanın testleri gerçekten veritabanına erişiyorsa @pytest.mark.django_db eklediğinden emin olun. Ajan test yazarken reverse ile URL çözümlemesi yapabilir; testlerde Client yerine APIClient kullanması gerektiğini GEMINI.md’ye yazın. Migration testleri için django_test_migrations gibi ek paketler kullanıyorsanız bunu da belirtin.
Sorgu sayısını doğrulamak için django_assert_num_queries fixture’ını kullanabilirsiniz. Örneğin ajan bir view’i optimize ettiyse, test dosyasına with django_assert_num_queries(2): response = client.get(reverse('order-detail', args=[order.pk])) eklemesini isteyin. Bu, N+1 problemini gerçekten çözdüğünü kanıtlar. Ayrıca CaptureQueriesContext ile üretilen SQL’e bakabilirsiniz. Testlerden sonra ruff check . ve mypy . komutlarını mutlaka çalıştırın; ajan bazen kullanılmayan importlar veya tür hataları üretebilir. python manage.py check de Django ayarlarındaki hataları yakalamak için faydalıdır. Son olarak git diff --stat ile değişen dosyaların kapsamını gözden geçirin; beklenmedik dosyalarda değişiklik varsa ajanı uyarın.
Aynı Django projesinde birden fazla ajanı AgentVera ile çalıştırmak
AgentVera, Gemini CLI dahil birden fazla kodlama ajanının gerçek komut satırı araçlarını tek pencerede yan yana çalıştırır. Django’da model, API ve test görevlerini ayrı git worktree’lerde paralel yürütebilir, böylece ajanlar birbirinin dosyalarının üzerine yazmaz. Bir ajanın turu bitince otomatik kod incelemesi bulguları file:line ile gösterir; checkpoints sayesinde hatalı bir migration düzeltmesini tek tıkla geri alıp oturumu adım adım yeniden oynatabilirsiniz. Token bütçeleri ise ajanın gün içinde kontrolden çıkmasını engeller.
Sonuç
Gemini CLI, Django projenizde GEMINI.md ile net kurallar tanındığında model, migration, DRF ve test işlerini hızlandıran pratik bir ajan olur. Başarı, büyük görevleri tek seferde istemekten değil; küçük adımlar, test döngüsü ve diff denetiminden gelir. Bu disiplinle ajanı güvenle kullanabilirsiniz.