סיכום

SLAtech LTD היא חברת פיתוח תוכנה ישראלית הפועלת מאז 2004. אנחנו עוזרים לצוותים ולבעלי מוצרים שהקוד שלהם נכתב עם GitHub Copilot: בודקים ארכיטקטורה, אבטחה ובדיקות, את כללי המאגר ואת אופן הבדיקה של שינויי הסוכן, מביאים את הפרויקט ל-production וממשיכים לפתח אותו. הקוד נשאר במאגר שלכם. אנשים קובעים את הארכיטקטורה ומקבלים את ההחלטות, וה-AI רק מציע.

פרויקטים ב-GitHub Copilot

פרויקט ב-GitHub Copilot נתקע? נבדוק, נתקן ונביא אותו ל-production

GitHub Copilot משולב במקום שבו הצוות כבר עובד: מציע קוד בעורך, מבצע משימות במצב סוכן, וה-coding agent לוקח בעצמו משימה מ-GitHub ופותח טיוטת pull request. הקושי מתחיל כשיש יותר קוד מ-Copilot ממה שהצוות מספיק לקרוא בעיון. מקבלים הצעות בלי להסתכל, כותבים לסוכן משימות בשתי שורות, וגם את בדיקת השינויים משאירים ל-Copilot. אנחנו בודקים פרויקטים ב-GitHub Copilot, ממשיכים את הפיתוח שלהם או כותבים מחדש את מה שלא כדאי לתקן. על מה שתיקנו אנחנו, אנחנו גם אחראים בהמשך.

מה GitHub Copilot עושה טוב

עובד בתוך GitHub והעורך. משימות, ענפים, pull request ובדיקות נשארים איפה שהיו.

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

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

בדיקת קוד אוטומטית. Copilot יכול להשאיר הערות ל-pull request.

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

איפה פרויקטים ב-GitHub Copilot בדרך כלל נתקעים

הצעות שהתקבלו בלי להסתכל

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

משימה בשתי שורות

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

Copilot בודק את Copilot

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

בדיקות מאותו כותב

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

הגנת ענפים לא בכל מקום

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

תלויות מיותרות ומומצאות

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

מה אנחנו בודקים בפרויקט ב-GitHub Copilot

1

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

2

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

3

ארכיטקטורה: איפה יושבת כל לוגיקה ואיפה היא חוזרת על עצמה.

4

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

5

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

6

תלויות: ספריות מיותרות, ישנות ופגיעות.

7

מפתחות וסודות: בקוד, בהיסטוריית השינויים, בהגדרות GitHub Actions.

8

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

9

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

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

שלוש דרכים להמשיך

אבחון

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

עוד על האבחון

המשך פיתוח

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

לדבר על המשך פיתוח

כתיבה מחדש של חלק

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

לדבר על כתיבה מחדש

איך אנחנו בוחרים בין הדרכים האלה, מוסבר בפירוט בעמוד על עזרה לפרויקטים ב-vibe coding.

איך אנחנו עצמנו עובדים עם AI

GitHub Copilot מציע קוד ויכול לבצע משימה בעצמו ולפתוח pull request. אנחנו עובדים אחרת. בפרויקטים של לקוחות, אנשים קובעים את הארכיטקטורה ומקבלים את ההחלטות. ה-AI מציע פתרון למשימה שאדם הגדיר, ואנחנו מכניסים אותו לפרויקט בעצמנו, אחרי בדיקה. סוכן ה-AI לא מקבל גישה לקוד, למסדי נתונים, למפתחות ולסיסמאות, ואין בקוד אף שורה שאדם לא יודע עליה.

שאלות נפוצות

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

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

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

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

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

כלי AI נוספים

עם פרויקטים בכלים אחרים אנחנו עובדים באותה דרך. העמוד הכללי: עזרה לפרויקטים ב-vibe coding.

ספרו לנו מה בניתם ב-GitHub Copilot

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