ToCode

📌 דברים שעדיין קשים ההתמכרות ל AI נותנת למפתחים ומנהלים הרגשה כאילו Coding Is Solved. זאת מחשבה נחמדה שלא מתחברת עם המציאות. כל המשימות האלה של פיתוח תוכנה עדיין קשות ואולי אפילו קשות יותר ממה שהיו בעבר: 1. להבין איך מערכת עובדת ואיך היא יכולה להישבר. 2. לראות איזה שינויים צפויים בדרישות הלקוח ואיך הקוד יסתגל לאותם שינויים. 3. לראות איזה מימוש מתאים לדרישות הלקוח, ואיזה רק נראה נכון אבל בעצם מפספס נקודות חשובות. 4. לבחור מבין מספר פתרונות את הפתרון הכי יעיל, פשוט ומתאים למשימה. 5. לשאול את השאלות הנכונות. 6. לבחור סביבת Deployment ולבנות תהליך עבודה שמביא מוצר מרעיון למשתמשים. 7. לבנות תהליכי עבודה שיוצרים חיכוך איפה שצריך ומצמצמים אותו איפה שאפשר. 8. לראות את האבסטרקציה שמאפשרת לבנות את כל המערכת. 9. לבצע פשרות כואבות גם כשכולם רוצים את הכל. זה מצוין שאנחנו כותבים HTML-ים הרבה יותר מהר מאי פעם. לא בגלל שזה פתר לנו את ה Coding, אלא פשוט בגלל שזה מאפשר לנו למצוא את הזמן להתרכז בדברים הקשים.

📌 כשהשיווק מחליף שיקול דעת שיווק יתר מתחיל להיות בעיה כשהוא מחליף שיקול דעת. ובעולם התוכנה זה קורה כל הזמן. כשכל התעשייה רצה אחרי Angular זה היה הפריימוורק שבחרנו לקוד חדש. כשכל התעשייה רצה לכתוב XML-ים בילינו עשור בכתיבת מערכות ששולחות ומקבלות XML. כשכל התעשייה התחילה לכתוב Micro Services עברנו בלי להתבלבל לכתוב Micro Services בענן. מה שמשותף לכל הטרנדים שאני חוויתי הוא גרעין של אמת שפותר בעיה אמיתית שמתגלגל והופך להכרח ולאימוץ עיוור. השטן הוא בפרטים ולכן אסור לוותר על השאלות הקשות. אני לא יכול לקחת שיטת עבודה שעובדת בחברה אחרת ולאמץ אותה אחד לאחד כי המוצר שלי שונה, האנשים שלי שונים, התהליכים אצלי שונים, גודל החברה שונה. רק כשהבנו את זה הצלחנו להשתמש נכון ב JavaScript Frameworks, הפכנו את ה XML ל JSON והוספנו פרוטוקולי תקשורת מגוונים למערכות ואנחנו מאמצים Micro Services בצורה זהירה לפי מאפייני החברה. קידוד בעזרת AI נמכר היום בתור Silver Bullet, בתור מוצר אחד שמתאים לכולם ופותר את כל הבעיות. ולא סתם AI אנחנו ממש מדייקים - קלוד קוד עם אופוס 4.7. אבל לקחת מוצר מדף מהפרסומת ולקוות שהוא יעבוד כמו בפרסומת זו לא אסטרטגיה טובה בעולם הפיתוח. בואו נלמד מהעבר. כן אתם הולכים לעשות קידוד עם AI בשנים הקרובות אבל לא בטוח שזה יהיה קלוד קוד ולא בטוח שזה בכלל יהיה מודל של אנטרופיק. למעשה אף אחד לא יודע איך קידוד בסיוע AI הולך לעבוד ובטח שאין שום מוצר מדף שאפשר לשים שיתאים בדיוק לצוות שלכם. עזבו את הפרסומת. קחו צעד אחורה והשקיעו את הזמן והמאמץ בבניית תהליך עבודה בסיוע AI שרלוונטי עבורכם. נסו: 1. לגוון במודלים ובסוכני הקידוד. שימו לב אם אפשר לעבור ביניהם ואיך. 2. לגוון בתהליכי העבודה, יום אחד לעבוד רק דרך הפרומפט, יום אחר מתוך ה IDE, לפעמים לשלב סוכן בענן. 3. לגוון בפיצ'רים, לבנות פיצ'ר ידנית ואז לשים בענף נפרד ואז לתת ל AI לממש אותו. לראות את ההבדלים. לשים לב לבחירות של ה AI ולמה זה קרה. קלוד קוד זה לא פרסומת לג'ינס. הדרך להטמעה מוצלחת היא התאמה אישית של התהליך לארגון שלכם ולתהליכים שלכם.

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

from typing import TypeVar

T = TypeVar("T")

def same(x: T) -> T:
    return x

וכל זה רק בשביל שיהיה מה לכתוב אחרי הנקודותיים בתור הטיפוס של x. החל מפייתון 3.12 אפשר לשכוח מכל הכאב ראש הזה ולאמץ תחביר שמזכיר את כתיב ה Generics של שפות אחרות:

def same[T](x: T) -> T:
    return x

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

def swap[T, S](x: T, y: S) -> tuple[S, T]:
    return y, x

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

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

from typing import TypeVar

T = TypeVar("T")

def same(x: T) -> T:
    return x

וכל זה רק בשביל שיהיה מה לכתוב אחרי הנקודותיים בתור הטיפוס של x. החל מפייתון 3.12 אפשר לשכוח מכל הכאב ראש הזה ולאמץ תחביר שמזכיר את כתיב ה Generics של שפות אחרות:

def same[T](x: T) -> T:
    return x

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

def swap[T, S](x: T, y: S) -> tuple[S, T]:
    return y, x

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

            else:
                # Try skipping SRT words
                found = False
                for sahead in range(1, MAX_SKIPS + 1):
                    if sp + sahead < len(srt_flat):
                        if words_match(srt_flat[sp + sahead][0], ts_norms[tp]):
                            sp += sahead
                            found = True
                            break
                if not found:
                    sp += 1
                    tp += 1

    # Compute timestamps per entry
    results = []
    for entry in srt_entries:
        ts_indices = entry_ts_map.get(entry["index"], [])
        if ts_indices:
            new_start = ts_words[ts_indices[0]]["ms"]
            last_idx = ts_indices[-1]
            if last_idx + 1 < len(ts_words):
                new_end = ts_words[last_idx + 1]["ms"]
            else:
                new_end = ts_words[last_idx]["ms"] + 500
        else:
            new_start = None
            new_end = None
        results.append((entry["index"], new_start, new_end))

    # Interpolate gaps
    for i, (idx, start, end) in enumerate(results):
        if start is None:
            prev_match = next(
                (results[j] for j in range(i - 1, -1, -1) if results[j][1] is not None),
                None,
            )
            next_match = next(
                (results[j] for j in range(i + 1, len(results)) if results[j][1] is not None),
                None,
            )
            if prev_match and next_match:
                old_prev = srt_entries[prev_match[0] - 1]["old_start_ms"]
                old_next = srt_entries[next_match[0] - 1]["old_start_ms"]
                old_curr = srt_entries[idx - 1]["old_start_ms"]
                if old_next != old_prev:
                    frac = (old_curr - old_prev) / (old_next - old_prev)
                else:
                    frac = 0.5
                interp_start = int(prev_match[1] + frac * (next_match[1] - prev_match[1]))
                interp_end = int(prev_match[2] + frac * (next_match[2] - prev_match[2]))
                results[i] = (idx, interp_start, interp_end)
            elif prev_match:
                results[i] = (idx, prev_match[1], prev_match[2])
            elif next_match:
                results[i] = (idx, next_match[1], next_match[2])

    return results

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

📌 שתי הרמות של הקוד חברה שואלת - האם לדעתך עומק פיתוח וחשיבה הנדסית עדיין יהיו הבסיס המרכזי גם בשנים הקרובות? אנשים אוהבים לדבר על AI כאילו הוא מבטל את החשיבה של המפתחים והופך אותנו לרובוטים שרק מאשרים קוד שאנחנו אפילו לא מבינים. אין ספק שיש אנשים שבוחרים בגישה זו אבל היא לא פרודוקטיבית ולאורך זמן לא תחזיק מעמד. מה שאנחנו רואים היום הוא שינוי טקטוני בתפקיד המפתחים. בעבר מפתחים ביצעו שני תפקידים בו זמנית: גם תכננו איך מנגנון מסוים ישתלב בקוד המערכת וגם כתבו את הקוד הספציפי עבור אותו מנגנון. יש חברות שניסו להפריד את התפקיד כך שארכיטקטים יסבירו איך המנגנונים משתלבים במערכת ומפתחים רק יכתבו את הקוד, אבל במציאות זה לא עבד. מפתחים היו צריכים לקבל אינסוף החלטות טכניות על המימושים והרבה פעמים תוך כדי מימוש גילו שהארכיטקטורה לא תואמת. בסופו של דבר ארכיטקטים נדחפו למעלה להחליט איך תתי מערכות שונות יתחברו אבל התרחקו מהקוד. המפתחים היו אלה שהחליטו איפה עושים Code Reuse ואיפה משכפלים מנגנון, איפה יוצרים קלאס חדש ואיפה מוסיפים רק פונקציה, איפה מגדירים Builder נפרד במקום להעביר עוד פרמטרים לבנאי, מה לשמור ב Cache ולכמה זמן. כשמפתחים לא הבינו מה הם מחליטים מערכות התדרדרו. היום תפקיד המימוש ברובו מבוצע על ידי AI, כך שמפתחים יכולים לתכנן ו AI מיישם מהר יותר מאיתנו. דוגמה? בטח. היה לי קובץ SRT עם כתוביות וזמנים לא מדויקים וקובץ נפרד של timestamps של מילים בו המילים עצמן לא היו מדויקות אבל ה timestamps כן, כלומר חלק מהמילים הופיעו עם שגיאות כתיב, חלק מהמילים לא הופיעו, חלק הופיעה מילה אחרת, אבל בגדול הזמנים שליד כל מילה היו מדויקים. עכשיו צריך לשלב בין השניים, לקחת את הטקסט מה SRT ולהתאים לכל תחילת משפט את הזמן האמיתי של תחילת המשפט לפי קובץ הזמנים. כתבתי ל AI:

write a script to fix the SRT timestamps based on transcript.txt assembly ai times. Walk both files in parallel ignoring small differences and fix timestamps in the SRT based on the
 transcript.txt word timestamps

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

Better -
start with the SRT, first line in the SRT includes N words
take these N words from the list of word-timestamps transcript.txt and use the first timestamp
Then continue iterating SRT lines

when a word doesn't match you can skip it, but if multiple words don't match (maybe 3) you should backtrack to check if a word was just skipped (missing)
if you can't match or backtrack raise an exception as there's a problem with either the script or the data

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

def align_and_fix(
    srt_entries: list[dict], ts_words: list[dict]
) -> list[dict]:
    """
    Align SRT entries with transcript word timestamps.
    Returns the entries list with new_start_ms / new_end_ms set.
    """
    # Flatten SRT words with entry tracking
    srt_flat = []  # (norm_word, entry_index)
    for entry in srt_entries:
        for w in entry["norm_words"]:
            srt_flat.append((w, entry["index"]))

    ts_norms = [w["norm"] for w in ts_words]

    sp = 0
    tp = 0
    entry_ts_map: dict[int, list[int]] = {}

    while sp < len(srt_flat) and tp < len(ts_norms):
        srt_word, ei = srt_flat[sp]

        if words_match(srt_word, ts_norms[tp]):
            entry_ts_map.setdefault(ei, []).append(tp)
            sp += 1
            tp += 1
        else:
            offset = find_sync(
                [w[0] for w in srt_flat], ts_norms, sp, tp
            )
            if offset is not None:
                tp += offset

📌 אנטרופיק לא בונים מודל ביקשתי מקלוד לכתוב Managed Agent שמתרגם מאנגלית לספרדית ותוך דקה קיבלתי ממשק שעובד לתרגום דרך AI. ביקשתי מ GPT את אותו דבר והוא הסביר לי מה צריך לעשות בשביל לבנות כזה סוכן. ההבדל בין השניים הוא לא היכולות של המודל. בהנתן אותו System Prompt ואותם כלים גם אופוס וגם GPT יכולים לבנות את המערכת. אבל כמובן שקלוד נתן חוויה כוללת טובה בהרבה. אנטרופיק לא בונים מודל. כלומר בטח הם מאמנים את קלוד אבל הראייה שלהם רחבה בהרבה. העתיד שלהם הוא פלטפורמה עליה ירוצו מערכות התוכנה של העתיד. אנטרופיק אולי מפרסמים שהם חברת מחקר ובטיחות AI אבל בפועל הם רוצים להיות ה AWS הבאה. והם לא היחידים: 1. לגוגל כבר יש ענן ומגנון להריץ עליו סוכנים. פעם קראו לזה Vertex AI אבל היום הם כבר Gemini Enterprise Agent Platform. 2. ל AWS יש את Bedrock וגם את AgentCore. 3. למייקרוסופט יש את Foundry חברות SaaS מתו? כל אחד יבנה לעצמו את התוכנה? הצחקתם אותם. התעשייה במירוץ למצוא מי יהיה ענן ה Saas הבא, ענן שמשלב את כל שירותי הענן הקלאסיים יחד עם פלטפורמת Gen AI. אנחנו רק בהתחלה. עכשיו הזמן הכי טוב ללמוד קוד.

📌 שלושה ימים של מחקר, עשר דקות פתרון בימים שלפני ה AI הבאגים הכי מעניינים היו אלה שדרשו מחקר רב כדי להבין מה קורה שם, ואז תיקון של שורה או פונקציה כדי לפתור את הבעיה. היום זה מאפיין של כמעט כל פיתוח. ו AI רק הופך את החלק הקשה ליותר קשה. בסיפור היום הסתכלתי על מנגנון בלנגלטס שמייצר מילים דומות לתרגיל שמיעה, כלומר אנחנו לוקחים מילה מהקטע מוחקים אותה ורוצים לראות שהמשתמש מצליח לזהות משמיעה את המילה. בתרגיל מציגים למשתמש את המילה מהקטע ומילה אחרת קרובה לה וצריך לבחור את המילה שנשמעה. במקור ניסיתי לגשת למודל שפה כדי לייצר את "המילה הדומה". בצ'אט היה נראה שהם ממש טובים בזה ומצליחים להפוך את house ל mouse. בעבודה האמיתית הם באמת היו טובים בזה חלק מהזמן, אבל בחלק אחר מהזמן נתקעו ב thinking אינסופי. לקח מעל שלוש שעות כדי לייצר מילים חלופיות לקטע של עשר דקות ואפילו זה לא תמיד הצליח. כל כמה שניסיתי לבקש מ AI לשפר את הקוד הוא התמקד ב Prompt Engineering. הוא הציע המון שינויים בפרומפטים, מודלים אחרים, שימוש חוזר במילים שכבר מצאנו - אבל בשום שלב לא חשב לוותר על הפנייה למודל שפה ולעבור למנגנון אחר. בגלל שהיה כל כך קל לנסות את ההצעות של קלוד (הוא כל הזמן מימש עוד הצעה), וכל בדיקה לקחה כמה שעות יצא שנסחפתי אחריו בלופ. רק אחרי שעצרתי לחשוב הבנתי שצריך כיוון אחר. מצאתי ספריה בשם symspell שיודעת למצוא מילים עם כתיב דומה למילה. הבעיה? הספריה ב rust והקוד שלי ברובי. אבל עכשיו זאת היתה ההזדמנות של קלוד להתחיל להיות מועיל. תוך עשר דקות הוא בנה ממשק שורת פקודה לספריית ה rust, מצא ברשת והוריד מילונים לערבית, אנגלית, ספרדית, צרפתית ורוסית והחליף את כל מנגנון חיפוש המילים החלופיות מ LLM לחיפוש דטרמניסטי עם symspell. המתכנתים המהירים בעתיד לא יהיו אלה שיודעים לכתוב קוד יותר מהר. זה חסר משמעות. המפתחים הטובים ביותר יהיו אלה שיודעים לראות איך המערכת מתחברת ולכוון את הקוד למקום אליו הוא צריך להגיע. הרבה פרסומות על AI יספרו לכם שהמפתח לעבודה מהירה עם AI הוא לדעת "לכוון" את הסוכן לקוד שאתם רוצים לקבל. האמת הקשה יותר היא שהמפתח לעבודה מהירה הוא ההבנה איזה קוד אנחנו רוצים לקבל.

📌 תוכנות שמשנות את עצמן העבודה עם פאי היתה מאירת עיניים לגבי העתיד ולגבי תוכנות שמסוגלות לשנות את עצמן. פאי הוא סוכן קידוד בקוד פתוח שגם מכיר את הקוד של עצמו וניתן להרחבה. בעבודה עם ריילס סוכני קידוד נוטים לכתוב סקריפטים במקום להשתמש ב REPL. יש כמה שרתי MCP שמחברים מודלים לריילס אבל לא ניסיתי אותם ובאופן כללי אני לא נלהב להוסיף שרתי MCP לסטאפ שלי. וככה הגעתי לפאי עם בקשה פשוטה - כתוב חיבור שיאפשר לך לפתוח Rails Console ולעבוד ב REPL שלו בלי לתקוע את ממשק הסוכן כלומר בלי לחכות שהתהליך "יסתיים", כי REPL-ים לא מסתיימים. עשר דקות מאוחר יותר התוסף לפאי היה באוויר. זה הקוד שנכתב: https://gist.github.com/ynonp/eba94cfebeecddbcae2cf1127d69f092 יש שם כמעט 500 שורות, טיפול בשגיאות, טיפול בסגירת ה console כשסוגרים את פאי, טיימאאוטים - במבט ראשון קוד הרבה יותר טוב ממה שאני הייתי כותב למטרה זו. והקוד אפילו עובד, כלומר הוא מתנהג כאילו הפעלתי את ה rails c וכאילו הסוכן יכול לכתוב בתוך ה REPL. הבעיה היחידה שזה לא מה שקורה שם. קריאה בקוד עצמו מראה לנו שהסוכן בחר לכתוב סקריפט REPL משלו שמתקשר עם התוסף באמצעות JSON. הוא גם מקצץ הדפסות כשהפלט ארוך מדי לטענתו "כמו שעושה פאי", אבל הכלים המובנים בפאי שומרים את הפלט המקוצץ לקובץ והתוסף החדש לא ממש. אין התאוששות משגיאות ואין התיחסות למקרי קצה או נעילות. בקיצור קוד ש"רוב הזמן עובד אצלי על המכונה". אפילו אם הקוד היה מושלם אני חושב שהבעיה הכי גדולה היא המימוש לא לפי ה Spec. כן AI יכול לכתוב קוד טוב אבל זה דורש תשומת לב, מפתחים שיקראו את הקוד והרבה פעמים יותר מנסיון אחד. מפתחים היום שחושבים שהם כותבים Spec והכל עובד אז לא צריך לקרוא את הקוד עלולים להתעורר בעוד כמה חודשים ולמצוא מערכת מאוד שונה ממה שהם חשבו שיש להם.

📌 חדש בפייתון מילון קפוא פייתון 15 הוסיפה מנגנון חדש שפותר כאב ראש מאוד ישן. זה נקרא frozendict וזה פשוט dict שאי אפשר לשנות אותו. עכשיו אני מבין שאתם מופתעים, מי צריך מילון שאי אפשר לשנות את מה שכתוב בו? מה לא מספיק לך dataclasses? נכון dataclass לא קפוא בברירת מחדל אבל אפשר בקלות להעביר frozen=True בבנאי ולקבל אותו קפוא. התשובה היא שתמיד טוב שיש דברים שלא משתנים ולא תמיד צריך או רצוי להגדיר dataclass. לפעמים יש לי מידע שקיבלתי דרך API או מידע שאני לא בטוח מה המבנה שלו, ובכל זאת אני רוצה להקפיא אותו. בשביל ליצור מילון קפוא מספיק להשתמש במילה החדשה frozendict החל מפייתון 3.15:

frozendict({"a": 10 })

או אם יש לכם מילון ביד אפשר לעטוף אותו ב frozendict:

d = {"a": 10}
f = frozendict(d)

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

from functools import lru_cache

@lru_cache
def sum_values(d):
    numbers = sum(v for v in d.values() if type(v) == int)
    others = {k: v for k, v in d.items() if not isinstance(v, int)}
    if len(others) == 0:
        return numbers

    return numbers + sum_values(frozendict({ k: sum_values(v) for k, v in others.items() }))

print(sum_values(frozendict(
    {
    "a": 10,
    "b": 20,
    "c": frozendict({ "a": 30, "b": 40 }),
    "d": frozendict({ "e": frozendict({"f": 100}) })
    })))