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

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

מהסוף להתחלה. ניסיתי לאחסן את הקבצים ב-GridFS של מונגו. זה לא התאים לצורך שלי. גריד יודע להתמודד עם גדלים שונים של קבצים על ידי פיצול לחלקים קטנים יותר, צ׳אנקים. אבל אני צריך משהו יותר Robust. אחרי מחקר, בחרתי ב-AWS s3 לשירות אחסון, לא לפני שניסיתי להבין איך התהליך עובד בהעלאת והורדת קבצים.

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

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

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

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

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

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

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

ובסוף, למדתי. התחזקתי. וזה עובד!

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

בסשן דיברתי על מבוא כללי ל-GEN AI, כלי VIBE CODING, יתרונות וחסרונות והשתדלתי לזרוק הרבה "פנינות" לאוויר תוך כדי הסשן.

קישור ממש פה >>> https://www.youtube.com/watch?v=fXULAsH4aZg&t=2912s

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

ההכנות דירבנו אותי לחשוב מחוץ לקופסא. להבין מה אני רוצה לפתח וליצור. אחרי המון שיחות ומפגשים עם Gilad G. Amir נפל לי האסימון: חברה שיודעת להתחבר למקורות מידע של חברות ולתת תחזיות מבוססות עובדות באמצעות AI - כדי לחזות את הפעולות הבאות, Next Best Actions.

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

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

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

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

ותודה לחברי וחברות קהילת הפיתוח וה-AI ולישראלים בארץ ובחו״ל, ולכל השותפים והשותפות למסע שלי. כל זה היה חסרי משמעות בלעדיכם/ן. הרי הבמה הכי גדולה לא שווה אם אין קהל מדהים וחכם שמוכן להאזין. אז תודה גדולה לאשתי, לה׳ יתברך, לכל השותפים בדרך, לחברות לארגונים לעסקים - וכמובן - לכם ולכן!

זהו סיימתי עם הריגשי. שנזכה לכל הישועות - ועד אז - מי מהמר על מה היעד? ✈️

תחנה ראשונה: סיימתי פגישה עם נירו, סמנכ״ל ה-GTM והאסטרטגיה בתחום ה-AI והדבאופס-סקיוריטי של GitHub הגדולה, בלונדון. הקלטנו סשן שאלות ותשובות על שלל נושאים בדגש על קופיילוט של גיטהאב ופיתוח אפליקציות מבוססות AI, וכמובן נגענו גם ב-MCP ו-Vibe Coding ועוד.

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

תודה רבה לך נירו, היה מדהים, מחכה כבר לפעם הבאה 🚀

לא רק רכבת: בואו תראו מה אפשר לפתח עם Base44 תוך כדי טיסה!!! (תודה Elad Cohen שהזכרת לי את זה באוויר!)


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

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

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

שוב תודה לאשתי היקרה (ומזל טוב!!) ולה׳ יתברך ולכל מי שתמכו ועודדו, וכמובן למי שהזמין אותי להוביל את אירועי ה-AI המדהימים האלה. שבת שלום ובשורות טובות לכולם 🙏

רגע מכונן: יצרתי Boilerplate חדש בסגנון ״הכל כלול״ (עם אותנטיקציה והכנה למונגו אטלס) ופרסמתי אותו ב-npm! מה שאומר שהוא זמין בחינם בהרצת הפקודה המקוצררת: npx create-yuv-app my-app !!!! 🚀


נכון. זה לא חדש שיצרתי בוילר-פלייט, ויש כנראה המון בחוץ. אבל עבורי זה רגע מכונן גם כי הפעם הלכתי על מינימליזם בהיבט של לתת את כל השלד הדרוש, אבל גם מיקסום החבילה כך שעל ידי הרצת הפקודה הקצרה שציינתי הכל יהיה זמין לכל מפתח ומפתחת על המחשב שלו, לוקאלית, עם ההכנה לחיבור לבסיס הנתונים של מונגו אטלס, עם התקנות של NextJS, Tailwind, Shadcn, Clerk וכמובן Mongoose / MongoDB.

הכנתי מדריך באורך של כ-7 דקות בלבד ואני נרגש לשתף אותו אתכם. זו פעם ראשונה שאני מפרסם חבילה ל-npm המהולל, לכן אני מתלהב ברמות. הסיבה לבוילר-פלייט החדש היא כיוון שיש מי שרצה את המינימום. עמוד נחיתה יפה, עם אפשרות להרשמה, ומשם כל אחד ואחת שיקחו את זה לאן *שהם* רוצים ולא יהיו מחוייבים בתבנית כזו או אחרת. תהנו, עדכנו מה חשבתם! בהצלחה לכולנו!!
קוד המקור זמין בגיטהאב שלי (היוזר שלי בגיטהאב נקרא hoodini אז תראו הכל שם)

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

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

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

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

בגלל שאני שורף, ושרפתי, למעלה ממאות רבות של שעות (לא אגזים אם אגיד שאחצה בקרוב את ה-1000 שעות עם קרסר), נמאס לי מהמון בעיות שיש עם סוכני ה-AI הקיימים:

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

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

אתן דוגמה: כשאני עובד עם NextJS, מהר מאוד תיקיית API מתמלאת בלוגיקות, וגם העמודים עצמם, וגם הקומפוננטות, וגם תיקיית lib. כנ״ל אם אני עובד עם Django, אני צריך לשמור על ההבנה של החיבורים בשיטת ה-MVC, או שכשאני מפתח תוסף לוורדפרס או ל-VSCode, אני רוצה לדעת מה אמור להיות המבנה של הפרויקט ואיפה נמצא ״הזהב״ כדי להתמקד בו בתהליך איתור השגיאות שלי. נכון שעם הניסיון זוכרים, אבל ככל שפרויקטים מסתעפים זה הולך ומסתבך ולמה לסמוך על הזיכרון או יכולת הדיבוג אם אפשר שיהיו לנו דפי עזר? זו בדיוק הבעיה שאני מנסה לפתור.

כדי להבין את הקונטקסט של הפרויקט הוספתי תמיכה גם במודלים מסחריים של Cohere, OpenAI, Claude, אבל גם במודלים לוקאליים דרך Ollama כמו LlamaCoder, Qwen וכדומה. זה עדיין לא מושלם - אבל זה מרגש אותי שזה עובד!

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

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

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

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

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

כמה תובנות חשובות על ״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 ושימוש במודלים לא מצונזרים לשלל משימות

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

אשתי נכנסה אלי לחדר ושואלת אותי: יש לך משהו להגיד לי?
עניתי לה: כן, 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 בהספק של בית תוכנה שלם?״

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

עבדתי בכל כך הרבה מקומות עבודה, ראיתי כמה זמן צריך כדי לפתח פיצ׳ר למוצר קיים וכמה שיתופי פעולה חוצי צוותים צריך לשם כך. רבעונים שלמים, מצגות, פוליטיקה ארגונית, וכנראה שגם דחייה בעמידה ביעד. הכל ״כבד״. ואילו כיום? מהרגע שמגדירים דרישות כמו שצריך - אפשר לטוס. כמה מהר? הלקוח שלי (אחד מהם) יצר Prototyoe עם v0. תוך שעתיים וחצי הפכתי אותו לאפליקציית NextJS עם Cursor - ועכשיו אני בעבודה על צד השרת. הלקוח שלי קיבל הצעה מבית תוכנה ״קלאסי״, שאמר שצריך 10 עובדים לפרויקט, ולוח הזמנים הוא 8-9 חודשים. כיום, אנחנו בערך שבועיים אל תוך הפרויקט, כבר יש אפליקציה שכל הפרונט שלה מוכן ב-85%, לרבות פריסה בענן, חיבור לבסיס נתונים, אימות משתמשים, ורוב העבודה היא פיתוח הבקאנד, כאמור.

אני גם מסתכל על זה כבעל עסק. אם אני צריך שירותי פיתוח לרעיון שיש לי - למה לי להעסיק 10 מפתחים/ות אם אני צריך 1-2 שיודעים לעבוד עם קרסר? זה גם מה שאמרו לי משקיעים ומשקיעות. בצדק. תראו את Maor Shlomo לדוגמה הכי בולטת פה עם Base44 . זה ההווה. זה העתיד. מה שהיה - הוא לא מה שיהיה. לעניות דעתי הכל גם ככה משתנה - מי שיאחוז בחבלי החדשנות, הוא זה שארגונים ולקוחות יצטרכו. אל תישארו מאחור. תחזיקו בחבל ה-AI עוד היום. לא מאוחר מדי. לאחרונה Ron Kaldes פרסם פוסט שנגע לי בדיוק במקומות האלה. צריך לפרק ולהרכיב מחדש ארגונים. להבין מחדש את התהליכים העסקיים. מעבר לדרמטיות של הרעיון, שהוא ככ נכון, החיזוק הכי גדול שיש לי לתת לתזה הזו - הוא שזה בדיוק מה שאחד מהלקוחות שלי עשה כששכר את שירותיי.

שבוע טוב ובשורות טובות, ותזכורת שהיום שניים וארבעים יום לעומר שהם שישה שבועות.

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

ככלל, קיימים 3 יוז קייסים שאני נתקל בהם:
1. פיתוח מוצר חדש מאפס
2. התחברות לסביבת פיתוח קיימת והוספת פיצ׳רים
3. התחברות לסביב פיתוח קיימת - וביצוע אופטימיזציות או מיגרציות (מעבר למסגרות פיתוח מתקדמות יותר)

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

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

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

- פיתוח פיצ׳רים במוצר קיים ו/או אופטימיזציות - זה יותר מאתגר, אבל ברגע שיש חיבור לקודבייס עם LLM כמו GitHub Workspace החיים קלים הרבה יותר. מבינים את הקשרים. מבינים את ה-Stack. ואז גם כאן - כשמבינים איזה קונטקסט לצרף למודל, איזה שינוי משפיע על איזה רכיב, הכל הופך לקל יותר.

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

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

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