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

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

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

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

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

1. קונטקסט ריק - הפקודה /context בקלוד קוד מראה את כל התוספים שתופסים מקום בקונטקסט. כשמפעילים את קלוד קוד במצב בטוח עם claude --safe-mode קלוד קוד לא טוען תוספים כלל ומתעלם מקובץ CLAUDE.md. נסו להפעיל את קלוד קוד במצב בטוח לאותה משימה שקודם הפעלתם במצב הרגיל ושימו לב לטוקנים. האם קיבלתם תוצאה דומה במחיר יותר נמוך? אם כן אולי שווה לנקות.

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

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

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

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

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

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

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

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

שלוש תשובות לדעתי שלושתן חשובות:

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

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

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

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

קלוד החליט לגוון בסקריפט פייתון שביקשתי וסיים את הסקריפט עם הקטע הבא שקצת הפתיע אותי:

if __name__ == "__main__":
    raise SystemExit(main())

למה לסיים קוד עם raise? מי זה SystemExit? ומה ההגיון בשיטת הכתיבה הזו?

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

if rm demo
then
    echo "yes"
else
    echo "no"
fi

מנסה להריץ את פקודת המחיקה, אם הצליחה למחוק אז היא תדפיס yes ואם לא הצליחה למחוק תדפיס no.

איך אנחנו יודעים אם תוכנית "הצליחה" או "לא הצליחה"? כל תוכנית יוניקס מחזירה ערך למערכת ההפעלה. ערך 0 מעיד על הצלחה וכל ערך שאינו 0 מעיד על כשלון. בפייתון אפשר להשתמש ב sys.exit כדי להחזיר ערך למערכת ההפעלה לדוגמה תוכנית הפייתון הבאה תמיד תכשל:

import sys

sys.exit(1)

ותוכנית הפייתון הבאה תמיד תצליח:

import sys

sys.exit(0)

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

import sys

result = main()
sys.exit(result)

או צעד לכיוון הקוד מתחילת הפוסט:

import sys

sys.exit(main())

ומה עושה sys.exit? שימו לב למימוש מתוך sysmodule.c:

static PyObject *
sys_exit_impl(PyObject *module, PyObject *status)
/*[clinic end generated code: output=13870986c1ab2ec0 input=b86ca9497baa94f2]*/
{
    /* Raise SystemExit so callers may catch it or clean up. */
    PyErr_SetObject(PyExc_SystemExit, status);
    return NULL;
}

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

raise SystemExit(main())

ולחסוך את ה import sys.

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

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

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

לנגלטס היא הניסיון שלי להפוך את התיאוריה הזאת למציאות. נכנסים בקישור he.langlets.app

עקרון העבודה הוא פשוט:

1. מוצאים סרטים מעניינים ביוטיוב או טיקטוק.

2. מדביקים ל Langlets או משתפים בלחיצת כפתור מאפליקציית יוטיוב או טיקטוק לאפליקציית לנגלטס.

3. מחכים שתי דקות שה AI יארגן את התוכן ומתחילים לתרגל.

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

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

מבנה כל שיעור שהסוכן יוצר מתאים לאיך שאני רגיל לתרגל שפה:

1. מסך ראשון הוא פשוט הטקסט בעברית של אותו קטע.

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

3. מסך שלישי נכנס לתרגול משפטים ספציפיים - מראה לכם משפט באנגלית מתוך הסרט ואתם צריכים לבחור את התרגום שלו לעברית מתוך 4 אפשרויות.

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

בסרט מיוטיוב של 8 דקות יש כ 17 שיעורים. בטיקטוק הסרטים יותר קצרים ושם לכל סרט יהיו 3-4 שיעורים.

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

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

כשלמדתי next.js לקח לי זמן להבין שכשאני כותב use client בתחילת קובץ הכוונה שלהם היא שהקוד ירוץ גם ב client וגם ב server, ולא רק ב client כמו שאולי היה אפשר להבין מהשם.

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

'use client';

import { useEffect, useState } from 'react';

export default function StoredValue({ storageKey = 'username', fallback = 'Not set' }) {
  // null means "haven't read storage yet" — distinct from an empty stored value
  const [value, setValue] = useState(null);

  useEffect(() => {
    try {
      setValue(localStorage.getItem(storageKey) ?? fallback);
    } catch {
      // Storage can throw in private mode or when disabled
      setValue(fallback);
    }
  }, [storageKey, fallback]);

  if (value === null) return <p>Loading…</p>;

  return <p>{value}</p>;
}

בשביל לקרוא מ local storage ריאקט היה צריך להחביא את הקוד שקורא מקוד צד השרת שיריץ אותו, כי על השרת ה local storage אולי לא זמין ובטוח מכיל ערכים אחרים.

לאחרונה next הוסיפו מנגנון חמוד בשם browser: https://react.dev/reference/react-dom/browser

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

'use client';

import { use, useState } from 'react';
import { browser } from 'react-dom';

export default function StoredValue({ storageKey = 'username', fallback = 'Not set' }) {
  use(browser('The value is stored in localStorage.'));

  const [value] = useState(() => localStorage.getItem(storageKey) ?? fallback);

  return <p>{value}</p>;
}

המלכודת היחידה בעדכון היא לכתוב את הקומפוננטה רק בתוך Suspense Boundary כלומר:

import { Suspense } from 'react';
import StoredValue from './StoredValue';

export default function Page() {
  return (
    <Suspense fallback={<p>Loading…</p>}>
      <StoredValue />
    </Suspense>
  );
}

אבל בטח יש לכם אחד כזה ביישום כבר בשביל כל הפיצ'רים האחרים שבנויים עליו.

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

זה הפוסט שהוא כתב לסכם את הניסוי: https://maxleiter.com/blog/thank-u-next

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

מקס חושד ש next.js עשוי לטפל במקרי קצה שאצלו הקלוד לא מימש אבל אני אפילו לא בטוח שזה חשש אמיתי או מעניין.

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

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

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

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

לקרוא כל שורת קוד ייקח נצח.

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

מה עושים? משלבים:

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

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

3. טאב שלישי זה הסוכן. תוך כדי מעבר על ה Diff אני שואל שאלות, "למה השורה הזאת שם?", "למה לשמור את זה או את זה ב DB". כשהשינוי גדול אני משתמש בכמה טאבים של סוכנים כי בדרך כלל אני שואל שאלות יותר מהר ממה שהם מצליחים לענות.

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

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

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

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

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

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

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

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

אחד מסיים אחרי יומיים עם קוד עובד ויכול להסביר מה בדיוק קורה במערכת.

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

איך זה קורה?

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

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

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

גם ב 2026 ולדעתי גם בעתיד הנראה לעין, מפתחים טובים הם אלה שיודעים איך נראה הקוד שפותר את הבעיה לפני שניגשים להפעיל את ה AI שיכתוב אותו. לא כל שורה (כאן המפתח לפרודוקטיביות), לא כל קריאת API, אבל כן הבנה ברורה של המבנה.

"תמשיך לנסות עד שזה עובד לפי ה Spec" עדיין עובד הרבה פחות טוב מ"תכתוב קוד במבנה הזה".

אם אתם כותבים כדאי לנסות את הכלי הזה:

https://tools.simonwillison.net/llm-cliche-highlighter

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

1. שימוש ברצף של שאלות רטוריות.

2. נקודותיים ואז שלושה פריטים.

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

4. משפט חיובי ואחריו מה שלא הצליח (לדוגמה Reading mostly passed … Writing didn’t)

5. שרשראות של no לדוגמה No fluff, no filler, no jargon

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

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

1. טיפול במקרי קצה שאי אפשר להגיע אליהם (על חשבון מקרי הקצה האמיתיים שלא טופלו).

2. כתיבת המון בדיקות יותר מדי ספציפיות.

3. כפל קוד.

4. השארת קוד "מת" רק בשביל לא למחוק היסטוריה ("אני משאיר את זה בינתיים ונמחק אחרי שנראה שהכל עובד").

5. כתיבת הערות בהגזמה במקום קוד קריא.

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

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