CodeBuddy NPC הופך את ה-Git למרחב העבודה של סוכני AI

לא עוד עוזר ליד המאגר — אלא משתתף בתוכו

הרעיון המרכזי של CodeBuddy NPC הוא להפוך את ה-AI למשתתף מזוהה, מורשה ומונע-אירועים במערכת הפיתוח הקיימת המבוססת על Git — ולא לכלי צ'אט שפועל לצדה. מפתח יכול לזמן תפקיד AI באמצעות אזכור @ ב-Issue או ב-Pull Request ‏(PR), והסוכן מתקדם באופן אסינכרוני בלולאה של חקירה, תכנון, מימוש, פתיחת PR, אימות CI, תיקון כשלים ואימות מחדש. 16

Git כזיכרון העבודה המתמשך

במודל AI Native Git, המאגר אינו רק המקום שבו נשמר הקוד. היסטוריית הקוד, ה-Issues, ה-PRs, תוצאות ה-CI/CD ושערי האיכות משמשים כהקשר העבודה המתמשך של הסוכן. במקום להעתיק ידנית דרישות, קטעי קוד ולוגים של בנייה אל תוך עוזר AI, ה-NPC פועל דרך אותם פריטים וממשיך את תהליך העבודה שהצוות כבר מנהל. 17

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

תפקידי AI שמוגדרים במאגר

CNB מאפשרת להגדיר תפקידי NPC ייחודיים למאגר בקובץ .cnb/settings.yml. ההגדרה יכולה לכלול שם תפקיד, הנחיה (prompt), ייבוא של בסיסי ידע ואפשרויות אינטראקציה. אירועי NPC המתועדים מופעלים כאשר תפקיד מוזכר ב-Issue או ב-PR; התנהגות מותאמת אישית של התפקיד יכולה להיות מוגדרת בקובץ .cnb.yml. 367

כך ניתן לחלק אחריות בין תפקידים שונים, למשל:

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

אפשר גם להפעיל כמה NPCs במקביל בעבודות גדולות יותר. אם לא הוגדרה צינורית אירוע מותאמת לתפקיד, CNB מציינת שימוש בסביבת ברירת מחדל של cnbcool/default-npc:latest. 6

לולאת מסירה אוטונומית, לא רק השלמת קוד

לאחר ההפעלה, CodeBuddy NPC יכול למשוך ולפרש את בסיס הקוד, לגבש דרך פעולה, לכתוב קוד, לפתוח PR, להריץ בדיקות, לבדוק כשלי CI ולבצע איטרציות של תיקון עד שהעבודה מגיעה למצב מוכן לאישור. מכיוון שהתהליך אסינכרוני, המפתח אינו חייב להישאר לאורך כל ההרצה בתוך שיחת צ'אט פעילה. 17

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

CNB כשכבת הרצה, הרשאות ובקרה

מתחת לסוכן פועלת CNB, המספקת אירוח Git, צינורות CI/CD, מאגרי ארטיפקטים וסביבות פיתוח ענניות. YAML של צינור יכול להגדיר, בין השאר, תמונות Docker, תמונות זמניות שנבנות מ-Dockerfile, ‏dev containers, נפחים (volumes), מריצים עם תגי CPU ומטמון Docker חוזר. כך אפשר להריץ בנייה ובדיקות בסביבות מבודדות וחוזרות, במקום להסתמך על המחשב המקומי של מפתח. 54

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

עקיבות אינה מבטלת פיקוח אנושי

כאשר המשימה מתחילה ב-Issue או ב-PR, נרשמת באמצעות commits ו-PRs ונבדקת בצינורות ובשערי איכות, הארגון שומר על עקבות הביקורת ההנדסיות המוכרות. תיעוד ה-Keystore של CNB מתאר גם בקרות גישה, מגבלות פעולה, יומני ביקורת וסימוני מים להגנה על מידע רגיש. 19

גם הטענה לחיסכון בעלויות קשורה לאופן ההפעלה: טנסנט מייחסת ירידה בצריכת הטוקנים בפנייה הראשונה — מיותר מ-20,000 לכ-2,000, ירידה של מעל 90% — לאופטימיזציה מתמשכת של הנחיות, קריאות לכלים, פלט CLI ושיעור פגיעות מטמון. היא מתארת גם בחירת אסטרטגיית מודל לפי מורכבות המשימה, במקום להפעיל יכולת יקרה באותה רמה לכל עבודה. 811

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