ToCode

שטויות שלקח לי יותר מדי זמן להבין על LangGraph כמה הערות על LangGraph לאנשים שמכירים או שמתחילים ללמוד שלי לפחות לקח יותר מדי זמן להבין: 1. כדאי להתחיל עם LangChain. זה לא אחד במקום השני אלא שאחד מרחיב את השני. 2. נוח לפתח את ה Nodes אחד אחרי השני, כל Node בצורה עצמאית עם בדיקות משלו. 3. נוד הוא בסך הכל פונקציה שמקבלת State ומחזירה State מעודכן. 4. יש המון חבילות הרחבה ל LangGraph רק בשביל לדבר עם ה LLM-ים השונים. אותם LLM-ים מופיעים בכמה חבילות. לפעמים צריך לנסות כמה עד שמוצאים את החבילה הנכונה. 5. לאנגגרף עבר ועובר הרבה שינויים. לא נדיר לקבל מ AI קוד שמתאים לגירסה ישנה יותר של LangGraph. כשזה קורה אפשר לבקש מה AI לשדרג או לשדרג בעצמנו עם התיעוד. 6. אפשר וכדאי להשתמש ב State Class שונה לכל נוד (וכך פלט של נוד אחד הוא הקלט של הנוד הבא). את הסטייט אפשר לכתוב בתור TypedDict או pydantic. אני מעדיף pydantic. 7. תחברו את LangSmith. זה שווה את השתי לחיצות. 8. כל קריאה ל graph.stream שולחת את הסטייט הראשוני למסע בגרף ומסתיימת כשהגרף מסתיים עם הסטייט מהנוד האחרון. 9. אפשר להשתמש בגרף כדי לתאר Workflow או שיתוף פעולה לא לינארי בין מספר סוכנים. צומת יכול להיות אסינכרוני וכך אפשר להריץ חלקים מה Workflow במקביל או לתאר דינמיקה של סוכנים עם תנאי סיום. ככל שאני עובד עם לאנגגרף אני חייב להודות שהוא מפתיע לטובה. מהכלים שנראים מסובכים ממבט ראשון אבל עם הזמן ברור למה הם צריכים להיות מסובכים. אני ממליץ עליו ובוודאות אכתוב עליו קורס כשכל עולם האייג'נטים קצת יתייצב.

להביא את הפיצה אחד האתגרים של חברות שאימצו Agile היה להבין מה המנהלים צריכים לעשות עכשיו. הרבה מהעבודה של מנהלים עברה למנהלי מוצר, ל ScrumMasters ולמפתחים. הבדיחה שלהם היתה שלמנהל נשאר רק להביא את הפיצה או בנימה יותר רצינית: 1. הגדרת יעדים ברורים - איך נראית הצלחה. 2. שיפור היכולות - איך אפשר לעשות יותר עם הצוות והמשאבים הקיימים. 3. שיפור המערכת - זיהוי הזדמנויות "להוריד עלויות" ולשפר תהליכים. אולי אנחנו מסתכלים על שינוי דומה בעבודת המתכנתים. אני בונה עכשיו Workflow חדש ללקוח שיאפשר למנהלת מוצר לאפיין פיצ'ר באמצעות יצירת Issue (מה שהיום היא בכל מקרה עושה) אבל במקום שמפתח יצטרך לקחת את זה משם את ה Issue ייקח סוכן AI אוטונומי, ה AI יפתור את הבעיה או יממש את הפיצ'ר, יריץ בדיקות אוטומטיות ויעלה גירסת בדיקה על מכונה בענן. מפה הדיאלוג ממשיך ואותה מנהלת מוצר תוכל לשלוח פידבק על הגירסה ולהטריג סיבוב עדכון, עד שהפיצ'ר עובד. והמשבר - אם זה המצב מה נשאר למתכנתים לעשות? מעבר לחלומות של להביא את הפיצה בואו ניקח את שלושת המשימות של מנהלי Agile ונתאים אותן לעולם שלנו: 1. הגדרת ארכיטקטורה ברורה - כלי AI לא יודעים לקבל החלטות. הארכיטקטורה נכתבת בקבצי איפיון ייעודיים ונקבעת על ידי אנשים שמבינים את הצרכים של המערכת ואיך היא הולכת לגדול ולהשתנות. 2. שיפור היכולות - שיחה עם מנהלי המוצר, סשנים של הדרכות יותר טכניות על המוצר, זיהוי פרומפטים לא מספיק טובים והצעות לשיפור. 3. שיפור תהליכים מערכתיים - זיהוי תבניות בעייתיות בקוד ש AI מייצר, ריפקטורינג של המערכת כדי של AI יהיה יותר קל, בניית AI Friendly Codebase, שיפור הבדיקות. זה לא מדע בדיוני ואפילו לא העתיד. ה Flow של אנשי מוצר שבונים מערכות בעזרת סוכני AI זה ההווה. הם עושים את זה עם בייס44 ומחר בבוקר ימשיכו לעשות את זה על המערכות שלהם. אנחנו יוצאים מהלופ, ולא בטוח שזה דבר רע.

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

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

1. זכרו שעבודה מול AI עשויה לדרוש שינוי בארכיטקטורה או מודל הנתונים. הקצו מראש את הזמן לתכנון וביצוע שינויים אלה. 2. התחילו באיפיון. ראינו מספיק מוצרי AI בחודשים האחרונים בשביל להבין איזה התנהגות חדשה וחכמה אנחנו צריכים. 3. אחרי שהגדרתם את ההתנהגות המשיכו לאיפיון טכני: איזה מידע ה AI צריך, מה הציפיות שלכם מבחינת ביצועים, מה הציפיות מבחינת עלויות, באיזה מודלים כדאי להשתמש, כמה אתם מוכנים לסבול טעויות של AI, איך אתם עוקבים אחרי בקשות ואיכות התוצרים של AI. 4. הכי טוב אם אפשר לתת ל AI לעבוד על "לוח טיוטה", לתת למשתמשים לערוך ולתקן את התוצרים ואז לפרסם. ב Langlets ה AI יוצר JSON שמתאים למידע ששמור ב DB ורק אחרי שה JSON נערך על ידי בן אדם, נבדק ומתוקן אפשר לפרסם אותו בתהליך ידני. 5. אחרי שהמוצר עולה לאוויר המשיכו לעקוב אחר בקשות, תשובות וכשלונות. שינוי פרומפטים, מודלים ובניית מנגנוני Fallbacks יכול לעשות הבדל גדול באיכות התוצאות. עדיין מתלבטים? אשמח לעזור בחודשים האחרונים אני עוזר ללקוחות לשלב AI במוצרים שלהם במקביל לשילוב AI במוצרים שלי וללמידה של התחום. אני לומד המון ומשתדל לפרסם כאן תובנות מעניינות מהמסע. השינוי שאני רואה מזכיר את השינוי שקרה כשנכנסו הטלפונים החכמים: אפשרות טכנולוגית חדשה פוגשת צמא של משתמשים ודוחפת קדימה את מוצרי התוכנה. כמו שאנחנו לא יכולים לדמיין היום מוצר שלא מתאים לעבודה מהנייד, כך לא רחוק היום שלא נוכל לדמיין מוצר שלא מתקשר איתנו בשפה טבעית. אם אתם משלבים AI במוצר קיים ורוצים להתייעץ על איפיון, להתלבט יחד באיזה טכנולוגיות כדאי להשתמש או מחפשים פרילאנסר לעזרה בפיתוח אשמח לשמוע ואני בטוח שאוכל לעזור. אפשר לכתוב לי בטלגרם, במייל או להשאיר הודעה באתר.

הטמעת AI במוצר קיים שילוב AI במערכות ופיתוח רכיבים ותהליכים חכמים הולך להיות האתגר הגדול של השנים הקרובות. לארגונים עם מוצר קיים הסיפור הולך להיות הרבה יותר מסובך ויש סיכוי לא מבוטל למתחרים חדשים שישתמשו ב AI כדי לתפוס נתח שוק ומהר. בפוסט היום נרצה להסתכל על התופעה והאתגרים מנקודת מבט של מוצר קיים. הילד החדש בשכונה לא סתם כל סטארט-אפ חדש השנה היה ה"משהו עם AI". היה לנו קרסר למצגות, קרסר למסמכים, טרמינל עם AI, ניהול צוות תמיכה עם AI, דפי צביעה עם AI, בוני אתרים ודפי נחיתה עם AI ועוד אינסוף חברות חדשות שמסתכלות על העולם ומזהות רצון של משתמשים שפוגש יכולת טכנולוגית חדשה. כן כשאתה מתחיל מאפס אין לך Legacy ואתה יכול לבנות כל מוצר בעולם עם AI משולב בתהליכי עבודה מהצעד הראשון. אבל מה אם כבר בנית מערכת לפיתוח דפי נחיתה לפני 5 שנים והיא עובדת דווקא די טוב? מה אם יש לך כבר תוכנת אופיס שפיתחת שעד עכשיו היה נראה שמובילה את השוק? מה אם יש לך מערכת לניהול קריאות שירות מלקוחות שכבר עובדת ומרוויחה? מה אתה עושה כשמגיע הילד החדש בשכונה שחשב על AI עוד לפני שכתב את שורת הקוד הראשונה? למה זה מסובך שילוב AI בתוך מוצר קיים הוא תהליך מאתגר בהרבה מפיתוח מוצר AI חדש מאפס. ברמה הארגונית לא בטוח שיש צוות AI, אנשי הפרודקט הקיימים לא מכירים עדיין את האתגרים ב AI, התחום מתפתח מאוד מהר ואופי הפיתוח מתאים הרבה יותר לסטארט-אפים מאשר לארגונים מבוססים, והכי גרוע הלקוחות הקיימים רגילים לשיטת עבודה ושיטת תשלום מסוימת. ל AI יש עלות ותוספת AI אומרת שעלינו לשנות את מודל התמחור כדי לשקף את העלות החדשה שנוספה. ויש את האתגרים הטכניים: 1. ה API לא תמיד ערוך לקבל פניות מ AI. לא תמיד יש API ולא תמיד יש בו את כל הפונקציונאליות שאנחנו צריכים. 2. מערכת ההרשאות מאפשרת ביצוע פעולות רק דרך ה API, למרות שגישה ישירה לבסיס הנתונים היתה יכולה לספק ל AI את המידע שהוא צריך הרבה יותר מהר (אבל בשביל זה ה DB צריך להבין מי שואל ואיזה שורות מותר להחזיר). 3. אין לנו דרך טובה לזהות טעויות של AI ולתקן אותן מהר. אין גירסאות על המידע או מקום לשמור טיוטה. 4. לא רוצים לשבור תהליכים קיימים. הבעיה כאן היא שפתיחת המוצר ל AI היא ממש פיתוח "ממשק משתמש" חדש שנותן גישה לפיצ'רים אחרים מהממשק הקיים. בפרויקט הטמעת AI במוצר קיים עלינו גם להחליט מה יהיו הפיצ'רים שנרצה לפתוח לממשק ה Chat וגם להחליט איך הם ישתלבו עם הפיצ'רים הקיימים במערכת. דוגמאות נדמיין אתר קורסים (כמו האתר הזה). אז פיצ'ר שקל להוסיף וכבר הוספתי זה צ'אט עם מורה וירטואלי שאפשר לכתוב לו שאלות על השיעור ולקבל הסברים. פיצ'רים יותר קשים שאני מקווה לפתח בעתיד כוללים אפשרות לעצור את הוידאו בכל נקודה ולשאול שאלה על הקוד באותה נקודה, או לקבל בתשובה מה AI הפניה למקומות אחרים באתר. דוגמה נוספת היא קרסר, שנוצר בתור IDE חדש ולא תוסף ל VS Code כי המפתחים של קרסר היו צריכים גישה הרבה יותר מעמיקה לכל הקוד בפרויקט כדי לבנות RAG ממנו, הם עוקבים אחרי תנועות מקלדת ועכבר ומפעילים מיני-מודל כדי לזהות את השלמת הטאב לקפיצה למקום הבא והוסיפו מנגנוני עריכה חוצי קבצים שהיה מאוד קשה ליישם בתוך תוסף. במקרה של Microsoft הם הדביקו את הקצב מהר והיום קופיילוט מגיע לביצועים דומים. עוד דוגמה זה גיטהאב. יש להם API עשיר עם המון יכולות ובקרת גישה, לכן כשהם היו צריכים להוסיף שרת MCP כדי לאפשר לסוכני AI לדבר בשמנו עם גיטהאב הם יכלו להשתמש באותן Endpoints שכבר הוגדרו. אבל - בגיטהאב יש פעולות שאי אפשר לבטל. אם הסוכן מחליט ליצור Issue ואני שמתי לב לזה באיחור נוכל לסגור את ה Issue אבל לא למחוק אותו. אני בטוח שאם הם היו מתכננים מאפס עבודה דרך AI הם היו שמחים לממש "נקודות שמירה" ו"חזרה בטוחה" כדי לא להישאר עם תוכן לא טוב ש AI יצר. פרויקט אחר שכתבתי, לאנגלטס הוא פלטפורמה ליצירה אוטומטית של תרגילי שפה מתוך סרטים ביוטיוב. בלאנגלטס כל העבודה של ה AI היא על קובץ טיוטה ורק אחרי תיקונים ופרסום היא נכנסת לבסיס הנתונים. זו תבנית שמאפשרת הרבה יותר בקלות ניהול גירסאות, נקודות שמירה וחזרה בטוחה על פלט של AI. זה היה אפשרי בדיוק בגלל שלאנגלטס נכתב מאפס לתוך עולם של AI. איך לגשת להטמעת AI במוצר קיים סדר הפעולות הבא יכול לעזור כשיש לכם מוצר קיים ואתם צריכים להוסיף לו יכולות חכמות:

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

הסוכן החדש של גיטהאב הוא לא מהעולם הזה הפוסט היום הוא קדימון לוובינר שיתקיים ביום חמישי. בוובינר אראה לכם לייב איך להגדיר סוכן אסינכרוני ונבין יותר לעומק באיזה מצבים נשתמש בכאלה סוכנים, כולל דוגמאות למיקבול ועבודה גם על פרויקטים קיימים. השתתפות חינם בזום, לא תהיה הקלטה ובשביל הקישור לזום צריך רק להירשם בעמוד הזה והקישור נשלח אליכם מיידית במייל חוזר: https://tocode.ravpage.co.il/tocodeai עכשיו בואו נדבר על קופיילוט. אני יודע, זאת לא הפעם הראשונה היום ששמעתם על איזה AI שהוא "לא מהעולם הזה". ובכל זאת גיטהאב השאירו אותי בהלם ואפילו לא היו צריכים לבנות מודל חדש בשביל זה. הנה מה שהם עשו: 1. הם לקחו את קלוד הרגיל שרץ בקופיילוט ונתנו לו מחשב בענן. 2. הם חיברו לו MCP של פליירייט כדי שיוכל להריץ דפדפן ובטח עוד כמה כלים כדי שיוכל לשלוט במחשב שהוא קיבל. 3. הם בנו סביבו Workflow שלוקח Issue, מפרק אותו למשימות ועוקב אחרי התקדמות. 4. ואז חיברו את הכל לסוכן אחד שכותב קוד בזמן שאנחנו ישנים. הנה דוגמה לתוצאה שקיבלתי על פרויקט חדש. זה היה ה Issue שפתחתי:

Create a PR implementing a snake game:

1. Use valtio for state management
2. Use industry best practices React/Next Project with multiple files, client side components, client side storage using context provider pattern.
3. Game mechanics:
  - Snake has to eat apples.
  - Game has 2 types of apples, regular and special (gold) apples. Gold apples are worth more points.
  - As the snake eats more apples it grows.
  - When the snake hits a wall or itself the game is over. User can restart.

4. Pay attention to performance. Use \requestAnimationFrame\ for movement and control the FPS. Actual snake speed depends on the user's progress in the game.

5. Do not write tests but write the code using testing best practices so it'll be easy to add tests in the future.

קישור: https://github.com/ynonp/snake-agent/issues/1 ופה אפשר לראות את ה PR שנוצר: https://github.com/ynonp/snake-agent/pull/2 וכאן לוג של כל ה Session שקרה ללא מגע יד: https://github.com/ynonp/snake-agent/actions/runs/16096719029/job/45420480907 ה PR כלל 12 קבצים וכמעט 700 שורות של diff. בזכות החיבור ל playwright קופיילוט באמת הריץ את הפרויקט כדי לוודא שהמשחק עובד. נכון על הארכיטקטורה הוא החליט לבד ואני לא בטוח שאני מסכים עם כל הבחירות שלו, אבל זה בדיוק המשחק שלנו עם AI - אנחנו לא חייבים לקבל את ה PR ואין שום בעיה לזרוק את הקוד, לעדכן את קוד ה Issue בצורה שתגרום להחלטות ארכיטקטורה אחרות ולנסות שוב. היתרון הגדול של שיטת עבודה זו על פני עבודה בתוך ה IDE הוא יכולת המקבול. הרבה זמן מתבזבז על המתנה ל AI שיסיים לעבוד, ואם אנחנו יודעים לבנות את ה Issues בצורה נכונה ולבחור על מה אפשר לעבוד במקביל (כלומר איזה דברים לא יגרמו ליותר מדי קונפליקטים) יש פה פוטנציאל עצום לחיסכון בזמן ולהתמקדות בתכנות, ארכיטקטורה, בחירת טכנולוגיות ומגע אישי.

total_score=$((total_score + score))
    fi
done < "$word_file"

echo "----------------------------------------"
echo "Found ${#valid_words[@]} valid words"
echo "Total score: $total_score points"

נשים לב להמון דברים כאן: 1. קלוד חישב ניקוד של כל המילים שהוא מצא. זה מאוד סיבך לו את המימוש. 2. קלוד השתמש רק בפקודות bash לסינונים בעוד שאני שמחתי להשתמש ב grep. 3. קלוד "ניקה" את המילים לפני הבדיקה, כלומר מחק תווים שאינם אותיות באנגלית. זאת בחירה מוזרה כי אם בקובץ המילים יש מילה שמכילה מספר הגיוני יותר לדלג על השורה שלה. רוב הסיכויים שבלי המספר זאת לא תהיה מילה תקינה באנגלית. השוואה יותר מעניינת מתקבלת כשאני מעדכן את הפרומפט ומוסיף את המשפט: > Use a one line pipeline giving just word suggestions (without score) עכשיו אני מקבל מקלוד את הסקריפט:

* !/bin/bash -e *

center=$1
rest=$2

grep -E "^[${center}${rest}]+$" /usr/share/dict/words | grep "$center" | awk 'length >= 4' | sort -u

שכבר מאוד דומה לפיתרון שלי מלבד סדר הפעולות, המיון בסוף, והבחירה להשתמש ב awk במקום ב grep כדי לבדוק אורך.

פקודת Bash קצרה לפתרון Spelling Bee דבורת האיות הוא משחק חמוד המכיל אות אחת באמצע ועוד 6 אותיות מסביב והמשימה שלנו היא למצוא כמה שיותר מילים מהאותיות האלה עם הכללים: 1. האות שבאמצע חייבת להופיע. 2. אורך המילה לפחות 4 אותיות. אפשר לשחק בו כאן: https://6mal5.com/wortendo/ ובטח בעוד המון מקומות ברשת. המשחק כיפי וביום רגיל כשנתקעים אפשר לבקש עזרה מחברים אבל אם במקרה אין לכם חברים שאוהבים משחקי מילים או שגם הם לא יודעים להרכיב מילים עם U נוכל לקבל גם טיפים מהמחשב בעזרת סקריפט Bash קצר. אני אראה את הסקריפט בגירסה שלי קודם ואחרי זה בגירסה של קלוד ודרך זה גם נלמד משהו על הבדלי הגישות בין אנשים לבינה מלאכותית. אתחיל עם הפיתרון שלי והוא נראה כך:

* !/bin/bash -e *

center=$1
rest=$2

cat /usr/share/dict/words | grep $center | grep .... | egrep "^[${rest}{$center}]+$" | awk '{ print length "\t" $0 }' | sort -n | cut -f2-

וכן זה שורה אחת: 1. לוקחים קובץ מילים. 2. משאירים רק את המילים עם האות שבאמצע. 3. משאירים רק מילים עם 4 אותיות. 4. משאירים רק מילים שמורכבות אך ורק מהאותיות של המשחק. 5. מסדרים את הכל לפי האורך כך שמילים ארוכות יופיעו בתחתית הרשימה (שיהיה קל לראות אותן). מיטיבי לכת יכולים להוסיף שם head -1 כדי לקבל רק רמז אחד. ועכשיו למימוש של קלוד:

* !/bin/bash -e *

center=$1
rest=$2

* Check if arguments are provided *
if [ -z "$center" ] || [ -z "$rest" ]; then
    echo "Usage: $0 <center_letter> <other_letters>"
    echo "Example: $0 a bcdefg"
    exit 1
fi

* Combine all available letters *
all_letters="${center}${rest}"

* Convert to lowercase for consistency *
center=$(echo "$center" | tr '[:upper:]' '[:lower:]')
rest=$(echo "$rest" | tr '[:upper:]' '[:lower:]')
all_letters=$(echo "$all_letters" | tr '[:upper:]' '[:lower:]')

* Word list file (common locations) *
word_files=(
    "/usr/share/dict/words"
    "/usr/dict/words"
    "/usr/share/dict/american-english"
    "/usr/share/dict/web2"
)

word_file=""
for file in "${word_files[@]}"; do
    if [ -f "$file" ]; then
        word_file="$file"
        break
    fi
done

if [ -z "$word_file" ]; then
    echo "Error: No word dictionary found. Please install a word list."
    echo "On Ubuntu/Debian: sudo apt-get install wamerican"
    echo "On macOS: Word lists are usually in /usr/share/dict/"
    exit 1
fi

echo "Solving Spelling Bee with center letter: $center"
echo "Available letters: $all_letters"
echo "Using word list: $word_file"
echo "----------------------------------------"

* Find valid words *
valid_words=()
total_score=0

while IFS= read -r word; do
    # Convert word to lowercase and remove any non-alphabetic characters
    clean_word=$(echo "$word" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z]//g')
    
    # Skip if word is less than 4 letters
    if [ ${#clean_word} -lt 4 ]; then
        continue
    fi
    
    # Check if word contains the center letter
    if [[ "$clean_word" != *"$center"* ]]; then
        continue
    fi
    
    # Check if word only uses available letters
    valid=true
    for ((i=0; i<${#clean_word}; i++)); do
        letter="${clean_word:$i:1}"
        if [[ "$all_letters" != *"$letter"* ]]; then
            valid=false
            break
        fi
    done
    
    if [ "$valid" = true ]; then
        # Calculate score
        word_length=${#clean_word}
        if [ $word_length -eq 4 ]; then
            score=1
        else
            score=$word_length
        fi
        
        # Check if it's a pangram (uses all letters)
        is_pangram=true
        for ((i=0; i<${#all_letters}; i++)); do
            letter="${all_letters:$i:1}"
            if [[ "$clean_word" != *"$letter"* ]]; then
                is_pangram=false
                break
            fi
        done
        
        if [ "$is_pangram" = true ]; then
            score=$((score + 7))
            echo "$clean_word ($score points) - PANGRAM!"
        else
            echo "$clean_word ($score points)"
        fi
        
        valid_words+=("$clean_word")

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