יצירת בודק קוד רב-לשוני באמצעות סוכני Parallel Antigravity

1. מבוא

3072ce11df4b71eb.jpeg

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

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

מה תלמדו

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

הדרישות

כדי לבצע את ה-codelab הזה, צריך להתקין את הכלים הבאים באופן מקומי:

  • Google Antigravity
  • Git
  • שפה אחת או יותר מהשפות הבאות מוגדרות בסביבה שלכם: Go, ‏ Python, ‏ C#‎ / .NET, ‏ NodeJS, ‏ Java

קדימה, מתחילים!

2. הגדרת הסביבה

קודם כול, מוודאים שהאפליקציה Antigravity מותקנת.

בשלב השני, משכפלים את Online Boutique, אפליקציית הדגמה של מיקרו-שירותים בענן:

git clone https://github.com/GoogleCloudPlatform/microservices-demo.git

יוצרים פרויקט חדש ב-Antigravity עם הקוד. ב-Antigravity, לוחצים על Create New Project בקטע Projects בצד ימין:

e8b14447dfcc289b.png

בוחרים את תיקיית המאגר:

b39f0b1843ef1f3d.png

אתם יכולים לבחור את המצב Default עבור Agent Security Settings וגם להשתמש באותו שם microservices-demo לפרויקט.

3. Discovery

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

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

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

ב-Antigravity, מתחילים שיחה חדשה בmicroservices-demoפרויקט שיצרתם קודם. אפשר להשתמש במודל Gemini העדכני ביותר עם רמת חשיבה בינונית:

1a88687c5fe37b04.png

הנה הנחיה לדוגמה:

Identify all the microservices located under the src/ directory,
detect which programming language each service is written in, and
output the list as a clean markdown table showing: Service Name,
Directory, and Primary Language.

בסופו של דבר, Antigravity אמור להחזיר טבלה מסודרת של השירותים והשפה העיקרית שלהם, בדומה לטבלה הבאה:

2e37b2e607596573.png

4. בחירת שפות

אחרי שמיפיתם את בסיס הקוד, צריך לבחור את השפות שרוצים לעבוד איתן. צריך לוודא שיש לכם את הקומפיילרים או הכלים שנדרשים לשפות שבחרתם (לדוגמה, כלי dotnet ל-C#, כלי javac ל-Java וכו').

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

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

משנים את ההנחיה הבאה בהתאם לסביבה שלכם ומריצים אותה:

I have [C#, Python, Go, Java, Node.js] setup locally. 
Run the unit tests for services in these languages 
in parallel subagents and report back in a clean markdown 
on their pass/fail status.

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

a3c1834909975020.png

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

e8ce8e16f195ea8c.png

5. תכנון הביקורת

תוכנית

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

כדי להבטיח פיקוח אנושי (Human-in-the-loop), המתאם יכתוב את התוכנית לארטיפקט ויושהה מיד כדי שתוכלו לבדוק אותה.

כדי ליצור תוכנית ביקורת, אפשר לנסות את ההנחיה הבאה:

We want to audit these microservices for code quality, 
exception handling and database query formatting standards 
for the languages I have set up locally. Design an audit plan 
detailing what you will check and save it as an Audit Plan artifact.
Do not execute the audit yet. Stop after writing the plan and wait
for my instructions.

בצ'אט אמור להופיע ארטיפקט של תוכנית ביקורת:

a7eb6b75b28fd788.png

בדיקה

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

לוחצים על תוכנית הביקורת שנוצרה ורואים את התוכנית המפורטת:

9b36c0ca827fdc53.png

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

6. ביצוע הביקורת

ביצוע

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

הנה ההנחיה שכדאי לנסות:

Execute the audit plan by spawning the parallel language subagents.
Once they finish scanning, collect their findings into an audit 
report artifact, sorted by language and then priority. Include the 
file paths, line ranges, snippets, and explanation of why it is a 
finding. Stop after writing the report.

אמורים להופיע שוב כמה נציגים:

9c282924eb33cc34.png

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

6706295f5cf7292b.png

בדיקה

אחרי שפותחים את דוח הביקורת, אמורים לראות גם ממצאים מפורטים לכל שפה. לדוגמה, הנה בעיה בעדיפות גבוהה מ-cartservice ב-C#:

aca90d0da393bffc.png

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

7. תיקון

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

יש כמה דרכים לנסות לעשות את זה:

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

נשתמש בגישה השמרנית יותר מספר 3 עם ההנחיה הבאה:

Select the top high-priority finding in [pick a language, e.g., C#]
and remediate the finding. Show me the code changes once complete.

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

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

9e79c7bb1e102aee.png

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

8. אימות

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

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

מריצים את ההנחיה הבאה:

Rerun the unit tests for the changed language. If they pass, rerun
the relevant audit agent to check if the finding is resolved. If it 
is resolved, mark the issue as resolved in the audit report.

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

36ac20baa92d1602.png

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

9. מזל טוב

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

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

מסקנות עיקריות

  • מקביליות מתואמת: למדתם איך להפיץ ביקורות ובדיקות בין סוכני משנה עצמאיים שפועלים במקביל בשפות ספציפיות, כדי להימנע מפקקים בבדיקה ליניארית.
  • Human-in-the-Loop: בדקתם את תוכנית הביקורת שנוצרה והוספתם לה הערות לפני ההפעלה, וכך שמרתם על פיקוח על פעולות אוטונומיות.
  • תיקון ואימות אוטומטיים: ראיתם איך סוכני AI יכולים לא רק לאבחן אי-התאמות באיכות הקוד, אלא גם לשנות את הקוד ולאמת את השינויים שלהם באמצעות חבילות בדיקה מקומיות.