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

טיפים קצרים וחדשות למתכנתים

מבחן ה Actually

14/05/2026

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

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

Wait, looking at the flow more carefully: Looking at checking.py more carefully: But wait - looking at the caller maigret() function Actually, let me re-read the code more carefully Actually, let me think about this differently Wait, but ... But wait, I should also add the check in Actually, looking at the code more carefully Actually the current code already handles this! Look at Let me think about this differently. Actually, the simplest and most maintainable approach Wait, but the user says Actually wait, let me re-read the user's request Actually, I think the most correct regex would be Actually, I need to be more careful Actually, let me think about this more practically

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

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

האם שפת התכנות עדיין חשובה?

13/05/2026

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

  1. שפת תכנות = אקוסיסטם. בגלל זה כולם כותבים GUI בשפות מבוססות ווב וכלי למידת מכונה בפייתון. אבל מה קורה כשאין אקוסיסטם? למה לנגגרף כתובה בפייתון ולא ב rust? למה אנחנו לא מתחילים לכתוב שרתים באליקסיר?

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

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

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

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

מה דעתכם?

היום למדתי: "חוץ מ" בגיט

12/05/2026

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

$ git add .
$ git reset api.js

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

$ git add . ':!api.js'

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

וכן זה עובד בכל הפקודות ב git שצריכות קבצים כמו add, rm, restore, log ועוד.

אז עדיין צריך הודעות קומיט?

11/05/2026

ב 2026 סוכני קידוד יודעים לכתוב הודעות קומיט טובות יותר מאיתנו גם בדיעבד. ניסיתי את זה - הפרומפט:

explain the commit 
1. what changed?
2. why?
3. what's still left to do for this issue?

עם הקומיט שעשיתי כאן:

https://github.com/ynonp/langlets-rails/commit/c07821619789ce2c814f9056088f0b083c7e92c7

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

ועכשיו השאלה בכותרת היא התלבטות אמיתית.

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

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

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

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

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

10/05/2026

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

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

המשך קריאה

טוקנים מיותרים

09/05/2026

ביקשתי מקלוד אופוס לכתוב דוגמה לאפליקציית Hello World בפלאסק. הקוד של main שהוא כתב היה:

from app import create_app

app = create_app()


if __name__ == "__main__":
    app.run(host="127.0.0.1", port=5100, debug=True)

פורט 5100 שם כי אני ביקשתי. את debug הוא כתב על דעת עצמו ו host הוא סתם רעש. פלאסק משתמש ב 127.0.0.1 בתור ערך ברירת מחדל.

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

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

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

המטרה היא לקבל מ AI קוד עובד בו אני מבין כל טוקן.

נ.ב. גם המודל וגם ה Harness אחראים לטוקנים המיותרים. לפעמים יותר קל להעתיק את הפרומפט ל pi או לקופיילוט ולראות מה הם יעשו במקום לנקות קוד מנופח של קלוד קוד. המשחק הוא לא AI אלא פייתון. לדעת שלא צריך לציין host=127.0.0.1 בקריאה ל run כי זו ברירת המחדל.

הוק לקלוד עבור קומיט אחרי כל שינוי

08/05/2026

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

חלק מהמשתתפים העירו שאפשר לעשות את הקומיטים האלה אוטומטית ואז לא שוכחים. הלכתי לחקור את הרעיון ושמחתי לראות שזה עבד די בקלות. אם אתם בקלוד קוד אפשר ליצור קובץ .claude/settings.json בתיקיית הפרויקט עם התוכן הבא:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/auto-commit.sh",
            "async": true,
            "timeout": 30
          }
        ]
      }
    ]
  }
}

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

#!/usr/bin/env bash
# Stop hook: auto-commit Claude's changes using the last user prompt
# as the commit message.

set -uo pipefail

INPUT=$(cat)
read -r STOP_HOOK_ACTIVE TRANSCRIPT_PATH PROJECT_DIR < <(
  printf '%s' "$INPUT" | jq -r '[.stop_hook_active // false, .transcript_path // "", .cwd // ""] | @tsv'
)

[ "$STOP_HOOK_ACTIVE" = "true" ] && exit 0

[ -n "$PROJECT_DIR" ] && cd "$PROJECT_DIR" 2>/dev/null || exit 0
git rev-parse --git-dir >/dev/null 2>&1 || exit 0
git add -A 2>/dev/null || exit 0
git diff --cached --quiet && exit 0

# Last user text message from this turn's transcript.
# Skips tool_result entries and slash-commands (which start with '<').
USER_PROMPT=""
if [ -f "$TRANSCRIPT_PATH" ]; then
  USER_PROMPT=$(jq -r '
    select(.type == "user") | .message.content
    | if type == "string" then .
      elif type == "array" then (map(select(.type == "text")) | .[0].text // "")
      else "" end
    | select(. != "" and (startswith("<") | not))
  ' "$TRANSCRIPT_PATH" 2>/dev/null | tail -1)
fi

# Use the user prompt as the commit message; first line as subject (capped at
# 72 chars), remaining lines as the body.
if [ -n "$USER_PROMPT" ]; then
  SUBJECT=$(printf '%s' "$USER_PROMPT" | head -1 | cut -c1-72)
  BODY=$(printf '%s' "$USER_PROMPT" | tail -n +2)
else
  SUBJECT="checkpoint: $(date +%H:%M)"
  BODY=""
fi

if [ -n "$BODY" ]; then
  git commit --no-verify -m "$SUBJECT" -m "$BODY" >/dev/null 2>&1 || true
else
  git commit --no-verify -m "$SUBJECT" >/dev/null 2>&1 || true
fi
exit 0

קלוד מפעיל את הסקריפט עם JSON של מידע על השיחה האחרונה. מה שמעניין אותנו מתוך ה JSON הזה הוא ההודעה של המשתמש, כי אני אוהב שהפרומפט שלי הופך להודעת הקומיט (אם צריך הודעה יותר מתוחכמת אפשר להשתמש ב git commit --amend כדי לתקן). ליתר בטחון קלוד הוסיף --no-verify לפקודת הקומיט כדי לדלג על קומיט הוקס. אני חושב שזה הוגן וממילא לא משתמש בקומיט הוקס. יש גם בדיקה בהתחלה שמדלגת על כל הסקריפט אם אנחנו לא בתוך ריפו.

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

איטרציות מהירות, פיצ'רים איטיים

07/05/2026

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

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

ההזדמנות היא לייצר את הקוד הנכון.

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

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

קריאה מודרכת בלולאת הסוכן של פאי

06/05/2026

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

הריפו של פאי נמצא כאן:

https://github.com/badlogic/pi-mono/

ובשביל להבין איך עובדת לולאת סוכן נסתכל על הקובץ:

https://github.com/badlogic/pi-mono/blob/main/packages/agent/src/agent-loop.ts

ונחפש את הפונקציה runLoop. זה המימוש כמו שהוא - סופר קריא ומתועד:

async function runLoop(
    currentContext: AgentContext,
    newMessages: AgentMessage[],
    config: AgentLoopConfig,
    signal: AbortSignal | undefined,
    emit: AgentEventSink,
    streamFn?: StreamFn,
): Promise<void> {
    let firstTurn = true;
    // Check for steering messages at start (user may have typed while waiting)
    let pendingMessages: AgentMessage[] = (await config.getSteeringMessages?.()) || [];

    // Outer loop: continues when queued follow-up messages arrive after agent would stop
    while (true) {
        let hasMoreToolCalls = true;

        // Inner loop: process tool calls and steering messages
        while (hasMoreToolCalls || pendingMessages.length > 0) {
            if (!firstTurn) {
                await emit({ type: "turn_start" });
            } else {
                firstTurn = false;
            }

            // Process pending messages (inject before next assistant response)
            if (pendingMessages.length > 0) {
                for (const message of pendingMessages) {
                    await emit({ type: "message_start", message });
                    await emit({ type: "message_end", message });
                    currentContext.messages.push(message);
                    newMessages.push(message);
                }
                pendingMessages = [];
            }

            // Stream assistant response
            const message = await streamAssistantResponse(currentContext, config, signal, emit, streamFn);
            newMessages.push(message);

            if (message.stopReason === "error" || message.stopReason === "aborted") {
                await emit({ type: "turn_end", message, toolResults: [] });
                await emit({ type: "agent_end", messages: newMessages });
                return;
            }

            // Check for tool calls
            const toolCalls = message.content.filter((c) => c.type === "toolCall");

            const toolResults: ToolResultMessage[] = [];
            hasMoreToolCalls = false;
            if (toolCalls.length > 0) {
                const executedToolBatch = await executeToolCalls(currentContext, message, config, signal, emit);
                toolResults.push(...executedToolBatch.messages);
                hasMoreToolCalls = !executedToolBatch.terminate;

                for (const result of toolResults) {
                    currentContext.messages.push(result);
                    newMessages.push(result);
                }
            }

            await emit({ type: "turn_end", message, toolResults });

            if (
                await config.shouldStopAfterTurn?.({
                    message,
                    toolResults,
                    context: currentContext,
                    newMessages,
                })
            ) {
                await emit({ type: "agent_end", messages: newMessages });
                return;
            }

            pendingMessages = (await config.getSteeringMessages?.()) || [];
        }

        // Agent would stop here. Check for follow-up messages.
        const followUpMessages = (await config.getFollowUpMessages?.()) || [];
        if (followUpMessages.length > 0) {
            // Set as pending so inner loop processes them
            pendingMessages = followUpMessages;
            continue;
        }

        // No more messages, exit
        break;
    }

    await emit({ type: "agent_end", messages: newMessages });
}

אלה החלקים המרכזיים:

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

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

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

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

  5. אם יש הודעות ניווט ממתינות נוסיף אותן לרשימת ההודעות של השיחה.

עכשיו מגיעה השורה הכי חשובה של הפונקציה:

const message = await streamAssistantResponse(currentContext, config, signal, emit, streamFn);

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

const toolCalls = message.content.filter((c) => c.type === "toolCall");

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

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

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

המשך קריאה

מתכנת עם מברג בכיס

05/05/2026

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

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

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

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

הבעיה שלהם היא הגישה.

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

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

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