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

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

מהר מאוד הבנתי איזה Use Case ראיתי, ואיזה Use Case-ים פספסתי:

1. המחבת שלי היתה בדיוק בגודל שהתאים לארון. את המחבת הגדולה אין איפה לשים.

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

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

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

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

תגידו מה כן לעשות.

פקודת git checkout יודעת להדפיס לכם לעבור לגירסה החדשה יותר git switch, ואם חזרתם אחורה לקומיט גיט יכתוב לכם שאתם במצב detached head ותשימו לב להיזהר מהקומיט הבא.

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

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

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

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

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

במקום "אל תשכפל את אותו קוד ב-3 מקומות שונים" נכתוב "הוצא את הקוד המשותף לפונקציה".

וכן ברור שיותר קל לראות מה לא בסדר מלהמליץ מה כן לעשות. כדאי לזכור ש״לא להחליט״ זה פשוט לתת למישהו אחר (אולי פחות מוכשר) להחליט בשבילנו.

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

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

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

• אין בעיה לתת לסוכן קידוד לרוץ על הקוד. במקרה הגרוע נכתוב git restore ו git clean והכל יחזור למה שהיה. הוא לא יכול להרוס כלום.

• אין בעיה להריץ לינוקס בתוך מכונה וירטואלית. זה לא מסוכן. במקרה הגרוע תהרוס את המכונה הוירטואלית לא את המחשב שלך.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. גוגל מחלקת את Gemini בחינם, גם פלאש, גם פרו וגם אפשרות לצפיה בסרטים מיוטיוב. חוץ מהם גם ב Open Router אפשר למצוא לא מעט מודלים בחינם וגם גיטהאב מחלקים מודלים בחינם (למרות ששם יש Rate Limit קשוח).

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

https://www.youtube.com/watch?v=YtHdaXuOAks

1. גם כלי הפיתוח Gemini CLI מחולק בחינם כולל השאילתות, עד אלף בקשות ביום.

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

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

איך יראה הפורטפוליו הבא שלכם? איך מתבלטים בתוך כל הרעש? ומתי אתם מתכננים להתחיל ללמוד את כל הכלים החדשים?

מבין השלושה רק האחרון הוא בחירה ולכן רק האחרון הוא קשה.

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

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

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

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

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

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

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

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

1. הוסף למסך הפרופיל שדה חדש עבור כתובת. (במערכת שכבר יש בה מסך פרופיל ו flow של עריכה ושדות שנשמרים מתוך הפרופיל בבסיס הנתונים ומנגנון מתועד לעדכון הסכימה בבסיס הנתונים).

2. הוסף למסך הפרופיל שדה חדש עבור תמונת משתמש. יש לשמור את התמונה ב base64 בבסיס הנתונים.

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

4. הוסף כפתור למסך הניהול שמאפס למשתמש את הסיסמה (בהנחה שכבר יש פונקציה לאיפוס סיסמה במערכת).

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

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

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

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

אוהבים את המחיר של Github Copilot ואת מצב הסוכן שלהם, אבל אין לכם כח לצאת מהטרמינל? בין כל הרעש של כלי AI מצאתי היום אחד ממש קסום לשתף. הוא נקרא opencode ואלה התכונות שאני הכי אהבתי:

1. מתחבר לקופיילוט כך שאפשר להשתמש בחשבון 10$ בחודש הקיים שלכם בשביל המודלים (ויכול גם להתחבר ל ollama אם יש לכם מודל מקומי או ל Open Router או ל together ai עבור ערימה ענקית של מודלים בענן. וכן ברור שגם לכל המסחריים הרגילים).

2. עובד מהטרמינל בסגנון קלוד קוד או קודקס.

3. מתחבר ל vim בעזרת פלאגין:

https://github.com/NickvanDyke/opencode.nvim?tab=readme-ov-file

איך זה עובד? בינתיים מעולה:

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

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

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

4. אפשר לבטל את כל השינויים עם פקודת undo. מומלץ עדיין לשמור הכל ב git כשה AI יצר משהו שאתם אוהבים.

שני דברים שעדיין לא מצאתי (אולי עדיין אין) זה אינטגרציה אוטומטית עם גיט בסגנון aider שכל שינוי אוטומטית נכנס לקומיט ואפשרות לערוך הודעות ישנות כדי לנווט את השיחה לכיוון אחר. כן אפשר להשתמש ב undo עד שמגיעים להודעה הישנה שרוצים לערוך ואז לשנות אותה אבל זה קצת פחות נוח מכפתור העריכה של VS Code.

שימו לב לקלאס הבא מתוך דף תיעוד של openai שמתאר תשובה של סוכן שבודק אם ביקשו ממנו עזרה בשיעורי בית בחשבון:

class MathHomeworkOutput(BaseModel):
    is_math_homework: bool
    reasoning: str

guardrail_agent = Agent( 
    name="Guardrail check",
    instructions="Check if the user is asking you to do their math homework.",
    output_type=MathHomeworkOutput,
)

קוד הדוגמה המלא לא כולל שום התיחסות למידע שנכתב לתוך reasoning. כן הם בודקים אם is_math_homework הוא אמיתי, אבל reasoning? אף אחד לא מסתכל עליו.

אז למה הוא שם? שלוש סיבות חשובות שגם אני ראיתי בעבודה עם סוכנים:

1. מנגנון Structured Output עדיין לא עובד מספיק טוב. סוכנים לפעמים לא מצליחים להגיב בלי טקסט חופשי ולכן בקשות בלי שדה reasoning יכולות פשוט להיתקע.

2. אמינות - כשאני מבקש מ LLM הסבר למה הוא עשה משהו אני מקבל תשובות טובות ואמינות יותר.

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

וטיפ לסיום - נכון להיום Structured Output זה בדיוק דוגמה לפיצ'ר מסוג "חשיבה אופטימית" שממחיש את הפער בין ההייפ סביב AI לסיפור האמיתי שלהם ואת הקושי לפתור בעיות של LLM-ים באמצעות הנדסה. בשביל שזה יעבוד openai בנו שכבת retry בתוך ה API שלהם כך שכשאנחנו מבקשים מידע מובנה מה API בעצם OpenAI פונים למודל שוב ושוב עד שהוא מסכים להחזיר את המידע לפי המבנה שהעברנו. הפיתרון ההנדסי הזה נשמע טוב על הנייר אבל בינתיים הוא לא עובד, וכולם משתמשים בפיתחי מילוט כמו שדה reasoning (וגם זה לא תמיד עובד). יש לי כבר שתי מערכות שהוצאתי מ Structured Output והעברתי לקריאה רגילה לסוכן ופיענוח ידני של הפלט ובשתיהן המעבר שיפר משמעותית את התוצאות וגם איפשר לי לגוון במודלים.

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