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

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

אפשר לקרוא את התיעוד המלא ודוגמאות שלהם כאן:

https://pydantic.dev/docs/ai/overview/

והנה שלושה דברים שאהבתי במיוחד בספריה.

ההבטחה של Spec Driven Development היא פשוטה - במקום לכתוב ולקרוא קוד נעבור לכתוב ולקרוא איפיונים. במאמר ארוך בנושא ראיתי את ההמלצה הבאה:

Don’t kill the code reviews; just move the human checkpoint upstream to reviewing intent, specs, plans, constraints, and acceptance criteria. Code is actually the least important part of the reviews.

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

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

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

דוגמה קטנה מ langlets - ביקשתי מהסוכן פיצ'ר שכשלוחצים על מילה בטקסט יקפוץ פופאפ עם התרגום שלה. הסוכן הוסיף onclick על המילה אבל בגלל שמדובר ב JavaScript רגיל (לא ריאקט) בעמוד שהכיל הרבה טקסט נוצרו המון Event Handlers. לכל מילה היה את ה onclick שלה.

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

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

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

בין 2015 ל 2018 לימדתי קורסים בפיתוח Web ו Mobile Web. למרות שאנגולר יצאה לשוק כבר ב 2010 וריאקט ב 2013, רק באזור 2015 הטכנולוגיות האלה הבשילו ושינו את שוק העבודה. באותן שנים פגשתי המון מפתחי PHP ו jQuery שידעו הרבה יותר ממני על דפדפנים ובמיוחד על דפדפנים ישנים ובכל זאת התקשו למצוא עבודה.

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

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

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

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

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

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

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

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

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

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

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

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

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

בכלי שורת הפקודה זה די פשוט. הפקודה neon projects list מחזירה את כל הפרויקטים בתור טבלה. אני יכול להוסיף --output json כדי לקבל את הפלט בתור JSON ואז אפשר לחבר אליו כלי כמו jq כדי להריץ שאילתה ספציפית. אז אם אני מחפש האם קיים פרויקט בשם goomba אוכל להריץ:

neon projects list --output json | jq '.projects[] | select(.name == "goomba") | {id, name}'

התוצאה - אם יש כזה פרויקט נקבל JSON קטן עם ה id וה name של הפרויקט. אם אין יגיע פלט ריק.

ומה קורה ב MCP? הבעיה ב MCP היא שאין לי אופציה להעביר את הפלט לכלי נוסף כמו jq. ב MCP בשביל לענות על השאלה אני מפעיל את כלי רשימת הפרויקטים וצריך להעביר ל AI את כל הרשימה כדי להבין אם יש או אין פרויקט בשם מסוים. תיאורטית הפעלה של הפקודה מה CLI אמורה לחסוך טוקנים - במקום להכניס ל AI את כל הפרויקטים הוא יפעיל את הפקודה ויקבל רק את הפרטים של הפרויקט שאני מחפש.

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

use neon MCP and check if I have a project named goomba

התשובה שאין כזה עלתה 4.9 קרדיטים (כי ככה הם קוראים לטוקנים בקופיילוט היום).

בשיחה שניה ביקשתי:

use neon CLI tool and check if I have a project named goomba

קלוד בתוך הקופיילוט לא התרגש מהבקשה וענה:

The user wants to use the Neon CLI tool to check if they have a project named "goomba". Let me search for the Neon MCP tool that's configured in their workspace.

Looking at the mcp.json file, they have a Neon MCP server configured at https://mcp.neon.tech/mcp. Let me search for tools related to Neon.

לאחר מכן הוא הצליח למצוא כלי בשם neonctl והפעיל אותו כדי לקבל את כל רשימת הפרויקטים בתור טבלה וסיים עם ההודעה שאין לי כזה פרויקט והחיפוש עלה לי 4.7 קרדיטים - קצת פחות מה MCP אבל עדיין לא סיבה למסיבה.

בואו ננסה לעזור לו. כתבתי את הפרומפט הבא:

use neon CLI tool (called neon, it's already installed) and check if I have a project named goomba
  The CLI tool has --output json flag to get output as JSON. It returns an {"projects": [{"name": ...}, { ... }]}
  can use 'jq' to focus your query

הפעם הוא הריץ את הפקודה הנכונה:

neon projects list --output json | jq '.projects[] | select(.name == "goomba")'

והחזיר את התשובה שאין פרויקט במחיר מבצע של 3.8 קרדיטים בלבד, קרדיט שלם פחות ממה שעלה החיפוש דרך ה MCP או ירידה של 22% בעלות.

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

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

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

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

https://github.com/ynonp/webinar-demo-coloring-app

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

ביקשתי מקלוד להכין דוגמה לקורס שתראה איך להשתמש ב Celery בפייתון בשביל להוריד פוסטים מהבלוג מתוך כמה מכונות במקביל. נתתי את כל הפירוט הטכני וקלוד באמת יצר docker-compose.yml עם קונטיינרים לרדיס ולפייתון, הריץ כמה פעמים ותיקן באגים עד שהכל עבד והפוסטים נשמרו. אני נכנסתי לקוד רק כשהכל עבד ורק בשביל לסדר את הקוד עצמו: פונקציות קטנות ומדויקות יותר, חלוקה לקבצים, ממש בקטנה.

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

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

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

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

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

3. להשתמש בסוכנים כדי להציף את אותן נקודות כשל דרך Code Review.

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

1. פרומפט יותר טוב או מצב תכנון.

2. מימוש בפרויקט חדש (בלי דוגמת הסלרי הסינכרונית שמבלבלת את הסוכן).

3. מימוש בשלבים - קודם לבקש לכתוב את הקוד האסינכרוני שמוריד פוסט כולל בדיקות עליו ואז להמשיך ל Runner של רפיד.

בפייתון הפונקציה asyncio.to_thread משתמשת ב Thread Pool הדיפולטי של המערכת כדי להפעיל קוד סינכרוני בצורה שנראית אסינכרונית. היא עשויה להיראות כמו פתרון קסם כשיש לנו קוד אסינכרוני שצריך להפעיל פונקציה סינכרונית ארוכה ואנחנו לא רוצים לתקוע את ה Main Loop.

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

def ping_ip(ip: str, count: int = 4) -> tuple[str, float]:
    """Ping an IP address `count` times and return (ip, success_percent)."""
    if sys.platform == "win32":
        cmd = ["ping", "-n", str(count), ip]
    else:
        cmd = ["ping", "-c", str(count), ip]

    result = subprocess.run(
        cmd,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        text=True,
        errors="replace",
    )
    output = result.stdout + result.stderr

    # Parse packet loss percentage from output like "0.0% packet loss"
    match = re.search(r"(\d+(?:\.\d+)?)%\s+packet\s+loss", output, re.IGNORECASE)
    if match:
        loss_percent = float(match.group(1))
        success_percent = 100.0 - loss_percent
    else:
        # Could not parse output; assume total failure
        success_percent = 0.0

    print(f"IP = {ip}; success = {success_percent}")
    return ip, success_percent

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

    ips = [...]
    tasks = [ping_ip(ip) for ip in ips]
    results = await asyncio.gather(*tasks, return_exceptions=True)

    for result in results:
        if isinstance(result, Exception):
            print(f"Error: {result}")
        else:
            ip, success = result
            print(f"{ip}: {success:.1f}% successful pings") 

זה כמובן לא יעבוד כי ping_ip היא לא פונקציה אסינכרונית. היא לא מחזירה את השליטה ל Main Loop בזמן ביצוע ה ping והקוד פשוט ירוץ בצורה סדרתית בדיקה אחרי בדיקה.

במצב כזה מישהו יכול להציע להשתמש ב asynio.to_thread ואז לכתוב:

    tasks = [asyncio.to_thread(ping_ip, ip) for ip in ips]    
    results = await asyncio.gather(*tasks, return_exceptions=True)

    for result in results:
        if isinstance(result, Exception):
            print(f"Error: {result}")
        else:
            ip, success = result
            print(f"{ip}: {success:.1f}% successful pings")

עובד? בטח. אבל.

ההבדל בין Thread Pool ל Asyncio הוא בדיוק הסיבה בגללה רצינו להשתמש ב asyncio. הבעיה עם Threads היא שיש מספר מוגבל מהם כי מערכת ההפעלה לא אוהבת כשיוצרים יותר מדי. ה Default Thread Pool מכיל או 32 threads או מספר הליבות + 4, הקטן מביניהם. לעומת זאת ב asyncio אין לנו הגבלה על כמה משימות רצות במקביל.

איך זה מתורגם לביצועים? נשווה בין שתי הגרסאות.

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

uv run ping_ips_to_thread.py  0.12s user 0.22s system 1% cpu 20.283 total

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

uv run ping_ips.py  0.13s user 0.21s system 2% cpu 14.203 total

ככל שרשימת הכתובות תתארך כך גם ההפרש בין התוכניות יגדל.

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

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

עכשיו בואו נדבר על טוקנים.

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

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

1. המחיר שאני משלם על טוקנים צריך להתאים לקצב הפיתוח וצריך להתאים לרווחיות של המוצר.

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

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

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

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

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

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