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

השבוע בוובינר נדבר על כלכלת טוקנים כלומר איך לבזבז פחות טוקנים כשבונים דברים עם 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. תהליכי עבודה אג'נטיים וסוכנים אוטונומיים הם האתגר הכי גדול היום מבחינת טוקנים. תהליך עבודה או סוכן אוטונומי יעבדו לפי תוכנית ולכן כל חוסר יעילות במנגנון שלהם מתורגם לצריכה מיותרת בטוקנים. מפתחים אנושיים עוד יכולים לשים לב שקופיילוט מתחיל להשתולל עם הטוקנים ולדייק אותו. עם כלים אוטומטיים אנחנו שמים לב לזה רק כשכבר מאוחר מדי.

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

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

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

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

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

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

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

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

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

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

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

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

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

כדאי לזכור:

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

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

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

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

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

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

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

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

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

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

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

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

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

https://www.tocode.co.il/talking_ai