Rekayasa agentic dengan Claude Code dan Android CLI

Halo, saya Ben, Android Developer Relations.

Saya Steven, product manager.

Hari ini, kita akan membahas cara membuat aplikasi dengan Claude Code dan Android CLI, secara agentik.

Jadi, menurut saya, peran kita sebagai developer sedikit berubah, dan semuanya bergerak sangat cepat, bahkan, jujur saja, konten dalam presentasi ini mungkin sudah usang, terutama jika Anda menontonnya secara online.

Jadi, kami mengambil sikap proaktif dengan apa yang kami tulis, dengan info yang kami sajikan, tetapi demo yang mereka jalankan saat ini didasarkan pada kenyataan, sehingga seharusnya dapat diandalkan sekarang.

Hal lainnya adalah kami telah menggunakan Claude Code untuk diskusi ini, tetapi informasinya tidak bergantung pada agen.

Ini lebih merupakan pola pikir, sehingga harus berlaku untuk apa pun yang Anda pilih saat membangun aplikasi.

Jadi, kami ingin Anda mulai memikirkan dunia tempat Anda mengelola tim agen otonom dan cara Anda mempersiapkan mereka untuk meraih kesuksesan.

Saat mereka gagal menerapkan fitur atau hal semacam itu, alih-alih menyerah dan berkata, "Oh, AI belum bisa melakukan ini", kita perlu mundur dan memikirkan informasi apa yang hilang, dan memperlakukannya seperti kita memperlakukan bug saat ini.

Dan jika Anda telah membaca apa pun yang berasal dari tim yang membuat semua infrastruktur pengelola agen ini, Claude Code, Codex, Antigravity, Anda akan melihat bahwa inilah cara tim mereka benar-benar mengembangkan infrastruktur pengelola agen tersebut, dan jika kita menganggapnya sebagai gambaran masa depan, mungkin ke sanalah kita semua menuju.

Jadi, mungkin ini adalah saat yang paling menarik untuk menjadi kreator, menjadi developer Android, tetapi jika Anda seperti saya, Anda mungkin merasa sulit untuk mengetahui dengan pasti apa yang harus menjadi fokus.

Dan kita, sebagai developer, membutuhkan alat dan alur kerja yang benar-benar dapat diskalakan dengan kecerdasan, sehingga saat model baru memperluas batasan, semua kerja keras kita tidak menjadi sia-sia.

Kami ingin setiap peningkatan model menghasilkan alur kerja yang lebih cerdas bagi agen kami, yang pada akhirnya menghasilkan hasil yang lebih baik bagi pengguna kami.

Hari ini, kita akan membahas empat topik.

Pertama, kami akan menjelaskan mengapa sangat penting untuk menyiapkan agen Anda di lingkungan agar mereka berhasil.

Kemudian, kami akan memberikan ringkasan tentang konteks dan cara terbaik untuk mengelolanya.

Setelah itu, kita akan membahas beberapa alat terbaik yang tersedia untuk developer Android yang bekerja di dalam agen, dan terakhir, kita akan membahas alasan menambahkan loop ke Agentic Workflows Anda.

Baiklah, mari kita mulai.

Jadi, lingkungan.

Tapi, apa artinya?

Seperti yang saya katakan, kami mencoba menciptakan ruang tempat agen kami dapat berhasil, dan dapat berhasil tanpa Anda harus duduk di sana dan terus-menerus, seperti, memberikan perintah ulang dan mengarahkannya kembali ke jalur yang benar, karena saat Anda melakukannya, saat itulah Anda dapat menjalankan agen paralel, dan di situlah, seperti, peningkatan produktivitas yang sebenarnya terjadi, saat Anda dapat memiliki tim agen ini yang semuanya melakukan pekerjaan untuk Anda.

Namun, hal itu jauh lebih dari sekadar memiliki akses ke kode.

Mereka memerlukan akses ke dokumentasi yang akurat, yang mencakup spesifikasi project dan aturan cara bekerja dalam project tersebut.

Itu adalah salah satu yang jelas.

Beberapa hal lain yang dilakukan orang-orang adalah menghubungkan agen mereka ke ruang chat tim, bukan hanya untuk memulai agen, tetapi untuk benar-benar memberikan konteks tentang bagaimana keputusan dibuat yang mengarah pada fitur yang ditugaskan kepada mereka, karena Anda sebagai developer, itulah jenis informasi bawah sadar yang Anda gunakan saat memecahkan masalah, dan hal itu juga dapat membantu agen Anda.

Juga seperti histori keputusan dan permintaan pull sebelumnya.

Mereka harus dapat melihat komentar yang Anda dapatkan pada permintaan pull, hal-hal yang membuat mereka mendapatkan ping, dan hal-hal semacam itu, lalu Anda akan melihat bahwa mereka dapat bekerja dan memperbaikinya.

Selain itu, Anda tidak akan berharap dapat menulis kode Android tanpa akses ke perangkat atau emulator, jadi Anda juga tidak boleh berharap agen Anda dapat melakukannya.

Saya tahu perangkat ini tampak luar biasa dan dapat melakukan apa saja, tetapi emulator sangat membantu.

Sama halnya dengan profiler.

Jika Anda ingin mereka meningkatkan performa, mereka harus dapat membuat profil, yang melibatkan akses ke perangkat sungguhan.

Dan layanan backend apa pun yang digunakan aplikasi Anda, idealnya agen Anda juga dapat berkomunikasi dengan layanan tersebut.

Di sinilah Android CLI berperan.

Jika Anda belum pernah mendengarnya, Android CLI juga dibahas dalam presentasi Yang Baru di Alat, tetapi Android CLI adalah CLI baru kami untuk berinteraksi, hanya dengan berbagai alat Android.

Ini bukan produk AI, melainkan hanya CLI, antarmuka command line.

Jadi, Android Studio memberi Anda akses ke berbagai hal seperti Android SDK Manager, kemampuan untuk memulai emulator, dan banyak hal lainnya.

Gemini juga terhubung ke alat dan backend seperti Crashlytics.

Fitur ini berfungsi di agen apa pun yang Anda gunakan, dan hanya berada di ruang shell Anda.

Jadi, ya.

Anda dapat menginstalnya di link ini, tetapi menurut kami akan lebih mudah jika kita langsung melihat cara kerjanya.

Oke.

Jadi, daripada sekadar menjelaskan mengapa sangat penting untuk menyiapkan agen Anda agar berhasil, kami ingin benar-benar menerapkan prinsip ini ke aplikasi produksi yang kami buat, yang disebut Sideline.

Sideline adalah aplikasi Android untuk pemain tenis yang memberi mereka masukan real-time tentang lokasi bola, lokasi pemain, dan lokasi lapangan.

Aplikasi ini memberikan masukan pelatihan offline melalui pemutaran ulang video, dan menyediakan data kebugaran untuk hal-hal seperti kecepatan tercepat, jarak yang ditempuh, dan reli terpanjang.

Semuanya didukung melalui model TF Lite kustom yang berjalan langsung di perangkat Android.

Pertama-tama, kami ingin menyampaikan bahwa kami tentu tidak dapat menyelesaikan masalah yang tidak kami ketahui keberadaannya.

Jadi, dengan menggunakan Android CLI, kami menambahkan Firebase Crashlytics ke lingkungan pengembangan, yang memungkinkan kami menemukan beberapa masalah yang bahkan tidak kami ketahui sedang terjadi.

Pertama, ada error aplikasi tidak merespons, atau ANR, yang terjadi di perangkat Pixel 11 Pro Fold, yang tidak direproduksi di emulator.

Untungnya, Android CLI memiliki dukungan untuk Streaming Perangkat Android.

Setelah kami memintanya untuk memperbaiki masalah ini, agen tersebut membuat koneksi ke perangkat tempat ANR terjadi. Hal ini sangat berguna bagi saya karena saat itu, saya bahkan tidak memiliki Pixel 11 Pro Fold untuk memvalidasi perbaikan tersebut.

Jadi, dengan memberi agen kemampuan untuk mengakses perangkat yang diperlukan untuk memvalidasi perbaikan, kami pada akhirnya dapat memperluas kemampuan yang mungkin dilakukan.

Untuk menghemat waktu, saya menjalankan semua eksperimen terlebih dahulu dan merangkumnya di sini.

Tanpa membahas terlalu banyak detail, masalah yang kami alami adalah panggilan afinitas yang berkaitan dengan Android 17.

Perbaikannya cepat, hanya dua baris, dan terlihat bagus bagi saya.

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

Jadi, saya membuat permintaan pull, menggabungkannya, dan mengupdate dengan build baru yang dikirimkan ke Play.

Jadi, jika kita tidak menyiapkan lingkungan coding dengan kemampuan yang diperlukan agar berhasil, kita tidak akan dapat mengidentifikasi masalah yang sebenarnya, dan kita juga tidak akan dapat memvalidasi perbaikan.

Jadi, dengan build 1.0, Anda dapat melihat bahwa masalah telah diselesaikan.

Namun, masalah baru telah muncul dan kita akan membahasnya nanti.

Oke.

Berikutnya: konteks.

Jadi, sekitar 1, 5 atau 2 tahun yang lalu, yang sebenarnya belum terlalu lama, tetapi dalam dunia AI, itu sudah terasa seperti seumur hidup, ada perlombaan untuk memiliki jendela konteks yang makin besar, dan teorinya adalah, makin banyak yang bisa kita berikan ke model, makin baik hasil yang akan kita dapatkan, dan kami melakukan hal-hal gila seperti mencoba menyertakan seluruh developer.android.com dalam perintah, yang sebenarnya tidak berhasil.

Namun, meskipun jendela konteks sebagian besar telah stabil, kemampuan model masih terus meningkat.

Jadi, inilah Android Bench 1.0.

Android Bench adalah benchmark kami yang mengukur kemampuan AI dalam menulis kode Android.

Tugas di dalamnya realistis.

Hal-hal seperti itulah yang Anda kerjakan, dan kita dapat melihat jendela konteks mendatar di angka 1 juta, tetapi kemampuan model terus meningkat.

Namun, konteksnya tetaplah anggaran tetap, dan Anda ingin menyimpannya untuk hal yang penting.

Anda tidak ingin ada hal-hal yang tidak membantu menyelesaikan masalah yang sedang Anda kerjakan.

Dan banyak infrastruktur pengelola agen yang sebenarnya tidak mengekspos jendela konteks 1 juta penuh itu kepada Anda karena mereka merasa, seperti, itu tidak ada gunanya.

Hasilnya akan menjadi lebih buruk jika mereka melakukannya.

Sebenarnya ada titik ideal, dan ini berubah tergantung pada modelnya, tetapi jika Anda dapat menjaga percakapan Anda sekitar 150.000 token, di situlah Anda mendapatkan kekuatan penuh model tanpa pembusukan konteks.

Namun, konteks bukan hanya apa yang Anda ketik.

[
  {
    "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 }"
  }
]

Sebenarnya ada banyak hal di balik layar yang tidak Anda lihat.

Sistem ini terdiri dari sejumlah bagian.

Pertama adalah petunjuk sistem.

Petunjuk sistem disediakan oleh agen Anda.

Ini seperti perintah yang memberi tahu cara bekerja dengan agen ini, jenis perilaku yang harus dilakukan.

Namun, juga informasi ruang kerja, dan seperti, seperti direktori kerja Anda saat ini, SDK yang Anda miliki, keterampilan yang diinstal, kita akan membahasnya sebentar lagi, dan alat MCP, alat apa pun yang disediakan oleh agen Anda juga.

Model perlu mengetahui bahwa model dapat memanggilnya, sehingga hal ini memerlukan konteks.

Namun, yang paling penting adalah histori pesan dan histori panggilan alat lengkap dikirim dengan setiap perintah, setiap pesan baru yang Anda kirim, dengan agen Anda.

Dan hal itu, dapat benar-benar bertambah, terutama dengan Gradle.

Seperti yang kita ketahui, log Gradle sangat panjang, sangat panjang, dan sangat panjang.

Sebagian besar informasi tersebut tidak diperlukan.

Jadi, berikut tips singkat untuk mengatasinya.

Anda dapat menjalankan Gradle dalam mode senyap.

./gradlew assembleDebug --quiet

Atau, infrastruktur pengelola agen yang lebih besar akan memotongnya untuk Anda.

Jadi, Claude Code dan Android Studio, kami tidak mengirimkan log Gradle lengkap.

Namun, jika Anda menggunakan salah satu agen minimal, karena filosofi mereka adalah mengirimkan semuanya ke model, model tahu yang terbaik, jadi mini-SWE-agent, mengirimkan log Gradle lengkap, dan itu bisa menjadi sangat mahal dengan sangat cepat.

Namun,bagaimana cara agar kita tetap berada dalam jendela ajaib 150.000 ini?

Kuncinya adalah menggunakan alur kerja.

Ada banyak alur kerja di luar sana.

Salah satu yang sangat saya sukai adalah dari seseorang bernama Matt Pocock, dan dia memiliki serangkaian keterampilan untuk membantu Anda mengelola sesi ini.

Jadi, dimulai dengan skill yang disebut "grill-me".

Yang Anda lakukan adalah menjalankan keterampilan ini saat pertama kali memulai seluruh project atau hanya fitur baru di dalam project, dan keterampilan ini akan membuat agen Anda mengajukan banyak pertanyaan kepada Anda.

Jadi, Anda mungkin hanya mengatakan, "uji saya.

Saya ingin membuat, entahlah, pengelola alarm waktu baru di aplikasi saya."

Kemudian, Gemini akan mulai mengajukan pertanyaan balik kepada Anda, seperti bahasa pemrograman apa yang harus digunakan, di mana kode tersebut harus ditempatkan.

Dan hal ini menghilangkan semua ambiguitas dari masalah dan dari pikiran Anda ke dalam sebuah masalah.

Kemudian, kita menjalankan keterampilan berikutnya, yaitu menulis dokumen spesifikasi yang besar.

Ada keterampilan lain yang kemudian membaginya menjadi masalah, dan kami mengajukannya di pengelola masalah apa pun yang Anda pilih untuk digunakan.

Kemudian,idenya adalah setiap masalah tersebut harus sesuai dengan jendela 150.000 token.

Lalu, dari sana, Anda memilih satu masalah, baik Anda bekerja di terminal atau IDE, apa pun yang Anda inginkan, build, verifikasi loop, kita menghapus konteks di akhir, tidak ada lagi histori percakapan, dan kita tetap berada dalam jendela.

Oke.

Selanjutnya, mari kita bahas AGENTS.md.

AGENTS.md adalah tempat Anda dapat memberikan informasi tambahan untuk agen yang berlaku untuk masalah apa pun yang sedang dikerjakan dalam project ini atau di seluruh ruang kerja, jika itu yang Anda pilih.

Namun, karena diberikan ke setiap perintah, sebaiknya batasi hanya untuk hal-hal yang idealnya berlaku setiap saat.

Jadi, hal-hal yang berfungsi adalah aturan arsitektur dan modul.

Hal-hal tersebut adalah hal yang mungkin tidak diketahui oleh agen Anda, terutama jika Anda mengerjakan aplikasi closed source.

Namun, sangat penting untuk dipahami agar dapat menghemat penalaran di awal tentang di mana fitur ini berada.

Jadi, Anda dapat menempatkan hal-hal seperti komponen UI dalam modul sistem desain, atau hal lain yang sangat cocok adalah kesalahan umum dalam peninjauan kode, atau hal-hal umum yang Anda temukan dan harus Anda ketik terus-menerus.

# 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.

Jadi, dalam project ini, kami lebih suka menggunakan kotlinx.datetime, dan hal-hal semacam itu.

Saya sangat ingin memberikan semacam praktik terbaik yang selalu berlaku, tetapi kenyataannya hal ini berubah seiring dengan setiap rilis model.

Setiap model memiliki perilaku yang berbeda dalam hal konteks tambahan.

Jadi, sebagai contoh, pada masa Opus 4.6, sangat umum untuk memiliki huruf kapital besar yang bertuliskan, "Jangan pernah lakukan ini".

Lalu, saat Opus 5 dirilis, Anthropic merilis pernyataan yang mengatakan, "Sebenarnya, huruf kapital tidak lagi berfungsi dengan baik.

Gunakan huruf kecil saja."

Jadi, inilah yang kami maksud: Anda harus terus memantaunya.

Namun, beberapa hal yang tetap cukup universal adalah membuatnya tetap singkat.

Jadi, usahakan tidak lebih dari sekitar 250 baris.

Dan yang satu ini, yang berikutnya ini agak mempolarisasi, karena saya tahu banyak orang suka melakukan ini, tetapi sebuah studi yang dirilis pada Februari tahun ini menunjukkan bahwa jika Anda membiarkan agen Anda mengubah AGENTS.md-nya sendiri, performanya akan menurun sekitar 2 hingga 3%, yang, Anda tahu, tidak terlalu menjadi masalah.

Namun, bagian pentingnya adalah biaya meningkat sebesar 20%.

Jadi, kita kehilangan sedikit performa, dan biaya kita membengkak, semuanya karena membiarkan agen menulis AGENTS.md-nya sendiri.

Cara mengatasinya yang pernah saya lihat, Anda dapat meminta agen menulis retrospektif di akhir setiap permintaan pull, lalu Anda sebagai tim dalam retrospektif dapat membaca semuanya bersama-sama dan memutuskan modifikasi apa yang akan Anda buat, karena file ini menjadi bagian penting dari infrastruktur tim yang penting jika Anda bekerja dalam tim besar dengan agen.

Jadi, singkatnya, berikut adalah AGENTS.md untuk aplikasi Sideline yang kami buat.

Ada dua hal yang ingin saya sampaikan di sini.

Pertama, memiliki arsitektur yang ditentukan dengan jelas akan menghemat token dan jendela konteks.

Pada dasarnya, hal ini memungkinkan agen Anda untuk tidak perlu terus-menerus memeriksa lebih banyak codebase dan membuat lebih banyak inferensi.

Hal ini memberikan panduan yang sangat jelas untuk diikuti.

Hal kedua yang ingin saya sampaikan adalah khususnya untuk aplikasi closed source.

Tentu saja, jika Anda menggunakan closed source, tidak ada agen yang dapat melatih LLM di codebase Anda.

Jadi, dalam kasus ini, sangat penting untuk meluangkan waktu ekstra, menghabiskan siklus tersebut untuk terus membersihkan, meninjau, menyaring, dan meningkatkan kualitas AGENTS.md Anda, karena hal ini akan menguntungkan Anda dalam jangka panjang.

Jadi, jika kita tidak boleh memasukkan semuanya ke dalam AGENTS.md, bagaimana cara mengubah perilaku agen atau model?

Yang pertama adalah hook, dan hook sebenarnya sangat bagus untuk hal-hal yang dimasukkan orang ke dalam AGENTS.md, misalnya, selalu jalankan linter setelah Anda selesai menulis.

// settings.json

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

Hal itu bisa menjadi hook.

Hook adalah agen yang mengekspos semua peristiwa yang dapat Anda ikuti, dan ada peristiwa untuk hampir semua hal yang dapat Anda pikirkan, tetapi yang utama adalah memulai sesi, menghentikan sesi, membaca, dan menulis file.

Jadi, daripada menulis di bagian bawah AGENTS.md, "selalu jalankan linter", atau, "selalu jalankan suite pengujian saya sebelum mengatakan Anda selesai", Anda cukup memiliki stop hook yang dapat menjalankan skrip deterministik, dan ini membantu mengendalikan sedikit keacakan AI.

Selain itu, jika Anda memiliki file yang benar-benar tidak ingin dibaca atau ditulis oleh agen, misalnya file rahasia, Anda tidak ingin file tersebut dikirim ke server, atau AGENTS.md, Anda tidak ingin agen dapat menulis ke file tersebut, Anda dapat menggunakan hook untuk itu.

Jadi, Anda memiliki hook baca atau tulis, Anda mendapatkan file yang coba diedit, dan Anda dapat menampilkan, "Tidak, Anda tidak dapat melakukannya".

Ini hanyalah cara untuk menambahkan determinisme.

Berikutnya adalah keterampilan.

Dan sebenarnya ada keterampilan untuk mengubah AGENTS.md Anda menjadi hook sekarang.

Itu hal yang sama sekali berbeda.

Namun, keterampilan adalah cara menambahkan konteks hanya jika relevan.

Jadi, AGENTS.md ditujukan untuk hal-hal yang selalu relevan.

Keterampilan ditujukan untuk hal-hal yang relevan dalam situasi tertentu, terutama dokumentasi.

Jadi, skill terdiri dari tiga bagian: nama, deskripsi, dan ini bagian yang penting,deskripsi ini dibatasi hingga 1.024 karakter, lalu ada isi.

---

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

Dan isi email bisa sangat besar, bahkan bisa menyertakan skrip lain, yang cukup umum.

Anda dapat melakukan banyak hal dengan keterampilan.

Mari kita lihat contohnya.

Ini adalah deskripsi Android CLI.

Anda tidak perlu membaca semuanya.

Cukup ketahui bahwa ini seperti deskripsi singkat yang menjelaskan kapan Android CLI relevan.

Lalu, ini adalah isi emailnya.

Ukurannya sangat besar, jadi kita tidak ingin memuat semua ini setiap saat, bukan?

Kita hanya ingin memuatnya saat mencoba menggunakan Android CLI, dan itulah yang dapat dilakukan dengan skill.

Namun, penting untuk bersikap selektif terkait keterampilan yang Anda instal.

Kita tidak ingin menginstal begitu saja repositori yang kita lihat di internet yang berisi ratusan keterampilan rekayasa agentic.

Pertama, hal itu merupakan risiko keamanan yang sangat besar.

Anda tidak tahu apa yang ada dalam keterampilan tersebut, yang bisa saja memberi tahu agen Anda untuk melakukan apa pun.

Dan kami memiliki serangkaian keterampilan Android, saya berjanji kami telah memeriksanya, mereka tidak mengatakan itu.

Namun, kedua, 100 deskripsi dikalikan 1.000 karakter adalah 100.000 karakter yang baru saja Anda tambahkan bahkan sebelum Anda mulai melakukan coding.

Jadi, Anda sudah mendekati jendela tersebut.

Oleh karena itu, untuk skill Android, sebaiknya instal saja skill dasar Android CLI untuk semuanya, dan dari sana Android CLI dapat menelusuri skill yang tersedia dan menginstal skill yang sesuai untuk aplikasi Anda.

> android init

✓ Installed base skill: android-cli

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

Atau, jika Anda melihatnya, sebaiknya ketahui keterampilan apa yang tersedia, Anda dapat menambahkan keterampilan yang sesuai untuk project Anda secara manual, seperti keterampilan Compose, keterampilan edge-to-edge, yang cukup universal.

Tentu saja, ada keterampilan untuk mengaudit keterampilan.

Jadi, ada /skill-doctor di Claude Code, dan fitur itu akan melihat dan memberi tahu Anda keterampilan apa yang Anda sertakan yang tidak pernah diaktifkan, sehingga Anda hanya membuang-buang deskripsi seribu karakter itu.

Dan jika Anda tidak menggunakan Claude Code, hampir setiap infrastruktur pengelola agen memiliki semacam layar statistik atau layar audit untuk melakukan hal yang sama.

Jadi, sekali lagi, Android CLI, itulah linknya.

Namun, model ini memiliki perintah daftar keterampilan, dan misalnya Anda memiliki Navigation 3 dalam project Anda.

android skills list
android skills add navigation-3

Navigation 3 adalah library yang cukup baru, jadi belum banyak pelatihan yang dilakukan, Anda dapat menambahkan keterampilan Navigation 3.

Kita sering Oh, maaf.

Berikutnya adalah MCP.

Namun, kami sering ditanya mengapa kami menjadikan Android CLI sebagai CLI, bukan server MCP?

Kami telah membangun CLI ini jauh sebelum AI ada, bahkan jauh sebelum mouse ada, kami sudah membangun CLI, jadi CLI cepat, dapat dikomposisi, dan karena berjalan secara lokal di sesi shell Anda, CLI ini efektif dan gratis untuk dijalankan.

Selain itu, tolok ukur seperti Terminal Bench telah menjadi tolok ukur terbesar dalam hal rekayasa software, sehingga pembuat model secara agresif meningkatkan penggunaan terminal, sehingga mereka sangat mahir menggunakan CLI saat ini.

Namun, bukan berarti MCP tidak memiliki tempat.

Server MCP sangat cocok untuk layanan eksternal yang sudah Anda gunakan, terutama jika layanan tersebut sudah menghosting layanan MCP.

Anda dapat langsung menghubungkannya, dan ini adalah cara tanpa penginstalan untuk mendapatkan konteks tambahan ke agen Anda.

Layanan seperti GitHub, Figma, dan Slack kini mengekspos server MCP.

Lalu, hal-hal yang selalu kita jalankan di shell dapat tetap berada di shell, jadi perintah Android melalui Android CLI, tetapi Perfetto dan Gradle juga sebaiknya berada di lokal tempat keduanya memiliki akses ke semua yang Anda gunakan dalam pengembangan.

Saya pernah menangani performa.

Saya selalu mengatakan, Perfetto adalah satu-satunya alat yang Anda perlukan untuk menyelesaikan masalah performa apa pun.

Namun, kurva pembelajarannya sangat curam, seperti yang baru saja kita lihat dalam presentasi terakhir dari Rahul.

Mari kita lihat bagaimana AI dapat membantu meningkatkan performa.

Terima kasih, Ben.

Jadi, agar aplikasi kami, Sideline, dapat berfungsi, aplikasi ini harus berjalan pada 30 frame per detik, dan secara real time.

Seperti yang Anda lihat di Pixel 10 Pro Fold ini, kita hanya mendapatkan sekitar 20 hingga 22 frame per detik.

Frame yang hilang ini akan menjadi masalah, karena berarti aplikasi tidak akan berfungsi seperti yang diiklankan, jadi kita benar-benar perlu memperbaikinya.

Dengan Android CLI, kita memiliki perintah profiler Android.

Saat kami menambahkannya ke agen coding, dan kami menginstruksikannya untuk memenuhi persyaratan 30 frame per detik ini, dua hal menarik terjadi.

Pertama, Gemini menemukan perbaikan menggunakan perintah Android Profiler.

Alat ini merekam pelacakan sistem di perangkat Pixel 10 Pro Fold yang terpasang, dan menemukan bahwa thread AI-nya berjalan di core paling lambat di perangkat.

Dan yang kedua adalah, menariknya, Gemini menggunakan penelusuran dokumen Android tanpa kami minta secara eksplisit, dan mengambil panduan resmi untuk Performance Hint API.

Yang dipelajari agen adalah mengoptimalkan jadwal sistem, dan dengan demikian, agen dapat memenuhi persyaratan 30 frame per detik.

Jadi, pada dasarnya, perbaikan yang dilakukan mengikuti panduan.

Jadi, dengan Android CLI, kuncinya adalah, Anda tahu, dengan menghubungkannya dengan agen, alat ini membantu Anda menemukan alat yang tepat, meskipun Anda tidak terbiasa dengan alat tersebut, untuk pekerjaan apa pun yang perlu Anda selesaikan.

Jadi, setelah kita menjalankannya, Anda dapat melihat bahwa Sideline memenuhi persyaratan 30 frame per detik yang dimiliki pengguna, dan kini berfungsi di Pixel 10 Pro Fold.

Oke.

Sekarang, kita akan menggabungkan semuanya dengan loop.

Jadi, saya yakin kita semua pernah melakukan ini, Anda meminta agen untuk menerapkan beberapa perubahan besar, dan agen tersebut kembali dan mengatakan bahwa perubahan tersebut telah selesai.

Dan jika Anda menginstalnya dan mengklik aplikasi secara manual, lalu mengetik kembali bug, itulah yang harus kita hentikan.

Kita harus berhenti menjadi penguji QA agen dan menentukan di awal apa yang kita anggap sebagai selesai.

Berikut contohnya.

Kami ingin memigrasikan seluruh project ke Nav3, lalu agen akan menghilang, prosesnya memang memerlukan waktu, tetapi agen akan kembali dengan percaya diri dan berkata, "Migrasi selesai.

Aku yang terbaik."

Namun, tentu saja, Anda memutar ponsel, aplikasi error, semua transisi slide terlewat, dan file Gradle-nya tidak dibersihkan.

Ini seperti dunia tempat kita berada saat ini.

Idealnya, kita tidak perlu melakukan ini, tetapi inilah kenyataan saat ini.

Jadi, kita harus menentukan semua hal tersebut di awal tentang apa yang kita harapkan, dan hal itu akan memungkinkan agen melakukan loop hingga memenuhi semua kriteria tersebut.

Itulah yang dimaksud dengan loop verifikasi.

Kami memiliki data yang sangat kuat tentang efektivitas hal ini.

Jadi, ini adalah Android Bench 2.0, versi baru benchmark AI kami yang saya sebutkan di awal presentasi.

Tingkat kelulusan saat ini sekitar 40%.

Tugas-tugas ini sangat sulit, sangat besar, dan realistis, tetapi salah satunya adalah Nav2 ke Nav3, yaitu jenis hal yang Anda lakukan dalam project Anda saat ini.

Dan jika kita menggunakan Fable 5.1, tingkat keberhasilannya adalah 22%, itulah yang diperolehnya hanya dengan penyiapan perintah alami, seperti "migrasikan Nav2 ke Nav3".

Namun, jika kita memberinya suite pengujian yang gagal terlebih dahulu, jadi ini tidak memberinya jawaban, kita tidak memberi tahu cara bermigrasi ke Nav3, kita hanya memberinya suite pengujian yang sudah gagal dan akan lulus saat semua hal tersebut selesai, tingkat kelulusannya pada seluruh tolok ukur melonjak menjadi 90%.

Hal ini menunjukkan bahwa model ini sekarang benar-benar mampu mengimplementasikan hampir semua tugas Android yang dapat kita pikirkan, hanya saja tidak selalu tahu apa arti "selesai".

Jadi, Anda tidak perlu menulis suite pengujian gagal yang lengkap terlebih dahulu.

Loop verifikasi dapat sesederhana penambahan perintah.

Jadi, misalnya Anda sedang mengerjakan UI, Anda dapat memintanya untuk merender pratinjau Compose dan memastikan pratinjau tersebut sesuai dengan spesifikasi Figma, lalu menampilkan hasilnya kepada Anda.

Tampaknya, model ini benar-benar berfungsi saat Anda memintanya untuk menunjukkan hasil dan membuktikan bahwa tugas telah selesai, bukan hanya menerima respons teks, "Saya sudah selesai".

Jika Anda sedang mengerjakan logika bisnis, Anda dapat memintanya untuk menjalankan pengujian unit, atau, seperti yang kita lihat di awal, jika Anda sedang mengerjakan perbaikan error, Anda dapat memintanya untuk memvalidasi bahwa error telah diperbaiki di perangkat sungguhan tempat error tersebut terjadi melalui lab pengujian jarak jauh.

Sebenarnya ada keterampilan bawaan di Claude Code untuk membantu Anda membangun loop verifikasi sekarang.

Jadi, pastikan untuk memeriksanya.

Dan jika Anda bekerja di Android Studio dengan membawa agen Anda sendiri, Android Studio mengekspos banyak alat yang dapat Anda gunakan untuk membangun loop, bergantung pada apa yang sedang Anda kerjakan.

Jadi, seperti linter, Anda dapat memintanya untuk tidak berhenti sampai semua error lint diperbaiki, atau yang sangat saya sukai adalah perjalanan, Anda dapat memintanya untuk menjalankan perjalanan Anda dan memastikan perjalanan tersebut masih berfungsi.

Atau jika Anda telah menulis perjalanan, karena perjalanan cukup mudah ditulis, perjalanan hanyalah perintah tentang fitur yang sedang Anda kerjakan, Anda dapat memintanya untuk menjalankan perjalanan tersebut dan memastikan bahwa perjalanan tersebut lulus sebelum menyatakan dirinya selesai.

Namun, perjalanan memerlukan waktu beberapa saat untuk dijalankan.

Jadi, Anda juga dapat membuat tingkatan untuk level loop verifikasi Anda.

Jadi, kita dapat memintanya untuk memastikan terlebih dahulu bahwa pengujian unit dan Pratinjau Compose semuanya dirender dengan benar.

Kemudian, jika pengujian tersebut lulus, jalankan pengujian terhubung dan Android Journey kami, dan hanya jika pengujian tersebut lulus, jalankan pengujian penuh seperti lab pengujian perangkat jarak jauh, suite pengujian lengkap yang akan memakan waktu berjam-jam.

Dan jika Anda memberikan informasi tambahan tersebut, kami mendapati bahwa informasi tersebut akan diulang per tingkat, bukan mencoba melakukan setiap langkah pada setiap operasi.

Karena model sangat percaya diri.

Jadi, mereka selalu menganggap kode mereka sudah lengkap, dan mereka selalu menganggap kode mereka akan lulus semua pengujian pada percobaan pertama.

Jadi, mari kita lihat di Sideline.

Jadi, mari kita terapkan ide ini ke aplikasi Sideline, dan mari kita lakukan ini dengan menambahkan fitur baru, khususnya untuk kacamata XR, yang akan segera hadir.

Karena belum memiliki hardware, tentu saja kita akan menggunakan emulator XR dan menginstruksikan agen coding untuk memperluas Sideline untuk faktor bentuk baru.

Saat melakukannya, kita akan secara khusus meminta agen untuk melakukan loop melalui pengujian JVM, pengujian Pratinjau Compose, dan pengujian emulator dalam urutan tersebut.

Dan setiap loop diperintahkan untuk membangun loop sebelumnya.

Saat kita melakukannya, hal pertama yang kita perhatikan adalah bahwa antara loop satu dan dua, pengujian JVM-lah yang digunakan untuk menentukan enam status Pratinjau Compose.

Tentu saja, tidak ada emulator yang dipanggil, sehingga berjalan sangat cepat.

Kemudian, antara loop dua dan loop tiga, masalah seperti string panjang akan ditampilkan dan diperbaiki bahkan sebelum emulator harus dijalankan.

Jadi, akhirnya, setelah loop emulator berjalan, loop tersebut akan menemukan bug tambahan yang tidak dapat diperbaiki oleh pengujian JVM dan Pratinjau Compose.

Namun pada dasarnya, dengan setiap loop, kita semakin memperkuat aplikasi, dan kita ingin menjalankan loop tercepat tetapi paling tidak efektif terlebih dahulu, diikuti dengan loop paling lambat tetapi paling efektif.

Dan inilah hasilnya.

Video ini menunjukkan bahwa kacamata tersebut kini menampilkan jenis ayunan dan kecepatan bola yang keluar dari raket, sehingga Anda dapat bermain tenis dan mendapatkan masukan tentang gameplay Anda secara real time tanpa mengalihkan pandangan dari bola.

Oh, dan sebelumnya saya menyebutkan bahwa kita akan kembali ke dua masalah Crashlytics yang muncul sebelumnya.

Jadi, karena kita sudah dapat memvalidasi bahwa pendekatan tersebut berhasil, kita dapat menggunakan perintah /schedule di Claude Code untuk mengulanginya, dan kita dapat menetapkan ritme apa pun yang kita inginkan, sehingga sekarang kita memiliki aplikasi yang dapat memperbaiki sendiri semua bug dan memvalidasi bahwa bug tersebut telah diperbaiki, mengirimkannya sebagai permintaan pull kepada engineer kita untuk dilihat dan digabungkan.

Keren!

Jadi, cukup sekian untuk hari ini.

Jika Anda mengambil satu poin penting, mulailah memikirkan dunia tempat kita membangun lingkungan agar agen kita berhasil, dan memperlakukannya seperti cara kita memperlakukan pengembangan software dan bug saat ini.

Dengan begitu, kita dapat mengaktifkan agen paralel.

Anda akan menemukan banyak saran tentang topik ini di internet, dan banyak di antaranya yang saling bertentangan.

Dan itulah kenyataan dari lingkungan yang bergerak cepat ini.

Jadi, hal terbaik yang dapat Anda lakukan adalah menulis evaluasi sendiri untuk project Anda.

Lalu, saat ada saran atau model baru, Anda dapat mengukur dan melihat apakah saran atau model tersebut membantu Anda.

Dan tentu saja, ada keterampilan untuk semuanya.

Ada keterampilan untuk membantu Anda membuat evaluasi di Claude Code.

/claude-api build-eval

Kami sangat menyarankan Anda untuk melihatnya.

Saya membahas Android Bench hari ini.

Android Bench adalah evaluasi kami.

Dengan begitu, kami dapat mengukur untuk memastikan semuanya menjadi lebih baik.

Jika Anda ingin mendengar pelajaran yang kami peroleh saat membangunnya, agar Anda tidak melakukan kesalahan yang sama, tonton presentasi Android Bench.

Ada juga dua panel.

Ada satu di AS, ada satu di London.

Keduanya akan dipublikasikan secara online dan membahas jenis konsep ini dalam praktik di komunitas.

Jadi, kami mengundang anggota komunitas Android Dev ke panel untuk membahas cara mereka menerapkan hal ini dalam pekerjaan mereka.

Kami juga sangat mengharapkan masukan Anda.

Kami sangat ingin mendengar apakah kami membangun hal-hal yang benar-benar membantu Anda.

Jadi, harap isi survei ini.

Saya akan membiarkannya tetap ditampilkan di layar.

Dan, ya.

Terima kasih sudah mendengarkan.

Terima kasih.