ToCode

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

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

חיפוש פוסטים דומים עם 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 של כל קטע בבסיס נתונים וקטורי.

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

טיפ ריילס: מתי להוסיף את שם הטבלה ל 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")
}

https://chatgpt.com/share/69664d32-ad5c-8009-b4b1-b1e892858436 קראו את כל תשובות ה AI לפרומפטים שלי, בצעו את 10 המשימות שהוא כתב וספרו לי אחרי זה מה ההרגשה שלכם לגבי git worktree והיכולת להשתמש בהם. אחרי זה מוזמנים להצטרף לוובינר בחמישי הקרוב, שם אדבר גם על הדוגמה הזאת וגם על רעיונות נוספים ללימוד באמצעות AI, כולל על השאלות מה ללמוד ואיך ללמוד. אפשר להצטרף כאן: https://tocode.ravpage.co.il/tocodeai

בואו נלמד Git Worktree בעזרת AI לימוד באמצעות AI הוא נחמד כי ה AI מסוגל להתאים את עצמו לסגנון שלנו ולייצר בדיוק את המידע שאנחנו צריכים בשביל להבין את הנושא. מצד שני קל לטעות ולקבל ממנו חומר יותר מדי קל לעיכול כך שנרגיש שאנחנו מבינים משהו למרות שבפועל רק קראנו וכל הידע יישכח כמה דקות אחרי. אני רוצה בפוסט הזה להראות דוגמה ללימוד אפקטיבי בעזרת AI, לתעד את התהליך ולשים לב אם דברים מסתבכים ואיפה. פרומפט 1 - הצגת הנושא החלטתי ללמוד Git Worktree כי VS Code התחיל להקפיץ לי הודעות שסוכן ה AI שלו צריך לעבוד ב Worktree והוא רוצה לדעת מה לעשות עם השינויים שלי לפני שהוא מתחיל לעבוד. אני מתחיל עם הפרומפט (בעברית): > כתוב פוסט לבלוג של tocode המסביר מה זה git worktree ואיך זה עוזר לסוכני AI שעובדים על הפרויקט התשובה הסבירה לי בגדול מה זה worktree ואיך זה עוזר לסוכני AI וגם כללה דוגמת הרצה קצרה שהסבירה לי איך ליצור worktree משורת הפקודה. זה לא רע. הוא סיים בהצעה: אם רוצים, אני יכול גם לכתוב גרסה קלה יותר לקריאה עם דיאגרמות והסבר ויזואלי, שמתאימה במיוחד לבלוג של ToCode עם קטעי קוד ואיורים שמראים worktree בפעולה. זה יהפוך את הפוסט ליותר “חי” ואינטראקטיבי. ואני עונה: > כן תוסיף בבקשה דיאגרמות והסברים אהבתי גם שהוא תרגם את branch ל"סניף" (אבל זה כבר סיפור אחר):

/project
 ├── main/       <- סניף main
 └── experiment/ <- סניף experiment

אפשר לראות את השיחה בלינק הזה: https://chatgpt.com/share/69664d32-ad5c-8009-b4b1-b1e892858436 פרומפט 2 - מעבר מהפרטי לכללי מתוך השיחה הקודמת הבנתי למה VS Code ממליץ לי להשתמש ב Worktree אבל עדיין לא היה מספיק ברור השימוש הכללי בפיצ'ר זה - מאיפה הוא נולד, האם יש עוד מצבים בהם נרצה להשתמש בו, חוץ מיצירה של worktree מה עוד אפשר לעשות עם זה. אפשר להגיד שהגעתי לשיחה עם נקודת כניסה מסוימת ועכשיו אני רוצה לקחת צעד אחורה ולהרחיב את ההבנה. אני ממשיך עם הפרומפט הבא: > כתוב מדריך טכני שמסביר לעומק: > 1. מה זה git subtree > 2. מה המגבלות שלו > 3. איך הוא ממומש, איך זה עובד מתחת לפני השטח > 4. מהן כל האפשרויות לכתיבה משורת הפקודה כולל אפשרויות שאנשים לא מכירים > 5. באיזה עוד מקרים חשוב להשתמש בו > 6. באיזה מקרים אנשים משתמשים בו בטעות והיה עדיף להם להשתמש במנגנונים אחרים עכשיו השיחה הלכה לכיוונים מאוד מעניינים ולא תמיד נכונים, למשל מהר מאוד אני מזהה משפט חשוד ברשימת המגבלות של subtree: > שכפול נתונים כל commit של סאבטרי נכנס למאגר הראשי. אם המאגר החיצוני ענק, המאגר הראשי גם הוא מתנפח. רגע, מה? ברור שכל קומיט יישלח למאגר הראשי. זה לא אומר שנתונים שוכפלו. המטרה שלנו בשלב הזה היא לזהות את הבעיות האלה, כי דווקא דרך הוויכוחים וחוסר ההסכמה עם ה AI אנחנו יכולים לשפר את ההבנה שלנו. כל פעם שמצאנו משהו אפשר לכתוב ל AI כדי להרחיב עליו לדוגמה: > כתבת "שכפול נתונים" כל commit של סאבטרי נכנס למאגר הראשי. אם המאגר החיצוני ענק, המאגר הראשי גם הוא מתנפח. זאת לא המשמעות של שכפול נתונים - הקומיט לא משוכפל לכמה מאגרים הוא פשוט נשמר פעם אחת במאגר הראשי פרומפט 3 - זמן לעבוד אחרי שקראתי והתווכחתי מגיע הזמן לעבוד. אפשר באותה שיחה או בשיחה חדשה להפוך את כל הידע לתרגול אינטרקטיבי: > צור דף תרגילים בסגנון התרגולים באתר טוקוד שלוקחת אותי צעד צעד ממתחיל עד למישהו שמבין טוב איך להשתמש ב worktree > כל תרגיל צריך להיבנות על ולהרחיב את הקודם והתרגילים יהיו ברמת קושי עולה > את התרגילים אני אבצע על ריפו שלי ובסוף כל תרגיל כתוב לי איך אני בודק את עצמי > דף התרגול מכיל 10 תרגילים > בתרגילים יש להתמקד בתרחישים מהעולם האמיתי, לדוגמה לדמות מספר סוכני קידוד שעובדים במקביל על פרויקט או משיכה של גרסה ובנייתה בלי לפגוע בקבצים שכבר יש לי בתיקיית העבודה זאת רשימת התרגילים שנוצרה: 1. יצירת worktree בסיסי 2. עבודה מקבילה על שני סניפים 3. משיכת שינויים מסניף חיצוני בלי לפגוע בקבצים 4. מחיקת worktree 5. יצירת מספר worktrees מקבילים 6. סנכרון שינויים מ־feature2 ל־main 7. עבודה על סניפים מרוחקים במקביל 8. ניהול קונפליקטים בין worktrees 9. שימוש ב־worktree עם תיקיות Nested 10. תרחיש סוכני AI מורכב עכשיו אתם אם עדיין לא נכנסתם לשיחה התחנה הבאה היא הקישור הזה:

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

נקודה שניה היא הבנת אותם פתרונות. זה שיש 10 פתרונות לבעיה לא אומר שכולם טובים ושכולם מתאימים לאותן נסיבות. פה בהחלט אפשר להתאמן יחד עם ה AI ולשחק "מה קורה אם" - מה קורה אם השורות מאוד ארוכות? מה קורה אם קריאה מקובץ היא איטית מאוד כי הקובץ נמצא על כונן רשת? מה קורה אם הדרישות ישתנו ונצטרך לספור שורות בלי שורות כותרת או בקובץ בפורמט אחר? מה החסרונות של כל גישה? האתגר שלנו הוא להתנתק מתפיסת העולם של "איך פותרים את הבאג" ולעבור לתפיסה של "מה הסיפור פה" ו"מה הסיבות הבסיסיות שגרמו לבאג". נקודה שלישית היתה תשומת לב לפרטים. אני חושב שזה משהו שקשה מאוד להתאמן עליו אבל הוא הכרחי לכל עבודת פיתוח ואולי פה ה AI דווקא יכול להיות חבר טוב ולשחק את פרקליט השטן. ככל שאני עובד יותר עם AI אני מגלה שאני קורא קוד בזכוכית מגדלת הרבה יותר מבעבר כי יש לי את מי לשאול. בכל שורת קוד אני עוצר לשאול "מה עושה השורה הזאת כאן", "איך עוד אפשר היה לכתוב את זה", "מה ההשלכות של השורה הזאת על הביצועים של המערכת", "איזה בעיות אבטחת מידע היא עלולה ליצור", "איך בודקים אותה?", "מה יקרה אם דרישה מסוימת תשתנה", "האם יש דרך חדשה יותר לכתוב את הקוד הזה", "האם הייתי יכול לחשוב על אבסטרקציה אחרת שהיתה גורמת לשורה הזאת להיראות אחרת". ככל שאני מבלה יותר זמן עם הקוד כך אני שם לב ליותר פרטים, וככל שאני מקפיד לחזור על זה עם כל קוד שאני קורא כך אני שם לב לפרטים מהר יותר. נקודה רביעית היתה טעם טוב ופה עליי לאכזב שוב את אלה שמחפשים פתרונות מהירים. טעם טוב לוקח שנים לפתח. עלינו להיות מעורבים במערכות קיימות, לקרוא קוד, לקרוא ספרים על קוד, להבין את השיקולים בעד או נגד שיטת כתיבה מסוימת. זו דרך ללא סוף. הנקודה החמישית היתה מודעות לאילוצים ולמגבלות ופה האימון שלנו הוא שוב משחק בכאילו ויציאה מכסא המפתח כדי להבין טוב יותר את החברה והמודל העסקי. מפתחים טובים יודעים איזה פיצ'רים הולכים להגיע לפני שפרודקט העביר אותם כי אנחנו מבינים לאן דברים הולכים. בדוגמה דומה מישהו שאל בפייסבוק "עברתי מכתיבת אתרים ב Wordpress ל next.js ועכשיו חשבון האחסון שלי קפץ, מה עושים?". בתור מפתחים שמודעים למגבלות אנחנו רוצים לשים לב לעלויות האחסון כבר בשלב הפיתוח, להתלבט על SEO וזמני טעינה עם כל שורת קוד. וכן לשלב את כל זה בשיקולים על לוחות זמנים ויכולת לעבוד בצוות או בשיתוף פעולה עם צוותים אחרים בחברה. טריק קטן שעוזר להשתפר גם בתשומת לב לפרטים וגם במודעות לאילוצים הוא ממש לכתוב אחרי כל פיצ'ר מה אתם חושבים שיהיו הפיצ'רים הבאים, באיזה מצבים אתם חושבים שהקוד הזה הולך להשתנות. לכתוב מכריח אותנו לחשוב ואחרי זה תמיד כיף לפתוח את הפתקים האלה ולהבין כמה היינו בכיוון (ואם לא, לנסות לחשוב איך לשפר את התחזיות לפעם הבאה). נקודה שישית וסופר חשובה היא החשיבה מחוץ לקופסה. האתגר שלנו הוא להסתכל על בעיה ולהבין איזה דברים היו יכולים להיות אחרת כדי שהבעיה הזאת בכלל לא תהיה בעיה. זה היה הטריק של אדם וואתן עם Tailwind - אדם הסתכל על אלמנט HTML ולא ידע להגיד איזה CSS משפיע עליו, הוא הסתכל על קוד ה CSS שלו ולא ידע להגיד איזה חלקים בו בכלל פעילים. בעוד ש AI היה עשוי להציע לסרוק את המערכת ולמפות מה קשור למה אדם הסתכל צעד קדימה והבין שהפתרון הוא לכתוב את כל ה CSS בתוך קוד ה HTML. אבל אדם לא היה לבד, באותו זמן שהוא יצר את טיילווינד זו היתה תקופה של פריחה לספריות של CSS-In-JS שהציעו לכתוב את קוד ה CSS בתוך קוד הקומפוננטות של ריאקט. חשיבה מחוץ לקופסה דורשת גם היא שינוי תפיסה, במקום לנסות לפתור את הבעיה בכלים הקיימים לחפש כלים אחרים שיגרמו לבעיה לא להתקיים. האתגר העיקרי - מוטיבציה תמיד קשה לדבר על העתיד אבל היציבות של סוכני הקידוד בהיבט של מנגנון קבלת ההחלטות שלהם, מנגנון שלא השתנה מאז הגרסה הראשונה של ChatGPT, מלמדת אותנו שמפתחים אנושיים ימשיכו להיות קריטיים לתעשייה לפחות בעשור הקרוב וכנראה הרבה מעבר. אבל היכולות המדהימות של סוכני הקידוד בייצור קוד ובבחירת פתרון עובד פועלות לרעתנו. מתכנתים בתחילת הדרך מסתכלים על העולם ושואלים את עצמם "אם כל מה שאני יכול לעשות ה AI עושה טוב יותר, בשביל מה להתאמץ?". אני מבין את זה. פעם לימוד פייתון נתן לך יכולות מסוימות. אחרי שלמדת פייתון יכלת לכתוב סקריפט שסופר שורות בקובץ. היום? אפשר לכתוב את הסקריפט הזה בלי לדעת פייתון כלל. אפשר לכתוב משחקים בלי לדעת כלום על פיתוח משחקים, אתרי אינטרנט בלי לדעת כלום על HTML. איך נשכנע אנשים ללמוד תכנות אם אין שום "גמול" מיידי בסוף הקורס, אם הלימוד לא ייתן להם מיומנות חדשה?

והנה המשחק - גם אם סוכן הקידוד יכול לקחת כל דרישה שלי בנפרד ולתת לה פתרון מושלם (זה עדיין לא המצב אבל אפשר לדמיין עתיד בו זה יהיה), עדיין אין דרך לבנות פתרון אחד שיפתור את כל הדרישות יחד. קבלת החלטות הופכת הרבה יותר מסובכת ככל שאנחנו מדברים על מערכות גדולות יותר. בגלל שאין תשובה נכונה, בגלל שאין פתרון בית ספר, אנחנו חייבים להבין את האילוצים והאפשרויות הרבה יותר לעומק. במערכת אמיתית לא נוכל להגיד לסוכן קידוד "תכתוב פתרון מאובטח עם ביצועים טובים", כי המלים האלה לא אומרות כלום. יותר מזה, שום סוכן קידוד לא יוכל לחשוב מחוץ לקופסה כי מנגנון קבלת ההחלטות של סוכני קידוד מתוכנן להציע את הפתרונות ההגיוניים ביותר, וחשיבה מחוץ לקופסה היא בדיוק החיפוש אחרי הפתרונות שלא נראים הגיוניים. סוכני קידוד לעולם לא היו יכולים להמציא את Rails למרות ש Rails הופך את העבודה שלהם להרבה יותר קלה. כש DHH המציא את ריילס הוא היה תקוע בין פרויקטי PHP מבולגנים ורצון ללמוד רובי. לסוכן קידוד אין רצון ללמוד שום דבר ואל מול פרויקט מבולגן הוא רק ינסה לשמור על תאימות אחורה ולאמץ את הבלאגן גם לקוד החדש. פה המקום לפתוח סוגריים ולהתייחס להערה שאני שומע מדי פעם שאומרת "אולי כבר לא צריך חדשנות". יש לנו ריילס ויש לנו next.js ויש לנו ריאקט ו vue ויש לנו Web Assembly וגם Rust ו Docker. די מספיק. חדשנות או אבסטרקציות מאפשרות לנו לכתוב מערכות גדולות יותר בפחות קוד, אבל ל AI אין בעיה של כמות קוד. אפשר לזרוק הכל ולתת ל AI לכתוב כל מערכת מאפס באסמבלי. התשובה שלי לזה היא לא אידאולוגית אלא אמפירית. עד היום לא ראיתי שום ראיה שסוכני קידוד מסוגלים להתמודד עם מערכות תוכנה בלי אבסטרקציות. למעשה בעבודה מאוד אינטנסיבית שלי עם סוכני קידוד אני רואה שוב ושוב את אותן תבניות - כשהאבסטרקציות טובות הסוכן נותן תוצאות יעילות ובונה קוד טוב. כשהאבסטרקציות גרועות או לא מספיק טובות הקוד שהסוכן יכתוב יהיה גרוע ולא יעבוד. זה לא סתם ש Lovable נותנים לסוכן שלהם תבנית בסיס וספריות קוד מובנות ולא מבקשות ממנו לבנות כל מערכת מאפס. אולי בעתיד נראה את סוכני הקידוד המופלאים שמצליחים לבנות מערכות מורכבות ללא אבסטרקציות וללא חלוקה לשכבות, כרגע אנחנו בכלל לא בכיוון לשם. איך מתאמנים על קבלת החלטות טובות בתוכנה זיהיתי קודם שש נקודות שעוזרות ליכולת לקבל החלטות טובות יותר. בואו נפתח אותן כדי להבין איך להתאמן על כל אחת. התחלנו עם היכרות עם פתרונות קיימים. זה נשמע מוזר בעידן ה AI כי בעצם ה AI יכול להציג לי כמה פתרונות שאני ארצה לכל בעיה אז בשביל מה אני צריך להכיר אותם, אבל הסיפור פה מטעה. ה AI מציג את הפתרונות הצפויים ואת אלה שאני מבקש ממנו, גם אם זה לא נראה שביקשתי. במילים אחרות הפתרון שה AI יציג יהיה הפתרון שהכי מתאים לפרומפט שכתבתי לפי נתוני האימון של ה AI ובאיזושהי הסתברות ממושקלת. כדי לקבל יותר פתרונות אני צריך או לשאול את אותה שאלה שוב ושוב מספיק פעמים עד שפתרון אחר יעלה בגורל, או מה שיותר פרקטי לשאול שאלה אחרת שעבורה הפתרון השני יהיה בעל הסתברות גבוהה יותר. בדוגמה של פונקציית פייתון שסופרת שורות בקובץ לא משנה כמה פעמים אני אבקש אותה אף סוכן קידוד לא יגיד לי "בעצם עדיף לך class". דבר שני בגלל האינטגרציה של סוכני קידוד עם כלי פיתוח הרבה פעמים אפילו אם AI ירצה להציע כמה פתרונות ה VS Code או Cursor יבחר רק אחד מהם וכבר יכתוב אותו בתוך הקוד כך שאני לא אראה את זה. לכן הדבר הראשון שאנחנו חייבים לעשות הוא להמשיך לחפש בעיות ופתרונות גם מעולם התוכן שלנו וגם מעולמות תוכן אחרים - מישקו הברה, היוצר של אנגולר לא היה מתכנת FrontEnd והגיע מעולם של Java כשהוא יצר את אנגולר. הוא הגיע עם ראייה של פתרונות מהעולם של תכנות מונחה עצמים וזה לדעתי מאוד עזר לו לראות בעיות ופתרונות שאנשי פרונטאנד פספסו. קריאת ספרים, היכרות עם מערכות קיימות, עבודה על עוד פרויקטים, קריאת בלוגים ואפילו קורסים מקצועיים כולם יעזרו לכם להכיר טוב יותר את עולם התוכן, את היסודות, את הבעיות והפתרונות הקיימים. כדאי גם לפתח הרגל במקום להסתכל על תרגיל ולחפש את הפתרון שלו אתם רוצים להסתכל על תרגיל ולחפש כמה שיותר פתרונות אפשריים.

איך ללמוד תכנות בעידן ה AI תכנות הוא האומנות של לגרום למחשב לעשות מה שבני אדם רוצים שהוא יעשה באמצעות כתיבת תוכניות מחשב. עידן ה AI ובמיוחד כניסתם של סוכני קידוד מבוססי AI מטלטלת את ההבנה שלנו לגבי תכנות. אנחנו עומדים משתאים מול סוכן קידוד שלוקח תיאור בעיה או אפילו מערכת בשפה חופשית והופך אותה לקוד. אנחנו שואלים ובצדק איך יראה היום יום של מפתחי תוכנה בעוד שנה או חמש? מה עלינו ללמוד כדי להצליח להשתלב בו? ומה עלינו להמליץ לילדינו וחברינו ללמוד כדי שיוכלו לכתוב תוכנה בעידן שבו AI יעשה את רוב ההקלדה? כתיבת קוד היא קבלת החלטות נתחיל בנקודה הכי קשה והיא מה זה בעצם פיתוח תוכנה? תוכניות המחשב הראשונות היו בסך הכל חורים על כרטיס ומפתחי התוכנה הראשונים היו צריכים להחליט איפה לחורר את החורים. מפתחי תוכנה בשנות ה 80 היו צריכים להכיר לעומק את מבנה החומרה, בשנות ה 90 התוכניות גדלו משמעותית ותכנות מונחה עצמים הפך לפרדיגמה מובילה, אחרי כניסת האינטרנט עברנו לבנות מערכות מבוזרות שמדברות ביניהן דרך פרוטוקולי תקשורת והיום אנחנו בונים סוכנים חכמים ואפילו סוכני קידוד שכותבים קוד. אז מה זה הדבר הזה שאנחנו "לומדים" או "יודעים" שהופך אותנו למפתחי תוכנה? ברור שזה לא שפת תכנות מסוימת או אפילו צורת כתיבת קוד מסוימת. מפתחים שכתבו משחקים למחשב אישי בשנות ה 80 לא ימצאו את הידיים והרגליים בסטודיו לפיתוח משחקים של 2025. אפילו בפערים קטנים בהרבה הקושי בולט, מפתחי PHP שרק בשנת 2004 בנו את כל האינטרנט התקשו ב 2014 למצוא עבודה בפיתוח אותה אינטרנט כשהפרדיגמה השתנתה ועברנו לכתוב קוד Front End. ועדיין לא מעט מפתחים עברו בעצמם רעידות אדמה של שינויים טכנולוגיים. והדבר המדהים הוא שמכל שינוי טכנולוגי כזה רק צמחנו. אותם מפתחי PHP שהתקשו למצוא עבודה כשהעולם הפך לפרונטאנד למדו מהר מאוד את הכלים החדשים והפכו למפתחי פרונטאנד טובים בהרבה ממפתחים שהתחילו בתור מפתחי פרונטאנד. שפות התכנות משתנות אבל יש משהו יותר גדול שנשאר ומשתפר ככל שנבחר לשפר אותו. בעבר קראתי לזה טכניקה. היום אני חושב שיותר נכון להשתמש בשם "קבלת החלטות". קבלת החלטות בעולם הפיתוח היא היכולת שלנו לשים לב לדרישות האמיתיות של המערכת, של הלקוחות ואפילו של העתיד ולשלב את הדברים כדי לבחור את הפתרון המתאים ביותר לכל בעיה. קבלת החלטות היא שילוב של: 1. היכרות עם אוסף גדול של פתרונות. 2. הבנה של הקונטקסט של כל פתרון, לאיזה בעיות הוא מתאים, מה היתרונות והחסרונות שלו. 3. תשומת לב לפרטים ויכולת לזהות את הבעיה האמיתית ואת הבעיות האמיתיות העתידיות. 4. טעם טוב ויכולת לראות כשמשהו "לא נכון" או "יסבך אותנו בהמשך" או אפילו פשוט "מכוער". 5. מודעות למגבלות ואילוצים וחשיבה בתוך האילוצים - זמני פיתוח, השפעה על תחזוקה, אבטחת מידע, ביצועים, עלות תפעול. 6. יצירתיות, תעוזה וחשיבה מחוץ לקופסה. בתכנות זאת הראיה של "אם היה לי X אז הבעיה שאני עכשיו מסתכל עליה בכלל לא היתה קיימת. בעצם צריך לבנות את X". מפתחים מנוסים עם יכולת קבלת החלטות טובה ותשומת לב לפרטים ייכנסו מהר יותר לפרויקטים, יהיו פרודוקטיביים מהר יותר ויבנו מערכות יציבות יותר גם אם אין להם נסיון קודם בטכנולוגיה הספציפית של הפרויקט. קבלת החלטות - דוגמת פרומפט פשוט בניגוד למתכנתים אנושיים סוכני קידוד ממש טובים באיתור מידע, תרגומו ועיבודו. הם יכולים לקחת כל בקשה בשפה טבעית ולייצר ממנה קוד, מה שרק מבליט את הפער בין בני אדם לסוכני קידוד ורק מחדד את החשיבות של קבלת החלטות. אם בעבר יכולת להסתדר בפיתוח תוכנה רק בהעתק-הדבק היום ברור שסוכני קידוד יעשו את זה טוב יותר ומהר יותר. אבל מה זה אומר קבלת החלטות בפועל? אם AI יכול לכתוב כל קוד שנגיד לו איזה החלטות נשאר לנו לקבל? בואו ניקח דוגמה ראשונה פשוטה לסקריפט פייתון שצריך לספור כמה שורות יש בקובץ. הנה כמה פרומפטים שאפשר לנסות להפעיל: 1. כתוב סקריפט פייתון שמקבל שם קובץ ומדפיס את מספר השורות בקובץ. 2. אני תלמיד בחטיבה וקיבלתי שיעורי בית: כתוב סקריפט פייתון שמקבל שם קובץ ומדפיס את מספר השורות בקובץ. תוכל לעזור לי לפתור כדי שאקבל 100 על המשימה? 3. כתוב סקריפט פייתון שמקבל קובץ (מקומי או מרוחק) ומדפיס את מספר השורות בקובץ. 4. כתוב סקריפט פייתון שסופר שורות בקובץ. אנחנו מצפים להפעיל את הסקריפט על קבצים ענקיים שים לב לביצועים ולזכרון. 5. כתוב סקריפט פייתון שסופר שורות בקובץ טקסט. יש סיכוי טוב שבעתיד יבקשו גם לספור שורות תוכן בקובץ אקסל או CSV כלומר בלי הכותרת.