כשאין מה להגיד אנחנו ממציאים מילים - לדוגמה "taste" היא מילה שאמורה לתאר את איכות הקוד שאינה ניתנת לכימות.

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

בעידן שבו סוכני קידוד כותבים את הקוד הגיוני לשאול:

1. למה צריך "טעם"? למי אכפת איך המערכת נראית?

2. איך מפתחים אותו?

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

https://mtyurt.net/post/2026/we-should-still-send-home-assignments-in-engineering-interviews

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

1. למה בחרת דווקא את הספריה הזו? האם היו התלבטויות או אפשרויות רלוונטיות אחרות? באיזה מצבים היית בוחר בחלופה אחרת?

2. ראיתי שהקוד שלך מורכב משני מודולים. לפי מה החלטת על החלוקה ביניהם? למה דווקא שם? מה היה גורם לחלוקה אחרת?

3. מהם צווארי הבקבוק בארכיטקטורה שיצרת? למה בחרת למקם אותם שם? מה היה משנה את החלטתך?

ראיתם איך טאריק הפך את המשחק משאלון על "איך המערכת עובדת" לשאלון בחירה ואחריות? המשחק הוא לא להבין מה קרה אלא לבחור מה לצייר. הבחירה היא הטעם.

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

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

def test_html_href_preserves_mailto_and_tel_links() -> None:
    html = (
        '<p>Contact <a href="mailto:team@example.com">the team</a> or '
        '<a href="tel:+1234567890">call us</a>.</p>'
    )
    markdown = _convert_html(html)
    assert "[the team](mailto:team@example.com)" in markdown
    assert "[call us](tel:+1234567890)" in markdown

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

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

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

דרך נוספת היא לקרוא קוד וללמוד תיאוריה של קוד. כן לדעת מה זה Dependency Injection ומה היתרונות והחסרונות של Delegation ולהכיר את התבנית של Generator ו yield ובכלל Design Patterns. תיאוריה של קוד שנראתה אולי מעייפת לפני 5 שנים היא היום הלחם והחמאה של המקצוע.