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

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

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

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

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

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

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

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

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

8. גיוס ג'וניורים - הדגש הוא על מיומנויות רכות, מוטיבציה, חשיבה אנליטית, מוכנות ללמוד את הבסיס ויכולת ללמוד מה AI ולא לתת ל AI לכתוב במקומך. עדיף להתמקצע ב Vanilla JavaScript ולהכיר את העקרונות טוב מאשר ללמוד עוד Web Framework בלי להבין לעומק איך הוא בנוי.

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

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

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

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

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

מתכנתת חכמה מקבלת קוד מסורבל וחושבת-

"אני יודעת! אקח כל פעם מודול קטן ואממש אותו מחדש ב node.js, וכך לאט לאט אוכל לברוח מהמפלצת ולבנות מערכת קטנה ומודולרית".

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

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

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

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

הי חברים,

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

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

https://youtu.be/KvUVtKRs9EU?si=FJXSGtHBM91dkXwQ

וחלק שני מסביר איך להוסיף רכיבי ממשק משתמש לשרת ה MCP הזה כדי להפוך אותו לאפליקציה:

https://youtu.be/h0uQUfrv2oA?si=fz4e-pmM6uE7CxT6

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

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

https://github.com/ynonp/mcp-server-demo-deno

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

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

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

הנה כמה דוגמאות על מספרים:

3.3.5 :004 > 2 <=> 3
 => -1
3.3.5 :005 > 3 <=> 3
 => 0
3.3.5 :006 > 5 <=> 3
 => 1

ועל מחרוזות:

3.3.5 :011 > 'a' <=> 'b'
 => -1
3.3.5 :012 > 'b' <=> 'b'
 => 0
3.3.5 :013 > 'c' <=> 'b'
 => 1

במחרוזות "גדול מ..." אומר שהדבר נמצא אחרי הדבר השני בסדר מילוני.

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

3.3.5 :019 > [1, 2, 3] <=> [1, 5, 3]
 => -1

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

3.3.5 :023 > [major, minor, build] <=> [10, 4, 2]
 => 0

נ.ב. לפי ChatGPT אופרטור החללית עובדת בדיוק באותו אופן על מערכים גם ב PHP, C++, Groovy ו Elixir. בקלוז'ר הפונקציה compare אימצה את ההתנהגות וגם היא מטפלת במערכים באותה צורה.

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

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

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

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

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

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

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

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

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

1. קוד שלי - אמון הכי גבוה, אני רואה את הקוד ושולט בסביבת הריצה.

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

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

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

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

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

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

parseInt(...)
Math.floor(...)
Math.round(...)
Math.trunc(...)
``

הבדלים? נשים לב:

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

```language-javascript
ynonp@ynons-MacBook-Air ~/tmp $ node
> Math.trunc(4.5)
4
> Math.trunc(4.8)
4
> Math.trunc(-4.8)
-4
> Math.trunc(-4.2)
-4
> Math.trunc("4.9")
4
> Math.trunc("4.9a")
NaN
>

1. החברות שלה Math.round ו Math.floor מתנהגות דומה לגבי מחרוזות אבל ישנו לכם את המספר בשליליים או כשהמספר קרוב לקצה:

> Math.round(2.3)
2
> Math.round(2.8)
3
> Math.floor(4.2)
4
> Math.floor(4.8)
4
> Math.floor(-4.8)
-5
>

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

> parseInt(3.4)
3
> parseInt(-3.4)
-3
> parseInt(-3.8)
-3
> parseInt(3.8)
3
> parseInt("2 apples")
2

לכן הטיפ היום כשהופכים שבר למספר שלם ב JavaScript מומלץ להשתמש ב Math.trunc. הכי מהירה והכי מדויקת.

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

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

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

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

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

הבעיה שבן 5 לא יצליח לעשות את מה שצריך לעשות כדי להתקדם.

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

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