GitHub, GitHub Copilot CLI, Copilot uygulaması ve Copilot SDK'nın arkasında çalışan runtime'ı, daha önce TypeScript, Node.js ve V8 motoruna dayanırken yeniden oluşturdu. GitHub blogunda yayımlanan yazıya göre sonuç, çoğu yapay zekâ ajanlarının yardımıyla 128 çekme isteği üzerinden ana dala kademeli olarak birleştirilen, üretim için özel olarak yazılmış 800.000'den fazla Rust satırı oldu.
Yazar, çalışmanın birkaç ay içinde ve esas olarak tek bir geliştiricinin katılımıyla tamamlandığını; bu sırada ekibin geri kalanının runtime'ın yeteneklerini geliştirmeye ve kullanım alanını genişletmeye devam ettiğini söylüyor. GitHub, geçişten sonra performansın “büyük ölçüde” iyileştiğini belirtiyor, ancak yazının erişilebilen bölümünde bu iyileşmeyi ölçmek için ayrıntılı rakamlar sunmuyor.
Sorun yalnızca komut satırı arayüzünde değildi
Copilot runtime yalnızca CLI'yi çalıştırmakla sınırlı değil. GitHub Copilot CLI, Copilot uygulaması ve Copilot SDK'nın yanı sıra VS Code, Visual Studio, Cloud Agent, Copilot Code Review, Copilot Cowork, Copilot Studio ile Excel, Outlook, PowerPoint ve Word uygulamalarını kapsayan birden fazla sürüm ve ürün tarafından kullanılan ortak bir katman.
Önceki tasarımda runtime ile CLI arayüzü büyük ölçüde iç içeydi. Ürünlerin programatik erişime ihtiyaç duyması durumunda SDK, pratikte CLI'nin üzerine kuruluyordu; ayrı bir Node.js süreci çalıştırılıyor ve bu süreçle JSON-RPC üzerinden iletişim kuruluyordu. Bu yaklaşım hızlı ve esnekti, ancak her tüketici uygulamaya işletim maliyeti getiriyordu.
Yeni bir CopilotClient oluşturmak, Node.js ve V8'ı barındıran ek bir süreç çalıştırmak, TypeScript'ten üretilen JavaScript kodunu ayrıştırmak ve motorla ilişkili belleği taşımak anlamına geliyordu. Node.js'deki çökmeler oturumu sonlandırabilirken uygulamaların en az iki süreci izlemesi gerekiyordu. Yazıya göre C#, TypeScript, Python, Rust, Go ve Java ile yazılmış SDK paketleri, başka bir şey için Node.js'e ihtiyaç duymasalar bile, ek runtime için çalışma kümesinden en az yaklaşık 100 megabayt taşıyordu.
Neden Rust seçildi?
GitHub yeni katman için net hedefler belirledi: runtime'ı TUI arayüzünden ayırmak, bağımlılıkları ve işletim maliyetini azaltmak, aynı süreç içinde gömülmeyi mümkün kılmak ve ölçeklenebilirlik ile güvenilirliği geliştirmek. Ayrıca farklı FFI mekanizmaları üzerinden altı SDK sürümünden runtime'ın kullanılmasına olanak tanıyan bir C ABI arayüzüne ihtiyaç vardı.
Yazıya göre Rust, daha yeni bir güvenlik duruşunu destekleyen, tedarik zinciri risklerini azaltan ve tasarım gereği doğru koda daha fazla destek sağlayan bir araç zincirinin yanı sıra bu gereksinimlerin karşılanmasına yardımcı oldu. Ancak deneyimin her büyük TypeScript projesini Rust'a dönüştürme önerisi olmadığını da vurguluyor; seçim, başlatma, bellek, gömme ve kaynak tüketiminin öngörülebilirliğiyle ilgili belirli gereksinimlerden kaynaklandı.
Kapsamlı bir yeniden yazım yerine kademeli değiştirme
GitHub projeyi uzun ömürlü bir dal veya yolun sonunda gerçekleştirilen tek seferlik bir dönüştürme süreciyle yürütmedi. Ana dal içinde, her TypeScript bileşeninin ayrı ayrı bir Rust bileşeniyle değiştirildiği bir yaklaşım seçti. Her çekme isteği, Rust'ı çağıran ince bir bağlama katmanı ekliyor ve aynı değişiklik içinde eski uygulamayı siliyordu; böylece dal gönderilebilir durumda kalıyor ve yeni kod doğrudan sistem içinde test ediliyordu.
- Projenin durdurulmasına gerek kalmadan diğer geliştiricilerin olağan çalışmaları sürdü.
- Her değişiklik, kapsamlı bir yeniden yazıma kıyasla daha küçük ve incelenmesi daha kolay hâle geldi.
- CLI ve SDK'ya özgü uçtan uca testler her adımda çalıştırıldı.
- Gerilemeler göçün sonuna ertelenmek yerine geçiş sırasında ortaya çıkarıldı ve düzeltildi.
GitHub ayrıca her bileşenin iki paralel sürümünü uzun süre korumayı da reddetti. Depo haftada yüzlerce çekme isteği alıyordu ve iki dildeki iki uygulama ile iki bağımlılık kümesini sürdürmek karmaşıklığı artıracaktı. Değiştirilebilir durum yöneten bileşenlerde, örneğin oturum biçimlendirmesinde, iki sürümü karşılaştırmak daha da zorlaşıyor; çünkü bu bileşenler geri çağrılarla ilgileniyor ve sistemin geniş bölümlerine bağlanıyordu.
Rakamlar neyi ortaya koyuyor?
İlk tahmin Mayıs 2026'da yaklaşık 130.000 TypeScript satırı olarak başladı, ancak gerçek işin hacmini yansıtmıyordu. TUI katmanı içinde sayılan bileşenler daha sonra runtime'a taşındı ve geçişle eş zamanlı olarak yeni TypeScript kodu gelmeye devam etti. Bu nedenle yaklaşık 430.000 TypeScript satırı fiilen taşıma sürecinden geçti.
Aynı dönemde projeye yaklaşık 300.000 üretim TypeScript satırı eklendi ve yaklaşık 430.000 satır kaldırıldı; buna karşılık yaklaşık 1.200.000 Rust satırı eklendi ve yaklaşık 365.000 satır kaldırıldı. Bu rakamlar, depoda görünen TypeScript hacminin sabit kalmasının ilerleme olmadığı anlamına gelmediğini; aksine ekleme, silme ve sorumlulukların yeniden dağıtılması şeklinde büyük bir hareketi gizlediğini gösteriyor.
Bu haber neden önemli?
Deneyimin pratik değeri yalnızca Rust kullanılmasında değil, çok sayıda ürünün paylaştığı temel bir katmanın yeniden yazılmasının nasıl yönetildiğinde yatıyor. Her bileşenin atomik olarak değiştirilmesi, dalın gönderilebilir durumda tutulması ve testlerin sürekli çalıştırılması, “büyük dönüşüm” risklerini azaltıyor ve geri almayı veya hatanın yerini belirlemeyi daha anlaşılır hâle getiriyor.
Buna karşılık yazı, bu yöntemin her kuruma uygun olduğunu veya yapay zekâ ajanlarının bu ölçekteki bir yeniden yazımın kalitesini tek başına garanti edebileceğini kanıtlamıyor. Ayrıca erişilebilen bölüm, öncesi ve sonrası için yayımlanmış tüketim ölçümleri sunmuyor; inceleme, testler veya gerilemelerin giderilmesi için gereken ayrıntılı insan maliyetini de açıklamıyor. Bu nedenle en belirgin ders, Rust'ı veya ajanları tüm geçiş süreçleri için genel bir çözüm olarak görmekten ziyade kademeli mühendislik ve katmanların ayrılmasıyla ilgili.