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

נתחיל בעובדות. אפשר לחבר לקלוד שרתי MCP שרצים ברשת דרך מסך ה Connectors בקישור הזה:

https://claude.ai/customize/connectors

אחרי שחיברתם שרת MCP שנקרא שם Connector עליכם לבחור שם לחיבור. אם תבחרו שם בעברית קלוד ישמור את החיבור אבל לא יוכל להגיע לכלים על שרת ה MCP הזה. הוא יגיד לכם משהו כמו "אני רואה שיש חיבור לשרת MCP שביקשת אבל הכלים לא נגישים עבורי בשיחה זו", ואז הוא מציע רשימה של דברים לא קשורים שצריך לבדוק.

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

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

1. מישהו כתב איפיון לא מספיק מדויק.

2. סוכן קידוד השלים את הפערים תוך התבססות על הנחת עבודה לא נכונה (שם חייב להיות ASCII תקני).

3. אנשי QA פספסו את הבעיה כשבדקו את המערכת באוויר.

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

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

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

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

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

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

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

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

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

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

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

https://github.com/ynonp/fable-coloring-app

נשים לב-

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

const circlePath = (cx: number, cy: number, r: number) =>
  `M ${cx + r} ${cy} a ${r} ${r} 0 1 1 ${-2 * r} 0 a ${r} ${r} 0 1 1 ${2 * r} 0 Z`;

זה נפלא עד שנזכרים שב SVG יש כבר circle שהיה עובד יותר טוב לבד. עכשיו אני מבין למה הוא כתב את זה ככה - היתה לו אבסטרקציה גרועה שהוא יצר (הפונקציה R שם אם תכנסו להסתכל על הקוד) והוא המשיך איתה את כל התוכנית.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. חפשו מבנה פרויקט שלא מתאים לקוד שרציתם. קובץ אחד איפה שהיה צריך להפריד לכמה קבצים, כל הפונקציות במקום אחד במקום פונקציה בכל קובץ, עיצוב ב CSS במקום בטיילווינד (או בלוק style במקום קובץ CSS). כל פער כזה זו הזדמנות - נוסיף אותו לפרומפט או לקובץ פרומפט קבוע כמו AGENTS.md כדי לשפר את כל הקוד העתידי שניצור.

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

חבר מקשה - "לכתוב קוד היום זה משעמם. אתה רק מבקש משהו מה AI ויש לך את הקוד. עבודה שפעם לקחה זמן וחשיבה היום עושים כלאחר יד. זה לא מעניין".

אז שאלתי בחזרה - "נו אז מה כתבת מעניין עם ה AI"?.

שתיקה.

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

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

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

אבל שווה להכיר גם ש 50-70% מהעובדים בחברות לא מנצלים את תקציב הטוקנים שלהם. לא משתמשים בסוכני קידוד כדי להתקדם במהירות שהמנהלים שלהם רוצים שהם יתקדמו. הם אולי נוסעים באוטו אבל עדיין במהירות 15 קמ"ש.

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

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

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

התכונות הטובות של Repid כוללות:

1. משימות אסינכרוניות (כמובן, בשביל זה באנו).

2. תמיכה טובה בבדיקות עם רכיב TestClient.

3. תיעוד ידידותי לסוכנים עם קבצי llms.txt ו llms-full.txt.

4. חיבור מובנה ל pydantic בשביל הגדרת טיפוסים.

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

שילוב 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 כותב קוד כל כך מהר שאף אחד אפילו לא מרגיש שצריך יותר קוד בשביל לפתור בעיה. אבל - אנחנו כן נרגיש כשהפונקציונאליות של המערכת נשברת ופיצ'ר לא פותר את כל הבעיה, בעזרת קבצי תיעוד אפשר להישאר עם קוד משוכפל ולקבל תוצאות טובות וכשנרצה ליצור אבסטרקציה המעבר מקוד משוכפל לאבסטרקציה יהיה מאוד קל בזכות סוכן הקידוד.