ToCode

📌 היתרונות של ריאקט נשמעים לי הרבה פחות משכנעים היום כשבני אדם כתבו את רוב הקוד היו מספר סיבות טובות להשתמש בריאקט. הסיבות המרכזיות ששכנעו אותי היו: 1. אני חושב על ה State ועל התרגום שלו ל UI פעם אחת במקום בכל פעולה. 2. אני חושב על חלוקה נכונה לקומפוננטות ומשתמש באותן קומפוננטות לאורך היישום. בואו נפתח את זה. ✏ חשיבה על הסטייט במרוכז ולא עבור כל פעולה ניקח את הדוגמה הקלאסית של מונה לחיצות. בעולם לפני ריאקט חשבתי על הסטייט בכל לחיצה על הכפתור שמעלה את מספר הלחיצות: document.querySelector("button").addEventListener("click", () => { count++; document.querySelector("#count").textContent = count; }); ואז שוב בלחיצה על הכפתור שמאפס: document.querySelector("button").addEventListener("click", () => { count = 0; document.querySelector("#count").textContent = count; }); ואם הייתי צריך לשנות את צבע הרקע כשעוברים ערך מסוים אז עכשיו צריך להוסיף את ההתיחסות לצבע הרקע לשתי הפעולות. מהר מאוד קשה לנהל את המכפלות ואנחנו נתקלים בבעיות סינכרון. זה לא קיים יותר עם סוכנים. הסוכן מזהה ברגע את כל המקומות שמשנים את הערך של count ומעדכן את המיפוי ל UI. למעשה לסוכן יותר קל לסדר את המיפוי בכל פעולה מאשר לחשוב על הכל מראש. שימוש באפקטים, closures, זכרון מטמון ותבניות ריאקט נוספות דורש מהסוכן קוד הגנתי ופוגע בביצועים שלא לצורך. ✏ חשיבה במסכים במקום בקומפוננטות פעם היה לי מאוד חשוב לבחור נכון קומפוננטות ולהשתמש בהן שוב ושוב לאורך התוכנית. בחירת קומפוננטות נכונה הבטיחה ביצועים טובים ואפשרות לנסות מבני UI חדשים יותר מהר. זה לא שיקול יותר. אני לא צריך קומפוננטה של "תיבת בחירה עם אפשרות חיפוש" או לפחות לא צריך לתכנן אותה מראש כדי שאוכל להשתמש בה בכמה מקומות בתוכנית. כשאני מזהה את הצורך בכזו קומפוננטה אני מבקש אותה מהסוכן ותוך דקות מקבל אחת למערכת שלי. אני גם לא צריך את האקוסיסטם של ריאקט. הסוכן שלי יכול לכתוב כל קומפוננטה בדקות. הדבר היחיד שאני צריך להחליט עליו הוא איזה קומפוננטות יהיו במערכת בכל רגע נתון. אין שום הגיון להשקיע שבוע בכתיבת קומפוננטה, סטוריבוק ובדיקות בשבילה. ככל שאני מסתכל על המערכת כאוסף מסכים והקומפוננטות מאבדות מחשיבותן כך אני מגלה ש web components או אפילו … Read in full →

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

📌 היום למדתי: git intent to add בואו נשחק עם גיט. יש לי ריפו ויצרתי בו קובץ חדש בשם demo.py. רואים את זה: ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $ git status On branch main Untracked files: (use "git add <file>..." to include in what will be committed) demo.py nothing added to commit but untracked files present (use "git add" to track) ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $ עכשיו אני רוצה לראות מה יש בקובץ. קודם כל אני מנסה git diff - אבל הוא לא מדפיס כלום כי אין שינויים בקבצים של הפרויקט (הקובץ demo.py הוא חדש ומבחינת גיט לא חלק מהפרויקט עדיין). אז אני מנסה להוסיף אותו עם git add . ועכשיו הוא חלק מהפרויקט: ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $ git add . ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git status On branch main Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: demo.py ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git diff ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ אבל עדיין git diff לא מדפיס כלום כי אין הבדל בין תוכן הקובץ לתוכן הקובץ ב Staging Area. שוב ברור, git add הוסיף את הקובץ ל staging area. עד היום השתמשתי ב git diff HEAD או git diff --cached כדי לראות את השינויים אחרי add לדוגמה: ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git status On branch main Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: demo.py ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git diff ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git diff HEAD diff --git a/demo.py b/demo.py new file mode 100644 index 0000000..d77c663 --- /dev/null +++ b/demo.py @@ -0,0 +1 @@ +print("hello world from python") מסתבר ש git add מגיע עם מתג מיוחד בדיוק למקרים האלה, המתג -N או --intent-to-add. מתג זה מסמן לגיט שאנחנו מתכוונים להוסיף את הקובץ הזה לפרויקט בלי להוסיף את התוכן שלו ל Staging בדיוק בשביל שנוכל לראות את ה diff. ככה זה נראה: ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $ git add -N demo.py ynonp@ynons-MacBook-Air ~… Read in full →

ואני מחדד את הפוסט מהבוקר עם הפוסט הזה https://www.parameter.ai/labs/we-found-a-gap-at-openai ספריית גרפים בשם mathlive מציירת גרפים אבל גם מאפשרת לאייפריימים לצייר מקלדת וירטואלית מ HTML שאנחנו מעבירים כש ChatGPT השתמשו בספרייה הזו כדי להציג גרפים אף אחד לא אמר להם שהיא גם תאפשר לאייפריימים הפנימיים של כל צד שלישי להריץ JavaScript על האתר שלהם ושום AI Security Review בצד של ChatGPT לא ראה את זה לפני שהבאג עלה לאוויר ״תמיד היו בעיות אבטחה״ לא אמור לתת לנו להכניס חופשי קוד למערכת בלי לדעת מה נכנס לשם

📌 הגרסה המעניינת הי כולם, התחלתי אוטומציה חדשה - סוכן AI שסוקר את האינטרנט כל בוקר ושולח 4-5 עדכוני AI וטכנולוגיה מעניינים עם תקציר בעברית לכל מאמר. קוראים וותיקים אולי זוכרים שפעם הייתי כותב ניוזלטר כזה פעם בחודש וזה היה לוקח לי המון זמן לעבור על כל המאמרים לקרוא ולסכם הכל. בכל מקרה הנה עוד צעד במהפכת ה AI. אחרי שיצרתי את האוטומציה הלכתי לבנות דף נחיתה בשבילה וכמובן ביקשתי מהסוכן לבנות לעצמו דף נחיתה. זה היה הדף הראשון שהוא בנה: https://tocode.ravpage.co.il/ai-daily יש בו משהו מינימליסטי ויפה אב גם משעמם וקצת מזכיר דף HTML מספר לימוד. (הוא עובד אגב אין בעיה להירשם שם). וזו הגרסה השניה אחרי הערות: https://tocode.ravpage.co.il/ai-daily-devs הרבה יותר יפה אבל משעמם באותה מידה. (גם הוא עובד. אפשר להירשם ותקבלו 4-5 מאמרים על AI למייל כל בוקר מלבד שבתות וחגים). המעבר בין שתי הגרסאות פעם היה מסובך. מה ש AI מאפשר לדעתי הוא להשקיע יותר זמן בחיפוש הגרסה המעניינת בלי קשר לעיצוב שלה. ואולי בכלל כל המימושים הקלים האלה יחזירו אותנו לאינטרנט המינימליסטי. מעט טקסט אותנטי, מסודר כמו שצריך ובלי רעש וצלצולים כי ממילא הרעש והצלצולים כבר לא עושים רושם. בכל מקרה בניגוד לכותרת אין לי עדיין גרסה מעניינת לדף נחיתה הזה. אולי גם לא תהיה, אבל כן יש שתי גרסאות עובדות ובשתיהן סוכן AI ששולח עדכוני טכנולוגיה יומיים. אולי זה מספיק לבינתיים.

📌 הפרומפט השביעי עוד שלושה שבועות אני מתכנן וובינר על Eve ופיתוח סוכנים חכמים איתו ובשביל לארגן את החומרים ניסיתי לבקש מה AI לכתוב לי מדריך ידידותי למתחילים איך ליצור סוכן חכם עם Eve. פעם ראשונה הוא הסתבך עם הזדהות משתמשים. תיקנתי את הפרומפט. פעם שניה הוא הלך לאיבוד בחיבור בין next.js ל eve. תיקנתי שוב את הפרומפט. פעם שלישית הוא ניסה להשתמש בבסיס נתונים מקומי שלא עובד על vercel, שוב שדרגתי את הפרומפט עם הנחיה מפורשת לשמור את בסיס הנתונים על neon. פעם רביעית הוא השתמש ב BetterAuth המשולב ב neon (או לפחות ניסה). תיקנתי את הפרומפט שישתמש במנגנון התחברות מקומי. פעם חמישית הוא טעה באתחול הפרויקט. השתמש בטעות בתיעוד ישן של eve אז שוב חיזקתי את הפרומפט עם קישור ישיר לתיעוד ואיך מתחילים פרויקט חדש. פעם שישית הוא יצר מדריך שנראה נכון אבל אחרי שהלכתי צעד-צעד לפי המדריך הסוכן לא עלה מקומית. ופעם שביעית הוא שכח ש .env.local נטען רק מ next.js וצריך לטעון את משתני הסביבה באופן מפורש כשכותבים סקריפטים משורת הפקודה. ואחרי כל הטעויות האלה הבנתי למה אנחנו אוהבים Coding Agents ואיך כלי פיתוח פשוטים מסתירים את הטפשות של מודלי שפה. אפילו שקלוד מאוד חכם יש יותר מדי נעלמים וניחושים בכתיבת מדריך מראש, אבל כל גרסה של מדריך שנכתבה היה אפשר לתקן ולהביא למצב שהיא עובדת בעזרת לולאת תיקון "תוודא שזה עובד, תקן את הטעויות ותחזור אליי עם קוד רץ". לא כל גרסה היתה יוצאת משהו שרציתי, אבל הרבה יותר מעניין לבחור את ה Tutorial הכי טוב מבין 7 גרסאות (או להמשיך ולייצר גרסאות עד שאני מגיע לגרסה שרציתי).

📌 מתי לבנות סוכן כשהראיתי היום בקורס AI איך להשתמש ב Pydantic AI כדי לבנות סוכן מאפס התגובה הראשונה שקיבלתי היתה "אבל למה?". אנחנו הרי יודעים להשתמש ב claude -p בתוך סקריפטים או תוכניות קטנות אז מה הבעיה להשתמש בו בכל מקום שנצטרך לשלב בינה מלאכותית בתוכנית- 1. צריכים תרגום? תקראו ל claude עם פרומפט שמבקש תרגום. 2. צריכים לחפש בלוג? שלחו את קלוד למצוא מה מעניין שם. 3. צריכים לסנן איזה PDF הוא חשבונית? פרומפט מתאים לקלוד קוד ותקבלו את הקבצים מסודרים. אז בשביל מה צריך לכתוב סוכן? אלה התשובות הכי מעניינות שאספנו: 1. ביצועים - כתיבת סוכן מאפשרת להריץ את כל הפניות ל LLM מאותו תהליך במקום להריץ תהליך נפרד לכל פניה. 2. שליטה בטוקנים - כתיבת סוכן מאפשרת לי לקבוע את ה System Prompt ולבחור בדיוק מה יישלח ל LLM. 3. חיבור לתוכנית שלי באמצעות מימוש כלים - במקום לכתוב MCP אני יכול לכתוב פונקציות פייתון פשוטות שיאפשרו למודל להתממשק עם המערכת הקיימת שלי. 4. פלט מובנה - פניה לסוכן בסקריפט עם claude -p מחזירה תמיד תשובה כמחרוזת. סוכן יכול לדרוש Structured Output כדי לקבל מבנה צפוי של התשובה. בסוף הגבול בין המוצרים דק ואפשר לפתור כל בעיה במספר דרכים. בעולם של סוכני AI ובמיוחד כשהיכולות של הכלים כל הזמן מתעדכנות עדיף לא לבזבז יותר מדי זמן בחשיבה "איך נכון לפתור X" אלא להתמקד ב "מעניין איך זה יראה עם כל כלי". וכמובן התשתית הטכנולוגית לטובתנו כאן - "הי קלוד תראה לי איך זה היה נראה אם הייתי רוצה להשתמש ב claude -p במקום בסוכן כאן" או להיפך.

📌 סיימתי הכל בהצלחה כשהסוכן כותב ״סיימתי הכל בהצלחה״ למה הוא מתכוון? נתתי ל-4 סוכנים להוסיף 4 פיצ׳רים במקביל לאפליקציית דוגמה לקראת הוובינר של יום חמישי. כל אחד מהם כתב שהוא בנה את הפיצ'ר ובדק שהכל עובד דרך כרום וגם הסביר על הפיצ'ר שהוא בנה מה בדיוק זה עושה. אף אחד מהם לא סיפר ש git לא עבד לו, שסוכן אחר מחק לו קבצים ושינה לו חלקים בקוד תוך כדי תנועה, שהוא היה צריך להפעיל את הדפדפן כמה פעמים כי סוכן אחר שינה לו כל הזמן את שרת הפיתוח או הפעיל בעצמו דפדפן ואז ה MCP נכשל, שהיה צריך להפעיל tsc כמה פעמים כי סוכנים אחרים שינו קוד באמצע בדיקת הטיפוסים. אף אחד מהם לא סיפר שהוא בזבז הרבה יותר טוקנים ממה שהיה צריך רק בגלל כל ההפעלות הכפולות האלה או שיהיה לו קשה עכשיו להסביר מה השינויים שלו ומה השינויים של הסוכנים האחרים. אף אחד מהם לא חשב להמליץ לי פעם הבאה להריץ כל סוכן בסביבה משלו. ואם ״סיימתי הכל בהצלחה״ מסתיר כל כך הרבה בעיות ומהמורות ברורות - מה לגבי כל ההתלבטויות הפחות ברורות? איך בדיוק לממש, מה עושים עם החלק הלא סגור באיפיון, באיזה ספריה חיצונית להשתמש או האם לממש לבד. אנחנו נכנסים לתקופה בה הפרטים המעניינים הם הפרטים שלא רואים והמשימה שלנו היא ללמוד להסתכל.

https://sshhole.com/ אחד ההזויים של התקופה

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

📌 שדרוג תשתיות חייב להיכנס כתהליך אוטונומי ריילס שחררו גרסה שמתקנת 21 בעיות אבטחה השבוע: https://rubyonrails.org/2026/11/4/Rails-8.0.5.2-and-8.1.4.1-have-been-released אלפין לינוקס היה פתוח לכניסה לכל אחד בעשר השנים האחרונות פשוט על ידי הכנסת סיסמה ארוכה מ 256 תווים: https://sshhole.com באג בספריה בשם ברוטלי אפשר לכל אחד להיכנס להמון שרתי לינוקס באמצעות הרצת סקריפט פשוט: https://ubuntu.com/security/CVE-2026-111497 כל זה רק כמה ימים אחרי שהתגלה PHP2Shell אוסף חולשות בליבה של PHP ששוב אפשרו השתלטות מלאה על שרתים שמריצים PHP: https://www.php2shell.com לפני כמה שנים כל באג כזה היה מעסיק אותנו לחודשים. כש Heartbleed התגלה ב 2014 אתרים שלחו מיילים מבועתים ללקוחות וביקשו מכולם להחליף סיסמאות כי אי אפשר לדעת איזה מידע דלף. היום בעיות בהיקף דומה ואפילו גדול יותר הולכות לאיבוד ברעש הכללי של AI. הדרך היחידה להתמודד עם העומס (והיא לא מלהיבה) היא שדרוג תשתיות אוטונומי. זה לא מלהיב וכולל סיכונים לנפילות אבל אני חושש שהאלטרנטיבה גרועה יותר. יש יותר מדי שדרוגי אבטחה קריטיים שלא מקבלים מספיק תשומת לב בגלל הכמות.