GitHub Copilot CLI ile Kotlin ve Android geliştirme rehberi

GitHub Copilot CLI’yi Kotlin ve Android projesinde kullanmak için proje kökünde terminal açıp copilot komutunu çalıştırırsınız. Ajan, .github/copilot-instructions.md veya AGENTS.md dosyanızdaki build, test, lint ve mimari kurallarını okur; Gradle wrapper üzerinden işlem yapabilir. Bu rehberde kurulumu, çalışma döngüsünü ve Android’e özgü dikkat noktalarını pratik biçimde ele alıyorum.

Neden GitHub Copilot CLI Kotlin ve Android işine uygun?

Kotlin projeleri genelde çok dosyalıdır; ViewModel, repository, use case, Compose ekranları ve testleri arasında geçiş yapmak terminal tabanlı bir ajan için hızlıdır. Copilot CLI, Gradle hatalarını, lint uyarılarını ve test başarısızlıklarını komut çıktısından okuyup dosyaları düzeltebilir. Özellikle sürüm kataloğu (libs.versions.toml), manifest ve resource dosyaları gibi Android’e özgü yapıları tek bakışta tarayabilir. StateFlow’u Compose’a bağlama, coroutine scope seçme veya sealed class dönüşümü gibi işleri net kurallarla yaptığınızda verimli olur. Ayrıca Gradle sync veya IDE’ye bağımlı kalmadan uzun süren temizlik ve test komutlarını arka planda yürütebilir; siz aynı sırada başka bir işe bakabilirsiniz. Ancak ajanın önerdiği API’lerin güncel sürümlerle uyumlu olduğunu kendiniz doğrulamalısınız.

Projeyi ajan için hazırlamak

Ajan en iyi sonucu, projede kısa ve net bir talimat dosyası varsa verir. Depoya .github/copilot-instructions.md ekleyin; yoksa AGENTS.md da aynı işi görür. Bu dosyaya Gradle komutlarını, modül yapısını, mimari kararları ve test beklentilerini yazın. Ne kadar az genel yapay zeka tavsiyesi, o kadar çok proje gerçeği olursa o kadar tutarlı çıktı alırsınız.

# Kotlin ve Android talimatları

## Komutlar
- Build: ./gradlew assembleDebug
- Birim test: ./gradlew testDebugUnitTest
- Enstrümantasyon testi: ./gradlew connectedDebugAndroidTest
- Lint: ./gradlew lintDebug
- Sürüm kataloğu: gradle/libs.versions.toml

## Modül ve paket düzeni
- app ana modül; feature modülleri feature/<name> altında
- UI: com.example.app.feature.<name>.ui
- Veri: com.example.app.feature.<name>.data
- Ortak kod: core/common, core/designsystem

## Mimari kurallar
- Yeni ekranlarda Jetpack Compose kullan; XML layout ekleme
- ViewModel yalnızca StateFlow veya Compose state expose etsin
- Ağ ve disk işleri Dispatchers.IO, ağır parse Default, asla Main'de engelleme
- Coroutine'leri viewModelScope veya uygun scope ile başlat
- Kullanıcıya görünen metinleri strings.xml'den stringResource ile al

## Test beklentisi
- Her yeni UseCase/repository için birim test yaz (app/src/test)
- Compose ekranları için androidTest altında createAndroidComposeRule ile UI testi ekle
- Test isimleri `givenWhenThen` biçiminde olsun

## Dikkat
- Yeni izin eklemeden önce gerekçeyi yorumda belirt
- Mevcut minSdk 24; daha yüksek API gerektiren çağrıları Build.VERSION ile koru
- Dış kütüphane eklemeden önce sürüm kataloğunu güncelle, doğrudan build.gradle yazma

Dosyayı ekledikten sonra copilot başlatın. İlk istekte ajanın build, test veya lint çalıştırmasına izin verin; böylece proje hakkında daha az varsayım yapar. Talimat dosyanızı ilk kez eklediğinizde ajanın mevcut yapıyı öğrenmesi için kısa bir keşif adımı da yarar sağlar; örneğin ‘Proje modüllerini ve test komutlarını listele’ gibi bir istek gönderin. Daha ayrıntılı başlangıç için GitHub Copilot CLI nasıl kullanılır? Adım adım rehber yolunu izleyebilirsiniz.

Çalışma döngüsü ve örnek promptlar

Büyük bir özelliği tek seferde istemeyin. Şu döngüyü kullanın: önce ajanın mevcut kodu okumasını isteyin, sonra küçük bir değişiklik ve test planı isteyin, testleri/linti çalıştırmasını söyleyin, en son diff’i inceleyin. Her adımda git diff veya IDE’deki diff görünümüyle değişen satırları kendiniz doğrulayın. Ajanın çalıştırdığı komutu onaylamak isterseniz, komutu kendiniz de terminalde çalıştırıp çıktıyı ajanla paylaşabilirsiniz; ancak en akıcı yol, ajanın doğrudan Gradle testlerini çalıştırmasına izin vermektir. Spec odaklı yaklaşımla ilerleyen ekipler için spec odaklı geliştirme rehberi yol gösterebilir.

• Mevcut MainViewModel’i incele; StateFlow alanlarını ve error/loading durumlarını listele. Loading durumu için küçük bir değişiklik yap, ilgili birim testi ekle ve ./gradlew testDebugUnitTest çalıştır.
• FeedScreen içindeki LazyColumn’u FeedItem modeliyle bağla. State’i ViewModel’den collectAsStateWithLifecycle ile topla, preview’ları güncelle ve lint çalıştır.
• UserRepository’deki ağ çağrısını Dispatchers.IO’ya al, sonucu Result ile ViewModel’e taşı. Hata mesajını strings.xml’e ekle ve Compose’da stringResource ile göster.
• Mevcut Espresso testlerini Compose test API’sine geçir; createAndroidComposeRule kullan, testlerin cihaz/emülatörde ./gradlew connectedDebugAndroidTest ile geçtiğini doğrula.
• Gradle sürüm kataloğunda kullanılmayan bağımlılıkları bul ve temizle; ./gradlew assembleDebug ile derlendiğini, ./gradlew lintDebug ile yeni uyarı çıkmadığını göster.

Hangi işler iyi gider, nerelerde dikkat gerekir

Copilot CLI; tekrarlayan refactor, test yazımı, sürüm kataloğu güncellemesi, sealed class hiyerarşisi ve Compose state hoisting gibi konularda iyidir. Buna karşılık API seviyesi uyumu, recomposition yan etkileri ve Gradle plugin sürümleri gibi konularda ürettiği kodu dikkatle incelemeniz gerekir.

Özellikle Android’de ajanın eski AsyncTask, LiveData yerine Flow veya XML yerine Compose gibi projeyle çelişen desenler önermesini engellemek için talimat dosyanızda net kurallar olmalı. Kotlin’de nullable ve smart cast konusunda bazen fazla temkinli veya yanlış !! kullanabilir; diff’i satır satır inceleyin. Gradle sürümlerini veya bağımlılık adlarını uydurursa derleme hatası alırsınız; şüpheli her satırı ./gradlew ile doğrulayın.

Test ve doğrulama

Ajan bir değişiklik yaptığında mutlaka şu sırayı kendiniz de tekrar edin: birim testler, lint, derleme ve varsa enstrümantasyon testi. Ajanın çalıştırdığı komutların çıktısını görmek yetmez; testin gerçekten yeni davranışı kapsadığını ve yanlış pozitif olmadığını kontrol edin. Kotlin coroutine testlerinde runTest ve StandardTestDispatcher kullanıldıysa zamanlama hataları testi yeşil gösterebilir; bu yüzden testi bilinçli kırmızıya çevirip tekrar yeşile döndürmek iyi bir yöntemdir. Compose UI testlerinde waitForIdle ve onNodeWithTag gibi semantik öğeleri tercih edin; ajanın eklediği test tag’lerinin benzersiz olduğundan emin olun. Enstrümantasyon testleri için emülatör veya cihaz bağlı olmalı; ajan cihaz yönetimi yapamaz, bu yüzden cihazın hazır olduğundan emin olun. Son olarak ./gradlew lintDebug çıktısındaki yeni uyarıları kapatmayı değil, kök nedenini çözmeyi isteyin.

Aynı projede birden fazla ajan çalıştırmak: AgentVera

Kotlin ve Android projelerinde birden fazla ajanı paralel çalıştırmak için AgentVera’nın git worktree desteği önemlidir; her ajan ayrı dizinde çalışarak aynı dosyaları ezmez. Otomatik kod incelemesi, ajanın önerdiği recomposition veya lifecycle hatalarını yakalayıp dosya:satır olarak gösterir. Checkpoint’ler, bağımlılık güncellemesi gibi riskli değişikliklerden sonra tek tıkla geri dönmeyi sağlar. Token bütçeleri ise uzun Gradle derleme ve test döngülerinin bütçeyi erken tüketmesini engeller; böylece birden fazla aynı anda çalışırken bile her ajan işini tamamlayabilir.

Sonuç

GitHub Copilot CLI, Kotlin ve Android geliştirmede terminalde güçlü bir yardımcı olabilir; ancak doğru talimatlar, küçük adımlar ve sürekli doğrulama olmadan verim düşer. Ajanın ürettiği kodu Android’in yaşam döngüsü, coroutine ve Compose incelikleri açısından mutlaka gözden geçirin. Kurallarınızı net tutarsanız, tekrarlayan işlerden kurtulur ve daha hızlı ilerlersiniz.