ToCode

📌 המודל החדש של אנטרופיק מוכיח שוב את מה שכולם רוצים לשכוח מאז שיצא fable, ששמו נשמע לי הרבה יותר כמו faible הצרפתי מאשר כמו משהו מהאגדות, הספקתי לדבר איתו לא מעט וכל שיחה מחדדת יותר את ההבנה שאולי המודלים רצים קדימה אבל היעד הוא לא מה שמספרים לקהל הרחב. בדוגמה אחת באמת מהאגדות שלחתי את פייבל להוסיף דוח למערכת. המודל חקר את הקוד, מצא פתרונות כירוגיים יפים לבעיות, מימש את הדוח החדש בתוך האילוצים של המערכת הקיימת בלי להתבלבל ואפילו התחיל לאסוף כמה נתונים חדשים כדי שאפשר יהיה לייצר את הדוח. הקוד כלל קוד צד שרת, קוד צד לקוח, אינטרקציה עם בסיס הנתונים ועוד אבסטרקציות סך הכל סדר גודל של מאות שורות בכעשרים קבצים. ואחרי כל זה הוא הפעיל דפדפן בדק את כל העבודה שלו ותיקן את עצמו עד שהכל עבד כמו שצריך. אפילו אופוס לא היה מתקרב לנחישות הזו, וזה באמת מדהים. בדוגמה אחרת ביקשתי ממנו לכתוב קוד פייתון שמשתמש ב Multi Threads כדי לספור כמה מספרים ראשוניים יש בין 1 למיליון. פייבל מימש ואפילו דאג להזהיר אותי ששימוש ב Threads למשימה זו הוא לא אידאלי בגלל ה GIL בפייתון ואולי אני רוצה לשדרג ל multiprocessing. מרשים? כמובן. מחליף אנשי תוכנה? לא ממש. דוגמת הפייתון טובה עד שנזכרים שהרבה יותר מהר לספור ראשוניים בשיטת המסננת עם Thread יחיד. בדוגמת הדוח שינוי מבנה הטבלאות במערכת היה מאפשר ייצור הרבה יותר מהיר של הדוח ופילטרים יותר מתקדמים, מה שלא ניתן לבצע במבנה הקיים. שני המקרים הזכירו לי את האמת שכולם רוצים לשכוח - העבודה של מפתחים היא לא להקליד את הקוד אלא להחליט איזה קוד לכתוב.

📌 שלוש תובנות על פיתוח בעידן ה AI מהיוצר של Open Code הקשבתי לראיון עם דקס רד, היוצר של אופןקוד בפודקסט של Pragmatic Engineer. בחור מרתק ואני ממליץ להקשיב לפרק הזה כשיש לכם זמן. מכל הדברים אני רוצה להתיחס ל-3 תובנות שהוא מעלה על פיתוח באמצעות AI היום, שלושה דברים שתמיד היו אבל היום עם ה AI הפכו משמעותיים בהרבה: 1. הכנסת פיצ'רים שלא באמת שווים את זה - מאחר וכל כך קל להוסיף פיצ'רים אנחנו מעלים הרבה יותר פיצ'רים במוצרים שלנו. הבעיה היא שכל פיצ'ר ימשיך ללוות אותנו שנים קדימה, אנשים אחרים יסתמכו עליו ונצטרך לתמוך בו. דקס העיד שאחרי שהם ניסו לרוץ מהר ולשבור דברים היום הצוות שלהם מחפש איך ליצור צווארי בקבוק ולהעלות פחות פיצ'רים למוצר כי הם גילו שעוד פיצ'רים לא הופכים את המוצר לטוב יותר. 2. קשה יותר לשלוט בפתרונות עקומים - פעם כשהיית צריך לבנות פיצ'ר שלא בדיוק התאים למערכת היית צריך לבחור אם לחשוב מחדש על חלקים גדולים במערכת או לבנות פתרון לא מדויק ולעקם את המערכת כדי שזה יעבוד. היום בפיתוח עם AI הסוכן עושה את זה בשבילך ולסוכני קידוד יש Bias ליצירת הפתרונות העקומים. התוצאה היא שהרבה פעמים אנחנו לא יודעים שנבחר פתרון עקום ולא חושבים עד הסוף על ההשלכות ומקרי הקצה. יותר מזה, מרגע שנבחר הפתרון העקום סוכני קידוד ישתמשו ב Bias השני שלהם לתאימות אחורה וימשיכו לבנות עוד שכבות של פיצ'רים על גבי אותו פתרון עקום וכך כשאנחנו מזהים את הבעיה עלול להיות מאוחר מדי לתקן אותה. 3. עלינו להשקיע יותר זמן בניקוי הקוד - התוצאה המתבקשת של שתי הנקודות הראשונות. סוכני קידוד שרצים חופשי יבנו אינסוף פיצ'רים כי אין להם יכולת לסנן ויכניסו פתרונות עקומים למערכת עבור כל פיצ'ר כזה. הדרך היחידה להשתלט על הכאוס היא ליצור צווארי בקבוק מלאכותיים ולהשקיע יותר זמן בניקוי הקוד. ניקוי כאן הכוונה לראות פתרון עקום, לחשוב מחדש על המערכת כדי להגיע לפתרון הנכון ואז להשתמש ב AI כדי לבצע Refactor לחלק גדול מהקוד. אני רוצה לסיים בדוגמה קצרה מהפרויקט שלי לאותו רעיון של פתרונות עקומים. קומיט: https://github.com/ynonp/langlets-rails/commit/24f9d380e593a2886f8163cbf989c9405cbc7402 רציתי להוסיף ל langlets כפתור לעבור בין "מצב בהיר" ל"מצב כהה". באיטרציה הראשונה הסוכן שם כפתור מרחף בצד ימין למטה של המסך ואני ביקשתי להעביר את הכפתור לשורת הכותרת. התוצאה - הסוכן כתב את הכפתור בשורת הכותרת וגם השאיר את הקוד שמצייר את הכפתור המרחף בצד ימין למטה. אז הוא הוסיף משתנה בשם suppress_floating_theme_toggle עם ערך ברירת מחדל "אמת" שגורם לתבנית להסתיר את אותו כפתור מרחף. בלי ניקוי של הקוד הכפתור הזה היה נשאר ומופיע מדי פעם במסכים חדשים פשוט בגלל שמישהו שכח להגדיר את המשתנה. ניקוי של הקוד הוא קריטי בדיוק בגלל אותן התנהגויות מובנות של סוכני קידוד.

📌 ארבעה פתרונות במהלך הרצאה על קלוד קוד שהעברתי היום נתתי לקלוד לפתור באג ביצועים במערכת, ארבע פעמים כל פעם עם פרומפט קצת אחר. מתוך ארבעת הפתרונות שלושה עבדו ואחד לא. השלושה שעבדו היו כולם טובים, כל אחד בדרך אחרת. מי שהיה נותן לקלוד לנסות לפתור את זה עם הפרומפט הראשון היה מתאכזב ואולי יוצא בתחושה שקלוד לא מספיק טוב בשביל לפתור את הבעיה. מי שהיה משתמש בפרומפט השני היה חושב שקלוד לא רואה את התמונה הגדולה. מי שהיה משתמש בפרומפט השלישי היה חושב שקלוד משנה יותר מדי קבצים ואפשר היה לייצר פתרון הרבה יותר פשוט. ומי שהיה לוקח את הפרומפט הרביעי היה חושב שקלוד או פזיז או גאון. אבל כולם נוצרו בדיוק מאותו סוכן ובדיוק עם אותו מודל. וכל אחד מהם מציג עוד נקודת מבט על הבעיה. כשקוראים את כל ארבעת הפתרונות הרבה יותר קל לגבש דעה על הפתרון שמתאים לנו ועל ההשפעה שלו על המשך בניית המערכת. חבל לעצור בפתרון הראשון שעובד. (נ.ב. זה אפילו לא מסובך ליצור עוד פתרונות - פעם אחת נתנו למודל לרוץ לבד, פעם שניה הפעלנו Plan Mode, פעם שלישית בכלל הפעלנו מתוך VS Code ובנינו את הפרומפט שלב שלב תוך כדי שאנחנו שואלים את קלוד שאלות על הקוד ואת הרעיון לרביעי קיבלנו אחרי ששלחנו אותו לעשות לעצמו Code Review. יש די הרבה מיץ בלימון הזה שנקרא קלוד).

📌 איך אני מתחיל היום פרויקט חדש פיתוח Agent First שינה את סדר העדיפויות בפיתוח וחלק מהשיקולים. בעבר הייתי מתחיל בבחירת טכנולוגיה שאני אוהב, הקמה של דף קונספט קטן כדי להבין בכלל מה אני רוצה ואז פיתוח אינקרמנטלי של הפיצ'רים. היום מהירות הפיתוח שסוכני קידוד מכתיבים אומרת שאם אני לא מקבל את ההחלטות הנכונות מהרגע הראשון אני עלול להתעורר כשיהיה מאוחר מדי. זה מה שאני עושה היום כדי להתחיל פרויקט חדש בגישת Agent First: 1. תיעוד לסוכן - מוודא שיש את כל התיעוד של הספריות הרלוונטיות זמין לסוכן בקבצי Markdown. אם אין אני תמיד יכול להפנות את קלוד לתיעוד ולבקש שיבנה לעצמו Skill ממה שיש שם. 2. בחירת שפה וטכנולוגיה - הרבה פחות חשוב ממה שהיה פעם. טייפסקריפט? פייתון? רובי? ראסט? כל עוד אני יודע לקרוא את זה יהיה בסדר. מה שחשוב זה שהאקוסיסטם יהיה בשל. 3. שולח את הסוכן לבנות דף קונספט. עמוד אחד רק לראות שהכלים עובדים. 4. מסדר את כל מנגנון ה Deployment לגרסה הראשונה. הדבר האחרון שאני רוצה זה שהסוכן יחליט לשמור את המפתחות בקוד כי "זה רק MVP" או משהו כזה. 5. מתקן את מבנה הפרויקט שהסוכן יצר כדי להתאים לפרויקט שאני רוצה וכותב קובץ AGENTS.md עם תיאור הפרויקט וקווים כלליים לפיתוח. 6. מחבר דפדפן (וכלים נוספים לפי הצורך) ב MCP כדי שהסוכן יוכל לבדוק את עצמו. המשחק הוא לייצר סוכן שכותב קוד באופן עצמאי בתוך מסגרת של כללים. אנחנו עדיין צריכים לעבור על הקוד ולוודא שהוא לא יוצא מהמסגרת, אבל אם מהצעד הראשון אנחנו חושבים על המסגרת, הכללים והחופש של הסוכן אנחנו מתחילים לראות את המערכת שאנחנו רוצים לייצר.

📌 אף אחד לא התלהב מאיכות הקוד מישהו שאל בהאקרניוז מה היה הרגע הקסום ביותר מבחינתכם בעבודה עם Gen AI. הדיון כאן: https://news.ycombinator.com/item?id=48406174 התשובות באמת מדהימות- בן אדם אחד סיפר על מדפסת שעבדה פיקס חוץ מאשר כשהדפיס בלינוקס מתוך כרום. קלוד יצא לדרך ואחרי כמה דקות המדפסת התחילה להדפיס. מישהו אחר סיפר על תוכנה שהיתה לו שהפסיקה לעבוד כי השרת שהיא ניסתה להתחבר אליו כדי לאמת את הרשיון ירד מהרשת (החברה כבר נסגרה). קלוד השתמש בכלי הנדסה אחורנית בשם גידרה, פרץ את התוכנה וביטל את מנגנון ההגנה. עוד מגיב סיפר על קודי שהיה מתרסק אחרי כמה דקות שימוש על הכרוםקאסט. קלוד התחבר למכשיר עם adb זיהה את הסיבה להתרסקות, הוריד מהאינטרנט את קוד המקור של קודי ובנה גרסה חדשה שלא מתרסקת. מגיב נוסף שלח את קלוד לבנות MNIST Classifier על FPGA בתור דמו. הוא נתן לקלוד את הכלים, יצא לאכול צהריים וכשחזר הוא יכל לצייר על המסך את המספר 2 שאכן זוהה כמו שצריך. סיפור חמישי הוא על CTO שהחזיק שתי אפליקציות קטנות, שתיהן נבנו על ידי יועצים חיצוניים בבלאגן נוראי - מיקרו סרביסים, next.js, ריאקט, וכל זה בשביל 50 משתמשים בשבוע. ה AI שכתב את שתי האפליקציות ותוך כמה ימים הגיעו לגרסה פשוטה בהרבה של מערכת עם אותם פיצ'רים, הכל עובד יותר מהר ועלויות השרת ירדו משמעותית. ויש שם עוד אינסוף סיפורים מטורפים. אין בכלל ספק ש Gen AI הוא השינוי הגדול ביותר בעולם התוכנה אולי מאז האינטרנט אולי אפילו יותר גדול. מה שלא ראיתי שם היה אנשים שהתלהבו מהקוד. לא היו סיפורים של אנשים שקראו קוד של סוכן קידוד ונפלו מהכסא. למעשה רוב המפתחים הטובים שאני מכיר כשקראו קוד של AI הרגישו שהוא צריך הכוונה וגם למודלים הכי חדשים אין את הראייה המערכתית האנושית. שאלתי גם את קלוד בשביל המשחק שיחפש ברשת וזו התשובה שקיבלתי:

When people praise AI coding on HN, the praise is almost always about capability, speed, and unblocking — "I shipped an iOS app in two weeks," "10–20x more features," "it found the bug in five minutes." The code-as-craft dimension, when it shows up at all, tends to show up as criticism: the recurring argument that AI code is "always good enough and never great" because great code requires taste and judgment about what's appropriate, what's overkill, what's elegant for this specific codebase.

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

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

📌 מי בכלל צריך לכתוב סוכנים? אתמול בוובינר אחת השאלות הקשות בעיניי היתה "בשביל מה בכלל צריך לכתוב סוכן?", או בגרסה אחרת "זה רק בשביל Chat?". באותו רגע לא הייתי בטוח איך לענות אז כרגיל במקרים כאלה אני מנסח את התשובה הארוכה כאן לבלוג. כשאנחנו מסתכלים על האינטרנט היום מצד אחד אנחנו מתקשרים עם המון סוכנים אבל באותו זמן בגלל שכולם כותבים סוכנים לא לגמרי ברור למה שנרצה עוד אחד. מה אפשר לעשות עם סוכן שלי שאי אפשר לעשות בשיחה רגילה עם ה ChatGPT? צריכים לכתוב קוד? יש כבר סוכן לזה. צריכים לתרגם? מישהו כתב סוכן לזה. צריכים לשאול שאלה את תיבת הג'ימייל שלכם? גוגל ישמחו לשים שם את ג'מיני שיענה. צריכים לבנות תוכנית טיול? שימו את כל הלינקים ב Notebook LM ותנו לג'מיני לסדר אותם לפי ימים. צריכים להזמין טיסה? צ'ט ג'יפיטי ישמח להתחבר למערכת של חברת התעופה ולהזמין לכם, ואולי אפילו להראות פרסומת בדרך להשכרת רכב (גם אם לא היום זה תכף מגיע). השאלה הגדולה אנחנו מסתכלים על העתיד של סוכנים כמו "דפדפני אינטרנט" או כמו "אתרים"? האם אני אכנס באופן קבוע ל ChatGPT ודרך ממשק השיחה איתו אמשיך לבצע פעולות במערכות אחרות, או שלכל מערכת יהיה את הסוכן שלה? אם העתיד הוא האפשרות הראשונה באמת אין טעם לבנות סוכנים. הרבה יותר חשוב לבנות API טוב ש ChatGPT או מתחריו יוכלו להשתמש במערכת שלי, כמו שאני בונה אתר בטכנולוגיות ווב כדי שייפתח טוב בכל הדפדפנים. אבל אם סוכנים הם הדור הבא של אתרי אינטרנט אז ברור שכל מי שהיום מחזיק אתר יצטרך להוסיף אליו סוכן, בדיוק כמו שהוספנו אתר מותאם ואפליקציה. לשאול "למה צריך סוכן" זה קצת כמו לשאול "למה צריך אתר מותאם למובייל" ב 2010. באותו רגע באמת רצינו לדחות את כאב הראש הזה, אבל עד 2015 כבר לא היה צריך לשאול. אני אישית חושב שסוכנים יהיו יותר כמו אתרים מאשר כמו דפדפנים מהסיבות הבאות: 1. קל מאוד לכתוב סוכן וממילא המשתמש מדבר עם הסוכן דרך דפדפן. אין בעיית הפצה. 2. פיתוח סוכן נותן לי שליטה מלאה על החוויה של הלקוח. מה הגולש רואה, מה מציעים לו, איזה פרסומות יש מסביב, איך הממשק של השיחה מתחבר עם דברים נוספים באתר. שאלתי את Gemini ו ChatGPT בשביל המשחק. שניהם בטוחים שבעתיד הם ישלטו בעולם, אף אחד לא יכתוב סוכנים וכולנו רק נספק "ממשק" דרכו גולשי ChatGPT יוכלו להשתמש במוצר שלנו אבל עדיין להישאר ב ChatGPT. אני חושב שהם טועים. העתיד יגיד. עד אז אפילו אם אתם לא צריכים לבנות סוכן אני חושב שזאת חוויה מעניינת. סוכן הוא בסך הכל אוטומציה של תהליך שקורה אצלכם ממילא ומשלב מודל שפה. הנה כמה דוגמאות של דברים שאפשר לבנות כבר היום רק בשביל המשחק והלמידה: 1. סוכן שמקבל אימיילים ושומר חשבוניות או מסמכים מצורפים לתיקיית רשת. 2. סוכן שמקשיב להודעות בטלגרם ומתרגם את הטקסט לשפה אחרת. 3. סוכן שכל ערב שולח לכם תקציר חדשות מותאם אישית לנושאים שמעניינים אתכם. 4. סוכן ששולח אוטומטית Code Review על כל PR פתוח. 5. סוכן שעונה על שאלות על המוצר שלכם. 6. סוכן שמשחק נגדכם איקס עיגול. 7. סוכן שמחזיק רשימת קניות. שולחים הודעה בטלגרם כשחסר משהו והודעה אחרת בטלגרם כשאנחנו בסופר. 8. סוכן ששולח בשמכם ברכת יום הולדת מקורית לחברים לאימייל (או משאיר הודעה בפרופיל החברתי שלהם). 9. סוכן שקרא את כל הפוסטים מהבלוג הזה ויודע לענות על שאלות לגביהם. 10. סוכן בטלגרם שעוזר לכם להכנס לכושר באמצעות שליחת תוכנית אימונים והודעות מוטיבציה ומעקב. 11. סוכן כרטיסיות - הוא גם מתרגם בשבילכם מילים וגם שומר אוטומטית כרטיסיות. מדי פעם תוכלו לבקש שיבחן אתכם ואז הוא שולף את הכרטיסיות לראות שאתם זוכרים. 12. הסוכן הבוחן - תנו לו לינק למאמר או פוסט והוא יתחיל לשאול אתכם שאלות על הטקסט כדי לראות שאתם מבינים אותו לעומק. האם אפשר לכתוב את כולם או חלקם בגישת No Code עם כלי אוטומציה קיימים? ברור. האם שווה לכתוב את הקוד לבד כדי להבין איך דברים עובדים מבפנים? אין שום ספק.

📌 אל תכוון. תסחט. חבר שואל - בעיות פשוטות ה AI פותר לגמרי לבד. כשהקוד מורכב לפעמים אני צריך לכוון אותו כדי שיגיע לתוצאה נכונה. נראה לי שעוד שנה הוא כבר יצליח להתמודד גם עם המערכות המורכבות. מה נשאר לי לעשות? איפה העבודה שלי? תשובה - דווקא בבעיות הפשוטות קל יותר לראות את התשובה. כשאתה מקבל את התשובה הראשונה של ה AI אתה מוותר לעצמך ועל עצמך. זה מוזר כי לפעמים התשובה הראשונה של ה AI טובה כמו תשובה שפעם היית עובד יומיים בשביל לקבל. זה בכלל לא חשוב. המטרה היא לא לקבל יותר מהר את אותה התשובה מפעם. אנחנו פה בשביל לבנות משהו טוב יותר. במקום להסתפק בתשובה הראשונה שה AI מייצר תכתוב פרומפטים נוספים ושיחות חדשות ותלמד יותר לעומק על הבעיה. תשאל את ה AI איזה בעיות יש בפתרון שהוא יצר. תבקש פתרון יותר מהיר, או שמשתמש ביותר זכרון, או בפחות זכרון, תחפש איפה זה יישבר ואיזה פיצ'רים דומים או משיקים אפשר לייצר. לפעמים צריך לכוון את ה AI בעבודה על Codebases מורכבים. אבל זה לא הדבר החשוב או המעניין. אמרת נכון - עוד שנה הוא כבר יצטרך פחות הכוונה. בוא נתמקד במקומות שה AI כאילו מצליח את המשימה ונתחיל לסחוט אותו. עוד פתרון, עוד דרך, עוד שיקול, עוד אופטימיזציה, עוד מחשבה על העתיד. זוכר את כל הפעמים שקיטרת שאין זמן לבנות פתרון נכון או להבין לעומק דברים? אז הנה עכשיו יש זמן. הזמנים התקצרו. הקוד שלך צריך להיות הרבה יותר טוב מהגירסה הראשונה שה AI יוצר. נ.ב. לא לשכוח היום בעשר אנחנו חוזרים לשגרת הוובינרים עם וובינר על פיתוח סוכנים עם OpenAI Agents SDK. נתראה בזום.

📌 למה עדיין קשה לקבל Code Review מסוכני קוד יש לי פרומפט קבוע ל Code Review שנראה ככה:

---
description: Review attached code
---

Review the provided code change.

Explain:
- What the code does
- Is the implementation complete
- What other alternatives can solve the same problem? Why was the current alternative chosen?

Then Code Review, focus on:
- Correctness - Bugs and logic errors
- Performance - are there newly introduced regressions? how will the feature work with production data?
- Scale
- Code architecture
- Coding best practices
- Security issues
- Error handling gaps
- Handled and unhandled edge cases

Test Coverage
- Examine existing tests
- Search for untested paths or incomplete tests, specifically tests that only verify the happy path
- Find if the untested code could break in ways we didn't consider

Multi Threaded or Concurrency
- We're writing a web application whose code runs from both user facing web frontend and background workers
- Evaluate code for multi threaded and concurrency anti patterns or possible hidden bugs, deadlocks, duplicate execution, starvation
- Evaluate the need for transactions only where absolutely needed due to the performance penalty of locking.

Security
- We're writing a web application performing in possible hostile environment
- Verify authorization is checked on every route
- Verify user input is sanitized before used


Finally look for AI anti patterns:
- Dead code
- Duplicated code or logic

** DO NOT RUN ANY CODE NOR DO NOT INTERACT WITH THE SYSTEM IN ANY WAY **

This is a static analysis code review running on an isolated machine.

כן זה ארוך אבל מעניין. תנו אותו למודל חכם (אופוס או דיפסיק פרו) ותמיד הוא ימצא על מה להתלונן. תקנו דבר אחד ותפעילו שוב ואתם תראו שתקבלו רשימה קצת שונה של בעיות. ככל שממשיכים לתקן רשימת הבעיות משתנה. הפעלה עם מודל אחר מחזירה רשימת בעיות קצת אחרת. אפשר גם לשנות את הפרומפט ולייצר כמה סוכנים, אחד עבור ביצועים, עוד אחד לאבטחת מידע ושלישי לאיכות הקוד. אבל זה לא משנה את הבעיה המהותית: 1. אי אפשר לקבל רשימה מקיפה של כל הבעיות - כל הפעלה וכל תיקון חושפים בעיות נוספות. 2. בעיות מסוימות מדורגות "חשובות" אבל למעשה הן לא חשובות בכלל. לפעמים המודל נטפל לדברים שאנחנו יודעים שהם בסדר אבל בגלל שהם שם הוא לא מצליח לראות בעיות אמיתיות. "תיקון" אותם דברים שהם לגמרי בסדר פתאום גורם למודל להציף בעיות אחרות כן חשובות. 3. הבעיות שהסוכן מוצא עשויות לתת תחושה שקרית של בטחון - "וואו הוא מצא דברים כל כך מתוחכמים בטוח הוא היה רואה את הדברים הבסיסיים והפשוטים ששבורים בקוד" זו לא תמיד מסקנה נכונה כשמדובר בסוכני קידוד. סך הכל קחו את הפרומפט תהנו ממנו ואני מקווה שהוא יעזור גם לכם לשפר את הקוד לפני שממזגים PR. אבל שימו לב שאנחנו עדיין רחוקים מתהליך Code Review אמין.

📌 עצה גרועה שעובדת עצה גרועה שעובדת היא הרבה יותר גרועה מעצה גרועה שלא עובדת. לא מזמן העברתי את ה DNS של האתר לקלאודפלייר ועל הדרך נכנסתי לפרוקסי שלהם כך שעכשיו אנחנו מוגנים ממתקפות DDoS. לא יודע כמה זה אפקטיבי הפעם האחרונה שהיתה מתקפה על האתר זה היה מילדים בטורקיה באזור שנת 2015 בעקבותיה שמתי את fail2ban וזה די פתר את כל הבעיות האלה, אבל לא משנה נותנים לך תיקח וממילא זה בחינם אז נרשמתי. כשבאתי להעלות גרסה חדשה של התוכנה דרך ה Github Action שהגדרתי ההעלאה נכשלה בגלל Network Error. ברור מה הבעיה - הקונטיינר שמעלה גרסה נתקע בפרוקסי של קלאודפלייר ולא יכול להגיע לשרת. בשביל להגיע לשרת הוא יצטרך את כתובת ה IP האמיתית שלו, שהיא כאמור מוסתרת מאחורי קלאודפלייר בשביל להגן ממתקפות DDoS. גיטהאב, שכמובן דוחפים את כולנו לדבר עם AI-ים כל היום הוסיפו כפתור Explain שאפשר ללחוץ עליו כש Action נכשל כדי לראות מה קרה. אז לחצתי. קלוד הסביר שהבעיה היא שהוא מנסה להתחבר ל IP6 של השרת אז נתתי לו רמז שזה התחיל רק מאז שנרשמתי לקלאודפלייר ואז הוא התאפס:

That's the key insight. When Cloudflare proxy (orange cloud 🟠) is enabled, SSH traffic breaks entirely

אין לך מה לעבור ל IP4 אתה צריך את התיקון האמיתי. ומה התיקון האמיתי? תוסיף רשומת DNS חדשה בשם לדוגמה deploy.tocode.co.il בה תפרסם את כתובת ה IP האמיתית של השרת כדי שהקונטיינר של גיטהאב ידע מה הכתובת ויוכל להעלות גרסה. רואים כבר את הבעיה? אני משלם* לקלאודפלייר כדי שיסתירו את כתובת ה IP שלי ובשורה הבאה ב DNS חושף לעולם את אותה כתובת שרציתי להסתיר. ומי יגן עליי מ DDoS-ים ? קלוד? שיהיה בהצלחה עם זה. (משלם זו מילה גדולה בהתחשב בזה שהפרוקסי של קלאודפלייר הוא בחינם, אבל נשים את זה בצד). עכשיו קלוד יודע את זה. וכן גם "יודע" זו מילה גדולה פה. כשאני ממשיך את השיחה לקלוד אין בעיה להסביר שההצעה שלו מטופשת. אבל זה יקרה רק אחרי שאני אכוון אותו לשם. בלי לדעת לאן אנחנו הולכים שום מכונה לא תיקח אותנו לשם.