https://chatgpt.com/share/69664d32-ad5c-8009-b4b1-b1e892858436

קראו את כל תשובות ה AI לפרומפטים שלי, בצעו את 10 המשימות שהוא כתב וספרו לי אחרי זה מה ההרגשה שלכם לגבי git worktree והיכולת להשתמש בהם.

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

https://tocode.ravpage.co.il/tocodeai

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

scope :latest, -> { order(created_at: :desc) }

ואז פקודת ה order by תצורף לשאילתה. עד לפה הכל קל, עכשיו נסתכל על סקופ יותר מסובך:

scope :with_questions, ->() {
  where("questions is not null and cardinality(questions) > 0")
}

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

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

MyModel.joins(:other_table).with_questions

ונדמיין שגם ל other_table יש עמודה בשם questions. עכשיו מקבלים את ה SQL:

SELECT "my_models".* FROM "my_models"
INNER JOIN "other_table" ON "other_table".my_model_id = "my_models".id
WHERE questions IS NOT NULL AND cardinality(questions) > 0

ואם לשתי הטבלאות יש עמודת questions נקבל שגיאה:

ERROR:  column reference "questions" is ambiguous

התיקון הוא פשוט אבל הכי טוב לזכור את הטיפ הכללי - כשכותבים scope שכולל SQL כדאי לצרף את שם הטבלה, כלומר נגדיר את הסקופ:

scope :with_questions, ->() {
  where("quizzes.questions IS NOT NULL AND cardinality(quizzes.questions) > 0")
}

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

זה הריפו של הדפדפן שהם יצרו ללא מגע יד אדם:
https://github.com/wilsonzlin/fastrender

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

ברמת הקומיטים מספיק לפתוח אחד לדוגמה כדי להבין שמשהו חשוד פה. פתחתי את קומיט 87f1c6b. הודעת הקומיט אומרת:

fix: resolve merge markers and restore vm-js build
- Remove unresolved merge conflict markers across fastrender + vendored vm-js.
- Fix vm-js exec.rs issues uncovered after cleanup (async yield* arm, NamedEvaluation super prop, unused binding).
- Drop duplicate Range native getter in window_realm.rs (required by conflict-marker guard).

This keeps scripts/check_no_conflict_markers.sh and  passing.

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

אבל זה לא מה שחשוב.

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

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

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

דברים שקרסר לא הציע למיכאל
חבר כתב בפייסבוק

> שלחתי את Cursor לדבר עם עצמו והוא הביא את האתר לציון 100. אמרתי לו: תסרוק את האתר, תזהה הזדמנויות לשיפור, תתקן ותסרוק שוב. תחזור על זה עד שהציונים טובים.

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

לקחים? אני לא בטוח, הנה כמה מחשבות שלי אחרי הקריאה. לא ראיתי את הפרויקט או את התיקונים של קרסר:

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

2. רק בגלל שמישהו מפרסם שקרסר הצליח להביא את האתר שלו לציון 100 ב Lighthouse לא אומר שהאתר שלו נטען יותר מהר או שאתם יכולים להגיע לתוצאה דומה על האתר שלכם. בביצועים יש כלל שהרבה יותר קל להגיע לשיפור של 90% מאשר לשיפור של 3% כי אם הורדת את זמן הטעינה ב 90% הקוד המקורי היה די גרוע. בדיקת ביצועים אמיתית דורשת שמירת זמני טעינה של גולשים אמיתיים וניתוח לאורך זמן.

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

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

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

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

איך מחשבים Embedding
מודל שפה גדול מייצג שפה באמצעות אוסף של וקטורים. בממשק שיחה המודל חוזה את המשך השיחה באמצעות מיפוי:

1. הקלט (הפרומפט) ממופה לוקטור בתוך המודל.

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

3. מוסיפים את הוקטור שמצאנו לפרומפט וחוזרים בלולאה.

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

בשביל הדוגמה התקנתי על המחשב ollama והפעלתי מודל שנקרא nomic-embed-text:v1.5. עכשיו אני יכול משורת הפקודה לחשב וקטורים של הטמעה לכל קלט שארצה לדוגמה:

$ ollama run nomic-embed-text:v1.5 "hello"
[0.017934207,-0.005861857,-0.17534052,-0.013759711,...

$ ollama run nomic-embed-text:v1.5 "bye bye"
[0.059325065,-0.0042824764,-0.13401125,-0.009296248,0.010595661,0.062132772,0.008114117,0.049777295,-0.022414487 ...

כל וקטור במודל nomic-embed-text הוא בגודל 768 ערכים.

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

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

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

3. בלוג יכול להציג "פוסטים קשורים" כשקוראים פוסט.

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

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

קיימות מספר שיטות לחישוב מרחק בין וקטורים בבסיס נתונים וקטורי:

1. L2 distance
2. inner product
3. cosine distance
4. L1 distance
5. Hamming distance
6. Jaccard distance

נתתי ל ChatGPT ליצור הסבר מלא בעברית עם דוגמאות על כל שיטה מוזמנים להעיף מבט:

https://chatgpt.com/share/696b6177-acdc-8009-bf4a-e33a2b416a8b

אני עד עכשיו עבדתי עם cosine distance והתוצאות היו טובות.

דוגמה: מציאת פוסטים קשורים באמצעות Embedding
נמשיך ונראה איך היינו מוסיפים תיבת "פוסטים קשורים" לבלוג בעזרת Embedding. תחילה נשים לב שבניגוד למודלי שיחה, מודלי Embedding מוגבלים לפרומפטים הרבה יותר קצרים לדוגמה מודל nomic‑embed‑text שדיברנו עליו מוגבל ל 8192 טוקנים. רוב הזמן יהיו לנו קלטים ארוכים בהרבה ולכן נצטרך לשבור את הקלטים ל Chunk-ים. בדוגמת חיפוש פוסטים קשורים אני אבצע:

1. פיצול כל פוסט לקטעים קטנים אותם אפשר להעביר למודל ה embedding.

2. שמירת ה embedding של כל קטע בבסיס נתונים וקטורי.

שיחות הזויות עם AI (חלק 28)
- הי קלוד יש לי בדיקה שנכשלת יכול לבדוק למה?
- בטח זה ברור, הבדיקה נכשלת כי אתה מפעיל את הפונקציה X פעמיים. תראה הפונקציה יוצרת נתונים ב DB, חלק מהנתונים צריכים להיווצר פעם שניה אבל יש גם טבלה של נתונים גלובאליים שצריכים להיווצר רק פעם אחת. ההפעלה השניה נכשלת ומכשילה את הבדיקה.
- אלוף אתה קלוד עכשיו תקן את זה
- בטח מיד מתקן! אני אעדכן את קוד הפונקציה לקוד יותר בטיחותי שיבדוק אם הנתונים הגלובאליים קיימים לפני שהוא יוצר אותם.

רגע, מה?

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

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

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

איך ניגשים לזה?

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

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

I'm building a TODO editor allowing users to create todos items, edit todos, delete todos and reorder todos in the list with optimistic updates.

When users perform multiple actions before server had a chance to update the system has strange bugs, for example: 

1. trying to edit a todo that wasn't yet created 2. trying to reorder todos when server state is different than the optimistic state

Suggest 4 possible architectures to combine optimistic updates and editing, order from simple to complicated. For each architecture explain what API calls are made and when and how it deals with user editing faster than server updates

ואתם יכולים לראות את השיחה כאן:
https://chatgpt.com/share/696e35f8-9d68-8009-a35a-26169c8ccbe9

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

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

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

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

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

4. הנאה - אין הרבה כיף בלכתוב פתרון עם באגים שעובד פחות טוב ממה ש AI היה כותב או להגיד ל AI "טוב תבנה את הדבר הכי פשוט" ולהגיש.

אם אין לכם זמן לכתוב מימוש נכון, איפה תמצאו זמן לכתוב את המימוש פעמיים?

טיפ גיט: שינוי מקומי בלי קומיט על קבצים במעקב
אתם כבר מכירים את gitignore ואת .git/info/exclude וזוכרים את הבעיה המעצבנת בשניהם: מנגנון ההתעלמות מאפשר להתעלם מקבצים קיימים על הדיסק שאינם בריפו. אבל מרגע שקובץ נמצא בריפו לא משנה כמה פעמים תכתבו אותו ב gitignore השינויים בו תמיד יופיעו ב status. קובץ שנמצא במעקב עוקף את ה gitignore.

אז מה עושים עם שינויים מקומיים בקבצים במעקב שלא צריכים להיכנס לריפו? לדוגמה שינוי בקובץ docker-compose שמשנה את מיפויי הפורטים ספציפית על המחשב שלכם.

התשובה נקראת skip worktree bit ואפשר לקרוא עליה בדף התיעוד man git-update-index. בקצרה זה מתג שנשמר מקומית אצלכם ואומר לגיט לשמור על השינויים המקומיים שלכם כל עוד אפשר. אנחנו מדליקים אותו לקובץ מסוים עם:

git update-index --skip-worktree docker-compose.yml

ומבטלים עם:

git update-index --no-skip-worktree docker-compose.yml

דוגמה? בטח. ניצור ריפו עם שני קבצים:

$ git init .
$ date > a.txt
$ date > b.txt
$ git add .
$ git commit -m 'initial commit'

עכשיו נשנה את b.txt ונראה בסטטוס את השינוי:

$ date > b.txt
ynonp@ynons-MacBook-Air ~/tmp/blog/skipworktree (main*) $ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

נדליק את skip worktree bit:

$ git update-index --skip-worktree b.txt
ynonp@ynons-MacBook-Air ~/tmp/blog/skipworktree (main) $ git status
On branch main
nothing to commit, working tree clean

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

$ git restore b.txt
error: pathspec 'b.txt' did not match any file(s) known to git

ב ls-files לעומת זאת הקובץ כן מופיע:

$ git ls-files
a.txt
b.txt

ואם נוסיף -v נוכל לראות שהוא במצב S כלומר skip-worktree:

$ git ls-files -v
H a.txt
S b.txt

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

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

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

אם גם אתם שמעתם דברים דומים בבקשה קחו אוויר. בעבודה עם ג'וניורים הבעיה שלנו היא עודף שימוש בכלי AI:

1. ג'וניורים נותנים ל AI לכתוב קוד ושולחים PR בלי להבין מה בוצע.

2. ג'וניורים חושבים שהם מבינים אבל בעצם קראו רק את מה שה AI כתב ולא אימתו את זה מול התיעוד הרשמי.

3. ג'וניורים לא עצרו לחפש פתרונות יעילים יותר ולא השוו בין מספר אופציות.

4. ג'וניורים לא ראו את בעיות האבטחה שהם הכניסו למערכת.

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

דוגמה קטנה מעולם שיפור ביצועי מערכת Full Stack - הרבה יותר חשוב להבין לעומק מה גורם לאיטיות ומה ה Trade Offs הרלוונטים מאשר להבין איך לחבר את לייטהאוס ב MCP כדי שקלוד ישפר ביצועים באוטומט.

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

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

יצירת פרויקט זדוני
הקובץ tasks.json נועד כדי לאפשר למפתחים להריץ דברים בצורה קלה מתוך העורך, למשל להריץ קומפילציה, משיכת קוד משרת מרוחק או בדיקה אוטומטית. בואו ננסה את זה, אני יוצר תיקייה חדשה ופותח אותה ב VS Code ואז יוצר תיקיה חדשה בשם .vscode ובתוכה קובץ חדש בשם tasks.json. בתוך הקובץ אני כותב את הקוד:

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Ynon Run Tests",
      "type": "shell",
      "command": "echo Run Tests"
    }
  ]
}

שומר ולוחץ Ctrl+Shift+P בשביל להכנס לתפריט ואז בוחר Tasks: Run Task. יופיע לי דיאלוג לבחירת משימה מהירה ואני יכול לבחור את המשימה שלי משם ולראות את הסקריפט שלי רץ. עד פה הכל קל.

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

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Ynon Run Tests",
      "type": "shell",
      "command": "date >> tests.txt",
      "problemMatcher": [],
      "isBackground": true,
      "presentation": {
        "reveal": "never",
      },
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]
}

הגדרת problemMatcher ריק מבטלת את הדיאלוג ששאל איך להציג שגיאות, הגדרת isBackground מאפשרת למשימה לרוץ ברקע, הגדרת reveal: never מונעת את הצגת המסוף עם פלט המשימה ו runOn: folderOpen אומרת שהמשימה תרוץ כל פעם שפותחים קובץ מתוך התיקייה.

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

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

כמה דוגמאות לדברים שלא עובדים במצב המוגבל:

1. הצגת תמונות במסוף

2. הצגת היסטוריה במסוף

3. תיקון מהיר לפקודות מסוף

4. שימוש ב Skills בעבודה עם AI

5. שימוש בקבצי Agents.md בעבודה עם AI

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

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

איך אתם רגילים לעבוד? אפשר להגיב במייל או בטלגרם.

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

אחד השימושים למנגנון ה Embedding נקרא RAG או Retrieval-augmented generation. הרעיון הוא שאחרי שיצרנו וקטורי Embedding מכל הפוסטים נוכל ליצור וקטור כזה גם משאלה של משתמש ואז נוסיף את הפוסטים הרלוונטים לפרומפט בצורה אוטומטית.

בואו נראה איך זה עובד בעזרת פרויקט לדוגמה.

התקנה והפעלה
בקישור:

https://github.com/ynonp/embedding-demo

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

$ docker run --rm -p 5454:5432 -e POSTGRES_PASSWORD=password pgvector/pgvector:pg18-trixie

תצטרכו גם את ollama מותקן על המחשב עם מודל האמבדינג nomic-embed-text-v2-moe:latest. לאחר מכן אפשר ליצור את הנתונים בבסיס הנתונים לדוגמה עם הפקודות:

$ ./bin/rails db:migrate
$ ./bin/rails r script/scrape_data.rb
$ ./bin/rails r script/index_posts.rb

אחרי הפעלת שלושת הפקודות תקבלו בבסיס הנתונים טבלת פוסטים עם 200 פוסטים אחרונים מהבלוג פה, ולכל פוסט יהיה וקטור Embedding שמתאים לו שחושב באמצעות המודל nomic-embed-text-v2-moe:latest.

חישוב מרחק מפרומפט
נפתח את הקובץ app/models/post.rb ושם נמצא את הפונקציה cosine_distance_from_prompt:

  def cosine_distance_from_prompt(prompt, model: EMBED_MODEL)
    return nil unless embedding.present?

    # Calculate embedding for the prompt
    embed = RubyLLM.embed(prompt, provider: :ollama, model:, dimensions: 768)
    prompt_embedding = embed.vectors

    # Calculate cosine distance using PostgreSQL's <=> operator
    conn = self.class.connection.raw_connection
    result = conn.exec_params(
      "SELECT embedding <=> $1::vector AS distance FROM posts WHERE id = $2",
      [prompt_embedding, id]
    )

    result.first['distance'].to_f
  end

המתודה מקבלת פרומפט, מחשבת וקטור אמבדינג ממנו ומחזירה את המרחק מהפרומפט לאותו פוסט. הנה כמה דוגמאות הפעלה עם פוסטים נבחרים והפרומפט "סכנות אבטחה ב vs code":

3.3.5 :004 > Post.find_by(slug: '2026-01-vscode-tasks').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.6270134320979381

3.3.5 :005 > Post.find_by(slug: '2026-01-basic-knowledge').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.7205912733782678

3.3.5 :006 > Post.find_by(slug: '2026-01-learn-worktree-with-ai').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.658548735705814

3.3.5 :008 > Post.find_by(slug: '2026-01-aoc2025day8').cosine_distance_from_prompt("סכנות אבטחה ב vs code")
 => 0.6936170916427378

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

העברת מידע נוסף לסוכן
הסוכן כתוב ב Ruby ומשתמש בספריית ruby_llm. בשביל לשלוח שאלה ל AI בספריה זו כל מה שצריך זו קריאת פונקציה אחת:

chat = Chat.create(model: "gpt-5-mini")
chat.ask "מהן סכנות האבטחה ב VS Code"

מפעילים את הפרויקט עם ./bin/dev, נכנסים ל localhost:3000/chats, לוחצים על הכפתור לפתיחת שיחה חדשה ומקלידים את הפרומפט ונוכל לראות את התשובה הבסיסית של הסוכן.

הפונקציה הבאה ברשימה עדיין במודל post אחראית על חיפוש פוסטים שרלוונטים לפרומפט מסוים:

  def self.find_relevant_for_prompt(user_prompt, limit: 5)
    # Calculate embedding for the prompt
    embed = RubyLLM.embed(user_prompt, provider: :ollama, model: EMBED_MODEL)
    prompt_embedding = embed.vectors

    # Search database directly using vector search
    conn = connection.raw_connection
    conn.exec_params(
      "SELECT *, embedding <=> $1::vector AS distance FROM posts ORDER BY embedding <=> $1::vector LIMIT $2",
      [prompt_embedding, limit]
    )
  end