YUV.AI - בינה מלאכותית בעברית

עדכון לכל מי שרכש\ה כרטיס לכנס ה-AI שלי: לפני כמה דקות הפצתי במייל את הפרטים (נשלח דרך מערכת רב מסר) בראש ובראשונה - ברצוני להודות לשותפיי לאירוע: שותפים בדרגת יהלום - חברת Amazon Web Services (AWS) Amazon Web Services (AWS) שותפים בדרגת זהב - החברות eBay, Microsoft, Bit Cloud eBay Microsoft Bit שותפים נוספים - GitHub, Base44, AT&T, NeuronVision להלן פרטי האירוע תאריך: 30.6.2025 שעות: 09:00-16:00 מיקום: מרכז ענב לתרבות, תל-אביב (חניה עצמאית בתשלום ברחבי המתחם) כשרות: המזון שיוגש באירוע הינו כשר חלבי לוח הזמנים המשוער לאירוע ויתר הפרטים - אצלכם במייל. בעזרת השם נתראה בקרוב, יובל

קבלו את StagewiseAI: תוסף שמשתלט על סביבת הפיתוח ועוזר לשנות אלמנטים בעיצוב על ידי בחירת העיצוב והזנת פרומפט לסוכן הקוד בצורה אוטומטית! נחשפתי לזה בפוסט המעולה של Elad Cohen האדיר והנדיר, וגם בהתייחסות של אברהם יצחק מאיר הגאון וגם בקהילות המדהימות שלי בקבוצת הדיונים ובקבוצת ה-Vibe Coding החדשה, וכפי שהבטחתי, אני קודם לוקח לסיבוב בעצמי ורק אח"כ מפרסם במידה ומצאתי ערך. וכאן לגמרי מצאתי ערך, אהבתי את זה מאוד וממליץ בחום לנסות! צפו בסקירה שלי ובעוד כמה טיפים >>>

פעם ראיתם מודל LLM שעבר Fine Tune ללימודי גמרא? גם אני לא, ולכן התחלתי שיחה עם GPT על איך לאמן מודל כזה, מה ההבדל בין מודל "רגיל" לבין מודל "Reasoning" (היסק) ברמה הכי טכנית שיש? 1. מודל שפה "רגיל", במתכונתו הראשונית ביותר, מתאמן על דאטה ויודע לבצע השלמה. Completion. דוגמא קלאסית היא לאמן מודל על כל הטקסטים של שייקספיר. ברגע שהמודל סיים להתאמן, אם ניתן לו פסקה - הוא ידע להשלים את מה שבא אח"כ. 2. לאחר שלב ההשלמה, במידה ואנחנו רוצים משהו קצת יותר מתקדם כמו מענה על שאלות של טקסטים, אנחנו יכולים לקחת את מודל הבסיס שאומן, ולהמשיך לאמן אותו, הפעם על דאטה של שאלות ותשובות. כך אנחנו "מכווננים" את המודל ומבצעים את ההתאמות הנדרשות כדי לשנות את האופי שלו, ולגרום לו להשיב לנו על שאלות ולא רק להשלים משפטים. זה אפשרי כי בשלב הזה אנחנו לוקחים דאטה של שאלות ותשובות, ועל זה המודל מתאמן. לכן כאשר הוא מקבל שאלה, הוא "מבין" איך הוא אמור להשיב עליה. גם כאן יש חיזוי של הטוקן הבא (או יותר קל להבין את זה כחיזוי של המילה הבאה. כמו לשאול שאלות על הטקסטים של שייקספיר ולא רק לקבל השלמות). הבעיה היא שכאשר שואלים שאלות על מידע שלא נמצא בדאטה של האימון, או שהוא כן נמצא אבל ביחס קטן מאוד לכל הדאטה, ככל הנראה נקבל תשובות עם הזיות. אם אנחנו רוצים שהמודל יהיה מאוד מדויק, אנחנו יכולים להשתמש בטכניקות שעוזרות להנגיש את הקונטקסט הרלוונטי למודל - ואז הוא ידע להשיב כמו שצריך. הנגשה של הקונטקסט הרלוונטי יכולה להתבצע באמצעות RAG. לוקחים מידע, מעבירים אותו תהליך, שומרים אותו, וכאשר שואלים שאלה, מייבאים את התשובות הפוטנציאליות, מצרפים אותן לפרומפט, ואז שואלים את ה-LLM, והוא משיב. אחלה. הדרך הנוספת לזה, היא לבצע "כוונון עדין" למודלים, Fine Tune. שזה אומר בא נקח דאטה של מה שאנחנו רוצים, ונשנה שוב את האופי של המודל. למשל, אם נקח את מודל הבסיס, שיודע להשיב על שאלות ותשובות, אבל נאמן אותו על דאטה של "שלבי פיתרון", או "תהליכי חשיבה", ולא רק שאלות ותשובות, וכמות הדאטה תהיה מספיק גדולה, והדאטה יהיה מעובד ומוכן לאימון כמו שצריך, אז ברגע שהאימון יסתיים, נקבל מודל שלא רק משיב על שאלות ותשובות, אלא גם מבין שיש שלבים עד לפיתרון, וכך בעצם לפני שהוא משיב, הוא "חושב", "מבין", "מסיק". המודלים האלה יקרים יותר, צורכים יותר כוח מחשוב, וזה לא שהם "חכמים" יותר אלא הם פשוט מיועדים למטרות אחרות של בעיות מורכבות. אם אתם רוצים שיר - אתם לא צריכים מודל חשיבה. אם אתם רוצים לפתור בעיה מורכבת - אתם לא רוצים מודל של שירים. ואם נרצה לקחת את זה שלב אחד קדימה - מה לגבי מודל חשיבה עמוקה של גמרא? למי שלא יודע\ת, לימוד גמרא (פרוטוקולים מהדיונים של חז"ל שכוללים המון חשיבה מעמיקה, פלפולי הלכות, סברות, לוגיקה והסקות מורכבות בשלל נושאים תורניים והלכתיים) דורש הבנה "כבדה". זה לא תחום לימוד קל. הוא מאוד מורכב, מצריך הבנה רצינית, ואסור שיהיו בו הזיות כשם שלהבדיל בחוק אסור פשוט להמציא חוקים ופסקי דין. זה מה שדיברתי עליו עם GPT, ומצויד בכל ההבנה הזו, שאלתי איך אפשר לאמן מודל בפועל על חשיבה של גמרא? והתשובה: מכינים דאטה סט גדול, ומפרקים את הסוגיות למבנה שמתאים לאימון מודלים. קושיא, תירוץ, נימוק, פירוט, ולאחר מכן מבצעים את האימון בפועל, ובמידה והדאטה יהיה מספיק איכותי וגדול, אנו אמורים לקבל מודל חשיבה עמוקה שמבוסס על הגמרא. אני לא יכול להגיד שאעשה את זה, כי זה תהליך מאוד מייגע, אבל מרתק להבין איך זה עובד מתחת למכסה המנוע.

אני מרגיש שאני עובר תהליך פנימי של הבשלה עם Vibe Coding. ממקום אבוד, מצאתי את נוסחת הקסם שעובדת לי ממש טוב, ואני חולק איתה אתכם. ככלל, קיימים 3 יוז קייסים שאני נתקל בהם: 1. פיתוח מוצר חדש מאפס 2. התחברות לסביבת פיתוח קיימת והוספת פיצ׳רים 3. התחברות לסביב פיתוח קיימת - וביצוע אופטימיזציות או מיגרציות (מעבר למסגרות פיתוח מתקדמות יותר) המכנה המשותף לכולם: אני צריך להבין מה הבעיה, איך לתכנן את הפיתרון, מה סביבת הפיתוח, באיזה טכנולוגיות משתמשים, איך. ארכיטקטורה בנויה - ומשם כל פעם אני בוחר את קטע הקונטקסט הרלוונטי בלבד בצ׳אט שלי עם קרסר, מפתח רכיב אחר רכיב, לאט לאט - וזה מה שגורם לי לטוס מהר. למדתי שכשאני רץ מהר אני בסוף חוזר להתחלה ומאבד המון זמן. וכשאני ״רץ לאט״ - אני בעצם ״טס בזכות האיטיות״. כדי להבין, מצאתי שיטה כיפית: אני מתחיל שיחה עם המודל הקולי של GPT ומשתף אותו בכל. הבעיה. הפיתרון. צולל איתו לטכני, תסביר לי את הקשרים בין הרכיבים, תסביר את הרעיון, במבט על. ואז צולל למכניקה. למה הזדהות כזו, איך מיושמת פונקציה כזו וכזו בקוד (למשל העלאת קבצים), ממש מנהל איתו שיחה ארוכה כדי להבין את כל ההקשר לפרטי פרטים. המטרה כאן היא כדי שאדע איך לצרף את הקונטקסט הכי רלוונטי לצ׳אט בקרסר. למה? כי אם אני מבין את מסגרת הפיתוח שלי מצוין (או את הקוד הקיים), אז אני יודע בדיוק איפה הרכיב של כל פיצ׳ר ובמקום לשאול שאלות כלליות שעולות המון טוקנים - אני ממקד את השאלה ומצרף את ההקשר וזה עובד מדהים. דוגמאות שעבדתי עליהן: - פיתוח מוצר מאפס עם NextJS - ביקשתי הסבר על נקסט, על המבנה, איפה כל פיצ׳ר נבנה, למה, ממש בניתי הבנה מקיפה, כנ״ל כשפיתחתי תוסף לוורדפרס או לכרום או ל- VSCode, רציתי להבין איך המבנה נראה, מה זה קובץ המניפסט, גם כי זה מעניין אותי - אבל בעיקר כדי לדעת איזה קובץ לתייג בצ׳אט שלי עם קרסר. - פיתוח פיצ׳רים במוצר קיים ו/או אופטימיזציות - זה יותר מאתגר, אבל ברגע שיש חיבור לקודבייס עם LLM כמו GitHub Workspace החיים קלים הרבה יותר. מבינים את הקשרים. מבינים את ה-Stack. ואז גם כאן - כשמבינים איזה קונטקסט לצרף למודל, איזה שינוי משפיע על איזה רכיב, הכל הופך לקל יותר. - מיגרציות - מעבר מאפליקציות לגאסי, ישנות, לטכנולוגיות חדשות יותר. גם כאן צריך להבין את הכל לעומק, ולמצוא פתרונות טובים. לאחר מכן להרים את סביבת הפיתוח החדשה ובהדרגה לבצע את המיגרציה ולבדוק ששום דבר לא נשבר בדרך. בלי LLM זה סיוט. עם LLM זה סיוט. אבל הרבה פחות! כשאני מדבר על פרקטיקה, על זה בדיוק אני מדבר. לא עוד כלי שיודע לכתוב קוד. לא עוד תת פיצ׳ר במוצר. אלא שיתוף בתהליכים העסקיים והטכניים. תחשבו כמה זמן כסף מאמץ וכולי נחסכים כאן ע״י שימוש ב-LLMs. כשאין אגו - יש אפשרות לטוס קדימה. העולם גם ככה שועט קדימה. עולם הפיתוח הוא מהראשונים שחווים את הזעזוע העצום הזה, שמצריך מאיתנו להמציא את עצמנו מחדש. יצירתיים יותר. וזה האתגר האמיתי. עולם הפיתוח באמת משתנה. מנכ״לים שאיתם דיברתי משתוקקים לרגע שבו ההוצאות יקטנו, הרווחים יעלו, גם על חשבון צמצום בכח אדם. ברגע שזה יוכח כמוצלח - כדור השלג יתחיל להתגלגל. אין סנטימנטים בעסקים. זה רווח והפסד נטו. זה לא בית ולא משפחה. ולכן, עסק זה עסק, וגם אנחנו צריכים לפתח את החשיבה הזו ולהבין: ה-AI באמת מאיץ תהליכים דרמטית. אנחנו יכולים להמשיך להתנגד ולצקצק, ויום אחד למצוא את עצמנו בחוץ. או שאנחנו יכולים לאמץ את הכלים ולהבין את המגבלות שלהם - ולנווט את הספינה. הכל בידינו.

לקוח שאני מלווה ומפתח לו החליף את בית התוכנה שלו - ובחר לעבוד איתי במקום. הסיבה, לדבריו: ״למה לשלם לבית תוכנה מיושן במקום לקחת מפתח סולו שעובד עם AI בהספק של בית תוכנה שלם?״ זה לא שאני מחולל ניסים. ממש לא. אני גם לא מתיימר להיות יהיר ולהבטיח הבטחות כאילו אני בית תוכנה של 50 עובדים. אני ״פשוט״ עובד עם כלי AI ומשתדל להבין מה אני עושה - ולמה. השיטה הזו, בנוסף לעובדה שאני עסק עצמאי משלי, מאפשרת לי לרוץ מהר. בלי ישיבות מיותרות. בלי בזבוזי זמן. רק הגדרות מהלקוח - וטיסת AI לעבר היעד. עבדתי בכל כך הרבה מקומות עבודה, ראיתי כמה זמן צריך כדי לפתח פיצ׳ר למוצר קיים וכמה שיתופי פעולה חוצי צוותים צריך לשם כך. רבעונים שלמים, מצגות, פוליטיקה ארגונית, וכנראה שגם דחייה בעמידה ביעד. הכל ״כבד״. ואילו כיום? מהרגע שמגדירים דרישות כמו שצריך - אפשר לטוס. כמה מהר? הלקוח שלי (אחד מהם) יצר Prototyoe עם v0. תוך שעתיים וחצי הפכתי אותו לאפליקציית NextJS עם Cursor - ועכשיו אני בעבודה על צד השרת. הלקוח שלי קיבל הצעה מבית תוכנה ״קלאסי״, שאמר שצריך 10 עובדים לפרויקט, ולוח הזמנים הוא 8-9 חודשים. כיום, אנחנו בערך שבועיים אל תוך הפרויקט, כבר יש אפליקציה שכל הפרונט שלה מוכן ב-85%, לרבות פריסה בענן, חיבור לבסיס נתונים, אימות משתמשים, ורוב העבודה היא פיתוח הבקאנד, כאמור. אני גם מסתכל על זה כבעל עסק. אם אני צריך שירותי פיתוח לרעיון שיש לי - למה לי להעסיק 10 מפתחים/ות אם אני צריך 1-2 שיודעים לעבוד עם קרסר? זה גם מה שאמרו לי משקיעים ומשקיעות. בצדק. תראו את Maor Shlomo לדוגמה הכי בולטת פה עם Base44 . זה ההווה. זה העתיד. מה שהיה - הוא לא מה שיהיה. לעניות דעתי הכל גם ככה משתנה - מי שיאחוז בחבלי החדשנות, הוא זה שארגונים ולקוחות יצטרכו. אל תישארו מאחור. תחזיקו בחבל ה-AI עוד היום. לא מאוחר מדי. לאחרונה Ron Kaldes פרסם פוסט שנגע לי בדיוק במקומות האלה. צריך לפרק ולהרכיב מחדש ארגונים. להבין מחדש את התהליכים העסקיים. מעבר לדרמטיות של הרעיון, שהוא ככ נכון, החיזוק הכי גדול שיש לי לתת לתזה הזו - הוא שזה בדיוק מה שאחד מהלקוחות שלי עשה כששכר את שירותיי. שבוע טוב ובשורות טובות, ותזכורת שהיום שניים וארבעים יום לעומר שהם שישה שבועות.

אשתי נכנסה אלי לחדר ושואלת אותי: יש לך משהו להגיד לי? עניתי לה: כן, Don't Overthink ו-Don't Overcomplicate זה בדיוק מה שאני מרגיש כלפי קלוד 4 החדש שהושק אתמול ב-2 גרסאות שאמורות להיות המובילות בפיתוח. ניסיתי את שתיהן ב-Cursor, והמסקנה שלי הוא מה שכתב קלוד עצמו: הוא סתם מסבך דברים יתר על המידה. או כלשונו: I overcomplicate. זה מחזיר אותי לנקודה חשובה: הלידרבורדים, הטבלה שמציגה מי המודלים המובילים במשימות מסוימות, משתנה כל הזמן. כל רגע יכול להיות מודל חדש שיוביל. יש כל מיני קריטריונים כדי לקבוע שמודל מצליח במשימה כזו או אחרת ואני לא מזלזל במדדים, אבל אני כן מרגיש שלטובת הפרויקטים שלי זה שיש מודל שניצב בראש הרשימה לא אומר שהוא מתאים לפרויקט שלי יותר מכולם. כך למשל, קלוד 3.7 עד לאחרונה הוביל מבחינת הרשימות, אבל קלוד 3.5 היה טוב יותר בדיוק במשימות. כמו כן, קלוד 3.7 MAX עם חשיבה היה אמור להיות "רמה אחרת", אבל בפועל o3 הצליח יותר בפרויקט שעבדתי עליהם. ניסיתי גם את Gemini 2.5 למשימות Refactoring, יחד עם קלוד 3.7 MAX, ועם o3, וגיליתי ש-o3 ניצח. בקיצור, זה לא רק מי ניצב בראש הטבלה - אלא מי מתאים יותר למשימות שלנו. ובקשר לאשתי, עדיין לא הבנתי את השאלה שלה, ולא מה אני אמור להגיד. בדיוק כמו קלוד. וכמו עם אשתי, כל פעם צריך להתאים את התשובה, שזה כמו לדעת באיזה מודל להשתמש בכל בעיה. שמחתי לעזור. שבת שלום!

כמה תובנות חשובות על ״AI שאחרי ההייפ״ ומקרי בוחן אצל לקוחות אמיתיים (השמות שמורים במערכת) הבנו. יש AI. יש API. יש אפילו MCP. יש סוכנים. יש מודלים קוליים. יש יצירת תמונות ווידאו. אבל אחרי כל ההייפ - מה באמת מעניין לקוחות הלכה למעשה? הנה כמה נקודות מחוויה אישית שלי עם לקוחות שאני מלווה. 1. כולנו נמצאים בבלבול. אף אחד לא יודע מהי הדרך הנכונה להטמיע AI. כולנו מנסים לסלול דרך שעדיין לא סלולה. זה בסדר לנסות לטעות לתהות לתקן לשפר ושוב לבחון. 2. כולנו לומדים אחרי טעויות. בנינו סוכן. שילמנו פתאום הרבה. קריאות API כשלו. דברים נשברו בפרודקשן. הסוכן לא עבד כפי שציפינו. אבל אז תיקנו. זה בסדר להיכשל וללמוד מזה. 3. לקוחות מעוניינים במנוע AI יותר מאשר צ׳אט בוט AI. זאת אומרת, לא מספיק סוכן שמשיב על שאלות על בסיס מאגר ידע. זה נחמד. Nice to have אבל לא Must to have. לקוחות רוצים לקבל תובנות על הדאטה שיש להם כבר שנים רבות. 4. כדי לקבל תובנות - מנסים לפתור שני עניינים: הראשון הוא הקונקטורים. איזה חיבורים אנחנו מנגישים למודל השפה כדי שיבצע עבורנו ניתוח מידע? והשני הוא איך אנחנו מזקקים את המידע הרלוונטי כדי להנגיש רק קונטקסט רלוונטי למודל? פה נכנסים כל שיקולי הקונטקסט. איך לנהל אותו. האם להשתמש במודל Reranking או לא, האם לחלק סוכנים לתפקידים שונים? ואיך ״לנצח״ על מקהלת הסוכנים? 5. אבטחת מידע. למרות שיש מודלים מובילים, רוב החברות ירצו לבנות תשתית סגורה בענן של מייקרוסופט או אמזון (ולעיתים אפילו לוקאלית עם המון GPUs) ולהשתמש במודלים שמוחצנים דרכן, עם Fallback מוגדר היטב למקרה של כשל. והנה מספר מקרי בוחן של חברות איתן שוחחתי (מספר רק מה שמותר לי במבט על): - אתר שמתחבר לטרנזקציות פיננסיות ומנסה לנבא מה להמליץ ללקוחות - שימוש במודל שפה גדול כדי לבצע חיפוש בדאטה עצום ולספק תוצאות בשפה טבעית - יצירת צ׳אט בוט AI על קודבייס עצום כדי לאפשר לאנשי מוצר ופיתוח להבין טוב יותר את המכניקה - ביצוע refactoring לקוד ועזרה בתהליכי מיגרציות מאפליקציות Legacy לטכנולוגיות חדשניות יותר - תשאול מסמכים או איתור תמונות מספריות בצורה מקומית (ע״י שימוש במודל Clip דרך ChatRTX של Nvidia שרץ מקומית) - שימוש בממשקים של קוד מקור פתוח כמו Open Web או Chainlit כדי לקבל ממש נחמד לתשאול LLM ושימוש במודלים לא מצונזרים לשלל משימות לסיכום מבחינתי יש הבנה גדולה שנגמר ההייפ. יופי שיש כלים נוצצים. עכשיו בואו נדבר תכלס על שיפור תהליכים עסקיים שיחסכו המון משאבים. גם זמן גם כסף וגם יקצרו תהליכים. שם עסקים נמצאים כיום, והמירוץ הוא לפתור בעיות מורכבות ולא רק לנופף בכלים נוצצים.

יש סחף חדש בקהילת הפיתוח סביב Memory Bank שזו טכניקה שאמורה לגרום לסוכן הקוד להכיר טוב יותר את הפרויקט ואת ההקשרים, האם זה עובד והאם זה עוזר? נתחיל מהסוף. זה קצת רמאות. כי זה לא באמת פיצ׳ר של זיכרון אמיתי. זה הגדרה נוספת ברמת הפרומפטינג (בחוקים) ששולחת את ההנחיות של ״הזיכרון״ בכל פרומפט מחדש. זה עדיין בזבוז של טוקנים ולא באמת פיתרון יסודי לבעיה. טכנית, כדי להוסיף את היכולת הזו אנחנו צריכים לבצע כמה הגדרות, בין אם זה ב Cline או Cursor או Windsurf או GitHub Copilot. ההגדרות ״סך הכל״ מאלצות את ה-LLM להסתכל בכל פרומפט על סט של קבצים ולעדכן אותם בהתאם וכך יוצרים מעין ״זיכרון״ מדומה. יש פה יכולות ממש חמודות, אני לא מרגיש שזה מה שעוזר מספיק. זה נחמד כדי לנסות לפתור את הבעיה הכי גדולה של איבוד ההקשר תוך כדי שיחה מתמשכת, אבל כפיתרון יסודי זה עוד לא שם, ולעניות דעתי, וזו רק דעתי, מה שצריך זה סוכן שעוזר להבין את תמונת המצב של הארכיטקטורה בכל רגע נתון ולא אחד ששולח את כל זה בכל פרומפט מחדש. האחריות עדיין צריכה להיות עלינו. הנה חלק מסרטון נפלא של AI Labs ביוטיוב, אני מאוד אוהב אותם, שמסביר קצת על הזיכרון.

נמאס לי שה-AI לא מצליח להבין אותי בפיתוח אז החלטתי לפתח סוכן לסביבת הפיתוח שתפקידו לזכור כל הזמן את מטרת הפרויקט - ובעיקר למקד אותי איזה קובץ לתייג בפרומפט כדי לצרף אותו כקונטקסט רלוונטי, כדי ה-AI יפתח כמו שצריך למען השם! בגלל שאני שורף, ושרפתי, למעלה ממאות רבות של שעות (לא אגזים אם אגיד שאחצה בקרוב את ה-1000 שעות עם קרסר), נמאס לי מהמון בעיות שיש עם סוכני ה-AI הקיימים: 1. כל פעם אני צריך להסביר מה אני רוצה 2. אני הולך לאיבוד תוך כדי הפרויקט ולא מבין את ההסתעפות, את מבנה התיקיות והקבצים 3. אני לא תמיד בפוקוס על הקשרים בין הקומפוננטות, וכולי אני לא מצפה ש-AI יפתור עבורי הכל. אני מציאותי. אבל! החלטתי לבנות סוכן AI שמה שהוא יודע זה להסתכל על מסגרת הפיתוח של הפרויקט, ״להזכיר״ לי מה המבנה, עוקב אחר הקשרים בין התיקיות והקבצים כדי שאדע מי אחראי על כל פיצ'ר ועל כל קומפוננטה. המטרה היא לבנות מעין גרף ידע, Knowledge Graph, ויזואלי שמשמש לי כעזר. כמו טייס משנה. לא רוצה שהוא יקח שליטה על הקוד, להיפך, אני רוצה שהוא יעזור לי לקחת שליטה וימקד אותי איזה קובץ לתייג בפרומפט כדי לעבוד טוב יותר. אתן דוגמה: כשאני עובד עם NextJS, מהר מאוד תיקיית API מתמלאת בלוגיקות, וגם העמודים עצמם, וגם הקומפוננטות, וגם תיקיית lib. כנ״ל אם אני עובד עם Django, אני צריך לשמור על ההבנה של החיבורים בשיטת ה-MVC, או שכשאני מפתח תוסף לוורדפרס או ל-VSCode, אני רוצה לדעת מה אמור להיות המבנה של הפרויקט ואיפה נמצא ״הזהב״ כדי להתמקד בו בתהליך איתור השגיאות שלי. נכון שעם הניסיון זוכרים, אבל ככל שפרויקטים מסתעפים זה הולך ומסתבך ולמה לסמוך על הזיכרון או יכולת הדיבוג אם אפשר שיהיו לנו דפי עזר? זו בדיוק הבעיה שאני מנסה לפתור. כדי להבין את הקונטקסט של הפרויקט הוספתי תמיכה גם במודלים מסחריים של Cohere, OpenAI, Claude, אבל גם במודלים לוקאליים דרך Ollama כמו LlamaCoder, Qwen וכדומה. זה עדיין לא מושלם - אבל זה מרגש אותי שזה עובד!

הגילוי המאוחר שחוסך לי שעות של תסכול: אחרי כל שינוי משמעותי או פיצ'ר חדש, אני מבקש מה-LLM לייצר יחידות בדיקה מקיפות, להריץ אותן, ורק לאחר הצלחה בשיעור של 100% - להמשיך הלאה. בדרך הזו גיליתי ששעות רבות של איתור שגיאות נחסכות ממני! כנראה שמי שבא מעולמות הבדיקות, או מי שיש לו יותר סבלנות ממני בשלבי הפיתוח, יכיר את זה ומתכנן את זה מראש. אבל אני אוהב לרוץ מהר ולתקן תוך כדי, מה שגורם להרבה תסכול לא מעט פעמים ולכן הלקח שלי הוא משולש: לתכנן מראש, לקחת שליטה מה-AI, וכל הזמן לבקש יחידות בדיקה. אני יודע. יש מי שיגידו בצדק: ה-AI כותב את הקוד, הוא לא יכול לבדוק את הקוד של עצמו. כלומר, הוא כן יכול אבל זה לא הגיוני. וזה נכון, ולכן: אפשר בקרסר לפתוח טאב חדש עם קונטרול+T ואז נוכל להשתמש ב-2 סוכני קוד במקביל. סוכן אחד הוא הסוכן הרגיל, ואילו בסוכן השני אפשר לבחור מודל שפה אחר. מה שאומר, סוכן אחד עם מודל שפה אחד - כותב את הקוד, וסוכן אחר עם מודל שפה אחר - כותב את הבדיקות ומריץ אותן! כך יש לנו בקרה, שלי אישית חוסכת המון זמן. רק חבל שחשבתי על זה וגיליתי את זה מאות שעות אחרי. אבל עדיף מאוחר מאשר אף פעם לא.

רגע מכונן: יצרתי Boilerplate חדש בסגנון ״הכל כלול״ (עם אותנטיקציה והכנה למונגו אטלס) ופרסמתי אותו ב-npm! מה שאומר שהוא זמין בחינם בהרצת הפקודה המקוצררת: npx create-yuv-app my-app !!!! 🚀 נכון. זה לא חדש שיצרתי בוילר-פלייט, ויש כנראה המון בחוץ. אבל עבורי זה רגע מכונן גם כי הפעם הלכתי על מינימליזם בהיבט של לתת את כל השלד הדרוש, אבל גם מיקסום החבילה כך שעל ידי הרצת הפקודה הקצרה שציינתי הכל יהיה זמין לכל מפתח ומפתחת על המחשב שלו, לוקאלית, עם ההכנה לחיבור לבסיס הנתונים של מונגו אטלס, עם התקנות של NextJS, Tailwind, Shadcn, Clerk וכמובן Mongoose / MongoDB. הכנתי מדריך באורך של כ-7 דקות בלבד ואני נרגש לשתף אותו אתכם. זו פעם ראשונה שאני מפרסם חבילה ל-npm המהולל, לכן אני מתלהב ברמות. הסיבה לבוילר-פלייט החדש היא כיוון שיש מי שרצה את המינימום. עמוד נחיתה יפה, עם אפשרות להרשמה, ומשם כל אחד ואחת שיקחו את זה לאן *שהם* רוצים ולא יהיו מחוייבים בתבנית כזו או אחרת. תהנו, עדכנו מה חשבתם! בהצלחה לכולנו!! קוד המקור זמין בגיטהאב שלי (היוזר שלי בגיטהאב נקרא hoodini אז תראו הכל שם)

4 ימים בתמונה אחת (רק חסרה החותמת של ניס בצרפת). היה מטורף, היה מדהים, ומשהו מעניין שאני לוקח מהשבוע הזה הוא ששאלו אותי (לא ישראלים ולא יהודים): כל כך יקר בישראל, טילים שהשביתו לך את כל הטיסות חזור, מלחמה, חטופים, ילדים שרצים לממ״ד בגלל אזעקות כמעט כל יום. למה אתה עוד שם ולא עובר? אני: כי זה הבית. ישראל זה הבית. כמה טוב לשוב הביתה. שוב תודה לאשתי היקרה (ומזל טוב!!) ולה׳ יתברך ולכל מי שתמכו ועודדו, וכמובן למי שהזמין אותי להוביל את אירועי ה-AI המדהימים האלה. שבת שלום ובשורות טובות לכולם 🙏