אייג'נטים אופןסורס, מודלים טובים לעברית, ועוד
תשתיות קוד פתוח לבניית Agents
1. הצורך בארכיטקטורה חזקה וחינמית: אחד החברים ביקש המלצות על פרויקט LangGraph איכותי כנקודת פתיחה. הוא הסביר שלדעתו ReAct (כולל LangGraph) לא נותן תוצאות טובות מספיק עבור agent עם MCP, בעוד ש-Claude Agent SDK מרגיש לו מגביל יתר על המידה וכל עניין ה-tool activation/deactivation עובד לא מספיק טוב, ובעלויות גבוהות.
2. המשתנים שמכריעים ביצועי agent: הביצועים כמעט אינם תלויים בפריימוורק אלא בכמות הכלים, איכות הפרומפטים, ובחירת ה-LLM המתאים. ההמלצה היא לבחון היטב את ההגדרות האלו ולבצע התאמות אינדיבידואליות. הוצגה תבנית בסיסית ל-agent מסוג LangGraph ReAct עם תמיכה ב-MCP, אך הודגש שאין פתרון one-size-fits-all. תמיד דרושה התאמה לדומיין.
3. תלות בדומיין: מניסיונם של המשתמשים, ההגדרה של “תוצאה סבירה” משתנה מאוד בין תחומים – למשל משימות קוד דורשות agent שמסוגל לארגן תכנית כרונולוגית ולבצע צעדים הדרגתיים. חשוב למצוא ארכיטקטורה שניתן להרחיב ולשפר אותה לאורך זמן.
4. המלצות נוספות – deepagents ולוגיקה מבוזרת: ניתנה המלצה חמה על deepagents של LangChain – פרויקט קוד פתוח מתקדם עם ארכיטקטורת agents גמישה ושכבת הפשטה מצוינת, שמאפשרת לבחור ולשנות רכיבים מבלי להסתבך בתשתית עצמה. אפשר לקבל ממנו הרבה השראה למימושים בארץ.
5. גישה לבניית sub-agents והפרדה דינמית של הקשר: אחד המשתתפים שיתף ארכיטקטורה מבוססת LangGraph שבה בכל node מבוצע סינון נוסף: בכל שלב מסננים מידע לא רלוונטי ורק בסוף השלב נותנים ל-agent הגמר לעבוד על סט נקי ורלוונטי בלבד. המתודולוגיה מתאימה לסביבות פרודקשן, במיוחד בפרויקטים עם מידע רב.
🗓️ הדיון המלא התחיל בתאריך: 05.11.25 | 20:05 | LangTalks Community 2
מודלים טובים לעברית + שימוש בכלים
1. שילוב עברית עם Tool Use במודלי שפה: הקבוצה בחנה אילו מודלים יודעים להתמודד היטב עם שפה עברית וגם לבצע tool calling בצורה יציבה.
2. ניסיון מהשטח: Gemini, GPT-5 וגם Sonnet: הובלטו Gemini ו-GPT-5 כמועמדים מובילים לדיאלוגים בעברית ומשימות Tool Use, לצד Sonnet במקרים מסוימים. עם זאת, הובלט שאין תשובה חד-משמעית והבחירה תלויה בפרומפט וסוג המשימה.
3. חשיבות שפת ההוראות לעומת input המשתמש: אחד המשתתפים הדגיש שההוראות למודל כתובות באנגלית ורק הקלט של המשתמש בעברית – כך שאין לראות בביצועים בעברית ערובה לטיפול טוב ב-instructions מורכבות. חשוב לבדוק היטב באיזה שלב טמונה הבעיה.
🗓️ הדיון המלא התחיל בתאריך: 31.10.25 | 15:13 | LangTalks Community 3
symlinks ונתיבי קבצים ניטרליים ב-repos צוותיים
1. ערך השימוש ב-symlink: מפתחים שונים עובדים עם מבני תיקיות שונים במחשב האישי, מה שיוצר תלות בנתיבים אישיים בתוך סקריפטים ו־config. שימוש ב-symlink מאפשר להגדיר נתיב לוגי אחיד שהסקריפטים מצביעים אליו, בעוד שכל מפתח מפנה את ה-symlink לנתיב האמיתי שלו. כך כולם שומרים על סביבת עבודה אישית — בלי לשבור את הסקריפטים ובלי להכניס נתיבים פרטיים ל-repo.
2. שקיפות ושיתוף פעולה ללא תלות במכונה: הגישה הזו הופכת את כללי ה-git, האוטומציות והקונפיגים לאגנוסטיים לחלוטין למבנה תיקיות או למערכת ההפעלה של כל מפתח. אין צורך ליישר קו על נתיב קבוע או תיקייה משותפת כדי שהפרויקט יעבוד. זה מונע זליגה של מידע אישי לקבצי הגדרות ושומר על repo נקי ואחיד לכל הצוות.
3. פחות תחזוקה, יותר גמישות: כשמבנה הפרויקט משתנה, או כשמפתח חדש מצטרף, אין צורך לעדכן קבצי config או לשבור סקריפטים לכולם. כל מפתח פשוט מעדכן את ה-symlink שלו פעם אחת — וזהו. הגמישות הזו מפחיתה תלות בתשתית המקומית, מגינה על ה-repo משינויים מיותרים ולמעשה יוצרת שכבת הפשטה שמייצבת את סביבת העבודה של הצוות כולו.
🗓️ הדיון המלא התחיל בתאריך: 27.10.25 | 18:56 | LangTalks - AI driven coding
סיכום מיטאפ LangTalks בנושא AI Driven SDLC
1. מדידה חכמה ו-AI Guilds כמנועי שינוי: החברות המצליחות לא מסתפקות ב-adoption rates בלבד – הן מודדות קורלציה בין טוקנים לקוד שנכנס לפרודקשן, בוחנות מי מג’נרט הרבה אבל לא ממרג’ ומנסות להבין למה. במקביל, הן מקימות AI Guild כדרך היחידה שעובדת להפצת ידע וכלים אורגנית בין צוותים (בעיקר סביב קודינג, אבל לא רק). בלי מדידה אין שיפור, ובלי גילדה אין העמקה.
2. סוכנים אוטונומיים – לא רק למפתחים: החלק המשמעותי והמפתיע הוא שאנשי מוצר, מעצבים ואנליסטים מסוגלים כיום לפתוח PRs למשימות לא מורכבות בעזרת AI agents. זו לא רק בעיה טכנולוגית אלא שינוי תרבותי שמרחיב את מעגל התורמים לקוד הפרודקשן.
3. חשיבה מחדש על SDLC – מעבר לקודינג: החברות שמצליחות לא מסתכלות רק על coding. הן מיישמות AI בכל שלבי מחזור החיים: Code Review, Design Review, כתיבת specs, ניתוח דרישות ומחקר הקוד. המסר המרכזי מהמפגש: בעתיד הלא רחוק כמעט כל הקוד ייכתב על ידי AI, אבל רק החברות שיעבדו נכון את המסלול הזה יגיעו לשם לפני המתחרים. בהשתתפות 200 מנהלי פיתוח, פאנליסטים מ-Gloat, monday.com ו-fintastic, וחסות AWS ו-Sap.Hi.
הצטרפות לקבוצת הוואטסאפ החדשה שלנו בנושא: כאן.
📖 נושאים נוספים שעלו 📖
בדיקות אוטומטיות לקוד שנוצר ב-AI: הגישה המומלצת: unit tests אוטומטיים + contract tests לכל PR שנוצר על ידי agent, במקום לסמוך על code review ידני בלבד.
אופטימיזציית עלויות טוקנים: שימוש ב-prompt caching (Claude), response streaming, ובחירה דינמית בין מודלים (Haiku לטאסקים פשוטים, Sonnet למורכבים) יכולים לחסוך עשרות אחוזים מעלויות ה-LLM.
Security scanning לקוד AI-generated: כלים כמו Semgrep ו-Snyk יכולים לזהות בעיות אבטחה (SQL injection, XSS, secrets בקוד) שה-LLM יוצר לפני שנכנס לפרודקשן.
Brownfield migration strategy - כשמטמיעים AI בפרויקט קיים: התחילו מ-specs ו-documentation generation, עברו לtests, ורק אז לקוד. לא להפך.





