תוספי AI ל-VS Code: פיתוח מלא עם אינטגרציה של LLM

פיתוח הרחבת AI ל-VSCode: מה נשבר בלעדיה

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

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

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

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

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

מה משתנה בעבודת הצוות אחרי הטמעת העוזר

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

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

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

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

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

מצבי עבודה של העוזר: מקומי, שרת עצמי, שירות חיצוני

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

מצב משולב

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

איך אנחנו מובילים הטמעה: שלבי עבודת הנדסה

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

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

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

ארטיפקטים ומדיניות גישה: מה נשאר אצל הצוות

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

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

מקרה בוחן: בדיקת קוד בצוות מבוזר

מה היה לפני ההטמעה

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

מה שינו

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

מה קרה לפי המטריקות

הזמן עד למשוב המשמעותי הראשון הצטמצם מ-26 שעות ל-40 דקות, מחזור הבדיקה המלא — מיומיים לשש שעות. שיעור ההחזרות לעבודה נוספת ירד מ-34% ל-11%, והבודקים עברו לשאלות ארכיטקטוניות: לוגיקה, גבולות שירותים, השפעה על מודולים סמוכים.

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

מה לעשות אם בחברה כבר יש שירות מודלים משלה?

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

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

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

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

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

שאלות ששואלים לפני תחילת הפרויקט

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

מה קורה עם מאגר הקוד הפנימי?

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

איך מתעדכנים כללי הפרויקט?

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

מה עם תחזוקה אחרי המסירה?

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

נדון במשימה: ממה מתחילה העבודה על העוזר

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

מה נדרש מהלקוח בקלט:

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

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

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