"- Only mark genuine downtime as a break — do not use it for slow "
            "or informal but still on-topic teaching."
        ),
    )


def analyze_chunk(
    agent: Agent, chunk: dict, chunk_index: int, total_chunks: int
) -> list[Lesson]:
    """
    Analyze one chunk → list of lessons with timestamps converted to
    original video time.
    """
    offset = chunk["offset_seconds"]
    video_file = upload_chunk(chunk["path"], chunk_index)

    print(f"   🤖 Analyzing chunk {chunk_index}/{total_chunks - 1} "
          f"(offset={seconds_to_ts(offset)})...")
    t0 = time.time()

    result = agent.run_sync(
        [
            (
                f"This is chunk {chunk_index} of a longer course video. "
                f"The chunk starts at {seconds_to_ts(offset)} in the original video. "
                f"Identify all complete 10-15 minute lessons within this chunk. "
                f"Timestamps must be relative to THIS CHUNK (00:00:00 = chunk start). "
                f"Do NOT include lessons that are cut off at chunk boundaries — "
                f"adjacent overlapping chunks will capture them."
            ),
            video_file,
        ]
    )

    elapsed = time.time() - t0
    chunk_lessons = result.output.lessons
    print(f"      ✅ {len(chunk_lessons)} lessons found in {elapsed:.0f}s")

    # Convert chunk-relative timestamps to original video timestamps
    converted = []
    for lesson in chunk_lessons:
        rel_start = ts_to_seconds(lesson.start_timestamp)
        rel_end = ts_to_seconds(lesson.end_timestamp)
        abs_start = rel_start + offset
        abs_end = rel_end + offset
        converted.append(Lesson(
            index=0,  # will be re-indexed later
            start_timestamp=seconds_to_ts(abs_start),
            end_timestamp=seconds_to_ts(abs_end),
            is_break=lesson.is_break,
            # Force the canonical slug for breaks in code, rather than
            # trusting the model to use the right literal string.
            slug="breaktime" if lesson.is_break else lesson.slug,
            title=lesson.title,
            summary_markdown_hebrew=lesson.summary_markdown_hebrew,
        ))

    return converted

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

📌 יום 12 - לקחים מפיתוח סוכנים שכדאי לקחת לפרודקשן

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

1. תעדו את כל השיחות - עובד על המכונה שלי זה לא מספיק. לא רק כי דברים עובדים אחרת בפרודקשן אלא שספציפית סוכנים באמת מחזירים תשובות שונות כל פעם שנפנה אליהם. לקוח יכול להתלונן על בעיה ולא יהיה לכם מושג איפה להתחיל לחפש אותה. יש אינסוף פלטפורמות ששומרות היסטוריית שיחות של סוכנים וגם אין בעיה לשמור את כל ההודעות בבסיס הנתונים אצלכם באפליקציה. מה שחשוב שמרו גישה לכל מה שקרה, עוד תצטרכו אותה.
2. שימו לב לטוקנים - כשאתם בודקים את הסוכן אתם יודעים בדיוק מה לכתוב כי אתם כתבתם את הפרומפט. המשתמשים שלכם הולכים להשתמש בטקסטים הרבה יותר ארוכים ולשאול שאלות לא רלוונטיות. שימו לב להכניס מנגנונים שבודקים כמה טוקנים שיחה מסוימת עולה לכם ואולי לעצור שיחות שלא הולכות לכיוון הנכון. טריק נפוץ כאן הוא מנגנון של Guardrails שם סוכן נוסף קורא את השיחה בשביל להבין אם היא פרודוקטיבית או שעדיף לחתוך אותה.
3. חשבו על העומס - שיחה עם סוכן תופסת Thread וחיבור רשת כי הגולשים מחכים לתשובה שמגיעה ב Streaming. זו תבנית עבודה יחסית חדשה ולכן עלינו לבדוק שכל השרשרת עובדת כמו שצריך איתה. שימו סביבת Staging תגייסו חברים ותעמיסו הודעות על השרת לפני שמגיעים למשתמשים אמיתיים כדי לראות מה נשבר. לכל חברות הענן יש היום פתרונות Deployment לסוכנים שווה לבדוק אותם לפני שאתם מקימים סביבה משלכם.
4. בנו מנגנוני Fallback - כל סוכן עם טמפרטורה מעל 0 הולך להחזיר תשובות שונות בכל הפעלה. הוא יכול לא להחזיר תשובה בלבד, להחזיר תשובה חלקית או להחזיר ממש שטויות. נסו להגדיר fallback למודל אחר אם משהו נכשל ותמיד וודאו מה קורה כשהמודל יענה תשובות אחרות ממה שציפיתם.
5. הוציאו כמה שיותר עבודה מחוץ למודל - קוד הוא דטרמניסטי, מודל לא. אם אני צריך לתרגם טקסט אין לי ברירה אני צריך מודל שפה, אבל בשביל להוריד רווחים מסוף או תחילת שורה אני לא צריך אותו. כמה שתסדרו יותר טוב את המידע לפני שתגיעו למודל תקבלו תוצאות טובות ומדויקות יותר.
6. השקיעו בבחירת מודלים ופרומפטים (ושימו לב שזה הולך יחד) - המודל הכי יקר הוא לא תמיד הכי טוב ולא רק בגלל מהירות. כשאתם משנים מודל סיכוי טוב שתצטרכו לדייק מחדש את הפרומפט. הגדירו סט של קלטי בדיקה והפעילו אותם מול קבוצה של פרומפטים ומודלים שהכנתם מראש. כשיגיע מודל חדש תוכלו להריץ אותו על אותו סט של קלטי בדיקה. בצורה כזאת תוכלו להבין איזה מודל באמת נותן את התוצאה המדויקת ביותר ל Use Case שלכם.
7. שימו לב להרשאות - סוכן חכם לא יודע לקבל החלטות בצורה אמינה ולכן תמיד כדאי להניח שהפלט שנקבל ממנו הוא זדוני. איזה כלים הסוכן יכול להפעיל? איזה בקרה יעבור המידע מהסוכן לפני שייכנס למערכת? ולא, להוסיף עוד סוכן לא יעזור. יש לנקות את הפלט של הסוכנים בכל מעבר מסוכן לקוד רגיל.
8. לא חייבים להעביר למודל את כל השיחה ולא חייבים לכתוב רק סוכן אחד - כשאתם כותבים סוכן שיחה שימו לב שאתם לא צריכים להעביר את כל היסטוריית השיחה ולא חייבים להמשיך שיחה שלמה עם אותו סוכן. תבנית שעבדה לי טוב היתה להריץ סוכן "מיון" בתחילת השיחה וכשהשיחה מקבלת כיוון להעביר את השליטה לסוכן ספציפי יותר, וגם לתת לכל סוכן אפשרות לזרוק את השיחה חזרה לסוכן המיון (העברת שיחה לסוכן היא בסך הכל הפעלת כלי).
9. נסיונות חוזרים - מותר לשלוח את אותה שאלה לסוכן כמה פעמים אבל רוב הזמן זה לא אפקטיבי. אם יש משהו ששבר את הסוכן פעם ראשונה הרבה פעמים הוא ישבור את הסוכן גם פעם שניה ובכל מקרה אתם לא רוצים להיות על 30% כשלונות. השתמשו בכשלונות כדי ללמוד על הסוכנים שכתבתם, על ניקוי הקלט והפרומפטים ולהתאים אותם כדי לקבל תשובה נכונה על אותו קלט שנכשל.
10. צאו לדרך, גם אם זה לא מושלם - סוכנים חכמים הם עדיין טריק חדש בספר וכל סוכן שתכתבו ילמד אתכם המון. כל יום שתחכו רק תצא עוד דרך חדשה לכתוב סוכנים ושוב תחזרו להתחלה. קחו את Pydantic AI Agents או כל ספריה אחרת שאהבתם ובנו את הסוכן הראשון שלכם.

יש לכם עוד? ספרו לי בתגובות בטלגרם.

📌 מצאתי 8 בעיות

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

I found eight concrete cases where the uncommitted views cause redundant or oversized queries.

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

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

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

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

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

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

בוקר טוב כולם שימו לב העליתי תוכנית וובינרים חדשה החל משבוע הבא
https://www.tocode.co.il/talking_ai

תקבלו גם מייל מסודר אם אתם ברשימת הדיוור

📌 מה מעניין בסוכני קידוד?

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

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

Work with Claude directly in your codebase. Build, debug, and ship from your terminal, IDE, Slack, web, and more.

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

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

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

ומה קורה ב OpenAI? הנה כמה פיצ'רים עדכניים שלהם:

1. מצב "מטרה" שנועד לטפל במשימות ארוכות.
2. הפעלת סוכנים במקביל והפרדה ביניהם, כולל אינטגרציה עם git worktrees ושליטה במקביל על כל הסוכנים מתוך האפליקציה.
3. שימוש במחשב וחיבור סוכן הקידוד לתוכנות אחרות שמותקנות לי על המכונה.
4. חיבור מרחוק דרך הטלפון.
5. מערכת בניית אתרים שיודעת גם לפרסם את העבודה שלכם לרשת.
6. הצגת Diff של עבודת הסוכן ומעבר על הקוד מתוך קודקס.

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

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

https://fx.sh/

הוא מגיע אחרי פאי שמתגאה בליבה מינימליסטית ותשתית הרחבות מפותחת:

https://pi.dev/

ועוד סוכנים וותיקים יותר כמו opencode, goose ו cline.

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

האהוב עליי נקרא paseo והוא מספק סביבה להרצה וניהול סוכנים מרובים במקביל, כולל חיבור לטרמינל, עורך טקסט ודפדפן מובנה, אינטגרציה עם תוכנות שמותקנות על המחשב ועם git worktrees בשביל מקביליות. את paseo אפשר לחבר לקלוד קוד וקודקס אבל גם לסוכנים הקטנים יותר כמו fx ו pi כי כולם מדברים ACP.

כלי בשם agent deck מספק יכולות דומות אבל מתוך סביבת Terminal.

וייב קנבן שלוקח את לוח ה Kanban בתור המבנה המרכזי ובונה סוכנים סביבו.

ו kepler מהיוצרים של Git Kraken.

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

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

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

📌 חלוקת פיצ'רים או חלוקת מומחיות

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

אף אחד לא אהב את זה.

הרבה לפני ה AI בנינו פריימוורקים לצמצום הפער. בנינו תשתיות של Infra As Code וחיבורים לענן כדי שמפתחים יוכלו להקים לעצמם את התשתית ונפרדנו מתפקידי Sysadmin ו DB Admin לטובת Devops. בנינו פריימוורקים לפיתוח צד שרת וצד לקוח יחד והתחלנו לגייס מפתחי Full Stack. פריימוורק כמו Next.js עם האינטגרציה שלו ל Vercel מיועד לתת פתרון פיתוח מקצה לקצה בו מפתח אחד שמכיר את הפריימוורק יוכל לבנות פיצ'ר מלא או מוצר מלא לבד.

ואז הגיע ה AI והאיץ את התהליך.

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

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

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

1. צוות Backend אחראי על קריאת קוד ה Backend של המערכת, הטבלאות בבסיס הנתונים, השאילתות. כשהם מזהים בקוד בעיות או כפילויות אחריותם לבצע Refactor לחלקים הבעייתיים.
2. צוות בדיקות אחראי על שיפור בדיקות המערכת. הם מקבלים זמן ספציפי לקריאה ושיפור תשתית הבדיקות כדי לוודא שכולם משתמשים בתשתית טובה יותר ובודקים את הדברים הנכונים.
3. צוות FrontEnd אחראי על חווית המשתמש וקוד ה Front, שיפור הארכיטקטורה, יצירת אחידות בקומפוננטות ושיפורי ביצועים שקשורים לממשק.

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

📌 ההבדל בין שיפור לאופטימיזציה

אלה שני מושגים שאנחנו הרבה פעמים מבלבלים.

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

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

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

📌 לא מיועד לקריאה על ידי בני אדם

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

1. בפרויקט יש תיקיית _components ולידה תיקייה בשם components. כן הבנתי שאתם משתמשים ב shadcn אבל האילוצים הטכניים הם בחירה שלכם.
2. הפרויקט מכיל 3 תיקיות עזר נסתרות: .vercel, .next ו .eve.
3. הפרויקט כולל 3 מנגנוני אימות משתמשים: אחד דרך vercel, שני חיבור מקומי בפיתוח ושלישי הוא Placeholder שעלינו להחליף בפלאגין אותנטיקציה אמיתי אחרי שנבחר אחד.
4. גישה ל Sessions מבוצעת דרך נתיב בשם s. כן רק האות s ואחריה מזהה ה Session.

הנה DHH מתוך הדוקטרינה של ריילס בשביל השוואה:

We write code not just to be understood by the computer or other programmers, but to bask in the warm glow of beauty. Aesthetically pleasing code is a value unto itself and should be pursued with vigor. That doesn’t mean that beautiful code always trumps other concerns, but it should have a full seat at the table of priorities.

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

class Project < ApplicationRecord
  belongs_to :account
  has_many :participants, class_name: 'Person'
  validates_presence_of :name
end

מעט שורות, הרבה משמעות ונקרא כשפה טבעית.

בפרויקט eve החדש זה התוכן של page.tsx:

import { AgentChat } from "@/app/_components/agent-chat";

export default function Page() {
  return <AgentChat />;
}

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

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

from pydantic_ai import Agent

agent = Agent('openai:gpt-5.2', instructions='You are a helpful assistant.')
app = agent.to_web()

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

📌 מה בעצם הבעיה שם?

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

"מה בעצם הבעיה?"

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

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

אבל זאת לא ההשוואה הנכונה.

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

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

📌 טעויות שלא רואים

טעות בפרומפט גרמה לסוכן לעלות מ 10% שגיאות ל 30%.

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

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

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

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

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

📌 קלישאות של AI שמצאתי בטקסטים שאני כתבתי

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

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.

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

  
Hi,

You know when you ship a cool feature and think people will notice and use it? But... they don't.

Yes, that was us, with our Code Review and GitHub integration features.

Not because they're not useful. In fact, some of the customers I spoke with asked for those features but didn't know they were already there! 😅

I guess that's on us: maybe we didn't make these features easy enough to discover.

So, we recorded a nice video to show them!