הבלוג של ינון פרק

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אתם כבר מכירים את 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.

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

קיבלתם משימה לבנות מוצר של ניהול 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 "טוב תבנה את הדבר הכי פשוט" ולהגיש.

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

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

רגע, מה?

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

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

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

חבר כתב בפייסבוק

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

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

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

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

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

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

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

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

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

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