הבלוג של ינון פרק

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

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

2. בסיסי נתונים - מפתחות זרים ו Sequence-ים בבסיסי נתונים מבינים למצב שקשה לי מאוד לשנות היסטוריה אחרי שהיא קרתה. בעתיד אנחנו נצטרך למצוא דרך להוציא "ענף" מגרסה ישנה של בסיס הנתונים ולהלביש את הנתונים החדשים על השינוי שנבצע בהיסטוריה.

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

המשמעות של להוציא את המפתחים מהלופ ולוותר על צוואר הבקבוק של Code Reviews היא היכולת להתחרט ולתקן טעויות של סוכנים. גיט הומצא במקרה ב 2005. הענן של AWS הוקם ב 2002. טרפורם ב 2014. אין סיבה להניח שהכלים האלה יישארו איתנו לעד.

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

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

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

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

2. הזמן עובר ונכנסת דרישה חדשה למערכת.

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

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

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

אגב התרחיש המקורי ממנו מפתח A ניסה להתגונן היה:

1. הזמן עובר ונכנסת דרישה חדשה למערכת.

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

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

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

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

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

ואת כל זה צריך להכפיל פי 10 כי סוכני קידוד כותבים הרבה יותר קוד הרבה יותר מהר מבני אדם.

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

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

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

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

https://github.com/ynonp/langlets-rails/blob/main/docs/video-player.md

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

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

ספריית פיתוח הסוכנים Pydantic AI היא משב רוח מרענן של פשטות. היא מזכירה את OpenAI Agents SDK האהובה עליי רק בלי החיבור ל OpenAI ועם הרבה יותר שליטה בפרמטרים של המודלים. העבודה איתה בהחלט יכולה להרגיש כמו מישהו שהבין מה ש OpenAI ניסו לעשות עם Agents SDK ופשוט המשיך עם זה.

אפשר לקרוא את התיעוד המלא ודוגמאות שלהם כאן:

https://pydantic.dev/docs/ai/overview/

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

ההבטחה של Spec Driven Development היא פשוטה - במקום לכתוב ולקרוא קוד נעבור לכתוב ולקרוא איפיונים. במאמר ארוך בנושא ראיתי את ההמלצה הבאה:

Don’t kill the code reviews; just move the human checkpoint upstream to reviewing intent, specs, plans, constraints, and acceptance criteria. Code is actually the least important part of the reviews.

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

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

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

דוגמה קטנה מ langlets - ביקשתי מהסוכן פיצ'ר שכשלוחצים על מילה בטקסט יקפוץ פופאפ עם התרגום שלה. הסוכן הוסיף onclick על המילה אבל בגלל שמדובר ב JavaScript רגיל (לא ריאקט) בעמוד שהכיל הרבה טקסט נוצרו המון Event Handlers. לכל מילה היה את ה onclick שלה.

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

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

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

בין 2015 ל 2018 לימדתי קורסים בפיתוח Web ו Mobile Web. למרות שאנגולר יצאה לשוק כבר ב 2010 וריאקט ב 2013, רק באזור 2015 הטכנולוגיות האלה הבשילו ושינו את שוק העבודה. באותן שנים פגשתי המון מפתחי PHP ו jQuery שידעו הרבה יותר ממני על דפדפנים ובמיוחד על דפדפנים ישנים ובכל זאת התקשו למצוא עבודה.

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

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

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

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

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

2. המפתחים של העתיד יהיו הרבה יותר טובים בלקרוא קוד ויהיו הרבה יותר רגישים כשהקוד לא תואם לתבניות ול Best Practices שהם הכתיבו.

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

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

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

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

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

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

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

בכלי שורת הפקודה זה די פשוט. הפקודה neon projects list מחזירה את כל הפרויקטים בתור טבלה. אני יכול להוסיף --output json כדי לקבל את הפלט בתור JSON ואז אפשר לחבר אליו כלי כמו jq כדי להריץ שאילתה ספציפית. אז אם אני מחפש האם קיים פרויקט בשם goomba אוכל להריץ:

neon projects list --output json | jq '.projects[] | select(.name == "goomba") | {id, name}'

התוצאה - אם יש כזה פרויקט נקבל JSON קטן עם ה id וה name של הפרויקט. אם אין יגיע פלט ריק.

ומה קורה ב MCP? הבעיה ב MCP היא שאין לי אופציה להעביר את הפלט לכלי נוסף כמו jq. ב MCP בשביל לענות על השאלה אני מפעיל את כלי רשימת הפרויקטים וצריך להעביר ל AI את כל הרשימה כדי להבין אם יש או אין פרויקט בשם מסוים. תיאורטית הפעלה של הפקודה מה CLI אמורה לחסוך טוקנים - במקום להכניס ל AI את כל הפרויקטים הוא יפעיל את הפקודה ויקבל רק את הפרטים של הפרויקט שאני מחפש.

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

use neon MCP and check if I have a project named goomba

התשובה שאין כזה עלתה 4.9 קרדיטים (כי ככה הם קוראים לטוקנים בקופיילוט היום).

בשיחה שניה ביקשתי:

use neon CLI tool and check if I have a project named goomba

קלוד בתוך הקופיילוט לא התרגש מהבקשה וענה:

The user wants to use the Neon CLI tool to check if they have a project named "goomba". Let me search for the Neon MCP tool that's configured in their workspace.

Looking at the mcp.json file, they have a Neon MCP server configured at https://mcp.neon.tech/mcp. Let me search for tools related to Neon.

לאחר מכן הוא הצליח למצוא כלי בשם neonctl והפעיל אותו כדי לקבל את כל רשימת הפרויקטים בתור טבלה וסיים עם ההודעה שאין לי כזה פרויקט והחיפוש עלה לי 4.7 קרדיטים - קצת פחות מה MCP אבל עדיין לא סיבה למסיבה.

בואו ננסה לעזור לו. כתבתי את הפרומפט הבא:

use neon CLI tool (called neon, it's already installed) and check if I have a project named goomba
  The CLI tool has --output json flag to get output as JSON. It returns an {"projects": [{"name": ...}, { ... }]}
  can use 'jq' to focus your query

הפעם הוא הריץ את הפקודה הנכונה:

neon projects list --output json | jq '.projects[] | select(.name == "goomba")'

והחזיר את התשובה שאין פרויקט במחיר מבצע של 3.8 קרדיטים בלבד, קרדיט שלם פחות ממה שעלה החיפוש דרך ה MCP או ירידה של 22% בעלות.

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

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

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

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

https://github.com/ynonp/webinar-demo-coloring-app

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