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

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

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

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

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

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

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

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

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

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

https://claude.ai/share/87cbabb1-608f-4375-b37c-b6f659b9bba4

אלה הנקודות המרכזיות שאני העליתי:

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

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

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

בסוף השיחה קלוד הסביר את זה מאוד יפה:

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

2. הרבה מהיכולות ממומשות ברמת ה Harness ולא ברמת המודל. קלוד קוד הוא חלק מהמוצר שלנו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

את הדוח עצמו אפשר למצוא כאן: https://www.taasuka.gov.il/media/oauod4pb/hitech_report.pdf

הוא מרתק ומלא בנתונים אבל הנתון היחיד שעניין אותי לא היה שם. מצאתי אותו בסקירה הזו של דה מרקר (דורש מנוי לקריאה):

https://www.themarker.com/career/2026-07-07/ty-article/.premium/0000019f-377d-d07c-af9f-ff7dcc840000?fromLogin=success

זה המשפט:

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

או בעברית יש היום יותר משרות טק פנויות מאשר דורשי עבודה.

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

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

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

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

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

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

בפרק האחרון של rework דייויד הנסן מדבר על פיתוח משולב AI ב 37 Signals.

https://37signals.com/podcast/ai-challenges-in-software/

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

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

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

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

4. אם תתנו ל AI לכתוב קוד ללא השגחה התוצאה תהיה בלאגן. או במילים של DHH:

The problem is if you just keep doing that, if you keep asking the monkeypaw for more wishes, you’re going to get a distorted code base.

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

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

נתחיל בעובדות. אפשר לחבר לקלוד שרתי 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 מוכרת זמן עבודה של שרת. והמפתחים? מתבלבלים.