ToCode

📌 חשוב לא שווה מעניין בתקופה שאנטרופיק לא הפסיקו לדבר על MCP זה היה המושג שעלה הכי הרבה בשיחות עם לקוחות. איך בונים MCP? האם אני צריך MCP? איך בדיוק זה עובד? מה ההבדל בין Resource ל Tool? היו שם הרבה כפתורים, כולם התלהבו מהטכנולוגיה וזה היה נראה כאילו אם רק תבין MCP תצליח לקבל תוצאות הרבה יותר טובות מסוכנים חכמים. אבל זה היה רק מסך עשן. רוב מה שצריך לדעת על MCP מסתכם במשפט "ואפשר לכתוב Tools בעצמנו כדי להרחיב את VS Code". משפט כזה שם את ה MCP במקום שלו, אחרי ו החיבור. שימוש בכלים הוא המבנה הבסיסי של סוכנים חכמים. מרגע שהבנו מה זה שימוש בכלים ואיך זה עובד, התחביר של איך לבנות כלים נוספים הוא בסך הכל עוד תחביר לא חשוב. ממילא AI יכול לבנות שרת MCP יותר מהר מאיתנו. חשוב - דברים שיישארו איתנו לאורך זמן, עקרונות, שיטות עבודה, פריימוורק איך להבין את העולם. דברים שלוקח הרבה זמן ללמוד ואחרי שהבנת אי אפשר לשכוח. מעניין - כלי חדש, טיפ שישנה לכם את החיים, שלושה שרתי MCP שאי אפשר לחיות בלעדיהם, מודל חדש, כפתור שאף אחד לא מכיר, זכרון אוטומטי. כשלא בטוחים חפשו את החשוב.

📌 כפול עשר המושג 10x programmer הומצא הרבה לפני ש AI כתב את כל הקוד. הוא בא לתאר את התופעה שיש מפתחים הרבה יותר יעילים שמקפיצים את הארגון קדימה ולפעמים מפתח או מפתחת כאלה יכולים להיות שווים לארגון אפילו יותר מעשרה אחרים. אותם מפתחי 10x כמובן לא מצטיינים בגלל שהם מקלידים מהר יותר (יש גבול כמה מהר אפשר להקליד, וממילא מהירות הקלדה אף פעם לא היתה הבעיה). התכונות שהפכו אותם ליעילים היו חדות חשיבה, יכולת לראות דברים שאחרים לא ראו, יכולת קבלת החלטות, בחירת הטכנולוגיה הנכונה, בניית מערכת כך שבאגים יקרו פחות או יהיו קלים יותר לאיתור. מדידת ביצועי 10x היתה חייבת להתבצע לאורך זמן. הרבה אנשים יכלו להיות כפול עשר יותר מהירים מאחרים במשימה ספציפית או באמצעות קיצורי דרך אבל בתוכנה סופם של באגים נסתרים להתגלות ולאורך זמן קיצורי דרך רק מאריכים את המסלול. בתוך הדיון הזה אפשר היה לאפיין 4 סוגים של מפתחים שנראים מאוד פרודוקטיביים אבל בעצם הם לא: 1. מעיין הקוד - אלה שכותבים עוד ועוד קוד. אם היית מודד אותם לפי שורות קוד הם בקלות כותבים כפול עשר שורות מכל האחרים, אבל שורות קוד אינן המדד לתוכנה טובה. 2. סוגרי הטיקטים - אלה שתמיד ימצאו עוד משימה קלה לפתור ומסיימים את תקופת המדידה עם כפול 10 טיקטים שנפתרו מכל השאר, כל זה בלי לעשות דבר אחד חשוב. 3. הארכיטקטים - שכל היום כותבים ומוחקים ועושים Refactor ובונים ארכיטקטורות שיוכלו להתמודד עם כל צרה שלא תבוא אבל אף פעם לא מגיעים לפרודקשן, או שמגיעים רק כדי לגלות שכל המבנה עמד על יסודות רעועים. אם המדד להצלחה הוא כמה שינויים עשית בפרויקט כל שבוע הארכיטקטים לוקחים את גביע הכפול עשר בלי להתבלבל. 4. הכמעט עובד - הם מתקתקים פיצ'רים וזה באמת נראה עובד אבל יש רק מקרה קצה אחד שעדיין לא הגיעו אליו או כמה בעיות פרודקשן קטנות. האמת היא שקיצורי הדרך שהם לוקחים לא מאפשרים להם להגיע ל 100%. הם אולי בונים כפול עשר יותר פיצ'רים אבל מכניסים כפול 100 יותר באגים. היום מפתחי הכפול עשר האלה נעזרים ב AI כדי להיות כפול 100 יותר ״פרודוקטיביים״. הם כותבים יותר קוד ממה שאפשר לקרוא, פותחים וסוגרים יותר טיקטים ממה שאפשר לעקוב, משנים את הפרויקט מקצה לקצה כל שבוע ומציפים אותנו בפיצ'רים שכמעט עובדים חוץ מכמה בעיות קטנות. ואיכות המוצר? שביעות רצון המשתמשים? תוכנות שעובדות? זה יחכה לאחרי הריליס.

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