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

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

ועכשיו היא הגיעה לקוד.

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

כמה תובנות להשאיר בראש:

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

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

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

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

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

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

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

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

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

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

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

1. בקשו מ AI לייצר Security Review על קוד והוא בטוח ימצא דברים. לפעמים הדברים האלה הם בעיות אבטחה אמיתיות בקוד (במיוחד אם זה בעיות מאוד בולטות), לפעמים זה פשוט Best Practices שלא לקחת ולפעמים זה פשוט קוד שנראה קצת חשוד או לא שגרתי. כן אני יכול להשתמש ב AI כדי לקבל כיוון ולהציף דברים שיכולים להיות בעייתיים, אבל בשום אופן לא הייתי נותן לו להחליט איזה בעיית אבטחה היא אמיתית ודורשת תיקון ואיזה רק נראית כמו בעיה.

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

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

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

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

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

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

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

אז מה בכל זאת היו הבעיות ולמה אני לא מתכנן להמשיך איתו?

1. נרשמתי למסלול של ה 20$ בחודש וסיימתי אותו ב-3 ימים. הבנתי שיש מסלול יותר מתקדם של 100$ בחודש שאמור להספיק לכל החודש אבל זה פי 10 מקופיילוט ופי 5 מקרסר.

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

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

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

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

https://www.tocode.co.il/talking_ai

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

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

new Array(100).fill(0).map(i => Math.floor(Math.random() * 100)).find(p => p > 50)

אבל עדיין יש פה משהו צורם בקוד - בשביל מה היית צריך להמשיך להגריל מספרים אחרי שמצאת את הראשון שגדול מ-50? כתיב השורה אחת צריך לעבוד יותר קשה מכתיב הלולאה המקביל:

for (let i=0; i < 100; i++) {
  const r = Math.floor(Math.random() * 100)
  if (r > 50) { console.log(r); break; }
}

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

1. הפונקציה values של מערך מחזירה איטרטור.
2. לאיטרטור יש פונקציות כמו map, filter, take, drop שמשפיעות על מהלך האיטרציה.
3. לאיטרטור יש פונקציית next שמחזירה את הערך הבא ממנו.

ולכן הלולאה נראית כך:

new Array(100).values().map(() => Math.floor(Math.random() * 100)).filter(i => i > 50).take(1).next().value

שורה אחת, מגרילה עד 100 מספרים ומחזירה את הראשון שגדול מ-50.

ואם אני רוצה את ה-3 מספרים הראשונים שגדולים מ-50? אין שום בעיה פשוט נשתמש ב toArray במקום ב next:

new Array(100).values().map(() => Math.floor(Math.random() * 100)).filter(i => i > 50).take(3).toArray()

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

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator

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

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

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

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

2. קצב מהיר זה ה Vibe Coding, ה Agent Mode, ה Yolo. כמה Issues אני מצליח לפתור בשעה, קומיט אחרי קומיט, ריכוז גבוה, אנדרנלין, מצב Flow, זזים מהר ושוברים דברים.

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

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

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

1. מי יכול להריץ את שרת ה MCP? שרתי MCP יכולים לרוץ בתור סקריפט מקומי (דרך stdio) או בתור שרת HTTP. מסתבר שבתור שרת HTTP שרתים רבים מאזינים לכתובת 0.0.0.0 מה שהופך אותם לנגישים לכל המכונות ברשת ולא רק לקופיילוט שרץ אצלכם ב VS Code.

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

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

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

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

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

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

$ lumen draft

ומקבלים הודעת קומיט בשורת הפקודה. בשביל להתקין מריצים:

$ brew install jnsahaj/lumen/lumen

אבל עכשיו שיש לנו אותו נוכל לחבר אותו לגיט עם alias כדי שלא נצטרך ללמוד פקודות חדשות. אני שומר את הסקריפט הבא בקובץ ~/bin/git-aicommit.sh:

    #!/bin/sh

    # Generate AI commit message
    DRAFT_MSG=$(lumen draft)

    if [ -z "$DRAFT_MSG" ]; then
        echo "❌ lumen draft returned no output. Aborting."
        exit 1
    fi

    # Use Git's message template mechanism
    git commit --edit -m "$DRAFT_MSG"

נותן הרשאות הרצה:

chmod +x ~/bin/git-aicommit.sh

ומגדיר את ה alias:

git config --global alias.aicommit '!sh ~/bin/git-aicommit.sh'

ועכשיו אפשר לכתוב משורת הפקודה:

$ git aicommit

מקבלים הודעת קומיט מה AI לתוך העורך, אפשר להוסיף או להתאים אותה לפי הידע שלכם, לשמור ולהתקדם.

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

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

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

def count_lines(fp: typing.IO):

לפונקציה הזו:

def count_lines(fp: str):

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

במקביל אני מופתע לגלות שגם בשפות שלא כוללות Type Hints אני מקבל מימושים טובים וכמעט בלי בעיות טיפוסים. ב langlets יש לי כבר כ 2,500 שורות JavaScript וה AI מצליח להתמודד עם זה בלי טעויות. ב Ruby של הפרויקט הוא כן טועה אבל בעיקר כשאני כותב קוד מבלבל.

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

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

2. החלפת מפתחים בצוות (שגורמת לשינוי בסטנדרטים).

3. אינטגרציה בין מערכות.

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

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

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

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

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

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

https://tocode.ravpage.co.il/tocodeai

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

https://www.tocode.co.il/blog/2025-04-mcp-intro

נתראה בחמישי בבוקר.