4 תשובות אמיתיות לשאלה: איך AI באמת משנה את תפקיד המפתחים?

אימוץ של AI בפיתוח דורש עיצוב מחדש של מבנה הצוותים, לולאת המשוב של ה-CI ותהליך ה-Evaluation של הסוכנים. הנה 4 תובנות מהשטח

החלק הקשה מתחיל אחרי כתיבת הקוד (צילום: Unsplash)

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

זוהי אחת המסקנות העיקריות שעלתה בסדרת המיטאפים האחרונה שלנו ב-Wix Engineering: מעבר אמיתי לפיתוח AI-Native לא נעצר בהוספת Coding Assistant, אלא דורש שינוי בתפקיד המפתחים, בתשתית הידע, באופן שבו מעניקים לסוכנים אוטונומיה ובדרך שבה מאמתים את התוצרים שאנחנו מקבלים מהם. הנה 4 שינויים עמוקים שמעצבים מחדש את עבודת הפיתוח בעידן ה-AI.

1. כשהקוד זול יותר, האחריות יקרה יותר

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

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

התשובה שלנו לאתגר הזה היא מודל xEngineer שהצגנו השנה. לא מדובר ב-Full-Stack Generalist שיודע מעט מכל דבר, אלא במהנדס Design-First: מפתח או מפתחת ששומרים על עומק מקצועי אמיתי בדומיין או בסטאק הליבה שלהם, אבל יודעים להשתמש ב-AI בשביל להרחיב את טווח הפעולה ולקחת אחריות מקצה לקצה.

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

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

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

(יניב אבן-חיים, אבירן מורדו ואסף יונאי)

2. קונטקסט הוא תשתית, לא פרומפט

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

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

• הקשר קבוע – כגון מבנה הפרויקט, פקודות Build ו-Test וכללי העבודה
• הקשר משימתי – כגון הטיקט, הקוד והתיעוד הרלוונטיים
• הקשר תפעולי שמגיע מסביבת הייצור ומסביר מה קרה בפועל

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

Context Engineering הוא לא כתיבה של פרומפט ארוך (צילום: Unsplash)

האתגר הוא לספק את המידע הנכון, בזמן הנכון וברמת הפירוט המתאימה. כאן נכנס לתמונה Octocode – כלי מחקר וסריקת קוד מבוסס בינה מלאכותית שהופך קוד מקומי, GitHub וחבילות npm למרחב מחקר שסוכני AI יכולים לנווט בו. במקום להזין למודל את כל בסיס הקוד, הסוכן מחפש מידע, עוקב אחר פונקציות ותלויות ופותח רק את הקבצים הנחוצים. ה-MCP מספק את כלי המחקר, ה-Skills מגדירים תהליכים כמו מחקר טכנולוגי או סקירת Pull Request, וה-Sub-Agents יכולים לחקור במקביל מקורות וכיוונים שונים ולהחזיר סיכום ממוקד.

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

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

(גיא ברי וישראל זבליאנוב)

3. אוטונומיה בלי Evaluation היא הימור

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

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

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

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

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

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

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

(דרור ארזי ואור גולדרייך)

4. ה-CI צריך להפוך משער בסוף התהליך ללולאת משוב

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

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

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

הפרודקט, הפיתוח וה-QA לא מעבירים ביניהם מסמכים מנותקים, אלא בונים מערכת הקשר משותפת (צילום: Unsplash)

הפתרון הוא Progressive Disclosure. בגישה הזו, קובץ ה-‏AGENTS.md צריך לשמש כמפה: להסביר לסוכן באיזה עולם הוא נמצא, מהם כללי היסוד והיכן נמצא המידע הנוסף. תהליכים מפורטים עוברים ל-Skills שנטענים רק כשהמשימה דורשת אותם. ככה אפשר לשמור על הקשר התחלתי קטן, באופן שמאפשר לסוכן להגיע לעומק הנדרש.

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

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

(אור רוזנצוויג ושניר שרישט)

החלק הקשה מתחיל אחרי כתיבת הקוד

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

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

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