Claude Code ve Android KSA ile ajan tabanlı mühendislik

Merhaba, ben Ben, Android Geliştirici İlişkileri'ndenim.

Ben Steven, ürün müdürüyüm.

Bugün, Claude Code ve Android KSA ile ajan tabanlı uygulama geliştirmeyi ele alacağız.

Geliştiriciler olarak rolümüzün biraz değiştiğini ve her şeyin çok hızlı ilerlediğini söyleyebiliriz. Hatta dürüst olmak gerekirse bu konuşmadaki içerik muhtemelen şimdiden eskidi, özellikle de internetten izliyorsanız.

Bu nedenle, yazdıklarımız ve sunduğumuz bilgilerle ileriye dönük bir duruş sergiledik ancak bugün çalıştırdıkları demolar gerçeğe dayalı olduğundan artık güvenilir olmaları gerekir.

Bu konuşmada Claude Code'u kullandık ancak bilgiler, temsilciden bağımsızdır.

Bu daha çok bir zihniyet olduğundan, uygulamalarınızı oluştururken kullanmayı tercih ettiğiniz her şeye uygulanmalıdır.

Bu nedenle, otonom temsilci ekiplerini yönettiğiniz ve onları başarıya ulaştırdığınız bir dünya hakkında düşünmeye başlamanızı istiyoruz.

Bir özelliği veya benzer bir şeyi uygulayamadıklarında, pes edip "Yapay zeka bunu henüz yapamıyor" demek yerine geri adım atıp hangi bilginin eksik olduğunu düşünmemiz ve bunu günümüzdeki hatalara yaklaştığımız gibi ele almamız gerekiyor.

Tüm bu ajan düzeneği, Claude Code, Codex, Antigravity gibi araçları geliştiren ekiplerin yayınladığı makaleleri okuduysanız ekiplerin bu düzenekleri bu şekilde geliştirdiğini görürsünüz. Bu araçları geleceğe dair bir ipucu olarak kabul edersek muhtemelen hepimiz bu yöne doğru ilerliyoruz.

Yani, Android geliştiricisi olmak için muhtemelen en heyecan verici dönemdeyiz. Ancak benim gibiyseniz tam olarak neye odaklanmanız gerektiğini bilmekte zorlanabilirsiniz.

Geliştiriciler olarak, yeni bir model sınırları genişlettiğinde tüm çalışmalarımızın boşa gitmemesi için akıllıca ölçeklenebilen araçlara ve iş akışlarına ihtiyacımız var.

Modellerde yapılan her modellenmiş iyileştirmenin, temsilcilerimiz için daha akıllı iş akışları sağlamasını ve sonuç olarak kullanıcılarımıza daha iyi sonuçlar sunmasını istiyoruz.

Bugün dört konuyu ele alacağız.

Öncelikle, temsilcilerinizi başarılı olabilecekleri ortamlara yerleştirmenin neden bu kadar önemli olduğunu açıklayacağız.

Ardından, bağlam ve bağlamı en iyi şekilde yönetme hakkında genel bir bakış sunacağız.

Ardından, temsilcilerle çalışan Android geliştiricileri için sunduğumuz en iyi araçlardan bazılarına değineceğiz. Son olarak, temsilci tabanlı iş akışlarınıza döngü eklemenin neden önemli olduğunu açıklayacağız.

Haydi başlayalım.

Yani, ortam.

Peki bu tam olarak ne anlama geliyor?

Dediğim gibi, temsilcimizin başarılı olabileceği bir alan yaratmaya çalışıyoruz. Bu alanda, sizin sürekli başında durup yeniden istem girmenize ve onu doğru yola sokmanıza gerek kalmadan başarılı olabilmeli. Bunu yaptığınızda, paralel temsilciler çalıştırma imkanına kavuşursunuz. İşte o zaman, bu temsilci ekipleri sizin için çalışırken gerçek verimlilik artışını elde edersiniz.

Ancak bu, koda erişimden çok daha fazlasını ifade eder.

Proje spesifikasyonlarını ve o projede nasıl çalışılacağına dair kuralları içeren doğru belgelere erişmeleri gerekir.

Bu, en bariz olanı.

Kullanıcılar artık temsilcilerini yalnızca başlatmak için değil, aynı zamanda görevlendirildikleri özelliğe yol açan kararların nasıl alındığına dair bağlam sağlamak için ekip sohbet alanlarına bağlıyor. Geliştirici olarak sorunları çözerken bu tür bilinçaltı bilgileri kullandığınız için bu, temsilciniz için de yararlı olabilir.

Önceki karar geçmişi ve pull istekleri de buna dahildir.

Pull isteklerinizle ilgili aldığınız yorumları, ping aldıkları konuları ve benzeri şeyleri görebilmeleri gerekir. Sonrasında bu sorunları çözebildiklerini göreceksiniz.

Ayrıca, bir cihaza veya emülatöre erişiminiz olmadan Android kodu yazmanız mümkün değildir. Bu nedenle, temsilcinizin de bunu yapabilmesini beklememelisiniz.

Harika göründüklerini ve her şeyi yapabileceklerini biliyorum ancak emülatör gerçekten çok yardımcı oluyor.

Profil oluşturucular için de aynı durum geçerlidir.

Performans üzerinde çalışmalarını istiyorsanız profil oluşturabilmeleri gerekir. Bunun için de gerçek bir cihaza erişimleri olmalıdır.

Uygulamanızın kullandığı arka uç hizmetleriyle de iletişim kurabilmesi idealdir.

Android KSA işte bu noktada devreye girer.

Araçlardaki Yenilikler konuşmasında da bahsedilen Android KSA, çeşitli Android araçlarıyla arayüz oluşturmak için kullanabileceğiniz yeni KSA'mızdır.

Kendi başına bir yapay zeka ürünü değil, yalnızca bir komut satırı arayüzü (CLI).

Bu sayede Android SDK Manager gibi araçlara erişebilir, emülatörleri başlatabilir ve daha birçok işlem yapabilirsiniz.

Ayrıca Crashlytics gibi araçlara ve arka uçlara da bağlanır.

Kullandığınız tüm temsilcilerde çalışır ve kabuk alanınızda bulunur.

Evet.

Bu bağlantıdan yükleyebilirsiniz ancak bence uygulamalı olarak görmek daha kolay.

İşte böyle.

Temsilcilerinizi başarıya hazırlamanın neden bu kadar önemli olduğunu açıklamak yerine, bu ilkeyi Sideline adını verdiğimiz bir üretim uygulamasına uygulayacağız.

Sideline ise tenis oyuncularına topun, oyuncunun ve kortun konumu hakkında anında geri bildirim sağlayan bir Android uygulamasıdır.

Video tekrarı yoluyla çevrimdışı koçluk geri bildirimi sağlar ve en yüksek hız, kat edilen mesafe ve en uzun ralliler gibi fitness verileri sunar.

Tüm bunlar, doğrudan Android cihazda çalışan özel TF Lite modelleriyle desteklenir.

Öncelikle, varlığından haberdar olmadığımız sorunları çözemeyeceğimizi belirtmek isteriz.

Android KSA'yı kullanarak Firebase Crashlytics'i geliştirme ortamımıza ekledik. Bu sayede, varlığından bile haberdar olmadığımız bazı sorunları tespit edebildik.

İlk sorun, Pixel 11 Pro Fold cihazda meydana gelen ve emülatörde tekrarlanmayan bir "Uygulama Yanıt Vermiyor" (ANR) hatasıydı.

Neyse ki Android KSA, Android Cihaz Akışı'nı destekliyor.

Temsilci, bu sorunu düzeltmesini söylediğimizde ANR'nin gerçekleştiği cihazla bağlantı kurdu. Bu benim için özellikle yararlı oldu çünkü o sırada düzeltmeyi doğrulayabileceğim bir Pixel 11 Pro Fold'um yoktu.

Temsilciye, düzeltmeyi doğrulamak için ihtiyaç duyduğu cihaza erişme yetkisi vererek mümkün olanın kapsamını genişletebildik.

Zaman kazanmak için tüm denemeleri önceden çalıştırdım ve burada özetledim.

Çok fazla ayrıntıya girmeden, yaşadığımız sorunun Android 17 ile ilgili bir yakınlık çağrısı olduğunu söyleyebilirim.

İki satırlık hızlı bir düzeltmeydi ve bana iyi görünüyordu.

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

Ben de pull isteği oluşturup birleştirdim ve Play'e gönderilen yeni bir derlemeyle güncelledim.

Kodlama ortamını başarılı olması için gereken özelliklerle ayarlamasaydık gerçek bir sorunu tanımlayamaz ve bir düzeltmeyi doğrulayamazdık.

1.0 derlemelerinde sorunun çözüldüğünü görebilirsiniz.

Ancak yeni sorunlar ortaya çıktı ve bunlara daha sonra değineceğiz.

İşte böyle.

Sıradaki adım: bağlam.

Yaklaşık 1,5-2 yıl önce, yani çok uzun bir süre değil ama yapay zeka alanında bir ömür kadar uzun bir süre önce, daha büyük bağlam pencerelerine sahip olmak için bir yarış vardı. Teoriye göre, modele ne kadar çok şey atabilirsek o kadar iyi sonuçlar alırdık. Biz de çılgınca şeyler yapıyorduk. Örneğin, developer.android.com'un tamamını isteme dahil etmeye çalıştık ama pek işe yaramadı.

Ancak bağlam pencereleri büyük ölçüde sabit kalsa da model özellikleri hâlâ gelişiyor.

Android Bench 1.0'ın özellikleri bu şekilde.

Android Bench, yapay zekanın Android kodu yazma becerisini değerlendiren karşılaştırma aracımızdır.

Görevlerin gerçekçi olup olmadığı

Bunlar üzerinde çalıştığınız konular. Bağlam pencerelerinin 1 milyon sınırında sabitlendiğini görüyoruz ancak model kapasitesi artmaya devam ediyor.

Ancak bağlam, hâlâ sabit bir bütçedir ve bunu önemli şeyler için saklamak istersiniz.

Üzerinde çalıştığınız soruna yardımcı olmayan şeylerin orada olmasını istemezsiniz.

Ayrıca, ajan düzeneklerinin çoğu, anlamsız olduğunu düşündükleri için 1 milyonluk bağlam penceresinin tamamını size göstermez.

Bunu yaptıklarında sonuçlar daha da kötüleşir.

Aslında ideal bir nokta var ve bu nokta modele göre değişiyor. Ancak sohbetlerinizi yaklaşık 150.000 jetonla sınırlayabilirseniz bağlam bozulması olmadan modelin tüm gücünden yararlanabilirsiniz.

Ancak bağlam, yalnızca yazdıklarınızdan ibaret değildir.

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

Aslında arka planda görmediğiniz pek çok şey var.

Birkaç bölümden oluşur.

İlk olarak sistem talimatı var.

Sistem talimatı, temsilciniz tarafından sağlanır.

Bu, temsilciye nasıl çalışması ve nasıl davranması gerektiğini söyleyen bir istem gibidir.

Ayrıca çalışma alanı bilgileri, mevcut çalışma dizininiz, sahip olduğunuz SDK'lar, yüklü beceriler (buna birazdan değineceğiz) ve MCP araçları ile temsilciniz tarafından sağlanan tüm araçlar da buna dahildir.

Modelin bu araçları çağırabileceğini bilmesi gerekir. Bu nedenle, bağlam kullanılır.

Ancak en önemli fark, her istemde ve temsilcinize gönderdiğiniz her yeni mesajda tüm mesaj ve araç çağrısı geçmişinin gönderilmesidir.

Bu da özellikle Gradle'da büyük bir fark yaratabilir.

Hepimizin bildiği gibi Gradle günlükleri çok uzun, yani gerçekten çok uzun ve ayrıntılıdır.

Bunların çoğu gerekli değildir.

Bu konuda dikkat etmeniz gereken bir nokta var.

Gradle'ı sessiz modda çalıştırabilirsiniz.

./gradlew assembleDebug --quiet

Daha büyük ajan düzenekleri de bu işlemi sizin için yapabilir.

Bu nedenle, Claude Code ve Android Studio'da tam Gradle günlüğünü göndermiyoruz.

Ancak minimal temsilcilerden birini kullanıyorsanız felsefeleri her şeyi modele göndermek olduğu için (model en iyisini bilir) mini-SWE-agent, tüm Gradle günlüğünü gönderir ve bu da çok hızlı bir şekilde çok pahalı hale gelebilir.

Peki,bu 150.000'lik sihirli aralıkta nasıl kalabiliriz?

Bunun için bir iş akışı kullanmak gerekir.

Çok sayıda iş akışı vardır.

Matt Pocock adlı birinin hazırladığı bir kursu çok beğeniyorum. Bu kurs, bu tür oturumları yönetmenize yardımcı olacak bir dizi beceri öğretiyor.

Bu nedenle, "grill-me" adlı beceriyle başlar.

Bu beceriyi, bir projenin tamamına veya projedeki yeni bir özelliğe ilk başladığınızda çalıştırırsınız. Temsilciniz size bir dizi soru sorar.

"Beni sorguya çek" diyebilirsiniz.

Uygulamamda yeni bir zaman alarmı yöneticisi oluşturmak istiyorum."

Ardından, bu kodu nerede kullanmamız gerektiği ve nereye ait olduğu gibi sorular sormaya başlayacak.

Bu sayede, sorunun ve kafanızdaki tüm belirsizlikler ortadan kalkar ve bir sorun haline gelir.

Ardından, büyük bir spesifikasyon dokümanı yazan bir sonraki beceriyi çalıştırırız.

Başka bir beceri de bu bilgileri sorunlara ayırır ve tercih ettiğiniz sorun yöneticisine kaydeder.

Ardından,bu sayıların her birinin yaklaşık 150.000 aralığına sığması gerekir.

Ardından, terminalde veya IDE'nizde çalışırken bir sorun seçersiniz. Tercih ettiğiniz şekilde derleme ve doğrulama döngüsünü tamamladıktan sonra bağlamı temizleriz. Sohbet geçmişi kalmaz ve pencere sınırları içinde kalmış oluruz.

İşte böyle.

Şimdi de AGENTS.md hakkında konuşalım.

AGENTS.md, temsilcinize bu projede veya tüm çalışma alanınızda üzerinde çalıştığı sorunlar için geçerli olan ek bilgiler sağlayabileceğiniz yerdir.

Ancak her istemde kullanıldığı için yalnızca her zaman geçerli olan bilgileri eklemeniz önemlidir.

Bu nedenle, mimari ve modül kuralları gibi şeyler işe yarar.

Bunlar, özellikle kapalı kaynak bir uygulama üzerinde çalışıyorsanız temsilcinizin bilmesinin mümkün olmadığı türden bilgilerdir.

Ancak bu özelliğin nereye ait olduğuyla ilgili başlangıçta mantık yürütmek için bunları anlamak gerçekten önemlidir.

Örneğin, tasarım sistemi modülüne ait kullanıcı arayüzü bileşenleri gibi şeyleri ekleyebilirsiniz. Ayrıca, sık yapılan kod incelemesi hataları veya sürekli yazmak zorunda kaldığınız yaygın şeyler de çok işe yarar.

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

"Bu projede kotlinx.datetime kullanmayı tercih ediyoruz" gibi şeyler söyleyebilirsiniz.

Her zaman geçerli olan en iyi uygulamaları sunmak isterdim ancak gerçek şu ki her model sürümünde bu uygulamalar değişiyor.

Ek bağlam söz konusu olduğunda farklı modeller farklı davranışlar sergiler.

Örneğin, Opus 4.6 döneminde "Bunu asla yapmayın" gibi büyük harflerle yazılmış uyarılar çok yaygındı.

Opus 5 çıktığında Anthropic bir açıklama yaparak "Aslında büyük harfler artık o kadar iyi çalışmıyor.

Yalnızca küçük harf kullanın."

Demek istediğim şu: Bu konuyu yakından takip etmeniz gerekiyor.

Ancak bazı şeyler her zaman geçerlidir. Örneğin, kısa tutmak.

Bu nedenle, 250 satırdan kısa tutun.

Sıradaki konu biraz tartışmalı çünkü birçok kişinin bunu yapmayı sevdiğini biliyorum. Ancak bu yılın şubat ayında yayınlanan bir çalışma, temsilcinizin kendi AGENTS.md değerini değiştirmesine izin vermenin performansı yaklaşık %2 ila %3 oranında düşürdüğünü gösterdi. Bu çok büyük bir sorun değil.

Ancak önemli olan, maliyetleri %20 artırmasıydı.

Yani temsilcinin kendi AGENTS.md kodunu yazmasına izin verdiğimiz için performansta küçük bir düşüş yaşadık ve maliyetlerimiz fırladı.

Bunun için bir çözüm gördüm. Temsilcinizin her pull isteğinin sonunda bir retrospektif yazmasını sağlayabilirsiniz. Ardından, retrospektiflerinizde ekip olarak bunları birlikte okuyabilir ve hangi değişiklikleri yapacağınıza karar verebilirsiniz. Çünkü bu dosya, temsilcilerle büyük ekiplerde çalışıyorsanız kritik ekip altyapısının önemli bir parçası haline geliyor.

Kısaca, oluşturduğumuz Sideline uygulamasının AGENTS.md'sini burada görebilirsiniz.

Burada dikkat çekmek istediğim iki nokta var.

İlk olarak, net bir şekilde tanımlanmış bir mimariye sahip olmak, jetonlardan ve bağlam uzunluğundan tasarruf etmenizi sağlar.

Temel olarak, temsilcinizin kod tabanınızın daha fazlasını sürekli olarak incelemek ve daha fazla çıkarım yapmak zorunda kalmasını önler.

Sistemin takip edeceği çok net bir kılavuz sağlar.

Değinmek istediğim ikinci nokta ise özellikle kapalı kaynak uygulamalarla ilgili.

Kapalı kaynaklı bir kod tabanınız varsa temsilcilerin hiçbiri kod tabanınızda eğitilemez.

Bu nedenle, bu gibi durumlarda AGENTS.md'nizi sürekli olarak temizlemek, incelemek, hassaslaştırmak ve iyileştirmek için fazladan zaman harcamak özellikle önemlidir. Çünkü bu, uzun vadede size fayda sağlayacaktır.

Her şeyi AGENTS.md içine koymamamız gerekiyorsa temsilci veya model davranışını nasıl değiştireceğiz?

İlk olarak kancalardan bahsedelim. Kancalar, kullanıcıların AGENTS.md içine koyduğu şeyler için gerçekten çok kullanışlıdır. Örneğin, yazmayı bitirdiğinizde her zaman linter'ı çalıştırın.

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

Bu bir kanca olabilir.

Temsilciniz, abone olabileceğiniz tüm bu etkinlikleri gösteren bir kanca sunar. Aklınıza gelebilecek hemen her şey için bir kanca vardır ancak ana kancalar oturumu başlatma, oturumu durdurma, dosyaları okuma ve yazmadır.

Yani AGENTS.md dosyanızın altına "her zaman linter'ı çalıştır" veya "işinin bittiğini söylemeden önce her zaman test paketimi çalıştır" yazmak yerine, deterministik bir komut dosyası çalıştırabilen bir durdurma kancası kullanırsınız. Bu da yapay zekanın hafif rastgeleliğini kontrol altına almaya yardımcı olur.

Başka bir örnek: Temsilcinizin okumasını veya yazmasını istemediğiniz dosyalarınız varsa (ör. gizli dosyalarınız varsa) ve bunların bir sunucuya gönderilmesini istemiyorsanız ya da AGENTS.md, temsilcinizin bu dosyalara yazmasını istemiyorsanız bunun için bir kanca kullanabilirsiniz.

Okuma veya yazma kancanız varsa düzenlemeye çalıştığı dosya size iletilir ve "Hayır, bunu yapamazsınız." yanıtını verebilirsiniz.

Bu, determinizm eklemenin bir yoludur.

Bir sonraki beceriler.

AGENTS.md içeriğinizi kancaya dönüştürmek için kullanabileceğiniz beceriler de var.

Bu tamamen başka bir konu.

Ancak beceriler, yalnızca alakalı olduğunda bağlam eklemenin bir yoludur.

Yani AGENTS.md, her zaman geçerli olan şeyler için kullanılır.

Beceriler, belirli durumlarda (özellikle de dokümanlarla ilgili durumlarda) geçerli olan şeyler içindir.

Beceriler üç bölümden oluşur: Ad, açıklama (Bu önemli bir bölümdür ve 1.024 karakterle sınırlıdır.) ve gövde.

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

Gövde çok büyük olabilir, hatta başka komut dosyaları da içerebilir. Bu oldukça yaygın bir durumdur.

Becerilerle pek çok şey yapabilirsiniz.

Bir örneğe bakalım.

Bu, Android KSA açıklamasıdır.

Hepsini okumanıza gerek yok.

Android KSA'nın ne zaman alakalı olduğunu açıklayan kısa bir açıklama gibi olduğunu bilmeniz yeterlidir.

Bu da gövde metni.

Bu çok büyük bir veri kümesi. Bu nedenle, tüm bu verileri her zaman yüklemek istemeyiz, değil mi?

Bunu yalnızca Android KSA'yı kullanmaya çalıştığımızda yüklemek istiyoruz. Beceri de bunu yapmamızı sağlıyor.

Ancak yüklediğiniz beceriler konusunda seçici olmanız önemlidir.

İnternette gördüğümüz, yüzlerce temsilci mühendislik becerisi içeren depoları körü körüne yüklemek istemiyoruz.

Birincisi, bu çok büyük bir güvenlik riski.

Bu becerilerin içinde ne olduğunu bilmiyorsunuz. Temsilcinize her şeyi yapmasını söyleyebilir.

Android becerilerimiz var, bunları incelediğimizden emin olabilirsiniz.

İkincisi, 100 açıklama çarpı 1.000 karakter, kodlamaya başlamadan önce eklediğiniz 100.000 karakter demektir.

Yani bu pencereye zaten yaklaşıyorsunuz.

Bu nedenle, Android becerileri için her şeye Android KSA temel becerisini yüklemenizi öneririz. Android KSA, mevcut becerileri arayabilir ve uygulamanız için mantıklı olanları yükleyebilir.

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

İncelediğinizde hangi becerilerin mevcut olduğunu bilmek güzel. Projeniz için anlamlı olanları manuel olarak ekleyebilirsiniz. Örneğin, Compose becerileri, uçtan uca beceriler oldukça evrenseldir.

Elbette becerileri denetlemek için de beceriler vardır.

Claude Code'da /skill-doctor var. Bu araç, hiç etkinleştirilmeyen becerileri size bildirir. Böylece, bin karakterlik açıklama alanını boşa harcamamış olursunuz.

Claude Code kullanmıyorsanız hemen hemen her ajan düzeneğinde aynı işlemi yapabileceğiniz bir istatistik veya denetim ekranı bulunur.

Android KSA bağlantısını tekrar hatırlatmak isterim.

Ancak bir beceri listesi komutu var ve projenizde Navigation 3 olduğunu varsayalım.

android skills list
android skills add navigation-3

Navigation 3 oldukça yeni bir kitaplık olduğundan henüz çok fazla eğitim almadı. Navigation 3 becerisini ekleyebilirsiniz.

Sık sık, pardon.

Sırada MCP var.

Ancak sık sık Android KSA'yı neden MCP sunucusu değil de KSA olarak tasarladığımız soruluyor.

CLI'ları yapay zekadan, hatta fareden bile çok önce geliştirmeye başladık. Bu nedenle hızlı ve birleştirilebilirler. Ayrıca kabuk oturumunuzda yerel olarak çalıştıkları için ücretsiz olarak kullanılabilirler.

Ayrıca Terminal Bench gibi karşılaştırmalar, yazılım mühendisliği söz konusu olduğunda en büyük karşılaştırmalar haline geldi. Bu nedenle model üreticileri, terminal kullanımına karşı agresif bir şekilde tırmanıyor. Bu yüzden günümüzde CLI'ları kullanma konusunda gerçekten iyiler.

Ancak bu, MCP'nin hiçbir yeri olmadığı anlamına gelmez.

MCP sunucuları, halihazırda kullandığınız harici hizmetler için, özellikle de zaten bir MCP hizmeti barındırıyorlarsa çok kullanışlıdır.

Doğrudan bağlanabilirsiniz. Bu, temsilcinize ek bağlam sağlamanın yükleme gerektirmeyen bir yoludur.

GitHub, Figma ve Slack gibi platformlar artık MCP sunucularını kullanıyor.

Kabukta çalıştırdığımız şeyler kabukta kalabilir. Android KSA üzerinden Android komutları, Perfetto ve Gradle'ın yerel olarak çalıştırılması mantıklı olur. Böylece geliştirme sürecinde kullandığınız her şeye erişebilirler.

Performans üzerinde çalışıyordum.

Her zaman Perfetto'nun tüm performans sorunlarını çözmek için ihtiyacınız olan tek araç olduğunu söylerdim.

Ancak Rahul'un son konuşmasında da gördüğümüz gibi, öğrenme süreci çok zordu.

Yapay zekanın performansı artırmaya nasıl yardımcı olabileceğine bakalım.

Teşekkürler Berk.

Sideline uygulamamızın çalışması için saniyedeki kare sayısı (FPS) 30 hızında ve gerçek zamanlı olarak çalışması gerekiyor.

Bu Pixel 10 Pro Fold'da görebileceğiniz gibi, saniyedeki kare sayısı (FPS) yalnızca yaklaşık 20 ila 22.

Bu atlanan kareler sorun yaratacaktır çünkü uygulamanın tanıtıldığı gibi çalışmayacağı anlamına gelir. Bu nedenle bunu düzeltmemiz gerekir.

Android KSA'da Android Profiler komutları bulunur.

Bunu kodlama temsilcimize ekleyip saniyedeki kare sayısı (FPS) şartını karşılamasını istediğimizde iki ilginç şey oluyor.

İlk olarak, Android Profiler komutunu kullanarak bir düzeltme bulur.

Bağlı Pixel 10 Pro Fold cihazda sistem izlerini kaydetti ve yapay zeka iş parçacıklarının cihazdaki en yavaş çekirdeklerde çalıştığını tespit etti.

İkincisi ise ilginç bir şekilde, biz açıkça istemeden Android belgelerinde arama yaparak Performance Hint API ile ilgili resmi kılavuzu buldu.

Temsilci, sistem programını optimize etmeyi öğrendi ve bu sayede saniyedeki kare sayısı (FPS) gereksinimini karşılayabildi.

Yani aslında düzeltme, kılavuzdaki talimatlara uygun şekilde yapıldı.

Android KSA'da önemli olan, temsilcinizle bağlantı kurarak, aşina olmadığınız bir araç olsa bile, yapmanız gereken her türlü iş için doğru aracı bulmanıza yardımcı olmasıdır.

Çalıştırdığımızda, Sideline'ın kullanıcıların saniyedeki kare sayısı (FPS) şartını karşıladığını ve artık Pixel 10 Pro Fold'da çalıştığını görebilirsiniz.

İşte böyle.

Şimdi tüm bunları döngülerle bir araya getireceğiz.

Hepimiz bunu yapmışızdır. Temsilcinizden büyük bir değişiklik yapmasını istersiniz ve o da geri dönüp değişikliğin yapıldığını söyler.

Uygulamayı yükleyip manuel olarak tıklayarak hataları yazıyorsanız bu yöntemi bırakmanız gerekir.

Temsilcimizin kalite güvencesi test uzmanı olmayı bırakmalı ve tamamlanmış olarak kabul ettiğimiz şeyleri önceden tanımlamalıyız.

Örneğin,

Tüm projeyi Nav3'e taşımak istiyoruz. Temsilci bir süre çalıştıktan sonra geri dönüp "Taşıma işlemi tamamlandı.

En iyisi benim."

Ancak telefonu döndürdüğünüzde uygulama kilitleniyor, tüm slayt geçişlerini kaçırıyor ve Gradle dosyasını temizlemiyor.

Bu, şu anda içinde bulunduğumuz dünyaya benziyor.

İdeal olan, bunu yapmak zorunda kalmamamızdır ancak şu anki gerçeklik budur.

Bu nedenle, beklentilerimizi önceden tanımlamamız gerekirdi. Böylece temsilci, tüm bu kriterleri karşılayana kadar döngüye girebilirdi.

Doğrulama döngüsü budur.

Bu yöntemin etkililiğine dair elimizde çok güçlü veriler var.

Bu, Android Bench 2.0. Konuşmanın başında bahsettiğim yapay zeka karşılaştırma aracımızın yeni sürümü.

Geçme oranları şu anda yaklaşık %40'tır.

Bu görevler gerçekten zor, büyük ve gerçekçi. Ancak bunlardan biri Nav2'den Nav3'e geçiş. Bunlar şu anda projelerinizde yaptığınız türden şeyler.

Fable 5.1'i ele alırsak, geçme oranı %22. Bu, "Nav2'yi Nav3'e taşı" gibi doğal istem kurulumuyla elde ettiği sonuç.

Ancak önceden başarısız bir test paketi verirsek (bu, yanıtları vermek anlamına gelmez, Nav3'e nasıl geçiş yapılacağını söylemiyoruz, yalnızca zaten başarısız olan ve tüm bu işlemler tamamlandığında başarılı olacak bir test paketi veriyoruz) tüm karşılaştırmadaki başarı oranları %90'a çıkıyor.

Bu da bize, bu modellerin artık aklımıza gelebilecek hemen her Android görevini yerine getirebildiğini, ancak her zaman "tamamlandı" ifadesinin ne anlama geldiğini bilmediğini gösteriyor.

Bu nedenle, önceden başarısız olan tam bir test paketi yazmanız gerekmez.

Doğrulama döngüleri, istem ekleme kadar basit olabilir.

Örneğin, kullanıcı arayüzü üzerinde çalışırken Oluşturma önizlemesini oluşturmasını, Figma spesifikasyonuyla eşleştiğinden emin olmasını ve sonuçları göstermesini isteyebilirsiniz.

"Tamamladım" şeklinde bir metin yanıtını kabul etmek yerine, sonuçları göstermesini ve işlemin tamamlandığını kanıtlamasını istediğinizde gerçekten işe yaradığı görülüyor.

İş mantığı üzerinde çalışıyorsanız birim testlerinizi çalıştırmasını isteyebilirsiniz. Başlangıçta gördüğümüz gibi, kilitlenme düzeltmesi üzerinde çalışıyorsanız kilitlenmenin, gerçekleştiği gerçek cihazda düzeltildiğini uzaktan test laboratuvarı aracılığıyla doğrulamasını söyleyebilirsiniz.

Claude Code'da doğrulama döngüleri oluşturmanıza yardımcı olacak bir beceri de var.

Bu nedenle, bu sayfaya mutlaka göz atın.

Android Studio'da kendi temsilcinizi getirerek çalışıyorsanız Android Studio, üzerinde çalıştığınız konuya bağlı olarak döngüler oluşturabileceğiniz bir dizi araç sunar.

Linter gibi, tüm lint hataları düzeltilene kadar durmamasını söyleyebilirsiniz. Benim en sevdiğim özellik ise yolculuklar. Yolculuklarınızı çalıştırmasını ve hâlâ işlevsel olduklarından emin olmasını isteyebilirsiniz.

Ya da bir yolculuk yazdıysanız (yolculuk yazmak oldukça kolaydır, üzerinde çalıştığınız özellikle ilgili istemlerden ibarettir) bu yolculuğu çalıştırmasını ve tamamlandığını bildirmeden önce başarılı olmasını sağlayabilirsiniz.

Ancak yolculukların çalışması biraz zaman alır.

Doğrulama döngünüzün seviyelerini de kademelendirebilirsiniz.

Bu nedenle, öncelikle birim testlerinin ve Oluşturma önizlemelerinin doğru şekilde oluşturulduğundan emin olmasını isteyebiliriz.

Bu test başarılı olduğunda lütfen bağlı testlerimizi ve Android Journeys'i çalıştırın. Yalnızca bu test başarılı olduğunda, uzak cihaz test laboratuvarı gibi tam test paketini çalıştırın. Bu işlem saatler sürebilir.

Bu ek bilgileri verdiğinizde, her çalıştırmada her adımı yapmak yerine her katman için döngü oluşturduğunu görürüz.

Çünkü modeller kendilerine çok güveniyor.

Bu nedenle, her zaman eksiksiz olduklarını ve tüm testleri ilk seferde geçeceklerini düşünürler.

Şimdi Sideline'da buna bir göz atalım.

Bu fikri Sideline uygulamamıza uygulayalım. Bunu, yakında çıkacak XR gözlükleri için yeni bir özellik ekleyerek yapalım.

Henüz donanımımız olmadığı için elbette XR emülatörünü kullanacağız ve kodlama temsilcimize Sideline'ı yeni form faktörü için genişletme talimatı vereceğiz.

Bunu yaparken temsilcilerimizden özellikle JVM testleri, Oluşturma Önizleme testleri ve emülatör testleri arasında sırayla geçiş yapmalarını isteyeceğiz.

Her döngüye, bir önceki döngünün üzerine inşa edilmesi söylenir.

Bunu yaptığımızda ilk fark ettiğimiz şey, birinci ve ikinci döngü arasında altı Oluşturma Önizleme durumunu tanımlamak için JVM testlerinin kullanılmasıdır.

Tabii ki emülatör çağrılmadığı için bu işlem çok hızlı çalışır.

Benzer şekilde, ikinci ve üçüncü döngü arasında, uzun dizeler gibi sorunlar emülatörün çalıştırılmasına gerek kalmadan ortaya çıkarılır ve düzeltilir.

Son olarak, emülatör döngüsü çalıştırıldığında JVM testinin ve Compose önizlemelerinin düzeltemediği diğer hatalar bulunur.

Ancak temel olarak, her döngüde uygulamamızı daha da güçlendiriyoruz ve önce en hızlı ancak en az güçlü döngüleri, ardından en yavaş ancak en güçlü döngüleri çalıştırmak istiyoruz.

Sonuç da bu.

Gözlükler artık vuruş türünü ve topun raketten çıkış hızını gösteriyor. Böylece tenis oynarken gözünüzü toptan ayırmadan oyununuzla ilgili anlık geri bildirim alabilirsiniz.

Daha önce, daha önce ortaya çıkan iki Crashlytics sorununa geri döneceğimizi söylemiştim.

Bu yaklaşımın işe yaradığını doğrulayabildiğimiz için Claude Code'da /schedule komutunu kullanarak bu yaklaşımı döngüye alabilir ve istediğimiz sıklığı ayarlayabiliriz. Böylece tüm hataları düzelten ve düzeltildiklerini doğrulayan, bunları mühendislerimizin inceleyip birleştirmesi için pull isteği olarak gönderen, kendi kendini onaran bir uygulamamız olur.

Mükemmel.

Bugünlük bu kadar.

Bu sunumdan çıkaracağınız en önemli ders, temsilcilerimizin başarılı olabileceği bir ortam oluşturduğumuz bu dünya hakkında düşünmeye başlamak ve bu süreci günümüzdeki yazılım geliştirme ve hata düzeltme süreçlerine benzer şekilde ele almak olmalıdır.

Paralel temsilcileri bu şekilde etkinleştiririz.

İnternette bu konuyla ilgili birçok tavsiye bulabilirsiniz ve bunların çoğu birbiriyle çelişir.

Bu, hızla değişen bu ortamın bir gerçeğidir.

Bu nedenle, yapabileceğiniz en iyi şey projeniz için kendi değerlendirmelerinizi yazmaktır.

Yeni bir tavsiye veya yeni bir model çıktığında bunu ölçebilir ve size yardımcı olup olmadığını görebilirsiniz.

Tabii ki her şey için bir beceri var.

Claude Code'da değerlendirme oluşturmanıza yardımcı olacak bir beceri var.

/claude-api build-eval

Bu videoyu mutlaka izlemenizi öneririz.

Bugün Android Bench'ten bahsettim.

Android Bench, değerlendirme aracımızdır.

İşlerin daha iyiye gittiğinden emin olmak için bu şekilde ölçüm yaparız.

Bu aracı geliştirirken öğrendiğimiz dersleri dinleyerek aynı hataları yapmaktan kaçınmak istiyorsanız Android Bench konuşmasını izleyin.

İki panel de vardır.

Biri ABD'de, diğeri Londra'da.

Her ikisi de toplulukta bu tür bir kavramın pratikte nasıl uygulandığını anlatan videolar.

Android geliştirici topluluğu üyeleri, bu yaklaşımı işlerinde nasıl uyguladıklarını anlatmak için panelimize katılacak.

Geri bildirimlerinizi de bekliyoruz.

Size gerçekten yardımcı olan özellikler geliştirip geliştirmediğimizi öğrenmek istiyoruz.

Bu nedenle, lütfen anketi doldurun.

Bunu ekranda bırakacağım.

Evet.

Dinlediğiniz için teşekkürler.

Teşekkür ederiz.