GitHub Copilot CLI ile Ruby on Rails geliştirme rehberi

GitHub Copilot CLI’yi bir Ruby on Rails projesinde kullanmak için proje kök dizininde copilot komutunu çalıştırmak yeterlidir; ajan, .github/copilot-instructions.md veya AGENTS.md dosyasındaki proje talimatlarını okuyarak Rails komutlarını ve test döngüsünü öğrenir. Bu rehberde Rails’e özel kurulum, etkili çalışma döngüsü, tipik tuzaklar ve çoklu ajan kullanımı pratik biçimde anlatılıyor.

Neden GitHub Copilot CLI Rails işlerine uygun

Rails, katı klasör yapısı ve konvansiyonları sayesinde ajanların bağlamı hızla kavramasını sağlar. app/models, app/controllers, app/views, db/migrate gibi standart konumlar; Active Record ilişkileri, Strong Parameters ve RESTful route düzeni Copilot CLI’nin doğru kod üretme olasılığını artırır. Ajan bin/rails generate gibi üreticileri kullanabilir, RSpec ya da Minitest dosyalarını mevcut yapıya uygun yazabilir. Hotwire ile Turbo Frames/Streams gibi Rails’e özgü araçları da bilir; ancak en iyi sonuç, beklentilerin açıkça yazıldığı komutlarla alınır. Ayrıca Rails’in schema.rb dosyası, ajanın mevcut veritabanı yapısını hızlıca anlamasını sağlar. Örneğin, yeni bir migration yazarken ajan mevcut tabloları ve indeksleri schema.rb üzerinden inceleyebilir. Bu, özellikle büyük projelerde manuel dosya gezintisini azaltır ve daha tutarlı kod üretir. GitHub Copilot CLI hakkında genel kurulum ve kullanım için GitHub Copilot CLI sayfasına bakabilirsiniz; daha ayrıntılı adım adım rehber için ise GitHub Copilot CLI nasıl kullanılır? Adım adım rehber yazısı faydalıdır.

Projeyi ajan için hazırlama

Ajanın Rails projesinde doğru çalışması için .github/copilot-instructions.md veya AGENTS.md dosyasına komutlar, klasör kuralları ve Rails’e özgü kısıtlar yazılmalıdır. Bu dosya, ajanın her turda doğru komutları kullanmasını ve Rails konvansiyonlarından sapmamasını sağlar. Aşağıdaki örnek, RSpec ve RuboCop kullanan tipik bir Rails 7 projesi için kısa ama yeterli bir başlangıçtır:

# Ruby on Rails project instructions

## Commands
- Install: `bundle install`
- Prepare DB: `bin/rails db:prepare`
- Run tests: `bin/rails spec`
- Run one test: `bin/rails spec spec/models/user_spec.rb:42`
- Lint: `bin/rubocop`
- Run server: `bin/rails server`
- Assets: `bin/rails assets:precompile`

## Conventions
- MVC: app/models, app/controllers, app/views
- Business logic: app/services (plain Ruby objects)
- Tests: RSpec with FactoryBot; factories in spec/factories
- Use Hotwire (Turbo Frames/Streams) instead of custom JavaScript where possible

## Rules
- Always generate migrations with `bin/rails generate migration`
- Do not edit db/schema.rb manually
- After a migration, run `bin/rails db:migrate` and `bin/rails db:rollback` to verify it is reversible
- Run RuboCop before completing a task
- Prefer existing partials and helpers before creating new ones

Bu dosyada yer alan komutlar ajanın doğru test ve lint araçlarını kullanmasını sağlar. Örneğin, bin/rails spec yerine yanlışlıkla rspec çalıştırmak Spring preloader’ı atlayabilir ve daha yavaş çalışır; bu yüzden Rails wrapper komutları belirtilmelidir. Klasör kuralları, ajanın iş mantığını app/services altına koymasını ve view katmanında app/views dışında dosya oluşturmamasını sağlar. Migration kuralı ise ajanın db/schema.rb dosyasını elle değiştirmesini engeller; çünkü Rails bu dosyayı migration’lardan otomatik üretir. Ayrıca Hotwire tercihi, ajanın gereksiz JavaScript kütüphaneleri eklemesini önler ve Rails’in varsayılan stack’ine sadık kalmasını sağlar. Bu talimat dosyasını yazarken daha genel rehberlik için CLAUDE.md nasıl yazılır? AGENTS.md ve GEMINI.md rehberi bağlantısındaki AGENTS.md yazım ipuçlarından faydalanabilirsiniz.

Eğer projeniz Minitest kullanıyorsa, komutları bin/rails test ve bin/rails test test/models/user_test.rb:42 olarak değiştirmeniz yeterlidir. Ayrıca spec/factories yerine test/fixtures altındaki fixture dosyalarını belirtmek gerekir. Ajan, bu farkları otomatik algılamaz; bu yüzden talimat dosyasında açıkça yazılmalıdır.

Çalışma döngüsü: planla, küçük adım at, test et, diff’i incele

Copilot CLI ile verimli çalışmanın temeli, ajanı büyük bir görevle baş başa bırakmak yerine küçük ve doğrulanabilir adımlara bölmektir. Şu döngü Rails projelerinde iyi sonuç verir:

1. Önce ajanın mevcut kodu incelemesini ve kısa bir plan çıkarmasını isteyin. Bu adım, ajanın hangi dosyaları değiştireceğini ve hangi testleri etkileyeceğini anlamasını sağlar. Örneğin, yeni bir özellik eklerken ajanın routes.rb, controller, model ve view dosyalarını listelemesini isteyebilirsiniz.
2. Plana göre tek bir somut adım seçin (örneğin migration + model testi). Ajanın aynı anda birden fazla bağımsız değişiklik yapması, diff’in incelenmesini zorlaştırır ve hata kaynağını bulmayı geciktirebilir.
3. Ajan değişikliği yaptıktan sonra ilgili testleri çalıştırın. Rails’te genellikle model veya request spec’leri yeterlidir; tüm suite’i çalıştırmak her adımda zaman kaybıdır.
4. git diff ile değişen dosyaları satır satır gözden geçirin. Özellikle migration, schema veya route dosyalarındaki beklenmedik değişikliklere dikkat edin.
5. Hata ya da eksik varsa, test çıktısı ve diff bağlamını ajanla paylaşarak düzeltme isteyin. Doğrudan hata mesajını yapıştırmak, ajanın sorunu daha hızlı çözmesini sağlar.

Aşağıdaki prompt’lar bu döngüye uygun tipik Rails görevlerini gösterir:

• “User modeline role enum alanı ekleyen migration’ı bin/rails generate migration ile oluştur, model validasyonlarını güncelle ve ilgili RSpec testlerini yaz.”
• “PostsController#create aksiyonunu Hotwire Turbo Stream ile güncelle; mevcut partial’ları kullan ve request spec’lerini çalıştır.”
• “İlgili controller ve view’lardaki N+1 sorguları tespit et, Active Record includes ile düzelt ve testlerin yeşil kalmasını sağla.”
• “Yeni Comment modeli için migration, model, RESTful controller, routes ve request spec’lerini oluştur; ardından bin/rails spec komutunu çalıştır.”
• “RuboCop uyarılarını sadece değişen dosyalarda gider; testleri bozma ve sonucu bin/rubocop ile doğrula.”

Bu liste, ajanın Rails ekosisteminde en çok işe yarayan görevlerini kapsar. Her adımda tek sorumluluk vermek, ajanın bağlamı korumasına ve hataların hızlı bulunmasına yardımcı olur. Ayrıca plan adımında ajanın mevcut kodu taraması için Yapay zeka ajanları için kod haritası: grep’siz arama bağlantısındaki kod haritası yaklaşımını kullanabilirsiniz.

Copilot CLI’nin iyi yaptığı Rails işleri ve dikkat edilecekler

Copilot CLI; CRUD scaffold’ları, Active Record ilişkileri, validasyonlar, RSpec factory ve request spec’leri, Hotwire partial güncellemeleri ve basit refactor işlerinde oldukça başarılıdır. Ancak Rails’e özgü bazı alanlarda dikkatli gözden geçirme şarttır:

Özellikle migration’larda ajan bazen veri taşıyan geri dönüşü olmayan kodlar yazabilir; bu yüzden her migration sonrası bin/rails db:rollback ve bin/rails db:migrate çalıştırıp şemayı elle kontrol edin. Ayrıca Zeitwerk otomatik yükleme kurallarına uymayan dosya adları veya sabitler ekleyebilir; bin/rails zeitwerk:check komutu bu tür hataları yakalar. View katmanında ise ajan, mevcut partial’ları yok sayıp benzer yapıda yeni dosyalar üretebilir; bu da kod tabanını şişirir. Controller refactor işlerinde ajan, mevcut authorization mantığını (örneğin Pundit veya CanCanCan) atlayabilir veya Strong Parameters listesine yanlış alan ekleyebilir. Bu tür değişikliklerde özellikle güvenlik açısından diff’i dikkatle incelemek gerekir.

Asset pipeline konusunda da dikkatli olunmalıdır. Ajan, eski tarz //= require direktifleri yerine importmap veya jsbundling kullanılan projelerde yanlış asset ekleyebilir. Ayrıca app/assets/config/manifest.js dosyasını gereksiz yere değiştirebilir. Bu yüzden asset ile ilgili görevlerde ajanın yalnızca gerekli dosyaları değiştirdiğinden emin olun.

Test ve doğrulama

Rails’te ajanla çalışırken test, döngünün ayrılmaz parçasıdır. Ajan her değişiklikten sonra ilgili testi veya tüm suite’i çalıştırmalı, siz de çıktıyı incelemelisiniz. RSpec kullanıyorsanız bin/rails spec spec/models/user_spec.rb:42 gibi satır bazlı komutlar hızlı döngü sağlar; Minitest için bin/rails test test/models/user_test.rb kullanılır. Ajan test eklerken mevcut factory veya fixture altyapısını kullanmaya zorlanmalıdır; aksi halde testler çalışmaz.

Önce test yazdırıp sonra implementasyonu yaptırmak, ajanın neyi başarması gerektiğini netleştirir. Örneğin, bir Order modeline total_price metodu eklemek istiyorsanız, ajanın önce order_spec.rb içinde beklenen davranışı test etmesini isteyin, ardından testi geçecek kodu yazmasını söyleyin. Bu yaklaşım, ajanın yanlış varsayımlar yapmasını azaltır ve sonucun doğrulanmasını kolaylaştırır. Daha kapsamlı bir süreç için Yapay zekâ ajanlarıyla spec odaklı geliştirme rehberi bağlantısındaki spec odaklı geliştirme yaklaşımı Rails projelerine uyarlanabilir.

Ayrıca system testleri (Capybara) eklerken ajanın selenium veya rack_test driver’larını doğru kullandığından emin olun. Hotwire ile yapılan canlı güncellemelerde assert_selector gibi bekleme metodları kritik öneme sahiptir; ajan bazen bu asenkron beklentileri atlayabilir. Bu durumda test hatasını ajanla paylaşarak düzeltme istemek etkilidir.

Birden fazla ajanı tek Rails projesinde çalıştırma: AgentVera

Ruby on Rails projesinde birden fazla Copilot CLI oturumunu yönetmek için AgentVera masaüstü uygulaması işe yarar. Her ajan kendi git worktree’sinde çalıştığı için aynı anda birden fazla ajan dosyaları ezmeden paralel geliştirme yapabilir; Rails’te sık karşılaşılan çakışmalar böylece azalır. Ajanın turu bittiğinde ikinci bir model kodu otomatik inceler ve bulgular dosya:satır olarak gösterilir. Ayrıca her turun anlık görüntüsü alındığından, kötü bir migration veya refactor tek tıkla geri alınabilir. Token bütçeleri ise ajan başına, tur başına ve günlük sınırlarla maliyeti kontrol altında tutar.

Sonuç

GitHub Copilot CLI, doğru talimatlar ve küçük adımlarla Ruby on Rails geliştirmede ciddi zaman kazandırır. Önemli olan, Rails konvansiyonlarını talimat dosyasına yazmak, her değişikliği test ve diff ile doğrulamak, migration gibi kritik alanlarda gözden geçirmeyi elden bırakmamaktır. Birden fazla ajanla çalışırken git worktree ve otomatik inceleme gibi araçlar süreci güvenli hale getirir.