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

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

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

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

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

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

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

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

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

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

We’ve seen usage intensify for all users as they realize the value of agents and subagents in tackling complex coding problems

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

בהסתכלות קדימה אני מהמר שזה הולך להשתנות.

נורות להט ישנות צרכו 60 וואט אבל רוב החשמל הזה הפך לחום. הנורות החסכוניות היום נותנות אור דומה אבל צריכות רק 13-15. נורות לד יורדות ל 8-10 וואט בשביל אותו אור.

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

אם כולם צורכים יותר מדי חשמל זה כנראה סימן שאנחנו צריכים נורות יעילות יותר.

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

היום אני מסתכל על VS Code עם קופיילוט וכל פעם שאני פותח אותו מופתע מכמות החידושים. אלה הפיצ'רים המרכזיים שאציג בוובינר שאולי לא הכרתם:

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

2. מצב טייס אוטומטי - מתוכנית לפיצ'ר ממומש ללא מגע יד אדם.

3. חיבור קופיילוט לעורכי טקסט אחרים (היוש nvim) דרך פרוטוקול ACP.

4. קופיילוט יודע להתחבר ל Ollama ולהשתמש במודלים שרצים אצלכם על המחשב או דרך מנוי Ollama cloud.

5. קופיילוט יודע לטעון Skills בדיוק כמו קלוד, בנוסף לקבצי ה Instructions וה prompt שאנחנו טוענים בצורה יזומה.

6. קופיילוט בתוך VS Code מגיע עם דפדפן מובנה, וגם מתחבר דרך MCP לכרום.

7. קופיילוט יודע לכתוב לכם Code Review אוטומטי.

8. קופיילוט מתחבר לסוכנים שכבר בניתם ב Claude Agents SDK ויכול לשלוח אליהם משימות.

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

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

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

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

וזאת בדיוק הבעיה שלנו עם Agent Harnesses:

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

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

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

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

התקנתי ננובוט (גרסה מוקטנת של אופןקלו) על ה Raspberry Pi שישב בארון והתוצאה מטלטלת. לא בגלל שיש המון מה לעשות איתו אלא בגלל מה שקרה לאינטרקציה-

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

במקום להריץ top כדי לבדוק מה מצב הזכרון או df למצב הדיסק אפשר לשאול את הננובוט.

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

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

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

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

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

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

1. מה עושים אם ה DB מפסיק להגיב באמצע ריצה?
2. איך להמשיך ייצוא אחרי שהוא נעצר באמצע? האם זה נתמך?
3. באיזה פורמט יישמרו הנתונים?
4. האם יש להצפין את המידע שמייצאים? באיזו שיטה?
5. איזה קונפליקטים יכולים להיות ביבוא? מה עושים בכל מצב?
6. איך שומרים על קונסיסטנטיות ביצוא אם נתונים ממשיכים להכתב תוך כדי שהסקריפט רץ?
7. האם יש Rate Limit בקריאה מה DB?
8. האם יש נתונים או חשבונות שאסור לייצר, כי הם מכילים מידע רגיש?

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

היום הקוד זול אבל ההחלטות נשארו יקרות - אולי אפילו יותר יקרות מאי פעם. יש שאומרים שיש "יותר מקום ל Seniors" אבל אולי יותר מדויק להגיד שיש יותר מקום לאנשים ששואלים שאלות, שרוצים ללמוד, שמוכנים לאתגר את ה AI ושיתאמצו כדי לראות כמה גרסאות של כל פיצ'ר עד שיחליטו איזו גרסה למזג. זה קל כשיש Human In The Loop שממזג PR-ים שסוכנים כותבים.

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

1. אנשי מוצר יבקשו פיצ'רים דרך טיקטים ב Jira
2. סוכני קידוד ישמרו את הפרומפטים בהודעות קומיט בגיט וימזגו לבד את ה PR-ים
3. מפתחים יוכלו לעבור על הקוד בדיעבד ולשנות גם החלטות ישנות. אני אוכל להסתכל על אותו סקריפט יצוא ולבקש שהוא ישמור את הנתונים ב CSV במקום ב JSON. סוכן קידוד יכתוב מחדש את כל הקוד מאותו קומיט, כלומר יחזור לנקודה שבה בוצעה ההחלטה, יכתוב מחדש את הקוד לאותו קומיט ואז ימשיך ויכתוב מחדש את כל הקוד של כל הקומיטים הבאים בתור. כמו rebase רק שגם יבנה מחדש את הקוד ולא רק את הקומיטים.

מה דעתכם? אפשרי? רצוי?

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

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

1. שכבת ההוראות - שזה הדברים שאנחנו כותבים בשפה טבעית.

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

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

אז איך יודעים אם לזרוק או לשמור? מסתכלים באיזו שכבה היתה הבעיה.

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

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

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

export const setAuthCredentials = response => {
  const expiryDate = getHeaderExpiry(response);
  const now = new Date();
  const diffMs = expiryDate.getTime() - now.getTime();
  const diffDays = diffMs / (1000 * 60 * 60 * 24);
  Cookies.set('cw_d_session_info', JSON.stringify(response.headers), {
    expires: diffDays > 0 ? diffDays : 1, // fallback to 1 day minimum
  });
  setUser(response.data.data);
};

ולמה זה מגושם? כי expiryDate הוא תאריך ו expires יכול לקבל או ערך מסוג תאריך או ערך מספרי שמייצג מספר ימים. מה עושה אופוס? הופך את התאריך לערך מספר (שמייצג מספר ימים) רק בשביל להעביר אותו ל expires של Cookies.set, בלי לשים לב שבתוך Cookies.set הערך הזה יומר חזרה מימים לתאריך.

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

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

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

בספר המפורסם Design Patterns של GoF יושבים 4 חכמים ומציגים תבניות עיצוב שהם מצאו במערכות תוכנה שראו. הספר פורסם ב 1994 ולכן ברור למה המימושים שהוצגו שם מורכבים מקטעי קוד קטנים ומספרים רק חלק מהסיפור. ב 1994 אי אפשר היה לשתף מערכת מלאה ולתת דוגמאות ממנה. הנחת העבודה שלהם היתה שהאנשים שקוראים את הספר מכירים את הבעיות ממערכות גדולות שלהם ומתעניינים בבניית הפתרונות.

זה מזמן לא המצב.

כמות הקוד הפתוח שיש לנו באינטרנט והיכולת לגשת לכל ריפו עם AI הם המפתח ללימוד יעיל של Design Patterns. לא במובן של להכיר איך בנוי Singleton, אלא במובן של להבין איפה אנשים אמיתיים משתמשים בתבנית זו.

נסו את הפרומפט הבא ב Gemini:

explain the singleton design pattern in python

1. what problem does it try to solve
2. what are some different implementations (variants) of the pattern?
3. provide examples for real world usages of the pattern in existing python open source libraries

וג'מיני ישמח להראות לכם קוד אמיתי מתוך Django, tornado, kivy ואפילו מתוך הספריה הסטנדרטית של פייתון שמשתמש ב Singleton וגם יסביר וירחיב למה הם בחרו בתבנית זו. המשיכו בשיחה ונסו להציע פתרונות אחרים לבעיה ומימושים שלכם ובקשו מ Gemini פידבק על ההצעות שלכם.

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

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

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

query = <<~END
  SELECT name, email
  FROM users
  WHERE active = true
END

puts query

מדפיס:

SELECT name, email
FROM users
WHERE active = true

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

query = """
  SELECT name, email
  FROM users
  WHERE active = true
""".strip()

print(query)

מדפיס את זה:

SELECT name, email
  FROM users
  WHERE active = true

היום למדתי על מודול מובנה בפייתון בשם textwrap שיודע לעשות בדיוק את הטריק שאני אוהב מרובי. כך נראה קוד פייתון שמשתמש בו:

import textwrap

query = textwrap.dedent("""
  SELECT name, email
  FROM users
  WHERE active = true
""").strip()

print(query)

והתוצאה:

SELECT name, email
FROM users
WHERE active = true

שימו לב שה strip צריך להופיע אחרי הקריאה ל dedent אחרת האינדנטציה הלא שווה מבלבלת את המודול.

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

query = d"""
  SELECT name, email
  FROM users
  WHERE active = true
  """

print(query)

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

ב PEP תוכלו למצוא עוד המון דוגמאות מה יעבור ומה לא יעבוד עם הכתיב החדש: https://peps.python.org/pep-0822/

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

ברור שלא.

וכמו שלא מחזירים כלים מלוכלכים לארון כך לא נמזג קוד גרוע.

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

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

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

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

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