הנדסה מבוססת-סוכנים באמצעות Claude Code ו-Android CLI

שלום, אני בן, מצוות קשרי המפתחים של Android.

אני סטיבן, מנהל מוצר.

היום נדבר על יצירת אפליקציות באמצעות Claude Code ו-Android CLI, באופן סוכני.

אז אני חושב שאפשר לומר שהתפקיד שלנו כמפתחים משתנה קצת, והדברים מתקדמים במהירות מטורפת, כל כך מהר, שלמען האמת, התוכן בשיחה הזו כנראה כבר לא עדכני, במיוחד אם אתם צופים באינטרנט.

אז נקטנו עמדה שצופה פני עתיד במה שכתבנו, במידע שאנחנו מציגים, אבל ההדגמות שהם מריצים היום, הן מבוססות על המציאות, אז הן אמורות להיות אמינות עכשיו.

דבר נוסף, השתמשנו ב-Claude Code בהרצאה הזו, אבל המידע לא תלוי בסוכן.

זו יותר גישה, ולכן היא צריכה לחול על כל מה שאתם מעדיפים להשתמש בו כשאתם מפתחים את האפליקציות שלכם.

לכן, אנחנו רוצים שתתחילו לחשוב על עולם שבו אתם מנהלים צוותים של סוכנים אוטונומיים ואיך אתם מכינים אותם להצלחה.

כשהם לא מצליחים להטמיע תכונה או משהו כזה, במקום פשוט לוותר ולהגיד, "טוב, AI עדיין לא יכול לעשות את זה", אנחנו צריכים לקחת צעד אחורה ולחשוב איזה מידע היה חסר, ולהתייחס לזה כמו שאנחנו מתייחסים לבאגים היום.

ואם קראתם משהו שפורסם על ידי הצוותים שמייצרים את כל המעטפות האג'נטיות האלה, Claude Code, ‏ Codex, ‏ Antigravity, תראו שככה הצוותים שלהם באמת מפתחים את המעטפות האלה, ואם נתייחס אליהם כאל הצצה לעתיד, כנראה שכולנו הולכים לשם.

אז כנראה שמעולם לא הייתה תקופה מרגשת יותר להיות מפתח של Android, אבל אם אתם כמוני, אולי קשה לכם לדעת במה בדיוק להתמקד.

אנחנו, כמפתחים, צריכים כלים ותהליכי עבודה שבאמת מתרחבים בצורה חכמה, כדי שכאשר מודל חדש מרחיב את הגבולות, כל העבודה הקשה שלנו לא תהפוך למיותרת.

אנחנו רוצים שכל שיפור במודל יוביל לתהליכי עבודה חכמים יותר של הסוכנים שלנו, ובסופו של דבר יניב תוצאות טובות יותר למשתמשים.

היום נדבר על ארבעה נושאים.

קודם נסביר למה חשוב להגדיר את הסוכנים בסביבות שמתאימות להם.

אחר כך נספק סקירה כללית על ההקשר ואיך הכי טוב לנהל אותו.

אחר כך נדבר על כמה מהכלים הכי טובים שיש לנו למפתחים של Android שעובדים בתוך סוכנים, ולבסוף נסביר למה כדאי להוסיף לולאות ל-Agentic Workflows.

בסדר, בואו נתחיל.

אז, סביבה.

אבל מה זה אומר בעצם?

כמו שאמרתי, אנחנו מנסים ליצור מרחב שבו הנציג שלנו יכול להצליח, ולהצליח בלי שתצטרכו לשבת שם וכל הזמן, אתם יודעים, לתת לו הנחיות מחדש ולהחזיר אותו למסלול, כי כשאתם עושים את זה, אז אתם יכולים להפעיל נציגים במקביל, ושם, אתם יודעים, מגיעים הרווחים האמיתיים בפרודוקטיביות, כשאתם יכולים להפעיל את הצוותים האלה של הנציגים שכולם עושים את העבודה בשבילכם.

אבל זה הרבה יותר מרק גישה לקוד.

הם צריכים גישה לתיעוד מדויק, כולל מפרטי הפרויקט וכללים לעבודה בפרויקט.

זה די ברור.

יש אנשים שמחברים את הנציג שלהם למרחב הצ'אט של הצוות, לא רק כדי להפעיל נציגים, אלא כדי לספק את ההקשר של האופן שבו התקבלו החלטות שהובילו לתכונה שהם התבקשו לעשות, כי כמפתחים, זה סוג המידע התת-מודע שאתם משתמשים בו כשאתם פותרים בעיות, ולכן זה יכול להיות שימושי גם לנציג שלכם.

וגם כמו היסטוריית ההחלטות הקודמות ובקשות משיכה (pull request).

הם צריכים להיות מסוגלים לראות את התגובות שאתם מקבלים על בקשות ה-pull שלכם, את סוג הדברים שהם מקבלים עליהם פינגים, דברים כאלה, ואז תגלו שהם יכולים לעבוד ולתקן את זה.

כמו שאתם לא מצפים שתוכלו לכתוב קוד ל-Android בלי גישה למכשיר או לאמולטור, אתם לא צריכים לצפות שהנציג יוכל לעשות את זה.

אני יודע שהם נראים מדהימים ויכולים לעשות הכול, אבל אמולטור ממש עוזר.

אותו דבר לגבי פרופיילרים.

אם אתם רוצים שהם יעבדו על הביצועים, הם צריכים להיות מסוגלים ליצור פרופיל, וזה כולל גישה למכשיר אמיתי.

ואם האפליקציה שלכם משתמשת בשירותי קצה עורפי, כדאי שהסוכן יוכל לתקשר גם איתם.

כאן Android CLI נכנס לתמונה.

אם לא שמעתם עליו, הוא הוזכר גם בשיחה "מה חדש בכלים", אבל Android CLI הוא ה-CLI החדש שלנו לממשק, רק עם כלים שונים של Android.

זה לא מוצר AI בפני עצמו, אלא רק ממשק שורת פקודה (CLI).

כך שאתם מקבלים גישה לדברים כמו Android SDK Manager, יכולת להפעיל אמולטורים, ועוד הרבה דברים.

הוא גם מתחבר לכלים ולמערכות לקצה העורפי כמו Crashlytics.

הוא פועל בכל סוכן שבו אתם משתמשים, הוא פשוט נמצא במרחב המעטפת שלכם.

אז כן.

אפשר להתקין אותו דרך הקישור הזה, אבל לדעתי קל יותר פשוט לראות אותו בפעולה.

טוב.

לכן, במקום רק להסביר למה כל כך חשוב להגדיר את הנציגים להצלחה, רצינו ליישם את העיקרון הזה באפליקציה בסביבת הייצור שבנינו, שנקראת Sideline.

ו-Sideline היא אפליקציה ל-Android לשחקני טניס, שמספקת להם משוב בזמן אמת על מיקום הכדור, מיקום השחקן ומיקום המגרש.

הוא מספק משוב לאימון אופליין באמצעות הפעלה מחדש של סרטונים, ונתונים של אימוני כושר כמו המהירות הגבוהה ביותר, המרחק שעברתם והראלי הארוך ביותר.

הכול מופעל באמצעות מודלים מותאמים אישית של TF Lite שפועלים ישירות במכשיר Android.

קודם כול, חשוב לי להגיד שאנחנו לא יכולים לפתור בעיות שאנחנו לא יודעים על קיומן.

אז באמצעות Android CLI, הוספנו את Firebase Crashlytics לסביבת הפיתוח שלנו, וזה אפשר לנו למצוא כמה בעיות שאפילו לא ידענו שקיימות.

הראשונה הייתה שגיאת "האפליקציה לא מגיבה" (ANR) במכשיר Pixel 11 Pro Fold, שלא שוחזרה באמולטור.

למרבה המזל, Android CLI תומך בסטרימינג של מכשירי Android.

ומה שהסוכן עשה אחרי שאמרנו לו לתקן את הבעיה הזו, הוא יצר חיבור למכשיר שבו התרחשה ה-ANR, וזה היה שימושי במיוחד בשבילי כי באותו זמן לא היה לי Pixel 11 Pro Fold כדי לאמת את התיקון.

אז כשהענקנו לסוכן את היכולת לגשת למכשיר שהוא היה צריך כדי לאמת את התיקון, בסופו של דבר הצלחנו להרחיב את היכולות של מה שאפשר לעשות.

כדי לחסוך זמן, הרצתי את כל הניסויים מראש וסיכמתי אותם כאן.

ובלי להיכנס יותר מדי לפרטים, הבעיה שהייתה לנו הייתה קריאת אפיניות שקשורה ל-Android 17.

זה היה תיקון מהיר של שתי שורות, שנראה לי טוב.

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

אז יצרתי את בקשת משיכה (pull request), מיזגתי אותה ועדכנתי עם build חדש שנשלח ל-Play.

לכן, אם לא היינו מגדירים את סביבת התכנות עם היכולות שהיא צריכה כדי להצליח, לא היינו יכולים לזהות בעיה אמיתית, וגם לא היינו יכולים לאמת תיקון.

אז בגרסאות 1.0, אפשר לראות שהבעיה נפתרה.

אבל יש בעיות חדשות, ונדבר עליהן בהמשך.

טוב.

השלב הבא: הקשר.

לפני שנה וחצי או שנתיים, שזה לא הרבה זמן, אבל בעולם ה-AI זה נצח, היה מרוץ להגדלת חלונות ההקשר. התיאוריה הייתה שככל שניתן למודל יותר מידע, נקבל תוצאות טובות יותר. עשינו דברים משוגעים, כמו לנסות לכלול את כל developer.android.com בהנחיה, וזה לא ממש עבד.

אבל למרות שחלונות ההקשר הגיעו פחות או יותר לשיא, היכולות של המודלים עדיין משתפרות.

אז זה Android Bench 1.0.

‫Android Bench הוא מבחן הביצועים שלנו שבודק את היכולת של ה-AI לכתוב קוד ל-Android.

המשימות בו מציאותיות.

אלה הדברים שעובדים עליהם, ואנחנו יכולים לראות שחלונות ההקשר הגיעו לשיא בנקודת הציון של מיליון, אבל היכולת של המודל ממשיכה לעלות.

אבל ההקשר הוא עדיין תקציב קבוע, ואתם רוצים לשמור אותו לדברים החשובים.

אתם לא רוצים שיהיו שם דברים שלא עוזרים לפתור את הבעיה הספציפית שאתם עובדים עליה.

והרבה מהמעטפות האג'נטיות לא באמת חושפות בפניכם את כל חלון ההקשר של מיליון הטוקנים, כי הן מוצאות שזה חסר טעם.

התוצאות רק מחמירות כשהם עושים את זה.

ויש למעשה נקודה אידיאלית, והיא משתנה בהתאם למודל, אבל אם אתם יכולים לשמור על השיחות שלכם בערך ב-150,000 טוקנים, שם אתם מקבלים את מלוא הכוח של המודל בלי שום ריקבון הקשר.

אבל ההקשר הוא לא רק מה שאתם מקלידים.

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

למעשה, יש הרבה דברים שקורים מאחורי הקלעים שאתם לא רואים.

הוא מורכב מכמה חלקים.

הראשונה היא הוראת המערכת.

ההוראה למערכת ניתנת על ידי הנציג.

זה כמו הנחיה שאומרת לו איך לעבוד עם הסוכן הזה, ואיך הוא צריך להתנהג.

אבל גם מידע על סביבת העבודה, כמו ספריית העבודה הנוכחית, ערכות ה-SDK שיש לכם, מיומנויות מותקנות, נדבר על זה עוד רגע, וכלי MCP, כל הכלים שהסוכן שלכם מספק.

המודל צריך לדעת שהוא יכול להפעיל אותן, וזה תופס מקום בהקשר.

אבל ההבדל הגדול הוא שכל ההיסטוריה של ההודעות וקריאות ה-API לכלי נשלחת עם כל הנחיה, כל הודעה חדשה שאתם שולחים, עם הנציג שלכם.

וזה יכול להצטבר, במיוחד עם Gradle.

כמו שכולנו יודעים, היומנים של Gradle הם ממש ארוכים, ממש ממש ארוכים, ומאוד מפורטים.

רוב המידע הזה לא נדרש.

הנה טיפ קצר שיעזור לכם להיזהר מזה.

אתם יכולים להריץ את Gradle במצב שקט.

./gradlew assembleDebug --quiet

או שהמעטפות האג'נטיות הגדולות יותר חותכות את זה בשבילכם.

אז ב-Claude Code וב-Android Studio, אנחנו לא שולחים את יומן ה-Gradle המלא.

אבל אם משתמשים באחד מהסוכנים המינימליים, כי כל הפילוסופיה שלהם היא לשלוח הכל למודל, המודל יודע הכי טוב, אז mini-SWE-agent, הוא שולח את כל יומן ה-Gradle, וזה יכול להיות ממש יקר ממש מהר.

אבל איך אפשר להישאר בטווח של 150,000?

הסוד הוא להשתמש בתהליך עבודה.

ויש המון תהליכי עבודה כאלה.

הסרטון שאני הכי אוהב הוא של בחור בשם מאט פוקוק, ויש לו סדרה של מיומנויות שיעזרו לכם לנהל את הסשנים האלה.

אז היא מתחילה במיומנות שנקראת "grill-me".

אתם מפעילים את המיומנות הזו כשאתם מתחילים פרויקט שלם או רק פיצ'ר חדש בתוך הפרויקט, והיא גורמת לסוכן לשאול אתכם כמה שאלות.

אז אתם יכולים פשוט לומר, "grill-me".

אני רוצה ליצור, לא יודע, מנהל שעון מעורר חדש באפליקציה שלי".

ואז הוא יתחיל לשאול אתכם שאלות כמו: באיזו שפה להטמיע את הקוד, לאן הוא שייך.

זה מוציא את כל חוסר הבהירות מהבעיה ומהראש שלכם, ומעביר אותה לבעיה.

ואז אנחנו מפעילים את המיומנות הבאה, שכותבת מסמך מפרט גדול.

יש מיומנות אחרת שמחלקת את זה לבעיות, ואנחנו מתייקים אותן במנהל הבעיות שאתם מעדיפים להשתמש בו.

ואז הרעיון הוא שכל אחת מהבעיות האלה צריכה להתאים בערך לחלון של 150,000.

ואז בוחרים בעיה אחת, או שעובדים בטרמינל או ב-IDE, מה שמעדיפים, בונים, מאמתים את הלולאה, אנחנו מנקים את ההקשר בסוף, אין יותר היסטוריית שיחות, ונשארנו בתוך החלון.

טוב.

עכשיו נדבר על AGENTS.md.

ב-AGENTS.md אתם יכולים לספק לסוכן מידע נוסף שרלוונטי לכל בעיה שהוא עובד עליה בפרויקט הזה או בכל סביבת העבודה, אם זה מה שאתם בוחרים לעשות.

אבל מכיוון שההוראות האלה ניתנות לכל הנחיה, חשוב שהן יכללו רק דברים שרלוונטיים כל הזמן.

לכן, הדברים שפועלים הם כללי ארכיטקטורה ומודולים.

אלה דברים שהסוכן לא יכול לדעת, במיוחד אם אתם עובדים על אפליקציה בקוד סגור.

אבל חשוב מאוד להבין אותם כדי לחסוך זמן בהתחלה, כשחושבים לאן התכונה הזו שייכת.

אז אפשר להכניס דברים כמו רכיבי ממשק משתמש למודול של מערכת העיצוב, או דברים אחרים שמתאימים מאוד, כמו טעויות נפוצות בסקירת קוד, או פשוט דברים נפוצים שאתם נתקלים בהם וצריכים להקליד כל הזמן.

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

למשל, בפרויקט הזה אנחנו מעדיפים להשתמש ב-kotlinx.datetime, דברים כאלה.

ורציתי מאוד לספק שיטות מומלצות שתמיד רלוונטיות, אבל המציאות היא שהן משתנות עם כל גרסה חדשה של המודל.

לכל מודל יש התנהגות שונה כשמדובר בהקשר נוסף.

לדוגמה, בימים של Opus 4.6, היה נפוץ מאוד להשתמש באותיות רישיות גדולות כדי לכתוב "לעולם אל תעשו את זה".

ואז, כש-Opus 5 יצא, Anthropic פרסמה הצהרה שאומרת, "למעשה, אותיות רישיות כבר לא עובדות כל כך טוב.

פשוט משתמשים באותיות קטנות".

לזה אני מתכוון: צריך להיות עם היד על הדופק.

אבל יש כמה דברים שעדיין נכונים כמעט תמיד, כמו לשמור על אורך קצר.

לכן, כדאי שהקובץ לא יכלול יותר מ-250 שורות.

והנושא הבא קצת מפלג, כי אני יודע שהרבה אנשים אוהבים לעשות את זה, אבל מחקר שיצא בפברואר השנה הראה שאם נותנים לסוכן לשנות את ה-AGENTS.md שלו, זה פוגע בביצועים ב-2 עד 3 אחוזים בערך, וזה לא כזה נורא.

אבל החלק החשוב הוא שהעלויות גדלו ב-20%.

אז הביצועים קצת נפגעו והעלויות זינקו, וכל זה רק כי נתנו לסוכן לכתוב AGENTS.md משלו.

דרך אחת לעקוף את זה שראיתי, היא לגרום לסוכן לכתוב רטרוספקטיבה בסוף כל בקשת משיכה, ואז אתם כצוות ברטרוספקטיבות שלכם יכולים לקרוא את כולן ביחד ולהחליט אילו שינויים אתם הולכים לעשות, כי הקובץ הזה הופך להיות החלק המרכזי בתשתית הצוות הקריטית אם אתם עובדים בצוותים גדולים עם סוכנים.

אז בקצרה, הנה AGENTS.md של אפליקציית Sideline שבנינו.

יש שני דברים שאני רוצה להדגיש כאן.

הסיבה הראשונה היא שארכיטקטורה מוגדרת בבירור תחסוך לכם טוקנים ותחסוך לכם בחלון ההקשר.

בעצם, זה מאפשר לסוכן להימנע מהצורך לבדוק כל הזמן עוד חלקים בבסיס הקוד ולהסיק עוד ועוד מסקנות.

הוא מספק הנחיה מוגדרת וברורה מאוד.

הדבר השני שרציתי לציין קשור במיוחד לאפליקציות בקוד סגור.

ברור שאם אתם מקור סגור, אף אחד מהסוכנים לא הצליח לאמן מודלי LLM על בסיס הקוד שלכם.

לכן, במקרים כאלה, חשוב במיוחד להקדיש את הזמן הנוסף הזה, להשקיע את המחזורים האלה בניקוי, בבדיקה, בשיפור ובשיפור מתמידים של AGENTS.md, כי זה יועיל לך בטווח הארוך.

אם לא כדאי להכניס הכול ל-AGENTS.md, איך אפשר לשנות את ההתנהגות של הנציג או המודל?

הראשון הוא הוקים, והוקים הם למעשה ממש טובים לדברים שאנשים שמים ב-AGENTS.md כמו למשל, תמיד להריץ את ה-linter כשמסיימים לכתוב.

// settings.json

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

זה יכול להיות הוק.

הוק הוא בעצם אירוע שהסוכן חושף ואפשר להירשם אליו. יש הוקים כמעט לכל דבר שאפשר לחשוב עליו, אבל העיקריים הם התחלת סשן, הפסקת סשן, קריאת קבצים וכתיבת קבצים.

אז במקום לכתוב בתחתית של AGENTS.md, "תמיד להפעיל את ה-linter" או "תמיד להפעיל את חבילת המקרים לבדיקה לפני שאתה אומר שסיימת", פשוט יש לך stop hook שיכול להפעיל סקריפט דטרמיניסטי, וזה עוזר לרסן את האקראיות הקלה של ה-AI.

דוגמה נוספת: אם יש לכם קבצים שאתם ממש לא רוצים שהסוכן יוכל לקרוא או לכתוב, למשל קובץ סודי, ואתם לא רוצים שהוא יישלח לשרת או ל-AGENTS.md, ואתם לא רוצים שהסוכן יוכל לכתוב בו, אתם יכולים להשתמש ב-hook בשביל זה.

אז יש לכם הוק לקריאה או לכתיבה, אתם מקבלים את הקובץ שהוא מנסה לערוך, ואתם יכולים פשוט להחזיר, "לא, אי אפשר לעשות את זה".

זו פשוט דרך להוסיף דטרמיניזם.

השלב הבא הוא מיומנויות.

ויש גם מיומנויות שיכולות להפוך את AGENTS.md לווים.

זה כבר משהו אחר לגמרי.

אבל המיומנויות הן דרך להוסיף הקשר רק כשהוא רלוונטי.

לכן, AGENTS.md מיועד לדברים שתמיד רלוונטיים.

מיומנויות הן דברים שרלוונטיים במצבים מסוימים, בעיקר תיעוד.

אז מיומנויות מורכבות משלושה חלקים: יש להן שם, יש להן תיאור, וזה החלק החשוב, התיאור הזה מוגבל ל-1,024 תווים, ואז יש להן גוף.

---

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

גוף הפונקציה יכול להיות עצום, והוא יכול אפילו לכלול סקריפטים אחרים, וזה די נפוץ.

אתם יכולים לעשות הרבה דברים עם סקילים.

בואו נראה דוגמה.

זה התיאור של Android CLI.

אתם לא חייבים לקרוא את כל זה.

חשוב לדעת שזה כמו תיאור קצר שמסביר מתי Android CLI רלוונטי.

וזה גוף ההודעה.

הוא עצום, אז אנחנו לא רוצים לטעון את כל זה כל הזמן, נכון?

אנחנו רוצים לטעון את זה רק כשאנחנו מנסים להשתמש ב-Android CLI, וזה מה שהמיומנות מאפשרת לנו לעשות.

עם זאת, חשוב לבחור בקפידה את המיומנויות שאתם מתקינים.

אנחנו לא רוצים להתקין באופן עיוור את המאגרים שאנחנו רואים באינטרנט, שכוללים מאות מיומנויות הנדסה של סוכנים.

קודם כול, זה סיכון אבטחה עצום.

אין לכם מושג מה המיומנויות האלה כוללות, והן יכולות להורות לסוכן לעשות כל דבר.

ויש לנו קבוצה של מיומנויות ל-Android, אני מבטיח שבדקנו אותן, הן לא אומרות את זה.

אבל שנית, 100 תיאורים כפול 1,000 תווים הם 100,000 תווים שהוספתם עוד לפני שהתחלתם לתכנת.

אז אתם כבר מתקרבים לחלון הזה.

לכן, כשמדובר במיומנויות של Android, אנחנו ממליצים להתקין את מיומנות הבסיס של Android CLI לכל דבר, ומשם Android CLI יכול לחפש את המיומנויות הזמינות ולהתקין את אלה שמתאימות לאפליקציה שלכם.

> android init

✓ Installed base skill: android-cli

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

ואם אתם כן מסתכלים, כדאי לדעת אילו מיומנויות זמינות, אתם יכולים להוסיף באופן ידני את אלה שמתאימות לפרויקט שלכם, כמו מיומנויות Compose, מיומנויות מקצה לקצה, אלה די אוניברסליות.

כמובן שיש מיומנויות לבדיקת מיומנויות.

אז יש את /skill-doctor ב-Claude Code, והוא יבדוק ויגיד לכם אילו יכולות אתם כוללים שאף פעם לא מופעלות, כך שאתם פשוט מבזבזים את התיאור של אלף התווים.

ואם אתם לא משתמשים ב-Claude Code, כמעט לכל מעטפת אג'נטית יש מסך סטטיסטיקה או מסך ביקורת שעושה את אותו הדבר.

אז שוב, Android CLI, זה הקישור.

אבל יש לו פקודה של רשימת מיומנויות, ואז נניח שיש לכם את Navigation 3 בפרויקט.

android skills list
android skills add navigation-3

‫Navigation 3 היא ספרייה חדשה יחסית, אז עדיין אין הרבה חומרי הדרכה לגביה. אתם יכולים להוסיף את המיומנות Navigation 3.

אנחנו לעיתים קרובות, אה, סליחה.

השלב הבא הוא MCP.

אבל הרבה פעמים שואלים אותנו למה הפכנו את Android CLI ל-CLI ולא לשרת MCP.

אנחנו מפתחים את ממשקי שורת הפקודה האלה הרבה לפני שה-AI היה קיים, הרבה לפני שהעכבר היה קיים, פיתחנו ממשקי שורת פקודה, אז הם מהירים, הם ניתנים להרכבה, ומכיוון שהם פועלים באופן מקומי בסשן המעטפת, הם למעשה פועלים בחינם.

וגם, נקודות השוואה כמו Terminal Bench הפכו לנקודות ההשוואה הכי גדולות כשמדובר בהנדסת תוכנה, ולכן יצרני המודלים מטפסים באגרסיביות נגד השימוש בטרמינל, כך שהם ממש טובים בשימוש ב-CLI בימים אלה.

אבל זה לא אומר שאין מקום ל-MCP.

שרתי MCP מתאימים במיוחד לשירותים חיצוניים שאתם כבר משתמשים בהם, במיוחד אם הם כבר מארחים שירות MCP.

אפשר להתחבר אליו ישירות, וזו דרך לקבל הקשר נוסף לנציג בלי להתקין שום דבר.

פלטפורמות כמו GitHub,‏ Figma ו-Slack חושפות עכשיו שרתי MCP.

ודברים שתמיד הרצנו במעטפת יכולים להישאר במעטפת, כמו פקודות Android דרך Android CLI, אבל גם Perfetto ו-Gradle פשוט הגיוני שיהיו מקומיים, שם יש להם גישה לכל מה שאתם משתמשים בו בפיתוח.

פעם עבדתי על ביצועים.

פעם תמיד אמרתי ש-Perfetto הוא הכלי היחיד שצריך כדי לפתור כל בעיה בביצועים.

אבל עקומת הלמידה הייתה תלולה מאוד, כפי שראינו בהרצאה האחרונה של רהול.

בואו נראה איך AI יכול לעזור לשפר את הביצועים.

תודה, בן.

כדי שהאפליקציה שלנו, Sideline, תעבוד, היא צריכה לפעול בקצב של 30 FPS ובזמן אמת.

וכמו שאפשר לראות כאן ב-Pixel 10 Pro Fold, אנחנו מגיעים רק ל-20 עד 22 FPS.

הפריימים שהושמטו יהיו בעיה, כי זה אומר שהאפליקציה לא תפעל כמו שפורסם, אז אנחנו באמת צריכים לתקן את זה.

ב-Android CLI יש לנו את פקודות הפרופיילר של Android.

וכשאנחנו מוסיפים את זה לסוכן התכנות שלנו, ומורים לו לעמוד בדרישה הזו של 30 FPS, קורים שני דברים מעניינים.

הראשונה היא שהכלי מוצא תיקון באמצעות פקודת הפרופיילר של Android.

הוא תיעד את עקבות המערכת במכשיר Pixel 10 Pro Fold המחובר, וגילה שהתהליכים של ה-AI פועלים בליבות הכי איטיות במכשיר.

והדבר השני הוא שהוא השתמש בחיפוש במסמכי התיעוד של Android, באופן מעניין, בלי שביקשנו ממנו במפורש לעשות את זה, ושלף את ההנחיות הרשמיות ל-Performance Hint API.

מה שהסוכן למד לעשות היה לבצע אופטימיזציה של לוח הזמנים של המערכת, וכך הוא הצליח לעמוד בדרישות של 30 FPS.

אז בעצם מה שקרה זה שהתיקון בוצע לפי ההנחיות.

אז עם Android CLI, העיקר הוא, אתם יודעים, לחבר אותו לסוכן, זה עוזר לכם למצוא את הכלי הנכון, גם אם אתם לא מכירים את הכלי הזה, לכל עבודה שאתם צריכים לבצע.

אז אחרי שנפעיל אותו, תוכלו לראות ש-Sideline עומדת בדרישה של המשתמשים ל-FPS, ועכשיו היא פועלת ב-Pixel 10 Pro Fold.

טוב.

עכשיו נשלב את הכול באמצעות לולאות.

אני בטוח שכולנו עשינו את זה: ביקשנו מהסוכן לבצע שינוי גדול, והוא חזר ואמר שהוא סיים.

ואם אתם מתקינים אותה ולוחצים ידנית על האפליקציה בעצמכם, ואתם מקלידים את הבאגים, זה סוג הדברים שאנחנו צריכים להפסיק לעשות.

אנחנו צריכים להפסיק להיות בודקי ה-QA של הסוכן שלנו ולהגדיר מראש מה נחשב מבחינתנו כמשימה שהושלמה.

הנה דוגמה.

אנחנו רוצים להעביר את כל הפרויקט ל-Nav3, ואז הנציג נעלם, זה לוקח קצת זמן, אבל הוא חוזר בביטחון ואומר, "ההעברה הושלמה.

אני הכי טוב".

אבל אז, כמובן, אתם מסובבים את הטלפון, האפליקציה קורסת, היא פספסה את כל המעברים בין השקפים, היא לא ניקתה את קובץ ה-Gradle שלה.

זה קצת כמו העולם שאנחנו חיים בו עכשיו.

היינו מעדיפים שלא נצטרך לעשות את זה, אבל זו המציאות כרגע.

לכן, היינו צריכים להגדיר את כל זה מראש, ואז הנציג היה יכול להמשיך בלולאה עד שהוא היה עומד בכל הקריטריונים האלה.

זה מה שנקרא לולאת אימות.

ויש לנו נתונים חזקים מאוד על היעילות של זה.

אז זה Android Bench 2.0, הגרסה החדשה של מבחן הביצועים ל-AI שהזכרתי בתחילת ההרצאה.

שיעור המעבר עומד כרגע על כ-40%.

המשימות האלה ממש קשות, והן ממש גדולות ומציאותיות, אבל אחת מהן היא Nav2 ל-Nav3, אלה סוגי הדברים שאתם עושים בפרויקטים שלכם בזמן אמת.

ואם ניקח את Fable 5.1, שיעור ההצלחה שלו הוא 22%, זה מה שהוא מקבל רק עם הגדרת ההנחיה הטבעית, כמו "העבר את Nav2 ל-Nav3".

אבל אם אנחנו נותנים לו מראש חבילת מקרים לבדיקה שנכשלה, אז זה לא נותן לו את התשובות, אנחנו לא אומרים לו איך לעבור ל-Nav3, אנחנו רק נותנים לו חבילת מקרים לבדיקה שכבר נכשלה ותעבור כשכל הדברים האלה יושלמו, שיעורי המעבר שלו בכל נקודת ההשוואה קופצים ל-90%.

זה מראה לנו שהמודלים האלה באמת מסוגלים עכשיו לבצע כמעט כל משימה ב-Android שאנחנו יכולים לחשוב עליה, הם פשוט לא תמיד יודעים מה המשמעות של "סיום".

כך שלא צריך לכתוב מראש חבילת מקרים לבדיקה שנכשלת.

לולאות אימות יכולות להיות פשוטות כמו הוספת הנחיות.

לדוגמה, אם אתם עובדים בממשק המשתמש, אתם יכולים לבקש ממנו לעבד את התצוגה המקדימה של Compose, לוודא שהיא תואמת למפרט של Figma ולהציג לכם את התוצאות.

נראה שזה באמת עובד כשמבקשים ממנו להראות את התוצאות ולהוכיח שהמשימה בוצעה, במקום פשוט לקבל את התשובה "סיימתי".

אם אתם עובדים על לוגיקה עסקית, אתם יכולים לבקש ממנו להריץ את בדיקות היחידה שלכם. לחלופין, כמו שראינו בהתחלה, אם אתם עובדים על תיקון קריסה, אתם יכולים להורות לו לאמת שהקריסה תוקנה במכשיר האמיתי שבו היא קרתה, באמצעות מעבדת בדיקה מרחוק.

למעשה, יש מיומנות מובנית ב-Claude Code שעוזרת לכם ליצור לולאות אימות.

כדאי לבדוק את זה.

ואם אתם עובדים ב-Android Studio עם סוכן משלכם, Android Studio חושף הרבה כלים שאפשר לבנות סביבם לולאות, בהתאם למה שאתם עובדים עליו.

אז כמו ה-linter, אתם יכולים להגיד לו לא להפסיק עד שכל שגיאות ה-lint יתוקנו, או, מה שאני ממש אוהב, אתם יכולים לבקש ממנו להריץ את התהליכים שלכם ולוודא שהם עדיין פועלים.

או אם כתבתם מסלול, כי מסלולים די קל לכתוב, הם רק הנחיות לגבי התכונה שאתם עובדים עליה, אתם יכולים להורות לו להריץ את המסלול הזה ולוודא שהוא עובר לפני שהוא מצהיר שהוא סיים.

אבל תהליכים כאלה לוקחים זמן.

אז מה עוד אפשר לעשות? אפשר להגדיר רמות שונות של לולאת האימות.

אז אנחנו יכולים לבקש ממנו לוודא קודם שכל בדיקות היחידה והתצוגות המקדימות של Compose מוצגות בצורה נכונה.

ואז, כשהבדיקה הזו עוברת, צריך להריץ את הבדיקות המחוברות ואת Android Journeys, ורק כשהן עוברות, להריץ את הבדיקה המלאה, כמו מעבדת בדיקה של מכשיר מרוחק, חבילת מקרים לבדיקה מלאה, שתימשך כמה שעות.

ואם אתם מספקים את המידע הנוסף הזה, אנחנו מגלים שהוא חוזר על עצמו בכל רמה במקום לנסות לבצע כל שלב בכל הרצה.

כי המודלים נשמעים מאוד בטוחים בעצמם.

לכן, הם תמיד חושבים שהם שלמים, והם תמיד חושבים שהם יעברו את כל הבדיקות בניסיון הראשון.

בואו נראה איך זה נראה ב-Sideline.

אז בואו ניישם את הרעיון הזה באפליקציית Sideline, ונוסיף תכונה חדשה במיוחד למשקפי ה-XR שיושקו בקרוב.

ומכיוון שעדיין אין לנו חומרה, כמובן, נשתמש באמולטור XR ונורה לסוכן הקידוד שלנו להרחיב את Sideline עבור גורם הצורה החדש.

כשאנחנו עושים את זה, אנחנו מבקשים מהסוכנים שלנו לעבור על בדיקות JVM, בדיקות של גרסאות טרום-השקה (Preview) של Compose ובדיקות של אמולטורים, בסדר הזה.

כל לולאה מתבססת על הלולאה הקודמת.

כשאנחנו עושים את זה, הדבר הראשון שאנחנו שמים לב אליו הוא שבין לולאה אחת לשתיים, בדיקות ה-JVM הן אלה שמשמשות להגדרת ששת המצבים של Compose Preview.

כמובן, לא הופעל אמולטור, אז זה פועל מהר מאוד.

באופן דומה, בין הלולאה השנייה לשלישית, בעיות כמו מחרוזות ארוכות מזוהות ומתוקנות עוד לפני שהאמולטור צריך לפעול.

אז בסופו של דבר, כשהלולאה של האמולטור פועלת, היא מוצאת באגים נוספים שבדיקת ה-JVM והתצוגות המקדימות של Compose לא הצליחו לתקן.

אבל בעיקרון, בכל לולאה אנחנו מקשיחים עוד יותר את האפליקציה, ואנחנו רוצים להריץ קודם את הלולאות המהירות ביותר אבל הכי פחות חזקות, ואחריהן את האיטיות ביותר אבל הכי חזקות.

והנה התוצאה.

הוא מראה שהמשקפיים מציגים עכשיו את סוג החבטה ואת מהירות הכדור שיוצא מהמחבט, כך שאפשר לשחק טניס ולקבל משוב על המשחק בזמן אמת בלי להוריד את העיניים מהכדור.

אה, וציינתי קודם שנחזור לשתי הבעיות ב-Crashlytics שצצו קודם.

אז מכיוון שכבר הצלחנו לאמת שהגישה הזו עבדה, אנחנו יכולים להשתמש בפקודה ‎/schedule ב-Claude Code כדי לעבור עליה בלולאה, ואנחנו יכולים להגדיר כל קצב שאנחנו רוצים, כך שעכשיו יש לנו אפליקציה שמתקנת את עצמה, מתקנת את כל הבאגים ומאמתת שהם תוקנו, שולחת אותם כבקשות משיכה למהנדסים שלנו כדי שיסתכלו עליהם וימזגו אותם.

מגניב.

זה פחות או יותר הכול להיום.

אם יש מסקנה אחת חשובה, היא שצריך להתחיל לחשוב על העולם הזה שבו אנחנו בונים סביבה שבה הסוכנים שלנו יכולים להצליח, ולהתייחס לזה כמו שאנחנו מתייחסים לפיתוח תוכנה ולבאגים היום.

ככה אנחנו מפעילים סוכנים מקבילים.

באינטרנט יש הרבה עצות בנושא הזה, והרבה מהן סותרות זו את זו.

וזו פשוט המציאות בסביבה שמשתנה במהירות.

לכן, הדבר הכי טוב שאתם יכולים לעשות הוא לכתוב הערכות משלכם לפרויקט.

ואז, כשמתפרסמת עצה חדשה או מודל חדש, אתם יכולים למדוד את זה ולראות אם זה עוזר לכם.

וכמובן, יש מיומנות לכל דבר.

יש מיומנות שעוזרת לכם ליצור הערכות ב-Claude Code.

/claude-api build-eval

מומלץ מאוד לבדוק את זה.

היום דיברתי על Android Bench.

‫Android Bench הוא כלי ההערכה שלנו.

ככה אנחנו מודדים את ההתקדמות שלנו.

אם אתם רוצים לשמוע על הלקחים שהפקנו מהפיתוח שלו, כדי שלא תעשו את אותן טעויות, כדאי לכם לצפות בהרצאה על Android Bench.

יש גם שני פאנלים.

יש אחד בארה"ב, יש אחד בלונדון.

שניהם יעלו לאינטרנט ויעסקו ביישום של הרעיון הזה בקהילה.

לכן, חברים בקהילת מפתחי Android יצטרפו לפאנל כדי לדבר על האופן שבו הם מיישמים את זה בעבודה שלהם.

אנחנו גם מאוד רוצים לקבל מכם משוב.

אנחנו רוצים לדעת אם אנחנו מפתחים דברים שבאמת עוזרים לכם.

לכן, נשמח אם תמלאו את הסקר.

אני אשאיר את זה על המסך.

וכן,

תודה על ההקשבה.

תודה.